jonah-fleet 1.6.0 → 1.9.0

package/schema.json

@@ -26,7 +26,8 @@
         "issues-housekeeping": { "type": "boolean" },
         "dependency-update-security-check": { "type": "boolean" },
         "product-planning": { "type": "boolean" },
-        "analytics-review": { "type": "boolean" }
+        "analytics-review": { "type": "boolean" },
+        "design-review": { "type": "boolean" }
       },
       "additionalProperties": false,
       "description": "Granular routine toggles"
@@ -36,6 +37,65 @@
       "items": { "type": "string" },
       "description": "List of core engineering skills to install/sync"
     },
+    "models": {
+      "type": "object",
+      "properties": {
+        "default": { "type": "string", "description": "Default model used across routines" },
+        "autowork": { "type": "string", "description": "Target model for autowork routine" },
+        "peer-review": { "type": "string", "description": "Target model for peer-review routine" },
+        "optimizer": { "type": "string", "description": "Target model for optimizer routine" },
+        "issues-housekeeping": { "type": "string", "description": "Target model for issues-housekeeping routine" },
+        "dependency-update-security-check": { "type": "string", "description": "Target model for dependency-update-security-check routine" },
+        "product-planning": { "type": "string", "description": "Target model for product-planning routine" },
+        "analytics-review": { "type": "string", "description": "Target model for analytics-review routine" },
+        "design-review": { "type": "string", "description": "Target model for design-review routine" }
+      },
+      "additionalProperties": { "type": "string" },
+      "description": "Per-routine model overrides (e.g. gemini-3.8-flash-high, gemini-3.8-flash-medium)"
+    },
+    "budgets": {
+      "type": "object",
+      "properties": {
+        "weeklyTokens": {
+          "type": "number",
+          "description": "Weekly token budget limit across routines"
+        },
+        "maxIterations": {
+          "type": "object",
+          "properties": {
+            "default": { "type": "number" },
+            "autowork": { "type": "number" },
+            "peer-review": { "type": "number" },
+            "optimizer": { "type": "number" },
+            "issues-housekeeping": { "type": "number" },
+            "dependency-update-security-check": { "type": "number" },
+            "product-planning": { "type": "number" },
+            "analytics-review": { "type": "number" },
+            "design-review": { "type": "number" }
+          },
+          "additionalProperties": { "type": "number" },
+          "description": "Maximum tool call iterations per routine"
+        },
+        "timeoutMinutes": {
+          "type": "object",
+          "properties": {
+            "default": { "type": "number" },
+            "autowork": { "type": "number" },
+            "peer-review": { "type": "number" },
+            "optimizer": { "type": "number" },
+            "issues-housekeeping": { "type": "number" },
+            "dependency-update-security-check": { "type": "number" },
+            "product-planning": { "type": "number" },
+            "analytics-review": { "type": "number" },
+            "design-review": { "type": "number" }
+          },
+          "additionalProperties": { "type": "number" },
+          "description": "Workflow runner timeout in minutes per routine"
+        }
+      },
+      "additionalProperties": false,
+      "description": "Per-routine token, iteration, and timeout budgets"
+    },
     "schedules": {
       "type": "object",
       "properties": {
@@ -45,6 +105,7 @@
         "issues-housekeeping": { "type": "string", "description": "Custom cron schedule for issues housekeeping" },
         "dependency-update-security-check": { "type": "string", "description": "Custom cron schedule for dependency security checks" },
         "analytics-review": { "type": "string", "description": "Custom cron schedule for analytics review" },
+        "design-review": { "type": "string", "description": "Custom cron schedule for design review" },
         "sync-fleet": { "type": "string", "description": "Custom cron schedule for fleet sync" }
       },
       "additionalProperties": { "type": "string" },
@@ -90,6 +151,18 @@
       },
       "additionalProperties": false,
       "description": "Configuration for priority-driven dual local/cloud agent execution"
+    },
+    "labels": {
+      "type": "object",
+      "properties": {
+        "protected": {
+          "type": "array",
+          "items": { "type": "string" },
+          "description": "User-defined list or wildcard patterns of protected labels retained during label pruning"
+        }
+      },
+      "additionalProperties": false,
+      "description": "Configuration for label management and protection shields"
     }
   },
   "required": ["version", "preset", "routines", "skills"],

package/templates/prompts/ORCHESTRATION.md

