Workflows graph extractor

[karthikscale3]

This PR adds a new control flow graph extractor that analyzes bundled workflow files and generates graph manifests for workflow visualization.

Note: The corresponding UI updates for graph viewer are in #456

Changes

• @workflow/builders: Add workflows-extractor.ts that parses workflow bundles using SWC to extract nodes and edges representing step calls, loops, conditionals, and parallel execution patterns
• @workflow/builders: Add createWorkflowsManifest() method to BaseBuilder for generating workflow graph manifests post-bundle
• @workflow/next: Integrate manifest generation into Next.js builder (initial build and watch mode rebuilds)

Output

Generates a workflows.json manifest containing React Flow-compatible graph data for each workflow, including:

• Step nodes with metadata (loop context, conditional branches, parallel groups)
• Edges representing control flow between steps
• Support for transitive step resolution through helper functions

[changeset-bot]

🦋 Changeset detected

Latest commit: f1e5807

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

This PR includes changesets to release 19 packages

Name	Type
@workflow/world-postgres	Patch
@workflow/world-local	Patch
@workflow/sveltekit	Patch
@workflow/builders	Patch
@workflow/nitro	Patch
@workflow/utils	Patch
@workflow/world	Patch
@workflow/core	Patch
@workflow/next	Patch
@workflow/web	Patch
@workflow/cli	Patch
workflow	Patch
@workflow/astro	Patch
@workflow/nuxt	Patch
@workflow/errors	Patch
@workflow/web-shared	Patch
@workflow/world-testing	Patch
@workflow/world-vercel	Patch
@workflow/ai	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

[vercel]

@karthikscale3 is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[pranaygp]

Left a bunch of comments we need to address. Very excited about this!

Let's try and just get things aligned with how we want to do manifests according to the versioning spec. I'll be a nuisance to try and clean this up later

[karthikscale3]

@pranaygp thanks for the review! Great and valid points! Let me do a bit of thinking to address these.

[karthikscale3]

@pranaygp Please take a look at the new iteration when you get a chance. Summary of the changes:

1. Unified the partial manifest.debug.json files that gets generated inside .well-known/workflow/v1/flow and .well-known/workflow/v1/step directories as a single manifest.json.
2. This new manifest.json file gets generated inside the .well-known/workflow/v1 directory for each builder.
3. This manifest.json file is the single source of truth for all workflow metadata including the graph structure needed to build the Control Flow Graphs for the workflows and steps.
4. See below the schema extension that allows this new structure. (A graph field is added to the workflows):

