Settle literal and operator precedence before saving warehouse rules
Operations wrote zone == 'north' OR service == 'express' AND weightGrams < 500. Two engineers read it differently, and there is no grammar to decide which parcels qualify.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- High
- Engineering practice
- Grammar design · Input validation · Error contracts
Estimated field mix
- Compiler and language tooling80%
- API design20%
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
- InterpreterApply
Use an explicit expression grammar as the interpreter boundary so precedence and permitted operations are reviewable before execution.
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
No earlier ticket is required. Complete the project setup above.
Acceptance criteria
- Define parentheses, AND-before-OR precedence, quoted strings, and nonnegative integer gram literals with unambiguous examples.
- Reject unknown operators, decimal weights, and trailing tokens with a stable code and source range.
- A parse result carries a language version; invalid input cannot produce a saved rule object.
Implementation constraints
- Keep the grammar limited to the three documented parcel fields; do not translate input into JavaScript or expose general function calls.
Verification to include
- Parse the disputed expression and its parenthesized alternative into different expected trees.
- Reject an unterminated string and an extra closing parenthesis without a stack trace in the public diagnostic.
Deliverables
- Versioned grammar note, parser entry point, and synthetic parsing cases
Rollout and recovery
Use the grammar for newly authored local rules first; retain the original text when reverting the parser version.
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.