W3 PINS AND OUTSTANDING ACCEPTANCE CASES. Source reads and gh queries only; nothing run, no probe. FIRST, A DISAMBIGUATION, because the noun is overloaded and I nearly reported the wrong wave. "W3" in my own durable notes is milestone A's ENGINE-ROOM + EMPOWER wave (ADR-0052, July). That is NOT this W3. The live one is REMOTE-FRICTION-PLAN.md section W3, "responsiveness and truthful client guidance". Everything below is the latter. Say so if you meant the other. == PINS == PLAN, the governing document: docs/REMOTE-FRICTION-PLAN.md blob c9ab6b6bafcebc4aaf1d66933c65bea7b2300da6 docs/REMOTE-FRICTION-GRILL.md blob 6dbe2e7dc3ad0912a6b28ae8e094d7bee0c4f182 both last written by b12d4619 "docs(remote-friction): land #304 grill journal, plan and register addendum", 2026-09-11. PRODUCT, i.e. what the field evidence is bound to: v0.69.0 = 16df0e41be04ca4614a792f7e70e4d1bdec60b24 "release: v0.69.0 -- version material only", 2026-09-10. Working tree version is 0.69.0. #299 and #302 are both reported AGAINST 0.69.0. #49 was filed 2026-07-31, long before it, and its evidence is NOT 0.69.0-bound. main HEAD right now: 1ac2699f365353f622e584a1198f5182dbd6f48f (my receipt amendment). There is no W3 code pin to report: NO W3 IMPLEMENTATION EXISTS YET. All four issues are state: WIP with no commit against them, so anything I called a "W3 product pin" beyond the release above would be an invention. == THE FOUR ISSUES, all OPEN, all state: WIP + type: BUGFIX, no milestone, all updated 2026-09-11T07:10Z == #299 endpoint list --show-all recurring ~10s stalls with COMPLETE UNCHANGED output Evidence (perri, standalone 0.69.0, HFENDULEAM): unpiped runs at 3822 / 10120 / 10105 ms, each rc=0, each byte-identical 2497-byte complete output. Three adapter field traces show long roster stages. No adapter-imposed subprocess timeout; bare CLI reproduces. Unreachable peers are CORRELATED, NOT ESTABLISHED CAUSE. ACCEPTANCE, outstanding: identify the WAITING STAGE and remove the diagnosed unnecessary delay while preserving full roster, suspended rows, local merge and truthful unavailable state. MUST distinguish network deadline vs local contention vs metadata cost BEFORE choosing a fix. MUST NOT substitute an empty or partial roster, move reads past destructive consumption, or widen a harness-specific timeout. whoami is NOT an equivalent substitute -- public docs promise a bounded identity-only whoami, never a numerical full-roster latency bound. Remedy must clarify list freshness/blocking semantics. Gate at the diagnosed seam and demonstrate complete output without the wait. Nonurgent per reporter; no adapter rework requested. #302 rc sessions frequently hitch Evidence (discord:reavo, 0.69.0): pty stream AND input freeze every 10-20 s, freeze lasts 5-10 s, all input ENQUEUES during the freeze and the whole queue DRAINS when it ends. Seen on enlyzeam->gravity-nvidia-temp, enlyzeam local, and gravity-nvidia-temp local -- so it is NOT remote-only. ACCEPTANCE, outstanding: diagnose then fix. Queued terminal input must be preserved (it already is, per the report -- the drain is evidence the queue works, so a remedy must not "fix" it by dropping input). No timeout widening, no partial-output fallback, no silent rerun-as-fix. #49 all rc connections freeze across `spt daemon refresh` / staged self-update restart Operator-filed 2026-07-31 via you. LONG-STANDING WITH A FAILED-FIX HISTORY: attemptedly fixed more than once, none held. Every prior "fixed" claim is to be treated as REFUTED by field evidence. ACCEPTANCE, outstanding and unusually strict: the RCA MUST EXPLAIN WHY THE PRIOR ATTEMPTS FAILED -- not merely propose another patch. The issue itself names the tension to weigh: the broker/brain split exists precisely to keep endpoints including rc viewports alive across a brain swap, and rc reconnect plus no-endpoint-terminates-during-update obligations BOTH exist in the registry with shipped evidence, yet the field behaviour persists. So either the contract is satisfied in test but unsound in the field path, or a different layer -- viewport pump, attach lease, broker handoff -- is the real owner. ONE SUPERSESSION TO NOTE: the issue body still carries the 2026-07-31 operator sequencing ruling coupling #49 to #42 in a joint RCA-first lane after the #40/#41/#43/#48 EVAL batch. The W3 plan line EXPLICITLY SUPERSEDES that #42 coupling. The issue text has not been updated to say so, so a reader going to the issue first gets the superseded sequencing. Worth an issue comment; I have not written one. #267 spt daemon refresh stalls session PTYs Evidence (discord:reavo): also happens after spt update. KEY PROPERTY: all PTYs RECOVER after an intentional detach plus a followup rc/go back to the SAME endpoint session. ACCEPTANCE, outstanding: same lane as #49 by your "#49/#267" pairing. I AM NOT TREATING #49 AND #267 AS ONE CAUSE. The plan's own rule is that symptom similarity does not merge causes, and these differ in a discriminating way: #267 RECOVERS on detach+reattach, which says the endpoint and its PTY survived and the CLIENT-SIDE attach is what is wedged. #49 says connections freeze, with no recovery property stated. If #49 also recovers on detach+reattach they may be one bug; if it does not, they are two, and the recovery asymmetry is the discriminator. That is a question for the reporter, not something I can settle from source. ALSO MINE IN THE PLAN, NOT IN YOUR ASK: #230 ATTACH_CLIENT_STALE. The plan line assigns it to me alongside these four. Flagging so it is not dropped by omission; tell me if it is deliberately out of scope for now. == NEXT SOURCE-ONLY WORK, executable during the W2 build, no probes, no rig == Ranked by how much a source read can actually settle. Hertz owns reproduction instruments and regressions, so none of this builds a rig. 1. #299 -- TRACE THE ROSTER PATH AND CLASSIFY THE WAIT. The acceptance criterion literally requires distinguishing network deadline / local contention / metadata cost before any fix, and that is a pure source read: follow endpoint list --show-all from the verb through roster assembly and enumerate every blocking call with its deadline source. HIGHEST VALUE: the 3822 vs 10120 vs 10105 ms shape, with byte-identical output every time, is consistent with a deadline being HIT rather than work being done -- a ~10 s ceiling twice is a timeout signature, not a cost curve. Naming the constant and its owner is a source-only finding that either confirms or kills that reading. 2. #49 -- FAILED-FIX ARCHAEOLOGY. The RCA is required to explain why prior attempts failed, and the prior attempts are in the git history and the registry. Enumerating them, with what each claimed and what shipped evidence each carried, needs no probe and is a prerequisite to the RCA rather than part of it. This is the piece that has blocked #49 for six weeks and it is entirely readable. 3. #302 -- PERIODIC-CADENCE CANDIDATE GENERATION. A 10-20 s period with a 5-10 s stall is a duty cycle, and duty cycles come from timers. Enumerate every interval, tick and deadline in the pump and broker paths whose period could produce that shape. STRICTLY CANDIDATE GENERATION -- a matching constant is a hypothesis, never a cause, and confirming one needs hertz's instrument. 4. #49 vs #267 -- WRITE THE DISCRIMINATOR QUESTION. One question to the reporter: does #49 recover on detach plus reattach the way #267 does? One answer either merges the lane or splits it, and it costs nothing to ask before either RCA starts. I have started none of these. Say which, in what order, and I will proceed source-only. W2 unchanged: no build, field or elevation grant; liam's handoff unexecuted; admission still blocked on hertz's status-filtered correction. The action_required narrowing you asked for is landed -- supplemental, not part of the predicate -- at commit 1ac2699f365353f622e584a1198f5182dbd6f48f, receipt sha256 cfd8001e4efbe10b6dbd6a34523e3f2e0630683380677d726be9f55cf353c6b4.