feat: real multi-nozzle printers + user-definable filament slots (v0.8.0)

[Hiosdra]

Closes #140. Supersedes #154, whose commit is included here.

Real multi-nozzle machines work, and filament slots are now something you can actually create in the UI rather than only inherit from an import.

Eleven commits: the engine fix, the per-object assignment UI, the slot-definition UI, a minor version bump, six rounds of review follow-ups, and a documentation pass.

1. Engine — three defects, none where the issue predicted

The issue blamed support_different_extruders() and per-extruder G-code placeholders. The real causes were all ours:

Wrong separator for multi-value options. The passthrough joined every array with ,, but the separator depends on the option's type: coStrings uses ; with c-style escaping, coPointsGroups uses # between groups (, only separates points within a group). An H2D stores one printable area and one colour per nozzle, so comma-joining fused each pair into one entry — leaving nozzle_diameter length 2 with length-1 companions, indexed by extruder id, dying in Brim.cpp::outer_inner_brim_area() and ToolOrdering's flush-matrix lookup. The join now happens in the bridge, which reads the separator from the engine's own option registry rather than a JS-side list that could drift.

UI-mapped multi-value fields never reached the engine. ORCA_FIELD_MAP collapses arrays to one scalar for display, so nozzle_diameter: ["0.4","0.4"] became 0.4 — a dual-nozzle machine sliced as single-nozzle.

Uninitialised plate origin. Print::m_origin is an Eigen Vec3d with no default member initializer, and only the desktop GUI's PartPlate code calls set_plate_origin(). Headless it stayed garbage, and shift_without_plate_offset() subtracts it from every instance shift — so Brim.cpp translated brim polygons by that garbage and Clipper rejected them. Being uninitialised memory it was layout-dependent: it surfaced only for some meshes and flipped on unrelated edits. Caught because the synthetic icosphere in smoke-test.mjs began failing after a bridge change that never executed, confirmed with a control build where the new function was present but unreachable. Note this corrupted brim geometry for ordinary single-nozzle prints too, whenever the garbage happened to be large.

isMultiExtruderProfile() is removed — it had nothing left to guard.

2 & 3. UI — assign objects to slots, and create slots in the first place

The queue gains a per-object Filament picker (shown only when the config has more than one slot), and the Settings panel's Filament section becomes a list: add a slot, pick a material per slot, remove one. A single slot looks and behaves exactly as the old single "Material" dropdown.

Making slots real to the engine is the substantive part. Its filament count is not filament_type (that is display text — #155) but the length of filament_colour, and several vectors must agree or it reads past the end of one:

• filament_colour — one distinct colour per slot; this is what establishes the count
• filament_map — each slot to a physical extruder, round-robin over available nozzles: all on extruder 1 for an AMS-style single-nozzle printer, alternating on a dual-nozzle machine (which is what produces genuine T0/T1)
• flush_volumes_matrix — one N×N sub-matrix per nozzle laid end to end, and flush_multiplier one entry per nozzle; GCode::append_full_config() divides the former by the latter to validate the shape
• filament_start_gcode / filament_end_gcode — read with .at(filament_id), so a one-entry default throws the moment anything prints with a slot other than the first

Slots are applied after the config layers merge, not inside buildConfig(): an imported machine profile is the only way a real multi-nozzle printer reaches us today, and it only becomes visible once that layer is combined. Deriving the nozzle count earlier would put both slots on nozzle 1 and silently waste the second.

4. Version

Bumped to v0.8.0 — a feature boundary rather than a routine patch, so this takes the minor instead of letting deploy.yml auto-increment. deploy.yml respects a version already ahead of the latest tag and will tag/deploy v0.8.0 as-is.

5. Follow-up: the slot assignment outside a plate slice

Reported after the first push: changing an object's slot on the Slice tab after slicing did not offer to re-slice the way a settings change does. The missing indicator was the visible half — the assignment genuinely did nothing for a single-item slice, because only orc_slice_multi carries a per-object filament. Both halves are fixed: an item with a slot assigned is now sliced as a single-object plate, and reassigning marks its own result (and the plate's) stale.

