The early design review, and what it changed

Before most of this was built, the plan was put through a long external critique. Thirteen recommendations came back. Every one of them is now in the product, and several are load-bearing enough that it is worth recording where they came from — partly as provenance, and partly because the reasoning still explains why some of these are the way they are.

The raw transcript is not kept. It was 419 lines in the repository root, most of it now embodied in code that says the same thing more precisely, and the parts worth keeping are below.

What it changed

The recommendation	Where it landed
Do not use assignee as the concurrency lock	claims became a table of its own, and a claim became a lease. --assignee is durable ownership; a claim is who holds it right now. The two are still deliberately different words.
Stable planning keys as a first-class field	apply documents carry key, so a re-applied plan updates rather than duplicates.
Split notes from generic event payloads at the storage level	Notes are FTS-indexed separately; the event log stays append-only and untyped.
Define event transaction semantics explicitly	Every mutation goes through one wrapper that writes the row and its event in a single SQLite transaction.
Avoid explicit historical timestamps on normal events	Ordering is by monotonic event id, not wall clock — which later turned out to matter for approval staleness, where two edits in the same millisecond looked identical.
Prefer event cursors over timestamps	log --after <cursor> returns nextCursor; comparing timestamps is never the interface.
Treat claim expiration as a lease, not a warning	An expired claim is winnable by anyone, atomically. A crashed agent cannot wedge a task.
touches overlaps need severity and normalization	Globs are normalized and overlap is reported per pair, with the explicit caveat that absence of a warning is not proof that parallel work is safe.
Parent completion needs clearer semantics	done refuses while children are open, and names them.
Cancellation should require a reason	cancel refuses without -m or --superseded-by. The reason is in the event log and now on the board.
Optimistic concurrency on edits	--if-version refuses a stale write instead of clobbering it.
Be cautious with Drizzle plus FTS5	FTS is maintained through explicit triggers and a rebuild path, not through the ORM.
Missing command surfaces	criteria add/edit/rm, unlink, undep, unevidence, list, config, and doctor all exist. doctor returns remediation commands rather than diagnoses, which was the specific ask.

Two further suggestions were taken as stated:

Selection policy behind an interface. next does not hard-code its ordering. The policy is a list of keys, the response carries selectedBy and selectionReason, and a manual rank field exists for when priority is too coarse.

The framing. The review argued against describing this as “project management meant for LLMs”, on the grounds that it invites people to imagine another tracker. The positioning document’s first line is the result.

The one warning worth re-reading

The main risk is building the polished tracker before proving the execution protocol.

That risk was real and was avoided in the order the work happened: the transaction engine, apply, ready, next --claim, the context bundle and the event cursor all shipped and were dogfooded by parallel agents before any of the presentation work started. It is still the right thing to check against when deciding what to build next.