[githubscum]

WO: WO-L84-01 + WO-L84-02 (Lotor lane run 80). Addresses: a new limit, 84: the matcher stamp still misses helpers its hashed rules call. This is the candidate run 77 flagged (firstBraceGroup, matchableCommand), measured, and it turned out to be 23 names, not 2.

What this PR is: docs and a test. No core file touched. The fix itself is core (the policy module's matcherHashInputs()) and queues for a signing sitting.

What changed

• KNOWN-LIMITS.md: new entry 84, pin re-stamped.
• test/policy-matcher-stamp-helpers.test.js: a tripwire in the same form as the limit-63 one. It asserts the defect today and fails on purpose when the fix lands.

Evidence (executed, not read)

1. Measurement. A probe listed every top-level function and regex constant in the policy module and checked each one against matcherHashInputs(). 21 of 57 are hashed. 18 functions and 5 constants are called or referenced from hashed text but their own source is not hashed.
2. Mutation. I patched scratch copies of the module, never the repo:
   • matchableCommand with prose stripping removed: isPushForce on git commit -m "do not git push --force" goes from false to true.
   • firstBraceGroup returning null: self-mod on touch src/g{a,x}te/x.js goes from true to false. This is an under-gate.
   • In both cases the stamp stayed e0877fab0f459e0c.
3. Tripwire check. A scratch copy with all 23 names added to parts made the test go 2 pass / 23 fail, as designed. On this branch it is 25/25.
4. npm test: 1404 tests, 1399 pass, 0 fail (main is 1379; this adds 25).

Executor and verification

• Executor: glm-5.3-flash, two WOs. The Lotor session receipts show model: glm-5.3-flash for both sessions, and the only file touched is the test file.
• Verifier pass (mine) caught one flaw in WO-01. The constant checks looked for the text const NAME =, which would never trip on the natural fix (NAME.toString() emits the literal). WO-02 changed them to key on the regex literal, and check 3 above confirms they now trip.
• Written by me, not the executor:
  • the KNOWN-LIMITS prose;
  • a one-word fix to a test title ("UNREFERENCED" became "REFERENCED"). That is a hair over the "executor writes" line, and I'm disclosing it here.

Eval served: none of E1-E6. This is stamp integrity (R-trust), not v3 granularity. The v3 spec has nothing unstarted except V3-07, which is still unruled.

What a reviewer should doubt

• The list is a lower bound. It counts only direct references from hashed text. evaluate()-only callees (isImplicitProtectedPush) and helpers reached only through other unhashed helpers (INLINE_CODE_FLAG, PRESIGN_PARAM_PREFIX) are named in the entry but not tested. The sitting fix should probably derive the list from the call graph instead of extending it by hand again.
• The control regex \bNAME\( is textual. A call inside a comment in hashed text would satisfy it. I checked that the hits are real call sites, but the test does not enforce it.
• The test reads the policy source with fs to find the literals. If a constant is reformatted onto two lines, regexLiteralOf throws instead of passing silently. That is the right failure direction, but it is noisy.