[johnnyelwailer]

Problem

From a real incident (thread fbdb583b, run 1b57cb41), three independent
orchestration-launch defects surfaced:

1. Unparseable workflow files were accepted at launch and died asynchronously
   at rehydration with an opaque SyntaxError, no actionable feedback.
2. Self-heal (source replacement / corrected-source resume) was silently
   disabled for path-launched runs — the gate was keyed on a specific
   snapshot path that only inline-source launches produced.
3. A terminal failure notice posted mid-turn was buried — nothing re-surfaced
   the failure after the launch turn ended, so the user saw 40+ minutes of silence.

Root-cause audit showed all three are longstanding gaps, not fresh regressions:
the path-based canReplaceEphemeralSource gate dates to deea85942, and the
precheck (fc8316f96) only ever covered inline source.

Fixes

Fix 1 — Precheck covers workflowPath. t3team-workflowRunPathAuthorize.ts
now reads + prechecks both workspace-local (case 2) and pack (case 3) workflow
files before launch. t3team-workflowSourcePrecheck.ts adds a V8 compile gate
(new NodeVM.Script(body)) — ts.transpileModule does not throw on syntax
errors, only the V8 compiler does. An unparseable file now fails the launch
synchronously with the full actionable manual attached.

Fix 2 — Snapshot for ephemeral path-launched runs. Workspace-local
workflowPath runs are snapshotted to .t3team-runs/<runId>/workflow.ts via a
new persistEphemeralWorkflowSource helper. Both inline-source and workspace-path
launches now produce the snapshot, so canReplaceEphemeralSource (keyed on the
snapshot path) is satisfied for both — repair and corrected-source resume work for
path-launched runs. Pack-recipe paths are prechecked but not snapshotted
(managed/bundled code, in-place execution).

Fix 3 — Terminal failure resurfacing. New
t3team-workflowTerminalResurface.ts: when the launch thread transitions
busy→idle, the most recent failed run (≤30 min window) is re-posted under the
stable t3team-wf-result:<runId> message id. Idempotent, one per run per uptime,
no new agent turn.

Fix 4 — Manual clarification. t3team-workflowManual.ts states that
agent() / askAgent() / askUser() suspension is durable control flow, never
an error to catch or retry.

Files

File	Change
t3team-toolBrokerWorkflowRunTools.ts	wire precheck + snapshot into launch path
t3team-workflowRunPathAuthorize.ts	read + precheck + snapshot workflowPath (−48/+128)
t3team-workflowSourcePrecheck.ts	V8 compile gate (+57)
t3team-workflowTerminalResurface.ts	new — busy→idle resurfer (+119)
t3team-workflowTerminalResurface.test.ts	new — resurfer tests (+155)
t3team-workflowCompletionMessage.ts	terminal-notice upsert (+20)
t3team-workflowEngineReactor.ts	hook resurfer into session events (+25)
t3team-workflowManual.ts	durable-suspension guidance (+12)
t3team-workflowRunPathAuthorize.test.ts	precheck + snapshot coverage (+99)
t3team-workflowSourcePrecheck.test.ts	compile-gate coverage (+29)

Verification

• 49/49 tests green across 8 test files (path-authorize, source-precheck,
  terminal-resurface, completion).
• Lint / format / typecheck clean on all touched files. 4 pre-existing
  typecheck errors in untouched files (server.ts, t3team-distribution.ts)
  exist at main HEAD independent of this change.
• Additive guard (node t3team-additive-guard.mjs) green.
• Live QA on a parallel Nexi Work instance (port 4480, Nexplore provider):
  all four fixes confirmed present in the built server-v9hqUzN7.mjs bundle;
  deterministic harness against real probe files confirmed Fix 1 (sync reject),
  Fix 2 (snapshot), Fix 3 (boundary).

[github-actions]

Thread transfer impact

⚠️ The latest CI run did not produce a thread transfer result for 9988014.

This comment will update automatically after the next completed run.