Sizing filament_start_gcode/filament_end_gcode per slot is what makes any slot but the first usable at all — assignments of [1] and [1,2] worked while [2] and [2,2] threw std::out_of_range.

6. Follow-up: review fixes

Three of these were silent — nothing in the UI showed the wrong state.

• Manual overrides survived. withFilamentSlots() built every slot from FILAMENT_PRESETS, slot 0 included. Those arrays land in _passthrough, which the worker spreads over the resolved config, so adding a second slot silently reverted a hand-typed nozzle or bed temperature back to the preset value — undoing Manual settings outrank profiles and survive printer/filament/preset changes #159 for any multi-slot config. Slot 0 now reads the resolved config.
• Preset G-code hooks survived. The same function overwrote filament_start_gcode/filament_end_gcode with empty strings; it now pads the existing value across the new slots.
• Picker and vectors can no longer disagree. The picker offered a slot per entry of a multi-value filament_type, which an imported profile can carry without the UI having defined any slots. withFilamentSlots() now sizes for max(UI slots, declared), and both the picker and the queue read one shared filamentSlotLabels().
• Removing a slot drops assignments naming it. Below two slots the picker disappears, so those were invisible — but buildPlateExtruderIds still sent them.
• Slots persist. selectedFilaments was missing from the settings-persistence effect's deps, so adding, removing, or editing any slot but the first was never saved. Saved user presets carry the whole list now, not slot 0 alone.
• "+ Add filament slot" picks the first unused material rather than duplicating the last, and adding/removing a slot no longer sheds an imported filament profile — only a change to slot 0, the slot that layer describes, does.
• Docs/comments. status.md still listed real multi-nozzle as deliberately blocked, and four comments pointed at the deleted isMultiExtruderProfile().

7. Follow-up: the imported multi-material profile

Same class as §6, one slot further down the list. withFilamentSlots() rebuilt every per-filament vector from scratch, so a profile that arrived declaring its own values had them silently replaced by stock presets the moment the slots were sized — _passthrough is spread over the resolved config, so anything written there beats what was imported:

declared by the import	became
filament_colour ["#FF0000","#00FF00"]	SLOT_COLOURS
filament_diameter ["2.85","2.85"]	["1.75","1.75"]
hot_plate_temp ["55","80"]	["55","70"] (stock PETG)
flush_volumes_matrix [0,700,700,0]	uniform 280

