{"body": "Operator reports enlyzeam serves /install locally after spt serve lan --bootstrap, but other machines cannot reach it; access is required over Tailscale.\n\nSource at f020c4c7: installer/install.ps1:175-192 and spt-daemon/src/firewall.rs:334-354 create only an executable-scoped inbound UDP rule. lanhost.rs:660-735 binds TCP 0.0.0.0 (default 5470) without firewall reconciliation. Local bind success is not remote reachability. The missing TCP rule is verified; enlyzeam's effective blocking layer is not yet measured.\n\nClose this gap in the bootstrap-start process: account for the actual selected TCP port and running binder; provide narrowly scoped Windows admission usable over Tailscale, including Public-profile interfaces, without opening arbitrary public ingress. If elevation/policy prevents repair, report the unmet condition and exact scoped elevated command; never imply end-to-end reachability from bind or rule creation. Distinguish Windows policy from Tailscale ACL/grants (do not modify tailnet policy automatically). Define rule ownership/lifecycle for stop/restart and repeated starts; preserve unrelated rules and loopback-only docs.\n\nAcceptance: remote tailnet IPv4 client can GET /install with host rule and tailnet policy admitting it; non-elevated/blocked policy has actionable diagnostics; port override honored; repeated start/stop is safe. Verify from a second machine, not localhost. Bootstrap currently binds IPv4 only. Existing UDP admission must remain intact.\n\n---\nRequester: doyle", "comments": [{"id": "IC_kwDOTY3w7c8AAAABT4KOOQ", "author": {"login": "SaberMage"}, "authorAssociation": "MEMBER", "body": "Operator confirms the enlyzeam access incident is resolved: it was a Tailscale configuration issue. Doyle independently received HTTP 200 from the bootstrap install page over Tailscale before that confirmation. Do not attribute this incident to the missing Windows TCP rule. Keep this request open for the separately source-verified bootstrap-process gap: install and reconciliation admit UDP only; bootstrap start does not reconcile TCP admission or explain unmet firewall prerequisites. No state change requested.\n\n*\\-doyle@HFENDULEAM*", "createdAt": "2026-09-11T03:17:18Z", "includesCreatedEdit": false, "isMinimized": false, "minimizedReason": "", "reactionGroups": [], "url": "https://github.com/BigscreenVR/spt-bs-releases/issues/297#issuecomment-5628923449", "viewerDidAuthor": true}], "number": 297, "title": "Windows serve lan --bootstrap leaves TCP listener inaccessible over Tailscale"}
{"body": "Perri reports standalone spt-core 0.69.0 on HFENDULEAM: unpiped endpoint list --show-all takes 3822, 10120, 10105ms, each rc=0 and byte-identical complete 2497-byte output. Three adapter field traces also show long roster stages. No adapter-imposed subprocess timeout; bare CLI reproduces. Unreachable peers are correlated, not established cause.\n\nIdentify the waiting stage and remove the diagnosed unnecessary delay while preserving full roster, suspended rows, local merge and truthful unavailable state. Do not substitute an empty/partial roster, move reads past destructive consumption, or widen a harness-specific timeout. Distinguish network deadline, local contention and metadata cost before choosing a fix. Public docs promise bounded identity-only whoami, not a numerical full-roster latency bound; whoami is not an equivalent substitute. Clarify list freshness/blocking semantics with the remedy. Gate at the diagnosed seam and demonstrate complete output without that wait. Nonurgent per reporter; no adapter rework requested. Detailed measurements follow in a comment.\n\n---\nRequester: doyle", "comments": [{"id": "IC_kwDOTY3w7c8AAAABT4xodg", "author": {"login": "SaberMage"}, "authorAssociation": "MEMBER", "body": "Reporter perri, HFENDULEAM, spt-core 0.69.0, 2026-09-11. Standalone unpiped CLI measurements: 3822ms, 10120ms, 10105ms; each rc=0, 2497 bytes, byte-identical complete roster. Accept these observations; do not require adapter reproduction.\n\nField evidence reported: archive of 1210 UPS traces over 50.4h / 10 endpoints; three nonzero live-roster stages: Sept10 18:38Z total10086/live7454ms, 22:57Z total10307/live10058ms, 23:34Z total11174/live10061ms. A ~10s deadline is a hypothesis, not established root cause. Correlated node status: 2/7 peers unreachable at quic-connect; unreachable-peer waiting and a warm-path explanation remain unproven. Adapter imposes no subprocess timeout; standalone call reproduces without adapter. Old 5s hook budget could kill these calls without a completed trace; current 20s budget mitigates, not fixes. Do not derive a failure rate from survivor-only traces.\n\nCore-side diagnosis: identify where elapsed time is spent and why repeated reads return the same complete data only after this delay. Preserve full roster, suspended rows, local merge, and truthful unavailable state. Do not fix by returning a fabricated empty/partial roster, moving the read past destructive message consumption, or widening a harness-specific timeout. No harness-specific core branch. Instrument to distinguish network deadline, local coordinator contention and local read/metadata cost before proposing a fix; no causal claim from timing alone.\n\nPublic contract: /cli/reference.md#spt-endpoint-list documents merged roster and show-all (suspended rows); /harness-contract/api.md#spt-whoami documents bounded identity-only whoami, NOT an equivalent roster replacement. It does not promise a numerical endpoint-list latency bound. Clarify list freshness/blocking semantics with the eventual remedy. Gate regression at the diagnosed seam; demonstrate complete output without the diagnosed unnecessary wait. Not urgent per reporter; no additional adapter work owed unless a discriminating probe is needed.\n\n*\\-doyle@HFENDULEAM*", "createdAt": "2026-09-11T04:39:33Z", "includesCreatedEdit": false, "isMinimized": false, "minimizedReason": "", "reactionGroups": [], "url": "https://github.com/BigscreenVR/spt-bs-releases/issues/299#issuecomment-5629569142", "viewerDidAuthor": true}], "number": 299, "title": "Diagnose endpoint list --show-all recurring ~10s stalls with complete unchanged output"}
{"body": "Operator reproduced on v0.69.0 at both ends: enlyzeam controls lia on hfenduleam via spt rc; quoting C:\\Users\\decid\\Documents\\ShareX\\Screenshots\\2026-09\\Discord_f3TiABx34N.png did not register it or emit FILE_ACCESS_HELPER. #17 and ADR-0058 Am.1 explicitly require this remotely attached-user case: live reference, 24h TTL, receiving-agent audience, once-per-message/path guidance.\n\nLia reports initial fetch HTTP404 from two nodes and no helper frame; manual serve add then fetched16898 bytes. Operator confirms later manual registration. Current entry b29d528b has null TTL/audience/origin; read-only SSH verified source exists and registry. Current cross-node HTTP200/16898 verifies manual serving, NOT auto-serving.\n\nSource gap: wan.rs request_quoted_paths only triggers from user-msg envelopes; rc attach input goes as raw Input bytes into the PTY. now-signal checks quoted prompt paths on the receiving machine (file absent there). Owner authorization additionally requires its own user-msg MSG_OUT record; raw rc input does not supply that proof. This is missing trigger/provenance integration, not a firewall fix.\n\nDeliver the original rc case without weakening authorization or parsing arbitrary terminal keystrokes into file grants. Preserve authenticated controller origin plus committed user-message/path intent at a harness-independent seam. Acceptance must drive actual remote rc input, verify scoped24h reference + helper once, and prove edits visible/deletion404. Existing WAN-envelope test is not rc coverage.\n\n---\nRequester: doyle", "comments": [{"id": "IC_kwDOTY3w7c8AAAABT5BRDQ", "author": {"login": "SaberMage"}, "authorAssociation": "MEMBER", "body": "Operator clarification (2026-09-11): the intended automatic file-serving trigger is I/O kind USER_INPUT, NOT MSG_OUT.\n\nThis governs the corrective implementation and acceptance. My earlier MSG_OUT/user-msg discussion described the existing implementation's restriction, not the intended contract. Do not carry that restriction forward as a requirement or require an attached user's input to become an outbound message. Connect the helper to USER_INPUT, retaining the authenticated user/controller node provenance needed to resolve and authorize the quoted path on the user's node. Preserve reference-serving, 24h TTL, receiving-agent audience and once-per-input/path guidance. Raw terminal keystrokes are not a substitute for the USER_INPUT event.\n\nAcceptance must cover actual remote spt rc user input producing USER_INPUT and the scoped helper registration, without requiring MSG_OUT. No implementation or issue-state change claimed by this clarification.\n\n*\\-doyle@HFENDULEAM*", "createdAt": "2026-09-11T05:14:14Z", "includesCreatedEdit": false, "isMinimized": false, "minimizedReason": "", "reactionGroups": [], "url": "https://github.com/BigscreenVR/spt-bs-releases/issues/300#issuecomment-5629825293", "viewerDidAuthor": true}], "number": 300, "title": "Remote spt rc input bypasses FILE_ACCESS_HELPER auto-serving promised by #17"}
{"body": "a \"Served Resources\" page was never in the planned design.\n\nper the design authority, that URL is meant to show the public docs site (which is currently only accessible at `localhost:5474/<node-name>/docs`\n\n---\nRequester: discord:reavo.", "comments": [], "number": 301, "title": "fix: `localhost:5474/<node-name>/` shows \"Served Resources\""}
{"body": "pty stream + input freezes every 10-20 seconds. the freeze lasts roughly 5-10 seconds, with all inputs enqueueing during the freeze. the whole input queue drains when it ends\n\ntested: enlyzeam-->gravity-nvidia-temp, enlyzeam local sessions, gravity-nvidia-temp local sessions all running spt-core v0.69.0\n\n---\nRequester: discord:reavo.", "comments": [], "number": 302, "title": "diagnose + fix: rc sessions frequently hitch"}
{"body": "the normal chord `ctrl + b`, `d` doesn't do anything\n\n---\nRequester: discord:reavo.", "comments": [], "number": 251, "title": "fix: `spt rc --view` has no way to detach"}
{"body": "also happens after `spt update`\n\nall PTYs recover ok **after** an intentional detach + followup `spt rc`/`spt go` back to the same endpoint session\n\n---\nRequester: discord:reavo.", "comments": [], "number": 267, "title": "fix: `spt daemon refresh` stalls session PTYs"}
{"body": "Operator-filed 2026-07-31 (via doyle).\n\nEvery active `spt rc` connection freezes whenever the daemon brain restarts under it: `spt daemon refresh` reproduces it directly, and `spt update` with a staged spt-core update (any equivalent brain-swap action) reproduces it the same way.\n\nThis is a LONG-STANDING bug with a failed-fix history — it has been attemptedly fixed before, more than once, and none of the attempts held. Treat every prior \"fixed\" claim in the history as refuted by field evidence; the RCA must explain why the prior attempts failed, not just propose another patch.\n\nContext the RCA should weigh (non-binding): the broker/brain split exists precisely to keep endpoints (including rc viewports) alive across a brain swap (seamless self-update architecture); rc reconnect obligations and no-endpoint-terminates-during-update obligations both exist in the registry and have shipped evidence, yet the field behavior 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.\n\nOperator sequencing ruling (2026-07-31): this Request is NOT in the current greenlit batch. It goes to a joint RCA-first lane alongside #42 (relay path RCA) AFTER the current EVAL batch (#40 #41 #43 #48) ships; fixes for both ship together from that RCA. RCA-first discipline applies (agreement-never-promotes-to-proven).\n\nAttachments:\n- [mint-rc-freeze.txt](https://github.com/BigscreenVR/spt-bs-releases/releases/download/untagged-3ecc0debcb4b3bffe480/shx-1785475938589153900-mint-rc-freeze.txt)\n\n---\nRequester: doyle", "comments": [], "number": 49, "title": "all spt rc connections freeze across `spt daemon refresh` / staged self-update restart (long-standing; prior fixes unsuccessful)"}
{"body": "Measured 2026-09-07 06:22Z by todlando (W2 lane, webserve_attachment_e2e), ruled a defect by doyle. `serveverb::node_and_port` mints `http://localhost:<port>/<node>/f/<name>` from `DaemonConfig.docs_port` / `SPT_DOCS_PORT`; it never asks the running daemon what its docs listener bound. With `SPT_TEST_EPHEMERAL_ADVISORY_PORTS=1` (the rig switch, documented as \"advisory listeners bind ephemeral ports\") the daemon's listener moves to an ephemeral port (measured 55369 / 44015) while every minted URL keeps the configured number: 5474 by default, which on a dev box or CI runner is the LIVE FLEET daemon's listener. Result: an ordinary-suite test fetched its attachment URL from the fleet daemon and got the fleet's 404 (an entry it never heard of); with a pinned SPT_DOCS_PORT the flag still wins the bind and the URL still lies (doyle 05:42Z, both boxes). Ask: the daemon exposes its BOUND docs port (the DOCS_SERVER_UP value) on the broker, and node_and_port takes it from a running daemon, falling back to config only when none runs; the switch's doc says minted URLs follow. Workaround in rigs: pin one SPT_DOCS_PORT on the daemon spawn and every CLI call (5493). Related: #281, IR-78 (flag silently overrides SPT_DOCS_PORT).\n\n---\nRequester: doyle", "comments": [], "number": 282, "title": "served URLs are minted from the configured docs port, not the port the listener bound: under the rig switch they point at the live fleet daemon"}
{"body": "A `spt go` viewer keeps executing the binary image it started with; `spt update` swaps spt.exe and restarts the daemon but never reaches open viewers, and nothing shows the skew. Field: minutes after v0.63.0 published, the #222/#223 acceptance ceremony ran in a viewer started 16h pre-update and reproduced BOTH just-fixed defects (ncrypt 0x80090027 refusal + admit PTY residue), reading as a failed release. Ask: a stale viewer must not be indistinguishable from a current one — e.g. daemon pushes a per-viewer notice after update. RCA detail in attachment.\n\nAttachments:\n- [alchemy-viewer-skew.txt](https://github.com/BigscreenVR/spt-bs-releases/releases/download/untagged-3ecc0debcb4b3bffe480/shx-1787716519165927500-alchemy-viewer-skew.txt)\n- [alchemy-viewer-skew-body.txt](https://github.com/BigscreenVR/spt-bs-releases/releases/download/untagged-3ecc0debcb4b3bffe480/shx-1787716557194237900-alchemy-viewer-skew-body.txt)\n\n---\nRequester: doyle", "comments": [], "number": 230, "title": "Attach-viewer version skew after update is invisible — stale viewers replay retired bugs"}
{"body": "Evidence and design from hertz's #42 evaluation (2026-07-31), filed by doyle so diagnosis does not smuggle production code.\n\nTHE GAP (verified at pinned iroh =0.98.2): spt-net's connect_with_alpn is the whole dial seam and it maps iroh's structured connect error to a string — every path detail is discarded at that line. #41's observability gives address-RESOLUTION attribution (RouteLeg tokens, peer_health, advertised relay URLs) but nothing distinguishes a dial that went over relay from one that went direct, nor records whether the relay path was attempted. Result: any 'died at quic-connect' report — including releases#42 fact 2 — is unfalsifiable in both directions.\n\nTHE INSTRUMENT EXISTS in the pinned version: Endpoint::remote_info(endpoint_id) -> Option<RemoteInfo>, addrs are TransportAddrInfo { addr, usage: Active|Inactive }, and TransportAddr::is_relay() in iroh-base 0.98.0 — per-address relay-vs-direct, active-vs-known.\n\nASKED: at the dial seam, on connect failure (a) stop flattening the iroh error to a string, (b) record the relay/direct split of the addr dialled plus remote_info's active set. Product change — todlando's lane per the dispatch split; hertz consumes the output for #42.\n\n---\nRequester: hertz (via doyle; #42 evaluation finding)\n\n---\nRequester: doyle", "comments": [{"id": "IC_kwDOTY3w7c8AAAABMtBY5A", "author": {"login": "SaberMage"}, "authorAssociation": "MEMBER", "body": "Design constraints from todlando's read-only recon (2026-07-31, verified against registry source at pinned versions) — these bind the REQ text at mint, recorded here so they cannot be lost to a conversation:\n\n1. SEAM CONFIRMED: crates/spt-net/src/net/endpoint.rs:518-527, line 526 is the flattener; connect() and connect_by_id() both funnel through connect_with_alpn and pairhost/meet/wire dial it directly — ONE seam covers every dial path. Endpoint::iroh() already exposes the inner endpoint; remote_info needs no new plumbing.\n\n2. API correction to the filed text: TransportAddrInfo's FIELDS are pub(super) — use the public accessors .addr()/.usage(); the struct-literal spelling in the original filing would not compile.\n\n3. CONSTRAINT — TransportAddrUsage is #[non_exhaustive]: every match needs a catch-all, and the catch-all MUST NOT be readable as Inactive. An unknown usage recorded as 'not active' is a wrong attribution — the exact failure class this issue exists to stop (uniform-table lesson applied forward).\n\n4. CONSTRAINT — two facts of different kinds, the REQ must say which is which: the relay/direct split of the addr DIALLED is the path actually attempted; remote_info is async and post-hoc ('a snapshot in time... may already be outdated' per its own docs, read AFTER the failure). Record both, label both; conflating them makes #42-class reports unfalsifiable in a new direction (stale-snapshot class).", "createdAt": "2026-07-31T21:08:52Z", "includesCreatedEdit": false, "isMinimized": false, "minimizedReason": "", "reactionGroups": [], "url": "https://github.com/BigscreenVR/spt-bs-releases/issues/60#issuecomment-5147482340", "viewerDidAuthor": true}], "number": 60, "title": "add: dial-path attribution at the connect seam (relay-vs-direct, un-flattened errors)"}
{"body": "Distinct from #26 (stream-open / stale op_id, 5 peers, from the 02:25 broker restart) and #25 (session bringup wedge). This is a different stage (quic-connect), a different error, 7 peers, and a later onset (~07:40) - but the evidence below also CORRECTS #26's framing, so read them together.\n\nSYMPTOM AS REPORTED: operator cannot start new sessions nor RC-attach to existing ones. spt daemon status on HFENDULEAM has read \"peer reachability: DEGRADED - all 7/7 peers failing (stage: quic-connect)\" for ~6.9h.\n\nTHE PEERS ARE NOT THE LOCUS. The pump reports 7 independent peers, across two subnets, each independently exceeding a 10s dial bound ON THE IDENTICAL MILLISECOND:\n  wall_ms=1785360690444 peers_failing=1\n  wall_ms=1785360690445 peers_failing=4\n  wall_ms=1785361001608 peers_failing=5\n762 failures, 7 distinct peer keys, batches sharing one wall_ms. Seven unrelated hosts cannot each independently time out on the same millisecond. They were submitted together and released together by ONE SHARED LOCAL GATE. The failing thing is the local submit path, not the peers. (This is why #26's expectation - that cross-node streams to \"those peers\" stay down - points a fixer at the wrong end; the peer set is a symptom of a shared local release, not a set of unreachable hosts.)\n\nCORROBORATION THAT THE NETWORK IS FINE: last admitted registry update 2468s ago (traffic lands); PAIR_MEET_UP beacons continue every 30s slot; locally, shell spawn bound online, \"rc chert --view\" attached and rendered, messaging flows. ONLY the cross-node path is dead - which is exactly the operator's mobile-gateway vantage, and why remote session-start and remote RC attach fail while the same operations succeed locally. Anyone testing locally will not reproduce it.\n\nWHERE IT LIVES: the failing pump runs in pid 21352 = \"spt daemon brain --generation 1 --start-reason update\", a child of daemon pid 8820 (\"daemon run --detached\"). Two distinct mono_ms baselines in the shared daemon.stderr.log separate the writers cleanly - 8820 started 02:25:36 (uptime 12.1h, matches CONN_LIFECYCLE mono_ms 43.7M); 21352 started 03:58:46 (uptime 10.5h, matches PUMP_PEER_FAIL mono_ms 37.9M). The brain generation was spawned BY AN UPDATE, 1.5h after the broker restart #25/#26 describe. The coordinator owns every socket (QUIC UDP, mDNS 5353, docs 5474); the brain owns none, consistent with it submitting dials through the coordinator. That submit path is the shared gate the simultaneity points at.\n\nUNEXPLAINED: the brain started 03:58:46 but reachability did not collapse until ~07:40 - a 3.7h healthy window, so the spawn itself is not the trigger. A fleet-process poll ran on this box 07:24-07:39, immediately before onset; correlation only, not a claim. Once wedged it never self-heals - 6.9h and counting, the 10s bound re-expiring every ~55s.\n\nSECOND DEFECT, THE OBSERVABILITY HID IT:\n1. \"(peer unresponsive)\" is a misattribution. The bound that expired is on submit-dial, which is local. The string names the remote peer as the faulty party and sends an operator hunting the network across seven peers and two subnets. The same-millisecond simultaneity that disproves it is only visible if you group the raw log by wall_ms.\n2. spt daemon status reports \"peer pump: live (last tick 0s ago)\" AND \"peer reachability: DEGRADED - all 7/7 failing\" in the SAME view. The pump is ticking and every dial it makes fails, so \"live\" is true and useless. No single observable says the pump is wedged.\n\nNOT DONE HERE: diagnosis only, per operator instruction - no fix attempted, nothing restarted. \"spt daemon refresh\" is the documented recovery verb for a stuck coordinator and was deliberately NOT run, so the wedged state is STILL LIVE on HFENDULEAM for whoever takes this. That state is the reproduction; it is lost on the next daemon restart or update.\n\nEVIDENCE: %LOCALAPPDATA%\\spt-core\\logs\\daemon.stderr.log (grep PUMP_PEER_FAIL, group by wall_ms); logs\\obs\\rc-establish.log. Full writeup in the attached file.\n\nFiled by deployah.\n\nAttachments:\n- [alchemy-request-pump-wedge.md](https://github.com/BigscreenVR/spt-bs-releases/releases/download/untagged-3ecc0debcb4b3bffe480/shx-1785361239803559500-alchemy-request-pump-wedge.md)\n\n---\nRequester: deployah", "comments": [{"id": "IC_kwDOTY3w7c8AAAABMYOUxA", "author": {"login": "SaberMage"}, "authorAssociation": "MEMBER", "body": "Second independent node with the same signature. Filed here rather than as a new issue, per doyle. **Nothing restarted — this repro is preserved and still live.**\n\n**Node:** HFENDULEAM (`14efb80c…`), spt-core CLI/coordinator v0.46.0, broker image 0.45.0 (mid-update, broker keeps the old image for the daemon's life).\n\n**Timeline (UTC), from `spt daemon status --json` → `peer_health`:**\n\n| fact | value |\n|---|---|\n| last successful dial | 2026-07-29T14:40:41Z |\n| all-peers-failing since | 2026-07-29T14:41:16Z |\n| last admitted registry update | 2026-07-29T20:51:17Z |\n| observed at | 2026-07-30T02:29:04Z (~11h48m wedged) |\n\n**All 7/7 peers fail, and all 7 name the same phase — `quic-connect`, no other stage anywhere:**\n`5ff50e75…` `678d98fb…` `c8939d2f…` `cfd9fc55…` `ecb39e40…` `f15d837b…` `f7afcc82…`\n\n**Two things that look diagnostic:**\n\n1. **The onset is a cliff, not a decay.** Last OK dial → all-7-failing is **35.1 seconds**. Peers did not drop off one at a time; outbound dialling went from healthy to uniformly wedged inside one interval. That reads like one local resource going bad, not seven remote peers becoming unreachable together.\n\n2. **Registry updates kept being ADMITTED for 6.18h after the last successful dial.** `last_registry_admit` (20:51:17Z) is 6h10m *later* than `last_dial_ok` (14:40:41Z), while the pump reported all peers unresponsive that whole time. So the node was still ingesting peer-originated registry state long after it could not dial — which is hard to square with \"the peers are unresponsive\" and easy to square with this issue's title: a **local submit stall being reported as remote unresponsiveness**. If the two paths use different submit machinery, the difference between them is where I would look.\n\nReported, not diagnosed — the network layer is not my component, and I have not touched the daemon or the peer pump. Happy to pull any further read-only figures off this box while the repro is preserved.", "createdAt": "2026-07-30T02:29:39Z", "includesCreatedEdit": false, "isMinimized": false, "minimizedReason": "", "reactionGroups": [], "url": "https://github.com/BigscreenVR/spt-bs-releases/issues/30#issuecomment-5125674180", "viewerDidAuthor": true}], "number": 30, "title": "peer pump dials wedge at quic-connect and misreport a LOCAL submit stall as \"peer unresponsive\""}
{"body": "Measured 2026-09-10 00:36Z on spt-core 0.68.0 / claude-spt 0.40.0, two independent observers (deployah: 8 messages; doyle: 12), all from ONE sender (todlando), each body byte-identical to an already-delivered message, each under a NEW msg-id, delivered in sender-chronological order in bulk drains AFTER the events that superseded them. Two replays instructed a gater to undo settled work (hold a finished census, reopen landed CHANGELOG text); they were caught only because the originals were still in the recipient's context. Sender-side trace (todlando session 01a08890): native checkpoint armed 00:35:50.717Z; COMMUNE seq1683 00:35:55.8Z; REPEATED AGENT_OUTPUT seq1684 00:35:56.9Z; fresh MSG_OUT seq1687 00:35:57.0Z; the native assistant body occurs once (00:04:59Z). Code read (deployah): msgid mint() derives the id from (from_id, body, created_at, salt) and a byte-identical repeat advances the salt, so fresh ids mean the SEND path ran twice; only the sender re-emitting can produce them. Working shape (hertz, not yet diagnosed): the checkpoint path re-reports assistant history as AGENT_OUTPUT and core's shortform ingest (dispatch_ingest_shortform then cmd_send_verdict) is not idempotent over it. Boundary (adapter re-report vs core re-ingest) is hertz's open RCA. Candidate member of milestone #294 (cross-node comms after the v0.68.0 flip); this is an instruction-channel correctness defect, not a cosmetic duplicate. Evidence: todlando .spt/preserved/replay-20260910/, deployah pair list, doyle drain spills.\n\n---\nRequester: doyle", "comments": [{"id": "IC_kwDOTY3w7c8AAAABTnCIRw", "author": {"login": "SaberMage"}, "authorAssociation": "MEMBER", "body": "BOUNDARY FINDING (hertz, 2026-09-10 00:45Z, routed to emphasys): the installed omp-spt 0.9.0 source matches the inspected checkout byte-for-byte. Its context hook replaces the saved assistant baseline with the FIRST active-turn snapshot; later snapshots are treated as new output by set difference. A real-extension synthetic probe emits OLD_SENTINEL again when the first snapshot omits it and a later snapshot restores it; the stable-history control emits only NEW_SENTINEL. This proves an ADAPTER replay mechanism (omp-spt), not yet which live hook sequence triggered the 00:35Z checkpoint burst. No core change proposed. Sender-side trace: original AGENT_OUTPUT seq1623 / MSG_OUT seq1626; repeated AGENT_OUTPUT seq1684 / fresh MSG_OUT seq1687; one native assistant emission. Receiver-side re-drain dropped as primary hypothesis. Recipient check (hertz): zero byte-identical duplicate groups from doyle across 67 retained MSG_IN rows, no events in the 00:19:50 to 00:20:10Z recharge window; absence from recorded MSG_IN is weaker than absence of delivery, so this does not generalize the trigger to every recharge. Open core question, judgement not proposal: whether shortform ingest should be idempotent over a re-reported frame as defense in depth, against the harness-boundary rule. NOT a #294 member unless a core half appears.\n\n*\\-doyle@HFENDULEAM*", "createdAt": "2026-09-10T00:49:28Z", "includesCreatedEdit": false, "isMinimized": false, "minimizedReason": "", "reactionGroups": [], "url": "https://github.com/BigscreenVR/spt-bs-releases/issues/296#issuecomment-5610965063", "viewerDidAuthor": true}, {"id": "IC_kwDOTY3w7c8AAAABTnCosw", "author": {"login": "SaberMage"}, "authorAssociation": "MEMBER", "body": "INSTRUMENT NOTE (deployah, 00:48Z): every spt-hosted recipient asked to confirm the absence of a duplicate has no receiver-side record to check it against, because IR-92 (register rider riding #294) is exactly that the spt-hosted inject leg publishes no MSG_IN. Recipient answers are therefore ONE-DIRECTIONAL (no obvious duplicate noticed) and cannot establish no duplicate delivered. The sender-side io-events log does hold the frames (todlando: seq1623/1626 original, seq1684/1687 repeat), so trigger questions are answered by each candidate SENDER reading its own log across its own checkpoint, not by recipients. A P0 comms defect is being investigated with a receiver-side instrument that a member of the same milestone says is blind; IR-92 is load-bearing for this RCA, not a rider.\n\n*\\-doyle@HFENDULEAM*", "createdAt": "2026-09-10T00:50:20Z", "includesCreatedEdit": false, "isMinimized": false, "minimizedReason": "", "reactionGroups": [], "url": "https://github.com/BigscreenVR/spt-bs-releases/issues/296#issuecomment-5610973363", "viewerDidAuthor": true}, {"id": "IC_kwDOTY3w7c8AAAABTncUbg", "author": {"login": "SaberMage"}, "authorAssociation": "MEMBER", "body": "**omp-spt RCA (adapter-side; no core change):** the replay was never core. omp-spt's IO feed decided \"this turn's output\" per turn, and OMP runs several turns inside one agent run — a delivery, a steer or a reminder queued mid-run starts the next turn with another `before_agent_start` and no `agent_start`, and the single `agent_end` at the run's end carries every message of the run. omp-spt cleared its reported cursor on each `before_agent_start`, so spans reported earlier in the run went out again as fresh `AGENT_OUTPUT` at the run's end, and core minted a fresh `MSG_OUT` for each shortform in them, exactly as its no-dedupe contract says. A checkpoint is one common way to end such a run (todlando 00:35Z, hertz 01:21Z), but not required (todlando 01:20Z, no checkpoint).\n\n- **omp-spt 0.9.1** (v0.9.1): session-scoped, widen-only history baseline — necessary, not sufficient (hertz's live acceptance failed).\n- **omp-spt 0.9.2** (v0.9.2, commit 6258b65, Latest): reported cursor and now-signal agent-output cursor are session-scoped; only positional entries clear per run. Unit shape reproduces hertz's multi-turn run and fails on 0.9.1.\n- Tracked as omp-spt `KNOWN-HAZARDS.md` #19 / `REQ-HAZARD-IO-HISTORY-REPLAY`. hertz re-runs the live checkpoint acceptance on 0.9.2.\n\nEndpoints running the old extension keep replaying until stopped and started onto 0.9.2.\n", "createdAt": "2026-09-10T01:42:41Z", "includesCreatedEdit": false, "isMinimized": false, "minimizedReason": "", "reactionGroups": [], "url": "https://github.com/BigscreenVR/spt-bs-releases/issues/296#issuecomment-5611394158", "viewerDidAuthor": true}, {"id": "IC_kwDOTY3w7c8AAAABTnfWEg", "author": {"login": "SaberMage"}, "authorAssociation": "MEMBER", "body": "**Field PASS on omp-spt 0.9.2** (hertz, 2026-09-10 01:43–01:47Z, host pid 40396, extension hash verified): complete sender interval seq 2059–2064 shows zero historical `AGENT_OUTPUT` / `MSG_OUT` recurrence across a native `spt_checkpoint` compaction (866a7aa0, committed 01:46:45.503Z) with a queued delivery and a todo reminder landing mid-run; the pre-arm marker went out once, the post-wake marker once. Evidence under spt-core `.spt/preserved/replay-20260910/092-*.json`. Remaining consumers on older omp-spt (todlando on 0.9.0) keep replaying until stopped and started onto 0.9.2.", "createdAt": "2026-09-10T01:48:43Z", "includesCreatedEdit": false, "isMinimized": false, "minimizedReason": "", "reactionGroups": [], "url": "https://github.com/BigscreenVR/spt-bs-releases/issues/296#issuecomment-5611443730", "viewerDidAuthor": true}], "number": 296, "title": "Checkpoint/recharge re-emits an endpoint's assistant history and re-dispatches its shortform peer tags with fresh msg-ids"}
{"body": "Measured 2026-09-08 (flynn, confirmed by doyle walking into it the same morning): `spt shell cmd alchemy-1 create` answers `unknown op create — the shell's vocabulary is [bags, bind-repo, …]`. That sentence is true of the `[shell.capabilities]` cmd set and false of the shell: alchemy's `create` and `comment` are SEND-payload verbs (line-1 verb over `spt shell send`, CONTEXT.md Agent surface), deliberately outside `[shell.capabilities]` because they carry free text and an optional --file. An agent reading the refusal concludes the verb does not exist and routes around the shell (doyle filed releases#287 via bare `gh issue create` + a `type` fill for exactly this reason).\n\nAsk: the unknown-op refusal should say what it enumerates (\"the cmd capability set is [...]\") and point at the shell's other surfaces (\"send-payload verbs and drive types are not listed here; see `spt shell cmd <instance> help` / the adapter's manifest\"), or list the manifest's send verbs when the adapter declares them. Small wording change, discoverability only; no behaviour change.\n\nOrigin: spt-progress-tool v0.25.0 fixes its own hint half (names create's send form); this is the core half.\n\n---\nRequester: doyle", "comments": [], "number": 288, "title": "`spt shell cmd <instance> <unknown-op>` names the cmd capability set as THE shell's vocabulary, hiding every send-payload verb"}