@synap-core/workspace-templates 0.12.0 → 0.23.0

package/src/operations.yaml

@@ -12,6 +12,32 @@ meta:
   color: "#0F766E"
   tags: [operations, delivery, clients, engagements]
   isPublic: true
+  # Onboarding start (meta.start): the "client delivery" card.
+  start:
+    order: 4
+    label: Client delivery
+    promise: Every client engagement and where it stands.
+    suggestFor: [consultant]
+    profile: engagement
+    views: [engagements]
+    example:
+      - { title: "Website redesign for Maison Dupont", values: { engagement-status: active, engagement-value: 18000 } }
+      - { title: "Monthly strategy retainer", values: { engagement-status: active, engagement-value: 4500 } }
+      - { title: "Brand audit for Nordlys", values: { engagement-status: proposed, engagement-value: 6000 } }
+      - { title: "Onboarding workshop for Atelier 9", values: { engagement-status: completed, engagement-value: 2800 } }
+    firstSession:
+      title: Your live engagements
+      goal: "Add the 3 to 5 client engagements you are delivering now, each with its client, a status and a value."
+    starters:
+      - "I run client projects as a freelancer"
+      - "We are a small agency with several retainers"
+      - "I deliver workshops and audits to companies"
+  # What this space PRODUCES (homes): the purpose word, then its kinds/roles.
+  intent:
+    label: Delivery
+    produces:
+      - profile: engagement
+      - profile: deliverable
 
 workspace:
   name: Operations
@@ -45,12 +71,21 @@ profiles:
     icon: briefcase
     color: "#0F766E"
     description: "A unit of client work — a project or retainer delivered for a company, with scope, dates, and value."
+    # The ONE lifecycle (work model L1): the initiative base without its
+    # agreed and ready steps (lifecycle-presets.ts). Putting an engagement on
+    # hold and cancelling it are a person's call; completing it is not (the
+    # close stage has its own human gate).
+    lifecycle:
+      property: engagement-status
+      adopts: initiative
+      drop: [agreed, ready]
+      rename: { dropped: cancelled }
+      humanOnly: { on-hold: true, completed: false, cancelled: true }
     properties:
       - slug: engagement-status
         label: Status
         valueType: string
         inputType: select
-        enumValues: [proposed, active, on-hold, completed, cancelled]
         constraints: { defaultValue: proposed }
       - slug: engagement-client
         label: Client
@@ -81,18 +116,42 @@ profiles:
         label: Notes
         valueType: string
         inputType: textarea
+      # How the engagement is invoiced (founder decision 2026-10-12): once at
+      # close (the default — "Deliver a client engagement" creates the closing
+      # invoice), or one invoice per accepted deliverable (milestone billing —
+      # "Deliver a deliverable" creates it at Accepted). Not a lifecycle.
+      - slug: engagement-billing-mode
+        label: Billing
+        valueType: string
+        inputType: select
+        enumValues: [at-close, per-deliverable]
+        constraints: { defaultValue: at-close }
 
   - slug: deliverable
     displayName: Deliverable
     icon: package-check
     color: "#0EA5E9"
     description: "A concrete output owed inside an engagement — with a due date, an owner, and a status."
+    # The ONE lifecycle (work model L1): every option's category.
+    lifecycle:
+      property: deliverable-status
+      options:
+        - { key: not-started, category: open }
+        - { key: in-progress, category: active }
+        - { key: in-review, category: active }
+        - { key: delivered, category: active }
+        - { key: accepted, category: done }
+        # A deliverable the client no longer wants (scope cut, engagement
+        # cancelled) ends here, not in `accepted`; dropping it is a person's
+        # call, like every `cancelled` (work-item base, plan aac47c4a W5). It is
+        # a client decision, not a failure: muted, not the lost default `error`.
+        - { key: cancelled, category: lost, tone: textMuted, humanOnly: true }
     properties:
       - slug: deliverable-status
         label: Status
         valueType: string
         inputType: select
-        enumValues: [not-started, in-progress, in-review, delivered, accepted]
+        enumValues: [not-started, in-progress, in-review, delivered, accepted, cancelled]
         constraints: { defaultValue: not-started }
       - slug: deliverable-engagement
         label: Engagement
@@ -121,6 +180,16 @@ profiles:
     icon: file-signature
     color: "#8B5CF6"
     description: "The agreement that governs an engagement — its status, value, term, and signed document."
