@rubytech/create-maxy-code 0.1.500 → 0.1.502

package/payload/platform/lib/graph-style/src/index.ts

@@ -42,11 +42,12 @@ export const GRAPH_LABEL_COLOURS: Record<string, string> = {
   // JobLogic service-delivery ontology (Task 1084; supersedes the Task 650/773
   // homegrown set). Muted brick-red / earthy family — the service register sits
   // apart from people-terracotta, viewing-amber, and task-rose bands so
-  // sitedesk legends read as their own group. Top-level (operator-entry)
-  // labels only; child labels (QuoteLine, Milestone, Valuation, VariationNote,
-  // JobCost, Contact, PurchaseOrderLine, InvoiceLine, InvoicePayment, Credit)
-  // intentionally stay fallback-grey. :Engineer is an additional label on
-  // Person and takes the Person colour; :Supplier is an additional label on
+  // sitedesk legends read as their own group. These are the top-level
+  // (operator-entry) labels; the child labels (QuoteLine, Milestone, Valuation,
+  // VariationNote, JobCost, Contact, PurchaseOrderLine, InvoiceLine,
+  // InvoicePayment, Credit) are coloured in the Task 1965 block appended at the
+  // end of this object, not here. :Engineer is an additional label on Person
+  // and takes the Person colour; :Supplier is an additional label on
   // Organization and takes the tobacco Organization colour. All hexes here are
   // pairwise-unique across the registry.
   Job: '#8C3B2E',
@@ -156,6 +157,93 @@ export const GRAPH_LABEL_COLOURS: Record<string, string> = {
   // (this object's key order), so a mid-table insert would silently change
   // the rendered shape of every label after it.
   CashEntry: '#7D5A2B',
+
+  // --- Task 1965: colour every node type that can appear in the graph ---
+  // Appended at the END so SHAPE_BY_LABEL indices for the labels above are
+  // unchanged. Grouped by family band; each hex is pairwise-unique across the
+  // whole registry (except the pre-existing UserMessage/Preference twin).
+
+  // Ledger / money children (brown-gold, beside Invoice and CashEntry).
+  InvoiceLine: '#7A5326',
+  InvoicePayment: '#8A6230',
+  QuoteLine: '#9A7038',
+  PurchaseOrderLine: '#A67E42',
+  JobCost: '#6A4A22',
+  Credit: '#B48A48',
+  Retainer: '#C29A55',
+  Sale: '#8E5E2A',
+  Valuation: '#A06A34',
+  Order: '#B87C3E',
+  DiningOrder: '#C9954E',
+
+  // Documents / content (steel-blue, hue-adjacent to the business slates).
+  Content: '#58708C',
+  Report: '#6D8299',
+  Page: '#849AAF',
+  Post: '#93A7BA',
+  VariationNote: '#47617B',
+  FileArtifact: '#A9BBCC',
+
+  // Marketing (bright teal-green, apart from workflow and research teals).
+  SocialPost: '#2FA69A',
+  Campaign: '#3FB8A0',
+  BrandDeal: '#57C2AE',
+  Recommendation: '#74CDBB',
+
+  // CRM people (terracotta, beside Person and Customer).
+  Contact: '#C97E52',
+  Lead: '#A85E38',
+  Position: '#96522E',
+  Audience: '#E0B088',
+
+  // Places / transport / retail (forest-emerald, apart from knowledge moss).
+  PostalAddress: '#2E8B57',
+  Room: '#3A9B63',
+  StoreLocation: '#46A96F',
+  Vehicle: '#54B77B',
+  Route: '#62C187',
+  Stop: '#2A7A4C',
+  Shipment: '#6FCB93',
+  Reservation: '#7ED4A0',
+  TableReservation: '#8CDBAC',
+  Menu: '#1F6B41',
+  MenuItem: '#98E0B6',
+  Product: '#34925E',
+  StockMovement: '#4CA574',
+
+  // Work / delivery (indigo, apart from the strategy indigo band).
+  Milestone: '#4A5FA8',
+  Deliverable: '#6274C0',
+  TimeEntry: '#8189CE',
+  Engagement: '#9AA0DA',
+  Case: '#3B4E92',
+  Meeting: '#5566B4',
+
+  // Idea (amber).
+  Idea: '#E0A82E',
+
+  // Web analytics (sky-cyan, apart from the research teal).
+  Session: '#2AA7C4',
+  PageView: '#3DB4CE',
+  Click: '#55C0D6',
+  ScrollMilestone: '#70CCDE',
+  TimelineEvent: '#1E93B0',
+  AnonVisitor: '#88D6E6',
+  AEOAudit: '#46B0CB',
+
+  // WhatsApp transport (brand green).
+  WhatsAppConversation: '#128C7E',
+  WhatsAppMessage: '#1FA894',
+
+  // Cloudflare / chain infra (grey-blue).
+  CloudflareHostname: '#5B6E82',
+  CloudflareTunnel: '#6E8296',
+  Chain: '#47586A',
+  ChainLink: '#8496AA',
+
+  // Voice (violet).
+  VoiceProfile: '#9B59B6',
+  VoiceEdit: '#B07CC9',
 }
 
 export const FALLBACK_LABEL_COLOUR = '#94A3B8'
@@ -251,6 +339,18 @@ export function shapeForLabel(label: string): GraphNodeShape {
   return SHAPE_BY_LABEL[label] ?? FALLBACK_LABEL_SHAPE
 }
 
+/**
+ * Node labels written by code with no schema node-type-table row and no
+ * typed-edge declaration. They still render as graph nodes, so they must carry
+ * a colour + glyph like any other node type. The reconciliation gate in
+ * __tests__/icons.test.ts folds this set into the node-label universe. Add a
+ * label here when the runtime `op=icon-fallback` census names one that no
+ * schema table or typed edge declares.
+ */
+export const CODE_EMITTED_NODE_LABELS: ReadonlySet<string> = Object.freeze(
+  new Set(['FileArtifact']),
+) as ReadonlySet<string>
+
 // ---------------------------------------------------------------------------
 // Icon registry — a third visual channel alongside colour + shape.
 //
@@ -325,6 +425,67 @@ const LABEL_ICONS: Record<string, string> = {
   Finding: '<path d="M15 14c.2-1 .7-1.7 1.5-2.5 1-.9 1.5-2.2 1.5-3.5A6 6 0 0 0 6 8c0 1 .2 2.2 1.5 3.5.7.7 1.3 1.5 1.5 2.5"></path><path d="M9 18h6"></path><path d="M10 22h4"></path>',
   Hypothesis: '<path d="M14 2v6a2 2 0 0 0 .245.96l5.51 10.08A2 2 0 0 1 18 22H6a2 2 0 0 1-1.755-2.96l5.51-10.08A2 2 0 0 0 10 8V2"></path><path d="M6.453 15h11.094"></path><path d="M8.5 2h7"></path>',
   CashEntry: '<rect width="20" height="12" x="2" y="6" rx="2"></rect><circle cx="12" cy="12" r="2"></circle><path d="M6 12h.01"></path><path d="M18 12h.01"></path>',
+  // --- Task 1965: glyphs for the 60 previously-uncovered node labels ---
+  InvoiceLine: '<path d="M13 16H8" /><path d="M14 8H8" /><path d="M16 12H8" /><path d="M4 3a1 1 0 0 1 1-1 1.3 1.3 0 0 1 .7.2l.933.6a1.3 1.3 0 0 0 1.4 0l.934-.6a1.3 1.3 0 0 1 1.4 0l.933.6a1.3 1.3 0 0 0 1.4 0l.933-.6a1.3 1.3 0 0 1 1.4 0l.934.6a1.3 1.3 0 0 0 1.4 0l.933-.6A1.3 1.3 0 0 1 19 2a1 1 0 0 1 1 1v18a1 1 0 0 1-1 1 1.3 1.3 0 0 1-.7-.2l-.933-.6a1.3 1.3 0 0 0-1.4 0l-.934.6a1.3 1.3 0 0 1-1.4 0l-.933-.6a1.3 1.3 0 0 0-1.4 0l-.933.6a1.3 1.3 0 0 1-1.4 0l-.934-.6a1.3 1.3 0 0 0-1.4 0l-.933.6a1.3 1.3 0 0 1-.7.2 1 1 0 0 1-1-1z" />',
+  InvoicePayment: '<path d="M11 15h2a2 2 0 1 0 0-4h-3c-.6 0-1.1.2-1.4.6L3 17" /><path d="m7 21 1.6-1.4c.3-.4.8-.6 1.4-.6h4c1.1 0 2.1-.4 2.8-1.2l4.6-4.4a2 2 0 0 0-2.75-2.91l-4.2 3.9" /><path d="m2 16 6 6" /><circle cx="16" cy="9" r="2.9" /><circle cx="6" cy="5" r="3" />',
+  QuoteLine: '<path d="M3 5h.01" /><path d="M3 12h.01" /><path d="M3 19h.01" /><path d="M8 5h13" /><path d="M8 12h13" /><path d="M8 19h13" />',
+  PurchaseOrderLine: '<path d="M11 5h10" /><path d="M11 12h10" /><path d="M11 19h10" /><path d="M4 4h1v5" /><path d="M4 9h2" /><path d="M6.5 20H3.4c0-1 2.6-1.925 2.6-3.5a1.5 1.5 0 0 0-2.6-1.02" />',
+  JobCost: '<rect width="20" height="12" x="2" y="6" rx="2" /><circle cx="12" cy="12" r="2" /><path d="M6 12h.01M18 12h.01" />',
+  Credit: '<path d="M3.85 8.62a4 4 0 0 1 4.78-4.77 4 4 0 0 1 6.74 0 4 4 0 0 1 4.78 4.78 4 4 0 0 1 0 6.74 4 4 0 0 1-4.77 4.78 4 4 0 0 1-6.75 0 4 4 0 0 1-4.78-4.77 4 4 0 0 1 0-6.76Z" /><path d="M16 8h-6a2 2 0 1 0 0 4h4a2 2 0 1 1 0 4H8" /><path d="M12 18V6" />',
+  Retainer: '<path d="M19 7V4a1 1 0 0 0-1-1H5a2 2 0 0 0 0 4h15a1 1 0 0 1 1 1v4h-3a2 2 0 0 0 0 4h3a1 1 0 0 0 1-1v-2a1 1 0 0 0-1-1" /><path d="M3 5v14a2 2 0 0 0 2 2h15a1 1 0 0 0 1-1v-4" />',
+  Sale: '<path d="M12 17V7" /><path d="M16 8h-6a2 2 0 0 0 0 4h4a2 2 0 0 1 0 4H8" /><path d="M4 3a1 1 0 0 1 1-1 1.3 1.3 0 0 1 .7.2l.933.6a1.3 1.3 0 0 0 1.4 0l.934-.6a1.3 1.3 0 0 1 1.4 0l.933.6a1.3 1.3 0 0 0 1.4 0l.933-.6a1.3 1.3 0 0 1 1.4 0l.934.6a1.3 1.3 0 0 0 1.4 0l.933-.6A1.3 1.3 0 0 1 19 2a1 1 0 0 1 1 1v18a1 1 0 0 1-1 1 1.3 1.3 0 0 1-.7-.2l-.933-.6a1.3 1.3 0 0 0-1.4 0l-.934.6a1.3 1.3 0 0 1-1.4 0l-.933-.6a1.3 1.3 0 0 0-1.4 0l-.933.6a1.3 1.3 0 0 1-1.4 0l-.934-.6a1.3 1.3 0 0 0-1.4 0l-.933.6a1.3 1.3 0 0 1-.7.2 1 1 0 0 1-1-1z" />',
+  Valuation: '<path d="M12 3v18" /><path d="m19 8 3 8a5 5 0 0 1-6 0zV7" /><path d="M3 7h1a17 17 0 0 0 8-2 17 17 0 0 0 8 2h1" /><path d="m5 8 3 8a5 5 0 0 1-6 0zV7" /><path d="M7 21h10" />',
+  Order: '<path d="M16 10a4 4 0 0 1-8 0" /><path d="M3.103 6.034h17.794" /><path d="M3.4 5.467a2 2 0 0 0-.4 1.2V20a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V6.667a2 2 0 0 0-.4-1.2l-2-2.667A2 2 0 0 0 17 2H7a2 2 0 0 0-1.6.8z" />',
+  DiningOrder: '<path d="M3 2v7c0 1.1.9 2 2 2h4a2 2 0 0 0 2-2V2" /><path d="M7 2v20" /><path d="M21 15V2a5 5 0 0 0-5 5v6c0 1.1.9 2 2 2h3Zm0 0v7" />',
+  Content: '<path d="M15 18h-5" /><path d="M18 14h-8" /><path d="M4 22h16a2 2 0 0 0 2-2V4a2 2 0 0 0-2-2H8a2 2 0 0 0-2 2v16a2 2 0 0 1-4 0v-9a2 2 0 0 1 2-2h2" /><rect width="8" height="4" x="10" y="6" rx="1" />',
+  Report: '<rect width="8" height="4" x="8" y="2" rx="1" ry="1" /><path d="M16 4h2a2 2 0 0 1 2 2v14a2 2 0 0 1-2 2H6a2 2 0 0 1-2-2V6a2 2 0 0 1 2-2h2" /><path d="M12 11h4" /><path d="M12 16h4" /><path d="M8 11h.01" /><path d="M8 16h.01" />',
+  Page: '<path d="M6 22a2 2 0 0 1-2-2V4a2 2 0 0 1 2-2h8a2.4 2.4 0 0 1 1.704.706l3.588 3.588A2.4 2.4 0 0 1 20 8v12a2 2 0 0 1-2 2z" /><path d="M14 2v5a1 1 0 0 0 1 1h5" />',
+  Post: '<path d="M12 3H5a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2v-7" /><path d="M18.375 2.625a1 1 0 0 1 3 3l-9.013 9.014a2 2 0 0 1-.853.505l-2.873.84a.5.5 0 0 1-.62-.62l.84-2.873a2 2 0 0 1 .506-.852z" />',
+  SocialPost: '<path d="M11 6a13 13 0 0 0 8.4-2.8A1 1 0 0 1 21 4v12a1 1 0 0 1-1.6.8A13 13 0 0 0 11 14H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2z" /><path d="M6 14a12 12 0 0 0 2.4 7.2 2 2 0 0 0 3.2-2.4A8 8 0 0 1 10 14" /><path d="M8 6v8" />',
+  VariationNote: '<path d="M6 22a2 2 0 0 1-2-2V4a2 2 0 0 1 2-2h8a2.4 2.4 0 0 1 1.704.706l3.588 3.588A2.4 2.4 0 0 1 20 8v12a2 2 0 0 1-2 2z" /><path d="M9 10h6" /><path d="M12 13V7" /><path d="M9 17h6" />',
+  Contact: '<path d="M16 2v2" /><path d="M17.915 22a6 6 0 0 0-12 0" /><path d="M8 2v2" /><circle cx="12" cy="12" r="4" /><rect x="3" y="4" width="18" height="18" rx="2" />',
+  Lead: '<path d="M16 21v-2a4 4 0 0 0-4-4H6a4 4 0 0 0-4 4v2" /><circle cx="9" cy="7" r="4" /><line x1="19" x2="19" y1="8" y2="14" /><line x1="22" x2="16" y1="11" y2="11" />',
+  Position: '<path d="M16 20V4a2 2 0 0 0-2-2h-4a2 2 0 0 0-2 2v16" /><rect width="20" height="14" x="2" y="6" rx="2" />',
+  Audience: '<path d="M18 21a8 8 0 0 0-16 0" /><circle cx="10" cy="8" r="5" /><path d="M22 20c0-3.37-2-6.5-4-8a5 5 0 0 0-.45-8.3" />',
+  PostalAddress: '<path d="M18 8c0 3.613-3.869 7.429-5.393 8.795a1 1 0 0 1-1.214 0C9.87 15.429 6 11.613 6 8a6 6 0 0 1 12 0" /><circle cx="12" cy="8" r="2" /><path d="M8.714 14h-3.71a1 1 0 0 0-.948.683l-2.004 6A1 1 0 0 0 3 22h18a1 1 0 0 0 .948-1.316l-2-6a1 1 0 0 0-.949-.684h-3.712" />',
+  Room: '<path d="M11 20H2" /><path d="M11 4.562v16.157a1 1 0 0 0 1.242.97L19 20V5.562a2 2 0 0 0-1.515-1.94l-4-1A2 2 0 0 0 11 4.561z" /><path d="M11 4H8a2 2 0 0 0-2 2v14" /><path d="M14 12h.01" /><path d="M22 20h-3" />',
+  StoreLocation: '<path d="M15 21v-5a1 1 0 0 0-1-1h-4a1 1 0 0 0-1 1v5" /><path d="M17.774 10.31a1.12 1.12 0 0 0-1.549 0 2.5 2.5 0 0 1-3.451 0 1.12 1.12 0 0 0-1.548 0 2.5 2.5 0 0 1-3.452 0 1.12 1.12 0 0 0-1.549 0 2.5 2.5 0 0 1-3.77-3.248l2.889-4.184A2 2 0 0 1 7 2h10a2 2 0 0 1 1.653.873l2.895 4.192a2.5 2.5 0 0 1-3.774 3.244" /><path d="M4 10.95V19a2 2 0 0 0 2 2h12a2 2 0 0 0 2-2v-8.05" />',
+  Vehicle: '<path d="M19 17h2c.6 0 1-.4 1-1v-3c0-.9-.7-1.7-1.5-1.9C18.7 10.6 16 10 16 10s-1.3-1.4-2.2-2.3c-.5-.4-1.1-.7-1.8-.7H5c-.6 0-1.1.4-1.4.9l-1.4 2.9A3.7 3.7 0 0 0 2 12v4c0 .6.4 1 1 1h2" /><circle cx="7" cy="17" r="2" /><path d="M9 17h6" /><circle cx="17" cy="17" r="2" />',
+  Route: '<circle cx="6" cy="19" r="3" /><path d="M9 19h8.5a3.5 3.5 0 0 0 0-7h-11a3.5 3.5 0 0 1 0-7H15" /><circle cx="18" cy="5" r="3" />',
+  Stop: '<path d="M20 10c0 4.993-5.539 10.193-7.399 11.799a1 1 0 0 1-1.202 0C9.539 20.193 4 14.993 4 10a8 8 0 0 1 16 0" /><circle cx="12" cy="10" r="3" />',
+  Shipment: '<path d="M11 21.73a2 2 0 0 0 2 0l7-4A2 2 0 0 0 21 16V8a2 2 0 0 0-1-1.73l-7-4a2 2 0 0 0-2 0l-7 4A2 2 0 0 0 3 8v8a2 2 0 0 0 1 1.73z" /><path d="M12 22V12" /><polyline points="3.29 7 12 12 20.71 7" /><path d="m7.5 4.27 9 5.15" />',
+  Reservation: '<path d="M8 2v4" /><path d="M16 2v4" /><rect width="18" height="18" x="3" y="4" rx="2" /><path d="M3 10h18" /><path d="m9 16 2 2 4-4" />',
+  TableReservation: '<path d="m16 2-2.3 2.3a3 3 0 0 0 0 4.2l1.8 1.8a3 3 0 0 0 4.2 0L22 8" /><path d="M15 15 3.3 3.3a4.2 4.2 0 0 0 0 6l7.3 7.3c.7.7 2 .7 2.8 0L15 15Zm0 0 7 7" /><path d="m2.1 21.8 6.4-6.3" /><path d="m19 5-7 7" />',
+  Menu: '<path d="M12 5v16" /><path d="M20.001 19A2 2 0 0022 17V5a2 2 0 00-1.999-2L16 3.002A5 5 0 0012 5a5 5 0 00-4-2H4a2 2 0 00-2 2v12a2 2 0 001.999 2H8a5 5 0 014 2 5 5 0 014-2z" />',
+  MenuItem: '<path d="M7 21h10" /><path d="M12 21a9 9 0 0 0 9-9H3a9 9 0 0 0 9 9Z" /><path d="M11.38 12a2.4 2.4 0 0 1-.4-4.77 2.4 2.4 0 0 1 3.2-2.77 2.4 2.4 0 0 1 3.47-.63 2.4 2.4 0 0 1 3.37 3.37 2.4 2.4 0 0 1-1.1 3.7 2.51 2.51 0 0 1 .03 1.1" /><path d="m13 12 4-4" /><path d="M10.9 7.25A3.99 3.99 0 0 0 4 10c0 .73.2 1.41.54 2" />',
+  Product: '<path d="M21 8a2 2 0 0 0-1-1.73l-7-4a2 2 0 0 0-2 0l-7 4A2 2 0 0 0 3 8v8a2 2 0 0 0 1 1.73l7 4a2 2 0 0 0 2 0l7-4A2 2 0 0 0 21 16Z" /><path d="m3.3 7 8.7 5 8.7-5" /><path d="M12 22V12" />',
+  StockMovement: '<path d="m16 3 4 4-4 4" /><path d="M20 7H4" /><path d="m8 21-4-4 4-4" /><path d="M4 17h16" />',
+  Milestone: '<path d="M4 22V4a1 1 0 0 1 .4-.8A6 6 0 0 1 8 2c3 0 5 2 7.333 2q2 0 3.067-.8A1 1 0 0 1 20 4v10a1 1 0 0 1-.4.8A6 6 0 0 1 16 16c-3 0-5-2-8-2a6 6 0 0 0-4 1.528" />',
+  Deliverable: '<path d="M12 22V12" /><path d="m16 17 2 2 4-4" /><path d="M21 11.127V8a2 2 0 0 0-1-1.73l-7-4a2 2 0 0 0-2 0l-7 4A2 2 0 0 0 3 8v8a2 2 0 0 0 1 1.729l7 4a2 2 0 0 0 2 .001l1.32-.753" /><path d="M3.29 7 12 12l8.71-5" /><path d="m7.5 4.27 8.997 5.148" />',
+  TimeEntry: '<line x1="10" x2="14" y1="2" y2="2" /><line x1="12" x2="15" y1="14" y2="11" /><circle cx="12" cy="14" r="8" />',
+  Engagement: '<path d="m11 17 2 2a1 1 0 1 0 3-3" /><path d="m14 14 2.5 2.5a1 1 0 1 0 3-3l-3.88-3.88a3 3 0 0 0-4.24 0l-.88.88a1 1 0 1 1-3-3l2.81-2.81a5.79 5.79 0 0 1 7.06-.87l.47.28a2 2 0 0 0 1.42.25L21 4" /><path d="m21 3 1 11h-2" /><path d="M3 3 2 14l6.5 6.5a1 1 0 1 0 3-3" /><path d="M3 4h8" />',
+  Case: '<path d="M20 20a2 2 0 0 0 2-2V8a2 2 0 0 0-2-2h-7.9a2 2 0 0 1-1.69-.9L9.6 3.9A2 2 0 0 0 7.93 3H4a2 2 0 0 0-2 2v13a2 2 0 0 0 2 2Z" />',
+  Meeting: '<path d="M16 21v-2a4 4 0 0 0-4-4H6a4 4 0 0 0-4 4v2" /><path d="M16 3.128a4 4 0 0 1 0 7.744" /><path d="M22 21v-2a4 4 0 0 0-3-3.87" /><circle cx="9" cy="7" r="4" />',
+  Idea: '<path d="M15 14c.2-1 .7-1.7 1.5-2.5 1-.9 1.5-2.2 1.5-3.5A6 6 0 0 0 6 8c0 1 .2 2.2 1.5 3.5.7.7 1.3 1.5 1.5 2.5" /><path d="M9 18h6" /><path d="M10 22h4" />',
+  Campaign: '<path d="M12 15v5s3.03-.55 4-2c1.08-1.62 0-5 0-5" /><path d="M4.5 16.5c-1.5 1.26-2 5-2 5s3.74-.5 5-2c.71-.84.7-2.13-.09-2.91a2.18 2.18 0 0 0-2.91-.09" /><path d="M9 12a22 22 0 0 1 2-3.95A12.88 12.88 0 0 1 22 2c0 2.72-.78 7.5-6 11a22.4 22.4 0 0 1-4 2z" /><path d="M9 12H4s.55-3.03 2-4c1.62-1.08 5 .05 5 .05" />',
+  BrandDeal: '<path d="M3.85 8.62a4 4 0 0 1 4.78-4.77 4 4 0 0 1 6.74 0 4 4 0 0 1 4.78 4.78 4 4 0 0 1 0 6.74 4 4 0 0 1-4.77 4.78 4 4 0 0 1-6.75 0 4 4 0 0 1-4.78-4.77 4 4 0 0 1 0-6.76Z" /><path d="m9 12 2 2 4-4" />',
+  Recommendation: '<path d="M15 5.88 14 10h5.83a2 2 0 0 1 1.92 2.56l-2.33 8A2 2 0 0 1 17.5 22H4a2 2 0 0 1-2-2v-8a2 2 0 0 1 2-2h2.76a2 2 0 0 0 1.79-1.11L12 2a3.13 3.13 0 0 1 3 3.88Z" /><path d="M7 10v12" />',
+  Session: '<rect width="20" height="14" x="2" y="3" rx="2" /><line x1="8" x2="16" y1="21" y2="21" /><line x1="12" x2="12" y1="17" y2="21" />',
+  PageView: '<path d="M2.062 12.348a1 1 0 0 1 0-.696 10.75 10.75 0 0 1 19.876 0 1 1 0 0 1 0 .696 10.75 10.75 0 0 1-19.876 0" /><circle cx="12" cy="12" r="3" />',
+  Click: '<path d="M14 4.1 12 6" /><path d="m5.1 8-2.9-.8" /><path d="m6 12-1.9 2" /><path d="M7.2 2.2 8 5.1" /><path d="M9.037 9.69a.498.498 0 0 1 .653-.653l11 4.5a.5.5 0 0 1-.074.949l-4.349 1.041a1 1 0 0 0-.74.739l-1.04 4.35a.5.5 0 0 1-.95.074z" />',
+  ScrollMilestone: '<path d="m7 6 5 5 5-5" /><path d="m7 13 5 5 5-5" />',
+  TimelineEvent: '<path d="M3 12a9 9 0 1 0 9-9 9.75 9.75 0 0 0-6.74 2.74L3 8" /><path d="M3 3v5h5" /><path d="M12 7v5l4 2" />',
+  AnonVisitor: '<path d="M9 10h.01" /><path d="M15 10h.01" /><path d="M12 2a8 8 0 0 0-8 8v12l3-3 2.5 2.5L12 19l2.5 2.5L17 19l3 3V10a8 8 0 0 0-8-8z" />',
+  AEOAudit: '<path d="m8 11 2 2 4-4" /><circle cx="11" cy="11" r="8" /><path d="m21 21-4.3-4.3" />',
+  WhatsAppConversation: '<path d="M2.992 16.342a2 2 0 0 1 .094 1.167l-1.065 3.29a1 1 0 0 0 1.236 1.168l3.413-.998a2 2 0 0 1 1.099.092 10 10 0 1 0-4.777-4.719" />',
+  WhatsAppMessage: '<path d="M22 17a2 2 0 0 1-2 2H6.828a2 2 0 0 0-1.414.586l-2.202 2.202A.71.71 0 0 1 2 21.286V5a2 2 0 0 1 2-2h16a2 2 0 0 1 2 2z" /><path d="M7 11h10" /><path d="M7 15h6" /><path d="M7 7h8" />',
+  CloudflareHostname: '<circle cx="12" cy="12" r="10" /><path d="M12 2a14.5 14.5 0 0 0 0 20 14.5 14.5 0 0 0 0-20" /><path d="M2 12h20" />',
+  CloudflareTunnel: '<rect x="16" y="16" width="6" height="6" rx="1" /><rect x="2" y="16" width="6" height="6" rx="1" /><rect x="9" y="2" width="6" height="6" rx="1" /><path d="M5 16v-3a1 1 0 0 1 1-1h12a1 1 0 0 1 1 1v3" /><path d="M12 12V8" />',
+  Chain: '<path d="M10 13a5 5 0 0 0 7.54.54l3-3a5 5 0 0 0-7.07-7.07l-1.72 1.71" /><path d="M14 11a5 5 0 0 0-7.54-.54l-3 3a5 5 0 0 0 7.07 7.07l1.71-1.71" />',
+  ChainLink: '<path d="M9 17H7A5 5 0 0 1 7 7h2" /><path d="M15 7h2a5 5 0 1 1 0 10h-2" /><line x1="8" x2="16" y1="12" y2="12" />',
+  FileArtifact: '<path d="M13.659 22H18a2 2 0 0 0 2-2V8a2.4 2.4 0 0 0-.706-1.706l-3.588-3.588A2.4 2.4 0 0 0 14 2H6a2 2 0 0 0-2 2v11.5" /><path d="M14 2v5a1 1 0 0 0 1 1h5" /><path d="M8 12v-1" /><path d="M8 18v-2" /><path d="M8 7V6" /><circle cx="8" cy="20" r="2" />',
+  VoiceProfile: '<path d="M12 19v3" /><path d="M19 10v2a7 7 0 0 1-14 0v-2" /><rect x="9" y="2" width="6" height="13" rx="3" />',
+  VoiceEdit: '<path d="M2 10v3" /><path d="M6 6v11" /><path d="M10 3v18" /><path d="M14 8v7" /><path d="M18 5v13" /><path d="M22 10v3" />',
 }
 
 /**

package/payload/platform/plugins/admin/PLUGIN.md

@@ -184,6 +184,7 @@ Tools are available via the `admin` MCP server.
 | Investigate a bug or unexpected behaviour | User asks to debug, fix a bug, find the root cause, or investigate an error | `skills/investigate/SKILL.md` |
 | Capture work as a task before implementing | User asks to "task it", create a task, or describes work that should be a task file before a sprint | `skills/task/SKILL.md` |
 | Run an insight pass on this session | Operator asks to run an insight pass, review this session, capture what we learned, or do a retrospective on the conversation | `skills/insight/SKILL.md` |
+| Summarise the last turn | User asks to summarise, recap, or give the "in short" version of what the agent just said or asked | `skills/summarise/SKILL.md` |
 
 ## Hooks
 

package/payload/platform/plugins/admin/skills/agent-builder/SKILL.md

@@ -28,6 +28,21 @@ Load `references/agent-pattern.md`. It is the canonical shape: the two kinds of
 deny-by-default tool rule, model-choice guidance, and the three-part contract body. Use it
 throughout. Do not paraphrase the pattern from memory; the reference is the source.
 
+## Step 0: Check for a deliverable catalogue
+
+When the operator asks what can be built here, rather than naming a specific agent, first look for
+a shipped suggestion catalogue. A premium bundle can ship a `DELIVERABLES.md` at its root listing
+deliverables it supports beyond the agents it already ships. Get the enabled bundles from
+`capabilities-here`, then for each one read `$PLATFORM_ROOT/../premium-plugins/<bundle>/DELIVERABLES.md`
+if it exists, the bundle root where its `BUNDLE.md` and `agents/` live. Offer the operator the entries you find, grouped by bundle. If
+no enabled bundle ships one, skip this step and go to Step 1.
+
+The catalogue is a suggestion list, not a shipped roster. Each entry is authored bespoke for this
+account when the operator picks it, because a generic version carries none of the customer's own
+determinism. On a pick, run Steps 1 through 7 to author the skill and agent into the account's own
+plugins tree, and name the agent for the customer's actual deliverable rather than the catalogue's
+ontology label, exactly as the catalogue instructs. The ontology name is grounding, not a file name.
+
 ## Step 1: Name the deliverable
 
 Ask: **"What is the one thing this agent hands back?"**

package/payload/platform/plugins/admin/skills/platform-architecture/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: platform-architecture
 description: Use when grounding any documented-surface claim about what Maxy ships — plugins, skills, specialists, install/deploy flows, internals. This is the install catalogue, not evidence of what is enabled on the current account. For install state on this account, call `capabilities-here`; for documented surface, cite the `Source:` URL inline.
-content-hash: sha256:8be6993be76afa65716e56cd2dcb17c87f6588109d64ca81e38db74af1d4d48c
+content-hash: sha256:f78dfe81d9832fd7197627e1cf770c730bb2d16b4b640f1a47558e86acfe0db8
 brand: maxy-code
 product-name: Maxy
 ---
@@ -3045,6 +3045,37 @@ routines exist for the account is the account-scope-miss signature; the logged
 `cron=` on `outcome=ok` confirms the persisted expression without opening the
 graph.
 
+### Skills
+
+The Skills surface (`/skills`) is the admin view of the account's operator-
+authored skills — the `SKILL.md` files the store-skill tool writes under
+`<accountDir>/plugins/<plugin>/skills/<skill>/` (the durable per-account plugin
+root, never the immutable `PLATFORM_ROOT/plugins` tree). It renders one card per
+skill (name, owning plugin, frontmatter description, reference count); a card
+opens a **read-only** detail modal showing the frontmatter, the SKILL.md body,
+and the reference filenames. The page is read-only by design — skills are
+authored and edited through the chat interface — with one exception: a **delete**
+behind an explicit confirm step in the modal. A confirmed delete removes the
+skill directory, and the whole plugin directory when that was its last skill.
+
+The route (`server/routes/admin/skills.ts`) walks only the account tree, so
+shipped platform skills never appear. Plugin and skill path params are kebab-case
+validated (`/^[a-z0-9][a-z0-9-]*$/`) — the traversal guard; anything else 400s.
+
+| Route | Behaviour |
+|-------|-----------|
+| `GET /api/admin/skills` | Enumerates `plugins/*/skills/*/SKILL.md`, returns `{plugin, skill, description, refCount}` per skill, sorted plugin then skill. A per-entry read error logs `op=list-skip` rather than silently shortening the list. |
+| `GET /api/admin/skills/:plugin/:skill` | One skill's parsed frontmatter (`name`, `description`, `publicEmbed`), the SKILL.md body, and the reference filenames. Unknown skill 404s. |
+| `DELETE /api/admin/skills/:plugin/:skill` | Removes the skill dir; removes the plugin dir when its `skills/` empties. Returns `{ok, skillDirGone, pluginDirRemoved}` measured after the rm. |
+
+Observability rides `[admin:skills]`: `op=list accountId=<8> plugins=<n>
+skills=<n>` (the surface's own heartbeat — `skills=0` against a populated
+`plugins/*/skills/` is the broken-walk signature), `op=get plugin=<…> skill=<…>
+found=<bool>`, and `op=delete plugin=<…> skill=<…> outcome=ok
+skillDirGone=<bool> pluginDirRemoved=<bool>` (`skillDirGone=false` with
+`outcome=ok` is a named failure) / `outcome=rejected reason=<invalid-name|
+not-found|rm-error>`.
+
 ### Graph
 
 | Mount | Purpose |
@@ -3056,6 +3087,25 @@ graph.
 | `/graph-labels-in-graph` | Distinct label list for the filter dropdown. |
 | `/graph-default-view` | Account-scoped saved view (zoom, focal id, filters). |
 
+**Node visual encoding.** Every node type that can appear on the canvas renders
+a coloured disc with a white Lucide glyph, sized by incident-edge count, with a
+matching legend swatch. Colour, shape, and glyph are three per-label registries
+in `platform/lib/graph-style/src/index.ts`. Coverage is reconciled against the
+true node-label universe, not the colour registry itself: the standing test
+`__tests__/icons.test.ts` assembles the universe from the `Neo4j Label` column
+of every `schema-*.md` node-type table, the `sourceLabel`/`targetLabel` set in
+`typed-edge-schema.ts`, and the `CODE_EMITTED_NODE_LABELS` list, then fails the
+build if any member lacks a colour or glyph. Labels that only ever stack on a
+base node (`ADDITIONAL_BASE_LABELS`) inherit the base node's colour and are
+excluded. A node type carries a coloured glyph even when its text caption is its
+bare type: the glyph and the caption are independent channels (caption coverage
+is the separate `caption-coverage.test.ts` gate). At runtime, a per-session
+`op=icon-fallback` census (emitted from `app/graph/page.tsx` across the initial
+render and every live-update poll) names any label that reached the canvas with
+no glyph; an empty census is the healthy signal, a non-empty one means a
+code-emitted label that no static source declares and should be added to
+`CODE_EMITTED_NODE_LABELS`.
+
 ### Artefacts and files
 
 | Mount | Purpose |
@@ -4304,7 +4354,7 @@ Standing rules the operator gives over a channel are `Preference` nodes. Two mec
 
 **Observability.** `[preference-write] op=reconcile … mode=<reinforce|update|contradict|new> similarity=…` — a stream of `mode=new` for subjects that already exist is the duplicate-minting signature. `[preference-inject] op=inject channel=<wa|tg|web> injected=<N> owner=<8> source=<owner|no-owner|owner-error|fetch-error>` — injection selects only the account owner's admin preferences, so `source=owner injected=0` is a genuinely empty owner, `source=no-owner` is an account with no seeded owner (injects nothing, a missed owner seeding), and `injected=0 source=owner` on an account whose owner holds rules is the write-only regression re-appearing. `[preference-inject] op=reconcile accountId=… stored=… injected=…` — the standing reconciliation audit (claude-session-manager, 5-minute tick) flags any account whose stored active count diverges from what injection surfaces; injection now surfaces every stored active preference verbatim, so `stored == injected` is the healthy signal and any gap is a dropped-row regression (a reintroduced cap, filter, or truncation). A clean pass logs `op=reconcile drifted=0`, the no-event detector.
 
-**Consult-before-send gate.** Injection (above) puts the owner's active rules in front of every channel turn, but the growing layer-2 `Preference` set is read on demand with `profile-read`, a per-turn judgement the agent can skip, the miss that dropped a customer signature on a delivered document. `hooks/preference-consult-gate.sh` (admin plugin) is the deliverable-boundary enforcement: a PreToolUse gate on customer-facing document deliverables (`browser-pdf-save`/`SendUserFile` to `memory/users/<phone>/documents/`, and email/Outlook sends carrying attachments) that blocks (exit 2) when no `profile-read` ran after the last user message in the transcript. It fires on documents only, never on casual replies. **Observability:** `[preference-gate] op=allow tool=<name> consulted=true` on an allowed document deliverable, `op=bypass tool=<name> detail=no profile-read this turn` on a block; a stream of `op=bypass` is the un-consulted-send signature. The advisory companion `hooks/preference-consult-directive.sh` injects the two-layer architecture reminder every turn (`[pref-wrapper] op=inject`). The placement half, promoting finished deliverables out of `output/` scratch, is counted by the `data-manager` reconcile audit (`scratch-refs`, `stranded`); making that audit run on a standing periodic cadence is a filed follow-up.
+**Consult-before-send gate.** Injection (above) puts the owner's active rules in front of every channel turn, but the growing layer-2 `Preference` set is read on demand with `profile-read`, a per-turn judgement the agent can skip, the miss that dropped a customer signature on a delivered document. `hooks/preference-consult-gate.sh` (admin plugin) is the deliverable-boundary enforcement: a PreToolUse gate on customer-facing document deliverables (`browser-pdf-save`/`SendUserFile` to `memory/users/<phone>/documents/`, and email/Outlook sends carrying attachments) that blocks (exit 2) when no `profile-read` ran after the last user message in the transcript. It fires on documents only, never on casual replies. **Observability:** `[preference-gate] op=allow tool=<name> consulted=true` on an allowed document deliverable, `op=bypass tool=<name> detail=no profile-read this turn` on a block; a stream of `op=bypass` is the un-consulted-send signature. The advisory companion `hooks/preference-consult-directive.sh` injects the two-layer architecture reminder every turn (`[pref-wrapper] op=inject`). The placement half, promoting finished deliverables out of `output/` scratch, is counted by the `data-manager` reconcile audit (`scratch-refs`, `stranded`); making that audit run on a standing periodic cadence is a filed follow-up. The inbound mirror is the `uploads/` intake inbox: an uploaded file lands at `uploads/<attachmentId>/` and is promoted to its canonical entity bucket when its graph node is created, so a persisted node reference resolving into `uploads/` is intake drift, counted by the same reconcile audit as `stranded-intake`. Unlike `output/`, `uploads/` is never rebuilt by a tool, so the `data-manager` may promote a file out of it. Beyond placement and intake, the same audit counts intra-folder sprawl inside each operator-data entity folder from disk structure alone: superseded version copies (`<base>.ext` and `<base>-vN.ext` are one deliverable, all but the newest counted `versioned`), format twins (a source `.html`/`.md` render kept beside its delivered `.pdf` of the same basename, counted `format-twins`), and subfolders nested under `projects/<name>/` or `contacts/<name>/` that the flat rule forbids (counted `stray-subdir`). These are read-only counts; removal or flattening happens only on a `data-manager` stewardship dispatch, each paired with a `database-operator` reference update. The reconcile output contract is `unreachable=N broken-refs=M scratch-refs=P stranded=Q stranded-intake=R versioned=S format-twins=T stray-subdir=U`.
 
 ---
 

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

@@ -0,0 +1,37 @@
+---
+name: summarise
+description: Use when the user types /summarise, or asks for a summary, recap, or "in short" version of what the agent just said or asked. Restates the agent's own immediately preceding turn under the plainly rules: precise, concise, plain English, every claim already evidenced in that turn. When that turn concluded an investigation, the summary carries exactly two things: the diagnosis and the proposed resolution.
+---
+
+# summarise
+
+Invoked by the admin agent directly.
+
+The subject is the agent's own last turn, not the codebase, not the conversation as a whole, and not the user's message. Whatever was just said or asked gets restated so a reader who skipped the turn ends up with the same working understanding, in a fraction of the words.
+
+## What success looks like
+
+The summary is precise, concise, plain English, with every claim already evidenced in the turn being summarised. It also satisfies the shipped `plainly` skill (`skills/plainly/SKILL.md`): spoken register, no acronyms, no formulas, no AI tells, no em-dashes. Read `plainly` before writing; do not summarise from memory of what it says.
+
+Three sentences is the ceiling for an ordinary turn. If the turn ended in a question, the summary states the question and what turns on the answer, and nothing else.
+
+## Investigations
+
+When the preceding turn concluded an investigation, the summary has exactly two parts, in this order:
+
+1. **Diagnosis.** What is actually wrong, and the evidence that establishes it. Name the cause, not the layer where the symptom surfaced.
+2. **Proposed resolution.** What would fix that cause, and its scope boundary.
+
+Both parts are mandatory. A diagnosis with no proposed resolution is an unfinished summary; a proposed resolution with no diagnosis is speculation wearing a summary's clothes. Neither part introduces a finding, a fix, or a caveat that was absent from the turn being summarised. If the investigation reached a diagnosis but no resolution, say that in the resolution slot rather than inventing one.
+
+## Constraints
+
+- **No new content.** The summary is a compression, never an extension. Anything not in the turn being summarised does not belong here.
+- **Drop the scaffolding, keep the load.** File paths, tool names, and step-by-step narration go unless the reader needs them to act. The outcome stays.
+- **No hedging.** The original turn either established a claim or it did not. Do not soften a confirmed finding into "appears to", and do not harden a speculation into a fact.
+- **No follow-up offers.** End on the summary.
+
+## When NOT to use
+
+- The user wants the summary of a document, a file, or someone else's text: that is ordinary reading work, and the `plainly` skill fits better.
+- The last turn was already one or two plain sentences: there is nothing to compress, so say so and stop.

package/payload/platform/plugins/admin/skills/whats-new/SKILL.md

@@ -9,6 +9,13 @@ Invoked by the admin agent directly.
 
 This is the platform's release timeline, newest first. Each entry shows the date it shipped and the version it shipped in, so you can tell the operator how current their install is. To compare, read the installed version from `capabilities-here` and match it against the versions below. Keep answers high level and in plain English; this is a summary, not a full commit log.
 
+## 2026-07-25 (0.1.502)
+
+- Uploading a file from the phone or desktop app now shows as a proper thumbnail in chat, not a raw file path.
+- Switching accounts now shows a loading screen and lands you on the dashboard instead of a blank page.
+- Uploaded files are automatically filed into the right folder instead of sitting in a temporary holding area.
+- Searching your files is more reliable and no longer times out on larger accounts.
+
 ## 2026-07-21 (0.1.482)
 
 - WhatsApp now runs a separate connection for each client account, so one client's messages never mix with another's.

package/payload/platform/plugins/docs/references/admin-ui.md

@@ -118,6 +118,37 @@ routines exist for the account is the account-scope-miss signature; the logged
 `cron=` on `outcome=ok` confirms the persisted expression without opening the
 graph.
 
+### Skills
+
+The Skills surface (`/skills`) is the admin view of the account's operator-
+authored skills — the `SKILL.md` files the store-skill tool writes under
+`<accountDir>/plugins/<plugin>/skills/<skill>/` (the durable per-account plugin
+root, never the immutable `PLATFORM_ROOT/plugins` tree). It renders one card per
+skill (name, owning plugin, frontmatter description, reference count); a card
+opens a **read-only** detail modal showing the frontmatter, the SKILL.md body,
+and the reference filenames. The page is read-only by design — skills are
+authored and edited through the chat interface — with one exception: a **delete**
+behind an explicit confirm step in the modal. A confirmed delete removes the
+skill directory, and the whole plugin directory when that was its last skill.
+
+The route (`server/routes/admin/skills.ts`) walks only the account tree, so
+shipped platform skills never appear. Plugin and skill path params are kebab-case
+validated (`/^[a-z0-9][a-z0-9-]*$/`) — the traversal guard; anything else 400s.
+
+| Route | Behaviour |
+|-------|-----------|
+| `GET /api/admin/skills` | Enumerates `plugins/*/skills/*/SKILL.md`, returns `{plugin, skill, description, refCount}` per skill, sorted plugin then skill. A per-entry read error logs `op=list-skip` rather than silently shortening the list. |
+| `GET /api/admin/skills/:plugin/:skill` | One skill's parsed frontmatter (`name`, `description`, `publicEmbed`), the SKILL.md body, and the reference filenames. Unknown skill 404s. |
+| `DELETE /api/admin/skills/:plugin/:skill` | Removes the skill dir; removes the plugin dir when its `skills/` empties. Returns `{ok, skillDirGone, pluginDirRemoved}` measured after the rm. |
+
+Observability rides `[admin:skills]`: `op=list accountId=<8> plugins=<n>
+skills=<n>` (the surface's own heartbeat — `skills=0` against a populated
+`plugins/*/skills/` is the broken-walk signature), `op=get plugin=<…> skill=<…>
+found=<bool>`, and `op=delete plugin=<…> skill=<…> outcome=ok
+skillDirGone=<bool> pluginDirRemoved=<bool>` (`skillDirGone=false` with
+`outcome=ok` is a named failure) / `outcome=rejected reason=<invalid-name|
+not-found|rm-error>`.
+
 ### Graph
 
 | Mount | Purpose |
@@ -129,6 +160,25 @@ graph.
 | `/graph-labels-in-graph` | Distinct label list for the filter dropdown. |
 | `/graph-default-view` | Account-scoped saved view (zoom, focal id, filters). |
 
+**Node visual encoding.** Every node type that can appear on the canvas renders
+a coloured disc with a white Lucide glyph, sized by incident-edge count, with a
+matching legend swatch. Colour, shape, and glyph are three per-label registries
+in `platform/lib/graph-style/src/index.ts`. Coverage is reconciled against the
+true node-label universe, not the colour registry itself: the standing test
+`__tests__/icons.test.ts` assembles the universe from the `Neo4j Label` column
+of every `schema-*.md` node-type table, the `sourceLabel`/`targetLabel` set in
+`typed-edge-schema.ts`, and the `CODE_EMITTED_NODE_LABELS` list, then fails the
+build if any member lacks a colour or glyph. Labels that only ever stack on a
+base node (`ADDITIONAL_BASE_LABELS`) inherit the base node's colour and are
+excluded. A node type carries a coloured glyph even when its text caption is its
+bare type: the glyph and the caption are independent channels (caption coverage
+is the separate `caption-coverage.test.ts` gate). At runtime, a per-session
+`op=icon-fallback` census (emitted from `app/graph/page.tsx` across the initial
+render and every live-update poll) names any label that reached the canvas with
+no glyph; an empty census is the healthy signal, a non-empty one means a
+code-emitted label that no static source declares and should be added to
+`CODE_EMITTED_NODE_LABELS`.
+
 ### Artefacts and files
 
 | Mount | Purpose |

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

@@ -408,7 +408,7 @@ Standing rules the operator gives over a channel are `Preference` nodes. Two mec
 
 **Observability.** `[preference-write] op=reconcile … mode=<reinforce|update|contradict|new> similarity=…` — a stream of `mode=new` for subjects that already exist is the duplicate-minting signature. `[preference-inject] op=inject channel=<wa|tg|web> injected=<N> owner=<8> source=<owner|no-owner|owner-error|fetch-error>` — injection selects only the account owner's admin preferences, so `source=owner injected=0` is a genuinely empty owner, `source=no-owner` is an account with no seeded owner (injects nothing, a missed owner seeding), and `injected=0 source=owner` on an account whose owner holds rules is the write-only regression re-appearing. `[preference-inject] op=reconcile accountId=… stored=… injected=…` — the standing reconciliation audit (claude-session-manager, 5-minute tick) flags any account whose stored active count diverges from what injection surfaces; injection now surfaces every stored active preference verbatim, so `stored == injected` is the healthy signal and any gap is a dropped-row regression (a reintroduced cap, filter, or truncation). A clean pass logs `op=reconcile drifted=0`, the no-event detector.
 
-**Consult-before-send gate.** Injection (above) puts the owner's active rules in front of every channel turn, but the growing layer-2 `Preference` set is read on demand with `profile-read`, a per-turn judgement the agent can skip, the miss that dropped a customer signature on a delivered document. `hooks/preference-consult-gate.sh` (admin plugin) is the deliverable-boundary enforcement: a PreToolUse gate on customer-facing document deliverables (`browser-pdf-save`/`SendUserFile` to `memory/users/<phone>/documents/`, and email/Outlook sends carrying attachments) that blocks (exit 2) when no `profile-read` ran after the last user message in the transcript. It fires on documents only, never on casual replies. **Observability:** `[preference-gate] op=allow tool=<name> consulted=true` on an allowed document deliverable, `op=bypass tool=<name> detail=no profile-read this turn` on a block; a stream of `op=bypass` is the un-consulted-send signature. The advisory companion `hooks/preference-consult-directive.sh` injects the two-layer architecture reminder every turn (`[pref-wrapper] op=inject`). The placement half, promoting finished deliverables out of `output/` scratch, is counted by the `data-manager` reconcile audit (`scratch-refs`, `stranded`); making that audit run on a standing periodic cadence is a filed follow-up.
+**Consult-before-send gate.** Injection (above) puts the owner's active rules in front of every channel turn, but the growing layer-2 `Preference` set is read on demand with `profile-read`, a per-turn judgement the agent can skip, the miss that dropped a customer signature on a delivered document. `hooks/preference-consult-gate.sh` (admin plugin) is the deliverable-boundary enforcement: a PreToolUse gate on customer-facing document deliverables (`browser-pdf-save`/`SendUserFile` to `memory/users/<phone>/documents/`, and email/Outlook sends carrying attachments) that blocks (exit 2) when no `profile-read` ran after the last user message in the transcript. It fires on documents only, never on casual replies. **Observability:** `[preference-gate] op=allow tool=<name> consulted=true` on an allowed document deliverable, `op=bypass tool=<name> detail=no profile-read this turn` on a block; a stream of `op=bypass` is the un-consulted-send signature. The advisory companion `hooks/preference-consult-directive.sh` injects the two-layer architecture reminder every turn (`[pref-wrapper] op=inject`). The placement half, promoting finished deliverables out of `output/` scratch, is counted by the `data-manager` reconcile audit (`scratch-refs`, `stranded`); making that audit run on a standing periodic cadence is a filed follow-up. The inbound mirror is the `uploads/` intake inbox: an uploaded file lands at `uploads/<attachmentId>/` and is promoted to its canonical entity bucket when its graph node is created, so a persisted node reference resolving into `uploads/` is intake drift, counted by the same reconcile audit as `stranded-intake`. Unlike `output/`, `uploads/` is never rebuilt by a tool, so the `data-manager` may promote a file out of it. Beyond placement and intake, the same audit counts intra-folder sprawl inside each operator-data entity folder from disk structure alone: superseded version copies (`<base>.ext` and `<base>-vN.ext` are one deliverable, all but the newest counted `versioned`), format twins (a source `.html`/`.md` render kept beside its delivered `.pdf` of the same basename, counted `format-twins`), and subfolders nested under `projects/<name>/` or `contacts/<name>/` that the flat rule forbids (counted `stray-subdir`). These are read-only counts; removal or flattening happens only on a `data-manager` stewardship dispatch, each paired with a `database-operator` reference update. The reconcile output contract is `unreachable=N broken-refs=M scratch-refs=P stranded=Q stranded-intake=R versioned=S format-twins=T stray-subdir=U`.
 
 ---
 

package/payload/platform/plugins/docs/references/summarise-skill.md

@@ -0,0 +1,7 @@
+# summarise skill
+
+A workflow skill bundled in the admin plugin on every {{productName}} install.
+
+**`summarise`** restates the agent's own immediately-preceding turn under the plainly rules: precise, concise, plain English, every claim already evidenced in the turn. Three-sentence ceiling for an ordinary turn. When that turn concluded an investigation, the summary carries exactly two parts in order: the diagnosis (the cause, with its evidence) and the proposed resolution (or an explicit note that none was reached). Triggers: "/summarise", "summarise", "recap", "in short".
+
+It never adds content, never hedges, and never ends on a follow-up offer. For summarising someone else's document or text, `plainly` fits better; a turn already one or two plain sentences needs no compression.

package/payload/platform/templates/account-schema/SCHEMA.md

@@ -26,6 +26,32 @@ the client data portal, and case-sensitive matching. The write guard blocks a ba
 name as you create it, and the standing reconcile counts any that predate the
 rule. Renaming an existing bad name goes through the `data-manager` specialist.
 
+## Intra-folder hygiene
+
+The `projects/<name>/` and `contacts/<name>/` entity folders hold one current
+copy of each deliverable, in one canonical format, with no subtree. Three rules
+keep them that way; the standing reconcile counts any that predate them, and
+`data-manager` clears them on a stewardship dispatch. (`documents/` is exempt: it
+may hold one document-folder deep per the buckets above, so these rules do not
+apply there.)
+
+- **Current version only.** `<base>.ext` and `<base>-vN.ext` (for example
+  `charlotte-deck.pdf` and `charlotte-deck-v2.pdf` through
+  `charlotte-deck-v6.pdf`) are versions of one deliverable, not separate files.
+  Keep the highest-numbered version (the unsuffixed base is the original, so any
+  `-vN` supersedes it); the superseded copies are removed through `data-manager`.
+- **One canonical format.** A delivered `.pdf` and its source render sharing the
+  same basename (`charlotte-deck.html` beside `charlotte-deck.pdf`,
+  `invoice-rbt-2026-005.html` beside `invoice-rbt-2026-005.pdf`) are one
+  deliverable in two formats. The pdf is the deliverable; the `.html` or `.md`
+  render that produced it is not a second one and is removed through
+  `data-manager`.
+- **No subfolder.** No folder nests under `projects/<name>/` or
+  `contacts/<name>/`; files live directly inside the entity folder. This is the
+  flat rule from the buckets above, restated as a standing invariant: the write
+  guard blocks the depth as you create it, and the reconcile counts any subtree
+  that predates the guard or was created off-path.
+
 ## Tool-owned (off-limits — never reorganise)
 
 Finished deliverables must be promoted out of `output/` into `documents/` or
@@ -33,8 +59,17 @@ Finished deliverables must be promoted out of `output/` into `documents/` or
 last resort, and a graph reference must never point into it (the next tool write
 rebuilds the tree and the reference dangles).
 
+`uploads/` is a temporary intake inbox, not rebuilt scratch. A file lands at
+`uploads/<attachmentId>/` on upload and is promoted to its canonical entity
+bucket when its graph node is created: a Person or Organization file to
+`contacts/<name>/`, a Project file to `projects/<name>/`, anything else to
+`documents/`. A persisted graph reference must never point into `uploads/`.
+Unlike `output/`, each upload writes its own `uploads/<attachmentId>/` dir and no
+tool walks or rebuilds the subtree, so promoting a file out of it through the
+`data-manager` specialist is safe.
+
 The internal structure of these is owned by the writing tool and is recreated on
-the next write: `url-get/`, `output/`, `generated/`, `extracted/`, `uploads/`,
+the next write: `url-get/`, `output/`, `generated/`, `extracted/`,
 any published/served tree (`sites/`, `public/`), `agents/`, `specialists/`, and
 platform-internal areas (`cache/`, `secrets/`, `state/`, `logs/`, `tmp/`).
 `.quarantine/` is a historical store. An earlier version of the schema reconcile

package/payload/platform/templates/specialists/agents/data-manager.md

@@ -14,6 +14,8 @@ You are the steward of this account's data directory. Admin dispatches you throu
 - The account data directory is organised consistently with the graph ontology. Before the first move of a session, Read `platform/plugins/memory/references/schema-base.md`; when `brand.json#vertical` is set, also Read `platform/plugins/memory/references/schema-<vertical>.md`. Directory structure and file placement should make sense to someone navigating by the graph: files that belong to a Project, Person, or document node live where the node's references say they live.
 - Every operator file is reachable from a graph node, and every graph file-reference resolves to a real path. `memory-search` is how you resolve which nodes reference a file — search for the filename and the path before deciding anything about it.
 - A file is never moved without the referencing nodes being updated in the same pass. Moves and reference updates are paired operations: for each move, dispatch `database-operator` via the Task tool with a brief naming the node (elementId from your `memory-search`), the property holding the old path, and the new path. You have no graph-write tools by design — every graph mutation flows through database-operator.
+- A file in the `uploads/` intake inbox whose graph node exists is promoted to its canonical bucket (Person or Organization to `contacts/<name>/`, Project to `projects/<name>/`, else `documents/`), paired with a `database-operator` `sourcePath` update in the same pass, exactly as any other move. `uploads/` is a temporary landing area, not a tool-owned tree, so moving a file out of it is not a reorganisation of a system-convention directory.
+- Superseded versions and redundant format twins are removed, and a subfolder nested under `projects/<name>/` or `contacts/<name>/` is flattened or re-filed, when a stewardship brief asks for it. Each removal or move pairs with a `database-operator` reference update in the same pass, exactly as any other move: the surviving current render keeps the node reference, and a removed file's node is repointed or its reference dropped. Removal is destructive, so it happens only on an explicit stewardship dispatch, never in the read-only reconcile audit.
 
 ## Off-limits: system-convention directories
 
@@ -21,13 +23,13 @@ Directories whose layout is owned by tools are not yours to reorganise — a too
 
 ## The reconcile audit brief
 
-When admin's brief names a reconcile audit, the pass is read-only: walk the operator-file areas of the account directory, resolve each file against the graph via `memory-search`, and count (a) files unreachable from any graph node, (b) graph file-references that do not resolve to a real path, (c) graph file-references that resolve into a tool-owned scratch dir (`output/`, `generated/`, `extracted/`, `url-get/`), which the next tool write rebuilds so the reference is fragile by construction, and (d) deliverables a node references that resolve only under a scratch dir and were never promoted to `documents/` or `projects/`. Move nothing, dispatch nothing. The audit exists so a rising count is visible before anyone asks for a cleanup.
+When admin's brief names a reconcile audit, the pass is read-only: walk the operator-file areas of the account directory, resolve each file against the graph via `memory-search`, and count (a) files unreachable from any graph node, (b) graph file-references that do not resolve to a real path, (c) graph file-references that resolve into a tool-owned scratch dir (`output/`, `generated/`, `extracted/`, `url-get/`), which the next tool write rebuilds so the reference is fragile by construction, (d) deliverables a node references that resolve only under a scratch dir and were never promoted to `documents/` or `projects/`, and (e) graph file-references that resolve into the `uploads/` intake inbox, which is a temporary landing area a file should have been promoted out of when its node was created. The walk now includes `uploads/`; a file under `uploads/` that no node references counts under (a) unreachable. Then, per operator-data entity folder (`projects/<name>/`, `contacts/<name>/`), count three intra-folder drifts from disk structure alone, no graph resolution needed: (f) files in a version group, where `<base>.ext` and `<base>-vN.ext` share a basename stem and extension and all but the newest are superseded, counting every superseded copy as `versioned`; (g) format twins, a source-render file (`.html`, `.md`) whose delivered `.pdf` twin of the same basename sits in the same folder, counting each such render as `format-twins`; (h) stray subfolders nested under an entity folder, which the flat rule forbids, counting each subfolder as `stray-subdir`. Move nothing, dispatch nothing. The audit exists so a rising count is visible before anyone asks for a cleanup.
 
 When the vertical's `schema-<vertical>.md` declares a **published / served tree** with a Filesystem ↔ graph section (e.g. the per-listing site target with a URL ↔ path rule and an artefact → graph-reference table), the audit also walks that tree. The graph references it by hosted URL, not local path, so resolution runs through the section's URL ↔ path rule: for each served file, derive its hosted URL and check that some node references it; for each node URL **that matches the section's hosted-URL prefix**, derive its local path and check the file exists. Count served files matching no node reference in `unreachable` and prefix-matching node URLs resolving to no served file in `broken-refs`. Node URLs the rule cannot resolve — externally-hosted URLs (a CDN image, a third-party portal link) carry no served-tree prefix — are outside this audit and are never counted as broken. Honour the section's "served but intentionally unreferenced (tool / collateral)" list — those classes carry no reference by design and are never orphans, the same exclusion you already apply to the `url-get/` cache. This walk is still read-only: the served tree is a publish write target (off-limits to moves, above); the audit only counts drift, it never reorganises.
 
 ## Output contract
 
-End every dispatch with a one-line machine-greppable summary as the last line of your reply. For stewardship work: `moves=N ref-updates=M skipped=<reason|none>`. For the reconcile audit: `unreachable=N broken-refs=M scratch-refs=P stranded=Q`. If a brief is ambiguous about whether a directory is operator data or a system convention, name the ambiguity in your reply instead of guessing.
+End every dispatch with a one-line machine-greppable summary as the last line of your reply. For stewardship work: `moves=N ref-updates=M skipped=<reason|none>`. For the reconcile audit: `unreachable=N broken-refs=M scratch-refs=P stranded=Q stranded-intake=R versioned=S format-twins=T stray-subdir=U`. If a brief is ambiguous about whether a directory is operator data or a system convention, name the ambiguity in your reply instead of guessing.
 
 ## Review gates
 

package/payload/server/public/activity.html

@@ -5,12 +5,12 @@
   <meta name="viewport" content="width=device-width, initial-scale=1.0">
   <title>Activity — Maxy</title>
   <link rel="icon" href="/favicon.ico">
-  <script type="module" crossorigin src="/assets/activity-CKUYOLd2.js"></script>
-  <link rel="modulepreload" crossorigin href="/assets/chunk-fQC6bEKA.js">
-  <link rel="modulepreload" crossorigin href="/assets/useSubAccountSwitcher-Bc7XHr0L.js">
-  <link rel="modulepreload" crossorigin href="/assets/AdminShell-BFVVkWFC.js">
-  <link rel="modulepreload" crossorigin href="/assets/triangle-alert-DumCWC08.js">
-  <link rel="stylesheet" crossorigin href="/assets/useSubAccountSwitcher-DPHQJO7E.css">
+  <script type="module" crossorigin src="/assets/activity-DZFYDHNA.js"></script>
+  <link rel="modulepreload" crossorigin href="/assets/chunk-CCr-iYLO.js">
+  <link rel="modulepreload" crossorigin href="/assets/useSubAccountSwitcher-iQGqNJhI.js">
+  <link rel="modulepreload" crossorigin href="/assets/AdminShell-Gq8DU_ig.js">
+  <link rel="modulepreload" crossorigin href="/assets/triangle-alert-k8ulav-N.js">
+  <link rel="stylesheet" crossorigin href="/assets/useSubAccountSwitcher-fvBunpOC.css">
   <link rel="stylesheet" href="/brand-defaults.css">
 </head>
 <body>