human-checkpoint

# Human Checkpoint A checkpoint is **consent**, not a formatting step. It binds a named human Decision to the exact Artifacts and constraints reviewed before execution may continue. ## Inputs - `DECISIONS.md`. - `UNITS.csv` and `STATUS.md` for the active checkpoint. - Artifacts declared by the locked Pipeline for that checkpoint. ## Outputs - Updated `DECISIONS.md`. - A checkpoint Decision in the Run ledger. ## Steps ### 1. Identify the pending checkpoint Inspect `STATUS.md`, `UNITS.csv`, and the active runner message. Select the first blocked HUMAN Unit and its `C*` identifier. If multiple checkpoints appear active or the checklist is missing, stop and repair the projection before approving anything. Completion criterion: exactly one pending checkpoint and its owning HUMAN Unit are identified. ### 2. Review the declared Artifacts Read the locked Pipeline's checkpoint contract and inspect every named Artifact. Record requested constraints or scope changes in the checkpoint block before approval; do not silently modify reader-facing content as part of sign-off. Completion criterion: the reviewer can name the Artifacts inspected and any constraints attached to the Decision. ### 3. Record approval through the adapter Use the Pipeline adapter so the Markdown checkbox and machine Decision ledger remain synchronized: ```bash uv run python scripts/pipeline.py approve \ --workspace workspaces/<name> \ --checkpoint <C*> ``` Do not infer approval from chat silence, ...