#299 SOURCE-ONLY ANALYSIS. Nothing run, no probe, no rig, no fix proposed. All conclusions provisional in the terms you set. == FIRST: MY "NO W3 IMPLEMENTATION EXISTS" CLAIM WAS WRONG, AND WRONG IN A SHAPE I HAVE NOW MADE THREE TIMES TODAY == I inferred code absence from ISSUE METADATA -- no commit link on the issue, therefore no code. That is the same scope-as-population error as my depth-3 driver search and my latest-15 CI predicate. You are right that a missing commit link is not evidence of absent code, and the tree disproves me directly: there is a substantial shipped `endpoint list` implementation with its own REQ family. One thing I could NOT reconcile, and I am reporting it rather than papering it. I read both pins you named. 58b95354 "feat(serving): propose a quoted path from committed input, grant nothing" touches helperline.rs, api/delivery.rs, docs-site serving/attachments.md, traceable-reqs.toml. 3e7eaf67 "fix(webproxy): name the one-way coupling and exclude protocol-relative Locations" touches docshost.rs and webproxy.rs. Neither diff contains #299 or #230 code. I take it you are pointing at the RECEIPTS carried on that lane -- the doc/impl/unit records -- rather than claiming those two diffs implement these issues. If you meant something else on that lane, name the file and I will read it; I would rather ask than guess a second time in the same message. == RECOVERED IMPLEMENTATION PINS (the existing work, not rebuilt) == The `endpoint list` surface is governed by a REQ family, and the LISTING SHAPE is explicitly split from the noun namespace: REQ-ENDPOINT-LIST-NODE-GROUPED node-grouped over unique instances REQ-ENDPOINT-LIST-REST-FILTER suspended-hidden + --show-all <- the flag in this issue REQ-ENDPOINT-LIST-MERGE-LOCAL the list ALWAYS merges local; --local was dropped REQ-WHOAMI-IDENTITY-ONLY whoami is identity-only, NOT a list alias (the endpoint-noun REQ at traceable-reqs.toml:1249 records the supersession explicitly) Code: cli.rs:6426 cmd_endpoint_list, filter_and_order at cli.rs:7432 (the --show-all predicate), roster::enumerate at roster.rs:62, entry_at at roster.rs:100, picker/data.rs:103 gather_endpoints and its reconcile_self_owned pass. #230 IS NOT ABSENT EITHER, AND I ALMOST REPORTED THAT IT WAS. `ATTACH_CLIENT_STALE` as a literal string appears only in the two remote-friction docs -- but searching by CONCEPT instead of by that one spelling turns up a large shipped attach family: REQ-ATTACH-IDEMPOTENT-REPLAY, REQ-ATTACH-RESIZE-REPAINT, REQ-ATTACH-SEED-REQUEST-DOUBLE-SERVE, REQ-BROKER-ATTACH-JOURNAL-RESILIENT, REQ-RC-CROSS-NODE-ATTACH, REQ-HAZARD-ATTACH-WEDGE, REQ-HAZARD-RC-ATTACH-FAILFAST, REQ-HAZARD-RC-ATTACH-ONLINE-RACE, REQ-HAZARD-RC-ATTACH-TRUTH, REQ-ENDPOINT-UNBOUND-ATTACH, plus REQ-REDISPATCH-STALL-W1 whose text is squarely about stale attach rows and control steals (traceable-reqs.toml:2782), with T6 int coverage in daemon tests/redispatch_stall.rs:676-688. I have not yet mapped which of these IS #230's shipped work; that is recovery work I will do rather than rebuild anything. == WHAT I TRACED IN THE #299 PATH, AND WHAT IT KILLS == Legs of cmd_endpoint_list, human (unpiped) path: SubnetStore::load wansend::load_snapshots(identity/registry) pure read_dir + read_to_string + serde, NO locks VisibilityStore::load roster::enumerate() read_dir over the owlery, per-dir info::read_info, ready-file exists(), liveness probes, lookup_address spt_store::info::read_info per perch resource_projection(reg, visibility closure) per subnet FOUR CANDIDATES KILLED BY SOURCE, which is the part I think is worth most: 1. THE GIT FANOUT IS ALREADY RETIRED. cli.rs carries the comment in the live path: "O(PxB+C) per-perch git fanout is retired -- readers never run git", and again on the human table, "no per-perch git derivation on the human table either". The 2026-07-15 message-delivery incident that this REQ history describes is the reason whoami stopped being a list alias. So the known historical cost for this exact surface is GONE, and #299 is not a recurrence of it. 2. THE PID PROBE IS O(1), NOT A TABLE SCAN. is_process_alive (spt-procident/src/lib.rs:44) on Windows is OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION) + CloseHandle, with an explicit comment that tasklist/WMIC were avoided because they hang. Per-perch liveness is microseconds, not a multi-second fanout. 3. NO LOCK IN THE READ PATH. I grepped the perch, wansend and visibility modules for LockFile / lock_exclusive / try_lock / flock / Mutex: the only Mutex is a TEST env guard (perch.rs:1154). Nothing in these legs waits on a lock, so "local contention" in the lock sense is not supported by the source. 4. THE DATA VOLUME CANNOT EXPLAIN TEN SECONDS. Measured on this box, read-only: the owlery holds 48 perch directories and 28 info.json files at all depths; identity/registry holds 6 subnet snapshots totalling roughly 60 KB. That is a few dozen small local reads. This does not PROVE the legs are fast -- filesystem latency is not a function of byte count, and an on-access scanner or a cold cache can make small reads slow -- but it does mean a cost-of-work explanation has to name a per-file latency, not a population size. == DEADLINE AND LOCK OWNERSHIP, WHICH IS WHAT YOU ASKED FOR == I found NO deadline and NO lock owned by the CLI legs above. Every one is a local filesystem read. There ARE several 10-second bounds in the tree, and I am naming them as CANDIDATES ONLY because the plateau shape invites exactly the error you pre-empted: brain.rs:2569 PEER_REPLY_READ_BUDGET = Duration::from_secs(10) broker.rs:2234 deadline = now + 10s daemon.rs:2928 and :2986 deadline = now + 10s autostart.rs:264 and :299 replay_bounded(10s) nethost.rs bounded_block_on, the BROKER-QUIC-DEADLINE path (traceable-reqs.toml:1402 records it as 10s) EVERY ONE OF THOSE IS DAEMON-SIDE. They are relevant to #299 only if the CLI awaits the daemon somewhere in this path, and I HAVE NOT FOUND SUCH A WAIT -- but I also have not finished tracing resource_projection's internals, VisibilityStore::load, SubnetStore::load or perch::identity_dir. So the honest statement is: the legs I have read are local and deadline-free, several 10 s bounds exist one process away, and I cannot yet connect them. A matching constant is a hypothesis, not a cause. Per your constraint, restated in my own words so it is on my record and not just yours: THE ~10 s PLATEAU SUGGESTS A DEADLINE AND I HAVE NOT ESTABLISHED THE OBSERVED WAITING STAGE. 3822 / 10120 / 10105 ms is consistent with a bound being hit twice, and equally consistent with a bimodal cost I have not found. Source inspection cannot close that. == THE SMALLEST DISCRIMINATING RUNTIME MEASUREMENT == It needs no instrumentation, no code change, no rig, and no new probe class -- three command walls on the affected box, same shell, unpiped, repeated enough to catch the bimodality the reporter saw: A. `spt --version` startup only: process, clap tree, no roster, no registry B. `spt whoami` startup + SELF pin (identity-only since REQ-WHOAMI-IDENTITY-ONLY -- deliberately NOT the roster) C. `spt endpoint list --show-all` startup + full roster + registry projection That partitions the observed wall into three additive segments and each outcome names a different owner: - A already ~10 s => the cost is PROCESS STARTUP and nothing in this issue's framing is the subject. Everything above becomes irrelevant. - A fast, B ~10 s => the cost is the SELF pin / identity path, not the roster -- and that would also be a public-docs problem, since the docs promise a bounded identity-only whoami. - A and B fast, C ~10 s => the cost is genuinely in the roster/registry legs, and only then is the per-leg trace worth building. B is the load-bearing arm and it is free: whoami and endpoint list share render_self_pin but whoami deliberately does NOT take the full-roster surface, so the pair isolates the roster legs from everything they sit on top of. I want A as well rather than assuming startup is free, because assuming a segment is cheap is how I would end up measuring the wrong difference. I am NOT asking to run this. It is a runtime measurement and I hold no grant; it is also arguably hertz's instrument rather than mine. Tell me which. == NEXT == Moving to #49/#267 failed-fix archaeology now, source and history only, carrying the #42 supersession as already ruled rather than reopening it. I will not raise the reporter question -- you have ruled it unnecessary before the history work, and I note that matching recovery behaviour would not prove a shared cause anyway.