@synap-core/workspace-templates 0.2.2 → 0.4.0

package/src/brand-library.yaml

@@ -510,6 +510,74 @@ entityLinks:
     type: uses
     label: Uses token set
 
+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.
+  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.
+      - >
+        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.
+      - >
+        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.
+    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.
+      - >
+        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.
+      - >
+        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.
+    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.
+  collect:
+    - profileSlug: brand-identity
+      what: The core brand identity — name, essence, and how it presents itself.
+      cardinality: one
+    - profileSlug: brand-voice-guide
+      what: Voice guides — tone, personality traits, vocabulary, and do/don't examples per context.
+      cardinality: few
+      keyFields: [voice-personality-traits, voice-tone-descriptors, voice-example-do, voice-example-dont]
+    - profileSlug: brand-rule
+      what: Usage rules and constraints (mandatory / important / guideline).
+      cardinality: several
+    - profileSlug: brand-color
+      what: The brand's core colors.
+      cardinality: few
+    - profileSlug: brand-font
+      what: The brand's typefaces (heading / body / mono).
+      cardinality: few
+  openingQuestions:
+    - In three words, how should the brand sound?
+    - What's one thing the brand must never say or do?
+    - Who's the brand talking to (tie this back to your Foundation audience)?
+  doneWhen: A brand identity + at least one voice guide + a few rules are captured.
+
 app:
   kind: native
   appId: brandLibrary
@@ -581,47 +649,3 @@ bento:
     - kind: view
       viewName: Templates
       pos: { x: 6, y: 8, w: 6, h: 4 }
-
-seedEntities:
-  - profileSlug: brand-identity
-    title: Primary Brand
-    properties:
-      brand-type: universal
-      brand-status: active
-      brand-positioning: Describe the promise, category, and differentiation of this brand.
-      brand-audience-primary: Describe the primary audience and buying context.
-      brand-voice-summary: Clear, useful, specific, and calm.
-  - profileSlug: brand-color
-    title: Primary
-    properties:
-      color-role: primary
-      color-group: core
-      color-hex: "#B67A38"
-      color-token-name: brand-primary
-      color-status: approved
-      color-usage: Primary action and selection accent.
-  - profileSlug: brand-font
-    title: System Sans
-    properties:
-      font-role: body
-      font-family: system-ui
-      font-license: system
-      font-weights: "400, 500, 600, 700"
-      font-fallback: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif
-      font-status: active
-  - profileSlug: brand-token-set
-    title: Base Tokens
-    properties:
-      token-status: draft
-      token-mode: base
-      token-source-ids: seed
-      token-json: '{"colors":{"primary":"#B67A38"},"typography":{"body":"system-ui"}}'
-      token-css: ":root { --brand-primary: #B67A38; --brand-font-body: system-ui; }"
-  - profileSlug: brand-rule
-    title: Use approved sources first
-    properties:
-      rule-kind: generation
-      rule-subject: general
-      rule-severity: guideline
-      rule-content: Use approved colors, typefaces, assets, and token sets before creating variants.
-      rule-example: When generating an artboard, prefer the active token set and approved logo/image assets.

package/src/builder.yaml

@@ -1258,6 +1258,81 @@ entityLinks:
     type: depends_on
     label: Depends on
 
+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.
+  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.
+      - >
+        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.
+      - >
+        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.
+    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.
+      - >
+        "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.
+      - >
+        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.
+    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.
+  collect:
+    - profileSlug: devplane_app
+      what: The apps that are shipped or actively being built — with where their code lives and what stack they run on.
+      cardinality: several
+      keyFields: [appName, appStatus, techStack, repoUrl]
+    - profileSlug: devplane_service
+      what: The backend services, workers, and jobs that run behind those apps.
+      cardinality: few
+      keyFields: [serviceType, serviceStatus, host]
+    - profileSlug: devplane_environment
+      what: The servers and deploy targets the team ships to — local through production.
+      cardinality: few
+      keyFields: [envType, host, serverProvider]
+    - profileSlug: devplane_package
+      what: The shared packages the apps depend on — the reusable substrate of the codebase.
+      cardinality: several
+      keyFields: [packageName, packageRegistry, dependsOn]
+    - profileSlug: devplane_feature
+      what: The work in flight right now — features and work items with a status and priority.
+      cardinality: several
+      keyFields: [featureStatus, priority]
+    - profileSlug: project
+      what: The larger bounded bodies of work delegated to agents or the team, tied to a goal.
+      cardinality: few
+      keyFields: [project-status, project-goal]
+  openingQuestions:
+    - "What have you actually shipped, and what's still just planned? Give me the apps and their repos."
+    - "For each app — what runs behind it (services, workers), and where does it deploy?"
+    - "What's on your plate this week, and which of it should be delegated to agents?"
+  doneWhen: at least one app (with a repo) + its primary deploy target + one in-flight feature or project captured.
+
 # App reference
 app:
   kind: native
