'Spec Merged' Does Not Mean 'Implementation Queued'

Somewhere around day three of the build, an engineer agent dispatched to wire together the processing pipeline stopped-and-flagged:

The core scoring module doesn't exist. I found only an empty __init__.py.

The specification for that module had merged two days earlier. It had passed review, landed on main, satisfied all the cross-spec dependencies that downstream work depended on.

Nobody had queued the implementation.

The Mechanical Failure

The spec task was marked "completed" when the spec pull request merged. The implementation was implicitly understood to be "what happens next." Except it didn't happen next, because there was no explicit ticket for it and the task tracker wouldn't surface it.

The deeper mechanic was worse. The spec had been deliberately decoupled from an adjacent module so the adjacent module could ship without waiting for the scoring work. That decoupling was correct — it unblocked parallel work. But the decoupling created an implementation-shaped hole in the plan that nobody was holding.

"Later" never gets a specific time, a specific assignee, or a specific trigger. The ticket for the implementation needs to be cut at the moment of the decoupling decision — not left as an implicit follow-up.

The Rule

Every spec-completion must explicitly queue its implementation task. Decoupling-for-sequencing must cut the successor ticket in the same conversation as the decoupling decision.

The second half is the harder part. When you say "ship X without Y, Y will come later," the "Y will come later" sentence is the one that fails.

A checklist version for retroactive audit:

1. Grep the task list for every spec that merged in the last phase.
2. For each merged spec, confirm there is an explicit implementation task with a specific owner or trigger.
3. If there isn't, you have a latent orphan. Either cut the ticket now, or explicitly declare the spec reference-only.

This Happened Twice

Two different modules. Two different phases. Same pattern each time. The first caught at integration. The second caught at deployment. Both were recoverable. Both wasted time that a queue-at-decoupling discipline would have saved.

The lesson: status tracking isn't neutral. It encodes assumptions about what "done" means. If "spec merged" and "implementation queued" look identical in your task list, you're one decoupling decision away from finding out the difference at the worst possible moment.

The Transfer

Any multi-module project with sequenced phase work is vulnerable to this pattern. The spec-to-implementation handoff is where the orchestrator's correctness-layer work has to happen explicitly. Marking a spec task complete on spec merge is shorthand that costs you a discovery later.

The remedy is not elaborate. It's one extra ticket, cut at the exact moment the decoupling decision is made.

That ticket is the thread that prevents the orphan.

Visual Summary

click to expand