galvanize

Galvanizing

The genius of rallying work into motion. Its failure mode is the vague plan: a decision everyone agrees with and nobody can start.

The concept: convert the decision into slices a fresh session can pick up cold. A short behavioral brief, test seams agreed with the user as contracts, and vertical slices — each cutting through every layer the change touches, demoable on its own, its acceptance criteria verifiable by a stranger. One shape of work refuses the vertical cut: a mechanical change whose blast radius spans the codebase; plan that as expand → migrate → contract, the migration batches its slices, each still landing green. A value the plan leaves "sensible" is a decision deferred to a session that can't ask — write the number. A criterion needs an instrument as much as a number: one with nothing named to show it gets checked in somebody's head, and absences are the usual trap. Where no instrument can reach, say whose eyes decide; where those eyes are the user's, the slice closes with that criterion as an owed: line in Open (the genius-file format's Open rule). Each agreed seam names the test that proves it, and that test is a criterion at both ends of every after: edge that crosses it (the format holds the rule), so the edge is verified by a run at the waiting slice's close and not by a reviewer's eyes at close-out. The cut states its own order: the slice list's order is the build order, and a slice that waits on less than everything above it says so with after: — that line is what lets a coordinator run two slices at once, and what stops a fresh session grabbing a slice whose seam is not built yet. Pressure-test the cut with the user before finalizing; approval of a breakdown nobody pushed on is approval of nothing. Then put the blindspot skill's question to the contract before it binds: what would a stranger do to this system that no criterion mentions? An empty request, an unknown id, the one dependency everything routes through gone offline, the state after the last piece of work is done. Ask it because the contract binds the builder to what it says and frees it from what it doesn't, so what a competent engineer would do unasked is not built unless it is written.

Record base: and commit the plan as contract v1 — its full text in CONTRACT.md in the work's folder, contract: v1 in the snapshot's frontmatter, one pointer line in the snapshot's Contract section. Each slice's acceptance criteria are written once, there, under the slice's own heading; the snapshot's slice line carries the mark, the name, its after: and a link to that heading, never a second copy. This file is born here and nowhere else: a work that never ran Galvanizing has none. When the plan meets reality it changes by whole versions (genius-file skill). base: is HEAD as you write the line, never the plan's own commit: a commit cannot carry its own id, and amending one to add it orphans the sha you recorded. The pressure test itself — what the user pushed on, what it changed — is this stage's log entry, so the contract stays the contract rather than the transcript.

Where the repo tracks work in issues (Issue tracking: pinned, or the user asks), publish the approved breakdown before building starts: one parent issue for the work — its body the brief, the work file path, a task list of the slice issues — then one issue per slice, linked under the parent as sub-issues where the tooling allows. All wear one shared working-genius label, created if the repo lacks it; per-work grouping is the parent's job. Write the numbers back: — issue: #N on each slice line, **Parent issue:** #N in the snapshot's Slices section, where the format's template puts it. The work file stays the source of truth; issues mirror it.