@topy-ai/maggie 0.7.53 → 0.7.55

package/bundled-skills/maggie-assistant-tools/references/unattended-agents.md

@@ -0,0 +1,70 @@
+# Unattended agents: keys, sign-in grants and clipped lists
+
+A scheduled routine (Claude Routines, Codex Automations, a cloud task) calls
+the product's MCP with nobody watching. Three things go wrong when the tool
+surface was designed only for a person in a chat. Each is checked by
+`maggie assistant registry-validate` once the registry declares it.
+
+## 1. A prompt is not a limit
+
+A routine's prompt can say "add at most ten ideas a day", but nothing stops
+the next run, a changed prompt, or a confused model from doing more. Every
+write an unattended caller can reach needs a cap the **server** counts.
+
+Declare it in `registry.unattended` (`enforcedBy: "server"`):
+
+- **Agent keys** (`agentKeys`): an API key made for one routine holds a
+  standing permission naming the writes it may run without a preview and a
+  daily number for each (`standingTools.<tool>.perDay`). Before such a write
+  the server claims one use; when the claim is refused (today's number is
+  used, the permission was revoked) the tool returns the reason, not a
+  preview (`refusalReturnsReason: true`) — nobody is there to confirm one, and
+  an agent key can never confirm previews (`canConfirmPreviews: false`).
+  Standing permissions cover reversible or spending writes only; public or
+  irreversible writes always go through a person.
+- **Sign-in (OAuth) grants** (`oauth`): a connector the person signed in with
+  acts as that person, with their full role. Give the grant its own server
+  caps — a total daily write number (`dailyWriteLimit`) and/or one per tool
+  (`perToolPerDay`) — that the owner sets on the connections page, and count
+  them per grant. The validator fails any write a grant can reach with no cap.
+
+Record each claimed use with the key or grant id in the audit log, the same
+way a standing workflow approval is recorded (see
+[approvals and audit](approvals-and-audit.md)).
+
+## 2. The sign-in default is the role's full tool set
+
+A grant's default tool set should be what the person's role allows on MCP,
+filtered at call time by the role (`oauth.defaultTools: "role"`). A default
+copied from the first feature that used sign-in (for example only the
+translation tools) leaves a routine connected by sign-in unable to reach the
+rest of the product, with no error that says why. A narrower default is
+allowed only with `narrowedReason`; the validator names the tools it leaves
+out.
+
+Re-check membership and role on every call, so removing or demoting a person
+cuts their connected apps off at once.
+
+## 3. Clipped list fields need a full-text get tool
+
+List tools keep responses small by shortening long fields (a post's text to
+about 300 characters). An agent asked to check what will be published then
+reports text "cut off mid-sentence" that is in fact whole. For every list
+that shortens fields:
+
+- declare `clips` on the list tool: the shortened `fields`, `maxChars`, the
+  `getTool` that returns one item in full, and the `idField` it takes;
+- mark each shortened item in the result: `clipped: true` or
+  `clipped: ["text"]`;
+- serve the get tool on every channel the list is on, read-only, same scope;
+- say in the list's model-facing description that text is shortened and which
+  tool reads it in full.
+
+Check a recorded result of the list:
+
+```bash
+maggie assistant list-check --registry tools.registry.json --tool social_list --result recorded-list.json
+```
+
+It fails items whose field reaches `maxChars` (or ends with an ellipsis)
+without a `clipped` marker, and items without the id the get tool needs.

package/bundled-skills/maggie-blog/SKILL.md

@@ -56,6 +56,21 @@ Search/sort views are not indexable; drafts never appear in public routes, RSS,
 or sitemap output. Provider keys remain server-side. Public publication and
  migrations always require explicit confirmation.
 
