@synap-core/workspace-templates 0.8.1 → 0.9.0

package/src/content-os.yaml

@@ -27,6 +27,20 @@ meta:
 #     guarantees its SSOT body is the base; this template re-declares `sponsor`
 #     below with `scope: shared` (identical to grants.yaml's shared-role reuse) so
 #     provisioning dedups to the ONE pod-wide row and grants THIS workspace access.
+#   • `offer` — foundation's pod-wide `scope: shared` KIND (the thing being sold).
+#     Same mechanics as `sponsor`, and the re-declaration is equally load-bearing:
+#     both provisioning doors iterate ONLY `definition.profiles`, and that
+#     iteration is what writes the `profile_workspace_access` grant. Omit it and
+#     `offer` is invisible here — every `post → offer` link lands in
+#     `report.entityLinks.unresolved` instead of resolving.
+#   • `audience` / `pain-point` / `positioning` — foundation's pod-wide strategy
+#     kinds, targeted by six properties here. They ARE re-declared below, for the
+#     same grant reason as `offer`: a `targetProfileSlug` reference earns nothing.
+#     `resolve-property-target-profiles.ts:117` resolves the target through
+#     `getBySlugForWorkspace`, which for a SHARED profile requires a
+#     `profile_workspace_access` row — written only by declaring the slug. Without
+#     the declaration all six resolve to a NULL `target_profile_id`, i.e. an
+#     unconstrained picker.
 # Both are `require` (not `compose`): each dependency is a real standalone
 # workspace, and this template creates its OWN workspace — it does not overlay onto
 # theirs.
@@ -132,6 +146,44 @@ profiles:
         valueType: entity_id
         targetProfileSlug: sponsor
         inputType: entity_select
+      # ── The journey layer — BOTH axes optional, and independent ────────────
+      # `post-stage` is the AUDIENCE axis (unordered: where is the reader), and
+      # `post-series` + `post-position` are the CURRICULUM axis (ordered:
+      # chapter by chapter). A post carries at most one of each; with neither,
+      # this workspace behaves exactly as it did before the journey existed.
+      # Position lives on the POST, not on the series, so reordering a
+      # curriculum is one write per moved piece instead of rewriting a list.
+      - slug: post-stage
+        label: Journey Stage
+        valueType: entity_id
+        targetProfileSlug: journey-stage
+        inputType: entity_select
+      - slug: post-series
+        label: Series
+        valueType: entity_id
+        targetProfileSlug: series
+        inputType: entity_select
+      # ⚠️ Position is AGENT-READ, not yet user-rendered in sequence. `Plan Next
+      # Content` reasons over it (finds "a series that stops mid-chapter"), so it
+      # is real data, not dead — but NO view surfaces a single series' posts in
+      # order today (the series-detail relations slot is an unordered ObjectGraph,
+      # and corpus-wide views sort on ONE key so a flat position-sort interleaves
+      # every series). FAST-FOLLOW: an ordered "Posts in this series" section on
+      # the series detail page. Until then the order lives in the number, read by
+      # the agent, not shown back to the user as a sequence.
+      - slug: post-position
+        label: Position in Series
+        valueType: number
+        inputType: number
+        placeholder: "1 = first chapter"
+      # The commercial axis. Present ONLY when the pod actually sells something
+      # — `offer` is optional by construction (foundation.yaml), so an empty
+      # value here means "no commerce", never "unfilled".
+      - slug: post-offer
+        label: Offer
+        valueType: entity_id
+        targetProfileSlug: offer
+        inputType: entity_select
       - slug: publish-date
         label: Publish Date
         valueType: date
@@ -157,11 +209,22 @@ profiles:
         label: "Reach / Views"
         valueType: number
         inputType: number
+      # `repurposed-from` is free TEXT and stays that way. A `valueType` change
+      # is reported as a conflict and NEVER applied to a live workspace
+      # (reconcile-workspace-from-definition.ts), so retyping it would leave YAML
+      # and every provisioned pod permanently divergent. The real edge is added
+      # ALONGSIDE as `derived-from`; the text field is relabelled to say so and
+      # dropped from the views. A `remapPropertyValues` conversion can backfill
+      # the old values later — that is an operator-run script, not automatic.
       - slug: repurposed-from
