@synap-core/workspace-templates 0.23.0 → 0.24.1

package/README.md

@@ -1,7 +1,7 @@
 # The Synap catalog
 
 ONE home for every official installable template: workspaces, capabilities, skills,
-packs and automations. The team sees, edits, validates and publishes them all from
+packs, automations and views. The team sees, edits, validates and publishes them all from
 this folder, through one lib and one CLI. The live catalog is the Control Plane's
 `synap_packages` table, and it has one write door: `POST /api/packages` →
 `publishPackageCore`.
@@ -21,20 +21,26 @@ How installs, reconciles and tiers work is in the `synap-market` skill
 | Dir | Kind | Format | Published today? |
 |---|---|---|---|
 | `src/*.yaml` | `workspace` (and `pack`, for a suite) | Legacy workspace YAML (`meta:` plus body). A thin adapter reads it as `{kind: workspace, meta, spec}` | Yes. 31 entries, CI on every push to main |
-| `capabilities/<key>.capability.json` | `capability` | Manifest (below). `meta` carries the listing and visibility; `spec` is the CapabilityDefinition | Yes, by hand. CI also publishes it once `SYNAP_CATALOG_LIVE_KINDS` includes `capability` (§3) |
-| `skills/<slug>/` | `skill` | Either a manifest `<slug>.skill.json` (`creative-director`), or an Agent-Skills folder (`SKILL.md` plus references) with a header `skills/<slug>.catalog.json` beside it | The manifest: yes. A folder: only with its header, and only when it holds no reference files (a skill package carries no documents). Today one folder has a header (`designing-with-real-components`); the five moved folders have none and are **staged** |
-| `packs/*.json` | `pack` (CP profile/view fragment) | CP `_meta` fragment | **Staged** (founder decision pending: what `pack` means). The CP's insert-only `seed-templates.ts` still owns them |
-| `automations/<slug>.automation.json` | `automation` | bridge-setup `flowDefinition` form, plus a header `automations/<slug>.catalog.json` beside it | Only with its header, and only without apply-time placeholders. Today none has a header, so all three are **staged** (`mail-feed` also carries two placeholders bridge-setup fills) |
+| `capabilities/<key>.capability.json` | `capability` | Manifest (below). `meta` carries the listing and visibility; `spec` is the CapabilityDefinition | Yes, CI on every push to main (§4) |
+| `skills/<slug>/` | `skill` | Either a manifest `<slug>.skill.json` (`creative-director`), or an Agent-Skills folder (`SKILL.md` plus references) with a header `skills/<slug>.catalog.json` beside it | The manifest: yes. A folder: only with its header, and only when it holds no reference files (a skill package carries no documents). Headers decided by the founder on 2026-11-05: `bookmark-enrichment` and `routing-to-channels` public, `mapping-the-server` unlisted (private to the official owner); `reading-client-progress` and the parked `stellar-scf-grants-advisor` stay **staged** |
+| `views/<slug>.view.json` | `view` | Manifest; `spec.views` in the canonical shape the CP stores (`{slug, displayName, type, config, scopeProfileSlugs}`) | Category `view`. Three today (`bookmark-views-pack`, `event-views-pack`, `task-views-pack`), moved from the old CP pack fragments on 2026-11-05. CI on every push to main |
+| `automations/<slug>.automation.json` | `automation` | bridge-setup `flowDefinition` form, plus a header `automations/<slug>.catalog.json` beside it | Only with its header, and only without apply-time placeholders. Headers decided by the founder on 2026-11-05: `bookmark-enrichment` public; `url-bookmark-capture`, `github-pr-events` and the five `ship-a-change-*` unlisted. `mail-feed` stays **staged**: it carries two placeholders bridge-setup fills |
 | `schema/` | | Zod manifest schema: `header.ts`, plus one body per kind (`workspace`, `capability`, `skill`, `automation`, `playbook`) | |
 | `standards/*.standard.yaml` | | Quality standard per workspace (`pnpm eval`) | |
 | `scripts/catalog-lib.mjs` | | **The ONE lib**: `loadCatalog` → `validateCatalog` → `diffCatalog` → `publishCatalog` | |
 | `src/*.ts` | | The typed bundle (`dist/`) that clients ship as the zero-network fallback | |
 
 A staged file is read, validated and counted, and the problem list carries a
