dev-loops 0.1.0

package/skills/dev-loop/scripts/render-template.mjs

@@ -0,0 +1,82 @@
+import { mkdir, readFile, writeFile } from "node:fs/promises";
+import path from "node:path";
+import { pathToFileURL } from "node:url";
+
+export function renderTemplate(template, variables) {
+  if (typeof template !== "string") {
+    throw new Error("template must be a string");
+  }
+
+  return template.replace(/{{\s*([a-zA-Z0-9_-]+)\s*}}/g, (match, key) => {
+    if (!(key in variables)) {
+      throw new Error(`Missing template variable: ${key}`);
+    }
+
+    return String(variables[key]);
+  });
+}
+
+export async function materializeTemplate(templatePath, outputPath, variables) {
+  const template = await readFile(templatePath, "utf8");
+  const content = renderTemplate(template, variables);
+  await mkdir(path.dirname(outputPath), { recursive: true });
+  await writeFile(outputPath, content, "utf8");
+  return { templatePath, outputPath, content };
+}
+
+export function parseCliArgs(argv) {
+  const args = [...argv];
+  let templatePath;
+  let outputPath;
+  let variables = {};
+
+  while (args.length > 0) {
+    const token = args.shift();
+
+    if (token === "--template") {
+      templatePath = args.shift();
+      continue;
+    }
+
+    if (token === "--output") {
+      outputPath = args.shift();
+      continue;
+    }
+
+    if (token === "--vars") {
+      variables = JSON.parse(args.shift() ?? "{}");
+      continue;
+    }
+
+    throw new Error(`Unknown argument: ${token}`);
+  }
+
+  if (!templatePath) {
+    throw new Error("Missing required --template <path> argument");
+  }
+
+  if (!outputPath) {
+    throw new Error("Missing required --output <path> argument");
+  }
+
+  return { templatePath, outputPath, variables };
+}
+
+export async function runCli(argv = process.argv.slice(2)) {
+  const options = parseCliArgs(argv);
+  const result = await materializeTemplate(options.templatePath, options.outputPath, options.variables);
+  process.stdout.write(
+    `${JSON.stringify({ ok: true, templatePath: result.templatePath, outputPath: result.outputPath })}\n`,
+  );
+}
+
+const invokedAsScript = process.argv[1]
+  ? import.meta.url === pathToFileURL(process.argv[1]).href
+  : false;
+
+if (invokedAsScript) {
+  runCli().catch((error) => {
+    process.stderr.write(`${error instanceof Error ? error.message : String(error)}\n`);
+    process.exitCode = 1;
+  });
+}

package/skills/dev-loop/scripts/render-template.test.mjs

@@ -0,0 +1,63 @@
+import test from "node:test";
+import assert from "node:assert/strict";
+import { mkdtemp, readFile, rm, writeFile } from "node:fs/promises";
+import os from "node:os";
+import path from "node:path";
+
+import { materializeTemplate, parseCliArgs, renderTemplate } from "./render-template.mjs";
+
+test("render-template renders placeholders deterministically", () => {
+  assert.equal(
+    renderTemplate("# Phase {{phase}} variant {{variant}}\n", {
+      phase: "phase-0",
+      variant: "a",
+    }),
+    "# Phase phase-0 variant a\n",
+  );
+});
+
+test("render-template throws on missing variables", () => {
+  assert.throws(() => renderTemplate("Hello {{name}}", {}), /missing template variable: name/i);
+});
+
+test("render-template materializes a template file", async () => {
+  const tempDir = await mkdtemp(path.join(os.tmpdir(), "dev-loop-render-template-"));
+  const templatePath = path.join(tempDir, "template.md");
+  const outputPath = path.join(tempDir, "out", "variant-a.md");
+
+  try {
+    await writeFile(templatePath, "# {{phase}}\n{{body}}\n", "utf8");
+    await materializeTemplate(templatePath, outputPath, {
+      phase: "phase-0",
+      body: "hello",
+    });
+
+    const output = await readFile(outputPath, "utf8");
+    assert.equal(output, "# phase-0\nhello\n");
+  } finally {
+    await rm(tempDir, { recursive: true, force: true });
+  }
+});
+
+test("render-template parses cli args", () => {
+  assert.deepEqual(
+    parseCliArgs([
+      "--template",
+      "templates/x.md",
+      "--output",
+      "tmp/x.md",
+      "--vars",
+      '{"phase":"phase-0"}',
+    ]),
+    {
+      templatePath: "templates/x.md",
+      outputPath: "tmp/x.md",
+      variables: { phase: "phase-0" },
+    },
+  );
+});
+
+test("render-template requires template and output args", () => {
+  assert.throws(() => parseCliArgs(["--output", "tmp/x.md"]), /missing required --template/i);
+  assert.throws(() => parseCliArgs(["--template", "templates/x.md"]), /missing required --output/i);
+});

