jonah-fleet 1.1.0 → 1.4.0

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

@@ -4,24 +4,26 @@ How agent routines in this repository are dispatched, claimed, and reconciled
 
 **Read this when** you need the claim protocol, the stale-claim conditions, the log-push rules, or the measurement-issue protocol — i.e. most Autowork, Peer Review, Analytics Review, and Issues Housekeeping runs.
 
-This project's automation is a GitHub-native instance of the pattern formalized for orchestrating coding agents against an issue tracker. There is **no long-running orchestrator daemon**; the roles map onto GitHub primitives:
+This project's automation is a GitHub-native implementation of the orchestration pattern formalized by OpenAI's [Symphony specification](https://github.com/openai/symphony/blob/main/SPEC.md) for orchestrating autonomous coding agents against an issue tracker. There is **no long-running orchestrator daemon**; the roles map onto GitHub primitives:
 
-| Concept | Implementation in this repo |
+| Symphony Concept | Implementation in this repo |
 |---|---|
 | `WORKFLOW.md` (repo-owned config + prompt templates) | `AGENTS.md` (aliased as `GEMINI.md`/`CLAUDE.md`) + `.github/prompts/*.md` |
 | Orchestrator (poll, dispatch, reconcile) | GitHub Actions triggers + scheduled routine sessions |
-| Issue tracker | GitHub Issues |
-| Agent runner | An ephemeral agent session (Antigravity CLI `agy`) in an isolated fresh clone |
+| Issue tracker (Linear in Symphony) | GitHub Issues |
+| Agent runner (Codex app-server in per-issue workspace) | An ephemeral agent session (Antigravity CLI `agy`) in an isolated fresh clone |
 | Tracker is reader/scheduler; mutations happen via agent tools | Routines only schedule; the agent session makes every GitHub write |
 
+
 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:
 
@@ -62,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 |
 
 ---
 
@@ -95,3 +98,100 @@ Single source of truth for every routine's Logging section:
 1. **Direct commit to `main` is default**: For operational run logs under `.github/prompts/logs/**`, commit directly to `main` via GitHub API or git push.
 2. **Draft PR fallback**: If direct push fails, commit the log to a dedicated, fresh branch and open a draft PR carrying only the log files.
 3. **Automated landing**: `auto-merge-log-prs.yml` or `issues-housekeeping.md` lands accumulated log PRs. Draft log PRs are never reviewed by Peer Review and do not count toward Autowork's backpressure limits.
+
+---
+
+## Token Anomaly Triage & Remediation
+
+How token spend, runaway loops, and budget anomalies are detected, triaged, and remediated autonomously across the fleet:
+
+1. **Supervised Token Ceiling**: The fleet operates under a global 70% weekly token ceiling (~8.75M tokens/week across all routines). `optimizer.md` evaluates pacing during each scheduled sweep.
+2. **Anomaly Classification & Heuristics**:
+   - **Token Surge**: Average token spend per run for a specific routine increases >50% week-over-week. Trigger: prompt bloat or runaway context accumulation. Remediation: prompt instruction pruning, replacing verbose guidelines with concise leading words and progressive disclosure pointers.
+   - **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.
+
+---
+
+## Autonomous Issue Synthesis
+
+How external and human contributor pull requests are reconciled into the issue tracker without manual friction or reviewer bounces:
+
+1. **Zero-Friction Contribution**: External human contributors often submit PRs directly without opening an issue first. Forcing contributors to open tracking issues or bouncing clean PRs causes friction, review thrash, and abandonment.
+2. **Autonomous Synthesis on Merge**: When `peer-review.md` approves a pull request lacking a `Closes #N` link, the review routine automatically synthesizes a tracking issue before merging:
+   - Creates a tracked issue via `gh issue create` capturing the PR title, body, and deliverables.
+   - 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

@@ -13,6 +13,7 @@ The run is SUCCESS if ALL of these are true:
 - [ ] All log files from the incremental window in `.github/prompts/logs/` have been scanned
 - [ ] Every FAILURE log has been categorized and analyzed
 - [ ] Inefficiency and review loops per PR have been computed across SUCCESS logs
+- [ ] Per-agent token and cost consumption metrics have been aggregated across in-window logs and evaluated against the 70% weekly budget ceiling in `ORCHESTRATION.md`
 - [ ] Closed bug issues and merged bug-fix PRs in the window have been analyzed for systemic root causes
 - [ ] For each fixable pattern:
   - If project-specific: opened a local PR with a prompt, template, or test fix and marked ready for review
@@ -38,17 +39,37 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 
 ### 1. Collect signals & analyze logs
 
-1. Scan in-window log files in `.github/prompts/logs/*/`.
-2. Extract failure categories: `prompt_unclear`, `data_issue`, `token_limit`, `infeasible_task`.
-3. Compute efficiency metrics: PRs with 3+ review rounds, high iteration usage.
-4. Analyze resolved bugs for missing checks in authoring (`autowork.md`) or review (`peer-review.md`).
+1. **Scan in-window log files**: Read all log files in `.github/prompts/logs/*/` within the incremental scan window.
+2. **Extract failure categories**: Categorize runs logging `FAILURE` (`prompt_unclear`, `data_issue`, `token_limit`, `infeasible_task`).
+3. **Compute efficiency metrics**: Identify PRs experiencing $\ge 3$ review bounce rounds and runs with high iteration usage relative to limits.
+4. **Aggregate per-agent token & cost consumption**:
+   - Parse the metadata table from each in-window log: `Routine`, `Input tokens`, `Output tokens`, `Estimated cost`, `Iterations used` (e.g. `26 / 65`), and `Result` (`SUCCESS` or `FAILURE`).
+   - Group logs by `Routine` (`autowork`, `peer-review`, `issues-housekeeping`, `dependency-update-security-check`, `optimizer`, `product-planning`).
+   - For each routine, compute:
+     - **Run count**: total completed runs.
+     - **Token volume**: total input tokens, total output tokens, combined total tokens.
+     - **Cost volume**: sum of estimated costs ($).
+     - **Fleet spend share**: `(routine total cost / fleet total cost) * 100` (or token volume share if cost is unmetered).
+     - **Token averages & peaks**: average tokens per run and max tokens in a single run.
+     - **Iteration efficiency**: average iterations used per run and percentage of budget consumed.
+   - **Weekly token ceiling pacing**: Compare total fleet tokens and per-routine volume against the 70% weekly token budget ceiling specified in `ORCHESTRATION.md` (~8.75M tokens/week, and per-routine budget overrides in `agents-manifest.json` if present). Determine burn rate velocity (tokens/day) and projected 7-day total.
+5. **Evaluate Token Anomaly Heuristics**: Detect actionable anomalies using concrete numerical thresholds:
+   - **Token Surge**: Routine average token consumption increases >50% week-over-week (or against baseline).
+   - **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
 
-Translate findings into concrete preventative improvements:
-- Enhance pre-ready checklist in `autowork.md`
-- Add automated verification tests or invariant checks
-- Clarify ambiguous prompt instructions
+Translate findings into concrete preventative improvements and remediation triggers:
+- **Instruction Pruning**: For Token Surge and prompt bloat, prune redundant instructions, anti-patterns, and no-ops in routine prompts following `/writing-for-agents` principles (replacing sprawling descriptions with crisp leading words and progressive disclosure pointers).
+- **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)
 
