feat: decrypt sealed payloads in the dashboard and CLI

[TooTallNate]

Replaces #3097. That PR was force-closed as "merged" by GitHub when I
force-pushed its base branch to a commit that happened to contain its head —
GitHub concluded it had merged into its base. Its code never reached main.
It cannot be reopened, so this PR carries the identical work. Review history
on #3097 still applies.

Ordering change: this now targets main directly and should land before
#3096, per the review there. #3096 begins emitting sealed (encp) hook payloads
while workflow inspect --decrypt can only build a symmetric key, so merging it
first would leave those payloads showing as ciphertext placeholders. Landing the
reader first closes that window.

To make this PR stand alone, deriveRunPayloadKeys moved here from #3096 — it
is the capability the reader needs, and its own doc says to use it "anywhere a
run reads its own event log", so it belongs on this side regardless.

---

PR 5 of 7. Stacked on #3096; review the stack in order, starting from #3093.

• feat(core): add encp sealed-box encryption primitive #3093 — the encp sealed-box primitive
• feat(core): route sealed envelopes through the serialization layer #3094 — route sealed envelopes through the serialization layer
• feat: publish each run's X25519 public key on the run entity #3095 — publish each run's public key on the run entity
• feat(core): seal hook payloads to the target run's public key #3096 — resumeHook() seals instead of fetching the key ← the payoff
• feat: decrypt sealed payloads in the dashboard and CLI #3097 (this PR) — decrypt sealed payloads in observability tooling
• feat(core): seal forwarded stream writes to the owner's public key #3098 — seal forwarded stream writes
• feat: return the run public key from the capability probe #3099 — start() gets the key from the probe it already awaits

Why this is required, not optional

Once #3096 lands, a hook resumption from another deployment writes a sealed payload into the run's event log. Observability tooling can't open it: hydrateDataWithKey only ever ran AES-GCM. So the dashboard and CLI would render a 🔒 placeholder on data the user is entitled to read and has already supplied the key for — a visible debugging regression on exactly the runs this work speeds up.

What changed

hydrateDataWithKey delegates to the envelope layer, which dispatches on the 4-byte format prefix, instead of unconditionally decrypting with AES-GCM.

All four o11y key-resolution sites now resolve the run's full key capability rather than just its symmetric key:

Site	Path
@workflow/web-shared	hydrateResourceIOAsync
@workflow/web	use-stream-reader (hand-rolled frame decode)
@workflow/cli	--decrypt field hydration
@workflow/cli	--decrypt stream output

Each already had the raw 32 bytes in hand, so this costs one extra key derivation and no additional requests or round trips.

A caller that supplies only a symmetric key still gets the ciphertext placeholder for sealed payloads rather than a decryption error — that key never could have opened them, so surfacing a failure would be misleading.

Browser bundling

The natural import for the new helper is @workflow/core/serialization, but that module graph reaches node:util and node:async_hooks and cannot be bundled for the browser — which is precisely what the @workflow/core/serialization-format entrypoint exists to avoid. I hit this as a build failure and moved the key helpers to a re-export from that browser-safe entrypoint; the two browser consumers import from there, while the CLI keeps the direct import since it runs on Node.

Verified by walking the built import graph: serialization-format.js reaches 6 modules and zero Node built-ins.

Tests

Two new cases assert the o11y path opens a real sealed payload with the derived keypair, and that the same resolved key still opens the run's own symmetric payloads — a run's event log mixes both.

Core suite 1598 passing, web-shared 160, CLI 78. Zero new lint diagnostics (diffed against a stashed baseline).

[changeset-bot]

🦋 Changeset detected

Latest commit: 916bc93

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@workflow/core	Minor
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/cli	Patch
@workflow/builders	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/vitest	Patch
workflow	Minor
@workflow/world-testing	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Jul 28, 2026 12:08am
example-nextjs-workflow-webpack	Building	Preview, Comment	Jul 28, 2026 12:08am
example-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-astro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-express-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-fastify-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-hono-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nestjs-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nitro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nuxt-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-sveltekit-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-tanstack-start-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-vite-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-docs	Ready	Preview, Comment, Open in v0	Jul 28, 2026 12:08am
workflow-swc-playground	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-tarballs	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-web	Ready	Preview, Comment	Jul 28, 2026 12:08am

[github-actions]

📊 Workflow Benchmarks

commit 916bc93 · Tue, 28 Jul 2026 00:26:55 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	228 (-69%) 💚	1407 🔴 (+24%) 🔻	1449 🔴 (+20%) 🔻	1751 🔴 (+28%) 🔻	30
TTFS	stream	273 (-13%)	1428 🔴 (+30%) 🔻	1438 🔴 (+26%) 🔻	1527 🔴 (+30%) 🔻	30
TTFS	hook + stream	572 (-55%) 💚	1694 🔴 (+21%) 🔻	1740 🔴 (+19%) 🔻	1895 🔴 (+16%) 🔻	30
STSO	1020 steps (1-20)	185 (+8.8%)	327 🔴 (+8.3%)	550 🔴 (+56%) 🔻	681 🔴 (+80%) 🔻	19
STSO	1020 steps (101-120)	205 (+4.1%)	298 🔴 (-12%)	473 🔴 (+16%) 🔻	598 🔴 (+20%) 🔻	19
STSO	1020 steps (1001-1020)	473 (-2.1%)	563 🔴 (-1.9%)	669 🔴 (+3.6%)	852 🔴 (+30%) 🔻	19
WO	1020 steps	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	1
SL	stream latency	97 (+4.3%)	196 🔴 (+17%) 🔻	257 🔴 (+9.8%)	592 🔴 (+134%) 🔻	30
SO	stream overhead (text)	126 (-3.8%)	303 🔴 (+4.5%)	400 (+13%)	543 (+29%) 🔻	30
SO	stream overhead (structured)	135 (±0%)	391 🔴 (+50%) 🔻	729 🔴 (+162%) 🔻	5527 🔴 (+1238%) 🔻	30

ℹ️ Metric definitions & methodology

_{Best/P75/P90/P99 deltas compare against the most recent benchmark run on main at the time of this run. 🔻 flags a delta worse than +15%, 💚 one better than −15%.}

_{Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window)}

_{Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost}

_{🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120}

_{All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor (clientStart) right before start(), so the CI runner’s request and its path through api.vercel.com sit outside every measured window. TTFS = in-deployment start() → first step body (turbo uses the in-process fast path, non-turbo the dispatch path), and includes the VQS dispatch hop plus any /flow cold start. STSO/WO are measured between step bodies on the deployment. SL is measured inside the workflow (parallel reader/writer steps), so it no longer includes the api.vercel.com read path.}

_{Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the /flow invocation for a large fraction of runs, inflating P75+; the Best column shows the fastest (warm-start) sample for comparison.}

[github-actions]

🧪 E2E Test Results

✅ All tests passed

E2E Test Summary

Summary

	Passed	Failed	Skipped	Total
✅ ▲ Vercel Production	1455	0	239	1694
✅ 💻 Local Development	1621	0	227	1848
✅ 📦 Local Production	1621	0	227	1848
✅ 🐘 Local Postgres	1621	0	227	1848
✅ 🪟 Windows	154	0	0	154
✅ 📋 Other	1020	0	212	1232
✅ vercel-multi-region	27	0	0	27
Total	7519	0	1132	8651

Details by Category

✅ ▲ Vercel Production

App	Passed	Failed	Skipped
✅ astro	126	0	28
✅ example	126	0	28
✅ express	126	0	28
✅ fastify	126	0	28
✅ hono	126	0	28
✅ nextjs-turbopack	151	0	3
✅ nextjs-webpack	151	0	3
✅ nitro	126	0	28
✅ nuxt	126	0	28
✅ sveltekit	145	0	9
✅ vite	126	0	28

✅ 💻 Local Development

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 📦 Local Production

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🐘 Local Postgres

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🪟 Windows

App	Passed	Failed	Skipped
✅ nextjs-turbopack	154	0	0

✅ 📋 Other

App	Passed	Failed	Skipped
✅ e2e-local-dev-nest-stable	128	0	26
✅ e2e-local-dev-tanstack-start-	128	0	26
✅ e2e-local-postgres-nest-stable	128	0	26
✅ e2e-local-postgres-tanstack-start-	128	0	26
✅ e2e-local-prod-nest-stable	128	0	26
✅ e2e-local-prod-tanstack-start-	128	0	26
✅ e2e-vercel-prod-nest	126	0	28
✅ e2e-vercel-prod-tanstack-start	126	0	28

✅ vercel-multi-region

