@minhduydev/mdpi 0.3.0

package/dist/template/.pi/prompts/init.md

@@ -0,0 +1,206 @@
+---
+description: Initialize project setup — AGENTS.md, planning context, user profile, and tech stack
+argument-hint: "[--deep] [--context|--user|--all] [--dry-run] [--help]"
+---
+
+# Init
+
+Initialize project setup. Run once per project.
+
+> **Next step for fresh projects:** `/create` to start first feature.
+> **Next step for existing codebases:** `/research` for deep codebase analysis, or just describe what you want to build.
+
+## Idempotency Rules
+
+| File | Rule |
+|------|------|
+| `AGENTS.md` | Improve in-place — never overwrite blindly |
+| `.pi/tech-stack.md` | Overwrite with detected values (auto-regenerated) |
+| `.pi/roadmap.md` / `.pi/state.md` | Skip if exists, ask before overwrite |
+| `.pi/user.md` | Skip if exists, ask before overwrite |
+
+## Parse Arguments
+
+| Argument   | Default | Description |
+|------------|---------|-------------|
+| `--deep`   | false   | Comprehensive research for AGENTS.md (~100+ tool calls). **Context-heavy** — prefer a dedicated session, or split across phases (history → structure → patterns) |
+| `--context`| false   | Init planning context (roadmap.md, state.md) |
+| `--user`   | false   | Init user profile (user.md) |
+| `--all`    | false   | Full init: AGENTS.md + context + user profile |
+| `--dry-run`| false   | Preview detection results without writing files |
+| `--help`   | false   | Show this usage |
+
+**Mode rules:**
+- No flags (default): Core project setup — AGENTS.md + tech-stack.md
+- `--context`: Planning context (roadmap.md, state.md)
+- `--user`: User profile (user.md)
+- `--all`: Everything
+- `--deep` applies to AGENTS.md generation only
+
+**Brownfield auto-detection:** Existing codebase = any `src/`, `lib/`, or `app/` directory with `.ts`, `.js`, `.tsx`, `.jsx`, `.py`, `.go`, or `.rs` files.
+
+**Mode 1 brownfield branch:** If brownfield auto-detected and no `--deep`/`--context` flag, before running default AGENTS.md generation, ask the user: "Detected existing codebase. (a) Deep-profile first — spawn parallel `subagent({ agent: "explore" })` + run `srcwalk`/`fallow` to enrich AGENTS.md and pre-fill context, or (b) continue with basic AGENTS.md only?" Default to (a) for repos with > 50 source files; (b) otherwise. Set `MODE:` in `.pi/state.md` accordingly (`greenfield` | `brownfield` | `mixed`). This closes the silent-greenfield-on-brownfield failure — never run the greenfield flow silently on an existing codebase.
+
+## Guard Phase
+
+Before initializing:
+- Check if `AGENTS.md` already exists — if yes, improve in-place, never overwrite blindly
+- Check if `.pi/tech-stack.md`, `.pi/roadmap.md`, `.pi/state.md`, `.pi/user.md` exist — ask before overwriting
+- Validate the project's build, test, lint commands before documenting them
+
+## Load Skills
+
+| Skill | When | Why |
+|-------|------|-----|
+| `context-engineering` | Always (Mode 1) | AGENTS.md structure, context hierarchy, rules file best practices |
+| `documentation-and-adrs` | Always (Mode 1) | Doc conventions, ADR format when architectural decisions arise |
+| `verification-before-completion` | Before writing AGENTS.md | Validate commands before documenting them |
+| `brainstorming` | Conditionally: when ambiguous requirements arise | Refine project vision before initializing |
+
+---
+
+## Mode 1: Core Setup (Default)
+
+### Phase 1: Detect Project
+
+Detect and validate:
+- Package manager and dependencies (with versions)
+- Build, test, lint, dev commands — **validate each actually works**
+- CI/CD configuration
+- Existing AI rules (`.cursor/rules/`, `.cursorrules`, `.github/copilot-instructions.md`)
+- Top-level directory structure
+
+With `--deep`:
+- Analyze git history (last 50 commits for patterns)
+- Map source directory structure and subsystem candidates
+- Identify common patterns (error handling, logging, data flow)
+- Detect testing patterns and coverage gaps
+
+### Phase 2: Preview Detection
+
+Show detected summary and ask for confirmation before writing. If `--dry-run`, stop here.
+
+### Phase 3: Create AGENTS.md
+
+Load `verification-before-completion` skill — validate all commands before documenting them.
+
+Create `./AGENTS.md` — target <60 lines (max 150). Include:
+- Tech stack with versions, file structure, validated commands
+- Code example from actual codebase
+- Testing conventions, boundaries, gotchas
+
+**Principles:** Examples > explanations. Pointers > copies. If AGENTS.md exists, improve it — don't overwrite blindly.
+
+**Architectural decisions:** If `--deep` surfaces a non-obvious architectural choice (framework selection, state strategy, data layer), load `documentation-and-adrs` and propose an ADR using `.pi/templates/adr.md`. Don't force it — only when a real decision worth recording exists.
+
+### Phase 4: Create tech-stack.md
+
+Write detected values to `.pi/tech-stack.md`. Then persist to long-term memory via the `memory` tool (pi-hermes-memory, action: `add`, target: `failure`, category: `convention`):
+
+- content: "Project initialized — [tech stack summary]"
+- (target `failure` holds ALL categorized memories; `convention` = project-specific setup norms)
+
+### Phase 5: Setup Fallow (if available)
+
+Check if fallow is available. If yes and no `.fallowrc.json` exists:
+
+```bash
+npx fallow init --quiet 2>/dev/null || echo "Fallow not available — skipped"
+```
+
+Report explicitly if skipped.
+
+---
+
+## Mode 2: Planning Context (`--context`)
+
+### Phase 1: Discovery (brownfield)
+
+If the project has existing code (see auto-detection above), spawn parallel codebase analysis via `subagent({ agent: "explore" })`.
+
+If greenfield (no existing code), skip to requirements gathering.
+
+### Phase 2: Requirements Gathering
+
+Ask questions:
+- What is the project vision? (1-2 sentences)
+- Who are the primary users?
+- What defines success?
+
+### Phase 3: Preview
+
+Show structured outline and ask for confirmation before writing.
+
+### Phase 4: Create Files
+
+Create `.pi/roadmap.md` and `.pi/state.md` from templates in `.pi/templates/`.
+
+---
+
+## Mode 3: User Profile (`--user`)
+
+### Phase 1: Gather Preferences
+
+Ask about identity, communication style, git workflow preferences.
+
+### Phase 2: Preview
+
+Show captured preferences summary and ask for confirmation.
+
+### Phase 3: Create user.md
+
+Write to `.pi/user.md` with the captured preferences.
+
+---
+
+## Failure Handling
+
+| Scenario | Action |
+|----------|--------|
+| Command validation fails | Report which command failed with actual error |
+| AGENTS.md already exists | Improve in-place, don't overwrite blindly |
+| Fallow not available | Skip fallow setup, note in output |
+| Tech stack detection ambiguous | Ask user to confirm, don't guess |
+
+## Stop Conditions
+
+- User says no to AGENTS.md confirmation → stop, report detection only
+- Roadmap/state/user.md exists and user says no to overwrite → skip, report
+- AGENTS.md exceeds 150 lines → trim before writing
+- Command validation fails → stop, report which command failed
+
+## Output
+
+Report what was created:
+1. AGENTS.md (if core setup ran)
+2. tech-stack.md (if core setup ran)
+3. roadmap.md + state.md (if `--context`)
+4. user.md (if `--user`)
+5. Recommended next command: `/create` to start first feature, or `/research` to explore.
+
+---
+
+### Platform-Specific Skills
+
+If you use a platform-specific technology, the matching skill is auto-discovered in `.pi/skills/`. Load via `/skill:<name>` when needed:
+
+- `cloudflare` — Cloudflare Workers, Pages, KV, D1, R2, AI
+- `react-best-practices` — React/Next.js performance patterns
+- `supabase-postgres-best-practices` — Postgres query optimization
+- `swiftui-expert-skill` — SwiftUI development
+- `swift-concurrency` — Swift async/await patterns
+- `core-data-expert` — Core Data on iOS/macOS
+
+## Related Commands
+
+| Need              | Command       |
+| ----------------- | ------------- |
+| Create first spec | `/create`     |
+| Research codebase | `/research`   |
+| Plan feature      | `/plan`       |
+
+## Related Skills
+
+- `context-engineering` — AGENTS.md structure and context hierarchy design
+- `documentation-and-adrs` — doc conventions and ADR format
+- `verification-before-completion` — command validation discipline

