Post-review build order

Field	Value
Version	1.9
Updated	2026-08-22
Target file	the simulator — 44 screens
Source	Call record v1.2 — call of 2026-08-21
Open items	Open items v1.9 — every blocker and question, by owner. Source of truth.
Build state	Build state v3.4 — read §2 rules and §5 ratified decisions first
Deadline	Jay workshop 9:00 AM Brad’s time, 2026-08-22. Brad targets testable by Tuesday if it lands.
Verify	`SMOKE PASS 368 + 74 form + 76 dock + 4 arrival + 96 chain + 96 chat + 13 live + 35 walk + 3 all` · master all three identical · token drift clean
Ship gate	G-1 and G-2 COMPLETE 2026-08-21. See §Ship gate.

BLUF

THE POST-REVIEW BUILD LIST IS FINISHED. G-1 and G-2 landed 2026-08-21; B-1 through B-10 followed; B-5, D-3 and the six remaining forms landed 2026-08-22; Refresh Tap and the all-stages view landed the same day once R-4 settled at 30 days.

What is left: B-11, and nothing else. It is blocked on D-4 + Q3, which are one question and settle together.

Of the three things that must not be guessed, one is now decided. D-3 is SETTLED — the dock wins (CJ, 2026-08-22), and the in-thread branch and its toggle are withdrawn. D-1 is built as a proposal to CJ’s ratified reading and awaits Brad’s and Jay’s reaction. D-2, the blue bubble, still must not be built — and it matters more now that B-5 has put conversation between every milestone.

Ship gate — before 9:00 AM

Brad stated the gate twice. 42:16: “try to make sure that we’re not missing those next step buttons at each stage. And then I think we’re good to show Jay. And the images.”

✅ G-1 · The two initiating actions and their forms — DONE 2026-08-21

Verified by measurement: exactly 2 controls on the 3 renter screens and 0 on all other 20 stages across both roles and both lanes; the second label derives from the item (worn → Request Try-On); both open a form; each form sends to a real stage. STAGES[] unchanged.

Widened to three screens — interest, inspection-concluded, schedule-denied — ratified by CJ. Brad’s own renterCan for schedule-denied reads “Schedule try-on / pickup again” and its chip is literally Interest; stopping at two would leave a denied proposal with no way forward.

The forms could not be stages. fillSelect() indexes the picker by position in STAGES[], so a Forms optgroup from there would have meant editing Brad’s master. They live in a separate FORMS[] array with form: addressing. Form and pending card read from one PROPOSAL object, so the card is the preview rather than a second copy that can drift.

Placement is D-3 and stays open. Built in-thread at the foot of the thread; the old “the action dock was removed” flag is rewritten as a reversal under test carrying both quotes and naming the two places that move if the dock wins (.next-actions, and the one nextStepHtml() call site).

Bug found by rendering, not by the harness: document.fonts.ready.then(pinThread) fired after a form rendered and scrolled the request’s own heading off the top of the screen. Guarded.

Original specification

G-1 · The two initiating actions and their forms

Scope is smaller than it first reads. Brad blessed card-borne next steps at 21:57 — “the next step can be like on that card. That makes sense. But to initiate … there needs to be like a button for that.” So:

A next step that follows an event → lives on that event’s card. Most of the 23 stages are this, and most already have the slot.
A next step that initiates something → needs a persistent control. There are exactly two.

The two controls, renter view:

Control	Label rule
Schedule Rental	fixed
Request Inspection	Request Try-On where the item is worn; Request Inspection otherwise

Gating — these appear on two screens only: renter interest, renter inspection-concluded. Never on the lender view, never during an inspection.

Placement: build CJ’s in-thread version, above the composer, scrolling with content — and mark it under test in the Styles panel. Brad conceded it for the workshop without endorsing it (29:01: “we can see how it feels… We can certainly do it that way until it’s built”). Jay breaks the tie. Do not delete the flag recording that the dock was removed — amend it to a reversal-under-test.

The forms. Each control opens a form screen; what the renter submits renders as a preview on the matching requested stage:

Control	Form stage	Preview lands on
Schedule Rental	`form-propose-pickup`	`rental-requested`, renter view
Request Inspection / Try-On	`form-propose-inspection`	`inspection-requested`, renter view

