fix(workbench): retire beh.sandbox from the baseline, confirmed at n=10

[EtienneLescot]

Summary

assertAgainstBaseline reads the union of the scenario's expectedFailures and the baseline file's, so removing beh.sandbox from the scenario alone left it live. Every run printed:

! défaut connu semble corrigé sur wizard-enhance/beh.sandbox : confirmez à n plus élevé …

A permanent notice is ignored as fast as a permanent green, which is exactly what lib/baseline.ts says the bidirectional ratchet exists to prevent.

Removed on two arguments, not one

Structural. deep-agent/service.ts builds its agent with createAgent and the OpenScreen tools alone — the phantom ls/grep/glob surface this check probes for is gone. A call to one of them today would be a hallucination, i.e. an unexpected failure, which is the signal the scenario wants. The check itself stays for exactly that reason; only the expectation is retired.

Measured, as README.md § "Le ratchet tourne dans les deux sens" requires before any removal:

check	k/n	Wilson 95%	outcome
beh.sandbox	10/10	[72%, 100%]	retired
dsl.focus.not-fabricated	10/10	[72%, 100%]	kept
beh.multiplier	9/10	[60%, 98%]	kept
beh.counts	9/10	[60%, 98%]	unexpected failure — see below

n=10 on 2026-08-21, resolved model deepseek-v4-flash (deepseek-chat requested; the MODÈLE RÉSOLU notice fired). Verified after the edit that the notice stops firing.

Why dsl.focus.not-fabricated scored 10/10 and stays anyway

It has only the observation behind it — no structural argument, and the scenario documents the faulty code as still present. That is the difference between "the cause is gone" and "variance was kind ten times", and it is why the numbers alone were never going to settle either entry.

The single-rep verification run after the edit makes the point again from the other side: beh.multiplier passed there and printed "seems fixed", having just been measured 9/10 at n=10. One green run proves nothing, which is precisely what the README says.

The baseline's numbers are an archive, and now say so

behaviour: 0.6667 was computed on 2026-07-31 over a check set that no longer exists — beh.no-false-negative has since become the judged beh.attributes-the-limit under a new id. They are not re-recorded:

• Nothing reads them. BaselineVerdict derives no field from them and assertAgainstBaseline compares ids only; every behaviour read in cli.ts and report.ts comes from the run's own score, not the baseline's.
• Re-recording from this run would freeze an anomalous pass, one in which beh.counts regressed.

Hand-edited rather than --update-baseline, which would have harvested both intermittent entries on a single green run — the exact failure the README forbids.

Also

l0/stats-report.wb.ts used beh.no-false-negative as a synthetic id in a fabricated report fixture. Nothing read it from the registry so nothing broke, but a fixture wearing a dead real name reads as a live one. Renamed to beh.synthetique.

Related issue

Refs #428 — one of the two pre-existing defects surfaced by #452 and deliberately left out of it, each being a claim about the product that needed its own measurement.

Stacked on #452

Branched from feat/workbench-migrate-cursor-denial, not main: that branch already edits baselines/wizard-enhance.json (it removed the beh.no-false-negative line) and wizard-enhance.scn.ts. Merge #452 first.

Type of change

• Bug fix
• Feature
• Enhancement
• Documentation
• Refactor / maintenance
• Performance
• Security

Release impact

• No release note needed

Desktop impact

• Not platform-specific

Testing

• npm run wb:live -- --scenario wizard-enhance --reps 10 --label sandbox-confirm — the measurement above.
• One further live rep after the edit, confirming the beh.sandbox notice no longer fires while the two intermittent ones still do.
• workbench/l0 — 44 failures, the pre-existing absent-fixture baseline, unchanged; 328 passing.
• workbench/l1 — 21 failures, same baseline; 62 passing.
• npm run wb:typecheck, npx tsc --noEmit, npx tsc -p tsconfig.test.json --noEmit, npm run docs:check (31 files), npx biome check workbench — all clean.

One thing this run surfaced and did not fix

beh.counts failed 1 of 10 and is not in expectedFailures, so the ratchet correctly flagged it as a regression. It is a genuine finding about model behaviour on this scenario, not about anything in this PR, and it needs its own measurement rather than a rider here. Worth an issue if it reproduces.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 983d7b59-391a-4d83-a5d3-0a73f422918c

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}