@rubytech/create-maxy 1.0.697 → 1.0.699

package/package.json

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

package/payload/platform/neo4j/schema.cypher

@@ -259,8 +259,8 @@ ON EACH [k.summary, k.content];
 
 // ----------------------------------------------------------
 // Conversation node — persistent conversation sessions
-// One Conversation per sessionKey. Scoped to an account via
-// (Conversation)-[:BELONGS_TO]->(LocalBusiness).
+// One Conversation per sessionKey. Account scope is encoded by the
+// `accountId` property on the node itself — every read filters by it.
 // Public conversations carry a visitorId (browser cookie) and
 // agentSlug for session resume across page reloads and server restarts.
 // Task 621 — carries a `summary` string denormalised from the first
@@ -463,8 +463,9 @@ FOR (sr:StepResult) ON (sr.runId);
 
 // ----------------------------------------------------------
 // UserProfile node — structured knowledge about the business owner
-// Platform-native (no Schema.org equivalent). One per account.
-// Linked via (UserProfile)-[:BELONGS_TO]->(LocalBusiness).
+// Platform-native (no Schema.org equivalent). One per (accountId, userId).
+// Linked via (AdminUser)-[:HAS_PROFILE]->(UserProfile). Account scope is
+// encoded by the `accountId` property on the node itself.
 //
 // Created automatically on first admin session start via MERGE.
 // Properties populated progressively through conversation and
@@ -717,3 +718,31 @@ FOR (n:Trashed) ON (n.accountId);
 
 CREATE INDEX trashed_at IF NOT EXISTS
 FOR (n:Trashed) ON (n.trashedAt);
+
+// ----------------------------------------------------------
+// Person.linkedinUrl — natural key for LinkedIn-origin Persons.
+// Indexed (not uniquely constrained) so a Person can appear
+// first from another source (email-first) and later have its
+// linkedinUrl filled in without collision. Schema-base requires
+// `email or telephone` on :Person, but LinkedIn basic exports
+// rarely emit either for connections; `linkedinUrl` is the
+// reliable dedup key for the linkedin-import skill.
+// ----------------------------------------------------------
+CREATE INDEX person_linkedin_url IF NOT EXISTS
+FOR (p:Person) ON (p.linkedinUrl);
+
+// ----------------------------------------------------------
+// Credential — schema:EducationalOccupationalCredential.
+// Professional certifications (e.g. LinkedIn's Certifications.csv,
+// or credentials entered through memory-write). Natural key is
+// the triple (accountId, name, authority) — a credential is
+// identified by what it is and who issued it, within a tenant.
+// No existing Maxy label covers this semantics, so a new label
+// is warranted (unlike articles → :CreativeWork, recommendations
+// → :Review, skills → :DefinedTerm, which all reuse existing labels).
+// ----------------------------------------------------------
+CREATE CONSTRAINT credential_unique IF NOT EXISTS
+FOR (c:Credential) REQUIRE (c.accountId, c.name, c.authority) IS UNIQUE;
+
+CREATE INDEX credential_account IF NOT EXISTS
+FOR (c:Credential) ON (c.accountId);

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

@@ -52,7 +52,7 @@ The memory graph is stored on your Pi. It never leaves your network.
 
 ## The Web Interface
 
-The web app runs on your Pi on port 19200. A small always-on front door (`maxy-edge`) owns that port and the remote terminal transport — so when the Software Update command restarts the app server, the browser-side terminal keeps streaming bytes exactly like an SSH session would. The edge also hosts the update flow's own routes (the sudo prompt, the action launcher, the SSE progress stream, the installed-version poll), so the Software Update modal's log panel does not go blank during the app-server restart window — it keeps receiving lines, heartbeats, and the final exit event unbroken. Login cookies are HMAC-signed with a shared key on disk, so both processes recognise the same session without any coordination and you do not have to log in again after an update. It provides:
+The web app runs on your Pi on port 19200. A small always-on front door (`maxy-edge`) owns that port and the remote terminal transport — so when the Software Update command restarts the app server, the browser-side terminal keeps streaming bytes exactly like an SSH session would. The edge also hosts the update flow's own routes (the sudo prompt, the action launcher, the SSE progress stream, the installed-version poll), so the Software Update modal's log panel does not go blank during the app-server restart window — it keeps receiving lines, heartbeats, and the final exit event unbroken. Login cookies are HMAC-signed with a shared key on disk, so both processes recognise the same session without any coordination and you do not have to log in again after an update. Every request is also classified as LAN or external based on the network shape it arrived on — LAN browsers reach admin directly; the remote password screen only appears on the tunnel-exposed admin domain. It provides:
 
 - **Admin chat** (at `/`) — your primary interface, PIN-protected
 - **Public chat** (at `/{agent-name}`) — visitor-facing agents, each with their own URL. On public hostnames, the root path serves the default agent.

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

@@ -1,5 +1,33 @@
 # Troubleshooting
 
+## Fresh install opens to "Set your remote password" on the LAN URL
+
+**Symptom:** On a brand-new device, the LAN URL printed by `create-maxy` (e.g. `http://maxy.local:19200`) opens to a remote-password setup page instead of admin onboarding. This was a Task-647-era regression and should not occur on any install built after Task 679.
+
+**Diagnose:** On the Pi, grep the UI server log for the gate's disambiguation fields:
+
+```
+tail -200 ~/.maxy/logs/maxy-ui.log | rg '\[remote-auth\].*resolvedKind='
+```
+
+- `resolvedKind=lan` on a `login required` or `not configured` line means the classifier sees the request as local — if the browser is still on the remote-auth page, something cached the older page before the fix shipped (hard-refresh the tab).
+- `resolvedKind=external` means the request chain presents as remote (routable IP in the first `x-forwarded-for` hop). On a LAN-only browser this points to a proxy or VPN rewriting headers between the browser and the Pi.
+- `resolvedKind=unknown` is a defect — the classifier could not identify the TCP peer. Capture the log line and file it; do not work around it.
+
+**Fix:** If all three fields confirm the LAN shape and the gate still refuses, upgrade the platform (`Software Update` from admin chat) to pick up the Task-679 classifier.
+
+---
+
+## Remote sign-in is rejected with "Remote access requires TLS"
+
+**Symptom:** Posting the remote-auth password returns a plain-text `400 Remote access requires TLS` response instead of completing sign-in.
+
+**What this means:** The login endpoint will only issue a session cookie when the request arrived over HTTPS (via the Cloudflare tunnel). Browsers silently drop `Set-Cookie: Secure` on plain-HTTP responses, so minting a cookie there would produce a dead-end redirect. Task 679 replaced that silent failure with this loud one.
+
+**Fix:** Reach the admin surface through the tunnel hostname (e.g. `https://admin.<your-domain>`), not an IP or plain-HTTP URL. If you need LAN access, use the LAN URL (`http://<hostname>.local:<port>`) — LAN never hits the remote-auth endpoint.
+
+---
+
 ## Agent Not Responding
 
 **Symptom:** You send a message and nothing comes back, or the response never arrives.