@synap-core/workspace-templates 0.6.0 → 0.6.2

package/src/the-arch.yaml

@@ -0,0 +1,182 @@
+# The Arch — the private command layer (addon on top of Enterprise OS)
+# =====================================================================
+# A PRIVATE suite template (isPublic: false → served only through the Control
+# Plane to its owner, never in the public catalog). It is the full company brain:
+# the whole public Enterprise OS PLUS the private flagship workspaces that make it
+# "The Arch" — the grant pipeline, the web3 ecosystem overlay, and the dev
+# dashboard.
+#
+# What it composes:
+#   • enterprise-os        — the whole public operating core (transitively brings
+#                            foundation / ecosystem / operations / crm)
+#   • grants               — the grant-agency pipeline (composes onto operations)
+#   • blockchain-ecosystem — web3 market actors + relations (composes onto ecosystem)
+#   • dev-dashboard        — the engineering/ops dashboard
+#
+# Ordering is safe by construction: `require` is deps-first, and grants /
+# blockchain-ecosystem declare their OWN compose bases (operations / ecosystem)
+# which enterprise-os installs first — so the overlays always land on a base that
+# already exists. Idempotent: install Enterprise OS first, then The Arch, and the
+# resolver reuses the OS workspaces instead of duplicating them.
+
+meta:
+  slug: the-arch
+  name: The Arch
+  description: The complete private company brain — the whole Enterprise OS plus the grant pipeline, the web3 ecosystem overlay, and the dev dashboard.
+  icon: landmark
+  color: "#7C3AED"
+  tags: [suite, private, arch, grants, web3, flagship]
+  isPublic: false
+
+# `require` (deps-first). enterprise-os brings the public core; the three private
+# flagships overlay onto it (grants→operations, blockchain-ecosystem→ecosystem)
+# or stand alongside it (dev-dashboard). Transitive: enterprise-os's own deps
+# resolve before the overlays that compose onto them.
+dependencies:
+  - slug: enterprise-os
+    kind: workspace
+    relation: require
+    reason: "The whole public operating core — strategy, market, operations, and pipeline — that the private flagships extend."
+  - slug: grants
+    kind: workspace
+    relation: require
+    reason: "The grant-agency pipeline; composes its operations onto the Operations workspace the OS installs."
+  - slug: blockchain-ecosystem
+    kind: workspace
+    relation: require
+    reason: "Web3 market actors + relations; composes onto the Ecosystem workspace the OS installs."
+  - slug: dev-dashboard
+    kind: workspace
+    relation: require
+    reason: "The engineering / ops dashboard — the build-side view of the company."
+
+workspace:
+  name: The Arch
+  description: The private command layer over the full company brain — track the cross-workspace initiatives that span the operating system and its private flagships.
+  subtype: the-arch
+  visibility: private
+
+profiles:
+  # The Arch's one native profile: a cross-cutting initiative that spans several
+  # of the workspaces this suite installs (a grant round that touches operations,
+  # ecosystem, and the dev dashboard, say). The place to stand above the lenses.
+  - slug: initiative
+    displayName: Initiative
+    icon: flag
+    color: "#7C3AED"
+    description: A cross-workspace initiative that spans the operating system and its private flagships.
+    properties:
+      - slug: summary
+        label: Summary
+        valueType: string
+        inputType: textarea
+      - slug: stage
+        label: Stage
+        valueType: string
+        inputType: select
+        enumValues: [shaping, active, blocked, shipped, archived]
+        constraints: { defaultValue: shaping }
+      - slug: lead
+        label: Lead
+        valueType: string
+        inputType: text
+      - slug: priority
+        label: Priority
+        valueType: string
+        inputType: select
+        enumValues: [low, medium, high, critical]
+        constraints: { defaultValue: medium }
+      - slug: dueDate
+        label: Due Date
+        valueType: date
+        inputType: date
+
+views:
+  - name: Initiatives
+    slug: initiatives
+    type: table
+    scopeProfileSlug: initiative
+    description: The cross-workspace initiatives spanning the full company brain, by stage and priority.
+    defaultView: true
+    config:
+      columns: [title, stage, priority, lead, dueDate]
+  - name: Initiative Board
+    slug: initiative-board
+    type: kanban
+    scopeProfileSlug: initiative
+    description: Initiatives grouped by stage — the command view over everything in flight.
+    config:
+      groupBy: stage
+
+onboarding:
+  goal: >
+    Name the cross-workspace initiatives that span the operating system and its
+    private flagships — the few big things in flight that touch more than one
+    lens — so The Arch is a real command layer, not just an aggregate of apps.
+  framing: |
+    THE FOUNDER'S COMMAND LAYER: Act from the seat above every lens. The whole
+    company brain is installed — operating core plus the private grant, web3, and
+    dev flagships. Your job is to surface the handful of initiatives that cut
+    across them and give each a stage, a lead, and a priority.
+  expertise:
+    starters:
+      - >
+        Name the cross-cutting few. An initiative earns a place here only if it
+        spans more than one workspace — a grant round that pulls in operations,
+        ecosystem, and dev. Single-lens work stays in its lens.
+      - >
+        Give each initiative a real stage and lead. Shaping / active / blocked /
+        shipped is the honest status; a lead is who to ask. Without them the
+        command layer is a wish list.
+    blindSpots:
+      - >
+        Everything marked "high priority" is the same as nothing marked. Force
+        the ranking — what is actually critical this week?
+      - >
+        A blocked initiative with no note about the blocker is invisible risk.
+        Name what is stuck and on whom.
+    bar: >
+      A short command board: the few genuinely cross-workspace initiatives, each
+      with a stage, a lead, and an honest priority — sitting over a fully
+      installed company brain.
+  collect:
+    - profileSlug: initiative
+      what: The cross-workspace initiatives currently in flight.
+      cardinality: few
+      keyFields: [stage, priority, lead]
+  openingQuestions:
+    - "What are the few big initiatives in flight that span more than one part of the company?"
+    - "For each, what stage is it in and who is the lead?"
+  doneWhen: A few cross-workspace initiatives captured, each with a stage and a lead.
+
+app:
+  kind: stored
+  cellKey: entity-detail
+
+layout:
+  defaultView: Initiatives
+  defaultApp: null
+  pinnedApps: [dashboard, data]
+  sidebarItems:
+    - kind: view
+      viewName: Initiatives
+      label: Initiatives
+      icon: flag
+    - kind: view
+      viewName: Initiative Board
+      label: Board
+      icon: kanban-square
+    - kind: app
+      appId: data
+      label: Data
+      icon: database
+
+bento:
+  viewName: Initiatives
+  blocks:
+    - kind: view
+      viewName: Initiatives
+      pos: { x: 0, y: 0, w: 8, h: 4 }
+    - kind: view
+      viewName: Initiative Board
+      pos: { x: 8, y: 0, w: 4, h: 4 }

