S00-003: Record blocked task and remediation handoff

Changes: Preserve incomplete work and blocker metadata for S00-003. This checkpoint does not mark implementation accepted.
Validation: Session ended with status blocked.
Blocker: S00-003 cannot attest parser limits: Stanza 12.22.1 exposes no resource bounds and its persistent WebSocket parser accepts large/deep XML and reassembles incomplete documents across separate input messages.

Task: S00-003
Agent: auto-protocol-902594b44429
Role: protocol
Action: claim
Status: blocked

Task title: Проверить XMPP WSS/auth библиотеку
This commit is contained in:
wt committed 2026-10-15 02:24:00 +07:00
1 parent 1850dbc39f
commit f556fc0deb
14 files changed
+335 -24

No files matched your search

@@ -0,0 +1,39 @@
# S00-003 parser-limit blocker evidence
Executor: auto-protocol-902594b44429, protocol. Date: 2026-10-15.
Result: bounded diagnostic reproduced missing input limits; library selection remains incomplete.
Input: assigned master/startup/role/workflow documents, resume/show/packet, card and previous handoff; required docs/TESTING.md and docs/decisions/README.md; exact ACC-004/NET-003/NET-004; accepted ADR 0000, 0001-stack and 0002-xmpp-sasl-validation; all direct dependency executor/review evidence and handoffs. S00-017 is done and its prior SASL blocker is resolved within its reviewed fixture scope. S01 shared contracts are still future work; no shared interface is introduced.
Intended output: one library-selection ADR and runnable WSS/auth/parser/extension spike. Focused acceptance includes actual WSS handshake, verified SCRAM, bounded parser input and no invented TLS binding. This run stops before selection because parser bounds cannot be attested for the candidate's stock input path.
## Actual diagnostic
Added only experiments/0002-xmpp-library/parser-probe/reproduce.mjs, using the existing installed Stanza 12.22.1 and actual Client registry/StreamParser. No dependency, lockfile, accepted SASL plugin, vendor source, spec or app module changed. The script uses exactly the shipped WebSocket parser options: wrappedStream=false and allowComments=false. It asserts version, received stanza/body/XML depth and absence of error. No parser or registry result is stubbed. Finite fixtures have no accounts or real conversations; no network connection or authentication occurs.
Command:
`PATH=/private/tmp/luma-stack-runtime/node-v24.21.0-darwin-arm64/bin:$PATH node experiments/0002-xmpp-library/parser-probe/reproduce.mjs`
Exit 0, actual stdout:
```text
stock: 18 separate writes reassembled into one 65536-byte body; no error
stock: 1048576-byte body accepted; no error
stock: 256 nested child elements accepted; no error
```
Passing assertions mean stock limitations were reproduced, not safe parsing. The first case writes an unfinished message/body, sixteen 4096-byte chunks, then closing tags. Before closure there is no error/output and parser remains alive; after closure the entire body is emitted. The second and third cases show large and deep complete input accepted. This is not a memory-exhaustion benchmark or proof of infinite capacity; no crash/unbounded allocation was attempted and no product limit value is invented.
Version-pinned source inspection: stanza/jxt/StreamParser.d.ts exposes no byte/depth/element/attribute limit options. StreamParser.js builds nested element trees/text; Parser.js appends characters to recordBuffer across writes. stanza/transports/websocket.js creates one persistent parser, converts each socket.onmessage payload to text and writes it without checking completeness, size/depth, or text-message type. Therefore these separate parser writes model the transport's per-message ingress; actual WebSocket/TLS execution is NOT claimed. Browser WebSocket APIs also do not make a remote XML payload safe merely by using TLS.
Primary sources opened with web tool on 2026-10-15: RFC 7395 and upstream Stanza/xmpp.js repositories. [RFC 7395 section 3.3.3](https://www.rfc-editor.org/rfc/rfc7395.html#section-3.3.3) requires standalone XML per WebSocket message. The observed reassembly conflicts with that framing requirement when each write represents a distinct WebSocket message (inference from shipped transport source). Resource-limit absence is established by shipped API/source plus the finite examples, not by an RFC maximum. The alternative xmpp.js is not installed or tested and not selected as a safe replacement.
## Commands and limitations
- python3 scripts/tasks.py resume --agent auto-protocol-902594b44429; show S00-003; packet S00-003 --agent auto-protocol-902594b44429: exit 0 each; existing assigned task, no repeated claim.
- Initial git status --short: exit 0, only coordinator claim modification in state/tasks.json.
- Diagnostic command above: exit 0, all three cases reproduced in 0.154 seconds tool wall time.
- Exploratory guessed 0001-web-stack.md, lib/StreamParser.js and experiments/0017-scram-server-final paths were absent; actual required ADR/parser/remediation paths were located and read. These failed exploratory reads are not passed checks or missing required inputs.
Source edits stopped immediately after reproduction. No make check, clean npm ci, fresh SASL test run, browser build/runtime, real WSS handshake, complete NET-003 selection, extension roundtrip or independent interoperability was performed in this session. Parent npm test still points to absent future tests; do not use it as completed spike. No selection ADR was written. Existing dependency acceptance is reported as prior evidence, not re-executed validation. No certificate/CORS workaround, invented binding, crypto primitive, real credentials or Git mutation.
Next: separately reviewed atomic bounded frame/parser ingress experiment; original library selection resumes only in a fresh assigned session after resolver done and coordinator commit.