[immakermatty]

Why

Slice P7 of the Launchpad parity program (#65 B8; root decision DEV-6616 "Launchpad Chat → T3"): the resident Launchpad's Chat entry into T3 Code, done in the Platform from the recorded handover entry — never from a hostname convention.

What changes

• Sidebar Chat (first item, T3 pattern) on a hosted Machine with a recorded entry; absent on a workstation (the resident's behaviour). A plain click does what the resident does (R:launchpad/src/t3-chat-lib.mjs:56-90): POST /api/chat/pair mints a one-time pairing token with T3's own CLI (t3 auth pairing create --base-dir ~/.t3 --ttl 60s --label launchpad-chat --json, t3 from the Launchpad's PATH) and opens <t3codeOrigin>/pair#token=…; the token is never logged, never in an error, never in a query. Without a launcher or on a failed call (409 t3-launcher-missing / t3-pairing-failed) the page follows the plain t3codeOrigin, where an unpaired browser is asked to pair; a modified click opens the plain origin in a new tab.
• GET /api/entry: {launchpadOrigin, t3codeOrigin, moduleOriginTemplate} or null, read-only, behind the existing admission; also answered in Recovery mode (the pairing route there keeps the Recovery refusal).
• Recovery page, hosted with a prompt: an "Open T3 Code" button next to "Copy the prompt" (plain link, new tab).
• No thread creation and no context passing (the resident creates none); no module-page link (the resident had none); no manual change (the resident's manual never mentioned Chat); lazurio chat link (C.5 item 10) is not in this slice.
• Tests: the entry route and the pair link from the recorded origin; a fake launcher with its exact arguments and the missing/failed/malformed cases with the token kept out of every answer; the workstation case; Recovery-mode route and link; a scan that no source under src/launchpad builds a hostname from labels. Docs: launchpad-development.md "Chat entry", hosted-entry.md, recovery.md, machine-handover.md.

Verified

Author of the slice: bun run check 919 pass; the page driven in headless Chromium with stubbed hosted answers (absent on a workstation; correct href on home, Settings, Recovery; the click lands on the pair URL, and on the plain origin when pairing is refused). Thread owner's bun run check on the merged head: exit 0; lint and the chat/recovery-page tests on 97ba9e8 (merges main after #75).

What only a real hosted Machine can prove

That t3 is on the Launchpad's PATH (Machines DEV-6624 adds ~/.local/bin/t3; until then Chat falls back to the plain origin); that the fork's t3 auth pairing create --json still returns credential; that /pair#token= pairs through the real gateway; that a browser already paired opens straight through the fallback.

🤖 Generated with Claude Code

[agentrozjedemeai]

@immakermatty — Exact-head QA for 97ba9e8: APPROVED. The recorded entry supplies the T3 origin; no Launchpad hostname composition. The hosted same-origin POST is admitted by the gateway, runs the PATH-resolved t3 auth pairing create --base-dir ~/.t3 --ttl 60s --label launchpad-chat --json call, and returns the token only in the /pair fragment. A disposable fake launcher with a marker credential in stdout/stderr confirmed no console or failure-body marker and an empty URL query. Workstation returns 404 and Recovery mode refuses pairing while GET /api/entry remains admitted. Resident t3-chat-lib.mjs at c9b57da8 and Machines t3 base-dir at 7b2bcaa were compared. Local lint, typecheck, 935 tests (4 platform skips), public guard, proof build/smoke pass; both required ubuntu-24.04 and macos-14 checks succeeded on this exact SHA. No unresolved review threads. This is a review only; do not merge as part of this request.