jonah-fleet 1.11.0 → 1.13.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jonah-fleet",
-  "version": "1.11.0",
+  "version": "1.13.0",
   "description": "Standalone autonomous agent fleet with Symphony orchestration, claim protocols, and continuous improvement loops",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/schema.json

@@ -163,6 +163,32 @@
       },
       "additionalProperties": false,
       "description": "Configuration for label management and protection shields"
+    },
+    "lessons": {
+      "oneOf": [
+        {
+          "type": "boolean",
+          "description": "Enable or disable opt-in LESSONS.md operational memory tier"
+        },
+        {
+          "type": "object",
+          "properties": {
+            "enabled": {
+              "type": "boolean",
+              "default": true,
+              "description": "Enable opt-in LESSONS.md operational memory tier"
+            },
+            "maxEntries": {
+              "type": "number",
+              "default": 25,
+              "description": "Maximum number of active operational lesson entries (hard cap: 25)"
+            }
+          },
+          "additionalProperties": false,
+          "description": "Configuration for opt-in operational memory tier (LESSONS.md)"
+        }
+      ],
+      "description": "Configuration for opt-in operational memory tier (LESSONS.md)"
     }
   },
   "required": ["version", "preset", "routines", "skills"],

package/templates/docs/LESSONS.template.md

@@ -0,0 +1,7 @@
+# Operational Lessons & Repository Heuristics
+<!-- Invariants: Max 25 entries. Hard cap. Older entries graduate or demote to LESSONS_ARCHIVE.md -->
+
+### [subsystem] Title
+- **Symptom:** <Symptom description or error message>
+- **Root Cause:** <Brief explanation of the underlying cause>
+- **Rule:** <Actionable rule or constraint to follow>

package/templates/prompts/ORCHESTRATION.md

@@ -210,11 +210,11 @@ How the fleet guarantees continuous review throughput, recovers from transient A
 
 ---
 
-## Upstream Symphony & Funes Intel & Architectural Evaluation Framework
+## Upstream Symphony, Funes & Orbital Intel & Architectural Evaluation Framework
 