package/skills/dev-loop/templates/bootstrap-agents.md

@@ -0,0 +1,26 @@
+# AGENTS.md
+
+## Project contract
+
+This repository uses the `dev-loop` skill as the primary implementation workflow.
+
+The skill may be provided repo-locally or globally; this contract does not assume a local skill path.
+
+## Working agreement
+
+- Work test-first for all non-trivial logic.
+- Maintain at least 90% coverage for lines, statements, functions, and branches.
+- Implement one phase at a time.
+- Use fan-out / fan-in / review / merge before implementing each phase.
+- Keep logs under `tmp/` in deterministic phase-scoped paths.
+- Use local branches and small commits only after local verification.
+- Do not assume GitHub PR or issue workflows.
+
+## Core guard rails
+
+- KISS
+- SRP
+- YAGNI
+- strict TypeScript
+- thin runtime glue
+- no production reliance on Pi private internals

package/skills/dev-loop/templates/bootstrap-implementation-state.md

@@ -0,0 +1,31 @@
+# Implementation state
+
+## Status
+
+Preparation is in place. Implementation has not started.
+
+## Current source of truth
+
+- Product plan: [Project Plan](../../../PLAN.md)
+- Durable phase plans: [Phase Plan](../../../docs/phases/)
+- Execution skill: `dev-loop`
+- Repo contract: [Agent Instructions](../../../AGENTS.md)
+- Workflow explainer: [Implementation Workflow](../../../docs/IMPLEMENTATION_WORKFLOW.md)
+- tmp index for fresh-context inspection if present locally: `tmp/phases/index.json`
+
+## Next action for a fresh session
+
+If the user says **"start implementation"**:
+
+1. read [Project Plan](../../../PLAN.md)
+2. load the `dev-loop` skill
+3. read [Agent Instructions](../../../AGENTS.md) if it exists
+4. read [Implementation Workflow](../../../docs/IMPLEMENTATION_WORKFLOW.md)
+5. read the current durable phase plan under `docs/phases/` if it exists
+6. inspect `tmp/phases/` only if it exists locally and is relevant
+7. read this file
+8. start with the next unfinished phase only
+
+## Next unfinished phase
+
+Phase 0 — define the workflow convention, durable phase-plan format, and initial package boundary.

package/skills/dev-loop/templates/bootstrap-implementation-workflow.md

@@ -0,0 +1,17 @@
+# Implementation workflow
+
+This file is optional. The primary execution entrypoint is the `dev-loop` skill.
+
+Use this file for repo-specific workflow notes that complement the skill.
+
+## Defaults
+
+- one phase at a time
+- [Project Plan](../../../PLAN.md) holds roadmap/product truth
+- `docs/phases/phase-<n>.md` holds the durable plan for the active phase
+- `tmp/phases/phase-<n>/` holds temporary local execution artifacts, reviews, and logs
+- fan-out / fan-in / review / merge before coding
+- test-first
+- deterministic tmp logging
+- local validation before phase completion
+- local branches and small commits only after verification

package/skills/dev-loop/templates/dev-mode-retrospective.md

@@ -0,0 +1,15 @@
+# Phase {{phase}} dev-mode retrospective
+
+## Iteration reviewed
+
+## What the loop did well
+
+## What created friction or waste
+
+## Prompt follow-ups required
+
+## Prompt and workflow changes applied
+
+## Validation of the follow-up changes
+
+## Next dev-mode watchpoints

package/skills/dev-loop/templates/dev-mode-review.md

@@ -0,0 +1,17 @@
+# Phase {{phase}} dev-mode review
+
+Optional analytical notes that support the required [Dev Mode Retrospective](./dev-mode-retrospective.md).
+
+## Iteration reviewed
+
+## Artifact inputs reviewed
+
+## What the skill did well
+
+## Friction and failure patterns
+
+## Deterministic tooling gaps
+
+## Recommended skill or workflow changes
+
+## Decision

