Fold spec-review refinements into sp-stack design

Add pre-move verification step and bound v1 manifest seed scope.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

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. `./<category>/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.