jonah-fleet 1.6.0 → 1.8.0

package/templates/prompts/ORCHESTRATION.md

@@ -6,16 +6,16 @@ How agent routines in this repository are dispatched, claimed, and reconciled
 
 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:
 
-| 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 (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 |
-
+| 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 (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 & 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.
@@ -27,7 +27,7 @@ Autowork triggers pass the target issue via environment variables (`TARGET_ISSUE
 
 Invariants deliberately upheld from this spec:
 
-- **Single-flight per issue and PR convergence** — at most one run works an issue or pull request at a time, enforced by the autowork claim protocol (assign → read-back → earliest-timestamp tiebreak). For **umbrella** issues, single-flight is maintained at the *child-issue* level so slices progress cleanly.
+- **Single-flight per issue and PR convergence** — at most one run works an issue or pull request at a time, enforced by the autowork claim protocol (assign → read-back → earliest-timestamp tiebreak). For **umbrella** issues, single-flight is maintained at the _child-issue_ level so slices progress cleanly.
 - **Recover dead-run claims** — a crashed run's orphaned claim is released back to the pool rather than starving the issue or PR, both opportunistically during candidate selection and periodically via issues housekeeping.
 - **Reader/writer separation** — the routine that authors a PR never merges it; the Peer Review routine is the sole merge authority for **product** PRs. (Operational log-only PRs are exempt; see Log delivery fallback.)
 - **Warm-Context Review Synchronization** — Autowork maintains an active warm session during implementation, polling for Peer Review's verdict. When Peer Review bounces a PR to draft with findings, Autowork immediately detects the draft state in-session, applies fixes directly to its warm working tree, and re-marks the PR ready—re-firing Peer Review for Round N+1 without cold-start overhead.
@@ -36,13 +36,14 @@ Invariants deliberately upheld from this spec:
 
 ## Stale-Claim Definition
 
-Single source of truth for both autowork candidate reclamation and housekeeping sweeps. An assigned issue is a *stale claim* (a dead autowork run's orphaned reservation, safe to release) only when **all** of these hold:
+Single source of truth for both autowork candidate reclamation and housekeeping sweeps. An assigned issue is a _stale claim_ (a dead autowork run's orphaned reservation, safe to release) only when **all** of these hold:
 
 1. **It is an autowork claim, not a manual one.** The issue carries a `🔒 Claimed by autowork run …` comment. An assigned issue with **no** such comment is never stale; leave it alone (it may be a person working manually).
 2. **No live work exists.** There is **no open PR** referencing the issue (`Closes #N`). An open PR is live, recoverable work that autowork Phase 1 owns — never reclaim it, at any age.
 3. **The claim is old.** The most recent `🔒 Claimed by autowork run …` comment's GitHub creation time (`created_at`) is **more than 6 hours** ago. Measure age from that `created_at` only — never the issue's `updated_at`.
 
 **Releasing a stale claim is a destructive write and MUST be guarded:**
+
 - **Re-read immediately before writing.** Re-read the issue (`issue_read`) right before the unassign and re-confirm conditions 1–3 still hold. If any no longer holds, abort the release and move on.
 - **Remove only the named dead owner.** Unassign that specific login; never blindly clear all assignees.
 
@@ -50,7 +51,7 @@ Single source of truth for both autowork candidate reclamation and housekeeping
 
 ## PR Stale-Claim Definition (Phase 1 Convergence)
 
-Single source of truth for Autowork Phase 1 pull request convergence. An assigned pull request or draft PR with unaddressed review comments is a *stale claim* (safe to reclaim and reassign by another runner) only when **all** of these hold:
+Single source of truth for Autowork Phase 1 pull request convergence. An assigned pull request or draft PR with unaddressed review comments is a _stale claim_ (safe to reclaim and reassign by another runner) only when **all** of these hold:
 
 1. **It carries an autowork claim comment**: The PR thread contains `🔒 Addressing review findings by autowork run …` or `🔒 Addressing review findings by local autowork session …`.
 2. **The claim is old**: The most recent claim comment's `created_at` is **more than 2 hours** ago. (2 hours instead of 6 hours because PR review convergence is a rapid turnaround loop).
@@ -66,15 +67,15 @@ Single source of truth for Autowork Phase 1 pull request convergence. An assigne
 2. **Content match** — compare the task against the routine table below. When matching an interactive request from a human, name the matched routine and confirm before proceeding.
 3. **No match** — follow the general Working Practices, PR Workflow, and documentation rules with no routine-specific constraints.
 
-| Routine | File | Applies when the conversation is about... |
-|---|---|---|
-| Autowork | `.github/prompts/autowork.md` | Converging on open work: addressing PR review comments, closing issues whose PRs merged, then claiming and implementing the highest-priority unclaimed issue |
-| Peer Review | `.github/prompts/peer-review.md` | Reviewing a pull request (a named PR or scan mode) and merging it or leaving findings and bouncing to draft |
-| Prompt Optimizer | `.github/prompts/optimizer.md` | Diagnosing failures, inefficiency, token anomalies, and analyzing resolved bugs to propose prompt/test/workflow fixes and upstream contributions |
-| 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 |
+| Routine                            | File                                                  | Applies when the conversation is about...                                                                                                                    |
+| ---------------------------------- | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| Autowork                           | `.github/prompts/autowork.md`                         | Converging on open work: addressing PR review comments, closing issues whose PRs merged, then claiming and implementing the highest-priority unclaimed issue |
+| Peer Review                        | `.github/prompts/peer-review.md`                      | Reviewing a pull request (a named PR or scan mode) and merging it or leaving findings and bouncing to draft                                                  |
+| Prompt Optimizer                   | `.github/prompts/optimizer.md`                        | Diagnosing failures, inefficiency, token anomalies, and analyzing resolved bugs to propose prompt/test/workflow fixes and upstream contributions             |
+| 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  |
 
 ---
 
@@ -108,12 +109,12 @@ The routines invoke specialized engineering skills at key workflow checkpoints:
 ## Log Delivery Fallback
 
 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. Never commit logs to an active feature branch.
 2. **Mandatory `[skip ci]`**: All log commits MUST include `[skip ci]` in the commit message (e.g. `docs(log): record {routine-name} run {timestamp} [skip ci]`) to prevent unnecessary CI executions or approval blocks.
 3. **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.
 4. **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
@@ -141,13 +142,14 @@ How external and human contributor pull requests are reconciled into the issue t
 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.
+3. **Audit & Single-Flight Lineage**: When the PR is squash-merged, `peer-review` explicitly closes the tracking issue (`gh issue close <ISSUE_NUMBER>`) to guarantee tracking closure, even when bot credentials or draft PR states bypass GitHub's native issue auto-close. This maintains 100% issue auditability, project board tracking, telemetry metrics, and release changelogs without leaving stray open issues.
 
 ---
 
 ## 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).
@@ -168,23 +170,27 @@ How the fleet guarantees continuous review throughput, recovers from transient A
 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. Review re-triggering is strictly conditioned on all CI checks having passed (`conclusion: SUCCESS`, `mergeStateStatus: CLEAN`) and is strictly prohibited if checks are in-progress or awaiting approval (`ACTION_REQUIRED`).
 
-
 ---
 
-## Upstream Symphony Intel & Architectural Evaluation Framework
+## Upstream Symphony & Funes 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:
+How changes and innovations from upstream ecosystems—[openai/symphony](https://github.com/openai/symphony) for issue-tracker orchestration and [huggingface/funes](https://github.com/huggingface/funes) for agent memory & session indexing—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.
+1. **Automated Ecosystem 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 across `openai/symphony` (orchestration) and `huggingface/funes` (memory tooling), 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.
+3. **Agent Memory & Session Indexing Evaluation Dimensions (Funes Watch)**:
+   - **Zero-LLM Ingestion**: Deterministic parsing of agent session traces (`.jsonl`/Parquet) into LanceDB without spending LLM tokens from the weekly budget.
+   - **Pull-Based Memory Delivery**: Memory served strictly on demand via MCP (`recall`, `get`) to prevent prompt context bloat.
+   - **Cross-Session Provenance**: Verbatim turns and provenance retention instead of lossy summary drift.
+   - **Multi-Agent Portability**: Standardized trace ingestion across Antigravity CLI (`agy`), Claude Code, and Codex.
+4. **Classification & Action Protocol**:
+   - **🟢 Category A (Adopt Directly)**: Security guardrails, claim lock invariants, reader/writer rules, prompt engineering optimizations, deterministic zero-LLM indexing.
+   - **🟡 Category B (Adapt to Actions/CLI)**: Dynamic orchestrator pacing, backpressure controls, multi-stage review checks, pull-based memory MCP integrations.
+   - **🔴 Category C (Skip)**: Elixir/OTP supervision trees, BEAM memory tuning, proprietary runtime internals, always-loaded memory context dumps.
 
 ---
 
@@ -213,4 +219,3 @@ How agent routines are partitioned between cloud GitHub Actions (24/7 cloud runn
    - Local agent PR convergence claims post: `🔒 Addressing review findings by local autowork session (host: <hostname>) <timestamp>`.
    - Local processes trap `SIGINT`/`SIGTERM` to unassign claims and remove worktrees cleanly on exit.
    - Standard stale-claim rules (6h for issues, 2h for PRs) safely reclaim orphaned local claims if a machine powers down unexpectedly.
-

package/templates/prompts/autowork.md

@@ -2,20 +2,20 @@
 
 ## Objective
 
-This routine runs in two modes, decided in Step 0. In **Scan mode** (a scheduled run, no issue named): converge on existing open work before starting anything new — priority order (1) address review comments on open PRs, (2) close issues whose PRs are merged, (3) only then pick a new issue. In **Targeted mode** (fired with a specific issue in the payload): work *that* issue as the run's objective, **ahead of** the convergence steps above — the fire exists to start its issue immediately, so an unrelated pending PR does not preempt it (Step 0.5); fall back to the Scan flow only if the target is ineligible. Either way, at most one issue may be **implemented** (code written, branch pushed) per run — the sole exception is batching up to 3 same-recipe slices of a single *umbrella* issue into one child issue + PR (step 12a); that batch is still one concern, not a second issue. Evaluating a candidate and finding it infeasible does not count as "working" it: in Scan mode, step 12's infeasible-continuation cap lets a run evaluate up to 3 candidates for feasibility before it must stop, so a single blocked issue can't consume an entire run without any other progress being attempted.
+This routine runs in two modes, decided in Step 0. In **Scan mode** (a scheduled run, no issue named): converge on existing open work before starting anything new — priority order (1) address review comments on open PRs, (2) close issues whose PRs are merged, (3) only then pick a new issue. In **Targeted mode** (fired with a specific issue in the payload): work _that_ issue as the run's objective, **ahead of** the convergence steps above — the fire exists to start its issue immediately, so an unrelated pending PR does not preempt it (Step 0.5); fall back to the Scan flow only if the target is ineligible. Either way, at most one issue may be **implemented** (code written, branch pushed) per run — the sole exception is batching up to 3 same-recipe slices of a single _umbrella_ issue into one child issue + PR (step 12a); that batch is still one concern, not a second issue. Evaluating a candidate and finding it infeasible does not count as "working" it: in Scan mode, step 12's infeasible-continuation cap lets a run evaluate up to 3 candidates for feasibility before it must stop, so a single blocked issue can't consume an entire run without any other progress being attempted.
 
 ## Definition of Done
 
-This routine runs in two modes (Step 0): **Targeted** (a fire named an issue) and **Scan** (scheduled / no issue named). In **Targeted mode**, the run is SUCCESS if you claimed and implemented the target issue to a pushed draft PR (or documented why it is infeasible and released the claim, or ended via step 13's **collision bail** — a competing open PR discovered immediately before opening yours: branch pushed, claim comment annotated, no unassign, no second PR) — or, when the target was *ineligible* (closed / has an open PR / claimed by a live run), you fell back to the Scan flow and met the Scan criteria below.
+This routine runs in two modes (Step 0): **Targeted** (a fire named an issue) and **Scan** (scheduled / no issue named). In **Targeted mode**, the run is SUCCESS if you claimed and implemented the target issue to a pushed draft PR (or documented why it is infeasible and released the claim, or ended via step 13's **collision bail** — a competing open PR discovered immediately before opening yours: branch pushed, claim comment annotated, no unassign, no second PR) — or, when the target was _ineligible_ (closed / has an open PR / claimed by a live run), you fell back to the Scan flow and met the Scan criteria below.
 
 In **Scan mode**, the run is SUCCESS only if ALL of these are true:
 
 - [ ] Checked all open PRs for unresolved or unaddressed review comments; if actionable findings were found, claimed the PR before writing fixes (see the Phase 1 PR Claim protocol), confirmed sole ownership, and pushed fixes
 - [ ] Closed any issues whose corresponding PRs are all merged
-- [ ] If no open PRs needed attention: picked the highest-priority *unclaimed* issue (P1 > P2 > P3); if it turned out to be already-done (step 10 — all its PRs merged), closed it and moved on to the next-priority candidate rather than stopping there; otherwise **claimed it before starting work** (see the Claim protocol), and either implemented a fix and **opened a draft pull request on GitHub via `gh pr create --draft`** or left a comment explaining why autonomous completion is blocked and released the claim, then repeated candidate selection for the next-priority issue per step 12's infeasible-continuation cap
+- [ ] If no open PRs needed attention: picked the highest-priority _unclaimed_ issue (P1 > P2 > P3); if it turned out to be already-done (step 10 — all its PRs merged), closed it and moved on to the next-priority candidate rather than stopping there; otherwise **claimed it before starting work** (see the Claim protocol), and either implemented a fix and **opened a draft pull request on GitHub via `gh pr create --draft`** or left a comment explaining why autonomous completion is blocked and released the claim, then repeated candidate selection for the next-priority issue per step 12's infeasible-continuation cap
 - [ ] If an issue was implemented: successfully opened a draft pull request on GitHub via `gh pr create --draft` referencing the issue (`Closes #N`) in its body, verified the PR exists (a returned PR URL is mandatory), updated the issue's `## Tasks` checkboxes (`- [ ]` → `- [x]`) for every deliverable the PR ships, marked the PR ready for review (`gh pr ready <PR>`), and executed step 15's in-session review wait (never stop at merely pushing the branch or editing the issue; a pushed branch with no open PR on GitHub is a fatal invariant violation and must be logged as FAILURE)
-- [ ] Did not open a new PR while any existing PR by this routine has unaddressed review comments (a finding you have replied to with a rationale counts as *addressed*, even if the thread is still technically unresolved) — **Targeted mode is exempt**
-- [ ] Never worked an issue or PR that was already actively claimed (assigned) by another live run, and confirmed sole ownership of the claim before writing any code — reclaiming a *stale* claim (a dead run's orphaned assignment, per step 10a / `ORCHESTRATION.md`) is permitted
+- [ ] Did not open a new PR while any existing PR by this routine has unaddressed review comments (a finding you have replied to with a rationale counts as _addressed_, even if the thread is still technically unresolved) — **Targeted mode is exempt**
+- [ ] Never worked an issue or PR that was already actively claimed (assigned) by another live run, and confirmed sole ownership of the claim before writing any code — reclaiming a _stale_ claim (a dead run's orphaned assignment, per step 10a / `ORCHESTRATION.md`) is permitted
 - [ ] If work was an umbrella slice/batch (step 12a): the child issue created for it carries the required Summary/Tasks/Why/Complexity template and exactly one type/size/priority label, and the `🧭 Decomposition plan` markers were left `🔍 in review` until the child PR merges
 
 If any criterion cannot be met, stop immediately and log FAILURE with the reason.
@@ -33,12 +33,12 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 ## Negative examples (DO NOT do these)
 
 - Do not address a subset of review findings and stop — handle ALL findings in one run before stopping or marking the PR as ready.
-- Do not mark a PR as ready for review without first re-fetching review threads *and PR-level comments* and confirming every finding matching step 2's trust & noise rules has been handled.
+- Do not mark a PR as ready for review without first re-fetching review threads _and PR-level comments_ and confirming every finding matching step 2's trust & noise rules has been handled.
 - Do not start addressing review findings on a PR before claiming it (both PR assignment AND claim comment).
 - Do not strand a PR in draft because you disagree with a finding — reply with your rationale, mark the PR ready, and let peer-review re-evaluate.
 - Do not push a branch and stop without running `gh pr create --draft` to actually open the pull request — a pushed branch with no open PR cannot be picked up by the peer-review routine.
 - Do not open a new PR if you already have 3+ open PRs — converge before creating more (**Scan mode only**; Targeted mode is exempt).
-- Do not *implement* multiple *unrelated* issues in a single run.
+- Do not _implement_ multiple _unrelated_ issues in a single run.
 - Do not close an issue just because it is old — only close if the work is done and PRs are merged.
 - 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).
@@ -51,23 +51,26 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 ### Step 0: Determine Targeted vs Scan mode (before Phase 1)
 
 This routine runs in two modes, decided here before any other work:
-- **Targeted mode** — an environment variable `$ISSUE_NUMBER` (or explicit issue payload) names a target issue. Work *that* issue as the run's objective, **ahead of** Phase 1 convergence and the normal priority scan.
+
+- **Targeted mode** — an environment variable `$ISSUE_NUMBER` (or explicit issue payload) names a target issue. Work _that_ issue as the run's objective, **ahead of** Phase 1 convergence and the normal priority scan.
 - **Scan mode** — no issue is named (a scheduled cron run). Run Phase 1, then select an issue by priority in Phase 2.
 
 Check if `$ISSUE_NUMBER` environment variable is set (or scan invocation text for `#<number>` / `/issues/<number>`):
+
 - **Found one → Targeted mode.** Record it as this run's target issue and proceed to Step 0.5.
 - **None found → Scan mode.** Proceed as a scheduled run: Phase 1, then normal priority selection in Phase 2.
 
 ### 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`), 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).
+
+- **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).
 
 ### Phase 1: Converge on open work (Scan mode; skipped in Targeted mode)
 
 1. List all open PRs authored by this routine.
-1a. **PR Claim Protocol (Single-Flight PR Convergence)**:
+   1a. **PR Claim Protocol (Single-Flight PR Convergence)**:
    - For each open PR needing attention (bounced to draft with actionable findings, or open with unaddressed review comments):
    - **Check eligibility**: re-read candidate PR (`gh pr view <PR> --json assignees,comments`). Skip PRs currently assigned to another live runner or carrying an active claim comment posted within the last 2 hours (unless stale claim per `ORCHESTRATION.md`).
    - Call `get_me` once to learn your own login if not already known.
@@ -77,7 +80,7 @@ b. **Eligible → claim, then implement.** Call `get_me` once to learn your own
    - **Confirm sole ownership**: fetch comments on the PR. Earliest `created_at` among competing claim comments in this round wins. If you lost the race, unassign yourself (`gh pr edit <PR> --remove-assignee <login>`), annotate your comment, and evaluate the next PR (or proceed to Phase 2 if none left).
 2. For the claimed PR, fetch ALL review threads and PR-level comments. Filter for actionable findings matching trust & noise rules (author login matching `get_me`, non-noise). Address every single one in this run — push fixes for actionable findings, reply to clarifying questions, and comment on deferred items.
 3. For PRs where you have addressed all findings:
-3a. **Pre-ready self-audit** (run before marking ready):
+   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).
@@ -85,12 +88,17 @@ b. **Eligible → claim, then implement.** Call `get_me` once to learn your own
    - **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.
    - **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.
-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>`).
+     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>`).
    - **Passing CI Verification Gate**: Verify via `gh pr view <PR> --json statusCheckRollup,mergeStateStatus` that all required and existing checks have completed with `conclusion: "SUCCESS"` and `mergeStateStatus` is `CLEAN` (neither `UNSTABLE`, `BLOCKED`, nor `DIRTY`).
    - **Unapproved/Pending Workflow Invariant**: NEVER post `/review` or toggle draft state if checks are in-progress, failing, or awaiting approval (`conclusion: "ACTION_REQUIRED"`). Doing so creates an infinite comment storm while workflows remain paused awaiting human permissions.
-4. Check open issues that have linked merged PRs — close them.
+4. **Check open issues with merged PRs / work done — close them**:
+   - For open issues, check if recent git history or merged PRs reference the issue (e.g. `git log -n 50 --grep="#<ISSUE_NUMBER>"` or `gh pr list --state merged --search "<ISSUE_NUMBER>" --limit 5`).
+   - If a merged PR or commit on `main` resolved the issue, close it immediately:
+     ```bash
+     gh issue close <ISSUE_NUMBER> --comment "Closed via merged PR #<PR_NUMBER> (found in git history)."
+     ```
 
 5. If any PR was updated in this phase, STOP — run is SUCCESS.
 
@@ -107,14 +115,14 @@ b. **Eligible → claim, then implement.** Call `get_me` once to learn your own
      - 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`, `needs-design`, or `needs-info`, 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.
+10. If the candidate should be closed already (work done, merged PR found in git history or via `gh pr list --state merged --search "<ISSUE_NUMBER>"`), close it immediately (`gh issue close <ISSUE_NUMBER> --comment "Closed: work already merged in PR #<PR_NUMBER>."`) 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:
-       - 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.
+    - 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.
@@ -127,7 +135,7 @@ b. **Eligible → claim, then implement.** Call `get_me` once to learn your own
       - Select the next candidate (evaluating ambiguous issues counts toward step 12's infeasible-continuation cap).
     - **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:
+      12a. **Umbrella-issue handoff + batching:** If candidate is an umbrella epic:
     - 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.
@@ -139,6 +147,7 @@ b. **Eligible → claim, then implement.** Call `get_me` once to learn your own
     - 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.
+    - **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>`).
 14. If run aborts before opening PR, release claim (unassign).
@@ -151,12 +160,14 @@ b. **Eligible → claim, then implement.** Call `get_me` once to learn your own
 ## 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:
+
 - 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**:
+
 - **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/**`:
@@ -168,4 +179,3 @@ After completing (SUCCESS or FAILURE), write a log file to `.github/prompts/logs
   git push origin main
   ```
   Follow the Log delivery fallback in `ORCHESTRATION.md` if direct push fails.
-

package/templates/prompts/issues-housekeeping.md

@@ -39,7 +39,7 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 3. **Priority review**: Check open P1/P2/P3 issues. Promote critical bugs or unblocked items; demote items that lack immediate priority.
 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.
+6. **Label audit & safe prune**: Ensure open issues carry standard role labels (`needs-triage`, `ready-for-agent`, `needs-human`, etc.). Use `/triage` if classifying incoming issues. Run `npx --yes jonah-fleet labels prune --yes` (or `jonah-fleet labels prune --yes`) to safely prune strictly unused boilerplate labels (`issues: 0`, `pullRequests: 0`, non-protected taxonomy) without deleting historical or fleet taxonomy labels.
 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

package/templates/prompts/peer-review.md

@@ -8,7 +8,7 @@ Review a pull request (in Targeted mode for a specific `$PR_NUMBER`, or in Scan
 
 Before reading further, before any tool call, and before deciding the mode, check the environment variable `$PR_NUMBER`.
 
-- **$PR_NUMBER is set → Targeted mode.** The value of `$PR_NUMBER` is your target PR. You may also check `$PR_URL`. Skip all selection logic.
+- **$PR_NUMBER is set → Targeted mode.** The value of `$PR_NUMBER`is your target PR. You may also check`$PR_URL`. Skip all selection logic.
 - **$PR_NUMBER is not set → Scan mode.** Only then select a PR by priority.
 
 **Targeted mode is sticky: it can never fall back to Scan mode.** Once the invocation contains a PR reference, you must review exactly that PR. If you cannot act on it (closed/merged/missing), STOP and log FAILURE.
@@ -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; 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
+- [ ] Took exactly one final action: squash-merged (if PR is good, CI green and present; executed Autonomous Issue Synthesis if unlinked; closed tracking issue explicitly if referenced) 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,9 @@ 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. 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.
+  - Sequence: (1) if unlinked, synthesize tracking issue (`gh issue create`) and link to PR (`gh pr edit`), (2) squash-merge (`gh pr merge <N> --squash --delete-branch`), (3) explicitly close tracking issue if referenced (`gh issue close <ISSUE_NUMBER>`), (4) submit held review comments, (5) 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):
@@ -63,6 +64,7 @@ Every review ends in exactly one of two states:
 ### Step 0: Determine the target PR (do this FIRST)
 
 Check if `$PR_NUMBER` is set:
+
 - **$PR_NUMBER is set → Targeted mode.** Review that exact PR. Skip selection steps 1–2.
 - **$PR_NUMBER is not set → Scan mode.** Proceed to steps 1–2.
 
@@ -98,12 +100,14 @@ Check if `$PR_NUMBER` is set:
 ### Step 5: Classify Findings & Make Decision
 
 Classify each finding:
+
 - **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_"
@@ -121,7 +125,12 @@ If the PR is clean and approved for merge, but lacks a `Closes #N` tracking link
   - 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).
+  - 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`.
+  - **Explicit Tracking Issue Closure Guardrail**: If a tracking issue was referenced (`$ISSUE_NUMBER`), explicitly close it immediately after merge rather than relying solely on GitHub's native keyword parser (which often fails to trigger on bot-merged squash commits or draft PRs):
+    ```bash
+    gh issue close "$ISSUE_NUMBER" --comment "Closed via PR #<N> (merged into main)."
+    ```
   - Submit held review comments.
   - File follow-up issues for material non-blocking findings.
   - If mechanical doc fixes are needed, commit directly to `main`.
@@ -129,6 +138,7 @@ If the PR is clean and approved for merge, but lacks a `Closes #N` tracking link
 ## 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:
+
 - Prompt SHA
 - Target PR number and decision (MERGE / BOUNCE / ESCALATE)
 - Execution trace and findings summary

package/templates/workflows/autowork-cron.yml

@@ -105,6 +105,45 @@ jobs:
           fi
           echo "skills_prompt=$SKILLS_PROMPT" >> "$GITHUB_OUTPUT"
 
+      - name: Resolve routine configuration
+        id: routine-config
+        run: |
+          ROUTINE="autowork"
+          DEFAULT_MODEL="gemini-3.7-flash-high"
+          DEFAULT_TIMEOUT="60"
+
+          MODEL="$DEFAULT_MODEL"
+          TIMEOUT="$DEFAULT_TIMEOUT"
+
+          if [ -f "agents-manifest.json" ]; then
+            CONFIG_JSON=$(node -e '
+              try {
+                const fs = require("fs");
+                const m = JSON.parse(fs.readFileSync("agents-manifest.json", "utf8"));
+                const r = process.argv[1];
+                const model = m.models?.[r] || m.models?.default;
+                const timeout = m.budgets?.timeoutMinutes?.[r] || m.budgets?.timeoutMinutes?.default;
+                console.log(JSON.stringify({ model: model || "", timeout: timeout ? String(timeout) : "" }));
+              } catch (e) {
+                console.log(JSON.stringify({ model: "", timeout: "" }));
+              }
+            ' "$ROUTINE")
+
+            RESOLVED_MODEL=$(node -e "try { console.log(JSON.parse(process.argv[1]).model || ''); } catch {}" "$CONFIG_JSON")
+            RESOLVED_TIMEOUT=$(node -e "try { console.log(JSON.parse(process.argv[1]).timeout || ''); } catch {}" "$CONFIG_JSON")
+
+            if [ -n "$RESOLVED_MODEL" ]; then
+              MODEL="$RESOLVED_MODEL"
+            fi
+            if [ -n "$RESOLVED_TIMEOUT" ]; then
+              TIMEOUT="$RESOLVED_TIMEOUT"
+            fi
+          fi
+
+          echo "model=$MODEL" >> "$GITHUB_OUTPUT"
+          echo "print_timeout=${TIMEOUT}m" >> "$GITHUB_OUTPUT"
+          echo "Resolved routine configuration: model=$MODEL, timeout=${TIMEOUT}m"
+
       - name: Run Autowork
         timeout-minutes: 60
         env:
@@ -125,9 +164,9 @@ jobs:
           fi
 
           agy -p "$PROMPT" \
-            --model gemini-3.7-flash-high \
+            --model "${{ steps.routine-config.outputs.model || 'gemini-3.7-flash-high' }}" \
             --output-format text \
-            --print-timeout 60m \
+            --print-timeout "${{ steps.routine-config.outputs.print_timeout || '60m' }}" \
             --dangerously-skip-permissions
 
       - name: Emit run summary

package/templates/workflows/dependency-check-cron.yml

@@ -65,6 +65,45 @@ jobs:
           printf '%s' "$ANTIGRAVITY_OAUTH_TOKEN" > "$HOME/.gemini/antigravity-cli/antigravity-oauth-token"
           chmod 600 "$HOME/.gemini/antigravity-cli/antigravity-oauth-token"
 
+      - name: Resolve routine configuration
+        id: routine-config
+        run: |
+          ROUTINE="dependency-update-security-check"
+          DEFAULT_MODEL="gemini-3.7-flash"
+          DEFAULT_TIMEOUT="25"
+
+          MODEL="$DEFAULT_MODEL"
+          TIMEOUT="$DEFAULT_TIMEOUT"
+
+          if [ -f "agents-manifest.json" ]; then
+            CONFIG_JSON=$(node -e '
+              try {
+                const fs = require("fs");
+                const m = JSON.parse(fs.readFileSync("agents-manifest.json", "utf8"));
+                const r = process.argv[1];
+                const model = m.models?.[r] || m.models?.default;
+                const timeout = m.budgets?.timeoutMinutes?.[r] || m.budgets?.timeoutMinutes?.default;
+                console.log(JSON.stringify({ model: model || "", timeout: timeout ? String(timeout) : "" }));
+              } catch (e) {
+                console.log(JSON.stringify({ model: "", timeout: "" }));
+              }
+            ' "$ROUTINE")
+
+            RESOLVED_MODEL=$(node -e "try { console.log(JSON.parse(process.argv[1]).model || ''); } catch {}" "$CONFIG_JSON")
+            RESOLVED_TIMEOUT=$(node -e "try { console.log(JSON.parse(process.argv[1]).timeout || ''); } catch {}" "$CONFIG_JSON")
+
+            if [ -n "$RESOLVED_MODEL" ]; then
+              MODEL="$RESOLVED_MODEL"
+            fi
+            if [ -n "$RESOLVED_TIMEOUT" ]; then
+              TIMEOUT="$RESOLVED_TIMEOUT"
+            fi
+          fi
+
+          echo "model=$MODEL" >> "$GITHUB_OUTPUT"
+          echo "print_timeout=${TIMEOUT}m" >> "$GITHUB_OUTPUT"
+          echo "Resolved routine configuration: model=$MODEL, timeout=${TIMEOUT}m"
+
       - name: Run Dependency Update Check
         timeout-minutes: 25
         env:
@@ -79,7 +118,7 @@ jobs:
           PROMPT="You are the Dependency Update & Security Check routine. Read and follow .github/prompts/dependency-update-security-check.md exactly. Check dependencies for updates and vulnerabilities, and create or update tracking issues."
 
           agy -p "$PROMPT" \
-            --model gemini-3.7-flash-high \
+            --model "${{ steps.routine-config.outputs.model || 'gemini-3.7-flash' }}" \
             --output-format text \
-            --print-timeout 25m \
+            --print-timeout "${{ steps.routine-config.outputs.print_timeout || '25m' }}" \
             --dangerously-skip-permissions

package/templates/workflows/issues-housekeeping-cron.yml

@@ -65,6 +65,45 @@ jobs:
           printf '%s' "$ANTIGRAVITY_OAUTH_TOKEN" > "$HOME/.gemini/antigravity-cli/antigravity-oauth-token"
           chmod 600 "$HOME/.gemini/antigravity-cli/antigravity-oauth-token"
 
+      - name: Resolve routine configuration
+        id: routine-config
+        run: |
+          ROUTINE="issues-housekeeping"
+          DEFAULT_MODEL="gemini-3.7-flash"
+          DEFAULT_TIMEOUT="40"
+
+          MODEL="$DEFAULT_MODEL"
+          TIMEOUT="$DEFAULT_TIMEOUT"
+
+          if [ -f "agents-manifest.json" ]; then
+            CONFIG_JSON=$(node -e '
+              try {
+                const fs = require("fs");
+                const m = JSON.parse(fs.readFileSync("agents-manifest.json", "utf8"));
+                const r = process.argv[1];
+                const model = m.models?.[r] || m.models?.default;
+                const timeout = m.budgets?.timeoutMinutes?.[r] || m.budgets?.timeoutMinutes?.default;
+                console.log(JSON.stringify({ model: model || "", timeout: timeout ? String(timeout) : "" }));
+              } catch (e) {
+                console.log(JSON.stringify({ model: "", timeout: "" }));
+              }
+            ' "$ROUTINE")
+
+            RESOLVED_MODEL=$(node -e "try { console.log(JSON.parse(process.argv[1]).model || ''); } catch {}" "$CONFIG_JSON")
+            RESOLVED_TIMEOUT=$(node -e "try { console.log(JSON.parse(process.argv[1]).timeout || ''); } catch {}" "$CONFIG_JSON")
+
+            if [ -n "$RESOLVED_MODEL" ]; then
+              MODEL="$RESOLVED_MODEL"
+            fi
+            if [ -n "$RESOLVED_TIMEOUT" ]; then
+              TIMEOUT="$RESOLVED_TIMEOUT"
+            fi
+          fi
+
+          echo "model=$MODEL" >> "$GITHUB_OUTPUT"
+          echo "print_timeout=${TIMEOUT}m" >> "$GITHUB_OUTPUT"
+          echo "Resolved routine configuration: model=$MODEL, timeout=${TIMEOUT}m"
+
       - name: Run Issues Housekeeping
         timeout-minutes: 40
         env:
@@ -79,7 +118,7 @@ jobs:
           PROMPT="You are the Issues Housekeeping routine for this repository. Read and follow .github/prompts/issues-housekeeping.md exactly. Sweep open issues for staleness, duplicates, priority accuracy, and orphaned claims."
 
           agy -p "$PROMPT" \
-            --model gemini-3.7-flash-high \
+            --model "${{ steps.routine-config.outputs.model || 'gemini-3.7-flash' }}" \
             --output-format text \
-            --print-timeout 40m \
+            --print-timeout "${{ steps.routine-config.outputs.print_timeout || '40m' }}" \
             --dangerously-skip-permissions