Detect duplicate configuration keys with both source locations
Repeated keys silently overwrite earlier values. Report the later assignment with a related earlier location.
- Focused work estimate
- 2h + prerequisites
- Priority in the scenario
- Medium
- Engineering practice
- Static analysis · Scopes
Estimated field mix
- Compiler and language tooling100%
Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.
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
Fictional build tool Sprig reads a tiny configuration language with identifiers, strings, lists and assignments. Author the grammar and synthetic source corpus locally; parsing never executes source.
Setup prerequisites
- Write the tiny language grammar and generated source examples.
- Create fixtures with Unicode, truncated tokens and nested lists.
Preceding work
Complete these dependencies, or supply their agreed outputs before taking this ticket.
- CPARSE-101 · Track configuration token spans across mixed newline styles
- CPARSE-102 · Reject unterminated configuration strings with one useful diagnostic
- CPARSE-103 · Preserve configuration string escape meaning
- CPARSE-104 · Parse configuration lists without unbounded recursion
- CPARSE-105 · Recover configuration assignments at a documented synchronization point
Acceptance criteria
- Duplicate is explicit
- Both spans are available
- Distinct nested scopes remain independent
Implementation constraints
- Do not normalize identifiers beyond the grammar contract.
Verification to include
- Detect duplicate in one scope
- Use same key in separate scopes
Deliverables
- Duplicate-key pass and cases
Rollout and recovery
Reject duplicate-bearing files if diagnostics cannot disambiguate them.
Value of the work
For the engineer: Practice source positions, grammar boundaries and error recovery.
For the team: Inspect whether tooling errors help users correct configuration safely.
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.