+    # The ONE lifecycle (work model L1): every option's category.
+    lifecycle:
+      property: contract-status
+      options:
+        - { key: draft, category: open }
+        - { key: sent, category: active }
+        - { key: signed, category: active }
+        - { key: active, category: active }
+        - { key: expired, category: done, humanOnly: true }
+        - { key: terminated, category: lost, humanOnly: true }
     properties:
       - slug: contract-status
         label: Status
@@ -267,10 +336,12 @@ onboarding:
     engagement, who owns it, and when it's due.
   collect:
     - profileSlug: engagement
+      min: 1
       what: The client engagements live right now — one per real project or retainer, with its client and dates.
       cardinality: several
       keyFields: [engagement-status, engagement-client, engagement-end]
     - profileSlug: deliverable
+      min: 1
       what: The deliverables due inside those engagements, placed at their true status with a due date.
       cardinality: several
       keyFields: [deliverable-status, due-date]
@@ -591,8 +662,8 @@ automations:
   # ══════════════════════════════════════════════════════════════════════════
   # CRM → Operations HANDOFF PICKUP
   #
-  # The other half of business-developer's "Win and hand off". That flow ends by
-  # attaching the pod-wide `client` role with `handoffStatus`; nothing on the
+  # The other half of CRM's "Win a deal" (and The Arch's "Win and hand off",
+  # moved there from business-developer 2026-10-12). Both end by attaching the pod-wide `client` role with `handoffStatus`; nothing on the
   # delivery side ever picked it up, so a won deal became a client and then
   # nothing happened. This automation is that pickup: once a day it finds
   # clients marked ready/handed_off that have NO engagement yet, and opens the
@@ -841,3 +912,232 @@ automations:
         - { id: h-engagement-link, source: create-engagement, target: link-engagement }
         - { id: h-link-contract, source: link-engagement, target: create-contract }
         - { id: h-contract-link, source: create-contract, target: link-contract }
