Where this stands
What is built, what is left, and what each remaining item is waiting on. The place to start.
In one paragraph
The conversation lifecycle is specified end to end. Forty-four screens — Brad’s twenty-three stages, twelve proposed stages, and nine forms — walkable from Interest to a settled rental in seventeen clicks, verified by 800-odd measured assertions on every change. The build list is finished. What remains is twelve open decisions, three of which are canon questions only Brad or Jay can answer, and two pieces of scheduled work that have never been scheduled.
Nothing is currently blocking build work except one item, and that one is the last thing on the list.
As of 2026-08-24 both governing documents are here. The Master FSD was promoted out of boro-ops and the
Terms of Service v2.5 out of Drive, so every FSD §x.y and Terms v2.5 §x on this site links to the clause
it cites, and Brad and Jay can check any canon claim against the document that governs it — including the
item-eligibility schedule, which until today no one but CJ could open. How that move works, and what makes it
one-way, is How a document gets promoted.
What is built
| Count | What it is | |
|---|---|---|
| Stages | 23 | Brad’s master lifecycle. Byte-identical to his original — every label, date and behaviour derives in the presentation layer instead. |
| Proposed stages | 12 | The pickup chain (6), the return chain (4) and Refresh Tap (2). Marked “(proposed)” in the picker until Brad adopts them. |
| Forms | 9 | Every request the conversation can compose. formHtml() is declarative, so a tenth is a data entry rather than a code change. |
| Total screens | 44 | Plus a contact-sheet view that renders all of them side by side. |
The properties that took the longest to get right, because each one is a thing a reader would otherwise have to take on trust:
- The thread is cumulative. Every event at or before the current phase renders; only the event at the phase is live. A completed rental carries twelve cards where it once carried three.
- The document is walkable. Card buttons navigate. Every action declares
go,formorinert-with-a- reason, navigation only goes forward, and the harness clicks its own way from Interest to settled. - Conversation sits between the milestones, so the Chat and Timeline tabs finally differ.
- Every stage says how to build it — the governing FSD sections, what the screen must do, and a Watch out line. Brad asked for this specifically; it is the thing he reads before implementing.
- Verification survives the move.
./tools/lifecycle/verify-all.shruns the same three checks here that it ran in the Drive folder, with the same numbers — plus a fourth, added on 2026-08-24, that fails if a promoted document has been edited here or if the copy it came from is still editable.
What is left to build
Two items. One is blocked; the other is not a question but unscheduled work.
| Item | Waiting on | |
|---|---|---|
| B-11 | A no-show reads as a consequence, not a filing. | D-4 + Q3 + W-2 + W-12 — one question with four names. See Handoffs. |
| Q9 | boro-shared/tailwind/boro-theme.css carries no semantic tokens — only the brand ramp, two surface steps, spacing and radii. There is nothing in the app to build this specification against. |
Nobody. It is work that has not been scheduled, not a question anyone can answer. |
Everything else on the post-review list is done. The full history is in Build order.
What is waiting on a person
Twelve open decisions. The three at the top are canon questions — cases where what was described either contradicts the FSD or is absent from it, and guessing produces something that gets built twice.
Brad
| ID | Question |
|---|---|
| W-1 | Is there a 15-minute check-in window? Described three times at the workshop; FSD §10.2 says verbatim “There is no separate 15-minute timer.” |
| W-2 | What happens to the holds when NEITHER party shows up? §6.1 routes forfeiture to “the non-violating party” and a mutual no-show has none. The screens have been made silent on the outcome rather than left stating a wrong one. |
| D-4 + Q3 + W-12 | What is a no-show called, what tone does it wear, is it a distinct status? A data-model decision, not a colour one. Blocks B-11. |
| R-7 | Twelve proposed stages to adopt into his STAGES[]. A merge he owns. |
| R-8, R-9, R-11 | Three structural gaps found by wiring the buttons: one stage doing two jobs, a terminal outcome with no stage, and no way to rent straight off a try-on — which both CJ and Jay independently said should exist. |
| D-5, NS-7, Q1–Q7, R-1, C-4 | Copy and policy items, none blocking. |
Jay
| ID | Question |
|---|---|
| W-3 | FSD §8 is LOCKED, and the launch model everyone agreed removes what it is built on. Jay named the consequence himself at the workshop. Only he can make that change. |
| W-16 | AI comparison of the two photo sets drives the payout. Described at the workshop; not in the FSD. |
| CANON-1 | The FSD names Terms v2.4; v2.5 superseded it in full six days later (effective 2026-08-06). Stale, not contradictory — and v2.5 §8.4 is Category H, so every “Terms v2.5 §8.4” citation here is correct. A one-line canon amendment. |
| CANON-2 | §16.1 asks the Terms for six changes — v2.5 appears to have made all six, at different numbers: §8.3–§8.6, §8.2.1 (the forfeiture redraft, worded exactly as §14.6 demanded), §6.6/§6.8, §9 and §10.12, and §10A. Only risk allocation does not map cleanly. Jay to confirm. |
| ACCESS-4 | The FSD’s source of record is in no repository. The promoted copy is a conversion; the executed .docx governs it and is on no machine here. Re-converting — the only approved way to correct it — needs that file. |
| W-11, W-19, NS-3, D-1 | The consent checkbox’s legal posture; a UI-aware version of the FSD; the manual check-in fallback Brad deferred to him by name; and the QR model, built as a proposal nobody has reacted to. |
| R-4 residue | MAX_TOTAL_RENTAL_DAYS is still 12 in the shipped constants against 30 in §13.1. Live-app work, not simulator work. |
CJ
| ID | Question |
|---|---|
| D-2 | Settled 2026-08-24 — the blue is the user’s own bubble; the counterparty’s does not carry the emphasis. Nothing in the artifact moves. What it leaves is a task, not a decision: there is still no blue in the token set, so the bubble needs a semantic token and a DS amendment. Rides with R-5. |
| W-4 | This page is the answer to half of it — the wiki is the source of truth now. The other half: the Drive folder CJ asked for in the same call is superseded, and someone should say so out loud. |
| CANON-3 | Private sales are in canon twice and specified nowhere. FSD §3.3 gives a for-sale listing coordinated through chat; the proposed Terms §8A adds thirteen subsections, one of which — §8A.11 — gates the first message behind a recorded acknowledgment. The simulator has no sale surface at all. §3.3 binds today; §8A does not yet. |
| Q14, D-7, CR-12 | Small design calls. W-8, Q16, W-23 and R-3 closed 2026-08-24. |
What is needed to move forward
Three things, none of which is a decision.
1 · The design system has twelve unapplied amendments — R-5. Tokens that do not exist, components with
no entry, and rules that live in the build and not in the document. The register is
Design-system amendments — one place, because it used to be
three and they disagreed. Doc first, then regenerate boro-tokens.css, boro-typography.css and the
Tailwind preset together. Never one alone.
2 · The app has nothing to receive this — Q9. See above. It is the real integration blocker and it does
not move by building here.
3 · A decisions meeting, not a third walkthrough. Two full walkthroughs have now failed to surface a decisions list. The register recorded why after the first one:
A stage-by-stage walkthrough will not surface a decisions list. It surfaces whatever is on screen.
On 2026-08-21, eight of Brad’s items survived a fifty-minute review untouched because their stages were never opened. On 2026-08-22, the workshop settled one of the six things it was convened to settle. Handoffs exists to be that meeting’s agenda.
Where things live now
| The specification | src/canon/BoRo_MasterFSD.md, rendered at Master FSD. Promoted out of boro-ops on 2026-08-24 — derived and read-only, so cite it, do not edit it. |
| The Terms | src/canon/BoRo_TermsOfService_v2_5.md, rendered at Terms of Service v2.5. Promoted 2026-08-24. §8.4 is the eligibility schedule; screen by make and model against the clause, never a summary. |
| The simulator | public/artifacts/conversation-lifecycle.html — the source, not a copy. Edit it here. |
| Verification | ./tools/lifecycle/verify-all.sh — run all four checks on every change to the artifact. |
| Brad’s original | tools/lifecycle/baseline/ — the diff baseline, kept out of public/ on purpose. |
| The Drive folder | Archive as of 2026-08-24. It is where all of this was written; it is no longer where any of it is maintained. |
The one thing to be careful about. The simulator carries a copy of
boro-tokens.css, and the design system moves. It once sat a version behind while the DS shipped a fix, and the one drifted value was an AA failure across the entire caption layer.token-drift.pycatches it, and it tells you which token file it compared against — a drift check run against a stale vendored copy reports CLEAN while the DS has moved underneath it.