@synap-core/workspace-templates 0.12.0 → 0.24.0

package/src/outreach-comms.yaml

@@ -1,486 +0,0 @@
-# Outreach & Comms workspace template
-# A standalone, channel-first outreach workspace: personalized LinkedIn and
-# email sequences run against people and companies you already track pod-wide.
-# Owns the outreach data (campaigns + individual touches) and the playbook
-# that drafts and sends the next message — not a CRM, not a content calendar.
-# Reuses the pod-wide `person`/`company` kinds so a contact worked here is the
-# same entity a CRM or Ecosystem workspace sees, not a workspace-local twin.
-
-meta:
-  slug: outreach-comms
-  domain: revenue
-  name: Outreach & Comms
-  description: Personalized LinkedIn and email outreach — sequenced touches against real people and companies, drafted and sent by an agent.
-  icon: send
-  color: "#0EA5E9"
-  tags: [outreach, linkedin, email, comms, sequences]
-  isPublic: true
-
-workspace:
-  name: Outreach & Comms
-  description: Personalized LinkedIn and email outreach — sequenced touches against real people and companies, drafted and sent by an agent.
-  subtype: outreach-comms
-  visibility: pod_visible
-  capabilities:
-    - outreach.campaigns
-    - outreach.touches
-  sourceRoles:
-    outreach: provider
-
-profiles:
-  # ── Actors ────────────────────────────────────────────────────────────────
-  # The pod-wide person and company kinds — declared minimally so campaign and
-  # touch links resolve. Kept light on purpose: identity lives elsewhere.
-  - slug: person
-    displayName: Person
-    icon: user
-    color: amber
-    description: A person you are reaching out to — a prospect, partner, or contact.
-    properties:
-      - slug: email
-        label: Email
-        valueType: string
-        inputType: email
-      - slug: notes
-        label: Notes
-        valueType: string
-        inputType: textarea
-
-  - slug: company
-    displayName: Company
-    icon: building-2
-    color: "#10B981"
-    description: A company you are reaching out to.
-    properties:
-      - slug: website
-        label: Website
-        valueType: string
-        inputType: url
-      - slug: industry
-        label: Industry
-        valueType: string
-        inputType: text
-
-  # ── Outreach data (owned here) ───────────────────────────────────────────
-  - slug: outreach-campaign
-    displayName: Outreach Campaign
-    icon: target
-    color: sky
-    description: A sequence of personalized touches aimed at a segment — the "why we're reaching out" and the offer.
-    properties:
-      - slug: channel
-        label: Channel
-        valueType: string
-        inputType: select
-        enumValues: [linkedin, email, both]
-        constraints: { defaultValue: linkedin }
-      - slug: status
-        label: Status
-        valueType: string
-        inputType: select
-        enumValues: [draft, active, paused, completed]
-        constraints: { defaultValue: draft }
-      - slug: targetSegment
-        label: Target segment
-        valueType: string
-        inputType: text
-        placeholder: e.g. Series A-B B2B SaaS founders
-      - slug: valueProp
-        label: Value proposition
-        valueType: string
-        inputType: textarea
-      - slug: callToAction
-        label: Call to action
-        valueType: string
-        inputType: text
-      - slug: startDate
-        label: Start date
-        valueType: date
-        inputType: date
-      - slug: notes
-        label: Notes
-        valueType: string
-        inputType: textarea
-
-  - slug: outreach-touch
-    displayName: Outreach Touch
-    icon: message-circle
-    color: blue
-    description: A single message sent (or drafted) to one person as part of a campaign.
-    properties:
-      - slug: channel
-        label: Channel
-        valueType: string
-        inputType: select
-        enumValues: [linkedin, email]
-      - slug: touchType
-        label: Touch type
-        valueType: string
-        inputType: select
-        enumValues: [connection_request, follow_up, intro_email, reply]
-      - slug: status
-        label: Status
-        valueType: string
-        inputType: select
-        enumValues: [drafted, sent, opened, replied, bounced, no_response]
-        constraints: { defaultValue: drafted }
-      - slug: sentDate
-        label: Sent date
-        valueType: date
-        inputType: date
-      - slug: messageContent
-        label: Message content
-        valueType: string
-        inputType: textarea
-
-views:
-  - name: Campaigns
-    slug: outreach-campaigns
-    type: table
-    scopeProfileSlug: outreach-campaign
-    description: Every outreach sequence, its channel, and its status.
-    config:
-      columns: [title, channel, status, targetSegment, startDate]
-    defaultView: true
-  - name: Touches
-    slug: outreach-touches
-    type: kanban
-    scopeProfileSlug: outreach-touch
-    groupBy: status
-    description: Individual messages, grouped by where they stand — drafted through replied.
-    config:
-      groupBy: status
-      cardFields: [channel, touchType, sentDate]
-
-entityLinks:
-  - sourceProfileSlug: outreach-campaign
-    targetProfileSlug: person
-    type: targets
-    label: Targets
-  - sourceProfileSlug: outreach-campaign
-    targetProfileSlug: company
-    type: targets
-    label: Targets
-  - sourceProfileSlug: outreach-touch
-    targetProfileSlug: person
-    type: sent_to
-    label: Sent to
-  - sourceProfileSlug: outreach-touch
-    targetProfileSlug: outreach-campaign
-    type: part_of
-    label: Part of
-
-# Playbook — drafts and sends the next personalized touch for a target, using
-# whatever we already know about them so the message isn't generic. Bound to
-# the campaign kind so a captured/updated campaign can offer this as a session.
-playbooks:
-  - name: Personalized Outreach
-    description: Draft a personalized LinkedIn or email message to a target contact, send it, and log the touch.
-    goalTemplate: >-
-      Reach out to {target} on {channel} as part of the "{campaign}" campaign.
-      Research them first using what we already know (their company, role, and
-      any prior touches) so the message is specific, not generic. Campaign
-      context — value proposition and call to action: {campaignContext}. Draft
-      the message, send it via {channel}, then create an outreach-touch record
-      logging what was sent and update the target's contact record with the
-      outcome.
-    subjectProfile:
-      profileSlug: outreach-campaign
-    params:
-      - { name: target, type: entity, label: Target contact, required: true }
-      - { name: campaign, type: text, label: Campaign name, required: true }
-      - { name: channel, type: choice, label: Channel, defaultValue: linkedin }
-      - {
-          name: campaignContext,
-          type: text,
-          label: Value prop + call to action,
-        }
-    executor: is-agent
-    grants:
-      - linkedin_send_invite
-      - unipile_send_message
-      - gmail_send
-      - entity.create
-    status: active
-
-# ── LinkedIn conversation ingest (PURE-CONFIG automation — PROPOSAL) ─────────
-# Pulls LinkedIn threads via Unipile and records each as an EXTERNAL channel +
-# messages through the GENERIC `channel.ingest` verb. No provider code in the
-# pod — this composes existing verbs (unipile_list_accounts /
-# unipile_list_conversations / unipile_list_messages + channel.ingest).
-#
-# TRIGGER MODEL — ONE automation, both jobs (no high-freq polling):
-#   • RECONCILIATION: `triggerType: cron` at a LOW frequency (daily 06:00).
-#   • BACKFILL / on-demand: fire the SAME automation via
-#     `POST /automations/{id}/trigger` (MCP `synap_trigger_automation`), which
-#     "bypasses the automation's normal trigger config" and runs the flow once.
-# channel.ingest is idempotent, so cron sweeps and manual backfills are safe to
-# overlap and repeat.
-#
-# ⚠️ NEEDS-REVIEW — TWO verified engine constraints shape this flow; see the
-# handoff report. (1) The automation engine has NO nested loops
-# (LOOP_BODY_NODE_TYPES excludes `loop`/`sub_automation`), so the requested
-# `loop conversations → loop messages → channel.ingest per message` graph is
-# not expressible. This does ONE loop over conversations and hands each thread's
-# whole `messages` array to channel.ingest in a single call. (2) A `transform`
-# `map:` pipe can only project a single field/string per item, so it cannot
-# normalize messages into `{text, sentAt, participant, idempotencySeed}` objects
-# in-flow. => channel.ingest must accept a BATCH `messages: [...]` of raw
-# provider rows and do the per-message normalization + idempotent dedup
-# SERVER-SIDE. That is a contract change vs the single-message signature.
-# Kept `status: draft` until that batch shape ships; then activate.
-automations:
-  - key: linkedin-conversation-ingest
-    name: LinkedIn conversation ingest
-    description: >-
-      Pull LinkedIn conversations via Unipile and record each thread as an
-      external channel + its messages through channel.ingest (idempotent, so
-      re-runs are safe). Cron = low-frequency reconciliation; manual trigger =
-      on-demand backfill.
-    triggerType: cron
-    triggerConfig:
-      expression: "0 6 * * *"
-    status: draft
-    flow:
-      nodes:
-        - id: trigger
-          type: trigger
-          position: { x: 0, y: 0 }
-          data:
-            label: Daily 06:00 reconciliation (also fired manually for backfill)
-            triggerType: cron
-            config:
-              expression: "0 6 * * *"
-
-        # Resolve the connected account AT RUNTIME so the cron sweep needs no
-        # payload. A multi-account / multi-provider pod would still need a
-        # run-param accountId to sweep MORE than the first LinkedIn account — a
-        # per-account sweep would itself need the nested loop this engine lacks
-        # (secondary follow-up, noted in the report).
-        - id: list-accounts
-          type: capability
-          position: { x: 0, y: 120 }
-          data:
-            label: Resolve the connected Unipile account
-            verbId: unipile_list_accounts
-
-        # F5 — PROVIDER FILTER. `unipile_list_accounts` returns RAW Unipile v2
-        # account rows and a pod can connect several providers, so a non-LinkedIn
-        # account (WhatsApp / Telegram / Gmail) can sit at index 0. Taking a blind
-        # `accounts.0` would ingest that provider's threads AS linkedin. This
-        # `transform` node's array `filter:` pipe keeps ONLY LinkedIn accounts;
-        # every step below takes `.0` of the FILTERED list.
-        #   Field: the predicate matches the RAW Unipile v2 account shape
-        #   `type: 'LINKEDIN' | 'GMAIL' | 'WHATSAPP' | …` (verified in
-        #   UnipileConnector's UnipileAccountSchema, NOT the capability's loose
-        #   "provider" prose). evaluateCondition does an EXACT, case-sensitive
-        #   `==`, hence the uppercase literal.
-        #   Failure mode: if no LinkedIn account is connected (or the raw field
-        #   shape ever drifts) the filtered list is empty → the accountId below
-        #   resolves to "" → the run FAILS VISIBLY at list-conversations. It never
-        #   silently ingests the wrong provider — that is the point of F5.
-        #   Multi-LinkedIn-account: still takes the first; a run-param accountId
-        #   is the multi-account follow-up (noted in the report).
-        - id: filter-linkedin-account
-          type: transform
-          position: { x: 0, y: 180 }
-          data:
-            label: Keep only LinkedIn Unipile accounts
-            expression: "{{steps.list-accounts.output.accounts}} | filter:item.type == 'LINKEDIN'"
-
-        - id: list-conversations
-          type: capability
-          position: { x: 0, y: 240 }
-          data:
-            label: List LinkedIn conversations for the account
-            verbId: unipile_list_conversations
-            inputMapping:
-              accountId: "{{steps.filter-linkedin-account.output.result.0.id}}"
-
-        # NOTE: the automation engine caps loops at MAX_LOOP_ITERATIONS=100 per run
-        # (logs a warning, then truncates). So one cron pass reconciles the 100
-        # most-recent conversations; accounts with >100 threads need either a
-        # newest-first list (so the active threads are always covered) or a paged
-        # sweep (blocked today — would need the nested loops the engine lacks).
-        # Fine for the current dogfood scale; revisit if a user exceeds ~100 threads.
-        - id: conversations-loop
-          type: loop
-          position: { x: 0, y: 360 }
-          data:
-            label: For each conversation
-            iteratorExpression: steps.list-conversations.output.conversations
-            itemVariable: conversation
-
-        # Loop body (owned by conversations-loop): list this thread's messages,
-        # then ingest. `{{loop.item.id}}` is the chat/thread id for THIS
-        # iteration; `steps.list-messages` is re-bound per iteration.
-        - id: list-messages
-          type: capability
-          position: { x: 0, y: 480 }
-          data:
-            label: List this thread's messages
-            verbId: unipile_list_messages
-            inputMapping:
-              threadId: "{{loop.item.id}}"
-              accountId: "{{steps.filter-linkedin-account.output.result.0.id}}"
-
-        # GENERIC ingest — records the external channel for this thread and its
-        # messages, idempotently (dedup on a per-message idempotency seed derived
-        # SERVER-SIDE, e.g. `${externalId}:${sentAt}:${body}`). See the ⚠️ note:
-        # `messages` is a BATCH of raw provider rows (pending channel.ingest's
-        # batch contract).
-        - id: ingest
-          type: capability
-          position: { x: 0, y: 600 }
-          data:
-            label: Ingest thread + messages (idempotent, generic)
-            verbId: channel.ingest
-            inputMapping:
-              provider: linkedin
-              externalId: "{{loop.item.id}}"
-              title: "{{loop.item.name}}"
-              accountExternalId: "{{steps.filter-linkedin-account.output.result.0.id}}"
-              # F1 — TARGET THE CRM WORKSPACE. Without this, channel.ingest lands
-              # in the automation's OWN workspace, but the dashboard inbox reads
-              # "The arch CRM". Single-tenant target = the inbox/CRM workspace.
-              # TODO(multi-tenant): make this an install/run param instead of a
-              # literal (the flow schema has no template-var/param mechanism for a
-              # capability inputMapping today, so a documented literal is the
-              # single-tenant path — see the report).
-              workspaceId: "499328b7-fd35-4143-b1bc-67b9e45d9b4b"
-              # F2 — SUPPRESS THE BACKFILL STORM. This is a poll / reconciliation
-              # of HISTORICAL messages, so it must NOT emit
-              # `external_message.received` per message (channel resolve + dedup
-              # insert still run). Without this, one backfill of N threads fans
-              # out through the webhook + automation-trigger reactors N×messages.
-              suppressSideEffects: true
-              # BATCH mode: hand the whole thread's messages[] to the generic verb
-              # in ONE call (the engine has no nested loops). channel.ingest stays
-              # provider-agnostic — messageMap tells it (in CONFIG) where each field
-              # lives inside a raw Unipile v2 message row. Verified live 2026-07-27:
-              # a message = { id, text, timestamp (ISO), sender_id, is_sender, ... }.
-              messages: "{{steps.list-messages.output.messages}}"
-              messageMap:
-                text: text
-                id: id
-                sentAt: timestamp
-                # F3 — DIRECTION. `is_sender` (dot-path to a boolean per row) marks
-                # the operator's OWN sent messages as OUTBOUND so the inbox renders
-                # them right-aligned, instead of everything looking inbound.
-                isOutbound: is_sender
-                # F6 — participantExternalId DROPPED on purpose. link-at-birth
-                # binds the channel to the participant of the first-processed
-                # (newest) message, which — when that message is the account
-                # OWNER's own reply — mis-binds the whole thread to yourself. The
-                # channel `title` already carries the conversation (contact) name,
-                # so dropping the per-message sender id lets link-at-birth avoid
-                # the mis-bind.
-      edges:
-        - { id: e-trigger-accounts, source: trigger, target: list-accounts }
-        - {
-            id: e-accounts-filter,
-            source: list-accounts,
-            target: filter-linkedin-account,
-          }
-        - {
-            id: e-filter-convos,
-            source: filter-linkedin-account,
-            target: list-conversations,
-          }
-        - {
-            id: e-convos-loop,
-            source: list-conversations,
-            target: conversations-loop,
-          }
-        - {
-            id: e-loop-messages,
-            source: conversations-loop,
-            target: list-messages,
-          }
-        - { id: e-messages-ingest, source: list-messages, target: ingest }
-
-# LinkedIn send/search via Unipile, email send via Gmail (nango-google). The
-# user connects each once on install; a missing key fails gracefully per-skill.
-integrations:
-  - templateKey: unipile-linkedin
-  - templateKey: nango-google
-
-onboarding:
-  goal: >
-    Stand up an outreach motion — who we're targeting, on which channel, with
-    what offer — so the agent can start drafting and sending real touches
-    instead of waiting for a blank campaign.
-  framing: |
-    THE OUTBOUND LEAD: Act as a sharp SDR/outbound lead. Push for a SPECIFIC
-    segment and a SPECIFIC offer, not "reach out to everyone about our product".
-    A campaign with no segment and no value prop is just a contact list.
-  expertise:
-    starters:
-      - >
-        Name the segment as a person, not a market — "Head of Growth at
-        seed-to-Series-A B2B SaaS", not "SaaS companies". The agent personalizes
-        against a person, not a category.
-      - >
-        Every campaign needs ONE call to action, stated plainly — a call, a demo,
-        a reply. If the founder gives a vague goal ("build awareness"), push for
-        the concrete next step a touch should provoke.
-    blindSpots:
-      - >
-        Founders default to email when LinkedIn converts better for cold B2B —
-        ask which channel the target segment actually lives on before defaulting.
-      - >
-        A campaign with no target contacts yet is fine to create, but flag it —
-        the first touch needs at least one real person or company to reach.
-    bar: >
-      At least one real campaign exists with a named segment, a stated value
-      prop and call to action, and — ideally — a first target contact ready for
-      the Personalized Outreach playbook to run against.
-  collect:
-    - profileSlug: outreach-campaign
-      what: The outreach sequences to run — channel, target segment, and offer.
-      cardinality: few
-      keyFields: [channel, targetSegment, valueProp, callToAction]
-    - profileSlug: person
-      what: The first contacts to target with this campaign.
-      cardinality: few
-      keyFields: [email]
-  openingQuestions:
-    - "Who are you trying to reach — what role, at what kind of company?"
-    - "LinkedIn, email, or both?"
-    - "What's the one thing you want them to do after reading your message?"
-  doneWhen: At least one campaign captured with a channel, segment, and value prop, plus one target contact.
-
-app:
-  kind: stored
-  cellKey: entity-detail
-
-layout:
-  defaultView: Campaigns
-  defaultApp: null
-  pinnedApps: [dashboard, data, chat]
-  sidebarItems:
-    - kind: view
-      viewName: Campaigns
-      label: Campaigns
-      icon: target
-    - kind: view
-      viewName: Touches
-      label: Touches
-      icon: message-circle
-    - kind: app
-      appId: data
-      label: Data
-      icon: database
-
-bento:
-  # Distinct from the "Campaigns" table it embeds — see meetings-knowledge:
-  # the bento becomes its own view row, so a shared name collides in the
-  # switcher and makes layout.defaultView ambiguous.
-  viewName: Outreach Home
-  blocks:
-    - kind: view
-      viewName: Campaigns
-      pos: { x: 0, y: 0, w: 8, h: 5 }
-    - kind: view
-      viewName: Touches
-      pos: { x: 8, y: 0, w: 4, h: 5 }