+
+playbooks:
+  - name: Deliver a client engagement
+    description: Run one client engagement from kick-off to close — scope, contract, deliverables, final review and the closing invoice — with a person approving the start and the close.
+    goalTemplate: >-
+      Run this client engagement ({engagement}); each stage moves its status.
+      KICK-OFF: read the won deal, the proposal and every message with the
+      client; write the scope, owner, start and end dates and value on the
+      engagement; create one deliverable per promised output (each with a due
+      date and an owner); reuse the draft contract already linked to the
+      engagement (the daily client pick-up opens one), and create a draft
+      contract only when none is linked.
+      START: a person confirms the contract is signed and the work may start.
+      DELIVER: track every deliverable to accepted (or cancelled by a person),
+      post a short weekly status in this session's room, and flag any
+      deliverable past its due date.
+      CLOSE: once every deliverable is accepted or cancelled, write the closing review
+      (what was delivered, what slipped, what the client said), create the
+      closing invoice in Finance at the draft status for the engagement value
+      still owed (when the engagement bills per deliverable, subtract every
+      milestone invoice already created for it), and propose the renewal or
+      next engagement. A person
+      approves the close. Pausing or cancelling an engagement is a person's
+      call.
+    subjectProfile:
+      profileSlug: engagement
+      statusProperty: engagement-status
+    humanOnlyStatuses: [on-hold, cancelled]
+    activators:
+      - { on: created, mode: propose }
+    params:
+      - { name: engagement, type: entity, label: Engagement, required: true }
+    executor: is-agent
+    status: active
+    requiredIntents: [list_records, send_message]
+    expectedOutputs:
+      - { kind: deliverable, label: Deliverables, relationToSubject: relates_to }
+      - { kind: contract, label: Contract, relationToSubject: contract_for_engagement }
+      - { kind: invoice, label: Closing invoice, relationToSubject: relates_to }
+      - { kind: document, label: Closing review }
+    metadata:
+      lineage: { method: "Agency delivery: kick-off, milestone tracking, close-out review" }
+    stages:
+      - key: kickoff
+        name: Kick-off
+        category: planned
+        subjectStatus: proposed
+        goal: Write scope, owner, dates and value; create the deliverables; reuse the linked draft contract or create one when none exists.
+        criteria:
+          - key: kickoff-scope
+            statement: The engagement's scope, owner, start date, end date and value are set.
+            check: { kind: judge }
+          - key: kickoff-deliverables
+            statement: Every output promised in the proposal exists as a deliverable with a due date and an owner.
+            check: { kind: judge }
+          - key: kickoff-contract
+            statement: A contract is linked to the engagement.
+            check: { kind: judge }
+      - key: start
+        name: Start
+        category: started
+        subjectStatus: active
+        goal: A person confirms the contract is signed and the work may start.
+        gate: { kind: human }
+        onFail: { toStage: kickoff }
+      - key: deliver
+        name: Deliver
+        category: started
+        goal: Track every deliverable to accepted or cancelled and post a weekly status in the room.
+        indefinite: true
+        criteria:
+          - key: deliver-all-accepted
+            statement: Every deliverable of the engagement is accepted or cancelled.
+            check: { kind: judge }
+          - key: deliver-weekly-status
+            statement: A status was posted in the room for every week the engagement was active.
+            check: { kind: judge }
+      - key: close
+        name: Close
+        category: completed
+        subjectStatus: completed
+        goal: Write the closing review, create the closing invoice, propose the renewal; a person approves the close.
+        gate: { kind: human }
+        onFail: { toStage: deliver }
+
+  # Starts when a person moves the deliverable to In progress (founder
+  # decision 2026-10-12), not when it is created: a deliverable is usually
+  # created at kick-off, weeks before anyone works on it. Not started is
+  # therefore a person's status, and the first stage writes nothing.
+  - name: Deliver a deliverable
+    description: Take one deliverable from in progress to accepted by the client — plan, produce, review internally, send, get the client's sign-off, and bill it when the engagement bills per deliverable.
+    goalTemplate: >-
+      Deliver this deliverable ({deliverable}); each stage moves its status.
+      PLAN: read the engagement's scope and the client's brief, and write what
+      done looks like for this deliverable. PRODUCE: make it, or break it into
+      tasks for the people who will. REVIEW: check it against what done looks
+      like before anyone outside sees it. SEND: a person approves before it
+      goes to the client; record the date it was delivered. ACCEPTED: a person
+      confirms the client accepted it; if the client asked for changes, go
+      back to producing. Then read the engagement's billing: only when it
+      bills per deliverable, create this deliverable's invoice in Finance at
+      the draft status for its share of the engagement value, linked to the
+      deliverable. When it bills at close, create no invoice; the engagement's
+      close bills it.
+    subjectProfile:
+      profileSlug: deliverable
+      statusProperty: deliverable-status
+    humanOnlyStatuses: [not-started, cancelled]
+    activators:
+      - { on: enters_status, status: in-progress, mode: propose }
+    params:
+      - { name: deliverable, type: entity, label: Deliverable, required: true }
+    executor: is-agent
+    status: active
+    expectedOutputs:
+      - { kind: document, label: Delivered file or link }
+    stages:
+      - key: plan
+        name: Plan
+        category: started
+        goal: Write what done looks like for this deliverable from the engagement scope and the client brief.
+        criteria:
+          - key: plan-definition-of-done
+            statement: The deliverable states what done looks like in checkable terms.
+            check: { kind: judge }
+      - key: produce
+        name: Produce
+        category: started
+        subjectStatus: in-progress
+        goal: Make the deliverable, or split it into tasks with owners.
+        criteria:
+          - key: produce-draft-attached
+            statement: A draft of the deliverable is attached or linked.
+            check: { kind: judge }
+      - key: review
+        name: Internal review
+        category: started
+        subjectStatus: in-review
+        goal: Check the draft against what done looks like before the client sees it.
+        gate: { kind: check }
+        onFail: { toStage: produce }
+        criteria:
+          - key: review-meets-done
+            statement: The draft meets every point of the deliverable's definition of done.
+            check: { kind: judge }
+      - key: send
+        name: Send to client
+        category: started
+        subjectStatus: delivered
+        goal: A person approves sending; record the delivered date.
+        gate: { kind: human }
+        onFail: { toStage: produce }
+        criteria:
+          - key: send-date-recorded
+            statement: The deliverable's delivered date is set.
+            check: { kind: evidence, evidenceKey: delivered-date }
+      - key: accepted
+        name: Accepted
+        category: completed
+        subjectStatus: accepted
+        goal: A person confirms the client accepted the deliverable; when the engagement bills per deliverable, create its draft invoice in Finance.
+        gate: { kind: human }
+        onFail: { toStage: produce }
+        # Milestone billing. Only made when the engagement's billing is
+        # per-deliverable; at-close engagements are billed by the engagement's
+        # close. `optional` (synap-backend 30a9ab85): nobody owes the slot, so
+        # an at-close run never shows it pending; the condition itself lives
+        # in the goal.
+        expectedOutputs:
+          - { kind: invoice, label: Milestone invoice (per-deliverable billing only), relationToSubject: relates_to, optional: true }
+
+  - name: Get a contract signed
+    description: Take a client contract from draft to signed and active, with a person approving what is sent and confirming the signature.
+    goalTemplate: >-
+      Get this contract ({contract}) signed; each stage moves its status.
+      DRAFT: fill the contract from the engagement's scope, value, dates and
+      the agency's standard terms, and list every term that differs from the
+      standard. SEND: a person approves the contract before it goes to the
+      client. SIGNED: ask the person to `provide` the signed file; their
+      approval confirms both sides signed. ACTIVE: set the start and end dates and link the signed
+      document. Expiry and termination are a person's call.
+    subjectProfile:
+      profileSlug: contract
+      statusProperty: contract-status
+    humanOnlyStatuses: [expired, terminated]
+    activators:
+      - { on: created, mode: propose }
+    params:
+      - { name: contract, type: entity, label: Contract, required: true }
+    executor: is-agent
+    status: active
+    expectedOutputs:
+      - { kind: document, label: Signed contract }
+    stages:
+      - key: draft
+        name: Draft
+        category: planned
+        subjectStatus: draft
+        goal: Fill the contract from the engagement and the standard terms; list every non-standard term.
+        criteria:
+          - key: contract-value-dates
+            statement: The contract's value, start date and end date are set.
+            check: { kind: judge }
+          - key: contract-deviations-listed
+            statement: Every term that differs from the agency's standard terms is listed.
+            check: { kind: judge }
+      - key: send
+        name: Send
+        category: started
+        subjectStatus: sent
+        goal: A person approves the contract before it goes to the client.
+        gate: { kind: human }
+        onFail: { toStage: draft }
+      - key: signed
+        name: Signed
+        category: started
+        subjectStatus: signed
+        goal: Ask the person to provide the signed file; their approval confirms both sides signed.
+        gate: { kind: human }
+        onFail: { toStage: send }
+      - key: active
+        name: Active
+        category: completed
+        subjectStatus: active
+        goal: Set the dates and link the signed document on the contract.
+        criteria:
+          - key: contract-document-linked
+            statement: The signed document's link is set on the contract.
+            check: { kind: evidence, evidenceKey: contract-url }

