@haposoft/cafekit 0.16.6 → 0.18.0

package/src/claude/skills/delegate/references/grok-delegation.md

@@ -1,84 +0,0 @@
-# Delegating to Grok CLI (Grok Build)
-
-Verified against grok 0.2.101 (2026-07). Re-check `grok --help` if flags fail.
-
-## Preflight
-
-```bash
-which grok && grok --version
-grok models          # available model IDs
-```
-
-## Non-interactive dispatch
-
-Two forms:
-
-```bash
-# single-turn from a brief file (preferred for delegation)
-grok --prompt-file plans/<slug>-task.md \
-     --worktree=<slug> \
-     --check \
-     --permission-mode acceptEdits \
-     --allow "Bash(npm:*)" --allow "Bash(node:*)" \
-     --output-format plain
-
-# short single-turn prompt
-grok -p "<prompt>"
-```
-
-Run in a background shell and poll the output.
-
-### Key flags
-
-| Flag | Notes |
-|---|---|
-| `--prompt-file <path>` | single-turn prompt from file |
-| `-p, --single <prompt>` | single-turn inline prompt |
-| `--worktree=<name>` | built-in git worktree isolation (grok-managed; see pitfalls) |
-| `--check` | appends a self-verification loop (headless only) — use it |
-| `--permission-mode <mode>` | `default` \| `acceptEdits` \| `auto` \| `dontAsk` \| `bypassPermissions` \| `plan` |
-| `--allow "<RULE>"` / `--deny "<RULE>"` | permission rules, Claude Code syntax: `Bash(npm:*)`, `Write`, `Edit` |
-| `-m <model>` / `--reasoning-effort` | model + effort overrides |
-| `--max-turns <N>` | hard cap on agent turns |
-| `--json-schema '<schema>'` | structured final output |
-| `--output-format plain\|json\|streaming-json` | headless output format |
-| `--resume <SESSION_ID>` | continue a session (context preserved) |
-| `--best-of-n <N>` | run task N ways in parallel, pick best (headless) |
-
-## Permission model — the #1 pitfall
-
-`--permission-mode acceptEdits` **does not reliably unblock file writes in headless runs**; grok may report "Write tool blocked" and quietly degrade to a **design-only** response that reads like progress. It still exits 0.
-
-Mitigations:
-- Add explicit allow rules for write tools on the first dispatch: `--allow "Write" --allow "Edit" --allow "StrReplace"` alongside `--allow "Bash(npm:*)" --allow "Bash(node:*)"`.
-- After ~30s, grep the output for `blocked`/`chặn` — catch degradation early.
-- If the run finished design-only: **resume the same session** with widened allows and an explicit apply instruction; grok picks up its own design and implements without re-exploring:
-
-```bash
-grok --resume <SESSION_ID> --no-plan \
-     --permission-mode acceptEdits \
-     --allow "Write" --allow "Edit" --allow "StrReplace" \
-     --allow "Bash(npm:*)" --allow "Bash(node:*)" \
-     --check -p "Continue: apply the designed changes, run tests, report results."
-```
-
-Even with allows granted, shell may still be policy-restricted (runs finish with "npm test BLOCKED — shell not pre-approved"). That's fine: **you run the Evidence commands yourself during verification** — do not loosen to `bypassPermissions` just to make the agent self-verify.
-
-## Worktree pitfalls
-
-- `--worktree=<name>` worktrees are **grok-managed**: they may not appear in the target repo's `git worktree list` and `grok worktree list` may still say "No worktrees found". **Do not trust either listing** — after the run, check `git status` in the main repo to find where changes actually landed. In practice (0.2.101, resumed sessions) grok can write **directly into the main working tree** despite the flag.
-- Consequence: always take a stash-backup snapshot before dispatch (`git stash push -u -m "backup: ..." && git stash apply -q`), and treat the main tree as potentially modified.
-
-## Session management
-
-```bash
-grok sessions list                      # ids + summaries
-grok --resume <SESSION_ID> [flags] -p "..."   # continue with same context
-grok export <SESSION_ID>                # transcript as Markdown
-```
-
-## Quirks
-
-- Grok reads the target repo's `CLAUDE.md` and obeys it (including tone rules) — repo constraints apply automatically, but so do repo-wide bans; account for that in the brief.
-- `--check` produces a self-verification section in the final report — useful signal, **not** a substitute for your independent verification.
-- Exit code 0 means the CLI ran, not that the task succeeded. Judge by diff + your own Evidence runs.

