jonah-fleet 1.8.0 → 1.9.1

package/templates/prompts/autowork.md

@@ -86,7 +86,7 @@ a. **Read the target issue and check eligibility.** Eligible = open, unassigned
    - **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.
+   - **Active Origin Sync & Clean-Merge Gate**: Run `git fetch origin main && git merge origin/main --no-edit` to absorb any newly merged pull requests and resolve any conflicts locally. Verify `git merge-tree origin/main HEAD` reports no conflicts before marking ready.
    - **Release claim on ready**: mark the PR ready (`gh pr ready <PR>`) and unassign yourself (`gh pr edit <PR> --remove-assignee <login>`) so Peer Review can evaluate without holding stale agent reservation locks.
      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.
@@ -139,10 +139,28 @@ a. **Read the target issue and check eligibility.** Eligible = open, unassigned
     - Read `🧭 Decomposition plan` comment (or create if first run).
     - Pick next slice(s), batching up to 3 same-recipe slices into one child issue + PR.
     - Create and claim child issue first, then update plan marker to `🚧 in progress — child #M`, release umbrella claim, and implement against child.
+    - **Milestone 1 (Intake & Strategy)**: If `$ROUTINE_ISSUE_NUMBER` is set, emit milestone card to the routine issue thread:
+      ```bash
+      gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "### 🧭 Milestone: Intake & Strategy
+- **Phase**: \`Phase 1 · Target Selection & Planning\`
+- **Status**: ⏳ In Progress
+- **Target / Context**: \`#<TARGET_ISSUE> (<Title>)\`
+- **Key Decision / Finding**: <Summary of plan, root cause, or reproduction strategy>
+- **Next**: Implementation & Test Verification" || true
+      ```
 13. **Implementation & PR creation:**
     - Branch from freshly fetched `origin/main` with descriptive name (e.g. `feat/...` or `fix/...`).
     - Drive implementation via `/tdd` (red-green-refactor).
     - Run repository tests and verification.
+    - **Milestone 2 (Verification & Tests)**: Once implementation passes tests and type checks, emit milestone card if `$ROUTINE_ISSUE_NUMBER` is set:
+      ```bash
+      gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "### 🧪 Milestone: Verification & Tests
+- **Phase**: \`Phase 2 · Implementation & Verification\`
+- **Status**: ✅ Tests Passing
+- **Target / Context**: \`#<TARGET_ISSUE>\`
+- **Key Decision / Finding**: Tests verified passing with zero failures and clean type-check.
+- **Next**: PR Creation & Autonomous Handoff" || true
+      ```
     - 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.
@@ -150,6 +168,15 @@ a. **Read the target issue and check eligibility.** Eligible = open, unassigned
     - **Issue Cross-Reference Comment Guardrail**: Post an explicit comment on the tracking issue referencing the newly created PR (`gh issue comment <ISSUE_NUMBER> --body "Work in progress in PR #<PR_NUMBER>."`). This guarantees an unambiguous, permanent link on the issue timeline even when GitHub's native UI link is suppressed for bot draft PRs.
     - **Warm Context Assignment**: Assign yourself to the newly opened PR (`gh pr edit <PR> --add-assignee <login>`) to hold the reservation across Step 15's in-session review wait so parallel Scan routines recognise the PR as actively held by a live session.
     - Mark PR ready (`gh pr ready <PR>`).
+    - **Milestone 3 (Autonomous Handoff)**: Once PR is marked ready, emit milestone card if `$ROUTINE_ISSUE_NUMBER` is set:
+      ```bash
+      gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "### 🚀 Milestone: Autonomous Handoff
+- **Phase**: \`Phase 3 · Autonomous Handoff\`
+- **Status**: ✅ PR Marked Ready
+- **Target / Context**: \`PR #<PR_NUMBER> (closes #<TARGET_ISSUE>)\`
+- **Key Decision / Finding**: Pushed branch and marked PR ready for review.
+- **Next**: In-session review wait or run completion" || true
+      ```
 14. If run aborts before opening PR, release claim (unassign).
 15. **In-Session Peer Review Wait & Immediate Convergence (Warm Context):**
     - Poll PR status for up to 10–12 minutes.
@@ -159,23 +186,27 @@ a. **Read the target issue and check eligibility.** Eligible = open, unassigned
 
 ## Logging
 
