refactor(conductor): delete the dead dev-job step coupling (epic #470 C5)

[Weegy]

First change in epic #470 that moves the decoupling count down: 3,303 → 3,167 (−136). Every prior change either added or held it flat.

What this is not

The Conductor is a live feature — 31 files, ~6,200 LOC backend, 23 UI files, 7 own migrations, its own spec. Workflow runs, steps, human approval gates, templates, the Designer canvas: all untouched. All 204 conductor tests pass.

What was dead

One step type inside it. dev.job was meant to let a workflow launch a Dev Platform job, park the run, and resume on its terminal outcome. It was built and never wired:

• conductor/index.ts constructs the executor with no devJob dep, so the dispatch branch was permanently false — and git log -S 'devJob' on that file returns nothing, so it was never wired in any commit
• the launch half had no implementation at all: createConductorJob, setAwaitId, getAwaitId existed only as interface members, and dev_jobs.conductor_await_id was never selected or written
• DevJobOutcomeEmitter.emit() had no caller in src/
• nothing scheduled the reconciliation sweep
• no bundled template referenced dev.job, and listActions never included it — so the step could not even pass validation

That last point matters: nobody could have authored this step.

Removed

File
conductor/devJobStepEffect.ts	deleted, 122 LOC
devplatform/devJobConductorBridge.ts	deleted, 113 LOC
test/conductorDevJobStep.test.ts	deleted, 358 LOC
conductor/runExecutor.ts	31 → 0 refs
conductor/awaitStore.ts	6 → 0 refs
conductor/routes.ts	1 → 0 refs

Kept: migration 0024's conductor_await_id column. Migrations are forward-only here and dropping a column is the one irreversible act in this change — it is marked orphaned instead.

The subtle part

awaitStore's human-inbox query excluded channel_type = 'dev_job'. That predicate is now gone rather than genericised: after the delete, openHumanAwait is the sole writer of conductor_awaits, so a filter whose complement no code path can populate asserts an invariant in the wrong place. A channel allow/denylist would also fail open for a future await kind that forgot to register itself.

On a database that somehow held such a row, it becomes visible in the operator inbox and a resolve attempt returns 403 (the holder gate compares against dev_job:<id>, which no user id can equal). With the resolver deleted, such a run is permanently parked — the await row is the only evidence of it, so surfacing it is the better outcome than hiding it.

A review catch worth naming

The compensating test added for the removed predicate could not detect that predicate being restored. Its fixtures were teams/telegram/web, so re-adding AND channel_type <> 'dev_job' left it green — it did not cover the exact regression it existed for. Fixed with a dev_job fixture row and mutation-checked: with the predicate restored 1 fail, without it 3 pass.

Also

Propagates the decision into the specs, which still described the step as a capability the extraction must carry and H2 as a registry to build. H2 needed no mechanism after all — the coupling was dead, so deleting it was the whole fix. That removes one of the three "hard couplings" from the plan.

Test plan

• Middleware suite: 5,197 pass. Two intermittent failures are unrelated and load-sensitive (a 401 session test and one that measures wallclock speedup of parallel dispatch); neither reproduces consistently and neither is in conductor
• All 204 conductor tests pass, including runs, awaits, quorum/timeout, reminders and the resume worker
• Typecheck clean; ratchet 3,303 → 3,167, no zone rose
• Every removed symbol grepped across middleware/, web-ui/, scripts/, .github/ — the exported DevJobPortUnavailableError included — with no consumer outside the delete list

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}