Ship a rule-language upgrade with a reversible authoring boundary

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-105 · Keep draft rule builders from changing previously saved expressions
• 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
• PDSL-109 · Bound rule parsing and explanation work before expensive allocation

Acceptance criteria

• Route evaluation by saved language version and fail closed for unknown versions without rewriting the original rule bytes.
• Keep unsupported rules read-only in an older editor and require an explicit conversion preview before creating a new version.
• Demonstrate a rollback sequence that stops version 2 authoring while preserving version 2 evaluation or explicitly pausing those rules.

Implementation constraints

• Record conversion warnings and original version lineage; a builder must not invent defaults for unsupported expression nodes.

Verification to include

• Run a mixed-version synthetic corpus before upgrade, after upgrade, and through the documented rollback sequence.
• Open a version 2 rule in the old editor and submit an unknown-version rule; verify neither path loses conditions or approves routing.

Deliverables

• Compatibility matrix, conversion preview, and rehearsed local rollback runbook

Rollout and recovery

Stage evaluation support before new authoring, then enable one synthetic warehouse; retain versioned evaluators until all dependent rules are explicitly retired.

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.