package/dist/template/.pi/prompts/loop-check.md

@@ -0,0 +1,87 @@
+---
+description: NO-GO qualification gate — decide whether a task is safe to run as an unattended loop
+argument-hint: "<task description> [--help]"
+---
+
+# Loop-Check: $ARGUMENTS
+
+Qualify a task before it is ever scheduled as an unattended loop. Emit a single GO/NO-GO verdict with the cited condition that produced it. This prompt is the gate *before* the gate — it refuses work a loop cannot honestly judge.
+
+> Refuse first, test second, checklist last. Never let "looks automatable" override the refuse-list.
+
+## Parse Arguments
+
+| Argument       | Default  | Description                                      |
+| ------------- | -------- | ------------------------------------------------ |
+| `<task>`      | required | The task proposed for unattended looping          |
+| `--help`      | false    | Show this usage                                   |
+
+## Step 1 — Refuse-List (Immediate NO-GO)
+
+If the task touches any of these, **stop here** and emit NO-GO. Do not proceed to the 2-condition test.
+
+- **auth** — login, sessions, tokens, permissions, auth flows, auth module rewrites
+- **payments** — billing, checkout, refunds, subscriptions, payment provider integration
+- **architecture** — framework/library switches, schema migrations, new DB tables, new services, breaking API changes
+
+> Rationale: these need human judgement a loop cannot provide. The refuse-list is the honest ceiling, not a configurable preference.
+
+If a refuse-list category is hit → `CONDITION: <refused category> refused` (e.g. `CONDITION: architecture refused`).
+
+## Step 2 — The 2-Condition Test
+
+Both conditions must hold. If either fails, emit NO-GO citing the failed condition.
+
+1. **Verification is automated.** There exists an objective command whose **exit code** decides pass/fail — `npm test`, `tsc --noEmit`, `eslint`, a custom gate script. The stop condition is computational (exit code), never an LLM's opinion. If the only "check" is "the agent says it looks good" → FAIL.
+2. **The token budget absorbs the waste.** The cost of one wasted run (gate fails, no-op, early-exit) is small enough that running on the scheduled cadence does not blow the budget. If a single failed run is expensive (large model, long context, many turns) and there is no per-run cap → FAIL.
+
+If condition 1 fails → `CONDITION: verification not automated (no exit-code gate)`.
+If condition 2 fails → `CONDITION: budget does not absorb waste (uncapped/expensive failed run)`.
+
+## Step 3 — 30-Second Checklist
+
+Confirm every item. Any miss → NO-GO citing the missing item.
+
+- [ ] **Objective gate exists** — a named command with a pass = exit 0 contract (write it down; "tests" without a command is not a gate).
+- [ ] **Hard stop exists** — a non-negotiable exit condition: repeated gate failure, budget cap hit, or forbidden path touched. The loop exits; it does not improvise.
+- [ ] **Human approves merge/deploy/dependency changes** — the loop may open PRs and stage work; a human merges, deploys, and changes deps. No auto-merge.
+
+Missing gate → `CONDITION: no objective gate`.
+Missing hard stop → `CONDITION: no hard stop`.
+No human-approval boundary → `CONDITION: no human-approval boundary on merge/deploy/deps`.
+
+## Step 4 — Emit Verdict
+
+Output **exactly** these two lines and nothing else as the decision:
+
+```
+VERDICT: GO
+CONDITION: verification automated + budget absorbs waste
+```
+
+or
+
+```
+VERDICT: NO-GO
+CONDITION: <cited condition from Step 1, 2, or 3>
+```
+
+- `VERDICT` is `GO` or `NO-GO` — no other values.
+- `CONDITION` cites the specific condition that produced the verdict. For GO, cite both passing conditions. For NO-GO, cite the first failing condition (Step 1 overrides Step 2 overrides Step 3).
+- Do not add rationale, recommendations, or next steps after the verdict lines. The verdict is the contract.
+
+## Worked Examples
+
+- **"triage failing CI nightly"** with `npm test` gate, no-op early-exit <5k tokens → `VERDICT: GO` / `CONDITION: verification automated + budget absorbs waste`
+- **"rewrite auth module"** → `VERDICT: NO-GO` / `CONDITION: auth refused`
+- **"migrate from REST to GraphQL"** → `VERDICT: NO-GO` / `CONDITION: architecture refused`
+- **"keep docs in sync with code weekly"** with no gate command → `VERDICT: NO-GO` / `CONDITION: verification not automated (no exit-code gate)`
+
+## Related
+
+| Companion | Role |
+|---|---|
+| `loop-engineering` skill | The 2-condition test, refuse-list, and 5 building blocks this gate codifies |
+| `/loop-init` | Scaffold `.pi/loops/<name>/` once a task is GO |
+| `/loop-review` | Maker/checker verification — the gate *during* a run |
+| `loop-audit` | Readiness scoring (L0-L3) for an already-GO loop |

