Summary
scripts/toolcraft-dom-call-target-evidence.mjs has per-call analysis budgets:
const MAX_CALL_TARGETS = 64;
const MAX_CALL_PAIR_VISITS = 256;
const MAX_CALL_SOURCE_SUMMARIES = 512;
When a call's static-flow analysis exhausts, the collector falls back to checker.getTypeAtLocation(call) (line ~201), which resolves to any → risk unknown → dangerousOverflow = true. Safe code is then reported as a capability violation:
src/app/app-schema.ts:84:14: lib.dom capability cannot be erased into a structural non-DOM boundary
that exposes markup or interaction authority.
In one app this produced 12 violations, all false positives — every collected source/target pair was in fact plain/safe with erased: false. Flagged lines included pure numeric code (Math.imul, (hash >>> 0).toString(16)).
Not a blocker: it is workable around in product code, so no framework change is required to unblock an app.
Signature
The flags cluster partway through a large literal — early calls in the same object pass, later ones fail. That is the budget exhausting, not a real capability leak. Worth recognising because the message reads as a security finding and sends authors hunting for a nonexistent DOM capability escape.
Workarounds that cleared all 12 (value-preserving, product-side only)
- Hoist helper calls out of a nested
defineToolcraft({ … }) literal into module-level consts — cleared 9 at once.
- Extract a flagged region from a long function into a small dedicated helper. Two identical
context.stroke() calls in one file: only the one inside the longer function was flagged.
- Replace imperative
.push() loops with Array.from({ length: n }, (_, i) => …).
Suggestion
When the collector exhausts its budget, treat the result as indeterminate rather than dangerous, or emit a distinct diagnostic. A budget limit should not be reported as a capability violation. At minimum, documenting the budget constants would tell authors that the reshape above is the intended remedy.
Why an issue rather than a PR
Which direction to take — indeterminate result vs. distinct diagnostic vs. raising the budget — is a design call, and it changes what the check reports.
Environment: @pixel-point/toolcraft (reproduced against main), Node v24.4.1.
Summary
scripts/toolcraft-dom-call-target-evidence.mjshas per-call analysis budgets:When a call's static-flow analysis exhausts, the collector falls back to
checker.getTypeAtLocation(call)(line ~201), which resolves toany→ riskunknown→dangerousOverflow = true. Safe code is then reported as a capability violation:In one app this produced 12 violations, all false positives — every collected source/target pair was in fact
plain/safewitherased: false. Flagged lines included pure numeric code (Math.imul,(hash >>> 0).toString(16)).Not a blocker: it is workable around in product code, so no framework change is required to unblock an app.
Signature
The flags cluster partway through a large literal — early calls in the same object pass, later ones fail. That is the budget exhausting, not a real capability leak. Worth recognising because the message reads as a security finding and sends authors hunting for a nonexistent DOM capability escape.
Workarounds that cleared all 12 (value-preserving, product-side only)
defineToolcraft({ … })literal into module-levelconsts — cleared 9 at once.context.stroke()calls in one file: only the one inside the longer function was flagged..push()loops withArray.from({ length: n }, (_, i) => …).Suggestion
When the collector exhausts its budget, treat the result as indeterminate rather than dangerous, or emit a distinct diagnostic. A budget limit should not be reported as a capability violation. At minimum, documenting the budget constants would tell authors that the reshape above is the intended remedy.
Why an issue rather than a PR
Which direction to take — indeterminate result vs. distinct diagnostic vs. raising the budget — is a design call, and it changes what the check reports.
Environment:
@pixel-point/toolcraft(reproduced againstmain), Node v24.4.1.