@synap-core/workspace-templates 0.7.1 → 0.7.3

package/src/concept-guard.test.ts

@@ -0,0 +1,176 @@
+/**
+ * Concept-guard tests.
+ *
+ * The first test is the gate: the SHIPPED corpus must be free of undeclared
+ * vocabulary forks. The rest prove the guard actually fires — a guard nobody
+ * has watched fail is decoration, so the failure cases are pinned here rather
+ * than demonstrated once by hand and forgotten.
+ */
+
+import { describe, expect, it } from "vitest";
+import {
+  DECLARED_DIVERGENCES,
+  conceptTerm,
+  findConceptViolations,
+  formatConceptViolations,
+} from "./concept-guard.js";
+import { WORKSPACE_TEMPLATES } from "./templates.js";
+import type { WorkspaceYaml } from "./types.js";
+
+/** Minimal fixture corpus — only the fields the guard reads. */
+function corpus(
+  templates: Record<string, Array<Record<string, unknown>>>
+): Record<string, WorkspaceYaml> {
+  return Object.fromEntries(
+    Object.entries(templates).map(([slug, profiles]) => [slug, { profiles }])
+  ) as unknown as Record<string, WorkspaceYaml>;
+}
+
+const role = (slug: string, extra: Record<string, unknown> = {}) => ({
+  slug,
+  displayName: slug,
+  profileKind: "role",
+  properties: [],
+  ...extra,
+});
+
+describe("concept guard — shipped corpus", () => {
+  it("has no undeclared cross-template concept forks", () => {
+    const violations = findConceptViolations();
+    expect(
+      violations,
+      violations.length ? `\n${formatConceptViolations(violations)}\n` : ""
+    ).toEqual([]);
+  });
+
+  it("still sees the two-tier CRM divergence — declared, not absent", () => {
+    // If business-developer's crm-lead/crm-client ever stopped colliding with
+    // foundation's lead/client, the allowlist would be stale and rule 3 would
+    // fire. This asserts the allowlist is load-bearing, not inert.
+    const withoutAllowlist = Object.keys(DECLARED_DIVERGENCES);
+    expect(withoutAllowlist).toEqual(["crm-lead|lead", "client|crm-client"]);
+    expect(WORKSPACE_TEMPLATES["business-developer"]?.profiles.find((p) => p.slug === "crm-lead")
+      ?.semanticSlug).toBe("crm.lead");
+  });
+});
+
+describe("conceptTerm", () => {
+  it("reduces a qualified concept identifier to its bare noun", () => {
+    expect(conceptTerm("lead")).toBe("lead");
+    expect(conceptTerm("crm.lead")).toBe("lead");
+    expect(conceptTerm("crm-lead")).toBe("lead");
+    expect(conceptTerm("marketing.contact")).toBe("contact");
+  });
+});
+
+describe("concept guard — fires on a real fork", () => {
+  it("fails when a second template renames an existing role concept", () => {
+    const violations = findConceptViolations(
+      corpus({
+        foundation: [role("partner", { scope: "shared", applicableKinds: ["company"] })],
+        "some-addon": [role("channel-partner", { scope: "WORKSPACE" })],
+      })
+    );
+    // Fixture corpora never match the real allowlist, so the stale-allowlist
+    // findings are expected noise here — the collision is what is under test.
+    const forks = violations.filter((v) => v.rule !== "stale-allowlist");
+    expect(forks).toHaveLength(1);
+    expect(forks[0]!.rule).toBe("concept-collision");
+    expect(forks[0]!.concept).toBe("partner");
+    expect(forks[0]!.message).toContain("channel-partner");
+  });
+
+  it("suppresses exactly the pair an author declared — and nothing else", () => {
+    // The SAME shape as the test above, but with the slugs the allowlist names.
+    // This is the whole safety property of the escape hatch: it is per-pair, not
+    // per-concept, so a THIRD `lead` spelling would still fail.
+    const declared = findConceptViolations(
+      corpus({
+        foundation: [role("lead", { scope: "shared" })],
+        "business-developer": [role("crm-lead", { semanticSlug: "crm.lead", scope: "WORKSPACE" })],
+      })
+    );
+    expect(declared.filter((v) => v.rule === "concept-collision")).toEqual([]);
+
+    const third = findConceptViolations(
+      corpus({
+        foundation: [role("lead", { scope: "shared" })],
+        "business-developer": [role("crm-lead", { semanticSlug: "crm.lead", scope: "WORKSPACE" })],
+        "another-addon": [role("sales-lead", { scope: "WORKSPACE" })],
+      })
+    );
+    expect(third.filter((v) => v.rule === "concept-collision")).toHaveLength(2);
+  });
+
+  it("fires even when the fork hides behind a namespaced semanticSlug", () => {
+    const violations = findConceptViolations(
+      corpus({
+        foundation: [role("lead")],
+        other: [role("pipeline-lead", { semanticSlug: "sales.lead" })],
+      })
+    );
+    expect(violations.filter((v) => v.rule !== "stale-allowlist").map((v) => v.rule)).toEqual([
+      "concept-collision",
+    ]);
+  });
+
+  it("fails when two aliased profiles disagree on shape", () => {
+    const violations = findConceptViolations(
+      corpus({
+        a: [role("campaign", { semanticSlug: "marketing.campaign", scope: "shared" })],
+        b: [role("promo", { semanticSlug: "marketing.campaign", scope: "WORKSPACE" })],
+      })
+    );
+    expect(violations.map((v) => v.rule)).toContain("alias-shape-divergence");
+  });
+
+  it("fails when an allowlist entry stops matching anything", () => {
+    // DECLARED_DIVERGENCES is module-level, so an empty corpus makes every
+    // entry stale — exactly the state a resolved divergence would leave behind.
+    const violations = findConceptViolations(corpus({}));
+    expect(violations.every((v) => v.rule === "stale-allowlist")).toBe(true);
+    expect(violations).toHaveLength(Object.keys(DECLARED_DIVERGENCES).length);
+  });
+});
+
+describe("concept guard — stays green on legitimate patterns", () => {
+  it("allows the same slug re-declared across templates (overlay mechanism)", () => {
+    const violations = findConceptViolations(
+      corpus({
+        foundation: [role("lead", { scope: "shared", applicableKinds: ["person", "company"] })],
+        // A consumer legitimately OMITS row-level fields it does not own.
+        marketing: [role("lead", { scope: "shared" })],
+      })
+    );
+    expect(violations.filter((v) => v.rule !== "stale-allowlist")).toEqual([]);
+  });
+
+  it("allows sibling roles authored in ONE template to share a noun", () => {
+    const violations = findConceptViolations(
+      corpus({
+        "blockchain-ecosystem": [role("marketing-agency"), role("paid-ads-agency")],
+      })
+    );
+    expect(violations.filter((v) => v.rule !== "stale-allowlist")).toEqual([]);
+  });
+
+  it("allows an identical concept reused under one semanticSlug", () => {
+    const violations = findConceptViolations(
+      corpus({
+        "content-os": [role("campaign", { semanticSlug: "marketing.campaign", scope: "shared" })],
+        marketing: [role("campaign", { semanticSlug: "marketing.campaign", scope: "shared" })],
+      })
+    );
+    expect(violations.filter((v) => v.rule !== "stale-allowlist")).toEqual([]);
+  });
+
+  it("does not police non-role profiles", () => {
+    const violations = findConceptViolations(
+      corpus({
+        a: [{ slug: "note", displayName: "Note", properties: [] }],
+        b: [{ slug: "meeting-note", displayName: "Meeting Note", properties: [] }],
+      })
+    );
+    expect(violations.filter((v) => v.rule !== "stale-allowlist")).toEqual([]);
+  });
+});