...
"workflows": {
"example/workflows/97_bench.ts": {
"noStepsWorkflow": {
"workflowId": "workflow//example/workflows/97_bench.ts//noStepsWorkflow",
"graph": {
"nodes": [
{
"id": "start",
"type": "workflowStart",
"data": {
"label": "Start: noStepsWorkflow",
"nodeKind": "workflow_start"
}
},
{
"id": "end",
"type": "workflowEnd",
"data": {
"label": "Return",
"nodeKind": "workflow_end"
}
}
],
"edges": [
{
"id": "e_start_end",
"source": "start",
"target": "end",
"type": "default"
}
]
}
},
...

[VaguelySerious]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

[karthikscale3]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

Thanks for a comprehensive review. And the duplicate code between workflow-graph-viewer and workflow-graph-execution-viewer should be addressed with my next set of changes which I am iterating on based on some of the other feedback provided by @pranaygp. I am hoping to push my updates to this PR later today which should address your remaining comments as well.

[karthikscale3]

@pranaygp / @VaguelySerious - Thanks again for the comprehensive reviews. I have iterated further:

• Made sure this feature is disabled for non local backend.
• Addressed all the comments left by @VaguelySerious.
• For representing conditionals, I have introduced a new node to show the actual condition from which the true and false edges branch out.
• Made the node colors consistent and cleaned up the legends and made them more clear.
• @pranaygp - For promise.all, promise.any, and promise.race, I have introduced an overlay container that holds the promises. I have kept the edges leaving each node within the container instead of having a single incoming and outgoing edge going in and out of the overlay container. While this might be cleaner, it won't accurately represent promise.race. In race scenarios, we would ideally want to see exactly which step won the race. Let me know what you think.
• Loops are represented with a looping edge that is attached to the node on the left side.

Known limitation:

• child workflows that are triggered within a step are not shown in the graph. I have left this for now as this requires a recursive extraction and I am not 100% sure of the best way to represent this in the graph.

[VaguelySerious]

LGTM from an o11y and general maintenance perspective, will let @pranaygp voice any concerns about graph extraction, though my take is merge and ITG from here, since it's local-only, oss-ui-only, and isolated. I'm going to add plenty of error boundaries to this code once it's merged, before we release the next version, to assuage any concerns about brittle code.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-nextjs-workflow-webpack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-astro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-express-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-fastify-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-hono-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nitro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nuxt-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-sveltekit-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-vite-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workflow-docs	Ready	Preview, Comment	Dec 22, 2025 8:17pm

[pranaygp]

lgtm to merge and iterate. Let's just fix up the merge conflicts and get this in - thanks so much for this and the multiple iterations. Very excited!

[karthikscale3]

Fixed the merge conflicts and pushed it up. Ready to merge once CI completes successfully! Thanks again for the reviews!

[karthikscale3]

This PR adds a new control flow graph extractor that analyzes bundled workflow files and generates graph manifests for workflow visualization.

Note: The corresponding UI updates for graph viewer are in #456

Changes

• @workflow/builders: Add workflows-extractor.ts that parses workflow bundles using SWC to extract nodes and edges representing step calls, loops, conditionals, and parallel execution patterns
• @workflow/builders: Add createWorkflowsManifest() method to BaseBuilder for generating workflow graph manifests post-bundle
• @workflow/next: Integrate manifest generation into Next.js builder (initial build and watch mode rebuilds)

Output

Generates a workflows.json manifest containing React Flow-compatible graph data for each workflow, including:

• Step nodes with metadata (loop context, conditional branches, parallel groups)
• Edges representing control flow between steps
• Support for transitive step resolution through helper functions

[changeset-bot]

🦋 Changeset detected

Latest commit: f1e5807

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

This PR includes changesets to release 19 packages

Name	Type
@workflow/world-postgres	Patch
@workflow/world-local	Patch
@workflow/sveltekit	Patch
@workflow/builders	Patch
@workflow/nitro	Patch
@workflow/utils	Patch
@workflow/world	Patch
@workflow/core	Patch
@workflow/next	Patch
@workflow/web	Patch
@workflow/cli	Patch
workflow	Patch
@workflow/astro	Patch
@workflow/nuxt	Patch
@workflow/errors	Patch
@workflow/web-shared	Patch
@workflow/world-testing	Patch
@workflow/world-vercel	Patch
@workflow/ai	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

[vercel]

@karthikscale3 is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[pranaygp]

Left a bunch of comments we need to address. Very excited about this!

Let's try and just get things aligned with how we want to do manifests according to the versioning spec. I'll be a nuisance to try and clean this up later

[karthikscale3]

@pranaygp thanks for the review! Great and valid points! Let me do a bit of thinking to address these.

[karthikscale3]

@pranaygp Please take a look at the new iteration when you get a chance. Summary of the changes:

1. Unified the partial manifest.debug.json files that gets generated inside .well-known/workflow/v1/flow and .well-known/workflow/v1/step directories as a single manifest.json.
2. This new manifest.json file gets generated inside the .well-known/workflow/v1 directory for each builder.
3. This manifest.json file is the single source of truth for all workflow metadata including the graph structure needed to build the Control Flow Graphs for the workflows and steps.
4. See below the schema extension that allows this new structure. (A graph field is added to the workflows):

...
"workflows": {
"example/workflows/97_bench.ts": {
"noStepsWorkflow": {
"workflowId": "workflow//example/workflows/97_bench.ts//noStepsWorkflow",
"graph": {
"nodes": [
{
"id": "start",
"type": "workflowStart",
"data": {
"label": "Start: noStepsWorkflow",
"nodeKind": "workflow_start"
}
},
{
"id": "end",
"type": "workflowEnd",
"data": {
"label": "Return",
"nodeKind": "workflow_end"
}
}
],
"edges": [
{
"id": "e_start_end",
"source": "start",
"target": "end",
"type": "default"
}
]
}
},
...

[VaguelySerious]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

[karthikscale3]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

Thanks for a comprehensive review. And the duplicate code between workflow-graph-viewer and workflow-graph-execution-viewer should be addressed with my next set of changes which I am iterating on based on some of the other feedback provided by @pranaygp. I am hoping to push my updates to this PR later today which should address your remaining comments as well.

[karthikscale3]

@pranaygp / @VaguelySerious - Thanks again for the comprehensive reviews. I have iterated further:

• Made sure this feature is disabled for non local backend.
• Addressed all the comments left by @VaguelySerious.
• For representing conditionals, I have introduced a new node to show the actual condition from which the true and false edges branch out.
• Made the node colors consistent and cleaned up the legends and made them more clear.
• @pranaygp - For promise.all, promise.any, and promise.race, I have introduced an overlay container that holds the promises. I have kept the edges leaving each node within the container instead of having a single incoming and outgoing edge going in and out of the overlay container. While this might be cleaner, it won't accurately represent promise.race. In race scenarios, we would ideally want to see exactly which step won the race. Let me know what you think.
• Loops are represented with a looping edge that is attached to the node on the left side.

Known limitation:

• child workflows that are triggered within a step are not shown in the graph. I have left this for now as this requires a recursive extraction and I am not 100% sure of the best way to represent this in the graph.

[VaguelySerious]

LGTM from an o11y and general maintenance perspective, will let @pranaygp voice any concerns about graph extraction, though my take is merge and ITG from here, since it's local-only, oss-ui-only, and isolated. I'm going to add plenty of error boundaries to this code once it's merged, before we release the next version, to assuage any concerns about brittle code.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-nextjs-workflow-webpack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-astro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-express-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-fastify-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-hono-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nitro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nuxt-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-sveltekit-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-vite-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workflow-docs	Ready	Preview, Comment	Dec 22, 2025 8:17pm

[pranaygp]

lgtm to merge and iterate. Let's just fix up the merge conflicts and get this in - thanks so much for this and the multiple iterations. Very excited!

[karthikscale3]

Fixed the merge conflicts and pushed it up. Ready to merge once CI completes successfully! Thanks again for the reviews!

[karthikscale3]

This PR adds a new control flow graph extractor that analyzes bundled workflow files and generates graph manifests for workflow visualization.

Note: The corresponding UI updates for graph viewer are in #456

Changes

• @workflow/builders: Add workflows-extractor.ts that parses workflow bundles using SWC to extract nodes and edges representing step calls, loops, conditionals, and parallel execution patterns
• @workflow/builders: Add createWorkflowsManifest() method to BaseBuilder for generating workflow graph manifests post-bundle
• @workflow/next: Integrate manifest generation into Next.js builder (initial build and watch mode rebuilds)

Output

Generates a workflows.json manifest containing React Flow-compatible graph data for each workflow, including:

• Step nodes with metadata (loop context, conditional branches, parallel groups)
• Edges representing control flow between steps
• Support for transitive step resolution through helper functions

[changeset-bot]

🦋 Changeset detected

Latest commit: f1e5807

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

This PR includes changesets to release 19 packages

Name	Type
@workflow/world-postgres	Patch
@workflow/world-local	Patch
@workflow/sveltekit	Patch
@workflow/builders	Patch
@workflow/nitro	Patch
@workflow/utils	Patch
@workflow/world	Patch
@workflow/core	Patch
@workflow/next	Patch
@workflow/web	Patch
@workflow/cli	Patch
workflow	Patch
@workflow/astro	Patch
@workflow/nuxt	Patch
@workflow/errors	Patch
@workflow/web-shared	Patch
@workflow/world-testing	Patch
@workflow/world-vercel	Patch
@workflow/ai	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

[vercel]

@karthikscale3 is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[pranaygp]

Left a bunch of comments we need to address. Very excited about this!

Let's try and just get things aligned with how we want to do manifests according to the versioning spec. I'll be a nuisance to try and clean this up later

[karthikscale3]

@pranaygp thanks for the review! Great and valid points! Let me do a bit of thinking to address these.

[karthikscale3]

@pranaygp Please take a look at the new iteration when you get a chance. Summary of the changes:

1. Unified the partial manifest.debug.json files that gets generated inside .well-known/workflow/v1/flow and .well-known/workflow/v1/step directories as a single manifest.json.
2. This new manifest.json file gets generated inside the .well-known/workflow/v1 directory for each builder.
3. This manifest.json file is the single source of truth for all workflow metadata including the graph structure needed to build the Control Flow Graphs for the workflows and steps.
4. See below the schema extension that allows this new structure. (A graph field is added to the workflows):

...
"workflows": {
"example/workflows/97_bench.ts": {
"noStepsWorkflow": {
"workflowId": "workflow//example/workflows/97_bench.ts//noStepsWorkflow",
"graph": {
"nodes": [
{
"id": "start",
"type": "workflowStart",
"data": {
"label": "Start: noStepsWorkflow",
"nodeKind": "workflow_start"
}
},
{
"id": "end",
"type": "workflowEnd",
"data": {
"label": "Return",
"nodeKind": "workflow_end"
}
}
],
"edges": [
{
"id": "e_start_end",
"source": "start",
"target": "end",
"type": "default"
}
]
}
},
...

[VaguelySerious]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

[karthikscale3]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

Thanks for a comprehensive review. And the duplicate code between workflow-graph-viewer and workflow-graph-execution-viewer should be addressed with my next set of changes which I am iterating on based on some of the other feedback provided by @pranaygp. I am hoping to push my updates to this PR later today which should address your remaining comments as well.

[karthikscale3]

@pranaygp / @VaguelySerious - Thanks again for the comprehensive reviews. I have iterated further:

• Made sure this feature is disabled for non local backend.
• Addressed all the comments left by @VaguelySerious.
• For representing conditionals, I have introduced a new node to show the actual condition from which the true and false edges branch out.
• Made the node colors consistent and cleaned up the legends and made them more clear.
• @pranaygp - For promise.all, promise.any, and promise.race, I have introduced an overlay container that holds the promises. I have kept the edges leaving each node within the container instead of having a single incoming and outgoing edge going in and out of the overlay container. While this might be cleaner, it won't accurately represent promise.race. In race scenarios, we would ideally want to see exactly which step won the race. Let me know what you think.
• Loops are represented with a looping edge that is attached to the node on the left side.

Known limitation:

• child workflows that are triggered within a step are not shown in the graph. I have left this for now as this requires a recursive extraction and I am not 100% sure of the best way to represent this in the graph.

[VaguelySerious]

LGTM from an o11y and general maintenance perspective, will let @pranaygp voice any concerns about graph extraction, though my take is merge and ITG from here, since it's local-only, oss-ui-only, and isolated. I'm going to add plenty of error boundaries to this code once it's merged, before we release the next version, to assuage any concerns about brittle code.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-nextjs-workflow-webpack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-astro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-express-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-fastify-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-hono-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nitro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nuxt-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-sveltekit-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-vite-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workflow-docs	Ready	Preview, Comment	Dec 22, 2025 8:17pm

[pranaygp]

lgtm to merge and iterate. Let's just fix up the merge conflicts and get this in - thanks so much for this and the multiple iterations. Very excited!

[karthikscale3]

Fixed the merge conflicts and pushed it up. Ready to merge once CI completes successfully! Thanks again for the reviews!

[karthikscale3]

This PR adds a new control flow graph extractor that analyzes bundled workflow files and generates graph manifests for workflow visualization.

Note: The corresponding UI updates for graph viewer are in #456

Changes

• @workflow/builders: Add workflows-extractor.ts that parses workflow bundles using SWC to extract nodes and edges representing step calls, loops, conditionals, and parallel execution patterns
• @workflow/builders: Add createWorkflowsManifest() method to BaseBuilder for generating workflow graph manifests post-bundle
• @workflow/next: Integrate manifest generation into Next.js builder (initial build and watch mode rebuilds)

Output

Generates a workflows.json manifest containing React Flow-compatible graph data for each workflow, including:

• Step nodes with metadata (loop context, conditional branches, parallel groups)
• Edges representing control flow between steps
• Support for transitive step resolution through helper functions

[changeset-bot]

🦋 Changeset detected

Latest commit: f1e5807

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

This PR includes changesets to release 19 packages

Name	Type
@workflow/world-postgres	Patch
@workflow/world-local	Patch
@workflow/sveltekit	Patch
@workflow/builders	Patch
@workflow/nitro	Patch
@workflow/utils	Patch
@workflow/world	Patch
@workflow/core	Patch
@workflow/next	Patch
@workflow/web	Patch
@workflow/cli	Patch
workflow	Patch
@workflow/astro	Patch
@workflow/nuxt	Patch
@workflow/errors	Patch
@workflow/web-shared	Patch
@workflow/world-testing	Patch
@workflow/world-vercel	Patch
@workflow/ai	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

[vercel]

@karthikscale3 is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[pranaygp]

Left a bunch of comments we need to address. Very excited about this!

Let's try and just get things aligned with how we want to do manifests according to the versioning spec. I'll be a nuisance to try and clean this up later

[karthikscale3]

@pranaygp thanks for the review! Great and valid points! Let me do a bit of thinking to address these.

[karthikscale3]

@pranaygp Please take a look at the new iteration when you get a chance. Summary of the changes:

1. Unified the partial manifest.debug.json files that gets generated inside .well-known/workflow/v1/flow and .well-known/workflow/v1/step directories as a single manifest.json.
2. This new manifest.json file gets generated inside the .well-known/workflow/v1 directory for each builder.
3. This manifest.json file is the single source of truth for all workflow metadata including the graph structure needed to build the Control Flow Graphs for the workflows and steps.
4. See below the schema extension that allows this new structure. (A graph field is added to the workflows):

...
"workflows": {
"example/workflows/97_bench.ts": {
"noStepsWorkflow": {
"workflowId": "workflow//example/workflows/97_bench.ts//noStepsWorkflow",
"graph": {
"nodes": [
{
"id": "start",
"type": "workflowStart",
"data": {
"label": "Start: noStepsWorkflow",
"nodeKind": "workflow_start"
}
},
{
"id": "end",
"type": "workflowEnd",
"data": {
"label": "Return",
"nodeKind": "workflow_end"
}
}
],
"edges": [
{
"id": "e_start_end",
"source": "start",
"target": "end",
"type": "default"
}
]
}
},
...

[VaguelySerious]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

[karthikscale3]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

Thanks for a comprehensive review. And the duplicate code between workflow-graph-viewer and workflow-graph-execution-viewer should be addressed with my next set of changes which I am iterating on based on some of the other feedback provided by @pranaygp. I am hoping to push my updates to this PR later today which should address your remaining comments as well.

[karthikscale3]

@pranaygp / @VaguelySerious - Thanks again for the comprehensive reviews. I have iterated further:

• Made sure this feature is disabled for non local backend.
• Addressed all the comments left by @VaguelySerious.
• For representing conditionals, I have introduced a new node to show the actual condition from which the true and false edges branch out.
• Made the node colors consistent and cleaned up the legends and made them more clear.
• @pranaygp - For promise.all, promise.any, and promise.race, I have introduced an overlay container that holds the promises. I have kept the edges leaving each node within the container instead of having a single incoming and outgoing edge going in and out of the overlay container. While this might be cleaner, it won't accurately represent promise.race. In race scenarios, we would ideally want to see exactly which step won the race. Let me know what you think.
• Loops are represented with a looping edge that is attached to the node on the left side.

Known limitation:

• child workflows that are triggered within a step are not shown in the graph. I have left this for now as this requires a recursive extraction and I am not 100% sure of the best way to represent this in the graph.

[VaguelySerious]

LGTM from an o11y and general maintenance perspective, will let @pranaygp voice any concerns about graph extraction, though my take is merge and ITG from here, since it's local-only, oss-ui-only, and isolated. I'm going to add plenty of error boundaries to this code once it's merged, before we release the next version, to assuage any concerns about brittle code.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-nextjs-workflow-webpack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-astro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-express-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-fastify-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-hono-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nitro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nuxt-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-sveltekit-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-vite-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workflow-docs	Ready	Preview, Comment	Dec 22, 2025 8:17pm

[pranaygp]

lgtm to merge and iterate. Let's just fix up the merge conflicts and get this in - thanks so much for this and the multiple iterations. Very excited!

[karthikscale3]

Fixed the merge conflicts and pushed it up. Ready to merge once CI completes successfully! Thanks again for the reviews!

[karthikscale3]

This PR adds a new control flow graph extractor that analyzes bundled workflow files and generates graph manifests for workflow visualization.

Note: The corresponding UI updates for graph viewer are in #456

Changes

• @workflow/builders: Add workflows-extractor.ts that parses workflow bundles using SWC to extract nodes and edges representing step calls, loops, conditionals, and parallel execution patterns
• @workflow/builders: Add createWorkflowsManifest() method to BaseBuilder for generating workflow graph manifests post-bundle
• @workflow/next: Integrate manifest generation into Next.js builder (initial build and watch mode rebuilds)

Output

Generates a workflows.json manifest containing React Flow-compatible graph data for each workflow, including:

• Step nodes with metadata (loop context, conditional branches, parallel groups)
• Edges representing control flow between steps
• Support for transitive step resolution through helper functions

[changeset-bot]

🦋 Changeset detected

Latest commit: f1e5807

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

This PR includes changesets to release 19 packages

Name	Type
@workflow/world-postgres	Patch
@workflow/world-local	Patch
@workflow/sveltekit	Patch
@workflow/builders	Patch
@workflow/nitro	Patch
@workflow/utils	Patch
@workflow/world	Patch
@workflow/core	Patch
@workflow/next	Patch
@workflow/web	Patch
@workflow/cli	Patch
workflow	Patch
@workflow/astro	Patch
@workflow/nuxt	Patch
@workflow/errors	Patch
@workflow/web-shared	Patch
@workflow/world-testing	Patch
@workflow/world-vercel	Patch
@workflow/ai	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

[vercel]

@karthikscale3 is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[pranaygp]

Left a bunch of comments we need to address. Very excited about this!

Let's try and just get things aligned with how we want to do manifests according to the versioning spec. I'll be a nuisance to try and clean this up later

[karthikscale3]

@pranaygp thanks for the review! Great and valid points! Let me do a bit of thinking to address these.

[karthikscale3]

@pranaygp Please take a look at the new iteration when you get a chance. Summary of the changes:

1. Unified the partial manifest.debug.json files that gets generated inside .well-known/workflow/v1/flow and .well-known/workflow/v1/step directories as a single manifest.json.
2. This new manifest.json file gets generated inside the .well-known/workflow/v1 directory for each builder.
3. This manifest.json file is the single source of truth for all workflow metadata including the graph structure needed to build the Control Flow Graphs for the workflows and steps.
4. See below the schema extension that allows this new structure. (A graph field is added to the workflows):

...
"workflows": {
"example/workflows/97_bench.ts": {
"noStepsWorkflow": {
"workflowId": "workflow//example/workflows/97_bench.ts//noStepsWorkflow",
"graph": {
"nodes": [
{
"id": "start",
"type": "workflowStart",
"data": {
"label": "Start: noStepsWorkflow",
"nodeKind": "workflow_start"
}
},
{
"id": "end",
"type": "workflowEnd",
"data": {
"label": "Return",
"nodeKind": "workflow_end"
}
}
],
"edges": [
{
"id": "e_start_end",
"source": "start",
"target": "end",
"type": "default"
}
]
}
},
...

[VaguelySerious]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

[karthikscale3]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

Thanks for a comprehensive review. And the duplicate code between workflow-graph-viewer and workflow-graph-execution-viewer should be addressed with my next set of changes which I am iterating on based on some of the other feedback provided by @pranaygp. I am hoping to push my updates to this PR later today which should address your remaining comments as well.

[karthikscale3]

@pranaygp / @VaguelySerious - Thanks again for the comprehensive reviews. I have iterated further:

• Made sure this feature is disabled for non local backend.
• Addressed all the comments left by @VaguelySerious.
• For representing conditionals, I have introduced a new node to show the actual condition from which the true and false edges branch out.
• Made the node colors consistent and cleaned up the legends and made them more clear.
• @pranaygp - For promise.all, promise.any, and promise.race, I have introduced an overlay container that holds the promises. I have kept the edges leaving each node within the container instead of having a single incoming and outgoing edge going in and out of the overlay container. While this might be cleaner, it won't accurately represent promise.race. In race scenarios, we would ideally want to see exactly which step won the race. Let me know what you think.
• Loops are represented with a looping edge that is attached to the node on the left side.

Known limitation:

• child workflows that are triggered within a step are not shown in the graph. I have left this for now as this requires a recursive extraction and I am not 100% sure of the best way to represent this in the graph.

[VaguelySerious]

LGTM from an o11y and general maintenance perspective, will let @pranaygp voice any concerns about graph extraction, though my take is merge and ITG from here, since it's local-only, oss-ui-only, and isolated. I'm going to add plenty of error boundaries to this code once it's merged, before we release the next version, to assuage any concerns about brittle code.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-nextjs-workflow-webpack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-astro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-express-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-fastify-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-hono-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nitro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nuxt-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-sveltekit-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-vite-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workflow-docs	Ready	Preview, Comment	Dec 22, 2025 8:17pm

[pranaygp]

lgtm to merge and iterate. Let's just fix up the merge conflicts and get this in - thanks so much for this and the multiple iterations. Very excited!

[karthikscale3]

Fixed the merge conflicts and pushed it up. Ready to merge once CI completes successfully! Thanks again for the reviews!

[karthikscale3]

This PR adds a new control flow graph extractor that analyzes bundled workflow files and generates graph manifests for workflow visualization.

Note: The corresponding UI updates for graph viewer are in #456

Changes

• @workflow/builders: Add workflows-extractor.ts that parses workflow bundles using SWC to extract nodes and edges representing step calls, loops, conditionals, and parallel execution patterns
• @workflow/builders: Add createWorkflowsManifest() method to BaseBuilder for generating workflow graph manifests post-bundle
• @workflow/next: Integrate manifest generation into Next.js builder (initial build and watch mode rebuilds)

Output

Generates a workflows.json manifest containing React Flow-compatible graph data for each workflow, including:

• Step nodes with metadata (loop context, conditional branches, parallel groups)
• Edges representing control flow between steps
• Support for transitive step resolution through helper functions

[changeset-bot]

🦋 Changeset detected

Latest commit: f1e5807

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

This PR includes changesets to release 19 packages

Name	Type
@workflow/world-postgres	Patch
@workflow/world-local	Patch
@workflow/sveltekit	Patch
@workflow/builders	Patch
@workflow/nitro	Patch
@workflow/utils	Patch
@workflow/world	Patch
@workflow/core	Patch
@workflow/next	Patch
@workflow/web	Patch
@workflow/cli	Patch
workflow	Patch
@workflow/astro	Patch
@workflow/nuxt	Patch
@workflow/errors	Patch
@workflow/web-shared	Patch
@workflow/world-testing	Patch
@workflow/world-vercel	Patch
@workflow/ai	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

[vercel]

@karthikscale3 is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[pranaygp]

Left a bunch of comments we need to address. Very excited about this!

Let's try and just get things aligned with how we want to do manifests according to the versioning spec. I'll be a nuisance to try and clean this up later

[karthikscale3]

@pranaygp thanks for the review! Great and valid points! Let me do a bit of thinking to address these.

[karthikscale3]

@pranaygp Please take a look at the new iteration when you get a chance. Summary of the changes:

1. Unified the partial manifest.debug.json files that gets generated inside .well-known/workflow/v1/flow and .well-known/workflow/v1/step directories as a single manifest.json.
2. This new manifest.json file gets generated inside the .well-known/workflow/v1 directory for each builder.
3. This manifest.json file is the single source of truth for all workflow metadata including the graph structure needed to build the Control Flow Graphs for the workflows and steps.
4. See below the schema extension that allows this new structure. (A graph field is added to the workflows):

...
"workflows": {
"example/workflows/97_bench.ts": {
"noStepsWorkflow": {
"workflowId": "workflow//example/workflows/97_bench.ts//noStepsWorkflow",
"graph": {
"nodes": [
{
"id": "start",
"type": "workflowStart",
"data": {
"label": "Start: noStepsWorkflow",
"nodeKind": "workflow_start"
}
},
{
"id": "end",
"type": "workflowEnd",
"data": {
"label": "Return",
"nodeKind": "workflow_end"
}
}
],
"edges": [
{
"id": "e_start_end",
"source": "start",
"target": "end",
"type": "default"
}
]
}
},
...

[VaguelySerious]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

[karthikscale3]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

Thanks for a comprehensive review. And the duplicate code between workflow-graph-viewer and workflow-graph-execution-viewer should be addressed with my next set of changes which I am iterating on based on some of the other feedback provided by @pranaygp. I am hoping to push my updates to this PR later today which should address your remaining comments as well.

[karthikscale3]

@pranaygp / @VaguelySerious - Thanks again for the comprehensive reviews. I have iterated further:

• Made sure this feature is disabled for non local backend.
• Addressed all the comments left by @VaguelySerious.
• For representing conditionals, I have introduced a new node to show the actual condition from which the true and false edges branch out.
• Made the node colors consistent and cleaned up the legends and made them more clear.
• @pranaygp - For promise.all, promise.any, and promise.race, I have introduced an overlay container that holds the promises. I have kept the edges leaving each node within the container instead of having a single incoming and outgoing edge going in and out of the overlay container. While this might be cleaner, it won't accurately represent promise.race. In race scenarios, we would ideally want to see exactly which step won the race. Let me know what you think.
• Loops are represented with a looping edge that is attached to the node on the left side.

Known limitation:

• child workflows that are triggered within a step are not shown in the graph. I have left this for now as this requires a recursive extraction and I am not 100% sure of the best way to represent this in the graph.

[VaguelySerious]

LGTM from an o11y and general maintenance perspective, will let @pranaygp voice any concerns about graph extraction, though my take is merge and ITG from here, since it's local-only, oss-ui-only, and isolated. I'm going to add plenty of error boundaries to this code once it's merged, before we release the next version, to assuage any concerns about brittle code.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-nextjs-workflow-webpack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-astro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-express-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-fastify-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-hono-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nitro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nuxt-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-sveltekit-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-vite-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workflow-docs	Ready	Preview, Comment	Dec 22, 2025 8:17pm

[pranaygp]

lgtm to merge and iterate. Let's just fix up the merge conflicts and get this in - thanks so much for this and the multiple iterations. Very excited!

[karthikscale3]

Fixed the merge conflicts and pushed it up. Ready to merge once CI completes successfully! Thanks again for the reviews!

[karthikscale3]

This PR adds a new control flow graph extractor that analyzes bundled workflow files and generates graph manifests for workflow visualization.

Note: The corresponding UI updates for graph viewer are in #456

Changes

• @workflow/builders: Add workflows-extractor.ts that parses workflow bundles using SWC to extract nodes and edges representing step calls, loops, conditionals, and parallel execution patterns
• @workflow/builders: Add createWorkflowsManifest() method to BaseBuilder for generating workflow graph manifests post-bundle
• @workflow/next: Integrate manifest generation into Next.js builder (initial build and watch mode rebuilds)

Output

Generates a workflows.json manifest containing React Flow-compatible graph data for each workflow, including:

• Step nodes with metadata (loop context, conditional branches, parallel groups)
• Edges representing control flow between steps
• Support for transitive step resolution through helper functions

[changeset-bot]

🦋 Changeset detected

Latest commit: f1e5807

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

This PR includes changesets to release 19 packages

Name	Type
@workflow/world-postgres	Patch
@workflow/world-local	Patch
@workflow/sveltekit	Patch
@workflow/builders	Patch
@workflow/nitro	Patch
@workflow/utils	Patch
@workflow/world	Patch
@workflow/core	Patch
@workflow/next	Patch
@workflow/web	Patch
@workflow/cli	Patch
workflow	Patch
@workflow/astro	Patch
@workflow/nuxt	Patch
@workflow/errors	Patch
@workflow/web-shared	Patch
@workflow/world-testing	Patch
@workflow/world-vercel	Patch
@workflow/ai	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

[vercel]

@karthikscale3 is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[pranaygp]

Left a bunch of comments we need to address. Very excited about this!

Let's try and just get things aligned with how we want to do manifests according to the versioning spec. I'll be a nuisance to try and clean this up later

[karthikscale3]

@pranaygp thanks for the review! Great and valid points! Let me do a bit of thinking to address these.

[karthikscale3]

@pranaygp Please take a look at the new iteration when you get a chance. Summary of the changes:

1. Unified the partial manifest.debug.json files that gets generated inside .well-known/workflow/v1/flow and .well-known/workflow/v1/step directories as a single manifest.json.
2. This new manifest.json file gets generated inside the .well-known/workflow/v1 directory for each builder.
3. This manifest.json file is the single source of truth for all workflow metadata including the graph structure needed to build the Control Flow Graphs for the workflows and steps.
4. See below the schema extension that allows this new structure. (A graph field is added to the workflows):

...
"workflows": {
"example/workflows/97_bench.ts": {
"noStepsWorkflow": {
"workflowId": "workflow//example/workflows/97_bench.ts//noStepsWorkflow",
"graph": {
"nodes": [
{
"id": "start",
"type": "workflowStart",
"data": {
"label": "Start: noStepsWorkflow",
"nodeKind": "workflow_start"
}
},
{
"id": "end",
"type": "workflowEnd",
"data": {
"label": "Return",
"nodeKind": "workflow_end"
}
}
],
"edges": [
{
"id": "e_start_end",
"source": "start",
"target": "end",
"type": "default"
}
]
}
},
...

[VaguelySerious]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

[karthikscale3]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

Thanks for a comprehensive review. And the duplicate code between workflow-graph-viewer and workflow-graph-execution-viewer should be addressed with my next set of changes which I am iterating on based on some of the other feedback provided by @pranaygp. I am hoping to push my updates to this PR later today which should address your remaining comments as well.

[karthikscale3]

@pranaygp / @VaguelySerious - Thanks again for the comprehensive reviews. I have iterated further:

• Made sure this feature is disabled for non local backend.
• Addressed all the comments left by @VaguelySerious.
• For representing conditionals, I have introduced a new node to show the actual condition from which the true and false edges branch out.
• Made the node colors consistent and cleaned up the legends and made them more clear.
• @pranaygp - For promise.all, promise.any, and promise.race, I have introduced an overlay container that holds the promises. I have kept the edges leaving each node within the container instead of having a single incoming and outgoing edge going in and out of the overlay container. While this might be cleaner, it won't accurately represent promise.race. In race scenarios, we would ideally want to see exactly which step won the race. Let me know what you think.
• Loops are represented with a looping edge that is attached to the node on the left side.

Known limitation:

• child workflows that are triggered within a step are not shown in the graph. I have left this for now as this requires a recursive extraction and I am not 100% sure of the best way to represent this in the graph.

[VaguelySerious]

LGTM from an o11y and general maintenance perspective, will let @pranaygp voice any concerns about graph extraction, though my take is merge and ITG from here, since it's local-only, oss-ui-only, and isolated. I'm going to add plenty of error boundaries to this code once it's merged, before we release the next version, to assuage any concerns about brittle code.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-nextjs-workflow-webpack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-astro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-express-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-fastify-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-hono-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nitro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nuxt-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-sveltekit-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-vite-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workflow-docs	Ready	Preview, Comment	Dec 22, 2025 8:17pm

[pranaygp]

lgtm to merge and iterate. Let's just fix up the merge conflicts and get this in - thanks so much for this and the multiple iterations. Very excited!

[karthikscale3]

Fixed the merge conflicts and pushed it up. Ready to merge once CI completes successfully! Thanks again for the reviews!

[karthikscale3]

This PR adds a new control flow graph extractor that analyzes bundled workflow files and generates graph manifests for workflow visualization.

Note: The corresponding UI updates for graph viewer are in #456

Changes

• @workflow/builders: Add workflows-extractor.ts that parses workflow bundles using SWC to extract nodes and edges representing step calls, loops, conditionals, and parallel execution patterns
• @workflow/builders: Add createWorkflowsManifest() method to BaseBuilder for generating workflow graph manifests post-bundle
• @workflow/next: Integrate manifest generation into Next.js builder (initial build and watch mode rebuilds)

Output

Generates a workflows.json manifest containing React Flow-compatible graph data for each workflow, including:

• Step nodes with metadata (loop context, conditional branches, parallel groups)
• Edges representing control flow between steps
• Support for transitive step resolution through helper functions

[changeset-bot]

🦋 Changeset detected

Latest commit: f1e5807

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

This PR includes changesets to release 19 packages

Name	Type
@workflow/world-postgres	Patch
@workflow/world-local	Patch
@workflow/sveltekit	Patch
@workflow/builders	Patch
@workflow/nitro	Patch
@workflow/utils	Patch
@workflow/world	Patch
@workflow/core	Patch
@workflow/next	Patch
@workflow/web	Patch
@workflow/cli	Patch
workflow	Patch
@workflow/astro	Patch
@workflow/nuxt	Patch
@workflow/errors	Patch
@workflow/web-shared	Patch
@workflow/world-testing	Patch
@workflow/world-vercel	Patch
@workflow/ai	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

[vercel]

@karthikscale3 is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[pranaygp]

Left a bunch of comments we need to address. Very excited about this!

Let's try and just get things aligned with how we want to do manifests according to the versioning spec. I'll be a nuisance to try and clean this up later

[karthikscale3]

@pranaygp thanks for the review! Great and valid points! Let me do a bit of thinking to address these.

[karthikscale3]

@pranaygp Please take a look at the new iteration when you get a chance. Summary of the changes:

1. Unified the partial manifest.debug.json files that gets generated inside .well-known/workflow/v1/flow and .well-known/workflow/v1/step directories as a single manifest.json.
2. This new manifest.json file gets generated inside the .well-known/workflow/v1 directory for each builder.
3. This manifest.json file is the single source of truth for all workflow metadata including the graph structure needed to build the Control Flow Graphs for the workflows and steps.
4. See below the schema extension that allows this new structure. (A graph field is added to the workflows):

...
"workflows": {
"example/workflows/97_bench.ts": {
"noStepsWorkflow": {
"workflowId": "workflow//example/workflows/97_bench.ts//noStepsWorkflow",
"graph": {
"nodes": [
{
"id": "start",
"type": "workflowStart",
"data": {
"label": "Start: noStepsWorkflow",
"nodeKind": "workflow_start"
}
},
{
"id": "end",
"type": "workflowEnd",
"data": {
"label": "Return",
"nodeKind": "workflow_end"
}
}
],
"edges": [
{
"id": "e_start_end",
"source": "start",
"target": "end",
"type": "default"
}
]
}
},
...

[VaguelySerious]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

[karthikscale3]

Overall LGTM and super excited for this!

The only major comment is that we should be disabling this feature for non-local environments until we ship a way to reliably fetch manifests via the world interface. Once that's done, I think we're good to merge.

A minor comment is that workflow-graph-viewer and workflow-graph-execution-viewer seem to duplicate a ton of code and might be hard to iterate on since we don't have a view that shows both side-by-side. Not something you need to do in this PR, but maybe something to think about, e.g. if debug=1 (we already use this search param), the run-detail-view may show both graph viewers side by side, allowing for quick style iteration, and also gives some confidence if we e.g. ask AI to DRY up the graph code a bit.

I also have a ton of tiny nits that I would love to see addressed but aren't blocking merge.

Thanks for a comprehensive review. And the duplicate code between workflow-graph-viewer and workflow-graph-execution-viewer should be addressed with my next set of changes which I am iterating on based on some of the other feedback provided by @pranaygp. I am hoping to push my updates to this PR later today which should address your remaining comments as well.

[karthikscale3]

@pranaygp / @VaguelySerious - Thanks again for the comprehensive reviews. I have iterated further:

• Made sure this feature is disabled for non local backend.
• Addressed all the comments left by @VaguelySerious.
• For representing conditionals, I have introduced a new node to show the actual condition from which the true and false edges branch out.
• Made the node colors consistent and cleaned up the legends and made them more clear.
• @pranaygp - For promise.all, promise.any, and promise.race, I have introduced an overlay container that holds the promises. I have kept the edges leaving each node within the container instead of having a single incoming and outgoing edge going in and out of the overlay container. While this might be cleaner, it won't accurately represent promise.race. In race scenarios, we would ideally want to see exactly which step won the race. Let me know what you think.
• Loops are represented with a looping edge that is attached to the node on the left side.

Known limitation:

• child workflows that are triggered within a step are not shown in the graph. I have left this for now as this requires a recursive extraction and I am not 100% sure of the best way to represent this in the graph.

[VaguelySerious]

LGTM from an o11y and general maintenance perspective, will let @pranaygp voice any concerns about graph extraction, though my take is merge and ITG from here, since it's local-only, oss-ui-only, and isolated. I'm going to add plenty of error boundaries to this code once it's merged, before we release the next version, to assuage any concerns about brittle code.

[vercel]

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

Project	Deployment	Review	Updated (UTC)
example-nextjs-workflow-turbopack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-nextjs-workflow-webpack	Ready	Preview, Comment	Dec 22, 2025 8:17pm
example-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-astro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-express-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-fastify-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-hono-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nitro-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-nuxt-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-sveltekit-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workbench-vite-workflow	Ready	Preview, Comment	Dec 22, 2025 8:17pm
workflow-docs	Ready	Preview, Comment	Dec 22, 2025 8:17pm

[pranaygp]

lgtm to merge and iterate. Let's just fix up the merge conflicts and get this in - thanks so much for this and the multiple iterations. Very excited!

[karthikscale3]

Fixed the merge conflicts and pushed it up. Ready to merge once CI completes successfully! Thanks again for the reviews!