adjustments

.github/prompts/plan-step4.prompt.md

@@ -2,6 +2,15 @@
 
 This section finalizes Step 4 by defining a production-ready docs registry loader that reads packaged docs through Python resource APIs, parses SKILL.md frontmatter, validates schema and cross-links, and builds an immutable in-memory registry keyed by skill_id.
 
+### Greenfield Framing (Normative)
+
+This Step 4 design is for the greenfield target state:
+
+1. No legacy metadata sidecars (`metadata.yaml`) are part of the runtime contract.
+2. No dual-loader compatibility path is required.
+3. Registry loading from packaged resources is the only runtime source of truth.
+4. Compatibility shims are prohibited.
+
 ### Research Baseline (Python + Design Guidance)
 
 Authoritative references used for this step:
@@ -171,11 +180,11 @@ Runtime safety rules:
 
 Primary integration target:
 
-1. Replace path-based logic in `src/personal_mcp/skills/document_loader.py` with package-resource-based registry loading.
+1. Implement the canonical package-resource-based registry loader in `src/personal_mcp/skills/document_loader.py` as the only supported runtime loader path.
 
 Catalog integration:
 
-1. Update `src/personal_mcp/catalog/server.py` to consume the shared in-memory registry instead of scanning `metadata.yaml` files.
+1. Update `src/personal_mcp/catalog/server.py` to consume the shared in-memory registry as the only catalog data source.
 2. Keep catalog payload normalization deterministic and sourced from registry records only.
 
 Startup wiring:
@@ -235,4 +244,5 @@ Step 4 is complete when all are true:
 1. No FastMCP resource registration wiring details (Step 5).
 2. No discovery-tool fallback behavior design (Step 6).
 3. No final packaging/build-system migration mechanics (Step 7).
-4. No backward-compat alias rollout mechanics beyond validation readiness.
+4. No backward-compat alias rollout mechanics in the greenfield baseline.
+5. No compatibility layer of any kind (URI aliases, dual reads, adapter shims, or legacy schema bridges).