diff --git a/docs/superpowers/specs/2026-05-29-sp-stack-composer-design.md b/docs/superpowers/specs/2026-05-29-sp-stack-composer-design.md index 66ece0e..f678502 100644 --- a/docs/superpowers/specs/2026-05-29-sp-stack-composer-design.md +++ b/docs/superpowers/specs/2026-05-29-sp-stack-composer-design.md @@ -76,6 +76,12 @@ reference in `sp/SKILL.md` is rewritten from the hard-coded A repo-root path that only resolves when the entire marketplace is cloned together is replaced by a plugin-relative path that resolves however the plugin is installed. +**Pre-move verification (planning step):** before relocating ~6k files, grep the repo +for any other reference to the root `docs/` path — the 383 `library-navigator` skills, +`marketplace.json`, and any build/lint scripts — and confirm none break. Relative links +*inside* `docs/` (e.g. `.//README.md`) survive a wholesale move; references +*into* `docs/` from outside do not. + ### Capability manifest (`capabilities.md`) A small, hand-curated table — the heart of Approach C. One row per common capability: @@ -92,6 +98,13 @@ A small, hand-curated table — the heart of Approach C. One row per common capa The manifest is the only place the "prefer turnkey over low-level primitives" rule is encoded, so selection is deterministic rather than re-derived per request. +**v1 seed scope:** ship ~15–20 of the most common app capabilities (auth, multi-tenancy, +payments, email-campaigns, transactional-email, file-upload, search, realtime/SSE, +rate-limiting, notifications, webhooks, validation, PWA, client data hooks, CLI, testing). +This bounds the manifest work; everything outside it degrades to the docs-traversal +fallback, not a wrong answer. Each seed row should be anchored against a real example +phrasing so the `capability` vocabulary maps to how users actually describe needs. + ## Composer flow 1. Parse the app description into a capability list plus an inferred app-type.