jonah-fleet 1.2.0 → 1.4.1

package/schema.json

@@ -25,7 +25,8 @@
         "optimizer": { "type": "boolean" },
         "issues-housekeeping": { "type": "boolean" },
         "dependency-update-security-check": { "type": "boolean" },
-        "product-planning": { "type": "boolean" }
+        "product-planning": { "type": "boolean" },
+        "analytics-review": { "type": "boolean" }
       },
       "additionalProperties": false,
       "description": "Granular routine toggles"
@@ -35,6 +36,20 @@
       "items": { "type": "string" },
       "description": "List of core engineering skills to install/sync"
     },
+    "schedules": {
+      "type": "object",
+      "properties": {
+        "autowork": { "type": "string", "description": "Custom cron schedule for autowork (e.g. '0 * * * *')" },
+        "peer-review": { "type": "string", "description": "Custom cron schedule for peer-review watchdog" },
+        "optimizer": { "type": "string", "description": "Custom cron schedule for prompt optimizer" },
+        "issues-housekeeping": { "type": "string", "description": "Custom cron schedule for issues housekeeping" },
+        "dependency-update-security-check": { "type": "string", "description": "Custom cron schedule for dependency security checks" },
+        "analytics-review": { "type": "string", "description": "Custom cron schedule for analytics review" },
+        "sync-fleet": { "type": "string", "description": "Custom cron schedule for fleet sync" }
+      },
+      "additionalProperties": { "type": "string" },
+      "description": "Custom cron schedules per routine or workflow"
+    },
     "repositories": {
       "type": "array",
       "items": { "type": "string" },
@@ -47,6 +62,34 @@
         "channel": { "type": "string", "enum": ["stable", "latest"], "default": "stable" }
       },
       "additionalProperties": false
+    },
+    "telemetry": {
+      "type": "object",
+      "properties": {
+        "enabled": { "type": "boolean", "default": false },
+        "endpoint": { "type": "string", "description": "Optional telemetry collector webhook or API endpoint URL" },
+        "weeklyTokenBudget": { "type": "number", "default": 8750000, "description": "Global weekly token ceiling across fleet (~8.75M tokens/week)" }
+      },
+      "additionalProperties": false
+    },
+    "dualExecution": {
+      "type": "object",
+      "properties": {
+        "enabled": { "type": "boolean", "default": true, "description": "Enable priority-driven dual local/cloud execution" },
+        "cloudPriorities": {
+          "type": "array",
+          "items": { "type": "string" },
+          "default": ["P0", "P1"],
+          "description": "Priorities handled immediately by cloud GitHub Actions"
+        },
+        "cloudCatchupHours": {
+          "type": "number",
+          "default": 48,
+          "description": "Hours before lower-priority items are eligible for cloud catchup"
+        }
+      },
+      "additionalProperties": false,
+      "description": "Configuration for priority-driven dual local/cloud agent execution"
     }
   },
   "required": ["version", "preset", "routines", "skills"],

package/templates/docs/AGENTS.template.md

@@ -47,6 +47,21 @@ tests/            # Test suites
 - **Changelog**: Append user-facing changes to `CHANGELOG.md` under today's date section.
 - **Antigravity Run Footer**: Every GitHub comment, issue edit, and PR description posted by automated Actions must end with `_Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_`.
 
+## Autonomous Agent Dispatch (Targeted Autowork)
+
+To trigger the Autowork routine manually on any specific issue, use the GitHub Actions `workflow_dispatch` trigger or embed this badge link in issue templates/descriptions:
+
+```markdown
+[![Trigger Autowork](https://img.shields.io/badge/Autowork-Run_Targeted-blue?style=for-the-badge&logo=githubactions)](https://github.com/OWNER/REPO/actions/workflows/trigger-autowork-manual.yml)
+```
+
+## Design System & UI Guardrails
+
+- **Design Token Purity**: Use standard design system tokens and scale classes. Avoid arbitrary values (e.g. `text-[...px]`, `w-[...px]`) and bespoke inline overrides.
+- **Accessibility & Contrast**: Enforce WCAG AA 4.5:1 minimum text contrast across light and dark themes (e.g. avoid unreadable low-contrast text on dark backgrounds).
+- **CTA & Visual Hierarchy**: Maintain at most one primary forward action button (`.btn-primary`) per view/tab to prevent choice paralysis.
+- **Viewport Density & Nudge Budget**: Ensure banners, nudges, and sticky elements do not stack concurrently or crowd mobile viewports (~390px above the fold).
+
 ## Security Guidelines
 
 - Auth boundaries required for all sensitive mutations.

package/templates/prompts/ORCHESTRATION.md

@@ -17,12 +17,13 @@ This project's automation is a GitHub-native implementation of the orchestration
 
 Dispatch is both **scheduled** and **event-driven**. All routines run as ephemeral agent sessions via **Antigravity CLI (`agy`)** powered by **Gemini 3.7 Flash (High reasoning)**. The routine suite is calibrated to operate within a **strict 70% weekly token ceiling across all routines combined**, supervised by `optimizer.md`:
 - **Scheduled cron sweeps**: Autowork runs periodically (`autowork-cron.yml`), complemented by prompt optimization (`prompt-optimizer-cron.yml`), issues housekeeping (`issues-housekeeping-cron.yml`), and dependency security checks (`dependency-check-cron.yml`).
