jonah-fleet 1.28.2 → 1.28.3

package/CHANGELOG.md

@@ -5,18 +5,25 @@ 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.28.2](https://github.com/Jonah-Projects/jonah-fleet/compare/v1.28.1...v1.28.2) (2026-09-24)
+## [1.28.3](https://github.com/Jonah-Projects/jonah-fleet/compare/v1.28.2...v1.28.3) (2026-09-24)
 
 
 ### Bug Fixes
 
-* **guard:** exempt analytics-review from repetition and ping-pong loop circuit breakers ([#447](https://github.com/Jonah-Projects/jonah-fleet/issues/447)) ([#450](https://github.com/Jonah-Projects/jonah-fleet/issues/450)) ([839873c](https://github.com/Jonah-Projects/jonah-fleet/commit/839873c1c9e40b633a3e52a77aa74fc66374b8df))
+* **peer-review:** synthesize companion measurement issues upon merge ([#455](https://github.com/Jonah-Projects/jonah-fleet/issues/455)) ([6123c18](https://github.com/Jonah-Projects/jonah-fleet/commit/6123c18fb2d3bece994daa65cf8139f31b6fb154))
 
 ## [Unreleased]
 
 ### Bug Fixes
 
-* **guard:** exempt `analytics-review` routine from repetition and ping-pong loop circuit breaker false-positives while preserving consecutive error protection ([#447](https://github.com/Jonah-Projects/jonah-fleet/issues/447))
+* **peer-review:** add Post-Merge Companion Measurement Issue Filing protocol to `peer-review.md` and `ORCHESTRATION.md` to automatically synthesize `Measure: ...` tracking issues upon merge
+
+## [1.28.2](https://github.com/Jonah-Projects/jonah-fleet/compare/v1.28.1...v1.28.2) (2026-09-24)
+
+
+### Bug Fixes
+
+* **guard:** exempt analytics-review from repetition and ping-pong loop circuit breakers ([#447](https://github.com/Jonah-Projects/jonah-fleet/issues/447)) ([#450](https://github.com/Jonah-Projects/jonah-fleet/issues/450)) ([839873c](https://github.com/Jonah-Projects/jonah-fleet/commit/839873c1c9e40b633a3e52a77aa74fc66374b8df))
 
 ## [1.28.1](https://github.com/Jonah-Projects/jonah-fleet/compare/v1.28.0...v1.28.1) (2026-09-24)
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jonah-fleet",
-  "version": "1.28.2",
+  "version": "1.28.3",
   "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

@@ -264,6 +264,7 @@ How closed-loop feedback from product telemetry and measurement trackers drives
 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.
 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/peer-review.md

@@ -209,6 +209,29 @@ If the PR is clean and approved for merge, but lacks a `Closes #N` tracking link
 
 _Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID:-})_"
     ```
+  - **Post-Merge Companion Measurement Issue Filing**:
+    After closing the tracking issue, inspect the closed tracking issue body (or PR description if unlinked) for a `## Telemetry & Measurement Decisions` section:
+    - If a companion measurement issue is outlined (e.g. `Measure: <Feature Name>`) or if the feature introduced Tier 1 / Tier 2 telemetry contracts:
+      1. Check if an open tracker already exists:
+         ```bash
+         gh issue list --label "measurement" --search "Measure: <Feature Name> in:title" --state open
+         ```
+      2. If no open tracker exists, synthesize and file the companion measurement issue with the `measurement` label so `analytics-review` can track its adoption (using a quoted heredoc to avoid shell expansion and markdown backtick interpretation issues):
+         ```bash
+         gh issue create \
+           --title "Measure: <Feature Name>" \
+           --label "measurement" \
+           --body-file - <<'EOF'
+Companion measurement issue for PR #<PR_NUMBER> (closes #<ISSUE_NUMBER>).
+
+## Metric & Success Criteria
+<extract question answered, impression denominator, target metric, and key properties from spec/issue>
+
+[![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:-})_
+EOF
+         ```
   - Submit held review comments.
   - In any review summary, decision comment, or escalation comment posted to the PR, include the run log reference if `$ROUTINE_ISSUE_NUMBER` is set (e.g. `- **Run Log**: [#$ROUTINE_ISSUE_NUMBER](${GITHUB_SERVER_URL:-https://github.com}/${GITHUB_REPOSITORY}/issues/${ROUTINE_ISSUE_NUMBER})`).
   - File follow-up issues for material non-blocking findings.