You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 53fbf49
Browse filesBrowse the repository at this point in the historyBrowse files
test(automation): pin the control-flow trio's designer forms (#4045) (#4064)
`loop` / `parallel` / `try_catch` had NO descriptor assertions — config-schemas.test.ts
covered the CRUD quartet, `assignment` and `screen`, so the designer's input for the
entire control-flow trio was unguarded.
These pin intent, not current bytes. All three publish a form description that is
deliberately SHALLOWER and LOOSER than its Zod counterpart in control-flow.zod.ts:
region keys (`loop.body`, `parallel.branches[].nodes/edges`, `try_catch.try/catch`)
publish `{ type: 'array' }` with NO `items`, so a sub-graph stays opaque — it is
edited on the canvas, not in a property form — while the Zod side is
`z.array(FlowNodeSchema)`; and `collection`/`iteratorVariable` omit the Zod-only
`minLength`/`default`.
That corrects a premise of #4045: these were treated as redundant copies awaiting
de-duplication by a single Zod source. They are a second artifact with a different
job, and the gaps are deliberate — naively generating them would nest a form for
every node inside a loop body.
Verified to bite: simulating a naive z.toJSONSchema swap (deep `items` under
body.nodes plus minLength/default) turns both new loop tests red, naming
`loop.body.nodes must stay opaque (no items)`.
Tests only; empty changeset since nothing releases.
0 commit comments