Ruled gates: prompt for ratify_gate instead of remediation; unknown-ruling false flag on a valid ruling; struck step reopened on relaunch

[HenryLach]

Report

penster batch 20260911T234647, field report on #627, items D, F (unknown-ruling half), G. Three smaller defects around rulings, grouped because they share the "runtime should recognise a ruled gate" theme:

D — ruling-closed gates still trigger remediation + a fresh review

When the supervisor closes a REVISE-capped gate by ruling, the latest on-disk verdict stays REVISE; at .DONE the finalize sweep spawns a "review remediation" iteration and a fresh review (4 ledger reviews on TP-2103/TP-2054, ~1 iteration + 1 review each). ratify_gate (TP-198) is exactly the mechanism — but nothing prompts for it. Fix: the unresolved-verdict refusal alert and the remediation-spawn STATUS line should, when the task has a released hold whose ruling post-dates the REVISE file, name ratify_gate(taskId, gate, rulingId, …) as the remedy instead of "have the worker address the findings". Consider refusing to spawn remediation for a gate that already has a released ruling and alerting for ratification instead.

F — unknown-ruling flagged on a valid released ruling

The trailer cited a ruling id that is present in the agent's ack/ dir and has hold-released:<id> in the engine log, yet validateRulingCitations flagged unknown-ruling. Needs the commit (git show <sha>) and the hold record from batch-state.json to diagnose. Suspects: the citation used the escalation id rather than the ruling id; or the hold binding the unit was a segment hold and holdsForUnit scope didn't match the scanning unit; or the scan ran with a holdStore.list() snapshot taken before the release persisted. (The prose-claim half of F is fixed in #643.)

G — relaunch reset a struck step to open

After a split ruling on TP-1920, the relaunched worker's STATUS showed a previously struck step re-opened; the worker reverted it. Suspect: the lane-runner's updateStepStatus(firstStep, "in-progress") on the first remaining step, where "struck" (a ruling removed the step from scope) is not a status the parser recognises, so the step still counts as remaining. Fix: recognise a struck/waived marker (e.g. **Status:** ⛔ Struck (ruling <id>)) in parseStatusMd and exclude such steps from remainingSteps and from the finalize all-steps-complete check — the same predicate authorizeCompletion uses.

Acceptance

• D: fixture with REVISE latest + released later ruling → refusal alert names ratify_gate; no remediation spawn.
• F: root cause identified from penster artifacts; regression added.
• G: struck-step fixture → not re-opened on relaunch, not counted as incomplete at finalize.