-        label: Repurposed From
+        label: Repurpose Notes
         valueType: string
         inputType: text
-        placeholder: "Source post or content this was adapted from"
+      - slug: derived-from
+        label: Repurposed From
+        valueType: entity_id
+        targetProfileSlug: post
+        inputType: entity_select
       - slug: post-url
         label: Published URL
         valueType: string
@@ -181,11 +244,25 @@ profiles:
         valueType: string
         inputType: select
         enumValues: ["Active", "Developing", "Paused", "Retired"]
+      # `pillar-audience` was free text and MUST stay free text — see the note on
+      # `repurposed-from` above: a retype is a conflict that never reaches a live
+      # workspace. The real graph edges are the two `-ref` slugs added below,
+      # which point at foundation's pod-wide `audience` / `pain-point` rows. Both
+      # legacy fields keep their data and are dropped from the view columns.
       - slug: pillar-audience
-        label: Audience Segment
+        label: Audience Notes
         valueType: string
         inputType: text
-        placeholder: "Who does this pillar speak to?"
+      - slug: pillar-audience-ref
+        label: Audience
+        valueType: entity_id
+        targetProfileSlug: audience
+        inputType: entity_select
+      - slug: pillar-pain-ref
+        label: Pain Addressed
+        valueType: entity_id
+        targetProfileSlug: pain-point
+        inputType: entity_select
       - slug: pillar-goal
         label: Audience Goal
         valueType: string
@@ -236,6 +313,99 @@ profiles:
         label: Tags
         valueType: array
 
+  # ── Journey Stage — the AUDIENCE axis ─────────────────────────────────────
+  # A stage is an ENTITY, not an enum, because each one carries reasoning the
+  # agent needs to write toward it: the belief to install, the objection to
+  # dissolve, the next step to earn. An enum would carry a label and nothing
+  # else, and the whole point of the journey is that it explains itself.
+  #
+  # `scope: WORKSPACE` — content-os OWNS this vocabulary and no other template
+  # re-declares it. Making it `shared` would bind the ENTIRE corpus to this body
+  # forever via the shared-kind SSOT rule; that is a one-way door and this
+  # concept is young. `entityScope: pod` is the axis that actually matters here:
+  # the stage ROWS go pod-wide so marketing and CRM can point at "which stage
+  # was this reader in" without content-os having to hand out its vocabulary.
+  #
+  # Seeded by the onboarding interview as a small ladder the operator renames —
+  # 3 stages held honestly beats 7 invented ones.
+  - slug: journey-stage
+    displayName: Journey Stage
+    icon: footprints
+    color: "#F59E0B"
+    description: "A step on the reader's journey — where they are, what they now believe, and what moves them forward."
+    scope: WORKSPACE
+    entityScope: pod
+    properties:
+      - slug: stage-order
+        label: Order
+        valueType: number
+        inputType: number
+        placeholder: "1 = first contact"
+      - slug: stage-audience
+        label: Audience
+        valueType: entity_id
+        targetProfileSlug: audience
+        inputType: entity_select
+      - slug: belief-installed
+        label: Now Believes
+        valueType: string
+        inputType: textarea
+        placeholder: "What should the reader now believe that they didn't before?"
+      - slug: objection-removed
+        label: Doubt Answered
+        valueType: string
+        inputType: textarea
+        placeholder: "Which doubt does this stage dissolve?"
+      - slug: next-step
+        label: Next Step
+        valueType: string
+        inputType: text
+        placeholder: "The one action that moves them to the next stage"
+      # No `stage-offer` here — deliberate. The post already carries `post-offer`,
+      # and a stage-level offer would be a SECOND path to the same mapping with no
+      # rule for which wins when a stage says offer A and its posts say offer B.
+      # Which offer a stage serves is derivable through the posts that sit in it.
+
+  # ── Series — the CURRICULUM axis ──────────────────────────────────────────
+  # Ordered and prerequisite-bearing: "chapter by chapter" rather than "where is
+  # the reader". Workspace-scoped AND workspace-placed — a series is an editorial
+  # artifact with no life outside the publication, so unlike `journey-stage` its
+  # rows have no reason to go pod-wide. It holds no member list and no length:
+  # the members ARE whatever posts carry this series in `post-series`, ordered
+  # by `post-position`, so there is nothing here to keep in sync.
+  - slug: series
+    displayName: Series
+    icon: layers
+    color: "#0EA5E9"
+    description: "An ordered run of posts that teaches one thing end to end — the curriculum axis of the content engine."
+    scope: WORKSPACE
+    properties:
+      - slug: series-status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: ["Planned", "Running", "Complete", "Abandoned"]
+      - slug: series-goal
+        label: Goal
+        valueType: string
+        inputType: textarea
+        placeholder: "What can the reader do at the end that they couldn't at the start?"
+      # A series belongs to ONE pillar — the relationship the onboarding copy,
+      # the collect entry and the skill all already assert. It also settles the
+      # only real overlap in the model: `pillar-goal` ("what should the audience
+      # think/feel/do") and `series-goal` ("what can they DO at the end") ask
+      # nearly the same question, and a series that points at its pillar reads
+      # as the pillar's curriculum rather than competing with it.
+      #
+      # No `series-audience`: the pillar already carries one. Three pointers to
+      # the same answer (`pillar-audience-ref`, `series-audience`,
+      # `stage-audience`) is three places to keep in sync and two to get wrong.
+      - slug: series-pillar
+        label: Pillar
+        valueType: entity_id
+        targetProfileSlug: pillar
+        inputType: entity_select
+
   # `platform` is the ONE pod-wide publishing-account *vocabulary*. `scope: shared`
   # makes it a single pod-wide profile row that a `require`-consumer (e.g.
   # social.yaml) can adopt by RE-DECLARING this slug — the resolver writes the