Both go under a new Forms optgroup. These are two of the eight forms in HANDOFF §7 item 4, pulled forward. Include on each: date, time, session length (45 min, FSD §10.2), venue, and the terms panel with the commitment-hold amount — which also closes the long-standing gap that the hold is only visible in the terms panel and never on the pending card.

Label derivation stays out of STAGES[] — same seam as chipLabel(). Hard rule 1 holds.

Acceptance: on renter interest and renter inspection-concluded, exactly two controls; on all 21 other stages and every lender view, zero. Each control opens a form; each form’s submission is visible as a preview on its requested stage. STAGES[] byte-identical.

✅ G-2 · Real item images — DONE 2026-08-21

Source is BoRo’s own licensed library — boro-landingpage/public/assets/categories/. No external fetch, no third-party rights question, and they are the pictures the marketplace already ships. Four items at 200px as data URIs; the file went 200 KB → 237 KB. The harness now fails on any absolute URL that is not one of the two font hosts, which is what protects rule 3 as images go in.

Screened by make and model against Terms v2.5 §8.4: drills appear nowhere in the schedule; pressure washers are permitted at any rating (§8.4.4 H-4); apparel appears in none of the nine H-subcategories and §8.5 Category I is life-safety only, so the gown is permitted; a camera lens is nowhere in the schedule and §8.4.9 H-9 is Unmanned Aircraft, which a lens is not.

The wearable is a Sherri Hill Beaded Gala Gown, which makes the Request Try-On branch exercisable — opening that conversation switches the hero and the label follows.

One swap, flagged — and reversed on 2026-08-24 (R-3). The Dyson Airwrap became a Sony FE 70-200mm f/2.8 GM Lens on 08-22 because the image library held no hair-styling device and the styler rendered as a flat glyph among three photographs. CJ supplied a photograph on 08-24, so the Airwrap is back and G-2 holds. The first attempt at the revert, made before the photograph existed, failed the G-2 assertion in eight places — which is how “one line to revert” turned out to cost a ratified decision.

Original specification

G-2 · Real item images

Brad, 19:10: “can we put in some images for the items?… some real images or whatever.”

The three sample items already carry make-and-model names — DeWalt 20V MAX Cordless Drill, Ryobi 1900 PSI Electric Pressure Washer, Dyson Airwrap Multi-Styler — and all three are PERMITTED under Terms v2.5 §8.4, so images of them raise no screening question. Replace the inline SVGs in the thread header and the conversation rows.

Add one wearable sample item so the “Request Try-On” branch in G-1 is exercisable — nothing in the current set is worn. Screen it by make and model against Terms §8.4 before it goes in, and keep it out of Category I (§8.5), which is permanent and includes helmets, PFDs and protective gear.

Constraint: the file stays self-contained. Images embed as data URIs, or the single-document rule breaks.

After the workshop, in order

✅ B-1 — DONE 2026-08-21. Check-in states — four, viewer-relative. Adopt CJ’s four-state structure under the existing Check-in · prefix, not GPS Check-in ·:

Check-in · Nobody arrived
Check-in · I arrived first
Check-in · They arrived first
Check-in · Both arrived

Why not “GPS”: batch 3 removed it deliberately — “named the technology rather than the state” — and Brad has since asked for a manual check-in fallback. A chip reading “GPS Check-in” over a manual check-in is describing a mechanism that was not used. Check-in · survives both paths.

The blocker inside this is RESOLVED. CJ chose the who-arrived-first dimension on 2026-08-21, so all four labels render honestly and the harness asserts the chip and the card body name the same party. Original statement of the problem: CHIP_LABEL["gps-one-arrived"] hardcoded the renter as the early arriver, and the card copy beneath reads “Brad checked in · Jun 24, 9:58 AM. Waiting for Zach.” You cannot render “They arrived first” honestly over that. Decide before building: add a who-arrived-first dimension, or document renter-first as a fixed simplification in the Styles panel. Shipping the label over the hardcode is the one outcome to avoid. The card body swaps by viewer alongside the chip either way.

✅ B-2 — DONE 2026-08-21. The “I’m here” control. Appears on exactly two states — the two where the viewer has not checked in: Nobody arrived and They arrived first. Not on “I arrived first,” not on “Both arrived.” It initiates a geofence check rather than polling (Brad, 25:50: “we don’t want it, like, constantly checking the geofence stuff”).

