@synap-core/workspace-templates 0.11.0 → 0.23.0

package/src/content-os.yaml

@@ -2,9 +2,16 @@
 # The editorial engine — turn thinking into a published content system.
 # View-driven workspace (app: stored / entity-detail), modeled on marketing.yaml.
 #
-# This is the EDITORIAL half that used to be absorbed inside content-studio.yaml.
-# content-studio stays video/render-only; Content OS owns the publishing model:
-# posts, pillars, platforms, and newsletters.
+# Content OS is THE Content space — one space per domain (root CLAUDE.md, "One
+# space per domain"), so this ONE template carries every format: the editorial
+# model (posts, pillars, platforms, newsletters) AND the video/visual pipeline
+# (`content-composition`, `content-asset`, `render-job`, plus the shared
+# `brand-template` grant). The browser Content app (`CONTENT_KINDS` in
+# browser/.../apps/content/content-model.ts) reads all of them from this one
+# space — before this template declared them, "New video" failed with
+# `Profile not found: content-composition` on a pod with only Content OS.
+# content-studio.yaml was SUPERSEDED (its kinds were re-declared here verbatim)
+# and is retired into this template (retired.yaml, 2026-11-03).
 
 meta:
   slug: content-os
@@ -15,6 +22,34 @@ meta:
   color: "#6366F1"
   tags: [content, editorial, publishing, creator, newsletter]
   isPublic: true
+  # Onboarding start (meta.start): the "content" card.
+  start:
+    order: 2
+    label: Content
+    promise: Every post from idea to published, on one calendar.
+    suggestFor: [writer, creator, marketer, musician, photographer]
+    profile: post
+    views: [content-posts, content-calendar]
+    example:
+      - { title: "Why we left spreadsheets", values: { post-status: Idea, post-format: Article } }
+      - { title: "Three mistakes in our first launch", values: { post-status: Briefed, post-format: Thread } }
+      - { title: "Behind the scenes: build week", values: { post-status: "In Draft", post-format: "Short Video" } }
+      - { title: "Customer story: the Lyon bakery", values: { post-status: Review, post-format: Carousel } }
+      - { title: "Our pricing, explained", values: { post-status: Published, post-format: Article } }
+    firstSession:
+      title: Your content pipeline
+      goal: "Add the 3 to 5 posts you are working on now, each with a format and a status, and set a publish date on the next one."
+    starters:
+      - "I publish a weekly newsletter and a few social posts"
+      - "I make short videos for Instagram and YouTube"
+      - "I write articles to attract clients"
+  # What this space PRODUCES (homes): the purpose word, then its kinds/roles.
+  intent:
+    label: Content
+    produces:
+      - profile: post
+      - profile: newsletter
+      - profile: campaign
 
 # The editorial `post`/`newsletter` kinds REFERENCE profiles owned elsewhere:
 #   • `campaign` — the marketing-campaign template's kind. It ships pod-wide as a
@@ -53,6 +88,91 @@ dependencies:
     kind: workspace
     relation: require
     reason: "Provides the campaign kind (and its SSOT property body) this workspace's posts/newsletters link to."
+  # Same reason as foundation above, for the video pipeline: `brand-template` is
+  # Brand Library's pod-wide `scope: shared` kind and is re-declared below with
+  # only the properties used here. Requiring brand-library installs it FIRST, so
+  # its FULL body is the SSOT base and our subset never takes the pod-wide seat.
+  # It is also what the Produce Content playbook already reads (the brand kit,
+  # GET /api/hub/brand/kit). Brand is a separate domain, so this is a second
+  # space by design, not a second Content space.
+  - slug: brand-library
+    kind: workspace
+    relation: require
+    reason: "Provides the brand kit and the shared brand-template kind compositions start from."
+  # Bottom-up: the skill is its OWN standalone package (skills/creative-director.skill.json),
+  # published before this template, and installed here by slug. Resolved in Step 0 of
+  # materialization — BEFORE the skills linker — so the `skills:` link below finds a
+  # pod-wide approved row and reports `linked` rather than `unresolved`.
+  - slug: creative-director
+    kind: skill
+    relation: require
+    reason: "The creative director routes every content ask to the brand's approved brand-template, references and assets."
+  # Same bottom-up shape for the taste skill (skills/content-taste/): linked
+  # on-demand below, for the readiness gaps the director routes to it.
+  - slug: content-taste
+    kind: skill
+    relation: require
+    reason: "Turns references into approved guidelines and the asset kit a post is made from, when the readiness check finds them missing."
+  - slug: carousel-format
+    kind: skill
+    relation: require
+    reason: "The carousel module: hook slide, one idea per slide, text density, last-slide CTA, 4:5, slot use, built as a layered composition on the post."
+  # The edit loop (founder D0-D2, 2026-11-02): one contract every engine
+  # shares (the layer-<pass> slots, studio, needs-tool-<tool>, the three
+  # answers), and the Open Design engine for decks and PDF documents.
+  - slug: edit-loop
+    kind: skill
+    relation: require
+    reason: "The one edit-run contract every engine shares: pass slots, the three answers, a version before every pass, work from the diff."
+  - slug: open-design-edit
+    kind: skill
+    relation: require
+    reason: "Decks, PDF documents and presentations built in Open Design on the person's Mac, filed back to the pod."
+  # The video toolbox (founder decision 2026-10-13, pod decision "Video toolbox:
+  # one tool per job"): one routing skill plus one skill per job. Same bottom-up
+  # shape as the skills above: each is its own package under skills/, installed
+  # here and linked on-demand in `skills:` below.
+  - slug: video-toolbox
+    kind: skill
+    relation: require
+    reason: "Routes every video ask to the one tool for its job: HyperFrames to create, Cap + OpenChatCut to edit footage, ManimGX for math, fal.ai to generate."
+  - slug: video-direction
+    kind: skill
+    relation: require
+    reason: "Directs a short film from brief to delivery: story, treatment, look, sound, camera, delivery."
+  - slug: video-style-vocabulary
+    kind: skill
+    relation: require
+    reason: "43 visual styles and the per-film style sheet the build follows, under the brand's palette and fonts."
+  - slug: motion-quality-gates
+    kind: skill
+    relation: require
+    reason: "The checks a HyperFrames cut passes before anyone sees it: determinism, reading time, seams, loudness, rhythm."
+  - slug: math-explainer-manimgx
+    kind: skill
+    relation: require
+    reason: "Math, equation, graph and algorithm explainer clips with ManimGX, handed to HyperFrames as media."
+  - slug: facecam-edit
+    kind: skill
+    relation: require
+    reason: "Face-camera footage to a finished cut: transcript-based cuts, captions and graphics timed to speech, QA."
+  - slug: collage-broll
+    kind: skill
+    relation: require
+    reason: "Generated b-roll through fal.ai in three approval gates (idea, still, video), saved to the pod for reuse."
+
+# ── taskIntents — WHAT THIS WORKSPACE NEEDS TO FUNCTION ─────────────────────
+# Carried over from content-studio with the video pipeline it describes:
+# generate_media (the render), manage_file (zip / mp4 / stills land as pod
+# files), capture_into_pod (a finished render becomes pod entities),
+# search_external (asset gathering upstream of composition). A declaration, not
+# a snapshot of what is installed — validated by `validateTemplate`
+# (`task-intent-unknown`) and src/task-intents.test.ts.
+taskIntents:
+  - generate_media
+  - manage_file
+  - capture_into_pod
+  - search_external
 
 workspace:
   name: Content OS
@@ -69,18 +189,48 @@ workspace:
     - content.pillars
     - content.calendar
     - content.newsletter
+    # The video pipeline's family (`CONTENT_CAPABILITIES`, @synap-core/workspace-directory),
+    # carried over from content-studio. `content.pipeline` is the anchor the
+    # browser resolves a `workspaceType: content` scope against
+    # (useSurfaceReadiness `capabilityForKind`). `content.templates` is not
+    # claimed: templates are Brand Library's `brand-template` (brand.templates).
+    - content.pipeline
+    - content.compose
+    - content.render
+    - content.assets
   sourceRoles:
     brand: consumer
     marketing: consumer
     content: provider
 
 profiles:
+  # `post` is the ONE pod-wide post kind (`scope: shared`, the `platform`
+  # pattern below): Social re-declares it to get the grant instead of owning a
+  # `social-post` twin (folded in by the w11.post.* manifest ops, plan D2).
+  # Shares the DEFINITION, not the entities — no `entityScope: pod`.
   - slug: post
     displayName: Post
     icon: file-edit
     color: "#6366F1"
     description: "Your atomic content unit. One idea, multiple platform formats — tracked from spark to publication."
-    scope: WORKSPACE
+    scope: shared
+    # The ONE lifecycle (work model L1): every option's category.
+    lifecycle:
+      property: post-status
+      options:
+        - { key: Idea, category: open }
+        - { key: Briefed, category: active }
+        # Added 2026-10-12 (D4): the written version (script / outline) exists
+        # and waits for a person's approval before anything is generated.
+        - { key: Scripted, category: active }
+        - { key: "In Draft", category: active }
+        - { key: Review, category: active }
+        - { key: Scheduled, category: active }
+        - { key: Published, category: done }
+        - { key: Archived, category: lost, humanOnly: true }
+    # How it renders (entity rendering, decision 8): @synap-core/types/presentation.
+    presentation:
+      family: work
     properties:
       - slug: post-status
         label: Status
@@ -90,6 +240,7 @@ profiles:
           [
             "Idea",
             "Briefed",
+            "Scripted",
             "In Draft",
             "Review",
             "Scheduled",
@@ -113,6 +264,24 @@ profiles:
             "Podcast Episode",
             "Other",
           ]
+      # What the post is FOR — the axis that picks its narrative frame (an
+      # approved `content-guideline` of type=frame for this goal, Brand
+      # Library). Same enum as `guideline-goal`; never rename a value.
+      - slug: post-goal
+        label: Goal
+        valueType: string
+        inputType: select
+        enumValues:
+          [
+            "sell",
+            "hot-take",
+            "tutorial",
+            "product-demo",
+            "announcement",
+            "proof",
+            "behind-the-scenes",
+            "community",
+          ]
       - slug: post-platform
         label: Platform
         valueType: string
@@ -225,12 +394,177 @@ profiles:
         valueType: entity_id
         targetProfileSlug: post
         inputType: entity_select
+      # The person's own words, verbatim (B7). Stored by capture before it was
+      # declared; declared so it can be queried and validated.
+      - slug: content
+        label: Original words
+        description: "The person's own words, verbatim, in whatever language they were written."
+        valueType: string
+        inputType: textarea
       - slug: post-url
         label: Published URL
         valueType: string
         inputType: text
         placeholder: "https://..."
         constraints: { format: url }