@@ -340,7 +510,7 @@ profiles:
         enumValues:
           ["Idea", "Drafting", "Editing", "Scheduled", "Sent", "Archived"]
       - slug: newsletter-series
-        label: Series
+        label: Newsletter Series
         valueType: string
         inputType: text
         placeholder: "Which newsletter series is this issue part of?"
@@ -487,6 +657,134 @@ profiles:
         valueType: string
         inputType: textarea
 
+  # ── Strategy kinds (shared pod-wide — SSOT is foundation.yaml) ────────────
+  # Re-declared for the same grant-gating rule as `sponsor`/`offer` (see the meta
+  # header): six `targetProfileSlug` properties here point at these three kinds,
+  # and a reference earns no grant — omit the declaration and all six resolve to
+  # a NULL `target_profile_id`. Bodies verbatim from foundation; SSOT stays there.
+  - slug: audience
+    displayName: Audience
+    icon: users
+    color: blue
+    description: "An ideal customer profile — who we are built for."
+    scope: shared
+    entityScope: pod
+    properties:
+      - slug: segment
+        label: Segment
+        valueType: string
+        inputType: text
+      - slug: persona
+        label: Persona
+        valueType: string
+        inputType: textarea
+      - slug: jobs-to-be-done
+        label: Jobs to be done
+        valueType: string
+        inputType: textarea
+      - slug: traits
+        label: Traits
+        valueType: array
+        inputType: text
+
+  - slug: pain-point
+    displayName: Pain Point
+    icon: flame
+    color: orange
+    description: "A specific pain a target audience feels today."
+    scope: shared
+    entityScope: pod
+    properties:
+      - slug: description
+        label: Description
+        valueType: string
+        inputType: textarea
+      - slug: severity
+        label: Severity
+        valueType: string
+        inputType: select
+        enumValues: [low, medium, high, critical]
+        constraints: { defaultValue: medium }
+      - slug: target-audience
+        label: Audience
+        valueType: entity_id
+        targetProfileSlug: audience
+        inputType: entity_select
+      - slug: evidence
+        label: Evidence
+        valueType: string
+        inputType: textarea
+
+  - slug: positioning
+    displayName: Positioning
+    icon: crosshair
+    color: cyan
+    description: "Market category, who we stand against, and why we win."
+    scope: shared
+    entityScope: pod
+    properties:
+      - slug: category
+        label: Category
+        valueType: string
+        inputType: text
+      - slug: against
+        label: Against
+        valueType: string
+        inputType: textarea
+      - slug: because
+        label: Because
+        valueType: string
+        inputType: textarea
+
+  # ── Offer (shared pod-wide kind — SSOT is foundation.yaml) ────────────────
+  # Grant-gated exactly like the three above; body verbatim from foundation,
+  # `entityScope: pod` restated so rows land pod-wide even in the
+  # (ordering-degenerate) case where this workspace creates the profile first.
+  - slug: offer
+    displayName: Offer
+    icon: package
+    color: fuchsia
+    description: "Something the company sells — a product, service, or program. Optional: a pod that sells nothing simply has none."
+    scope: shared
+    entityScope: pod
+    properties:
+      - slug: offer-status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues:
+          - draft
+          - active
+          - paused
+          - retired
+        constraints: { defaultValue: draft }
+      - slug: offer-summary
+        label: Summary
+        valueType: string
+        inputType: textarea
+        placeholder: "What it is and what changes for the buyer"
+      - slug: offer-price-model
+        label: Price Model
+        valueType: string
+        inputType: select
+        enumValues:
+          - one-off
+          - subscription
+          - retainer
+          - usage-based
+          - free
+          - other
+      - slug: offer-audience
+        label: Audience
+        valueType: entity_id
+        targetProfileSlug: audience
+        inputType: entity_select
+      - slug: offer-positioning
+        label: Positioning
+        valueType: entity_id
+        targetProfileSlug: positioning
+        inputType: entity_select
+
 # CURATED views — the editorial spine
 views:
   - name: Posts
