Trace

Completed and cancelled projects leave the planning board by themselves

Until now the board's list of projects came from each project's own flag and nothing else. A project marked completed or cancelled kept its check-in card on the weekly go-around every week until somebody remembered to take it off. It also kept showing in the planning report's check-in staleness notes and, with no lead, as a lead gap. A completed project cannot go back to in_progress and a cancelled one cannot move at all, so there was nothing left to plan for either.

Now finished projects are left out wherever the board's scope is decided, which covers the weekly check-in cards, check-in seeding and the planning report together. This applies to every scope filter kind except lifecycle: that one names the state it wants, so a cycle deliberately scoped to completed projects still gets them. The project's own flag is left as it is and is not cleared.

• Seeding one finished project now says why it has no card. It used to say only that the project was out of scope, which read as though its board flag were off.
• The Dashboard badge on a completed or cancelled project reads Off the planning board — completed (or cancelled) and is no longer a toggle, because the flag no longer affects anything there. The plan band on the project page says not on the weekly go-around for the same projects.
• The MCP descriptions of tracksCheckins and the planning configuration now state the rule, so an agent asked why a project is missing from the go-around has the second answer as well as the first.

A correction to 0.232.0. Its entry said a completed project on the board was reported as a planning gap each week. The report already skipped finished projects when flagging ones with no planned hours. What such a project actually kept getting was its check-in card and the staleness notes above.

Trace 0.233.0 / MCP 0.138.0 / Dashboard 1.182.0.

A completed project can come off the planning board

Reported on the live server: the "On the planning board" badge on ETT00000002 R0 Sparrow Production Readiness R1 could not be changed. The project had been marked completed on 2026-09-15, and the project update refuses every call on a completed or cancelled project before it looks at which fields the call changes. So the board toggle was refused as a locked metadata edit, with a message about design entities that said nothing about the board.

That left the project exactly where it should not be. The planning scope counts every project that is on the board, finished or not, so a completed project stayed on the weekly go-around and was reported as a planning gap each week, and neither the Dashboard nor MCP could take it off.

Board membership is not a statement about the design, so it no longer counts as locked metadata. A call that only moves a project on or off the board now passes the lifecycle lock. The ManagePlanning check (or the project's own lead) still applies to it. Every other field on the update stays locked, including one sent in the same call as the board change.

Probe review and Probe read: the names, and a seat screen that could not be filled in

Reported on the live server within the hour: the Probe read seats could not be assigned, and the two Probe seats were confusingly named. Both were mine, both shipped in 0.230.0, and the second caused the first.

A redundant seat was being priced instead of refused. Assigning a read seat to somebody who already held a review seat returned "needs acknowledgement", which the seats screen renders as its typed-confirmation dialogue: headed this seat is not in your licence, demanding the word CHARGE, offering assign and accept the charge. The seat was inside the licence and free. So the first people an administrator ticks — the engineers who already hold review seats — produced a demand for money that did not exist, and there was no way through the screen that was not a lie about the bill.

That confirmation is now for MONEY and nothing else. A seat that grants nothing because a larger seat already covers it is refused on its own terms, naming the remedy: clear the review seat first. Any other refusal routed through the CHARGE dialogue teaches an administrator that the sentence about money is noise, and the next one they click through is a real invoice.

The screen no longer offers the box at all. SeatOverview carries CoveredBy, so the grid draws the read cell for a review-seat holder as covered, tagged with the seat that covers it, disabled, with a tooltip saying to clear the review box first if this person should only read. A box whose only possible answer is a refusal should not invite a click.

The seats are named for what they permit. Probe review reads and writes; Probe read only reads. They were Probe and Probe reading, a pairing that read as though the plain one might be the read-only one, and which said nothing about the relationship that matters: review INCLUDES read, so nobody needs both. The registry seed owns display names, so existing servers are renamed on the next startup. The usage scopes follow (Probe review (read and write), Probe read (read-only)), as do the licence page, the usage page and the vendor console.

A read-only seat no longer refuses in the language of writing. Every application in this estate gated writes until this one, so every refusal ended "writes are paused, reads remain open" — which on a read seat is nonsense and promises the reader the one thing being taken away. Found by running check-license-authority.ps1 against factory, which printed "so Probe reading writes are refused. Reads remain open." Read-only applications now say reading is refused, and say nothing about reads remaining open, because they do not. The other applications keep their wording unchanged, with a test pinning that.

What a seat INCLUDES and whether it is read-only are product facts, so they live in code beside the registry defaults rather than in a column: there is nothing to migrate, and no administrator should be able to unset the fact that one seat covers another.

Also proven rather than asserted this time: the license_period migration from 0.230.0 was run against a real PostgreSQL carrying the pre-upgrade table — ADD COLUMN IF NOT EXISTS added probe_reader, the existing row defaulted to 0, and the insert round-tripped. That path fails silently if it is wrong (the caller logs at Debug and carries on), so a passing unit test would have proven nothing about it.

Trace 0.231.0.