package/src/concept-guard.ts

@@ -0,0 +1,219 @@
+/**
+ * Cross-template CONCEPT guard — catches vocabulary forks between templates.
+ *
+ * WHY THIS EXISTS (read before weakening or deleting it):
+ * `business-developer.yaml` introduced workspace-scoped `crm-lead`/`crm-client`
+ * for the same real-world concept that `foundation.yaml`/`crm.yaml` declare as
+ * pod-wide shared `lead`/`client`. Nothing failed. Three reasons:
+ *
+ *   1. `build.mjs`'s `validate()` runs PER FILE, inside the read loop, so it
+ *      structurally cannot see that another template already owns `lead`.
+ *   2. The only vocabulary rule that exists (`template-shared-role-ssot.test.ts`
+ *      in synap-backend) polices a HARDCODED five-slug set — and it FORBIDS
+ *      declaring one of those slugs workspace-scoped, which is exactly what the
+ *      two-tier design legitimately needed. So RENAMING was the path of least
+ *      resistance: `crm-lead` is outside the set and passes silently. That rule
+ *      polices SPELLING, not MEANING.
+ *   3. That test also cannot run in CI — it resolves this package across a
+ *      sibling-repo relative path that CI never checks out. It is green on a dev
+ *      machine and mute everywhere else.
+ *
+ * This guard lives HERE, in the repo that owns the template source, and runs in
+ * this repo's CI (`pnpm test`) and in `pnpm build` / `prepublishOnly` via
+ * `scripts/check-concepts.mjs`. It is deliberately NOT a hardcoded slug list —
+ * that is the pattern that failed.
+ *
+ * WHAT IT DOES NOT DO: it does not guess. There is no fuzzy name matching, no
+ * edit distance, no synonym table. A guesser nobody trusts is worse than no
+ * guard. It uses two exact, falsifiable signals only — see the rules below.
+ */
+
+import { WORKSPACE_TEMPLATES } from "./templates.js";
+import type { TemplateProfile, WorkspaceYaml } from "./types.js";
+
+export interface ConceptViolation {
+  rule: "concept-collision" | "alias-shape-divergence" | "stale-allowlist";
+  /** The concept term or semantic slug the finding is about. */
+  concept: string;
+  message: string;
+}
+
+/**
+ * DECLARED, INTENTIONAL divergences — the escape hatch, and deliberately the
+ * SECONDARY mechanism. An entry here is an author saying "yes, two spellings of
+ * one concept, on purpose, and here is why". Keep it tiny; every entry must
+ * carry its WHY. A key that stops matching anything FAILS the guard, so this
+ * list cannot rot into a graveyard.
+ *
+ * Key = the two colliding profile slugs, sorted, joined by "|".
+ */
+export const DECLARED_DIVERGENCES: Record<string, string> = {
+  // Two-tier lead vocabulary, documented at business-developer.yaml:1-16.
+  // Foundation's `lead` is a SHARED pod-wide role: being a lead is true
+  // everywhere. `crm-lead` is a WORKSPACE-scoped role so a person can be a lead
+  // inside one CRM workspace without becoming a lead across the whole pod. The
+  // tiers are intentionally separate rows; `semanticSlug: crm.lead` records the
+  // kinship so the two are discoverable as one concept via getBySemanticSlug.
+  "crm-lead|lead":
+    "business-developer: workspace-tier lead, deliberately NOT pod-wide foundation `lead` (two-tier CRM design)",
+  // Same reasoning for the post-sale side of the same lifecycle.
+  "client|crm-client":
+    "business-developer: workspace-tier client, deliberately NOT pod-wide foundation `client` (two-tier CRM design)",
+};
+
+/**
+ * A profile's concept identity. `semanticSlug` is the ONE field that can say
+ * "same concept, different spelling"; synap-backend's `profile-repository.ts`
+ * defaults it to the slug when unset, so this mirrors runtime truth exactly.
+ */
+function effectiveSemanticSlug(profile: TemplateProfile): string {
+  return profile.semanticSlug ?? profile.slug;
+}
+
+/**
+ * The bare noun a concept identifier ends in: `crm.lead` → `lead`,
+ * `crm-lead` → `lead`, `lead` → `lead`.
+ *
+ * This is EXACT terminal-token equality on the author's own qualified name —
+ * not a similarity heuristic. `crm-lead` and `lead` collide because the author
+ * literally wrote the same noun; `prospect` and `lead` do not collide, and that
+ * is honest: no guard can know they mean the same thing.
+ */
+export function conceptTerm(semanticSlug: string): string {
+  const tokens = semanticSlug.split(/[.\-_]/).filter(Boolean);
+  return (tokens[tokens.length - 1] ?? semanticSlug).toLowerCase();
+}
+
+/** `undefined`/`null` = the template makes NO claim, which cannot contradict one. */
+function declaredValue(profile: TemplateProfile, field: string): string | null {
+  const raw = (profile as unknown as Record<string, unknown>)[field];
+  if (raw === undefined || raw === null) return null;
+  if (field === "applicableKinds") {
+    return Array.isArray(raw) ? JSON.stringify([...(raw as string[])].sort()) : null;
+  }
+  // `scope` is authored as both `shared` and `WORKSPACE` across the corpus.
+  return JSON.stringify(String(raw).toLowerCase());
+}
+
+function pairKey(a: string, b: string): string {
+  return [a, b].sort().join("|");
+}
+
+interface ProfileRef {
+  template: string;
+  profile: TemplateProfile;
+}
+
+export function findConceptViolations(
+  templates: Record<string, WorkspaceYaml> = WORKSPACE_TEMPLATES
+): ConceptViolation[] {
+  const violations: ConceptViolation[] = [];
+  const all: ProfileRef[] = [];
+  for (const [templateSlug, template] of Object.entries(templates)) {
+    for (const profile of template.profiles ?? []) {
+      all.push({ template: templateSlug, profile });
+    }
+  }
+
+  // ── RULE 1 — concept collision across templates ────────────────────────────
+  // Two ROLE profiles, in DIFFERENT templates, with DIFFERENT slugs, whose
+  // concept identifiers end in the same noun. Every qualifier is load-bearing:
+  //   • ROLE only — roles are the facet vocabulary (the hat an entity wears),
+  //     where a fork actually hurts: the same person is a lead under one
+  //     spelling and not under the other. Kinds are things with their own life.
+  //   • DIFFERENT templates — sibling roles authored in ONE file are a
+  //     deliberate distinction the author had in front of them (blockchain-
+  //     ecosystem's `marketing-agency` + `paid-ads-agency`). A fork is by
+  //     definition cross-template drift. This qualifier is what takes the rule
+  //     from 1 false positive to 0 on the current corpus.
+  //   • DIFFERENT slugs — the SAME slug in several templates is the documented
+  //     overlay/reuse mechanism (`lead` in foundation + crm + marketing), not a
+  //     fork. That case is rule 2's business.
+  const roles = all.filter((r) => r.profile.profileKind === "role");
+  const usedAllowlistKeys = new Set<string>();
+  const reportedPairs = new Set<string>();
+
+  for (let i = 0; i < roles.length; i++) {
+    for (let j = i + 1; j < roles.length; j++) {
+      const a = roles[i]!;
+      const b = roles[j]!;
+      if (a.template === b.template) continue;
+      if (a.profile.slug === b.profile.slug) continue;
+      const term = conceptTerm(effectiveSemanticSlug(a.profile));
+      if (term !== conceptTerm(effectiveSemanticSlug(b.profile))) continue;
+
+      const key = pairKey(a.profile.slug, b.profile.slug);
+      if (key in DECLARED_DIVERGENCES) {
+        usedAllowlistKeys.add(key);
+        continue;
+      }
+      if (reportedPairs.has(key)) continue;
+      reportedPairs.add(key);
+      violations.push({
+        rule: "concept-collision",
+        concept: term,
+        message:
+          `two role profiles denote the concept "${term}" under different slugs: ` +
+          `"${a.profile.slug}" (${a.template}) vs "${b.profile.slug}" (${b.template}). ` +
+          `Either REUSE the existing slug, or — if the divergence is intentional — declare it: ` +
+          `set an explicit \`semanticSlug\` on the new profile and add "${key}" to ` +
+          `DECLARED_DIVERGENCES in src/concept-guard.ts with the reason.`,
+      });
+    }
+  }
+
+  // ── RULE 2 — declared alias, forked shape ──────────────────────────────────
+  // Two profiles with DIFFERENT slugs that claim the SAME `semanticSlug` are
+  // asserting "one concept". Then their row-level shape must agree, or the
+  // assertion is a lie and the field is decorative. Absence is not a conflict:
+  // a template that OMITS a row-level field makes no claim (that is exactly how
+  // marketing.yaml correctly stops restating what foundation owns).
+  // Same-slug re-declaration is NOT checked here — that is the overlay path.
+  const bySemantic = new Map<string, ProfileRef[]>();
+  for (const ref of all) {
+    const key = effectiveSemanticSlug(ref.profile);
+    const bucket = bySemantic.get(key);
+    if (bucket) bucket.push(ref);
+    else bySemantic.set(key, [ref]);
+  }
+  for (const [semantic, group] of bySemantic) {
+    if (new Set(group.map((r) => r.profile.slug)).size < 2) continue;
+    for (const field of ["profileKind", "scope", "applicableKinds"]) {
+      const claims = new Map<string, string>();
+      for (const ref of group) {
+        const value = declaredValue(ref.profile, field);
+        if (value === null) continue;
+        const existing = claims.get(value);
+        if (!existing) claims.set(value, `${ref.template}:${ref.profile.slug}`);
+      }
+      if (claims.size > 1) {
+        violations.push({
+          rule: "alias-shape-divergence",
+          concept: semantic,
+          message:
+            `profiles aliased to semanticSlug "${semantic}" disagree on \`${field}\`: ` +
+            [...claims].map(([v, who]) => `${who} declares ${v}`).join(", ") +
+            `. Aliased profiles assert one concept — make the shapes agree, or drop the alias.`,
+        });
+      }
+    }
+  }
+
+  // ── RULE 3 — the allowlist may not rot ─────────────────────────────────────
+  for (const key of Object.keys(DECLARED_DIVERGENCES)) {
+    if (usedAllowlistKeys.has(key)) continue;
+    violations.push({
+      rule: "stale-allowlist",
+      concept: key,
+      message:
+        `DECLARED_DIVERGENCES entry "${key}" no longer matches any collision — ` +
+        `the divergence was resolved or the profiles were renamed. Delete the entry.`,
+    });
+  }
+
+  return violations;
+}
+
+export function formatConceptViolations(violations: ConceptViolation[]): string {
+  return violations.map((v) => `  • [${v.rule}] ${v.message}`).join("\n");
+}