package/skills/dev-loop/templates/dev-mode-skill-changes.md

@@ -0,0 +1,11 @@
+# Phase {{phase}} dev-mode skill changes
+
+## Trigger
+
+## Changes made
+
+## Why these changes were chosen
+
+## Validation
+
+## Remaining gaps

package/skills/dev-loop/templates/merged-phase-plan.md

@@ -0,0 +1,19 @@
+# Phase {{phase}} merged plan
+
+## Selected direction
+
+## Exact scope
+
+## Explicit non-goals
+
+## Tests to write first
+
+## Implementation order
+
+## Validation steps
+
+## Acceptance criteria
+
+## Definition of done
+
+## Risks / watchpoints

package/skills/dev-loop/templates/phase-doc.md

@@ -0,0 +1,27 @@
+# {{phase}} durable plan
+
+## Status
+
+Planning
+
+## Objective
+
+## Why this phase exists now
+
+## In scope
+
+## Explicit non-goals
+
+## Acceptance criteria
+
+## Definition of done
+
+## Validation approach
+
+## Durable decisions
+
+## Open questions
+
+## Links to execution artifacts
+
+- local execution artifacts may exist under `tmp/phases/{{phase}}/`

package/skills/dev-loop/templates/phase-summary.md

@@ -0,0 +1,13 @@
+# Phase {{phase}} summary
+
+## What was planned
+
+## What was implemented
+
+## Tests added or updated
+
+## Validation results
+
+## Decisions recorded
+
+## Follow-ups for next phase

package/skills/dev-loop/templates/phase-variant.md

@@ -0,0 +1,15 @@
+# Phase {{phase}} variant {{variant}}
+
+## Intent
+
+## Phase scope
+
+## Files/modules touched
+
+## Tests to add first
+
+## Implementation order
+
+## Acceptance criteria
+
+## Risks / non-goals

package/skills/dev-loop/templates/retrospective.md

@@ -0,0 +1,11 @@
+# Phase {{phase}} retrospective
+
+## What worked well
+
+## What caused friction or waste
+
+## Fan-out / fan-in / review loop effectiveness
+
+## What to change in the skill or workflow next time
+
+## What a fresh session should know before the next phase

package/skills/dev-loop/templates/review.md

@@ -0,0 +1,32 @@
+# Phase {{phase}} merged-plan review
+
+## Review verdict
+
+## Scope overreach check
+
+## Default pre-approval gate
+<!-- Resolve angles from config: resolveGateAngles(config, "preApproval") -->
+- configured angle checks: add one bullet per configured pre-approval angle (for example `dry`, `kiss`, `yagni`, `srp`, `soc` when defaults apply)
+- fallback note: if parallel execution of the configured review angles is impractical, record why and confirm all configured angles were still covered
+
+## Additional design-principle check (SRP, etc.)
+
+## Test and validation check
+
+## Module boundary check
+
+## Pi API / runtime coupling check
+
+## Acceptance criteria clarity check
+
+## Definition-of-done clarity check
+
+## Review-surface completeness check
+- review-surface completeness: confirm the merged plan and durable phase doc both carry stable definition-of-done output
+- confirm the review surface checks the planned definition of done instead of only acceptance criteria
+
+## RFC-escalation sanity check
+- confirm RFC-worthy technical decisions are escalated to the parent session / human operator
+- confirm the parent-session receiving boundary and decision ownership remain explicit
+
+## Required revisions

package/skills/dev-loop/templates/ui-vision-review.md