App	Passed	Failed	Skipped
✅ nextjs-turbopack	27	0	0

---

📋 View full workflow run

[karthikscale3]

ai review: The decryption changes look correct, but the published @workflow/web package is missing from the changeset.

[karthikscale3]

Reviewed at 85e262c. Implementation looks good; the existing inline changeset note is non-blocking.

[github-actions]

No backport to stable for e8bc7d6 (AI decision).

This is feature work — PR 5 of 7 in a stack that introduces the sealed-box (encp) payload scheme, adding new capability (deriveRunPayloadKeys, DecryptionKey, browser-safe re-exports) to observability tooling. It also builds directly on main-only APIs: git ls-tree origin/stable confirms packages/core/src/sealed-box.ts and packages/core/src/serialization/encryption.ts do not exist on stable, so the cherry-pick could not even work. The "regression" it fixes only materializes once the rest of the sealed-payload stack lands, which is not on the maintenance line.

To override, re-run the Backport to stable workflow manually via workflow_dispatch and paste this commit SHA into the ref input:

e8bc7d6aadcdb5f89de1be71cfcafe5e9085ed25

[TooTallNate]

Replaces #3097. That PR was force-closed as "merged" by GitHub when I
force-pushed its base branch to a commit that happened to contain its head —
GitHub concluded it had merged into its base. Its code never reached main.
It cannot be reopened, so this PR carries the identical work. Review history
on #3097 still applies.

Ordering change: this now targets main directly and should land before
#3096, per the review there. #3096 begins emitting sealed (encp) hook payloads
while workflow inspect --decrypt can only build a symmetric key, so merging it
first would leave those payloads showing as ciphertext placeholders. Landing the
reader first closes that window.

To make this PR stand alone, deriveRunPayloadKeys moved here from #3096 — it
is the capability the reader needs, and its own doc says to use it "anywhere a
run reads its own event log", so it belongs on this side regardless.

---

PR 5 of 7. Stacked on #3096; review the stack in order, starting from #3093.

• feat(core): add encp sealed-box encryption primitive #3093 — the encp sealed-box primitive
• feat(core): route sealed envelopes through the serialization layer #3094 — route sealed envelopes through the serialization layer
• feat: publish each run's X25519 public key on the run entity #3095 — publish each run's public key on the run entity
• feat(core): seal hook payloads to the target run's public key #3096 — resumeHook() seals instead of fetching the key ← the payoff
• feat: decrypt sealed payloads in the dashboard and CLI #3097 (this PR) — decrypt sealed payloads in observability tooling
• feat(core): seal forwarded stream writes to the owner's public key #3098 — seal forwarded stream writes
• feat: return the run public key from the capability probe #3099 — start() gets the key from the probe it already awaits

Why this is required, not optional

Once #3096 lands, a hook resumption from another deployment writes a sealed payload into the run's event log. Observability tooling can't open it: hydrateDataWithKey only ever ran AES-GCM. So the dashboard and CLI would render a 🔒 placeholder on data the user is entitled to read and has already supplied the key for — a visible debugging regression on exactly the runs this work speeds up.

What changed

hydrateDataWithKey delegates to the envelope layer, which dispatches on the 4-byte format prefix, instead of unconditionally decrypting with AES-GCM.

All four o11y key-resolution sites now resolve the run's full key capability rather than just its symmetric key:

Site	Path
@workflow/web-shared	hydrateResourceIOAsync
@workflow/web	use-stream-reader (hand-rolled frame decode)
@workflow/cli	--decrypt field hydration
@workflow/cli	--decrypt stream output

Each already had the raw 32 bytes in hand, so this costs one extra key derivation and no additional requests or round trips.

A caller that supplies only a symmetric key still gets the ciphertext placeholder for sealed payloads rather than a decryption error — that key never could have opened them, so surfacing a failure would be misleading.

Browser bundling

The natural import for the new helper is @workflow/core/serialization, but that module graph reaches node:util and node:async_hooks and cannot be bundled for the browser — which is precisely what the @workflow/core/serialization-format entrypoint exists to avoid. I hit this as a build failure and moved the key helpers to a re-export from that browser-safe entrypoint; the two browser consumers import from there, while the CLI keeps the direct import since it runs on Node.

Verified by walking the built import graph: serialization-format.js reaches 6 modules and zero Node built-ins.

Tests

Two new cases assert the o11y path opens a real sealed payload with the derived keypair, and that the same resolved key still opens the run's own symmetric payloads — a run's event log mixes both.

Core suite 1598 passing, web-shared 160, CLI 78. Zero new lint diagnostics (diffed against a stashed baseline).

[changeset-bot]

🦋 Changeset detected

Latest commit: 916bc93

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@workflow/core	Minor
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/cli	Patch
@workflow/builders	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/vitest	Patch
workflow	Minor
@workflow/world-testing	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Jul 28, 2026 12:08am
example-nextjs-workflow-webpack	Building	Preview, Comment	Jul 28, 2026 12:08am
example-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-astro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-express-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-fastify-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-hono-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nestjs-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nitro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nuxt-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-sveltekit-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-tanstack-start-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-vite-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-docs	Ready	Preview, Comment, Open in v0	Jul 28, 2026 12:08am
workflow-swc-playground	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-tarballs	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-web	Ready	Preview, Comment	Jul 28, 2026 12:08am

[github-actions]

📊 Workflow Benchmarks

commit 916bc93 · Tue, 28 Jul 2026 00:26:55 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	228 (-69%) 💚	1407 🔴 (+24%) 🔻	1449 🔴 (+20%) 🔻	1751 🔴 (+28%) 🔻	30
TTFS	stream	273 (-13%)	1428 🔴 (+30%) 🔻	1438 🔴 (+26%) 🔻	1527 🔴 (+30%) 🔻	30
TTFS	hook + stream	572 (-55%) 💚	1694 🔴 (+21%) 🔻	1740 🔴 (+19%) 🔻	1895 🔴 (+16%) 🔻	30
STSO	1020 steps (1-20)	185 (+8.8%)	327 🔴 (+8.3%)	550 🔴 (+56%) 🔻	681 🔴 (+80%) 🔻	19
STSO	1020 steps (101-120)	205 (+4.1%)	298 🔴 (-12%)	473 🔴 (+16%) 🔻	598 🔴 (+20%) 🔻	19
STSO	1020 steps (1001-1020)	473 (-2.1%)	563 🔴 (-1.9%)	669 🔴 (+3.6%)	852 🔴 (+30%) 🔻	19
WO	1020 steps	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	1
SL	stream latency	97 (+4.3%)	196 🔴 (+17%) 🔻	257 🔴 (+9.8%)	592 🔴 (+134%) 🔻	30
SO	stream overhead (text)	126 (-3.8%)	303 🔴 (+4.5%)	400 (+13%)	543 (+29%) 🔻	30
SO	stream overhead (structured)	135 (±0%)	391 🔴 (+50%) 🔻	729 🔴 (+162%) 🔻	5527 🔴 (+1238%) 🔻	30

ℹ️ Metric definitions & methodology

_{Best/P75/P90/P99 deltas compare against the most recent benchmark run on main at the time of this run. 🔻 flags a delta worse than +15%, 💚 one better than −15%.}

_{Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window)}

_{Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost}

_{🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120}

_{All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor (clientStart) right before start(), so the CI runner’s request and its path through api.vercel.com sit outside every measured window. TTFS = in-deployment start() → first step body (turbo uses the in-process fast path, non-turbo the dispatch path), and includes the VQS dispatch hop plus any /flow cold start. STSO/WO are measured between step bodies on the deployment. SL is measured inside the workflow (parallel reader/writer steps), so it no longer includes the api.vercel.com read path.}

_{Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the /flow invocation for a large fraction of runs, inflating P75+; the Best column shows the fastest (warm-start) sample for comparison.}

[github-actions]

🧪 E2E Test Results

✅ All tests passed

E2E Test Summary

Summary

	Passed	Failed	Skipped	Total
✅ ▲ Vercel Production	1455	0	239	1694
✅ 💻 Local Development	1621	0	227	1848
✅ 📦 Local Production	1621	0	227	1848
✅ 🐘 Local Postgres	1621	0	227	1848
✅ 🪟 Windows	154	0	0	154
✅ 📋 Other	1020	0	212	1232
✅ vercel-multi-region	27	0	0	27
Total	7519	0	1132	8651

Details by Category

✅ ▲ Vercel Production

