mini-ork apply¶

Close the apply loop: take the highest-confidence proposed prompt change, turn it into a scored workflow candidate, gate it on a non-regression rule, and then either rewrite the prompt file (promote) or quarantine it with a reason (regression).

The command is opt-in. Without MO_APPLY_ENABLED=1 — or the per-call --enable flag — nothing is written.

Usage¶

mini-ork apply --task-class <name> --target <file>
               [--target-kind prompt_file|agent_prompt|workflow_node|workflow_edge]
               [--dry-run] [--scorer probe|mock|gepa] [--enable]

Options¶

Flag	Default	Meaning
`--task-class <name>`	required	Which class's proposed directives to consider
`--target <file>`	required	File the change would rewrite
`--target-kind <kind>`	`prompt_file`	What kind of target the file is
`--scorer <name>`	`probe`	How utility is measured: `probe`, `mock`, `gepa`
`--dry-run`	off (unless `MO_APPLY_DRY_RUN=1`)	Do everything except the write
`--enable`	off	Sets `MO_APPLY_ENABLED=1` for this call

Scorers¶

Scorer	Behaviour	Can promote?
`probe`	Frozen probe-set held-out evaluation using real runs from `recipes/<recipe>/probes/*.md`	Yes — the only promotable scorer
`mock`	Deterministic placeholder that fabricates utility	No — test only
`gepa`	Neutral placeholder	No — test only

Without a real measurement the candidate is quarantined rather than promoted. That is the rule the scorer names encode: only probe measures anything.

Revert: `--revert-unverified`¶

The only-verified-learnings rule, enforced in reverse. This removes every prompt directive that was not earned by a measured promote, records the removal in promotion_records, and quarantines the matching version_registry rows.

mini-ork apply --revert-unverified [--dry-run]
               [--files-only | --db-only] [--include-home]

Flag	Meaning
`--dry-run`	Report what would be removed; change nothing
`--files-only`	Edit the prompt files only; no database writes
`--db-only`	Record and quarantine from database state alone (post-merge, when on-disk markers are gone)
`--include-home`	Also scan the project overlay (`<home>/recipes`), which a run reads before `<root>/recipes`

--files-only and --db-only are mutually exclusive. Use --db-only after a merge has already removed the on-disk markers but the ledger still lists the promotion.

Examples¶

# See what would be applied
mini-ork apply --task-class code_fix --target recipes/code-fix/prompts/implementer.md --dry-run

# Apply with the default probe scorer
mini-ork apply --task-class code_fix \
  --target recipes/code-fix/prompts/implementer.md --enable

# Audit: what directives were never earned?
mini-ork apply --revert-unverified --dry-run

# Remove them from files only, leaving the ledger for a later pass
mini-ork apply --revert-unverified --files-only

What "earned" means here¶

A directive is earned when a promote record shows a measured scorer (probe or code) produced a non-regressing result. Everything else — a model's suggestion, a frequency count, a placeholder score — is unearned and is removed by the revert path. This is why mock and gepa exist only for tests: they can produce a decision object, but never an earned directive.

Where apply sits in the loop¶

Three commands close the learning loop at three altitudes:

Command	Changes	Gated by
`promote`	A workflow version	Utility delta from `eval`
`apply`	One prompt file or workflow node	Probe-set non-regression
`self-improve`	This checkout, in a worktree	Full verifier run

apply is the smallest unit. It exists because prompt directives are the most tempting place to inject an unverified "improvement": a sentence can be added by anyone and it changes behaviour immediately. Requiring a measured scorer before the write, and offering --revert-unverified for everything that slipped through, is what keeps that surface honest.