@rubytech/create-maxy 1.0.875 → 1.0.876

package/payload/platform/plugins/admin/skills/onboarding/SKILL.md

@@ -33,7 +33,7 @@ Wait for the user's component submission before continuing. Their response will
   - `pdf-viewer` → `claude plugin install pdf-viewer@knowledge-work-plugins`
 - For each selected **{{productName}} plugin**, read the current `account.json` via `account-manage`, add the plugin name to the `enabledPlugins` array (create the array if absent), and write back via `Edit`. Use the `value` field (not `label`) as the plugin name — e.g., `docs` not `maxy-guide`. This activates the plugin's behaviour and MCP server from the next session.
 
-After installing/enabling (or skipping), call `onboarding-complete-step` with step 1.
+After installing/enabling (or skipping), call `onboarding-complete-step` with step 1. When step 1 is the step being completed, also pass `acceptedAnthropicVerticals` and `declinedAnthropicVerticals` derived from the user's submission against the closed Anthropic-verticals set `{kyc-screener, meeting-prep-agent, pdf-viewer}` — `acceptedAnthropicVerticals` is the intersection of the submission with that set, and `declinedAnthropicVerticals` is the set minus the intersection. Both arrays must be passed together: this emits `[plugin-onboarding] group=anthropic-verticals accepted=<n> declined=<n>`, the paired counter to Task 976's `presented=3` line.
 
 If any {{productName}} plugins were enabled in this step, call `session-reset` immediately after completing step 1. {{productName}} plugin MCP servers only load when a new subprocess spawns — the current session cannot access them. After the reset, the new session calls `onboarding-get` (returning `currentStep = 2`) and resumes from Step 2 with all newly enabled plugins available. If no {{productName}} plugins were enabled (user skipped or selected only Claude Official plugins), proceed directly to Step 2 — no reset needed.
 

package/payload/platform/plugins/docs/references/deployment.md

@@ -123,7 +123,7 @@ A single Pi or laptop can host more than one brand (for example Maxy and Real Ag
 
 - **Separate:** each brand has its own install folder (`~/maxy/`, `~/realagent/`), its own config folder (`~/.maxy/`, `~/.realagent/`), its own web port, its own Cloudflare tunnel state, its own edge systemd unit (`maxy-edge.service` vs `realagent-edge.service`), and by default its own Neo4j database (Maxy on bolt port 7687, Real Agent on 7688). Action runner units are transient and per-invocation, not per-brand, so no naming conflict is possible.
 - **Brand-isolated Neo4j:** when a brand provisions a dedicated Neo4j instance (any port other than 7687), the installer stops and disables the apt-package's system `neo4j.service` after enabling the brand-dedicated unit, so only one Neo4j process holds the shared `/var/lib/neo4j/run/` PID file. The seed step receives the brand-correct `NEO4J_URI` and `NEO4J_PASSWORD` as explicit environment variables — the seed script no longer carries a `bolt://localhost:7687` default. A failed dedicated start aborts the install loudly with a journalctl tail; there is no silent fallback to the system instance. Stop/disable targets the literal `neo4j.service` only, so peer brands running their own `neo4j-{brand}.service` are unaffected.
-- **Peer-aware system-unit guard:** before stopping the system `neo4j.service`, the installer checks whether any other brand on the device still depends on it — that is, has `NEO4J_URI=bolt://localhost:7687` in its `~/.<peer>/.env`. If so, the system unit is left enabled and active, and the install log shows `[neo4j] system unit kept active — peer brand <name> depends on port 7687` instead of the usual `[neo4j] disabling system unit` line. This prevents a `create-realagent` install from disabling Maxy's database on a host where Maxy still uses the shared system instance (the earlier platform fixes reproducer on Neo's laptop, 2026-04-28). On single-brand hosts and on multi-brand hosts where every peer runs a dedicated port, behaviour is unchanged.
+- **Peer-aware system-unit guard:** before stopping the system `neo4j.service`, the installer checks whether any other brand on the device still depends on it — that is, has `NEO4J_URI=bolt://localhost:7687` in its `~/.<peer>/.env`. If so, the system unit is left enabled and active, and the install log shows `[neo4j] system unit kept active — peer brand <name> depends on port 7687` instead of the usual `[neo4j] disabling system unit` line. This prevents a `create-realagent` install from disabling Maxy's database on a host where Maxy still uses the shared system instance (the earlier platform fixes reproducer on Neo's laptop, 2026-04-28). On single-brand hosts and on multi-brand hosts where every peer runs a dedicated port, behaviour is unchanged. The dedicated unit exports `NEO4J_HOME=<per-brand-data-dir>` alongside `NEO4J_CONF`, so `server.directories.run`, `server.directories.plugins`, and `server.directories.import` resolve per-brand — no collision with `/var/lib/neo4j/run/neo4j.pid`. The conf sed-overrides, mkdir-p, chown, and unit-write are idempotent and re-run on every install, so a host whose prior install left a broken unit recovers on retry.
 - **Shared:** both brands share the system Chromium/VNC stack, the Ollama model server, and the `cloudflared` command itself. Browser automation is serialised — one admin session at a time across both brands.
 
 To install a second brand on a device that already runs the first, just run the other installer. No flags needed for isolation:

package/payload/platform/plugins/docs/references/plugins-guide.md

@@ -66,6 +66,8 @@ Install verbatim:
 - `claude plugin install meeting-prep-agent@claude-for-financial-services`
 - `claude plugin install pdf-viewer@knowledge-work-plugins`
 
+Onboarding observability for this group: Step 1 emits `[plugin-onboarding] group=anthropic-verticals presented=3` when the three entries are offered, then `[plugin-onboarding] group=anthropic-verticals accepted=<n> declined=<n>` when Step 1 completes — derived from your submission against the closed set above. Grep `~/.{productName}/logs/server.log` for the full prefix to see both halves of the funnel.
+
 ### Premium Plugins
 
 Premium plugins are one-off purchases that grant permanent ownership. They are not part of the standard install — once purchased, {{productName}} delivers them automatically.

package/payload/server/public/assets/{Checkbox-CiL1E1ss.js → Checkbox-BsqexMy3.js}

@@ -1 +1 @@
-import{t as e}from"./jsx-runtime-BRxv9PO7.js";var t=e();function n({checked:e,onChange:n,label:r,disabled:i}){return(0,t.jsxs)(`label`,{className:`maxy-checkbox${i?` maxy-checkbox--disabled`:``}`,children:[(0,t.jsx)(`input`,{type:`checkbox`,checked:e,onChange:e=>n(e.target.checked),disabled:i}),(0,t.jsx)(`span`,{className:`maxy-checkbox__box`,children:`✱`}),r&&(0,t.jsx)(`span`,{className:`maxy-checkbox__label`,children:r})]})}export{n as t};
+import{t as e}from"./jsx-runtime-B8sGPXtT.js";var t=e();function n({checked:e,onChange:n,label:r,disabled:i}){return(0,t.jsxs)(`label`,{className:`maxy-checkbox${i?` maxy-checkbox--disabled`:``}`,children:[(0,t.jsx)(`input`,{type:`checkbox`,checked:e,onChange:e=>n(e.target.checked),disabled:i}),(0,t.jsx)(`span`,{className:`maxy-checkbox__box`,children:`✱`}),r&&(0,t.jsx)(`span`,{className:`maxy-checkbox__label`,children:r})]})}export{n as t};