The spec lives in the codebase

Here's the move everything rests on: the spec for a feature lives in the repo, as files under docs/ — not in a task tracker. Your feature definitions sit next to the code they describe, version with it, and travel with it.

This is a deliberate break from how most teams work, and it's worth saying why it matters:

• The builder lives in the code. The agent building the feature is already in the repo. Put the contract there and it reads the spec and the code together — the spec can actually govern the build instead of floating in another tab the agent never opens.
• Intent and implementation can't drift apart unsupervised. When the plan is a ticket somewhere else, the code and the intent diverge the moment work starts, and nobody reconciles them. Co-located, they're reviewed and versioned as one thing.
• It becomes permanent product memory. A closed ticket is archived and forgotten. A shipped spec graduates into the repo — the contract frozen, the rationale kept — so the why survives staff changes, vendor changes, and model changes. (Chapter 9.)

That's the bet: the feature definition is a repository artifact, not a tracker entry. Everything Specline adds — the fixed shape, the checker, the build loop — exists to make that bet pay off. It only works, though, if the artifact is consistent enough that an agent can rely on it. That's the next chapter.