Waiting on someone
Everything that needs a person to answer it, grouped by who. Nothing settled, nothing already built — only what is owed.
Two full walkthroughs have now failed to surface a decisions list. On 21 August, eight of Brad's items survived a fifty-minute review untouched because their stages were never opened. On 22 August, the workshop settled one of the six things it was convened to settle. The reason was written down after the first one:
A stage-by-stage walkthrough will not surface a decisions list. It surfaces whatever is on screen.
This page is the agenda for the meeting that would. It is a view of the same data as Open items — filtered to what is unresolved, grouped by who has to act. Settled items are not here; they are there.
Owner means who has to act, not which department. Anything that needs a decision belongs here — marketing, operations, legal — which is why this page is not named after two engineers.
Start here — 4 blocking
Something cannot be built correctly until each of these lands.
Brad
18Lifecycle logic, the data model, and his own copy.
Is there a 15-minute check-in window?
Described three times at the workshop as settled rule. FSD §10.2 says, verbatim: “There is no separate 15-minute timer.”
Why it cannot be guessed: The charitable reading — a check-in grace that is a different object from the 45-minute session — is nowhere in the FSD, and the artifact was built on the sentence that forecloses it. Nothing is being built on 15 minutes until this lands.
What is a no-show called, what tone does it wear, is it its own status?
Four threads, one question. Brad wants red rather than grey; the naming he parked for Jay; and a third name proposed at the workshop, “Meetup window closed.”
Why it cannot be guessed: Tone derives from TONE_BY_STATUS and terminated is neutral, so this is either a platform-wide repaint of every ordinary termination or a new status. A data-model decision, not a colour one. W-2 belongs in the same answer.
What happens to the holds when neither party shows up?
Jay's rule: “if neither side meet up then both at fault, we're going to release the money back to them.” FSD §6.1 does not define this case — it routes forfeiture to “the non-violating party”, and a mutual no-show has none.
Why it cannot be guessed: Settle it with D-4 and Q3; they are one question. Until then the cards say nothing about the outcome.
Where it got to: Interim copy shipped 2026-08-22. Both terminal cards were stating the opposite AND were incoherent on their own terms — “neither side… forfeited to the other party” has no other party. They now name the defined case, name the undefined one, and assert no outcome. The RULE is still owed.
Should the pending card carry the hold amount?
The form states it before approval; whether the card repeats it is his.
Where it got to: Presentationally addressed — the G-1 form states the hold before approval.
Twelve proposed stages to adopt
The pickup chain (6), the return chain (4) and Refresh Tap (2). Built, marked “(proposed)” in the picker, and living outside STAGES[] so his master stays byte-identical.
schedule-denied is one stage doing two jobs
His own renterCan reads “Schedule try-on / pickup again”, so it serves the denied inspection AND the denied pickup. A stage has one position on the spine, so denying a pickup rewinds the thread past the whole inspection chain.
Why it cannot be guessed: Split it, or give the denial its own phase. W-9 also wants it renamed.
There is no “declined at pickup” stage
FSD §10.4 gives the borrower Accept / Decline / Report, and Decline “at no charge… all holds release” is a real terminal outcome. cancelled is a meetup nobody attended, which is a different thing.
Why it cannot be guessed: The button is built inert with that reason rather than pointed at the nearest wrong stage.
A renter should be able to rent straight off a try-on
Both CJ and Jay said so independently at the workshop, and CJ named the defect on screen: “Complete and rent item is not linking to the right screen… they should be able to do it right there.” There is no stage for it.
Why it cannot be guessed: Related: a Lane B term carries four Refresh Taps and the spine has one position for the rental, so a tap is built as an interruption rather than a step.
not_returned is filed under Terminated
When Cancelled and Terminated became two filter buckets the unreturned-item status had to land in one. A system end is not a user quit, so it went to Terminated.
Why it cannot be guessed: An inference, and adjacent to Q3. Settle it with D-4.
How long does the lender have to decline an extension?
FSD §13.2 sets the commit model and the +6/+12/+18/+24 increments and names no response window. “Back within that one day” was said on a call and is not canon.
Why it cannot be guessed: The extension form is built and states it as open; a harness rule fails if any digit ever lands in that field, so nobody can quietly fill it in.
Is there a deadline to confirm a try-on item came back?
§10.4 answers the analogous check-in case and not this one.
Close-while-accepted
Live code allows closing after a hold is authorized. Blocked, or priced as a forfeit?
Why it cannot be guessed: Partly answered by construction — the destructive menu item now opens the priced cancellation confirm. Whether it should be blocked outright is his.
A real Late chip, and a chip for extension-requested
His own gap notes rule both out — “Intentional: no Late chip” and “Chip does not change — keep it loud.” The case for Late got stronger: the overdue card carries an Overdue badge while the header chip still reads Rental · Underway.
The composer in a review window and in a dispute
Read-only, support-only, or normal Send?
The late card's copy, and BoRo Recovery
The card is new and FSD-derived. BoRo Recovery is not in his renterCan list — it comes from §12.4.
The meetup cards no longer print a weekday
His data calls the same date Sat on the try-on and Tue on the pickup. Invisible until the thread went cumulative and put both in one view. His strings are untouched.
“No support after the window” against “contact support”
Jay: “there's no support, there's no real reschedule or nothing.” Brad: “now it's contact support.” The built card says Contact Support.
Why it cannot be guessed: Small, but it is the copy on a terminal screen and they do not agree.
Rename schedule-denied to “Lender unavailable at requested time”
Proposed at the workshop and agreed in the room.
Why it cannot be guessed: Adjacent to R-8 — if the stage splits, both halves need names.
Jay
10Canon. The FSD is his document; several of these amend it.
FSD §8 is LOCKED, and the agreed launch model removes what it is built on
§8 has the borrower selecting one of three exchange lanes at booking, with travel priced on productive miles beyond the midpoint at $0.75/mile. The workshop agreed to ship the simple version — chat, agree a place, drop the pin.
Why it cannot be guessed: Jay named the consequence himself: “if we are going to go with your route Brad, then we had to remove whatever the midpoint is.” Amending a locked section by implication is not a thing to leave implied.
The QR model
Built as a proposal to the reconciling reading: one booking code, rendered on both devices, either party scans, the scan confirms both. Satisfies §10.1 and Brad's “whoever wants to do it”.
Why it cannot be guessed: He and Brad were meant to react to it, and it never came up at the workshop.
Where it got to: Built as a proposal 2026-08-22. Awaiting a reaction rather than a decision.
The FSD's source of record is not in any repository
The promoted specification is a conversion. Its own opening callout says the executed BoRo_Master_FSD_07_30_V9.docx governs and that the markdown is the defect where they disagree — and that .docx is on no machine here. Drive holds only the v8.1 PDF, two versions behind.
Why it cannot be guessed: The rule for a derived document is *re-convert, never hand-edit*, and re-converting needs the source. Without it the wiki copy cannot be corrected the approved way, and nothing notices if the .docx moves ahead of it — the verifier catches an edit made here, not staleness there. The fix is an ask, not a tool: the .docx sitting beside its conversion.
Where it got to: Partly closed the same day. CJ produced a full markdown export of V9 from Jay — not the executed .docx, but a complete second rendering of it, which is enough to check the promoted copy against. It found three real defects, now repaired. tools/promotion/compare-source.py reports 104 of 104 sections identical. Still open: the .docx itself, without which the specification cannot be re-converted the approved way.
AI comparison of the two photo sets drives the payout
Described at the workshop, including serial numbers in the capture. §11.3 says “damage on the evidence” and names no comparison mechanism.
Why it cannot be guessed: Not in the FSD.
The commitment-hold consent checkbox
Agreed at the workshop. It turns the disclosure from a statement into an ACCEPTANCE, which is a legal posture change.
Why it cannot be guessed: Worth his confirmation in writing rather than ours.
A clean, UI-aware version of the FSD
The current document carries AI-generated notes meant for us rather than for the app. The build needs the version that says which buttons show when.
The manual check-in fallback
Assert presence with a photo of the location, when the geofence check fails. The enums already carry MANUAL_PENDING / MANUAL_CONFIRMED / MANUAL_FAILED.
Why it cannot be guessed: Brad deferred this to Jay by name, and it did not come up at the workshop. Keep it distinct from “I'm here” — that initiates the check, this is the failure path.
MAX_TOTAL_RENTAL_DAYS is still 12 in the shipped constants
CJ confirmed 30 on 2026-08-22 and FSD §13.1 governs, so the constant is the defect.
Why it cannot be guessed: Live-app work, not simulator work. Belongs with Q13.
The FSD names Terms of Service v2.4 — v2.5 superseded it six days later
Answered on 2026-08-24, by reading the document. Terms of Service v2.5 is “Complete and Restated — supersedes Version 2.4 in its entirety”, effective 2026-08-06. The FSD was updated 2026-07-30 and so predates it by six days: its companion-document reference is stale, not contradictory. And v2.5 §8.4 is “Category H — Pilot-Period Restrictions”, H-1 through H-9 — so every “Terms v2.5 §8.4” citation on this site is correct as written.
Why it cannot be guessed: What is left for Jay is a one-line canon amendment: the FSD's header table, and five further references, should name v2.5. Nothing else in the FSD moves. It is small and it is his, because the FSD is his document — and leaving it says the specification defers to a superseded instrument.
FSD §16.1 asks the Terms for six changes — v2.5 appears to have made all six
§16.1 is headed “Terms of Service v2.4 — Required Changes” and lists six. Reading v2.5 against it, each one has a home: the item-level schedule at §8.3–§8.6 (Categories A–G, Category H as H-1…H-9, Category I, Tier 2); the forfeiture redraft at §8.2.1, “Consequence Falls Upon the Breaching Party” — *“what the Lender forfeits is coverage … and not the Borrower's money”*, which is precisely what FSD §14.6 demanded; lender insurance at §6.6 and §6.8; consent to off-session charge and authorization refresh at §9 and §10.12; and uncollected and abandoned items at §10A. Risk allocation is the one that does not map cleanly — v2.5 spreads it across §15, §16 and §24 rather than the single new section §16.1 anticipated.
Why it cannot be guessed: The FSD does not know this happened. §16.1 still reads as a work order against v2.4, so anyone planning from it plans drafting work that is already done. Jay should confirm the mapping — particularly that §15/§16/§24 together implement FSD §15.1–§15.10 — and then §16.1 becomes a record rather than a list of debts.
CJ
4Design decisions and the shape of the specification.
Which source of truth survives?
The workshop agreed this repository is it. That supersedes the Drive folder CJ asked for forty minutes earlier in the same call.
Why it cannot be guessed: Both are in the same transcript. Someone has to say which one survives, out loud.
Where it got to: Half done — the repo is the source and the Drive folder carries an archive pointer. The wider question of what else moves is the source inventory.
The line-timer treatment
Lab 15 round 2 recommends icon + sentence (“Meetup starts in 1 day”). Round 1's pill was rejected — a chip means STATE everywhere else in the document, and a countdown is not a state.
Why it cannot be guessed: The one unratified lab.
“Make these thicker — the active one”
Unanswered on the call. The segment pips are now behind a disclosure and mostly unseen, which makes the display timer's progress bar the likelier reading.
Private sales are in canon twice and in the specification nowhere
FSD §3.3 gives the lender an optional for-sale listing, coordinated *through chat*, with no Shield and no evidence capture. The proposed Terms §8A builds thirteen subsections on top of it — and §8A.11 puts a hard gate in the conversation: before a user may send or receive a first message about a private sale, the platform must show a conspicuous notice, take an affirmative acknowledgment, and record it. The simulator has no sale surface at all — the only occurrences of the word are “sales tax”. §8A is PROPOSED: it is an insertion into v2.5 and is not in the effective Terms, whose sections run 8, then 9.
Why it cannot be guessed: This wiki specifies the conversation, and §8A.11 is a conversation requirement written into the Terms. Four more are product-shaped: §8A.2 forbids displaying a sale price or any offer, negotiation or payment function; §8A.3 allows the flag only on a listing that passes §8 and is not High-Risk, and removes it automatically when that stops being true; §8A.4 takes six representations on applying the flag and again on every edit; §8A.8(b) forbids any sale price from touching Item Value or Shield sizing. None of it binds until §8A is executed — but FSD §3.3 does bind, and even it is unbuilt.
All three
1Decided together, or still being decided together.
Handoff format, token scope, and whether Figma survives
CSS variables against Tailwind for the handoff; whether the full token set lands in boro-shared; and a direct contradiction to settle — CJ wants this back into Figma, Brad said “I almost feel like we don't even need Figma anymore.”
Nobody yet
5Not a question anyone can answer — work that has not been scheduled.
boro-shared carries no semantic tokens
boro-shared/tailwind/boro-theme.css has only the brand ramp, two surface steps, spacing and radii. There is nothing in the application to build this specification against.
Why it cannot be guessed: The real integration blocker. It does not move by building in the artifact.
Twelve design-system amendments, none applied
Everything this work settled that the design system does not carry — tokens that do not exist, components with no entry, rules that live in the build and not in the document. The full register is Design-system amendments, which is the one place it lives.
Why it cannot be guessed: It was three lists and they disagreed. This entry said ten and named .badge.info; Build state §9 numbered eight and named three things this one had missed, including the component specs — the largest item on the list; the status page restated this one. The union is twelve, and nobody was wrong on purpose: each was written in a different pass and none of them was the one place. Doc first, then regenerate boro-tokens.css, boro-typography.css and the Tailwind preset together. Never one alone.
RentalStageChip.tsx fails WCAG AA on five of twelve states
Worst 2.00:1, on the chip meaning a lender owes a decision. Live in the application today, independent of this artifact.
Why it cannot be guessed: Do not conflate with the simulator's accessibility pass. They are two efforts.
Chat guardrails, a rental-notes field, the review screen, feedback capture
Four things the workshop added that do not exist yet: blocking links and contacts with a notice to BOTH parties (Jay's rationale is liability evidence), an instructions field so manuals do not travel as links, the review screen, and “suggest an improvement”.
The listing-creation flow carries a compliance gate
FSD §14.5: “The restriction screen runs FIRST in the listing flow, before any other field” — screening against Terms v2.5 §8.4, blocking rather than warning.
Why it cannot be guessed: Not a screen to design and retrofit a gate into later. Brad named it as the next design.