package/src/content-os.yaml

@@ -8,6 +8,7 @@
 
 meta:
   slug: content-os
+  domain: content
   name: Content OS
   description: "Your editorial operating system — pillars, posts, platforms, and newsletters. Turn raw thinking into a published content engine, all connected to your campaigns and brand voice."
   icon: pen-tool
@@ -71,17 +72,51 @@ profiles:
         label: Status
         valueType: string
         inputType: select
-        enumValues: ["Idea", "Briefed", "In Draft", "Review", "Scheduled", "Published", "Archived"]
+        enumValues:
+          [
+            "Idea",
+            "Briefed",
+            "In Draft",
+            "Review",
+            "Scheduled",
+            "Published",
+            "Archived",
+          ]
       - slug: post-format
         label: Format
         valueType: string
         inputType: select
-        enumValues: ["Article", "Thread", "Short Video", "Long Video", "Carousel", "Image Post", "Story", "Newsletter Section", "Podcast Episode", "Other"]
+        enumValues:
+          [
+            "Article",
+            "Thread",
+            "Short Video",
+            "Long Video",
+            "Carousel",
+            "Image Post",
+            "Story",
+            "Newsletter Section",
+            "Podcast Episode",
+            "Other",
+          ]
       - slug: post-platform
         label: Platform
         valueType: string
         inputType: select
