# Programs — when one repo becomes several

**Activate this layer the day a second repo is born. Not before.**
Anticipatory program structure is scaffolding around a building
that doesn't exist.

**What broke without it:** sibling repos tracking each other's
plans until every roadmap churned with work it didn't own; the
map of the program living inside one member of the program, which
made that member secretly senior to its peers; identifier
collisions that turned cross-repo citations into guesswork.

## When to spawn a repo

The test is **dependency direction.** When a new initiative
*reads* this repo's content but this repo will never read the
initiative's, the initiative belongs in its own repo — because
otherwise its plan state churns this repo's master, and the
maintenance rule creates a back-edge from work this repo doesn't
depend on. Sovereignty follows dependency: the upstream repo
stays pure; the downstream repo reads upstream **read-only, never
edits it**, and pins the upstream version it builds against.

## The program index — a micro-repo

The map of all repos cannot live inside any one of them — then
one sibling owns the map of the others, and the back-edge returns
wearing a different coat. Install a dedicated micro-repo,
**senior to all children and dependent on none**, containing
approximately three files:

- `INDEX.md` — every repo in the program: name, one-line purpose,
  whether it runs a framework instance. **The index knows *of*
  everything and *about* nothing.** It never holds status —
  status lives in each repo's own master; tracking it here would
  recreate the exact maintenance burden this repo exists to
  prevent. The whole of an entry:

  ```
  | Repo | Purpose | Framework instance |
  |---|---|---|
  | `atlas-engine/` | The product: the engine and its spec | Yes — the original |
  | `atlas-docs/`   | Public documentation rendering the spec | Yes |
  ```

  Notice what the rows *don't* say: no status, no version, no
  "currently working on." One line each is the entire job.
- `NAMESPACE.md` — the identifier registry (below).
- The micro agent-instruction file: the program's standing
  constraints, and the one governing rule — **register at
  birth**: a new repo or initiative gets its INDEX row and its
  NAMESPACE prefixes before first work.

**The pointer shape is a tree.** Each repo's instruction file
carries exactly one static up-pointer to the index; the index
carries the N down-pointers — and being N one-line entries is its
entire job. Pointers accumulate only in the document whose
purpose is to accumulate them.

## Identifier namespacing

Each repo runs its **own** sequences — its own PLAN-001, its own
phases — but record-class prefixes must be **globally unambiguous
across the program**, because documents will cite across repos.
The first repo keeps the bare prefixes (`OV`, `DR`); every
subsequent repo registers distinct ones (a documentation repo's
rulings as `OVD-nnn`, say) so every citation resolves without
qualification. A prefix, once registered, is never renumbered,
reused, or retired-and-recycled — and vocabulary that exists is
*used*, never re-coined into a near-synonym.

## Instances share DNA, not state

Each repo runs its own complete instance of this framework — its
own master, registers, corpus, and gates, scoped to its own
domain, governing itself. The instances share this specification;
they never share state. No repo's master tracks another repo's
plans; cross-repo work cites records by registered prefix and
otherwise minds its own consist.

The litmus test: **can a new repo join the program with one INDEX
row, one NAMESPACE entry, and one up-pointer — changing nothing
else anywhere?** If joining costs more than that, a back-edge has
crept in somewhere. Find it before it compounds.