enable

Enablement

The genius of doing the work the work needs. Its failure mode is flying blind: code produced without feedback until a big-bang reveal at the end.

The concept: build one slice at a time, in a fresh context, with reality voting every few minutes. Tests lead the code — write the failing test at the agreed seam and watch it fail before the implementation exists; this is the one discipline a capable model still talks itself out of (measured 0/3 baseline), so hold it even when momentum says skip it. Test behavior through public seams, not implementation. Some criteria can't be red-green — verify those against the real thing and record what you observed; the rule is feedback, not ceremony.

Coordinating multiple slices? Hand each builder the snapshot's path, verify each returned slice against real output yourself, and stay awake until they're done — a builder's word is not evidence.

Closing a slice is one commit with four effects (genius-file skill): the code, the slice's log entry, the compacted snapshot, and the close of its issue if it carries one. The record updates as a side effect of an action you had to take anyway, never as bookkeeping someone must remember. (An issue closes via closes #N in the message where that commit lands on the default branch, and directly, pointing at the commit, where it won't; where .genius/ is gitignored, the files are written at that same moment all the same.)

Write the log entry while the output is still on screen — under the slice's own anchor, one line per criterion: the command and its result, data not prose (the work-file discipline's rule). It goes in the log and not the commit message; the work-file discipline names why a message can't serve as the record. Compact the snapshot to current truth in the same commit: mark the slice's line done and link its entry; land a convention introduced or a pinned value revised in the contract, where the next slice already reads; move consumed assumed: lines to the log with what consumed them. What the build merely disproved — a stated fact, a value that measured differently — is the errata skill's line-level correction, made by whoever makes the commit, in that slice's issue too where it carries one.

Start each slice by reading the snapshot's slice list, so a slice that closed without marking itself is caught by the next slice rather than at close-out. And a discovery worth its own piece of work — spotted mid-build, not this slice's job — takes its one line in .genius/BACKLOG.md before momentum buries it (genius-file skill).

A slice earns its close under fresh eyes, not just green tests. Before the closing commit, hand the slice's diff to a fresh, context-isolated reviewer, judged against the slice's acceptance criteria and the contract — under the same rules as Tenacity's close-out review: don't tell it what not to flag, and treat its findings as claims to verify, not orders. Fix what's real before the commit; what's real but not this slice's job goes to .genius/BACKLOG.md or an Open line. The slice's log entry notes the outcome in one line — reviewed → 2 findings fixed, 1 to backlog — so close-out can trust the slice was reviewed without re-reading its diff. Reviewing only at close-out means someone eventually reads a diff no one can hold in their head — slice-sized review catches problems while the context that produced them is still warm, and leaves Tenacity's reviewer free for what slice-sized eyes cannot see: the seams between slices.

When the build changes the requirements, the plan re-enters the flow at minute scale: pause, confirm, re-version, resume. A discovery that moves the work's shape — criteria, scope, slices, seams — is the normal case, not an erratum: the contract was right for the world it was written in; the build just made the world clearer. Never silently improvise around it. Pause the slice and put the change to the user in one exchange — what was discovered, what it changes, which slices it touches, with your recommendation; where they can't be reached, an assumed: line, flagged for next contact. Then bump the contract (genius-file skill): the new version whole in the snapshot, the old version whole to the log with what overturned it, one changelog line between them. Re-cut the slices only where the change reaches — a reshaped slice leaves no corpse in the snapshot; the reshape and its reason are a log entry, its issue closed with the reason, its replacement joining the work's parent issue and label like any other. Then resume, building against the version that now binds. Ten churns cost ten log entries and a snapshot the same size it started — which is the point: a plan that gets more expensive to change gets defended instead of corrected.