-After completing (SUCCESS or FAILURE), write a log file to `.github/prompts/logs/autowork/{timestamp}.md` following the schema in `.github/prompts/logs/_template.md`. Include:
+After completing (SUCCESS or FAILURE), record run execution details to `.jonah-fleet/run-report.md`. Include:
 
 - The prompt SHA (run `git rev-parse --short HEAD:.github/prompts/autowork.md`)
 - Every Definition of Done criterion with YES/NO and evidence
 - Full execution trace with tool calls
 - If FAILURE: root cause, category, and suggested fix
 
-**Log Delivery Protocol & Invariants**:
+**Issue Logging Protocol & Invariants**:
 
-- **Negative Rule**: NEVER commit or push run logs to a feature branch or open PR branch. Doing so emits a `pull_request: synchronize` event under bot credentials, triggering GitHub Actions workflow approval gates (`action_required`) that stall CI.
-- **Mandatory `[skip ci]`**: Always append `[skip ci]` to any log commit message.
-- **Direct Push to `main`**: Commit the log file directly to `main` and push — explicitly permitted for files under `.github/prompts/logs/**`:
+- **Negative Rule**: NEVER commit or push run logs to any git branch (`main` or feature branches). Run logs are recorded exclusively as GitHub Issues and local `.jonah-fleet/runs/*.json` artifacts.
+- **Milestone 4 (Run Completed)**: If `$ROUTINE_ISSUE_NUMBER` is set in the environment, append the concluding compact milestone card to close out the comment stream:
   ```bash
-  git checkout main
-  git pull origin main
-  git add .github/prompts/logs/autowork/{timestamp}.md
-  git commit -m "docs(log): record autowork run {timestamp} [skip ci]"
-  git push origin main
+  gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "### 🏁 Milestone: Run Completed
+- **Phase**: \`Phase 4 · Reconciliation\`
+- **Status**: ✅ SUCCESS
+- **Target / Context**: \`#<TARGET_ISSUE>\` · \`PR #<PR_NUMBER>\`
+- **Key Decision / Finding**: All DoD criteria satisfied and verified.
+- **Next**: Routine finished; issue closed by harness" || true
   ```
-  Follow the Log delivery fallback in `ORCHESTRATION.md` if direct push fails.
+- **Harness Reconciliation**: When running under GitHub Actions or `jonah-fleet daemon`, the harness initializes the run issue (`status:running`), replaces the top-level issue body with `.jonah-fleet/run-report.md`, and reconciles the final status upon completion:
+  - On **SUCCESS**: Labels `status:success`, removes `status:running`, and closes the issue.
+  - On **FAILURE**: If interrupted or failed, the harness posts the Interruption Card, edits the body, and marks `status:failure,needs-attention`.
+  - On clean local runs outside a harness, write `.jonah-fleet/runs/{timestamp}.json`.
+- Follow the Routine Issue Logging & Telemetry Protocol in `ORCHESTRATION.md`.

package/templates/prompts/dependency-update-security-check.md

@@ -36,9 +36,11 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 
 ## Logging
 
-After completing (SUCCESS or FAILURE), write a log file to `.github/prompts/logs/dependency-update-security-check/{timestamp}.md` following the schema in `.github/prompts/logs/_template.md`. Include:
+After completing (SUCCESS or FAILURE), record run execution details to `.jonah-fleet/run-report.md`. Include:
 - Prompt SHA
 - Tally of audited dependencies and security findings
 - List of created or updated issues
 
-**Important**: Commit the log file directly to `main` and push. Follow the Log delivery fallback in `ORCHESTRATION.md` if direct push fails.
+**Issue Logging Protocol**:
+- Record run execution details to `.jonah-fleet/run-report.md` (or update `$ROUTINE_ISSUE_NUMBER`).
+- Follow the Routine Issue Logging & Telemetry Protocol in `ORCHESTRATION.md`. Never commit run logs to git branches.

package/templates/prompts/design-review.md