-        enumValues: ["LinkedIn", "Instagram", "TikTok", "YouTube", "Twitter / X", "Threads", "Bluesky", "Newsletter", "Podcast", "Blog", "Other"]
+        enumValues:
+          [
+            "LinkedIn",
+            "Instagram",
+            "TikTok",
+            "YouTube",
+            "Twitter / X",
+            "Threads",
+            "Bluesky",
+            "Newsletter",
+            "Podcast",
+            "Blog",
+            "Other",
+          ]
       - slug: post-pillar
         label: Pillar
         valueType: entity_id
@@ -160,7 +195,16 @@ profiles:
         label: Primary Formats
         valueType: string
         inputType: select
-        enumValues: ["Articles + Threads", "Short Video", "Long Video", "Newsletter", "Podcast", "Carousel", "Mixed"]
+        enumValues:
+          [
+            "Articles + Threads",
+            "Short Video",
+            "Long Video",
+            "Newsletter",
+            "Podcast",
+            "Carousel",
+            "Mixed",
+          ]
       - slug: post-count-pillar
         label: Total Posts Published
         valueType: number
@@ -178,23 +222,61 @@ profiles:
         label: Target Frequency
         valueType: string
         inputType: select
-        enumValues: ["Daily", "3x / week", "2x / week", "Weekly", "Bi-weekly", "Monthly", "Ad hoc"]
+        enumValues:
+          [
+            "Daily",
+            "3x / week",
+            "2x / week",
+            "Weekly",
+            "Bi-weekly",
+            "Monthly",
+            "Ad hoc",
+          ]
       - slug: pillar-tags
         label: Tags
         valueType: array
 