+      # The publishing ACCOUNT (a `platform` entity) the post goes out on —
+      # distinct from `post-platform`, the network label above.
+      - slug: post-account
+        label: Account
+        valueType: entity_id
+        targetProfileSlug: platform
+        inputType: entity_select
+      # ── Publish outcome (plan D12) ─────────────────────────────────────────
+      # `failed` is what happened to a publish ATTEMPT, not a lifecycle stage:
+      # a post whose publish failed is still Scheduled (or wherever it was).
+      # `queued`: approved and armed, Publish due posts sends it on its day;
+      # `sending`: claimed by the send (the automation, or Content Studio's
+      # "Post now"), so it is never sent twice (decision A, 3 Nov);
+      # `waiting`: a repost armed at approval that waits for its original to
+      # go out (Publish due posts queues it then, with the original's id).
+      - slug: publish-outcome
+        label: Publish outcome
+        valueType: string
+        inputType: select
+        enumValues: [succeeded, failed, queued, sending, waiting]
+      - slug: publish-error
+        label: Publish error
+        valueType: string
+        inputType: textarea
+      - slug: published-at
+        label: Published At
+        valueType: date
+        inputType: date
+      # ── What goes out, frozen when the post is approved (decision A, 3 Nov) ──
+      # Approving a post (Review → Scheduled) freezes what "Publish due posts"
+      # sends on its day, so the automation never reads documents: the words,
+      # the Unipile account, the pictures, and the moment it may go.
+      - slug: publish-text
+        label: Words to send
+        description: "The approved caption or text, frozen when the post was approved. Publish due posts sends exactly this."
+        valueType: string
+        inputType: textarea
+      - slug: publish-account-id
+        label: Unipile account ID
+        description: "The Unipile account it goes out on, copied from its platform's unipile-account-id when it was approved."
+        valueType: string
+        inputType: text
+      - slug: publish-media
+        label: Files to send
+        description: "The pictures or video sent with it, as pod file ids in order (at most 10), frozen when it was approved."
+        valueType: array
+      # Epoch milliseconds: the automation's query compares properties
+      # numerically only, so the moment is a number (09:00 Europe/Paris on the
+      # publish date when Content Studio arms it).
+      - slug: publish-at-ms
+        label: Sends after (ms)
+        description: "The moment Publish due posts may send it, in milliseconds since 1970 (UTC)."
+        valueType: number
+        inputType: number
+      # ── Where it goes (accounts and destinations, founder 4 Nov, L9) ──────
+      # A post goes out on ONE account (`post-account`) and may also go out on
+      # others: the same post sent again from each account in `post-copy-to`,
+      # or a native repost of it from each account in `post-reshare-on`
+      # (LinkedIn only: Unipile's quoted_post_id; Instagram has no repost).
+      # Approving the post writes one post per extra account (`post-copy-of`
+      # pointing back here, `post-send-mode` copy | reshare), each with its own
+      # frozen send and its own outcome, so Publish due posts still sends one
+      # post per run and a failed repost never hides a sent original.
+      - slug: post-copy-to
+        label: Also posted on
+        description: "The other accounts (platform ids) that get the same post, sent again from each."
+        valueType: array
+      - slug: post-reshare-on
+        label: Reposted by
+        description: "The other accounts (platform ids) that repost it once it is out (LinkedIn)."
+        valueType: array
+      - slug: post-copy-of
+        label: Sent for
+        description: "The post this one sends again or reposts on another account."
+        valueType: entity_id
+        targetProfileSlug: post
+        inputType: entity_select
+      - slug: post-send-mode
+        label: Sent as
+        valueType: string
+        inputType: select
+        enumValues: [copy, reshare]
+      # Frozen with the rest at approval, for a LinkedIn company page: the
+      # page's id (its platform's linkedin-organization-id), sent as post_as.
+      - slug: publish-as-organization
+        label: Posts as page
+        description: "The LinkedIn company page it is posted as (Unipile post_as), frozen when it was approved."
+        valueType: string
+        inputType: text
+      # A repost's original, written when the original went out: Unipile's id
+      # of that post, sent as quoted_post_id.
+      - slug: publish-quote-id
+        label: Reposts post
+        description: "Unipile's id of the post this repost shares, written when the original went out."
+        valueType: string
+        inputType: text
+      # Unipile's id of this post once it is out (what a repost of it quotes).
+      - slug: publish-post-id
+        label: Unipile post ID
+        description: "Unipile's id of this post, written when it went out."
+        valueType: string
+        inputType: text
+      # ── Postiz (the `postiz` capability) ─────────────────────────────────
+      # The post's id in the person's Postiz, recorded when it is queued there
+      # (postiz_schedule_post returns it). Postiz's webhook finds the post by it.
+      - slug: postiz-post-id
+        label: Postiz post ID
+        valueType: string
+        inputType: text
+
+  # An idea is its OWN kind, not a post at Idea (founder decision B, 3 Nov
+  # 2026, review 22fec5ee): it has no format and no date, and "one idea feeds
+  # several posts, several ideas feed one post" is a relation, `idea --feeds-->
+  # post` (entityLinks below). Packaging ideas into posts is the "Package ideas"
+  # playbook. The posts at Idea that predate this kind convert through the
+  # backend conversions manifest, never by hand.
+  - slug: idea
+    displayName: Idea
+    icon: lightbulb
+    color: "#F59E0B"
+    description: "A spark worth keeping: a claim, a story or a question, in your own words. It feeds one or more posts."
+    # The ONE lifecycle (work model L1). Used = it feeds a post. No playbook
+    # binds this lifecycle, so no option is humanOnly (an agent's move into
+    # done or lost proposes anyway).
+    lifecycle:
+      property: idea-status
+      options:
+        - { key: New, category: open }
+        - { key: Shaped, category: active }
+        - { key: Used, category: done }
+        - { key: Dropped, category: lost, tone: textMuted }
+    properties:
+      - slug: idea-status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: ["New", "Shaped", "Used", "Dropped"]
+        constraints: { defaultValue: New }
+      # The person's own words, verbatim (same field as on `post`).
+      - slug: content
+        label: Original words
+        description: "The person's own words, verbatim, in whatever language they were written."
+        valueType: string
+        inputType: textarea
+      - slug: idea-pillar
+        label: Pillar
+        valueType: entity_id
+        targetProfileSlug: pillar
+        inputType: entity_select
+      - slug: idea-stage
+        label: Journey Stage
+        valueType: entity_id
+        targetProfileSlug: journey-stage
+        inputType: entity_select
+      # Where it came from (`source:dump`, `source:interview`, …), as on `post-tags`.
+      - slug: idea-tags
+        label: Tags
+        valueType: array
 
   - slug: pillar
     displayName: Pillar
@@ -495,6 +829,42 @@ profiles:
       - slug: platform-tags
         label: Tags
         valueType: array
+      # ── Postiz channel (the `postiz` capability) ─────────────────────────
+      # Which Postiz channel this account is, both read from
+      # postiz_list_integrations: its id, and its provider (the `identifier`
+      # a post's `settings.__type` names: x, linkedin, instagram…). A post
+      # queued on this account passes both to postiz_schedule_post.
+      - slug: postiz-integration-id
+        label: Postiz channel ID
+        valueType: string
+        inputType: text
+      - slug: postiz-provider
+        label: Postiz provider
+        valueType: string
+        inputType: text
+      # The Unipile account this platform posts from (unipile_list_accounts
+      # `id`, e.g. acc_…): copied onto a post as publish-account-id when it is
+      # approved, so Publish due posts sends it from this account.
+      - slug: unipile-account-id
+        label: Unipile account ID
+        valueType: string
+        inputType: text
+      # Whose account it is (founder, 4 Nov): one row per account, so a
+      # network can hold a personal and a company account side by side. A new
+      # post goes to the personal account of its network by default.
+      - slug: account-owner
+        label: Owner
+        valueType: string
+        inputType: select
+        enumValues: [Personal, Company]
+      # A LinkedIn company page posts through the personal account that
+      # administers it: same unipile-account-id, plus the page's id here
+      # (linkedin_list_company_pages), copied onto a post as
+      # publish-as-organization and sent as Unipile's post_as.
+      - slug: linkedin-organization-id
+        label: LinkedIn page ID
+        valueType: string
+        inputType: text
 
   - slug: newsletter
     displayName: Newsletter
@@ -502,6 +872,16 @@ profiles:
     color: "#10B981"
     description: "A newsletter issue — your direct channel to an owned audience. No algorithm, no platform fee, no intermediary."
     scope: WORKSPACE
+    # The ONE lifecycle (work model L1): every option's category.
+    lifecycle:
+      property: newsletter-status
+      options:
+        - { key: Idea, category: open }
+        - { key: Drafting, category: active }
+        - { key: Editing, category: active }
+        - { key: Scheduled, category: active }
+        - { key: Sent, category: done }
+        - { key: Archived, category: lost, humanOnly: true }
     properties:
       - slug: newsletter-status
         label: Status
@@ -578,6 +958,15 @@ profiles:
     color: pink
     description: "A marketing campaign — email, social, event, content, or partnership"
     semanticSlug: marketing.campaign
+    # The ONE lifecycle (work model L1): every option's category.
+    lifecycle:
+      property: campaign-status
+      options:
+        - { key: planning, category: open }
+        - { key: active, category: active }
+        - { key: paused, category: paused, humanOnly: true }
+        - { key: completed, category: done }
+        - { key: cancelled, category: lost, humanOnly: true }
     properties:
       - slug: campaign-status
         label: Status
@@ -627,7 +1016,7 @@ profiles:
       # `campaign-channel` (the delivery medium). scoping/outreach/live have no
       # channel equivalent, so folding them into `campaign-channel` would lose
       # them — they get their own def. Kept verbatim across the three campaign
-      # declarations (business-developer / marketing / here) so there is no drift.
+      # declarations (crm / marketing / here) so there is no drift.
       - slug: campaign-type
         label: Type
         valueType: string
@@ -793,6 +1182,30 @@ profiles:
           - usage-based
           - free
           - other
+      # "Starting at" list price. The deal/contract stays authoritative for what
+      # a buyer actually pays; these three only answer "what do we advertise".
+      - slug: offer-list-price
+        label: Starting at
+        valueType: number
+        inputType: number
+        placeholder: "List price, before any negotiation"
+      - slug: offer-currency
+        label: Currency
+        valueType: string
+        inputType: select
+        enumValues:
+          - EUR
+          - USD
+          - GBP
+          - CHF
+        constraints: { defaultValue: EUR }
+      - slug: offer-billing
+        label: Billing
+        valueType: string
+        inputType: select
+        enumValues:
+          - one-off
+          - monthly
       - slug: offer-audience
         label: Audience
         valueType: entity_id
