ravel-lite run is the phase-loop entry point. It reads <plan-dir>/phase.md to decide which phase runs next, dispatches to the matching handler, and on completion advances phase.md to the successor. Single-plan mode (one directory) loops continuously, prompting between cycles. Multi-plan mode (two or more) prioritises across plans via an LLM survey and runs one cycle at a time on the chosen plan.

For now we run a single plan:

The TUI takes over the terminal. A banner identifies the plan and the agent backend; the first phase.md read picks up work, and the work phase begins.

The work phase is the only interactive phase in the cycle. The agent reads four sources of context — <project>/README.md, the backlog, distilled memory, and declared peer-project relationships — then asks you to steer task selection. Below is an illustrative session.

Three tasks, none blocked, no momentum from a prior cycle. Pick the first:

Behind the scenes the agent is calling ravel-lite state backlog set-status to flip the task to done and ravel-lite state backlog set-results to record what it did. The source-file edits to reading-list.md and the new files under notes/ are not committed by the work phase — they are left dirty for analyse-work, the next phase, to see and commit-message from the actual diff. This split is deliberate: the work phase records what was decided, the analyse-work phase records what was changed in the tree, and a commit message authored from the tree is more reliable than a commit message authored from a self-report.

When the work phase finishes, it writes analyse-work to phase.md and exits. The TUI advances and the next phase starts.

From here, the cycle runs unattended through analyse-work, git-commit-work, reflect, git-commit-reflect, (optionally dream and git-commit-dream), triage, and finally git-commit-triage. The TUI banners each phase as it starts, streams the agent output, and shows the per-phase exit status. Each runs in its own subprocess with its own prompt; nothing is shared between them except the plan-state files on disk.

A few things are worth watching for as the cycle progresses.

Analyse-work. The phase examines the actual git diff and writes two artifacts: a session-log entry (overwriting latest-session.yaml) and commits.yaml, which describes how to partition the diff into commits. Default is one commit per cycle; the phase splits only when the diff genuinely spans independent concerns. For a small reading-list update, expect a single commit.

Git-commit-work. A pure Rust handler — no LLM. It reads commits.yaml, applies each entry as git reset HEAD — . then git add — <paths> then git commit -m <message>, then appends latest-session.yaml to session-log.yaml and captures the next baseline. Two to three commits land: the work commit(s), and a save-reflect-baseline follow-on commit recording the SHA the reflect phase will diff against.

Reflect. Distils the latest session’s learnings into durable memory. Reflect is the only lossy phase — it can sharpen, contradict, and prune memory entries based on what the session uncovered. For a first cycle the agent typically adds zero or one new entries; reflection is more interesting from cycle 3 onward when patterns start to emerge.

Dream. Conditional. Runs only when memory has grown past baseline + headroom words (default 1500 from defaults/config.yaml). On a first cycle, memory is well within the threshold and dream is skipped — the TUI shows a DREAM banner: skipped — memory within headroom line so the absence is as legible as the work that ran.

Triage. Reviews the backlog, mines completed tasks for hand-offs, and reprioritises. Two things triage does even on a first cycle: it removes the completed task from the backlog (the audit trail of the work it did lives in the git history and the session log, not in the open backlog), and it tightens dependency edges between remaining tasks when the work just done makes a dependency newly visible. From cycle 2 onward, triage’s narrative starts to carry [REPRIORITISED], [PROMOTED], and [ARCHIVED] labels alongside its actions.

Git-commit-triage. Lands the triage mutations, captures work-baseline, and exits the inner phase loop. The cycle is over. The TUI prints "Proceed to next work phase?" and waits.

Stop here for a moment and look at the audit trail. git log --oneline after one full cycle is the complete record of what landed:

Reading bottom-up: the initial scaffold from chapter 02; the work commit, whose message is authored by analyse-work from the actual diff (so it reads like a normal feature commit, not a templated run-plan: work); the save-reflect-baseline capturing the SHA reflect will diff against; the reflect commit (memory mutations); save-triage-baseline; the triage commit; and the closing save-work-baseline ready for cycle 2. A reader can scrub through a cycle the same way they would scrub through a video.

The first cycle is a special case in one respect: there is no leading save-work-baseline between Initial scaffold and the work commit. The scaffold itself is the baseline ravel-lite diffs against; the first explicit save-work-baseline lands at the end of cycle 1 in preparation for cycle 2.

Inspect the session log to see what reflect saw:

The body is the attempted / what worked / what this suggests next shape that analyse-work distils from the diff. The "What this suggests next" line is what triage will read in the next phase to decide whether dependencies between backlog tasks should be tightened.

And the memory after reflect:

A new memory entry — "README.md is the authoritative entry-format specification" — distilled from the session. Reflect added it because the work-phase agent extended the README during the cycle (the original was a one-line stub) and that extension established a precedence rule between the README and the per-entry memories: when they conflict, README wins. Reflect noticed and made the rule durable.

The four-entry shape is also worth noting. Three of the entries are the seeds from chapter 03; the fourth is the cycle-1 distillation. Memory grows by accumulation, not replacement — the seeds stay until a future reflect or dream phase decides to consolidate them.

And the backlog after triage:

The completed task is gone — triage removed it; its trail lives in the work commit and the session log entry above. The cross-link task gained a dependency on the type-theory task: it is most productive once both batches of entries exist, and triage saw that constraint in the "What this suggests next" line of the session log and made it explicit. Cycle 2’s work phase will see only the type-theory task as actionable.

After git-commit-triage exits, the TUI prompts:

Answer y to start cycle 2. Answer n to exit the loop cleanly. The plan directory is left in a fully consistent state either way — phase.md reads work, ready for the next invocation. There is no "save and quit" step: every transition has already been written to disk and committed.

The next chapter runs cycles 2 and 3, watches memory accumulate, and demonstrates the dream trigger and a hand-off being mined by triage.