App	Passed	Failed	Skipped
✅ astro	126	0	28
✅ example	126	0	28
✅ express	126	0	28
✅ fastify	126	0	28
✅ hono	126	0	28
✅ nextjs-turbopack	151	0	3
✅ nextjs-webpack	151	0	3
✅ nitro	126	0	28
✅ nuxt	126	0	28
✅ sveltekit	145	0	9
✅ vite	126	0	28

✅ 💻 Local Development

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 📦 Local Production

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🐘 Local Postgres

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🪟 Windows

App	Passed	Failed	Skipped
✅ nextjs-turbopack	154	0	0

✅ 📋 Other

App	Passed	Failed	Skipped
✅ e2e-local-dev-nest-stable	128	0	26
✅ e2e-local-dev-tanstack-start-	128	0	26
✅ e2e-local-postgres-nest-stable	128	0	26
✅ e2e-local-postgres-tanstack-start-	128	0	26
✅ e2e-local-prod-nest-stable	128	0	26
✅ e2e-local-prod-tanstack-start-	128	0	26
✅ e2e-vercel-prod-nest	126	0	28
✅ e2e-vercel-prod-tanstack-start	126	0	28

✅ vercel-multi-region

App	Passed	Failed	Skipped
✅ nextjs-turbopack	27	0	0

---

📋 View full workflow run

[karthikscale3]

ai review: The decryption changes look correct, but the published @workflow/web package is missing from the changeset.

[karthikscale3]

Reviewed at 85e262c. Implementation looks good; the existing inline changeset note is non-blocking.

[github-actions]

No backport to stable for e8bc7d6 (AI decision).

This is feature work — PR 5 of 7 in a stack that introduces the sealed-box (encp) payload scheme, adding new capability (deriveRunPayloadKeys, DecryptionKey, browser-safe re-exports) to observability tooling. It also builds directly on main-only APIs: git ls-tree origin/stable confirms packages/core/src/sealed-box.ts and packages/core/src/serialization/encryption.ts do not exist on stable, so the cherry-pick could not even work. The "regression" it fixes only materializes once the rest of the sealed-payload stack lands, which is not on the maintenance line.

To override, re-run the Backport to stable workflow manually via workflow_dispatch and paste this commit SHA into the ref input:

e8bc7d6aadcdb5f89de1be71cfcafe5e9085ed25

[TooTallNate]

Replaces #3097. That PR was force-closed as "merged" by GitHub when I
force-pushed its base branch to a commit that happened to contain its head —
GitHub concluded it had merged into its base. Its code never reached main.
It cannot be reopened, so this PR carries the identical work. Review history
on #3097 still applies.

Ordering change: this now targets main directly and should land before
#3096, per the review there. #3096 begins emitting sealed (encp) hook payloads
while workflow inspect --decrypt can only build a symmetric key, so merging it
first would leave those payloads showing as ciphertext placeholders. Landing the
reader first closes that window.

To make this PR stand alone, deriveRunPayloadKeys moved here from #3096 — it
is the capability the reader needs, and its own doc says to use it "anywhere a
run reads its own event log", so it belongs on this side regardless.

---

PR 5 of 7. Stacked on #3096; review the stack in order, starting from #3093.

• feat(core): add encp sealed-box encryption primitive #3093 — the encp sealed-box primitive
• feat(core): route sealed envelopes through the serialization layer #3094 — route sealed envelopes through the serialization layer
• feat: publish each run's X25519 public key on the run entity #3095 — publish each run's public key on the run entity
• feat(core): seal hook payloads to the target run's public key #3096 — resumeHook() seals instead of fetching the key ← the payoff
• feat: decrypt sealed payloads in the dashboard and CLI #3097 (this PR) — decrypt sealed payloads in observability tooling
• feat(core): seal forwarded stream writes to the owner's public key #3098 — seal forwarded stream writes
• feat: return the run public key from the capability probe #3099 — start() gets the key from the probe it already awaits

Why this is required, not optional

Once #3096 lands, a hook resumption from another deployment writes a sealed payload into the run's event log. Observability tooling can't open it: hydrateDataWithKey only ever ran AES-GCM. So the dashboard and CLI would render a 🔒 placeholder on data the user is entitled to read and has already supplied the key for — a visible debugging regression on exactly the runs this work speeds up.

What changed

hydrateDataWithKey delegates to the envelope layer, which dispatches on the 4-byte format prefix, instead of unconditionally decrypting with AES-GCM.

All four o11y key-resolution sites now resolve the run's full key capability rather than just its symmetric key:

Site	Path
@workflow/web-shared	hydrateResourceIOAsync
@workflow/web	use-stream-reader (hand-rolled frame decode)
@workflow/cli	--decrypt field hydration
@workflow/cli	--decrypt stream output

Each already had the raw 32 bytes in hand, so this costs one extra key derivation and no additional requests or round trips.

A caller that supplies only a symmetric key still gets the ciphertext placeholder for sealed payloads rather than a decryption error — that key never could have opened them, so surfacing a failure would be misleading.

Browser bundling

The natural import for the new helper is @workflow/core/serialization, but that module graph reaches node:util and node:async_hooks and cannot be bundled for the browser — which is precisely what the @workflow/core/serialization-format entrypoint exists to avoid. I hit this as a build failure and moved the key helpers to a re-export from that browser-safe entrypoint; the two browser consumers import from there, while the CLI keeps the direct import since it runs on Node.

Verified by walking the built import graph: serialization-format.js reaches 6 modules and zero Node built-ins.

Tests

Two new cases assert the o11y path opens a real sealed payload with the derived keypair, and that the same resolved key still opens the run's own symmetric payloads — a run's event log mixes both.

Core suite 1598 passing, web-shared 160, CLI 78. Zero new lint diagnostics (diffed against a stashed baseline).

[changeset-bot]

🦋 Changeset detected

Latest commit: 916bc93

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@workflow/core	Minor
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/cli	Patch
@workflow/builders	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/vitest	Patch
workflow	Minor
@workflow/world-testing	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Jul 28, 2026 12:08am
example-nextjs-workflow-webpack	Building	Preview, Comment	Jul 28, 2026 12:08am
example-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-astro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-express-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-fastify-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-hono-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nestjs-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nitro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nuxt-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-sveltekit-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-tanstack-start-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-vite-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-docs	Ready	Preview, Comment, Open in v0	Jul 28, 2026 12:08am
workflow-swc-playground	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-tarballs	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-web	Ready	Preview, Comment	Jul 28, 2026 12:08am

[github-actions]

📊 Workflow Benchmarks

commit 916bc93 · Tue, 28 Jul 2026 00:26:55 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	228 (-69%) 💚	1407 🔴 (+24%) 🔻	1449 🔴 (+20%) 🔻	1751 🔴 (+28%) 🔻	30
TTFS	stream	273 (-13%)	1428 🔴 (+30%) 🔻	1438 🔴 (+26%) 🔻	1527 🔴 (+30%) 🔻	30
TTFS	hook + stream	572 (-55%) 💚	1694 🔴 (+21%) 🔻	1740 🔴 (+19%) 🔻	1895 🔴 (+16%) 🔻	30
STSO	1020 steps (1-20)	185 (+8.8%)	327 🔴 (+8.3%)	550 🔴 (+56%) 🔻	681 🔴 (+80%) 🔻	19
STSO	1020 steps (101-120)	205 (+4.1%)	298 🔴 (-12%)	473 🔴 (+16%) 🔻	598 🔴 (+20%) 🔻	19
STSO	1020 steps (1001-1020)	473 (-2.1%)	563 🔴 (-1.9%)	669 🔴 (+3.6%)	852 🔴 (+30%) 🔻	19
WO	1020 steps	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	1
SL	stream latency	97 (+4.3%)	196 🔴 (+17%) 🔻	257 🔴 (+9.8%)	592 🔴 (+134%) 🔻	30
SO	stream overhead (text)	126 (-3.8%)	303 🔴 (+4.5%)	400 (+13%)	543 (+29%) 🔻	30
SO	stream overhead (structured)	135 (±0%)	391 🔴 (+50%) 🔻	729 🔴 (+162%) 🔻	5527 🔴 (+1238%) 🔻	30

ℹ️ Metric definitions & methodology

_{Best/P75/P90/P99 deltas compare against the most recent benchmark run on main at the time of this run. 🔻 flags a delta worse than +15%, 💚 one better than −15%.}

_{Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window)}

_{Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost}

_{🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120}

_{All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor (clientStart) right before start(), so the CI runner’s request and its path through api.vercel.com sit outside every measured window. TTFS = in-deployment start() → first step body (turbo uses the in-process fast path, non-turbo the dispatch path), and includes the VQS dispatch hop plus any /flow cold start. STSO/WO are measured between step bodies on the deployment. SL is measured inside the workflow (parallel reader/writer steps), so it no longer includes the api.vercel.com read path.}