@@ -6,17 +6,17 @@ 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`).
+
+- **Scheduled cron sweeps**: Autowork runs periodically (`autowork-cron.yml`), complemented by prompt optimization (`prompt-optimizer-cron.yml`), issues housekeeping (`issues-housekeeping-cron.yml`), dependency security checks (`dependency-check-cron.yml`), analytics review (`analytics-review-cron.yml`), product planning (`product-planning-cron.yml`), and design review (`design-review-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.
   - `trigger-autowork-on-merge.yml` fires Autowork in **Targeted mode** when a PR merges to `main` and unblocks the next unit of chained work.
@@ -27,22 +27,23 @@ 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.)
+- **Reader/writer separation** — the routine that authors a PR never merges it; the Peer Review routine is the sole merge authority for pull requests.
 - **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.
 
 ---
 
 ## 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,16 @@ 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  |
+| Design Review                      | `.github/prompts/design-review.md`                    | Auditing player-facing surfaces for design system token deviations, visual clutter, feature pruning, and UX improvements                                      |
 
 ---
 
@@ -102,17 +104,54 @@ The routines invoke specialized engineering skills at key workflow checkpoints:
   - `/to-tickets`: Decomposes approved epics/proposals into dependency-linked issues.
 - **Prompt Optimizer (`optimizer.md`)**:
   - `/writing-for-agents`: Drafts crisp, token-efficient prompt and rule updates.
+- **Design Review (`design-review.md`)**:
+  - `/design-system`: Analyzes styling diffs and static components for token purity and pattern alignment.
+  - `/run`: Boots dev environment and automates mobile/desktop viewport captures.
+  - `/design-critique`: Analyzes captured screenshots for visual hierarchy, clutter, spacing, and contrast.
 
 ---
 
-## 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.
-
+## Routine Issue Logging & Telemetry Protocol
+
+Single source of truth for every routine's logging and telemetry lifecycle:
+
+1. **GitHub Issues as Operational Ledger**: Routine run logs are recorded as GitHub Issues instead of git commits, keeping `main` and Git history 100% clean. No operational markdown files are committed to Git, eliminating push conflicts, merge races, and draft-PR fallbacks.
+2. **Two-Phase Issue Lifecycle**:
+   - **Start**: The workflow harness or local runner pre-step creates a tracking issue via `gh issue create` titled `[routine-name] run {timestamp}` with labels `routine-log`, `routine:{name}`, `status:running`, and `runner:{github-actions|local}`. The issue number is exported as `ROUTINE_ISSUE_NUMBER`.
+   - **Execution**: The agent performs the routine and records its structured execution report (Definition of Done table, telemetry metrics, execution trace) to `.jonah-fleet/run-report.md`.
+   - **Finish**: The harness post-step reconciles the tracking issue body:
+     - On **SUCCESS**: Applies label `status:success`, removes `status:running`, and closes the issue immediately via `gh issue close $ROUTINE_ISSUE_NUMBER --reason completed`.
+     - On **FAILURE / CRASH / TIMEOUT**: Applies labels `status:failure`, `needs-attention`, removes `status:running`, and leaves the issue **OPEN** in the issue tracker for human maintainer triage and optimizer diagnosis.
+3. **Local Daemon Parity & Offline Fallback**: `jonah-fleet daemon` and `jonah-fleet run` always record runs locally in `.jonah-fleet/runs/{timestamp}.json` (ignored by git). When online with valid `gh` auth, local daemons create and close tracking issues labeled `runner:local`. If offline or unauthenticated, runs gracefully fall back to local-only logging without interrupting agent execution.
+4. **Issue Backlog Isolation**: Routine run issues carry `label:routine-log`. Human maintainers and product queries filter `-label:routine-log` in issue searches to keep product backlogs pristine.
+
+### Routine Issue Progress Reporting & Milestone Protocol
+
+How live execution progress is reported during autonomous routine runs:
+
+1. **Comment Stream for Live Telemetry**: Rather than leaving tracking issues static until completion, routines emit structured milestone comments into the thread of `$ROUTINE_ISSUE_NUMBER`. This gives maintainers real-time visibility into agent decisions and progress with GitHub timestamps without needing to inspect raw Actions logs.
+2. **Issue Isolation Invariant (Negative Rule)**: Milestone comments are posted exclusively to the routine tracking issue (`gh issue comment "$ROUTINE_ISSUE_NUMBER"`). Agents MUST NEVER post progress telemetry comments to target product issues or pull requests (except for required PR linkage and review comments).
+3. **Compact Milestone Cards (5-Point Schema)**: Every milestone comment follows this standard structure:
+   ```markdown
+   ### <Emoji> Milestone: <Milestone Name>
+   - **Phase**: `<Phase Identifier>`
+   - **Status**: <Status Emoji + Summary>
+   - **Target / Context**: `<Target Issue/PR or Context>`
+   - **Key Decision / Finding**: <Summary of key decision, root cause, or verification outcome>
+   - **Next**: <Next planned milestone>
+   ```
+4. **Bounded 4-Stage Milestone Cadence**: Routines enforce strictly 3–4 bounded milestones per flight:
+   - **Milestone 1 (Intake & Strategy)**: Target claimed, scope clarified, initial strategy/reproduction plan established.
+   - **Milestone 2 (Verification & Tests)**: Implementation complete, unit/integration tests passing, lint clean.
+   - **Milestone 3 (Autonomous Handoff)**: Branch pushed, PR opened with link, or review decision submitted.
+   - **Milestone 4 (Run Completed)**: Final compact status closing out the comment stream.
+5. **Soft Failure & Offline Tolerance**: All milestone commands use `|| true`:
+   ```bash
+   gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "..." || true
+   ```
+   If offline, unauthenticated, or rate-limited, agent execution continues uninterrupted.
+6. **Harness Interruption Card**: If a routine run fails, times out, or crashes abruptly before Milestone 4, the workflow harness or local runner post-step automatically appends an Interruption Card (`### ❌ Milestone: Run Interrupted / Failed`) before marking `status:failure`.
+7. **Final State Reconciliation**: The final comment is Milestone 4 (Compact completion card). The workflow harness replaces the top-level issue body with the comprehensive telemetry & audit report (`.jonah-fleet/run-report.md`) and closes the issue on success.
 
 ---
 