-- **Event-driven triggers**: GitHub Actions workflows fire routines on events so work starts within seconds instead of waiting for scheduled ticks:
-  - `trigger-review-routine.yml` fires Peer Review when a PR is marked ready for review (with debounce on rapid pushes).
+- **Event-driven & manual triggers**: GitHub Actions workflows fire routines on events and interactive commands so work starts within seconds instead of waiting for scheduled ticks:
+  - `trigger-review-routine.yml` fires Peer Review automatically when a PR is marked ready for review, updated, or review is requested (`ready_for_review`, `opened`, `reopened`, `synchronize`, `review_requested`). It can also be manually (re)triggered via `workflow_dispatch` (with optional `pr_number` for Targeted mode or blank for Scan mode) or by commenting `/review`, `/peer-review`, `/retrigger`, or `/re-review` on any open pull request.
   - `trigger-autowork-on-merge.yml` fires Autowork in **Targeted mode** when a PR merges to `main` and unblocks the next unit of chained work.
   - `trigger-autowork-on-bug.yml` fires Autowork when an issue becomes a high-priority bug.
+  - `trigger-autowork-manual.yml` fires Autowork manually via `workflow_dispatch` or badge link click on a specific issue in **Targeted mode**.
 
-Both autowork triggers pass the target issue via environment variables (`ISSUE_NUMBER`, `ISSUE_URL`), putting autowork.md into **Targeted mode** (working the named issue ahead of Phase 1 convergence). Single-flight per issue is strictly enforced across both scheduled and event-driven runs.
+Autowork triggers pass the target issue via environment variables (`TARGET_ISSUE`, `ISSUE_NUMBER`, `ISSUE_URL`), putting autowork.md into **Targeted mode** (working the named issue ahead of Phase 1 convergence). Single-flight per issue is strictly enforced across scheduled, event-driven, and manually triggered runs.
 
 Invariants deliberately upheld from this spec:
 
@@ -63,6 +64,7 @@ Single source of truth for both autowork candidate reclamation and housekeeping
 | Issues Housekeeping | `.github/prompts/issues-housekeeping.md` | Sweeping open issues for staleness, duplicates, label drift, priority accuracy, and orphaned claims |
 | Dependency Update & Security Check | `.github/prompts/dependency-update-security-check.md` | Checking dependencies for updates and known vulnerabilities, opening actionable PRs |
 | Product Planning | `.github/prompts/product-planning.md` | Turning roadmap priorities into staged issues (`/to-tickets`) and formal PRDs (`/to-spec`) |
+| Analytics Review | `.github/prompts/analytics-review.md` | Evaluating telemetry & measurement trackers against success metrics, emitting action directives (PIVOT/DEPRECATE/ITERATE), and bridging to product planning |
 
 ---
 
@@ -109,6 +111,7 @@ How token spend, runaway loops, and budget anomalies are detected, triaged, and
    - **Budget Hog**: A single agent routine consumes >75% of total fleet token allowance. Trigger: unbalanced dispatch frequency or unbounded candidate sweeps. Remediation: throttle cron frequency, introduce stricter candidate batching, or add early exit conditions.
    - **Iteration Ceiling Exhaustion**: >20% of runs in a routine terminate at the `token_limit` / max iteration cap. Trigger: tasks too complex for single-flight execution or unbounded looping. Remediation: enforce vertical slicing / umbrella decomposition, tighten pre-ready self-audits, or refine termination bounds.
    - **Review Loop Burn**: Pull requests experiencing $\ge 3$ bounce rounds between autowork and peer-review. Trigger: ambiguous reviewer feedback, pedantic non-blocking findings, or brittle test assertions. Remediation: tighten reviewer trust/noise rules, calibrate reviewer severity thresholds, and engage human escalation via ping-pong caps.
+   - **Feedback Loop Stagnation**: A downstream processing routine (e.g. measurement loop, verification, triage) records 0 intake (`filed: 0`) across $\ge 2$ consecutive runs while upstream PRs merge or roadmap/feature issues close in the same window. Trigger: overly broad or qualitative discovery sweeps that falsely claim all items are covered. Remediation: mandate deterministic per-issue matching tables and itemized reconciliation against upstream closed issues/PRs.
 3. **Automated Remediation PRs**: The optimizer automatically drafts targeted PRs—locally for repo-specific rules/configs, or upstream via `npx jonah-fleet contribute` for fleet-wide prompt/workflow improvements.
 
 ---
@@ -123,4 +126,72 @@ How external and human contributor pull requests are reconciled into the issue t
    - Appends `Closes #<synthesized_issue_id>` to the PR description via `gh pr edit`.
 3. **Audit & Single-Flight Lineage**: When the PR is squash-merged, GitHub's native issue closure kicks in and automatically closes the synthesized issue. This maintains 100% issue auditability, project board tracking, telemetry metrics, and release changelogs without imposing any friction on human contributors.
 