+  # `platform` is the ONE pod-wide publishing-account *vocabulary*. `scope: shared`
+  # makes it a single pod-wide profile row that a `require`-consumer (e.g.
+  # social.yaml) can adopt by RE-DECLARING this slug — the resolver writes the
+  # grant on declare, giving that workspace the same vocabulary instead of forking
+  # its own `channel` kind. (This shares the profile DEFINITION, not the account
+  # entities — `platform` has no `entityScope: pod`, so each workspace's platform
+  # rows stay its own.) This is the deterministic form of the campaign reuse
+  # pattern (there, a workspace kind is promoted to shared at apply; here the
+  # SSOT is shared from the start). The re-declared body in social must not
+  # conflict with this one — guarded locally by the shared-role SSOT check, not a
+  # CI gate.
   - slug: platform
     displayName: Platform
     icon: share-2
     color: "#06B6D4"
     description: "A social account, newsletter publication, or podcast channel. Each platform has its own audience metrics and publishing rhythm."
-    scope: WORKSPACE
+    scope: shared
     properties:
       - slug: platform-type
         label: Type
         valueType: string
         inputType: select
-        enumValues: ["LinkedIn", "Instagram", "TikTok", "YouTube", "Twitter / X", "Threads", "Bluesky", "Newsletter", "Podcast", "Blog / Website", "Other"]
+        enumValues:
+          [
+            "LinkedIn",
+            "Instagram",
+            "TikTok",
+            "YouTube",
+            "Twitter / X",
+            "Threads",
+            "Bluesky",
+            "Newsletter",
+            "Podcast",
+            "Blog / Website",
+            "Other",
+          ]
+      - slug: handle
+        label: Handle
+        valueType: string
+        inputType: text
+        placeholder: "@username"
       - slug: platform-status
         label: Status
         valueType: string