_{Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the /flow invocation for a large fraction of runs, inflating P75+; the Best column shows the fastest (warm-start) sample for comparison.}

[github-actions]

🧪 E2E Test Results

✅ All tests passed

E2E Test Summary

Summary

	Passed	Failed	Skipped	Total
✅ ▲ Vercel Production	1455	0	239	1694
✅ 💻 Local Development	1621	0	227	1848
✅ 📦 Local Production	1621	0	227	1848
✅ 🐘 Local Postgres	1621	0	227	1848
✅ 🪟 Windows	154	0	0	154
✅ 📋 Other	1020	0	212	1232
✅ vercel-multi-region	27	0	0	27
Total	7519	0	1132	8651

Details by Category

✅ ▲ Vercel Production

App	Passed	Failed	Skipped
✅ astro	126	0	28
✅ example	126	0	28
✅ express	126	0	28
✅ fastify	126	0	28
✅ hono	126	0	28
✅ nextjs-turbopack	151	0	3
✅ nextjs-webpack	151	0	3
✅ nitro	126	0	28
✅ nuxt	126	0	28
✅ sveltekit	145	0	9
✅ vite	126	0	28

✅ 💻 Local Development

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 📦 Local Production

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🐘 Local Postgres

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🪟 Windows

App	Passed	Failed	Skipped
✅ nextjs-turbopack	154	0	0

✅ 📋 Other

App	Passed	Failed	Skipped
✅ e2e-local-dev-nest-stable	128	0	26
✅ e2e-local-dev-tanstack-start-	128	0	26
✅ e2e-local-postgres-nest-stable	128	0	26
✅ e2e-local-postgres-tanstack-start-	128	0	26
✅ e2e-local-prod-nest-stable	128	0	26
✅ e2e-local-prod-tanstack-start-	128	0	26
✅ e2e-vercel-prod-nest	126	0	28
✅ e2e-vercel-prod-tanstack-start	126	0	28

✅ vercel-multi-region

App	Passed	Failed	Skipped
✅ nextjs-turbopack	27	0	0

---

📋 View full workflow run

[karthikscale3]

ai review: The decryption changes look correct, but the published @workflow/web package is missing from the changeset.

[karthikscale3]

Reviewed at 85e262c. Implementation looks good; the existing inline changeset note is non-blocking.

[github-actions]

No backport to stable for e8bc7d6 (AI decision).

This is feature work — PR 5 of 7 in a stack that introduces the sealed-box (encp) payload scheme, adding new capability (deriveRunPayloadKeys, DecryptionKey, browser-safe re-exports) to observability tooling. It also builds directly on main-only APIs: git ls-tree origin/stable confirms packages/core/src/sealed-box.ts and packages/core/src/serialization/encryption.ts do not exist on stable, so the cherry-pick could not even work. The "regression" it fixes only materializes once the rest of the sealed-payload stack lands, which is not on the maintenance line.

To override, re-run the Backport to stable workflow manually via workflow_dispatch and paste this commit SHA into the ref input:

e8bc7d6aadcdb5f89de1be71cfcafe5e9085ed25

[TooTallNate]

Replaces #3097. That PR was force-closed as "merged" by GitHub when I
force-pushed its base branch to a commit that happened to contain its head —
GitHub concluded it had merged into its base. Its code never reached main.
It cannot be reopened, so this PR carries the identical work. Review history
on #3097 still applies.

Ordering change: this now targets main directly and should land before
#3096, per the review there. #3096 begins emitting sealed (encp) hook payloads
while workflow inspect --decrypt can only build a symmetric key, so merging it
first would leave those payloads showing as ciphertext placeholders. Landing the
reader first closes that window.

To make this PR stand alone, deriveRunPayloadKeys moved here from #3096 — it
is the capability the reader needs, and its own doc says to use it "anywhere a
run reads its own event log", so it belongs on this side regardless.

---

PR 5 of 7. Stacked on #3096; review the stack in order, starting from #3093.

• feat(core): add encp sealed-box encryption primitive #3093 — the encp sealed-box primitive
• feat(core): route sealed envelopes through the serialization layer #3094 — route sealed envelopes through the serialization layer
• feat: publish each run's X25519 public key on the run entity #3095 — publish each run's public key on the run entity
• feat(core): seal hook payloads to the target run's public key #3096 — resumeHook() seals instead of fetching the key ← the payoff
• feat: decrypt sealed payloads in the dashboard and CLI #3097 (this PR) — decrypt sealed payloads in observability tooling
• feat(core): seal forwarded stream writes to the owner's public key #3098 — seal forwarded stream writes
• feat: return the run public key from the capability probe #3099 — start() gets the key from the probe it already awaits

Why this is required, not optional

Once #3096 lands, a hook resumption from another deployment writes a sealed payload into the run's event log. Observability tooling can't open it: hydrateDataWithKey only ever ran AES-GCM. So the dashboard and CLI would render a 🔒 placeholder on data the user is entitled to read and has already supplied the key for — a visible debugging regression on exactly the runs this work speeds up.

What changed

hydrateDataWithKey delegates to the envelope layer, which dispatches on the 4-byte format prefix, instead of unconditionally decrypting with AES-GCM.

All four o11y key-resolution sites now resolve the run's full key capability rather than just its symmetric key:

Site	Path
@workflow/web-shared	hydrateResourceIOAsync
@workflow/web	use-stream-reader (hand-rolled frame decode)
@workflow/cli	--decrypt field hydration
@workflow/cli	--decrypt stream output

Each already had the raw 32 bytes in hand, so this costs one extra key derivation and no additional requests or round trips.

A caller that supplies only a symmetric key still gets the ciphertext placeholder for sealed payloads rather than a decryption error — that key never could have opened them, so surfacing a failure would be misleading.

Browser bundling

The natural import for the new helper is @workflow/core/serialization, but that module graph reaches node:util and node:async_hooks and cannot be bundled for the browser — which is precisely what the @workflow/core/serialization-format entrypoint exists to avoid. I hit this as a build failure and moved the key helpers to a re-export from that browser-safe entrypoint; the two browser consumers import from there, while the CLI keeps the direct import since it runs on Node.

Verified by walking the built import graph: serialization-format.js reaches 6 modules and zero Node built-ins.

Tests

Two new cases assert the o11y path opens a real sealed payload with the derived keypair, and that the same resolved key still opens the run's own symmetric payloads — a run's event log mixes both.

Core suite 1598 passing, web-shared 160, CLI 78. Zero new lint diagnostics (diffed against a stashed baseline).

[changeset-bot]

🦋 Changeset detected

Latest commit: 916bc93

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@workflow/core	Minor
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/cli	Patch
@workflow/builders	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/vitest	Patch
workflow	Minor
@workflow/world-testing	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Jul 28, 2026 12:08am
example-nextjs-workflow-webpack	Building	Preview, Comment	Jul 28, 2026 12:08am
example-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-astro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-express-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-fastify-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-hono-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nestjs-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nitro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nuxt-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-sveltekit-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-tanstack-start-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-vite-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-docs	Ready	Preview, Comment, Open in v0	Jul 28, 2026 12:08am
workflow-swc-playground	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-tarballs	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-web	Ready	Preview, Comment	Jul 28, 2026 12:08am

[github-actions]

📊 Workflow Benchmarks

commit 916bc93 · Tue, 28 Jul 2026 00:26:55 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	228 (-69%) 💚	1407 🔴 (+24%) 🔻	1449 🔴 (+20%) 🔻	1751 🔴 (+28%) 🔻	30
TTFS	stream	273 (-13%)	1428 🔴 (+30%) 🔻	1438 🔴 (+26%) 🔻	1527 🔴 (+30%) 🔻	30
TTFS	hook + stream	572 (-55%) 💚	1694 🔴 (+21%) 🔻	1740 🔴 (+19%) 🔻	1895 🔴 (+16%) 🔻	30
STSO	1020 steps (1-20)	185 (+8.8%)	327 🔴 (+8.3%)	550 🔴 (+56%) 🔻	681 🔴 (+80%) 🔻	19
STSO	1020 steps (101-120)	205 (+4.1%)	298 🔴 (-12%)	473 🔴 (+16%) 🔻	598 🔴 (+20%) 🔻	19
STSO	1020 steps (1001-1020)	473 (-2.1%)	563 🔴 (-1.9%)	669 🔴 (+3.6%)	852 🔴 (+30%) 🔻	19
WO	1020 steps	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	1
SL	stream latency	97 (+4.3%)	196 🔴 (+17%) 🔻	257 🔴 (+9.8%)	592 🔴 (+134%) 🔻	30
SO	stream overhead (text)	126 (-3.8%)	303 🔴 (+4.5%)	400 (+13%)	543 (+29%) 🔻	30
SO	stream overhead (structured)	135 (±0%)	391 🔴 (+50%) 🔻	729 🔴 (+162%) 🔻	5527 🔴 (+1238%) 🔻	30