+---
+
+## Fleet Telemetry & Weekly Token Economics
+
+Cross-repository telemetry aggregation and token tracking protocol:
+1. **Lightweight Routine Telemetry**: Every autonomous routine log (`.github/prompts/logs/*/*.md`) emits a structured `RoutineTelemetrySummary` capturing routine identity, duration, iterations, result, failure category, cost, and tokens.
+2. **Opt-in Emission Step**: GitHub Actions workflows (`autowork-cron.yml`, `trigger-review-routine.yml`, `prompt-optimizer-cron.yml`) run `jonah-fleet telemetry --emit` using optional `JONAH_FLEET_TELEMETRY_ENDPOINT` secrets.
+3. **Global 70% Budget Ceiling**: Tracks rolling 7-day spend across all fleet repositories against the global ceiling (~8.75M tokens/week).
+4. **Health Thresholds**:
+   - `[HEALTHY]`: < 70% of weekly budget ceiling.
+   - `[WARNING]`: 70% – 90% of weekly budget ceiling.
+   - `[CRITICAL]`: 90% – 100% of weekly budget ceiling.
+   - `[EXCEEDED]`: > 100% of weekly budget ceiling.
+
+---
+
+## Peer Review Resilience & Orphaned PR Recovery
+
+How the fleet guarantees continuous review throughput, recovers from transient API quota exhaustion or runner crashes, and prevents pull requests from stalling indefinitely:
+
+1. **Failure Trapping & Transparency**: When a peer-review workflow session encounters an execution failure (e.g. LLM API rate limit / quota exhaustion or runner timeout), `trigger-review-routine.yml` traps the failure and posts an informational status notice on the PR. Failures are made immediately visible on the PR timeline rather than silently failing in the background.
+2. **Periodic Scan Sweep (Watchdog)**: `trigger-review-routine.yml` runs a scheduled 2-hour cron sweep (`cron: '45 */2 * * *'`) in Scan mode. Any open PR in `ready_for_review` state that was orphaned due to a transient API rate limit or missed event trigger is automatically picked up, evaluated, and resolved.
+3. **Interactive Re-triggering**: Any team member or author can immediately re-dispatch review by commenting `/review`, `/peer-review`, `/retrigger`, or `/re-review` on any open pull request, or manually triggering `trigger-review-routine.yml` via `workflow_dispatch`.
+4. **Autowork Phase 1 Watchdog**: During Phase 1 convergence, Autowork actively identifies open ready PRs that have received no review feedback for $>2$ hours, re-triggering review via draft toggle or `/review` comment before picking up new work.
+
+---
+
+## Upstream Symphony Intel & Architectural Evaluation Framework
+
+How changes and innovations from [openai/symphony](https://github.com/openai/symphony) are systematically audited and evaluated for incorporation into Jonah Fleet:
+
+1. **Automated Radar (`symphony-radar.yml`)**: A weekly scheduled workflow runs `.github/scripts/fetch-symphony-radar.js` to inspect upstream commits, specification updates (`SPEC.md`), and releases, generating an actionable digest issue in Jonah Fleet.
+2. **The 4 Evaluation Layers**:
+   - **Layer 1 (Zero-Daemon Invariant)**: Can the enhancement execute in ephemeral GitHub Actions and `agy` CLI sessions without requiring a 24/7 background server or persistent WebSocket?
+   - **Layer 2 (Issue Tracker Abstraction)**: Does the pattern map cleanly to native GitHub Issues, labels, and PR checks without proprietary tracker dependencies?
+   - **Layer 3 (Token & Cost Economy)**: Does the change optimize LLM spend within Jonah Fleet's 70% weekly token ceiling (~8.75M tokens)?
+   - **Layer 4 (Multi-Repo Portability)**: Can the routine or skill be distributed via `agents-manifest.json` and `jonah-fleet sync` across any consumer repository?
+3. **Classification & Action Protocol**:
+   - **🟢 Category A (Adopt Directly)**: Security guardrails, claim lock invariants, reader/writer rules, prompt engineering optimizations.
+   - **🟡 Category B (Adapt to Actions/CLI)**: Dynamic orchestrator pacing, backpressure controls, multi-stage review checks.
+   - **🔴 Category C (Skip)**: Elixir/OTP supervision trees, BEAM memory tuning, proprietary runtime internals.
+
+---
+
+## Post-Measurement Product Bridge & Intent vs. Defect Guardrail
+
+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.
+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).
+
+---
+
+## Priority-Driven Dual Agent Execution (GitHub Actions + Local Agents)
+
+How agent routines are partitioned between cloud GitHub Actions (24/7 cloud runners for fast time-to-resolution) and local machine agents (`jonah-fleet run` / `jonah-fleet daemon` for zero cloud quota consumption):
+
+1. **Priority Routing Rules**:
+   - **`priority/P0` & `priority/P1` & Bugs**: Processed immediately by cloud GitHub Actions upon event trigger (`issues`, `pull_request`, `schedule`).
+   - **`priority/P2` & `priority/P3` (Lower Priority)**: Handled primarily by local machine agents in isolated Git worktrees. Cloud Actions skips immediate event triggers on P2/P3 items to conserve Actions quota.
+   - **Cloud Catchup Sweep (48h Fallback)**: If a P2/P3 issue or PR remains unclaimed/unreviewed for $>48\text{ hours}$ (e.g. because local machines were offline), the scheduled cloud Actions scan sweep automatically picks it up to prevent work starvation.
+2. **PR Priority Mirroring**: When Autowork opens a PR, it automatically mirrors the parent issue's priority labels (`priority/P0`..`P3`) onto the pull request so downstream review workflows can filter triggers without extra API overhead.
+3. **Workspace Isolation via Git Worktrees**: Local agents execute inside ephemeral worktrees (`.jonah-fleet/worktrees/<routine>-<issue>`) off `origin/main`, ensuring active editor sessions, uncommitted changes, and local branches are never modified or disturbed.
+4. **Local Claim Protocol**:
+   - Local agent claims post: `🔒 Claimed by local autowork session (host: <hostname>) <timestamp>`.
+   - Local processes trap `SIGINT`/`SIGTERM` to unassign claims and remove worktrees cleanly on exit.
+   - Standard 6-hour stale-claim rule safely reclaims orphaned local claims if a machine powers down unexpectedly.
 

package/templates/prompts/analytics-review.md

