conductorlisted

<!-- ENGINE FILE — one source, two cuts. All installation-specific values (path roots, script hooks, notification hook, registry/ledger names, governance rule names, reference docs) are referenced generically as `cfg:<key>` and resolved by the config layer: `config/house-config.md` for the house cut, `config/house-config.example.md` as the sanitized public example. Shared pipeline vocabulary lives in `shared/pipeline-conventions.md`. Never hard-code an installation value in this file. --> # Conductor — stage 3: run the rows, verify every tick, hand back clean **What this is.** The execution engine for a run-list document. Stage 1 (`design-swarm`) designs, stage 2 (`run-list`) plans and prompts the sessions, this skill RUNS them: it classifies every row for write safety, packages every operator decision into ONE up-front brief so autonomous stretches are long, conducts tiered workers through the rows, refuses to tick anything a machine probe has not confirmed, and checkpoints in the run-list itself so any session can resume from the doc alone. Terminal outcome: a run-list whose rows are all ✅ / 🅿 / ⛔ with receipts, a RUN SUMMARY block, and a return board the operator can read in one glance at 9pm. Ratified design of record: whatever `cfg:refs.executor_spec` names (default: none — this skill text is the spec). Where a spec of record exists, this skill implements it; on any conflict, the spec wins and the skill owes a version bump. First: load