docs: define source ownership policy direction

docs/current_roadmap.md

@@ -125,6 +125,11 @@ implementation state.
    - Source registry startup merge is implemented: absent registry preserves
       config-only behavior, registry-only entries hydrate as dynamic connections,
       and config entries shadow same-id registry entries with an event.
+   - Config shadowing is the v1 conservative behavior, not the final ownership
+      model. The planned follow-up is explicit config ownership policy:
+      `locked` config entries stay operator-owned, while `seed` entries
+      bootstrap missing store entries and then let the store own later admin
+      changes.
    - Next source registry slices are planned in
       [2026-06-03 source registry next slices](./superpowers/plans/2026-06-03-source-registry-next-slices.md):
       desired-registry admin reads and safe mutation commands are complete;

docs/superpowers/plans/2026-06-03-source-registry-next-slices.md

@@ -76,6 +76,17 @@ The next executable slice is startup merge:
      local/static servers report unavailable and concrete MCP-backed
      `WorkflowServer` construction remains future work.
 
+6. **Slice 6: Config Ownership Policy**
+   - **Status: planned.**
+   - Replace implicit config-shadowing with explicit `locked` / `seed`
+     ownership policy.
+   - `locked` config entries remain operator-owned and shadow/reject registry
+     mutation for the same id.
+   - `seed` config entries bootstrap missing store entries, then the store owns
+     later admin changes.
+   - Update startup merge diagnostics and registry admin payloads so users can
+     see why a source is mutable or shadowed.
+
 ---
 
 ## Slice 2A: Generic Registry Mechanics
@@ -406,4 +417,5 @@ Status: complete. Implementation:
 - This is a multi-slice roadmap, not a single execution plan for all mutation work.
 - Slice 2A is the immediate next implementation target and resolves the location problem.
 - Startup merge is intentionally after generic/MCP split and conversion helpers.
-- No mutation commands are planned before persistence and merge rules are implemented.
+- Config ownership policy is intentionally after mutation commands, because it
+  changes precedence semantics rather than introducing persistence.

docs/superpowers/specs/2026-06-03-store-backed-source-registry-design.md

@@ -143,21 +143,38 @@ On server startup:
 4. Merge into one desired source map.
 5. Hydrate runtime `ConnectionService` / `SourceCatalogService` from that map.
 
-Precedence:
+Current v1 precedence:
 
 1. Built-in reserved ids always win for reserved ids.
 2. Config-defined entries win over dynamic registry entries with the same id.
 3. Dynamic registry entries fill in ids not present in config.
 
-Rationale: config is deployment bootstrap and operator-controlled. Dynamic store
+Rationale: this first pass is conservative. Config is deployment bootstrap and
-state should not secretly override source definitions checked into deployment
+operator-controlled, so dynamic store state should not secretly override source
-config.
+definitions checked into deployment config before source ownership policy exists.
+
+Long-term ownership policy:
+
+- Config remains valid for bootstrap, dev/test portability, disaster recovery,
+  and operator-managed static sources.
+- Store-backed registry is the normal mutable desired-state authority for
+  server-owned dynamic sources.
+- Config should not win forever by default. Future source definitions should
+  distinguish at least two config ownership modes:
+  - `locked`: config owns the id. Registry add/update for that id is rejected
+    or remains explicitly shadowed.
+  - `seed`: config creates or hydrates the initial store entry when missing,
+    then the store owns later admin changes.
+
+Until that policy exists in models and startup merge, same-id config entries
+continue to shadow store entries for safety.
 
 Duplicate behavior:
 
 - Duplicate ids inside one config or one registry file are validation errors.
 - A registry entry with the same id as config is allowed but ignored with a
-  diagnostic/event.
+  diagnostic/event in v1. Future `seed` config entries should instead allow the
+  store entry to become authoritative after seeding.
 - A registry entry using a reserved id is invalid.
 
 ## Mutation Rules
@@ -288,14 +305,23 @@ in v1. Remove requires `--confirm` in CLI. Local/static servers report
 unavailable for mutation commands. Concrete MCP-backed `WorkflowServer`
 construction remains future work.
 
+### Slice 6: Config Ownership Policy
+
+Status: planned. Replace implicit "config always shadows store" with explicit
+source ownership policy. The intended shape is `locked` for operator-owned
+config entries and `seed` for bootstrap entries that should hand ownership to
+the store after initial materialization. This should update config models,
+startup merge diagnostics, registry mutation validation, and admin read payloads
+so users can tell why a source id is mutable or shadowed.
+
 ## Open Questions
 
 - Should dynamic registry entries support non-MCP transports in v1, or only MCP
   stdio/HTTP?
 - Should auth references be required for sources that need auth, or optional
   until live validation?
-- Should config shadowing registry entries be a warning only, or should server
+- Should strict mode fail on `locked` config/store conflicts, or keep them as
-  startup fail in strict mode?
+  explicit shadow diagnostics?
 - Should disabled registry entries still hydrate as disabled sources so inspect
   can explain them, or stay only in registry/admin output?