ℹ️ Metric definitions & methodology

_{Best/P75/P90/P99 deltas compare against the most recent benchmark run on main at the time of this run. 🔻 flags a delta worse than +15%, 💚 one better than −15%.}

_{Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window)}

_{Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost}

_{🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120}

_{All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor (clientStart) right before start(), so the CI runner’s request and its path through api.vercel.com sit outside every measured window. TTFS = in-deployment start() → first step body (turbo uses the in-process fast path, non-turbo the dispatch path), and includes the VQS dispatch hop plus any /flow cold start. STSO/WO are measured between step bodies on the deployment. SL is measured inside the workflow (parallel reader/writer steps), so it no longer includes the api.vercel.com read path.}

_{Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the /flow invocation for a large fraction of runs, inflating P75+; the Best column shows the fastest (warm-start) sample for comparison.}

[github-actions]

🧪 E2E Test Results

✅ All tests passed

E2E Test Summary

Summary

	Passed	Failed	Skipped	Total
✅ ▲ Vercel Production	1455	0	239	1694
✅ 💻 Local Development	1621	0	227	1848
✅ 📦 Local Production	1621	0	227	1848
✅ 🐘 Local Postgres	1621	0	227	1848
✅ 🪟 Windows	154	0	0	154
✅ 📋 Other	1020	0	212	1232
✅ vercel-multi-region	27	0	0	27
Total	7519	0	1132	8651

Details by Category

✅ ▲ Vercel Production

App	Passed	Failed	Skipped
✅ astro	126	0	28
✅ example	126	0	28
✅ express	126	0	28
✅ fastify	126	0	28
✅ hono	126	0	28
✅ nextjs-turbopack	151	0	3
✅ nextjs-webpack	151	0	3
✅ nitro	126	0	28
✅ nuxt	126	0	28
✅ sveltekit	145	0	9
✅ vite	126	0	28

✅ 💻 Local Development

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 📦 Local Production

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🐘 Local Postgres

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🪟 Windows

App	Passed	Failed	Skipped
✅ nextjs-turbopack	154	0	0

✅ 📋 Other

App	Passed	Failed	Skipped
✅ e2e-local-dev-nest-stable	128	0	26
✅ e2e-local-dev-tanstack-start-	128	0	26
✅ e2e-local-postgres-nest-stable	128	0	26
✅ e2e-local-postgres-tanstack-start-	128	0	26
✅ e2e-local-prod-nest-stable	128	0	26
✅ e2e-local-prod-tanstack-start-	128	0	26
✅ e2e-vercel-prod-nest	126	0	28
✅ e2e-vercel-prod-tanstack-start	126	0	28

✅ vercel-multi-region

App	Passed	Failed	Skipped
✅ nextjs-turbopack	27	0	0

---

📋 View full workflow run

[karthikscale3]

ai review: The decryption changes look correct, but the published @workflow/web package is missing from the changeset.

[karthikscale3]

Reviewed at 85e262c. Implementation looks good; the existing inline changeset note is non-blocking.

[github-actions]

No backport to stable for e8bc7d6 (AI decision).

This is feature work — PR 5 of 7 in a stack that introduces the sealed-box (encp) payload scheme, adding new capability (deriveRunPayloadKeys, DecryptionKey, browser-safe re-exports) to observability tooling. It also builds directly on main-only APIs: git ls-tree origin/stable confirms packages/core/src/sealed-box.ts and packages/core/src/serialization/encryption.ts do not exist on stable, so the cherry-pick could not even work. The "regression" it fixes only materializes once the rest of the sealed-payload stack lands, which is not on the maintenance line.

To override, re-run the Backport to stable workflow manually via workflow_dispatch and paste this commit SHA into the ref input:

e8bc7d6aadcdb5f89de1be71cfcafe5e9085ed25

[TooTallNate]

Replaces #3097. That PR was force-closed as "merged" by GitHub when I
force-pushed its base branch to a commit that happened to contain its head —
GitHub concluded it had merged into its base. Its code never reached main.
It cannot be reopened, so this PR carries the identical work. Review history
on #3097 still applies.

Ordering change: this now targets main directly and should land before
#3096, per the review there. #3096 begins emitting sealed (encp) hook payloads
while workflow inspect --decrypt can only build a symmetric key, so merging it
first would leave those payloads showing as ciphertext placeholders. Landing the
reader first closes that window.

To make this PR stand alone, deriveRunPayloadKeys moved here from #3096 — it
is the capability the reader needs, and its own doc says to use it "anywhere a
run reads its own event log", so it belongs on this side regardless.

---

PR 5 of 7. Stacked on #3096; review the stack in order, starting from #3093.

• feat(core): add encp sealed-box encryption primitive #3093 — the encp sealed-box primitive
• feat(core): route sealed envelopes through the serialization layer #3094 — route sealed envelopes through the serialization layer
• feat: publish each run's X25519 public key on the run entity #3095 — publish each run's public key on the run entity
• feat(core): seal hook payloads to the target run's public key #3096 — resumeHook() seals instead of fetching the key ← the payoff
• feat: decrypt sealed payloads in the dashboard and CLI #3097 (this PR) — decrypt sealed payloads in observability tooling
• feat(core): seal forwarded stream writes to the owner's public key #3098 — seal forwarded stream writes
• feat: return the run public key from the capability probe #3099 — start() gets the key from the probe it already awaits

Why this is required, not optional

Once #3096 lands, a hook resumption from another deployment writes a sealed payload into the run's event log. Observability tooling can't open it: hydrateDataWithKey only ever ran AES-GCM. So the dashboard and CLI would render a 🔒 placeholder on data the user is entitled to read and has already supplied the key for — a visible debugging regression on exactly the runs this work speeds up.

What changed

hydrateDataWithKey delegates to the envelope layer, which dispatches on the 4-byte format prefix, instead of unconditionally decrypting with AES-GCM.

All four o11y key-resolution sites now resolve the run's full key capability rather than just its symmetric key:

Site	Path
@workflow/web-shared	hydrateResourceIOAsync
@workflow/web	use-stream-reader (hand-rolled frame decode)
@workflow/cli	--decrypt field hydration
@workflow/cli	--decrypt stream output

Each already had the raw 32 bytes in hand, so this costs one extra key derivation and no additional requests or round trips.

A caller that supplies only a symmetric key still gets the ciphertext placeholder for sealed payloads rather than a decryption error — that key never could have opened them, so surfacing a failure would be misleading.

Browser bundling

The natural import for the new helper is @workflow/core/serialization, but that module graph reaches node:util and node:async_hooks and cannot be bundled for the browser — which is precisely what the @workflow/core/serialization-format entrypoint exists to avoid. I hit this as a build failure and moved the key helpers to a re-export from that browser-safe entrypoint; the two browser consumers import from there, while the CLI keeps the direct import since it runs on Node.

Verified by walking the built import graph: serialization-format.js reaches 6 modules and zero Node built-ins.

Tests

Two new cases assert the o11y path opens a real sealed payload with the derived keypair, and that the same resolved key still opens the run's own symmetric payloads — a run's event log mixes both.

Core suite 1598 passing, web-shared 160, CLI 78. Zero new lint diagnostics (diffed against a stashed baseline).

[changeset-bot]

🦋 Changeset detected

Latest commit: 916bc93

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@workflow/core	Minor
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/cli	Patch
@workflow/builders	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/vitest	Patch
workflow	Minor
@workflow/world-testing	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Jul 28, 2026 12:08am
example-nextjs-workflow-webpack	Building	Preview, Comment	Jul 28, 2026 12:08am
example-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-astro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-express-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-fastify-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-hono-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nestjs-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nitro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nuxt-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-sveltekit-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-tanstack-start-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-vite-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-docs	Ready	Preview, Comment, Open in v0	Jul 28, 2026 12:08am
workflow-swc-playground	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-tarballs	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-web	Ready	Preview, Comment	Jul 28, 2026 12:08am

[github-actions]

📊 Workflow Benchmarks