Each option now prefers the value the config already carries for that slot. Two exceptions stay explicit: slot 0 of an option the settings panel edits reads the resolved config (a manual override lives there — #159), and a slot the UI names takes the material the user picked over whatever an older import said. The vectors whose length the engine validates can't be honoured entry by entry, so flush_volumes_matrix, flush_multiplier and filament_map are kept only at exactly the required shape — and filament_map only when it names nozzles this machine has.

Slot 0's filament_type could not be read off the resolved config at all. ORCA_FIELD_MAP collapses a multi-value option to one scalar for display, so an imported dual-material profile left config.filament_type as the joined "PLA,PETG" — which reached the engine as slot 1's type and showed in the queue's picker as Slot 1 · PLA,PETG. Taken from the unflattened passthrough array instead.

Two smaller ones: parseOrcaProfileJson stored a single-entry [""] as "" where the old comma-join dropped it, letting an import blank out a built-in preset's value (multi-entry arrays keep their empties, where the length is load-bearing); and colours past the hand-picked palette repeated it instead of walking the hue circle.

e2e now covers the slot UI for the first time — add a slot, see the picker appear with one option per slot, assign, remove the slot, find the assignment dropped rather than left naming a filament the engine no longer has. Verified against a negative control that fails with unexpected value "2" when CONFIG_CHANGED stops dropping it.

8. Follow-up: review fixes

Two more of the same shape as §6 and §7 — _passthrough is spread over the resolved config, so what withFilamentSlots() writes beats what is underneath it. Both silent; the panel kept showing the value the engine was not using.

• A declared filament_diameter survived one UI slot and not two. per()'s "a slot the UI names wins" rule is there because the user picked a material, so that material's preset outranks an older import — sound only while pick actually reads the slot's material. No FILAMENT_PRESETS entry carries a diameter, so it was passed () => undefined and the derived value was the bare literal 1.75: the branch had nothing to contribute and could only overwrite. An import declaring 2.85 kept it at one slot and became ["2.85","1.75"] on adding a second — the normal way to use a dual-material import, and the path §7 stopped one step short of. Every E value on that slot is then off by (2.85/1.75)². It joins filament_colour on a new declaredOr() helper, and per()'s doc now states the precondition its middle branch depends on.
• hot_plate_temp_initial_layer was missing from PANEL_EDITED_SLOT_OPTIONS, though the panel edits it: toEngineConfig() fans the single "Bed temp" field out to both it and hot_plate_temp. A single-slot config put the typed number in both; adding a slot left the first layer on the imported profile's temperature — Manual settings outrank profiles and survive printer/filament/preset changes #159 again, one option down, on the layer where bed temperature decides adhesion. nozzle_temperature_initial_layer stays out for the same rule read the other way (toEngineConfig() never writes it).

Reverting either fix alone fails exactly its own new test and nothing else.

Three with no behaviour change: slotColour()'s HSL ramp was discontinuous at both joins (slope 1.932 where the endpoints require 6·(max−min) = 3.804, and the stated S/L described neither endpoint) — saturation and lightness are now the inputs and everything else is derived from them; the bridge's static set_plate_origin() is renamed zero_plate_origin() so the call site stops reading as though it passed an origin; and smoke-test.mjs's hand-written DUAL_NOZZLE_CONFIG — which cannot import the TS module and so could keep proving T0/T1 for a config the app no longer builds — is now pinned by a test asserting the option set and every shape the engine validates.

9. Follow-up: review fixes

Four more. The first is §5's shape one step earlier: §5 made a reassignment after a slice offer a re-slice, and this one makes a reassignment during a slice not be lost. Silent again — the result came back looking current.

• A reassignment made mid-slice was dropped. ASSIGN_EXTRUDER flagged only an item already done, and the plate only when it already had G-code — which PLATE_STARTED clears for the duration of the slice. SLICE_DONE/PLATE_DONE then overwrote stale from the configEpoch comparison, and an assignment never touches configSnapshotRef, so it has no epoch to be caught by. The picker stays enabled throughout (SliceCards hides it only for converting/error), and a plate slice is exactly the multi-second window where "wait, that one should be PETG" happens — so the plate finished non-stale, showing the new slot beside G-code sliced with the old one. Both DONE cases now OR in a flag the assignment sets directly. RUN_QUEUE clears stale before re-slicing, so anything surviving into a DONE case arrived during the run — which is what makes the OR safe rather than "always stale", and has its own control test. Bumping configEpoch instead is the obvious fix and the wrong one: configSnapshotRef would sit one behind for the rest of the session and mark every later result stale.
• The config summary never counted panel-defined slots. Its "Material" row split the display scalar, which for UI slots is slot 0's material alone (buildConfig() merges FILAMENT_PRESETS[slots[0]]; the rest live in _passthrough). So the Slice tab read Material: PLA beside a picker offering three, and the row's own (N slots) branch only ever fired for an import whose flattened scalar happened to contain a separator. It reads filamentSlotLabels() now — the count the picker and CONFIG_CHANGED already share.
• A lone value the collapse would corrupt now stays an array. The bridge routes arrays through escape_strings_cstyle(), which quotes any element containing ;; a bare string reaches ConfigOptionStrings::deserialize() unquoted and its unescape_strings_cstyle() splits on every ; and strips leading whitespace. So filament_start_gcode: ["M900 K0.02 ; set K"] arrived chopped in two with only the first fragment ever run — and padHook() already repaired this at two slots while leaving one slot broken. §7's claim that the two shapes are "equivalent once the bridge joins them" was the part that was wrong. The option's type is deliberately not visible here, so the new collapsesCleanly() keys off the value instead: anything the quoting pass would have had to touch keeps the array form, which is never less correct and is the shape the source profile used anyway.
• filamentSlotLabels() no longer promotes display text to a slot count. Its single-slot fallback handed back filamentSlots()'s [;,] split, so a profile carrying a plain "PLA;PETG" offered a Slot 2 that withFilamentSlots() — reading the same declaredSlotCount() — had sized no per-filament vectors for. Clamped to one label rather than teaching declaredSlotCount() the split, since making display text a count is exactly what Multi-material (AMS): filament slots are modelled on a false assumption about filament_type #155 warns against.

Reverting any one of the four fails exactly its own new test and nothing else.

10. Follow-up: the docs that still described the old diagnosis

status.md was updated in §6, but three other places still called real multi-nozzle profiles a known crash risk and attributed that crash to the engine rejecting our single-extruder config — the diagnosis §1 replaces.

• api-reference.md described orc_slice_multi's extruder_ids as "the classic single-nozzle multi-material path, not a multi-nozzle machine". It names a filament slot either way; filament_map is what decides.
• ADR-009 listed the plate scenario as deliberately avoiding a real multi-nozzle nozzle_diameter array. §1 added exactly that scenario, so it joins the list and the scenario × mesh count goes 8 → 10.
• ADR-008 and fetch-orca-profiles.ts both pointed at the status.md section §6 deleted. The generator's comment gives two reasons for stripping _passthrough from the bundled presets, and the second is the resolved crash — only the PlaceholderParser one still stands, so it now says which is which rather than reading as two live blockers.

Comments and docs only; no behaviour change, and mkdocs build --strict passes.

11. Follow-up: the slot removal that renumbers

§6 taught CONFIG_CHANGED to drop an assignment naming a slot the config no longer has. It tested the count, which covers both shapes of "removed the last slot" and neither shape of removing one from the middle.

Slots are positional — index is the identity, for the engine's per-filament vectors and therefore for extruderId too. So removing one from the middle renumbers every slot after it while leaving every id in range:

slots            [PLA, PETG, ABS]     object -> slot 2 (PETG)
remove slot 2 -> [PLA, ABS]           id 2 <= 2, kept
                                      object -> slot 2, which is now ABS

Silent in the way the rest of this PR's bugs were: the item is marked stale like any config change, so it is re-sliced — with the wrong material — and the picker just starts reading Slot 2 · ABS with nothing to say it used to mean PETG. It prints wrong rather than indexing out of bounds, which is why no check downstream caught it.

CONFIG_CHANGED now carries the slot labels rather than the count, and the reducer keeps the previous list. No new plumbing: useSliceQueue already called filamentSlotLabels(config) there and discarded everything but .length.

Both halves of the new condition are load-bearing. A label changing on its own is the user re-picking that slot's material, which is deliberate — the object stays on slot 2 and prints with the new filament. It is a label changing because the list got shorter that means the position now describes something else. Dropping to Auto rather than following the material to its new index is the conservative half: the picker is right beside the item, and a wrong slot is worse than an unset one.

Two of the four new tests are controls a lazier fix would fail — an object on slot 1 of the same removal keeps its assignment, and so does one on slot 2 when slot 2 is merely re-picked at the same length. Reverting the label clause alone fails exactly the one test and nothing else.

Verification

smoke-test.mjs gains the dual-nozzle scenario this PR is about — two objects mapped to different nozzles, asserting both T0 and T1 appear, with a negative control that fails with saw [0] when the slots collapse to one filament. It runs on every future PR, on both engine variants:

[smoke-test] [synthetic icosphere] plate: 2 objects on a real dual-nozzle machine (T0 + T1) ... PASS
[smoke-test] [Voron Design Cube v7] plate: 2 objects on a real dual-nozzle machine (T0 + T1) ... PASS
[smoke-test] all scenarios passed          # build (mt) and build (st)

Against a locally built engine, driving the config the UI actually produces:

scenario	filament_map	flush matrix	result
P1S (1 nozzle) + 2 slots	[1,1]	4 = 1×2²	both filaments used (3595.62 / 3708.34 mm)
imported H2D (2 nozzles) + 2 slots	[1,2]	8 = 2×2²	T0 + T1, both filaments used
H2D dual-extruder plate	—	—	78,346 / 78,435 extrusion moves per nozzle
2 slots at different temps (PLA 220 / TPU 240)	—	—	slot 1 → ; filament: 1 @220 °C, slot 2 → ; filament: 2 @240 °C

114/114 unit tests, 10/10 Playwright e2e, typecheck, lint and production build clean; smoke-test.mjs passed every scenario across repeated runs (it failed 3 until the plate-origin fix). Single-entry arrays still collapse to a plain string wherever that is lossless (see §9), so single-extruder profiles keep their previous shape, and settings saved by an older build still load.

🤖 Generated with Claude Code

[github-actions]

✅ GitHub Pages snapshot: https://Hiosdra.github.io/OrcaWeb/previews/pr-160/

Aktualizowany po każdym pushu do tego PR-a.

[Hiosdra]

Summary

Re-review of the whole PR at 58bd224 — the previous review covered only the engine commit and is now hidden as outdated (its three concerns are all addressed: status.md and the four dangling isMultiExtruderProfile() references are gone, let sv is gone, and CI is green).

The engine half is convincing and, more importantly, is now defended by CI rather than by a paragraph in the PR body. The dual-nozzle scenario in smoke-test.mjs runs on both engine variants and passes:

[smoke-test] [synthetic icosphere] plate: 2 objects on a real dual-nozzle machine (T0 + T1) ... PASS
[smoke-test] [Voron Design Cube v7] plate: 2 objects on a real dual-nozzle machine (T0 + T1) ... PASS
[smoke-test] all scenarios passed          # build (mt) and build (st)

That closes the biggest gap the last review flagged. assertToolChanges() asserting both T0 and T1 is the right assertion — a config that silently collapses to one filament still slices and still passes assertSaneGcode(), so a plain "did it slice?" check would not have caught the regression this PR is about.

Locally on 58bd224: 89/89 unit tests pass, tsc --noEmit clean, biome check reports the same 10 pre-existing infos as master (all in scripts/, none in src/).

Strengths

• json_array_to_config_string() reading the separator from print_config_def instead of mirroring a type table in JS remains the right call — it cannot drift from the vendored engine version.
• set_plate_origin() mirrors the existing set_is_bbl_printer() pattern for the same class of bug, and the comment explains why it was flaky (stack-garbage-dependent, reproduces only for some meshes) — non-obvious from the code alone, and worth keeping.
• CONFIG_CHANGED carrying slotCount is the right place to drop assignments naming a removed slot: it's the only point where the count can actually change, and below two slots the picker is gone so nothing else could clear them. Four focused reducer tests, including the "drops every assignment when back down to one slot" case, which is the non-obvious one.
• Slot 0 reading the resolved config rather than FILAMENT_PRESETS (58bd224) is the correct fix for the #159 interaction, and the test spells out why (_passthrough is spread over the resolved config) rather than just asserting the value.
• padHook() sizing the G-code hooks without blanking them, and nextSlotMaterial() picking the first unused material — both are small, but both are the difference between "works" and "works without quietly degrading something".
• buildPlateExtruderIds() returning undefined when nothing is assigned, so a single-material plate posts a byte-identical SLICE_MULTI message. Good instinct for not churning the common case; same instinct as the single-entry-array collapse in profiles.ts.

Concerns

Three findings, all in withFilamentSlots()/parseOrcaProfileJson() and all on the imported multi-material profile path — i.e. the path declaredSlotCount() was added specifically to serve. Details are in the inline comments; summarised:

1. Slot 0's filament_type is the flattened scalar. An imported dual-material profile produces filamentSlotLabels() → ["PLA,PETG", "PETG"], so the picker reads Slot 1 · PLA,PETG and the engine receives that literal string as slot 1's filament type. Reproduced on this branch.
2. Imported per-slot values are overwritten, not padded. filament_colour → SLOT_COLOURS, filament_diameter → hardcoded 1.75, hot_plate_temp → stock preset, flush_volumes_matrix → uniform 280. Same class as the slot-0 bug 58bd224 just fixed, one level further down the list. Reproduced.
3. [""] now reaches the passthrough where master dropped it, so an imported layer can blank a lower layer's value. Reproduced; impact plausible rather than demonstrated.

(1) and (2) are worth fixing before merge — not because they crash, but because they're silent, and "silent" is exactly what the last two commits of this PR were spent hunting.

Smaller notes, none blocking

• Colours wrap past 8 slots. MAX_FILAMENT_SLOTS caps the UI at SLOT_COLOURS.length, but declaredSlotCount() is uncapped and SLOT_COLOURS[i % length] wraps. A 10-filament import gets two pairs of identically-coloured slots. The engine's count comes from values.size() so it still works, but the picker shows duplicates — and the file's own doc says a slot's colour is what makes it a distinct slot.
• nozzle_temperature_initial_layer / hot_plate_temp_initial_layer are derived from the main temps. Deliberate for a UI-defined slot, but it also discards an imported profile's genuinely different initial-layer values. Same family as (2).
• A single item with a slot assigned now takes a different geometry path. orc_slice_multi arranges via arrange_objects(); orc_slice uses center_object_xy_only(). So the same item can land at a different bed position depending only on whether a slot is picked — the type doc explains why the call changes, but not that placement can move with it. Worth a sentence.
• No e2e coverage for the new UI. data-testid="add-filament-slot" and data-testid="extruder-select" were added but nothing in e2e/ uses them. The reducer and profiles.ts coverage is genuinely good, so this is about the wiring (picker appears only above one slot, assignment survives a re-render) rather than the logic.

Assessment

The engine work is sound and now has the committed regression test it was missing — that was the last review's main ask and it's properly done, negative control and all. The UI half is well-tested for the UI-driven path.

What's left is that the imported multi-material path — newer, and the reason declaredSlotCount() exists — silently replaces values the user imported with derived defaults. Findings 1 and 2 sit in the same function that commit 58bd224 just fixed for slot 0, which suggests the fix stopped one slot short. Both are small changes; I'd want them before merge. Everything else is a note.

🤖 Generated with Claude Code

[Hiosdra]

Summary

Re-review of the whole PR at 98db439. The three threads from the previous round are all fixed and resolved; everything they were about now has a test.

I re-derived the engine claims against the pinned OrcaSlicer source in orca-wasm/orca/ rather than taking the PR body's word for them, and they hold up:

• padHook() is genuinely load-bearing. ConfigOptionVector::get_at() clamps (Config.hpp:624), so the filament_start_gcode reads at GCode.cpp:780/:1063 would not have thrown — but GCode.cpp:3150 uses values.at(initial_non_support_extruder_id) (which does throw std::out_of_range) and :3174 uses a raw values[initial_extruder_id] (out-of-bounds read, worse). The PR body's claim is right, and for a slightly better reason than it gives.
• The plate-origin fix is correctly ordered. set_plate_origin(print) lands after apply() but before validate()/process(); the only pre-process() reader of m_origin is sequential_print_clearance_valid() (Print.cpp:613-1003), reached through validate(). I checked m_plate_index for the same class of bug — it has { 0 } (PrintBase.hpp:558), so there is no third landmine of this shape.
• coPointsGroups and escape_strings_cstyle() both exist in the pinned engine, and reading the separator out of print_config_def instead of mirroring a list on the JS side is the right call — that is the part of this PR that cannot silently drift.
• deploy.yml:150-165 really does keep a package.json that is strictly ahead of the latest tag, so the v0.8.0 bump will tag and deploy as-is.
• The #141 / isMultiExtruderProfile() cleanup is complete — no references left anywhere in the repo, and #141 is already closed.

Local: 99/99 unit tests, typecheck clean, biome clean (the 10 remaining infos are pre-existing unsafe-fix suggestions), 10 e2e collected. CI has e2e / typecheck-build / docs green; build (mt) and build (st) — the ones that actually run the new dual-nozzle smoke scenario — were still pending when I looked.

Findings

Two real ones, both the same shape as the bug §6 and §7 already fixed twice: _passthrough is spread over the resolved config, so anything withFilamentSlots() writes beats what is underneath it. Both are silent — the panel keeps showing the value the engine is not using.

1. filament_diameter reverts to 1.75 mm for any slot the UI names past the first. Confirmed on this branch: an import declaring ["2.85","2.85"] survives as ["2.85","2.85"] with one UI slot, and becomes ["2.85","1.75"] the moment a second slot is added. E values off by (2.85/1.75)² ≈ 2.65×. Inline below.
2. hot_plate_temp_initial_layer is missing from PANEL_EDITED_SLOT_OPTIONS, but toEngineConfig() writes it from the same "Bed temp" field as hot_plate_temp. Typing 60 with an import that declares 80 gives hot_plate_temp: ["60","80"] and hot_plate_temp_initial_layer: ["80","80"] — a single-slot config puts 60 in both. Inline below.

And one cosmetic note on slotColour().

Everything else I went looking for came back clean: filamentSlotLabels() cannot disagree with what withFilamentSlots() sized (both go through declaredSlotCount()), buildPlateExtruderIds() omits the field entirely for an unassigned plate so the old SLICE_MULTI message is byte-identical, CONFIG_CHANGED's slotCount < 2 drop is right (a lone "slot 1" would otherwise pin the plate to the assigned code path with no picker to clear it), and the bridge's extruder_ids[i] > 0 guard matches the 0 = inherit contract the JS side encodes.

Nits

• slicer.cpp:349 — the static free function set_plate_origin(Print&) has the same name as the Print member it wraps. zero_plate_origin() would read better beside set_is_bbl_printer(), and would not make the call site look like it is passing an origin.
• smoke-test.mjs's DUAL_NOZZLE_CONFIG is a hand-written copy of what withFilamentSlots() produces, so it will not catch a drift between the two. Deliberate and documented (same reason as BASE_CONFIG), but worth an assertion in profiles.test.ts that pins the shape withFilamentSlots() emits for a 2-slot / 2-nozzle config against that literal, so the scenario the smoke test proves is the scenario the app actually builds.

[Hiosdra]

Fourth pass, on c398493. Reproduced locally against the branch head: 102/102 unit tests, tsc -b, biome check (10 pre-existing infos, all in scripts/, none from this PR) and the production build are clean, and CI is green on all seven jobs. All six earlier review threads are resolved and outdated — nothing is left open from §6–§8.

The substance holds up, and the §7/§8 rounds closed the interesting ones. Spot-checking the parts that are hard to test:

• json_array_to_config_string() reading the separator out of print_config_def rather than a JS-side table is the right shape — that is the one thing that cannot drift against the engine version the bridge is compiled with. escape_strings_cstyle() quotes empty elements as "", so filament_start_gcode: ["", ""] survives orc_init's if (sv.empty()) continue and still sizes the vector to 2, which is what the smoke test depends on.
• slotColour()'s ramp is now continuous by construction: q - p == chroma, and max - 6·chroma·(t - ½) is identically min + 6·chroma·(⅔ - t), so both joins meet. Channel order (h+⅓, h, h+⅔) is the standard R/G/B with h-⅓ ≡ h+⅔ (mod 1), and hue ∈ [0,1) keeps the single % 1 sufficient. No bug here — the §8 rewrite is correct.
• zero_plate_origin() lands after apply() but before process(), which is where shift_without_plate_offset() is actually read, so the ordering is fine.
• Int32Array.from([0, bytes.length]) matches the bridge's documented [start, len] pair layout for n_files = 1.

Four things below. The first is the same class §5 was about — an assignment that visibly changes nothing — but on the in-flight path rather than the already-sliced one, and it is the only one I would call blocking.

[Hiosdra]

Summary

Fifth pass, on the full PR at 42fdc8f (plus aec46ce, the docs commit this review pushed — see below). The four threads from the previous round are fixed and resolved, each with the test its reply claims.

Reproduced locally against the branch head: 110/110 unit tests, tsc --noEmit clean, biome check exit 0 (10 pre-existing infos, all in scripts/, none from this PR). CI is green on e2e (10/10), typecheck-build and docs; the two engine builds were still running when this was written.

The architecture holds up. _passthrough being spread over the resolved config is the hazard the last four rounds all circled, and it now has a stated priority order in one place (per() / declaredOr() / declaredIfSized()) instead of being rediscovered per option. declaredSlotCount() as the single count both withFilamentSlots() and filamentSlotLabels() read is what makes the picker/vector agreement checkable rather than coincidental.

Checked against a real engine, and clean

Built engine, same bridge as HEAD (only the set_plate_origin → zero_plate_origin rename since). The gap I expected to find and did not:

A dual-nozzle machine profile imported while the panel still has one filament slot. withFilamentSlots() returns at n < 2 and sizes nothing, so nozzle_diameter is length 2 while every per-filament vector stays at the engine's length-1 default — the exact "length 2 with length-1 companions" shape §1 says died in Brim.cpp. No test covers it, and DUAL_NOZZLE_CONFIG always carries both.

[A] dual nozzle_diameter, single filament — orc_slice ......................... OK (664603 bytes)
[B] dual nozzle_diameter, single filament — orc_slice_multi (2 objs) .......... OK (1305012 bytes)
[C] control: single nozzle, single filament — orc_slice ....................... OK (663497 bytes)

It slices. The engine tolerates a short companion vector where it does not tolerate a fused one, which is a sharper statement of §1 than "the arrays must agree" — worth knowing, not worth a fix.

Two findings

1. Slot 0 mixes the import's filament_type with the UI material's temperatures — profiles.ts:204. A slot announced to the engine as PLA and extruded at 270 °C. Silent; the panel and the picker each show real state and disagree. Narrow trigger (an import declaring per-slot types but not per-slot temperatures), and the fix is a policy choice between two consistent behaviours, so it is written up rather than pushed.
2. Removing a slot from the middle re-points assignments at a different material — useSliceQueue.ts:267. Same family as the out-of-range case already handled, but every id stays in range so nothing drops it. Prints the wrong filament rather than indexing out of bounds.

One note, no action needed

With an import declaring more filaments than the panel has slots, "Remove filament slot" reduces the Settings list but not the Slice tab's picker — n = max(ui.length, declaredSlotCount(config)) keeps the import's count. Correct (the profile really does declare those filaments) and documented in withFilamentSlots(), but the button reads as a no-op from the Slice tab. Only reachable via an import, so it is a wording problem at most.

Pushed: aec46ce

status.md was updated in §6; three other places were not, and still described real multi-nozzle profiles as a known crash risk caused by the engine rejecting our single-extruder config — the diagnosis §1 replaces. api-reference.md, ADR-009 (which also gains the new dual-nozzle scenario and the corrected 8 → 10 count), ADR-008, and fetch-orca-profiles.ts, whose second reason for stripping _passthrough from the bundled presets is the resolved crash. Comments and docs only; docs CI is green on it. Written up as §10 in the description.

Verdict

Approve once finding 1 is settled — it is the only one that can spoil a print, and it needs a decision rather than a patch. Finding 2 can follow separately.