Bound rule parsing and explanation work before expensive allocation
The editor rejects a deeply nested rule only after parsing its entire text. A pasted megabyte of repeated parentheses stalls the local worker, and explanations allocate one message for every attempted comparison.
- Focused work estimate
- 3h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Resource limits · Parser robustness · Failure recovery
Estimated field mix
- Compiler and language tooling50%
- Security30%
- Performance engineering20%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
Pattern topics
- InterpreterRefactor
Make resource accounting part of the interpreter contract so nested expressions cannot bypass limits through separate parsing or explanation paths.
Review it, then add it to your workspace.
The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.
Project context
A fictional fulfillment product routes parcels using destination zone, weight in grams, and service level. Its next release needs nested eligibility rules, but arbitrary customer scripts are out of scope. Create a local TypeScript baseline and synthetic parcel/rule fixtures; no starter repository or fixtures are supplied. Keep parsing and evaluation in a local practice application with no network, filesystem, or host-code expressions in the language.
Setup prerequisites
- Recursive data structures
- Parser error handling
- Discriminated unions
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- PDSL-101 · Settle literal and operator precedence before saving warehouse rules
- PDSL-102 · Represent nested all-of and any-of rules without special-case depth handling
- PDSL-103 · Point rule editors to invalid fields before evaluation starts
- PDSL-104 · Stop treating an absent parcel weight as a zero-weight match
- PDSL-106 · Give the support inspector a stable walk through nested conditions
- PDSL-108 · Add membership expressions without leaving tree operations behind
Acceptance criteria
- Reject source text above 64 KiB before tokenization and enforce depth, node, and literal limits as input is consumed.
- Bound evaluation steps and explanation entries independently; return distinct stable limit codes without partial routing approval.
- After a rejected rule, the same process can evaluate a small valid rule with no retained traversal or explanation state.
Implementation constraints
- Use deterministic operation budgets rather than relying solely on wall-clock time; no regex features with unbounded backtracking are required by this language.
Verification to include
- Exercise just-below and just-above each declared bound with reproducible generated inputs.
- Alternate rejected and valid rules for 100 runs; confirm bounded diagnostics and unchanged valid outcomes.
Deliverables
- Limit enforcement changes, adversarial local cases, and resource-bound report
Rollout and recovery
Publish the limit codes in the local editor before enforcing them; revert language authoring if needed while retaining safe evaluator limits.
Value of the work
For the engineer: Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter.
For the team: Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules.
Evidence boundaries
Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.
Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.