@@ -0,0 +1,55 @@
+# Vision-model UI review prompt template
+
+Use this template when `uiReviewMode` is `vision`.
+
+You are a vision-capable UI reviewer (model: `gpt-5.4`) reviewing deterministic named-state artifacts produced by `captureNamedUiState()`.
+
+## Inputs
+
+- `acceptanceCriteria`: required list of UI acceptance criteria
+- `reviewBrief`: required short focus brief
+- `artifactBundle.sliceId`: required UI slice id
+- `artifactBundle.namedStates[]`: required list of named states
+  - `stateName`
+  - `screenshotPath` (must point to `screenshot.png`)
+  - `statePath` (must point to `state.json`)
+
+## Review policy
+
+1. Fail closed when required inputs are missing, ambiguous, or unreadable.
+2. Ground every finding in one or more `screenshotPath` and `statePath` references.
+3. Evaluate layout, hierarchy, spacing, clipping, overlap, contrast, callouts/highlighting, and state-transition clarity against the acceptance criteria and review brief.
+4. Return only deterministic findings; do not invent evidence that is not visible in artifacts.
+
+## Required output format
+
+Allowed enum values:
+- `outcome`: `"continue_ui_fix_loop"` | `"ui_review_satisfied"` | `"blocked_needs_human_decision"`
+- `severity`: `"high"` | `"medium"` | `"low"`
+
+`blockedReason` must always be present in the output. Set it to `null` unless `outcome` is `"blocked_needs_human_decision"`, in which case provide a non-empty string explaining the block reason.
+
+Return strict JSON with this shape (example uses concrete values):
+
+```json
+{
+  "outcome": "ui_review_satisfied",
+  "summary": "short overall verdict",
+  "findings": [
+    {
+      "severity": "medium",
+      "stateName": "named state label",
+      "evidence": {
+        "screenshotPath": "test-results/ui-smoke/<sliceId>/named-states/<state-slug>/screenshot.png",
+        "statePath": "test-results/ui-smoke/<sliceId>/named-states/<state-slug>/state.json"
+      },
+      "problem": "what is visually wrong or unclear",
+      "suggestedFix": "specific corrective action"
+    }
+  ],
+  "nextIterationFocus": [
+    "small, actionable UI fix target"
+  ],
+  "blockedReason": null
+}
+```

package/skills/docs/acceptance-criteria-verification.md

