@rubytech/create-maxy-code 0.1.104 → 0.1.106

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-maxy-code",
-  "version": "0.1.104",
+  "version": "0.1.106",
   "description": "Install Maxy — AI for Productive People",
   "bin": {
     "create-maxy-code": "./dist/index.js"

package/payload/premium-plugins/real-agent/plugins/brochures/skills/brand-design/SKILL.md

@@ -87,7 +87,7 @@ Format — one role per line, `role: value`, or a Markdown table:
 | Role | Value |
 |---|---|
 | `display-headline-style` | `normal` |
-| `display-em-style` | `weight-shift` |
+| `display-em-style` | `italic` |
 | `display-letterspacing` | `medium` |
 | `deck-family` | `sans` |
 | `deck-case` | `sentence` |
@@ -110,7 +110,8 @@ How to decide which values to set, given the brand audit you've already done:
 | Display headlines render upright (no `font-style: italic`) | `display-headline-style: normal` |
 | Display family is a humanist sans (Montserrat, Inter, Söhne) | `display-letterspacing: medium` |
 | Display family is a geometric/grotesque sans (Helvetica, Roboto Mono) | `display-letterspacing: tight` |
-| The site never italicises anything | `display-em-style`, `body-em-style`, `caption-em-style`, `folio-em-style`, `backpage-em-style` → `weight-shift` (preferred) or `normal` |
+| The display family is a serif with an italic cut (Playfair Display, Cormorant Garamond, Lora, EB Garamond, etc.) AND the site visibly uses italic emphasis on em runs | `display-em-style: italic` (affirmative — emits no override; the template's natural italic is what the brand wants). DO NOT set `weight-shift` or `normal` for these brands; both destroy the natural italic and ship a flattened, sans-looking emphasis style. |
+| The site never italicises anything (display family is a sans, or visibly suppresses italic) | `display-em-style`, `body-em-style`, `caption-em-style`, `folio-em-style`, `backpage-em-style` → `weight-shift` (preferred) or `normal` |
 | All body running text is sans-serif | `deck-family: sans`, `caption-family: sans` |
 | Captions and labels share the body family | `caption-family: sans` |
 | No dropcaps anywhere on the site | `dropcap: hidden` |

package/payload/premium-plugins/real-agent/plugins/brochures/skills/property-brochure/SKILL.md

@@ -176,7 +176,11 @@ When any field above is unresolved after consulting its primary source, **stop b
 - **Web bundle ships the PDF, not per-page JPGs.** The bundle does not include `cover-print.jpg … backpage-print.jpg` — those duplicate the brochure content already embedded in `<slug>-brochure.pdf`. The web copy of `brochure.html` has its `.print-img` src attributes cleared so the print stylesheet drops to the live-DOM fallback; operators who want a printable PDF download the bundled PDF directly. See `references/build.md → Clear .print-img src in the web copy`. Shipping both was the historical bundle-bloat defect.
 - **Bottom chrome on `.page` is absolutely-positioned and stacks deterministically.** Three classes of bottom element exist: (1) the `.folio` page-number strip (`bottom: 8mm`, ~8mm tall → occupies bottom ~16mm of every page); (2) `.back-disclaimer` on the back page (`bottom: 16mm`, wraps to up to 5 lines × 3.7mm → occupies bottom ~34.5mm); (3) `.mi-foot` on the Material Information page (`bottom: 22mm`, ~7mm tall → occupies bottom ~22–29mm). All are `position: absolute`, anchored to their nearest positioned ancestor (`.page` which is `position: relative`). In-flow content above (e.g. `.mi-grid` inside `.mi-page`, `.backpage-inner` centred content) is a SIBLING in the stacking flow — nothing in CSS structure enforces clearance from the absolute layer. The fix is to either (a) **make the relevant footer absolute** (the approach used for `.mi-foot` to prevent oversized `.mi-grid` from pushing the disclaimer into the folio), or (b) **pull the in-flow container up via its parent's `padding-bottom`** when the footer is small and predictable (e.g. `.backpage-inner` uses 42mm to clear folio + disclaimer with a 4mm gap). Never use `margin-*` on a `position: absolute` element whose anchor is `bottom` — it has no positional effect.
 - **Folio is plain text on whitespace or absent — never chrome over imagery.** The `.folio > span` carries no background, blur, padding, border-radius, or shadow. It is plain text in `--teal-900` that sits on the clean whitespace reserved at the page bottom (see the previous rule on padding-bottom clearance). The folio is **hidden entirely** on full-bleed-bottom pages: `.cover`, `.page.intermission`, `.page.folio-dark`, and any `.page` whose body wraps a `.feature-page` (photo+panel layout where the photo bleeds to the page bottom). Never reintroduce a folio-pill background to "make it readable over the image" — that's competing chrome on the page; suppress the folio on that page instead. Any new full-bleed-bottom page class must be added to the `.folio` `display: none` selector in `references/template.html`.
-- **Page 13's `{{ siteplan_src }}` is never the floorplan.** Page 13 (the site-plan / plot page, `.page siteplan-page`, "Continued, Chapter VI · The plot") expects a plot drawing, site plan, or aerial photo — an image distinct from the floorplan that page 14 already carries. If no such image is naturally available (no `<slug>-siteplan.png` line-art, no aerial photo on disk), the operator confirmation prompt MUST list `{{ siteplan_src }}` as an unresolved field and request a substitute by name — a wide exterior, a paddock/grounds photo, a drone shot of the property in its setting, or a hand-marked site sketch. Silently falling back to the floorplan duplicates page 14's content and is a defect (the brochure ships with the same image on two consecutive pages — visible immediately on review). The fallback is forbidden by the same doctrine as `TBC`: never coerce a field to a default the operator did not confirm. If the operator cannot supply a substitute, the brochure drops to the 12-page reduced layout (no page 13) — not to a 16-page layout with a duplicated floorplan.
+- **Page 13's `{{ siteplan_src }}` is extract-or-omit-or-ask — NEVER fabricated.** Page 13 (the site-plan / plot page, `.page siteplan-page`, "Continued, Chapter VI · The plot") expects a real plot drawing, real site plan, or real aerial/exterior photograph — an image that EXISTS on disk because the listing supplied it, the operator staged it, or `property-extract` captured it. **The agent must never fabricate this image.** No mock plan drawn from coloured rectangles + text labels (e.g. "THE LODGE / DRIVEWAY · PARKING / SOUTH-WEST FACING LAWN" on a green background — a real-world failure observed on Plate VIII of a recent brochure), no SVG diagram synthesised from `property.json` dimensions, no AI-generated site sketch, no postcode-centroid satellite render, no Mapbox/Google static-map call with our API key, no `<canvas>` hand-drawing, no HTML/CSS box-and-label illustration. ALL of these are forbidden — the same "extract or omit" doctrine that governs `property-extract → Map detection` applies here. **The acceptable image set for `siteplan_src` is a closed list: (1) aerial / drone shot (taken from height, looking down on the property and its grounds), (2) site plan / plot drawing (line-art, supplied by the listing or staged by the operator), (3) local-area shot (street view, neighbourhood context, immediate surrounding setting that frames the plot's relationship to its area). Nothing else.** Ground-level exteriors of the house itself are NOT siteplan candidates — those belong to the cover, opener, intermission, or feature slots. Interior shots (kitchen, garden, terrace, lounge) are NOT candidates. The floorplan is NOT a candidate (page 14's content; banned above). A fabricated mock illustration is NOT a candidate (banned above). The hero photo is NOT a candidate (used on the cover).
+
+**Before any "no image" fallback** (asking the operator, dropping to the 12-page layout, or — forbidden — fabricating), the agent MUST first **scan `<property_dir>/images/` and enumerate candidates that match the closed list above**. Visual scan via the contact-sheet montage technique already required elsewhere in this SKILL ("Never assign an image to a slot from filename alone") — read each candidate's pixel content, not the filename. Real-world failure observed today: a brochure shipped with a fabricated mock plan on page 13 even though THREE perfectly good aerial photos sat in `<property_dir>/images/` unused; the agent skipped the directory scan, jumped to fabrication, and shipped. A separate failure mode also observed: agent picked an inappropriate image (e.g. ground-level garden shot, interior moment) for the slot because it scanned but didn't filter against the closed list. Both fail the same test — the slot must be filled with an image that ACTUALLY conveys the plot's geography, not just any image that happens to be on disk.
+
+If one or more candidates from the closed list exist, the operator confirmation prompt lists them by filename + one-line description (e.g. *"siteplan_src: 3 candidates found in images/ — <slug>-12.webp (drone, S-facing), <slug>-18.webp (street-view from the lane), <slug>-21.webp (aerial through trees). Pick one, or supply a different image."*) and the agent renders only after the operator picks. Only when zero candidates from the closed list exist on disk does the prompt request a fresh image; only when the operator declines does the brochure drop to the 12-page reduced layout. The order is **scan-and-filter first, ask second, drop-to-12 third** — fabricate, never; pick-an-inappropriate-image-just-because-it's-there, never. The brochure must NEVER ship with a fabricated illustration where a real plot/aerial belongs; this is a ship-stopper defect that misrepresents the property to a buyer. Also forbidden by the same doctrine: silently falling back to the floorplan (duplicates page 14). If the operator cannot supply a real image, the brochure drops to the 12-page reduced layout (no page 13) — never to a 16-page layout with fabricated or duplicated content on page 13.
 - **Verification covers every page in the deliverable — sampling is a defect, not a shortcut.** `scrollHeight` fit checks, computed-style collision probes (`.mi-foot` ↔ `.folio` gap, `.back-disclaimer` ↔ in-flow content, any future absolute-bottom element vs in-flow neighbour), and visual review before declaring done all walk **every page** in the 16-page folio (or 12-page reduced layout). "Sample-checked 3 of 12 pages" or any variant ("spot-checked the spreads I changed", "skimmed a few representative pages") is not authorised — the skill explicitly says "verify every page" in `references/build.md → Live editing workflow` step 8 and in `references/structure.md`. The deliverable is the brochure as a whole; a defect on an unchecked page ships exactly as readily as a defect on a checked one. If a probe is expensive enough that walking 16 pages feels burdensome, the cost is the probe's, not the skill's — propose a faster probe rather than narrowing the coverage.
 - **`scrollHeight > viewport budget` is ALWAYS a defect — never "negligible".** Landscape budget is **794px** (`min-height: 210mm` at 96dpi); portrait is **1123px**. Every `.page`'s `scrollHeight` must be `≤` the budget — strict, not "approximately equal". A 4px overflow IS a defect: `overflow: hidden` silently clips that excess, and on pages with absolute-positioned bottom chrome (`.folio`, `.back-disclaimer`) the clipped content paints over chrome that lives in the absolute layer. "It's only 4 pixels" is the rationalisation that ships defects — the rule does not have a tolerance band. If a page reports `scrollHeight > budget` even by 1px, the build halts until the operator addresses the content-volume mismatch (trim copy, shrink an image, reduce a row count, or split into a continuation page). Never paper over with `overflow: hidden`-as-clip; the warning sign is the deliverable's only signal that the content doesn't fit.
 - **Material Information table has a hard row capacity — overflow is a content-volume defect, not a render bug.** At the default `.mi-row` sizing (9.5/11.5px fonts, 6px vertical padding, 18px `.mi-grid` row-gap), one column in the three-column MI grid fits **~13 rows** within the 22mm-clearance budget. A property with an unusually full table (e.g. 17+ rows in the tallest column, observed on a recent run) overruns by ~25mm / ~85px and clips into the folio zone. When MI's content volume exceeds the budget, the operator confirmation prompt MUST surface `mi.<column>.row_count` as an overflow item and ask the operator to either (a) trim the column to ≤ 13 rows by consolidating related disclosures (e.g. merge "easements" + "water/sewerage" + "rights of way" into one "Other matters" row that points at the seller's solicitor), or (b) opt into a continuation page (15a / 15b) — a separate skill-level decision that breaks the default 16-page contract and must be operator-confirmed. The build never silently truncates rows, never shrinks fonts to "make it fit", and never accepts a scrollHeight overflow as "negligible". The default `.mi-page` 22mm bottom-padding is sized for the typical property; properties outside the typical range MUST resolve via operator confirmation, not via the agent's judgement about which rows are "less important".

package/payload/premium-plugins/real-agent/plugins/brochures/skills/property-brochure/references/build.md

@@ -429,6 +429,16 @@ ROLE_RECIPES = {
         ],
     },
     'display-em-style': {
+        # Affirmative "use the display family's natural italic cut". Emits no
+        # override (the template default at :root already sets em runs to italic
+        # via font-style inheritance). Authors should prefer this for any brand
+        # whose display family carries a real italic (Playfair, Cormorant, Lora,
+        # EB Garamond, etc.) AND whose site visibly uses italic emphasis. The
+        # "default" value in registers.md required OMITTING the role entirely,
+        # which made the safe choice silent and the destructive choices (weight-
+        # shift, normal) the only affirmative ones in the example block — a known
+        # foot-gun. Setting `italic` explicitly closes that.
+        'italic': [],
         'weight-shift': [
             '.cover-title em, .opener-title em, .ed-headline em, .toc-title em, '
             '.back-headline em, .mi-head em '

package/payload/premium-plugins/real-agent/plugins/brochures/skills/property-brochure/references/registers.md

@@ -34,7 +34,7 @@ The role API is **fixed and bounded**. Only the roles below may be overridden; t
 | Role | Targets (CSS selectors) | Allowed values |
 |---|---|---|
 | `display-headline-style` | `.cover-title`, `.opener-title`, `.ed-headline`, `.chapter-head h3`, `.feature-page h3`, `.gallery-head h3`, `.siteplan-page h3`, `.toc-title`, `.back-headline`, `.mi-head h2`, `.mi-head h3` | `italic` (default) / `normal` |
-| `display-em-style` | `<em>` inside the headline selectors above | `italic` (default) / `weight-shift` / `normal` |
+| `display-em-style` | `<em>` inside the headline selectors above | `italic` (affirmative — preserve display family's natural italic cut; recipe emits no override) / `weight-shift` (flatten italic to bold sans-like) / `normal` (flatten italic, no weight bump). Default if omitted is the same as `italic`; setting `italic` explicitly is preferred so the choice is recorded affirmatively rather than silently. |
 | `display-letterspacing` | `.cover-title`, `.opener-title` | `wide` (default, ≈0.18em — tuned for Cormorant/didone) / `medium` (≈0.10em — humanist sans) / `tight` (≈0.04em — geometric sans) |
 | `deck-family` | `.ed-deck`, `.feature-deck`, `.gallery-deck`, `.siteplan-deck` | `serif` (default) / `sans` |
 | `deck-case` | same as `deck-family` | `caps-tracked` (default) / `sentence` |