@@ -0,0 +1,91 @@
+# Analytics Review
+
+## Objective
+
+Evaluate active and scheduled measurement trackers against live product telemetry, user adoption metrics, conversion rates, and retention signals. Synthesize analytics observations into conclusive verdicts and mandatory downstream product action directives (`RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`), bridging measurement directly into product planning rather than treating measurement closure as a terminal dead-end.
+
+## Definition of Done
+
+The run is SUCCESS only if ALL of these are true:
+
+- [ ] Scanned all open measurement tracking issues (`measurement/*`, `telemetry/*`, or CTA/feature adoption trackers)
+- [ ] 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
+- [ ] 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.
+
+## Constraints
+
+- **Max iterations**: 30 — after 30 tool call rounds without completing Definition of Done, STOP. Log FAILURE with category `token_limit`.
+- **Max scope**: measurement evaluation and product recommendation staging only. Do not implement feature code or open feature PRs.
+- **No telemetry rabbit holes**: if data reveals low adoption or low user intent, do not spend cycles adding further downstream telemetry or error-handling fallbacks; mandate a product recommendation (`PIVOT` or `DEPRECATE`).
+- **Language Requirement**: All GitHub issue titles, descriptions, task checklists, and comments MUST be written in **English**.
+- **Session link footer**: sign every GitHub post with the Antigravity run footer (`_Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_`).
+
+## Negative examples (DO NOT do these)
+
+- 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 file bug tickets or request additional telemetry when users simply lack intent to interact with a feature.
+
+## Instructions
+
+### Step 1: Scan open measurement issues and telemetry datasets
+
+1. List all open issues tagged `measurement/*`, `telemetry/*`, or tracking feature adoption experiments.
+2. Read the baseline metric targets, hypothesis, and evaluation criteria defined in each tracker.
+3. Fetch or query relevant telemetry events, conversion funnels, and failure rates from logs or telemetry endpoints.
+
+### Step 2: Evaluate adoption and intent metrics
+
+1. Compare observed metrics against hypothesis targets:
+   - Click-Through Rate (CTR) & Conversion Rate
+   - Feature adoption percentage across active sessions
+   - Failure / error rates during user interaction
+2. Identify whether low conversion stems from technical defects or lack of user intent:
+   - If feature renders correctly without runtime errors but adoption is <2%, classify as **low user intent**.
+
+### Step 2.5: UI Friction & Nudge Fatigue Guardrail
+
+1. **Component-Level Rage Clicks**:
+   - Group `$rageclick` events by URL and element selector/text to pinpoint unclickable, misleading, or confusing UI components causing user friction.
+   - For UI elements generating recurring rage clicks, file or stage an actionable UX bug/redesign recommendation for `product-planning`.
+2. **Nudge & Banner Fatigue Rule**:
+   - Audit persistent promotional banners, cards, and nudges across active screens.
+   - Alert (P2) and mandate `RECOMMENDATION: DEPRECATE` or `RECOMMENDATION: PIVOT` if any persistent promotional banner/card exceeds 500 impressions in a 14-day window with an impression-to-action CTR < 2.0%, flagging it for consolidation, throttling, or clean removal to prevent visual crowding.
+
+### Step 3: Emit mandatory Post-Measurement Action Directive
+
+When a measurement tracker is conclusive or reaches sub-threshold adoption (<2% adoption or >50% failure rate):
+1. Formulate a mandatory structured directive:
+   - `RECOMMENDATION: PIVOT` — Feature has partial interest or flawed UX; recommend redesign or alternate positioning.
+   - `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`
+
+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.
+
+### Step 5: Close conclusive measurement trackers
+
+1. Post a comprehensive findings summary to the measurement issue including:
+   - Metric summary table (Target vs. Actual)
+   - Root cause assessment (Intent vs. Defect)
+   - Mandatory `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]` directive
+   - Reference to the staged product planning item (`Staged to #M`)
+   - Antigravity run footer
+2. Close the issue as completed.
+
+## Logging
+
+After completing (SUCCESS or FAILURE), write a log file to `.github/prompts/logs/analytics-review/{timestamp}.md` following the schema in `.github/prompts/logs/_template.md`. Include:
+- The prompt SHA (run `git rev-parse --short HEAD:.github/prompts/analytics-review.md`)
+- Every Definition of Done criterion with YES/NO and evidence
+- Full execution trace with evaluated trackers and emitted recommendations
+- If FAILURE: root cause, category, and suggested fix
+
+**Important**: Commit the log file directly to `main` and push — explicitly permitted for files under `.github/prompts/logs/**`. Follow the Log delivery fallback in `ORCHESTRATION.md` if direct push fails.

package/templates/prompts/autowork.md

@@ -42,6 +42,7 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 - Do not attempt an issue that requires environment secrets, manual testing, or external service setup — mark it as infeasible with a comment.
 - Do not start implementing an issue before claiming it (both assignment AND claim comment).
 - Do not mark a PR ready while its `mergeable_state` is `dirty` — resolve merge conflicts first.
+- Do not fall into the **Telemetry Rabbit Hole**: do not spend cycles instrumenting elaborate fallback telemetry or defensive error handling for features that suffer from lack of user intent rather than software bugs.
 
 ## Instructions
 
