Add membership expressions without leaving tree operations behind
Warehouse rules repeat long chains such as zone == 'north' OR zone == 'west'. Adding IN to evaluation alone would leave validation, inspection, and serialization unaware of the new node.
- Focused work estimate
- 5h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Language evolution · Exhaustiveness · Design tradeoffs
Estimated field mix
- Compiler and language tooling70%
- System design30%
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
- VisitorCompare
Use a real new-node change to compare operation-oriented visitors with node-local methods and make the extension cost visible in the patch.
- CompositeRefactor
Integrate the membership leaf into the uniform expression tree without adding special group traversal paths or weakening node validation.
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
Acceptance criteria
- Add string-set membership with a 50-item limit, explicit duplicate handling, and no implicit type conversion.
- Update parsing, validation, evaluation, inspection, and serialization, with an exhaustive mechanism that exposes unhandled node kinds.
- Compare visitor-based operations with node-local methods for this change and explain which extension axis becomes easier or harder.
Implementation constraints
- New syntax uses a new language version; existing rules retain their old version and behavior, including missing-field outcomes.
Verification to include
- Compare membership and equivalent OR rules over present, absent, matching, and nonmatching zones.
- Run every tree operation on the new node; reject a 51-item set and an older parser receiving the new version.
Deliverables
- Membership implementation, operation coverage matrix, and extension tradeoff note
Rollout and recovery
Enable authoring for the new version after all operations support it; turn off new authoring without rewriting saved older rules.
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.