Keep draft rule builders from changing previously saved expressions
The rule editor reuses a builder to produce two templates. Adding a condition to the second template mutates the first because both saved objects reference the builder's child array.
- Focused work estimate
- 2h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Object construction · Immutability · API ergonomics
Estimated field mix
- Compiler and language tooling50%
- Frontend30%
- 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
- BuilderCompare
Assess whether staged rule construction earns its complexity and make the handoff from a mutable draft to an immutable expression explicit.
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.
Acceptance criteria
- A build operation returns an immutable validated expression with no writable references to builder state.
- Incomplete drafts identify missing fields without emitting a partially valid saved rule.
- Building twice and then editing the draft cannot change either earlier result or its serialized bytes.
Implementation constraints
- Compare a builder with ordinary validated object construction; retain staged construction only where it improves the editor's incomplete-state handling.
Verification to include
- Build two rules from one draft and edit a nested child; verify both saved rule snapshots stay unchanged.
- Attempt to build a comparison without a literal and confirm no persisted rule identity is allocated.
Deliverables
- Draft-to-rule construction API and shared-reference regression reproduction
Rollout and recovery
Switch local editor saves behind a construction flag; old saved rules stay readable if the editor construction path is reverted.
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.