@@ -804,6 +1217,334 @@ profiles:
         targetProfileSlug: positioning
         inputType: entity_select
 
+  # ── The video / visual pipeline (moved from content-studio.yaml) ──────────
+  # HyperFrames-first: a composition IS a HyperFrames project — brief +
+  # storyboard documents, the project zip, the rendered MP4 and its key-frame
+  # stills, and the hash of the brand kit it was made with. Remotion is RETIRED
+  # (Content x Brand plan, 2026-10-05); live rows are retired through
+  # conversions/manifest.ts (`w11.content.*`), never by dropping a field here
+  # (the reconciler is ADD-ONLY).
+  #
+  # SCOPE: workspace (omitted), exactly as content-studio declared them. Only
+  # the ONE Content space uses these kinds, and `shared` would bind the whole
+  # corpus to this body forever (the shared-kind SSOT rule) — the one-way door
+  # the `journey-stage` note above declines for the same reason. Bodies are
+  # VERBATIM from content-studio.yaml so a pod that ever installed it converges
+  # on one body (same-actor reuse in resolve-profile-for-apply.ts), no drift.
+  # `recipe-ref` / `composition-ref` stay free text verbatim: a pod's live rows
+  # carry them, and `composition-ref` is what the Content app joins renders on.
+  # `recipe-ref` was `pipeline-ref` until 2026-10-11 ("pipeline" is now only the
+  # view); live rows move via conversions `w12.content.pipeline-ref-to-recipe-ref`.
+  - slug: content-composition
+    displayName: Composition
+    icon: clapperboard
+    color: blue
+    description: "A HyperFrames project: brief + storyboard, the project zip, the rendered MP4, its key-frame stills, and the brand kit it used."
+    semanticSlug: content.composition
+    # How it renders (entity rendering, decision 8): @synap-core/types/presentation.
+    presentation:
+      family: document
+    properties:
+      - slug: composition-id
+        label: Composition ID
+        valueType: string
+        inputType: text
+        description: Internal id for this composition record.
+      # HyperFrames renders video; `layered` is a carousel / image built as a
+      # layered composition in the pod, `open-design` a deck or PDF document
+      # built in Open Design (founder D1, 2 Nov; skills carousel-format and
+      # open-design-edit). `remotion` / `hybrid` are retired (reconcile is
+      # add-only — live enums keep them until retired by hand).
+      - slug: render-engine
+        label: Render engine
+        valueType: string
+        inputType: select
+        enumValues: [hyperframes, layered, open-design]
+        constraints: { defaultValue: hyperframes }
+      - slug: aspect-ratio
+        label: Aspect Ratio
+        valueType: string
+        inputType: select
+        enumValues: ["9:16", "16:9", "1:1", "4:5"]
+        constraints: { defaultValue: "16:9" }
+      - slug: duration-seconds
+        label: Duration (seconds)
+        valueType: number
+        inputType: number
+      # The HyperFrames workflow's own documents (pod document ids, the same
+      # spelling Brand Library uses for `asset-document-id`).
+      - slug: brief-document-id
+        label: Brief
+        valueType: string
+        inputType: text
+        description: Document id of the creative brief.
+      - slug: storyboard-document-id
+        label: Storyboard
+        valueType: string
+        inputType: text
+        description: Document id of the storyboard / script.
+      # Outputs are pod FILES (uploaded through the one upload door), linked
+      # so each is a door to its own page.
+      - slug: project-zip
+        label: Project (zip)
+        valueType: entity_id
+        targetProfileSlug: file
+        inputType: entity_select
+        description: The HyperFrames project folder, zipped — "edit as code".
+      - slug: render-mp4
+        label: Render (MP4)
+        valueType: entity_id
+        targetProfileSlug: file
+        inputType: entity_select
+        description: The rendered video.
+      - slug: key-frame-stills
+        label: Key-frame stills
+        valueType: array
+        description: File entity ids of key-frame stills — what relay approves from.
+      - slug: brand-kit-hash
+        label: Brand kit hash
+        valueType: string
+        inputType: text
+        description: Content hash of the brand kit export this was made with (GET /api/hub/brand/kit). A different current hash = stale brand.
+      - slug: hyperframes-meta
+        label: HyperFrames JSON
+        valueType: string
+        inputType: textarea
+      - slug: composition-template
+        label: Template
+        valueType: entity_id
+        targetProfileSlug: brand-template
+        inputType: entity_select
+        description: The reusable brand-template shell this started from.
+      - slug: recipe-ref
+        label: Recipe
+        valueType: string
+        inputType: text
+
+  - slug: content-asset
+    displayName: Asset
+    icon: image
+    color: green
+    description: "Media asset: image, video clip, audio track, font, or script."
+    semanticSlug: content.asset
+    # How it renders (entity rendering, decision 8): @synap-core/types/presentation.
+    presentation:
+      family: media
+      media:
+        source: { property: document-id }
+    properties:
+      # `recording` (D1, 29 Oct): a TAKE recorded in Content Studio's booth, or
+      # a PIECE cut from one into its own new file (D2). A piece is told apart
+      # by `source-take`; one Kind keeps one player and one transcript door.
+      - slug: asset-kind
+        label: Kind
+        valueType: string
+        inputType: select
+        enumValues: [image, video, audio, font, script, recording, other]
+      - slug: source-kind
+        label: Source
+        valueType: string
+        inputType: select
+        enumValues: [uploaded, brand, generated]
+        constraints: { defaultValue: uploaded }
+      - slug: source-url
+        label: URL
+        valueType: string
+        inputType: url
+      - slug: brand-asset-ref
+        label: Brand Asset Ref
+        valueType: string
+        inputType: text
+      - slug: file-id
+        label: File ID
+        valueType: string
+        inputType: text
+      - slug: document-id
+        label: Document ID
+        valueType: string
+        inputType: text
+      # ── A recording: a take, or a piece cut from one (D1, D2, 29 Oct) ──────
+      # `file-id` is the raw take's file, or the piece's OWN new file. The raw
+      # take is never overwritten. The facts come from the device that
+      # recorded it (a browser WebM carries no duration), else from ffprobe.
+      - slug: duration-seconds
+        label: Duration (seconds)
+        valueType: number
+        inputType: number
+      - slug: frame-width
+        label: Width (px)
+        valueType: number
+        inputType: number
+      - slug: frame-height
+        label: Height (px)
+        valueType: number
+        inputType: number
+      - slug: frame-rate
+        label: Frame rate (fps)
+        valueType: number
+        inputType: number
+      - slug: recorded-at
+        label: Recorded at
+        valueType: date
+        inputType: date
+      - slug: poster-file-id
+        label: Poster
+        valueType: string
+        inputType: text
+        description: File id of one still frame of the recording.
+      # The take's own facts. The week is derived from `recorded-at`.
+      - slug: take-kind
+        label: Take
+        valueType: string
+        inputType: select
+        enumValues: [answer, free]
+        description: "answer: it answers an interview question; free: a free take."
+      - slug: take-topic
+        label: Question or topic
+        valueType: string
+        inputType: text
+        description: The question the take answers, or the free take's topic.
+      - slug: take-look
+        label: Look (JSON)
+        valueType: string
+        inputType: textarea
+        description: 'The look picked in the booth before recording, the JSON Produce Content takes as its look param: {"background": …, "colour": …}.'
+      # A piece's lineage (G12). Seconds are in the TAKE's time.
+      - slug: source-take
+        label: Cut from take
+        valueType: entity_id
+        targetProfileSlug: content-asset
+        inputType: entity_select
+      - slug: source-start
+        label: Starts at (s)
+        valueType: number
+        inputType: number
+      - slug: source-end
+        label: Ends at (s)
+        valueType: number
+        inputType: number
+      - slug: piece-hook
+        label: Hook
+        valueType: string
+        inputType: text
+        description: The piece's opening line, in the person's exact words.
+      - slug: piece-format
+        label: Suggested format
+        valueType: string
+        inputType: select
+        enumValues: ["Short Video", "Long Video"]
+      # A re-cut is a NEW file: `file-id` moves to it and the old file id is
+      # appended here, oldest first. Nothing is deleted.
+      - slug: earlier-file-ids
+        label: Earlier cuts
+        valueType: array
+        description: File ids of this piece's earlier cuts, oldest first.
+
+  - slug: render-job
+    displayName: Render Job
+    icon: play
+    color: amber
+    description: "One render run of a composition — on the user's own agent (HyperFrames, local) — queued, rendering, done, or failed."
+    semanticSlug: content.render
+    # How it renders (entity rendering, decision 8): @synap-core/types/presentation.
+    presentation:
+      family: media
+      media:
+        source: { entityRef: output-file }
+    properties:
+      - slug: job-status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: [queued, rendering, done, failed]
+        constraints: { defaultValue: queued }
+      - slug: render-progress
+        label: Progress (%)
+        valueType: number
+        inputType: number
+        description: 0-100 while rendering, when the agent reports it.
+      - slug: output-format
+        label: Format
+        valueType: string
+        inputType: select
+        enumValues: [mp4, gif, webm, mp3, pdf, png, pptx]
+        constraints: { defaultValue: mp4 }
+      - slug: output-file
+        label: Output
+        valueType: entity_id
+        targetProfileSlug: file
+        inputType: entity_select
+      - slug: output-url
+        label: Output URL
+        valueType: string
+        inputType: url
+      - slug: render-duration-ms
+        label: Render Duration (ms)
+        valueType: number
+        inputType: number
+      - slug: error-message
+        label: Error
+        valueType: string
+        inputType: textarea
+      - slug: composition-ref
+        label: Composition
+        valueType: string
+        inputType: text
+
+  # ── brand-template (shared SSOT is brand-library.yaml) ──────────────────
+  # RE-DECLARED, not owned — and not twinned: `scope: shared` dedups to Brand
+  # Library's ONE pod-wide row (installed first by the `require: brand-library`
+  # dependency). The declaration is what writes THIS workspace's
+  # `profile_workspace_access` grant; without it `composition-template`'s
+  # `targetProfileSlug: brand-template` resolves to a NULL target (see the meta
+  # header). Only the properties this workspace uses are re-declared (as the
+  # retired content-studio did); bodies must match brand-library's (guarded
+  # by shared-role-ssot.test.ts).
+  - slug: brand-template
+    displayName: Brand Template
+    icon: layout-template
+    color: pink
+    description: Reusable output template for artboards, decks, carousels, banners, documents, video, or generated HTML.
+    semanticSlug: brand.template
+    scope: shared
+    # MIRROR of brand-library's lifecycle — every declaration of a shared kind's
+    # lifecycle must be identical (validate: lifecycle-diverges).
+    lifecycle:
+      property: template-status
+      options:
+        - { key: draft, category: open }
+        - { key: approved, category: done }
+        - { key: deprecated, category: lost }
+    # How it renders (entity rendering, decision 8): @synap-core/types/presentation.
+    presentation:
+      family: document
+    properties:
+      - slug: template-kind
+        label: Kind
+        valueType: string
+        inputType: select
+        enumValues:
+          [artboard, deck, carousel, banner, document, html, social, video, other]
+      - slug: template-status
+        label: Status
+        valueType: string
+        inputType: select
+        enumValues: [draft, approved, deprecated]
+        constraints: { defaultValue: draft }
+      # `layered` = a carousel / image built as a layered composition in the
+      # pod, `open-design` = a deck or PDF document built in Open Design: the
+      # words content-os `render-engine` uses (static edit loop, founder D1,
+      # 2 Nov 2026). Additive only: the reconciler never drops a value.
+      - slug: template-format
+        label: Format
+        valueType: string
+        inputType: select
+        enumValues: [tldraw, html, json, markdown, image, mixed, hyperframes, layered, open-design]
+      - slug: template-config
+        label: Config JSON
+        valueType: string
+        inputType: textarea
+
 # CURATED views — the editorial spine
 views:
   - name: Posts