commit 916bc93 · Tue, 28 Jul 2026 00:26:55 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	228 (-69%) 💚	1407 🔴 (+24%) 🔻	1449 🔴 (+20%) 🔻	1751 🔴 (+28%) 🔻	30
TTFS	stream	273 (-13%)	1428 🔴 (+30%) 🔻	1438 🔴 (+26%) 🔻	1527 🔴 (+30%) 🔻	30
TTFS	hook + stream	572 (-55%) 💚	1694 🔴 (+21%) 🔻	1740 🔴 (+19%) 🔻	1895 🔴 (+16%) 🔻	30
STSO	1020 steps (1-20)	185 (+8.8%)	327 🔴 (+8.3%)	550 🔴 (+56%) 🔻	681 🔴 (+80%) 🔻	19
STSO	1020 steps (101-120)	205 (+4.1%)	298 🔴 (-12%)	473 🔴 (+16%) 🔻	598 🔴 (+20%) 🔻	19
STSO	1020 steps (1001-1020)	473 (-2.1%)	563 🔴 (-1.9%)	669 🔴 (+3.6%)	852 🔴 (+30%) 🔻	19
WO	1020 steps	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	1
SL	stream latency	97 (+4.3%)	196 🔴 (+17%) 🔻	257 🔴 (+9.8%)	592 🔴 (+134%) 🔻	30
SO	stream overhead (text)	126 (-3.8%)	303 🔴 (+4.5%)	400 (+13%)	543 (+29%) 🔻	30
SO	stream overhead (structured)	135 (±0%)	391 🔴 (+50%) 🔻	729 🔴 (+162%) 🔻	5527 🔴 (+1238%) 🔻	30

ℹ️ Metric definitions & methodology

_{Best/P75/P90/P99 deltas compare against the most recent benchmark run on main at the time of this run. 🔻 flags a delta worse than +15%, 💚 one better than −15%.}

_{Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window)}

_{Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost}

_{🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120}

_{All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor (clientStart) right before start(), so the CI runner’s request and its path through api.vercel.com sit outside every measured window. TTFS = in-deployment start() → first step body (turbo uses the in-process fast path, non-turbo the dispatch path), and includes the VQS dispatch hop plus any /flow cold start. STSO/WO are measured between step bodies on the deployment. SL is measured inside the workflow (parallel reader/writer steps), so it no longer includes the api.vercel.com read path.}

_{Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the /flow invocation for a large fraction of runs, inflating P75+; the Best column shows the fastest (warm-start) sample for comparison.}

[github-actions]

🧪 E2E Test Results

✅ All tests passed

E2E Test Summary

Summary

	Passed	Failed	Skipped	Total
✅ ▲ Vercel Production	1455	0	239	1694
✅ 💻 Local Development	1621	0	227	1848
✅ 📦 Local Production	1621	0	227	1848
✅ 🐘 Local Postgres	1621	0	227	1848
✅ 🪟 Windows	154	0	0	154
✅ 📋 Other	1020	0	212	1232
✅ vercel-multi-region	27	0	0	27
Total	7519	0	1132	8651

Details by Category

✅ ▲ Vercel Production

App	Passed	Failed	Skipped
✅ astro	126	0	28
✅ example	126	0	28
✅ express	126	0	28
✅ fastify	126	0	28
✅ hono	126	0	28
✅ nextjs-turbopack	151	0	3
✅ nextjs-webpack	151	0	3
✅ nitro	126	0	28
✅ nuxt	126	0	28
✅ sveltekit	145	0	9
✅ vite	126	0	28

✅ 💻 Local Development

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 📦 Local Production

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🐘 Local Postgres

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🪟 Windows

App	Passed	Failed	Skipped
✅ nextjs-turbopack	154	0	0

✅ 📋 Other

App	Passed	Failed	Skipped
✅ e2e-local-dev-nest-stable	128	0	26
✅ e2e-local-dev-tanstack-start-	128	0	26
✅ e2e-local-postgres-nest-stable	128	0	26
✅ e2e-local-postgres-tanstack-start-	128	0	26
✅ e2e-local-prod-nest-stable	128	0	26
✅ e2e-local-prod-tanstack-start-	128	0	26
✅ e2e-vercel-prod-nest	126	0	28
✅ e2e-vercel-prod-tanstack-start	126	0	28

✅ vercel-multi-region

App	Passed	Failed	Skipped
✅ nextjs-turbopack	27	0	0

---

📋 View full workflow run

[karthikscale3]

ai review: The decryption changes look correct, but the published @workflow/web package is missing from the changeset.

[karthikscale3]

Reviewed at 85e262c. Implementation looks good; the existing inline changeset note is non-blocking.

[github-actions]

No backport to stable for e8bc7d6 (AI decision).

This is feature work — PR 5 of 7 in a stack that introduces the sealed-box (encp) payload scheme, adding new capability (deriveRunPayloadKeys, DecryptionKey, browser-safe re-exports) to observability tooling. It also builds directly on main-only APIs: git ls-tree origin/stable confirms packages/core/src/sealed-box.ts and packages/core/src/serialization/encryption.ts do not exist on stable, so the cherry-pick could not even work. The "regression" it fixes only materializes once the rest of the sealed-payload stack lands, which is not on the maintenance line.

To override, re-run the Backport to stable workflow manually via workflow_dispatch and paste this commit SHA into the ref input:

e8bc7d6aadcdb5f89de1be71cfcafe5e9085ed25

[TooTallNate]

Replaces #3097. That PR was force-closed as "merged" by GitHub when I
force-pushed its base branch to a commit that happened to contain its head —
GitHub concluded it had merged into its base. Its code never reached main.
It cannot be reopened, so this PR carries the identical work. Review history
on #3097 still applies.

Ordering change: this now targets main directly and should land before
#3096, per the review there. #3096 begins emitting sealed (encp) hook payloads
while workflow inspect --decrypt can only build a symmetric key, so merging it
first would leave those payloads showing as ciphertext placeholders. Landing the
reader first closes that window.

To make this PR stand alone, deriveRunPayloadKeys moved here from #3096 — it
is the capability the reader needs, and its own doc says to use it "anywhere a
run reads its own event log", so it belongs on this side regardless.

---

PR 5 of 7. Stacked on #3096; review the stack in order, starting from #3093.

• feat(core): add encp sealed-box encryption primitive #3093 — the encp sealed-box primitive
• feat(core): route sealed envelopes through the serialization layer #3094 — route sealed envelopes through the serialization layer
• feat: publish each run's X25519 public key on the run entity #3095 — publish each run's public key on the run entity
• feat(core): seal hook payloads to the target run's public key #3096 — resumeHook() seals instead of fetching the key ← the payoff
• feat: decrypt sealed payloads in the dashboard and CLI #3097 (this PR) — decrypt sealed payloads in observability tooling
• feat(core): seal forwarded stream writes to the owner's public key #3098 — seal forwarded stream writes
• feat: return the run public key from the capability probe #3099 — start() gets the key from the probe it already awaits

Why this is required, not optional

Once #3096 lands, a hook resumption from another deployment writes a sealed payload into the run's event log. Observability tooling can't open it: hydrateDataWithKey only ever ran AES-GCM. So the dashboard and CLI would render a 🔒 placeholder on data the user is entitled to read and has already supplied the key for — a visible debugging regression on exactly the runs this work speeds up.

What changed

hydrateDataWithKey delegates to the envelope layer, which dispatches on the 4-byte format prefix, instead of unconditionally decrypting with AES-GCM.

All four o11y key-resolution sites now resolve the run's full key capability rather than just its symmetric key:

Site	Path
@workflow/web-shared	hydrateResourceIOAsync
@workflow/web	use-stream-reader (hand-rolled frame decode)
@workflow/cli	--decrypt field hydration
@workflow/cli	--decrypt stream output

Each already had the raw 32 bytes in hand, so this costs one extra key derivation and no additional requests or round trips.

A caller that supplies only a symmetric key still gets the ciphertext placeholder for sealed payloads rather than a decryption error — that key never could have opened them, so surfacing a failure would be misleading.

Browser bundling

The natural import for the new helper is @workflow/core/serialization, but that module graph reaches node:util and node:async_hooks and cannot be bundled for the browser — which is precisely what the @workflow/core/serialization-format entrypoint exists to avoid. I hit this as a build failure and moved the key helpers to a re-export from that browser-safe entrypoint; the two browser consumers import from there, while the CLI keeps the direct import since it runs on Node.

Verified by walking the built import graph: serialization-format.js reaches 6 modules and zero Node built-ins.

Tests

Two new cases assert the o11y path opens a real sealed payload with the derived keypair, and that the same resolved key still opens the run's own symmetric payloads — a run's event log mixes both.

Core suite 1598 passing, web-shared 160, CLI 78. Zero new lint diagnostics (diffed against a stashed baseline).

