v0.7.0 — a phase hands the next one a record

What a build phase learned now survives the phase, and every segment records what it was asked to do

Half of the work in a run is what a segment discovered while doing it. Until this release that half reached the next segment only if the orchestrating session retyped it into the next prompt, and when it didn't, nothing recorded that anything had gone missing. It happened: one phase moved a rule out of an agent's definition into a temporary home, and the next phase deleted that temporary home before the rule had reached anywhere permanent. The rule left the repository and no record said so.

A build phase now leaves a committed record, the same way a review round already does. A new phase template mirrors the round's shape for the build side — what the phase was asked, what it found, and a table of what left the tree and where it must land. It is wired into the plan template, the implementation skill and the implementing agent, so a spawned session writes the record at each phase's close without being told twice.

And both records now say what the segment was asked to do, not only what it found. The cheapest review round ever measured here — under eight minutes, one blocking finding and four smaller ones — was cheap because its prompt named eight specific things to try to break, in order. That fact was recoverable only from a session transcript. Both templates now carry a section for it, filled in right after the segment posts.

Enforcement here is a template blank and a skill instruction, not a checker. A refusal for a missing section was considered and set aside: it would need a red test, a stated failure direction and a cutoff to measure against, for a mechanism that has shipped zero records so far. It is revisitable once real phase records exist to learn from.

What else moved

• Measuring a segment and logging what it found is now automatic in every repository this plugin installs into. The instruction used to live in one operator's own memory file, naming a fixed issue number that went stale twice. It is now part of the verification skill: after every segment, find this repository's open measurement log and post the numbers. Where no such log is open — nearly every installed repository — the step does nothing, asks nothing, and measures nothing.
• The log rolls itself forward. A new script, wired into the release workflow, closes the current log and opens the next one every time a release reaches the default branch, so it keeps growing without anyone opening an issue by hand.
• The rollover retries once on "no log open", and never on "more than one". A search-index lag right after a label write can only undercount what is actually open, never overcount, so only a zero reading gets a second look. Found while building this same change, when a listing came back empty immediately after a label was applied and a direct read in the same breath showed it already there.

Full changelog: v0.6.0...v0.7.0