docs: Add map format examples to defineStack() documentation

[Copilot]

defineStack() now accepts both array and map (Record) format for all named metadata collections, but docs only showed the array pattern. Updates the primary learning paths and reference docs to showcase both formats.

P0 — Primary learning paths

• core-concepts.mdx — First defineStack() example now uses <Tabs> for Array/Map format with a callout explaining the feature
• common-patterns.mdx — CRUD pattern and "Putting It All Together" use <Tabs> with both variants

P1 — Error/compatibility/architecture docs

• troubleshooting.mdx — "Object not found" fix shows both registration patterns
• backward-compatibility.mdx — Map format listed as guaranteed-stable under SemVer
• data-flow.mdx / protocol-diagram.mdx — Flow tables note "(array or map format)"

Example (core-concepts.mdx)

// Array format (traditional)
defineStack({
  objects: [{ name: 'user', label: 'User', fields: [...] }],
});

// Map format — key becomes `name`
defineStack({
  objects: {
    user: { label: 'User', fields: { ... } },
  },
});

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
objectstack-play	Canceled		Feb 14, 2026 7:02pm
spec	Ready	Preview, Comment	Feb 14, 2026 7:02pm

[Copilot]

Pull request overview

This PR adds documentation for the map (Record) format support in defineStack(), complementing the existing array format examples. The changes demonstrate that top-level metadata collections (objects, apps, flows, etc.) can use either array or map format, with map keys automatically injected as the name field.

Changes:

• Added Tabs components to core learning paths showing both array and map format examples side-by-side
• Updated architecture documentation tables to note "(array or map format)" support
• Added SemVer guarantee that both input formats remain stable within major versions

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
content/docs/getting-started/core-concepts.mdx	Added Tabs with Array/Map format examples and explanatory Callout for first defineStack() encounter
content/docs/guides/common-patterns.mdx	Added Tabs for CRUD pattern and "Putting It All Together" section comparing both formats
content/docs/guides/troubleshooting.mdx	Updated "Object not found" troubleshooting to show both registration patterns
content/docs/guides/cheatsheets/backward-compatibility.mdx	Added guarantee that both array and map formats are SemVer-stable
content/docs/guides/data-flow.mdx	Added note "(array or map format)" to configuration flow table
content/docs/guides/cheatsheets/protocol-diagram.mdx	Added note "(array or map format)" to metadata resolution table

[Copilot]

This callout states that map/array formats apply to "all named metadata collections (objects, apps, flows, etc.)", which is correct. However, it's important to clarify that the fields property within objects ONLY accepts map format (Record), never array format. The existing "Array Format" tab above (lines 41-42) incorrectly shows fields as an array, which contradicts the ObjectSchema definition where fields is defined as z.record(z.string().regex(...), FieldSchema). This should be corrected to avoid misleading developers into thinking fields can be either format.

[Copilot]

The Map Format tab correctly shows fields as a Record/map (lines 56-68). However, the Array Format tab above (lines 30-42, not in the changed region) incorrectly shows fields as an array, which is invalid according to ObjectSchema where fields is defined as z.record(z.string().regex(...), FieldSchema). This creates confusion by implying fields can be either format. The Array Format example should be corrected to also use map syntax for fields - only the top-level objects should differ between the two tabs.

[Copilot]

Good - the Map Format tab correctly shows fields: {/* ... */} (map syntax) as placeholders on lines 472 and 474. However, the Array Format tab above (lines 444, 446) shows fields: [/* ... */] which implies fields can be an array. This is incorrect - according to ObjectSchema, fields must always be a map/Record. The Array Format examples should also use fields: {/* ... */} placeholders.