jonah-fleet 1.30.4 → 1.31.0

package/CHANGELOG.md

@@ -5,6 +5,20 @@ All notable changes to `jonah-fleet` will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.31.0](https://github.com/Jonah-Projects/jonah-fleet/compare/v1.30.5...v1.31.0) (2026-10-01)
+
+
+### Features
+
+* **product-planning:** establish Continuous Staging Container lifecycle and cycle lookback ([#526](https://github.com/Jonah-Projects/jonah-fleet/issues/526)) ([2bfd318](https://github.com/Jonah-Projects/jonah-fleet/commit/2bfd31897c7a32f359b2b6ba8dd4d87b7c6b9b5c))
+
+## [1.30.5](https://github.com/Jonah-Projects/jonah-fleet/compare/v1.30.4...v1.30.5) (2026-10-01)
+
+
+### Bug Fixes
+
+* **worktree:** disambiguate base ref against local origin/main branch ([#519](https://github.com/Jonah-Projects/jonah-fleet/issues/519)) ([1e3e6f2](https://github.com/Jonah-Projects/jonah-fleet/commit/1e3e6f2cdc2e5e774fc050be5686254de935d798))
+
 ## [1.30.4](https://github.com/Jonah-Projects/jonah-fleet/compare/v1.30.3...v1.30.4) (2026-10-01)
 
 
@@ -21,6 +35,14 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased] - 2026-10-01
 
+### Features
+
+* **product-planning:** establish Continuous Staging Container lifecycle (`status:staging`) and 16-day cycle lookback window so daily telemetry directives stream continuously without mid-sprint loss
+* **product-planning:** remove artificial 3-proposal cap so planning stages all relevant proposals for operator review
+* **analytics-review:** stream daily measurement directives directly as comments into active product plan staging containers with self-healing lazy initialization
+* **design-review:** stream visual critique, clutter analysis, and pruning directives directly into active product plan staging containers instead of creating standalone open tracking issues
+* **labels:** add `status:staging` to default fleet label taxonomy for upcoming product planning containers
+
 ### Bug Fixes
 
 * **workflows:** mark quota-paused workflow runs as failed (`exit 1`) with an error annotation and keep routine issues open with `status:quota-paused` instead of falsely reporting success

package/dist/index.js

@@ -1373,6 +1373,7 @@ var FLEET_CORE_LABELS = [
   { name: "status:success", color: "0e8a16", description: "Routine execution succeeded" },
   { name: "status:failure", color: "d93f0b", description: "Routine execution failed" },
   { name: "status:quota-paused", color: "e4e669", description: "Routine execution paused due to API quota limits" },
+  { name: "status:staging", color: "fbca04", description: "Staging container for upcoming product proposals" },
   { name: "needs-attention", color: "e11d48", description: "Requires maintainer triage" },
   { name: "runner:github-actions", color: "1f883d", description: "Executed via GitHub Actions" },
   { name: "runner:local", color: "bfd4f2", description: "Executed via local machine daemon" },
@@ -3854,16 +3855,15 @@ async function createWorktree(repoRoot, options) {
     }
   }
   let baseRef = options.baseRef;
-  if (!baseRef) {
-    try {
-      await execFileAsync3("git", ["rev-parse", "--verify", "origin/main"], { cwd: repoRoot });
-      baseRef = "origin/main";
-    } catch {
+  if (!baseRef || baseRef === "origin/main") {
+    const candidates = ["refs/remotes/origin/main", "refs/heads/main", "main"];
+    baseRef = "HEAD";
+    for (const candidate of candidates) {
       try {
-        await execFileAsync3("git", ["rev-parse", "--verify", "main"], { cwd: repoRoot });
-        baseRef = "main";
+        await execFileAsync3("git", ["rev-parse", "--verify", candidate], { cwd: repoRoot });
+        baseRef = candidate;
+        break;
       } catch {
-        baseRef = "HEAD";
       }
     }
   }

package/dist/lib/labels.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"labels.d.ts","sourceRoot":"","sources":["../../src/lib/labels.ts"],"names":[],"mappings":"AAAA,OAAO,EAAqB,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAGjE,MAAM,WAAW,aAAa;IAC5B,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,eAAe,EAAE,MAAM,CAAC;IACxB,gBAAgB,EAAE,MAAM,CAAC;IACzB,qBAAqB,EAAE,MAAM,CAAC;IAC9B,sBAAsB,EAAE,MAAM,CAAC;CAChC;AAED,MAAM,MAAM,aAAa,GAAG,QAAQ,GAAG,sBAAsB,GAAG,YAAY,GAAG,UAAU,CAAC;AAE1F,MAAM,WAAW,mBAAoB,SAAQ,aAAa;IACxD,QAAQ,EAAE,aAAa,CAAC;CACzB;AAED,MAAM,WAAW,gBAAgB;IAC/B,MAAM,EAAE,mBAAmB,EAAE,CAAC;IAC9B,kBAAkB,EAAE,mBAAmB,EAAE,CAAC;IAC1C,UAAU,EAAE,mBAAmB,EAAE,CAAC;IAClC,QAAQ,EAAE,mBAAmB,EAAE,CAAC;IAChC,GAAG,EAAE,mBAAmB,EAAE,CAAC;CAC5B;AAED,eAAO,MAAM,gCAAgC,EAAE,MAAM,EAqBpD,CAAC;AAEF,wBAAgB,gBAAgB,CAC9B,SAAS,EAAE,MAAM,EACjB,iBAAiB,GAAE,MAAM,EAAqC,GAC7D,OAAO,CAcT;AAED,wBAAgB,cAAc,CAC5B,MAAM,EAAE,aAAa,EAAE,EACvB,iBAAiB,GAAE,MAAM,EAAqC,GAC7D,gBAAgB,CAyClB;AAED,wBAAsB,eAAe,CACnC,cAAc,CAAC,EAAE,MAAM,EACvB,GAAG,GAAE,MAAsB,EAC3B,QAAQ,GAAE,UAA8B,GACvC,OAAO,CAAC,MAAM,CAAC,CAiBjB;AAiCD,wBAAsB,eAAe,CACnC,cAAc,CAAC,EAAE,MAAM,EACvB,QAAQ,GAAE,UAA8B,EACxC,GAAG,GAAE,MAAsB,GAC1B,OAAO,CAAC,aAAa,EAAE,CAAC,CA6D1B;AAED,MAAM,WAAW,kBAAkB;IACjC,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,GAAG,CAAC,EAAE,OAAO,CAAC;IACd,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,iBAAiB,CAAC,EAAE,MAAM,EAAE,CAAC;IAC7B,QAAQ,CAAC,EAAE,UAAU,CAAC;CACvB;AAED,MAAM,WAAW,iBAAiB;IAChC,IAAI,EAAE,MAAM,CAAC;IACb,UAAU,EAAE,gBAAgB,CAAC;IAC7B,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,MAAM,EAAE,KAAK,CAAC;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAChD,MAAM,EAAE,OAAO,CAAC;CACjB;AAED,wBAAsB,WAAW,CAAC,OAAO,GAAE,kBAAuB,GAAG,OAAO,CAAC,iBAAiB,CAAC,CA6C9F;AAED,MAAM,WAAW,oBAAoB;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,EAAE,MAAM,CAAC;CACrB;AAED,eAAO,MAAM,iBAAiB,EAAE,oBAAoB,EAkBnD,CAAC;AAEF,MAAM,WAAW,qBAAqB;IACpC,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,aAAa,EAAE,MAAM,EAAE,CAAC;IACxB,MAAM,EAAE,KAAK,CAAC;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;CACjD;AAED,wBAAsB,eAAe,CAAC,OAAO,GAAE;IAC7C,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,QAAQ,CAAC,EAAE,UAAU,CAAC;CAClB,GAAG,OAAO,CAAC,qBAAqB,CAAC,CA8CtC"}
+{"version":3,"file":"labels.d.ts","sourceRoot":"","sources":["../../src/lib/labels.ts"],"names":[],"mappings":"AAAA,OAAO,EAAqB,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAGjE,MAAM,WAAW,aAAa;IAC5B,EAAE,EAAE,MAAM,CAAC;IACX,IAAI,EAAE,MAAM,CAAC;IACb,WAAW,CAAC,EAAE,MAAM,GAAG,IAAI,CAAC;IAC5B,KAAK,CAAC,EAAE,MAAM,CAAC;IACf,eAAe,EAAE,MAAM,CAAC;IACxB,gBAAgB,EAAE,MAAM,CAAC;IACzB,qBAAqB,EAAE,MAAM,CAAC;IAC9B,sBAAsB,EAAE,MAAM,CAAC;CAChC;AAED,MAAM,MAAM,aAAa,GAAG,QAAQ,GAAG,sBAAsB,GAAG,YAAY,GAAG,UAAU,CAAC;AAE1F,MAAM,WAAW,mBAAoB,SAAQ,aAAa;IACxD,QAAQ,EAAE,aAAa,CAAC;CACzB;AAED,MAAM,WAAW,gBAAgB;IAC/B,MAAM,EAAE,mBAAmB,EAAE,CAAC;IAC9B,kBAAkB,EAAE,mBAAmB,EAAE,CAAC;IAC1C,UAAU,EAAE,mBAAmB,EAAE,CAAC;IAClC,QAAQ,EAAE,mBAAmB,EAAE,CAAC;IAChC,GAAG,EAAE,mBAAmB,EAAE,CAAC;CAC5B;AAED,eAAO,MAAM,gCAAgC,EAAE,MAAM,EAqBpD,CAAC;AAEF,wBAAgB,gBAAgB,CAC9B,SAAS,EAAE,MAAM,EACjB,iBAAiB,GAAE,MAAM,EAAqC,GAC7D,OAAO,CAcT;AAED,wBAAgB,cAAc,CAC5B,MAAM,EAAE,aAAa,EAAE,EACvB,iBAAiB,GAAE,MAAM,EAAqC,GAC7D,gBAAgB,CAyClB;AAED,wBAAsB,eAAe,CACnC,cAAc,CAAC,EAAE,MAAM,EACvB,GAAG,GAAE,MAAsB,EAC3B,QAAQ,GAAE,UAA8B,GACvC,OAAO,CAAC,MAAM,CAAC,CAiBjB;AAiCD,wBAAsB,eAAe,CACnC,cAAc,CAAC,EAAE,MAAM,EACvB,QAAQ,GAAE,UAA8B,EACxC,GAAG,GAAE,MAAsB,GAC1B,OAAO,CAAC,aAAa,EAAE,CAAC,CA6D1B;AAED,MAAM,WAAW,kBAAkB;IACjC,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,MAAM,CAAC,EAAE,OAAO,CAAC;IACjB,GAAG,CAAC,EAAE,OAAO,CAAC;IACd,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,iBAAiB,CAAC,EAAE,MAAM,EAAE,CAAC;IAC7B,QAAQ,CAAC,EAAE,UAAU,CAAC;CACvB;AAED,MAAM,WAAW,iBAAiB;IAChC,IAAI,EAAE,MAAM,CAAC;IACb,UAAU,EAAE,gBAAgB,CAAC;IAC7B,MAAM,EAAE,MAAM,EAAE,CAAC;IACjB,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,MAAM,EAAE,KAAK,CAAC;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAChD,MAAM,EAAE,OAAO,CAAC;CACjB;AAED,wBAAsB,WAAW,CAAC,OAAO,GAAE,kBAAuB,GAAG,OAAO,CAAC,iBAAiB,CAAC,CA6C9F;AAED,MAAM,WAAW,oBAAoB;IACnC,IAAI,EAAE,MAAM,CAAC;IACb,KAAK,EAAE,MAAM,CAAC;IACd,WAAW,EAAE,MAAM,CAAC;CACrB;AAED,eAAO,MAAM,iBAAiB,EAAE,oBAAoB,EAmBnD,CAAC;AAEF,MAAM,WAAW,qBAAqB;IACpC,IAAI,EAAE,MAAM,CAAC;IACb,OAAO,EAAE,MAAM,EAAE,CAAC;IAClB,aAAa,EAAE,MAAM,EAAE,CAAC;IACxB,MAAM,EAAE,KAAK,CAAC;QAAE,KAAK,EAAE,MAAM,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;CACjD;AAED,wBAAsB,eAAe,CAAC,OAAO,GAAE;IAC7C,IAAI,CAAC,EAAE,MAAM,CAAC;IACd,GAAG,CAAC,EAAE,MAAM,CAAC;IACb,QAAQ,CAAC,EAAE,UAAU,CAAC;CAClB,GAAG,OAAO,CAAC,qBAAqB,CAAC,CA8CtC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jonah-fleet",
-  "version": "1.30.4",
+  "version": "1.31.0",
   "description": "Standalone autonomous agent fleet with Symphony orchestration, claim protocols, and continuous improvement loops",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/templates/prompts/ORCHESTRATION.md

@@ -261,10 +261,15 @@ How changes and innovations from upstream ecosystems—[openai/symphony](https:/
 
 How closed-loop feedback from product telemetry and measurement trackers drives product decisions while preventing autonomous agents from falling into telemetry rabbit holes:
 
-1. **Mandatory Post-Measurement Action Rule**: When `analytics-review` concludes an evaluation of a feature or experiment tracker (especially sub-threshold features with <2% user adoption or >50% failure rates), it MUST emit a structured directive: `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`. Measurement closure is never a terminal dead-end; outcomes are staged into an active `🗺️ Product Plan` (which must be currently `state: open`; agents must never stage into or comment on closed/past product plans) or actionable `roadmap/*` issues.
-2. **Feature Pruning & Deprecation Audit**: During Propose mode sweeps, `product-planning` actively audits shipped roadmap items and closed measurement trackers. For features with low ROI (<2% adoption, >50% error/failure rate), it drafts explicit deprecation, removal, or simplification proposals alongside new feature additions, keeping the codebase and UI lean.
-3. **Intent vs. Defect Guardrail**: When investigating underperforming or zero-conversion features, `autowork` and `diagnosing-bugs` verify whether the issue is a software defect or a lack of user intent. If the feature functions properly without runtime errors but user interaction is negligible, agents must classify the issue as a **product/UX intent question** (`needs-design` / `roadmap/*`) rather than falling into the **Telemetry Rabbit Hole** (adding redundant fallback telemetry, defensive error handling, or retry loops for unwanted features).
-4. **Post-Merge Measurement Tracker Ingestion**: When `peer-review` squash-merges an approved PR, it inspects the tracking issue or spec for `## Telemetry & Measurement Decisions`. If a Tier 1 or Tier 2 companion measurement issue is outlined (`Measure: <Feature Name>`), `peer-review` automatically files the tracker with the `measurement` label upon merge, ensuring downstream `analytics-review` sweeps are never starved of intake.
+1. **Mandatory Post-Measurement Action Rule**: When `analytics-review` concludes an evaluation of a feature or experiment tracker (especially sub-threshold features with <2% user adoption or >50% failure rates), it MUST emit a structured directive: `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`. Measurement closure is never a terminal dead-end; outcomes are streamed directly into an active, open `🗺️ Product Plan` staging container.
+2. **Continuous Product Plan Staging Container Protocol**:
+   - Exactly one open staging container issue (`routine:product-planning`, `status:staging`) exists in the repository at all times (`🗺️ Product Plan — {Next Date} (Staging)`).
+   - Daily `analytics-review` sweeps stream conclusive directives, UI friction findings, and tracker verdicts directly into this open staging container via comments, eliminating the 14-day vacuum between planning cycles. If no staging container exists, `analytics-review` lazily initializes it.
+   - When `product-planning` runs in Propose mode, it reads the staging container's accumulated comments and executes a trailing 16-day lookback sweep across closed measurement trackers, synthesizing all directives into the final proposals and transitioning the issue to `needs-human` for operator review.
+   - When approved and triggered in Promote mode, `product-planning` decomposes epics, updates `ROADMAP.md`, closes the current plan, and **immediately seeds the next staging container** for the upcoming cycle.
+3. **Feature Pruning & Deprecation Audit**: During Propose mode sweeps, `product-planning` actively audits shipped roadmap items and closed measurement trackers. For features with low ROI (<2% adoption, >50% error/failure rate), it drafts explicit deprecation, removal, or simplification proposals alongside new feature additions, keeping the codebase and UI lean.
+4. **Intent vs. Defect Guardrail**: When investigating underperforming or zero-conversion features, `autowork` and `diagnosing-bugs` verify whether the issue is a software defect or a lack of user intent. If the feature functions properly without runtime errors but user interaction is negligible, agents must classify the issue as a **product/UX intent question** (`needs-design` / `roadmap/*`) rather than falling into the **Telemetry Rabbit Hole** (adding redundant fallback telemetry, defensive error handling, or retry loops for unwanted features).
+5. **Post-Merge Measurement Tracker Ingestion**: When `peer-review` squash-merges an approved PR, it inspects the tracking issue or spec for `## Telemetry & Measurement Decisions`. If a Tier 1 or Tier 2 companion measurement issue is outlined (`Measure: <Feature Name>`), `peer-review` automatically files the tracker with the `measurement` label upon merge, ensuring downstream `analytics-review` sweeps are never starved of intake.
 
 ---
 

package/templates/prompts/analytics-review.md

@@ -20,7 +20,7 @@ The run is SUCCESS only if ALL of these are true:
 - [ ] For conclusive measurement issues: synthesized adoption metrics (CTR, conversion rate, error frequency) against defined success criteria
 - [ ] For sub-threshold features (<2% user adoption or >50% failure rate) or conclusive outcomes, outputted a structured directive: `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`
 - [ ] Evaluated UI friction signals (grouping `$rageclick` by URL and element) and applied the Nudge & Banner Fatigue rule for promotional elements exceeding 500 impressions with CTR < 2.0%
-- [ ] For conclusive measurement trackers or sub-threshold features: staged the recommendation directly into an active, open `🗺️ Product Plan` staging issue or filed an actionable `roadmap/*` issue for `product-planning` to review; if all trackers remain active/healthy with no new directives, logged scan status to the routine run issue
+- [ ] For conclusive measurement trackers, sub-threshold features, or actionable UI friction findings: streamed the directive directly as a comment into an active, open `🗺️ Product Plan` staging issue (`routine:product-planning`, `status:staging`) or lazily initialized the upcoming staging container if missing; if all trackers remain active/healthy with no new directives, logged scan status to the routine run issue
 - [ ] Closed resolved measurement trackers with full analysis summaries and Antigravity run footer
 
 If any criterion cannot be met, stop immediately and log FAILURE with the reason.
@@ -96,20 +96,64 @@ When a measurement tracker is conclusive or reaches sub-threshold adoption (<2%
    - `RECOMMENDATION: DEPRECATE` — Feature has negligible adoption (<2%) or high maintenance overhead (>50% failures); recommend simplification or clean removal.
    - `RECOMMENDATION: ITERATE` — Metric target met or trending positively; recommend next phase or expanded rollout.
 
-### Step 4: Bridge outcome to `product-planning`
+### Step 4: Bridge outcomes to `product-planning` (Continuous Staging Container Stream)
 
-When conclusive measurement directives (`RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`) are emitted:
-1. Search for an **active, OPEN** product planning staging issue:
+When conclusive measurement directives (`RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`) or actionable UI friction signals (recurring rageclick clusters or banner fatigue findings from Step 2.5) are identified:
+1. Search for the **active, OPEN** product planning staging issue:
    ```bash
-   gh issue list --state open --search "Product Plan"
+   gh issue list --state open --label "routine:product-planning" --limit 1
    ```
    **Active Staging Issue Invariant**: A staging issue is active ONLY if its state is currently **OPEN**. If an issue is closed, it is a historical plan from a past cycle and MUST be ignored. **NEVER comment on, reopen, or edit closed product plan issues (`state: closed`).**
-2. If an open staging issue exists (e.g. `🗺️ Product Plan — {YYYY-MM-DD}`):
-   - Stage the recommendation under its `### Feature Pruning & Deprecation Audit` or `### Backlog Re-rankings` section.
-3. If no open staging issue exists (the expected state between planning sweeps):
-   - Do NOT comment on past closed product plans.
-   - For actionable pivots, deprecations, or feature modifications requiring planning review, open an actionable `roadmap/*` issue labeled `needs-design` or `enhancement` detailing the measurement verdict and recommendation for the next product planning sweep.
-4. If no trackers reached a conclusive state during this run and all evaluated trackers remain healthy/within measurement horizon:
+2. If an open staging issue exists (e.g. `🗺️ Product Plan — {YYYY-MM-DD} (Staging)` or `🗺️ Product Plan — {YYYY-MM-DD}`):
+   - Stream and append conclusive recommendations and telemetry evidence directly as comments into the open staging issue:
+     ```bash
+     gh issue comment "$STAGING_ISSUE_NUMBER" --body "### 🗺️ Telemetry Learning & Action Directive ($(date -u +%Y-%m-%d))
+     - **Tracker**: #$TRACKER_NUMBER ($TRACKER_TITLE)
+     - **Verdict**: \`RECOMMENDATION: $DIRECTIVE\`
+     - **Telemetry Readout**: Target vs Actual metrics, root cause (Intent vs. Defect)
+     - **Product Directive**: Actionable recommendation for next product planning sweep
+
+     ---
+     [![Fleet](https://img.shields.io/badge/Fleet-Autonomous_Command-BBF65D?style=flat&logo=githubactions)](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})
+
+     _Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_"
+     ```
+   - For standalone UI friction findings (e.g. `$rageclick` clusters or banner fatigue without an attached tracker), stream an actionable friction directive comment:
+     ```bash
+     gh issue comment "$STAGING_ISSUE_NUMBER" --body "### ⚠️ UI Friction & Fatigue Signal ($(date -u +%Y-%m-%d))
+     - **Component / URL**: \`$ELEMENT_SELECTOR\` on \`$PAGE_URL\`
+     - **Signal**: Rage clicks ($RAGECLICK_COUNT events) / Banner fatigue ($IMPRESSIONS impressions, CTR $CTR%)
+     - **Recommendation**: Redesign, throttle, or deprecate component to eliminate user friction
+
+     ---
+     [![Fleet](https://img.shields.io/badge/Fleet-Autonomous_Command-BBF65D?style=flat&logo=githubactions)](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})
+
+     _Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_"
+     ```
+3. **Self-Healing Fallback (Lazy Seed)**: If NO open staging issue exists (e.g. initial repository setup, or previous plan closed without seeding):
+   - Lazily initialize the upcoming product plan staging container rather than dropping learnings or commenting on closed issues:
+     ```bash
+     STAGING_TITLE="🗺️ Product Plan — $(date -u +%Y-%m-%d) (Staging)"
+     STAGING_BODY="## 🗺️ Upcoming Product Plan (Continuous Staging Container)
+
+     This staging container accumulates daily telemetry findings, feature audits, and measurement directives between planning sweeps.
+
+     ### Feature Pruning, Deprecation & Pivot Audit
+     - (Accumulating from daily analytics-review runs)
+
+     ### Accumulated Directives & Telemetry Stream
+     - Daily directives are streamed below as comments.
+
+     ---
+     [![Fleet](https://img.shields.io/badge/Fleet-Autonomous_Command-BBF65D?style=flat&logo=githubactions)](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})
+
+     _Initialized autonomously by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_"
+
+     STAGING_URL=$(gh issue create --title "$STAGING_TITLE" --body "$STAGING_BODY" --label "routine:product-planning,status:staging")
+     STAGING_ISSUE_NUMBER=$(echo "$STAGING_URL" | grep -oE '[0-9]+$')
+     ```
+   - Then append the directive or friction comment to the newly created `$STAGING_ISSUE_NUMBER`.
+4. If no trackers reached a conclusive state and no actionable UI friction was detected during this run, and all evaluated trackers remain healthy/within measurement horizon:
    - Do not stage redundant directives or file unnecessary roadmap issues.
    - Record tracker evaluation progress in the routine run issue (`$ROUTINE_ISSUE_NUMBER`) and `.jonah-fleet/run-report.md`.
 

package/templates/prompts/design-review.md

@@ -21,8 +21,8 @@ The run is SUCCESS only if ALL of these are true:
 - [ ] Performed Tier 2 Headless Browser & Visual Critique: launched the dev environment and captured viewports at mobile (390px) and desktop (1280px) via `run` and `design-critique` skills, auditing whitespace consistency, visual hierarchy, touch targets, and viewport density (enforcing the mobile fold budget: max 1 banner/nudge)
 - [ ] Cross-referenced UI friction and telemetry signals: checked for recurring rage clicks (`$rageclick`) and identified low-interaction (<2% CTR) secondary elements or persistent nudges suitable for pruning
 - [ ] Executed Hybrid Handoff:
-  - If self-contained token, class, or contrast violations were found, filed or updated exactly one grouped punchlist issue titled `🎨 Design Polish & Token Cleanup — {YYYY-MM-DD}` labeled `design/polish` for Autowork
-  - Created or updated exactly one tracking issue titled `🎨 Design Review — {YYYY-MM-DD}` documenting: Surfaces Reviewed (with any `[NEW SURFACE]` highlighted), Next Surfaces in Rotation, Visual Critique & Clutter Analysis, Feature Pruning & Deprecation Recommendations, and Experience Enhancement Opportunities
+  - If self-contained token, class, or contrast violations were found, filed or updated exactly one grouped punchlist issue titled `🎨 Design Polish & Token Cleanup — {YYYY-MM-DD}` labeled `design/polish`, `autowork-candidate` for Autowork
+  - Streamed the overarching design audit, visual critique, clutter analysis, pruning recommendations, and experience enhancement opportunities directly as a comment into the active, open `🗺️ Product Plan` staging container (`routine:product-planning`, `status:staging`)
 - [ ] Emitted structured design directives in the run report (`DESIGN_DIRECTIVE: [PRUNE | REDESIGN | POLISH]`) and recorded the next queued surfaces for the subsequent run
 - [ ] Recorded the final execution report to `.jonah-fleet/run-report.md` following `ORCHESTRATION.md`
 
@@ -39,9 +39,9 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 ## Negative examples (DO NOT do these)
 
 - Do not open multiple separate issues for individual token mismatches — group all simple token and contrast cleanup items into a single grouped punchlist issue for Autowork.
-- Do not file unapproved structural redesigns or feature removals as direct Autowork issues — stage them in the `🎨 Design Review — {date}` tracking issue for Product Planning to review.
+- Do not create separate standalone tracking issues that stay open indefinitely — stream design review audit findings, clutter analyses, and pruning recommendations directly into the open `🗺️ Product Plan` staging container.
 - Do not review the admin back-office (`src/app/[locale]/admin/**`) — it is deliberately utilitarian and exempt from the player-facing design system polish bar.
-- Do not blindly repeat the same surface review order every run — dynamically discover routes and check previous review issues to resume rotation and fast-track unreviewed new surfaces.
+- Do not blindly repeat the same surface review order every run — dynamically discover routes and check previous review logs to resume rotation and fast-track unreviewed new surfaces.
 
 ## Instructions
 
@@ -53,7 +53,7 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
    - Scan the filesystem for all active player-facing page routes: `src/app/[locale]/**/page.tsx` (ignoring any `admin/**` directories).
    - Normalize the discovered paths into canonical route identifiers (e.g. `Home` (`/`), `Predictions` (`/pronostics`), `Episode Predictions` (`/pronostics/episode/[id]`), `Groups` (`/groupes`), `Group Detail` (`/groupes/[id]`), `Presenter` (`/groupes/[id]/presentateur`), `Leaderboard` (`/classements`), `Profile` (`/profil`), `Account` (`/compte`), `Auth` (`/auth/*`), `Season Overview` (`/saisons/[slug]`), `Share` (`/partage`)).
 3. **Reconcile with Previous Rotation State**:
-   - Locate the most recent `🎨 Design Review` issue or run issue labeled `routine:design-review`.
+   - Locate the most recent run issue labeled `routine:design-review` or prior design review comment in the open staging container.
    - Read the `Surfaces Reviewed` and `Next Surfaces in Rotation` fields.
    - Any discovered route on disk that has never appeared in prior review logs is flagged as **`[NEW SURFACE]`** and placed at **Priority 0** (Fast-Track).
    - Remaining surfaces are sequenced based on `Next Surfaces in Rotation` (resuming rotation where the previous run stopped).
@@ -105,23 +105,58 @@ For the surfaces being audited:
 2. Formulate **Pruning Recommendations**:
    - Any persistent card, teaser, or secondary control with near-zero interaction, high rage-click density, or severe visual clutter is recommended for deprecation (`RECOMMENDATION: DEPRECATE`) or simplification (`RECOMMENDATION: PRUNE`).
 
-### Step 5: Hybrid Handoff & Issue Generation
+### Step 5: Hybrid Handoff & Staging Stream
 
 1. **Direct Autowork Punchlist Issue**:
    - If concrete, self-contained token violations, contrast bugs, or duplicate `.btn-primary` classes are found, compile them into a single grouped punchlist issue:
      - Title: `🎨 Design Polish & Token Cleanup — {YYYY-MM-DD}`
      - Labels: `design/polish`, `autowork-candidate`
      - Content: Structured task list with target files, line references, current violation, and suggested replacement token/class.
-2. **Overarching Design Review Tracking Issue**:
-   - Create or update a single tracking issue:
-     - Title: `🎨 Design Review — {YYYY-MM-DD}`
-     - Labels: `area/design`, `review`
-     - Content:
-       - **Surfaces Reviewed**: list audited routes, noting any `[NEW SURFACE]`
-       - **Next Surfaces in Rotation**: list unreviewed routes queued for the subsequent run
-       - **Visual Critique & Clutter Analysis**: mobile fold density, hierarchy, and layout observations
-       - **Pruning & Deprecation Candidates**: specific features/elements recommended to be pruned or consolidated
-       - **Experience Enhancement Opportunities**: structural UX improvements staged for Product Planning
+2. **Bridge to Product Planning (Continuous Staging Container Stream)**:
+   - Search for the active, OPEN product planning staging issue:
+     ```bash
+     gh issue list --state open --label "routine:product-planning" --limit 1
+     ```
+   - Stream and append the visual critique, clutter analysis, pruning recommendations, and experience enhancement opportunities directly as a comment into the open staging issue:
+     ```bash
+     gh issue comment "$STAGING_ISSUE_NUMBER" --body "### 🎨 Design Review Audit & Directives ($(date -u +%Y-%m-%d))
+     - **Directive**: \`DESIGN_DIRECTIVE: [PRUNE | REDESIGN | POLISH]\`
+     - **Surfaces Reviewed**: (list audited routes)
+     - **Next Surfaces in Rotation**: (list next queued routes)
+     - **Mobile Viewport Density & Nudge Budget**: Mobile fold observations (390px)
+     - **Visual Critique & Clutter Analysis**: Hierarchy, whitespace, and touch targets
+     - **Feature Pruning & Deprecation Recommendations**: Elements flagged for removal/simplification
+     - **Experience Enhancement Opportunities**: Structural UX improvements for roadmap
+     - **Autowork Punchlist**: #N (if token violations were found)
+
+     ---
+     [![Fleet](https://img.shields.io/badge/Fleet-Autonomous_Command-BBF65D?style=flat&logo=githubactions)](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})
+
+     _Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_"
+     ```
+   - **Self-Healing Fallback (Lazy Seed)**: If NO open staging issue exists (e.g. initial repository setup, or previous plan closed without seeding):
+     - Lazily initialize the upcoming product plan staging container rather than dropping design critique or commenting on closed issues:
+       ```bash
+       STAGING_TITLE="🗺️ Product Plan — $(date -u +%Y-%m-%d) (Staging)"
+       STAGING_BODY="## 🗺️ Upcoming Product Plan (Continuous Staging Container)
+
+       This staging container accumulates daily telemetry findings, feature audits, and measurement directives between planning sweeps.
+
+       ### Feature Pruning, Deprecation & Pivot Audit
+       - (Accumulating from daily analytics-review and design-review runs)
+
+       ### Accumulated Directives & Telemetry Stream
+       - Daily directives are streamed below as comments.
+
+       ---
+       [![Fleet](https://img.shields.io/badge/Fleet-Autonomous_Command-BBF65D?style=flat&logo=githubactions)](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})
+
+       _Initialized autonomously by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_"
+
+       STAGING_URL=$(gh issue create --title "$STAGING_TITLE" --body "$STAGING_BODY" --label "routine:product-planning,status:staging")
+       STAGING_ISSUE_NUMBER=$(echo "$STAGING_URL" | grep -oE '[0-9]+$')
+       ```
+     - Then append the design review audit comment to the newly created `$STAGING_ISSUE_NUMBER`.
 3. **Structured Directives**:
    - Output clear directives: `DESIGN_DIRECTIVE: [PRUNE | REDESIGN | POLISH]` to be consumed downstream by `product-planning.md`.
 
@@ -135,7 +170,7 @@ Follow the Routine Issue Logging Protocol in `ORCHESTRATION.md`:
    - Result: `SUCCESS` or `FAILURE`
    - Every Definition of Done criterion with YES/NO and evidence
    - Surfaces Reviewed and Next Surfaces in Rotation
-   - Created issues (`🎨 Design Polish & Token Cleanup`, `🎨 Design Review`)
+   - Created issues / streams (`🎨 Design Polish & Token Cleanup`, streamed to `🗺️ Product Plan`)
    - If FAILURE: root cause, category, and suggested fix
 3. The surrounding execution harness will reconcile the corresponding GitHub issue.
 

package/templates/prompts/product-planning.md

@@ -19,13 +19,15 @@ This routine runs behind a **human approval gate**: it **never files autowork-re
 This routine runs in two modes: **Propose** (scheduled cron sweep / unapproved fire) and **Promote** (operator-approved fire).
 
 In **Propose mode**, SUCCESS requires:
-- [ ] Read current roadmap, domain documentation, closed measurement trackers, recent feedback/analytics findings, and the latest open `🎨 Design Review` issue / recent design-review routine run issues
+- [ ] Located or initialized the active open staging issue (`routine:product-planning`, `status:staging`) and ingested all accumulated comment directives streamed by `analytics-review` and `design-review`
+- [ ] Read current roadmap, domain documentation, closed measurement trackers across the trailing cycle lookback window (`closed:>=$(date -u -d '16 days ago' +%Y-%m-%d)`), recent analytics reviews (`routine:analytics-review`), and the latest open `🎨 Design Review` issue / recent design-review routine run issues
 - [ ] Performed Feature Pruning & Deprecation Audit: evaluated shipped features, measurement outcomes (<2% user adoption or >50% failure rate), and Design Review pruning/clutter directives, drafting deprecation, removal, or simplification proposals
-- [ ] Created or updated exactly one dated staging issue (`🗺️ Product Plan — {date}`) containing:
-  - Up to 3 well-scoped proposals (Summary/Tasks/Why/Complexity), covering additions, pivots, or deprecations
+- [ ] Synthesized all accumulated directives into exactly one dated staging issue (`🗺️ Product Plan — {date}`) containing:
+  - All relevant well-scoped proposals (Summary/Tasks/Why/Complexity) warranted by evidence, covering additions, pivots, or deprecations (the operator owns deciding which proposals get promoted)
   - Backlog re-ranking recommendations
   - Formal `/to-spec` PRD drafts for any proposal above `size/M`
   - Proposed `ROADMAP.md` updates
+- [ ] Updated staging issue labels from `status:staging` to `needs-human` for operator review
 - [ ] Filed ZERO autowork-ready issues without approval
 
 In **Promote mode**, SUCCESS requires:
@@ -33,7 +35,8 @@ In **Promote mode**, SUCCESS requires:
 - [ ] Created real, labeled GitHub issues for approved proposals using `/to-tickets` for epic decomposition
 - [ ] Applied approved backlog re-rankings
 - [ ] Committed approved changes to `ROADMAP.md` if explicitly approved
-- [ ] Annotated the staging issue with created issue numbers (`✅ Created → #N`)
+- [ ] Annotated the staging issue with created issue numbers (`✅ Created → #N`) and closed it as completed
+- [ ] Seeded next staging issue: immediately created the NEXT upcoming staging container (`🗺️ Product Plan — {Next Date} (Staging)`) labeled `routine:product-planning,status:staging` so daily analytics runs have an active container to deposit findings
 
 If any criterion cannot be met, stop immediately and log FAILURE with the reason.
 
@@ -57,24 +60,63 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 - **Promote mode**: Payload contains approval tokens (e.g. `Approve #1, #2`, `Approve roadmap`). Proceed to Step 4 (Promote).
 - **Propose mode**: Scheduled sweep or no approval directives. Proceed to Steps 1–3 (Propose).
 
-### Steps 1–3: Propose Mode (Staging Proposals)
-
-1. Read `ROADMAP.md`, `AGENTS.md`, closed measurement trackers with `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`, the latest open `🎨 Design Review` issue (and recent run issues with `gh issue list --label "routine:design-review"`), and open issues.
+### Steps 1–3: Propose Mode (Synthesizing Staging Proposals)
+
+1. **Continuous Staging Container Intake & Lookback Query**:
+   - Locate the active open staging issue:
+     ```bash
+     gh issue list --state open --label "routine:product-planning" --limit 1
+     ```
+     If no open staging container exists (e.g. unseeded first run), create one: `🗺️ Product Plan — {YYYY-MM-DD} (Staging)` labeled `routine:product-planning,status:staging`.
+   - Ingest all accumulated comment directives from the staging issue (`gh issue view <issue> --comments`) to ingest daily telemetry directives streamed by `analytics-review` and visual critique / clutter / pruning directives streamed by `design-review`.
+   - Ingest all measurement trackers closed across the trailing 16-day cycle lookback window:
+     ```bash
+     gh issue list --state closed --label "measurement" --search "closed:>=$(date -u -d '16 days ago' +%Y-%m-%d)" --limit 30
+     gh issue list --state closed --label "routine:analytics-review" --search "created:>=$(date -u -d '16 days ago' +%Y-%m-%d)" --limit 20
+     ```
+   - Read `ROADMAP.md`, `AGENTS.md`, and any recent design-review run reports (`gh issue list --label "routine:design-review"`).
 2. **Feature Pruning & Deprecation Audit**:
    - Audit shipped features, closed measurement tracker verdicts, and `🎨 Design Review` clutter/pruning findings.
    - For any feature with <2% user adoption, sub-threshold CTR, >50% failure rate, or persistent UI clutter flagged by Design Review, draft explicit deprecation, removal, or pivot proposals to keep the codebase lean and eliminate maintenance waste.
-3. Draft up to 3 high-impact proposals (including additions, pivots, or deprecations) based on roadmap priorities, measurement outcomes, and user feedback.
+3. **Draft All Relevant Proposals**:
+   - Draft as many well-scoped proposals (including additions, pivots, or deprecations) as are relevant and justified by roadmap priorities, accumulated measurement outcomes, design review directives, and user feedback. Do not artificially cap proposals to 3 — stage all relevant, high-leverage initiatives so the maintainer has a complete view of candidate work.
+   - The operator owns deciding which proposals get approved and promoted into active work.
 4. For proposals sized `size/M` or above, draft a formal specification using `/to-spec`.
-5. Stage all proposals in a dedicated staging issue: `🗺️ Product Plan — {YYYY-MM-DD}` assigned to the repo maintainer.
+5. **Finalize Staging Issue for Human Review**:
+   - Update the staging issue title to `🗺️ Product Plan — {YYYY-MM-DD}` (drop `(Staging)` suffix if present).
+   - Populate the body with executive summary, feature pruning & deprecation audit, proposals, PRDs, backlog re-rankings, and proposed roadmap updates.
+   - Update labels: remove `status:staging` and add `needs-human`. Assign to the repo maintainer for review.
 
-### Step 4: Promote Mode (Approved Execution)
+### Step 4: Promote Mode (Approved Execution & Next Staging Container Seed)
 
 1. For each approved proposal in the staging issue:
    - Create a GitHub issue with the full specification and appropriate labels (`type/*`, `size/*`, `priority/*`).
    - If the proposal is an epic, decompose into child tickets using `/to-tickets`.
 2. Apply approved backlog re-rankings.
 3. If roadmap edits were approved, update `ROADMAP.md` directly on `main`.
-4. Update the staging issue checklist with references to created issues.
+4. Update the staging issue checklist with references to created issues and close the staging issue as completed.
+5. **Seed Next Staging Container**:
+   Immediately create the staging container issue for the next cycle (+15 days out, e.g. next 1st or 15th):
+   ```bash
+   NEXT_DATE=$(date -u -d '+15 days' +%Y-%m-%d)
+   TITLE="🗺️ Product Plan — ${NEXT_DATE} (Staging)"
+   BODY="## 🗺️ Upcoming Product Plan (Continuous Staging Container)
+
+   This staging container accumulates daily telemetry findings, feature audits, and measurement directives between planning sweeps.
+
+   ### Feature Pruning, Deprecation & Pivot Audit
+   - (Accumulating from daily analytics-review runs)
+
+   ### Accumulated Directives & Telemetry Stream
+   - Daily directives are streamed below as comments.
+
+   ---
+   [![Fleet](https://img.shields.io/badge/Fleet-Autonomous_Command-BBF65D?style=flat&logo=githubactions)](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})
+
+   _Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_"
+
+   gh issue create --title "$TITLE" --body "$BODY" --label "routine:product-planning,status:staging"
+   ```
 
 ## Logging
 
@@ -118,7 +160,7 @@ Appended strictly at the tail of the prompt to preserve prefix cache validity.
 The dynamic execution context for this planning sweep is injected strictly at the tail of the prompt:
 
 - **Planning Mode & Directives**: Mode indicator (`Propose` vs `Promote`) and operator approval tokens.
-- **Input Artifacts**: Closed measurement trackers with `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`, open `🎨 Design Review` issues, and maintainer feedback.
+- **Input Artifacts**: Closed measurement trackers with `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`, accumulated comments on active staging container, recent design-review run reports (`routine:design-review`), and maintainer feedback.
 - **Runtime Metadata**: `$ROUTINE_ISSUE_NUMBER`, `$GITHUB_RUN_ID`, and runner timestamp.
 - **Prefix Caching Invariant**: Harnesses and runners MUST NEVER interpolate dynamic timestamps, run IDs, or target identifiers into Tier 1 or Tier 2 prefix blocks.