jonah-fleet 1.30.0 → 1.30.1

package/CHANGELOG.md

@@ -5,6 +5,13 @@ 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.30.1](https://github.com/Jonah-Projects/jonah-fleet/compare/v1.30.0...v1.30.1) (2026-09-25)
+
+
+### Bug Fixes
+
+* **analytics-review:** forbid staging into or commenting on closed product plans ([e945366](https://github.com/Jonah-Projects/jonah-fleet/commit/e945366f8d645d54b3c3de2c9bf7d8c4aaa8cf5f))
+
 ## [1.30.0](https://github.com/Jonah-Projects/jonah-fleet/compare/v1.29.0...v1.30.0) (2026-09-25)
 
 
@@ -48,6 +55,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Bug Fixes
 
+* **analytics-review:** require active product planning staging issues to be strictly open (`--state open`), forbid commenting on or editing closed product plans from past planning sweeps, and make DoD staging conditional on having emitted directives
 * **runner:** introduce granular tool output evaluation descriptions, live subagent progress tracking, and non-TTY spinner deduplication to replace long-running generic `Evaluating tool output...` states
 * **autowork:** prevent local and GitHub-hosted autowork runner collisions by excluding bot and self-assignments from `trigger-autowork-on-assign.yml`, enforcing a 2-hour active claim lock in Step 0.5a / Step 11a, and mandating concrete pre-PR collision checks with collision bail in Step 13
 * **daemon:** query `statusCheckRollup` in `getOpenReviewablePRs` and filter out PRs with in-progress CI to prevent premature review dispatch and repetition loop trips

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jonah-fleet",
-  "version": "1.30.0",
+  "version": "1.30.1",
   "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,7 +261,7 @@ 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 the active `🗺️ Product Plan` or actionable `roadmap/*` issues.
+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.

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%
-- [ ] Staged the recommendation directly into the current/next `🗺️ Product Plan` staging issue or filed an actionable `roadmap/*` issue for `product-planning` to review
+- [ ] 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
 - [ ] 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.
@@ -37,6 +37,8 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 
 - Do not close a measurement tracker with a failed adoption verdict without emitting a mandatory `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]` directive.
 - Do not treat measurement closure as a terminal dead-end — always bridge outcomes to `product-planning`.
+- Do not comment on, edit, or stage directives into closed product plans (`state: closed`) from past planning sweeps. Once closed, product plans are completed historical records and must never receive new comments.
+- Do not search issues with `--state all` when querying for active product plans; active plans are strictly open issues (`--state open`).
 - Do not file bug tickets or request additional telemetry when users simply lack intent to interact with a feature.
 
 ## Instructions
@@ -96,8 +98,20 @@ When a measurement tracker is conclusive or reaches sub-threshold adoption (<2%
 
 ### Step 4: Bridge outcome to `product-planning`
 
-1. If an active staging issue `🗺️ Product Plan — {YYYY-MM-DD}` exists, stage the recommendation under `### Feature Pruning & Deprecation Audit` or `### Backlog Re-rankings`.
-2. If no staging issue exists, open an actionable `roadmap/*` issue labeled `needs-design` or `enhancement` detailing the measurement verdict and recommendation for the next product planning sweep.
+When conclusive measurement directives (`RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`) are emitted:
+1. Search for an **active, OPEN** product planning staging issue:
+   ```bash
+   gh issue list --state open --search "Product Plan"
+   ```
+   **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:
+   - 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`.
 
 ### Step 5: Close conclusive measurement trackers