Two drifts in docs/design/cli-contract.md's crew ui coverage, both found while reviewing PR #85 (which fixes a different crew ui claim in the same document — the --json opener gating — and deliberately left these alone as outside #28's scope).
1. The human-output bullet describes output that is never printed. docs/design/cli-contract.md:767-769 reads:
crew ui prints the authenticated local-only URL and whether it opened the browser, then stays in the foreground until Ctrl-C. --no-open reports that the browser was not opened.
Neither sentence holds. renderUiStarted (src/format.ts:326-334) prints exactly two lines — Console listening at <url> (workspace <path>) and The URL embeds this run's secret token — do not share it. Ctrl-C stops the server. — and neither mentions the browser. runUi then invokes the opener silently and swallows its failure without emitting anything (src/ui/index.ts:118-124). So crew's human surface never reports whether the browser was opened, and --no-open produces no output of its own.
2. The crew ui port-failure sentence names no error code. docs/design/cli-contract.md:376-378 says an invalid or unavailable explicit port makes the command fail, without naming the code — while the meaning table (:480, as of PR #85) does name Console startup failure under LAUNCH_FAILED. The two failures also differ: an invalid port value is USAGE, whereas a port that is merely unavailable surfaces as LAUNCH_FAILED (src/ui/index.ts:103-109, never a fallback bind per FR-U03). This is the same omission #28 recorded for crew join / UNSUPPORTED_PLATFORM, which was fixed in the Agent-lifecycle section but not here.
Impact: the first is a false statement in an authority-level-3 document about the surface an Operator actually sees — a reader who scripts around "crew reports whether the browser opened" is building on nothing, and a reader debugging a silent opener has no way to learn the failure is swallowed by design. The second leaves the crew ui section inconsistent with the error table one PR just corrected, so the two extra LAUNCH_FAILED/USAGE causes remain undiscoverable from the section a reader consults for crew ui.
Acceptance: the human-output bullet states what renderUiStarted actually prints (the URL line and the token warning) and drops the claim that either the default path or --no-open reports on the browser; the opener's silent-failure-by-design behavior is stated where a reader would look for it; and the crew ui port sentence names USAGE for an invalid port value and LAUNCH_FAILED for an unavailable one, matching the meaning table.
Two drifts in
docs/design/cli-contract.md'screw uicoverage, both found while reviewing PR #85 (which fixes a differentcrew uiclaim in the same document — the--jsonopener gating — and deliberately left these alone as outside #28's scope).1. The human-output bullet describes output that is never printed.
docs/design/cli-contract.md:767-769reads:Neither sentence holds.
renderUiStarted(src/format.ts:326-334) prints exactly two lines —Console listening at <url> (workspace <path>)andThe URL embeds this run's secret token — do not share it. Ctrl-C stops the server.— and neither mentions the browser.runUithen invokes the opener silently and swallows its failure without emitting anything (src/ui/index.ts:118-124). So crew's human surface never reports whether the browser was opened, and--no-openproduces no output of its own.2. The
crew uiport-failure sentence names no error code.docs/design/cli-contract.md:376-378says an invalid or unavailable explicit port makes the command fail, without naming the code — while the meaning table (:480, as of PR #85) does name Console startup failure underLAUNCH_FAILED. The two failures also differ: an invalid port value isUSAGE, whereas a port that is merely unavailable surfaces asLAUNCH_FAILED(src/ui/index.ts:103-109, never a fallback bind per FR-U03). This is the same omission #28 recorded forcrew join/UNSUPPORTED_PLATFORM, which was fixed in the Agent-lifecycle section but not here.Impact: the first is a false statement in an authority-level-3 document about the surface an Operator actually sees — a reader who scripts around "crew reports whether the browser opened" is building on nothing, and a reader debugging a silent opener has no way to learn the failure is swallowed by design. The second leaves the
crew uisection inconsistent with the error table one PR just corrected, so the two extraLAUNCH_FAILED/USAGEcauses remain undiscoverable from the section a reader consults forcrew ui.Acceptance: the human-output bullet states what
renderUiStartedactually prints (the URL line and the token warning) and drops the claim that either the default path or--no-openreports on the browser; the opener's silent-failure-by-design behavior is stated where a reader would look for it; and thecrew uiport sentence namesUSAGEfor an invalid port value andLAUNCH_FAILEDfor an unavailable one, matching the meaning table.