@@ -886,11 +1627,34 @@ views:
     type: list
     scopeProfileSlug: series
     description: The curriculums you're running — each an ordered arc through one pillar.
+  # The video / visual pipeline (moved from content-studio.yaml). Not in the
+  # sidebar: the Content home (`content-home`) is where videos are made and
+  # read; these are the raw collections behind it. No Templates view — the
+  # templates live in Brand Library's own Templates view (one owner).
+  - name: Compositions
+    slug: content-compositions
+    type: grid
+    scopeProfileSlug: content-composition
+    description: Video compositions ready for rendering.
+  - name: Assets
+    slug: content-assets
+    type: grid
+    scopeProfileSlug: content-asset
+    description: Media assets uploaded or generated.
+  - name: Render Jobs
+    slug: render-jobs
+    type: table
+    scopeProfileSlug: render-job
+    description: Render queue and history.
 
-# App reference — view-driven, no custom app (mirrors marketing.yaml)
+# The workspace HOME is THE Content surface (plan W5, founder D1 + D11 — the
+# CRM precedent): the `content-home` cell, the lens page at this space's scope
+# (Needs you · Happening · Produced · Data with the coverage map). The same
+# cell is content-studio's home, so the two templates share ONE surface.
 app:
   kind: stored
-  cellKey: entity-detail
+  cellKey: content-home
+  title: Content
 
 # Layout config for browser sidebar
 layout:
@@ -929,8 +1693,8 @@ layout:
       label: Newsletters
       icon: mail
 
-# 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).
+# Bento dashboard — the space's editable DASHBOARD (pinned `dashboard`). The
+# landing surface is the `content-home` cell above (app:), not this bento.
 # 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
@@ -1004,58 +1768,1027 @@ entityLinks:
     targetProfileSlug: post
     type: derived_from
     label: Repurposed From
+  # Many-to-many: one idea feeds several posts, several ideas feed one post
+  # (decision B). The "Package ideas" playbook writes it.
+  - sourceProfileSlug: idea
+    targetProfileSlug: post
+    type: feeds
+    label: Feeds
+  - sourceProfileSlug: idea
+    targetProfileSlug: pillar
+    type: belongs_to_pillar
+    label: Pillar
+  # The video pipeline edges (moved from content-studio.yaml). content-studio's
+  # `made_with_recipe` edge is NOT carried: its recipe kind was folded into
+  # Brand Library's `brand-template` (decision D2, 2026-10-12), which the
+  # composition already names through `composition-template`. The `post` is
+  # this space's unit of work, and Produce Content already says to "record a
+  # content-composition linked to this post" — so the composition points at its
+  # post instead.
+  - sourceProfileSlug: content-composition
+    targetProfileSlug: post
+    type: made_for
+    label: Post
+  - sourceProfileSlug: render-job
+    targetProfileSlug: content-composition
+    type: renders
+    label: Composition
+  - sourceProfileSlug: content-asset
+    targetProfileSlug: render-job
+    type: used_in
+    label: Render Job
+  - sourceProfileSlug: content-asset
+    targetProfileSlug: content-composition
+    type: used_in
+    label: Composition
 
 # Playbooks — session templates seeded with the workspace.
-# `subjectProfile` binds this playbook to the `post` kind so the Capture → Session
-# matcher (playbooks.subject_profile->>'profileSlug') can offer it when a post is
-# captured. The captured post is passed as the `post` entity param and substituted
-# into the goalTemplate; the agent carries it from raw idea to a scheduled draft.
+# `subjectProfile` binds a playbook to a kind so the Capture → Session matcher
+# (playbooks.subject_profile->>'profileSlug') can offer it when one is captured.
+#
+# THE PROCESS CONTRACT (lifecycle-bound playbooks). `subjectProfile.statusProperty`
+# names the kind's lifecycle select (`post-status`); each stage's `subjectStatus`
+# is the value that stage IS — advancing into the stage writes it to the subject
+# (governed), and the subject entering it advances an open run to the stage.
+# `humanOnlyStatuses` lists the values no stage owns because a person sets them.
+# `activators` are DECLARATIONS the pod compiles into governed propose-mode rules
+# at install — never hand-written `automations:`. `relationToSubject` is the edge
+# written output → subject when a slot is satisfied. Validated by validate.ts
+# (`checkProcessContract`) and lifecycle-coverage.test.ts.
 playbooks:
   - name: Produce Content
-    description: Take a captured post idea and carry it from spark to a scheduled, platform-ready draft.
+    # ONE playbook for every format (plan W3.3): text / visual / video are
+    # BRANCHES of it, not sibling playbooks — never a second top-level
+    # "Produce video". Its only home is this template (decision D6: the
+    # content-idea-to-production capability no longer carries a copy).
+    description: Take a briefed post from brief to script to published in any format — text, visual or video (HyperFrames) — from the pod's brand kit, one stage per post status, with a person approving the script before anything is generated.
     goalTemplate: >-
-      Produce content for {platform} from this idea ({post}). Take the raw idea,
-      shape it into a {format} draft with a scroll-stopping hook and a clear CTA,
-      keep it aligned to the post's pillar and the operator's brand voice, then
-      move it to Scheduled with a publish date.
+      Produce content for {platform} from this idea ({post}) in the {format} format.
+      Read the brand first from the pod's brand kit (GET /api/hub/brand/kit) — never
+      re-derive it from a website capture — and load the creative-director skill
+      (linked to this space) to pick the approved brand-template (layout and
+      recipe), references and assets for this format and style; drafts never feed
+      generation. Work the stages in order; each stage moves the post's status.
+      SCRIPT before anything is made: write the script or outline for the format
+      (carousel slide outline, deck outline, video script and storyboard, or the
+      text draft) by filling the narrative frame for the post's goal — the
+      approved content-guideline of type frame for that goal, else the default
+      frame (sell: story, example, lesson, link; hot-take: claim, tension, reason,
+      invitation; tutorial: promise, steps, result, next; product-demo: problem,
+      real screen, outcome, try it). A person approves the script before the
+      draft; nothing is generated from an unapproved script. At the draft, run the
+      creative-director readiness check first (approved references, an approved
+      base guideline, an approved brand-template for this format); if anything is
+      missing, stop and route to the content-taste skill or brand onboarding
+      instead of improvising. Then branch on the format. TEXT
+      (article, thread, newsletter section, caption): draft it with a
+      scroll-stopping hook and a clear CTA. VISUAL: build it pass by pass through
+      the edit-loop skill, a person answering each pass — a carousel, LinkedIn
+      PDF or image post as a layered composition saved on the post
+      (carousel-format), a deck, PDF document or presentation in Open Design
+      (open-design-edit). VIDEO (short or
+      long video): first pick the route — FROM SCRATCH (script, storyboard,
+      frames), FROM A VOICE (an existing voice-over or talk: transcribe it, cut on
+      its beats, build the frames under it) or RE-EDIT (existing footage plus a
+      voice: cut, caption, add music and motion); takes ({takes}) mean RE-EDIT,
+      and the Draft stage says how takes, transcripts and passes are handled.
+      Then run the HyperFrames
+      workflow on your own agent with HYPERFRAMES_NO_TELEMETRY=1, from the kit's
+      frame.md (format=frame-md), with GSAP vendored locally — never `hyperframes
+      publish`, never a cloud render. For a visual or video format, record a
+      content-composition made for this post (for a video: the brief and storyboard
+      documents, the project zip, the MP4, key-frame stills and the brand-kit hash).
+      Keep every format on the post's pillar and the brand voice. A human approves
+      the script before the draft, each pass as it is built, and the
+      draft on the preview at Review. At
+      Schedule, a post whose account is a Postiz channel is queued through the
+      capability that serves publish_post (postiz_schedule_post); that queueing is
+      itself a proposal a person approves. Nothing publishes itself, and the post
+      reads Published only once it went live: reported by Postiz, or confirmed
+      by a person at Publish.
     subjectProfile:
       profileSlug: post
+      statusProperty: post-status
+    # Idea is where a capture lands and Archived is a person's call — no stage
+    # owns either. The activator below starts the run once the post is Briefed.
+    humanOnlyStatuses: [Idea, Archived]
+    activators:
+      - { on: enters_status, status: Briefed, mode: propose }
     params:
       - { name: post, type: entity, label: Post, required: true }
       - { name: platform, type: text, label: Platform, required: true }
       - { name: format, type: text, label: Format }
+      # Recorded footage, as `file` entity ids (comma-separated). A TEXT param,
+      # not `type: entity`: the pod's param contract has no list and no kind
+      # filter (`PlaybookParamType`, @synap/playbooks), and the reader drops any
+      # other key without a word, so "entity, file, multi" cannot be declared.
+      # Present → the video route is RE-EDIT.
+      - { name: takes, type: text, label: Takes (file ids) }
+      # The look picked in Content Studio's booth before recording (founder,
+      # 2026-10-28), as ONE JSON string: {"background": {"assetId","fileId"} |
+      # {"mode":"blur"} | null, "colour": {"assetId","fileId","intensity"} |
+      # null}. A TEXT param for the same reason as `takes`: the param contract
+      # has no object type, and a `text` value must be a string. Content Studio
+      # sends it only to a process that declares it. Present → the Background
+      # and Colour passes start from it; absent → they are built as before.
+      - { name: look, type: text, label: Look (JSON) }
     executor: is-agent
     status: active