@@ -514,6 +812,21 @@ views:
     type: list
     scopeProfileSlug: pillar
     description: Content pillars — the recurring themes.
+  # The reader's journey, in order. Onboarding seeds a 3-stage ladder and invests
+  # a whole opening question in the belief each stage installs — this is where
+  # that is seen and edited (without it the stages are write-once, reachable only
+  # as a post's picker option). `type: list` reads `sortColumn`/`sortDirection`
+  # off `config` (ListAdapter.tsx:107-108, numeric-aware), so the ladder renders
+  # in `stage-order` sequence — NOT `sortBy`/`sortOrder`, which is the TABLE
+  # adapter's key and would be silently ignored here.
+  - name: Journey
+    slug: content-journey
+    type: list
+    scopeProfileSlug: journey-stage
+    description: The reader's journey, in order — each stage's belief and the doubt it answers.
+    config:
+      sortColumn: stage-order
+      sortDirection: asc
   - name: Platforms
     slug: content-platforms
     type: table
@@ -525,6 +838,31 @@ views:
     scopeProfileSlug: newsletter
     groupBy: newsletter-status
     description: Newsletter issues by status.
+  # ⚠️ NO `Journey Board` (matrix) view here — DELIBERATE, do not "restore" it.
+  # A coverage grid is the right idea and this is the wrong substrate today:
+  # `MatrixAdapter` derives each axis from the property's enum constraint, else
+  # from the values PRESENT on the loaded entities (MatrixAdapter.tsx:83-137).
+  # Both axes would be `entity_id`, which has no enum — so a stage no post
+  # occupies gets no column and a pillar with nothing written gets no row. The
+  # one thing a coverage grid exists to show — the EMPTY cell — is precisely
+  # what it cannot render. Axis labels would also be raw entity ids (nothing in
+  # view-renderer resolves an `entity_id` to a title; TableAdapter.tsx:53 says
+  # the same). Prerequisite: teach `deriveAxisValues` to seed axes from the
+  # TARGET profile's entities for `entity_id` fields, and resolve labels. Until
+  # then the coverage read is the `Plan Next Content` playbook's job, which does
+  # it properly by reading the corpus.
+  #
+  # The curriculum. Scoped to `series`, NOT a timeline over posts: a timeline
+  # keyed on `publish-date` silently DROPS every undated entity
+  # (TimelineAdapter.tsx:128) — which is every post onboarding creates, all of
+  # them status `Idea` — and sorts newest-first (`:144,147`), so a curriculum
+  # would read chapter 5 above chapter 1. Per-series ordering (`post-position`)
+  # belongs on the series detail page, not on a corpus-wide time axis.
+  - name: Series
+    slug: content-series
+    type: list
+    scopeProfileSlug: series
+    description: The curriculums you're running — each an ordered arc through one pillar.
 
 # App reference — view-driven, no custom app (mirrors marketing.yaml)
 app:
