session-flow v2: persistent work items

I wrote the first account of session-flow around the instructions I kept repeating to coding agents: decide what is worth doing, break it into something a session can finish, check the result, and ship it. Version 2 gives that workflow a persistent record for each piece of work, so a later session can find the scope I accepted and the evidence behind what was reported as done.

The chain now has sixteen skills. The new one, /session-repair, handles migration into v2 and repairs a work root that has drifted. The changes below describe the current release, v2.0.3.

One record per outcome

A work item is one outcome with a stable identity, such as SEQ-042. Its record holds the intent and accepted scope, along with the current status. A small job can stay in that one file; a larger one keeps its specification, plan and task records beside it.

SEQUENCE.md is generated from those records. It shows the open backlog, and every identity stays taken after its item leaves the list. Changing a line in the generated file has no effect on the stored work; the next render replaces it. Capturing an idea or writing its breakdown also leaves acceptance as a separate decision.

Checks at the runtime boundary

Acceptance records the scope I agreed to. A scope change needs a fresh acceptance or a recorded decision that the meaning stayed the same, so instructions from an earlier session cannot silently become permission for a different job.

The Python runtime checks record revisions and claim ownership. It refuses a claim with unfinished or cyclic dependencies, or declared file paths that overlap another actor's live claim. It also refuses completion when recorded evidence belongs to an older scope, a required delivery has no receipt, or child tasks remain open.

Those checks have a specific boundary. The host's permissions govern filesystem access, and continuation across several tasks still depends on instructions the agent follows. Someone also has to judge whether the evidence proves the agreed outcome; passing every task does not by itself establish that the feature was delivered.

Upgrading an existing project

Version 2 needs Python 3.9 or newer available as python3, on Linux, macOS or WSL. For a project with an existing backlog, /session-repair surveys the old layout and produces a migration plan. You review that plan before it writes anything.

The migration keeps existing identities and leaves historical task files where they are. New work goes into the work root, and the generated sequence moves above the old archive. A fresh project starts with /session-init. The README has the installation commands; the repository ships a Claude Code plugin, while Codex needs a separately packaged copy of the runtime and skills.

The point releases

v2.0.1: migration can start without a work root. Repair can survey an older backlog before its namespace or work root exists, then include the required setup in the plan you approve.

v2.0.2: completed work leaves the sequence. Done items keep their records and task views, while the generated list stops growing with every finished job.

v2.0.3: the sequence shows only open work. Deferred and cancelled items leave the list too. Their records remain available, and their identities are never handed to another item.