Keep it distinct from the manual fallback — they are two controls and merging them loses the failure path:

Control	Role
“I’m here”	Initiates the check
Manual check-in	Fallback when that check fails — assert presence, evidenced by a photo of the location

Manual is deferred to Jay by Brad’s own instruction (25:30). The enums already carry MANUAL_PENDING / MANUAL_CONFIRMED / MANUAL_FAILED.

✅ B-3 — DONE 2026-08-22, as a proposal. The real QR code. Built to the reconciling reading CJ ratified: one booking code on both devices, either party scans, the scan confirms both. Deliberately not scannable. Original note: Replace the lender’s “Generate QR” on the checkin-both card with a rendered code. Do not draw it until D-1 lands, and decide what it encodes; a scannable code resolving to nothing is a trap in a workshop.

✅ B-4 — DONE 2026-08-22. Collapsible past cards + merged completion summary. Past cards collapse to a summary line with an expand affordance; return-assessment and rental-concluded merge into one “Rental completed” card carrying the summary. This is also the structural answer to Q17’s badge column. Money was scoped OUT of the first pass, deliberately, and the harness fails a folded card that states a fee. Original warning, still live for whenever it is scoped in: Brad listed “price and taxes” among the expanded detail. No card in the file states money today. Surfacing it means the 7% / 3% split (FSD §6.3), travel (§8.7) and sales tax — and §16.2 lists sales tax as an unsettled cross-document dependency. Either scope the money view deliberately or leave it out of the first pass; do not let the detail pane become the first surface to state fee mechanics.

✅ B-5 — DONE 2026-08-22. Simulated conversation between milestones. The Chat and Timeline tabs now differ (Brad, 37:22).

Built as a presentation-layer FILLER array, and Brad’s master was NOT edited — that was the choice, not the old prohibition. CJ authorized editing SAMPLE_CHAT where the presentation layer cannot do the job honestly. It can do this one. This doc previously recommended extending his master as “the cleaner of the two options”; that recommendation was wrong for a reason it had already identified two sentences later. His five messages are drill-specific — “more about this drill”, “holes in Jays walls” — so weaving per-item conversation through them means rewriting them into an item-keyed structure. That is a change to the SHAPE of his data, not an addition to it, and it would reach him as a large diff of copy he never wrote. The master check still reports all three blocks identical.

How it works: a filler message carries an at on the same phase spine EVENTS() uses, and messages and cards merge into one sorted stream. Adding conversation later means giving it a phase, exactly like adding a stage. The Timeline tab renders milestones only and states the number of messages it is collapsing.

Two things worth carrying forward. The lens carries no conversation on purpose — it is the document’s empty-thread sample, a Cancelled inquiry nobody replied to, and the harness asserts it stays empty so it does not read as an oversight. And the conversation row now previews the thread it is showing: it read the last SAMPLE_CHAT entry unconditionally, so after B-5 it said “EXACTLY.” while the thread ended four days later.

✅ B-6 — DONE 2026-08-21. Return / condition-assessment display timer. Brad, 33:41: “We probably need a timer up again for condition assessment.” Duration is 45 minutes — FSD §10.2, one session per phase, the return session being the lender’s. Only one live display timer per thread still holds.

✅ B-7 — DONE 2026-08-21. Review action on review-pending. Brad, 35:20: “If we’re going to have review pending, we should probably have like a review the person kind of thing.”

✅ B-8 — DONE 2026-08-21. Next steps on exception and terminal stages. Brad, 36:28: “we always want to have that, like, next step.” Contact-support is the sensible action on dead ends. Card-borne under G-1’s rule — no persistent control needed.

✅ B-9 — DONE 2026-08-21. Lane B segments accrue rather than pre-render. Default view is the plain return date; segments live behind a disclosure and accumulate as consumed. Changes the ratified “five pips, current one amber” and probably moots Q15.

✅ B-10 — DONE 2026-08-21. “Request a change” on an agreed return. A bounded time/place adjustment, not a renegotiation — Brad, 32:22: “the meetup to return has to be decided prior because you can’t have negotiation of where to return.” Ninth form stage.

B-11 · No-show reads as a consequence, not a filing — still blocked on D-4 + Q3, which are one question and settle together.