package/src/claude/skills/hotfix/SKILL.md

@@ -1,289 +0,0 @@
----
-name: cf:fix
-description: "Use when asked to FIX a bug, error, test failure, CI/CD issue, type error, lint error, log error, UI issue, or code problem. Uses cf:debug for evidence-first diagnosis before any code change."
-user-invocable: true
-when_to_use: "Invoke to fix a bug or failure with scout-first diagnosis before change."
-category: dev-tools
-keywords: [hotfix, fix, bug, diagnosis]
-argument-hint: "[issue] --quick|--parallel|--from-debug"
-metadata:
-  author: haposoft
-  version: "2.0.0"
----
-# Fix — root-cause repair workflow
-
-Fix the diagnosed root cause, prove the fix with fresh evidence, and leave no
-side effects. Evidence first, fix second.
-
-## Arguments
-
-- `--quick` - Reduced-depth path for trivial issues (lint, type errors, syntax); still scout-first
-- `--parallel` - Fix independent issues concurrently, only through the Delegation Gate below
-- `--from-debug` - Start from an existing `cf:debug` report and validate its contract before accepting it
-
-Default: deterministic scout-first fix. There is no initial mode selection step.
-
-## Proportional depth
-
-Choose the smallest adequate depth from the diagnosed evidence. Depth vocabulary
-follows `cf:debug`:
-
-- **Quick/local:** one deterministic syntax, lint, type, or isolated-test failure
-  with obvious local scope. Quick mode only reduces depth; it never skips scout, pre-fix evidence, diagnosis, or before/after verification.
-- **Standard:** a diagnosed root cause inside one bounded area. Fix plus a
-  regression test that fails without the fix and passes with it.
-- **Incident/deep:** production impact, multiple components, intermittent
-  behavior, data/security risk, or concurrency. Consume the full Incident/deep
-  debug handoff (timeline, elimination path, recurrence candidates), implement in
-  stages, and verify each stage.
-
-Depth changes evidence breadth, never the gates: scout, diagnosis, before/after
-proof, and the side-effect gate apply at every depth.
-
-## Bounded repair frame
-
-Quick/local does not add a separate framing ceremony when the issue and diagnosis
-already establish the repaired behavior and proof. For Standard or Incident/deep,
-or whenever scope or risk remains ambiguous after diagnosis, record four short
-fields before choosing an implementation:
-
-- **Outcome:** the observable repaired behavior.
-- **Constraints:** compatibility, safety, ownership, rollout, and time boundaries.
-- **Non-goals:** adjacent behavior the repair must not absorb.
-- **Acceptance:** the exact reproduction plus broader evidence that proves completion.
-
-Derive repository-owned facts from scout and diagnosis. Ask the user only for a
-missing user-owned decision that could materially change the repair. This frame
-does not select a solution, widen the issue into feature work, or run before the
-root cause is proven.
-
-<HARD-GATE>
-Do not propose or implement a fix before Steps 1-2 (scout + diagnosis) complete.
-A symptom patch without a diagnosed root cause is a failed fix.
-The exact root-cause contract in Step 2 is mandatory; answer each field in one concrete sentence.
-An answer containing 'probably', 'I think', 'something with', or 'maybe' is not an answer; gather evidence instead.
-If 3+ fix attempts fail, stop, question the architecture, and discuss with the user.
-</HARD-GATE>
-
-<HARD-GATE-SCOUT-FIRST>
-Fix always scouts before asking broad clarification questions, forming hypotheses, or changing files.
-Collect these scout outputs first:
-1. Project type, language(s), framework(s), and package/test runner from repo files.
-2. Exact file(s) where the symptom surfaces and their direct callers/dependents.
-3. Related tests covering the affected area.
-4. Recent commits touching affected files: `git log --oneline -10 -- <affected-files>`.
-5. Existing patterns/conventions for this kind of fix.
-Then state a concise 3-6 bullet codebase-context summary before Step 2.
-Do not ask generic questions before this step unless there is no repo, no error text, and no observable artifact to inspect.
-</HARD-GATE-SCOUT-FIRST>
-
-<HARD-GATE-NO-SIDE-EFFECTS>
-The fix is not done until Step 5 proves:
-1. The original symptom no longer reproduces with the exact pre-fix command/user flow.
-2. Modified files and transitively affected modules still pass relevant tests.
-3. Blast-radius workflows have no business-logic regression.
-4. No new lint/type/build errors were introduced.
-5. Public contracts are unchanged unless intentionally called out: function signatures, exported types, response shapes, DB schemas, env vars.
-
-If verification reveals a side effect or regression, stop and present 2-4 concrete options to the user:
-- Revert this fix and try a different root-cause angle
-- Keep the fix and update <dependent files> to match the new contract
-- Narrow the fix to <subset> so the regression disappears
-- Accept the change — the old behavior was itself a bug
-Do not silently patch around the regression.
-</HARD-GATE-NO-SIDE-EFFECTS>
-
-## Delegation Gate
-
-Dispatch subagents (parallel scouts, hypothesis tests, deep research, or
-`--parallel` fix trees) only when all three conditions hold:
-
-- The user explicitly requested or permitted delegation or parallel agents.
-- The active runtime exposes an Explore/delegation capability.
-- The work splits into at least two distinct, non-overlapping scopes with useful independent work.
-
-Otherwise continue sequentially in the main agent with focused local evidence.
-Task-tracking tools are an optional visibility fallback, never a required step;
-a concise markdown checklist is always sufficient.
-
-## Process Flow
-
-```mermaid
-flowchart TD
-    A[Issue Input] --> B[Step 1: Scout via cf:scout]
-    B --> C[Step 2: Diagnose via cf:debug]
-    C --> D[Step 3: Select Depth]
-    D --> E[Step 4: Implement Fix]
-    E --> F[Step 5: Verify + Prevent]
-    F --> G[Side-Effect Gate]
-    G -->|Pass| H[Step 6: Finalize]
-    G -->|Regression risk| C
-    F -->|Fail, <3 attempts| C
-    F -->|Fail, 3+ attempts| I[Question architecture with user]
-    H --> J[Report]
-```
-
-If prose conflicts with this flow, follow the diagram.
-
----
-
-## Step 1: Scout
-
-Understand the affected codebase before forming any hypotheses. Activate
-`cf:scout` or perform an equivalent focused local scout (`rg` plus targeted
-reads) to map the blast radius.
-
-| Path | Scout depth |
-|------|-------------|
-| Quick/local | Minimal - project type, affected file(s), direct callers/dependents, related tests, recent commits |
-| Standard and deeper | Full - module boundaries, test coverage, call chains, recent changes, existing patterns |
-| `--parallel` | Per-issue independent scouts, one scope each, only through the Delegation Gate |
-
-**Output:** `✓ Step 1: Scouted — [N] files mapped, [M] dependencies, [K] tests found`
-
----
-
-## Step 2: Diagnose via `cf:debug`
-
-Evidence-based root cause analysis; no guessing. Use `cf:debug`, or validate
-an existing debug report when `--from-debug` is provided. See
-`references/diagnosis-protocol.md` for the Fix-local checklist.
-
-Diagnosis chain:
-
-1. **Capture pre-fix state:** exact error messages, failing test output, stack traces. This is the baseline for Step 5.
-2. **Observe:** read the actual error; locate where it occurs and when it started (`git log -p`).
-3. **Hypothesize:** form 2-3 hypotheses, each with confirm/refute evidence and a quick test.
-4. **Test:** validate each hypothesis against codebase evidence with focused local reads; test hypotheses in parallel only through the Delegation Gate.
-5. **Trace root cause:** symptom → immediate cause → contributing factor → root cause.
-6. **Escalate:** if 2+ hypotheses fail, apply `references/escalation-tactics.md`.
-
-**Exact root-cause contract:**
-- Symptom: exact observable failure
-- Reproduction: command, user flow, CI job, log trigger, or route
-- Expected vs actual behavior
-- Trigger: event or input that activated the failure, or `unknown`
-- Root cause: file:line, config, environment, dependency, or data source
-- Contributing factors: conditions that raised likelihood or impact but are not sufficient causes, or `none evidenced`
-- Why now: recent change, dependency drift, data state, environment, timing, or load
-- Evidence chain: observations proving the cause
-- Blast radius: affected files, modules, tests, users, workflows, or release paths
-
-With `--from-debug`, validate the report before accepting it:
-
-- the exact root-cause contract above is complete;
-- `Evidence Timeline` is present — a skipped timeline is valid in either producer form (`Timeline: skipped - <reason>` or `- skipped: <reason>`);
-- `Elimination Path` records the decisive observation for each removed or retained candidate;
-- `Recurrence-Prevention Handoff`, when present, carries evidence-backed candidates only.
-
-A report missing required fields routes back to diagnosis (`cf:debug`); it
-does not enter implementation.
-
-If any contract field is vague or missing file:line/config/env evidence, keep
-diagnosing or ask the user for the specific missing artifact. Do not implement.
-
-**Output:** `✓ Step 2: Diagnosed — Root cause: [summary], Evidence: [brief], Scope: [N files]`
-
----
-
-## Step 3: Select Depth + Bound Repair
-
-Apply the Proportional depth rule above. For 2+ independent issues (or
-`--parallel`), evaluate the Delegation Gate; when it is closed, fix the issues
-sequentially. Track progress with the runtime's task surface when available, or
-a markdown checklist otherwise.
-
-For Standard and Incident/deep, complete the bounded repair frame above. Quick
-records no separate frame unless scope or risk is still ambiguous.
-
-**Output:** `✓ Step 3: [Depth] selected — [workflow]`
-
----
-
-## Step 4: Implement Fix
-
-Rules:
-- Fix the root cause, not the symptom. Follow diagnosis findings.
-- Minimal changes only; follow existing code patterns.
-- One logical change per commit boundary.
-
-Workflows by depth:
-- **Quick:** apply the minimal fix from completed scout + diagnosis, run the exact pre-fix command plus typecheck/lint immediately, report before/after proof.
-- **Standard:** implement the fix, add or update a regression test that fails without the fix and passes with it, run the relevant suite.
-- **Incident/deep:** after diagnosis, research only unresolved external facts. If
-  multiple cause-aligned remedies or an architecture decision remain, use
-  `cf:brainstorm` to compare 2-3 options against the bounded repair frame, then
-  write a concise staged implementation plan with dependencies and proof per
-  stage. When diagnosis leaves one safe direct repair, skip research and
-  brainstorm, record why it satisfies the frame, and implement it. Delegated
-  research follows the Delegation Gate; implementation starts only after the
-  direction is resolved.
-- **Parallel:** one independent issue per agent, each following Steps 1-5, dispatched only through the Delegation Gate; aggregate results on completion.
-
-**Output:** `✓ Step 4: Fixed — [N] files changed`
-
----
-
-## Step 5: Verify + Prevent
-
-1. **Iron-law verification:** run the exact commands from the pre-fix state capture and compare output. No claims without fresh command output from the current run.
-2. **Regression test:** must fail without the fix and pass with it.
-3. **Full check:** typecheck + lint + build + test (see `references/parallel-patterns.md` Pattern C).
-4. **Prevention guard (Standard+):** see `references/prevention-gate.md`; consume the debug report's recurrence candidates when present.
-5. **Side-effect gate:** sweep the full blast radius from Step 2 against the five checks in the gate above.
-6. **Review:** trigger `cf:code-review`; see `references/review-cycle.md`.
-
-Verification and review report `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`.
-The definition of `PASS` defers to `cf:code-review`. `PASS_WITH_WARNINGS`
-routes through the same remediation or user-pause path as `FAIL` and never
-auto-accepts. `BLOCKED` is terminal for the cycle; resolve the blocker instead
-of retrying. A review-only result is not execution proof; completion claims
-require fresh command output.
-
-If verification fails: under 3 attempts, loop back to Step 2 and re-diagnose
-with the new evidence; at 3+ attempts, stop and discuss with the user. Never
-weaken, delete, or mock a failing assertion to obtain green.
-
-**Output:** `✓ Step 5: Verified + Prevented — [before/after comparison], [N] tests added`
-
----
-
-## Step 6: Finalize
-
-1. **Report:** root cause, changes made, files affected, prevention measures, side-effect sweep result, and any remaining limitations.
-2. **Docs update:** if API or behavior changed, update only the affected existing docs through the docs flow.
-3. **Commit:** ask the user before committing; use conventional commits.
-
-**Output:** `✓ Step 6: Complete — [action taken]`
-
----
-
-## Output Format
-
-Unified step markers (emit after each step):
-```
-✓ Step 1: Scouted — [N] files, [M] deps
-✓ Step 2: Diagnosed — Root cause: [summary]
-✓ Step 3: [Depth] selected — [workflow]
-✓ Step 4: Fixed — [N] files changed
-✓ Step 5: Verified + Prevented — [tests added], [guards added]
-✓ Step 6: Complete — [action taken]
-```
-
-## Specialized Paths
-
-Use `references/workflow-specialized.md` as a progressively disclosed overlay
-after Step 1 scout for CI/CD failures, test suite failures, TypeScript type
-errors, UI/visual issues, and application log errors. Load only the matching
-section. Specialized paths add category-specific evidence and proof; they do
-not replace the six-step flow, weaken diagnosis, or broaden the repair scope.
-
-## References
-
-Load as needed:
-- `references/diagnosis-protocol.md` — Structured root cause analysis and the exact root-cause contract
-- `references/escalation-tactics.md` — What to do when hypotheses fail (Inversion, Scale Game)
-- `references/prevention-gate.md` — Defense-in-depth validation after fix
-- `references/review-cycle.md` — Review verdict handling and required user-pause conditions
-- `references/parallel-patterns.md` — Delegation Gate patterns for parallel work
-- `references/workflow-specialized.md` — CI/CD, test, TypeScript, UI-specific workflows

