implemented steps 1-5

docs/architecture.md

@@ -16,6 +16,12 @@ The system is complete in three layers:
 2. Catalog resources provide normalized discovery.
 3. Zensical builds a static site from those same Markdown sources and the FastAPI app serves it in the FastMCP runtime process.
 
+For Phase 1, this architecture is anchored by three contracts:
+
+1. Step 1: docs-first authored content contract under `docs/` with strict per-skill ownership.
+2. Step 2: SKILL.md frontmatter contract with Anthropic fields plus `x-personal-mcp` metadata.
+3. Step 3: canonical resource URI contract with break-and-replace policy for contract changes.
+
 This architecture keeps authored content human-friendly while preserving machine-stable contracts.
 
 ## Intent
@@ -30,7 +36,14 @@ The architecture is designed to satisfy three long-term requirements:
 
 ### Pattern Modules
 
-Each module encapsulates one methodology domain and publishes resource families:
+Each skill encapsulates one methodology domain in a docs-owned directory:
+
+1. `docs/skills/<skill-id>/SKILL.md`
+2. `docs/skills/<skill-id>/references/...`
+
+The skill document and references are the authored source of truth; runtime code indexes and serves these files without becoming a second authored source.
+
+Each skill publishes resource families:
 
 1. document
 
@@ -42,10 +55,23 @@ The catalog is the canonical discovery layer and publishes normalized records fo
 
 Typical catalog resources:
 
-1. resource://catalog/patterns
-2. resource://catalog/patterns_by_id
-3. resource://catalog/skills_index
-4. resource://catalog/skills_details
+1. resource://catalog/skills_index
+2. resource://catalog/skills/{skill_id}
+
+Only canonical catalog resources are part of the runtime contract in this phase.
+
+### Registry Loader
+
+Phase 2 runtime composition introduces a startup registry loader that reads packaged docs resources using `importlib.resources.files(...)` and `Traversable` APIs.
+
+Loader responsibilities:
+
+1. Parse SKILL.md frontmatter for each skill.
+2. Validate schema and cross-field constraints before any resource registration.
+3. Build an in-memory registry keyed by `skill_id`.
+4. Fail fast for duplicate ids, missing markdown files, broken reference mappings, and invalid `depends_on` values.
+
+Registry load failure is a startup error, not a partial runtime warning.
 
 ### Content Sources
 
@@ -76,27 +102,59 @@ flowchart TD
 
 ### Metadata Contract
 
-Each pattern module declares:
+Each skill declares frontmatter in `docs/skills/<skill-id>/SKILL.md`.
+
+Anthropic-facing required fields:
+
+1. name
+2. description
+
+Repository indexing metadata is declared in `x-personal-mcp`:
 
 1. id
-2. name
-3. version
-4. description
-5. tags
-6. capabilities
-7. depends_on
+2. version
+3. tags
+4. capabilities
+5. depends_on
+6. references map (ref id to relative path and optional metadata)
+
+No `metadata.yaml` sidecar is part of the end-state contract.
 
 ### URI Contract
 
-Module resource URIs are stable and follow:
+Canonical resource URIs are:
 
 1. resource://skills/<skill_id>/document
+2. resource://skills/<skill_id>/references/<ref_id>
+3. resource://catalog/skills_index
+4. resource://catalog/skills/{skill_id}
+5. resource://docs/{path*}
 
-Catalog resource URIs are stable and discovery-focused.
+Validation rules:
+
+1. `skill_id` is lowercase kebab-case and must satisfy the stable skill id contract.
+2. `ref_id` is lowercase kebab-case and must be declared in the skill references manifest.
+3. `path*` resolves only to normalized markdown paths under `docs/`.
+
+### Resource Registration Contract
+
+Resources are registered from the validated registry, not by ad hoc per-skill hardcoding.
+
+Registration rules:
+
+1. Use RFC6570 URI templates where appropriate.
+2. Mark documentation resources as read-only and idempotent.
+3. Set explicit mime types for resource responses.
+4. Configure duplicate URI handling with `on_duplicate="error"` for startup safety.
+
+This keeps runtime behavior deterministic and prevents accidental URI collisions.
 
 ### Versioning Rule
 
-Published URIs are immutable. Behavioral or schema changes are versioned in metadata and documented through additive migration notes.
+URIs are unversioned and canonical in this phase.
+
+1. Breaking URI changes are handled as direct replacement.
+2. No compatibility aliases or dual URI families are maintained.
 
 ## Static Hosting Pattern
 
@@ -161,8 +219,8 @@ Allowed exception:
 
 Existing markdown reference sets are valid examples of authored source material for this architecture:
 
-1. ../docs/skills/pytest-scaffolding/references/pytest-docs.md
-2. ../docs/skills/python-logging-dictconfig/references/python-logging-docs.md
-3. ../docs/skills/fastapi-uv-docker/references/fastapi-best-practices.md
+1. docs/skills/pytest-scaffolding/references/pytest-docs.md
+2. docs/skills/python-logging-dictconfig/references/python-logging-docs.md
+3. docs/skills/fastapi-uv-docker/references/fastapi-best-practices.md
 
 These inputs are treated as content sources, while resource URIs and catalog payloads remain the machine-facing contracts.