@@ -0,0 +1,125 @@
+# Design Review
+
+## Objective
+
+Audit player-facing surfaces for design system token deviations, visual clutter, candidates for feature pruning, and high-impact UX improvements. Provide a continuous, budget-capped quality loop across the app by combining dynamic route discovery, static code analysis, and headless visual critiques. Directly file concrete, self-contained design fixes for Autowork while staging structural UX opportunities and pruning proposals into a dedicated Design Review issue for Product Planning to ingest.
+
+## Definition of Done
+
+The run is SUCCESS only if ALL of these are true:
+
+- [ ] Evaluated target surfaces: if `TARGET_SURFACE` was provided via manual dispatch, targeted that specific surface; otherwise performed dynamic route discovery across `src/app/[locale]/**/page.tsx` (excluding `admin/**`), prioritized any `[NEW SURFACE]` at Priority 0, and proceeded through the rotation sequence within the 30-iteration budget
+- [ ] Performed Tier 1 Static Code Audit on target surfaces: checked against `DESIGN_SYSTEM.md` foundations, flagging arbitrary Tailwind values (`text-[...]`, `w-[...]`, arbitrary colors), non-standard button styling, multiple `.btn-primary` actions per view, and contrast token regressions
+- [ ] Performed Tier 2 Headless Browser & Visual Critique: launched the dev environment and captured viewports at mobile (390px) and desktop (1280px) via `run` and `design-critique` skills, auditing whitespace consistency, visual hierarchy, touch targets, and viewport density (enforcing the mobile fold budget: max 1 banner/nudge)
+- [ ] Cross-referenced UI friction and telemetry signals: checked for recurring rage clicks (`$rageclick`) and identified low-interaction (<2% CTR) secondary elements or persistent nudges suitable for pruning
+- [ ] Executed Hybrid Handoff:
+  - If self-contained token, class, or contrast violations were found, filed or updated exactly one grouped punchlist issue titled `🎨 Design Polish & Token Cleanup — {YYYY-MM-DD}` labeled `design/polish` for Autowork
+  - Created or updated exactly one tracking issue titled `🎨 Design Review — {YYYY-MM-DD}` documenting: Surfaces Reviewed (with any `[NEW SURFACE]` highlighted), Next Surfaces in Rotation, Visual Critique & Clutter Analysis, Feature Pruning & Deprecation Recommendations, and Experience Enhancement Opportunities
+- [ ] Emitted structured design directives in the run report (`DESIGN_DIRECTIVE: [PRUNE | REDESIGN | POLISH]`) and recorded the next queued surfaces for the subsequent run
+- [ ] Recorded the final execution report to `.jonah-fleet/run-report.md` following `ORCHESTRATION.md`
+
+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**: auditing player-facing UI surfaces only (`src/app/[locale]/**/page.tsx`, excluding `admin/**`). Do not implement feature code or open feature PRs directly.
+- **Budget-capped rotation**: review as many prioritized surfaces as possible within the iteration budget; do not attempt an exhaustive sweep if approaching the tool call ceiling. Stamp remaining surfaces as `Next Surfaces in Rotation`.
+- **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 open multiple separate issues for individual token mismatches — group all simple token and contrast cleanup items into a single grouped punchlist issue for Autowork.
+- Do not file unapproved structural redesigns or feature removals as direct Autowork issues — stage them in the `🎨 Design Review — {date}` tracking issue for Product Planning to review.
+- Do not review the admin back-office (`src/app/[locale]/admin/**`) — it is deliberately utilitarian and exempt from the player-facing design system polish bar.
+- Do not blindly repeat the same surface review order every run — dynamically discover routes and check previous review issues to resume rotation and fast-track unreviewed new surfaces.
+
+## Instructions
+
+### Step 1: Dynamic Route Discovery & Target Prioritization
+
+1. **Check for Manual Target Override**:
+   - If the environment variable `TARGET_SURFACE` is provided and non-empty, audit only that specified surface or route and skip rotation determination.
+2. **Dynamic Route Discovery**:
+   - Scan the filesystem for all active player-facing page routes: `src/app/[locale]/**/page.tsx` (ignoring any `admin/**` directories).
+   - Normalize the discovered paths into canonical route identifiers (e.g. `Home` (`/`), `Predictions` (`/pronostics`), `Episode Predictions` (`/pronostics/episode/[id]`), `Groups` (`/groupes`), `Group Detail` (`/groupes/[id]`), `Presenter` (`/groupes/[id]/presentateur`), `Leaderboard` (`/classements`), `Profile` (`/profil`), `Account` (`/compte`), `Auth` (`/auth/*`), `Season Overview` (`/saisons/[slug]`), `Share` (`/partage`)).
+3. **Reconcile with Previous Rotation State**:
+   - Locate the most recent `🎨 Design Review` issue or run issue labeled `routine:design-review`.
+   - Read the `Surfaces Reviewed` and `Next Surfaces in Rotation` fields.
+   - Any discovered route on disk that has never appeared in prior review logs is flagged as **`[NEW SURFACE]`** and placed at **Priority 0** (Fast-Track).
+   - Remaining surfaces are sequenced based on `Next Surfaces in Rotation` (resuming rotation where the previous run stopped).
+   - Any route present in the previous rotation list that no longer exists on disk is automatically pruned.
+4. **Set Run Queue**:
+   - Build the active review queue: `[NEW SURFACE]` items first, followed by the queued rotation surfaces.
+   - Keep a budget awareness counter: as iterations proceed, stop adding new surfaces when remaining tool calls are needed for issues and logging.
+
+### Step 2: Static Code & Token Audit
+
+For each surface in the active queue:
+1. Locate the page component and its imported presentation components under `src/components/**`.
+2. Inspect the styling using `.agents/skills/design-system/SKILL.md`:
+   - **Token Purity**: flag hardcoded hex codes (`#...`), rgb values, or arbitrary Tailwind brackets (e.g. `text-[13px]`, `w-[310px]`).
+   - **Surface Hierarchy**: verify background hierarchy adheres to `bg-gray-950` (base) → `bg-gray-900` / `.card` (card) → `bg-gray-800` / `.input-field` (input).
+   - **Contrast Tokens**: ensure readable secondary text uses `text-gray-400` minimum (never `text-gray-500`, which fails WCAG AA on dark backgrounds).
+   - **CTA Discipline**: verify each view/tab contains at most **one** primary action button (`.btn-primary`). Flag competing primary buttons.
+   - **Button & Pill Standards**: verify buttons use established classes (`.btn-primary`, `.btn-secondary`, `.btn-ghost`) and status pills use standard semantic colors.
+
+### Step 3: Headless Browser & Visual Critique
+
+For the surfaces being audited:
+1. Start the local Next.js dev server with mock credentials following `.agents/skills/run/SKILL.md`:
+   ```bash
+   NEXT_PUBLIC_SUPABASE_URL=http://localhost:54321 NEXT_PUBLIC_SUPABASE_ANON_KEY=placeholder npm run dev
+   ```
+2. Using Playwright, capture screenshots at two standard viewports:
+   - **Mobile**: 390px width
+   - **Desktop**: 1280px width
+3. Apply `.agents/skills/design-critique/SKILL.md` to evaluate visual evidence:
+   - **Viewport Density & Nudge Budget**: On mobile (390px), do sticky headers, promotional banners, and teasers crowd the viewport above the fold? Enforce: max 1 banner/nudge visible concurrently.
+   - **Visual Hierarchy & Clutter**: Are cards nested redundantly? Is there visual noise from excessive borders, conflicting accents, or dense text blocks?
+   - **Touch Targets & Spacing**: Are tap targets at least 44x44px? Is whitespace rhythmic and intentional?
+4. Shut down the dev server cleanly after capture.
+
+### Step 4: Telemetry & Friction Cross-Reference
+
+1. If telemetry endpoints or PostHog logs are available:
+   - Audit `$rageclick` events associated with URLs and selectors of the reviewed surfaces. Pinpoint confusing or non-interactive elements masquerading as buttons.
+   - Review click-through rates (CTR) on secondary promotional cards or banner elements.
+2. Formulate **Pruning Recommendations**:
+   - Any persistent card, teaser, or secondary control with near-zero interaction, high rage-click density, or severe visual clutter is recommended for deprecation (`RECOMMENDATION: DEPRECATE`) or simplification (`RECOMMENDATION: PRUNE`).
+
+### Step 5: Hybrid Handoff & Issue Generation
+
+1. **Direct Autowork Punchlist Issue**:
+   - If concrete, self-contained token violations, contrast bugs, or duplicate `.btn-primary` classes are found, compile them into a single grouped punchlist issue:
+     - Title: `🎨 Design Polish & Token Cleanup — {YYYY-MM-DD}`
+     - Labels: `design/polish`, `autowork-candidate`
+     - Content: Structured task list with target files, line references, current violation, and suggested replacement token/class.
+2. **Overarching Design Review Tracking Issue**:
+   - Create or update a single tracking issue:
+     - Title: `🎨 Design Review — {YYYY-MM-DD}`
+     - Labels: `area/design`, `review`
+     - Content:
+       - **Surfaces Reviewed**: list audited routes, noting any `[NEW SURFACE]`
+       - **Next Surfaces in Rotation**: list unreviewed routes queued for the subsequent run
+       - **Visual Critique & Clutter Analysis**: mobile fold density, hierarchy, and layout observations
+       - **Pruning & Deprecation Candidates**: specific features/elements recommended to be pruned or consolidated
+       - **Experience Enhancement Opportunities**: structural UX improvements staged for Product Planning
+3. **Structured Directives**:
+   - Output clear directives: `DESIGN_DIRECTIVE: [PRUNE | REDESIGN | POLISH]` to be consumed downstream by `product-planning.md`.
+
+## Logging
+
+Follow the Routine Issue Logging Protocol in `ORCHESTRATION.md`:
+1. Write the final run report to `.jonah-fleet/run-report.md`.
+2. Include the Run Summary table with:
+   - Routine: `design-review`
+   - Prompt SHA (run `git rev-parse --short HEAD:.github/prompts/design-review.md` or template)
+   - Result: `SUCCESS` or `FAILURE`
+   - Every Definition of Done criterion with YES/NO and evidence
+   - Surfaces Reviewed and Next Surfaces in Rotation
+   - Created issues (`🎨 Design Polish & Token Cleanup`, `🎨 Design Review`)
+   - If FAILURE: root cause, category, and suggested fix
+3. The surrounding execution harness will reconcile the corresponding GitHub issue.
+