@@ -549,28 +887,48 @@ layout:
       viewName: Pillars
       label: Pillars
       icon: columns
+    - kind: view
+      viewName: Journey
+      label: Journey
+      icon: footprints
+    - kind: view
+      viewName: Series
+      label: Series
+      icon: layers
     - kind: view
       viewName: Platforms
       label: Platforms
       icon: share-2
+    # Last: a creator with no newsletter never fills this, and an empty kanban
+    # high in the rail reads as a workspace that isn't working.
     - kind: view
       viewName: Newsletters
       label: Newsletters
       icon: mail
 
-# Bento dashboard
+# Bento dashboard = the STUDIO HOME (the browser landing surface — `defaultView`
+# is inert in browser/, so the workspace opens on this bento, not on a view).
+# Ordered so a FRESH workspace still says something: the Coverage grid leads
+# (the "where am I thin" read — a custom cell, `content-coverage-map`, since a
+# generic matrix can't render an entity_id×entity_id grid's empty cells), then
+# Pillars and Posts which onboarding fills, then the calendar below (empty until
+# something carries a publish date). Newsletters deliberately absent — it stays
+# empty forever for anyone who doesn't run one.
 bento:
   viewName: Posts
   blocks:
-    - kind: view
-      viewName: Content Calendar
-      pos: { x: 0, y: 0, w: 12, h: 6 }
+    - kind: widget
+      widgetType: content-coverage-map
+      pos: { x: 0, y: 0, w: 6, h: 5 }
     - kind: view
       viewName: Pillars
-      pos: { x: 0, y: 6, w: 6, h: 5 }
+      pos: { x: 6, y: 0, w: 6, h: 5 }
     - kind: view
-      viewName: Newsletters
-      pos: { x: 6, y: 6, w: 6, h: 5 }
+      viewName: Posts
+      pos: { x: 0, y: 5, w: 6, h: 5 }
+    - kind: view
+      viewName: Content Calendar
+      pos: { x: 6, y: 5, w: 6, h: 5 }
 
 # Editorial graph: connect posts to campaign / pillar / sponsor
 entityLinks:
@@ -586,6 +944,25 @@ entityLinks:
     targetProfileSlug: sponsor
     type: sponsored_by
     label: Sponsor
+  # The journey edges. `derived_from` is a self-link on `post` — the repurpose
+  # chain (one idea → thread → video → newsletter section) finally as a real
+  # graph edge instead of the free text it lived in.
+  - sourceProfileSlug: post
+    targetProfileSlug: journey-stage
+    type: at_journey_stage
+    label: Journey Stage
+  - sourceProfileSlug: post
+    targetProfileSlug: series
+    type: part_of_series
+    label: Series
+  - sourceProfileSlug: post
+    targetProfileSlug: offer
+    type: teaches_toward
+    label: Offer
+  - sourceProfileSlug: post
+    targetProfileSlug: post
+    type: derived_from
+    label: Repurposed From
 
 # Playbooks — session templates seeded with the workspace.
 # `subjectProfile` binds this playbook to the `post` kind so the Capture → Session
@@ -609,21 +986,58 @@ playbooks:
     executor: is-agent
     status: active
 