+    # What the process needs the pod to be able to do. Schedule queues the post
+    # through whatever serves publish_post (the `postiz` capability's
+    # postiz_schedule_post); a pod with nothing serving it reports the gap.
+    requiredIntents: [publish_post]
+    inputStrategy:
+      kind: pinned
+      fallback:
+        filter:
+          post-status: Idea
+        orderBy: createdAt
+        orderDir: asc
+    stages:
+      - key: brief
+        name: Brief
+        category: planned
+        subjectStatus: Briefed
+        # A run is BORN at its first stage, and nothing writes a stage's status
+        # at birth (finding f36420d5: the pilot post stayed at Idea while its
+        # run reached Draft). Said here, not only in goalTemplate: a template
+        # update leaves an owner-edited goal alone.
+        goal: >-
+          Pin down the post's angle, platform, format, pillar and journey stage
+          before anything is drafted. A run starts at this stage without moving
+          the post: if the post still reads Idea, move it to Briefed first
+          (synap_update_entity, post-status Briefed, expectedStatus Idea). Then
+          advance the run through every stage in order (currentStage), never
+          skipping one, takes included: entering a stage moves the post to its
+          status, and a reply that says proposed is success.
+        criteria:
+          - key: brief-has-hook
+            statement: The post has a hook or headline that states its one idea.
+            check: { kind: judge }
+          # One criterion for the whole placement (format, platform, pillar,
+          # goal): the playbook sits at MAX_SESSION_CRITERIA (12) and the
+          # script stage needed two.
+          - key: brief-has-format-platform
+            statement: The post's format, platform, pillar and goal are set.
+            check: { kind: judge }
+      # The written version, before anything is generated (D4, 2026-10-12).
+      - key: script
+        name: Script
+        category: started
+        subjectStatus: Scripted
+        goal: >-
+          Write the script or outline for the post's format — carousel slide
+          outline, deck outline, video script and storyboard, or the text draft —
+          by filling the narrative frame for the post's goal (the approved
+          content-guideline of type frame for that goal, else the default frame).
+          With takes (the RE-EDIT route), the script is the cut plan: what is
+          kept of the takes' words, in order, and why (the facecam-edit skill's
+          plan), so the person approves the cut before any pass is built.
+        expectedOutputs:
+          # A pod document. `relates_to` is the default relation (base.yaml):
+          # the composition's brief/storyboard documents are stored as ids on
+          # the composition, not as an edge, so there is no narrower one to reuse.
+          - kind: document
+            label: Script
+            relationToSubject: relates_to
+        criteria:
+          - key: script-follows-frame
+            statement: The script follows the narrative frame for the post's goal and ends on its call to action.
+            check: { kind: judge }
+          - key: script-fits-format
+            statement: The script is shaped for the post's format (slides, scenes or sections) and the platform's limits.
+            check: { kind: judge }
+      - key: draft
+        name: Draft
+        category: started
+        subjectStatus: In Draft
+        # Per-pass approval (founder D3, 2026-10-27): ONE person-owned slot per
+        # video pass, NOT a stage per pass (stages move post-status, and the
+        # post lifecycle has no per-pass status). The slots are declared by
+        # the agent as each pass's preview exists, never here in
+        # `expectedOutputs`: a stage's slots are all owed on entry, by every
+        # format (a text post would owe five video approvals, and the person
+        # would be asked before anything is built), and an `optional` slot is
+        # owed by nobody and cannot be turned owed again through the agent's
+        # outcome door. The slot shape is fixed in the edit-loop skill (one
+        # contract for every engine, 2 Nov) and named here, so every run asks
+        # the same questions. Takes and transcripts are spelled here too,
+        # not only in `goalTemplate`: a template update merges field by field
+        # and leaves a field the owner edited alone (`threeWayMergeFields`), so
+        # an install whose goal was edited on the pod still receives `stages`.
+        # The pod caps a stage goal at 5,000 characters (backend
+        # `playbook-stage.ts`); over it every install and update of Content OS
+        # is refused (2026-11-02), and the catalog validator now refuses it too.
+        goal: >-
+          Entering Draft waits on the person: this stage's gate asks them to
+          approve the script, and that approval moves the post to In Draft.
+          Build nothing before it passes.
+          Run the creative-director readiness check, then produce the draft in
+          the post's format from the approved script, the brand kit and the
+          approved brand-template (layout and recipe) for the format. A visual
+          or video format is built pass by pass through the edit-loop skill and
+          its engine's skill: carousel, LinkedIn PDF or image post, a layered
+          composition saved on the post (carousel-format; passes
+          layer-structure, layer-visual, layer-polish, an image the last two);
+          deck, PDF document or presentation, Open Design (open-design-edit,
+          same passes); video, HyperFrames.
+          Takes given (the
+          run's takes param, on the run session at metadata.params.takes:
+          comma-separated file ids of recorded footage) mean the RE-EDIT video
+          route, with the facecam-edit skill. A take's transcript is ONE
+          content-asset, Kind script, whose File ID is the take's file; its
+          body holds the readable text under a "## Transcript" heading, then a
+          "## Words" heading followed by exactly one ```json fenced block with
+          the word-level JSON in HyperFrames' shape [{"text","start","end"}]
+          (seconds; [] until the precise pass fills it). Find it before transcribing: if it exists, reuse
+          it and only fill the word timings; if not, create it and link it to
+          the take's file with a references relation. Never a separate
+          document per take.
+          A VIDEO is built in passes, in this order, each one non-destructive (changing a pass never
+          redoes an approved one): cut and order, background, colour,
+          captions, graphics and animation. Skip a pass the route does not
+          use. A run started in the older order builds the passes it has not done in this
+          order, background first.
+          When a pass starts, declare its slot as yours first (an outcome with
+          the pass's key, kind file, no owner, no ask). After each pass, render
+          its preview into the pod and hand the person ONE slot for it (an
+          outcome) on the same key, layer-<pass> (a video: layer-cut,
+          layer-background, layer-colour, layer-captions or layer-graphics):
+          owner human, ref the preview, ask choose with allowOther, options
+          Approve (recommended), Rework and Use my edit, answered as the
+          edit-loop skill spells out (Approve claims the slot: completeOutput).
+          Build the next pass only after the answer. Use my edit: their edit is
+          the pass; never overwrite or redo their changes. Before each of your
+          passes record a version, work from the diff to the current work (never
+          regenerate from the prompt), never write while a pass is the person's,
+          and acknowledge each answer in the room.
+          With takes, every pass is built in ONE HyperFrames project, the folder
+          edit in the run's work folder (~/synap-work/<this run's session
+          id>/edit), shown live in HyperFrames Studio, whose address is the
+          run's studio outcome, retired (retireOutput studio) whenever Studio
+          stops, as the facecam-edit skill spells out.
+          Every render the person hears, a preview included, carries the cut's
+          audio copied (a remux, never the render's own encode), and a
+          re-encode for size touches the video only, as the facecam-edit skill
+          spells out.
+          A LOOK given (the run's look param, at metadata.params.look: a JSON
+          string {"background": {"assetId","fileId"} or {"mode":"blur"} or
+          null, "colour": {"assetId","fileId","intensity"} or null}, picked in
+          the booth before recording) means the Background pass and the Colour
+          pass START from it, as the facecam-edit skill spells out. Background:
+          matte the person from the raw take with the person's edit_video tool
+          (synap_list_capabilities with intent edit_video), handing it the
+          take's pod file id ({"videoFile": id}; the pod signs it at run
+          time); gate the matte (its frame
+          count and duration match the take, no flicker); defocus the
+          background once; composite with ffmpeg (choke, feather, light wrap);
+          then grain on the background and a light match on the person. The
+          background is the background file (downloaded from the pod by its
+          fileId), or, for mode blur, a blurred copy of the raw take. No edit_video tool, a failed run or a failed gate: matte with
+          npx hyperframes remove-background instead and composite the same way
+          over the same background; that failing
+          too: the raw take, and the pass's question says "background not
+          applied". Colour: download the
+          .cube by its fileId and apply it as the grading block grading.lut
+          (src the .cube, intensity the look's intensity). Each is still its
+          own pass, with its own slot (layer-background, layer-colour) and its
+          own question, asked like every other pass; for these two the options
+          add Remove this pass (the raw take shows through: drop the pass,
+          retire its slot with retireOutput, build the next). A null part of
+          the look leaves its pass as it is without a look. The raw take is
+          never overwritten: a pass writes new files beside it.
+        # A person approves the written version before any generation: the
+        # gate holds In Draft until it passes, and a rejection sends the run
+        # back to rework the script.
+        gate: { kind: human }
+        onFail: { toStage: script }
+        expectedOutputs:
+          # Visual and video formats only: a text draft lives on the post itself.
+          - kind: content-composition
+            label: Composition (visual or video formats)
+            relationToSubject: made_for
+        criteria:
+          - key: draft-brand-kit-read
+            statement: The draft was built from the pod's brand kit and the approved brand-template for its format, not a re-derived brand.
+            check: { kind: judge }
+          - key: draft-matches-format
+            statement: The draft follows the approved script, is in the post's format and fits the platform's constraints.
+            check: { kind: judge }
+      - key: review
+        name: Review
+        category: started
+        subjectStatus: Review
+        goal: Put the draft in front of a person on the preview, with a proposed publish date.
+        gate: { kind: human }
+        onFail: { toStage: draft }
+        criteria:
+          - key: review-date-proposed
+            statement: A publish date is proposed.
+            check: { kind: judge }
+          - key: review-approved
+            statement: A person approved the draft.
+            check: { kind: human }
+      - key: schedule
+        name: Schedule
+        category: started
+        subjectStatus: Scheduled
+        goal: >-
+          Set the publish date and queue the post on its account: its
+          post-account, else the Personal account (account-owner) of its
+          network (founder, 4 Nov). When that platform carries
+          unipile-account-id (Unipile, the default; decision A, 3 Nov:
+          approving is the yes, nothing asks again), arm it for Publish due
+          posts in one write: post-account set to that platform,
+          publish-account-id to its unipile-account-id,
+          publish-as-organization to its linkedin-organization-id when it is
+          a LinkedIn company page, publish-text to the approved caption or
+          text, publish-media to the approved pictures or video as pod file
+          ids in order (at most 10), publish-at-ms to 09:00 Europe/Paris on
+          the publish date in epoch milliseconds, and publish-outcome queued.
+          Publish due posts sends it through unipile_publish_post on that day
+          and writes the result back. For each other account in post-copy-to
+          (the same post) or post-reshare-on (a LinkedIn repost), create one
+          Scheduled post armed the same way on that account, with
+          post-copy-of set to this post and post-send-mode copy or reshare; a
+          repost has empty publish-text and no media, and waits
+          (publish-outcome waiting) until this post is out.
+          When the account is a Postiz channel (it carries
+          postiz-integration-id and postiz-provider), queue it with
+          postiz_schedule_post: type schedule, the publish date, the approved
+          text, the media links in order, and postEntityId set to this post.
+          When a person approves that run, the pod records the returned postId
+          on the post as postiz-post-id. Any other account: queue it where the
+          account lives and say how.
+        criteria:
+          - key: schedule-date-set
+            statement: The post's publish date is set.
+            check: { kind: evidence, evidenceKey: publish-date }
+          # One judge criterion, not a postiz-post-id evidence check: an account
+          # that is not on Postiz (a newsletter, a blog) has no Postiz id.
+          - key: schedule-account-set
+            statement: The post names the account it goes out on and is queued there; on a Unipile account it is armed (publish-account-id and publish-text set, publish-outcome queued); on a Postiz account its postiz-post-id is recorded.
+            check: { kind: judge }
+      - key: publish
+        name: Publish
+        category: completed
+        subjectStatus: Published
+        goal: >-
+          The post is live at its URL. Armed for Unipile, Publish due posts
+          sends it on its day and writes Published, post-url and
+          published-at itself; a send that fails writes publish-outcome failed
+          and publish-error and leaves the post at Scheduled, for a person to
+          fix and arm again. Queued through Postiz, Postiz reports it (its
+          webhook records the URL and Published); otherwise a person confirms
+          it, and approving writes Published.
+        # A HUMAN gate, not a check: the pod holds a gated stage's status until
+        # the gate passes, and a check gate judges the stage being LEFT
+        # (Schedule), so it would pass on entry and write Published before
+        # anyone saw the post go out — firing Repurpose on a post that may
+        # never have shipped. Only a person's approval writes Published.
+        gate: { kind: human }
+        onFail: { toStage: schedule }
+        criteria:
+          - key: publish-live-url
+            statement: The post's published URL is recorded.
+            check: { kind: evidence, evidenceKey: post-url }
+          - key: publish-date-recorded
+            statement: The post's publish date is set to the day it went live.
+            check: { kind: evidence, evidenceKey: publish-date }
 
-  # 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.
+  # One take, several videos (D2, D3, 29 Oct). The take is a content-asset of
+  # Kind recording; it has no lifecycle (its state is derived from what was
+  # made from it), so this process declares no statusProperty and its stages
+  # move no status. The person decides at Keep, through one question per
+  # proposed piece (a slot ask: the door Content Studio and Relay answer), not
+  # a stage gate: keeping a piece commits nothing outside the pod, and the raw
+  # take is never touched. The per-piece slots are declared by the agent as
+  # each piece exists, like Produce Content's pass slots: a stage's own slots
+  # are owed on entry, and the number of pieces is not known before Analyse.
+  - name: Work a take
+    description: Find the videos inside one recorded take, cut the ones the person keeps into new files, and make one video post at Idea for each, on the person's computer, with the raw take never touched.
+    goalTemplate: >-
+      Work this take ({take}): a content-asset of Kind recording whose File ID
+      is the raw take's file. Run on the person's computer, in this run's work
+      folder (~/synap-work/<this run's session id>). Transcribe it precisely,
+      find the pieces inside it (one or more videos that each stand alone),
+      ask the person which to keep, cut each kept piece into its own new video
+      file, and make one video post at Idea per piece. The raw take is never
+      overwritten, moved or re-uploaded. Quote only words the person said;
+      never invent a claim or a number. Nothing is published, and no Produce
+      Content run starts unless the person asks for it.
+    subjectProfile:
+      profileSlug: content-asset
+    params:
+      - { name: take, type: entity, label: Take, required: true }
+    executor: is-agent
+    status: active
+    stages:
+      - key: transcribe
+        name: Transcribe
+        category: started
+        goal: >-
+          Download the take (GET /api/hub/files/<fileId>/url gives a signed
+          URL) and ffprobe it. Fill the take's missing facts:
+          duration-seconds, frame-width, frame-height, frame-rate, and a
+          poster (one still frame as a JPEG, stored with synap_store_file,
+          its id in poster-file-id). The take's transcript is ONE
+          content-asset, Kind script, whose File ID is the take's file; its
+          body holds the readable text under a "## Transcript" heading, then a
+          "## Words" heading followed by exactly one ```json fenced block with
+          the word-level JSON in HyperFrames' shape [{"text","start","end"}]
+          (seconds). Find it before transcribing (Content Studio usually made
+          it): reuse it and only fill the word timings (npx hyperframes
+          transcribe, Parakeet on the Mac); if none exists, create it and link
+          it to the take's file with a references relation. Never transcribe
+          twice, never a separate document.
+        criteria:
+          - key: take-words-timed
+            statement: The take's one transcript content-asset holds word timings for the whole take.
+            check: { kind: judge }
+          - key: take-facts-filled
+            statement: The take records its duration, frame size, frame rate and a poster.
+            check: { kind: judge }
+      - key: analyse
+        name: Analyse
+        category: started
+        goal: >-
+          Read the transcript and find the pieces: each a run of the take that
+          stands alone as one video, with a range whose edges sit on word
+          boundaries (seconds, in the take's time), a working title, its hook
+          (the person's exact opening sentence), a format (Short Video under
+          about 90 seconds, else Long Video) and why it stands alone. A take
+          that holds one video gives one piece. Write ONE document, the
+          analysis, linked to the take with a references relation: the topics,
+          the strong lines and a verdict on the hook, then a "## Pieces"
+          heading followed by exactly one ```json fenced block
+          [{"n","start","end","title","hook","format","why"}] (n from 1, in
+          take order). Then ask about each piece: hand the person ONE slot per
+          piece (an outcome), key keep-piece-<n>; kind decision; owner human;
+          blockedReason decision; why the piece's range, title and hook; ref
+          the analysis (kind document); ask
+          choose with allowOther, options Keep (recommended when it stands
+          alone and fits its format), Drop, and Adjust (the note gives the new
+          range as <start>-<end> in seconds, or its first and last words).
+          Lines worth a post that are not a piece: propose each as a post at
+          Idea that quotes the person's sentence and links to the take with a
+          references relation.
+        expectedOutputs:
+          - kind: document
+            label: Analysis
+            relationToSubject: references
+        criteria:
+          - key: pieces-ranged
+            statement: Each piece has a word-boundary range, a working title, a hook in the person's exact words and a reason it stands alone.
+            check: { kind: judge }
+          - key: pieces-asked
+            statement: Each piece has its own question to the person (keep-piece-n) with Keep, Drop and Adjust.
+            check: { kind: judge }
+      - key: keep
+        name: Keep pieces
+        category: started
+        goal: >-
+          Wait for the person's answer on every keep-piece-<n> question. Keep:
+          the piece is cut as proposed. Drop: nothing is made from it. Adjust:
+          take the range from the note, snap it to word boundaries, and treat
+          the piece as kept. Claim each answered question (completeOutput).
+          Cut only after every question is answered; a piece the person
+          dropped is never cut.
+        criteria:
+          - key: every-piece-answered
+            statement: The person kept, dropped or adjusted every proposed piece.
+            check: { kind: judge }
+          - key: none-cut-before-answers
+            statement: No piece was cut before every keep-piece question was answered.
+            check: { kind: judge }
+      - key: cut
+        name: Cut
+        category: started
+        goal: >-
+          Cut each kept piece, one at a time. Declare its slot as yours first
+          (an outcome, key piece-<n>, kind content-asset, no owner, no ask):
+          that is how the person sees it being cut. Cut with ffmpeg, frame
+          accurate, from the raw take into a NEW file,
+          ~/synap-work/<this run's session id>/pieces/<n>.mp4: ffmpeg -ss
+          <start> -to <end> -i <raw take> -vf fps=<frame rate> -c:v libx264
+          -crf 18 -preset medium -c:a aac -b:a 192k -af
+          "afade=t=in:st=0:d=0.03,afade=t=out:st=<end minus start minus
+          0.03>:d=0.03" -movflags +faststart <out> (the 30 ms fades keep the
+          edges from popping). Check it with ffprobe (duration within one
+          frame of end minus start, audio and video present). Upload it into
+          this space (synap_request_upload, PUT the bytes, then
+          synap_store_file with the uploadToken) as a file titled "Piece <n> ·
+          <title> (m:ss–m:ss)". Record the piece: a content-asset, Kind
+          recording, titled with its working title: file-id the new file,
+          source-take the take, source-start and source-end, piece-hook,
+          piece-format, duration-seconds, frame-width, frame-height,
+          frame-rate, a poster (poster-file-id) and recorded-at copied from
+          the take; link it to the take and to its file with references
+          relations. Give it its own transcript in the same ONE shape (File
+          ID = the piece's file): the take's words inside the range, re-timed
+          to the piece (minus source-start). Point the slot at the piece
+          (ref, kind entity) and claim it (completeOutput). The person may ask
+          to adjust a piece after its cut: cut the new range into a NEW file
+          the same way, set file-id to it and the new range, and append the
+          old file id to earlier-file-ids; never delete or overwrite a file.
+        criteria:
+          - key: only-kept-cut
+            statement: Only the kept pieces were cut, each into its own new file, and the raw take is unchanged.
+            check: { kind: judge }
+          - key: piece-lineage
+            statement: Each piece records its take, its range and its own file, and references the take.
+            check: { kind: judge }
+      - key: posts
+        name: Make the posts
+        category: completed
+        goal: >-
+          Make one video post per cut piece, at Idea: post-format the piece's
+          format, post-hook its hook, titled with its working title, linked to
+          the piece with a references relation. Record each as an outcome, key
+          post-<n>, kind post, ref the post (kind entity), and claim it
+          (completeOutput). Start Produce Content for a post only if the
+          person asks (its takes param is then the piece's file id).
+        criteria:
+          - key: one-post-per-piece
+            statement: Each cut piece has one video post at Idea that references it, and no post moved past Idea by itself.
+            check: { kind: judge }
+          - key: nothing-started-unasked
+            statement: Nothing was published, and no Produce Content run started unless the person asked for it.
+            check: { kind: judge }
+
+  # The proactive half: the plan. It reasons over the corpus as a whole, so it
+  # takes no params, and its WORKERS are per_moment: ONE run over every post,
+  # never one run per post (a subject-bound playbook's `schedule:` field fans
+  # out per entity; an activator's `schedule` and a per_moment `manual` do
+  # not: api `run-playbook.ts` runWorkerBatch). The `subjectProfile` names the
+  # kind those workers read; there are no stages and no `statusProperty`, so it
+  # never moves a post's status.
+  # Run by hand ("Re-plan" on Content Studio's calendar, or the pod's button)
+  # and once a week (founder, report 22fec5ee §6, 3 Nov 2026). The weekly one
+  # compiles to a governed rule the owner can pause on the pod; both propose
+  # every write, so the dates arrive as ONE batch the person approves.
+  # The plan's numbers are never in this text: cadence, goal mix, pillar
+  # balance and the campaign are read from the pod, where the person edits them.
   - name: Plan Next Content
-    description: Audit the whole corpus against the journey, find the gap, and propose what to make next.
+    description: Audit the whole corpus against the journey, find the gap, propose what to make next, and propose dates for the posts that have none or whose date has passed.
     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.
+      two pieces — each created as a post entity at the Idea status, placed on a
+      pillar, a stage and a platform, with the hook and the reason it is next.
+      Then re-plan the calendar. Read the plan's inputs from the pod, never from
+      a number in this text: the active campaign whose dates cover the coming
+      weeks (campaign-start-date, campaign-end-date, its notes), each publishing
+      account's cadence (platform-posting-freq on its platform), each pillar's
+      target (posting-frequency on the pillar) and the goal mix the person set
+      in this space's brief. Propose a publish-date for every post past Idea
+      that has none, and a new publish-date for every post whose date has
+      passed while it is not Published, the longest-waiting first: follow the
+      cadence, balance the pillars and the goals, keep a campaign's posts inside
+      its dates, and never put two posts of one account on the same day. Never
+      move a Published or Archived post, and never change a post's status. File
+      every date as a proposal, all of them in this one run so the person
+      approves them as one batch, each with a one-line reason (the cadence, the
+      gap or the campaign it serves); never apply a date yourself. When an input
+      is missing (no cadence, no goal mix), say which one in the run's summary
+      and plan without it.
+    subjectProfile:
+      profileSlug: post
+    activators:
+      - { on: schedule, cron: "0 9 * * 1", mode: propose }
+      - { on: manual, size: per_moment, mode: propose }
+    # Typed output: each idea is a real `post` at Idea (the start of Produce
+    # Content's lifecycle), not prose in a message. The run works the whole
+    # set, so no edge to a subject.
+    expectedOutputs:
+      - { kind: post, label: Next post idea, relationToSubject: none }
     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
 
+  # The idea bank's door (decision B, review 22fec5ee §7): Content Studio's
+  # "Package ideas" button runs it. Like Plan Next Content it reasons over the
+  # whole bank at once, so it has NO `subjectProfile` and no params. It OPENS the
+  # work: it proposes posts and their links in ONE capture the person approves,
+  # and never writes the post. The `feeds` edge is the idea → post entityLink.
+  - name: Package ideas
+    description: Read the idea bank, group the ideas that belong together, and propose a set of posts, each linked to the ideas that feed it, as one batch to approve.
+    goalTemplate: >-
+      Package the idea bank of this space. Read every idea (kind idea) at New or
+      Shaped: its words, its pillar, its journey stage and its age. Group the
+      ideas that belong in one piece (the same claim, the same story, or the
+      same question from the audience); one idea may feed several posts. Then
+      propose one to five posts: each with a working title, a format, a pillar
+      and the one sentence it is about, at the Idea status. Never a script, a
+      hook to publish or a finished text: the person writes the post. File the
+      whole set as ONE synap_capture graph (each post a new entity, each source
+      idea by existingEntityId, linked idea feeds post), so the person approves
+      it in one review. Every post has at least one idea; an idea with no cousin
+      that is not a piece on its own is left out. Once the batch is approved,
+      move each idea that feeds a post to Used (synap_update_entity,
+      expectedStatus its status). Nothing is briefed, scheduled or published,
+      and no Produce Content run starts.
+    # Typed output: each packaged post is a real `post` at Idea, linked from its
+    # ideas (`feeds`, written by the capture). No subject, so no edge to one.
+    expectedOutputs:
+      - { kind: post, label: Packaged post, relationToSubject: none }
+    executor: is-agent
+    status: active
+
+  # Once a post is Published, propose turning it into its siblings (thread →
+  # video → newsletter section). It READS the post lifecycle (its activator) but
+  # never moves it — the new pieces are new posts, linked `derived_from` (the
+  # post → post edge above) — so it declares no stages and owns no status.
+  - name: Repurpose
+    description: Turn a published post into new posts for other formats and platforms, each linked to the original.
+    goalTemplate: >-
+      Repurpose this published post ({post}). Read what it says and how it
+      performed, then propose one to three new pieces in other formats or on
+      other platforms where the same idea travels (a thread from an article, a
+      short video from a thread, a newsletter section from a series). Create each
+      as a new post at the Idea status, on the same pillar, with its own hook,
+      and link it derived_from the original. Never republish the original as is.
+    subjectProfile:
+      profileSlug: post
+      statusProperty: post-status
+    activators:
+      # A copy or repost sent for another account (post-copy-of) is not repurposed: its original is.
+      - { on: enters_status, status: Published, mode: propose, unless: { property: post-copy-of, present: true } }
+    expectedOutputs:
+      - { kind: post, label: Repurposed post, relationToSubject: derived_from }
+    params:
+      - { name: post, type: entity, label: Post, required: true }
+    executor: is-agent
+    status: active
+
+  # A newsletter issue from idea to sent, one stage per `newsletter-status`.
+  # No schedule: a subject-bound playbook on a cron fans out one run per
+  # existing newsletter, which is never what an issue cadence means.
+  - name: Newsletter issue
+    description: Take a newsletter issue from idea to sent — angle, draft, edit, schedule — with a person approving before it goes out.
+    goalTemplate: >-
+      Produce this newsletter issue ({newsletter}). Read the brand voice from the
+      pod's brand kit, then work the stages in order: settle the issue's angle
+      and the posts it draws on, draft it, edit it down with a subject line and
+      preview text, and schedule the send. A person approves the final issue
+      before it is sent, nothing sends itself, and the issue reads Sent only once
+      a person confirms it went out.
+    subjectProfile:
+      profileSlug: newsletter
+      statusProperty: newsletter-status
+    humanOnlyStatuses: [Archived]
+    params:
+      - { name: newsletter, type: entity, label: Newsletter issue, required: true }
+    executor: is-agent
+    status: active
+    stages:
+      - key: idea
+        name: Idea
+        category: backlog
+        subjectStatus: Idea
+        goal: Settle the issue's one angle and the posts or sources it draws on.
+        criteria:
+          - key: issue-has-angle
+            statement: The issue states its one angle in a sentence.
+            check: { kind: judge }
+          - key: issue-has-sources
+            statement: The posts or sources the issue draws on are listed.
+            check: { kind: judge }
+      - key: drafting
+        name: Drafting
+        category: started
+        subjectStatus: Drafting
+        goal: Write the full issue in the brand voice.
+        criteria:
+          - key: draft-complete
+            statement: Every section of the issue is written.
+            check: { kind: judge }
+          - key: draft-brand-voice
+            statement: The issue reads in the brand voice from the kit.
+            check: { kind: judge }
+      - key: editing
+        name: Editing
+        category: started
+        subjectStatus: Editing
+        goal: Tighten the issue and write its subject line and preview text.
+        criteria:
+          - key: edit-subject-line
+            statement: The issue has a subject line.
+            check: { kind: judge }
+          - key: edit-preview-text
+            statement: The issue has preview text of about 45 characters.
+            check: { kind: judge }
+          - key: edit-links-work
+            statement: Every link in the issue resolves.
+            check: { kind: judge }
+      - key: scheduled
+        name: Scheduled
+        category: started
+        subjectStatus: Scheduled
+        goal: Set the send date and queue the issue.
+        criteria:
+          - key: send-date-set
+            statement: The issue's send date is set.
+            check: { kind: evidence, evidenceKey: send-date }
+          - key: send-approved
+            statement: A person approved the final issue.
+            check: { kind: human }
+      - key: sent
+        name: Sent
+        category: completed
+        subjectStatus: Sent
+        goal: A person confirms the issue went out to the list; approving writes Sent.
+        # A HUMAN gate: only a person's approval writes Sent, so the issue
+        # never reads Sent before someone confirmed it went out.
+        gate: { kind: human }
+        onFail: { toStage: editing }
+        criteria:
+          - key: sent-confirmed
+            statement: The issue was sent to the list.
+            check: { kind: judge }
+          - key: sent-date-set
+            statement: The issue's send date is set to the day it went out.
+            check: { kind: evidence, evidenceKey: send-date }
+          - key: sent-numbers
+            statement: Subscriber count at send is recorded.
+            check: { kind: judge }
+
+automations:
+  - key: content-os-weekly-produce
+    name: Weekly content production
+    description: >
+      Monday 09:00. Runs Produce Content once, with no subject. The playbook
+      takes the first eligible pinned post, or the oldest post still in Idea
+      when the pin list has nobody eligible. Shipped paused because Content OS
+      is public: an active cron would spend a run for every installer. Turn
+      it on to start the cycle. Produce Content's own schedule stays off.
+    triggerType: cron
+    triggerConfig:
+      expression: "0 9 * * 1"
+    status: paused
+    flow:
+      nodes:
+        - id: trigger
+          type: trigger
+          position: { x: 0, y: 0 }
+          data:
+            label: Monday at 09:00
+            triggerType: cron
+            config:
+              expression: "0 9 * * 1"
+        - id: produce
+          type: playbook_run
+          position: { x: 0, y: 160 }
+          data:
+            label: Produce the next idea
+            playbookName: Produce Content
+      edges:
+        - id: e-trigger-produce
+          source: trigger
+          target: produce
+
+  # Decision A (founder, 3 Nov): a Scheduled post goes out through Unipile on
+  # its date, with no second approval. ONE post per run, at the top level: a
+  # capability node inside a loop that fails aborts its item with no failure
+  # branch, and the failure must be written on the post. The query compares
+  # properties numerically only, hence publish-at-ms. Shipped paused, like
+  # every catalog automation: the person turns it on, and lets
+  # unipile_publish_post run without a second approval for it (a run the pod
+  # would propose fails the send, and the post says so).
+  - key: content-os-publish-due-posts
+    name: Publish due posts
+    description: >
+      Every 15 minutes, sends the oldest approved post whose time has come
+      through Unipile, with no second approval. A post is due when it is
+      Scheduled, armed when it was approved (publish-outcome queued) and its
+      publish-at-ms has passed. It is claimed first (publish-outcome
+      sending), so it is never sent twice; then its frozen words, account and
+      pictures (publish-text, publish-account-id, publish-media) go out with
+      unipile_publish_post, as a LinkedIn company page when it names one
+      (publish-as-organization) and as a repost when it is one
+      (publish-quote-id). Sent: Published, published-at, post-url and its
+      Unipile id (publish-post-id), and its reposts waiting for it are
+      queued with that id. Failed: publish-outcome failed and publish-error,
+      the post left at Scheduled. Shipped paused: turn it on to start.
+    triggerType: cron
+    triggerConfig:
+      expression: "*/15 * * * *"
+    status: paused
+    flow:
+      nodes:
+        - id: trigger
+          type: trigger
+          position: { x: 0, y: 0 }
+          data:
+            label: Every 15 minutes
+            triggerType: cron
+            config:
+              expression: "*/15 * * * *"
+        - id: now
+          type: transform
+          position: { x: 0, y: 120 }
+          data:
+            label: When this run was due, in milliseconds
+            expression: "{{trigger.payload.scheduledAt}} | to_ms"
+        - id: due
+          type: query
+          position: { x: 0, y: 240 }
+          data:
+            label: The oldest armed post whose time has come
+            profileSlug: post
+            filter: '{"post-status": "Scheduled", "publish-outcome": "queued", "publish-at-ms": {"$lte": {{steps.now.output.result}}}}'
+            orderBy: properties.publish-at-ms
+            orderDir: asc
+            limit: 1
+        - id: any-due
+          type: condition
+          position: { x: 0, y: 360 }
+          data:
+            label: A post is due?
+            expression: "steps.due.output.count > 0"
+        - id: claim
+          type: output
+          position: { x: 0, y: 480 }
+          data:
+            label: Claim it, so it is never sent twice
+            outputType: entity_update
+            config:
+              entityId: "{{steps.due.output.entities.0.id}}"
+              properties:
+                publish-outcome: sending
+        # The claim must have LANDED: a claim the pod only proposed leaves the
+        # post queued, and the next run would send it a second time.
+        - id: claimed
+          type: condition
+          position: { x: 0, y: 540 }
+          data:
+            label: The claim is written?
+            expression: "steps.claim.output.status === 'updated'"
+        - id: send
+          type: capability
+          position: { x: 0, y: 600 }
+          data:
+            label: Post it through Unipile
+            verbId: unipile_publish_post
+            inputMapping:
+              accountId: "{{steps.due.output.entities.0.properties.publish-account-id}}"
+              text: "{{steps.due.output.entities.0.properties.publish-text}}"
+              media: "{{steps.due.output.entities.0.properties.publish-media}}"
+              # A LinkedIn company page (post_as) and a repost's original
+              # (quoted_post_id); both empty for an ordinary post.
+              postAs: "{{steps.due.output.entities.0.properties.publish-as-organization}}"
+              quotedPostId: "{{steps.due.output.entities.0.properties.publish-quote-id}}"
+            # Never retried (an outward post), and a failure goes on to the
+            # failure branch instead of stopping the run.
+            errorHandling:
+              continueOnError: true
+        - id: sent
+          type: condition
+          position: { x: 0, y: 720 }
+          data:
+            label: Unipile posted it?
+            expression: "steps.send.output.error === ''"
+        - id: published
+          type: output
+          position: { x: -160, y: 840 }
+          data:
+            label: Published, and when
+            outputType: entity_update
+            config:
+              entityId: "{{steps.due.output.entities.0.id}}"
+              properties:
+                post-status: Published
+                published-at: "{{trigger.payload.scheduledAt}}"
+                publish-outcome: succeeded
+        # Its own node: Unipile may return no link, and an empty post-url is
+        # refused; the post is Published either way.
+        - id: link
+          type: output
+          position: { x: -160, y: 960 }
+          data:
+            label: The live post's link
+            outputType: entity_update
+            config:
+              entityId: "{{steps.due.output.entities.0.id}}"
+              properties:
+                post-url: "{{steps.send.output.shareUrl}}"
+            errorHandling:
+              continueOnError: true
+        # Unipile's id of the post it just sent: what a repost of it quotes.
+        # With no id there is nothing to quote, so its reposts stay waiting
+        # (Content Studio says so on the post).
+        - id: has-id
+          type: condition
+          position: { x: -160, y: 1080 }
+          data:
+            label: Unipile gave the post's id?
+            expression: "steps.send.output.postId !== ''"
+        - id: remember-id
+          type: output
+          position: { x: -160, y: 1200 }
+          data:
+            label: Keep the post's Unipile id
+            outputType: entity_update
+            config:
+              entityId: "{{steps.due.output.entities.0.id}}"
+              properties:
+                publish-post-id: "{{steps.send.output.postId}}"
+            errorHandling:
+              continueOnError: true
+        # Its reposts (written at approval, each waiting for this post), now
+        # queued with the id they quote. Only writes run per item here: the
+        # send itself is never inside a loop.
+        - id: reposts
+          type: query
+          position: { x: -160, y: 1320 }
+          data:
+            label: The reposts waiting for this post
+            profileSlug: post
+            filter: '{"post-copy-of": "{{steps.due.output.entities.0.id}}", "publish-outcome": "waiting"}'
+            limit: 20
+        - id: each-repost
+          type: loop
+          position: { x: -160, y: 1440 }
+          data:
+            label: For each waiting repost
+            iteratorExpression: steps.reposts.output.entities
+            itemVariable: repost
+        - id: arm-repost
+          type: output
+          position: { x: -160, y: 1560 }
+          data:
+            label: Queue it, with the post it reposts
+            outputType: entity_update
+            config:
+              entityId: "{{loop.item.id}}"
+              properties:
+                publish-quote-id: "{{steps.send.output.postId}}"
+                publish-outcome: queued
+        - id: failed
+          type: output
+          position: { x: 160, y: 840 }
+          data:
+            label: It didn't go out, and why
+            outputType: entity_update
+            config:
+              entityId: "{{steps.due.output.entities.0.id}}"
+              properties:
+                publish-outcome: failed
+                publish-error: "{{steps.send.output.error}}"
+      edges:
+        - id: e-trigger-now
+          source: trigger
+          target: now
+        - id: e-now-due
+          source: now
+          target: due
+        - id: e-due-any
+          source: due
+          target: any-due
+        - id: e-any-claim
+          source: any-due
+          target: claim
+          sourceHandle: "yes"
+        - id: e-claim-claimed
+          source: claim
+          target: claimed
+        - id: e-claimed-send
+          source: claimed
+          target: send
+          sourceHandle: "yes"
+        - id: e-send-sent
+          source: send
+          target: sent
+        - id: e-sent-published
+          source: sent
+          target: published
+          sourceHandle: "yes"
+        - id: e-published-link
+          source: published
+          target: link
+        - id: e-link-has-id
+          source: link
+          target: has-id
+        - id: e-has-id-remember
+          source: has-id
+          target: remember-id
+          sourceHandle: "yes"
+        - id: e-remember-reposts
+          source: remember-id
+          target: reposts
+        - id: e-reposts-each
+          source: reposts
+          target: each-repost
+        - id: e-each-arm
+          source: each-repost
+          target: arm-repost
+        - id: e-sent-failed
+          source: sent
+          target: failed
+          sourceHandle: "no"
+
 onboarding:
   goal: >
     Stand up the editorial engine — the pillars you're known for, the journey a
@@ -1074,6 +2807,12 @@ onboarding:
     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.
+    READY BEFORE PRODUCING: a post is produced only from approved brand
+    material — at least three approved references, an approved base content
+    guideline, and an approved brand-template for each format the post uses.
+    If any is missing, do not improvise a look: say which, and route to the
+    content-taste skill (or Brand Library onboarding when there is no brand
+    identity or voice yet) before the first post is produced.
     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
@@ -1138,6 +2877,7 @@ onboarding:
       thin — so the coverage read is a habit, not a feature they never find.
   collect:
     - profileSlug: pillar
+      min: 1
       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]
@@ -1150,13 +2890,15 @@ onboarding:
       cardinality: one
       keyFields: [series-status, series-goal, series-pillar]
     - profileSlug: platform
+      min: 1
       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), and on a stage if the journey exists.
+      min: 1
+      what: A first post or two already in motion, each placed on a pillar and a platform at its true status (Idea through Published), with its goal (sell, hot-take, tutorial, product-demo…) so it gets the right narrative frame, and on a stage if the journey exists.
       cardinality: few
-      keyFields: [post-status, post-pillar, post-platform]
+      keyFields: [post-status, post-pillar, post-platform, post-goal]
     - profileSlug: offer
       what: >-
         ONLY IF THEY SELL SOMETHING. Ask once; if they don't sell, or hedge,
@@ -1176,3 +2918,52 @@ onboarding:
   # 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.
+
+skills:
+  # DECLARED, not asked for in prose: every AI working in Content OS is told this
+  # skill exists, is prepended with it each turn (`always`), and finds it ranked
+  # first — the producing space, where every content ask routes through it.
+  #
+  # A REF, not a copy: the skill ships as its own package
+  # (`skills/creative-director.skill.json`) and is installed by the `require`
+  # dependency below. This is the LINK; that is the INSTALL.
+  - slug: creative-director
+    when: Every content ask in this space — it picks the approved brand-template, references and assets
+    mode: always
+  # On-demand, not always: needed only when the readiness check finds no
+  # approved references, base guideline or template for the format.
+  - slug: content-taste
+    when: Studying inspiration, writing content guidelines, building the asset kit
+    mode: on-demand
+  - slug: carousel-format
+    when: Scripting or drafting a carousel, LinkedIn PDF or image post (the layered composition)
+    mode: on-demand
+  - slug: edit-loop
+    when: Building any visual or video post pass by pass — the slots, answers and rules every engine shares
+    mode: on-demand
+  - slug: open-design-edit
+    when: Building a deck, PDF document or presentation in Open Design
+    mode: on-demand
+  # Video: the toolbox first (which tool, where it renders, which skill next),
+  # then the job skill it names.
+  - slug: video-toolbox
+    when: Any video or animation ask, before choosing a tool — making, editing or animating video
+    mode: on-demand
+  - slug: video-direction
+    when: Planning a launch, promo or explainer film before building it — brief, story, treatment, storyboard
+    mode: on-demand
+  - slug: video-style-vocabulary
+    when: Choosing the visual style of a video or writing its style sheet
+    mode: on-demand
+  - slug: motion-quality-gates
+    when: Checking a HyperFrames draft before showing it or rendering the final
+    mode: on-demand
+  - slug: math-explainer-manimgx
+    when: Animating math, equations, graphs, algorithms or 3D concepts for a video
+    mode: on-demand
+  - slug: facecam-edit
+    when: Editing face-camera, interview or screen-recording footage — cuts, captions, graphics
+    mode: on-demand
+  - slug: collage-broll
+    when: Generating b-roll clips or illustrative stills for a video through fal.ai
+    mode: on-demand