package/src/the-arch.yaml

@@ -1,201 +0,0 @@
-# The Arch — the private command layer (addon on top of Enterprise OS)
-# =====================================================================
-# A PRIVATE suite template (isPublic: false → served only through the Control
-# Plane to its owner, never in the public catalog). It is the full company brain:
-# the whole public Enterprise OS PLUS the private flagship workspaces that make it
-# "The Arch" — the grant pipeline, the web3 ecosystem overlay, and the dev
-# dashboard.
-#
-# What it composes:
-#   • enterprise-os        — the whole public operating core (transitively brings
-#                            foundation / ecosystem / operations / crm)
-#   • grants               — the grant-agency pipeline (composes onto operations)
-#   • blockchain-ecosystem — web3 market actors + relations (composes onto ecosystem)
-#   • dev-dashboard        — the engineering/ops dashboard
-#
-# Ordering is safe by construction: `require` is deps-first, and grants /
-# blockchain-ecosystem declare their OWN compose bases (operations / ecosystem)
-# which enterprise-os installs first — so the overlays always land on a base that
-# already exists. Idempotent: install Enterprise OS first, then The Arch, and the
-# resolver reuses the OS workspaces instead of duplicating them.
-
-meta:
-  slug: the-arch
-  domain: company
-  name: The Arch
-  description: The complete private company brain — the whole Enterprise OS plus the grant pipeline, the web3 ecosystem overlay, and the dev dashboard.
-  icon: landmark
-  color: "#7C3AED"
-  tags: [suite, private, arch, grants, web3, flagship]
-  isPublic: false
-
-# `require` (deps-first). enterprise-os brings the public core; the three private
-# flagships overlay onto it (grants→operations, blockchain-ecosystem→ecosystem)
-# or stand alongside it (dev-dashboard). Transitive: enterprise-os's own deps
-# resolve before the overlays that compose onto them.
-dependencies:
-  - slug: enterprise-os
-    kind: workspace
-    relation: require
-    reason: "The whole public operating core — strategy, market, operations, and pipeline — that the private flagships extend."
-  - slug: grants
-    kind: workspace
-    relation: require
-    reason: "The grant-agency pipeline; composes its operations onto the Operations workspace the OS installs."
-  - slug: blockchain-ecosystem
-    kind: workspace
-    relation: require
-    reason: "Web3 market actors + relations; composes onto the Ecosystem workspace the OS installs."
-  - slug: dev-dashboard
-    kind: workspace
-    relation: require
-    reason: "The engineering / ops dashboard — the build-side view of the company."
-  - slug: networking
-    kind: workspace
-    relation: require
-    reason: "The partner-intro layer — need → intro-matcher → intro → billed_as → deal, with the A↔B confidentiality firewall; the Stellar Client-Sync emits needs that depend on it."
-
-workspace:
-  name: The Arch
-  description: The private command layer over the full company brain — track the cross-workspace initiatives that span the operating system and its private flagships.
-  subtype: the-arch
-  visibility: private
-
-profiles:
-  # The Arch's one native profile: a cross-cutting initiative that spans several
-  # of the workspaces this suite installs (a grant round that touches operations,
-  # ecosystem, and the dev dashboard, say). The place to stand above the lenses.
-  - slug: initiative
-    displayName: Initiative
-    icon: flag
-    color: "#7C3AED"
-    description: A cross-workspace initiative that spans the operating system and its private flagships.
-    properties:
-      - slug: summary
-        label: Summary
-        valueType: string
-        inputType: textarea
-      - slug: stage
-        label: Stage
-        valueType: string
-        inputType: select
-        enumValues: [shaping, active, blocked, shipped, archived]
-        constraints: { defaultValue: shaping }
-      - slug: lead
-        label: Lead
-        valueType: string
-        inputType: text
-      - slug: priority
-        label: Priority
-        valueType: string
-        inputType: select
-        enumValues: [low, medium, high, critical]
-        constraints: { defaultValue: medium }
-      - slug: dueDate
-        label: Due Date
-        valueType: date
-        inputType: date
-
-views:
-  - name: Initiatives
-    slug: initiatives
-    type: table
-    scopeProfileSlug: initiative
-    description: The cross-workspace initiatives spanning the full company brain, by stage and priority.
-    defaultView: true
-    config:
-      columns: [title, stage, priority, lead, dueDate]
-  - name: Initiative Board
-    slug: initiative-board
-    type: kanban
-    scopeProfileSlug: initiative
-    description: Initiatives grouped by stage — the command view over everything in flight.
-    config:
-      groupBy: stage
-
-# The Arch now OWNS the per-client comms digest capability. `client-comms-report`
-# is the one capability no constituent template installs today — the portable,
-# message-only client digest that any pod can run. The Arch, as the full company
-# brain, is where it belongs: it rides in alongside the operations-native durable
-# briefing so the founder has BOTH the entity-first record and the lightweight
-# recap. (discord-bot / agency-skills / stellar-grant-client already ride in via
-# the `grants` constituent's own integrations, so they are not re-declared here.)
-integrations:
-  - templateKey: client-comms-report
-  # The Arch's OWN backend agents, callable from Synap over A2A (the reverse of the
-  # consume-a-service connectors): discover + dispatch the read-only intelligence
-  # agents. Reachable surface is bounded by the pasted A2A key's server-side scope.
-  - templateKey: arch-backend
-
-onboarding:
-  goal: >
-    Name the cross-workspace initiatives that span the operating system and its
-    private flagships — the few big things in flight that touch more than one
-    lens — so The Arch is a real command layer, not just an aggregate of apps.
-  framing: |
-    THE FOUNDER'S COMMAND LAYER: Act from the seat above every lens. The whole
-    company brain is installed — operating core plus the private grant, web3, and
-    dev flagships. Your job is to surface the handful of initiatives that cut
-    across them and give each a stage, a lead, and a priority.
-  expertise:
-    starters:
-      - >
-        Name the cross-cutting few. An initiative earns a place here only if it
-        spans more than one workspace — a grant round that pulls in operations,
-        ecosystem, and dev. Single-lens work stays in its lens.
-      - >
-        Give each initiative a real stage and lead. Shaping / active / blocked /
-        shipped is the honest status; a lead is who to ask. Without them the
-        command layer is a wish list.
-    blindSpots:
-      - >
-        Everything marked "high priority" is the same as nothing marked. Force
-        the ranking — what is actually critical this week?
-      - >
-        A blocked initiative with no note about the blocker is invisible risk.
-        Name what is stuck and on whom.
-    bar: >
-      A short command board: the few genuinely cross-workspace initiatives, each
-      with a stage, a lead, and an honest priority — sitting over a fully
-      installed company brain.
-  collect:
-    - profileSlug: initiative
-      what: The cross-workspace initiatives currently in flight.
-      cardinality: few
-      keyFields: [stage, priority, lead]
-  openingQuestions:
-    - "What are the few big initiatives in flight that span more than one part of the company?"
-    - "For each, what stage is it in and who is the lead?"
-  doneWhen: A few cross-workspace initiatives captured, each with a stage and a lead.
-
-app:
-  kind: stored
-  cellKey: entity-detail
-
-layout:
-  defaultView: Initiatives
-  defaultApp: null
-  pinnedApps: [dashboard, data]
-  sidebarItems:
-    - kind: view
-      viewName: Initiatives
-      label: Initiatives
-      icon: flag
-    - kind: view
-      viewName: Initiative Board
-      label: Board
-      icon: kanban-square
-    - kind: app
-      appId: data
-      label: Data
-      icon: database
-
-bento:
-  viewName: Initiatives
-  blocks:
-    - kind: view
-      viewName: Initiatives
-      pos: { x: 0, y: 0, w: 8, h: 4 }
-    - kind: view
-      viewName: Initiative Board
-      pos: { x: 8, y: 0, w: 4, h: 4 }