feat(ports): surface listening ports per session in the fleet view

[jitokim]

Review

Review complete. I read the full diff (7 files, +742/−27), pivot.md §11, and ran go vet + the three affected packages' tests (all green). Verdict: solid — no blocking issues. Minor notes only:

• §11 design match: yes, with one deliberate, documented deviation. All of §11's first slice is there: Loop.Ports []int (nil = nothing observed), ListeningPortsByCwd() as two procTimeout-bounded lsof probes, applyPorts right after applyLiveness, the CwdVerified-only gate, exact-match-only v1, the gated probe (recommended option), dim 🌐:3000 FLEET tag + DETAIL PORTS row, and all four honesty rules. The deviation: §11 specified the cwd→loop join as encodeCwd(serverCwd) == Loop.ProjectDir, but the code compares real lsof paths (portsByCwd[loops[i].Cwd]) instead. That's strictly more honest — encodeCwd is many-to-one and could attach one dir's server to another dir's loop — and the applyPorts doc comment explains exactly why. Improvement, not drift.
• Pure observation: confirmed. Only read-only lsof exec; no open, no spawn/write/backend coupling; State/Stall never touched (pinned by TestApplyPorts_StateNeverTouched); probe failure attaches nothing. The §11 "open :3000" actuation was correctly left out of v1.
• Seam reuse: good, with mild parser duplication. procs.go now has three sibling p/n record walkers (parseLsofCwds, parseLsofListenPorts, parseLsofPidCwds) with near-identical loop skeletons. §11 anticipated this ("isomorphic to parseLsofCwds"), and each has a real reason to differ (count vs pid-keyed vs port-parsing), so it's acceptable — but a shared p/n record iterator is an easy follow-up if a fourth walker ever appears. TUI side reuses the ACCOUNT-column pattern faithfully (caller-requested, presence-gated, byte-identical rows when absent).
• Tests via injection seams: yes. Parsers and the join are tested on captured lsof output shapes; applyPorts/anyCwdVerified on injected maps; the width cascade, tag truncation (+N suffix drops, digits never sheared), demo fixture, and both DETAIL presence/absence cases are covered, including failure cases (probe failure, unverified cwd, subdirectory listener, bad pid lines). Only ListeningPortsByCwd itself is untested — consistent with LiveClaudeCwds, which has the same exec-boundary exemption.
• Nitpick (comment slightly overclaims): both new parsers document "an unparseable p line orphans the n lines under it, never credited to the previous pid," but a bare p line (length 1) is skipped by the len(line) < 2 guard before the switch, leaving pid at its previous value — so its n lines would be credited to the prior pid. Purely theoretical (lsof never emits a bare p; the tested pNOPE case is handled correctly), but if you want the comment to be literally true, reset pid = -1 for short lines starting with p, or soften the comment.
• Width math checked: the wPort = 10 claim about surviving renderWide's capped panel holds — at inner width 70 with ACCOUNT + PORT requested, the cascade sheds ORACLE and CYCLE and lands NAME exactly at nameGoodWidth (20), so PORT survives; at 12 it would drop. The 🌐:65535 fit claim (8 cols ≤ wPort−1) is also correct.
• Style/invariants: comment density and narrative style match the codebase; English-only holds throughout (code, comments, commit message); Conventional Commit format ok; demo fixture keeps its "only states the product can produce" discipline (ports ride a verified cwd, pinned by test).

🤖 Generated with Claude Code