{
  "findings": [
    {
      "title": "Race every custom command against shutdown aborts",
      "body": "When a custom `runSptCommand` starts before `session_shutdown`, this condition is false, so `runCommand` never installs the local abort/timeout race. A deterministic sequence is a pending bind, state update, or outcome whose custom runner ignores `options.signal`, followed by `session_shutdown`: `enterShutdownMode()` aborts the controller, but the command remains pending; the 1800ms handler returns while `teardownPromise` stays hung, `session-end` is never attempted, and the controller remains retained in `activeCommandControllers`. Install the abort race for every custom command, not only commands created after shutdown mode begins; shutdown can then reject already-active custom work immediately while still using the shutdown timeout for newly started teardown commands.",
      "priority": 2,
      "confidence": 0.99,
      "file_path": "adapter/strings/omp-spt.mjs",
      "line_start": 478,
      "line_end": 478
    },
    {
      "title": "Do not resend custody after an in-flight outcome succeeds",
      "body": "During `session_shutdown`, if `current.outcomePromise` is still pending, `settlePendingItem` awaits it but then unconditionally clears it and calls `settleItem` again. With a custom outcome sender that ignores the shutdown abort and then resolves, the first send marks `item.settled = true`; these lines erase the completed promise and issue a second terminal send containing the shutdown failure, so the peer receives both the real answer and a contradictory failure. After awaiting the existing promise, return immediately when `item.settled` is true; clear and replace the promise only when the in-flight send rejected.",
      "priority": 2,
      "confidence": 0.99,
      "file_path": "adapter/strings/omp-spt.mjs",
      "line_start": 686,
      "line_end": 692
    },
    {
      "title": "Suppress fail-closed escalation once shutdown is already stopping",
      "body": "If `session_shutdown` starts while `completeTurn` is awaiting an outcome, `enterShutdownMode()` aborts that send; its rejection enters this catch even though `teardownSession` has already set `stopping = true`. `failClosed()` then joins the lifecycle teardown and calls `runtimeCtx.shutdown()` afterward, turning an ordinary host shutdown into a recursive shutdown request. The same race exists for the subsequent idle-state catch. Check `stopping` in both catches and return when lifecycle shutdown already owns cleanup; only invoke `failClosed` for errors that occur while the endpoint is otherwise live.",
      "priority": 2,
      "confidence": 0.98,
      "file_path": "adapter/strings/omp-spt.mjs",
      "line_start": 1061,
      "line_end": 1065
    },
    {
      "title": "Avoid fail-closed recursion from a shutdown-time dispatch rejection",
      "body": "A shutdown that aborts `dispatchNext` while its busy-state command is pending enters `rejectItem`; if the shutdown-time failure outcome also rejects, this catch calls `failClosed` even though `stopping` is already true. `failClosed` joins the existing teardown and then invokes `runtimeCtx.shutdown()`, so a normal `session_shutdown` recursively requests another host shutdown. When `stopping` is true, return from this catch and let the already-running `failPending` path log/retry the bounded custody failure; reserve `failClosed` for live-session failures.",
      "priority": 2,
      "confidence": 0.97,
      "file_path": "adapter/strings/omp-spt.mjs",
      "line_start": 805,
      "line_end": 807
    }
  ],
  "overall_correctness": "incorrect",
  "explanation": "The final implementation does not satisfy the shutdown contract. Commands started through a custom runner before shutdown can outlive the hard budget and block session-end, an in-flight custody outcome can be sent twice, and outcome/dispatch errors caused by lifecycle shutdown can incorrectly escalate into recursive `runtimeCtx.shutdown()` calls.",
  "confidence": 0.98
}