package/src/claude/skills/inspect/SKILL.md

@@ -1,142 +0,0 @@
----
-name: cf:scout
-description: "Fast scoped codebase discovery using local search first and user-permitted Explore delegation only for broad independent scopes. Use for file discovery, task context, entrypoints, call paths, and blast radius."
-user-invocable: true
-when_to_use: "Invoke for fast scoped codebase discovery and file location."
-category: discovery
-keywords: [scout, inspect, discovery, search, context]
-argument-hint: "[search-target]"
-metadata:
-  author: haposoft
-  version: "2.1.0"
----
-# Scout
-
-Fast, token-efficient codebase discovery that uses focused local search by default
-and delegates only when parallel scouting has a concrete benefit.
-
-## Arguments
-- Default: Scout the named target with local `rg` and targeted reads. For a
-  genuinely broad scope, use the conditional delegation route in
-  `./references/internal-inspection.md`.
-
-## When to Use
-
-- Feature spanning multiple directories; user wants to find/locate/search files
-- Debugging that needs file relationships; project structure questions
-- Before multi-area changes, review, debug, or impact analysis
-
-## Preflight Scope Gate (MANDATORY)
-
-Before scanning:
-1. Detect repo-root or root-wide scans such as `.`, `/`, `./`, `**/*`, `**/*.ts`, or similar broad patterns without a scoped directory.
-2. Apply the built-in no-scan lists below.
-3. Prefer file-type or glob hints whenever possible.
-
-**When scope is too broad:** use a **2-phase approach** — lightweight structure
-mapping first, then parallel agents only when the Delegation Gate is open.
-
-### Phase 1 — Structure Map
-
-Map the top-level layout in the main agent. A single Explore agent may do this
-only when the Delegation Gate below is already open:
-1. List immediate children of the scope root (dirs + key config; monorepo markers)
-2. Rough file count per discovered directory
-3. Return a division plan of 1–10 logical sub-scopes (path/glob, est. files, focus)
-
-Complete the structure map before Phase 2.
-
-### Phase 2 — Conditional Parallel Explore
-
-1. Follow the structure map; merge scopes < 10 files; split scopes > 100 files
-2. If the Delegation Gate is open, spawn Explore agents on distinct sub-scopes;
-   otherwise scout the sub-scopes sequentially in the main agent
-3. Aggregate into the Scout Report; offer deeper follow-up on specific areas
-
-**Fallback to AskUserQuestion:** if the structure map still leaves multiple
-plausible targets and the choice would materially change the scan, offer 2–4
-concrete scopes from findings, then continue with the selected scope.
-
-## Built-in No-Scan Guidance
-
-### `NO_SCAN_PATHS`
-- `.git/`, `node_modules/`, `dist/`, `build/`, `.next/`, `coverage/`
-- `tmp/`, `temp/`, `vendor/`, `artifacts/`, `secrets/`, `private/`
-
-### `NO_SCAN_CONTENT_HINTS`
-- private keys, token dumps, credential exports, `.env` secrets
-- generated bundles, binary blobs
-
-## Workflow
-
-### 1. Analyze Task
-- Parse search targets; identify directories, patterns, file types
-- Estimate scan size and whether the work divides into independent scopes
-
-### 2. Choose The Smallest Route
-
-| Condition | Route |
-|---|---|
-| Named files/directories or focused scope (about 50 files or fewer) | Main-agent `rg` plus targeted reads; do not delegate |
-| Medium scope that still fits one coherent search | Main-agent scouting; narrow before considering delegation |
-| Broad scope with two or more independent areas | Structure map, then evaluate the Delegation Gate |
-
-Do not use the file estimate alone to justify agents. A focused 100-file search
-may still be cheaper locally; a smaller cross-system search may justify two
-independent scopes.
-
-### 3. Delegation Gate
-
-Delegate only when all are true:
-
-- The user explicitly requested or permitted subagents, delegation, or parallel work.
-- The active runtime exposes an Explore/delegation capability.
-- At least two non-overlapping scopes have useful independent work.
-
-If any condition is false, continue in the main agent with scoped `rg`, file
-listing, and targeted reads. Do not ask for delegation merely to complete an
-ordinary focused scout.
-
-### 4. Divide And Scout
-
-For local scouting, search the shortlisted scopes sequentially and stop when the
-question is answered. For delegated scouting, load
-`./references/internal-inspection.md`, split by logical boundaries, and ensure
-no overlap.
-
-- Skip task registration for two or fewer agents.
-- For three or more agents, use the live task/plan surface when available.
-- Prompt each agent with exact directories/files and a read-only boundary.
-
-### 5. Collect Results
-- Timeout: 3 minutes per agent (skip non-responders; log in report)
-- Update live task/plan state when one was used; aggregate; list unresolved questions at end
-
-## Report Format
-
-```markdown
-# Scout Report
-
-## Relevant Files
-- `path/to/file.ts` - Brief description
-- ...
-
-## Patterns
-- Key patterns observed
-
-## Unresolved Questions
-- Any gaps in findings
-```
-
-## Rules
-
-- Keep scope narrow. Do not use `cf:scout` as a runtime policy engine.
-- Prefer listing files first, then reading only the shortlisted files.
-- Never encourage scanning ignored/generated/sensitive areas from the no-scan list.
-- Keep reports concise and actionable.
-- Ensure no overlap between agent scopes.
-- Skip non-responding agents, do not retry.
-
-## References
-
-- `./references/internal-inspection.md` - Conditional Explore delegation

