cairn-apply

Apply a change: implement its tasks, prove the outcome, and accept it.

Prerequisites

• A change directory exists at meta/changes/<change-id>/
• proposal.md, design.md, and tasks.md are present

Steps

1. Identify the change to apply

   If the user doesn't specify a change:

   cairn change list
   

2. Read the change artifacts

   Read proposal.md, design.md, and tasks.md. The proposal names the outcome and the acceptance boundary you have to reach; treat that as the definition of done, not the task checkboxes.

3. Implement the tasks in order

   For each unchecked task, implement it and mark it complete in tasks.md. Run whatever narrow test or check covers just that task as you go. Let the repository decide commit granularity; most expect one reviewable commit per change, not one per task.

4. Run the host repository's own gates

   This is the target repository's call, not Cairn's. In order of authority:

   1. Instructions the repository gives you (AGENTS.md, CLAUDE.md, CONTRIBUTING.md, a documented script such as scripts/*gates*.sh).
   2. The gates: list in cairn.config.yaml, if the project configures one.
   3. The project's ordinary build and test commands for its language.

   Run only batteries from the project's own language. If you cannot tell what the gates are, ask rather than guessing.

5. Prove the outcome at its own claim boundary

   A green internal check is evidence about the code, not about the claim. Prove the thing the proposal actually promised, at the nearest place it becomes observable:

   Claim	Insufficient	Proof at the boundary
   Behavioural change	unit test passes	run the command or call the API and show the new observable result
   UI change	component test passes	load the surface and confirm the rendered state
   Generated output	generator has no errors	diff the regenerated artefact and show the delta is the intended one
   Operational change	config parses	exercise the path in a running instance, or state plainly that you could not
   Bug fix	new test passes	reproduce the original failure first, then show that reproduction now passes

   If a boundary is genuinely out of reach in this environment, say so and name what would close it. Do not upgrade a partial check into a completeness claim.

6. Run Cairn's acceptance boundary

   cairn change accept <change-id>
   

   This resolves and runs the project's language battery, then checks Cairn's own invariants: cairn lint, and the suggested-edges queue.

   accept picks the battery in this order: an explicit gates: list in cairn.config.yaml wins (an explicit empty list deliberately runs nothing); otherwise a Rust project falls back to a built-in cargo battery; every other language reports an informational note that no default battery exists and continues to the language-agnostic checks. That note means "configure gates: if you want Cairn to run them", not "this project has no gates". You are still responsible for step 4.

   CC002 means the change's meta/changes/<change-id>/suggested-edges.json still holds entries whose triage_state is pending. Those are machine suggested blueprint edges, and Cairn will not let them enter the graph without a human decision. Resolve it by setting each entry's triage_state to accepted, rejected, or deferred (with a triage_note when the reason is not obvious), then re-run accept. Do not delete the queue to clear the gate.

7. Report

   Summarise what was implemented, the evidence for the outcome, and anything you could not prove.

Mutation authority

You may, without asking: edit source, tests, and docs inside the change's scope; create and edit files the design calls for; run builds, tests, linters, and read-only commands; run cairn commands that write inside meta/ (todo set, change accept).