@rubytech/create-maxy-code 0.1.105 → 0.1.106

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rubytech/create-maxy-code",
-  "version": "0.1.105",
+  "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/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 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. **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**. Any photo that shows the property from height (drone shot, upper-floor view down the grounds), the plot from a distance, the front elevation framing the home in its setting, a paddock/grounds wide, or an aerial perspective IS a candidate for `siteplan_src`. Visual scan via the contact-sheet montage technique already required elsewhere in this SKILL ("Never assign an image to a slot from filename alone"). 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. If candidates 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 (wide exterior), <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 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-disk first, ask second, drop-to-12 third** — fabricate, 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.
+- **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".