+API Pull deliveries need their live URL recorded so social posts and internal
+links point at the page that exists now: the site reports it on publish
+(`maggie blog live-urls record --content-id ID --url URL`), and
+`maggie blog live-urls match --sitemap URL --write` fills the gaps
+additively — it never retires an earlier match, a post tracked with an empty
+URL is still matched, and the original page wins over translated copies that
+share the slug. See
+[where a delivered post went live](../../bundled-tools/integrations/maggie-api-pull.md#where-a-delivered-post-went-live).
+
+A pull site also pulls rewrites (`GET /updates`, same schedule as `/posts`):
+apply each one to the post it is for (`source_content_id`, else slug or
+address, previous slugs too), change only the body, keep the replaced body for
+undo, hold `publication_status: draft` rewrites and never create a post from
+one. See [rewrites on pull sites](../../bundled-tools/integrations/maggie-api-pull.md#rewrites-on-pull-sites).
+
 Automatic publication is an opt-in host policy, not the default. Keep human
 review enabled unless the owner explicitly chooses otherwise. If a host has
 that approval, validate its evidence before its scheduler calls the host's

package/bundled-skills/maggie-booking/SKILL.md

@@ -21,9 +21,9 @@ temporary project detail, secret, or unverified guess into active memory.
 
 ## Contract and safety boundary
 
-Read [`../../bundled-references/maggiedash-booking/README.md`](../../bundled-references/maggiedash-booking/README.md),
-[`TASKS.md`](../../bundled-references/maggiedash-booking/TASKS.md), and the task's linked
-reference before changing code. MaggieDash owns the manager UI and versioned
+Read the [PRD](../../bundled-references/maggiedash-booking/PRD.md), the
+[host adapter contract](../../bundled-references/maggiedash-booking/HOST-ADAPTER.md) and the
+task's linked reference before changing code. MaggieDash owns the manager UI and versioned
 contracts. The host owns routes, traditional email/password sessions,
 PostgreSQL connection/transaction lifetime, tenant authorization, provider
 credentials, payment webhooks, notifications, and deployment. MaggieDash also
@@ -32,11 +32,12 @@ booking, customer, configuration, schedule, health, audit, hold, and lifecycle
 persistence; it does not replace host connection ownership or payment/public-
 checkout adapters.
 
-For implementation work, use the leaf board and runbook:
-[`EXECUTION-BOARD.json`](../../bundled-references/maggiedash-booking/EXECUTION-BOARD.json)
-and [`TASK-RUNBOOK.md`](../../bundled-references/maggiedash-booking/TASK-RUNBOOK.md). Do not
-mark a task passed until its implementation gate, docs update, and evidence
-record are complete.
+Maintainers changing MaggieDash Booking itself work from the delivery board
+and runbook in the Maggie source repository (`docs/maggiedash-booking/`
+`EXECUTION-BOARD.json`, `TASK-RUNBOOK.md`, `TASKS.md`, `PROGRESS.md`); they are
+not installed with the skill. Do not mark a task passed until its
+implementation gate, docs update, and evidence record are complete. A host
+project records its own evidence in its own repository.
 
 Never put provider secrets, database credentials, payment card data, or a
 customer export in UI props, browser bundles, fixtures, screenshots, or
@@ -127,6 +128,12 @@ Booking installer:
 maggie booking install --project . --confirm
 ```
 
+Booking is an optional MaggieDash module: this installs the core (if it is
+not there yet) plus Booking, the same as `maggie dash add booking --confirm`.
+Install it only when the business takes bookings — `maggie dash install`
+alone gives a content site the core without payment or booking files, and
+`maggie dash recommend` says whether the site looks like it sells services.
+
 For a host project that does not already contain the Booking runtime packages,
 let the installer add only the missing dependencies through the package manager
 already declared by the project (`npm`, `pnpm`, `yarn`, or `bun`):
@@ -156,7 +163,7 @@ Use `--schedule systemd` or `--schedule cron` with `--ready` only to generate a
 reviewable scheduler artifact; enabling it remains an operator action after
 backup, migration, and release evidence checks.
 
-The default installer source is MaggieDash `main` (currently `0.2.13`; pin
+The default installer source is MaggieDash `main` (currently `0.2.15`; pin
 another release with `--ref`). It contains the released Astro `hostBootstrap`
 manifest and 47-route Booking source, including the tenant-scoped treatment
 package catalogue, and follows the booking rules above (manage-link state
@@ -364,7 +371,7 @@ settings, reports, and audit. If `permissions_json` is absent on a legacy role,
 apply the safe role defaults server-side; never treat a missing object as full
 read access. Explicitly granted staff capabilities must be honored by the
 route handler, while staff mutations remain limited to approved lifecycle
-transitions. Keep the access contract, Astro host, reference host, ORA mirror,
+transitions. Keep the access contract, Astro host, reference host, installed host copies,
 and CLI validator synchronized whenever a route capability changes.
 The bootstrap now uses the host's server-side Resend configuration to send
 single-use invitation and password-reset links; raw tokens are never stored.
@@ -519,8 +526,9 @@ Follow the task board rather than building a disconnected calendar first:
 6. Add the provider-neutral payment port and a test-mode adapter. Reconcile
    signed duplicate/out-of-order webhooks before enabling capture.
 7. Run the UI source gate, contract gate, host runtime conformance, browser
-   journeys, and release gate. Record each command in
-   [`PROGRESS.md`](../../bundled-references/maggiedash-booking/PROGRESS.md).
+   journeys, and release gate. Record each command in the host project's own
+   progress log (maintainers: `docs/maggiedash-booking/PROGRESS.md` in the
+   Maggie source repository).
 
 8. Verify the scheduled worker queues and delivers a reminder once for a
    confirmed booking inside the 24-hour window. Check the notification

package/bundled-skills/maggie-content-localization/SKILL.md

@@ -70,6 +70,32 @@ Norwegian, Finnish, Greek, Hebrew, Czech, Romanian, Hungarian, Thai, Persian,
 and Swahili. Use BCP 47 regions such as `es-MX`, `pt-BR`, `ar-SA`, or `ja-JP`
 when market-specific copy is required.
 
+## Text keys are site-wide; generated pages need position keys
+
+A translation stored under its source text (a text hash) applies to **every
+page** that shows that text. That is right for a shared header and wrong for
+generic phrases on generated pages: "your practice" is 诊所 on a dental page
+and 事务所 on an accountants page, and only one translation can exist per
+text. For generated or templated pages (one page per industry, city or
+product), render the source page, then store each node's translation under a
+**per-page position key** (page + node position, with the source text hash so
+a changed source shows as stale). Keep text keys only as a fallback for text
+that is genuinely the same everywhere.
+
+```bash
+maggie localization key-check rows.json [--locale zh-hans]
+maggie localization fragments --html dist --brand "Maggie"
+```
+
+`key-check` reads per-page rows (`page`, `position`, `text`, `translation`)
+and lists source texts translated differently on different pages — each one
+needs position keys. `fragments` reads rendered HTML and lists text split
+around an inline brand span into one- or two-word pieces ("Can", "No.",
+"What") that cannot be translated alone; translate the whole sentence with
+the span as a placeholder instead. Agents writing in parallel must use one
+glossary for short shared fragments, or the same piece gets different
+translations from different writers.
+
 ## Email and lifecycle email
 
 Localized email is a content surface with its own checks. Resolve the

package/bundled-skills/maggie-dash/SKILL.md

@@ -31,9 +31,35 @@ must already be configured for the project owner.
 maggie dash install --project . --confirm
 ```
 
+This installs **only the core**: the dashboard, the auth boundary
+(email/password sign-in, first-owner registration, password reset), the
+`/_maggie/admin` route, navigation and the core schema. It then reads the host
+(framework, existing sign-in, database, payments, whether the site sells
+services or publishes a blog, locales) and prints `recommendations`, one per
+optional module or companion skill with a reason. Install a module only after
+the user agrees:
+
+```bash
+maggie dash recommend --project .                 # analysis only, writes nothing
+maggie dash add booking --project . --confirm     # same as: maggie booking install --confirm
+```
+
+Booking is the optional code module MaggieDash ships (workspace, backend,
+schema, Stripe adapter, worker, env example). Blog, localization, social
+sharing and ops are Maggie skills that use the core panels; the
+recommendations name them. Never pass `--with booking` or `--all-modules` for
+a site that has not asked for bookings: a content-only site must not receive
+payment and booking files. A release without the module split (MaggieDash
+0.2.13 or older) still installs everything and says so in `notices`.
+
+Server settings in the Astro scaffold are read at run time
+(`src/lib/maggie/env.ts`). Never read a secret through `import.meta.env.X` in
+host code: Vite inlines it into the build output.
+
 The command is idempotent, preserves existing files unless `--force` is
-explicitly supplied, and records the resolved revision in
-`.maggie/dash-install.json`. It never accepts or stores a GitHub token as a
+explicitly supplied, and records the resolved revision and installed
+`modules` in `.maggie/dash-install.json` (a later `install` keeps refreshing
+modules that were added). It never accepts or stores a GitHub token as a
 CLI argument. For local development or a pinned checkout, use
 `--source /path/to/MaggieDash` or `--source URL --ref REF`.
 
@@ -97,6 +123,15 @@ fallback. The host owns authentication, event writes, menu persistence,
 translation behavior, and validation. Use the dashboard UI v3 contract for the
 required route and capability declarations.
 
+MaggieDash 0.2.15 adds the **AI agents** workspace (`/_maggie/admin/mcp`,
+capability `mcp.read`) for a host that serves its own MCP endpoint to outside
+agents: tokens with a tool set and a daily write limit, sign-in (OAuth)
+connections with their own tools and daily limit, per-call change review and
+undo, and — when the host syncs an agents repository — its routines. The host
+implements `GET`/`POST /api/maggie/mcp-admin.json` as described in MaggieDash
+`docs/HOST-AI-AGENTS.md` and enforces every limit on the server; see
+`maggie-assistant-tools` for the rules and `maggie-ops` for routines.
+
 For a built/deployed host, an agent must use the host's validated content
 bridge rather than editing release files or receiving database credentials:
 

package/bundled-skills/maggie-deployment/SKILL.md

@@ -25,6 +25,33 @@ metadata:
 - Product CLI and MCP packages: `maggie product release-check|smoke|mcp-check`
   ([product release](../maggie-assistant-tools/references/product-release.md)).
 
+## Downstream surfaces after a major product release
+
+A product change is not released while an agent-facing surface still
+describes the old product. After any major change to the app, the dashboard or
+the backend API (a new feature or channel, a renamed tab, a changed rule or
+limit), walk every surface below and either update it or record "no change":
+
+| Surface | Check | Evidence |
+|---|---|---|
+| Remote MCP tools | New or changed API params and response fields have tools; descriptions use the product's words | `tools/list` on the live server: count and the new names |
+| Agent system prompts | In-app assistant and any hosted bridge/agent prompt name tabs, channels and rules as the app does | One question about the change answered correctly |
+| Skills catalog and marketplace | Grep skills for the old wording; `mcp_tools` lists only real tool names; any tool-name allowlist is in sync with the tool source | Validator passes; marketplace repo pushed; agent hosts re-synced and recycled |
+| CLI and MCP npm packages | Commands/columns for the new data; both package versions bumped together | `npm view <pkg> version` |
+| Third-party plugins (ChatGPT, IDE) | Usually nothing if they use the remote MCP; re-review when tool names or auth change | Plugin lists the new tools |
+| SDK / API client types | New response fields typed | Workspace typecheck |
+| Mobile app | Web deploy plus OTA when the native fingerprint matches; a new build when it does not | Fingerprint compare; update id |
+| Assistant memory | A new channel or surface gets its own memory channel | Memory read for that channel |
+| Docs | PRD task list, progress log and the deployment runbook | — |
+| Preview host protection | Before (or after) adding basic auth to a preview host, every workflow, script or webhook that sends to it is repointed to production or sends the preview's basic-auth credentials from a secret — a bearer token does not pass basic auth | `maggie deployment preview-auth-check --host preview.example.com --repo . --live` passes; the next run of each listed workflow is green and the public surfaces it feeds show the new version |
+| npm staged publishes | A just-published version can stay invisible as `latest` for minutes; do not report it until it is. `Cannot publish over previously staged version` means the earlier attempt was already accepted, not a failure | `maggie product published --package-name NAME --version X --publish-log publish.log` reports `live` |
+
+Run the walk in the release order (schema → backend → dashboard → app →
+MCP/agent → bridge → npm → skills) and record which surfaces changed in the
+release record. Keep publish tokens in an env file and pass them through a
+temporary npmrc (`NPM_CONFIG_USERCONFIG`) that is deleted afterwards; never
+print them.
+
 ## Edge and rendered canary
 
 After staging or production deployment, verify that the edge serves the
@@ -592,6 +619,81 @@ judges latency only after warm-up requests. Failover between hosts must
 never replay a write: see "Failover must not replay writes" in
 [vps.md](references/vps.md).
 
+Host preflight also runs `maggie deployment runtime-inventory` (read-only):
+it warns when the host OS no longer gets security fixes and when a pinned
+container tag is behind the newest patch of its line (see "PHP runtime
+advisories" below).
+
+## Shared hosts: one session at a time
+
+Before an agent edits systemd units, containers or nginx on a production host,
+it takes the host lock and keeps its session id for every later command:
+
+```bash
+maggie deployment host-lock acquire --host deploy@HOST --session "$SESSION" \
+  --purpose "php 8.1 → container migration"
+# ... changes ...
+maggie deployment host-lock release --host deploy@HOST --session "$SESSION"
+```
+
+`acquire` refuses while another unexpired session holds the host (it names
+the holder and its purpose) and, like `status`, lists files changed in the last
+30 minutes under `/etc/systemd/system`, `/etc/nginx` and the container unit
+folders. A change you did not make means someone else is working there: stop
+and ask, even when the lock was free. Two sessions once recreated the same
+container in turn, each with its own command, and undid each other's fix.
+`--force` releases another session's lock only after the user confirms that
+session has stopped.
+
+## PHP runtime advisories (CVE response)
+
+For a PHP advisory, inventory every host first, then migrate one site at a
+time to a patched container without touching the site files:
+
+```bash
+maggie deployment runtime-inventory --ssh deploy@HOST \
+  --advisory advisory.json --latest-tags latest-tags.json \
+  [--image 'wordpress:php{line}-fpm'] [--writable /var/www/site/uploads] \
+  --output .maggie/deployment/HOST-runtime.json
+```
+
+`--ssh` runs only the read-only collector (`--print-collector` shows it; save
+its output and pass `--evidence FILE` when the host is reached another way).
+The report lists the OS, every active nginx server block with its
+`fastcgi_pass` target resolved to a host php-fpm unit or a container, and each
+runtime's status against the advisory (`advisory.json`:
+`{"id": "CVE-…", "fixed": {"8.1": "8.1.29", "8.2": "8.2.20"}, "unsupportedLines": ["7.4"]}`).
+It also flags:
+
+- an operating system past its end of standard security support (interim
+  Ubuntu releases end after nine months) or within 120 days of it;
+- a pinned image tag older than the newest patch of its line
+  (`latest-tags.json`: `{"php": {"8.2": "8.2.26"}}`);
+- php-fpm published on a public address instead of `127.0.0.1`;
+- a PHP image (container or systemd unit) running with the image's own
+  entrypoint.
+
+Nginx configuration is read with `nginx -T`, which includes files symlinked
+into `sites-enabled`. Never discover sites with `grep -r /etc/nginx`: it does
+not follow those symlinks, and a host then looks as if it had no PHP sites.
+Use `nginx -T`, or `grep -R` when nginx cannot be run.
+
+Each affected site gets a migration plan for review (`mutation: not
+executed`): take the host lock, record the site's file list, start the
+container on `127.0.0.1:PORT` with the site root mounted read-only (only
+`--writable` folders read-write) at the same path, back up and change that
+site's `fastcgi_pass`, `nginx -t`, reload; then verify and keep the rollback
+commands. Every PHP image — `php:*-fpm` and `wordpress:*-fpm` alike — runs with
+`--entrypoint docker-php-entrypoint` and an explicit `php-fpm` command. The
+WordPress image's own entrypoint copies a fresh WordPress into a mounted
+folder that has no `wp-config.php`; a site that was not WordPress once served a
+public `wp-admin/setup-config.php` for half an hour. After start, the plan's
+checks must pass: no file appeared in the site folder (diff with the list
+taken before) and `/wp-admin/setup-config.php` does not answer 200. When a
+systemd unit manages the container, change the unit's `ExecStart` the same
+way and recreate through the unit; otherwise the next restart brings the old
+command back.
+
 ## Provider boundary
 
 Deployment providers implement the same conceptual operations:
@@ -610,7 +712,8 @@ content, approval, URL, or SEO contracts. Read
 Stop before deployment when the target is ambiguous, the domain is not
 confirmed, a production secret/binding is missing, migrations are not
 idempotent/backed up, the build target and runtime disagree, or verification
-cannot prove public/private route and indexability behavior.
+cannot prove public/private route and indexability behavior. On a shared production host, stop when
+another session holds the host lock or recent changes there are not yours.
 ## Shared interactive decision loop
 
 Follow the shared [Maggie Decision Loop](../../references/decision-loop.md) for every invocation that has a meaningful choice. Before changing files, calling an external API, consuming quota, or changing production state:

package/bundled-skills/maggie-deployment/references/vps.md

@@ -32,6 +32,11 @@ maggie tool maggie_deployment.py . \
   --output .maggie/deployment-preflight.json
 ```
 
+Inventory the host read-only first (`maggie deployment runtime-inventory --ssh
+USER@HOST`): an end-of-life OS or a stale pinned image is a finding to fix or
+accept explicitly before deploying onto it. Take `maggie deployment host-lock
+acquire` before any change to units, containers or nginx.
+
 Confirm the VPS host/SSH user, canonical domain and DNS records, Node version,
 systemd service, environment file, Nginx/TLS configuration, release root,
 database/media migration and backup strategy, health checks, and rollback

package/bundled-skills/maggie-design/SKILL.md

@@ -262,6 +262,59 @@ maggie design step author-<id> --project . \
 An author plan is not complete until every `requiredSteps` entry has matching
 evidence and the explicit approval step is recorded.
 
+### Bulk author mode (many similar pages)
+
+For a family of similar pages (one use-case page per industry, one page per
+city), use one bulk job instead of hand-built scripts:
+
+```bash
+maggie design bulk plan --project . --targets targets.json --brief BRIEF.md --facts FACTS.md \
+  --validator '["python3", "scripts/validate-page.py"]' --check links --check prices --confirm
+maggie design bulk next <job> --stage write          # next batch (default 8) with each page's currentHash
+maggie design bulk record <job> --target ID --stage written --expect-hash HASH
+maggie design bulk validate <job>                    # project validator + built-in checks
+maggie design bulk next <job> --stage picture        # only pages validated and unchanged since
+maggie design bulk record <job> --target ID --stage pictured
+maggie design bulk status <job>
+maggie design bulk seed <job> --confirm              # only when every page passed
+```
+
+The job enforces what goes wrong in a parallel run: a picture is drawn only
+for a page that validated and has not changed since (a picture worker must
+never rewrite a page a writer is still editing); a writer records with the
+hash it read and is refused if the page changed meanwhile (re-read, re-apply,
+record again); changing the brief, facts or validator mid-run sends every
+earlier pass back to `revalidate`; nothing is seeded until all pages are
+validated and pictured. Built-in checks: every internal link points at a page
+of the job or a `--known-routes` entry, and every price appears in the facts
+file. The project validator checks structure, counts, facts and translation
+coverage. Share one glossary between writers for short repeated fragments
+(see maggie-content-localization, position keys).
+
+### Page pictures: choose the engine before a large run
+
+`maggie media generate` draws one picture with either engine; `maggie media
+engine-plan` states time and cost first. Show the plan and wait for a yes
+before a run of more than a handful of pictures.
+
+```bash
+maggie media engine-plan --count 510 --size 2400x1000 --gemini-unit-cost <price>
+maggie media generate --engine gemini --size 2400x1000 --prompt "..." --output hero.png --confirm
+maggie media generate --engine codex --image screen.png --prompt "Redraw as a clean step picture" --output step.png --confirm
+```
+
+| Engine | Billing | Speed (observed) | Reference pictures |
+|---|---|---|---|
+| `codex` | the ChatGPT plan's quota via the local `codex` CLI, no per-picture charge | about 75 s | yes (`--image`, before `--`) |
+| `gemini` | the project's own `GEMINI_API_KEY` (its Google account) | about 19 s at 2K | no |
+
+For 510 pictures that is hours versus minutes. Gemini takes the nearest
+aspect ratio and a size from the target (2400x1000 → 21:9 at 2K; 1K up to
+1300 px, 2K up to 2600 px, else 4K); crop to the exact size and convert to
+WebP afterwards. `engine-plan` leaves the Gemini cost empty until you pass
+`--gemini-unit-cost` from the current price list. Only transient Gemini
+errors (429, 5xx, network) are retried.
+
 ## Content UI initialization
 
 Use content UI initialization when `maggie-blog` or
@@ -398,6 +451,34 @@ repeated sheet and modal changes. Add `maggie design textinput-check`: a
 after collapsing; see the `chat-composer` pattern). `// maggie-allow-textinput`
 marks a reviewed exception.
 
+Closing a modal sheet is the third iOS-only trap. Closing a sheet and, in the
+same tick, showing a toast, refreshing or writing query data, navigating,
+opening another sheet, or changing what the closing sheet shows can leave the
+sheet's transparent window on top of the app: it looks fine but takes no
+touches until the app is killed. Close first, then do the rest once it has
+slid away:
+
+    export const SHEET_CLOSE_MS = 450;   // the slide-out duration
+    export function afterSheetCloses(fn: () => void) {
+      if (Platform.OS === "web") fn(); else setTimeout(fn, SHEET_CLOSE_MS);
+    }
+    // setSheet(null); afterSheetCloses(() => { toast(...); refresh(); });
+
+    maggie design sheet-check --project apps/app
+
+`sheet-check` finds closes (`setSheet(null)`, `setXOpen(false)`, `onClose()`,
+and the setter of any state used in a sheet's `open`/`visible` prop) followed
+in the same block by a toast, a refetch/invalidate/`setQueryData`,
+`router.*`/`*.open(…)` or another sheet opening; work inside
+`afterSheetCloses`, `setTimeout`, `requestAnimationFrame`, a local helper that
+wraps them, or after `await new Promise(r => setTimeout(r, …))` is deferred and
+passes. Errors fail the check. Warnings: a parent callback (`onDone()`) right
+after a close, and a sheet whose content reads the same state as its `open`
+prop (`open={Boolean(item)} title={item?.label}`), which empties the sheet
+while it slides away — keep a separate open flag. `// maggie-allow-sheet-close`
+marks a reviewed exception. Keep it with pressable-check, safe-area-check and
+textinput-check in the app's lint loop.
+
 ### Onboarding wizards
 
 Use one pattern for multi-step setup (brand, logo, voice, posting hours, and

package/bundled-skills/maggie-feedback/SKILL.md

@@ -223,10 +223,18 @@ leaving contradictory claims current.
 The CLI never submits automatically. After reviewing the draft:
 
 ```bash
-maggie feedback submit .maggie/feedback/<feedback-id>.json \
-  --endpoint https://feedback.noblox.app/api/feedback --confirm
+maggie feedback submit .maggie/feedback/<feedback-id>.json --confirm
 ```
 
+Without `--endpoint` the draft goes to `https://feedback.noblox.app/api/feedback`
+and, only when that host fails before storing it (no connection, timeout, or a
+5xx such as Cloudflare's 526), to `https://feedback.cmo.so/api/feedback`. Both
+accept the same contract and de-duplicate on `feedbackId`, so a retry never
+creates a second record. A 4xx is the host rejecting the draft and is not
+retried elsewhere. The saved `submission` records the `endpoint` that accepted
+the draft and any `failedEndpoints`. Repeat `--endpoint URL` to give your own
+ordered list. Do not hand-edit drafts to point at a different host.
+
 Only HTTPS endpoints are accepted. Project paths, file contents, secrets, and
 logs are excluded by default. `--allow-project-context` is an explicit opt-in;
 even then, send only a short public-safe context note. After submission, the

package/bundled-skills/maggie-marketplace/SKILL.md

@@ -205,7 +205,7 @@ packaging:
 maggie skills scaffold --root skills --category social --name cmo-thread \
   --description "Turn an article into a social thread; use after an article is approved."
 maggie skills validate --root skills [--catalog catalog.json] [--require-pinned]
-maggie skills package --root skills --out dist/marketplace --prefix cmo --owner "Example Ltd" --version 1.0.0
+maggie skills package --root skills --out dist/marketplace --prefix cmo --owner "Example Ltd" --version-from package.json:version
 maggie skills smoke --out dist/marketplace --claude
 ```
 
@@ -220,6 +220,26 @@ maggie skills smoke --out dist/marketplace --claude
 - `smoke` re-checks names, versions, sources and every packaged skill, and
   with `--claude` runs `claude plugin validate`.
 
+- **One version source.** `package` has no version of its own: pass
+  `--version-from FILE[:json.key|~CONSTANT]` (repeat it to require several
+  sources to agree) or `--version`; when they disagree it refuses instead of
+  writing one over the other. A packager that keeps its own `VERSION`
+  constant will otherwise overwrite a hand-bumped manifest.
+- **Generated data before deploy.** A site or catalogue built from the skills
+  (a generated skills JSON, a catalogue page) must be regenerated in the same
+  release. Check both before pushing:
+
+  ```bash
+  maggie tool maggie_version_sources.py check --source package.json:version \
+    --source scripts/pack.mjs~VERSION \
+    --generated site/data/skills.json --generator "node scripts/gen-skills.mjs {out}"
+  ```
+
+  It fails on any version mismatch and on generated data that differs from a
+  fresh run of its generator. Maggie's own release does the same: packaging
+  refuses when `VERSION` and the package version differ, and publishing runs
+  the release-metadata check first.
+
 Nothing is published; push the output folder to the marketplace repository
 yourself after review.
 
@@ -231,7 +251,7 @@ imported by the server and every node script (town pages, sitemaps, maps) —
 never a copy. It parses UK post towns and US "City, ST", falls back to the
 town field plus the state from the ZIP prefix when a US profile saved only
 the street, keeps non-US places in a US market ("Kingston, Jamaica"), and
-gives a normalised search key so "moonlake" finds "Moon Lake Spa", ranked
+gives a normalised search key so "lakeview" finds "Lake View Spa", ranked
 exact → prefix → word prefix → contains. See [directory towns and
 search](references/directory-search.md) for the generated-column SQL.
 

package/bundled-skills/maggie-marketplace/references/directory-search.md

@@ -27,7 +27,7 @@ counts per town.
 
 ## Name search
 
-People type "moonlake" for "Moon Lake Spa". Compare a normalised key —
+People type "lakeview" for "Lake View Spa". Compare a normalised key —
 lower case, accents removed, letters and digits only (`searchKey`) — as well
 as the plain `ILIKE` match, and rank exact and prefix matches first
 (`nameMatchRank`). In Postgres keep the key in a generated column with an

package/bundled-skills/maggie-marketplace/references/directory.mjs

@@ -85,8 +85,8 @@ export function parseTown(address, market, locality, postcode) {
 }
 
 /**
- * Name search key: lower case, accents removed, letters and digits only, so "moonlake", "Moon-Lake" and
- * "Moon Lake Spa" meet. Store it in a generated column (see directory-search.md) and compare both forms.
+ * Name search key: lower case, accents removed, letters and digits only, so "lakeview", "Lake-View" and
+ * "Lake View Spa" meet. Store it in a generated column (see directory-search.md) and compare both forms.
  * @param {string | null | undefined} value
  */
 export const searchKey = (value) => (value || "").normalize("NFKD").replace(/[̀-ͯ]/g, "").toLowerCase().replace(/[^a-z0-9]+/g, "");

package/bundled-skills/maggie-mobile-app/SKILL.md

@@ -129,6 +129,35 @@ always restores the working copies — checked by hash — even when a step
 fails. A mismatch with the build's own files means the change needs a new
 native build. `MAGGIE_MOBILE_EAS` overrides the `npx eas-cli` invocation.
 
+### Monorepos: publish only to a runtime an installed build has
+
+In a pnpm monorepo the fingerprint also hashes pnpm's virtual-store paths
+(`node_modules/.pnpm/<pkg>@<version>_<peer hash>`), so a dependency change in
+**any** workspace package (React added to the website) can move the app's
+runtime. `eas update` then publishes to a runtime no build has — silently.
+`ignorePaths` and `fileHookTransform` cannot fix it: `@expo/fingerprint` adds
+each native module folder by its real path. Keep the installed builds'
+runtimes in a file and publish through the guard:
+
+```json
+{"ios": [{"build": 7, "eas_build_id": "…", "runtime": "19d7a260e8e2…"}], "android": []}
+```
+
+```bash
+maggie mobile ota-guard --project . --app-dir apps/app --platform ios --runtimes scripts/ota-runtimes.json
+maggie mobile ota-guard … --publish --message "Fix copy" --confirm
+```
+
+It computes the fingerprint (`expo-updates fingerprint:generate`), refuses
+when no installed build has it — naming the two ways out (a native build, or
+publishing from a worktree with the build's lockfile and workspace file after a
+frozen install) — and with `--publish --confirm` runs `eas update` and checks
+that the published runtime is the one it checked. Add a build's runtime to the
+file when it ships; drop it when nobody runs it. At the next native build set
+an explicit `runtimeVersion` with a native-change check, so unrelated
+workspace changes cannot move it. `preflight` warns about a fingerprint
+runtime in a pnpm workspace.
+
 Show the plan's `costNotice` and wait for confirmation before step 1.
 
 ## 5. Store-review rules