✅ The six remaining forms — DONE 2026-08-22. Meetup chooser, cancellation confirm, report a problem, extension request, flag damage, condition capture. All nine forms now exist, and formHtml() was rewritten declaratively on the way: it used to branch on kind through a chain of ternaries, the harness carried a second copy of that chain, and at nine kinds it crashed outright. A form now declares its fields, its warning, its party and its target, so a tenth is a data entry. Grounding: §6.1 and cancellation.ts for the pricing, §10.3 for the condition record, §10.4 and §10.6 for report-a-problem, §11.2/§11.3/§11.5 for the damage ticket, §13.2/§13.3 for the extension.

request-extension states D-5 as open on the face of the screen — the field reads — D-5 · not set in canon and the harness fails if a digit ever lands in it, because that is how “back within that one day” would otherwise become a specification.

✅ Refresh Tap — DONE 2026-08-22, unblocked by R-4 settling at 30 days. Two Lane-B-only proposed stages: Lane A carries no Shield, so activeLane() forces B and the toggle hides — the existing rule, where hidden also means inert. §13.6’s double-hold disclosure sits on the same screen as the button because the FSD says before the tap and calls it not optional. §13.4’s ordering is stated as the safety property it is — new Shield first, prior one released only on success — along with why it cannot renew in the background. §13.5’s “the rental does not cancel” is the whole message of the declined screen, not a footnote. Four of those are asserted by name.

✅ All-stages view — DONE 2026-08-22, built last on purpose because it inherits whatever the thread does. All 44 screens side by side as real threads, pinned to the bottom of their own history, proposed stages marked.

Everything on this list is now built. B-11 is the only item waiting on anybody.

Do not resolve — build the comparison, leave the decision

Also in Open items, grouped by owner alongside everything else that is open.

This table and REGISTER §1–§3 are the only D-register. HANDOFF §4 carried a second, conflicting set of D-tags until 2026-08-22 — its rows read D-2/D-4/D-5/D-6 and meant different things from the rows here. They are now V-1…V-8, verification results rather than open decisions. A D-tag anywhere else is stale.

Two are settled: D-3 (docked, 2026-08-22) and D-1 (built as a proposal). The rest stand.

#	Decision	Why it blocks	Route
D-1	RESOLVED AS A PROPOSAL 2026-08-22 — CJ ratified the reconciling reading and it is built, so nothing is blocked. Brad and Jay still have to react; if they land elsewhere, the change is in `qrPanel()` and one card. Original: three live positions: FSD §10.1 (one booking code, geofence-gated, both devices inside); Brad, 26:56 (“they should both have a QR code or scan the other person’s… whoever wants to do it”); and S-4’s lender-side code, which is a third model.	Substrate for both check-in chains — gets built on twice. The reconciling reading: one booking code, rendered on whichever device is looking, either party scans. FSD-compliant and matches Brad’s words.	`[BRAD-CONFIRM]`
D-2	Blue own-bubble. Reverses `surface-inverse`, and no blue exists in the BoRo token set. Hedged three times — “for now”, “I guess”, “we’ll see”.	Hard rule 2: a colour change is DS-doc-first, never a local hex. This is a new semantic token and a ninth entry on the HANDOFF §9 amendment list, where none of the eight are applied. Also unresolved: CJ argued at 39:40 that the counterparty’s bubble should carry the emphasis; Brad answered with convention, not reasoning, and it was dropped.	`[CJ-DECIDE]`
D-3	~~Dock placement~~ — RESOLVED 2026-08-22 by CJ: DOCKED. Brad’s original placement is the standard. CJ’s in-thread version and the capture-bar toggle that carried both are withdrawn. `dockMode` is gone, `threadHtml()` emits nothing, `composerHtml()` always emits `nextStepHtml()`, and the harness asserts `.next-actions` is absent from `#thread` at every stage and both roles.	Recorded in the Styles panel as the SECOND reversal on this control — removed by decision 2026-08-21, restored by decision 2026-08-22 — with both reasons, so neither is restored by accident. CJ’s objection is unrefuted and carries forward as a constraint: the dock “covers up so much of the chat”, so it stays two buttons and never grows back into the deleted nine-control `.action-row`. Tell Jay — the register named this as his decision.	CLOSED
D-4	No-show tone. Brad wants red, not grey. Tone derives from `TONE_BY_STATUS`; `terminated` is neutral.	Cannot be a one-off colour: either `terminated` moves to error platform-wide — repainting ordinary terminations — or no-show becomes its own status. Data-model question, and it is the same question as Q3’s naming. Settle both together.	`[BRAD-CONFIRM]`
D-5	Extension decline window. CJ referenced “back within that one day” (31:44). FSD §13.2 names no lender response window.	Either it exists somewhere unread, or it is an assumption that will get built. Belongs in the FSD if real.	`[BRAD-CONFIRM]`
D-6	`SESSION_MINUTES` 30 → 45. Applied per FSD §10.2; Brad’s gap note still carries the question against live `inspection_duration_minutes`.	The FSD governs the file. The live field is his.	`[BRAD-CONFIRM]`
D-7	“Make these thicker — the active one” (43:00). Unanswered; unclear whether it means the segment pips or the timer bar.	Ask CJ which. If it is the pips, it folds into Q15 and B-9.	`[CJ-DECIDE]`