@@ -1335,21 +1410,3 @@ bento:
     - kind: view
       viewName: Task Board
       pos: { x: 0, y: 4, w: 12, h: 6 }
-
-seedEntities:
-  - profileSlug: deployment_target
-    title: Coolify Production (CT 103)
-    properties:
-      targetType: coolify
-      targetUrl: "http://10.10.0.20:8000"
-      targetAuthRef: COOLIFY_PROD_TOKEN
-      targetEnvType: production
-      targetStatus: active
-  - profileSlug: deployment_target
-    title: Coolify Staging (CT 104)
-    properties:
-      targetType: coolify
-      targetUrl: "http://10.10.0.20:8000"
-      targetAuthRef: COOLIFY_STAGING_TOKEN
-      targetEnvType: staging
-      targetStatus: active

package/src/content-os.yaml

@@ -677,397 +677,6 @@ entityLinks:
     targetProfileSlug: post
     type: publishes
 
-seedEntities:
-  - profileSlug: pillar
-    title: Data Sovereignty
-    properties:
-      pillar-status: Active
-      pillar-audience: "Founders, developers, and privacy-conscious professionals"
-      pillar-goal: "Position Synap as the infrastructure layer for personal data ownership — make the audience feel that sovereignty is not technical, it is a right"
-      pillar-formats: "Articles + Threads"
-      post-count-pillar: 12
-      avg-engagement: 340
-      top-post: "Why your data is not yours — and how to fix that"
-      posting-frequency: "2x / week"
-      pillar-tags: [sovereignty, synap, infrastructure]
-  - profileSlug: pillar
-    title: Product Building
-    properties:
-      pillar-status: Active
-      pillar-audience: "Indie hackers, founders, and early-stage builders"
-      pillar-goal: "Share the authentic journey of building Synap — decisions, mistakes, architecture choices — building trust through transparency"
-      pillar-formats: "Articles + Threads"
-      post-count-pillar: 8
-      avg-engagement: 210
-      top-post: "How we designed Synap's entity model from scratch"
-      posting-frequency: Weekly
-      pillar-tags: [building-in-public, synap, product]
-  - profileSlug: pillar
-    title: Creator Economy
-    properties:
-      pillar-status: Developing
-      pillar-audience: "Creators, solopreneurs, and content entrepreneurs"
-      pillar-goal: "Establish Synap's authority in the creator tools space — explain why the current tool stack is broken and what a sovereign alternative looks like"
-      pillar-formats: "Articles + Threads"
-      post-count-pillar: 4
-      avg-engagement: 180
-      posting-frequency: Weekly
-      pillar-tags: [creator-economy, content-os, tools]
-  - profileSlug: platform
-    title: LinkedIn
-    properties:
-      platform-status: Active
-      platform-url: "https://linkedin.com/in/your-handle"
-      follower-count: 3200
-      follower-target: 10000
-      avg-engagement-rate: 4.2
-      platform-posting-freq: "3x / week"
-      last-post-date: "2026-02-23"
-      platform-notes: "Long-form articles perform 3x better than short posts. Best engagement on Monday 8am and Thursday 6pm. CET. Professional tone, avoid jargon."
-      platform-tags: [linkedin, b2b, professional]
-  - profileSlug: platform
-    title: "Twitter / X"
-    properties:
-      platform-status: Active
-      platform-url: "https://x.com/your-handle"
-      follower-count: 1800
-      follower-target: 5000
-      avg-engagement-rate: 2.1
-      platform-posting-freq: Daily
-      last-post-date: "2026-02-23"
-      platform-notes: "Threads outperform single tweets 4:1. Tech and sovereignty threads go viral occasionally. Engage before posting — reply to 5 accounts before publishing."
-      platform-tags: [twitter, threads, tech]
-  - profileSlug: platform
-    title: Synap Newsletter
-    properties:
-      platform-type: Newsletter
-      platform-status: Building
-      follower-count: 420
-      follower-target: 2000
-      avg-engagement-rate: 38
-      platform-posting-freq: Weekly
-      last-post-date: "2026-02-17"
-      platform-notes: "35-40% open rate. Audience is tech-adjacent, values depth over brevity. Tuesdays at 7am CET performs best. Personal voice + one tactical insight + one product update."
-      platform-tags: [newsletter, owned, sovereign]
-  - profileSlug: campaign
-    title: "Synap Template Launch — Q1 2026"
-    properties:
-      campaign-status: Active
-      campaign-type: Product Launch
-      campaign-pillar: "ref:pillar:Product Building"
-      campaign-start: "2026-02-01"
-      campaign-end: "2026-03-31"
-      campaign-goal: "Drive 500 new workspace template activations and grow newsletter to 1,000 subscribers"
-      campaign-kpi: "Newsletter Sign-ups"
-      kpi-target: 500
-      post-count: 12
-      campaign-tags: [launch, templates, q1-2026]
-    content: |-
-      # Campaign Brief: Synap Template Launch — Q1 2026
-
-      ## Objective
-
-      Drive 500 template activations and 1,000 new newsletter subscribers by March 31, 2026. This is Synap's first public-facing product moment — the goal is not just installs but proof that the entity-first model resonates with creators who think in systems.
-
-      ## Target audience
-
-      Content creators and founder-creators managing multi-channel presence across 2+ platforms. They've tried Notion templates. They've paid for Buffer and Later. They feel the friction. They're ready for something built differently.
-
-      ## Content plan
-
-      12 posts across LinkedIn and Twitter/X over 8 weeks:
-
-      - **Week 1-2**: Problem framing — the creator stack is broken, context-switching cost, no unified operating record
-      - **Week 3-4**: Solution reveal — what a Content OS actually looks like, entity model walkthrough
-      - **Week 5-6**: Template demo — what's included, how seed data works, the graph view
-      - **Week 7-8**: Social proof + launch push — install CTA, newsletter integration, community feedback
-
-      ## KPIs
-
-      | Metric | Target |
-      |--------|--------|
-      | Template activations | 500 |
-      | Newsletter subs added | 1,000 |
-      | LinkedIn post avg reach | 8,000+ |
-      | Twitter thread avg impressions | 15,000+ |
-
-      ## Budget
-
-      €0 paid. Organic only. Brand deals (Mintlify, Anytype) offset production time.
-
-      ## Dependencies
-
-      - Template JSON validated and live in install flow
-      - Synap Newsletter Issue 13 dedicated to template walkthrough
-      - Mintlify sponsorship confirmed for Issue 12
-  - profileSlug: campaign
-    title: Data Sovereignty Series
-    properties:
-      campaign-status: Active
-      campaign-type: Editorial Series
-      campaign-pillar: "ref:pillar:Data Sovereignty"
-      campaign-start: "2026-01-15"
-      campaign-end: "2026-04-30"
-      campaign-goal: "Establish Synap's thought leadership in the sovereignty space — 10 long-form posts that define the narrative"
-      campaign-kpi: "Follower Growth"
-      kpi-target: 1000
-      post-count: 6
-      campaign-tags: [sovereignty, series, thought-leadership]
-  - profileSlug: post
-    title: "Why your subscriber list is not yours — and what to do about it"
-    properties:
-      post-status: Published
-      post-format: Article
-      post-platform: LinkedIn
-      post-pillar: "ref:pillar:Data Sovereignty"
-      post-campaign: "ref:campaign:Data Sovereignty Series"
-      publish-date: "2026-02-10"
-      post-hook: "You have 3,000 newsletter subscribers. If Substack disappears tomorrow, how many of them can you reach?"
-      post-cta: "Download our free guide to migrating your subscriber list to sovereign infrastructure"
-      post-tags: [sovereignty, newsletter, substack]
-      engagement-score: 520
-      post-reach: 12400
-    content: |-
-      # Why Your Subscriber List Is Not Yours — And What to Do About It
-
-      ## Core argument
-
-      When you build an audience on Substack, Mailchimp, or Beehiiv, you don't own the relationship. The platform does. They store the emails. They control deliverability. They set the terms of export. And if they change their pricing, get acquired, or shut down — your list goes with them.
-
-      This is not a hypothetical risk. It is the default architecture of every major newsletter platform.
-
-      ## What ownership actually means
-
-      Owning your subscriber list means three things:
-
-      1. **You hold the data.** The email addresses, open history, click behavior, and preferences live in infrastructure you control — not on a vendor's server.
-      2. **You choose the delivery layer.** You can switch from Mailchimp to Postmark to SES without asking permission and without migration friction.
-      3. **You set the rules.** GDPR compliance, data retention, deletion requests — you handle them directly, not through a third-party dashboard.
-
-      ## The sovereignty architecture
-
-      The alternative is treating your subscriber database as a first-class entity in your own data infrastructure. A record per subscriber. Properties for consent date, source, segment, engagement history. Relationships to the newsletter issues they opened, the posts that drove the sign-up.
-
-      This is what Synap enables with the Newsletter profile — your subscriber data lives in your pod, queryable by you, portable to any email provider, never held hostage.
-
-      ## The ask
-
-      Follow if you believe your audience relationship is a business asset — not a vendor dependency.
-
-      ---
-      *Published: LinkedIn · Data Sovereignty pillar · Data Sovereignty Series campaign*
-  - profileSlug: post
-    title: "Synap's entity model: why we ditched the database-first approach"
-    properties:
-      post-status: In Draft
-      post-format: Article
-      post-platform: LinkedIn
-      post-pillar: "ref:pillar:Product Building"
-      post-campaign: "ref:campaign:Synap Template Launch — Q1 2026"
-      publish-date: "2026-03-03"
-      post-hook: "Every other tool gives you a database. We built a network of entities — and the difference is everything."
-      post-cta: "Try the Second Brain template in Synap — free"
-      post-tags: [product, synap, architecture]
-  - profileSlug: post
-    title: "Thread: The creator tool stack is broken — here is why"
-    properties:
-      post-status: Scheduled
-      post-format: Thread
-      post-platform: "Twitter / X"
-      post-pillar: "ref:pillar:Creator Economy"
-      post-campaign: "ref:campaign:Synap Template Launch — Q1 2026"
-      publish-date: "2026-02-25"
-      post-hook: "I talked to 40 creators this month. Every single one uses 5+ tools that don't talk to each other. Here's what they all want:"
-      post-cta: "Follow for the full Creator Economy report"
-      post-tags: [creator-economy, tools, research]
-  - profileSlug: post
-    title: "Content OS template — what's included and why we built it"
-    properties:
-      post-status: Idea
-      post-format: Short Video
-      post-platform: LinkedIn
-      post-pillar: "ref:pillar:Product Building"
-      post-campaign: "ref:campaign:Synap Template Launch — Q1 2026"
-      post-hook: "We spent 3 weeks researching 8 creator tools before building Synap's Content OS template. Here is what we found."
-      post-tags: [content-os, templates, synap, research]
-  - profileSlug: post
-    title: "Data sovereignty is not a technical concept — it is a political one"
-    properties:
-      post-status: Idea
-      post-format: Article
-      post-platform: LinkedIn
-      post-pillar: "ref:pillar:Data Sovereignty"
-      post-campaign: "ref:campaign:Data Sovereignty Series"
-      post-hook: "The Sovereign Individual was published in 1997. It predicted exactly what is happening right now with AI and personal data."
-      post-tags: [sovereignty, philosophy, ai]
-  - profileSlug: post
-    title: "How Synap templates are seeded: the JSON-first approach"
-    properties:
-      post-status: Review
-      post-format: Article
-      post-platform: LinkedIn
-      post-pillar: "ref:pillar:Product Building"
-      post-campaign: "ref:campaign:Synap Template Launch — Q1 2026"
-      publish-date: "2026-03-10"
-      post-hook: "Most SaaS products show you an empty database on day one. Synap shows you a fully functional workspace. Here is how we do it."
-      post-cta: "Read the full technical deep-dive on our blog"
-      post-tags: [engineering, synap, templates, onboarding]
-  - profileSlug: newsletter
-    title: "The Sovereign Stack — Issue 12"
-    properties:
-      newsletter-status: Sent
-      newsletter-series: The Sovereign Stack
-      issue-number: 12
-      subject-line: "The 3 databases that own your content career (and how to escape)"
-      preview-text: "Your Substack list, your Buffer posts, your Notion brain..."
-      send-date: "2026-02-17"
-      subscriber-count: 390
-      open-rate: 39.2
-      click-rate: 6.8
-      newsletter-sponsor: "ref:sponsor:Mintlify"
-      newsletter-campaign: "ref:campaign:Data Sovereignty Series"
-      newsletter-pillar: "ref:pillar:Data Sovereignty"
-      newsletter-tags: [sovereignty, creator-tools, newsletter]
-  - profileSlug: newsletter
-    title: "The Sovereign Stack — Issue 13"
-    properties:
-      newsletter-status: Scheduled
-      newsletter-series: The Sovereign Stack
-      issue-number: 13
-      subject-line: "Inside Synap's Content OS template — what we built and why"
-      preview-text: "6 profiles, 16 views, 1 relational graph you own forever"
-      send-date: "2026-02-24"
-      newsletter-campaign: "ref:campaign:Synap Template Launch — Q1 2026"
-      newsletter-pillar: "ref:pillar:Product Building"
-      newsletter-tags: [content-os, templates, synap]
-  - profileSlug: newsletter
-    title: "The Sovereign Stack — Issue 14"
-    properties:
-      newsletter-status: Drafting
-      newsletter-series: The Sovereign Stack
-      issue-number: 14
-      subject-line: "Why we picked Ghost over Substack (and what it cost us)"
-      preview-text: "Honest numbers: subscriber growth, open rates, and the SEO truth"
-      send-date: "2026-03-03"
-      newsletter-pillar: "ref:pillar:Data Sovereignty"
-      newsletter-tags: [ghost, substack, sovereignty, newsletter]
-      newsletter-campaign: "ref:campaign:Data Sovereignty Series"
-  - profileSlug: sponsor
-    title: Mintlify
-    properties:
-      deal-status: Active
-      sponsor-type: Newsletter Sponsorship
-      contact-name: Alex Chen
-      contact-email: "alex@mintlify.com"
-      deal-value: 800
-      payment-status: Invoice Sent
-      contract-date: "2026-02-10"
-      deliverable-deadline: "2026-02-28"
-      exclusivity-end: "2026-03-15"
-      deliverables: "1 newsletter mention in Issue 12 (primary placement, 80–100 words). 1 LinkedIn post tagging Mintlify. Approved copy to be provided by sponsor."
-      talking-points: "Mintlify writes beautiful docs from your codebase. For developer-facing teams. Mention the GitHub integration."
-      performance-notes: "Issue 12: 39.2% open rate, 6.8% click rate. Sponsor link received 47 clicks. Will share screenshot report."
-      sponsor-tags: [developer-tools, newsletter, q1-2026]
-    content: |-
-      # Sponsor Brief: Mintlify — Issue 12
-
-      ## Deal summary
-
-      - **Format**: Primary newsletter placement, Issue 12 (The Sovereign Stack)
-      - **Value**: €800
-      - **Deliverables**: 1 newsletter mention (80-100 words, primary placement) + 1 LinkedIn post tagging Mintlify
-      - **Exclusivity**: No competing dev-tool sponsors until March 15, 2026
-      - **Payment**: Invoice sent Feb 17 — awaiting transfer
-
-      ## Approved copy (newsletter)
-
-      Mintlify builds documentation that actually gets read. If you're a developer or building developer-facing tools, Mintlify generates beautiful docs directly from your codebase — with GitHub integration, versioning, and AI-powered search. Worth 10 minutes to see what your docs could look like.
-
-      ## Performance report (to send)
-
-      Issue 12 stats to share with Alex:
-      - Open rate: 39.2% (industry avg ~22%)
-      - Click rate: 6.8%
-      - Sponsor link clicks: 47
-      - Screenshot attached in follow-up email
-
-      ## Notes
-
-      Alex Chen is responsive on email. They're considering a Q2 campaign (3 issues). Keep performance data clean and send within 48h of issue send. Relationship worth nurturing — philosophically aligned audience.
-  - profileSlug: sponsor
-    title: Anytype
-    properties:
-      deal-status: Prospecting
-      sponsor-type: Social Post
-      contact-name: Pavel K.
-      deal-value: 600
-      payment-status: Not Yet Due
-      deliverables: "1 LinkedIn post (honest review format). 1 Twitter thread. Not exclusive."
-      talking-points: "Anytype is open-source, local-first, object-based PKM. Philosophically aligned with Synap audience."
-      sponsor-tags: [pkm, local-first, sovereignty]
-
-suggestedRelations:
-  - sourceRef: "post:Why your subscriber list is not yours — and what to do about it"
-    targetRef: "campaign:Data Sovereignty Series"
-    type: belongs_to_project
-  - sourceRef: "post:Synap's entity model: why we ditched the database-first approach"
-    targetRef: "campaign:Synap Template Launch — Q1 2026"
-    type: belongs_to_project
-  - sourceRef: "post:Thread: The creator tool stack is broken — here is why"
-    targetRef: "campaign:Synap Template Launch — Q1 2026"
-    type: belongs_to_project
-  - sourceRef: "post:Content OS template — what's included and why we built it"
-    targetRef: "campaign:Synap Template Launch — Q1 2026"
-    type: belongs_to_project
-  - sourceRef: "post:Data sovereignty is not a technical concept — it is a political one"
-    targetRef: "campaign:Data Sovereignty Series"
-    type: belongs_to_project
-  - sourceRef: "post:How Synap templates are seeded: the JSON-first approach"
-    targetRef: "campaign:Synap Template Launch — Q1 2026"
-    type: belongs_to_project
-  - sourceRef: "post:Why your subscriber list is not yours — and what to do about it"
-    targetRef: "pillar:Data Sovereignty"
-    type: relates_to
-  - sourceRef: "post:Synap's entity model: why we ditched the database-first approach"
-    targetRef: "pillar:Product Building"
-    type: relates_to
-  - sourceRef: "post:Thread: The creator tool stack is broken — here is why"
-    targetRef: "pillar:Creator Economy"
-    type: relates_to
-  - sourceRef: "post:Content OS template — what's included and why we built it"
-    targetRef: "pillar:Product Building"
-    type: relates_to
-  - sourceRef: "post:Data sovereignty is not a technical concept — it is a political one"
-    targetRef: "pillar:Data Sovereignty"
-    type: relates_to
-  - sourceRef: "post:How Synap templates are seeded: the JSON-first approach"
-    targetRef: "pillar:Product Building"
-    type: relates_to
-  - sourceRef: "newsletter:The Sovereign Stack — Issue 12"
-    targetRef: "campaign:Data Sovereignty Series"
-    type: belongs_to_project
-  - sourceRef: "newsletter:The Sovereign Stack — Issue 13"
-    targetRef: "campaign:Synap Template Launch — Q1 2026"
-    type: belongs_to_project
-  - sourceRef: "newsletter:The Sovereign Stack — Issue 12"
-    targetRef: "pillar:Data Sovereignty"
-    type: relates_to
-  - sourceRef: "newsletter:The Sovereign Stack — Issue 13"
-    targetRef: "pillar:Product Building"
-    type: relates_to
-  - sourceRef: "newsletter:The Sovereign Stack — Issue 14"
-    targetRef: "pillar:Data Sovereignty"
-    type: relates_to
-  - sourceRef: "newsletter:The Sovereign Stack — Issue 12"
-    targetRef: "sponsor:Mintlify"
-    type: relates_to
-  - sourceRef: "campaign:Data Sovereignty Series"
-    targetRef: "pillar:Data Sovereignty"
-    type: relates_to
-  - sourceRef: "campaign:Synap Template Launch — Q1 2026"
-    targetRef: "pillar:Product Building"
-    type: relates_to
-
 displayTemplates:
   - name: Post Card
     description: "Content unit with status, format, platform, and performance metrics"
@@ -1400,6 +1009,37 @@ playbooks: []
 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.
+      - >
+        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.
+      - >
+        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.
+    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.
+      - >
+        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.
+      - >
+        Pillars with no audience attached reach no one. Tie each pillar to a
+        specific segment — "content for everyone" is content for nobody.
+    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.
   collect:
     - profileSlug: pillar
       what: "Their recurring content themes / brand voice — the lenses their audience knows them for, and who each speaks to"