design sketch: legion repos are probes, and the factory has no harvest path to bring their findings back

The factory already produces ephemeral repos, mutates them and discards them. What it does not have is a return path, so whatever those runs learned dies with them. This proposes a model for that, offered as a design sketch rather than a defect report.

The model is in production use on our side as a repo taxonomy (`aae-orc/_kos/ideas/three-tier-repo-taxonomy.md`, adapted for another org in `i-orc/docs/repo-tiers.md`). The half that is not solved anywhere is the harvest, and that half is squarely a factory concern because the factory is what generates the field.

## Three tiers

| Tier | Name | Governor | Lifecycle | Use case |
|---|---|---|---|---|
| 1 | **canon** | human, charter-tracked | stable, slow | the golden repo. One truth, protected branches, releases cut from it |
| 2 | **integration** | human | medium-lived | working copies. Owned (origin ours), `contrib/` (origin theirs, we push directly), `forks/` (origin our fork, upstream theirs) |
| 3 | **legion** | agent / factory | ephemeral, parallel, growing | replicas and variants that branch, split, expand and collapse. Also human throwaway spikes |

The tier split exists because governance differs, not because directories are tidy. Tier 1 is charter-tracked and swept by fleet recipes. Tier 2 is where a human works and where external contribution topology lives. Tier 3 is agent-governed, lives hours to days, and **must never be swept together with the other two**, or a fleet operation reaches into a thousand throwaways.

```mermaid
flowchart LR
subgraph T1["Tier 1: canon (human, charter)"]
C[golden repo]
end
subgraph T2["Tier 2: integration (human)"]
W[working copies
owned · contrib/ · forks/]
end
subgraph T3["Tier 3: legion (agent / factory)"]
V1[variant]
V2[variant]
V3[variant]
end
C --> W
W -- PR --> C
C -- factory spins off --> V1 & V2 & V3
V1 & V2 & V3 -. "findings, today: lost" .-> X((?))
style X stroke-dasharray: 4 4
```

## Legion repos are kos cycles, not just copies

The reframe that makes the harvest tractable: a variant is not a mutated copy of source, it is a **probe**. It exists to examine a question, it runs, and it yields findings. The factory is therefore running probe cycles at scale and in parallel, and the questions operate at three scales at once:

- **Micro.** What this one variant was spun off to examine.
- **Meso.** Patterns across a cohort in one run. Which mutations converged, which failed the same way.
- **Macro.** What the whole field says about **the factory itself**. Its error modes, blind spots, performance envelope. The variants are cross-cutting experiments on the machine that made them.

Each variant also carries latent data nobody asked for: errors, breakdowns, timings, and answers to questions that were never posed. The study surface is much larger than "did this variant work".

## The gap: no return path

Spinning variants off is solved. Bringing anything back is not. What is missing is a disposition step where the material a probe produced is handled deliberately instead of discarded by default. Borrowing the vocabulary we use for this elsewhere, a harvested finding lands in one of three states and **nothing is deleted**:

- **Adopt (bedrock).** The finding is load-bearing and evidence-backed. It changes canon: a spec, an ADR, a policy, a default.
- **Integrate (frontier).** Real but not settled. It becomes an open question carried forward, with the probe cited as its evidence.
- **Reject (graveyard).** It did not survive. The record stays, because the strongest value of a graveyard is stopping the same probe being run again in six months.

```mermaid
flowchart LR
Q[question] --> P[probe: legion repo]
P --> H{harvest}
H -- load-bearing --> A[adopt → canon]
H -- real, unsettled --> I[integrate → frontier question]
H -- did not survive --> G[reject → graveyard, retained]
A --> Q
I --> Q
G --> Q
```

Two properties worth building in from the start:

**Harvest is sampled, not exhaustive.** Study every instance and the cost of studying exceeds the value of the field. Different roles study for different things; some variants are never studied at all, deliberately. A design that assumes full harvest will be abandoned the first busy week.

**The index and the knowledge want different stores.** A node per variant would flood any knowledge graph with transient noise. The churning roster and lineage belong in a cheap indexed store queried without materializing the repos; only distilled findings that survive harvest graduate into the durable one. Discovery has to be an indexed query, not an O(n) probe across a thousand repos, and materialization has to be lazy.

## Where this touches the factory

- The factory decides what a variant is *for*, so it is the natural place to record the question a variant exists to answer. A variant with no recorded question cannot be harvested later by anyone, including its author.
- Variant lifetime is trending toward hours with N growing, so any harvest that requires a human to visit a repo before it is discarded will not hold.
- Macro-scale findings are about the factory itself, which makes this an observability feature as much as a knowledge one.

## Ask

Does the factory record, anywhere durable, the question a spun-off variant was created to answer? If it does, harvest is mostly a reporting problem. If it does not, that field looks like the cheapest possible first step, and everything above can be built incrementally on top of it.

This is a design proposal for adding a harvest path to the factory's ephemeral repos. Start by reading the factory's code for creating and managing variant repos. Look for where a variant's purpose or question could be recorded. The issue mentions macro-scale findings about the factory itself, so examine existing observability or logging. The goal is to understand the current variant lifecycle and identify where to attach metadata.

Written by the indexing model from the issue text.