Also still open and untouched by this call: the eight Brad-only items and the five integration items in BRIEF §5 — including Q9, no semantic tokens in boro-shared/tailwind/boro-theme.css, which remains the real integration blocker, and Q13, RentalStageChip.tsx failing AA on five of twelve states in the live app. Neither moves by building in this file.

Smoke assertions to add

Build the assertion with the decision — HANDOFF §11. Each of these fails today because the behaviour does not exist yet.

Initiating controls appear on exactly two screens — renter interest, renter inspection-concluded — and on zero others, at both roles, both lanes.
Every form stage’s submission is reachable as a preview on its matching requested stage.
“I’m here” appears on exactly two check-in states, and never where the viewer is already checked in.
The check-in chip label is one of the four in B-1, and never contains the string GPS.
The one-arrived chip and its card body name the same party — the assertion that would have caught the hardcode.
Item images resolve — every item slot renders a real image, no empty or broken source, and the document makes no external requests beyond the two font hosts.
Card collapse: exactly one card is expanded by default (the live one), and every collapsed card exposes an expand control.
Existing rules unchanged: one live display timer, badges from the closed vocabulary, .action-row absent from the DOM, history never shrinks along the spine.

The badge vocabulary is FOURTEEN entries — corrected 2026-08-22

This line said twelve until now, and HANDOFF §5 has said fourteen since 2026-08-22. A harness rule regenerated from the short list fails a real card — which is exactly how Ready to pair was lost once already. The full list:

Approved · Completed · Active · Pending · In process · Ready to pair · Under review · Flagged · Denied · Overdue · Expired · Closed · No show · Not returned

The last two joined on 2026-08-22 when both terminal cards went red and Closed stopped being the right word for either. HANDOFF §5 is the source; check it before regenerating any rule from this document.

Added 2026-08-22, with the work they came from

D-3 · exactly one placement exists. .next-actions renders inside .composer on the three screens that carry controls, and is absent from #thread at every stage and both roles. Absent from the DOM, not hidden — the rule .action-row is held to, and hidden-not-deleted is how the old nine-control row kept shipping after its own removal.
B-5 · the rendered message count equals the model’s, per item and per phase, so a message cannot leak past the phase it belongs to.
B-5 · runs survive the merge. One visible avatar on the last of a run, and a run never spans a card or a date separator.
B-5 · conversation actually falls between cards at a late phase. Without this the merge could no-op and every other message assertion would still pass.
B-5 · the Timeline tab renders no bubbles, and still renders its cards.
B-5 · the lens stays empty — the deliberate empty-thread sample.
B-5 · no money in FILLER, read from the data rather than the DOM, so it holds for copy that never renders at a probed phase.
The open conversation row previews the thread it is showing.
Forms · a form does not change with the viewer’s role. Rendered at both roles and compared byte for byte, which is what catches formPerson() leaking the global role.
Forms · the two actions never share a verb. The cancellation form shipped with both buttons reading Cancel, meaning opposite things. The harness passed it; a screenshot caught it immediately.
Forms · the chooser routes and cannot be sent, and every route resolves to a real form.
Forms · D-5 stays open — a digit in the lender-response-window field fails the run.
Forms · the damage ticket distinguishes the lanes — Lane A has no Shield, so a form that reads identically in both is stating one of them wrongly.
Forms · a send target resolves in STAGES[] or EXTRA_STAGES, since the condition capture lands on a proposed stage.

