@synap-core/workspace-templates 0.3.0 → 0.5.0

package/src/templates.ts

@@ -2603,7 +2603,7 @@ const DATA = {
     },
     "layout": {
       "pinnedApps": [
-        "intelligence",
+        "chat",
         "dashboard",
         "data"
       ],
@@ -2642,7 +2642,7 @@ const DATA = {
         },
         {
           "kind": "app",
-          "appId": "intelligence",
+          "appId": "chat",
           "label": "Intelligence"
         }
       ]
@@ -2669,6 +2669,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the agent fleet the user runs — the agents themselves, the model providers behind them, the skills they carry, and the projects they work — so the workspace reflects their real AI operation.",
       "framing": "Act as a pragmatic AI ops lead. Tease out which agents are live, what models and providers power them, what each agent can do, and what work they're pointed at. Translate that into agents, providers, skills, and projects.",
+      "expertise": {
+        "starters": [
+          "For every live agent, pin down the trio that actually matters: model, provider, and daily budget ceiling. \"I have an agent\" is not an entity — \"a Coder agent on Claude via OpenRouter, capped at $5/day\" is. Lead by capturing that trio for the one agent running most, then fan out. An agent with no budget number is an uncapped spend waiting to happen.\n",
+          "Capture each provider as its own entity with cost-per-token AND key health, not just a name. Propose logging the provider behind your busiest agent first, with its input/output token cost and when the key expires — because the two ways a fleet dies are a blown budget and an expired key, and both live on the provider, not the agent.\n",
+          "Scope each agent to ONE role and catalogue the specific skills it carries, with a trust level on each. Lead with \"what is this agent FOR, and what exactly can it do?\" A named, scoped agent with three trusted skills beats one vague \"assistant\" agent that can supposedly do everything.\n"
+        ],
+        "blindSpots": [
+          "Untracked spend is the fleet-killer. Agents burn tokens silently — a runaway loop, a retry storm, a context window nobody trimmed — and the first signal is the invoice. Surface daily budget ceilings and weekly actual spend per provider proactively; the CFO view (which work is burning budget) is the one nobody builds until it's too late.\n",
+          "The \"one agent for everything\" anti-pattern feels efficient and is the opposite. A single generalist agent with every skill and every key is un-auditable, un-scopeable, and a fat blast radius when a skill goes rogue. Push toward scoped agents — Coder, Researcher, Ops — each with only the skills and provider budget its job needs.\n",
+          "Single-provider risk hides until the provider has an outage or rate-limits you mid-run. Teams wire every agent to one provider and have no fallback, so one 429 halts the whole fleet. Capture provider fallback intent (primary + backup) so a single vendor's bad day isn't your whole operation's bad day.\n"
+        ],
+        "bar": "A great result is a fleet you can run like an operation, not a pile of daemons: every live agent has a model, a provider, a budget, and a scoped set of trusted skills; every provider shows its cost, key health, and spend-against-budget; and you can answer \"which agent is burning the most, on whose key, and what happens if that provider goes down?\" in one glance.\n"
+      },
       "collect": [
         {
           "profileSlug": "agent",
@@ -3652,6 +3665,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the brand's expressive DNA — voice, visual identity, and the rules that keep everything on-brand — so any human or AI can generate on-brand content and assets.",
       "framing": "THE BRAND STRATEGIST: Act as a seasoned brand strategist. Draw out how the brand sounds (tone, personality, do's and don'ts), how it looks (identity, colors, type), and the non-negotiable rules. Translate fuzzy vibes into concrete voice guides and rules. Reference the Foundation (mission, audience, positioning) so the brand expresses the strategy, never contradicts it.\n",
+      "expertise": {
+        "starters": [
+          "Adjectives don't define a voice — \"friendly, bold, human\" describes every brand and constrains none. Propose voice as a small set of DO / DON'T pairs instead (\"say 'you', not 'users'\"; \"short declaratives, never hedged qualifiers\"). Pairs are testable; adjectives are decoration.\n",
+          "A voice guide is only real if it survives a sentence test. Take one actual line from their site or a competitor's and rewrite it in the proposed voice on the spot — if the rewrite looks identical to the original, the voice isn't differentiated yet. Push until the two versions are visibly different.\n",
+          "Build the palette around ROLES, not just favorite colors. Pin the semantic roles first — primary, surface, text, and one restrained accent — and make the accent earn its keep. Most brands leak trust by using three \"brand colors\" as accents; propose one hero accent and demote the rest to support.\n"
+        ],
+        "blindSpots": [
+          "\"Brand = logo\" is the classic trap. The logo is the least-used, most-argued asset; the voice, the color roles, and the do/don't rules drive 90% of what anyone actually ships. If they lead with the logo, redirect to how the brand SOUNDS and behaves in a paragraph of copy.\n",
+          "Rules with no severity are ignored. A pile of equally-weighted \"guidelines\" gives an AI or a teammate nothing to obey — mark each as mandatory, important, or guideline so the non-negotiables (clearspace, accessibility contrast, forbidden words) actually hold under pressure.\n",
+          "Color contrast is a silent brand-killer: a beautiful palette that fails WCAG AA on text is off-brand the moment it's inaccessible. If they've picked colors without checking text-on-surface contrast, flag it before it's codified into tokens.\n"
+        ],
+        "bar": "A stranger handed the voice pairs, the color roles, and the rules could write a new paragraph and pick a button color that both read unmistakably as THIS brand — and every rule is testable on a real sentence or a real screen, not a vibe.\n"
+      },
       "collect": [
         {
           "profileSlug": "brand-identity",
@@ -3701,7 +3727,7 @@ const DATA = {
     "layout": {
       "pinnedApps": [
         "data",
-        "whiteboard",
+        "files",
         "brandLibrary"
       ],
       "defaultView": "Brand Command Center",
@@ -6011,6 +6037,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the real engineering surface — the apps that are shipped, where their code lives, what runs behind them, where they deploy, and what's in flight — so the workspace mirrors what the team actually builds and runs, not a generic template.",
       "framing": "THE STAFF ENGINEER: Act as a pragmatic, precise staff/platform engineer standing up a developer command center. Tease out what's actually shipped vs. planned, where the code lives (repos + local paths), what runs behind each app, where it deploys, and what's on the bench right now. Prefer concrete over aspirational — a repo URL beats a wish. Tie the roadmap back to the Foundation's mission and audiences: the surface exists to serve them.\n",
+      "expertise": {
+        "starters": [
+          "Don't ask \"what do you want to build?\" — ask what's already running. Propose starting from the ONE app that's live today, its primary deploy target, and the single feature in flight right now. One real node with a repo URL beats ten aspirational ones. The map grows from what exists, not from the org chart you wish you had.\n",
+          "For each app, capture the deploy path end to end: repo → branch that auto-deploys → target (Vercel/Coolify/bare VPS) → the URL it lands on. A node that says \"app\" but can't answer \"how does a commit reach production?\" is a label, not a map.\n",
+          "Lead with the in-flight work as first-class entities, not a backlog dump. Take the feature being coded this week, give it a status and an acceptance criterion, and link it to its app. That single live thread is what makes the workspace a command center instead of a wiki.\n"
+        ],
+        "blindSpots": [
+          "The map is worthless the moment it drifts from reality. Founders capture the IDEAL architecture (the clean diagram) instead of the system AS IT IS — the hacky cron, the service everyone forgot owns auth, the package no one dares upgrade. Capture the mess; the mess is where the incidents come from.\n",
+          "\"We'll document it later\" is how tribal knowledge dies. The one engineer who knows why service X can't be restarted during a deploy leaves, and it becomes a 2am incident. Capture the non-obvious operational facts (decision records, gotchas) NOW, while someone still remembers the why — not after the outage.\n",
+          "Packages and their dependency edges are the silent killer. Founders track apps but not the shared substrate underneath — so a \"small\" bump to a core package breaks three apps nobody connected to it. Capture what depends on what; the blast radius lives in the edges, not the nodes.\n"
+        ],
+        "bar": "A great result is a graph you can navigate in any direction to answer a real operational question — \"if I bump this package, what breaks?\", \"how does a commit reach prod for app X?\", \"what's actually in flight and who's on it?\" — and every answer matches what's true in the terminal right now, not what was true at kickoff.\n"
+      },
       "collect": [
         {
           "profileSlug": "devplane_app",
@@ -8496,6 +8535,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the user's brand voice, audience, content pillars, and publishing rhythm across channels — so the workspace reflects how they actually create and distribute content, not a generic calendar.",
       "framing": "Act as a seasoned content strategist. Tease out their voice and positioning, who they're talking to, the recurring themes they own, the channels they publish on, and how often. Translate that into pillars, platforms, and a seeded content calendar.",
+      "expertise": {
+        "starters": [
+          "Most creators over-index on one format and burn out. Propose 3–4 pillars that mix TEACH (how it works), PROVE (customer/results), and PROVOKE (point of view) — then adapt the mix to their niche. Don't ask for pillars from a blank slate; offer a starting set and let them react.\n",
+          "Better to own ONE channel consistently than be thin on four. If they list many platforms, propose a primary channel + a cadence they can actually sustain, and treat the rest as repurposing targets, not separate efforts.\n",
+          "Every pillar should ladder to a business goal — awareness, trust, or conversion. If a pillar is just \"stuff we post\", propose the job it should do and tie it to a specific audience segment.\n"
+        ],
+        "blindSpots": [
+          "Distribution is the silent killer — great content nobody sees. If they haven't said HOW each piece gets discovered (SEO, a platform's algorithm, an email list, founder-led amplification), raise it before moving on.\n",
+          "No repurposing plan = 5× the work for 1× the reach. If they treat each post as one-and-done, propose a chain: one deep piece → clips → posts → newsletter.\n",
+          "Pillars with no audience attached reach no one. Tie each pillar to a specific segment — \"content for everyone\" is content for nobody.\n"
+        ],
+        "bar": "The pillars + primary platform + cadence read like a system a small team could actually run for 3 months without burning out — where every pillar has a clear audience, a clear job, and a way to get discovered.\n"
+      },
       "collect": [
         {
           "profileSlug": "pillar",
@@ -9020,6 +9072,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture how you actually produce video and motion content — your real pipelines, your reusable templates, and the assets you cut from — so the studio mirrors your production line, not a generic setup.",
       "framing": "THE PRODUCER: Act as a seasoned motion/video production lead who has shipped thousands of frames. This is a HyperFrames/Remotion render pipeline, NOT a publishing calendar — anchor on how work gets MADE: formats, aspect ratios, durations, and the templates that make output repeatable. Push for the shows and series they actually run, not one-off ideas. Pull voice and visual identity from Brand and target audience from Foundation so every piece lands on-brand. Be concrete about specs; a fuzzy \"we make videos\" helps no one.\n",
+      "expertise": {
+        "starters": [
+          "Produce in BATCHES, not one-at-a-time. Setup — lighting, wardrobe, template loading, brand assets — is the real cost; shooting or composing five pieces in one session amortizes it. Propose a batch cadence (e.g. one shoot day → a month of cuts) rather than a per-video pipeline.\n",
+          "The hook is 80% of the view. On a 9:16 feed the first 1–2 seconds decide whether the piece is watched at all, so it's worth more iteration than the rest combined. Propose a template whose title card / cold-open IS the hook, and treat the hook as its own reusable asset.\n",
+          "Design every shoot for REPURPOSING before you roll. One long-form capture should yield the long cut, several vertical clips, and stills — but only if it's framed and shot with those crops in mind. Propose the repurpose chain up front so the raw footage is cut-once, use-many.\n"
+        ],
+        "blindSpots": [
+          "The velocity-vs-quality tradeoff is a real dial, not a failing — a weekly show that's \"good enough and on time\" beats a cinematic piece that ships quarterly. If they're chasing polish on a high-cadence line, name the tradeoff and propose a quality bar that survives the schedule.\n",
+          "No reusable templates = every video rebuilt from scratch, and brand drift creeps in. If they're producing on a cadence but have no locked intros/outros/lower-thirds, that's the gap — templates are what make output both fast AND on-brand. Surface it.\n",
+          "Aspect ratio and platform are a production decision, not an export afterthought. Shooting 16:9 and cropping to 9:16 later loses the frame and the hook. If a pipeline's platform doesn't match how it's actually shot, flag the mismatch before it's baked into every render.\n"
+        ],
+        "bar": "The studio reads like a production LINE: recurring shows with locked specs, reusable templates that carry brand into every render, and asset sources feeding a batch-then-repurpose flow — so a producer could ship the next episode this week without reinventing the format or fighting brand drift.\n"
+      },
       "collect": [
         {
           "profileSlug": "content-pipeline",
@@ -9886,11 +9951,97 @@ const DATA = {
             "valueType": "string",
             "inputType": "select",
             "enumValues": [
+              "prospect",
+              "active",
+              "paused",
+              "churned"
+            ]
+          },
+          {
+            "slug": "accountManager",
+            "label": "Account Manager",
+            "valueType": "string",
+            "inputType": "text"
+          },
+          {
+            "slug": "engagementStartDate",
+            "label": "Engagement Start",
+            "valueType": "date",
+            "inputType": "date"
+          },
+          {
+            "slug": "satisfactionScore",
+            "label": "Satisfaction",
+            "valueType": "number",
+            "inputType": "number"
+          },
+          {
+            "slug": "lifetimeValue",
+            "label": "Lifetime Value",
+            "valueType": "number",
+            "inputType": "number"
+          },
+          {
+            "slug": "notes",
+            "label": "Notes",
+            "valueType": "string",
+            "inputType": "textarea"
+          },
+          {
+            "slug": "contractValue",
+            "label": "Contract Value",
+            "valueType": "number",
+            "inputType": "number"
+          },
+          {
+            "slug": "renewalDate",
+            "label": "Renewal Date",
+            "valueType": "date",
+            "inputType": "date"
+          },
+          {
+            "slug": "healthScore",
+            "label": "Health",
+            "valueType": "string",
+            "inputType": "select",
+            "enumValues": [
+              "healthy",
+              "at_risk",
+              "critical"
+            ]
+          }
+        ]
+      },
+      {
+        "slug": "partner",
+        "displayName": "Partner",
+        "icon": "handshake",
+        "color": "teal",
+        "description": "A partner relationship — both a referral source and a co-delivery collaborator, distinguished by partner type.",
+        "properties": [
+          {
+            "slug": "partnerStatus",
+            "label": "Status",
+            "valueType": "string",
+            "inputType": "select",
+            "enumValues": [
+              "prospect",
               "active",
               "paused",
               "churned"
             ]
           },
+          {
+            "slug": "partnerType",
+            "label": "Partner Type",
+            "valueType": "string",
+            "inputType": "select",
+            "enumValues": [
+              "referral",
+              "co-delivery",
+              "both"
+            ]
+          },
           {
             "slug": "accountManager",
             "label": "Account Manager",
@@ -11223,6 +11374,31 @@ const DATA = {
         "sourceProfileSlug": "deal",
         "targetProfileSlug": "pipeline",
         "type": "belongs_to"
+      },
+      {
+        "sourceProfileSlug": "client",
+        "targetProfileSlug": "company",
+        "type": "belongs_to"
+      },
+      {
+        "sourceProfileSlug": "client",
+        "targetProfileSlug": "contact",
+        "type": "primary_contact"
+      },
+      {
+        "sourceProfileSlug": "partner",
+        "targetProfileSlug": "company",
+        "type": "works_with"
+      },
+      {
+        "sourceProfileSlug": "partner",
+        "targetProfileSlug": "contact",
+        "type": "primary_contact"
+      },
+      {
+        "sourceProfileSlug": "partner",
+        "targetProfileSlug": "client",
+        "type": "refers"
       }
     ],
     "displayTemplates": [
@@ -12032,6 +12208,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the user's sales pipeline shape, their key accounts/contacts, and how they qualify and move deals — so the CRM reflects their real revenue motion, not a generic template.",
       "framing": "Act as a sharp revenue/sales-ops lead. Tease out how they actually sell: who they sell to, what stages a deal moves through, where leads come from, and what 'qualified' means to them. Translate their words into pipeline config, companies, contacts, and deals.",
+      "expertise": {
+        "starters": [
+          "Don't ask for stages on a blank slate — infer the motion first and propose a default pipeline for it. PLG: Signup → Activated → PQL → Expansion. Sales-led: Discovery → Qualified → Demo → Proposal → Negotiation → Closed. Agency/retainer: Lead → Scoping → Proposal → Won → Delivery. Offer the one that fits and let them cut stages, rather than starting from nothing.\n",
+          "Define every stage by a BUYER action, not a seller activity — \"Demo booked\" or \"Security review passed\", not \"Following up\" or \"Sent email\". Seller-verb stages are why pipelines rot: they describe effort, not progress. If they name an activity stage, reflect it back as the buyer commitment it's meant to prove.\n",
+          "Anchor qualification to a named framework, don't leave \"qualified\" as a feeling. Propose BANT for transactional deals or MEDDIC for enterprise, then make the exit criteria out of it — e.g. a deal can't leave Qualified without a known budget, an identified economic buyer, and a compelling event.\n"
+        ],
+        "blindSpots": [
+          "The \"everything is 'in progress'\" pipeline. If most deals sit in middle stages with no close date or next step, that's not a pipeline, it's a graveyard — hygiene has collapsed. Push for a next step + a date on every open deal, and be willing to mark the dead ones lost.\n",
+          "A stage with no exit criteria is a wish, not a stage. If they can't tell you the ONE thing that must be true to advance a deal, the stage is theater. Force a crisp gate for each — what the buyer must have done to move forward.\n",
+          "Founders track deal value but not the two numbers that actually predict revenue: win rate by stage and average sales-cycle length. Without them you can't forecast or spot where deals stall. Surface both early even if the first answer is a rough guess.\n"
+        ],
+        "bar": "The pipeline stages mirror how a buyer actually commits (not how the rep works their day), each stage has a one-line exit gate, \"qualified\" maps to a real framework, and every live deal on the board has an owner, a value, a next step, and a close date — so a glance at the board tells the truth about revenue.\n"
+      },
       "collect": [
         {
           "profileSlug": "pipeline",
@@ -13711,6 +13900,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the user's infrastructure surface — the services they run, the repositories behind them, their environments, the vendors they depend on, and their credentials inventory — so the command center reflects their real stack.",
       "framing": "Act as a staff platform engineer doing an infra walkthrough. Tease out what's running in production, where the code lives, how environments are laid out, which third parties they depend on, and what secrets need tracking. Translate that into services, repositories, environments, vendors, and credentials.",
+      "expertise": {
+        "starters": [
+          "Start from what's serving live traffic RIGHT NOW, not the architecture diagram. Walk the request path: what does a user hit first, and what does that call, and what does THAT call? Capture each hop as a service with its host and health-check URL. The production edge is the map's anchor; everything else hangs off it.\n",
+          "For every third party, capture the cost AND who owns the account. Propose logging each vendor with its pricing model and monthly spend the moment you name it — the €12/mo that became €400/mo is always a vendor nobody was watching. An untracked line item is a future surprise on the card.\n",
+          "Inventory credentials by their EXPIRY, not their existence. For each secret, capture where it's stored (vault ref), what it unlocks, and when it expires or was last rotated. The credential nobody wrote down is the one that expires at 3am and takes prod with it.\n"
+        ],
+        "blindSpots": [
+          "The untracked credential is the classic infra time-bomb: the SSH key on one laptop, the API token in someone's .env, the cert that auto-renewed until it didn't. Teams track services obsessively and secrets not at all — surface expiry dates and rotation policy proactively, because the outage is silent until the exact moment it isn't.\n",
+          "Vendor cost creep has no owner. Each SaaS was signed up \"just to try,\" and now the monthly bill is a mystery no single person can explain line by line. Force a monthly-cost number and an owner on every vendor — the sum is almost always higher than anyone guessed.\n",
+          "\"Works on my machine\" is environment drift, and it hides until deploy day. Staging runs a different Node, prod has an env var dev doesn't, the migration ran here but not there. Map each environment EXPLICITLY with its branch and base URL so the deltas between prod, staging, and dev are visible instead of discovered during an incident.\n"
+        ],
+        "bar": "A great result is a command center where you can answer, without SSHing anywhere: what's serving traffic and is it healthy, which credential expires next and who rotates it, what each vendor costs and who owns it, and exactly how prod differs from staging. The value is in the facts nobody keeps in one place — expiry dates, cost owners, environment deltas — surfaced before they become incidents.\n"
+      },
       "collect": [
         {
           "profileSlug": "service",
@@ -14431,6 +14633,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the company's real money model — where cash sits, what revenue comes in, what it burns on, and its current runway — so the workspace reflects the actual financial position, not a generic ledger.",
       "framing": "THE CFO: Act as a pragmatic, numerate startup CFO. Get to the truth of the company's finances fast: how much cash is in the bank, what's coming in and from where, what it burns each month, and how many months of runway that leaves. Push for real numbers over estimates, flag anything that doesn't add up, and tie revenue back to the company's positioning and pricing (from Foundation) so the model is grounded in strategy, not spreadsheets.\n",
+      "expertise": {
+        "starters": [
+          "Don't reconstruct a full P&L on day one — default the model to the three numbers that keep a startup alive: cash in bank, monthly net burn, and runway (cash ÷ burn, in months). Propose those first and layer detail later; a founder who knows their runway to the month is ahead of one with a beautiful chart of accounts.\n",
+          "Add a small set of unit economics, not a whole finance stack: gross margin, CAC, and LTV (or at minimum LTV:CAC ratio). Propose sensible defaults — payback under ~12 months, LTV:CAC above ~3:1 — as reference points to react to, rather than asking them to define metrics from scratch.\n",
+          "Model cash on a timing basis, not an accrual one. When they give you revenue, ask when the cash actually LANDS — Net-30/60 invoices, annual prepay, Stripe payout lag — and capture that gap explicitly, because a profitable month can still run the account dry.\n"
+        ],
+        "blindSpots": [
+          "Revenue ≠ cash. Founders book an annual contract and feel rich, but the cash arrives monthly or after Net-60 — meanwhile payroll is due Friday. If they conflate the two, separate signed bookings from collected cash before computing anything.\n",
+          "Runway is THE number that predicts survival, and it's the one most often stale. If there's no current runway figure — or it hasn't been recomputed since the last big hire or price change — that's the first gap to close. Everything else is secondary to \"how many months of oxygen is left\".\n",
+          "Bookings, revenue, and cash are three different numbers and founders routinely merge them. A signed deal (booking), revenue recognized over its term, and the money in the account are rarely equal in any given month. Name which one each figure is, or the whole model lies.\n"
+        ],
+        "bar": "A stranger could open the workspace and answer three questions in ten seconds: how much cash is in the bank, how much it burns a month, and how many months of runway that leaves — with revenue captured on a cash-timing basis, bookings kept distinct from collected cash, and at least a rough gross margin and LTV:CAC in view.\n"
+      },
       "collect": [
         {
           "profileSlug": "account",
@@ -14490,7 +14705,7 @@ const DATA = {
       "pinnedApps": [
         "dashboard",
         "data",
-        "intelligence"
+        "chat"
       ],
       "sidebarItems": [
         {
@@ -14986,6 +15201,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the strategic DNA so every downstream workspace inherits a real company, not a generic template.",
       "framing": "THE COFOUNDER: Act as a sharp, skeptical co-founder. Pressure-test why-now, why-you, and why-this. Refuse fuzzy answers; push for specifics and evidence. Be respectful but direct — a vague mission helps no one.\n",
+      "expertise": {
+        "starters": [
+          "A mission is a CHANGE in the world, not a description of the product (\"make complex products understandable\", not \"we make explainer videos\"). If they describe the deliverable, reflect the underlying change back and propose THAT as the mission.\n",
+          "Positioning is sharpest as ONE sentence — \"the <X> for <who>\" or \"the only <category> that <wedge>\". If they give you a vague \"we help companies with Y\", propose a crisp category+wedge framing from what they've told you and let them sharpen it — never file the vague version.\n",
+          "Audience is a SPECIFIC buyer at a specific stage (\"Head of Product Marketing at Series A–B technical SaaS\"), not a market (\"SaaS companies\"). Push from the market to the person who actually signs off.\n"
+        ],
+        "blindSpots": [
+          "Founders skip the NON-goal — what they deliberately DON'T do. A company with no \"no\" has no focus. If they haven't named boundaries, ask what they turn down.\n",
+          "A differentiator that's just \"we're better / faster / care more\" isn't defensible. Push for a structural moat a competitor can't easily copy — and if it's founder-dependent (bus-factor), capture that honestly rather than dressing it up.\n",
+          "The #1 tells of fuzzy strategy: a mission that's really a deliverable, and positioning that's really a feature list. When you see either, name it and dig.\n"
+        ],
+        "bar": "A stranger could read the mission, audience, and positioning and instantly explain WHO this is for, WHAT changes for them, and WHY this company over the alternatives — in one breath, with no fluff.\n"
+      },
       "collect": [
         {
           "profileSlug": "mission",
@@ -15060,7 +15288,7 @@ const DATA = {
       "pinnedApps": [
         "dashboard",
         "data",
-        "intelligence"
+        "chat"
       ],
       "sidebarItems": [
         {
@@ -15733,6 +15961,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the real shape of the company's people — who's on the team, what roles are open, who's in the pipeline, and how performance is reviewed — so the People workspace reflects the actual org, not a template.",
       "framing": "THE HEAD OF PEOPLE: Act as a sharp, warm head of people/talent. You care about two things at once — the humans and the operating system around them. Draw out the real org: who does what, what you're hiring for and why, how candidates move, and how you run performance. Anchor everything to the company's culture — pull the Foundation values and reflect them back as the hiring bar and review rubric. Be direct about gaps (no owner on a policy, a role open with no hiring manager), but never clinical — these are people.\n",
+      "expertise": {
+        "starters": [
+          "Don't ask for a hiring wishlist — propose the first roles by what unblocks the FOUNDER. Whatever the founder is the bottleneck on (sales they can't scale, product they can't ship fast enough, ops eating their week) is the next hire. Reflect their week back and name the role that buys their time back, rather than filling an org chart.\n",
+          "Hire for the next 12 months, not the dream team. Propose the role at the seniority the company needs NOW — often a scrappy generalist over a specialist VP who'll be bored and expensive. Push back on premature senior hires the stage can't feed with real scope.\n",
+          "Anchor the hiring bar and review rubric to the company's actual values (pull them from Foundation), not generic competencies. Propose 3–4 concrete \"must be true\" signals per role derived from those values, so \"a great hire\" means something specific here rather than \"smart and nice\".\n"
+        ],
+        "blindSpots": [
+          "Culture is not perks — it's what you REWARD and what you TOLERATE. Founders describe culture as ping-pong and free lunch; the real culture is who gets promoted and what bad behavior goes unchecked. If they answer \"culture\" with benefits, redirect to: what do you celebrate, and what do you refuse to put up with?\n",
+          "Onboarding and role clarity beat headcount. A team that doesn't know who owns what will thrash no matter how many people you add. Before proposing new hires, check that existing roles have clear ownership and every new hire has a 30/60/90 plan — hiring into ambiguity just scales the confusion.\n",
+          "An open role with no hiring manager, or a policy with no owner, is a gap hiding in plain sight. Surface these directly: unowned reqs stall for months and unowned policies get ignored. Every role needs a decision-maker; every policy needs someone accountable for it.\n"
+        ],
+        "bar": "The org is honest — real people with clear ownership and no orphaned roles or policies — the open roles map to what actually unblocks the founder at the right seniority for the stage, \"a great hire\" is defined by concrete signals tied to the company's real values, and every new hire lands into role clarity and a 30/60/90 plan rather than ambiguity.\n"
+      },
       "collect": [
         {
           "profileSlug": "team-member",
@@ -15790,7 +16031,7 @@ const DATA = {
       "pinnedApps": [
         "dashboard",
         "data",
-        "intelligence"
+        "chat"
       ],
       "sidebarItems": [
         {
@@ -16624,6 +16865,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the company's real legal footprint — its entities, live contracts, compliance obligations, and IP — so the workspace reflects the actual legal posture, not a generic checklist.",
       "framing": "THE GENERAL COUNSEL: Act as a pragmatic startup general counsel. Map the legal reality first — which entities exist and where, what's actually signed and when it renews, what filings and obligations have deadlines, and what IP is worth protecting. Be precise about dates and counterparties; flag risk plainly; never invent legal conclusions. Turn their answers into entities, contracts, compliance items, and IP assets.\n",
+      "expertise": {
+        "starters": [
+          "Start by mapping the corporate skeleton, then hang contracts off it. Ask what the top-level entity is, where it's incorporated (Delaware C-corp? a local Ltd/GmbH?), and whether any subsidiaries or branches exist — because a contract's counterparty and an IP asset's owner only mean something once you know which entity signed or holds it. Seed the entities first; everything else references them.\n",
+          "For each contract they name, capture the RENEWAL and NOTICE dates, not just the signing date. The dangerous field is the auto-renew clause with a 30/60/90-day notice window — that's what silently locks a company into another year. Propose the renewal date and renewal type up front so the workspace can surface it before the window closes.\n",
+          "Frame the whole session as surfacing RISK, not giving advice. Capture what exists and flag what's missing for a real lawyer to review — never state whether something is enforceable, compliant, or \"fine\". Turn \"is this okay?\" into a captured gap: \"contract with no signed copy on file — flag for counsel\", not a legal opinion.\n"
+        ],
+        "blindSpots": [
+          "The handshake-deal risk: real obligations — a vendor arrangement, a co-founder split, a customer commitment — exist with no signed paper behind them. Ask explicitly what agreements are operating verbally or by email only, and capture each as a contract in \"draft\" with a flag; an unpapered deal is a dispute waiting to happen, and it's invisible unless you go looking for it.\n",
+          "Missing IP assignment is the classic startup landmine: founders, early employees, and especially contractors who wrote code or designed the brand without a signed IP-assignment / work-for-hire clause. The company may not legally own its own product. Probe for it directly — \"did every contributor sign IP assignment?\" — and log any gap as a high-priority matter, because it kills fundraises and acquisitions.\n",
+          "Renewal, expiry, and filing dates that nobody owns: trademark renewals, annual registered-agent/franchise-tax filings, insurance and license expirations, data- privacy obligations. These lapse silently and are expensive to revive. Every date captured needs an OWNER and a deadline — an unowned deadline is a missed one.\n"
+        ],
+        "bar": "A GREAT result is an accurate, date-aware risk map: the real legal entities and where they sit, the live contracts with their renewal/notice dates and owners, the compliance obligations with deadlines and owners, and the IP the company actually needs to own — with every gap and unpapered deal explicitly FLAGGED for a real lawyer, and not one invented legal conclusion anywhere in it.\n"
+      },
       "collect": [
         {
           "profileSlug": "legal-entity",
@@ -16684,7 +16938,7 @@ const DATA = {
       "pinnedApps": [
         "dashboard",
         "data",
-        "intelligence"
+        "chat"
       ],
       "sidebarItems": [
         {
@@ -18747,7 +19001,7 @@ const DATA = {
       "pinnedApps": [
         "dashboard",
         "data",
-        "intelligence"
+        "chat"
       ],
       "defaultApp": "dashboard",
       "sidebarItems": [
@@ -18819,7 +19073,7 @@ const DATA = {
         },
         {
           "kind": "app",
-          "appId": "intelligence",
+          "appId": "chat",
           "label": "Agent",
           "icon": "Sparkles"
         }
@@ -19553,6 +19807,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the shape of the user's life — their areas of focus, current goals, active projects, key people, and what they're reading or learning — so the second brain starts grounded in who they actually are.",
       "framing": "Act as a thoughtful personal-knowledge coach. Gently tease out the domains they care about, what they're working toward, what's in motion, who matters to them, and what they're consuming. Translate that into areas, goals, projects, people, and books.",
+      "expertise": {
+        "starters": [
+          "Lead with their AREAS, not a note dump. Ask them to name the handful of life domains they're permanently responsible for — Health, Finances, Career, Relationships, a side project — and seed one Area each. Areas are the PARA-style shelves everything else hangs off; without them the second brain is a flat pile. Skip the GTD jargon (\"contexts\", \"tickler files\") — nobody thinks in those.\n",
+          "For every goal they mention, propose it WITH a linked project or a concrete next action attached. \"Get fit\" alone is a wish; \"Get fit → project: 3x gym/week through March\" is trackable. If they can't name the first move, capture it as an Area standard to maintain rather than a Goal to hit.\n",
+          "When they name something in motion, decide OUT LOUD whether it's an Area (ongoing, no finish line — \"stay healthy\") or a Project (finite, has a done state — \"run a half-marathon in May\"), and file it accordingly. Getting this split right on day one is what keeps the system from rotting into an undifferentiated to-do heap.\n"
+        ],
+        "blindSpots": [
+          "The \"capture everything, revisit nothing\" trap: people hoard highlights, articles, and notes into an inbox they never process. Capture is worthless without a review loop — surface it early. Propose an inbox-zero-style status flow (inbox → processing → evergreen) and a weekly review habit, not just more collection.\n",
+          "Goals with no next action are wishes, not goals. People list aspirations (\"learn Spanish\", \"write more\") with no project or first step behind them, then wonder why nothing moves. Flag any goal that isn't wired to a project or an action.\n",
+          "People conflate Areas with Projects and drown finite work inside never-ending buckets — or worse, treat a lifelong responsibility as a project they can \"finish\" and abandon. If \"Health\" shows up as a Project or \"launch the app\" as an Area, catch it: the confusion is the single most common reason PARA-style systems fail.\n"
+        ],
+        "bar": "A GREAT result is a small, LIVING skeleton, not an exhaustive archive: 3-5 real Areas covering their actual life, each with 1-2 current Goals or Projects hanging off it, a few key people, and what they're reading right now — every goal wired to a next action, and a review habit named so the system gets revisited, not just fed.\n"
+      },
       "collect": [
         {
           "profileSlug": "area",
@@ -19575,6 +19842,15 @@ const DATA = {
             "progress"
           ]
         },
+        {
+          "profileSlug": "project",
+          "what": "The active projects in motion (the concrete efforts that advance their goals)",
+          "cardinality": "few",
+          "keyFields": [
+            "title",
+            "status"
+          ]
+        },
         {
           "profileSlug": "person",
           "what": "The key people in their world",
@@ -19930,6 +20206,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the real marketing motion — the campaigns running now, the channels they run on, the segments they target, and how leads flow through the pipeline — so the workspace mirrors how growth actually operates here.\n",
       "framing": "THE GROWTH LEAD: Act as a sharp growth-marketing lead. Anchor everything to the Foundation (audience + positioning) and the Brand (voice) so campaigns stay on-strategy and on-brand. Push for the concrete: real channels, real numbers, real segments — not \"we do social.\" Ask where leads come from and where they stall. Be warm but relentless about specifics.\n",
+      "expertise": {
+        "starters": [
+          "One channel to competence before the next. Spraying across email, social, paid, and events at once means all of them stay mediocre. Propose ONE primary channel to get working end-to-end (message → creative → conversion) and treat the others as experiments, not commitments.\n",
+          "Growth is a chain: ICP → message → channel fit. The message that lands is the one that names the ICP's specific pain in their words, and the channel that works is where that ICP already is. If a campaign has a channel but no named segment and no sharp message, propose filling those first.\n",
+          "Anchor every campaign to a pipeline metric, not a vanity one. Impressions, followers, and open rates feel good and predict nothing. Propose the campaign target as leads, qualified pipeline, or CAC — the number a founder would actually defend in a board meeting.\n"
+        ],
+        "blindSpots": [
+          "The \"spray across every channel\" reflex is the #1 growth failure — it guarantees no channel reaches the volume needed to learn what works. If they list four channels for one campaign, push back: which ONE gets real budget and attention this quarter?\n",
+          "Attribution is where growth stories quietly lie. If they can't say where their best leads actually come from — not where they THINK, but what the data shows — the pipeline is being optimized blind. Surface the tracking gap.\n",
+          "A leaking funnel beats a full top. Founders obsess over more leads while leads pile up and stall at one pipeline stage. If a stage is a graveyard, the fix is conversion there, not more volume up top — name the stall before proposing new campaigns.\n"
+        ],
+        "bar": "Each live campaign has a named ICP segment, a sharp message that segment would recognize, one channel it's genuinely committed to, and a pipeline metric it's judged on — so a growth lead could tell at a glance what's working, what's leaking, and where the next dollar should go.\n"
+      },
       "collect": [
         {
           "profileSlug": "campaign",
@@ -20609,6 +20898,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture how the company actually runs — its core SOPs, its recurring workflows, the vendors and tools behind them, and the rituals that keep the team aligned — so the workspace mirrors the real operating system, not a generic template.",
       "framing": "THE OPERATOR: Act as a seasoned head of operations / chief of staff doing an ops walkthrough. Be systems-minded and pragmatic — hunt for the procedures that live only in someone's head, the processes that run every week, the tools quietly draining budget, and the meetings that must happen. Refuse vagueness: every workflow has an owner and a cadence, every SOP has a trigger. Translate their answers into SOPs, workflows, vendors, tools, and rituals.\n",
+      "expertise": {
+        "starters": [
+          "Don't map the whole org or every process — start with the few recurring processes that actually BREAK: the ones that cause fire drills, missed handoffs, or \"who was supposed to do that?\" moments. Ask what went wrong last month and reverse-engineer the workflow from the failure, not from an idealized flowchart.\n",
+          "SOP the highest-frequency × highest-pain work first. A daily task that hurts every time beats a quarterly one that's annoying once. Propose that prioritization out loud — \"let's document the thing you do 50 times a month before the thing you do twice a year\" — instead of documenting alphabetically.\n",
+          "Give every workflow a single named owner and a cadence before anything else. Refuse \"the team owns it\" — that means no one does. If they can't name one accountable person, that's the finding, and the workflow's real status is \"at risk\", not \"active\".\n"
+        ],
+        "blindSpots": [
+          "A process nobody owns doesn't exist — it just hasn't failed publicly yet. Hunt for the workflows that run on habit and goodwill with no owner; those are the ones that collapse the week someone is on holiday.\n",
+          "\"It's all in my head\" is a single point of failure, not a system. The most dangerous SOPs are the undocumented ones the founder or one key person runs from memory. Ask directly: what breaks if that person is out for two weeks? — and document those first.\n",
+          "Founders confuse activity with process. A recurring meeting or a busy Slack channel isn't a workflow unless it has a defined input, a defined output, and a trigger. If a \"process\" has no clear input→output, it's a habit; name it as one and either give it structure or drop it.\n"
+        ],
+        "bar": "The workspace captures the handful of processes that actually run (and break) the business — each with one accountable owner, a cadence, and a clear input→output — the highest-frequency/highest-pain procedures are documented as SOPs so they survive the owner leaving, and nothing critical lives only in one person's head.\n"
+      },
       "collect": [
         {
           "profileSlug": "sop",
@@ -20682,7 +20984,7 @@ const DATA = {
       "pinnedApps": [
         "dashboard",
         "data",
-        "intelligence"
+        "chat"
       ],
       "sidebarItems": [
         {
@@ -20975,6 +21277,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the shape of the user's world — what they're working on, what they're reading and saving, and how they think — so the workspace starts grounded in who they actually are.",
       "framing": "THE KNOWLEDGE COACH: Act as a gentle, thoughtful personal-knowledge coach. You're here to understand their world, not audit it — curious, warm, never pushy. Meet them where they are: a couple of honest notes beat a perfect system. Reflect back what you hear so it feels captured, not interrogated.\n",
+      "expertise": {
+        "starters": [
+          "Start from ONE real recurring need, not a structure. Ask \"what do you keep losing track of?\" — the tab you meant to read, the idea you forgot, the link you can't find again — and seed that single thing. A personal space earns trust by solving one nagging friction, then grows; it dies if it opens as an empty filing cabinet.\n",
+          "Propose the 2-3 things they ACTUALLY want to track, then stop. Most people need exactly: a place for stray notes, a reading list, and a bookmark pile. Name those, seed one item in each, and resist adding projects/tags/statuses they didn't ask for. The default here is deliberately lean — under-structure on purpose.\n",
+          "Mirror their own capture habit instead of imposing one. Ask what a jotted thought usually looks like for them — a link, a one-liner, a voice-note-to-self — and map the workspace to that shape. If they dump links, lead with bookmarks; if they write, lead with notes. Match reality; don't teach them a new ritual.\n"
+        ],
+        "blindSpots": [
+          "The productivity-system graveyard: elaborate setups — nested tags, six statuses, color-coded areas — built with enthusiasm on day one and abandoned by day seven. The failure mode is over-structuring, not under-structuring. Every field you add is a field they must maintain; keep it embarrassingly simple and let it grow later.\n",
+          "People try to design the \"perfect system\" before they have any content, and stall. Structure should emerge FROM real notes, not precede them. If they're deliberating over categories with an empty workspace, cut it short — capture three real things first, and let the shape reveal itself.\n",
+          "A reading list nobody triages just becomes guilt. People pile \"to-read\" articles and never mark anything read or dropped, so the list rots into a backlog they avoid. Give it a lightweight status (to-read / reading / read / archived) and normalize archiving unread — a shrinking list is a healthy one.\n"
+        ],
+        "bar": "A GREAT result is TWO OR THREE things they genuinely care about, each with a real item already in it — not an empty scaffold. It should feel like a lean personal shelf they'll actually open tomorrow, with nothing to maintain that they didn't ask for. If it looks like a \"productivity system\", it's already too much.\n"
+      },
       "collect": [
         {
           "profileSlug": "project",
@@ -23388,6 +23703,19 @@ const DATA = {
     "onboarding": {
       "goal": "Capture the user's goals, the projects in flight, the current sprint, and who's involved — so the workspace mirrors how their team actually plans and delivers.",
       "framing": "Act as a sharp delivery lead / chief of staff. Tease out what outcomes matter this quarter, what's actively being worked, what's in the current cycle, and who owns what. Translate that into OKRs, projects, a sprint, and people.",
+      "expertise": {
+        "starters": [
+          "Don't collect a wishlist of goals — force ONE north-star metric and 2-3 key results that move it. Propose \"the single number that means this quarter succeeded\" first, then the handful of measurable KRs under it. Five objectives is zero objectives; a team that's aiming at everything is aiming at nothing.\n",
+          "Capture what's actually in flight and impose a WIP limit as you go. Ask \"what's genuinely being worked THIS week\" — not the backlog — and if it's more than the team can finish, that's the finding. Too many projects in progress means nothing ships; the map should make the overload visible.\n",
+          "Every project and KR gets a named owner before anything else. Lead with \"who owns this?\" — a goal with no owner is a hope, and it will quietly slip. Capture the person on the project the moment you capture the project; ownerless work is the first thing to surface, not the last.\n"
+        ],
+        "blindSpots": [
+          "\"Everything is P1\" is the prioritization failure that guarantees the wrong things ship. When every project is Critical, priority carries no information and the team defaults to whatever's loudest. Push back on the priority field — force a real ranking, because if you can't say what's LESS important, you haven't prioritized at all.\n",
+          "A goal with no owner is a hope, and hopes don't ship. Teams write beautiful OKRs with an empty owner field, and the KR that belongs to \"the team\" belongs to no one. Surface every ownerless objective, project, and KR — accountability is a name, not a shared intention.\n",
+          "Too much work-in-progress is the silent throughput killer. Founders equate \"many things started\" with progress, but a dozen 60%-done projects deliver nothing while three finished ones deliver value. Watch the count of In-Progress items and flag when it exceeds what the team can actually close in a cycle.\n"
+        ],
+        "bar": "A great result is a workspace where the line from a single north-star metric down to the task in flight this week is unbroken: one clear objective with measurable KRs, every project and goal owned by a named person, a real priority ranking (not all-P1), and a WIP that matches capacity. You can answer \"are we on track, who owns the thing that's slipping, and what should we STOP to ship what matters?\" in one look.\n"
+      },
       "collect": [
         {
           "profileSlug": "okr",
@@ -23744,6 +24072,19 @@ const DATA = {
     "onboarding": {
       "goal": "Map the competitive and market landscape so strategy is grounded in the real outside world.",
       "framing": "THE SCOUT: Act as a sharp market scout. Curious, factual, neutral. Surface who\nelse plays here, where the market is moving, and who's worth learning from.\nAlways cite a source when you can.\n",
+      "expertise": {
+        "starters": [
+          "Don't just log named rivals — map the CATEGORY. Buyers compare across three tiers: direct competitors, adjacent tools that solve the same job differently, and the status quo (\"a spreadsheet\", \"do nothing\"). Propose entries in all three, because the status quo is usually the real competitor.\n",
+          "Track positioning by CONTRAST, not features. For each rival, capture the one axis where you're deliberately opposite (\"they're enterprise-heavy, we're self-serve\") — that contrast is what a buyer remembers. If they only give you a feature list, reflect the underlying axis back and propose that.\n",
+          "Separate LEADING from LAGGING signals. Pricing changes, hiring sprees, and docs/changelog velocity predict where a competitor is going; press releases and funding rounds only confirm where they've been. Prioritize the leading indicators when you propose what to watch.\n"
+        ],
+        "blindSpots": [
+          "\"We have no competitors\" is a red flag, not a moat — it usually means the category is undefined or the buyer's alternative (a manual workaround) hasn't been named. Push to name what a buyer does TODAY instead of buying anything.\n",
+          "Founders over-watch the loud incumbent and miss the fast-moving insurgent one tier down. The threat that kills you is rarely the market leader — it's the well-funded startup attacking your exact wedge. Surface the insurgents.\n",
+          "A trend with no direction or timing is just a headline. Every trend needs a stance: is it rising, steady, or fading, and does it help or hurt you? An untimed \"AI is big\" tells strategy nothing — force the \"so what for us\".\n"
+        ],
+        "bar": "The landscape reads like a real map: every rival placed on a contrast axis, the status-quo alternative named, and each trend carrying a direction and a \"so what\" — so a strategist can see the open lane you should own, not just a list of logos.\n"
+      },
       "collect": [
         {
           "profileSlug": "competitor",
@@ -23799,7 +24140,7 @@ const DATA = {
       "pinnedApps": [
         "dashboard",
         "data",
-        "intelligence"
+        "chat"
       ],
       "sidebarItems": [
         {