package/templates/prompts/issues-housekeeping.md

@@ -15,7 +15,7 @@ The run is SUCCESS only if ALL of these are true:
 - [ ] Label audit completed: every open issue has consistent type, size, and priority labels
 - [ ] Dependency check completed: issues with `## Dependencies` verified against blocker status
 - [ ] Orphaned-claim sweep completed: stale autowork claims (per `ORCHESTRATION.md`) released back to the unclaimed pool
-- [ ] Draft log-only PR sweep completed: open draft PRs whose changed files are entirely under `.github/prompts/logs/**` undrafted and squash-merged
+- [ ] Stalled routine run audit completed: routine log issues in `status:running` older than 6 hours marked as `status:failure` (timed_out)
 - [ ] Summary posted listing all changes made
 
 If any criterion cannot be met, stop immediately and log FAILURE with the reason.
@@ -24,14 +24,14 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 
 - **Max iterations**: 40 — after 40 tool call rounds without completing Definition of Done, STOP. Log FAILURE with category `token_limit`.
 - **Max scope**: housekeeping only. Do not implement code fixes or open feature PRs.
-- **No speculative work**: only modify issue metadata (labels, status, comments, releasing stale assignees) and land draft log-only PRs.
+- **No speculative work**: only modify issue metadata (labels, status, comments, releasing stale assignees, reconciling stalled routine runs).
 - **Language Requirement**: All GitHub issue titles, descriptions, task checklists, and comments MUST be written in **English**.
 
 ## Instructions
 
 ### Phase 1: Quick Recovery & Clearing
 
