@synap-core/workspace-templates 0.23.0 → 0.24.0

package/dist/wire.d.ts

@@ -1,4 +1,4 @@
-import { g as PackageDefinitionOutput, X as WorkspaceDefinitionInput } from './define-CPS0n8BV.js';
+import { g as PackageDefinitionOutput, X as WorkspaceDefinitionInput } from './define-DqoItRiR.js';
 import '@synap-core/types/presentation';
 import '@synap-core/types/space-brief';
 import '@synap-core/types/capability-intents';

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@synap-core/workspace-templates",
-  "version": "0.23.0",
+  "version": "0.24.0",
   "type": "module",
   "description": "Canonical workspace definitions — YAML source + typed exports for browser, backend, CLI, and marketplace",
   "repository": {
@@ -19,8 +19,8 @@
     },
     "./capabilities/*": "./capabilities/*",
     "./skills/*": "./skills/*",
-    "./packs/*": "./packs/*",
     "./automations/*": "./automations/*",
+    "./views/*": "./views/*",
     "./package.json": "./package.json"
   },
   "files": [
@@ -28,8 +28,8 @@
     "src",
     "capabilities",
     "skills",
-    "packs",
     "automations",
+    "views",
     "retired.yaml"
   ],
   "dependencies": {

package/skills/app-factory-design-review/SKILL.md

@@ -42,7 +42,13 @@ Prompt (fill the braces):
 > phone: navigation, thumb reach, what is missing that the person needs on the phone; (11) boards that must exist and
 > do not (a state, a detail page a door points to, a first run, an island), split P0 (needed to approve) and P1;
 > (12) the sample world: dates, names and counts that disagree between boards, and any words attributed to the person
-> that are not verbatim from the plan's real data. End with the three changes that would most improve the design.
+> that are not verbatim from the plan's real data; (13) every filter drawn as a row of chips instead of one chip
+> showing its value that opens a menu, and every page whose filters, tabs and search take more than one row; (14)
+> every panel that shows all its options at once instead of the current choice and one door, every later step drawn
+> before the earlier one is made, every option that cannot apply to this object, and every default pre-selected
+> without a declared one; (15) anything that contradicts the object's status (a made thing offering to be made, a
+> done step offered again, a primary that is not the next move for the status). End with the three changes that
+> would most improve the design.
 
 ## Lens 2 — component fidelity, contrast and responsive
 