-`staged` warning for it. It cannot reach `POST /api/packages`. Today the
-whole-catalog validate prints `✓ 73 catalog entries validated (selected: 31
-workspace · 41 capability · 1 skill · 0 pack · 0 automation)` (41 = 35 seeded on
-the CP + 6 authored here first).
+`staged` warning for it. It cannot reach `POST /api/packages`. On 2026-11-05 the
+whole-catalog validate printed `✓ 93 catalog entries validated (selected: 27
+workspace · 44 capability · 18 skill · 0 pack · 0 automation · 3 view) + 13 retired`.
+
+**No CP pack fragment.** The old CP `templates/packs/*.json` shape (a JSON with a
+top-level `_meta`) is a load error. Its three view packs are `kind: view`
+manifests in `views/`. Its ten profile packs and the misfiled `deep-research`
+playbook are in `retired-sources/packs/` (never loaded or published): the CP
+retired the `profile-pack` category in its migration 0049, and the playbook never
+reached the CP.
 
 **What stays elsewhere:**
 - **System skills** (`system/*`) stay in `synap-backend/skills/`. They are the pod's
@@ -48,7 +54,7 @@ the CP + 6 authored here first).
 ```jsonc
 {
   "apiVersion": "synap/v1",
-  "kind": "capability",            // workspace | capability | skill | pack | automation
+  "kind": "capability",            // workspace | capability | skill | pack | automation | view
   "meta": {                        // the header: same limits as the CP publishSchema
     "slug": "apify",               // kebab-case; dots only for a capability whose slug === spec.key
     "name": "Apify — Web Scraping",
@@ -64,7 +70,7 @@ the CP + 6 authored here first).
 One pure compiler, `toPublishBody(manifest)`, turns a manifest into today's
 `POST /api/packages` body. The CP door and its `PACKAGE_TYPES` are unchanged. A
 workspace publishes as category `workspace`, a capability as `capability`, a skill
-as `skill`, an automation as `workflow`.
+as `skill`, an automation as `workflow`, a view as `view`.
 
 Playbook goals use `{name}` placeholders. `@{arg:}` is refused at authoring; the
 runtime still reads it.
@@ -80,12 +86,8 @@ only when it is strictly newer than their bundle.
 
 **Capability.** Edit `capabilities/<key>.capability.json`. The listing and
 visibility go in `meta`; the definition goes in `spec`.
-- **Transition:** an **existing** capability also has a CP copy,
-  `synap-control-plane-api/src/seeds/capability-templates/<key>.capability.json`,
-  whose content must equal `spec`. Its header lives in `capability-listings.ts` and
-  `CAPABILITY_VISIBILITY` in the seeder, and must equal `meta`. Change both sides.
-  The CP tripwire `catalog-mirror.tripwire.test.ts` turns red otherwise.
-- A **new** capability is authored here only: catalog-only files are allowed.
+- This file is the only copy. The CP's insert-only bootstrap reads this package's
+  `capabilities/` (installed from npm); it holds no copy of its own.
 - **A reader** is an ordinary verb that reads one link: `intent: "read_webpage"`, `metadata.readOnly: true`,
   a required `url` parameter, and `urls: [...]` declaring the links it handles (`host[/path]`, `*.host`,
   or `"*"`; the grammar lives in `@synap-core/types/url-read`). The pod's one read door routes by those
@@ -115,15 +117,26 @@ folder (`skill-documents`), `metadata.auto_load: true` (`skill-auto-load`), a
 frontmatter name that is not `meta.slug` (`skill-slug`). Without a header the folder
 is staged. Deciding which folders get a header (their listing and visibility) is a
 content decision; `reading-client-progress` and `stellar-scf-grants-advisor` are
-client-specific.
-- **Transition:** the five moved folders (`bookmark-enrichment`,
-  `mapping-the-server`, `reading-client-progress`, `routing-to-channels`,
-  `stellar-scf-grants-advisor`) must stay byte-identical to
-  `synap-cli/templates/skills/<slug>/`, because `bridge-setup` still reads them
-  there. The guard is the CLI's `test/catalog-mirror.tripwire.test.ts`.
+client-specific. A private (unlisted) header carries `"isPublic": false, "owner":
+"template-owner"`. `synap bridge-setup` reads these folders from the installed
+package; the CLI holds no copy (synap-cli#91).
+
+**View.** Add or edit `views/<slug>.view.json`:
 
-**Pack.** `packs/*.json` must stay byte-identical to the CP's `templates/packs/`
-(CP tripwire).
+```jsonc
+{ "apiVersion": "synap/v1", "kind": "view",
+  "meta": { "slug": "task-views-pack", "name": "Task Views", "description": "listing copy", "icon": "layout-grid", "color": "#3B82F6", "tags": ["tasks"], "isPublic": true },
+  "spec": { "views": [ { "slug": "task-board", "displayName": "Task Board", "type": "kanban", "config": { "groupByField": "status" }, "scopeProfileSlugs": ["task"] } ] },
+  "dependencies": [] }
+```
+
+It publishes as category `view` with `definition = { profiles: [], views, description:
+meta.description, icon, color }`, the shape the seeded view rows carry. Only the
+canonical view shape is accepted (the CP's `name` / singular `scopeProfileSlug`
+shorthand is refused), and view slugs are unique within the file.
+
+**Pack.** A `pack` is a workspace suite (`src/*.yaml` with the `suite` tag): it
+publishes as category `workspace` and owns no space.
 
 **Automation.** Either a manifest (`kind: automation`, `spec` in the authoring
 `flow` form), or a raw `automations/<slug>.automation.json` in the `flowDefinition`
@@ -134,8 +147,9 @@ description?, triggerType, triggerConfig, flowDefinition, status }] }`, i.e. the
 file minus its `metadata` notes. Refused: an apply-time placeholder
 (`apply-time-placeholder`: an empty or `<…>` connection id, a `<…>` output channel,
 a skill node without `skillId`) and any raw key a package cannot carry (`state`).
-Transition: the three raw files must stay byte-identical to
-`synap-cli/templates/automations/` (CLI tripwire).
+`synap bridge-setup` reads `bookmark-enrichment`, `mail-feed` and
+`url-bookmark-capture` from the installed package; the CLI holds no copy
+(synap-cli#91).
 
 **Every kind.** Run the gate before you push:
 
@@ -159,7 +173,7 @@ X" from "never heard of it" and offer the person a safe move to X.
 2. Add an entry to `retired.yaml`:
    ```yaml
    - slug: radar
-     kind: workspace            # default; capability · skill · pack · automation
+     kind: workspace            # default; capability · skill · pack · automation · view
      replacedBy: ecosystem      # a LIVE slug of the same kind, or omit when nothing replaces it
      reason: Radar was merged into Ecosystem, which tracks competitors and trends in one place.
      since: "2026-07-16"
@@ -330,12 +344,11 @@ wrapper `scripts/publish-official.mjs`, which uses the same lib):
 | Event | What runs |
 |---|---|
 | PR touching the catalog | Job `validate` only: build, validate every kind, print the **offline** preview (each entry and the version the CP will derive, where knowable offline). It holds **no secret and no `id-token`**: a PR runs its own lockfile and scripts. Guarded by `scripts/publish-workflow.guard.test.ts`. |
-| Push to `main` (or manual) | `validate`, then job `publish` (environment `catalog-publish`): a read-only preview against the live CP, then publish live `--kind ${SYNAP_CATALOG_LIVE_KINDS:-workspace}`, then npm publish, only if the `package.json` version is new on npm. |
+| Push to `main` (or manual) | `validate`, then job `publish` (environment `catalog-publish`): a read-only preview against the live CP, then publish EVERY kind live (no `--kind`), tombstones included, then npm publish, only if the `package.json` version is new on npm. |
 
-`SYNAP_CATALOG_LIVE_KINDS` is a repository **variable**. While it is unset, main
-publishes workspaces only: every kind is still validated and previewed, but only
-workspaces are written. Set it to `workspace,capability,skill,pack,automation`
-only after runbook §5 A. Secrets: `SYNAP_CP_URL`, `SYNAP_CP_PUBLISH_TOKEN`
+Main publishes every kind (founder, 2026-11-05: "remove the blocker that only do
+workspace, we will do ALL"); the old `SYNAP_CATALOG_LIVE_KINDS` variable is not
+read. Secrets: `SYNAP_CP_URL`, `SYNAP_CP_PUBLISH_TOKEN`
 (a CP PAT of the `synap-official` owner; humans use `synap login`), `NPM_TOKEN`.
 
 **One-time setup of the `catalog-publish` environment** (GitHub → synap-app →
@@ -357,19 +370,13 @@ row. A tripwire (`no-template-reseed-on-deploy-tripwire.test.ts`) guards this.
 key gets 409 `OFFICIAL_CAPABILITY_KEY_RESERVED`, and the CP serves the official row
 first for a key.
 
-**Transition mirrors** (each retires in the same change that deletes its copies; see §5).
-These guards are **local-only**: each skips when the sibling repo is not checked out,
-and every repo's CI checks out itself alone, so CI does not enforce them. Run them
-on a full monorepo checkout before merging a change to either side. The same holds
-for `schema/header.mirror.tripwire.test.ts` (header limits ↔ the CP `publishSchema`)
-and `scripts/catalog-lib.columns.tripwire.test.ts` (the preview's columns and
-adoption rule ↔ the CP publish core); their CI-safe halves are snapshots.
-
-| Copy | Guard | Retires when |
-|---|---|---|
-| CP `src/seeds/capability-templates/*.capability.json` + listings/visibility | CP `src/seeds/catalog-mirror.tripwire.test.ts` (spec- and meta-equal) | the CP pin is bumped and the seeder reads the package |
-| CP `templates/packs/*.json` | same file (byte-equal) | same |
-| CLI `templates/skills/<5 moved>/`, `templates/automations/*.automation.json` | CLI `test/catalog-mirror.tripwire.test.ts` (byte-equal, both directions) | the CLI's pin admits a package release that ships them: `bridge-setup` already reads the installed package first, and the CLI's retirement test fails while both exist |
+**No copies.** Since 2026-11-05 (founder: "keep one source only") neither the CP
+nor the CLI holds a copy of any catalog file: both read this package from npm. The
+CP's `no-catalog-copy.tripwire.test.ts` fails on a copy there. Two cross-repo guards
+stay **local-only** (they skip when the CP is not a sibling checkout):
+`schema/header.mirror.tripwire.test.ts` (header limits ↔ the CP `publishSchema`) and
+`scripts/catalog-lib.columns.tripwire.test.ts` (the preview's columns and adoption
+rule ↔ the CP publish core); their CI-safe halves are snapshots.
 
 ## 5. Founder runbook: deploy, publish, retire the copies
 
@@ -429,13 +436,17 @@ Do these in order. The runbook only names the commands; it does not run anything
      older CP): **STOP** and look.
 6. **Publish:** `synap catalog publish --official --kind capability`. Confirm at the
    prompt.
-7. **Widen CI:** set the repo variable
-   `SYNAP_CATALOG_LIVE_KINDS=workspace,capability,skill,automation`. A skill folder
-   or raw automation publishes only once it has a header; `pack` stays out until
-   its meaning is decided.
+7. **Views** (`views/`, 2026-11-05): `synap catalog diff bookmark-views-pack
+   event-views-pack task-views-pack` shows each `CHANGED`: a new content version
+   (the new listing description inside the definition), `displayName` and
+   `description` (the catalog's copy, which never reached the CP), `source:
+   "file-seed" → "api"` and `vendorId: null → synap-official` (the publish adopts
+   the unowned seeded row). The views themselves are byte-equal to the live rows.
+   CI publishes them with every other kind on the next push to main.
 8. On a **brand-new, empty** CP only: run
    `docker compose -f docker-compose.prod.yml run --rm control-plane pnpm seed:capabilities`
-   (and `seed:templates`) once, then step 6.
+   (and `seed:templates`) once, then publish (step 6). `seed:templates` seeds
+   workspaces only: views reach an empty CP through the publish.
 
 ### B. Publish the package and retire the mirrors
 
@@ -452,15 +463,14 @@ Do these in order. The runbook only names the commands; it does not run anything
      floor up only if a consumer needs the new content.
 3. **Point the readers at the package:**
    - the CP seeder and capability resolver (`capability-template-dir.ts`) read
-     `node_modules/@synap-core/workspace-templates/capabilities/`, plus `packs/` for
-     `seed-templates.ts`;
-   - `synap bridge-setup` installs the published skill and automation entries
-     through the pod instead of reading `templates/`.
+     `node_modules/@synap-core/workspace-templates/capabilities/` (done 2026-11-05;
+     `seed-templates.ts` no longer seeds packs: views publish through the door);
+   - `synap bridge-setup` reads the skill and automation files from the installed
+     package (done, synap-cli#91).
 4. **Delete the copies and their tripwires in the same change:**
-   - CP: `src/seeds/capability-templates/`, `templates/packs/`, the listing and
-     visibility literals, and `catalog-mirror.tripwire.test.ts`;
-   - CLI: the five moved skill folders, `templates/automations/`, and
-     `test/catalog-mirror.tripwire.test.ts`.
+   - CP: done 2026-11-05 (copies, listing and visibility literals, and both
+     tripwires deleted);
+   - CLI: done (synap-cli#91).
 
 ### C. Coordinated rename (planned)
 

package/automations/bookmark-enrichment.catalog.json

@@ -0,0 +1,16 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "automation",
+  "meta": {
+    "slug": "bookmark-enrichment-auto",
+    "name": "Bookmark enrichment (auto)",
+    "description": "When a bookmark is saved, enrich it: what the pod already connects to it first, then the page itself, classified and linked into the graph.",
+    "tags": [
+      "automation",
+      "bookmarks",
+      "enrichment"
+    ],
+    "isPublic": true
+  },
+  "dependencies": []
+}

package/automations/github-pr-events.catalog.json

@@ -0,0 +1,18 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "automation",
+  "meta": {
+    "slug": "github-pr-events",
+    "name": "GitHub pull requests and checks to dev-loop facts",
+    "description": "Reads the GitHub org webhook (one inbound source named GitHub) and records what happened as dev-loop observations: a pull request opened or reopened → dev.pr_opened, merged → dev.pr_merged, closed unmerged → dev.pr_closed; a check suite completed → ci.finished. The pod's own consumers (the merge sweeper, the Ship a change automations) take it from there.",
+    "tags": [
+      "automation",
+      "github",
+      "dev-loop",
+      "builder"
+    ],
+    "isPublic": false,
+    "owner": "template-owner"
+  },
+  "dependencies": []
+}

package/automations/ship-a-change-checks-green.catalog.json

@@ -0,0 +1,18 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "automation",
+  "meta": {
+    "slug": "ship-a-change-checks-green",
+    "name": "CI green to Ship a change waits on the merge",
+    "description": "When a CI run on a pull request's head finishes green, grade the session's checks-green criterion and move its Ship a change step to Merged.",
+    "tags": [
+      "automation",
+      "dev-loop",
+      "builder",
+      "ship-a-change"
+    ],
+    "isPublic": false,
+    "owner": "template-owner"
+  },
+  "dependencies": []
+}

package/automations/ship-a-change-checks-red.catalog.json

@@ -0,0 +1,18 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "automation",
+  "meta": {
+    "slug": "ship-a-change-checks-red",
+    "name": "CI red to Ship a change goes back to Building",
+    "description": "When a CI run on a pull request's head fails, grade the session's checks-green criterion as failed and send its Ship a change step back to Building (the Checks green stage's onFail).",
+    "tags": [
+      "automation",
+      "dev-loop",
+      "builder",
+      "ship-a-change"
+    ],
+    "isPublic": false,
+    "owner": "template-owner"
+  },
+  "dependencies": []
+}

package/automations/ship-a-change-deployed.catalog.json

@@ -0,0 +1,18 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "automation",
+  "meta": {
+    "slug": "ship-a-change-deployed",
+    "name": "Deployed to the devbox worker dogfoods it",
+    "description": "When this pod reports a new build live (dev.deployed, recorded by the pod itself after a successful update), start a Dogfood a change run handed to the devbox worker, filed into the goal.",
+    "tags": [
+      "automation",
+      "dev-loop",
+      "builder",
+      "ship-a-change"
+    ],
+    "isPublic": false,
+    "owner": "template-owner"
+  },
+  "dependencies": []
+}

package/automations/ship-a-change-pr-merged.catalog.json

@@ -0,0 +1,18 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "automation",
+  "meta": {
+    "slug": "ship-a-change-pr-merged",
+    "name": "PR merged to Ship a change waits on the lab deploy",
+    "description": "When a PR merges: the merge sweeper (built in, backend#283) already marks the session's pr-* outcome met. This automation grades the session's `merged` criterion and moves its Ship a change step to Deployed to lab, where the person approves the deploy.",
+    "tags": [
+      "automation",
+      "dev-loop",
+      "builder",
+      "ship-a-change"
+    ],
+    "isPublic": false,
+    "owner": "template-owner"
+  },
+  "dependencies": []
+}

package/automations/ship-a-change-pr-opened.catalog.json

@@ -0,0 +1,18 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "automation",
+  "meta": {
+    "slug": "ship-a-change-pr-opened",
+    "name": "PR opened to Ship a change waits on its checks",
+    "description": "When a pull request opens with a `Pod session:` line, grade the session's pr-opened criterion and move its Ship a change step to Checks green.",
+    "tags": [
+      "automation",
+      "dev-loop",
+      "builder",
+      "ship-a-change"
+    ],
+    "isPublic": false,
+    "owner": "template-owner"
+  },
+  "dependencies": []
+}

package/automations/url-bookmark-capture.catalog.json

@@ -0,0 +1,17 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "automation",
+  "meta": {
+    "slug": "url-bookmark-capture",
+    "name": "Discord links to bookmarks",
+    "description": "Every link posted in a Discord message becomes a bookmark, with the message's context kept. No AI.",
+    "tags": [
+      "automation",
+      "bookmarks",
+      "discord"
+    ],
+    "isPublic": false,
+    "owner": "template-owner"
+  },
+  "dependencies": []
+}