Skip to content

docs(DX-2): PROFILES.md — writing an emit profile - #23

Merged
ryandmonk merged 1 commit into
mainfrom
docs/dx2-emit-profile-guide
Jul 22, 2026
Merged

docs(DX-2): PROFILES.md — writing an emit profile#23
ryandmonk merged 1 commit into
mainfrom
docs/dx2-emit-profile-guide

Conversation

@ryandmonk

Copy link
Copy Markdown
Contributor

DX-2 companion (per the accepted RFC §6 DX-2: "emit-profile guide in dspack-emit, linked from the main one").

  • docs/PROFILES.md: what a profile is (pure data; source-agnostic engine), where it lives (your codebase, against the published package — with the studio's astryx-profile.ts as the working external reference, and the in-repo shadcnProfile reserved for ecosystem-canonical contracts), the full Profile anatomy with mechanical-vs-judgment labeling, the three judgment calls (what synthesizes, what's a casualty, how compounds flatten), and validation via transform/emitSurface.
  • Documented import surface verified against the published package (transform, emitSurface, validateCatalog, shadcnProfile, Profile all exported), and the external-authoring claim verified against the studio's real profile.
  • README links the guide from the charter block; dspack's ADOPTING.md links here at step 12.

Docs only — no engine or profile changes.

🤖 Generated with Claude Code

Profiles are pure data authored in the consumer's codebase against the
published package — the studio's external astryx-profile.ts is the
reference for exactly that pattern; the in-repo shadcnProfile (with
goldens and the parity suite) is only for ecosystem-canonical contracts.
Documents the Profile anatomy, the three judgment calls (synthesis,
casualties, compound flattening), the never-silent-loss stance, and
validation via transform/emitSurface. README links the guide.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Copilot AI review requested due to automatic review settings July 22, 2026 18:58

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds an “emit profile” authoring guide to dspack-emit and links it from the README so external consumers can write their own profiles against the published package API (per DX-2 / RFC companion doc goal).

Changes:

  • Adds docs/PROFILES.md explaining what an emit profile is, where it should live, its shape, and how to validate it via transform / emitSurface.
  • Updates README.md to link to the new guide and the broader adoption path.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
README.md Adds a pointer to the new profile authoring guide and adoption guide.
docs/PROFILES.md New documentation detailing profile structure, judgment points, and validation workflow.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread docs/PROFILES.md
Comment on lines +44 to +53
| Field | What it is | Mode |
|---|---|---|
| `catalogTitle`, `catalogDescription`, `catalogIdBase`, `instructions` | Catalog identity; the versioned `$id` is built from `catalogIdBase` | mechanical |
| `primaryColorToken` | Which contract token (`category` + `name`) supplies `theme.primaryColor` | judgment (small) |
| `components: ComponentPlan[]` | One plan per mapped dspack component | mostly mechanical, see below |
| `synthesized: ComponentPlan[]` | Target primitives your contract does **not** contain (Text, Column, …). dspack describes a component library, not a layout system; renderable surfaces need structure, so you synthesize it — and it is recorded as a fidelity finding, never smuggled in | **judgment** |
| `casualtyComponents` | Contract components with no faithful target representation: `{dspackId, attempted, class, reason}` — documented and warned, not emitted | **judgment** |
| `intentionallyOmitted` | Ids deliberately not mapped (not casualties either). Must stay documented, never silent | **judgment** |
| `surfaceSynthesis` | Which synthesized primitives the surface emitter uses for text leaves (`textComponent`/`textProp`) and for wrapping multiple children in single-child slots (`wrapComponent`/`wrapChildrenProp`) | mechanical once `synthesized` is decided |

@ryandmonk
ryandmonk merged commit 953a5e9 into main Jul 22, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants