Point rule editors to invalid fields before evaluation starts
A rule containing weightGrams == 'heavy' parses successfully, then fails when a parcel reaches the evaluator. Support needs all actionable type errors from the saved rule before attempting a run.
- Focused work estimate
- 1h 30m + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Static analysis · Tree traversal · Diagnostics
Estimated field mix
- Compiler and language tooling70%
- Developer tooling30%
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
Keep validation separate from evaluation and compare visitor dispatch with an exhaustive function for adding independent tree operations.
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
- Validate permitted field/operator/literal combinations in a pass that does not evaluate parcel data.
- Return diagnostics in source order with node path and source range, capped at 50 with an omitted count.
- Keep the rule tree unchanged and report an unknown node kind as an unsupported-language error.
Implementation constraints
- Compare a visitor with an exhaustive traversal function; document how adding a node forces the validator to handle it.
Verification to include
- Collect distinct string/number mismatch diagnostics from separate branches in stable order.
- Pass a synthetic unknown node and a 70-error tree; verify safe rejection and the diagnostic cap.
Deliverables
- Static rule validator and support-facing diagnostic examples
Rollout and recovery
Run validation on synthetic saved rules in report-only mode before blocking new invalid saves.
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.