package/dist/template/.pi/prompts/loop-init.md

@@ -0,0 +1,157 @@
+---
+description: Scaffold a new unattended loop at .pi/loops/<name>/ with VISION, STATE, and a per-loop SKILL stub
+argument-hint: "<name> [--help]"
+---
+
+# Loop Init: $ARGUMENTS
+
+Scaffold a new loop-engineering harness at `.pi/loops/<name>/` from the templates shipped in `.pi/templates/`. Run once per loop. The scaffold is the contract + ledger + procedure the orchestrator (T9/T10) drives unattended.
+
+> **Prerequisite:** `/loop-check <task>` returned GO. If not, refuse and tell the user to qualify the task first.
+
+## Parse Arguments
+
+| Argument | Default   | Description                                  |
+| -------- | --------- | -------------------------------------------- |
+| `<name>` | required  | Loop slug; used as directory name `loop/<name>/<ts>` branch prefix |
+| `--help` | false     | Show this usage                              |
+
+**Validation:** `<name>` must be a filesystem-safe slug (`^[a-z0-9][a-z0-9-]*$`, lowercase). Reject names containing `/`, spaces, or upper-case. Trim surrounding whitespace before use.
+
+## When to Use
+
+- You want to start a new unattended loop (nightly CI triage, dependency bumps, doc sync, PR babysitting).
+- `/loop-check <task>` already returned GO (verification automated + token budget absorbs waste + human approves merge/deploy/deps).
+- You need the contract (VISION.md), dedup ledger (STATE.json + STATE.md), and per-loop procedure (SKILL.md) that the orchestrator will drive.
+
+Do NOT use for:
+- One-off tasks (use `/create` or `/fix`).
+- Tasks `/loop-check` refused (auth, payments, architecture) — refuse here too.
+
+## The Scaffold Steps
+
+### 1. Create the loop directory
+
+Create `.pi/loops/<name>/` (parent `.pi/loops/` may not exist yet — create it).
+
+### 2. Copy the four artifacts
+
+Copy map (exact source → destination):
+
+| Source (template)                         | Destination                          | Purpose                                   |
+| ----------------------------------------- | ------------------------------------ | ----------------------------------------- |
+| `.pi/templates/loop-vision.md`            | `.pi/loops/<name>/VISION.md`         | Anti goal-drift contract (FR2)            |
+| `.pi/templates/loop-state.md`             | `.pi/loops/<name>/STATE.md`           | Human-readable state mirror (FR3)        |
+| `.pi/templates/loop-state.json`           | `.pi/loops/<name>/STATE.json`         | Machine dedup ledger (FR3, authoritative) |
+| (new stub)                                | `.pi/loops/<name>/SKILL.md`           | Per-loop procedure (classification + fix patterns) |
+
+Copy the three templates byte-for-byte first (placeholders intact), then fill placeholders in the copied files. The `SKILL.md` stub is not a template — write a minimal seed:
+
+```markdown
+---
+name: <name>
+description: Per-loop procedure for <name> — classify, fix, escalate
+---
+
+# Loop Procedure: <name>
+
+Reread `VISION.md` at the start of every run. Do not act outside it.
+
+## Procedure
+
+1. Reread `VISION.md` (boundaries authoritative).
+2. Read `STATE.json` — build the dedup set from `processed[]`.
+3. Fetch candidate items (per the loop's source: CI runs, PRs, packages, commits).
+4. For each item: skip if in `processed[]`; else classify → fix / escalate / reject.
+5. Run the Gate command (the ```bash block directly under `## Gate` in VISION.md); ship only on exit 0.
+6. Append to `STATE.json.processed[]`, `completed[]`, `escalated[]`, or `failures[]`.
+7. Enforce hard stops (see VISION.md "Hard stops").
+
+## Classification rubric
+
+<!-- Fill by hand after supervising the first manual runs. -->
+
+## Fix patterns
+
+<!-- Fill by hand as repeatable fixes are discovered. -->
+```
+
+### 3. Fill `<name>` placeholders
+
+In the copied `VISION.md`, `STATE.md`, and `STATE.json`, replace every placeholder occurrence with the actual loop name:
+
+- `<loop-name>` → `<name>`
+- Leave human-fill placeholders (`[Owner]`, `[Date]`, `[cron expression or "manual"]`, `[Allowed action 1]`, `<GATE_COMMAND>`, etc.) as bracketed prompts for the user to edit by hand — do NOT invent values.
+
+Tell the user explicitly which placeholders still need their input.
+
+### 4. Print the rollout order
+
+After scaffolding, print this rollout order so the user knows the path from scaffold to unattended run:
+
+```
+Rollout order:
+  1. check      — /loop-check <task> (already GO; re-run if scope changes)
+  2. init       — /loop-init <name>   (this step — scaffold created)
+  3. supervise  — run the loop's SKILL.md manually in a session; refine classification/fix patterns
+  4. wire       — copy loop-orchestrator.ts/.sh + loop-github-action.yml; set cadence + gate + scope
+  5. run        — schedule cron/launchd (local) or GitHub Actions `on: schedule` (CI); loop runs unattended
+  6. review     — /loop-review <name> for interactive maker/checker verify
+  7. audit/cost — loop-audit scores readiness (L0-L3); track cost-per-accepted-change; kill if acceptance < 50%
+```
+
+## Idempotency Guard
+
+Before writing anything:
+
+1. Check whether `.pi/loops/<name>/` already exists.
+2. **If it exists:** STOP. Do not overwrite. Ask the user:
+   > `.pi/loops/<name>/` already exists. Overwrite all files (VISION.md, STATE.md, STATE.json, SKILL.md)? This destroys any hand-edited contract/state. (y/N)
+3. **Refuse overwrite without explicit confirmation.** On `N` or no answer, abort and report the existing tree without modifying it.
+4. **If it does not exist:** proceed with the scaffold.
+
+This guard protects hand-edited VISION.md contracts and STATE.json dedup ledgers from being clobbered by a re-run.
+
+## Output
+
+Print:
+
+1. **Created tree** (e.g.):
+   ```
+   .pi/loops/<name>/
+   ├── VISION.md   (contract — fill [Owner], [Date], cadence, Scope, Gate)
+   ├── STATE.md    (human-readable state mirror)
+   ├── STATE.json  (machine dedup ledger — authoritative)
+   └── SKILL.md    (per-loop procedure — fill classification + fix patterns by hand)
+   ```
+2. **Rollout order** (the 7-step block above).
+3. **Placeholders still needing input** (list each `[...]` / `<GATE_COMMAND>` the user must fill by hand, with file:line where useful).
+4. **Next step:** `supervise` — run the loop's `SKILL.md` manually in a session and refine classification/fix patterns before wiring the orchestrator.
+
+## Failure Handling
+
+| Scenario                              | Action                                                        |
+| ------------------------------------- | ------------------------------------------------------------ |
+| `<name>` missing or invalid slug      | Abort with the validation regex and an example               |
+| `.pi/loops/<name>/` exists, no confirm| Abort, print existing tree, do not modify                     |
+| Template missing from `.pi/templates/`| Abort, list which template is missing (T2 must be shipped first) |
+| `<name>` would collide with a reserved path | Abort, suggest an alternate slug                        |
+
+## Stop Conditions
+
+- `<name>` invalid → stop, report the regex.
+- Directory exists and user declines overwrite → stop, report existing tree.
+- Any of the three templates missing → stop, report (T2 prerequisite unmet).
+
+## Related Commands
+
+| Need                     | Command           |
+| ------------------------ | ----------------- |
+| Qualify a task first     | `/loop-check`     |
+| Review a running loop    | `/loop-review`    |
+| Audit loop readiness     | `loop-audit`      |
+
+## Related Skills
+
+- `loop-engineering` — 2-condition test, 5 building blocks, VISION/state contract, failure modes
+- `planning-and-task-breakdown` — decompose the loop's procedure into verifiable steps

package/dist/template/.pi/prompts/loop-review.md

@@ -0,0 +1,90 @@
+---
+description: Maker/checker review for a loop — spawns a verifier subagent that runs the gate and inspects the diff, then emits ACCEPT/REJECT with evidence
+argument-hint: "<loop-name> [--help]"
+---
+
+# Loop Review: $ARGUMENTS
+
+Run the maker/checker gate for `<loop-name>`: dispatch an independent **verifier subagent** that runs the `## Gate` command from the loop's `VISION.md` via bash and reads the exit code, inspect the working-tree diff for scope creep and forbidden touches, then emit exactly `DECISION: ACCEPT|REJECT` plus `EVIDENCE:`. The maker never self-approves — default to **REJECT** on any uncertainty.
+
+## When to Use
+
+- After a loop's maker (the `pi -p` capability-deprived agent) reports its work done and before the orchestrator ships.
+- Interactive `/loop-review <loop-name>` to manually gate a loop cycle.
+- Whenever you need an independent, computational gate decision — never trust the maker's self-report.
+- Do **not** use for the orchestrator's own gate run (FR7); this prompt is the interactive maker/checker wrapper around the same gate-parse contract.
+
+## The Verifier Subagent
+
+Dispatch a **verifier** as an independent subagent so the maker cannot influence or self-approve the decision. The verifier's sole job: run the gate, read the exit code, collect diff findings, return raw evidence.
+
+### Dispatch
+
+Use the `subagent` tool with **type `review`**. Pass a prompt that instructs the verifier to:
+
+1. Read `.pi/loops/<loop-name>/VISION.md` (or wherever the loop's VISION lives for this run) from disk — do not trust context-supplied copies.
+2. Extract the gate command using the **exact gate-parse contract** below.
+3. Run the gate via bash and capture the **exit code** (the computational signal — never an opinion).
+4. Inspect the working-tree/staged diff for scope creep and forbidden paths (see The Diff Check).
+5. Return raw evidence only: exit code, gate command run, diff findings (paths touched, any forbidden hits). **No verdict** — the maker (this agent) issues the verdict.
+
+### Gate-parse contract (must match T2 exactly)
+
+Extract the gate command from `VISION.md` as: **the SINGLE fenced ```bash block located directly under the `## Gate` heading** — require **EXACTLY ONE** such block directly under `## Gate` (zero or more-than-one → REJECT / hard fail). Take that single block's content, strip trailing whitespace, run it via `bash -c "<command>"`, and read the exit code.
+
+- `exit 0`   → PASS → ship (orchestrator pushes `loop/<name>/<ts>` + opens PR)
+- non-zero   → FAIL → no ship; record failure in `STATE.json.failures[]`; cleanup worktree
+
+The gate decision is **computational (exit code), never an LLM's opinion**. If `## Gate` is missing, the fenced block is empty, or the block count under `## Gate` is not exactly one (zero or more-than-one), treat that as a hard fail: emit `DECISION: REJECT` with `EVIDENCE: gate not parseable` and do not run anything.
+
+### Evidence to collect from the verifier
+
+- The exact gate command extracted (verbatim, after whitespace strip).
+- The bash exit code (integer).
+- stdout/stderr tail (last ~20 lines) — enough to cite a concrete failure.
+- List of paths touched in the diff (added/modified/deleted).
+- Any forbidden-path hits (see The Diff Check).
+
+## The Diff Check
+
+Independently of the verifier (or have the verifier report and you confirm), inspect the diff against the loop's declared boundaries.
+
+### Scope creep
+
+Compare every path in the diff to `## Scope` and `## Out-of-scope` in `VISION.md`. Any touched path that is not clearly inside `## Scope` is scope creep → REJECT. When a path is ambiguous (not explicitly listed in either section), treat it as out-of-scope and escalate, do not approve.
+
+### Forbidden touches (always REJECT)
+
+Regardless of scope wording, REJECT immediately if the diff touches any of:
+
+- `VISION.md` (the loop contract itself — protected path).
+- The gate command / gate script referenced by `## Gate`.
+- `package.json`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, or any lockfile.
+- Any path under `## Out-of-scope` in `VISION.md`.
+- Auth, payments, or architectural-decision files (per `## Human-approval-required`).
+
+Cite the offending path verbatim in `EVIDENCE:`.
+
+## Output Contract
+
+Emit exactly two lines (no prose around them, no extra fields):
+
+```
+DECISION: ACCEPT|REJECT
+EVIDENCE: <exit code + diff findings>
+```
+
+- `DECISION: ACCEPT` only when the verifier reports **exit code 0** AND the diff has zero scope-creep and zero forbidden-touch findings.
+- `DECISION: REJECT` otherwise. `EVIDENCE:` must cite the concrete signal — e.g. `gate exit 1: npm test failed (see stderr tail)` or `forbidden touch: package.json` or `scope creep: src/auth/* not in VISION.md Scope`.
+- The orchestrator consumes these two lines machine-readably; do not decorate them with markdown, prefixes, or commentary.
+
+## Default-Reject Rule
+
+**The maker never self-approves.** The verdict is issued here (the maker/checker prompt), but the *evidence* comes from the independent verifier subagent — never from the maker's own self-report. On any uncertainty — gate not parseable, exit code unreadable, diff not inspectable, scope ambiguous, verifier subagent failed to return — emit:
+
+```
+DECISION: REJECT
+EVIDENCE: <what was uncertain — e.g. "verifier did not return exit code" / "scope ambiguous for src/foo.ts">
+```
+
+Default-reject is the safe state; the orchestrator records it and retries or escalates. Never substitute opinion for the computational exit-code signal.