@@ -222,7 +304,16 @@ profiles:
         label: Posting Frequency
         valueType: string
         inputType: select
-        enumValues: ["Daily", "3x / week", "2x / week", "Weekly", "Bi-weekly", "Monthly", "As Needed"]
+        enumValues:
+          [
+            "Daily",
+            "3x / week",
+            "2x / week",
+            "Weekly",
+            "Bi-weekly",
+            "Monthly",
+            "As Needed",
+          ]
       - slug: last-post-date
         label: Last Post Date
         valueType: date
@@ -246,7 +337,8 @@ profiles:
         label: Status
         valueType: string
         inputType: select
-        enumValues: ["Idea", "Drafting", "Editing", "Scheduled", "Sent", "Archived"]
+        enumValues:
+          ["Idea", "Drafting", "Editing", "Scheduled", "Sent", "Archived"]
       - slug: newsletter-series
         label: Series
         valueType: string
@@ -327,7 +419,8 @@ profiles:
         label: Channel
         valueType: string
         inputType: select
-        enumValues: [email, social, event, content, partnership, paid, organic, other]
+        enumValues:
+          [email, social, event, content, partnership, paid, organic, other]
       - slug: campaign-goal
         label: Goal
         valueType: string

package/src/content-studio.yaml

@@ -3,6 +3,7 @@
 
 meta:
   slug: content-studio