-1. **Draft log-only PR sweep**: Undraft and squash-merge open draft PRs whose diffs are entirely under `.github/prompts/logs/**`.
+1. **Stalled routine run sweep**: Check open issues with labels `routine-log` and `status:running`. If an issue has been in `status:running` for > 6 hours without updates, add label `status:failure`, remove `status:running`, add label `needs-attention`, and comment noting the runner timeout or crash.
 2. **Orphaned-claim sweep**: Sweep assigned issues. If an issue meets the 3 stale-claim conditions in `ORCHESTRATION.md` (autowork claim comment, no open PR, comment > 6 hours old), re-read immediately before writing, unassign the dead owner, and post a release comment.
 
 ### Phase 2: Backlog Hygiene
@@ -44,13 +44,15 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 
 ### Phase 3: Summary
 
-8. 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, reconciled stalled runs).
 
 ## Logging
 
-After completing (SUCCESS or FAILURE), write a log file to `.github/prompts/logs/issues-housekeeping/{timestamp}.md` following the schema in `.github/prompts/logs/_template.md`. Include:
+After completing (SUCCESS or FAILURE), record run execution details to `.jonah-fleet/run-report.md`. Include:
 - Prompt SHA
-- Tally of issues audited, claims released, PRs merged
+- Tally of issues audited, claims released, stalled runs reconciled
 - List of closed or modified issues
 
