Context-aware ILO-P009 hints for ternary-brace misfires

[danieljohnmorris]

Summary

Two parser-diagnostic improvements on the ?-syntax family. Pending #5x and #6 in the assessment log, both tagged S, paired in one PR because they share a code path (the { token interception during prefix-ternary operand parse).

Manifesto framing: a bare ILO-P009 expected expression, got {`` is the worst kind of diagnostic for an LLM agent. No hint = no recovery path = a re-prompt that re-emits the same code (or worse, restructures and breaks something else). One persona run (cron-explainer) burned 167k tokens partly on this. All ten date/time personas tripped on the ?h cond{body} variant. This PR turns those into actionable one-line hints.

Repro before / after

?h x{0:1;_:2} (match-on-value shape):

Before:

ILO-P009 expected expression, got `{`

After:

ILO-P009 expected ternary operand, got `{` (looks like match-on-value arms)
  hint: match arms need a single bracketed subject. Drop `?h` and write `?x{<lit>:body; _:fallback}`;
        for a multi-token subject use `?(<expr>){...}`

?h ok{1} (three-form conditional confusion):

Before:

ILO-P009 expected expression, got `{`

After:

ILO-P009 expected ternary operand, got `{`
  hint: three conditional shapes: prefix-ternary `?h ok a b` (no braces),
        brace-ternary `ok{a}{b}` (no `?h`), braced-conditional `ok{body}`
        (no `?h`, single brace). Pick one

What's in the diff

Three commits:

1. add context-aware ILO-P009 hint for ternary-brace misfires (src/parser/mod.rs, +93)
   • New prefix_ternary_brace_hint helper called from both statement (parse_match_stmt) and expression (parse_prefix_ternary) positions
   • Match-arm shape detected by peeking one token past { for <num>: or <text>:
   • First-operand source threaded through so the hint substitutes the condition the agent actually wrote
2. test: cover ternary-brace hint shapes across both positions (tests/regression_ternary_brace_hint.rs, +151)
   • Six tests: match-arm fires + correct subject substitution, three-shape fires + does NOT misfire as match-arm, expr-position parity, canonical ?(expr){...} and ?h a b c still parse
3. docs: add match-on-value example and conditional contrast in skill (examples/match-on-value.ilo, skills/ilo/ilo-language.md)
   • New example pins ?subj{...} and ?(expr){...} so the harness regresses both
   • One-line conditional section in ilo-language.md contrasts the three canonical forms (entry perf: pre-size string concatenation with String::with_capacity #6's doc-sync ask)

Test plan

• cargo build --release --features cranelift clean
• cargo test --release --features cranelift all green, 0 failures
• cargo clippy --release --features cranelift --all-targets -- -D warnings clean
• cargo fmt --check clean
• Manual repros verify hint text for both shapes
• Canonical ?(expr){...} and ?h cond a b still parse cleanly

Follow-ups

None blocking. The match-arm detector is intentionally conservative (one-token lookahead for <num>: or <text>:); pattern arms with ~v: / ^e: / _: deliberately do NOT trigger the match-on-value framing since those are Result/Option destructuring, not value-equality matches.

[codecov]

Codecov Report

❌ Patch coverage is 95.55556% with 2 lines in your changes missing coverage. Please review.
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/parser/mod.rs	95.55%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!