@p10i/rundown 1.0.0-rc.13 → 1.0.0-rc.15

package/README.md

@@ -92,7 +92,7 @@ Re-verify the most recently completed task (without changing checkbox state):
 rundown reverify -- opencode run
 ```
 
-Re-verify a specific historical run and fail fast without repair retries:
+Re-verify a specific historical run and fail fast without repair attempts:
 
 ```bash
 rundown reverify --run run-20260319T222645632Z-04e84d73 --no-repair -- opencode run
@@ -114,6 +114,15 @@ Common Git-aware forms:
 rundown run roadmap.md --commit -- opencode run
 rundown run roadmap.md --commit --commit-message "rundown: complete \"{{task}}\" in {{file}}" -- opencode run
 rundown run roadmap.md --on-complete "git push" -- opencode run
+rundown run roadmap.md --on-fail "node scripts/alert.js" -- opencode run
+rundown run roadmap.md --force-execute -- opencode run
+```
+
+Run all tasks sequentially:
+
+```bash
+rundown run roadmap.md --all -- opencode run
+rundown run roadmap.md --all --commit --on-fail "node scripts/alert.js" -- opencode run
 ```
 
 ---
@@ -124,19 +133,37 @@ rundown run roadmap.md --on-complete "git push" -- opencode run
 
 Use `rundown plan` to expand a high-level task into concrete subtasks before execution begins. Big goals become small, runnable steps.
 
+Nested checkbox contract:
+
+- A parent checkbox is a real task, not a passive container.
+- A parent task is blocked while any descendant checkbox remains unchecked.
+- A parent becomes runnable only after all descendants are checked.
+- Use a plain bullet (without a checkbox) for grouping-only headings.
+
 ### Execute
 
 The task context — the surrounding Markdown, the template, the file paths — gets rendered into a prompt and sent to your worker.
 
 ### Verify
 
-A separate verification prompt checks the result. The task needs an explicit `OK` to pass. No silent failures.
+A separate verification prompt checks the result.
+
+Verifier contract:
+
+- return `OK` on stdout when complete
+- otherwise return a short failure reason (recommended: `NOT_OK: <reason>`)
+
+`rundown` persists that stdout result to the task sidecar file (`<file>.<taskIndex>.validation`). The task needs an explicit `OK` to pass. No silent failures.
+
+If task text is verification-only (for example `verify: ...` or `[confirm] ...`), `rundown run` automatically skips the execute phase and runs verify/repair directly.
+
+Use `--force-execute` to override that auto-skip and run execution anyway.
 
 Need a confidence check later (for example before release)? Use `rundown reverify` to re-run verify/repair for the latest completed task from artifacts, without advancing task selection.
 
 ### Repair
 
-If verification fails, a repair prompt fires, the worker retries, and verification runs again. Completion is earned, not assumed.
+If verification fails, a repair prompt fires, the worker runs another repair attempt, and verification runs again. Completion is earned, not assumed.
 
 ---