@ammduncan/easel 0.2.21 → 0.2.22

package/CHANGELOG.md

@@ -2,6 +2,15 @@
 
 All notable changes to easel. This project adheres to [Semantic Versioning](https://semver.org/).
 
+## 0.2.22 — 2026-05-23
+
+### Changed
+- **Prose reading column now centres in the card.** The capped 880px prose sat flush-left, leaving a large empty right gutter next to any `.full-bleed` block. Added `margin-left/right: auto` so the reading column centres — balanced whether or not a full-bleed sibling has widened the body, and full-bleed blocks now break out symmetrically around it.
+
+### Docs
+- **Mockup height guidance rewritten to "match the source's real frame", both directions.** The first draft of this rule ("always size to content, never pad to desktop height") was too absolute — a full desktop *screen* genuinely floats its content in a ~720–800px viewport, and cropping that to content height misrepresents it as much as over-padding a small component does. New guidance distinguishes: component → content height (don't pad to fake desktop size); full screen/page → realistic viewport proportions (don't crop to content). Either way, copy the source's exact height if it has one. Updated skill + inline `push` tool description.
+- Reinforced "hug the source" for app recreations in the inline tool description (pull exact colors/spacing/sizing/radii/fonts; say so if you can't reach the actuals rather than passing off an approximation as accurate).
+
 ## 0.2.21 — 2026-05-23
 
 ### Fixed

package/dist/client/viewer.js

@@ -704,6 +704,16 @@ body > .wrap > p, body > .wrap > .deck, body > .wrap > .lede,
 body > .wrap > ul, body > .wrap > ol, body > .wrap > blockquote,
 body > .wrap > h1, body > .wrap > h2, body > .wrap > h3, body > .wrap > h4 {
   max-width: 880px;
+  /* Centre the reading column in the card so it stays balanced whether or not
+     a .full-bleed sibling has widened the body. Without auto margins the
+     capped prose sits flush-left with a large empty right gutter next to any
+     full-bleed block. !important is required because authors routinely set an
+     inline margin shorthand like 0 0 16px on prose — that sets the left/right
+     margins to 0 and would otherwise win over the stylesheet, leaving that one
+     element flush-left while its siblings centre (inconsistent column edge).
+     We only force the horizontal margins; inline top/bottom spacing is kept. */
+  margin-left: auto !important;
+  margin-right: auto !important;
 }
 body > *:first-child { margin-top: 0 !important; }
 body > *:last-child { margin-bottom: 0 !important; }

package/dist/mcp.js

@@ -140,6 +140,8 @@ export async function main() {
                     "• Stack desktop mockups VERTICALLY with labels ('Now', 'Proposed') — don't squeeze them side-by-side. The iframe is ~900px wide; two desktop screens at half-width crush columns, wrap headings to 3 lines, and turn tables unreadable.\n" +
                     "• Side-by-side is fine only for narrow mobile mockups, small cards, or short text columns that genuinely fit in half-width.\n" +
                     "• Mockup embedded mid-explanation? Prose has a ~880px reading-width cap, but a mockup section should fill the full card. Wrap JUST the mockup in <div class=\"full-bleed\">…</div> — it breaks out of the body padding + prose cap to span the full card width, while surrounding prose stays in the reading column. (If the WHOLE push is a UI recreation, use kind:'mockup'/'app' instead — that strips the entire frame.)\n" +
+                    "• MATCH THE SOURCE'S REAL FRAME — faithful height, not minimal, in both directions. Mocking a COMPONENT (card, modal, row, toolbar)? Size to content — do NOT pad with min-height:560px / height:100vh to feel 'desktop-y'; that floats content in dead whitespace. Mocking a FULL DESKTOP SCREEN (login page, dashboard)? Give it realistic viewport proportions (e.g. height:760px or 16:10) and lay content out inside as the real screen does (centred form, top nav) — cropping a real screen down to just its content height misrepresents it just as much. Either way copy the source's exact height if it has one. Test: cropped the same way, would your mock look like a screenshot of the real thing? Empty bands = over-padded; a screen squashed to a strip = under-sized.\n" +
+                    "• When recreating real app UI, hug the source — pull exact colors, spacing, sizing, radii, fonts from the component/theme/Figma/DevTools. A close-but-wrong recreation misleads more than no recreation. If you can't reach the actuals, say so in chat and don't pass the mock off as accurate.\n" +
                     "• One accent color, 3–4 instances max per card. Status colors (red/amber/green) only when state genuinely maps to status.\n\n" +
                     "═══ WHEN TO PUSH ═══\n" +
                     "A response that would otherwise contain: >2 paragraphs of explanation, any UI mockup, a diagram, a code diff, a ≥3-option comparison, or a multi-step progress view. Do NOT ask permission — push proactively. After pushing, reply in chat with ONE LINE: 'pushed to easel ↗ — #<index>'. Don't restate the card's content.\n\n" +

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ammduncan/easel",
-  "version": "0.2.21",
+  "version": "0.2.22",
   "description": "A live browser tab for every Claude Code (and MCP) session. The push MCP tool appends HTML cards to a scrolling feed you keep open in split-screen.",
   "type": "module",
   "license": "MIT",

package/skills/using-easel/SKILL.md

@@ -188,6 +188,22 @@ When the mockup references a real thing — a real app, a real component, a real
 
 **If you can't reach the actuals**, say so explicitly in the chat reply (e.g. *"Couldn't find the project's theme file — colors and sizing in this mock are estimates"*) and skip the mock if it would mislead. A recreation labelled "approximation" is fine; one passed off as accurate is a trap.
 
+#### Match the source's real frame — height included, in both directions
+
+A mockup's height should match what it actually represents — don't fake it taller *or* shorter than the real thing. There are two distinct cases, and the failure mode is using the wrong one:
+
+**Mocking a component** (a card, modal, row, toolbar, button, an embedded section): size it to its **content**. Do NOT slap `min-height: 560px` / `height: 100vh` on a component to make it "feel desktop-y" — that injects dead whitespace and floats the content unnaturally. If the real component is 320 px tall, the mock is 320 px tall.
+
+**Mocking a full desktop screen / page** (the whole viewport — a login screen, a dashboard, a settings page): give it **realistic desktop viewport proportions**, because the surrounding space *is* part of how that screen looks. A login form genuinely sits in a ~720–800 px-tall viewport with the panel centred — cropping that down to just the form's content height misrepresents it as much as over-padding a component does. Use a fixed frame (e.g. `height: 760px` or a 16:10 box) and lay the content out inside it the way the real screen does (centred form, top nav, sidebar full-height, etc.).
+
+So the rule is **faithful height, not minimal height**:
+- Component → content height (no padding to a fake screen size).
+- Full screen → real viewport proportions (don't crop to content).
+- Either way, if the source element has a specific height/min-height, copy that exact value (per the sizing rule above).
+- Vertical-centring inside a tall box is correct *only* when you're mocking a full screen whose real layout centres its content — not as a way to fill a component you've over-sized.
+
+The test: cropped the same way, would your mock look like a screenshot of the real thing? Empty bands the real screen doesn't have = over-padded. A desktop screen squashed to a short strip = under-sized.
+
 ```css
 /* Locked-dark container (terminal, dark code block, dark callout). */
 .terminal {