Assembly Plan

1. 01Several assemblies in one plan, arranged into dependency levels, where each level consumes the previous level's product by name
2. 02Six assembly chemistries per step — Type IIS restriction, Gibson, BioBrick standard, BASIC, ligase cycling reaction, and oligo-pair annealing
3. 03Leaf-part list: the physical parts a bench user must actually have, derived from the graph rather than from the plan text
4. 04Plan drawn as a status-coloured dependency graph, per level
5. 05A failed step cancels its dependents, and a cancelled step names its root cause rather than its immediate parent
6. 06Per-row validation derived on every edit — unknown part names, a step depending on itself, duplicate step names
7. 07Every construct openable: show on the map, open in the editor, or open as its own project

The planner is a port of DnaCauldron's AssemblyPlan and AssemblyPlanSimulation, golden-validated byte-for-byte against real DnaCauldron 2.0.12 on its own hierarchical-BioBrick fixture — the derived graph including node order, every construct sequence, the per-assembly errors and warnings, the outcome tally and the cancellation list. The app-facing wrapper carries a golden of its own, because a plan simulation is a composition and the parts' goldens do not cover it. The panel runs on @ports/assemblyplan.

Everything runs client-side. Files are parsed in the browser and projects are saved on this machine, so an unpublished sequence is never uploaded.

How is this different from running Gibson or Golden Gate several times?

The levels are derived from the parts each step consumes, so a construct that needs another construct is scheduled after it automatically. Running the assemblies one at a time means keeping that order in your head, and re-doing it whenever a part changes.

How are the levels worked out?

From the plan itself. Each step names its inputs, which gives a dependency graph of part to assembly; a step's level is its longest distance from a leaf part, so a step reachable by both a short and a long path sits at the long one and never runs before its input exists.

What happens when one step fails?

It is reported as errored and the steps that consume its product are cancelled rather than simulated, because their input was never made. Each cancelled step names the step that actually failed, not the neighbour it was waiting on.

What names do parts have?

Their file names, not the LOCUS inside the record — a plan refers to a part by the name you chose, and DnaCauldron builds its repository the same way. The shipped starter proves the point: one iGEM part's LOCUS disagrees with its file name.

Can I mix chemistries in one plan?

Yes. Chemistry is chosen per step, so a Type IIS level can feed a Gibson level. The Type IIS enzyme control appears only for the steps whose method uses one, and that flag comes from the engine, so the control cannot disagree with what runs.