package/src/pipeline-views.template.test.ts

@@ -0,0 +1,88 @@
+/**
+ * D3 (work model L3, 2026-10-12): a catalog board over a declared lifecycle is
+ * a `pipeline` view — ONE rendering of "things in the columns of their
+ * status" (the pod's `lifecycle.board`, the one mover), never a kanban beside
+ * it that draws a column per drifted value.
+ *
+ * Reachability, not shape (guards-and-tests.md): a `pipeline` view whose kind
+ * declares NO lifecycle renders nothing at all (PipelineView OMITs an
+ * undeclared profile), and one whose config names no kind renders "This
+ * pipeline names no kind". So every pipeline view must name its kind in
+ * `config.profileSlug` (what `readPipelineConfig` reads), and that kind must
+ * declare a lifecycle in the template itself or in a template it depends on
+ * (the install resolver puts dependencies first — the lead role's lifecycle
+ * lives in foundation).
+ *
+ * The scanned set is DERIVED from every bundled template; a non-vacuity floor
+ * keeps it honest. What it does not see: a lifecycle declared only by a pod
+ * (not in the catalog), and a pod whose dependency was later removed.
+ */
+import { describe, expect, it } from "vitest";
+import { WORKSPACE_TEMPLATES } from "./templates.js";
+
+type View = {
+  name: string;
+  type: string;
+  scopeProfileSlug?: string;
+  groupBy?: string;
+  config?: Record<string, unknown>;
+};
+type Profile = { slug: string; lifecycle?: { property: string } };
+type Template = {
+  meta?: { slug?: string };
+  profiles?: Profile[];
+  views?: View[];
+  dependencies?: Array<{ slug: string }>;
+};
+
+const templates = WORKSPACE_TEMPLATES as unknown as Record<string, Template>;
+const bySlug = new Map(
+  Object.entries(templates).map(([key, t]) => [t.meta?.slug ?? key, t] as const),
+);
+
+/** The lifecycle property a profile declares here or in a dependency (transitively). */
+function lifecycleOf(t: Template, profileSlug: string, seen = new Set<Template>()): string | null {
+  if (seen.has(t)) return null;
+  seen.add(t);
+  const own = t.profiles?.find((p) => p.slug === profileSlug && p.lifecycle)?.lifecycle?.property;
+  if (own) return own;
+  for (const dep of t.dependencies ?? []) {
+    const d = bySlug.get(dep.slug);
+    const found = d ? lifecycleOf(d, profileSlug, seen) : null;
+    if (found) return found;
+  }
+  return null;
+}
+
+const allViews = Object.values(templates).flatMap((t) => (t.views ?? []).map((v) => ({ t, v })));
+const pipelines = allViews.filter(({ v }) => v.type === "pipeline");
+
+describe("catalog pipeline views (D3)", () => {
+  it("the scan sees the catalog and the converted boards", () => {
+    expect(allViews.length).toBeGreaterThan(50);
+    expect(pipelines.map(({ v }) => v.name).sort()).toEqual(
+      expect.arrayContaining(["Hiring Pipeline", "Lead Pipeline", "Pipeline"]),
+    );
+  });
+
+  it("every pipeline view names a kind that declares a lifecycle", () => {
+    const broken = pipelines.flatMap(({ t, v }) => {
+      const slug = v.config?.profileSlug;
+      if (typeof slug !== "string" || !slug) return [`${t.meta?.slug} / ${v.name}: no config.profileSlug`];
+      if (v.scopeProfileSlug && v.scopeProfileSlug !== slug)
+        return [`${t.meta?.slug} / ${v.name}: config.profileSlug ≠ scopeProfileSlug`];
+      return lifecycleOf(t, slug) ? [] : [`${t.meta?.slug} / ${v.name}: ${slug} declares no lifecycle`];
+    });
+    expect(broken).toEqual([]);
+  });
+
+  it("no kanban named a pipeline still groups a declared lifecycle (it is a pipeline view)", () => {
+    const stray = allViews.flatMap(({ t, v }) => {
+      if (v.type !== "kanban" || !/pipeline/i.test(v.name) || !v.scopeProfileSlug) return [];
+      const property = lifecycleOf(t, v.scopeProfileSlug);
+      const groupBy = v.groupBy ?? v.config?.groupBy ?? v.config?.groupByField;
+      return property && groupBy === property ? [`${t.meta?.slug} / ${v.name}`] : [];
+    });
+    expect(stray).toEqual([]);
+  });
+});