@@ -57,7 +58,7 @@ Check if `$ISSUE_NUMBER` environment variable is set (or scan invocation text fo
 
 ### Step 0.5: Targeted mode — work the target issue first (only when Step 0 found one)
 
-a. **Read the target issue and check eligibility.** Eligible = open, unassigned or reclaimable stale claim, no open PR (`Closes #N`), and not carrying `needs-human` or `needs-design`.
+a. **Read the target issue and check eligibility.** Eligible = open, unassigned or reclaimable stale claim, no open PR (`Closes #N`), no unclosed inward blocking dependencies (`Blocked by #N` or `Depends on #N` where `#N` is open), and not carrying `needs-human` or `needs-design`.
    - **Ineligible** → fall back to Phase 1 and run the normal Scan flow.
 b. **Eligible → claim, then implement.** Call `get_me` once to learn your own login (step 7), reclaim stale claim if applicable (step 10a), run Claim protocol (step 11), evaluate and implement per steps 12–13, open draft PR, and run in-session review wait (step 15).
 
@@ -69,11 +70,13 @@ b. **Eligible → claim, then implement.** Call `get_me` once to learn your own
 3a. **Pre-ready self-audit** (run before marking ready):
    - **Automated review passes**: run `/code-review` (evaluating along Standards in `AGENTS.md` and Spec in the issue's `## Tasks`) and security review over the diff. Fix what they flag.
    - **Repository conventions scan**: read and verify all rules and conventions specified in `AGENTS.md` (or `CLAUDE.md`/`GEMINI.md`), project-level skills in `.agents/skills/`, and project documentation.
+   - **Design System & Viewport Pre-flight** (for frontend/UI diffs): self-audit diffs against design tokens (no arbitrary class overrides), WCAG AA 4.5:1 contrast ratios on dark/light surfaces, single primary CTA hierarchy per screen, and mobile viewport crowding (avoid stacked nudges/banners above the fold at ~390px).
    - **Documentation accuracy**: update relevant docs (`ARCHITECTURE.md`, `CODEMAP.md`, `API.md`, `CHANGELOG.md` if maintained by repo).
    - **Build & type-check verification**: run the repository's test, type-check, and lint commands from `AGENTS.md` (e.g. `npm test`, `npm run type-check`, `npm run lint`, `pytest`, `cargo test`). Confirm zero errors and zero test failures.
    - **Clean-merge gate**: verify `git merge-tree origin/main HEAD` reports no conflicts.
    Only mark the PR ready after passing every check above.
 3b. **Ping-pong cap**: If this same PR has bounced between draft and ready 3 or more times over the same substantive finding, stop re-marking it ready. Post a comment summarizing the disagreement for human resolution and leave the PR in draft.
+3c. **Orphaned Ready PR Recovery**: If an open PR authored by this routine is `ready_for_review`, has passing CI, no unaddressed review comments, and has received no review activity for over 2 hours (e.g. because peer review crashed or encountered quota limits), kickstart the review routine by posting `/review` comment or toggling draft and ready (`gh pr ready <PR> --undo && gh pr ready <PR>`).
 4. Check open issues that have linked merged PRs — close them.
 5. If any PR was updated in this phase, STOP — run is SUCCESS.
 
@@ -81,19 +84,26 @@ b. **Eligible → claim, then implement.** Call `get_me` once to learn your own
 
 6. Count open PRs authored by automated sessions representing live reviewable work (excluding log-only PRs). If 3 or more non-log PRs are open, STOP — run is SUCCESS with "Too many open PRs, converging first".
 7. Call `get_me` once to learn your own GitHub account (`login`).
-8. List open issues sorted by priority labels (P1 > P2 > P3). Within the same priority tier, order by type (`bug`/`security` before others), then oldest first. Skip assigned issues (unless stale claim per `ORCHESTRATION.md`), issues with open PRs, issues labeled `needs-human` or `needs-design`, and issues under cross-run cooldown.
+8. List open issues sorted by priority labels (P1 > P2 > P3). Within the same priority tier, order by type (`bug`/`security` before others), then oldest first.
+   - **Dual Execution Priority Routing**:
+     - If running in **Cloud Actions** (`$GITHUB_ACTIONS` / `$CI`): Scan mode selects `priority/P0` or `priority/P1` issues first. Lower-priority `priority/P2` or `priority/P3` issues are eligible in cloud Scan mode ONLY if the issue has remained unclaimed for more than 48 hours (`created_at` older than 48h, acting as a cloud catchup sweep).
+     - If running in **Local Agent** (`$LOCAL_AGENT`): Scan mode selects across all priorities (P0 → P1 → P2 → P3) without time gating, prioritizing active local backlog consumption.
+   - Skip assigned issues (unless stale claim per `ORCHESTRATION.md`), issues with open PRs, issues with unclosed blocking dependencies (`Blocked by #N` / `Depends on #N`), issues labeled `needs-human` or `needs-design`, and issues under cross-run cooldown.
 9. If no eligible candidate exists, STOP — run is SUCCESS with "No unclaimed work available".
 10. If the candidate should be closed already (work done, PRs merged), close it and return to step 8.
 10a. **Stale-claim reclamation:** If candidate is a stale claim per `ORCHESTRATION.md`, re-read immediately before writing, unassign the dead owner, post reclamation comment, and proceed to claim.
 11. **Claim protocol:**
     a. Re-read candidate issue immediately before claiming (`issue_read`). If assigned, abort and pick next candidate.
-    b. Claim atomically: assign yourself (`login` from step 7) AND post claim comment `🔒 Claimed by autowork run {timestamp}`.
-    c. Confirm sole ownership by counting `🔒 Claimed by autowork run` comments. Earliest `created_at` wins. If you lost the race, leave assignee as is, annotate your comment, and pick next candidate.
+    b. Claim atomically: assign yourself (`login` from step 7) AND post claim comment:
+       - In **Cloud Actions**: `🔒 Claimed by autowork run {run_url} {timestamp}`
+       - In **Local Agent**: `🔒 Claimed by local autowork session (host: {hostname}) {timestamp}`
+    c. Confirm sole ownership by counting `🔒 Claimed by autowork run` / `🔒 Claimed by local autowork session` comments. Earliest `created_at` wins. If you lost the race, leave assignee as is, annotate your comment, and pick next candidate.
 12. Evaluate whether the claimed issue can be completed autonomously:
     - Confirm your `🔒` claim comment is present on the issue.
     - Read the issue description, linked code, and comment thread.
     - If bug: use `/diagnosing-bugs` to establish reproduction test before fixing.
     - If large/complex: use `/domain-modeling` and `/codebase-design`.
+    - **Intent vs. Defect Guardrail**: When investigating issues related to low conversion, zero-click events, or underperforming features: verify whether the issue is a software defect or a lack of user intent. If data indicates the root cause is **lack of user intent** (e.g. button is rendered above fold and functions correctly when clicked, but user interaction rate is <2%) rather than a software defect, do NOT fall into the **telemetry rabbit hole** (adding elaborate fallback telemetry, downstream error handling, or defensive rendering). Categorize the issue as a **product/UX question** (`needs-design` / `roadmap/*`), comment explaining the lack of user intent, release the claim (unassign), and select the next candidate.
     - If infeasible: comment explaining blocker, release claim (unassign), and select next candidate (up to 3 infeasible evaluations per run). If permanent blocker on 2nd strike, apply `needs-human` label and tag repo owner.
 12a. **Umbrella-issue handoff + batching:** If candidate is an umbrella epic:
     - Read `🧭 Decomposition plan` comment (or create if first run).
@@ -105,6 +115,7 @@ b. **Eligible → claim, then implement.** Call `get_me` once to learn your own
     - Run repository tests and verification.
     - Check for competing open PRs immediately before creating PR. If collision, bail cleanly.
     - Open draft PR via `gh pr create --draft --head <branch> --base main --title "<title>" --body "<body referencing Closes #N>"`.
+    - **PR Priority Label Mirroring**: If the issue carried a priority label (`priority/P0`, `priority/P1`, `priority/P2`, `priority/P3`), add the identical priority label to the PR (`gh pr edit <PR> --add-label "<label>"` or via `--label` in create) so downstream review workflows can filter triggers immediately.
     - Verify PR URL returned. Update issue `## Tasks` checkboxes.
     - Mark PR ready (`gh pr ready <PR>`).
 14. If run aborts before opening PR, release claim (unassign).

package/templates/prompts/issues-housekeeping.md

@@ -40,10 +40,11 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 4. **Duplicate & consolidation check**: Identify duplicate issues; close duplicates with cross-references. Consolidate small, related micro-tasks into batch issues.
 5. **Premise-obsolete & stale check**: If an issue's premise was resolved by already-merged PRs or recent refactors, close as completed with evidence.
 6. **Label audit**: Ensure open issues carry standard role labels (`needs-triage`, `ready-for-agent`, `needs-human`, etc.). Use `/triage` if classifying incoming issues.
+7. **Closed-loop verification check**: For projects running impact or verification loops, audit recently closed roadmap/feature issues against tracking issues to ensure shipped levers do not remain untracked.
 
 ### Phase 3: Summary
 
-7. Post a summary comment or log recording all actions taken (priority shifts, closed duplicates, released claims, landed log PRs).
+8. Post a summary comment or log recording all actions taken (priority shifts, closed duplicates, released claims, landed log PRs).
 
 ## Logging
 

package/templates/prompts/optimizer.md

@@ -58,6 +58,7 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
    - **Budget Hog**: A single agent routine consumes >75% of total fleet token allowance.
    - **Iteration Ceiling Exhaustion**: >20% of runs in a routine terminate at the `token_limit` / max iteration cap.
    - **Review Loop Burn**: Pull requests experiencing >= 3 bounce rounds between autowork and peer-review over unresolved or recurring findings.
+   - **Feedback Loop Stagnation**: A downstream processing routine (e.g. impact measurement, verification, or triage) records 0 intake (`filed: 0` or 0 new items processed) across $\ge 2$ consecutive runs while upstream PRs merge or roadmap/feature issues close in the same window. Flags that discovery sweeps have stalled or become overly coarse.
 6. **Analyze resolved bugs & review comments**: Examine closed bug issues, merged bug-fix PRs, and review feedback for missing checks in authoring (`autowork.md`) or review (`peer-review.md`).
 
 ### 2. Formulate preventative improvements
@@ -67,6 +68,7 @@ Translate findings into concrete preventative improvements and remediation trigg
 - **Early Exit & Candidate Skip**: For Budget Hog and runaway sweeps, add early termination guards, candidate pre-qualification filters, and infeasible evaluation caps.
 - **Iteration Ceiling & Self-Audit Tuning**: For Iteration Ceiling Exhaustion, adjust max iteration bounds or tighten pre-ready self-audits in `autowork.md` to catch defects before review cycles start.
 - **Ping-Pong Convergence**: For Review Loop Burn, tighten reviewer trust & noise filtering, enforce clean-merge gates, and apply ping-pong caps to prevent endless bounce cycles.
+- **Loop Discovery Mechanical Audits**: For Feedback Loop Stagnation, tighten discovery sweeps by mandating deterministic per-issue matching tables and itemized reconciliation against upstream closed issues/PRs rather than allowing un-itemized generic summary assertions.
 - **Verification & Invariant Tests**: Add automated test cases in `tests/` verifying prompt invariant preservation and schema conformity.
 
 ### 3. Open Fix PR (Local or Upstream Bridge)

package/templates/prompts/peer-review.md

@@ -50,6 +50,7 @@ Every review ends in exactly one of two states:
 
 - Do not review or list any other PR when `$PR_NUMBER` is set.
 - Do not continue reviewing a PR after discovering it is already merged or closed.
+- Do not review automated release PRs (`release-please--*` / `chore(main): release*`).
 - Do not merge a PR with failing or absent CI checks.
 - Do not leave a PR in limbo — always merge or convert back to draft.
 - Do not attempt `REQUEST_CHANGES` or `APPROVE` on own PRs (GitHub rejects same-account review states). Always use `COMMENT` + draft toggle.
@@ -67,10 +68,13 @@ Check if `$PR_NUMBER` is set:
 
 ### Steps 1–2: Select a PR (Scan mode only)
 
-1. List all open PRs, excluding drafts and pure log PRs (`.github/prompts/logs/**`).
-2. Prioritize:
+1. List all open PRs, excluding drafts, pure log PRs (`.github/prompts/logs/**`), and automated release PRs (`release-please--*` / `chore(main): release*`).
+2. **Dual Execution Priority Routing**:
+   - If running in **Cloud Actions** (`$GITHUB_ACTIONS` / `$CI`): Scan mode prioritizes PRs labeled `priority/P0` or `priority/P1` (or untagged PRs). Lower-priority PRs (`priority/P2`, `priority/P3`) are eligible for cloud review ONLY if they have remained ready and unreviewed for more than 48 hours (`created_at` older than 48h, acting as a cloud catchup sweep).
+   - If running in **Local Agent** (`$LOCAL_AGENT`): Scan mode reviews any ready PR across all priorities (P0 → P1 → P2 → P3) with no age gating.
+3. Prioritize:
    - **Category A (re-review)**: PRs with prior review comments where author has pushed new fix commits.
-   - **Category B (first review)**: Brand new PRs ready for review.
+   - **Category B (first review / unreviewed)**: Brand new PRs ready for review, or ready PRs whose previous review session failed or timed out.
 
 ### Step 3: Round tracking & Starting Review marker
 
@@ -83,8 +87,13 @@ Check if `$PR_NUMBER` is set:
    - **Standards**: Conformance to `AGENTS.md` (or `CLAUDE.md`/`GEMINI.md`), conventions, and architecture.
    - **Spec Compliance**: Verification against the linked issue's deliverables (`## Tasks`), or against the PR description's summary/changes if no tracking issue is linked.
 2. Run Security Pass: auth gates, permission checks, injection risks, sensitive credentials.
-3. If PR modifies rendered UI, verify screenshots or visual components if tooling/scripts are available.
-4. Run repository verification commands (tests, type-check) if CI status is unconfirmed.
+3. **Design System & Viewport Density Pass** (if PR modifies frontend/rendered UI):
+   - **Token Purity**: Check for arbitrary CSS/Tailwind sizing overrides (e.g. `text-[...px]`, `w-[...px]`) or bespoke button styling bypassing standard design system tokens.
+   - **WCAG AA Contrast**: Enforce minimum 4.5:1 contrast on readable text (e.g. `text-gray-400` minimum on dark surfaces; avoid muted unreadable text).
+   - **CTA Hierarchy**: Verify at most one primary forward CTA (`.btn-primary`) per active screen/tab.
+   - **Mobile Viewport Budget**: Verify that new banners, nudges, or sticky elements do not stack concurrently above the fold on mobile viewports (~390px).
+4. If PR modifies rendered UI, verify screenshots or visual components if tooling/scripts are available.
+5. Run repository verification commands (tests, type-check) if CI status is unconfirmed.
 
 ### Step 5: Classify Findings & Make Decision
 

package/templates/prompts/product-planning.md

@@ -2,7 +2,7 @@
 
 ## Objective
 
-Turn strategy and evidence into **well-scoped, ready-to-build work** and a **current roadmap** — the "plan" between analytics/measurement and autowork's build phase. Each run reads roadmap priorities, analytics signals, and user feedback to **propose** the next units of product work: new feature issues, formal specs/PRDs for larger epics, backlog re-ranking recommendations, and roadmap updates.
+Turn strategy and evidence into **well-scoped, ready-to-build work** and a **current roadmap** — the "plan" between analytics/measurement and autowork's build phase. Each run reads roadmap priorities, closed measurement trackers (`RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`), analytics signals, and user feedback to **propose** the next units of product work: new feature issues, feature pruning and deprecations, formal specs/PRDs for larger epics, backlog re-ranking recommendations, and roadmap updates.
 
 This routine runs behind a **human approval gate**: it **never files autowork-ready issues on its own**. It stages proposals in one planning issue for operator approval; only a subsequent operator-approved **Promote** run creates the real issues autowork can claim.
 
@@ -11,9 +11,10 @@ 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, and recent feedback/analytics findings
+- [ ] Read current roadmap, domain documentation, closed measurement trackers, and recent feedback/analytics findings
+- [ ] Performed Feature Pruning & Deprecation Audit: evaluated shipped features and measurement outcomes for low-ROI (<2% user adoption or >50% failure rate) features, 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)
+  - Up to 3 well-scoped proposals (Summary/Tasks/Why/Complexity), covering additions, pivots, or deprecations
   - Backlog re-ranking recommendations
   - Formal `/to-spec` PRD drafts for any proposal above `size/M`
   - Proposed `ROADMAP.md` updates
@@ -33,6 +34,13 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 - **Max iterations**: 30 — after 30 tool call rounds without completing Definition of Done, STOP. Log FAILURE with category `token_limit`.
 - **Max scope**: planning and staging only. Do not implement code or open feature PRs.
 - **Language Requirement**: All GitHub issue titles, descriptions, task checklists, and comments MUST be written in **English**.
+- **Session link footer**: sign every GitHub post with the Antigravity run footer (`_Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_`).
+
+## Negative examples (DO NOT do these)
+
+- Do not ignore closed measurement tracker directives (`RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`) — incorporate them directly into planning.
+- Do not propose only new features while ignoring dead features with <2% adoption or >50% failure rates — keep the codebase lean by actively proposing deprecations.
+- Do not create unapproved autowork-ready candidate issues directly in Propose mode.
 
 ## Instructions
 
@@ -43,10 +51,13 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 
 ### Steps 1–3: Propose Mode (Staging Proposals)
 
-1. Read `ROADMAP.md`, `AGENTS.md`, and open issues.
-2. Draft up to 3 high-impact proposals based on roadmap priorities and user feedback.
-3. For proposals sized `size/M` or above, draft a formal specification using `/to-spec`.
-4. Stage all proposals in a dedicated staging issue: `🗺️ Product Plan — {YYYY-MM-DD}` assigned to the repo maintainer.
+1. Read `ROADMAP.md`, `AGENTS.md`, closed measurement trackers with `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`, and open issues.
+2. **Feature Pruning & Deprecation Audit**:
+   - Audit shipped features and closed measurement tracker verdicts.
+   - For any feature with <2% user adoption, sub-threshold CTR, or >50% failure rate, 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.
+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.
 
 ### Step 4: Promote Mode (Approved Execution)
 

package/templates/skills/diagnosing-bugs/SKILL.md

@@ -85,6 +85,15 @@ Done when **every remaining element is load-bearing**: removing any one of them
 
 Do not proceed until you have reproduced **and** minimised.
 
+## Intent vs. Defect Guardrail (Telemetry Rabbit Hole Prevention)
+
+When diagnosing an under-performing event, low-conversion funnel, or zero-click CTA:
+
+1. **Check for mechanical functionality first.** Run the code path or click handler in isolation: does it execute, route, and emit telemetry without throwing?
+2. **Distinguish user intent from code defects.** If the feature renders above the fold and works when clicked, but telemetry reveals near-zero clicks (<2% adoption), the root cause is **lack of user intent**, not a software bug.
+3. **Prevent the Telemetry Rabbit Hole.** Do NOT spend cycles instrumenting elaborate fallback telemetry, defensive error handling, or retry loops for a feature users simply do not want.
+4. **Handoff to product planning.** Reclassify the issue as a product/UX question (`needs-design` or `roadmap/*`) and hand it off to `product-planning` rather than writing code fixes.
+
 ## Phase 3: Hypothesise
 
 Generate **3–5 ranked hypotheses** before testing any of them. Single-hypothesis generation anchors on the first plausible idea.

package/templates/workflows/autowork-cron.yml

@@ -12,6 +12,10 @@ on:
         description: 'Optional issue number to work in Targeted mode (leave blank for Scan mode)'
         required: false
         type: string
+      issue_number:
+        description: 'Alias for target_issue (e.g. 18)'
+        required: false
+        type: string
 
 concurrency:
   group: autowork-agent-scan
@@ -106,7 +110,7 @@ jobs:
           GOOGLE_API_KEY: ${{ secrets.GEMINI_API_KEY }}
           ANTIGRAVITY_API_KEY: ${{ secrets.GEMINI_API_KEY }}
           GH_TOKEN: ${{ secrets.GH_PAT || github.token }}
-          TARGET_ISSUE: ${{ inputs.target_issue }}
+          TARGET_ISSUE: ${{ inputs.target_issue || inputs.issue_number }}
           SKILLS_PROMPT: ${{ steps.skills.outputs.skills_prompt }}
           GITHUB_SERVER_URL: ${{ github.server_url }}
           GITHUB_REPOSITORY: ${{ github.repository }}
@@ -132,6 +136,20 @@ jobs:
             cat "$LATEST_LOG" >> "$GITHUB_STEP_SUMMARY"
           fi
 
+      - name: Emit Fleet Telemetry (Opt-in)
+        if: always()
+        env:
+          GH_TOKEN: ${{ secrets.GH_PAT || github.token }}
+          TELEMETRY_ENDPOINT: ${{ secrets.JONAH_FLEET_TELEMETRY_ENDPOINT }}
+          GITHUB_REPOSITORY: ${{ github.repository }}
+          GITHUB_RUN_ID: ${{ github.run_id }}
+          GITHUB_RUN_NUMBER: ${{ github.run_number }}
+        run: |
+          LATEST_LOG=$(ls -t .github/prompts/logs/autowork/*.md 2>/dev/null | head -n 1)
+          if [ -n "$LATEST_LOG" ] && [ -f "$LATEST_LOG" ]; then
+            npx --yes jonah-fleet telemetry --emit --log "$LATEST_LOG" --endpoint "$TELEMETRY_ENDPOINT" || true
+          fi
+
       - name: Verify Atomic Handoff Invariant (PR Existence Guard)
         if: always()
         env:

package/templates/workflows/prompt-optimizer-cron.yml

@@ -83,3 +83,25 @@ jobs:
             --output-format text \
             --print-timeout 35m \
             --dangerously-skip-permissions
+
+      - name: Emit run summary
+        if: always()
+        run: |
+          LATEST_LOG=$(ls -t .github/prompts/logs/optimizer/*.md 2>/dev/null | head -n 1)
+          if [ -n "$LATEST_LOG" ] && [ -n "$GITHUB_STEP_SUMMARY" ]; then
+            cat "$LATEST_LOG" >> "$GITHUB_STEP_SUMMARY"
+          fi
+
+      - name: Emit Fleet Telemetry (Opt-in)
+        if: always()
+        env:
+          GH_TOKEN: ${{ secrets.GH_PAT || github.token }}
+          TELEMETRY_ENDPOINT: ${{ secrets.JONAH_FLEET_TELEMETRY_ENDPOINT }}
+          GITHUB_REPOSITORY: ${{ github.repository }}
+          GITHUB_RUN_ID: ${{ github.run_id }}
+          GITHUB_RUN_NUMBER: ${{ github.run_number }}
+        run: |
+          LATEST_LOG=$(ls -t .github/prompts/logs/optimizer/*.md 2>/dev/null | head -n 1)
+          if [ -n "$LATEST_LOG" ] && [ -f "$LATEST_LOG" ]; then
+            npx --yes jonah-fleet telemetry --emit --log "$LATEST_LOG" --endpoint "$TELEMETRY_ENDPOINT" || true
+          fi