sten 6 implementation

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

@@ -55,7 +55,7 @@ Rules:
 - No underscores, spaces, dots, or uppercase characters.
 - Directory name should equal `skill-id` in each committed revision.
 - Frontmatter `id` should equal directory name in each committed revision.
-- Prefer keeping `skill-id` stable, but renames are allowed when needed if mappings are updated together.
+- Treat `skill-id` as immutable after release; any rename is a breaking replacement and clients must move to the new id.
 
 Example valid ids:
 

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

@@ -72,16 +72,6 @@ Contract intent:
 - Resolves only inside `docs/`.
 - This surface is markdown-only in end state (`.md` files).
 
-### Legacy URI Policy (Current-to-Target Transition)
-
-Current catalog URIs in this repo (`resource://catalog/patterns`, `resource://catalog/patterns_by_id`, `resource://catalog/skills_details`) are treated as compatibility aliases during migration.
-
-Rules:
-
-- Keep aliases only when needed for active clients.
-- Prefer simple canonical URIs for new clients.
-- Remove aliases once consumers have moved.
-
 ### URI Versioning Policy
 
 Default rule:
@@ -91,30 +81,14 @@ Default rule:
 
 Breaking-change rule:
 
-- If clients are already using an older shape, provide either:
-   - a short-lived alias, or
-   - a versioned URI family such as `resource://catalog/v2/...`.
-- Choose the lightest migration path that minimizes maintenance overhead.
+- Breaking changes use direct replacement of the canonical URI family.
+- No compatibility aliases or dual URI families are maintained in this greenfield phase.
 
 FastMCP version metadata usage:
 
 - Resource `version` metadata MAY be used for implementation/version discovery.
 - URI readability and maintainability remain the primary contract.
 
-### Deprecation Policy For URIs
-
-When deprecating a URI:
-
-1. Document the replacement URI in changelog/docs.
-2. Optionally return deprecation metadata while an alias exists.
-3. Remove deprecated aliases when no active client needs them.
-
-Recommended deprecation metadata fields in resource responses:
-
-- `deprecated: true`
-- `replacement_uri: <uri>`
-- `sunset_at: <ISO-8601 timestamp>`
-
 ### Reference ID Compatibility Policy
 
 `ref_id` is the public identifier for a reference document, separate from file path.
@@ -123,19 +97,14 @@ Rules:
 
 - Prefer keeping `ref_id` stable when practical.
 - File paths may change without URI churn as long as the mapped `ref_id` resolves.
-- If a reference is renamed, introduce a new `ref_id`; keep an alias only if clients depend on the old id.
+- If a reference is renamed, introduce a new `ref_id` and treat the old one as retired.
 - Avoid reusing retired `ref_id` values for unrelated content.
 
-Alias behavior for renamed references:
-
-- If alias is kept, old `ref_id` continues to resolve and points to the replacement.
-- Remove old alias as soon as migration is complete.
-
 ### Invariants This Contract Guarantees
 
 - One canonical URI pattern per core capability surface.
-- Fast, low-friction URI evolution with optional compatibility aliases.
-- Explicit migration path for catalog URI consolidation when needed.
+- Fast, low-friction URI evolution through direct replacement of canonical URIs.
+- A single canonical catalog URI family with no alias maintenance overhead.
 - Reference mappings can evolve with minimal churn.
 
 ### Non-goals For Step 3

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

@@ -50,17 +50,19 @@ Rules:
 
 ### Tool Fallback Surface (Normative)
 
-The minimal read-only fallback tool set is:
+The fallback tool surface includes:
 
-1. `search_patterns`
-2. `get_pattern_by_id`
-3. `get_skill_document_by_id`
+1. `list_resources`
+2. `read_resource`
+3. `search_patterns`
+4. `get_pattern_by_id`
+5. `get_skill_document_by_id`
 
 Fallback order:
 
-1. call `search_patterns` to find likely skills
-2. call `get_pattern_by_id` for one selected id when detail is needed
-3. call `get_skill_document_by_id` only for selected skill(s)
+1. call `list_resources` to inspect canonical static/template resource surfaces
+2. call `read_resource` for catalog URIs and selected skill URIs
+3. use thin catalog tools only when additional metadata-first narrowing is needed
 
 Tool behavior requirements:
 
@@ -71,14 +73,14 @@ Tool behavior requirements:
 
 ### Resources-As-Tools Compatibility Layer
 
-Step 6 may include a resources-as-tools compatibility layer for clients that can call tools but not attach resources.
+Step 6 includes a resources-as-tools compatibility layer for clients that can call tools but not attach resources.
 
 Rules:
 
-1. If enabled, it wraps canonical resource reads rather than re-implementing content transforms.
+1. It wraps canonical resource reads rather than re-implementing content transforms.
 2. It preserves canonical URIs and metadata semantics.
 3. It does not replace the minimal catalog tools listed above.
-4. It remains optional and interoperability-driven.
+4. It is interoperability-driven and remains read-only.
 
 ### Resource/Tool Parity Contract
 
@@ -144,10 +146,11 @@ Separation-of-concerns rule:
 Step 6 is complete when all are true:
 
 1. Resource-first discovery remains the documented and implemented default path.
-2. The fallback tool set is minimal, read-only, and schema-aligned.
-3. Fallback tool outputs map to canonical skill identities and URIs.
-4. Context loading is bounded and clarifying-question behavior is documented for low-confidence cases.
-5. No second content source is introduced; resources and tools resolve the same authored markdown.
+2. `list_resources` and `read_resource` are available for tool-only clients.
+3. Thin catalog tools remain minimal, read-only parity surfaces.
+4. Fallback tool outputs map to canonical skill identities and URIs.
+5. Context loading is bounded and clarifying-question behavior is documented for low-confidence cases.
+6. No second content source is introduced; resources and tools resolve the same authored markdown.
 
 ### Non-goals for Step 6