An Executable Plan Refuses Compromise

I opened a 634-line implementation plan. Documents like this usually get skimmed and approved without deep questions. My first assumption: it would be a loose guide, adjustable midway, or a formality to satisfy process requirements.

The assumption was wrong. This document is built to be executed task by task by another agent. Every task names its files, the interfaces it consumes and produces, and ordered checkbox steps. There is no room for free interpretation. The value of an executable plan lies in what it refuses, not in how many features it promises.

Binding Mechanical Rules

The plan states global constraints up front, and all of them are mechanical. Schema changes are allowed only through migration files that carry an up and down pair; direct database writes are forbidden. This matches the official documentation: each migration has an up and down migration [1]. Martin Fowler makes the same point in evolutionary database design, where each database change should be as small as possible so errors are quick to spot and debug [2].

The contract-first approach is strict. The API description file changes first, then code generation runs, and the compiler errors that appear after regeneration become the work queue. This aligns with the OpenAPI Specification 3.1.0, which defines a standard interface so humans and computers can understand a service's capabilities without reading source code or inspecting network traffic [4].

Beyond that, any slice that carries a test must add its registry line to the test index in the same commit. That is product verification made concrete: the end product must conform to its stated specification [3]. Slices touching an admin module must also add a changelog line to that module's document.

Risk and Contradiction

The plan does not ignore risk. One destructive-prone migration, an ENUM type change, is called out explicitly: the down migration must be tested on a local database before the commit. A real prevention step, not a paper warning.

The read model is added alongside the write model, not in place of it. Existing write guards stay as they are. The decision prevents regressions in business logic that already works.

Non-goals are written down just as clearly. One module is deliberately left unchanged. One contradiction in the requirements is recorded transparently as waiting for a client answer, instead of being settled unilaterally by whoever wrote the plan.

Contract-first ordering also removes one time-burning debate: when an endpoint counts as done. The contract is written, the generator runs, and the compiler error list becomes the task list. No guessing about request shapes or field names, because those were frozen before a single line of implementation. On a long plan, the pairing rule for migrations works as a safety rope: every schema change carries its own way home, so a mistake never turns into a one-way door.

The Value of a Refusal

The strength of this document is not its 634 lines but its firmness. It refuses to touch schema outside a paired migration. It refuses to write code before the contract. It refuses to let a test go unregistered. It refuses to silently decide an open conflict.

When a plan dares to set explicit boundaries, it stops being an administrative formality and becomes a navigation instrument. I am adopting this pattern of mechanical constraints in my own workflow next.

Sources

[1] golang-migrate README, accessed 10 October 2026.
[2] Martin Fowler, Evolutionary Database Design, accessed 10 October 2026.
[3] NASA, SEH 5.3 Product Verification, accessed 10 October 2026.
[4] OpenAPI Specification v3.1.0, accessed 10 October 2026.