+  domain: content
   name: Content Studio
   description: HyperFrames + Remotion video pipeline — script, design, compose, render, publish.
   icon: clapperboard

package/src/crm.yaml

@@ -6,6 +6,7 @@
 
 meta:
   slug: crm
+  domain: revenue
   name: CRM
   description: Sales pipeline and contact management from first contact to handoff.
   icon: handshake

package/src/define.ts

@@ -404,6 +404,7 @@ export interface PackageDefinitionOutput {
     slug: string;
     icon?: string;
     color?: string;
+    domain?: string;
     tags?: string[];
     isPublic?: boolean;
     requiredTier?: string | null;
@@ -442,13 +443,11 @@ export interface PackageDefinitionOutput {
   automations?: PackageAutomationWire[];
   /**
    * Entity-detail action placements — carried verbatim (authored form IS the
-   * wire form). NOTE: the Hub `PackageApplySchema` (synap-backend
-   * `hub-protocol/rest/packages.ts`) is a plain `z.object` and does not yet
-   * declare `actionPlacements`, so on the CLI/Hub install path this field is
-   * STRIPPED before `applyPackagePostWorkspace` sees it. The tRPC
-   * `createFromDefinition` door DOES carry it. Named follow-up: add an
-   * `ActionPlacementSchema` field to `PackageApplySchema` to close the Hub half
-   * (out of the T2 fence — flagged in the handoff).
+   * wire form). The Hub `PackageApplySchema` (synap-backend
+   * `hub-protocol/rest/packages.ts`) now declares `actionPlacements`
+   * (`z.array(ActionPlacementSchema).optional()`), so BOTH the tRPC
+   * `createFromDefinition` door and the CLI/Hub install path carry it through to
+   * `applyPackagePostWorkspace` — the parity is closed.
    */
   actionPlacements?: WorkspaceYaml['actionPlacements'];
   onboarding?: WorkspaceYaml['onboarding'];
@@ -481,6 +480,7 @@ export function toPackageDefinition(
       slug: tpl.meta.slug,
       icon: tpl.meta.icon,
       color: tpl.meta.color,
+      domain: tpl.meta.domain,
       tags: tpl.meta.tags,
       isPublic: tpl.meta.isPublic ?? true,
     },
@@ -535,7 +535,7 @@ type PackageDefinitionForwarded =
   | 'integrations'  // → capabilities
   | 'playbooks'
   | 'automations'   // → mapped to the apply door's flowDefinition wire shape
-  | 'actionPlacements' // → carried verbatim (Hub inbound schema decl is a follow-up)
+  | 'actionPlacements' // → carried verbatim (Hub inbound schema declares it — parity closed)
   | 'onboarding'
   | 'dependencies';