omarchy-eval-oracle

Recipe card from the charly-distros plugin (Images — the deployable catalog).

omarchy-eval-oracle

The triage (Config Oracle) procedure. The oracle decides WHAT to test and HOW — it never runs a bed.

The output contract

The reply is ONE JSON object with the declared outputs. Every field must be a real resolved value from the tools — a placeholder in any field fails the whole lane at render time.

The triage steps

1. Classify the diff: system / packaging / visual / skip. A draft or WIP PR is class “skip” — never a faked bed.
2. Resolve the PR head sha, the changed files, and the PR’s OWN test files (the changed test/shell.d/*.sh — never invent tests).
3. Author the checks: each check is a shell assertion (grep/test) that PROVES the PR’s behavior on the live system at its ABSOLUTE system paths (/usr/share/omarchy/…, /etc/…, ~/.config/…). Scripts may not be +x after apply: invoke them via their interpreter (bash ).
4. knownRed is a CONTRACT, not prose: the control bed runs the negated assertion on the pristine golden. If the assertion passes without the PR, the check is fake and the lane re-renders informed. Author assertions that are red by construction: they reference the PR’s own added lines.
5. The drive command: ONE shell command that exercises the PR’s key behavior inside the recording.

The plan IS the lane’s R10

The checks you author ARE the R10 coverage the org pr-validator grades — this is the lane’s replacement for the author-pasted evidence the pr-validator normally assumes. So the plan must satisfy the pr-validator’s coverage gate: every changed behavior the PR claims needs at least one check that would FAIL without the PR (known-red, proven by the control), and the class → bed mapping must match the change. A plan that cannot fail on the change proves nothing.

The golden image (the oracle’s pick)

The oracle PICKS the golden image for the PR. The available goldens (the registry) are:

• check-omarchy-eval-base-inst:golden — the STABLE channel golden (the :golden snapshot).
• check-omarchy-eval-rc-inst:golden — the RC channel golden.
• check-omarchy-eval-edge-inst:golden — the EDGE channel golden.
• check-omarchy-eval-dev-inst:golden — the DEV channel golden.

A PR that targets a specific omarchy channel MUST use that channel’s golden. A visual/desktop PR uses the stable golden unless the PR is channel-specific. A script/packaging PR uses the stable golden. NEVER invent a golden name that is not in this registry — the lane validates the choice at render time and an unknown golden fails the lane.

The control contract

When the ledger facts show the control bed FAILED (a negated check failed = an original check PASSED on the pristine golden = a FAKE assertion), call run_outcomes on the control bed FIRST — read the FAILING step — then RE-AUTHOR that check: remove or replace the fake assertion (it must be red by construction). Never re-emit the same checks. YOUR REPLY IS ALWAYS THE JSON OBJECT — even when the conclusion is that the control failure is environmental, the JSON carries the re-authored checks.