[DanielNetzer]

Implements issue #218.

Molecule: mol-218-f691868a576222cda0143715
Formula: forgecell-github-issue
Base: 950c19af80f08f3699965f9afcacdbcf19cbe70e
Delivery: e8602c380573ba362a2ffc6fade18d3f8183a212

Awaiting exact-commit CI and human review. Harness-reported checks are not independent CI evidence. No merge, deployment or issue closure is authorized.

[DanielNetzer]

Delivered through Forgecell end to end. This is the first v1 slice with no hand delivery: Molecule mol-218-f691868a576222cda0143715, preview digest ca0a3e39 bound to tree 3336c3c. Every required check passed on both the candidate tree and the protected regression, including the go test -timeout 20m ./... baseline.

Review: one adversarial pass. It found one correctness MEDIUM: a UI-started run and a UI-started loop could each start a Molecule for the same Issue, because molecule.Run takes no per-Issue lock and a fresh intake has no ledger yet. That was fixed in the slice through a reviewed amend (plan revision 2). startRun refuses while the UI loop runs, and startLoop refuses while a UI run job runs, with both checks and registrations under the loop mutex. Lock order is always loop then jobs, so nothing can deadlock. New deterministic tests cover both orders. The verification pass on the fix is clean.

LOWs (not fixed):

• A loop started from the UI auto-approves a scope gate only where the Formula declares a policy that approves that exact plan, the same as the CLI loop. The UI itself never approves a gate. The UI copy could say this explicitly.
• After the 30 s stop grace, stopWork returns while engine goroutines may still be finishing. Exit relies on the engine killing its process groups on cancel.
• Engine-level gap (CLI too): molecule.Run doesn't take the per-Issue lock, so a CLI run beside a CLI or UI loop can still double-start. Post-v1 hardening, noted for Hardening 2: closed-but-unamendable verification failure path; explain or allow legitimate launcher rebinds #217.