package/src/claude/skills/loop/SKILL.md

@@ -1,114 +0,0 @@
----
-name: cf:loop
-description: "Run an explicit, bounded optimization loop against a numeric metric while a separate correctness guard protects the result."
-user-invocable: true
-when_to_use: "Use only when the user explicitly requests measurable iterative optimization and supplies a safe Metric and Guard contract."
-category: utilities
-keywords: [loop, optimization, benchmark, metric, experiment]
-argument-hint: "<goal>"
-metadata:
-  author: haposoft
-  version: "1.0.0"
----
-# Loop — bounded metric optimization
-
-Loop is explicit-only. Never auto-route ordinary implementation, debugging, or
-research into Loop. It optimizes one numeric outcome under a separate correctness
-Guard; it does not guarantee improvement or replace Test/Review.
-
-Live-agent adherence to this written contract is `[UNPROVEN]` without a host run.
-The safety boundary is cooperative: commands must already be trusted by the user
-or repository. No instruction-only workflow can contain a malicious executable
-without an OS sandbox.
-
-## 1. Preflight before mutation
-
-Load `references/metric-and-guard-contract.md` and freeze every field before any
-worktree, process, patch, or file mutation:
-
-- Goal and canonical repository root.
-- Scope: contained regular tracked text paths; symlink, untracked, binary, and
-  submodule policy. Default is reject each unsupported kind.
-- Pinned base OID plus primary tracked/untracked status. Reject dirty in-scope
-  state; record but never import or clean out-of-scope dirt.
-- Metric argv, unit, `higher|lower`, sample count, IEEE-754 binary64 numeric and
-  rounding policy, fixed aggregation/noise rule, minimum delta, timeout, and
-  reproducible baseline environment.
-- Distinct immutable Guard argv and timeout for code mutation. Metric and Guard
-  may not be the same command or validate the same sole outcome.
-- Frozen positive iteration and wall-clock budgets; explicit success,
-  no-improvement, drift, failure, timeout, and cancellation stops.
-- Unique run identity, exact disposable root, ownership marker, upfront cleanup
-  consent, handoff mode/destination, retention, and cleanup owner.
-
-Missing, ambiguous, unsafe, or non-reproducible input returns `BLOCKED` without
-mutation. A subjective score, a metric that can be edited by the loop, or code
-mutation without a distinct Guard is ineligible.
-
-## 2. Establish isolation and baseline
-
-Load `references/bounded-loop-protocol.md`. Create a never-reused canonical temp
-root and ownership marker, then add a detached Git worktree at the pinned OID.
-Do not create a branch or commit. Necessary common-Git-dir worktree metadata is
-the only allowed primary-repository metadata effect; primary worktree bytes,
-index, branch, and refs remain untouched.
-
-Screen each trusted command as an argv vector and run it with `cwd` fixed to the
-canonical detached root. The executable is a separately approved external
-realpath; only path-valued target arguments must resolve inside the detached
-root. Never use `eval`, `sh -c`, `bash -c`, `zsh -c`,
-`cmd /c`, PowerShell `-Command`, inline interpreter code, Git `-C`, `--git-dir`,
-`--work-tree`, destructive Git operations, path traversal, or an absolute target
-outside the detached root. Use a minimal fixed environment and redact secrets.
-
-Capture the complete detached-worktree tracked/untracked manifest before and
-after every Metric and Guard run, subtracting only an exact immutable cache
-allowlist frozen at preflight. Any other oracle mutation is drift. Establish
-baseline samples on pinned bytes before allowing a candidate.
-
-## 3. Iterate one attributable change
-
-For every iteration:
-
-1. Create a fresh unique detached worktree from pinned base and apply only the
-   accepted-best patch, if one exists. Never restore in place.
-2. Make exactly one bounded hypothesis change inside Scope. Multiple unrelated
-   changes are forbidden. Reject unexpected,
-   untracked, binary, symlink, submodule, or out-of-scope bytes.
-3. Fingerprint candidate bytes, run Metric samples, fingerprint again, then run
-   Guard on those identical bytes and fingerprint once more.
-4. Reject on nonzero exit, timeout, malformed/non-finite/multi-value output,
-   oracle mutation, Guard failure, or any source/environment/contract drift.
-5. Accept only when Guard passes and improvement over current best is strictly
-   greater than both the frozen minimum delta and calculated noise threshold.
-   Record the candidate as a base-bound accepted-best patch; otherwise discard
-   only that iteration's owned disposable environment.
-
-Do not edit Metric, Guard, tests, benchmarks, datasets, budgets, or thresholds
-to win; their frozen digests are revalidated before every candidate.
-Stop at the first budget, cancellation, drift, ownership, cleanup, or repeated
-no-improvement condition named in preflight.
-
-## 4. Failure and process ownership
-
-Launch every command in an isolated process group on POSIX or Job Object on
-Windows. If the runtime cannot terminate the whole process tree, refuse to run.
-On timeout/cancel, terminate, escalate to kill, reap, and verify quiescence before
-cleanup. Never reuse a timed-out path. If descendants, path ownership, or cleanup
-is uncertain, retain exact residue and return `BLOCKED`; never use
-`git reset --hard`, `git clean`, broad deletion, or unrelated recovery.
-
-## 5. Handoff
-
-Return baseline, best value/noise, the exact keep formula, accepted/rejected
-iteration ledger, Guard evidence, stop reason, remaining limits, and live-proof
-status. A successful handoff is a redacted tracked-text patch bound to base OID,
-complete scoped file manifest, and lowercase SHA-256. Reject secret-bearing,
-untracked, binary, incomplete, or stale output unless a separately approved
-bundle contract exists.
-
-Use only the preflight-selected handoff mode: inline ephemeral patch, or an exact
-user-approved path outside the primary worktree with retention and cleanup owner.
-Never apply, commit, push, merge, cherry-pick, deploy, publish, or write an
-artifact into the primary worktree implicitly. The user reviews and explicitly
-authorizes any later application through the normal Develop/Test/Review flow.