feat: Let the AI add steps and ports inside a subgraph

[camielvs]

Description

The PR below this one made the assistant change existing things wherever they
live. Creating something new still only worked at the top level, which left one
job impossible: getting a value into or out of a subgraph. That needs a new port
on the subgraph itself, and there was no way to ask for one.

Adding a step, an input, or an output can now target a subgraph. Ask for
something without saying where and nothing changes — it goes to the top level as
before. Name a subgraph, or open one and say "add a filter step here", and it
goes inside that one instead. An input added inside a subgraph shows up as a new
input port on that subgraph step, which is how you feed a value into it.

If you name something that isn't a subgraph, it says so and tells you how to add
at the top level instead, rather than failing quietly.

Getting a value in or out now finishes the job. A port on the boundary is
only a third of the work — it also has to be wired to the step inside the
subgraph that uses the value, and to whatever feeds it in the parent. Asked for
this, the assistant used to create the port and stop, leaving a value that
reaches nothing and two fresh validation errors where there had been none. It
now does all three, so "feed this into <subgraph>" is a single request that
ends with a working pipeline.

Two smaller corrections in the same area. Asked to fix a problem while you
happen to be looking at a subgraph, it no longer drops the fix into that
subgraph — repairs land on whatever they're repairing, wherever that lives. And
it now gets the subgraph you're viewing handed to it directly rather than
matching on its name, which was ambiguous whenever two subgraphs at different
levels shared a name.

Related Issue and Pull requests

Stacked on #2683 → #2687 → #2686 → #2685 → #2655.

Re-cut alongside #2683 — see that PR for why. This one is now purely the new
capability: it adds to the PR below rather than rewriting it.

Type of Change

• New feature

Checklist

• I have tested this does not break current pipelines / runs functionality
• I have tested the changes on staging

Test Instructions

1. Open a pipeline with a subgraph. Ask the chat: "add a <component> inside
   <subgraph name>". Open the subgraph and confirm it's there, and that it did
   not also appear at the top level.
2. Open a subgraph, then say "add an input called threshold here" — it should go
   into the subgraph you're looking at, not the top level.
3. Go back up: that subgraph step should now have a threshold input port on it.
4. Ask for the whole route in one go — "feed <some top-level value> into
   <subgraph name> so <inner step> can use it". It should end with the port
   wired on both sides: connected inside the subgraph to the step that uses it,
   and connected in the parent to the value you named. Ask it to validate
   afterwards — there should be no new errors, and in particular no unconnected
   port left behind.
5. Same again with an output — it should appear as an output port on the subgraph
   step, and the route out should get wired end to end the same way.
6. Ask for something with no location at all ("add a <component>") while looking
   at the top level — it should go to the top level, as before.
7. Ask it to add something "inside" a step that isn't a subgraph — it should
   explain that step isn't a subgraph rather than silently doing something else.
8. Open a pipeline with a validation problem on a top-level step, then open a
   subgraph before asking the chat to fix it. The fix should land on the top-level
   step, not inside the subgraph you happen to be looking at.
9. Undo (Cmd/Ctrl+Z) after a nested add, and confirm the pipeline still saves.

Additional Comments

The earlier version of this PR also returned the subgraph trail on every single
edit so the assistant could quote it back. That's been dropped: the assistant
already knows which subgraph it targeted, because it passed the id, so the extra
field was duplicating information it had. It's still told to name the subgraph it
changed in its reply — the canvas doesn't move, so you need to be told where to
look.

[github-actions]

🎩 Preview

A preview build has been created at: 08-31-fix_ai_subgraph_editing/c2f554c

[camielvs]

• feat: Let the AI add steps and ports inside a subgraph #2684 👈 (View in Graphite)
• fix: Apply AI edits in the subgraph the entity lives in #2683
• refactor: Resolve AI mutation targets and explain refusals #2687
• fix: Make AI chat chips work for steps inside subgraphs #2686
• refactor: Find pipeline entities inside nested subgraphs #2685
• fix: Give AI full visibility into subgraphs #2655
• fix: Misc Bugfixes #2646
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[camielvs]

Reviewed this PR on its own base (08-31-fix_ai_subgraph_error_reporting). The bridge/tool code checks out: nested adds do surface as ports on the parent task (resolvedComponentSpec is a live proxy read inside observer renders), resolveDestination's subgraph guard cannot misfire, a nested add undoes cleanly and the doc round-trips byte-identical, and all 66 tests in toolBridge.test.ts / csomTools.test.ts pass.

The substantive risk is in the prompt guidance rather than the code. Inline comments below.

One finding with no line to attach to: src/routes/v2/shared/components/AiChat/serializeSpecForAi.ts:10 still asserts "Edits always target the root spec; the path is a hint, not a target" — which this stack makes the opposite of true. The file isn't in this diff, so it needs a touch either here or in #2683.

---

🤖 Generated with Claude Code

_{- If this code review was useful, please react with 👍. Otherwise, react with 👎.}

[camielvs]

The unattached finding — the stale serializeSpecForAi.ts header claiming edits always target the root — is fixed in #2683, where the rest of that wording already changed.

[morgan-wowk]

🤖 Automated review

Approving. Add-into-subgraph honors the same resolver/refusal contract as #2687: resolveDestination returns root for undefined, reuses resolveTarget(..., "task") otherwise, and refuses a non-subgraph or unknown destination — fail-closed. New entity ids use the shared global counter (unique within and across the target subgraph), and names are uniquified within the destination spec so adding a colliding name into a subgraph can't create a duplicate. activeSubgraphTaskId is sourced from the currently-viewed subgraph, so "add here" targets what the user is actually looking at. addTask hydrates then resolves against the current spec (fail-closed if the subgraph was detached mid-await). Good tests. Nit: minor whitespace misalignment in subgraphBridge.test.ts (the formatter will catch it).

[camielvs]

Merge activity

• Sep 4, 12:51 AM UTC: A user started a stack merge that includes this pull request via Graphite.
• Sep 4, 1:22 AM UTC: Graphite rebased this pull request as part of a merge.
• Sep 4, 1:26 AM UTC: @camielvs merged this pull request with Graphite.