package/src/playbook-goal-placeholders.test.ts

@@ -0,0 +1,57 @@
+/**
+ * Every shipped playbook goal is fillable by a run.
+ *
+ * The pod's playbook door (`playbooks.create`, which the package installer
+ * reaches) REFUSES a goalTemplate whose placeholder no run fills
+ * (synap-backend `services/playbooks/goal-references.ts`, 1c619345):
+ *   - a bare `{{name}}` — the run door substitutes `{name}` / `@{arg:name}`
+ *     only, so `{{name}}` reached the agent verbatim; it never worked;
+ *   - a `{name}` / `@{arg:name}` naming no declared param.
+ * A template that ships either now fails its own install. This guard fails the
+ * template at build time instead, derived over EVERY bundled template.
+ *
+ * It mirrors the pod's rule (this package cannot import the api), so it proves
+ * the templates agree with THAT rule — not that the rule is right. Rooted
+ * automation paths (`{{trigger.x}}`, `{{steps.y}}`) are not placeholders and
+ * are out of scope; so is braced prose (`{see below}`, a space inside).
+ */
+
+import { describe, expect, it } from "vitest";
+import { WORKSPACE_TEMPLATES } from "./templates.js";
+// One matcher, shared with validateCatalog (which runs it on EVERY kind's playbooks).
+import { goalPlaceholderProblems } from "../scripts/catalog-lib.mjs";
+
+
+const goals = Object.entries(WORKSPACE_TEMPLATES).flatMap(([slug, tpl]) =>
+  (tpl.playbooks ?? []).map((p) => ({
+    where: `${slug} › ${p.name}`,
+    goal: p.goalTemplate ?? "",
+    declared: new Set((p.params ?? []).map((x) => x.name)),
+  }))
+);
+
+describe("playbook goals — every placeholder is one a run fills", () => {
+  it("non-vacuity: the scan sees real playbooks, and a real {name} placeholder", () => {
+    expect(goals.length).toBeGreaterThanOrEqual(15);
+    expect(goals.some((g) => /\{[A-Za-z_]\w*\}/.test(g.goal))).toBe(true);
+  });
+
+  it("the matcher catches what it hunts (self-check)", () => {
+    expect(goalPlaceholderProblems("Check {{part}} now", new Set(["part"]))).toEqual([
+      "{{part}}",
+    ]);
+    expect(goalPlaceholderProblems("Do {x} and @{arg:y}", new Set(["x"]))).toEqual([
+      "@{arg:y}",
+    ]);
+    expect(
+      goalPlaceholderProblems("Since {{trigger.payload.since}} {see below}", new Set())
+    ).toEqual([]);
+  });
+
+  it("no shipped playbook goal carries {{name}} or an undeclared {name}", () => {
+    const bad = goals.flatMap((g) =>
+      goalPlaceholderProblems(g.goal, g.declared).map((p) => `${g.where}: ${p}`)
+    );
+    expect(bad).toEqual([]);
+  });
+});