Patches to the other docs — applied 2026-08-21

Both companion docs were updated when this one landed, so nothing here is owed. Recorded so the changes are traceable.

Build state → v2.1 — header now points at this doc as the work order and at NOTES as the call record, with the predecessor build list corrected to v1.3 and marked superseded; §5’s “No action dock” rewritten as a reversal under test so no future session restores the removal Brad asked to undo; §5’s badge vocabulary corrected to twelve entries — Ready to pair was missing and is live on the pairing card; §7 ordering superseded by the ship gate below; §8 gained the five decisions from the call. Changelog at §12.

Review method → v2.1 — gained a sixth bucket, Acknowledged gaps, and a §8 coverage obligation: a coverage ledger, three mechanical scans, and a two-pass rule. The brief specified the output shape but never obliged a reader to account for the input, which is how the first pass over this call lost two gaps that were plainly in the transcript. Companion reference corrected from HANDOFF v1.7 to v2.1. Changelog at §9.

The Styles panel — still owed, and it is build work rather than a doc patch. Every decision below lands there or it did not happen. Reversals get written as reversals with their reason, per the working pattern that has already saved four decisions from being “fixed” back.

Starter prompt

Context: you are updating the BoRo Stage 2 chat lifecycle simulator, a single
self-contained HTML document at
"/Users/cjoltman/Library/CloudStorage/GoogleDrive-cj@bannerwave.com/Shared drives/BannerWave/BoRo USA/App/Chat Lifecycle/chat-lifecycle-stage-simulator-v2.html".
It is a 23-stage clickable specification of the rental conversation, reviewed
with Brad Larson on 2026-08-21 and going to a workshop with Jaydan Nguyen at
9:00 AM on 2026-08-22.

Deliverable: work BUILD_ChatLifecycle_PostReview.md in order. G-1 and G-2 are
the workshop gate and land first; everything under "After the workshop" waits.

Constraints: STAGES[], SAMPLE_CHAT and ALWAYS are Brad's master and must stay
byte-identical, so labels and copy derive in the presentation layer. Check
token drift against boro-tokens.css on every deploy. The document stays
self-contained, fonts excepted, so images embed as data URIs. Where the FSD
and a built screen disagree on transaction behaviour, the FSD governs. Item
eligibility is screened against Terms of Service v2.5 section 8.4 by make and
model. Measure and look; neither substitutes for the other. Do not resolve anything tagged
D-1 through D-7; build the comparison and leave the decision.

Source pointers: HANDOFF_ChatLifecycleSimulator.md v2.1 for build state and
the smoke harness; NOTES_CallReview_ChatLifecycle.md v1.2 for the call record
with quotes; boro-ops/product/BoRo_MasterFSD.md sections 10, 11, 13 and 14;
boro-shared/src for the enums. Read those in the mounted working tree.

Start by running the smoke harness on the file as it stands and reporting the
baseline, so any regression from this pass is attributable.

Changelog

v1.8 — 2026-08-22. B-5 and the six remaining forms marked done; D-3 moved to CLOSED in the do-not-resolve table. Two corrections to this document’s own guidance:

The badge vocabulary said twelve entries; it is fourteen. HANDOFF §5 had already moved. This document is the one a builder regenerates harness rules from, and its own §Smoke assertions warned that a rule built from a short list fails a real card.
The B-5 entry recommended extending SAMPLE_CHAT as “the cleaner of the two options”. That was wrong for a reason the same paragraph already named — the copy is drill-specific — and the built answer is the presentation-layer array. The recommendation is corrected rather than deleted, so the reasoning is visible.

Also: header versions corrected (REGISTER v1.6, HANDOFF v3.1, this doc v1.8 — all three were stale in every direction); a note that this table and REGISTER are the only D-register, after HANDOFF §4’s conflicting D-tags were relabelled V-1…V-8; and fifteen new smoke assertions recorded against the work they came from.

v1.9 — 2026-08-22. Refresh Tap and the all-stages view marked done; header versions and the verify line refreshed. The post-review build list is complete, B-11 excepted. One finding recorded in the register as R-11: a Lane B term carries four Refresh Taps and the phase spine has one position for the rental, so a tap is built as an interruption rather than a step — the same finding B-9 reached from the segment side.

v1.7 and earlier. See the body — the ship gate, B-1…B-10 and the check-in chains.