executing

Executing

Two things happen here: the work gets written down as a task list, and the list gets run. Both halves lean on the same rule — the list file is the state.

The list is the only progress record

Your context does not survive a compaction, a new session, or a handoff to a fresh subagent. A file in the repository survives all three, so completion is recorded there and nowhere else.

That means: no second ledger file, no "done so far" summary that outlives the turn, no todo tool standing in as the source of truth. A todo tool is fine as a scratchpad for the current turn; it is not the record. If two places can disagree about what is finished, one of them eventually will, and the expensive failure — redoing work that was already done — comes from believing the wrong one.

Format

# Tasks: parser rewrite

> arcforge task list v1 — status markers: `[ ]` pending, `[~]` in-progress,
> `[x]` done, `[!]` blocked. Every task has a stable id (`T1`, `T2`, …) that is
> never renumbered or reused. An indented `verify:` line is the command that
> proves the task done; a `note:` line explains a block. Edit markers in place —
> this file is the only state.

- [x] T1 — Write the failing test for the header parser
  - verify: `npm run test:scripts`
- [~] T2 — Implement the parser
- [ ] T3 — Wire it into the loop
  - verify: `npm test`
- [!] T4 — Publish the package
  - note: registry credentials are not available in this environment

Rules that are not negotiable, because a reader with no context depends on them:

• The banner line stays. It is how a fresh worker learns the notation.
• Ids are stable. A deleted task does not renumber its neighbours; gaps are fine.
• Four markers, no fifth. [!] requires a note: saying why — a block with no stated reason is unactionable.
• Markers are edited in place. Everything else in the file — a human's comments, ordering, extra prose — is left byte for byte alone.
• No nested checkboxes. Sub-structure belongs in its own list.