You are a Haskell developer working on the Intent language compiler in ~/omni/intent. Your task:

1. Build a synthesis eval harness that runs the existing eval tasks through Synth.hs WITH and WITHOUT structured diagnostics (Diag.hs)
2. Measure: retry counts, success rates, wall time — an A/B comparison
3. Output results as a markdown table
4. Commit the harness + results

The structured diagnostics module is at Omni/Intent/Diag.hs (~555 lines). The eval tasks are in the existing eval suite. The question we are answering: does feeding structured S-expression errors like (error ErrTypeMismatch …) back to the LLM actually reduce retries compared to no feedback?

Start by reading ROADMAP.md, Diag.hs, and the existing eval infrastructure to understand the codebase, then implement the A/B harness.

Status check: what’s the state of the structured-diagnostics A/B eval task from April 6? Have you run the baseline (prose errors) vs structured-fix retry loops? Please report: (1) current status, (2) any numbers you have on retries-per-successful-synthesis, (3) what’s blocking completion if anything, (4) when you expect to have final numbers. Short bullet reply is fine.

Ping: reply with ‘alive’ and your current working directory.

Re-dispatching the structured diagnostics A/B eval — the previous prompt on April 6 never ran (agent was broken: wrong provider, no API key). You’re back online now.

Goal: measure whether the structured S-expression diagnostics layer (Diag.hs) actually reduces retries-per-successful-synthesis vs the old prose-error loop.

Plan:

1. First, look at your working tree — you have uncommitted edits to Intent.hs, ROADMAP.md, and untracked DIAG_SPEC.md + intent.jsonl. Decide whether to commit them as-is or finish them before running the eval. Commit what’s stable.
2. Run the A/B: pick a set of synthesis tasks (use existing test corpus if available), run each under both the prose-error loop and the structured-diag loop, record retries per successful synthesis.
3. Report back with: (a) sample size, (b) mean + median retries in each arm, (c) success rate in each arm, (d) your qualitative read on whether the structured layer is worth keeping.

This is the deliverable that closes out Phase 5 of the roadmap. Don’t move on to impl-vs-spec verification or data-layer primitives until we have these numbers. Ping me when done or if blocked.

Pick up t-766: Add iAUC (incremental area under the curve) metric to the health dashboard. Run ‘task show t-766’ for full description. The relevant files are in Omni/Health/Analyze.hs (add iAUC computation), Omni/Health/Web.hs (display it), and Omni/Health/Test.hs (add tests). The iAUC algorithm: for each meal window, sum (glucose - baseline) * interval_minutes for all readings above baseline. Unit is mg/dL·min. Extend MealSpikeRecord with an msrIauc field and add iAUC columns to food rankings and meal rankings tables on the /health page.

quick health check from migration

cli send test

local-daemon-send-test

post-upgrade send check