fix: re-pin vendored core to dspack-gen v0.5.0 and re-sync the coupled copies

CHANGELOG.md

@@ -2,6 +2,52 @@
 
 ## Unreleased
 
+The vendored `@aestheticfunction/dspack-gen/core` bundle moves from the
+v0.1.2 release tag (`c5bfd6d`) to the v0.5.0 release tag (`5203569`), the
+current latest. **This changes what `validate-ui` rejects** — it is a
+behavior change to a published tool, not a maintenance bump:
+
+- Gate S2 now enforces sub-component **containment** (spec v0.4 §5.1): a
+  declared sub-component is valid only within its declaring compound's
+  subtree, so a `dialog-title` with no `dialog` ancestor is now a
+  vocabulary error. Previously accepted. (dspack-gen 0.3.0)
+- Gate S3 now evaluates **`requiredCategories`** on `required-composition`
+  rules (spec v0.4 §4.3), so a contract can require that a matching node
+  carry a descendant drawn from a named category. (dspack-gen 0.2.2)
+- `get-generation-context` serves a richer system prompt: each component's
+  vocabulary line now carries that component's `composition.notes` from the
+  contract, capped at two sentences. Prompt material only — no S-gate
+  changes with it. (dspack-gen 0.5.0)
+- Unchanged: `forbiddenCategories` was already evaluated at v0.1.2, and the
+  lookup tools and gate S1 are unaffected. Exactly four shipped `src/core`
+  files differ across the whole v0.1.2 -> v0.5.0 move: `lint/vocabulary.ts`
+  (S2 containment), `contract.ts` + `lint/rules.ts` (S3 requiredCategories),
+  and `compiler.ts` (the prompt change). dspack-gen 0.4.0/0.5.0's other work
+  — repair loop, casualty-free generation view, join-id view — lives in
+  `run/`, which ds-mcp does not vendor.
+
+Coupled updates that had to land in the same change:
+
+- `examples/shadcn-ui-v04.dspack.json` re-synced from the spec repo
+  (contract 2.3.0 -> 3.2.0: 8 -> 34 components, 8 -> 49 rules). It exercises
+  both new evaluations, and it is the file the quick start downloads.
+- `src/schema/dspack.v0.4.schema.json` re-synced from the spec repo, which
+  had added `requiredCategories` to `required-composition` (§4.3). Without
+  it the loader **rejected the spec's own example contract**. All four
+  schemas are now tracked in `scripts/check-sync.mjs`; v0.1-v0.3 were
+  already byte-exact.
+- The golden-context test now reads dspack-gen's contract fixture
+  (`src/tests/fixtures/shadcn.v0_4.contract.json`, newly drift-tracked)
+  instead of the shipped example. The golden is compiled from that contract,
+  and the two upstreams are no longer byte-equal — the spec repo moved to
+  3.2.0 while dspack-gen's fixture stayed at 2.3.0. The test now compares
+  compiler output against the compiler's own input, which is what it was
+  always meant to pin.
+- `rule.button-carries-text` (new in contract 3.2.0) requires a button's
+  own text, so the `textScope: subtree` fixture in
+  `generation-tools.test.ts` moves its label onto the button; the trigger
+  still carries no text of its own, which is what that test pins.
+
 - The v0.1 example `examples/shadcn-ui.dspack.json` is renamed to
   `examples/shadcn-ui-v01.dspack.json` (DX-1, D4): the old unversioned
   filename collided with the dspack repository's v0.4

README.md

@@ -164,16 +164,41 @@ the guarantee.
 dspack-gen is a **build-time** dependency: its `core` subpath is bundled
 into the published package (`dist/vendor/dspack-gen-core.js`) from a
 commit-pinned devDependency, so installing ds-mcp from npm pulls nothing
-from git. The default posture is **tag-pinned**: the pin is the commit of
-dspack-gen's latest release tag, so the vendored core corresponds exactly
-to a published dspack-gen version. CI watches this two ways:
-`scripts/check-core-pin.mjs` fails loudly when a newer dspack-gen release
-changes shipped `src/core` files (test files are excluded — the documented
-escape for intentional ahead-of-release pins), and the golden-context test
-byte-compares `get-generation-context` output against dspack-gen's own
-compiler golden. Updating governance semantics means re-pinning to the new
-release tag commit, `npm install`, `npm run build`, verifying the golden
-tests, and republishing ds-mcp.
+from git. The posture is **tag-pinned**: the pin is always the commit of a
+dspack-gen *release tag*, so the vendored core corresponds exactly to a
+published dspack-gen version.
+
+**Currently vendored: dspack-gen `v0.5.0`** (`5203569`), dspack-gen's
+latest release. Moving here from v0.1.2 widened what `validate-ui` rejects,
+in exactly two places. Gate S2 now enforces sub-component **containment**
+(spec v0.4 §5.1): a declared sub-component is valid only inside its
+declaring compound's subtree, so a `dialog-title` with no `dialog` ancestor
+is a vocabulary error rather than an accepted node. Gate S3 now evaluates
+**`requiredCategories`** on `required-composition` rules (§4.3), letting a
+contract require that a matching node have a descendant drawn from a named
+category. Surfaces that passed under the older core can fail under this one
+— that is the point of the move, and it is why re-pinning is a deliberate
+release step rather than an automatic follow. `forbiddenCategories` was
+already evaluated at v0.1.2 and is unchanged, as are the lookup tools.
+
+`get-generation-context` also serves a richer system prompt: from
+dspack-gen 0.5.0 each component's vocabulary line carries that component's
+`composition.notes` from the contract (capped at two sentences). Nothing
+about the S-gates changes with it — it is prompt material, and prompt
+steering is not enforcement.
+
+CI watches the vendoring three ways. `scripts/check-core-pin.mjs` fails
+loudly when a newer dspack-gen release changes shipped `src/core` files
+(test files are excluded — the documented escape for intentional
+ahead-of-release pins). `scripts/check-sync.mjs` byte-compares every copied
+artifact against its upstream, including the four dspack JSON Schemas the
+loader validates against — a stale schema copy is not cosmetic, it makes
+ds-mcp refuse contracts the spec considers valid. And the golden-context
+test byte-compares `get-generation-context` output against dspack-gen's own
+compiler golden, read against the contract dspack-gen compiled that golden
+from. Re-pinning means moving the devDependency to the new release tag
+commit, `npm install`, `npm run build`, `node scripts/check-sync.mjs
+--write`, verifying the golden tests, and republishing ds-mcp.
 
 ## Requirements