package/src/types.ts

@@ -299,6 +299,13 @@ export interface TemplatePlaybook {
   schedule?: { cron: string } | null;
   /** tool/skill keys this playbook grants. */
   grants?: string[];
+  /**
+   * The entity kind this playbook operates over, persisted to
+   * `playbooks.subject_profile`. Makes the playbook matchable by
+   * `playbooks.matchForEntity` (filters `subject_profile->>'profileSlug'`), so a
+   * captured entity of this kind can auto-launch the playbook as a session.
+   */
+  subjectProfile?: { profileSlug: string; filter?: Record<string, unknown> };
   status?: 'draft' | 'active' | 'paused';
 }
 
@@ -351,6 +358,56 @@ export interface TemplateExtendsRef {
  * `grants` → `operations`). Distinct from `extends` (which imports from a live
  * workspace, tRPC-only) — `dependencies` is template→template.
  */
+/**
+ * PACKAGE_DEPENDENCY_KINDS — the dependency-kind vocabulary, declared ONCE.
+ *
+ * This tuple exists so consumers can IMPORT the vocabulary instead of
+ * hand-copying it. `TemplateDependency` is currently mirrored by hand in six
+ * other places, four of which carry a comment promising they match "VERBATIM so
+ * the wire shape never drifts" — a comment doing a type's job. A comment cannot
+ * fail a build; an import can. Those mirrors live in repos this package does not
+ * own, so this tuple does not fix them by existing — it makes the fix possible:
+ *
+ *   - marketplace            `types.ts:102`
+ *   - onboarding             `workspace-templates.ts:27`
+ *   - synap-backend          `package-definition.ts:204` (exports its own
+ *                            `PackageDependencyKind` — the closest peer)
+ *   - hub-protocol REST      `rest/packages.ts:140` (zod enum)
+ *   - browser                `InstallPackageDialog.tsx:262`
+ *   - control-plane-api      `routes/packages.ts:436` (zod enum)
+ *
+ * ⚠️ `'automation'` IS RETIRED VOCABULARY, deliberately still listed here.
+ * CP migration `0049_package_vocabulary` retired the `automation` package
+ * category in favour of `workflow` ("workflow — a triggered/sequenced run
+ * (absorbs 'automation' + 'playbook')", `PACKAGE_TYPES` in CP
+ * `db/schema/packages.ts`). A dependency's `kind` names the TYPE of package it
+ * points at, so this vocabulary should track `PACKAGE_TYPES` — meaning the live
+ * spelling is `workflow`, not `automation`.
+ *
+ * It is NOT renamed here, on purpose. This is latent, not live: 0/21 templates
+ * declare any `kind` other than the default `'workspace'`. And all four wire
+ * enums (CP + hub zod, above) still accept `'automation'` and do NOT accept
+ * `'workflow'` — so emitting `'workflow'` today would be rejected with a 400 at
+ * both doors, and dropping `'automation'` from this tuple would make any
+ * consumer that derives a zod enum from it start rejecting a value the wire
+ * still legally accepts (a published third-party package may carry it; CP's own
+ * schema permits it). Narrowing must therefore follow the wire, not lead it.
+ *
+ * ORDERED FIX (each step deployable alone, no flag day):
+ *   1. Widen the CP + hub zod enums to accept BOTH `'automation'` and `'workflow'`.
+ *   2. Add `'workflow'` here; mark `'automation'` deprecated; migrate any authored use.
+ *   3. Once no payload carries `'automation'`, drop it from the wire enums and this tuple.
+ */
+export const PACKAGE_DEPENDENCY_KINDS = [
+  'workspace',
+  'capability',
+  /** @deprecated Retired by CP 0049 in favour of `workflow`. See note above. */
+  'automation',
+] as const;
+
+/** What a `TemplateDependency` points at. Derived — never re-declare the list. */
+export type PackageDependencyKind = (typeof PACKAGE_DEPENDENCY_KINDS)[number];
+
 export interface TemplateDependency {
   /** Slug of the template/package this one depends on. */
   slug: string;
@@ -359,7 +416,7 @@ export interface TemplateDependency {
    * dependencies can be `compose`d; `'capability'`/`'automation'` are always
    * `require`d present without merging.
    */
-  kind?: 'workspace' | 'capability' | 'automation';
+  kind?: PackageDependencyKind;
   /**
    * How this template relates to the dependency:
    * - `'compose'`: this template is an OVERLAY on the dependency's workspace.