Corrections are logged as they happen
acceptednot accepted
When the user corrects the driver, it logs the correction verbatim as a file under the vault's corrections/, so retro starts from a ready list of what is not yet handled.
On this page
- Author
- agent
- Created
- Updated
- Review
- not shown
- targets
- groom, develop, code-review
- brief
- When the user corrects you — rejects a proposal, rewrites an output, says it is wrong, answers a gate other than you suggested — run `booping create core.corrections.template {vault}/corrections --set name={step} --set step={playbook}/{step} --set did=… --set said='{the user's words verbatim}' --set artifact={run artefact, vault-relative}`, with `--set why=…` when the user states it; a plain confirmation is not a correction.
Rule§
When the user corrects you — rejects a proposal, rewrites an output, says it is
wrong, answers a gate other than you suggested — run
booping create core.corrections.template {vault}/corrections --set name={step} --set step={playbook}/{step} --set did=… --set said='{the user's words verbatim}' --set artifact={run artefact, vault-relative}.
Add --set why=… when the user states the reason. A plain confirmation is not a
correction.
One file per correction under {vault}/corrections/, its frontmatter stamped with the
session id and the time; fields: core.corrections.template.
Follows from§
- Curated self-learning — a correction is logged, not turned into a rule; it reaches a rule only through retro and learn with the user.
- Analysable history — the log is plain markdown in the vault, with the session it came from.
- Corrections log — the decision to log corrections as they happen instead of mining transcripts at retro.
- Journal entries are vault files —
one file per correction, written by
booping create.