@synap-core/workspace-templates 0.23.0 → 0.24.0

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`.
@@ -23,7 +23,7 @@ How installs, reconciles and tiers work is in the `synap-market` skill
 | `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 |
+| `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) |
 | `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`) | |
@@ -31,10 +31,16 @@ How installs, reconciles and tiers work is in the `synap-market` skill
 | `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.
@@ -122,8 +128,22 @@ client-specific.
   `synap-cli/templates/skills/<slug>/`, because `bridge-setup` still reads them
   there. The guard is the CLI's `test/catalog-mirror.tripwire.test.ts`.
 
-**Pack.** `packs/*.json` must stay byte-identical to the CP's `templates/packs/`
-(CP tripwire).
+**View.** Add or edit `views/<slug>.view.json`:
+
+```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`
@@ -159,7 +179,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"
@@ -334,7 +354,7 @@ wrapper `scripts/publish-official.mjs`, which uses the same lib):
 
 `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`
+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`
 (a CP PAT of the `synap-official` owner; humans use `synap login`), `NPM_TOKEN`.
 
@@ -367,8 +387,7 @@ 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 |
+| ~~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 |
 
 ## 5. Founder runbook: deploy, publish, retire the copies
@@ -429,13 +448,20 @@ 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.
-8. On a **brand-new, empty** CP only: run
+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.
+   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
    `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 step 6 and step 7. `seed:templates` seeds
+   workspaces only: views reach an empty CP through the publish.
 
 ### B. Publish the package and retire the mirrors
 
@@ -452,13 +478,13 @@ 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`;
+     `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/`.
 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`;
+   - 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`.