Orchestrata Ultimate › Research › Cut-over review

Cut-over review and test re-point measurement

The plan as recorded

• 25 increments, INT-01 to INT-25. Together they port 7,136 lines of original code. Each increment is at most 400 lines and at most 16 minutes.
• INT-01 is done. It holds the scaffold: the SPEC-125 delta, the release pyproject.toml with component pins, and the package __init__ files.
• Ruling gates. E-1 was cleared on 2026-10-20 (ADR-0115), which unblocked 18 increments. The plan still lists N4 as gating INT-11 (mint_gateway_token) and N-I1 as gating INT-04 (the Redis conversation consumer).
• INT-12 to INT-22 move the test runners into the integration package (orchestrata.run_tests and others), not into codetools.
• codetools pin. INT-01's pyproject.toml pins codetools as <PENDING tools release id>.

Cut-over review findings

1. The plan predates the wave tool. The 8 upstream packages landed through component_wave.py and land_component.py. Volks, for example, landed 286 modules in 44 s with 0 model tokens and 43 residue items. The integration plan instead assumes 24 separate per-increment dispatches. Their briefs are not written yet (increments/ holds only the README), and there is no packages/integration/.realize-out.
2. Half the plan is test tooling. INT-12 to INT-22 are 3,741 of the 7,136 lines (52%). The frozen snapshot e57782ea4 is stale for run_tests.py: 11 commits since have changed it by +566/−69 lines. ha_controller_cli (185 lines, in INT-22) is runtime code and stays in the release.
3. Two gates are stale records. N4 and N-I1 were APPROVED under AD-65 R3 (boundary-census.md lines 15–26 and 52), but the README and decisions.md still list them as gates.
4. Five CLI arrivals have no increment. The 5 AD-65 R3 CLI arrivals have no INT increment: ask_openrouter, e2e_run, graph_query, scan_implementation and generate_rtm_evidence.
5. Removing the old tree is not in the plan. In the 6-root snapshot, 1,596 of 2,091 test modules and 100 of 181 scripts import orchestrata_ultimate.

Test re-point measurement

The question here: if every import orchestrata_ultimate.X were rewritten to the package that now holds X, how many files would resolve?

"Resolves" means that a module at the same dotted path exists in the grammar's landed package.

Why most do not resolve. The landed packages moved modules:

• core.banned_libraries became util.banned_libraries;
• agents.volk_registry became kernel.volk_registry.

In all, 476 grammar modules have no file at the same path in any package: tools 112, kernel 102, contracts 73, session 55, kg 47, gateway 46 and governance 40. tools/src has 28 files against 120 grammar modules, because many of them were transferred to codetools.

No frozen-to-landed symbol map exists on disk. design.ir.json has no origin field. The mapping exists only inside fill_pkg's re-point logic. The next step is for a worker to build that map as an artifact. The re-point codemod would be built on top of it.

Other buckets:

• plugin code with no Python home: 14 modules, 27 test files;
• integration: 9 modules, 23 test files, which land with the wave;
• not in the grammar: 2.

Rulings that came out of the review (2026-10-22)

Both were published at the ADR publish step on 2026-10-23 (ADR-0130).

• "Cut-over first" (now Addendum 1 to ADR-0124). The components cut-over lands before either container is built, and the containers only ever run the components build. Until then, workers build on the host in worktrees.
• "OK, agree": keep the test runner out of the release (ADR-0127, Accepted). INT-12 to INT-21, and the start_test_services half of INT-22, are dropped from the integration release. ha_controller_cli stays. scripts/run_tests.py stays in the repo as a dev tool until codetools has an affected-set oracle, and only then moves to codetools. The ruling adds two work items:
  1. AST roots fix A: ast_pipeline.source_trees reads the declared roots. A Sonnet worker built it as eddfc6668 on fix/ast-pipeline-declared-roots. It is local and unpushed: 42 passed across 5 modules in 22 s, and the pipeline found 5,220 modules with 22 extra roots.
  2. Affected-set cross-package dependents, so that a contracts change selects kernel and volks tests.

What would make it faster

This list comes from the findings. It is a recommendation, not a ruling.

1. Run integration through the same wave tooling the eight packages used, instead of 24 hand-briefed dispatches.
2. Fix the two stale gate records so that INT-04 and INT-11 stop looking blocked.
3. Add increments for the five CLI arrivals, plus one for removing the old tree.
4. Build the frozen-to-landed symbol map first. Every re-point depends on it.

All four depend on the open packages/ ruling (ADR-0132, Proposed); see Python deployment best practices.

Related

• codetools versus the components branch
• Python deployment best practices
• Component DAG
• Open decisions
• Plans
• Upcoming work
• Research index