@rubytech/create-maxy 1.0.696 → 1.0.698

package/package.json

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

package/payload/platform/neo4j/migrations/002-linkedin-types.cypher

@@ -0,0 +1,103 @@
+// ============================================================
+// Migration 002 — LinkedIn import node types
+// Adds the labels required to accommodate a full LinkedIn
+// Basic Data Export. Idempotent: every statement uses
+// IF NOT EXISTS so the migration can be re-run safely.
+// ============================================================
+
+// ----------------------------------------------------------
+// Organization — schema:Organization. LinkedIn companies that
+// connections work for, that Joel has held positions at, that
+// he follows, or that appear as recommendation subjects.
+// Distinct from :LocalBusiness (the Maxy account itself).
+//
+// Natural key: (accountId, nameNormalised) — lowercased,
+// whitespace-trimmed company name. LinkedIn export has no
+// stable organization id in the basic archive, so dedupe on
+// normalised display name.
+// ----------------------------------------------------------
+CREATE CONSTRAINT organization_account_name_unique IF NOT EXISTS
+FOR (o:Organization) REQUIRE (o.accountId, o.nameNormalised) IS UNIQUE;
+
+CREATE INDEX organization_account IF NOT EXISTS
+FOR (o:Organization) ON (o.accountId);
+
+CREATE VECTOR INDEX organization_embedding IF NOT EXISTS
+FOR (o:Organization) ON (o.embedding)
+OPTIONS {
+  indexConfig: {
+    `vector.dimensions`: 768,
+    `vector.similarity_function`: 'cosine'
+  }
+};
+
+// ----------------------------------------------------------
+// EducationalOrganization — schema:EducationalOrganization.
+// Schools attended (Education.csv). Separate label (not a
+// sublabel of Organization) so filter chips in /graph keep
+// companies and schools visually distinct. Same natural key
+// shape as Organization.
+// ----------------------------------------------------------
+CREATE CONSTRAINT edu_org_account_name_unique IF NOT EXISTS
+FOR (e:EducationalOrganization) REQUIRE (e.accountId, e.nameNormalised) IS UNIQUE;
+
+CREATE INDEX edu_org_account IF NOT EXISTS
+FOR (e:EducationalOrganization) ON (e.accountId);
+
+// ----------------------------------------------------------
+// Skill — Joel's declared skills (Skills.csv) and the skills
+// named in endorsement rows. Natural key (accountId,
+// nameNormalised) so "machine learning" and "Machine Learning"
+// collapse to one node.
+// ----------------------------------------------------------
+CREATE CONSTRAINT skill_account_name_unique IF NOT EXISTS
+FOR (s:Skill) REQUIRE (s.accountId, s.nameNormalised) IS UNIQUE;
+
+// ----------------------------------------------------------
+// Credential — schema:EducationalOccupationalCredential.
+// Professional certifications (Certifications.csv). Natural
+// key (accountId, name, authority) — a credential is defined
+// by its name and issuing authority.
+// ----------------------------------------------------------
+CREATE CONSTRAINT credential_unique IF NOT EXISTS
+FOR (c:Credential) REQUIRE (c.accountId, c.name, c.authority) IS UNIQUE;
+
+// ----------------------------------------------------------
+// Article — schema:Article. Posts Joel authored on LinkedIn
+// (Articles/ directory). Natural key elementId-less: content
+// hash of (title + publishedAt) scoped to account.
+// ----------------------------------------------------------
+CREATE CONSTRAINT article_unique IF NOT EXISTS
+FOR (a:Article) REQUIRE (a.accountId, a.articleHash) IS UNIQUE;
+
+// ----------------------------------------------------------
+// Recommendation — schema:Review (recommendation is a
+// specialisation). One row per written-about relationship,
+// direction encoded in edges (GAVE_RECOMMENDATION vs
+// RECEIVED_RECOMMENDATION). Natural key: sha256 of
+// (authorUrl + subjectUrl + creationDate).
+// ----------------------------------------------------------
+CREATE CONSTRAINT recommendation_unique IF NOT EXISTS
+FOR (r:Recommendation) REQUIRE (r.accountId, r.recommendationHash) IS UNIQUE;
+
+// ----------------------------------------------------------
+// Sublabels — no new constraints, no new indexes. The
+// existing Conversation / Message constraints apply.
+//   :Conversation:LinkedInConversation — messages.csv threads
+//   :Message:LinkedInMessage            — individual DMs
+// The sublabel is set at CREATE time (set-semantic labels)
+// and drives /graph canvas colour and filter-chip separation
+// without schema fragmentation.
+// ----------------------------------------------------------
+
+// ----------------------------------------------------------
+// Person additions — LinkedIn carries two properties that do
+// not already have an index: linkedinUrl (natural key for
+// LinkedIn-origin persons) and isOperator (marks Joel's own
+// Person node so the import can MATCH it from every row).
+// ----------------------------------------------------------
+CREATE INDEX person_linkedin_url IF NOT EXISTS
+FOR (p:Person) ON (p.linkedinUrl);
+
+CREATE INDEX person_is_operator IF NOT EXISTS
+FOR (p:Person) ON (p.accountId, p.isOperator);

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.