@@ -67,6 +88,23 @@ Translate findings into concrete preventative improvements:
 After completing (SUCCESS or FAILURE), write a log file to `.github/prompts/logs/optimizer/{timestamp}.md` following the schema in `.github/prompts/logs/_template.md`. Include:
 - Prompt SHA
 - Analyzed logs count and identified patterns
+- **Token & Cost Consumption by Agent** scorecard table:
+
+```markdown
+### Token & Cost Consumption by Agent
+
+| Routine | Runs | Input Tokens | Output Tokens | Total Tokens | Cost | Fleet % | Avg Iterations | Max Iterations | Status / Anomaly |
+|---|---|---|---|---|---|---|---|---|---|
+| `autowork` | 0 | 0 | 0 | 0 | $0.00 | 0.0% | 0 | 0 | Nominal |
+| `peer-review` | 0 | 0 | 0 | 0 | $0.00 | 0.0% | 0 | 0 | Nominal |
+| `issues-housekeeping` | 0 | 0 | 0 | 0 | $0.00 | 0.0% | 0 | 0 | Nominal |
+| `dependency-update-security-check` | 0 | 0 | 0 | 0 | $0.00 | 0.0% | 0 | 0 | Nominal |
+| `optimizer` | 0 | 0 | 0 | 0 | $0.00 | 0.0% | 0 | 0 | Nominal |
+| `product-planning` | 0 | 0 | 0 | 0 | $0.00 | 0.0% | 0 | 0 | Nominal |
+```
+
+- Weekly token budget pacing evaluation (pacing vs 70% ceiling in `ORCHESTRATION.md`)
 - PRs opened (local or upstream)
 
 **Important**: Commit the log file directly to `main` and push. Follow the Log delivery fallback in `ORCHESTRATION.md` if direct push fails.
+

package/templates/prompts/peer-review.md

@@ -19,7 +19,7 @@ The run is SUCCESS only if ALL of these are true:
 
 - [ ] Identified the target PR: if one was named in the invocation, reviewed exactly that PR; otherwise listed open PRs and selected one by priority
 - [ ] Ran the code-review pass (`/code-review` and security pass), and posted findings as inline review comments
