Observed (siflow-test, 2026-07-22, second adoption run)
A wiki-adoption seed whose ledger is ALREADY closed at entry (coverage: 1575/1575 cited-or-excluded, lint clean under the deployed contract, provenance pre-bound) was dispatched as a plain compile.generate and the batch planner partitioned the raw set into 198 batches (~8 sources/batch) — the planner sizes the plan by source count, never asking what work remains.
The incremental (O(diff)) route cannot help here: before the first settle there is no compiled baseline manifest, so RAW_CHANGES is not computable — adoption is structurally forced into O(corpus) even when the correct amount of model work is near zero.
What the first compile of a closed seed actually needs
- deterministic entry selfcheck (code, minutes) — already exists;
- bounded verification only where the ledger is weak (unaccounted / dangling / flagged bindings) — O(residual), not O(corpus);
- import the seed's shipped contradiction tickets (adoption packages already carry them);
- settle + provenance commit.
Proposal
Box-side planner branch: on compile.generate with a NON-EMPTY candidate, run the entry selfcheck FIRST; if coverage closes (or closes above a threshold), emit a verification plan (per-page citation spot-checks + residual-only reads + ticket import) instead of the batch generation plan. Fall back to the batch pipeline when the seed does not close — i.e. classic first compiles are untouched.
Related: #430 (budget scales when the seed does NOT close), #426 (mechanical share demoted to code), #433 (image-doubt triage). Those shrink the per-batch noise; this issue removes the unnecessary batches themselves.
Observed (siflow-test, 2026-07-22, second adoption run)
A wiki-adoption seed whose ledger is ALREADY closed at entry (coverage: 1575/1575 cited-or-excluded, lint clean under the deployed contract, provenance pre-bound) was dispatched as a plain
compile.generateand the batch planner partitioned the raw set into 198 batches (~8 sources/batch) — the planner sizes the plan by source count, never asking what work remains.The incremental (O(diff)) route cannot help here: before the first settle there is no compiled baseline manifest, so RAW_CHANGES is not computable — adoption is structurally forced into O(corpus) even when the correct amount of model work is near zero.
What the first compile of a closed seed actually needs
Proposal
Box-side planner branch: on
compile.generatewith a NON-EMPTY candidate, run the entry selfcheck FIRST; if coverage closes (or closes above a threshold), emit a verification plan (per-page citation spot-checks + residual-only reads + ticket import) instead of the batch generation plan. Fall back to the batch pipeline when the seed does not close — i.e. classic first compiles are untouched.Related: #430 (budget scales when the seed does NOT close), #426 (mechanical share demoted to code), #433 (image-doubt triage). Those shrink the per-batch noise; this issue removes the unnecessary batches themselves.