-**Important**: Commit the log file directly to `main` and push. Follow the Log delivery fallback in `ORCHESTRATION.md` if direct push fails.
+**Issue Logging Protocol**:
+- Record run execution details to `.jonah-fleet/run-report.md` (or update `$ROUTINE_ISSUE_NUMBER`).
+- Follow the Routine Issue Logging & Telemetry Protocol in `ORCHESTRATION.md`. Never commit run logs to git branches.

package/templates/prompts/optimizer.md

@@ -10,10 +10,10 @@ Additionally, this routine acts as the **Upstream Evolution Bridge**: when a pro
 
 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`
+- [ ] All routine run issues from the incremental window (labeled `routine-log`) have been scanned
+- [ ] Every FAILURE run has been categorized and analyzed
+- [ ] Inefficiency and review loops per PR have been computed across SUCCESS runs
+- [ ] Per-agent token and cost consumption metrics have been aggregated across in-window routine runs 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
@@ -27,23 +27,32 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 
 - **Max iterations**: 30 — stop after 30 tool call rounds.
 - **Max scope**: one PR per identified problem. Do not bundle unrelated fixes.
-- **No speculative work**: only fix patterns evidenced by logs, closed bug issues, or reviewer findings.
+- **No speculative work**: only fix patterns evidenced by routine issues, closed bug issues, or reviewer findings.
 - **Language Requirement**: All GitHub issue titles, descriptions, task checklists, and comments MUST be written in **English**.
 
 ## Instructions
 
 ### 0. Establish the incremental scan boundary
 
-1. Check `.github/prompts/logs/optimizer/` for the most recent optimizer log.
+1. Check the most recent routine issue with labels `routine-log,routine:optimizer` via `gh issue list --label routine-log --label routine:optimizer --state all --limit 1`.
 2. Extract the timestamp as the scan boundary (or last 7 days if first run).
+3. **Milestone 1 (Intake & Fleet Telemetry Scan)**: If `$ROUTINE_ISSUE_NUMBER` is set, emit milestone card to the routine issue thread:
+   ```bash
+   gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "### 🧭 Milestone: Intake & Fleet Telemetry Scan
+- **Phase**: \`Phase 1 · Telemetry Intake & Boundary Scan\`
+- **Status**: ⏳ In Progress
+- **Target / Context**: \`Fleet Telemetry Window\`
+- **Key Decision / Finding**: Established scan boundary; analyzing in-window routine issues and token pacing.
+- **Next**: Anomaly Diagnosis & Proposals" || true
+   ```
 
 ### 1. Collect signals & analyze logs
 
-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`).
+1. **Query in-window routine issues**: List routine run issues within the window using `gh issue list --label routine-log --state all --limit 100 --json number,title,body,state,labels,createdAt`.
+2. **Extract failure categories**: Categorize runs labeled `status:failure` or 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`).
+   - Parse the metadata table from each in-window routine issue body: `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.
@@ -88,9 +97,9 @@ Translate findings into concrete preventative improvements and remediation trigg
 
 ## Logging
 
-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:
+After completing (SUCCESS or FAILURE), record run execution details to `.jonah-fleet/run-report.md`. Include:
 - Prompt SHA
-- Analyzed logs count and identified patterns
+- Analyzed routine issues count and identified patterns
 - **Token & Cost Consumption by Agent** scorecard table:
 
 ```markdown
