The Tracker Is the Spine

The tracker is not merely reporting or ceremony; it serves as the sole source where a requirement, contract, unit of executable work, pull request, and acceptance decision coexist on one thread in an order that can be traversed in either direction. This thread exists solely to answer the question of what this requirement cost. To accomplish this, an estimate must be written before the work begins, and a fact recorded afterward.

Without these, the cost remains speculative, leading to arguments based on feelings rather than facts.

In one instance, iterations were consuming approximately 350,000 tokens each. The tasks were completed without any failures, but the real problem lay in the inefficiencies and redundancies. The majority of the cost was due to reconnaissance, where executors gathered context anew for every task, and rework, where the same facts were rediscovered repeatedly.

The solution was to add a "facts of the set" section to the spec, where each fact is written once and limited to specific files, preventing the need for repeated searches in the codebase.

The current format consists of four practices applied to every task: 1. An estimate is mandatory, measured in hours of executor time rather than abstract complexity. 2. Status transitions only occur when there's a change in task state, with explicit "blocked" states for external dependencies. 3. Incidents are documented immediately upon occurrence, with five categories to classify different types of issues.

4. Estimates are revised explicitly when scope changes occur, ensuring that each change is visible and tracked. This approach emphasizes attaching a number to each requirement, making the cost of work visible and quantifiable.