+  # The proactive half. Deliberately has NO `subjectProfile`: a subject profile
+  # binds a playbook to ONE entity, so pairing it with a cron fans out into one
+  # run PER EXISTING POST (capped at 100) — exactly the wrong shape for a
+  # question about the corpus as a whole. This one reasons over everything at
+  # once and proposes the NEXT piece, which is why it also takes no params.
+  # Weekly, because a content plan that is re-litigated daily is not a plan.
+  - name: Plan Next Content
+    description: Audit the whole corpus against the journey, find the gap, and propose what to make next.
+    goalTemplate: >-
+      Audit the content corpus. Map every post onto its pillar and its journey
+      stage, and list which pillar × stage cells are empty or thin. Check the
+      running series for the chapter that is missing. If the pod has offers,
+      note which ones no content teaches toward; if it has none, plan purely for
+      audience-building and do not invent commerce. Then propose the next one or
+      two pieces — each as a post idea placed on a pillar, a stage, and a
+      platform, with the hook and the reason it is next.
+    executor: is-agent
+    # Monday 09:00, shipped OFF — the operator opts in. `enabled` is read
+    # STRICTLY (`cron-automation.ts:43` is `s.enabled === true`, and `:194`
+    # skips a falsy one), so OMITTING the key does not mean "on by default":
+    # it means the backing cron automation is never created and this playbook
+    # silently never fires. Declaring it explicitly is the difference between
+    # an opt-in cadence and a dead one. Off is the right default for a
+    # `isPublic: true` template — every installer would otherwise be enrolled
+    # in a recurring agent run (real token cost, a queue of proposals) they
+    # never asked for. Matches `ecosystem.yaml:413,436`, same cadence.
+    schedule: { cron: "0 9 * * 1", enabled: false }
+    status: active
+
 onboarding:
   goal: >
-    Stand up the editorial engine — the pillars you're known for, the platforms
-    you publish on, the cadence you can actually sustain, and a first post placed
-    in the system — so the workspace mirrors how you turn thinking into published
-    content, not a blank calendar.
+    Stand up the editorial engine — the pillars you're known for, the journey a
+    reader travels through them, the platforms you publish on, the cadence you
+    can actually sustain, and a first post placed in the system — so the
+    workspace mirrors how you turn thinking into published content that
+    compounds, not a blank calendar.
   framing: >
     THE EDITOR-IN-CHIEF: Act as a seasoned content strategist who has grown owned
     audiences from zero. Anchor everything on PILLARS — the two-to-four recurring
     themes an audience comes to you for — because pillars are what make a content
-    engine compound instead of drift. Pull voice and identity from Brand and the
-    target audience from Foundation so every piece lands on-strategy. Push for a
-    cadence they can hold for a year, not a heroic month. Be concrete: real
-    platforms, real formats, a real first post — a fuzzy "I'll post more" helps
-    no one.
+    engine compound instead of drift. Then ask the second question most creators
+    never ask: where is the reader when they arrive, and where are you taking
+    them? That is the JOURNEY — the ladder of belief a reader climbs, which turns a feed into a path.
+    Pull voice and identity from Brand and the target audience from Foundation so
+    every piece lands on-strategy. Push for a cadence they can hold for a year,
+    not a heroic month. Be concrete: real platforms, real formats, a real first
+    post — a fuzzy "I'll post more" helps no one.
+    COMMERCE IS OPTIONAL AND YOU MUST TREAT IT THAT WAY. Ask ONCE whether they
+    sell anything. If the answer is no, or vague, SKIP offers entirely, never
+    mention them again, and build the journey as pure audience-building — a
+    journey with no product at the end is a complete, correct answer, not a
+    half-finished one. Only if they name something real do you capture it.
   expertise:
     starters:
       - >
@@ -640,7 +1054,19 @@ onboarding:
         One idea, many formats — design for repurposing from the start. A single
         strong thought becomes a thread, a short video, a newsletter section, and
         a carousel. Propose the repurpose chain up front so one capture yields a
-        week of output, tracked via `repurposed-from`.
+        week of output, linked via `derived-from`.
+      - >
+        Most creators have never named the journey, so don't ask them to invent
+        one — PROPOSE a three-stage ladder and let them rename it. The usual
+        shape is: doesn't know the problem is theirs → believes it's solvable →
+        ready to act. For each stage, push for the BELIEF it installs and the
+        OBJECTION it removes; a stage with only a name teaches the engine
+        nothing.
+      - >
+        A series is how a pillar becomes a curriculum. Once the pillars are
+        named, propose ONE series inside the strongest of them — an ordered run
+        that takes a reader from not-knowing to able-to-do — and place the first
+        post as chapter one. One real series beats five planned ones.
     blindSpots:
       - >
         No pillars = brand drift. If they list a dozen post ideas but can't name
