objectstack-ai
diff --git a/‎.changeset/view-union-branch-focus.md‎
Lines changed: 54 additions & 0 deletions b/‎.changeset/view-union-branch-focus.md‎
Lines changed: 54 additions & 0 deletions
diff --git a/‎packages/metadata-protocol/src/protocol.save-union-issues.test.ts‎
Lines changed: 89 additions & 0 deletions b/‎packages/metadata-protocol/src/protocol.save-union-issues.test.ts‎
Lines changed: 89 additions & 0 deletions
@@ -0,0 +1,54 @@
+---
+"@objectstack/spec": patch
+---
+
+fix(spec): a failed `view` parse reports the branch the body claims, not the one that complains loudest (#7510)
+
+`ViewMetadataSchema` is a union of four members, and when a `viewKind`-carrying
+ViewItem failed on a nested key, the message the author got was the CONTAINER
+branch's. Measured through the real write path (`saveMetaItem`) on
+`origin/main` @ `9051802`, a form field whose `publicPicker` carried an unknown
+`sort` subkey was correctly refused with:
+
+```
+[invalid_metadata] view/lead.contact failed spec validation: <root>: Invalid input;
+<root>: Unrecognized key(s) on this view container: `viewKind`, `config`.
+  • `viewKind` belongs to a single VIEW, not to the container. Wrap it: …
+```
+
+The key the author mistyped appears nowhere; what they get instead is a
+confident, detailed instruction to restructure a container that was correct all
+along — and an author (or an agent) who follows it mangles a working document.
+
+**Why it happened.** Every consumer of a failed union in this repo ranks
+branches by `[issue count, carries an unrecognized_keys]`. On such a body the
+container branch reports exactly ONE root `unrecognized_keys` (`viewKind` and
+`config` are not container keys), while the ViewItem branch reports exactly ONE
+nested `invalid_union` whose real key sits one level below where the tiebreak
+looks. One issue each, and the unknown-key bonus handed it to the branch that
+understood the body least. Not a `publicPicker` quirk: an unknown form-field
+key, a bad field enum and a typo'd column summary all reproduced it.
+
+**The fix.** The union now focuses a failed parse on the branch the body
+CLAIMS, using `selectViewMetadataBranch` — the same rule `diagnoseViewMetadata`
+has answered with since #6391, so Studio's 422 and a consumer's diagnosis can no
+longer describe one body two ways. Branches that are not the claimed one are
+replaced, in place, by the "wrong kind at the root" issue shape that every
+ranking already drops, so the claimed branch is what remains to be rendered.
+
+The card's repro now reads:
+
+```
+config.sections.0.fields.0.publicPicker:
+  Unrecognized key(s) on this public picker configuration: `sort`.
+```
+
+**No acceptance change**, by construction: the focusing is a `$ZodCheck` that
+runs after the union has reached its verdict and can only rewrite an existing
+issue's `errors` — it adds no issue and removes none. Verdicts, parse output and
+top-level issue codes are byte-identical across the 42-body corpus in
+`view-union-diagnostics.test.ts` plus 11 more measured for this change. The
+`errors` array keeps its length and order for positional consumers, the
+`invalid_union` envelope is untouched, a body with no discriminant is left to
+the ranking exactly as before, and a genuine container failure still reads the
+#4001 wrap prescription verbatim.
@@ -174,6 +174,95 @@ describe('#5364 saveMetaItem 422 expands union branches', () => {
     });
 });
 
+/**
+ * #7510 — the 422 for a ViewItem body names the key the AUTHOR typed.
+ *
+ * #5364 (above) got a field name onto the wire at all. It did not settle WHICH
+ * branch's field name, and for a `viewKind`-carrying item the shared ranking
+ * picked the container branch: the author was told to restructure a correct
+ * container, in detail, with confidence, while the subkey they actually
+ * mistyped went unmentioned. `ViewMetadataSchema` now focuses a failed union on
+ * the branch the body claims (`spec/ui/view.zod.ts` → `focusClaimedBranch`), so
+ * the expansion below has the right branch to expand.
+ *
+ * Pinned HERE and not only in spec because this is the door the defect was
+ * measured through — `saveMetaItem`'s 422 is what Studio renders, and a spec
+ * fix that did not reach this envelope would be a fix nobody sees.
+ */
+describe('#7510 the 422 for a broken ViewItem names its own key, not the container\'s', () => {
+    /** The card's repro: a form ViewItem whose field's `publicPicker` carries `sort`. */
+    const pickerReproView = () => ({
+        name: 'lead.contact',
+        object: 'lead',
+        viewKind: 'form',
+        label: 'Contact us',
+        config: {
+            type: 'simple',
+            data: { provider: 'object', object: 'lead' },
+            sections: [{
+                label: 'About you',
+                fields: [{ field: 'owner', publicPicker: { displayFields: ['name'], sort: [{ field: 'email', order: 'desc' }] } }],
+            }],
+        },
+    });
+
+    it('the issue\'s body: `sort` reaches the author, the container prescription does not', async () => {
+        const { protocol, rows } = makeProtocol();
+
+        const err = await rejection(save(protocol, pickerReproView(), 'lead.contact'));
+
+        expect(err.code).toBe('INVALID_METADATA');
+        expect(err.status).toBe(422);
+        // Load-bearing: the verdict is unchanged — refused, nothing persisted.
+        // #7510 moves which refusal is explained, never whether it is one.
+        expect(rows.size).toBe(0);
+
+        // The union's own entry is still entry 0, unmoved (#5364's additive
+        // contract) — focusing happens inside its `errors`, not around it.
+        expect(err.issues[0]).toEqual({ path: '', message: 'Invalid input', code: 'invalid_union' });
+
+        const unknownKey = err.issues.find((i: any) => i.code === 'unrecognized_keys');
+        expect(unknownKey).toBeDefined();
+        expect(unknownKey.message).toContain('`sort`');
+        expect(unknownKey.path).toBe('config.sections.0.fields.0.publicPicker');
+
+        // ⛔ The measured misdirect, gone from the whole envelope: on
+        // `origin/main` @ `9051802` this message was the container branch's.
+        expect(err.message).not.toContain('belongs to a single VIEW, not to the container');
+        expect(JSON.stringify(err.issues)).not.toContain('this view container');
+    });
+
+    it('the same item minus the bad subkey still saves', async () => {
+        const { protocol, rows } = makeProtocol();
+        const item: any = pickerReproView();
+        delete item.config.sections[0].fields[0].publicPicker.sort;
+
+        const result = await save(protocol, item, 'lead.contact');
+
+        expect(result.success).toBe(true);
+        expect(rows.size).toBe(1);
+    });
+
+    it('a genuine container failure keeps the container prescription', async () => {
+        // Constraint (c) of the card: the #4001 guidance text is good, and a
+        // body that really is a container with wrong-layer keys still reads it.
+        const { protocol, rows } = makeProtocol();
+
+        const err = await rejection(save(protocol, {
+            name: 'lead',
+            object: 'lead',
+            list: { type: 'grid', columns: [{ field: 'title' }] },
+            type: 'grid',
+            columns: [{ field: 'title' }],
+        }, 'lead'));
+
+        expect(err.status).toBe(422);
+        expect(rows.size).toBe(0);
+        expect(err.message).toContain('Unrecognized key(s) on this view container');
+        expect(err.message).toContain('belongs to a single VIEW, not to the container');
+    });
+});
+
 describe('#5364 zodIssuesToMetadataIssues — the shared ranking, verbatim', () => {
     const union = (errors: unknown[][], path: unknown[] = []) =>
         ({ code: 'invalid_union', message: 'Invalid input', path, errors });