build: emit 0.5.0 + gen 0.2.1 — single emitter version across the tree - #51
Merged
Conversation
…sion, at last The 0.5.0 foundation release integration, and the retirement of a trace-risk on the register since July: the dependency tree previously carried TWO emitter versions (0.4.1 direct, 0.3.1 via dspack-gen's lockfile-frozen range), which is exactly the divergence that could evade gate A3. With dspack-gen 0.2.1 admitting the new emitter, the tree now resolves exactly one dspack-emit@0.5.0 and one dspack-gen@0.2.1, regenerated from the npm registry with no file, tarball, override, or worktree references. Consumer behavior is proven identical, not assumed: the committed catalogs rebuild byte-identically under 0.5.0 (v1 profiles are byte-frozen by the emitter's own pinned gates), the shadcn contract pin stays at v2.3.0 @ 805732c (sha256 verified, self-announcing), and the full battery is green — 155 unit tests across seven packages plus agent and web, renderer parity, typechecks, both static exports, exhibit Playwright 106, composer agent-mode + accessibility 42. Ranges: packages/contracts pins emit exactly (0.5.0, the byte-sync discipline); apps/agent and apps/composer take ^0.5.0 (composer's was in devDependencies — the single-version proof caught the miss); web/composer/ agent take gen ^0.2.1. No representation capabilities are consumed by this swap: profile v2, fidelity, --strict-surface and functions ship in the emitter but Studio's profiles remain v1 and byte-identical. T1-T5 remain unimplemented. No contract pin moves. No v3 migration. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
There was a problem hiding this comment.
Pull request overview
Updates the Studio workspace dependency graph to align on @aestheticfunction/dspack-emit@0.5.0 and @aestheticfunction/dspack-gen@0.2.1, ensuring a single resolved emitter version across the monorepo via updated package manifests and a regenerated pnpm-lock.yaml.
Changes:
- Bump
@aestheticfunction/dspack-emitto0.5.0(contracts pinned; agent/composer via range). - Bump
@aestheticfunction/dspack-gento^0.2.1where used (agent/composer/web). - Regenerate lockfile so
dspack-gen@0.2.1resolvesdspack-emit@0.5.0and no older emitter versions remain.
Reviewed changes
Copilot reviewed 4 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| pnpm-lock.yaml | Regenerated lockfile reflecting dspack-emit@0.5.0 and dspack-gen@0.2.1 resolution across importers/snapshots. |
| packages/contracts/package.json | Pin @aestheticfunction/dspack-emit from 0.4.1 to 0.5.0. |
| apps/agent/package.json | Update deps to @aestheticfunction/dspack-emit@^0.5.0 and @aestheticfunction/dspack-gen@^0.2.1. |
| apps/composer/package.json | Update dep @aestheticfunction/dspack-gen@^0.2.1 and devDep @aestheticfunction/dspack-emit@^0.5.0. |
| apps/web/package.json | Update dep @aestheticfunction/dspack-gen from ^0.2.0 to ^0.2.1. |
Files not reviewed (1)
- pnpm-lock.yaml: Generated file
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Studio integration for the
dspack-emit@0.5.0foundation release (dspack-emit#29, published withgitHead 84031a5), unblocked by dspack-gen#50 /dspack-gen@0.2.1.What this changes
Dependency ranges and the lockfile. Nothing else — no code, no contracts, no profiles, no catalogs.
0.4.1(exact)0.5.0(exact)^0.4.1, gen^0.2.0^0.5.0, gen^0.2.1^0.4.1(devDeps), gen^0.2.0^0.5.0, gen^0.2.1^0.2.0^0.2.1Why it matters beyond the version bump
This retires a trace-risk on the register since July: the tree previously resolved two emitter versions (0.4.1 direct + 0.3.1 via dspack-gen), the exact divergence that could evade gate A3. Now:
Regenerated from the npm registry; zero
file:/tarball/override references (the composer's emit dep hid indevDependencies— the single-version proof caught it).Proof the swap is behaviorally invisible
git statusclean overpackages/contracts/out/afterbuild:catalogs) — v1 profiles are byte-frozen by the emitter's own pinned gates, proven upstream and re-proven here.PINNED shadcn-ui.dspack.json v2.3.0 @ 805732c (sha256 verified).Boundaries
Studio's profiles remain v1 (byte-identical); no v2 authoring is consumed here. No contract pin moves, no shadcn-v3 migration, no T1–T5. Merge and deploy remain separate decisions.
🤖 Generated with Claude Code