@@ -109,5 +118,15 @@ After completing (SUCCESS or FAILURE), write a log file to `.github/prompts/logs
 - 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.
+**Issue Logging Protocol**:
+- **Milestone 4 (Run Completed)**: If `$ROUTINE_ISSUE_NUMBER` is set, emit compact milestone card to close out the comment stream:
+  ```bash
+  gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "### 🏁 Milestone: Run Completed
+- **Phase**: \`Phase 4 · Reconciliation\`
+- **Status**: ✅ SUCCESS
+- **Target / Context**: \`Fleet Optimization Sweep\`
+- **Key Decision / Finding**: Fleet telemetry sweep completed and scored against token ceiling.
+- **Next**: Routine finished; issue closed by harness" || true
+  ```
+- Follow the Routine Issue Logging & Telemetry Protocol in `ORCHESTRATION.md`. Never commit run logs to git branches.
 

package/templates/prompts/peer-review.md

@@ -70,7 +70,7 @@ Check if `$PR_NUMBER` is set:
 
 ### Steps 1–2: Select a PR (Scan mode only)
 
-1. List all open PRs, excluding drafts, pure log PRs (`.github/prompts/logs/**`), and automated release PRs (`release-please--*` / `chore(main): release*`).
+1. List all open PRs, excluding drafts 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.
@@ -80,8 +80,21 @@ Check if `$PR_NUMBER` is set:
 
 ### Step 3: Round tracking & Starting Review marker
 
-- Post a "Starting review (round N)" comment on the target PR to claim the review window.
+- Post a "Starting review (round N)" comment on the target PR to claim the review window:
+  - If `$ROUTINE_ISSUE_NUMBER` is set in the environment or routine prompt, include a link to the tracking log issue:
+    `Starting review (round N) · [Run Log #$ROUTINE_ISSUE_NUMBER](${GITHUB_SERVER_URL:-https://github.com}/${GITHUB_REPOSITORY}/issues/${ROUTINE_ISSUE_NUMBER})`
+    (or `Starting review (round N) · Run log: #$ROUTINE_ISSUE_NUMBER`).
+  - If `$ROUTINE_ISSUE_NUMBER` is not set, post `Starting review (round N)`.
 - Check round count `N`. If `N >= 5` and blocking findings persist, prepare to escalate.
+- **Milestone 1 (Intake & Review Scope)**: If `$ROUTINE_ISSUE_NUMBER` is set, emit milestone card to the routine issue thread:
+  ```bash
+  gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "### 🧭 Milestone: Intake & Review Scope
+- **Phase**: \`Phase 1 · Review Target & Scope\`
+- **Status**: ⏳ In Progress
+- **Target / Context**: \`PR #<PR_NUMBER> (Round N)\`
+- **Key Decision / Finding**: Claimed review window; starting multi-angle evaluation passes.
+- **Next**: Multi-Angle Code Review Pass" || true
+  ```
 
 ### Step 4: Multi-Angle Code Review Pass
 
@@ -124,6 +137,7 @@ If the PR is clean and approved for merge, but lacks a `Closes #N` tracking link
   - 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 the PR branch has minor mechanical merge conflicts against `origin/main` (e.g. adjacent `CHANGELOG.md` entries from concurrent merges) while code and tests are sound, resolve the conflict mechanically via `/resolving-merge-conflicts` before squash-merging rather than bouncing the PR back to draft.
   - If PR lacks `Closes #N`, execute Autonomous Issue Synthesis (Step 5.5).
   - Extract the tracking issue number `$ISSUE_NUMBER` from the PR description or title (e.g. `Closes #<N>`, `Fixes #<N>`, `Resolves #<N>`).
   - Squash-merge the PR: `gh pr merge <N> --squash --delete-branch`.