-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:
+How changes and innovations from upstream ecosystems—[openai/symphony](https://github.com/openai/symphony) for issue-tracker orchestration, [huggingface/funes](https://github.com/huggingface/funes) for agent memory & session indexing, and [zqiren/Orbital](https://github.com/zqiren/Orbital) for project agents & worker transports—are systematically audited and evaluated for incorporation into 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.
+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`), releases, and pull requests across `openai/symphony` (orchestration), `huggingface/funes` (memory tooling), and `zqiren/Orbital` (project agents & worker transports), 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?
@@ -225,9 +225,14 @@ How changes and innovations from upstream ecosystems—[openai/symphony](https:/
    - **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.
+4. **Project Agent & Worker Transports Evaluation Dimensions (Orbital Watch)**:
+   - **Layer-1 Context Memory Files**: In-repo memory files (`LESSONS.md`, `CONTEXT.md`) maintained directly by agents on PR branches to avoid uncommitted disk drift or git merge collisions.
+   - **ACP/PTY Worker Transports**: Agent Client Protocol (ACP) and pseudo-terminal delegation to sub-agents, adaptable for local CLI runner execution.
+   - **Prompt Prefix Caching Benchmarks**: Partitioning prompt structures into Static $\rightarrow$ Semi-Stable $\rightarrow$ Dynamic tiers to maximize prefix cache hit rates (~95%).
+   - **Fail-Closed Safety Guards**: Deterministic action-hash repetition guards, cycle detection, and circuit breakers that halt runaway execution loops before token budgets are breached.
+5. **Classification & Action Protocol**:
+   - **🟢 Category A (Adopt Directly)**: Security guardrails, claim lock invariants, reader/writer rules, prompt engineering & prefix caching optimizations, fail-closed safety guards, deterministic zero-LLM indexing.
+   - **🟡 Category B (Adapt to Actions/CLI)**: Dynamic orchestrator pacing, backpressure controls, multi-stage review checks, pull-based memory MCP integrations, ACP/PTY worker transports.
    - **🔴 Category C (Skip)**: Elixir/OTP supervision trees, BEAM memory tuning, proprietary runtime internals, always-loaded memory context dumps.
 
 ---
@@ -257,3 +262,39 @@ 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.
+
+---
+
+## Headless Execution & Asynchronous Non-Yielding Guardrail
+
+In headless CLI environments (`agy -p` / GitHub Actions), agent sessions terminate immediately whenever the model yields a turn without active tool calls. Therefore:
+
+1. **Zero-Yield Waiting Invariant**: Agents MUST NEVER call `schedule` or emit a terminal turn with plain text to "wait" for background commands, timers, or long-running checks. In headless mode, yielding the turn halts the process immediately with exit code 0 before reaching the Definition of Done.
+2. **Active Task Supervision**: If a verification command (`npm test`, `npm run type-check`) is sent to the background by `run_command`, the agent must actively poll `manage_task(Action='status')` or inspect code while waiting within the continuous tool-calling loop.
+3. **CI Trust Bar & Test Discipline**: Peer review routines should trust green passing remote CI checks (GitHub Actions or Vercel preview deployments) on the PR's head commit rather than initiating slow, background-prone full test runs. Run repository verification locally ONLY if CI status is unconfirmed, missing, or failing.
+
+---
+
+## Structured Human Escalation Card Protocol ("Why I believe this")
+
+How autonomous routines escalate decisions, ambiguities, and blockers to human maintainers without unbounded back-and-forth or vague questions:
+
+1. **Mandatory 4-Part Escalation Schema**: Whenever a routine cannot proceed autonomously due to ambiguity, conflicting requirements, unobservable acceptance criteria, or repeated review ping-pong—and applies `needs-human` or `needs-info`—it MUST post a comment structured as the mandatory 4-part escalation card (inspired by Orbital's Workbench Provenance format):
+   ```markdown
+   ## 🛑 Escalation: Human Decision Required
+   - **Decision Needed**: [1 focused question or choice]
+   - **Evidence ("Why I believe this")**: [Specific files, lines, test outputs, or conflicting docs]
+   - **Evaluated Options & Trade-offs**:
+     - *Option A*: [Pros / Cons]
+     - *Option B*: [Pros / Cons]
+   - **Recommended Path**: [Agent recommendation]
+   ```
+2. **Card Invariants**:
+   - **Decision Needed**: Exactly 1 high-leverage question or choice required from the maintainer or reporter. Prohibit question dumps or vague "please provide more details".
+   - **Evidence ("Why I believe this")**: Concrete artifacts, specific file paths, line numbers, test outputs, or contradicting specification documents justifying why the routine cannot proceed without human guidance.
+   - **Evaluated Options & Trade-offs**: At least two distinct, viable options with concrete pros and cons. Never ask maintainers to solve problems from scratch without agent-evaluated trade-offs.
+   - **Recommended Path**: The agent's recommended decision and reasoning, allowing maintainers to unblock execution with a simple confirmation.
+3. **Cross-Routine Enforcement**:
+   - `autowork.md`: Required when tripping the Ambiguity Gate (Step 12), encountering a 2nd-strike permanent blocker (`needs-human`), or hitting the review Ping-Pong Cap (Step 3b).
+   - `triage/SKILL.md`: Required when transitioning issues or PRs to `needs-info` or `ready-for-human`.
+   - `issues-housekeeping.md`: Required when auditing and escalating ambiguous, stale, or infeasible issues with `needs-human` or `needs-info`.

package/templates/prompts/autowork.md

@@ -29,6 +29,7 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 - **Single-flight per issue & PR**: multiple autowork runs can execute concurrently. Both issues and pull requests are shared resources — never begin implementing an issue without first claiming it (see Claim protocol in Phase 2), and never begin addressing findings on an open PR without first claiming it (see PR Claim protocol in Phase 1).
 - **Language Requirement**: All GitHub issue titles, descriptions, task checklists, and comments MUST be written in **English**.
 - **Session link footer**: sign every GitHub post (issue comments, PR comments, PR descriptions) with the Antigravity run footer (`_Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_`). Inline review-thread line comments are exempt.
+- **Headless Execution & Asynchronous Non-Yielding Guardrail**: You are running in a headless autonomous session. You MUST NEVER call `schedule` or yield the turn with plain text while waiting for background tasks or verification checks. If a verification command runs in the background, actively inspect its completion with `manage_task` or run with sufficient `WaitMsBeforeAsync` (up to `10000` ms). Never stop calling tools or yield your turn until the routine's terminal Definition of Done is fully reached.
 
 ## Negative examples (DO NOT do these)
 
@@ -44,7 +45,8 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 - Do not start implementing an issue before claiming it (both assignment AND claim comment).
 - Do not mark a PR ready while its `mergeable_state` is `dirty` — resolve merge conflicts first.
 - Do not fall into the **Telemetry Rabbit Hole**: do not spend cycles instrumenting elaborate fallback telemetry or defensive error handling for features that suffer from lack of user intent rather than software bugs.
-- Do not guess or invent arbitrary specifications for ambiguous issues — post clarifying questions, label `needs-info`, and release the claim instead of blindly writing code.
+- Do not guess or invent arbitrary specifications for ambiguous issues — post the 4-part escalation card ('Why I believe this'), label `needs-info`, and release the claim instead of blindly writing code.
+- Do not call `schedule` or yield the turn with plain text while waiting for background verification tasks — stay in the tool loop until the Definition of Done is met.
 
 ## Instructions
 
@@ -88,8 +90,17 @@ a. **Read the target issue and check eligibility.** Eligible = open, unassigned
    - **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.
    - **Active Origin Sync & Clean-Merge Gate**: Run `git fetch origin main && git merge origin/main --no-edit` to absorb any newly merged pull requests and resolve any conflicts locally. Verify `git merge-tree origin/main HEAD` reports no conflicts before marking ready.
    - **Release claim on ready**: mark the PR ready (`gh pr ready <PR>`) and unassign yourself (`gh pr edit <PR> --remove-assignee <login>`) so Peer Review can evaluate without holding stale agent reservation locks.
-     Only mark the PR ready after passing every check above.
-     3b. **Ping-pong cap**: If this same PR has bounced between draft and ready 3 or more times over the same substantive finding, stop re-marking it ready. Post a comment summarizing the disagreement for human resolution and leave the PR in draft.
+      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 the mandatory 4-part escalation card summarizing the disagreement for human resolution and leave the PR in draft:
+        ```markdown
+        ## 🛑 Escalation: Human Decision Required
+        - **Decision Needed**: [1 focused question or choice]
+        - **Evidence ("Why I believe this")**: [Specific files, lines, test outputs, or conflicting docs]
+        - **Evaluated Options & Trade-offs**:
+          - *Option A*: [Pros / Cons]
+          - *Option B*: [Pros / Cons]
+        - **Recommended Path**: [Agent recommendation]
+        ```
      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.
@@ -128,13 +139,23 @@ a. **Read the target issue and check eligibility.** Eligible = open, unassigned
     - Read the issue description, linked code, and comment thread.
     - If bug: use `/diagnosing-bugs` to establish reproduction test before fixing.
     - If large/complex: use `/domain-modeling` and `/codebase-design`.
+    - **Pre-Flight Memory Scan**: If `LESSONS.md` exists, grep matching subsystem tags (`grep -E "^### \[(subsystem)\]" LESSONS.md -A 4`) to incorporate known landmines into implementation plans before writing code.
     - **Ambiguity & Missing Acceptance Criteria Gate**: Challenge underspecified or incomplete requests before writing any code. If the issue lacks observable acceptance criteria, relies on unverified assumptions, or leaves critical technical/UX decisions ambiguous:
       - Do NOT guess or invent arbitrary requirements to force completion.
-      - Post a comment on the issue posing 1–3 focused clarifying questions that identify the exact decisions or trade-offs needed.
+      - Post the mandatory 4-part escalation card on the issue:
+        ```markdown
+        ## 🛑 Escalation: Human Decision Required
+        - **Decision Needed**: [1 focused question or choice]
+        - **Evidence ("Why I believe this")**: [Specific files, lines, test outputs, or conflicting docs]
+        - **Evaluated Options & Trade-offs**:
+          - *Option A*: [Pros / Cons]
+          - *Option B*: [Pros / Cons]
+        - **Recommended Path**: [Agent recommendation]
+        ```
       - Apply the `needs-info` label and release the claim (unassign).
       - 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.
+    - 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, post the mandatory 4-part escalation card (`## 🛑 Escalation: Human Decision Required`), apply `needs-human` label, and tag repo owner.
       12a. **Umbrella-issue handoff + batching:** If candidate is an umbrella epic:
     - Read `🧭 Decomposition plan` comment (or create if first run).
     - Pick next slice(s), batching up to 3 same-recipe slices into one child issue + PR.
@@ -151,7 +172,9 @@ a. **Read the target issue and check eligibility.** Eligible = open, unassigned
 13. **Implementation & PR creation:**
     - Branch from freshly fetched `origin/main` with descriptive name (e.g. `feat/...` or `fix/...`).
     - Drive implementation via `/tdd` (red-green-refactor).
+    - **Diagnostic Reflex**: On unexpected test/build failure during TDD, grep symptom text in `LESSONS.md` before making speculative code edits.
     - Run repository tests and verification.
+    - **Pre-PR Lessons Capture Gate**: If solving the issue required overcoming a non-obvious quirk not caught by tests/linters, append a 3-line structured entry on the active PR branch adhering to the 25-entry hard cap. Never write to `LESSONS.md` directly on `main`.
     - **Milestone 2 (Verification & Tests)**: Once implementation passes tests and type checks, emit milestone card if `$ROUTINE_ISSUE_NUMBER` is set:
       ```bash
       gh issue comment "$ROUTINE_ISSUE_NUMBER" --body "### 🧪 Milestone: Verification & Tests

package/templates/prompts/issues-housekeeping.md

@@ -39,7 +39,17 @@ 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 & 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.
+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. Whenever applying `needs-human` or `needs-info` to escalate an ambiguous, stale, or infeasible issue, mandate formatting the escalation comment with the 4-part card:
+   ```markdown
+   ## 🛑 Escalation: Human Decision Required
+   - **Decision Needed**: [1 focused question or choice]
+   - **Evidence ("Why I believe this")**: [Specific files, lines, test outputs, or conflicting docs]
+   - **Evaluated Options & Trade-offs**:
+     - *Option A*: [Pros / Cons]
+     - *Option B*: [Pros / Cons]
+   - **Recommended Path**: [Agent recommendation]
+   ```
+   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/optimizer.md

@@ -71,6 +71,8 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
    - **Passive Order-Taking Anomaly ("Yes-Man Blindspot")**: The Ambiguity Gate trigger rate across intake runs in `autowork` or `triage` is <5% despite elevated PR review bounces ($\ge 2$) or high iteration usage ($\ge 35$), indicating agents are silently guessing requirements and building flawed implementations rather than interrogating underspecified issues.
    - **Speculative Runaway Waste**: An agent run consumed >50k tokens on an underspecified issue with 0 clarifying questions asked, and subsequently failed, bounced, or required post-merge rework.
 6. **Analyze resolved bugs & review comments**: Examine closed bug issues, merged bug-fix PRs, and review feedback for missing checks in authoring (`autowork.md`) or review (`peer-review.md`).
+7. **Scan & Audit Operational Lessons (`LESSONS.md`)**:
+   - Scan `LESSONS.md` during routine optimization sweeps, graduating stable rules to automated linter/CI checks or archiving stale entries to `LESSONS_ARCHIVE.md`.
 
 ### 2. Formulate preventative improvements
 
@@ -81,6 +83,7 @@ Translate findings into concrete preventative improvements and remediation trigg
 - **Ping-Pong Convergence**: For Review Loop Burn, tighten reviewer trust & noise filtering, enforce clean-merge gates, and apply ping-pong caps to prevent endless bounce cycles.
 - **Loop Discovery Mechanical Audits**: For Feedback Loop Stagnation, tighten discovery sweeps by mandating deterministic per-issue matching tables and itemized reconciliation against upstream closed issues/PRs rather than allowing un-itemized generic summary assertions.
 - **Ambiguity Gate & Benchmark Eval Feeding**: For Passive Order-Taking and Speculative Runaway Waste, tighten Step 12 criteria in `autowork.md` and `triage.md` to mandate clarifying questions, and automatically extract the problem issue into a `BenchmarkIssue` test case to feed the automated ambiguity benchmark eval suite (`tests/evals.test.ts`), ensuring future agent prompts are continuously tested against real failure cases.
+- **Operational Memory Graduation & Archiving**: Scan `LESSONS.md` to identify recurring, stable rules for graduation into automated linter rules or CI workflow checks. Move obsolete or overflow entries (>25 cap) to `LESSONS_ARCHIVE.md`.
 - **Verification & Invariant Tests**: Add automated test cases in `tests/` verifying prompt invariant preservation and schema conformity.
 
 ### 3. Open Fix PR (Local or Upstream Bridge)

package/templates/prompts/peer-review.md

@@ -33,6 +33,8 @@ If any criterion cannot be met, stop immediately and log FAILURE with the reason
 - **No speculative work**: review only the diff in the PR.
 - **Language Requirement**: All GitHub comments, review notes, and follow-up issues MUST be written in **English**.
 - **Session link footer**: sign every GitHub post with the Antigravity run footer (`_Generated by [Antigravity](${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}/actions/runs/${GITHUB_RUN_ID})_`).
+- **Headless Execution & Asynchronous Non-Yielding Guardrail**: You are running in a headless autonomous CLI session. You MUST NEVER call `schedule` or yield the turn with plain text to "wait" for background tasks, timers, or long-running commands. In headless CLI mode, yielding the turn terminates the session immediately before reaching the Definition of Done. When invoking `run_command` for test runs or type checks, ALWAYS set `WaitMsBeforeAsync` high enough (up to the maximum `10000` ms) or if a command moves to the background, keep your execution turn active by checking task status (`manage_task(Action='status')`) or inspecting files; NEVER call `schedule` or emit a terminal turn with plain text before taking the final action.
+- **Verification Command & CI Discipline**: When remote CI checks (e.g. GitHub Actions, Vercel preview deployments) are already present and passed on the PR's head commit, treat CI as verified and green. Avoid executing slow, redundant local full test suites or full type-checks when CI is already green. Run local verification commands (`npm test`, `npm run type-check`) ONLY if CI is missing, unconfirmed, or failing.
 
 ## Final action: merge or bounce to draft
 
@@ -58,6 +60,8 @@ Every review ends in exactly one of two states:
 - On re-review, do not raise new findings in code that was unchanged since the prior review — only inspect the delta commits.
 - Do not bounce a PR for non-blocking style/preference findings when all correctness checks pass.
 - Do not bounce an external contributor PR purely for missing `Closes #N` when the PR description provides a clear specification.
+- Do not call `schedule` or yield the turn with plain text while waiting for background verification tasks — stay in the tool loop until the final action is taken.
+- Do not rerun full local test suites when remote CI checks on the head commit are already green and passing.
 
 ## Instructions
 
@@ -101,6 +105,7 @@ Check if `$PR_NUMBER` is set:
 1. Run `/code-review` over the diff (or delta commits if re-review) evaluating:
    - **Standards**: Conformance to `AGENTS.md` (or `CLAUDE.md`/`GEMINI.md`), conventions, and architecture.
    - **Spec Compliance**: Verification against the linked issue's deliverables (`## Tasks`), or against the PR description's summary/changes if no tracking issue is linked.
+   - **Operational Memory & Lessons Invariant**: Inspect `LESSONS.md` diffs in PRs to verify the lesson is accurate, non-trivial, follows the 3-line structured schema, and the file adheres to the 25-entry hard cap.
 2. Run Security Pass: auth gates, permission checks, injection risks, sensitive credentials.
 3. **Design System & Viewport Density Pass** (if PR modifies frontend/rendered UI):
    - **Token Purity**: Check for arbitrary CSS/Tailwind sizing overrides (e.g. `text-[...px]`, `w-[...px]`) or bespoke button styling bypassing standard design system tokens.
@@ -108,7 +113,7 @@ Check if `$PR_NUMBER` is set:
    - **CTA Hierarchy**: Verify at most one primary forward CTA (`.btn-primary`) per active screen/tab.
    - **Mobile Viewport Budget**: Verify that new banners, nudges, or sticky elements do not stack concurrently above the fold on mobile viewports (~390px).
 4. If PR modifies rendered UI, verify screenshots or visual components if tooling/scripts are available.
-5. Run repository verification commands (tests, type-check) if CI status is unconfirmed.
+5. Run repository verification commands (tests, type-check) ONLY if CI status is unconfirmed or failing. If remote CI (such as GitHub Actions or Vercel preview) is already green and passing on the head commit, treat CI as verified. If verification commands must be run locally, specify `WaitMsBeforeAsync: 10000` and NEVER call `schedule` or yield the turn with plain text while waiting for background tasks.
 
 ### Step 5: Classify Findings & Make Decision