@@ -655,27 +1081,57 @@ onboarding:
         Chasing every platform at once guarantees all of them stay shallow. If
         they name five channels, push back: which ONE or two get real cadence and
         attention now, and which are experiments?
+      - >
+        Almost every corpus is stacked at one end of the journey — usually all
+        top-of-funnel awareness, or all deep expert material for people who
+        already believe. Once the stages exist, say which end is empty. That gap
+        is the single most useful thing this workspace can tell them.
     bar: >
-      The workspace reads like a running publication: a handful of named pillars
-      each tied to an audience, the platforms actually committed to with a
-      sustainable cadence, an owned newsletter channel, and a first post placed in
-      a pillar — so a strategist could see at a glance what the brand is about,
-      where it publishes, and what ships next.
+      The workspace reads like a running publication with a direction: a handful
+      of named pillars each tied to an audience, a journey the reader visibly
+      travels, the platforms actually committed to with a sustainable cadence, an
+      owned newsletter channel, and a first post placed in a pillar — so a
+      strategist could see at a glance what the brand is about, who it is taking
+      where, where it publishes, and what ships next. Close by telling them they
+      can ask "what should I write next?" anytime to see where the journey is
+      thin — so the coverage read is a habit, not a feature they never find.
   collect:
     - profileSlug: pillar
-      what: The recurring themes you're known for — the 2–4 lenses your audience comes to you for, each with the segment it speaks to and the goal it serves.
+      what: The recurring themes you're known for — the 2–4 lenses your audience comes to you for, each pointed at the audience it speaks to and the goal it serves.
+      cardinality: few
+      keyFields: [pillar-status, pillar-audience-ref, pillar-goal]
+    - profileSlug: journey-stage
+      what: The steps a reader travels, in order — propose a three-stage ladder and let them rename it. Each stage needs the belief it installs and the objection it removes, not just a label.
       cardinality: few
-      keyFields: [pillar-status, pillar-audience, pillar-formats]
+      keyFields: [stage-order, belief-installed, objection-removed]
+    - profileSlug: series
+      what: One ordered run of posts inside the strongest pillar that takes a reader from not-knowing to able-to-do. One real series, not a backlog of planned ones.
+      cardinality: one
+      keyFields: [series-status, series-goal, series-pillar]
     - profileSlug: platform
       what: The channels you actually publish on — the social accounts, newsletter, or podcast — with their status and the cadence you can hold.
       cardinality: several
       keyFields: [platform-type, platform-status, platform-posting-freq]
     - profileSlug: post
-      what: A first post or two already in motion, each placed on a pillar and a platform at its true status (Idea through Published).
+      what: A first post or two already in motion, each placed on a pillar and a platform at its true status (Idea through Published), and on a stage if the journey exists.
+      cardinality: few
+      keyFields: [post-status, post-pillar, post-platform]
+    - profileSlug: offer
+      what: >-
+        ONLY IF THEY SELL SOMETHING. Ask once; if they don't sell, or hedge,
+        create NOTHING here and drop the subject — a content engine with no
+        commercial axis is a complete result. If they do, capture what it is,
+        how it's priced, and who it's for.
       cardinality: few
-      keyFields: [post-status, post-format, post-platform]
+      keyFields: [offer-status, offer-summary, offer-price-model]
   openingQuestions:
     - "What are the 2–4 themes your audience comes to you for — the pillars everything you make ties back to?"
+    - "Most people have never named the journey, so I'll start you with three stages — doesn't know it's a problem, believes it's solvable, ready to act. Rename them to your world, or leave them and we'll come back to it."
     - "Which platforms do you actually publish on, and what cadence can you genuinely sustain on each?"
     - "Do you run (or want) a newsletter — the audience you own outright — and what's the first post you'd place in the system?"
+  # The BAR is deliberately unchanged: pillars, a platform with a cadence, and a
+  # first post. The journey is what makes the engine compound, but requiring it
+  # would make a perfectly good editorial workspace fail its own standard on day
+  # one. Mirrored verbatim by standards/content-os.standard.yaml — the journey
+  # layer lives in its `recommends`, not its `requires`.
   doneWhen: at least one pillar + one platform with a cadence + a first post placed on a pillar.