@@ -141,14 +180,15 @@ 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.
+
+1. **Lightweight Routine Telemetry**: Every autonomous routine execution emits a structured `RoutineTelemetrySummary` (recorded in the GitHub Issue body and local `.jonah-fleet/runs/*.json` cache) capturing routine identity, duration, iterations, result, failure category, cost, and tokens.
 2. **Opt-in Emission Step**: GitHub Actions workflows (`autowork-cron.yml`, `trigger-review-routine.yml`, `prompt-optimizer-cron.yml`) run `jonah-fleet telemetry --emit` using optional `JONAH_FLEET_TELEMETRY_ENDPOINT` secrets.
 3. **Global 70% Budget Ceiling**: Tracks rolling 7-day spend across all fleet repositories against the global ceiling (~8.75M tokens/week).
 4. **Health Thresholds**:
@@ -168,23 +208,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 +257,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/_prompt-template.md

@@ -34,22 +34,19 @@ 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/{routine-name}/{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/{routine-name}.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 (e.g. `docs(log): record {routine-name} run {timestamp} [skip ci]`).
-- **Direct Push to `main`**: Commit the log file directly to `main` and push — explicitly permitted for files under `.github/prompts/logs/**`:
-  ```bash
-  git checkout main
-  git pull origin main
-  git add .github/prompts/logs/{routine-name}/{timestamp}.md
-  git commit -m "docs(log): record {routine-name} run {timestamp} [skip ci]"
-  git push origin main
-  ```
-  Follow the Log delivery fallback in `ORCHESTRATION.md` if direct push fails.
+**Issue Logging Protocol & Invariants**:
+- **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.
+- **Routine Issue Progress Milestones**: Emit bounded Compact Milestone Cards (3–5 bullet points) to `$ROUTINE_ISSUE_NUMBER` at major phase transitions using `gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "..." || true`.
+- **Milestone 4 (Run Completed)**: Append the final compact milestone card to close out the comment stream.
+- **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**: 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/analytics-review.md

@@ -82,10 +82,12 @@ When a measurement tracker is conclusive or reaches sub-threshold adoption (<2%
 
 ## Logging
 
-After completing (SUCCESS or FAILURE), write a log file to `.github/prompts/logs/analytics-review/{timestamp}.md` following the schema in `.github/prompts/logs/_template.md`. Include:
+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/analytics-review.md`)
 - Every Definition of Done criterion with YES/NO and evidence
 - Full execution trace with evaluated trackers and emitted recommendations
 - If FAILURE: root cause, category, and suggested fix
 
-**Important**: Commit the log file directly to `main` and push — explicitly permitted for files under `.github/prompts/logs/**`. Follow the Log delivery fallback in `ORCHESTRATION.md` if direct push fails.
+**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.