@@ -89,7 +95,7 @@ Prompt:
    across boards · boards to add (P0, P1) · fidelity (the measured numbers and token mapping) · real data (the one
    sample world) · process notes. Content Studio's brief is the reference shape.
 5. Apply it yourself, as the only writer: edit `design-kit/src`, `pnpm design:build && pnpm design:check`, `pnpm
-   design:preview`, commit `src` + `out`, republish the canvas, and list every board changed or added.
+design:preview`, commit `src` + `out`, republish the canvas, and list every board changed or added.
 
 ## Verify pass
 

package/skills/design-critique/SKILL.md

@@ -87,6 +87,9 @@ make it explicit, and lower `confidence` when the class is ambiguous.
 | `pat.creation`          | object creation → `minimum then detail page` · `wizard`                                                                 | a multi-step wizard before the object exists is a defect                                                                                                                           | ui-rules "Cardinal rules" (object creation)          |
 | `pat.raw-token`         | each label naming a kind, action or status → `words` · `raw token`                                                      | a raw token (`entity.create`, `in_review`) shown to a person is a defect                                                                                                           | vocabulary.md "Cardinal rules"                       |
 | `pat.states-covered`    | screen states → which of `empty` · `loading` · `failed` · `full` · `long` the screen has, and which the design lays out | a state the screen has and the design omits is a defect                                                                                                                            | "Design to implementation", Generate                 |
+| `pat.filter-row`        | each filter → `one chip + menu` · `row of chips`; the controls → `one row` · `several rows`                             | a filter drawn as a row of chips (one per value), or filters, tabs and search spread over more than one row, is a defect                                                           | page-grammar §9 (decision afab5911)                  |
+| `pat.disclosure`        | each choice → `current choice + one door` · `every option shown`; each default → `declared` · `first item`              | every option shown at once, a later step drawn before its earlier one is made, an option that cannot apply offered, or a default nobody declared is a defect                       | ui-composition §12                                   |
+| `pat.status-follows`    | each action, label, section → `fits the status` · `contradicts the status`                                              | anything that contradicts the object's status (offers to make what exists, offers a step already done, primary not the next move) is a defect                                      | ui-composition §13                                   |
 
 A `pattern` failure is `major` by default; it is a `blocker` when it hides a failure from the reader
 (`pat.empty-answer` folding a failed read into empty) or leaves the reader no way to act

package/src/catalog-safety.test.ts

@@ -172,7 +172,7 @@ describe("(b) every skill reference resolves", () => {
 
 // ── (c) the content directories ship, the build reads none of them ─────────
 
-const CONTENT_DIRS = ["capabilities", "skills", "packs", "automations"];
+const CONTENT_DIRS = ["capabilities", "skills", "automations", "views"];
 
 describe("(c) catalog content ships in the npm bundle; the build reads only src/*.yaml", () => {
   const pkg = JSON.parse(readFileSync(join(PKG, "package.json"), "utf8"));

package/src/content-os.template.test.ts

@@ -320,3 +320,30 @@ describe("Content OS Repurpose proposes once per original, never for a copy", ()
     expect(post?.properties.map((d) => d.slug)).toContain("post-copy-of");
   });
 });
+
+// "Write the caption" (founder, 5 Nov): Content Studio's "Write it for me" runs it on ONE post. It drafts, never
+// decides: it writes the script's "## Caption draft" section, never the "## Caption" on its own; the person's yes to ONE
+// owed confirm ask (or their Save in the app) makes it the caption. It binds no stage and moves no status.
+describe("Content OS Write the caption drafts one post's caption, never the person's", () => {
+  const playbooks = (template.playbooks ?? []) as TemplatePlaybook[];
+  const caption = playbooks.find((p) => p.name === "Write the caption");
+
+  it("is a post's process, run by hand on one post (non-vacuity)", () => {
+    expect(caption?.subjectProfile?.profileSlug).toBe("post");
+    expect(caption?.params).toEqual([expect.objectContaining({ name: "post", type: "entity", required: true })]);
+    expect(caption?.goalTemplate).toContain("{post}");
+    expect(caption?.status).toBe("active");
+  });
+
+  it("writes the draft section only, never the saved caption, and never moves the status", () => {
+    expect(caption?.goalTemplate).toMatch(/"## Caption draft" section/);
+    expect(caption?.goalTemplate).toMatch(/Never write or change the "## Caption" section on\s+your own/);
+    // The person's approval is ONE owed confirm ask; only their yes makes the draft the caption.
+    expect(caption?.goalTemplate).toMatch(/ONE confirm ask on this session/);
+    expect(caption?.goalTemplate).toMatch(/On yes, put the draft in\s+the "## Caption" section/);
+    expect(caption?.goalTemplate).toMatch(/Never move the post's status/);
+    expect(caption?.stages ?? []).toEqual([]);
+    expect(caption?.activators ?? []).toEqual([]);
+    expect(caption?.expectedOutputs).toEqual([expect.objectContaining({ kind: "document", label: "Caption draft", relationToSubject: "none" })]);
+  });
+});

package/src/content-os.yaml

@@ -2397,6 +2397,49 @@ playbooks:
     executor: is-agent
     status: active
 
+  # One post's caption, on request (founder, 5 Nov: "something that writes the
+  # caption so I don't have to"). Content Studio's "Write it for me" on a post's
+  # Caption box runs it for that post. It writes a DRAFT, the script document's
+  # "## Caption draft" section, never the "## Caption" the person saved; the
+  # person approves it through ONE owed confirm ask (yes: the draft becomes the
+  # caption) or uses it in the app's Caption box and saves it there. It works
+  # one post but binds no stage and never moves the status.
+  - name: Write the caption
+    description: Draft the caption of one post from its brief and its script, as a draft in its script document that the person edits and saves.
+    goalTemplate: >-
+      Draft the caption of this post ({post}). Read the post: its hook
+      (post-hook), its call to action (post-cta), its pillar, its journey
+      stage, its platform (post-platform) and its format. Read its script, the
+      post's own document: its slides (the S1, S2 lines or the slide table)
+      and any caption already written under "## Caption". Write ONE caption in
+      the brand voice (the pod's brand kit) that says what the slides leave
+      out: a first line that stands on its own before the platform cuts it
+      (Instagram shows about 125 characters before "more", LinkedIn about 210
+      before "see more"), then two or three short lines, and the call to action
+      last. No hashtag wall, no emoji run, no claim the script does not make,
+      and no line that starts with "##". Put it in the script document as its
+      "## Caption draft" section: replace that section if it is there, else add
+      it at the end, and change no other line (synap_update_document with the
+      revision you read). Never write or change the "## Caption" section on
+      your own: it is the person's. Then ask the person to approve your draft:
+      ONE confirm ask on this session (owner the person), its prompt the
+      caption itself, "Use this caption" recommended. On yes, put the draft in
+      the "## Caption" section (replace its words, or add it) and remove the
+      "## Caption draft" section, nothing else. On no, leave the draft where it
+      is (they may edit it and save it on the post's page in Content Studio,
+      which also makes it the caption). Never move the post's status. Close
+      this session once the person answered.
+    subjectProfile:
+      profileSlug: post
+    # Typed output: the draft lives in the post's own script document (a
+    # section of it), so nothing new is created and there is no edge to add.
+    expectedOutputs:
+      - { kind: document, label: Caption draft, relationToSubject: none }
+    params:
+      - { name: post, type: entity, label: Post, required: true }
+    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

package/src/crm-messages-cadence.template.test.ts

@@ -28,7 +28,12 @@
 import { describe, expect, it } from "vitest";
 import { readYamlTemplates } from "./generate.mjs";
 import type { WorkspaceYaml } from "./types.js";
+import { readFileSync } from "node:fs";
+import { join } from "node:path";
 
+const unipile = JSON.parse(
+  readFileSync(join(import.meta.dirname, "..", "capabilities", "unipile-linkedin.capability.json"), "utf8"),
+) as { spec: { skills: Array<{ name: string }> } };
 const corpus = readYamlTemplates().map((t) => t.data as WorkspaceYaml);
 const crm = corpus.find((x) => x.meta.slug === "crm")!;
 const playbookOf = (name: string) => {
@@ -47,8 +52,22 @@ const stageOf = (name: string, key: string) => {
 const CADENCE =
   'CADENCE: when a message is sent (a person approved its proposed message, so it is an outbound message in the channel), set its lead\'s lastContactedAt to the sent day, count the messages sent to the lead (the outbound messages in its channels, read with synap_get_channel mode person: for a company lead, the channels of the person written to there), and set the lead\'s next action: after the first message, nextAction "Follow up with <name> if no reply" and nextActionAt the sent day + 3 days; after the first follow-up, nextAction "Follow up with <name> a last time if no reply" and nextActionAt the sent day + 7 days; after the second follow-up, nextAction "No reply after two follow-ups: nurture or drop <name>" and nextActionAt the sent day + 7 days, and when that date passes with no reply, "Follow up on leads in outreach" proposes nurturing. Never a third follow-up. Propose moving a lead at new or researching to outreach through the status door, with its expected status. A reply stops the cadence: a reply is an inbound message after our last outbound one in the channel, and "Follow up on leads in outreach" reads it and proposes the next step.';
 
+/**
+ * The LinkedIn order (CRM wave 2, S4b, build map 6f6c197f; changed by the CRM
+ * Messages contract b4f8c2cd, decision b603d75e, build map ca310f27): a
+ * LinkedIn message is drafted WHATEVER the person's reach. The pod holds a
+ * first message to someone not connected when it is filed (backend#818,
+ * `data.held`) instead of refusing it (backend#786), so a drafter that held a
+ * draft back left the person with nothing to see. Find the profile and ask to
+ * connect still go alongside the draft. Part of the DRAFT RULES paragraph, so
+ * it is word for word the same in every drafter.
+ */
+const LINKEDIN_ORDER =
+  'A LinkedIn message is drafted whatever their reach: the pod holds a draft to someone who is not a connection yet, shows it with the next step and lets it go out once they connect, so never hold a draft back for want of a connection. Draft it, then, in this order: (1) a person with no linkedinUrl: find their profile with linkedin_find_profile (their full name and company); on a match, propose its linkedinUrl and linkedinProviderId on the person for a person to approve; on none or several, ask the person to choose among its candidates (the process "Find their LinkedIn" does this for one lead). (2) Read their linkedinConnection, which only the pod writes (never set it or linkedinInvitedAt): connected, nothing more; none or not set, ask to connect with linkedin_send_invite (it refuses someone already connected or already invited: then nothing more); pending, the draft waits for them; ignored, draft by email instead when they have an email address. While the draft waits for them to connect, set the lead\'s nextAction to "Wait for <name> to accept the LinkedIn request" and its nextActionAt 7 days later. An email message needs none of this.';
+
 const DRAFT_RULES =
-  "DRAFT RULES: each draft is one proposed message in the channel of the person it is written to, filed through the pod's send door: run messaging.send with to = that person's entity id (for a company lead, its decider: when that person is not in the pod, create them through the entity door with only their own fields, such as name, role and LinkedIn URL, never the company's website, domain or email), text = the message, and provider linkedin or email. Read their channel first (synap_get_channel, mode person) for what was already said. The pod files it for a person to review in that channel; it goes out only once they approve it. Never call a tool's own send verb (Unipile, Gmail), never create an outreach touch, a note or a task holding the message, and never use synap_capture for it. Never send.";
+  "DRAFT RULES: each draft is one proposed message in the channel of the person it is written to, filed through the pod's send door: run messaging.send with to = that person's entity id (for a company lead, its decider: when that person is not in the pod, create them through the entity door with only their own fields, such as name, role and LinkedIn URL, never the company's website, domain or email), text = the message, and provider linkedin or email. Read their channel first (synap_get_channel, mode person) for what was already said. The pod files it for a person to review in that channel; it goes out only once they approve it. Never call a tool's own send verb (Unipile, Gmail), never create an outreach touch, a note or a task holding the message, and never use synap_capture for it. Never send. " +
+  LINKEDIN_ORDER;
 
 /** What a drafter yields: a `messaging.external.send` proposal (target type `messaging`). */
 const PROPOSED_MESSAGE = "messaging";
@@ -161,4 +180,67 @@ describe("CRM messages and cadence — catalog contract", () => {
     expect(goal).not.toMatch(/14 days/);
     expect(flat(stageOf(name, "no-response").goal)).toMatch(/after the second follow-up propose moving the lead to nurturing/);
   });
+  it("the LinkedIn order: draft whatever their reach (the pod holds it), find the profile, ask to connect; the reach fields stay the pod's", () => {
+    for (const part of [
+      "A LinkedIn message is drafted whatever their reach",
+      "never hold a draft back for want of a connection",
+      "find their profile with linkedin_find_profile",
+      "propose its linkedinUrl and linkedinProviderId on the person for a person to approve",
+      "ask the person to choose among its candidates",
+      "never set it or linkedinInvitedAt",
+      "ask to connect with linkedin_send_invite",
+      "pending, the draft waits for them",
+      "ignored, draft by email instead",
+      "An email message needs none of this.",
+    ])
+      expect(LINKEDIN_ORDER).toContain(part);
+    for (const name of DRAFTERS) {
+      expect(goalOf(name), name).toContain(LINKEDIN_ORDER);
+      // Decision b603d75e (B): a draft is never held back for want of a connection.
+      // (A reply still gets no draft: "With a reply, draft nothing" stays, it is not about reach.)
+      for (const gone of ["goes only to a connection", "linkedin_send_invite and draft nothing", "wait and draft nothing", "candidates, or stop"])
+        expect(goalOf(name), `${name}: ${gone}`).not.toContain(gone);
+    }
+    // Every catalog verb the order names is a verb of the Unipile capability:
+    // a renamed or removed verb would leave the drafters calling nothing.
+    const named = [...LINKEDIN_ORDER.matchAll(/\b(linkedin_[a-z_]+)\b/g)].map((m) => m[1]);
+    expect(named.sort()).toEqual(["linkedin_find_profile", "linkedin_send_invite"]);
+    const verbs = unipile.spec.skills.map((s) => s.name);
+    for (const v of named) expect(verbs, v).toContain(v);
+    // The system person kind owns the reach fields (backend#786, machine-written):
+    // the CRM never declares them, so no CRM editor offers them.
+    const person = crm.profiles?.find((p) => p.slug === "person");
+    expect(person, "crm declares the person overlay").toBeTruthy();
+    const slugs = (person?.properties ?? []).map((p) => p.slug);
+    expect(slugs).toContain("linkedinUrl");
+    expect(slugs).not.toContain("linkedinConnection");
+    expect(slugs).not.toContain("linkedinInvitedAt");
+  });
+
+  it("'Find their LinkedIn': one lead, linkedin_find_profile, a proposal or up to 3 candidates, nothing sent", () => {
+    const name = "Find their LinkedIn";
+    const pb = playbookOf(name);
+    expect(pb.subjectProfile?.profileSlug).toBe("lead");
+    // The CRM app starts it for one lead, as "Draft a first message": params.lead.
+    expect(pb.params?.find((p) => p.name === "lead")).toMatchObject({ type: "entity", required: true });
+    expect(pb.params?.find((p) => p.name === "lead")).toEqual(playbookOf("Draft a first message").params?.find((p) => p.name === "lead"));
+    expect(pb.requiredIntents).toEqual(["enrich_entity"]);
+    const goal = goalOf(name);
+    expect(goal).toContain("run linkedin_find_profile with their full name, their company");
+    expect(goal).toContain("propose its linkedinUrl and linkedinProviderId on the person");
+    expect(goal).toContain("at most 3");
+    expect(goal).toContain("never set linkedinConnection or linkedinInvitedAt");
+    // A reader: it never asks to connect nor drafts (those are the other steps).
+    const named = [...goal.matchAll(/\b((?:linkedin|unipile)_[a-z_]+)\b/g)].map((m) => m[1]);
+    expect(named.sort()).toEqual(["linkedin_find_profile", "unipile_list_accounts"]);
+    const verbs = unipile.spec.skills.map((s) => s.name);
+    for (const v of named) expect(verbs, v).toContain(v);
+    // The verb it runs answers the intent it requires.
+    const find = (unipile.spec.skills as Array<{ name: string; intent?: string }>).find((s) => s.name === "linkedin_find_profile");
+    expect(find?.intent).toBe("enrich_entity");
+    // The person decides what lands on the person.
+    expect(stageOf(name, "confirm").gate).toEqual({ kind: "human" });
+    // The drafters point at it by its exact name.
+    expect(LINKEDIN_ORDER).toContain(`the process "${name}"`);
+  });
 });

package/src/crm.yaml

@@ -1398,7 +1398,24 @@ playbooks:
       pod files it for a person to review in that channel; it goes out only
       once they approve it. Never call a tool's own send verb (Unipile,
       Gmail), never create an outreach touch, a note or a task holding the
-      message, and never use synap_capture for it. Never send. Its message
+      message, and never use synap_capture for it. Never send.
+      A LinkedIn message is drafted whatever their reach: the pod holds a
+      draft to someone who is not a connection yet, shows it with the next
+      step and lets it go out once they connect, so never hold a draft back
+      for want of a connection. Draft it, then, in this order: (1) a person
+      with no linkedinUrl: find their profile with linkedin_find_profile
+      (their full name and company); on a match, propose its linkedinUrl and
+      linkedinProviderId on the person for a person to approve; on none or
+      several, ask the person to choose among its candidates (the process
+      "Find their LinkedIn" does this for one lead). (2) Read their
+      linkedinConnection, which only the pod writes (never set it or
+      linkedinInvitedAt): connected, nothing more; none or not set, ask to
+      connect with linkedin_send_invite (it refuses someone already connected
+      or already invited: then nothing more); pending, the draft waits for
+      them; ignored, draft by email instead when they have an email address.
+      While the draft waits for them to connect, set the lead's nextAction to
+      "Wait for <name> to accept the LinkedIn request" and its nextActionAt 7
+      days later. An email message needs none of this. Its message
       is personal: it cites the buying signal and what it showed, or a past
       exchange, never a generic template; short; in the person's language,
       French by default, and in French it says vous. It offers one useful
@@ -1452,7 +1469,7 @@ playbooks:
           # A judge: no core or catalog verb reads a session's proposals and
           # answers {passed}, so the pod has no exact check for this yet.
           - key: first-message-one-draft
-            statement: One proposed message, filed through messaging.send to the person written to (for a company, its decider), waits for review in that person's channel, holds the message text, and follows the campaign's angle when one was given.
+            statement: One proposed message, filed through messaging.send to the person written to (for a company, its decider), waits for review in that person's channel, holds the message text, and follows the campaign's angle when one was given, whatever the person's LinkedIn reach; on LinkedIn to someone not yet a connection, the pod holds it, and their profile is found and the connection asked for or awaited, in the DRAFT RULES order.
             check: { kind: judge }
           - key: first-message-no-capture
             statement: No tool's own send verb was called, no outreach touch, note or task holds the message, no record was made with synap_capture, and a decider created for a company lead carries only the person's own fields, never the company's website, domain or email.
@@ -1473,6 +1490,61 @@ playbooks:
         gate: { kind: human }
         onFail: { toStage: draft }
 
+  # ── Find their LinkedIn — one lead's LinkedIn profile ───────────────────
+  # CRM Messages contract (decision b603d75e, build map ca310f27): the first of
+  # the steps a LinkedIn lead walks (Find their LinkedIn, Ask to connect,
+  # Waiting, Send). linkedin_find_profile is a read with no inputMap, so the
+  # actions door cannot run it for the CRM app: the app starts this process
+  # for one lead (`params.lead`, as "Draft a first message"). On a strict match
+  # it PROPOSES linkedinUrl and linkedinProviderId on the person; on none or
+  # several it hands the person up to 3 candidates. The reach fields stay the
+  # pod's (backend#786). A lifecycle READER of leadStage: no stage moves.
+  - name: Find their LinkedIn
+    description: Find one lead's LinkedIn profile by their full name and company and propose its URL and member id on the person for a person to approve, or offer up to 3 candidates to choose from; nothing is sent.
+    goalTemplate: >-
+      Find the LinkedIn profile of the lead {lead}. WHO: a person lead is
+      looked up themselves; for a company lead, the person who decides there,
+      from the pod; when no decider is known, ask the person who it is. When
+      that person already has a linkedinUrl, say so and stop. FIND: run
+      linkedin_find_profile with their full name, their company and the
+      LinkedIn account unipile_list_accounts lists (when several are
+      connected, ask the person which one reads). On a match, propose its
+      linkedinUrl and linkedinProviderId on the person through the entity
+      door, for a person to approve; never write them directly, and never set
+      linkedinConnection or linkedinInvitedAt, which only the pod writes. On
+      none, several or more results than it read, ask the person to choose
+      among its candidates (at most 3, each with its name, headline and
+      profile URL) or to give the URL themselves, then propose the one chosen
+      the same way. Never send a message or a connection request, never draft
+      one, and never move the lead's stage.
+    subjectProfile:
+      profileSlug: lead
+    activators:
+      - { on: manual, mode: propose }
+    params:
+      - { name: lead, type: entity, label: Lead, required: true }
+    executor: is-agent
+    status: active
+    requiredIntents: [enrich_entity]
+    stages:
+      - key: find
+        name: Find the profile
+        category: started
+        goal: Run linkedin_find_profile for the lead (a company lead's decider) with their full name and company; on a match propose linkedinUrl and linkedinProviderId on the person, otherwise ask the person to choose among up to 3 candidates or give the URL.
+        criteria:
+          - key: find-linkedin-proposed
+            statement: The person's linkedinUrl and linkedinProviderId are proposed on them for a person to approve (a strict match, or the candidate the person chose), or the person was asked to choose among at most 3 candidates; nothing was written directly.
+            check: { kind: judge }
+          - key: find-linkedin-reader-only
+            statement: No message or connection request was sent or drafted, linkedinConnection and linkedinInvitedAt were not set, and the lead's stage was not moved.
+            check: { kind: judge }
+      - key: confirm
+        name: Person confirms
+        category: completed
+        goal: The person approves the proposed profile, or picks a candidate or gives the URL, and the pod stores linkedinUrl and linkedinProviderId on the person; the lead's next step is then to ask to connect.
+        gate: { kind: human }
+        onFail: { toStage: find }
+
   # ── Follow up on leads in outreach — THE one follow-up process ───────────
   # CRM build plan A6 (founder Q4). A batch worker: each weekday it reads the
   # channels of the leads in outreach. Due with no reply, it drafts one message
@@ -1534,7 +1606,24 @@ playbooks:
       files it for a person to review in that channel; it goes out only once
       they approve it. Never call a tool's own send verb (Unipile, Gmail),
       never create an outreach touch, a note or a task holding the message,
-      and never use synap_capture for it. Never send. For each draft, set
+      and never use synap_capture for it. Never send.
+      A LinkedIn message is drafted whatever their reach: the pod holds a
+      draft to someone who is not a connection yet, shows it with the next
+      step and lets it go out once they connect, so never hold a draft back
+      for want of a connection. Draft it, then, in this order: (1) a person
+      with no linkedinUrl: find their profile with linkedin_find_profile
+      (their full name and company); on a match, propose its linkedinUrl and
+      linkedinProviderId on the person for a person to approve; on none or
+      several, ask the person to choose among its candidates (the process
+      "Find their LinkedIn" does this for one lead). (2) Read their
+      linkedinConnection, which only the pod writes (never set it or
+      linkedinInvitedAt): connected, nothing more; none or not set, ask to
+      connect with linkedin_send_invite (it refuses someone already connected
+      or already invited: then nothing more); pending, the draft waits for
+      them; ignored, draft by email instead when they have an email address.
+      While the draft waits for them to connect, set the lead's nextAction to
+      "Wait for <name> to accept the LinkedIn request" and its nextActionAt 7
+      days later. An email message needs none of this. For each draft, set
       the lead's `nextAction` to send it (e.g. "Send the drafted message to
       Ana on LinkedIn") and `nextActionAt` to today. The person reviews each
       proposed message in its channel, edits it if needed and approves it;
@@ -1635,7 +1724,25 @@ playbooks:
       channel; it goes out only once they approve it. Never call a tool's own
       send verb (Unipile, Gmail), never create an outreach touch, a note or a
       task holding the message, and never use synap_capture for it. Never
-      send. START: a person approves the audience, the offer and the list,
+      send.
+      A LinkedIn message is drafted whatever their reach: the pod holds a
+      draft to someone who is not a connection yet, shows it with the next
+      step and lets it go out once they connect, so never hold a draft back
+      for want of a connection. Draft it, then, in this order: (1) a person
+      with no linkedinUrl: find their profile with linkedin_find_profile
+      (their full name and company); on a match, propose its linkedinUrl and
+      linkedinProviderId on the person for a person to approve; on none or
+      several, ask the person to choose among its candidates (the process
+      "Find their LinkedIn" does this for one lead). (2) Read their
+      linkedinConnection, which only the pod writes (never set it or
+      linkedinInvitedAt): connected, nothing more; none or not set, ask to
+      connect with linkedin_send_invite (it refuses someone already connected
+      or already invited: then nothing more); pending, the draft waits for
+      them; ignored, draft by email instead when they have an email address.
+      While the draft waits for them to connect, set the lead's nextAction to
+      "Wait for <name> to accept the LinkedIn request" and its nextActionAt 7
+      days later. An email message needs none of this. START: a person approves the audience, the offer and
+      the list,
       then reviews each proposed message in its channel and approves it;
       nothing goes out before they approve it, and the agent never sends.
       Once a message is sent, follow the cadence, so "Follow up on leads in

package/src/define.ts

@@ -272,6 +272,8 @@ export interface WorkspaceDefinitionInput {
   proposalId?: string;
   profiles: WorkspaceYaml['profiles'];
   views: NonNullable<WorkspaceYaml['views']>;
+  /** Template documents — created by the pod with the views (`utils/template-documents.ts`). */
+  documents?: WorkspaceYaml['documents'];
   entityLinks: NonNullable<WorkspaceYaml['entityLinks']>;
   seedEntities: NonNullable<WorkspaceYaml['seedEntities']>;
   suggestedRelations?: WorkspaceYaml['suggestedRelations'];
@@ -444,6 +446,9 @@ export function toWorkspaceDefinition(
     proposalId,
     profiles: tpl.profiles,
     views: tpl.views ?? [],
+    // Absent when the template has none, so a template without documents
+    // compiles to the same definition (and content hash) as before.
+    ...(tpl.documents?.length ? { documents: tpl.documents } : {}),
     entityLinks: tpl.entityLinks ?? [],
     seedEntities: tpl.seedEntities ?? [],
     suggestedRelations: tpl.suggestedRelations,
@@ -528,6 +533,7 @@ type WorkspaceDefinitionForwarded =
   | 'workspace'     // flattened into workspaceName/description/workspaceType/…
   | 'profiles'
   | 'views'
+  | 'documents'     // → carried verbatim; created with the views by the pod
   | 'entityLinks'
   | 'seedEntities'
   | 'suggestedRelations'
@@ -644,6 +650,14 @@ export interface PackageDefinitionOutput {
   defaultSources?: WorkspaceYaml['workspace']['defaultSources'];
   profiles: WorkspaceYaml['profiles'];
   views: NonNullable<WorkspaceYaml['views']>;
+  /**
+   * Template documents — created by the pod with the views
+   * (`utils/template-documents.ts`); the Hub `PackageApplySchema` slots them.
+   * The CP publish door does NOT yet (it strips the field and refuses a
+   * `kind: "document"` sidebar item), so no official template may declare
+   * documents until it does.
+   */
+  documents?: WorkspaceYaml['documents'];
   suggestedEntities: NonNullable<WorkspaceYaml['seedEntities']>;
   suggestedRelations?: WorkspaceYaml['suggestedRelations'];
   displayTemplates?: WorkspaceYaml['displayTemplates'];
@@ -744,6 +758,7 @@ export function toPackageDefinition(
     defaultSources: ws.defaultSources,
     profiles: tpl.profiles,
     views: tpl.views ?? [],
+    ...(tpl.documents?.length ? { documents: tpl.documents } : {}),
     suggestedEntities: tpl.seedEntities ?? [],
     suggestedRelations: tpl.suggestedRelations,
     displayTemplates: tpl.displayTemplates,
@@ -780,6 +795,7 @@ type PackageDefinitionForwarded =
   | 'workspace'     // flattened into workspaceName/description/workspaceType/…
   | 'profiles'
   | 'views'
+  | 'documents'     // → carried verbatim (Hub PackageApplySchema slots it)
   | 'seedEntities'  // → suggestedEntities
   | 'suggestedRelations'
   | 'displayTemplates'

package/src/reserved-profile-slugs.test.ts

@@ -12,8 +12,8 @@
  * synap-backend checkout and skips, with the reason logged, when it is absent.
  */
 
-import { existsSync, readdirSync, readFileSync } from "node:fs";
-import { dirname, join, resolve } from "node:path";
+import { existsSync } from "node:fs";
+import { dirname, resolve } from "node:path";
 import { fileURLToPath } from "node:url";
 import { describe, expect, it } from "vitest";
 import { RESERVED_PROFILE_SLUGS, validateTemplate } from "./validate.js";
@@ -54,18 +54,16 @@ describe("profile-slug-reserved", () => {
     expect(errors).toEqual([]);
   });
 
-  it("no shipped template or pack declares a reserved slug", () => {
-    const yamls = readYamlTemplates().map((t) => ({ file: `src/${t.file}`, data: t.data }));
-    const packs = readdirSync(join(PKG, "packs"))
-      .filter((f) => f.endsWith(".json"))
-      .map((f) => ({ file: `packs/${f}`, data: JSON.parse(readFileSync(join(PKG, "packs", f), "utf8")) }));
+  // Profiles are declared only by workspace YAMLs: the CP pack fragments that
+  // also declared them were retired (catalog-lib refuses a `_meta` fragment).
+  it("no shipped template declares a reserved slug", () => {
+    const yamls = readYamlTemplates().map((t) => ({ file: `src/${t.file}`, data: t.data as WorkspaceYaml }));
     // Non-vacuity: the scan sees the corpus, and the corpus declares profiles.
     expect(yamls.length).toBeGreaterThan(20);
-    expect(packs.length).toBeGreaterThan(2);
-    const declared = [...yamls, ...packs].flatMap((t) => (t.data?.profiles ?? []).map((p: { slug: string }) => p.slug));
+    const declared = yamls.flatMap((t) => (t.data?.profiles ?? []).map((p: { slug: string }) => p.slug));
     expect(declared.length).toBeGreaterThan(100);
 
-    const offenders = [...yamls, ...packs].flatMap((t) =>
+    const offenders = yamls.flatMap((t) =>
       reservedErrors(t.data as WorkspaceYaml).map((e) => `${t.file}: ${e.path}`)
     );
     expect(offenders).toEqual([]);

package/src/retired-goal-kinds.test.ts

@@ -13,14 +13,9 @@
  * goal links to the pod's goals (tracks); it never re-declares the kind.
  */
 
-import { readdirSync, readFileSync } from "node:fs";
-import { dirname, join, resolve } from "node:path";
-import { fileURLToPath } from "node:url";
 import { describe, expect, it } from "vitest";
 import { readYamlTemplates } from "./generate.mjs";
 
-const PKG = resolve(dirname(fileURLToPath(import.meta.url)), "..");
-
 const RETIRED_GOAL_KINDS = ["goal", "objective", "okr"] as const;
 
 type Declared = { slug?: string };
@@ -43,16 +38,15 @@ describe("retired goal-like kinds", () => {
     expect(retiredKindsDeclared(probe)).toEqual(["probe.yaml:  OKR ", "probe2.yaml: goal", "probe2.yaml: objective"]);
   });
 
-  it("no shipped workspace template or pack declares one", () => {
-    const yamls: Corpus[] = readYamlTemplates().map((t) => ({ file: `src/${t.file}`, data: t.data }));
-    const packs: Corpus[] = readdirSync(join(PKG, "packs"))
-      .filter((f) => f.endsWith(".json"))
-      .map((f) => ({ file: `packs/${f}`, data: JSON.parse(readFileSync(join(PKG, "packs", f), "utf8")) }));
+  // Profiles are declared only by workspace YAMLs: the CP pack fragments that
+  // also declared them were retired (catalog-lib refuses a `_meta` fragment).
+  it("no shipped workspace template declares one", () => {
+    const yamls: Corpus[] = readYamlTemplates().map((t) => ({ file: `src/${t.file}`, data: t.data as Corpus["data"] }));
     // Non-vacuity: the scan reads the corpus, and the corpus declares profiles.
     expect(yamls.length).toBeGreaterThan(20);
-    const declared = [...yamls, ...packs].flatMap((t) => t.data?.profiles ?? []);
+    const declared = yamls.flatMap((t) => t.data?.profiles ?? []);
     expect(declared.length).toBeGreaterThan(100);
 
-    expect(retiredKindsDeclared([...yamls, ...packs])).toEqual([]);
+    expect(retiredKindsDeclared(yamls)).toEqual([]);
   });
 });