@synap-core/workspace-templates 0.24.0 → 0.24.1

package/README.md

@@ -21,10 +21,10 @@ 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** |
-| `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 writes them once `SYNAP_CATALOG_LIVE_KINDS` includes `view` |
-| `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` | |
@@ -86,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
@@ -121,12 +117,9 @@ 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`:
 
@@ -154,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:
 
@@ -350,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,view`
-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 →
@@ -377,18 +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/`, `templates/packs/`~~ | | **Retired 2026-11-05** (founder: one source). The CP seeders read the installed package; its tripwire `no-catalog-copy.tripwire.test.ts` fails on any copy |
-| 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
 
@@ -454,13 +442,10 @@ Do these in order. The runbook only names the commands; it does not run anything
    `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.
-   Then publish the same three slugs with `synap catalog publish --official`.
-8. **Widen CI:** set the repo variable
-   `SYNAP_CATALOG_LIVE_KINDS=workspace,capability,skill,automation,view`. A skill
-   folder or raw automation publishes only once it has a header.
-9. On a **brand-new, empty** CP only: run
+   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 step 7. `seed:templates` seeds
+   (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
@@ -480,13 +465,12 @@ Do these in order. The runbook only names the commands; it does not run anything
    - the CP seeder and capability resolver (`capability-template-dir.ts`) read
      `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` installs the published skill and automation entries
-     through the pod instead of reading `templates/`.
+   - `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: done 2026-11-05 (copies, listing and visibility literals, and both
      tripwires deleted);
-   - CLI: the five moved skill folders, `templates/automations/`, and
-     `test/catalog-mirror.tripwire.test.ts`.
+   - 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": []
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@synap-core/workspace-templates",
-  "version": "0.24.0",
+  "version": "0.24.1",
   "type": "module",
   "description": "Canonical workspace definitions — YAML source + typed exports for browser, backend, CLI, and marketplace",
   "repository": {

package/skills/bookmark-enrichment.catalog.json

@@ -0,0 +1,16 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "skill",
+  "meta": {
+    "slug": "bookmark-enrichment",
+    "name": "Bookmark enrichment",
+    "description": "Enrich a saved bookmark from the page it points to: read the link, extract its title and description, classify it, and link it to what your pod already knows.",
+    "tags": [
+      "skill",
+      "bookmarks",
+      "enrichment"
+    ],
+    "isPublic": true
+  },
+  "dependencies": []
+}

package/skills/mapping-the-server.catalog.json

@@ -0,0 +1,18 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "skill",
+  "meta": {
+    "slug": "mapping-the-server",
+    "name": "Mapping the server",
+    "description": "Read a Discord server's structure (categories, channels, members) and propose one reviewable graph of clients, partners, companies, people and channel bindings, accepted in a single move.",
+    "tags": [
+      "skill",
+      "discord",
+      "crm",
+      "onboarding"
+    ],
+    "isPublic": false,
+    "owner": "template-owner"
+  },
+  "dependencies": []
+}

package/skills/routing-to-channels.catalog.json

@@ -0,0 +1,16 @@
+{
+  "apiVersion": "synap/v1",
+  "kind": "skill",
+  "meta": {
+    "slug": "routing-to-channels",
+    "name": "Routing to channels",
+    "description": "Route a message to the right channel, and create a channel, room or thread when one is warranted.",
+    "tags": [
+      "skill",
+      "channels",
+      "messaging"
+    ],
+    "isPublic": true
+  },
+  "dependencies": []
+}