@@ -0,0 +1,21 @@
+# Acceptance Criteria Verification
+
+Extracted procedure for verifying issue acceptance criteria during the `pre_approval_gate`. Referenced from [Copilot PR Follow-up Skill](../copilot-pr-followup/SKILL.md#pre-approval-gate-contract).
+
+## Procedure
+
+Before posting the `pre_approval_gate` comment, verify every acceptance criteria checklist item in the issue linked to this PR:
+
+1. **Resolve the linked issue number deterministically:** use `gh pr view <pr-number> --repo <owner/name> --json closingIssuesReferences,body` and apply this decision tree: if there is exactly one closing issue reference, use it; else if there is exactly one PR-body `Closes #N` / `Fixes #N` pattern, use it; otherwise (zero or multiple candidates), post the gate comment with verdict `blocked` (gate cannot complete deterministically) rather than guessing.
+
+2. **Read the issue body:** `gh issue view <issue-number> --repo <owner/name> --json body`
+
+3. **Extract checklist items** from the **Acceptance criteria** section of the issue body (both `- [ ]` unchecked and `- [x]` already-checked items). Ignore checklist items from other sections (DoD, tasks, non-goals) that are not acceptance criteria.
+
+4. **Verify each AC item** against the proposed changes on the current PR head.
+
+5. **Update the issue body once:** compute the fully-updated issue body by replacing each verified item's `- [ ]` with `- [x]`, write it to a temporary file, and perform a single `gh issue edit <issue-number> --body-file <tmp-file> --repo <owner/name>`. Do not issue one edit per item; prefer `--body-file` over inline `--body` to avoid shell quoting/escaping hazards.
+
+6. **Post the gate comment:** always post a `pre_approval_gate` comment (the checkpoint verdict comment contract requires a visible comment even for non-`clean` verdicts). Use verdict `clean` only when all AC items are verified; use verdict `findings_present` when any AC item is not satisfied and requires follow-up fixes; use verdict `blocked` when the gate cannot complete deterministically (for example no linked issue, ambiguous issue linkage, or the issue body is unavailable). In all cases include a note on AC verification status.
+
+When the issue body has no AC checklist items, post the gate comment with verdict `findings_present` and note that fact explicitly rather than assuming satisfaction.

package/skills/docs/anti-patterns.md

@@ -0,0 +1,21 @@
+# Anti-patterns
+
+Canonical owner for anti-pattern guidance across all workflow families.
+
+## Core anti-patterns
+
+1. **Skipping fan-out/fan-in for non-trivial changes**: Do not implement directly without refinement when scope exceeds light-mode thresholds.
+2. **Routing review-only work through local_implementation**: Review-only comparison, synthesis, or consolidation must use `refiner` agent, not `dev-loop` + `local_implementation`.
+3. **Thin placeholder PR descriptions**: Always include change summary, scope/context, acceptance criteria, definition of done, non-goals, and `Closes #N`.
+4. **Merging directly to main without PR**: Use PR-based remote loop when practical.
+5. **Duplicate worktree paths**: Check `git worktree list` before creating new worktrees; reuse existing matching worktrees.
+6. **Main-checkout mutation**: Reserve main checkout for inspection/control; use `tmp/worktrees/` paths for mutation work.
+
+## Light mode exception
+
+Small scoped changes (≤3 files, ≤200 lines) may skip fan-out/fan-in but must still run validation and a single review pass. See [Local Implementation](../local-implementation/SKILL.md) for details.
+
+## Cross-references
+
+- [Structural quality](structural-quality.md)
+- [Validation policy](validation-policy.md)

package/skills/docs/artifact-authority-contract.md

@@ -0,0 +1,119 @@
+# Artifact authority contract
+
+This document is the canonical authority for the artifact-selection model: when work originates from a GitHub issue (tracker-first) vs a persisted markdown plan file (local-planning).
+
+This canonical owner lives in the shipped `skills/docs/` surface because installed skill/runtime consumers reliably own the skills subtree. In installed layouts, read the same contract via [Artifact Authority Contract](../docs/artifact-authority-contract.md) from the installed skill directory.
+
+Other repo docs may summarize or link this contract, but they should not redefine it.
+
+## Two-tier model
+
+dev-loops supports two mutually exclusive artifact authority modes. Every work item must originate from exactly one authoritative artifact — a GitHub issue or a persisted markdown plan file. No work may originate from a PR or direct local change unless explicitly requested.
+
+### Tracker-first (default)
+
+**GitHub issues are the authoritative artifact store.** Work originates from a GitHub issue. A linked PR is the execution artifact. GitHub is the canonical source of truth for issue identity, acceptance criteria, scope, and lifecycle state.
+
+Artifacts:
+- **Planning artifact:** GitHub issue (title, body, labels, assignees, acceptance criteria)
+- **Execution artifact:** GitHub PR (linked to issue; created during implementation)
+- **No local duplicate:** Do not create `docs/phases/phase-<n>.md` for the same session when a GitHub issue is the canonical spec
+
+Key contract:
+- GitHub issue state is authoritative — not local notes or chat context
+- A linked PR is the single canonical follow-up artifact for the issue
+- When an open linked PR exists, reuse it rather than opening another
+- Implementation may proceed through either the GitHub-first routed path or the local implementation strategy (see [Public Dev Loop Contract](public-dev-loop-contract.md) `targetPreference`)
+
+### Local-planning (opt-out)
+
+**Persisted markdown plan files are the authoritative artifact store.** Work originates from a markdown plan file committed to the repository. No GitHub issue is required. GitHub PRs are still used for review and merge, but the plan file is the canonical spec.
+
+Artifacts:
+- **Planning artifact:** Persisted markdown plan file (e.g., `docs/phases/phase-<n>.md`)
+- **Execution artifact:** Local branch and associated GitHub PR (created during implementation)
+- **No GitHub issue:** The plan file replaces the issue as the canonical spec
+
+Key contract:
+- The markdown plan file is the canonical spec — not a duplicate of a tracker issue
+- GitHub issues may still be used for tracking or linking, but the plan file is authoritative for scope and acceptance criteria
+- A tracker-backed local implementation session (GitHub issue as canonical spec) must not also maintain a duplicate `docs/phases/phase-<n>.md` — see [Public Dev Loop Contract](public-dev-loop-contract.md) "Tracker-backed local implementation input-source contract"
+
+### Mode selection table
+
+| Mode | Canonical artifact | GitHub issue required | Settings values |
+|---|---|---|---|
+| Tracker-first (default) | GitHub issue | Yes | `strategy.default: github-first` |
+| Local-planning (opt-out) | Markdown plan file | No | `strategy.default: local-first` |
+
+`inputSource.default` further disambiguates local-first startup:
+| inputSource | Meaning |
+|---|---|
+| `tracker` (default) | Local agent implements from the GitHub issue body; no phase doc created |
+| `phase-docs` | Local agent implements from persisted phase docs (e.g., `docs/phases/phase-<n>.md`) |
+
+## Settings mechanism
+
+Artifact authority mode is controlled by `.devloops` at repo root:
+
+```yaml
+# .devloops
+strategy:
+  default: github-first   # tracker-first (GitHub issue required)
+  # default: local-first  # local-planning (markdown plan file)
+inputSource:
+  default: tracker        # spec source for local-first: tracker (issue body) or phase-docs
+```
+
+The `strategy.default` key serves dual purpose:
+1. It selects the artifact authority mode (tracker-first vs local-planning)
+2. It sets the default routing preference for `targetPreference` in dev-loop startup
+
+The `inputSource.default` key disambiguates local-first startup:
+- `tracker` (default): local agent implements from the GitHub issue body; the issue is canonical spec
+- `phase-docs`: local agent implements from persisted phase docs; no tracker issue required
+
+These keys are already defined in `.pi/dev-loop/defaults.yaml` (shipped with dev-loops) and may be overridden in `.devloops` (per-repo).
+
+### Defaults resolution
+
+1. `.pi/dev-loop/defaults.yaml` — shipped default (`github-first`)
+2. `.devloops` — per-repo override (takes precedence)
+
+### Explicit non-knobs
+
+These are not valid artifact authority mode selectors:
+- `strategy.default: copilot` — not a valid mode; must be `github-first` or `local-first`
+- Free-form string values — fail closed
+- Omitting `strategy.default` entirely — defaults to `github-first` from the shipped defaults
+
+## dev-loops own mode
+
+dev-loops is **tracker-first (opted in, GitHub backend).**
+
+- **Mode:** Tracker-first
+- **Settings:** `.pi/dev-loop/defaults.yaml` sets `strategy.default: github-first`
+- **Artifact authority:** GitHub issues are the canonical spec for all work in this repository
+- **No local-planning override:** This repo does not opt out to local-planning mode
+- **Why tracker-first:** All work in this repo originates from GitHub issues. The public dev-loop contract, Copilot follow-up state machines, and gate pipeline all assume issues are the primary artifact. Self-improvement work on dev-loops itself follows the same tracker-first contract.
+
+## Relationship to other docs
+
+| Doc | Relationship |
+|---|---|
+| [Public Dev Loop Contract](public-dev-loop-contract.md) | This contract is the canonical entrypoint; artifact authority contract defines the artifact model it assumes |
+| [Tracker-First Loop State](tracker-first-loop-state.md) | That doc defines the PR-level state machine for tracker-first PR workflows — it is about execution state, not artifact authority |
+| [Main Agent Contract](main-agent-contract.md) | Defines the delegation boundary; artifact authority defines which artifacts govern work |
+| AGENTS.md | Repo constitution; cites the work-origin rule and points to this contract |
+| [Dev Loop Skill](../dev-loop/SKILL.md) | Public entrypoint skill; cites the work-origin rule and points to this contract |
+
+### Distinction: artifact authority vs tracker-first PR workflow
+
+`tracker-first-loop-state.md` defines a state machine for PR lifecycle management when a tracker item (e.g., Shortcut story) drives a GitHub PR. That is a **PR-level workflow contract**, not the artifact authority model. The term "tracker-first" in that doc refers to tracker-driven PR state transitions — it does not redefine the artifact authority contract defined here.
+
+## Non-goals
+
+- Defining tracker adapters or multi-tracker support
+- Specifying how PRs map to issues in detail (that is the [Public Dev Loop Contract](public-dev-loop-contract.md))
+- Changing the dev-loop startup resolver behavior
+- Adding tracker-specific settings beyond `inputSource` — further tracker adapters or multi-tracker support remain out of scope

package/skills/docs/confirmation-rules.md

@@ -0,0 +1,28 @@
+# Confirmation rules
+
+Canonical owner for agent confirmation / authorization rules across all workflow families.
+
+## Core rule
+
+Before any state-changing action, get explicit confirmation unless the latest user message already clearly authorizes that exact action.
+
+## What counts as confirmation
+
+- ✅ Explicit authorization in the current conversation
+- ✅ Pre-authorized merge or mutation scope (e.g. "Merge authorized if gates green")
+- ❌ Questions, preferences, future-tense statements
+- ❌ Implied approval from prior turns
+- ❌ Bare response `ok`
+
+## Where this rule applies
+
+- All routed strategies (`local_implementation`, `copilot_pr_followup`, `issue_intake`, `reviewer_fixer`, `final_approval`)
+- All gate entries (`draft_gate`, `pre_approval_gate`)
+- All merge operations
+- All force-push / history-rewriting operations
+
+## Cross-references
+
+- [Stop conditions](stop-conditions.md)
+- [Merge preconditions](merge-preconditions.md)
+- [Public Dev Loop Contract](public-dev-loop-contract.md)