test(service-automation): pin that a node failing mid-resume strands the run (#13807 step 1 measurement)

[claude]

Part of #13807 — step 1 only (the measurement slice). No repair is included, deliberately.

The card's step 1 asks one question: does any workflow node failing mid-resume strand the run, or is stranded specific to the approval resume path? The card is explicit that the generalisation was a hypothesis, not its premise. This PR carries the instrument that answers it; the full written answer, with all four deliverables, is posted as a comment on #13807.

Verdict: general to the workflow engine, not approval-path-specific

AutomationEngine.resumeInternal consumes the suspension before it runs any downstream work:

await this.forgetSuspendedRun(run, 'resumed'); // packages/services/service-automation/src/engine.ts
...
await this.traverseNext(node, flow, variables, context, steps, signal?.branchLabel);

So a downstream node that throws throws with the pause already gone. The catch arm records the run failed and returns; nothing puts the suspension back. The word "stranded" never appears in the engine — it is prose in a plugin-approvals error message wrapped around this engine outcome.

What the new test measures

packages/services/service-automation/src/resume-node-failure-strands-run.test.ts reproduces the strand with zero approvals involvement: a plain pausing node declaring resumeAuthority: 'any' (the deliberate opposite of the approval node's resumeAuthority: 'service'), continued through the generic engine.resume() door — the same door POST /:name/runs/:runId/resume serves — with a downstream node that throws the reporter's own update_record ... not found shape.

Characterization assertions, all passing against main today:

1. the suspension is gone (hasSuspendedRun is false);
2. the run is recorded failed;
3. a second resume answers RUN_NOT_FOUND;
4. cancelRun returns false — a no-op, since it needs a suspended run to consume.

Two reverse controls keep those from being constants. A resume refused before the consumption point (INVALID_SIGNAL) leaves the pause intact and still resumable, so the same probes read true where they read false above. And a clean resume also ends unsuspended — so the strand is the failed status, not merely the missing pause.

These are characterization assertions, not desired behaviour. A repair for #13807 should turn the first test red. That is why it is pinned now: the repair then has to state which of these facts it changed.

Scope

• ⛔ No atomicity fix, no operator escape hatch, no change to the reject door.
• ⛔ /reject still returns 500. Making it green would hide the defect, which the card names explicitly.
• out of scope: [finding] 删除记录后，它的审批单仍留在审批收件箱：pending 与 approved 两种都留，记录引用退化为原始 id #13568 — that card is ruled and dispatch-ready, and nothing here touches it.
• packages/objectql/src/engine.ts was read only, never edited (it is held by another open PR).
• Test-only diff, so no changeset; labelled skip-changeset.

Gates

Re-derived from the actual diff with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, both output sections read whole — 22 path-matched families plus the convention-triggered set for adding a test file.

Union run at 69d9b14f8 (the final commit): 23 families green, including every convention-triggered ratchet — check:engine-double-contract, check:where-matcher, check:cross-package-test-inputs, check:query-options-erasure, check:type-check-coverage, check:test-source-alias, check:published-files.

check:type-check-debt — the ledger entry for @objectstack/service-automation reads errors: 3; tsc --noEmit on the package at 69d9b14f8 measures exactly 3, all three the ledgered TS2341s in nested-region-parity.test.ts, and 0 from the new file. --listFiles confirms the new test is in the tsc program (so this is a measurement, not an exclusion reading).

Two gates returned exit 3 = NOT MEASURED, by their own printed verdict lines, neither a pass nor a red: check-test-completeness.mjs (needs a saved turbo run test log, which CI tees and a local run cannot produce) and check:dual-build-cjs-loads (PREREQUISITE NOT MET — needs a full pnpm build; 49 packages have no dist/). Both are CI's to run.

Vitest: Test Files 1 passed (1) · Tests 3 passed (3).

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 73c84668743991a38d0016767175933138a376d3 → packageMentionDocs.

[claude]

Part of #13807 — step 1 only (the measurement slice). No repair is included, deliberately.

The card's step 1 asks one question: does any workflow node failing mid-resume strand the run, or is stranded specific to the approval resume path? The card is explicit that the generalisation was a hypothesis, not its premise. This PR carries the instrument that answers it; the full written answer, with all four deliverables, is posted as a comment on #13807.

Verdict: general to the workflow engine, not approval-path-specific

AutomationEngine.resumeInternal consumes the suspension before it runs any downstream work:

await this.forgetSuspendedRun(run, 'resumed'); // packages/services/service-automation/src/engine.ts
...
await this.traverseNext(node, flow, variables, context, steps, signal?.branchLabel);

So a downstream node that throws throws with the pause already gone. The catch arm records the run failed and returns; nothing puts the suspension back. The word "stranded" never appears in the engine — it is prose in a plugin-approvals error message wrapped around this engine outcome.

What the new test measures

packages/services/service-automation/src/resume-node-failure-strands-run.test.ts reproduces the strand with zero approvals involvement: a plain pausing node declaring resumeAuthority: 'any' (the deliberate opposite of the approval node's resumeAuthority: 'service'), continued through the generic engine.resume() door — the same door POST /:name/runs/:runId/resume serves — with a downstream node that throws the reporter's own update_record ... not found shape.

Characterization assertions, all passing against main today:

1. the suspension is gone (hasSuspendedRun is false);
2. the run is recorded failed;
3. a second resume answers RUN_NOT_FOUND;
4. cancelRun returns false — a no-op, since it needs a suspended run to consume.

Two reverse controls keep those from being constants. A resume refused before the consumption point (INVALID_SIGNAL) leaves the pause intact and still resumable, so the same probes read true where they read false above. And a clean resume also ends unsuspended — so the strand is the failed status, not merely the missing pause.

These are characterization assertions, not desired behaviour. A repair for #13807 should turn the first test red. That is why it is pinned now: the repair then has to state which of these facts it changed.

Scope

• ⛔ No atomicity fix, no operator escape hatch, no change to the reject door.
• ⛔ /reject still returns 500. Making it green would hide the defect, which the card names explicitly.
• out of scope: [finding] 删除记录后，它的审批单仍留在审批收件箱：pending 与 approved 两种都留，记录引用退化为原始 id #13568 — that card is ruled and dispatch-ready, and nothing here touches it.
• packages/objectql/src/engine.ts was read only, never edited (it is held by another open PR).
• Test-only diff, so no changeset; labelled skip-changeset.

Gates

Re-derived from the actual diff with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, both output sections read whole — 22 path-matched families plus the convention-triggered set for adding a test file.

Union run at 69d9b14f8 (the final commit): 23 families green, including every convention-triggered ratchet — check:engine-double-contract, check:where-matcher, check:cross-package-test-inputs, check:query-options-erasure, check:type-check-coverage, check:test-source-alias, check:published-files.

check:type-check-debt — the ledger entry for @objectstack/service-automation reads errors: 3; tsc --noEmit on the package at 69d9b14f8 measures exactly 3, all three the ledgered TS2341s in nested-region-parity.test.ts, and 0 from the new file. --listFiles confirms the new test is in the tsc program (so this is a measurement, not an exclusion reading).

Two gates returned exit 3 = NOT MEASURED, by their own printed verdict lines, neither a pass nor a red: check-test-completeness.mjs (needs a saved turbo run test log, which CI tees and a local run cannot produce) and check:dual-build-cjs-loads (PREREQUISITE NOT MET — needs a full pnpm build; 49 packages have no dist/). Both are CI's to run.

Vitest: Test Files 1 passed (1) · Tests 3 passed (3).

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 73c84668743991a38d0016767175933138a376d3 → packageMentionDocs.

[claude]

Part of #13807 — step 1 only (the measurement slice). No repair is included, deliberately.

The card's step 1 asks one question: does any workflow node failing mid-resume strand the run, or is stranded specific to the approval resume path? The card is explicit that the generalisation was a hypothesis, not its premise. This PR carries the instrument that answers it; the full written answer, with all four deliverables, is posted as a comment on #13807.

Verdict: general to the workflow engine, not approval-path-specific

AutomationEngine.resumeInternal consumes the suspension before it runs any downstream work:

await this.forgetSuspendedRun(run, 'resumed'); // packages/services/service-automation/src/engine.ts
...
await this.traverseNext(node, flow, variables, context, steps, signal?.branchLabel);

So a downstream node that throws throws with the pause already gone. The catch arm records the run failed and returns; nothing puts the suspension back. The word "stranded" never appears in the engine — it is prose in a plugin-approvals error message wrapped around this engine outcome.

What the new test measures

packages/services/service-automation/src/resume-node-failure-strands-run.test.ts reproduces the strand with zero approvals involvement: a plain pausing node declaring resumeAuthority: 'any' (the deliberate opposite of the approval node's resumeAuthority: 'service'), continued through the generic engine.resume() door — the same door POST /:name/runs/:runId/resume serves — with a downstream node that throws the reporter's own update_record ... not found shape.

Characterization assertions, all passing against main today:

1. the suspension is gone (hasSuspendedRun is false);
2. the run is recorded failed;
3. a second resume answers RUN_NOT_FOUND;
4. cancelRun returns false — a no-op, since it needs a suspended run to consume.

Two reverse controls keep those from being constants. A resume refused before the consumption point (INVALID_SIGNAL) leaves the pause intact and still resumable, so the same probes read true where they read false above. And a clean resume also ends unsuspended — so the strand is the failed status, not merely the missing pause.

These are characterization assertions, not desired behaviour. A repair for #13807 should turn the first test red. That is why it is pinned now: the repair then has to state which of these facts it changed.

Scope

• ⛔ No atomicity fix, no operator escape hatch, no change to the reject door.
• ⛔ /reject still returns 500. Making it green would hide the defect, which the card names explicitly.
• out of scope: [finding] 删除记录后，它的审批单仍留在审批收件箱：pending 与 approved 两种都留，记录引用退化为原始 id #13568 — that card is ruled and dispatch-ready, and nothing here touches it.
• packages/objectql/src/engine.ts was read only, never edited (it is held by another open PR).
• Test-only diff, so no changeset; labelled skip-changeset.

Gates

Re-derived from the actual diff with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, both output sections read whole — 22 path-matched families plus the convention-triggered set for adding a test file.

Union run at 69d9b14f8 (the final commit): 23 families green, including every convention-triggered ratchet — check:engine-double-contract, check:where-matcher, check:cross-package-test-inputs, check:query-options-erasure, check:type-check-coverage, check:test-source-alias, check:published-files.

check:type-check-debt — the ledger entry for @objectstack/service-automation reads errors: 3; tsc --noEmit on the package at 69d9b14f8 measures exactly 3, all three the ledgered TS2341s in nested-region-parity.test.ts, and 0 from the new file. --listFiles confirms the new test is in the tsc program (so this is a measurement, not an exclusion reading).

Two gates returned exit 3 = NOT MEASURED, by their own printed verdict lines, neither a pass nor a red: check-test-completeness.mjs (needs a saved turbo run test log, which CI tees and a local run cannot produce) and check:dual-build-cjs-loads (PREREQUISITE NOT MET — needs a full pnpm build; 49 packages have no dist/). Both are CI's to run.

Vitest: Test Files 1 passed (1) · Tests 3 passed (3).

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 73c84668743991a38d0016767175933138a376d3 → packageMentionDocs.

[claude]

Part of #13807 — step 1 only (the measurement slice). No repair is included, deliberately.

The card's step 1 asks one question: does any workflow node failing mid-resume strand the run, or is stranded specific to the approval resume path? The card is explicit that the generalisation was a hypothesis, not its premise. This PR carries the instrument that answers it; the full written answer, with all four deliverables, is posted as a comment on #13807.

Verdict: general to the workflow engine, not approval-path-specific

AutomationEngine.resumeInternal consumes the suspension before it runs any downstream work:

await this.forgetSuspendedRun(run, 'resumed'); // packages/services/service-automation/src/engine.ts
...
await this.traverseNext(node, flow, variables, context, steps, signal?.branchLabel);

So a downstream node that throws throws with the pause already gone. The catch arm records the run failed and returns; nothing puts the suspension back. The word "stranded" never appears in the engine — it is prose in a plugin-approvals error message wrapped around this engine outcome.

What the new test measures

packages/services/service-automation/src/resume-node-failure-strands-run.test.ts reproduces the strand with zero approvals involvement: a plain pausing node declaring resumeAuthority: 'any' (the deliberate opposite of the approval node's resumeAuthority: 'service'), continued through the generic engine.resume() door — the same door POST /:name/runs/:runId/resume serves — with a downstream node that throws the reporter's own update_record ... not found shape.

Characterization assertions, all passing against main today:

1. the suspension is gone (hasSuspendedRun is false);
2. the run is recorded failed;
3. a second resume answers RUN_NOT_FOUND;
4. cancelRun returns false — a no-op, since it needs a suspended run to consume.

Two reverse controls keep those from being constants. A resume refused before the consumption point (INVALID_SIGNAL) leaves the pause intact and still resumable, so the same probes read true where they read false above. And a clean resume also ends unsuspended — so the strand is the failed status, not merely the missing pause.

These are characterization assertions, not desired behaviour. A repair for #13807 should turn the first test red. That is why it is pinned now: the repair then has to state which of these facts it changed.

Scope

• ⛔ No atomicity fix, no operator escape hatch, no change to the reject door.
• ⛔ /reject still returns 500. Making it green would hide the defect, which the card names explicitly.
• out of scope: [finding] 删除记录后，它的审批单仍留在审批收件箱：pending 与 approved 两种都留，记录引用退化为原始 id #13568 — that card is ruled and dispatch-ready, and nothing here touches it.
• packages/objectql/src/engine.ts was read only, never edited (it is held by another open PR).
• Test-only diff, so no changeset; labelled skip-changeset.

Gates

Re-derived from the actual diff with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, both output sections read whole — 22 path-matched families plus the convention-triggered set for adding a test file.

Union run at 69d9b14f8 (the final commit): 23 families green, including every convention-triggered ratchet — check:engine-double-contract, check:where-matcher, check:cross-package-test-inputs, check:query-options-erasure, check:type-check-coverage, check:test-source-alias, check:published-files.

check:type-check-debt — the ledger entry for @objectstack/service-automation reads errors: 3; tsc --noEmit on the package at 69d9b14f8 measures exactly 3, all three the ledgered TS2341s in nested-region-parity.test.ts, and 0 from the new file. --listFiles confirms the new test is in the tsc program (so this is a measurement, not an exclusion reading).

Two gates returned exit 3 = NOT MEASURED, by their own printed verdict lines, neither a pass nor a red: check-test-completeness.mjs (needs a saved turbo run test log, which CI tees and a local run cannot produce) and check:dual-build-cjs-loads (PREREQUISITE NOT MET — needs a full pnpm build; 49 packages have no dist/). Both are CI's to run.

Vitest: Test Files 1 passed (1) · Tests 3 passed (3).

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 73c84668743991a38d0016767175933138a376d3 → packageMentionDocs.

[claude]

Part of #13807 — step 1 only (the measurement slice). No repair is included, deliberately.

The card's step 1 asks one question: does any workflow node failing mid-resume strand the run, or is stranded specific to the approval resume path? The card is explicit that the generalisation was a hypothesis, not its premise. This PR carries the instrument that answers it; the full written answer, with all four deliverables, is posted as a comment on #13807.

Verdict: general to the workflow engine, not approval-path-specific

AutomationEngine.resumeInternal consumes the suspension before it runs any downstream work:

await this.forgetSuspendedRun(run, 'resumed'); // packages/services/service-automation/src/engine.ts
...
await this.traverseNext(node, flow, variables, context, steps, signal?.branchLabel);

So a downstream node that throws throws with the pause already gone. The catch arm records the run failed and returns; nothing puts the suspension back. The word "stranded" never appears in the engine — it is prose in a plugin-approvals error message wrapped around this engine outcome.

What the new test measures

packages/services/service-automation/src/resume-node-failure-strands-run.test.ts reproduces the strand with zero approvals involvement: a plain pausing node declaring resumeAuthority: 'any' (the deliberate opposite of the approval node's resumeAuthority: 'service'), continued through the generic engine.resume() door — the same door POST /:name/runs/:runId/resume serves — with a downstream node that throws the reporter's own update_record ... not found shape.

Characterization assertions, all passing against main today:

1. the suspension is gone (hasSuspendedRun is false);
2. the run is recorded failed;
3. a second resume answers RUN_NOT_FOUND;
4. cancelRun returns false — a no-op, since it needs a suspended run to consume.

Two reverse controls keep those from being constants. A resume refused before the consumption point (INVALID_SIGNAL) leaves the pause intact and still resumable, so the same probes read true where they read false above. And a clean resume also ends unsuspended — so the strand is the failed status, not merely the missing pause.

These are characterization assertions, not desired behaviour. A repair for #13807 should turn the first test red. That is why it is pinned now: the repair then has to state which of these facts it changed.

Scope

• ⛔ No atomicity fix, no operator escape hatch, no change to the reject door.
• ⛔ /reject still returns 500. Making it green would hide the defect, which the card names explicitly.
• out of scope: [finding] 删除记录后，它的审批单仍留在审批收件箱：pending 与 approved 两种都留，记录引用退化为原始 id #13568 — that card is ruled and dispatch-ready, and nothing here touches it.
• packages/objectql/src/engine.ts was read only, never edited (it is held by another open PR).
• Test-only diff, so no changeset; labelled skip-changeset.

Gates

Re-derived from the actual diff with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, both output sections read whole — 22 path-matched families plus the convention-triggered set for adding a test file.

Union run at 69d9b14f8 (the final commit): 23 families green, including every convention-triggered ratchet — check:engine-double-contract, check:where-matcher, check:cross-package-test-inputs, check:query-options-erasure, check:type-check-coverage, check:test-source-alias, check:published-files.

check:type-check-debt — the ledger entry for @objectstack/service-automation reads errors: 3; tsc --noEmit on the package at 69d9b14f8 measures exactly 3, all three the ledgered TS2341s in nested-region-parity.test.ts, and 0 from the new file. --listFiles confirms the new test is in the tsc program (so this is a measurement, not an exclusion reading).

Two gates returned exit 3 = NOT MEASURED, by their own printed verdict lines, neither a pass nor a red: check-test-completeness.mjs (needs a saved turbo run test log, which CI tees and a local run cannot produce) and check:dual-build-cjs-loads (PREREQUISITE NOT MET — needs a full pnpm build; 49 packages have no dist/). Both are CI's to run.

Vitest: Test Files 1 passed (1) · Tests 3 passed (3).

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 73c84668743991a38d0016767175933138a376d3 → packageMentionDocs.

[claude]

Part of #13807 — step 1 only (the measurement slice). No repair is included, deliberately.

The card's step 1 asks one question: does any workflow node failing mid-resume strand the run, or is stranded specific to the approval resume path? The card is explicit that the generalisation was a hypothesis, not its premise. This PR carries the instrument that answers it; the full written answer, with all four deliverables, is posted as a comment on #13807.

Verdict: general to the workflow engine, not approval-path-specific

AutomationEngine.resumeInternal consumes the suspension before it runs any downstream work:

await this.forgetSuspendedRun(run, 'resumed'); // packages/services/service-automation/src/engine.ts
...
await this.traverseNext(node, flow, variables, context, steps, signal?.branchLabel);

So a downstream node that throws throws with the pause already gone. The catch arm records the run failed and returns; nothing puts the suspension back. The word "stranded" never appears in the engine — it is prose in a plugin-approvals error message wrapped around this engine outcome.

What the new test measures

packages/services/service-automation/src/resume-node-failure-strands-run.test.ts reproduces the strand with zero approvals involvement: a plain pausing node declaring resumeAuthority: 'any' (the deliberate opposite of the approval node's resumeAuthority: 'service'), continued through the generic engine.resume() door — the same door POST /:name/runs/:runId/resume serves — with a downstream node that throws the reporter's own update_record ... not found shape.

Characterization assertions, all passing against main today:

1. the suspension is gone (hasSuspendedRun is false);
2. the run is recorded failed;
3. a second resume answers RUN_NOT_FOUND;
4. cancelRun returns false — a no-op, since it needs a suspended run to consume.

Two reverse controls keep those from being constants. A resume refused before the consumption point (INVALID_SIGNAL) leaves the pause intact and still resumable, so the same probes read true where they read false above. And a clean resume also ends unsuspended — so the strand is the failed status, not merely the missing pause.

These are characterization assertions, not desired behaviour. A repair for #13807 should turn the first test red. That is why it is pinned now: the repair then has to state which of these facts it changed.

Scope

• ⛔ No atomicity fix, no operator escape hatch, no change to the reject door.
• ⛔ /reject still returns 500. Making it green would hide the defect, which the card names explicitly.
• out of scope: [finding] 删除记录后，它的审批单仍留在审批收件箱：pending 与 approved 两种都留，记录引用退化为原始 id #13568 — that card is ruled and dispatch-ready, and nothing here touches it.
• packages/objectql/src/engine.ts was read only, never edited (it is held by another open PR).
• Test-only diff, so no changeset; labelled skip-changeset.

Gates

Re-derived from the actual diff with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, both output sections read whole — 22 path-matched families plus the convention-triggered set for adding a test file.

Union run at 69d9b14f8 (the final commit): 23 families green, including every convention-triggered ratchet — check:engine-double-contract, check:where-matcher, check:cross-package-test-inputs, check:query-options-erasure, check:type-check-coverage, check:test-source-alias, check:published-files.

check:type-check-debt — the ledger entry for @objectstack/service-automation reads errors: 3; tsc --noEmit on the package at 69d9b14f8 measures exactly 3, all three the ledgered TS2341s in nested-region-parity.test.ts, and 0 from the new file. --listFiles confirms the new test is in the tsc program (so this is a measurement, not an exclusion reading).

Two gates returned exit 3 = NOT MEASURED, by their own printed verdict lines, neither a pass nor a red: check-test-completeness.mjs (needs a saved turbo run test log, which CI tees and a local run cannot produce) and check:dual-build-cjs-loads (PREREQUISITE NOT MET — needs a full pnpm build; 49 packages have no dist/). Both are CI's to run.

Vitest: Test Files 1 passed (1) · Tests 3 passed (3).

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 73c84668743991a38d0016767175933138a376d3 → packageMentionDocs.

[claude]

Part of #13807 — step 1 only (the measurement slice). No repair is included, deliberately.

The card's step 1 asks one question: does any workflow node failing mid-resume strand the run, or is stranded specific to the approval resume path? The card is explicit that the generalisation was a hypothesis, not its premise. This PR carries the instrument that answers it; the full written answer, with all four deliverables, is posted as a comment on #13807.

Verdict: general to the workflow engine, not approval-path-specific

AutomationEngine.resumeInternal consumes the suspension before it runs any downstream work:

await this.forgetSuspendedRun(run, 'resumed'); // packages/services/service-automation/src/engine.ts
...
await this.traverseNext(node, flow, variables, context, steps, signal?.branchLabel);

So a downstream node that throws throws with the pause already gone. The catch arm records the run failed and returns; nothing puts the suspension back. The word "stranded" never appears in the engine — it is prose in a plugin-approvals error message wrapped around this engine outcome.

What the new test measures

packages/services/service-automation/src/resume-node-failure-strands-run.test.ts reproduces the strand with zero approvals involvement: a plain pausing node declaring resumeAuthority: 'any' (the deliberate opposite of the approval node's resumeAuthority: 'service'), continued through the generic engine.resume() door — the same door POST /:name/runs/:runId/resume serves — with a downstream node that throws the reporter's own update_record ... not found shape.

Characterization assertions, all passing against main today:

1. the suspension is gone (hasSuspendedRun is false);
2. the run is recorded failed;
3. a second resume answers RUN_NOT_FOUND;
4. cancelRun returns false — a no-op, since it needs a suspended run to consume.

Two reverse controls keep those from being constants. A resume refused before the consumption point (INVALID_SIGNAL) leaves the pause intact and still resumable, so the same probes read true where they read false above. And a clean resume also ends unsuspended — so the strand is the failed status, not merely the missing pause.

These are characterization assertions, not desired behaviour. A repair for #13807 should turn the first test red. That is why it is pinned now: the repair then has to state which of these facts it changed.

Scope

• ⛔ No atomicity fix, no operator escape hatch, no change to the reject door.
• ⛔ /reject still returns 500. Making it green would hide the defect, which the card names explicitly.
• out of scope: [finding] 删除记录后，它的审批单仍留在审批收件箱：pending 与 approved 两种都留，记录引用退化为原始 id #13568 — that card is ruled and dispatch-ready, and nothing here touches it.
• packages/objectql/src/engine.ts was read only, never edited (it is held by another open PR).
• Test-only diff, so no changeset; labelled skip-changeset.

Gates

Re-derived from the actual diff with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, both output sections read whole — 22 path-matched families plus the convention-triggered set for adding a test file.

Union run at 69d9b14f8 (the final commit): 23 families green, including every convention-triggered ratchet — check:engine-double-contract, check:where-matcher, check:cross-package-test-inputs, check:query-options-erasure, check:type-check-coverage, check:test-source-alias, check:published-files.

check:type-check-debt — the ledger entry for @objectstack/service-automation reads errors: 3; tsc --noEmit on the package at 69d9b14f8 measures exactly 3, all three the ledgered TS2341s in nested-region-parity.test.ts, and 0 from the new file. --listFiles confirms the new test is in the tsc program (so this is a measurement, not an exclusion reading).

Two gates returned exit 3 = NOT MEASURED, by their own printed verdict lines, neither a pass nor a red: check-test-completeness.mjs (needs a saved turbo run test log, which CI tees and a local run cannot produce) and check:dual-build-cjs-loads (PREREQUISITE NOT MET — needs a full pnpm build; 49 packages have no dist/). Both are CI's to run.

Vitest: Test Files 1 passed (1) · Tests 3 passed (3).

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 73c84668743991a38d0016767175933138a376d3 → packageMentionDocs.

[claude]

Part of #13807 — step 1 only (the measurement slice). No repair is included, deliberately.

The card's step 1 asks one question: does any workflow node failing mid-resume strand the run, or is stranded specific to the approval resume path? The card is explicit that the generalisation was a hypothesis, not its premise. This PR carries the instrument that answers it; the full written answer, with all four deliverables, is posted as a comment on #13807.

Verdict: general to the workflow engine, not approval-path-specific

AutomationEngine.resumeInternal consumes the suspension before it runs any downstream work:

await this.forgetSuspendedRun(run, 'resumed'); // packages/services/service-automation/src/engine.ts
...
await this.traverseNext(node, flow, variables, context, steps, signal?.branchLabel);

So a downstream node that throws throws with the pause already gone. The catch arm records the run failed and returns; nothing puts the suspension back. The word "stranded" never appears in the engine — it is prose in a plugin-approvals error message wrapped around this engine outcome.

What the new test measures

packages/services/service-automation/src/resume-node-failure-strands-run.test.ts reproduces the strand with zero approvals involvement: a plain pausing node declaring resumeAuthority: 'any' (the deliberate opposite of the approval node's resumeAuthority: 'service'), continued through the generic engine.resume() door — the same door POST /:name/runs/:runId/resume serves — with a downstream node that throws the reporter's own update_record ... not found shape.

Characterization assertions, all passing against main today:

1. the suspension is gone (hasSuspendedRun is false);
2. the run is recorded failed;
3. a second resume answers RUN_NOT_FOUND;
4. cancelRun returns false — a no-op, since it needs a suspended run to consume.

Two reverse controls keep those from being constants. A resume refused before the consumption point (INVALID_SIGNAL) leaves the pause intact and still resumable, so the same probes read true where they read false above. And a clean resume also ends unsuspended — so the strand is the failed status, not merely the missing pause.

These are characterization assertions, not desired behaviour. A repair for #13807 should turn the first test red. That is why it is pinned now: the repair then has to state which of these facts it changed.

Scope

• ⛔ No atomicity fix, no operator escape hatch, no change to the reject door.
• ⛔ /reject still returns 500. Making it green would hide the defect, which the card names explicitly.
• out of scope: [finding] 删除记录后，它的审批单仍留在审批收件箱：pending 与 approved 两种都留，记录引用退化为原始 id #13568 — that card is ruled and dispatch-ready, and nothing here touches it.
• packages/objectql/src/engine.ts was read only, never edited (it is held by another open PR).
• Test-only diff, so no changeset; labelled skip-changeset.

Gates

Re-derived from the actual diff with node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack, both output sections read whole — 22 path-matched families plus the convention-triggered set for adding a test file.

Union run at 69d9b14f8 (the final commit): 23 families green, including every convention-triggered ratchet — check:engine-double-contract, check:where-matcher, check:cross-package-test-inputs, check:query-options-erasure, check:type-check-coverage, check:test-source-alias, check:published-files.

check:type-check-debt — the ledger entry for @objectstack/service-automation reads errors: 3; tsc --noEmit on the package at 69d9b14f8 measures exactly 3, all three the ledgered TS2341s in nested-region-parity.test.ts, and 0 from the new file. --listFiles confirms the new test is in the tsc program (so this is a measurement, not an exclusion reading).

Two gates returned exit 3 = NOT MEASURED, by their own printed verdict lines, neither a pass nor a red: check-test-completeness.mjs (needs a saved turbo run test log, which CI tees and a local run cannot produce) and check:dual-build-cjs-loads (PREREQUISITE NOT MET — needs a full pnpm build; 49 packages have no dist/). Both are CI's to run.

Vitest: Test Files 1 passed (1) · Tests 3 passed (3).

Generated by Claude Code

---

Generated by Claude Code

[github-actions]

📓 Docs Drift Check

Nothing in this diff resolved to a documentable surface (no symbol, route or SDK anchor derived from 0 changed package(s)), so this run has no opinion about the docs.

What this run could not see

• a page that states a rule by its inputs shares no identifier with the emitter that implements the rule, so an emitter-only diff cannot list it — not on this run and not on any run. Measured on fix(driver-sql): emit varchar(maxLength) for a text field a declared index keys on #11430: content/docs/protocol/objectql/types.mdx documents the text-family column mapping by the ObjectQL type names it maps FROM (text / textarea / html) while the diff changed createColumn; it went unlisted, and it was the page that diff falsified, in four places. No shared token exists to detect this on, so a rule your change carries has to be re-read by hand in the pages that restate it.

Coarse fallback — 0 page(s) merely mention a changed package (the pre-#9192 predicate, kept for the deliberately-wide backstop): node scripts/docs-audit/affected-docs.mjs --json 73c84668743991a38d0016767175933138a376d3 → packageMentionDocs.