@design-intelligence/ghost 0.30.0 → 0.31.1

package/dist/init-payloads/vessel-light/register.email.md

@@ -1,43 +0,0 @@
----
-for: Transactional email only.
-materials:
-  - materials/examples/email.html
----
-
-Condition: this node applies only to email. In any other medium, everything
-below is a violation.
-
-Email clients do not honor the web contract. Custom properties, external
-stylesheets, flex layout, and webfonts are unreliable materials here.
-
-Email inverts the material contract deliberately. Transcribe token values by
-hand instead of referencing tokens — every hex below is a transcription of
-`materials/tokens.css`, which stays the single source; if a token changes,
-re-transcribe.
-
-Use `#1a1a1a` (`--color-gray-900`, foreground) for text, `#999999`
-(`--color-gray-500`, muted) for muted text, and `#e8e8e8` (`--color-gray-200`,
-border) for borders when the email needs the Vessel palette.
-
-Keep the surface radius on cards and the control radius on buttons (see
-signature.shape). The values survive even when the token names cannot travel.
-
-Build with table layout, a 600px wrapper, predictable cells, and bulletproof
-buttons. Email fidelity is made from boring structure.
-
-HK Grotesk falls back to the system stack. The voice must survive without the
-font file.
-
-The soul survives the body swap: monochrome spine, quiet factual copy, one
-primary action, no celebration.
-
-Email gets exactly one expressive moment: a header band or the figure that
-matters, in one expression hue, transcribed by hand like every value here —
-amber is `#f6b44a` (`--expression-1`). One moment, one hue. A receipt is
-allowed one degree of warmth; it is not allowed a palette.
-
-Do not add further color to compensate for email constraints. Constraint is
-not permission to perform.
-
-Hardcoding hex here is fidelity, not drift. The check exemption is the
-condition itself.

package/dist/init-payloads/vessel-light/signature.palette.md

@@ -1,45 +0,0 @@
----
-for: Color beyond the base roles, in any register.
-materials:
-  - materials/tokens.css
----
-
-This is Vessel's answer to palette — it stands until you replace it.
-
-The relationship is fixed: one brand at different volumes. A monochrome spine
-is the default atmosphere in every medium — calm, legible, and resistant to
-novelty — and a closed expression set supplies the atmosphere, with volume
-set by register, never by taste.
-
-Vessel's current answer: the base palette is monochrome gray, and the
-expression palette is five named hues and only these — amber
-(`--expression-1`), periwinkle (`--expression-2`), clay (`--expression-3`),
-orchid (`--expression-4`), sage (`--expression-5`). Expressive color outside
-this set is not expression; it is another brand. An invented hue is not a
-bolder Vessel; it is a different brand.
-
-The volume ladder, by register:
-
-Product UI: expression lives only in data visualization. A chart may use the
-hues; the interface around it stays monochrome.
-
-Data-dense consoles: one hue family may mark status. Nothing atmospheric.
-Charts inside a console keep the product carve-out — hues stay inside the
-plot area and never leak into rows, badges, or headers.
-
-Email: exactly one expressive moment per message — a header band or the
-figure that matters. One hue, quiet everywhere else.
-
-Editorial: expression is sanctioned atmosphere — a tinted dark section, a
-colored pull-quote accent, a duotone moment. Never more than two hues per
-page. Loudness comes from commitment to few colors at scale, not variety.
-
-Two constants that outrank the ladder: expression never touches what you
-click — buttons, inputs, and links stay monochrome in every register — and
-the status roles are not expression; they keep their meanings everywhere and
-never moonlight as atmosphere.
-
-To adapt: edit the `--expression-*` values (and the gray ramp, if the spine
-changes) in `materials/tokens.css` and restate this node's current answer.
-The ladder — a quiet spine, a closed hue set, register-gated volume — is the
-part worth keeping.

package/dist/init-payloads/vessel-light/signature.shape.md

@@ -1,27 +0,0 @@
----
-for: Choosing or implementing any radius or corner treatment.
-materials:
-  - materials/tokens.css
-  - materials/primitives.css
----
-
-This is Vessel's answer to shape — it stands until you replace it.
-
-The relationship is fixed: controls and surfaces carry different radius
-roles, and the two never swap. Buttons and text inputs use
-`--radius-control`; cards and other surfaces use `--radius-surface`.
-
-Vessel's current answer: controls are pills (`--radius-control: 999px`) and
-surfaces take the 20px signature radius (`--radius-surface: 20px`). The pill
-is Vessel's most visible control signature; a rectangular button is not a
-variant, it is a different design system. Never give a button the surface
-radius — a rectangular button is the fastest tell that the output is not
-Vessel.
-
-20px is a considered position: rounder than default shadcn, but not bubbly.
-Use the radius system as restraint, not as decoration.
-
-To adapt: edit the `--radius-control` and `--radius-surface` values in
-`materials/tokens.css` and restate this node's current answer. The
-role split — one radius for what you click, one for what contains — is the
-part worth keeping.