[changeset-bot]

🦋 Changeset detected

Latest commit: 916bc93

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@workflow/core	Minor
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/cli	Patch
@workflow/builders	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/vitest	Patch
workflow	Minor
@workflow/world-testing	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Jul 28, 2026 12:08am
example-nextjs-workflow-webpack	Building	Preview, Comment	Jul 28, 2026 12:08am
example-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-astro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-express-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-fastify-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-hono-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nestjs-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nitro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nuxt-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-sveltekit-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-tanstack-start-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-vite-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-docs	Ready	Preview, Comment, Open in v0	Jul 28, 2026 12:08am
workflow-swc-playground	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-tarballs	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-web	Ready	Preview, Comment	Jul 28, 2026 12:08am

[github-actions]

📊 Workflow Benchmarks

commit 916bc93 · Tue, 28 Jul 2026 00:26:55 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	228 (-69%) 💚	1407 🔴 (+24%) 🔻	1449 🔴 (+20%) 🔻	1751 🔴 (+28%) 🔻	30
TTFS	stream	273 (-13%)	1428 🔴 (+30%) 🔻	1438 🔴 (+26%) 🔻	1527 🔴 (+30%) 🔻	30
TTFS	hook + stream	572 (-55%) 💚	1694 🔴 (+21%) 🔻	1740 🔴 (+19%) 🔻	1895 🔴 (+16%) 🔻	30
STSO	1020 steps (1-20)	185 (+8.8%)	327 🔴 (+8.3%)	550 🔴 (+56%) 🔻	681 🔴 (+80%) 🔻	19
STSO	1020 steps (101-120)	205 (+4.1%)	298 🔴 (-12%)	473 🔴 (+16%) 🔻	598 🔴 (+20%) 🔻	19
STSO	1020 steps (1001-1020)	473 (-2.1%)	563 🔴 (-1.9%)	669 🔴 (+3.6%)	852 🔴 (+30%) 🔻	19
WO	1020 steps	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	1
SL	stream latency	97 (+4.3%)	196 🔴 (+17%) 🔻	257 🔴 (+9.8%)	592 🔴 (+134%) 🔻	30
SO	stream overhead (text)	126 (-3.8%)	303 🔴 (+4.5%)	400 (+13%)	543 (+29%) 🔻	30
SO	stream overhead (structured)	135 (±0%)	391 🔴 (+50%) 🔻	729 🔴 (+162%) 🔻	5527 🔴 (+1238%) 🔻	30

ℹ️ Metric definitions & methodology

_{Best/P75/P90/P99 deltas compare against the most recent benchmark run on main at the time of this run. 🔻 flags a delta worse than +15%, 💚 one better than −15%.}

_{Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window)}

_{Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost}

_{🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120}

_{All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor (clientStart) right before start(), so the CI runner’s request and its path through api.vercel.com sit outside every measured window. TTFS = in-deployment start() → first step body (turbo uses the in-process fast path, non-turbo the dispatch path), and includes the VQS dispatch hop plus any /flow cold start. STSO/WO are measured between step bodies on the deployment. SL is measured inside the workflow (parallel reader/writer steps), so it no longer includes the api.vercel.com read path.}

_{Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the /flow invocation for a large fraction of runs, inflating P75+; the Best column shows the fastest (warm-start) sample for comparison.}

[github-actions]

🧪 E2E Test Results

✅ All tests passed

E2E Test Summary

Summary

	Passed	Failed	Skipped	Total
✅ ▲ Vercel Production	1455	0	239	1694
✅ 💻 Local Development	1621	0	227	1848
✅ 📦 Local Production	1621	0	227	1848
✅ 🐘 Local Postgres	1621	0	227	1848
✅ 🪟 Windows	154	0	0	154
✅ 📋 Other	1020	0	212	1232
✅ vercel-multi-region	27	0	0	27
Total	7519	0	1132	8651

Details by Category

✅ ▲ Vercel Production

App	Passed	Failed	Skipped
✅ astro	126	0	28
✅ example	126	0	28
✅ express	126	0	28
✅ fastify	126	0	28
✅ hono	126	0	28
✅ nextjs-turbopack	151	0	3
✅ nextjs-webpack	151	0	3
✅ nitro	126	0	28
✅ nuxt	126	0	28
✅ sveltekit	145	0	9
✅ vite	126	0	28

✅ 💻 Local Development

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 📦 Local Production

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🐘 Local Postgres

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🪟 Windows

App	Passed	Failed	Skipped
✅ nextjs-turbopack	154	0	0

✅ 📋 Other

App	Passed	Failed	Skipped
✅ e2e-local-dev-nest-stable	128	0	26
✅ e2e-local-dev-tanstack-start-	128	0	26
✅ e2e-local-postgres-nest-stable	128	0	26
✅ e2e-local-postgres-tanstack-start-	128	0	26
✅ e2e-local-prod-nest-stable	128	0	26
✅ e2e-local-prod-tanstack-start-	128	0	26
✅ e2e-vercel-prod-nest	126	0	28
✅ e2e-vercel-prod-tanstack-start	126	0	28

✅ vercel-multi-region

App	Passed	Failed	Skipped
✅ nextjs-turbopack	27	0	0

---

📋 View full workflow run

[karthikscale3]

ai review: The decryption changes look correct, but the published @workflow/web package is missing from the changeset.

[karthikscale3]

Reviewed at 85e262c. Implementation looks good; the existing inline changeset note is non-blocking.

[github-actions]

No backport to stable for e8bc7d6 (AI decision).

This is feature work — PR 5 of 7 in a stack that introduces the sealed-box (encp) payload scheme, adding new capability (deriveRunPayloadKeys, DecryptionKey, browser-safe re-exports) to observability tooling. It also builds directly on main-only APIs: git ls-tree origin/stable confirms packages/core/src/sealed-box.ts and packages/core/src/serialization/encryption.ts do not exist on stable, so the cherry-pick could not even work. The "regression" it fixes only materializes once the rest of the sealed-payload stack lands, which is not on the maintenance line.

To override, re-run the Backport to stable workflow manually via workflow_dispatch and paste this commit SHA into the ref input:

e8bc7d6aadcdb5f89de1be71cfcafe5e9085ed25

[TooTallNate]

Replaces #3097. That PR was force-closed as "merged" by GitHub when I
force-pushed its base branch to a commit that happened to contain its head —
GitHub concluded it had merged into its base. Its code never reached main.
It cannot be reopened, so this PR carries the identical work. Review history
on #3097 still applies.

Ordering change: this now targets main directly and should land before
#3096, per the review there. #3096 begins emitting sealed (encp) hook payloads
while workflow inspect --decrypt can only build a symmetric key, so merging it
first would leave those payloads showing as ciphertext placeholders. Landing the
reader first closes that window.

To make this PR stand alone, deriveRunPayloadKeys moved here from #3096 — it
is the capability the reader needs, and its own doc says to use it "anywhere a
run reads its own event log", so it belongs on this side regardless.

---

PR 5 of 7. Stacked on #3096; review the stack in order, starting from #3093.

• feat(core): add encp sealed-box encryption primitive #3093 — the encp sealed-box primitive
• feat(core): route sealed envelopes through the serialization layer #3094 — route sealed envelopes through the serialization layer
• feat: publish each run's X25519 public key on the run entity #3095 — publish each run's public key on the run entity
• feat(core): seal hook payloads to the target run's public key #3096 — resumeHook() seals instead of fetching the key ← the payoff
• feat: decrypt sealed payloads in the dashboard and CLI #3097 (this PR) — decrypt sealed payloads in observability tooling
• feat(core): seal forwarded stream writes to the owner's public key #3098 — seal forwarded stream writes
• feat: return the run public key from the capability probe #3099 — start() gets the key from the probe it already awaits

Why this is required, not optional

Once #3096 lands, a hook resumption from another deployment writes a sealed payload into the run's event log. Observability tooling can't open it: hydrateDataWithKey only ever ran AES-GCM. So the dashboard and CLI would render a 🔒 placeholder on data the user is entitled to read and has already supplied the key for — a visible debugging regression on exactly the runs this work speeds up.

What changed

hydrateDataWithKey delegates to the envelope layer, which dispatches on the 4-byte format prefix, instead of unconditionally decrypting with AES-GCM.

All four o11y key-resolution sites now resolve the run's full key capability rather than just its symmetric key:

Site	Path
@workflow/web-shared	hydrateResourceIOAsync
@workflow/web	use-stream-reader (hand-rolled frame decode)
@workflow/cli	--decrypt field hydration
@workflow/cli	--decrypt stream output