package/src/postiz-contract.test.ts

@@ -0,0 +1,134 @@
+/**
+ * The Postiz contract: the property keys the backend's Postiz webhook and the
+ * `postiz` capability agree on, pinned where the model is authored.
+ *
+ * The backend finds a post by `postiz-post-id` (the id Postiz returned when the
+ * post was queued) and a post queued on a `platform` account sends that
+ * account's `postiz-integration-id` and `postiz-provider`. A rename here would
+ * leave the webhook matching nothing, silently, so the keys are pinned on the
+ * SSOT template (content-os owns `post` and `platform`) and on every template
+ * that re-declares those profiles with the Postiz fields.
+ *
+ * NOT covered: the backend side of the contract (the webhook route and its
+ * lookup), which lives in synap-backend; whether Postiz accepts the body
+ * (exercised against the openapi, not a live Postiz).
+ */
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
+import { describe, expect, it } from "vitest";
+import { WORKSPACE_TEMPLATES } from "./templates.js";
+import type { TemplateProfile, WorkspaceYaml } from "./types.js";
+
+const POST_KEYS = ["postiz-post-id"];
+const PLATFORM_KEYS = ["postiz-integration-id", "postiz-provider"];
+
+const templates = Object.values(WORKSPACE_TEMPLATES) as WorkspaceYaml[];
+const profile = (tpl: WorkspaceYaml | undefined, slug: string): TemplateProfile | undefined =>
+  (tpl?.profiles ?? []).find((p) => p.slug === slug);
+const propertyOf = (p: TemplateProfile | undefined, key: string) =>
+  (p?.properties ?? []).find((prop) => prop.slug === key);
+
+const capability = JSON.parse(
+  readFileSync(join(import.meta.dirname, "..", "capabilities", "postiz.capability.json"), "utf8"),
+) as { spec: { skills: Array<Record<string, any>>; provides?: string[] } };
+
+describe("Postiz contract — the keys the webhook and the capability share", () => {
+  const contentOs = WORKSPACE_TEMPLATES["content-os"] as WorkspaceYaml | undefined;
+
+  it.each([
+    ["post", POST_KEYS],
+    ["platform", PLATFORM_KEYS],
+  ] as const)("content-os (the SSOT) declares %s's Postiz keys as text", (slug, keys) => {
+    const p = profile(contentOs, slug);
+    expect(p, `content-os declares ${slug}`).toBeDefined();
+    for (const key of keys) expect(propertyOf(p, key)?.valueType, `${slug}.${key}`).toBe("string");
+  });
+
+  it("every template that re-declares post or platform with a Postiz field declares all of them, as text", () => {
+    let seen = 0;
+    for (const tpl of templates) {
+      for (const [slug, keys] of [
+        ["post", POST_KEYS],
+        ["platform", PLATFORM_KEYS],
+      ] as const) {
+        const p = profile(tpl, slug);
+        if (!p || !(p.properties ?? []).some((prop) => prop.slug.startsWith("postiz-"))) continue;
+        seen += 1;
+        for (const key of keys) expect(propertyOf(p, key)?.valueType, `${tpl.meta?.slug}: ${slug}.${key}`).toBe("string");
+      }
+    }
+    // content-os and social each declare both profiles.
+    expect(seen).toBeGreaterThanOrEqual(4);
+  });
+
+  it("the capability queues a post that can be written back: postiz_schedule_post serves publish_post and returns the ids", () => {
+    const verb = capability.spec.skills.find((s) => s.name === "postiz_schedule_post");
+    expect(verb?.intent).toBe("publish_post");
+    expect(verb?.kind).toBe("code");
+    // A write: an agent's run is a proposal (never metadata.readOnly). The pod's
+    // post-gate runner writes `result.postId` onto the post named by the
+    // `postEntityId` param (backend `metadata.writeBack` hook, lane pz-be).
+    expect(verb?.metadata).toEqual({
+      verbType: "write",
+      writeBack: { entityParam: "postEntityId", kind: "post", properties: { "postiz-post-id": "postId" } },
+    });
+    for (const p of ["content", "integrationId", "provider", "postEntityId"]) expect(Object.keys(verb?.parameters ?? {})).toContain(p);
+    expect(verb?.code).toMatch(/return \{ postId, integrationId, provider,[^}]*postEntityId/);
+    expect(capability.spec.provides).toContain("publish_post");
+  });
+
+  it("the channel list hands back what a platform stores: id and provider", () => {
+    const verb = capability.spec.skills.find((s) => s.name === "postiz_list_integrations");
+    expect(verb?.metadata).toEqual({ readOnly: true });
+    expect(verb?.providerSpec?.responseShape?.item).toMatchObject({ id: "id", provider: "identifier" });
+  });
+
+  it("Produce Content requires publish_post and queues at Scheduled", () => {
+    const pb = (contentOs?.playbooks ?? []).find((p: { name?: string }) => p.name === "Produce Content") as
+      | { requiredIntents?: string[]; stages?: Array<{ key: string; subjectStatus?: string; goal?: string }> }
+      | undefined;
+    expect(pb?.requiredIntents).toContain("publish_post");
+    const schedule = pb?.stages?.find((s) => s.key === "schedule");
+    expect(schedule?.subjectStatus).toBe("Scheduled");
+    expect(schedule?.goal).toContain("postiz_schedule_post");
+    expect(schedule?.goal).toContain("postiz-post-id");
+  });
+});
+
+// Intent actions (decision ef0e917c, 2026-10-28): a pod app asks the person's
+// Postiz to publish a post with ONE input `{ text, when? }`. Postiz holds one
+// key for several social channels, so each mapped verb names the channel list
+// as its account source; the pod offers one action per channel and refuses a
+// map whose source is not a read listing these fields.
+describe("Postiz — what a pod app may ask it to publish", () => {
+  const skill = (name: string) => capability.spec.skills.find((s) => s.name === name)!;
+
+  it.each(["postiz_schedule", "postiz_publish"])("%s maps the text and the channel picked from postiz_list_integrations", (name) => {
+    expect(skill(name).inputMap).toEqual(
+      expect.objectContaining({
+        params: expect.objectContaining({
+          content: "$.text",
+          integrationId: "$account.id",
+          provider: "$account.provider",
+        }),
+        accounts: { verb: "postiz_list_integrations", id: "id", label: "name", provider: "provider" },
+      }),
+    );
+  });
+
+  it("the account source lists the fields it names", () => {
+    const list = skill("postiz_list_integrations");
+    expect(list.metadata?.readOnly).toBe(true);
+    expect(Object.keys(list.providerSpec.responseShape.item)).toEqual(expect.arrayContaining(["id", "name", "provider"]));
+  });
+
+  it("only the scheduled post reads the time; publishing now never does", () => {
+    expect(skill("postiz_schedule").inputMap.params.date).toBe("$.when");
+    expect(skill("postiz_publish").inputMap.params).not.toHaveProperty("date");
+  });
+
+  it("drafts, uploads and the media post are not offered to apps (P1 maps text and time only)", () => {
+    for (const name of ["postiz_draft", "postiz_schedule_post", "postiz_upload_from_url"])
+      expect(skill(name).inputMap, name).toBeUndefined();
+  });
+});