@@ -132,15 +146,26 @@ If the PR is clean and approved for merge, but lacks a `Closes #N` tracking link
     gh issue close "$ISSUE_NUMBER" --comment "Closed via PR #<N> (merged into main)."
     ```
   - Submit held review comments.
+  - In any review summary, decision comment, or escalation comment posted to the PR, include the run log reference if `$ROUTINE_ISSUE_NUMBER` is set (e.g. `- **Run Log**: [#$ROUTINE_ISSUE_NUMBER](${GITHUB_SERVER_URL:-https://github.com}/${GITHUB_REPOSITORY}/issues/${ROUTINE_ISSUE_NUMBER})`).
   - File follow-up issues for material non-blocking findings.
   - If mechanical doc fixes are needed, commit directly to `main`.
 
 ## Logging
 
-After completing (SUCCESS or FAILURE), write a log file to `.github/prompts/logs/peer-review/{timestamp}.md` following the schema in `.github/prompts/logs/_template.md`. Include:
+After completing (SUCCESS or FAILURE), record run execution details to `.jonah-fleet/run-report.md`. Include:
 
 - Prompt SHA
 - Target PR number and decision (MERGE / BOUNCE / ESCALATE)
 - Execution trace and findings summary
 
-**Important**: Commit the log file directly to `main` and push. Follow the Log delivery fallback in `ORCHESTRATION.md` if direct push fails.
+**Issue Logging Protocol**:
+- **Milestone 4 (Run Completed)**: If `$ROUTINE_ISSUE_NUMBER` is set, emit compact milestone card to close out the comment stream:
+  ```bash
+  gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "### 🏁 Milestone: Run Completed
+- **Phase**: \`Phase 4 · Reconciliation\`
+- **Status**: ✅ SUCCESS
+- **Target / Context**: \`PR #<PR_NUMBER>\`
+- **Key Decision / Finding**: Review completed with decision \`<MERGE | BOUNCE | ESCALATE>\`.
+- **Next**: Routine finished; issue closed by harness" || true
+  ```
+- Follow the Routine Issue Logging & Telemetry Protocol in `ORCHESTRATION.md`. Never commit run logs to git branches.

package/templates/prompts/product-planning.md

@@ -11,8 +11,8 @@ This routine runs behind a **human approval gate**: it **never files autowork-re
 This routine runs in two modes: **Propose** (scheduled cron sweep / unapproved fire) and **Promote** (operator-approved fire).
 
 In **Propose mode**, SUCCESS requires:
-- [ ] Read current roadmap, domain documentation, closed measurement trackers, 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
+- [ ] Read current roadmap, domain documentation, closed measurement trackers, recent feedback/analytics findings, and the latest open `🎨 Design Review` issue / recent design-review routine run issues
+- [ ] Performed Feature Pruning & Deprecation Audit: evaluated shipped features, measurement outcomes (<2% user adoption or >50% failure rate), and Design Review pruning/clutter directives, drafting deprecation, removal, or simplification proposals
 - [ ] Created or updated exactly one dated staging issue (`🗺️ Product Plan — {date}`) containing:
   - Up to 3 well-scoped proposals (Summary/Tasks/Why/Complexity), covering additions, pivots, or deprecations
   - Backlog re-ranking recommendations
@@ -51,10 +51,10 @@ 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`, closed measurement trackers with `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`, and open issues.
+1. Read `ROADMAP.md`, `AGENTS.md`, closed measurement trackers with `RECOMMENDATION: [PIVOT | DEPRECATE | ITERATE]`, the latest open `🎨 Design Review` issue (and recent run issues with `gh issue list --label "routine:design-review"`), and open issues.
 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.
+   - Audit shipped features, closed measurement tracker verdicts, and `🎨 Design Review` clutter/pruning findings.
+   - For any feature with <2% user adoption, sub-threshold CTR, >50% failure rate, or persistent UI clutter flagged by Design Review, draft explicit deprecation, removal, or pivot proposals to keep the codebase lean and eliminate maintenance waste.
 3. Draft up to 3 high-impact proposals (including additions, pivots, or deprecations) based on roadmap priorities, measurement outcomes, and user feedback.
 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.
@@ -70,9 +70,13 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 
 ## Logging
 
-After completing (SUCCESS or FAILURE), write a log file to `.github/prompts/logs/product-planning/{timestamp}.md` following the schema in `.github/prompts/logs/_template.md`. Include:
-- Prompt SHA
-- Mode (Propose or Promote)
-- Staged or promoted proposals tally
+Follow the Routine Issue Logging Protocol in `ORCHESTRATION.md`:
+1. Write the final run report to `.jonah-fleet/run-report.md`.
+2. Include the Run Summary table with:
+   - Routine: `product-planning`
+   - Mode: `Propose` or `Promote`
+   - Result: `SUCCESS` or `FAILURE`
+   - Prompt SHA: (run `git rev-parse --short HEAD:.github/prompts/product-planning.md` or template)
+   - Staged or promoted proposals tally
+3. The surrounding execution harness will reconcile the corresponding GitHub issue.
 
-**Important**: Commit the log file directly to `main` and push. Follow the Log delivery fallback in `ORCHESTRATION.md` if direct push fails.