Each already had the raw 32 bytes in hand, so this costs one extra key derivation and no additional requests or round trips.

A caller that supplies only a symmetric key still gets the ciphertext placeholder for sealed payloads rather than a decryption error — that key never could have opened them, so surfacing a failure would be misleading.

Browser bundling

The natural import for the new helper is @workflow/core/serialization, but that module graph reaches node:util and node:async_hooks and cannot be bundled for the browser — which is precisely what the @workflow/core/serialization-format entrypoint exists to avoid. I hit this as a build failure and moved the key helpers to a re-export from that browser-safe entrypoint; the two browser consumers import from there, while the CLI keeps the direct import since it runs on Node.

Verified by walking the built import graph: serialization-format.js reaches 6 modules and zero Node built-ins.

Tests

Two new cases assert the o11y path opens a real sealed payload with the derived keypair, and that the same resolved key still opens the run's own symmetric payloads — a run's event log mixes both.

Core suite 1598 passing, web-shared 160, CLI 78. Zero new lint diagnostics (diffed against a stashed baseline).

[changeset-bot]

🦋 Changeset detected

Latest commit: 916bc93

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 16 packages

Name	Type
@workflow/core	Minor
@workflow/web-shared	Patch
@workflow/web	Patch
@workflow/cli	Patch
@workflow/builders	Patch
@workflow/next	Patch
@workflow/nitro	Patch
@workflow/vitest	Patch
workflow	Minor
@workflow/world-testing	Patch
@workflow/astro	Patch
@workflow/nest	Patch
@workflow/nuxt	Patch
@workflow/rollup	Patch
@workflow/sveltekit	Patch
@workflow/vite	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Jul 28, 2026 12:08am
example-nextjs-workflow-webpack	Building	Preview, Comment	Jul 28, 2026 12:08am
example-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-astro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-express-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-fastify-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-hono-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nestjs-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nitro-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-nuxt-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-sveltekit-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-tanstack-start-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workbench-vite-workflow	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-docs	Ready	Preview, Comment, Open in v0	Jul 28, 2026 12:08am
workflow-swc-playground	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-tarballs	Ready	Preview, Comment	Jul 28, 2026 12:08am
workflow-web	Ready	Preview, Comment	Jul 28, 2026 12:08am

[github-actions]

📊 Workflow Benchmarks

commit 916bc93 · Tue, 28 Jul 2026 00:26:55 GMT · run logs

Backend: vercel · app: nextjs-turbopack

Metric	Scenario	Best (ms)	P75 (ms)	P90 (ms)	P99 (ms)	Samples
TTFS	step	228 (-69%) 💚	1407 🔴 (+24%) 🔻	1449 🔴 (+20%) 🔻	1751 🔴 (+28%) 🔻	30
TTFS	stream	273 (-13%)	1428 🔴 (+30%) 🔻	1438 🔴 (+26%) 🔻	1527 🔴 (+30%) 🔻	30
TTFS	hook + stream	572 (-55%) 💚	1694 🔴 (+21%) 🔻	1740 🔴 (+19%) 🔻	1895 🔴 (+16%) 🔻	30
STSO	1020 steps (1-20)	185 (+8.8%)	327 🔴 (+8.3%)	550 🔴 (+56%) 🔻	681 🔴 (+80%) 🔻	19
STSO	1020 steps (101-120)	205 (+4.1%)	298 🔴 (-12%)	473 🔴 (+16%) 🔻	598 🔴 (+20%) 🔻	19
STSO	1020 steps (1001-1020)	473 (-2.1%)	563 🔴 (-1.9%)	669 🔴 (+3.6%)	852 🔴 (+30%) 🔻	19
WO	1020 steps	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	410726 (-6.4%)	1
SL	stream latency	97 (+4.3%)	196 🔴 (+17%) 🔻	257 🔴 (+9.8%)	592 🔴 (+134%) 🔻	30
SO	stream overhead (text)	126 (-3.8%)	303 🔴 (+4.5%)	400 (+13%)	543 (+29%) 🔻	30
SO	stream overhead (structured)	135 (±0%)	391 🔴 (+50%) 🔻	729 🔴 (+162%) 🔻	5527 🔴 (+1238%) 🔻	30

ℹ️ Metric definitions & methodology

_{Best/P75/P90/P99 deltas compare against the most recent benchmark run on main at the time of this run. 🔻 flags a delta worse than +15%, 💚 one better than −15%.}

_{Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window)}

_{Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost}

_{🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 · STSO (1-20) 20/30/60 · STSO (101-120) 30/45/90 · STSO (1001-1020) 40/60/120}

_{All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor (clientStart) right before start(), so the CI runner’s request and its path through api.vercel.com sit outside every measured window. TTFS = in-deployment start() → first step body (turbo uses the in-process fast path, non-turbo the dispatch path), and includes the VQS dispatch hop plus any /flow cold start. STSO/WO are measured between step bodies on the deployment. SL is measured inside the workflow (parallel reader/writer steps), so it no longer includes the api.vercel.com read path.}

_{Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the /flow invocation for a large fraction of runs, inflating P75+; the Best column shows the fastest (warm-start) sample for comparison.}

[github-actions]

🧪 E2E Test Results

✅ All tests passed

E2E Test Summary

Summary

	Passed	Failed	Skipped	Total
✅ ▲ Vercel Production	1455	0	239	1694
✅ 💻 Local Development	1621	0	227	1848
✅ 📦 Local Production	1621	0	227	1848
✅ 🐘 Local Postgres	1621	0	227	1848
✅ 🪟 Windows	154	0	0	154
✅ 📋 Other	1020	0	212	1232
✅ vercel-multi-region	27	0	0	27
Total	7519	0	1132	8651

Details by Category

✅ ▲ Vercel Production

App	Passed	Failed	Skipped
✅ astro	126	0	28
✅ example	126	0	28
✅ express	126	0	28
✅ fastify	126	0	28
✅ hono	126	0	28
✅ nextjs-turbopack	151	0	3
✅ nextjs-webpack	151	0	3
✅ nitro	126	0	28
✅ nuxt	126	0	28
✅ sveltekit	145	0	9
✅ vite	126	0	28

✅ 💻 Local Development

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 📦 Local Production

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🐘 Local Postgres

App	Passed	Failed	Skipped
✅ astro-stable	128	0	26
✅ express-stable	128	0	26
✅ fastify-stable	128	0	26
✅ hono-stable	128	0	26
✅ nextjs-turbopack-canary	135	0	19
✅ nextjs-turbopack-stable	154	0	0
✅ nextjs-webpack-canary	135	0	19
✅ nextjs-webpack-stable	154	0	0
✅ nitro-stable	128	0	26
✅ nuxt-stable	128	0	26
✅ sveltekit-stable	147	0	7
✅ vite-stable	128	0	26

✅ 🪟 Windows

App	Passed	Failed	Skipped
✅ nextjs-turbopack	154	0	0

✅ 📋 Other

App	Passed	Failed	Skipped
✅ e2e-local-dev-nest-stable	128	0	26
✅ e2e-local-dev-tanstack-start-	128	0	26
✅ e2e-local-postgres-nest-stable	128	0	26
✅ e2e-local-postgres-tanstack-start-	128	0	26
✅ e2e-local-prod-nest-stable	128	0	26
✅ e2e-local-prod-tanstack-start-	128	0	26
✅ e2e-vercel-prod-nest	126	0	28
✅ e2e-vercel-prod-tanstack-start	126	0	28

✅ vercel-multi-region

App	Passed	Failed	Skipped
✅ nextjs-turbopack	27	0	0

---

📋 View full workflow run

[karthikscale3]

ai review: The decryption changes look correct, but the published @workflow/web package is missing from the changeset.

[karthikscale3]

Reviewed at 85e262c. Implementation looks good; the existing inline changeset note is non-blocking.

[github-actions]

No backport to stable for e8bc7d6 (AI decision).

This is feature work — PR 5 of 7 in a stack that introduces the sealed-box (encp) payload scheme, adding new capability (deriveRunPayloadKeys, DecryptionKey, browser-safe re-exports) to observability tooling. It also builds directly on main-only APIs: git ls-tree origin/stable confirms packages/core/src/sealed-box.ts and packages/core/src/serialization/encryption.ts do not exist on stable, so the cherry-pick could not even work. The "regression" it fixes only materializes once the rest of the sealed-payload stack lands, which is not on the maintenance line.

To override, re-run the Backport to stable workflow manually via workflow_dispatch and paste this commit SHA into the ref input:

e8bc7d6aadcdb5f89de1be71cfcafe5e9085ed25