-- [ ] Took exactly one final action: squash-merged (if PR is good, CI green and present, linked issue exists) OR posted findings and **converted the PR back to draft** (`gh pr ready <N> --undo`) for author/autowork in-session fixes OR, if round cap reached at round 5 with blocking findings, converted to draft and escalated to human
+- [ ] Took exactly one final action: squash-merged (if PR is good, CI green and present; executed Autonomous Issue Synthesis if unlinked) OR posted findings and **converted the PR back to draft** (`gh pr ready <N> --undo`) for author/autowork in-session fixes OR, if round cap reached at round 5 with blocking findings, converted to draft and escalated to human
 - [ ] If merging: captured deferred non-blocking findings per materiality bar (filed follow-up issues for material ones, batched or dropped immaterial ones)
 - [ ] If in Scan mode and no eligible PRs exist, logged SUCCESS with "No PRs to review"
 
@@ -37,8 +37,8 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 ## Final action: merge or bounce to draft
 
 Every review ends in exactly one of two states:
-- **Merge** — only if PR is good, CI is green and verified on the head commit, and has a linked issue (`Closes #N`).
-  - Sequence: (1) squash-merge, (2) submit held review comments, (3) file follow-up issues for deferred material findings.
+- **Merge** — only if PR is good, CI is green and verified on the head commit. If the PR does not reference a tracked issue (`Closes #N`), execute Autonomous Issue Synthesis prior to merge.
+  - Sequence: (1) if unlinked, synthesize tracking issue (`gh issue create`) and link to PR (`gh pr edit`), (2) squash-merge, (3) submit held review comments, (4) file follow-up issues for deferred material findings.
   - Immaterial findings (style/preference) default to dying in the review thread or getting batched.
   - Mechanical doc fixes (missing changelog line, doc typo in diff) can be committed directly to `main` after squash-merge.
 - **Bounce to draft** — if any **blocking** finding remains (correctness bug, security flaw, failing/missing CI, broken contract):
@@ -50,11 +50,13 @@ 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.
 - On re-review, do not raise new findings in code that was unchanged since the prior review — only inspect the delta commits.
 - Do not bounce a PR for non-blocking style/preference findings when all correctness checks pass.
+- Do not bounce an external contributor PR purely for missing `Closes #N` when the PR description provides a clear specification.
 
 ## Instructions
 
@@ -66,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
 
@@ -80,16 +85,34 @@ Check if `$PR_NUMBER` is set:
 
 1. Run `/code-review` over the diff (or delta commits if re-review) evaluating:
    - **Standards**: Conformance to `AGENTS.md` (or `CLAUDE.md`/`GEMINI.md`), conventions, and architecture.
-   - **Spec Compliance**: Verification against the linked issue's deliverables (`## Tasks`).
+   - **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
 
 Classify each finding:
-- **Blocking**: Broken logic, security hole, data loss, regression, broken tests, missing linked issue.
-- **Non-blocking**: Minor refactor, style preference, performance micro-optimization.
+- **Blocking**: Broken logic, security hole, data loss, regression, broken tests, missing deliverable from the issue/PR specification.
+- **Non-blocking**: Minor refactor, style preference, performance micro-optimization, missing `Closes #N` on contributor PRs with self-contained descriptions.
+
+### Step 5.5: Autonomous Issue Synthesis (for unlinked PRs)
+
+If the PR is clean and approved for merge, but lacks a `Closes #N` tracking link:
+1. Synthesize a retroactive tracking issue on GitHub:
+   ```bash
+   gh issue create --title "<PR Title>" --body "Tracked retroactively from external pull request #<PR_NUMBER>.\n\n## Deliverables & Context\n<PR Description>\n\n_Synthesized autonomously by Jonah Fleet Peer Review_"
+   ```
+2. Capture the newly created issue number `$ISSUE_NUMBER`.
+3. Edit the PR description to append `Closes #$ISSUE_NUMBER`:
+   ```bash
+   gh pr edit <PR_NUMBER> --body "<PR Description>\n\nCloses #$ISSUE_NUMBER"
+   ```
 
 ### Step 6: Execute Final Action
 
@@ -97,6 +120,7 @@ Classify each finding:
   - If `N < 5`: Post inline comments, submit review as `COMMENT`, and convert PR to draft (`gh pr ready <N> --undo`).
   - If `N >= 5`: Convert PR to draft, post summary comment escalating to repo maintainer, and apply `needs-human` label.
 - **If Clean (or only Non-blocking findings)**:
+  - If PR lacks `Closes #N`, execute Autonomous Issue Synthesis (Step 5.5).
   - Squash-merge the PR: `gh pr merge <N> --squash --delete-branch`.
   - Submit held review comments.
   - File follow-up issues for material non-blocking findings.