diff --git a/.agent/skills/openspec-apply-change/SKILL.md b/.agent/skills/openspec-apply-change/SKILL.md
index 70fbdb8..eddd3a6 100644
--- a/.agent/skills/openspec-apply-change/SKILL.md
+++ b/.agent/skills/openspec-apply-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Implement tasks from an OpenSpec change.
@@ -30,6 +30,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -49,6 +50,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.agent/skills/openspec-archive-change/SKILL.md b/.agent/skills/openspec-archive-change/SKILL.md
index 12e2f70..37b38eb 100644
--- a/.agent/skills/openspec-archive-change/SKILL.md
+++ b/.agent/skills/openspec-archive-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Archive a completed change in the experimental workflow.
@@ -30,8 +30,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Use **AskUserQuestion tool** to confirm user wants to proceed
@@ -52,7 +55,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -67,19 +70,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -98,7 +101,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
 
 All artifacts complete. All tasks complete.
diff --git a/.agent/skills/openspec-explore/SKILL.md b/.agent/skills/openspec-explore/SKILL.md
index 6858d3f..ca50074 100644
--- a/.agent/skills/openspec-explore/SKILL.md
+++ b/.agent/skills/openspec-explore/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
@@ -102,11 +102,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.agent/skills/openspec-propose/SKILL.md b/.agent/skills/openspec-propose/SKILL.md
index 4b7e204..51a52e1 100644
--- a/.agent/skills/openspec-propose/SKILL.md
+++ b/.agent/skills/openspec-propose/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Propose a new change - create the change and generate all artifacts in one step.
@@ -37,7 +37,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -46,6 +46,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -63,10 +64,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.agent/workflows/opsx-apply.md b/.agent/workflows/opsx-apply.md
index e23ec64..cb53869 100644
--- a/.agent/workflows/opsx-apply.md
+++ b/.agent/workflows/opsx-apply.md
@@ -23,6 +23,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -42,6 +43,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.agent/workflows/opsx-archive.md b/.agent/workflows/opsx-archive.md
index 1163776..b30dcd0 100644
--- a/.agent/workflows/opsx-archive.md
+++ b/.agent/workflows/opsx-archive.md
@@ -23,8 +23,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Prompt user for confirmation to continue
@@ -45,7 +48,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -60,19 +63,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -91,7 +94,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs
 
 All artifacts complete. All tasks complete.
@@ -104,7 +107,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** No delta specs
 
 All artifacts complete. All tasks complete.
@@ -117,7 +120,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** Sync skipped (user chose to skip)
 
 **Warnings:**
@@ -134,7 +137,7 @@ Review the archive if this was not intentional.
 ## Archive Failed
 
 **Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Target:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 
 Target archive directory already exists.
 
diff --git a/.agent/workflows/opsx-explore.md b/.agent/workflows/opsx-explore.md
index 3b674eb..32ec8d2 100644
--- a/.agent/workflows/opsx-explore.md
+++ b/.agent/workflows/opsx-explore.md
@@ -104,11 +104,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.agent/workflows/opsx-propose.md b/.agent/workflows/opsx-propose.md
index cf30b2a..30bd6fd 100644
--- a/.agent/workflows/opsx-propose.md
+++ b/.agent/workflows/opsx-propose.md
@@ -30,7 +30,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -39,6 +39,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -56,10 +57,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.claude/commands/opsx/apply.md b/.claude/commands/opsx/apply.md
index ae14f0f..45003f8 100644
--- a/.claude/commands/opsx/apply.md
+++ b/.claude/commands/opsx/apply.md
@@ -26,6 +26,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -45,6 +46,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.claude/commands/opsx/archive.md b/.claude/commands/opsx/archive.md
index 5e91608..4af9687 100644
--- a/.claude/commands/opsx/archive.md
+++ b/.claude/commands/opsx/archive.md
@@ -26,8 +26,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Prompt user for confirmation to continue
@@ -48,7 +51,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -63,19 +66,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -94,7 +97,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs
 
 All artifacts complete. All tasks complete.
@@ -107,7 +110,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** No delta specs
 
 All artifacts complete. All tasks complete.
@@ -120,7 +123,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** Sync skipped (user chose to skip)
 
 **Warnings:**
@@ -137,7 +140,7 @@ Review the archive if this was not intentional.
 ## Archive Failed
 
 **Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Target:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 
 Target archive directory already exists.
 
diff --git a/.claude/commands/opsx/explore.md b/.claude/commands/opsx/explore.md
index 1757907..8655619 100644
--- a/.claude/commands/opsx/explore.md
+++ b/.claude/commands/opsx/explore.md
@@ -107,11 +107,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.claude/commands/opsx/propose.md b/.claude/commands/opsx/propose.md
index 05276f4..90ba344 100644
--- a/.claude/commands/opsx/propose.md
+++ b/.claude/commands/opsx/propose.md
@@ -33,7 +33,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -42,6 +42,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -59,10 +60,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.claude/skills/openspec-apply-change/SKILL.md b/.claude/skills/openspec-apply-change/SKILL.md
index 70fbdb8..eddd3a6 100644
--- a/.claude/skills/openspec-apply-change/SKILL.md
+++ b/.claude/skills/openspec-apply-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Implement tasks from an OpenSpec change.
@@ -30,6 +30,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -49,6 +50,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.claude/skills/openspec-archive-change/SKILL.md b/.claude/skills/openspec-archive-change/SKILL.md
index 12e2f70..37b38eb 100644
--- a/.claude/skills/openspec-archive-change/SKILL.md
+++ b/.claude/skills/openspec-archive-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Archive a completed change in the experimental workflow.
@@ -30,8 +30,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Use **AskUserQuestion tool** to confirm user wants to proceed
@@ -52,7 +55,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -67,19 +70,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -98,7 +101,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
 
 All artifacts complete. All tasks complete.
diff --git a/.claude/skills/openspec-explore/SKILL.md b/.claude/skills/openspec-explore/SKILL.md
index 6858d3f..ca50074 100644
--- a/.claude/skills/openspec-explore/SKILL.md
+++ b/.claude/skills/openspec-explore/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
@@ -102,11 +102,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.claude/skills/openspec-propose/SKILL.md b/.claude/skills/openspec-propose/SKILL.md
index 4b7e204..51a52e1 100644
--- a/.claude/skills/openspec-propose/SKILL.md
+++ b/.claude/skills/openspec-propose/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Propose a new change - create the change and generate all artifacts in one step.
@@ -37,7 +37,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -46,6 +46,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -63,10 +64,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.cline/skills/openspec-apply-change/SKILL.md b/.cline/skills/openspec-apply-change/SKILL.md
deleted file mode 100644
index 70fbdb8..0000000
--- a/.cline/skills/openspec-apply-change/SKILL.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.cline/skills/openspec-archive-change/SKILL.md b/.cline/skills/openspec-archive-change/SKILL.md
deleted file mode 100644
index 12e2f70..0000000
--- a/.cline/skills/openspec-archive-change/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.cline/skills/openspec-explore/SKILL.md b/.cline/skills/openspec-explore/SKILL.md
deleted file mode 100644
index 6858d3f..0000000
--- a/.cline/skills/openspec-explore/SKILL.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Handling Different Entry Points
-
-**User brings a vague idea:**
-```
-User: I'm thinking about adding real-time collaboration
-
-You: Real-time collab is a big space. Let me think about this...
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
-
-      Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
-       trivial            moderate           complex
-
-      Where's your head at?
-```
-
-**User brings a specific problem:**
-```
-User: The auth system is a mess
-
-You: [reads codebase]
-
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
-
-     I see three tangles. Which one's burning?
-```
-
-**User is stuck mid-implementation:**
-```
-User: /opsx:explore add-auth-system
-      The OAuth integration is more complex than expected
-
-You: [reads change artifacts]
-
-     You're on task 4: "Implement OAuth flow"
-
-     Let me trace what's involved...
-
-     [draws diagram, explores options, suggests paths]
-
-     Want to update the design to reflect this?
-     Or add a spike task to investigate?
-```
-
-**User wants to compare options:**
-```
-User: Should we use Postgres or SQLite?
-
-You: Generic answer is boring. What's the context?
-
-User: A CLI tool that tracks local dev environments
-
-You: That changes everything.
-
-     ┌─────────────────────────────────────────────────┐
-     │          CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
-
-     Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
-
-                  SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
-
-     SQLite. Not even close.
-
-     Unless... is there a sync component?
-```
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When it feels like things are crystallizing, you might summarize:
-
-```
-## What We Figured Out
-
-**The problem**: [crystallized understanding]
-
-**The approach**: [if one emerged]
-
-**Open questions**: [if any remain]
-
-**Next steps** (if ready):
-- Create a change proposal
-- Keep exploring: just keep talking
-```
-
-But this summary is optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.cline/skills/openspec-propose/SKILL.md b/.cline/skills/openspec-propose/SKILL.md
deleted file mode 100644
index 4b7e204..0000000
--- a/.cline/skills/openspec-propose/SKILL.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
-
-**Steps**
-
-1. **If no clear input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.clinerules/workflows/opsx-apply.md b/.clinerules/workflows/opsx-apply.md
deleted file mode 100644
index 37a78e6..0000000
--- a/.clinerules/workflows/opsx-apply.md
+++ /dev/null
@@ -1,149 +0,0 @@
-# OPSX: Apply
-
-Implement tasks from an OpenSpec change (Experimental)
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! You can archive this change with `/opsx:archive`.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.clinerules/workflows/opsx-archive.md b/.clinerules/workflows/opsx-archive.md
deleted file mode 100644
index c38d6f6..0000000
--- a/.clinerules/workflows/opsx-archive.md
+++ /dev/null
@@ -1,154 +0,0 @@
-# OPSX: Archive
-
-Archive a completed change in the experimental workflow
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Spec sync status (synced / sync skipped / no delta specs)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success (No Delta Specs)**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** No delta specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success With Warnings**
-
-```
-## Archive Complete (with warnings)
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** Sync skipped (user chose to skip)
-
-**Warnings:**
-- Archived with 2 incomplete artifacts
-- Archived with 3 incomplete tasks
-- Delta spec sync was skipped (user chose to skip)
-
-Review the archive if this was not intentional.
-```
-
-**Output On Error (Archive Exists)**
-
-```
-## Archive Failed
-
-**Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
-
-Target archive directory already exists.
-
-**Options:**
-1. Rename the existing archive
-2. Delete the existing archive if it's a duplicate
-3. Wait until a different date to archive
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.clinerules/workflows/opsx-explore.md b/.clinerules/workflows/opsx-explore.md
deleted file mode 100644
index 0c5f034..0000000
--- a/.clinerules/workflows/opsx-explore.md
+++ /dev/null
@@ -1,170 +0,0 @@
-# OPSX: Explore
-
-Enter explore mode - think through ideas, investigate problems, clarify requirements
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
-**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
-- A vague idea: "real-time collaboration"
-- A specific problem: "the auth system is getting unwieldy"
-- A change name: "add-dark-mode" (to explore in context of that change)
-- A comparison: "postgres vs sqlite for this"
-- Nothing (just enter explore mode)
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-If the user mentioned a specific change name, read its artifacts for context.
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.clinerules/workflows/opsx-propose.md b/.clinerules/workflows/opsx-propose.md
deleted file mode 100644
index 6669d0d..0000000
--- a/.clinerules/workflows/opsx-propose.md
+++ /dev/null
@@ -1,103 +0,0 @@
-# OPSX: Propose
-
-Propose a new change - create it and generate all artifacts in one step
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
-
-**Steps**
-
-1. **If no input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` to start implementing."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.codex/skills/openspec-apply-change/SKILL.md b/.codex/skills/openspec-apply-change/SKILL.md
index 70fbdb8..eddd3a6 100644
--- a/.codex/skills/openspec-apply-change/SKILL.md
+++ b/.codex/skills/openspec-apply-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Implement tasks from an OpenSpec change.
@@ -30,6 +30,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -49,6 +50,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.codex/skills/openspec-archive-change/SKILL.md b/.codex/skills/openspec-archive-change/SKILL.md
index 12e2f70..37b38eb 100644
--- a/.codex/skills/openspec-archive-change/SKILL.md
+++ b/.codex/skills/openspec-archive-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Archive a completed change in the experimental workflow.
@@ -30,8 +30,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Use **AskUserQuestion tool** to confirm user wants to proceed
@@ -52,7 +55,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -67,19 +70,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -98,7 +101,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
 
 All artifacts complete. All tasks complete.
diff --git a/.codex/skills/openspec-explore/SKILL.md b/.codex/skills/openspec-explore/SKILL.md
index 6858d3f..ca50074 100644
--- a/.codex/skills/openspec-explore/SKILL.md
+++ b/.codex/skills/openspec-explore/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
@@ -102,11 +102,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.codex/skills/openspec-propose/SKILL.md b/.codex/skills/openspec-propose/SKILL.md
index 4b7e204..51a52e1 100644
--- a/.codex/skills/openspec-propose/SKILL.md
+++ b/.codex/skills/openspec-propose/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Propose a new change - create the change and generate all artifacts in one step.
@@ -37,7 +37,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -46,6 +46,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -63,10 +64,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.continue/prompts/opsx-apply.prompt b/.continue/prompts/opsx-apply.prompt
deleted file mode 100644
index 1c2b132..0000000
--- a/.continue/prompts/opsx-apply.prompt
+++ /dev/null
@@ -1,151 +0,0 @@
----
-name: opsx-apply
-description: Implement tasks from an OpenSpec change (Experimental)
-invokable: true
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! You can archive this change with `/opsx:archive`.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.continue/prompts/opsx-archive.prompt b/.continue/prompts/opsx-archive.prompt
deleted file mode 100644
index 83e6c4f..0000000
--- a/.continue/prompts/opsx-archive.prompt
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: opsx-archive
-description: Archive a completed change in the experimental workflow
-invokable: true
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Spec sync status (synced / sync skipped / no delta specs)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success (No Delta Specs)**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** No delta specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success With Warnings**
-
-```
-## Archive Complete (with warnings)
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** Sync skipped (user chose to skip)
-
-**Warnings:**
-- Archived with 2 incomplete artifacts
-- Archived with 3 incomplete tasks
-- Delta spec sync was skipped (user chose to skip)
-
-Review the archive if this was not intentional.
-```
-
-**Output On Error (Archive Exists)**
-
-```
-## Archive Failed
-
-**Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
-
-Target archive directory already exists.
-
-**Options:**
-1. Rename the existing archive
-2. Delete the existing archive if it's a duplicate
-3. Wait until a different date to archive
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.continue/prompts/opsx-explore.prompt b/.continue/prompts/opsx-explore.prompt
deleted file mode 100644
index f3c1679..0000000
--- a/.continue/prompts/opsx-explore.prompt
+++ /dev/null
@@ -1,172 +0,0 @@
----
-name: opsx-explore
-description: Enter explore mode - think through ideas, investigate problems, clarify requirements
-invokable: true
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
-**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
-- A vague idea: "real-time collaboration"
-- A specific problem: "the auth system is getting unwieldy"
-- A change name: "add-dark-mode" (to explore in context of that change)
-- A comparison: "postgres vs sqlite for this"
-- Nothing (just enter explore mode)
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-If the user mentioned a specific change name, read its artifacts for context.
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.continue/prompts/opsx-propose.prompt b/.continue/prompts/opsx-propose.prompt
deleted file mode 100644
index 83d6d35..0000000
--- a/.continue/prompts/opsx-propose.prompt
+++ /dev/null
@@ -1,105 +0,0 @@
----
-name: opsx-propose
-description: Propose a new change - create it and generate all artifacts in one step
-invokable: true
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
-
-**Steps**
-
-1. **If no input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` to start implementing."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.continue/skills/openspec-apply-change/SKILL.md b/.continue/skills/openspec-apply-change/SKILL.md
deleted file mode 100644
index 70fbdb8..0000000
--- a/.continue/skills/openspec-apply-change/SKILL.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.continue/skills/openspec-archive-change/SKILL.md b/.continue/skills/openspec-archive-change/SKILL.md
deleted file mode 100644
index 12e2f70..0000000
--- a/.continue/skills/openspec-archive-change/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.continue/skills/openspec-explore/SKILL.md b/.continue/skills/openspec-explore/SKILL.md
deleted file mode 100644
index 6858d3f..0000000
--- a/.continue/skills/openspec-explore/SKILL.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Handling Different Entry Points
-
-**User brings a vague idea:**
-```
-User: I'm thinking about adding real-time collaboration
-
-You: Real-time collab is a big space. Let me think about this...
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
-
-      Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
-       trivial            moderate           complex
-
-      Where's your head at?
-```
-
-**User brings a specific problem:**
-```
-User: The auth system is a mess
-
-You: [reads codebase]
-
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
-
-     I see three tangles. Which one's burning?
-```
-
-**User is stuck mid-implementation:**
-```
-User: /opsx:explore add-auth-system
-      The OAuth integration is more complex than expected
-
-You: [reads change artifacts]
-
-     You're on task 4: "Implement OAuth flow"
-
-     Let me trace what's involved...
-
-     [draws diagram, explores options, suggests paths]
-
-     Want to update the design to reflect this?
-     Or add a spike task to investigate?
-```
-
-**User wants to compare options:**
-```
-User: Should we use Postgres or SQLite?
-
-You: Generic answer is boring. What's the context?
-
-User: A CLI tool that tracks local dev environments
-
-You: That changes everything.
-
-     ┌─────────────────────────────────────────────────┐
-     │          CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
-
-     Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
-
-                  SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
-
-     SQLite. Not even close.
-
-     Unless... is there a sync component?
-```
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When it feels like things are crystallizing, you might summarize:
-
-```
-## What We Figured Out
-
-**The problem**: [crystallized understanding]
-
-**The approach**: [if one emerged]
-
-**Open questions**: [if any remain]
-
-**Next steps** (if ready):
-- Create a change proposal
-- Keep exploring: just keep talking
-```
-
-But this summary is optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.continue/skills/openspec-propose/SKILL.md b/.continue/skills/openspec-propose/SKILL.md
deleted file mode 100644
index 4b7e204..0000000
--- a/.continue/skills/openspec-propose/SKILL.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
-
-**Steps**
-
-1. **If no clear input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.cursor/commands/opsx-apply.md b/.cursor/commands/opsx-apply.md
index fcfa6c9..9c17178 100644
--- a/.cursor/commands/opsx-apply.md
+++ b/.cursor/commands/opsx-apply.md
@@ -26,6 +26,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -45,6 +46,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.cursor/commands/opsx-archive.md b/.cursor/commands/opsx-archive.md
index e5cdd0e..8e3553c 100644
--- a/.cursor/commands/opsx-archive.md
+++ b/.cursor/commands/opsx-archive.md
@@ -26,8 +26,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Prompt user for confirmation to continue
@@ -48,7 +51,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -63,19 +66,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -94,7 +97,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs
 
 All artifacts complete. All tasks complete.
@@ -107,7 +110,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** No delta specs
 
 All artifacts complete. All tasks complete.
@@ -120,7 +123,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** Sync skipped (user chose to skip)
 
 **Warnings:**
@@ -137,7 +140,7 @@ Review the archive if this was not intentional.
 ## Archive Failed
 
 **Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Target:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 
 Target archive directory already exists.
 
diff --git a/.cursor/commands/opsx-explore.md b/.cursor/commands/opsx-explore.md
index f1aceec..ba1339b 100644
--- a/.cursor/commands/opsx-explore.md
+++ b/.cursor/commands/opsx-explore.md
@@ -107,11 +107,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.cursor/commands/opsx-propose.md b/.cursor/commands/opsx-propose.md
index 4d75466..1744ba3 100644
--- a/.cursor/commands/opsx-propose.md
+++ b/.cursor/commands/opsx-propose.md
@@ -33,7 +33,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -42,6 +42,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -59,10 +60,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.cursor/skills/openspec-apply-change/SKILL.md b/.cursor/skills/openspec-apply-change/SKILL.md
index 70fbdb8..eddd3a6 100644
--- a/.cursor/skills/openspec-apply-change/SKILL.md
+++ b/.cursor/skills/openspec-apply-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Implement tasks from an OpenSpec change.
@@ -30,6 +30,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -49,6 +50,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.cursor/skills/openspec-archive-change/SKILL.md b/.cursor/skills/openspec-archive-change/SKILL.md
index 12e2f70..37b38eb 100644
--- a/.cursor/skills/openspec-archive-change/SKILL.md
+++ b/.cursor/skills/openspec-archive-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Archive a completed change in the experimental workflow.
@@ -30,8 +30,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Use **AskUserQuestion tool** to confirm user wants to proceed
@@ -52,7 +55,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -67,19 +70,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -98,7 +101,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
 
 All artifacts complete. All tasks complete.
diff --git a/.cursor/skills/openspec-explore/SKILL.md b/.cursor/skills/openspec-explore/SKILL.md
index 6858d3f..ca50074 100644
--- a/.cursor/skills/openspec-explore/SKILL.md
+++ b/.cursor/skills/openspec-explore/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
@@ -102,11 +102,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.cursor/skills/openspec-propose/SKILL.md b/.cursor/skills/openspec-propose/SKILL.md
index 4b7e204..51a52e1 100644
--- a/.cursor/skills/openspec-propose/SKILL.md
+++ b/.cursor/skills/openspec-propose/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Propose a new change - create the change and generate all artifacts in one step.
@@ -37,7 +37,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -46,6 +46,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -63,10 +64,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.gemini/commands/opsx/apply.toml b/.gemini/commands/opsx/apply.toml
index 83a33d7..24ca8d6 100644
--- a/.gemini/commands/opsx/apply.toml
+++ b/.gemini/commands/opsx/apply.toml
@@ -22,6 +22,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -41,6 +42,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.gemini/commands/opsx/archive.toml b/.gemini/commands/opsx/archive.toml
index cf76b75..6a11739 100644
--- a/.gemini/commands/opsx/archive.toml
+++ b/.gemini/commands/opsx/archive.toml
@@ -22,8 +22,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Prompt user for confirmation to continue
@@ -44,7 +47,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -59,19 +62,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -90,7 +93,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs
 
 All artifacts complete. All tasks complete.
@@ -103,7 +106,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** No delta specs
 
 All artifacts complete. All tasks complete.
@@ -116,7 +119,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** Sync skipped (user chose to skip)
 
 **Warnings:**
@@ -133,7 +136,7 @@ Review the archive if this was not intentional.
 ## Archive Failed
 
 **Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Target:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 
 Target archive directory already exists.
 
diff --git a/.gemini/commands/opsx/explore.toml b/.gemini/commands/opsx/explore.toml
index 8ccd312..7a25618 100644
--- a/.gemini/commands/opsx/explore.toml
+++ b/.gemini/commands/opsx/explore.toml
@@ -103,11 +103,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.gemini/commands/opsx/propose.toml b/.gemini/commands/opsx/propose.toml
index 8be4eaf..fbf3460 100644
--- a/.gemini/commands/opsx/propose.toml
+++ b/.gemini/commands/opsx/propose.toml
@@ -29,7 +29,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -38,6 +38,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -55,10 +56,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.gemini/skills/openspec-apply-change/SKILL.md b/.gemini/skills/openspec-apply-change/SKILL.md
index 70fbdb8..eddd3a6 100644
--- a/.gemini/skills/openspec-apply-change/SKILL.md
+++ b/.gemini/skills/openspec-apply-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Implement tasks from an OpenSpec change.
@@ -30,6 +30,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -49,6 +50,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.gemini/skills/openspec-archive-change/SKILL.md b/.gemini/skills/openspec-archive-change/SKILL.md
index 12e2f70..37b38eb 100644
--- a/.gemini/skills/openspec-archive-change/SKILL.md
+++ b/.gemini/skills/openspec-archive-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Archive a completed change in the experimental workflow.
@@ -30,8 +30,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Use **AskUserQuestion tool** to confirm user wants to proceed
@@ -52,7 +55,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -67,19 +70,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -98,7 +101,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
 
 All artifacts complete. All tasks complete.
diff --git a/.gemini/skills/openspec-explore/SKILL.md b/.gemini/skills/openspec-explore/SKILL.md
index 6858d3f..ca50074 100644
--- a/.gemini/skills/openspec-explore/SKILL.md
+++ b/.gemini/skills/openspec-explore/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
@@ -102,11 +102,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.gemini/skills/openspec-propose/SKILL.md b/.gemini/skills/openspec-propose/SKILL.md
index 4b7e204..51a52e1 100644
--- a/.gemini/skills/openspec-propose/SKILL.md
+++ b/.gemini/skills/openspec-propose/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Propose a new change - create the change and generate all artifacts in one step.
@@ -37,7 +37,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -46,6 +46,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -63,10 +64,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.github/prompts/opsx-apply.prompt.md b/.github/prompts/opsx-apply.prompt.md
index e23ec64..cb53869 100644
--- a/.github/prompts/opsx-apply.prompt.md
+++ b/.github/prompts/opsx-apply.prompt.md
@@ -23,6 +23,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -42,6 +43,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.github/prompts/opsx-archive.prompt.md b/.github/prompts/opsx-archive.prompt.md
index 1163776..b30dcd0 100644
--- a/.github/prompts/opsx-archive.prompt.md
+++ b/.github/prompts/opsx-archive.prompt.md
@@ -23,8 +23,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Prompt user for confirmation to continue
@@ -45,7 +48,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -60,19 +63,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -91,7 +94,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs
 
 All artifacts complete. All tasks complete.
@@ -104,7 +107,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** No delta specs
 
 All artifacts complete. All tasks complete.
@@ -117,7 +120,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** Sync skipped (user chose to skip)
 
 **Warnings:**
@@ -134,7 +137,7 @@ Review the archive if this was not intentional.
 ## Archive Failed
 
 **Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Target:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 
 Target archive directory already exists.
 
diff --git a/.github/prompts/opsx-explore.prompt.md b/.github/prompts/opsx-explore.prompt.md
index 3b674eb..32ec8d2 100644
--- a/.github/prompts/opsx-explore.prompt.md
+++ b/.github/prompts/opsx-explore.prompt.md
@@ -104,11 +104,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.github/prompts/opsx-propose.prompt.md b/.github/prompts/opsx-propose.prompt.md
index cf30b2a..30bd6fd 100644
--- a/.github/prompts/opsx-propose.prompt.md
+++ b/.github/prompts/opsx-propose.prompt.md
@@ -30,7 +30,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -39,6 +39,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -56,10 +57,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.github/skills/openspec-apply-change/SKILL.md b/.github/skills/openspec-apply-change/SKILL.md
index 70fbdb8..eddd3a6 100644
--- a/.github/skills/openspec-apply-change/SKILL.md
+++ b/.github/skills/openspec-apply-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Implement tasks from an OpenSpec change.
@@ -30,6 +30,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -49,6 +50,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.github/skills/openspec-archive-change/SKILL.md b/.github/skills/openspec-archive-change/SKILL.md
index 12e2f70..37b38eb 100644
--- a/.github/skills/openspec-archive-change/SKILL.md
+++ b/.github/skills/openspec-archive-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Archive a completed change in the experimental workflow.
@@ -30,8 +30,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Use **AskUserQuestion tool** to confirm user wants to proceed
@@ -52,7 +55,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -67,19 +70,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -98,7 +101,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
 
 All artifacts complete. All tasks complete.
diff --git a/.github/skills/openspec-explore/SKILL.md b/.github/skills/openspec-explore/SKILL.md
index 6858d3f..ca50074 100644
--- a/.github/skills/openspec-explore/SKILL.md
+++ b/.github/skills/openspec-explore/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
@@ -102,11 +102,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.github/skills/openspec-propose/SKILL.md b/.github/skills/openspec-propose/SKILL.md
index 4b7e204..51a52e1 100644
--- a/.github/skills/openspec-propose/SKILL.md
+++ b/.github/skills/openspec-propose/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Propose a new change - create the change and generate all artifacts in one step.
@@ -37,7 +37,7 @@ When ready to implement, run /opsx:apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -46,6 +46,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -63,10 +64,10 @@ When ready to implement, run /opsx:apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.kilocode/skills/openspec-apply-change/SKILL.md b/.kilocode/skills/openspec-apply-change/SKILL.md
deleted file mode 100644
index 70fbdb8..0000000
--- a/.kilocode/skills/openspec-apply-change/SKILL.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.kilocode/skills/openspec-archive-change/SKILL.md b/.kilocode/skills/openspec-archive-change/SKILL.md
deleted file mode 100644
index 12e2f70..0000000
--- a/.kilocode/skills/openspec-archive-change/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.kilocode/skills/openspec-explore/SKILL.md b/.kilocode/skills/openspec-explore/SKILL.md
deleted file mode 100644
index 6858d3f..0000000
--- a/.kilocode/skills/openspec-explore/SKILL.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Handling Different Entry Points
-
-**User brings a vague idea:**
-```
-User: I'm thinking about adding real-time collaboration
-
-You: Real-time collab is a big space. Let me think about this...
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
-
-      Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
-       trivial            moderate           complex
-
-      Where's your head at?
-```
-
-**User brings a specific problem:**
-```
-User: The auth system is a mess
-
-You: [reads codebase]
-
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
-
-     I see three tangles. Which one's burning?
-```
-
-**User is stuck mid-implementation:**
-```
-User: /opsx:explore add-auth-system
-      The OAuth integration is more complex than expected
-
-You: [reads change artifacts]
-
-     You're on task 4: "Implement OAuth flow"
-
-     Let me trace what's involved...
-
-     [draws diagram, explores options, suggests paths]
-
-     Want to update the design to reflect this?
-     Or add a spike task to investigate?
-```
-
-**User wants to compare options:**
-```
-User: Should we use Postgres or SQLite?
-
-You: Generic answer is boring. What's the context?
-
-User: A CLI tool that tracks local dev environments
-
-You: That changes everything.
-
-     ┌─────────────────────────────────────────────────┐
-     │          CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
-
-     Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
-
-                  SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
-
-     SQLite. Not even close.
-
-     Unless... is there a sync component?
-```
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When it feels like things are crystallizing, you might summarize:
-
-```
-## What We Figured Out
-
-**The problem**: [crystallized understanding]
-
-**The approach**: [if one emerged]
-
-**Open questions**: [if any remain]
-
-**Next steps** (if ready):
-- Create a change proposal
-- Keep exploring: just keep talking
-```
-
-But this summary is optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.kilocode/skills/openspec-propose/SKILL.md b/.kilocode/skills/openspec-propose/SKILL.md
deleted file mode 100644
index 4b7e204..0000000
--- a/.kilocode/skills/openspec-propose/SKILL.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
-
-**Steps**
-
-1. **If no clear input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.kilocode/workflows/opsx-apply.md b/.kilocode/workflows/opsx-apply.md
deleted file mode 100644
index a10693a..0000000
--- a/.kilocode/workflows/opsx-apply.md
+++ /dev/null
@@ -1,145 +0,0 @@
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! You can archive this change with `/opsx:archive`.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.kilocode/workflows/opsx-archive.md b/.kilocode/workflows/opsx-archive.md
deleted file mode 100644
index 46def16..0000000
--- a/.kilocode/workflows/opsx-archive.md
+++ /dev/null
@@ -1,150 +0,0 @@
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Spec sync status (synced / sync skipped / no delta specs)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success (No Delta Specs)**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** No delta specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success With Warnings**
-
-```
-## Archive Complete (with warnings)
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** Sync skipped (user chose to skip)
-
-**Warnings:**
-- Archived with 2 incomplete artifacts
-- Archived with 3 incomplete tasks
-- Delta spec sync was skipped (user chose to skip)
-
-Review the archive if this was not intentional.
-```
-
-**Output On Error (Archive Exists)**
-
-```
-## Archive Failed
-
-**Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
-
-Target archive directory already exists.
-
-**Options:**
-1. Rename the existing archive
-2. Delete the existing archive if it's a duplicate
-3. Wait until a different date to archive
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.kilocode/workflows/opsx-explore.md b/.kilocode/workflows/opsx-explore.md
deleted file mode 100644
index f4debae..0000000
--- a/.kilocode/workflows/opsx-explore.md
+++ /dev/null
@@ -1,166 +0,0 @@
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
-**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
-- A vague idea: "real-time collaboration"
-- A specific problem: "the auth system is getting unwieldy"
-- A change name: "add-dark-mode" (to explore in context of that change)
-- A comparison: "postgres vs sqlite for this"
-- Nothing (just enter explore mode)
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-If the user mentioned a specific change name, read its artifacts for context.
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.kilocode/workflows/opsx-propose.md b/.kilocode/workflows/opsx-propose.md
deleted file mode 100644
index 5085afc..0000000
--- a/.kilocode/workflows/opsx-propose.md
+++ /dev/null
@@ -1,99 +0,0 @@
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
-
-**Steps**
-
-1. **If no input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` to start implementing."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/.opencode/commands/opsx-apply.md b/.opencode/commands/opsx-apply.md
index 16d2ef3..9d0f3fc 100644
--- a/.opencode/commands/opsx-apply.md
+++ b/.opencode/commands/opsx-apply.md
@@ -23,6 +23,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -42,6 +43,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.opencode/commands/opsx-archive.md b/.opencode/commands/opsx-archive.md
index 2bd807a..8f4e144 100644
--- a/.opencode/commands/opsx-archive.md
+++ b/.opencode/commands/opsx-archive.md
@@ -23,8 +23,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Prompt user for confirmation to continue
@@ -45,7 +48,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -60,19 +63,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -91,7 +94,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs
 
 All artifacts complete. All tasks complete.
@@ -104,7 +107,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** No delta specs
 
 All artifacts complete. All tasks complete.
@@ -117,7 +120,7 @@ All artifacts complete. All tasks complete.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** Sync skipped (user chose to skip)
 
 **Warnings:**
@@ -134,7 +137,7 @@ Review the archive if this was not intentional.
 ## Archive Failed
 
 **Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Target:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 
 Target archive directory already exists.
 
diff --git a/.opencode/commands/opsx-explore.md b/.opencode/commands/opsx-explore.md
index 7db25f6..a4ed088 100644
--- a/.opencode/commands/opsx-explore.md
+++ b/.opencode/commands/opsx-explore.md
@@ -104,11 +104,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.opencode/commands/opsx-propose.md b/.opencode/commands/opsx-propose.md
index b063a7e..f100115 100644
--- a/.opencode/commands/opsx-propose.md
+++ b/.opencode/commands/opsx-propose.md
@@ -30,7 +30,7 @@ When ready to implement, run /opsx-apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -39,6 +39,7 @@ When ready to implement, run /opsx-apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -56,10 +57,10 @@ When ready to implement, run /opsx-apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.opencode/skills/openspec-apply-change/SKILL.md b/.opencode/skills/openspec-apply-change/SKILL.md
index 86c881d..87b5f9f 100644
--- a/.opencode/skills/openspec-apply-change/SKILL.md
+++ b/.opencode/skills/openspec-apply-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Implement tasks from an OpenSpec change.
@@ -30,6 +30,7 @@ Implement tasks from an OpenSpec change.
    ```
    Parse the JSON to understand:
    - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
    - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
 
 3. **Get apply instructions**
@@ -49,6 +50,8 @@ Implement tasks from an OpenSpec change.
    - If `state: "all_done"`: congratulate, suggest archive
    - Otherwise: proceed to implementation
 
+   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
+
 4. **Read context files**
 
    Read every file path listed under `contextFiles` from the apply instructions output.
diff --git a/.opencode/skills/openspec-archive-change/SKILL.md b/.opencode/skills/openspec-archive-change/SKILL.md
index 12e2f70..37b38eb 100644
--- a/.opencode/skills/openspec-archive-change/SKILL.md
+++ b/.opencode/skills/openspec-archive-change/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Archive a completed change in the experimental workflow.
@@ -30,8 +30,11 @@ Archive a completed change in the experimental workflow.
 
    Parse the JSON to understand:
    - `schemaName`: The workflow being used
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
    - `artifacts`: List of artifacts with their status (`done` or other)
 
+   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
+
    **If any artifacts are not `done`:**
    - Display warning listing incomplete artifacts
    - Use **AskUserQuestion tool** to confirm user wants to proceed
@@ -52,7 +55,7 @@ Archive a completed change in the experimental workflow.
 
 4. **Assess delta spec sync state**
 
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
 
    **If delta specs exist:**
    - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
@@ -67,19 +70,19 @@ Archive a completed change in the experimental workflow.
 
 5. **Perform the archive**
 
-   Create the archive directory if it doesn't exist:
+   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
    ```bash
-   mkdir -p openspec/changes/archive
+   mkdir -p "<planningHome.changesDir>/archive"
    ```
 
    Generate target name using current date: `YYYY-MM-DD-<change-name>`
 
    **Check if target already exists:**
    - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
+   - If no: Move `changeRoot` to the archive directory
 
    ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
    ```
 
 6. **Display summary**
@@ -98,7 +101,7 @@ Archive a completed change in the experimental workflow.
 
 **Change:** <change-name>
 **Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
 **Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
 
 All artifacts complete. All tasks complete.
diff --git a/.opencode/skills/openspec-explore/SKILL.md b/.opencode/skills/openspec-explore/SKILL.md
index 8c7225c..37ae6c1 100644
--- a/.opencode/skills/openspec-explore/SKILL.md
+++ b/.opencode/skills/openspec-explore/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
@@ -102,11 +102,10 @@ Think freely. When insights crystallize, you might offer:
 
 If the user mentions a change or you detect one is relevant:
 
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
+1. **Resolve and read existing artifacts for context**
+   - Run `openspec status --change "<name>" --json`.
+   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
+   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
 
 2. **Reference them naturally in conversation**
    - "Your design mentions using Redis, but we just realized SQLite fits better..."
diff --git a/.opencode/skills/openspec-propose/SKILL.md b/.opencode/skills/openspec-propose/SKILL.md
index 05fdc62..7caa2ef 100644
--- a/.opencode/skills/openspec-propose/SKILL.md
+++ b/.opencode/skills/openspec-propose/SKILL.md
@@ -6,7 +6,7 @@ compatibility: Requires openspec CLI.
 metadata:
   author: openspec
   version: "1.0"
-  generatedBy: "1.3.1"
+  generatedBy: "1.4.0"
 ---
 
 Propose a new change - create the change and generate all artifacts in one step.
@@ -37,7 +37,7 @@ When ready to implement, run /opsx-apply
    ```bash
    openspec new change "<name>"
    ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
 
 3. **Get the artifact build order**
    ```bash
@@ -46,6 +46,7 @@ When ready to implement, run /opsx-apply
    Parse the JSON to get:
    - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
    - `artifacts`: list of all artifacts with their status and dependencies
+   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -63,10 +64,10 @@ When ready to implement, run /opsx-apply
         - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
         - `template`: The structure to use for your output file
         - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
+        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
         - `dependencies`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
+      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
       - Apply `context` and `rules` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
diff --git a/.qwen/commands/opsx-apply.toml b/.qwen/commands/opsx-apply.toml
deleted file mode 100644
index 83a33d7..0000000
--- a/.qwen/commands/opsx-apply.toml
+++ /dev/null
@@ -1,149 +0,0 @@
-description = "Implement tasks from an OpenSpec change (Experimental)"
-
-prompt = """
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! You can archive this change with `/opsx:archive`.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
-"""
diff --git a/.qwen/commands/opsx-archive.toml b/.qwen/commands/opsx-archive.toml
deleted file mode 100644
index cf76b75..0000000
--- a/.qwen/commands/opsx-archive.toml
+++ /dev/null
@@ -1,154 +0,0 @@
-description = "Archive a completed change in the experimental workflow"
-
-prompt = """
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Prompt user for confirmation to continue
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Spec sync status (synced / sync skipped / no delta specs)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success (No Delta Specs)**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** No delta specs
-
-All artifacts complete. All tasks complete.
-```
-
-**Output On Success With Warnings**
-
-```
-## Archive Complete (with warnings)
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** Sync skipped (user chose to skip)
-
-**Warnings:**
-- Archived with 2 incomplete artifacts
-- Archived with 3 incomplete tasks
-- Delta spec sync was skipped (user chose to skip)
-
-Review the archive if this was not intentional.
-```
-
-**Output On Error (Archive Exists)**
-
-```
-## Archive Failed
-
-**Change:** <change-name>
-**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
-
-Target archive directory already exists.
-
-**Options:**
-1. Rename the existing archive
-2. Delete the existing archive if it's a duplicate
-3. Wait until a different date to archive
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
-"""
diff --git a/.qwen/commands/opsx-explore.toml b/.qwen/commands/opsx-explore.toml
deleted file mode 100644
index 8ccd312..0000000
--- a/.qwen/commands/opsx-explore.toml
+++ /dev/null
@@ -1,170 +0,0 @@
-description = "Enter explore mode - think through ideas, investigate problems, clarify requirements"
-
-prompt = """
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
-**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
-- A vague idea: "real-time collaboration"
-- A specific problem: "the auth system is getting unwieldy"
-- A change name: "add-dark-mode" (to explore in context of that change)
-- A comparison: "postgres vs sqlite for this"
-- Nothing (just enter explore mode)
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-If the user mentioned a specific change name, read its artifacts for context.
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
-"""
diff --git a/.qwen/commands/opsx-propose.toml b/.qwen/commands/opsx-propose.toml
deleted file mode 100644
index 8be4eaf..0000000
--- a/.qwen/commands/opsx-propose.toml
+++ /dev/null
@@ -1,103 +0,0 @@
-description = "Propose a new change - create it and generate all artifacts in one step"
-
-prompt = """
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
-
-**Steps**
-
-1. **If no input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` to start implementing."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
-"""
diff --git a/.qwen/skills/openspec-apply-change/SKILL.md b/.qwen/skills/openspec-apply-change/SKILL.md
deleted file mode 100644
index 70fbdb8..0000000
--- a/.qwen/skills/openspec-apply-change/SKILL.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.qwen/skills/openspec-archive-change/SKILL.md b/.qwen/skills/openspec-archive-change/SKILL.md
deleted file mode 100644
index 12e2f70..0000000
--- a/.qwen/skills/openspec-archive-change/SKILL.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create the archive directory if it doesn't exist:
-   ```bash
-   mkdir -p openspec/changes/archive
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move the change directory to archive
-
-   ```bash
-   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.qwen/skills/openspec-explore/SKILL.md b/.qwen/skills/openspec-explore/SKILL.md
deleted file mode 100644
index 6858d3f..0000000
--- a/.qwen/skills/openspec-explore/SKILL.md
+++ /dev/null
@@ -1,288 +0,0 @@
----
-name: openspec-explore
-description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Read existing artifacts for context**
-   - `openspec/changes/<name>/proposal.md`
-   - `openspec/changes/<name>/design.md`
-   - `openspec/changes/<name>/tasks.md`
-   - etc.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Handling Different Entry Points
-
-**User brings a vague idea:**
-```
-User: I'm thinking about adding real-time collaboration
-
-You: Real-time collab is a big space. Let me think about this...
-
-      COLLABORATION SPECTRUM
-      ════════════════════════════════════════════
-
-      Awareness          Coordination         Sync
-          │                   │                 │
-          ▼                   ▼                 ▼
-      ┌────────┐         ┌────────┐        ┌────────┐
-      │Presence│         │Cursors │        │  CRDT  │
-      │  "3    │         │ Multi  │        │Conflict│
-      │online" │         │ select │        │  free  │
-      └────────┘         └────────┘        └────────┘
-          │                   │                 │
-       trivial            moderate           complex
-
-      Where's your head at?
-```
-
-**User brings a specific problem:**
-```
-User: The auth system is a mess
-
-You: [reads codebase]
-
-     ┌─────────────────────────────────────────────┐
-     │              CURRENT AUTH FLOW              │
-     └─────────────────────────────────────────────┘
-                        │
-          ┌─────────────┼─────────────┐
-          ▼             ▼             ▼
-     ┌─────────┐  ┌─────────┐  ┌─────────┐
-     │ Google  │  │  GitHub │  │  Email  │
-     │  OAuth  │  │  OAuth  │  │  Magic  │
-     └────┬────┘  └────┬────┘  └────┬────┘
-          │             │             │
-          └─────────────┼─────────────┘
-                        ▼
-                  ┌───────────┐
-                  │  Session  │
-                  └─────┬─────┘
-                        │
-                        ▼
-                  ┌───────────┐
-                  │   Perms   │
-                  └───────────┘
-
-     I see three tangles. Which one's burning?
-```
-
-**User is stuck mid-implementation:**
-```
-User: /opsx:explore add-auth-system
-      The OAuth integration is more complex than expected
-
-You: [reads change artifacts]
-
-     You're on task 4: "Implement OAuth flow"
-
-     Let me trace what's involved...
-
-     [draws diagram, explores options, suggests paths]
-
-     Want to update the design to reflect this?
-     Or add a spike task to investigate?
-```
-
-**User wants to compare options:**
-```
-User: Should we use Postgres or SQLite?
-
-You: Generic answer is boring. What's the context?
-
-User: A CLI tool that tracks local dev environments
-
-You: That changes everything.
-
-     ┌─────────────────────────────────────────────────┐
-     │          CLI TOOL DATA STORAGE                  │
-     └─────────────────────────────────────────────────┘
-
-     Key constraints:
-     • No daemon running
-     • Must work offline
-     • Single user
-
-                  SQLite          Postgres
-     Deployment   embedded ✓      needs server ✗
-     Offline      yes ✓           no ✗
-     Single file  yes ✓           no ✗
-
-     SQLite. Not even close.
-
-     Unless... is there a sync component?
-```
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When it feels like things are crystallizing, you might summarize:
-
-```
-## What We Figured Out
-
-**The problem**: [crystallized understanding]
-
-**The approach**: [if one emerged]
-
-**Open questions**: [if any remain]
-
-**Next steps** (if ready):
-- Create a change proposal
-- Keep exploring: just keep talking
-```
-
-But this summary is optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own
diff --git a/.qwen/skills/openspec-propose/SKILL.md b/.qwen/skills/openspec-propose/SKILL.md
deleted file mode 100644
index 4b7e204..0000000
--- a/.qwen/skills/openspec-propose/SKILL.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-name: openspec-propose
-description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.3.1"
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx:apply
-
----
-
-**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
-
-**Steps**
-
-1. **If no clear input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `outputPath`: Where to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next
diff --git a/AGENTS.md b/AGENTS.md
index 0cdf1f4..8c456ce 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -135,14 +135,16 @@ See `CLAUDE.md` for deep architecture documentation, plugin contracts, and key d
   `NullLoggerFactory` produces zero allocations and zero output.
 - See [docs/configuration.md#what-gets-logged](docs/configuration.md#what-gets-logged) for the full per-class log
   inventory (level, trigger, structured properties).
-- **Connection-recovery logs** (added by the `add-connection-recovery` change) live in the runtime service classes that
-  own the connection (`NotificationBasedPublisher`, `OutboxPublisherService`, `KafkaPublisher`, `KafkaConsumer`,
-  `RabbitMqPublisher`) and use those classes' existing non-nullable `ILogger<T>`. **Exception:** `RabbitMqConsumer` has
-  no logger field (pre-existing exception to the logging-placement rule — message-receive errors silently NACK + requeue
-  with no useful context to log). Its connection disconnect/recovery events are therefore observable **only** via the
-  `raytree.connection.*` metric instruments; no log output. Plugins that emit connection-recovery metrics do so through
-  the public `RayTreeMeter.RecordConnectionDisconnect` / `RecordConnectionRecovery` / `RegisterConnectionStateGauge`
-  facade methods — no `InternalsVisibleTo` is granted to plugin assemblies for this purpose.
+- **Connection-recovery is log-only** — there are **no** connection metrics. The recovery logs live in the runtime
+  service classes that own the connection (`NotificationBasedPublisher`, `OutboxPublisherService`, `KafkaPublisher`,
+  `KafkaConsumer`, `RabbitMqPublisher`) and use those classes' existing non-nullable `ILogger<T>`. **Exception:**
+  `RabbitMqConsumer` has no logger field (pre-existing exception to the logging-placement rule — message-receive errors
+  silently NACK + requeue with no useful context to log). With the metrics removed it no longer subscribes to the SDK
+  recovery events at all, so its connection disconnect/recovery is **not observable** — accepted, consistent with its
+  no-logger posture. Each recovery-owning plugin tunes its loop via its own options type — `PostgresConnectionRecoveryOptions`
+  (PostgreSQL) and `KafkaConnectionRecoveryOptions` (Kafka); there is no shared Core options type and no Hosting binding.
+  `RayTreeMeter` exposes **no public metric-emission API** — all emit methods are `internal` and reachable only by Core
+  and IVT-privileged assemblies (`NotificationBasedPublisher`); its public surface is construct-and-observe only.
 
 ### Testing Conventions
 
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 288a1c1..67e9815 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,6 +6,31 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ---
 
+## [0.0.19-pre-release]
+
+### Removed — BREAKING
+- `ConnectionRecoveryOptions` (`RayTree.Core.Resilience`) and `ChangeTrackingRecoveryKeys` (`RayTree.Hosting`) are removed, along with the `ChangeTracking:Publisher:ConnectionRecovery` / `:Subscriber:ConnectionRecovery` config binding in `AddChangeTracking`. Each recovery-owning plugin now defines its own options type with identical field names, defaults, and validation: `PostgresConnectionRecoveryOptions` (`RayTree.Plugins.PostgreSQL.Resilience`) and `KafkaConnectionRecoveryOptions` (`RayTree.Plugins.Kafka`). The `ConnectionRecovery` property on `NotificationBasedPublisherOptions`, `KafkaPublisherOptions`, and `KafkaConsumerOptions` now returns the plugin-local type.
+- All four `raytree.connection.*` metric instruments (`disconnects`, `recoveries`, `recovery.duration`, `state`) are removed, along with the `RayTreeMeter` facade methods `RecordConnectionDisconnect`, `RecordConnectionRecovery`, and `RegisterConnectionStateGauge`. **Disconnect/recovery visibility is now log-only** (Postgres/Kafka retry + recovery + exhaustion logs; RabbitMQ publisher `Warning`/`Information`). The RabbitMQ consumer no longer observes recovery at all (no logger, no metrics). Dashboards/alerts built on any `raytree.connection.*` series break silently — a removed series produces no error, just a flat-lined chart.
+
+### Changed — BREAKING
+- `RayTreeMeter` exposes **no public metric-emission API**. `RecordPublishSuccess`, `RecordPublishFailure`, `RecordPayloadSize`, `RecordBatchSize`, and `RegisterPendingGauge` are now `internal` (all callers — Core and the IVT-privileged `NotificationBasedPublisher` — already see Core internals). The public surface collapses to `MeterName`, the constructors, `DefaultPendingCacheTtl`, and `Dispose()` — construct-and-observe only. Metric observation remains public via the `"RayTree"` meter name and `RayTree.OpenTelemetry`'s `AddRayTreeMetrics`.
+- `RabbitMqPublisher` and `RabbitMqConsumer` constructors no longer take a `RayTreeMeter?` parameter; `KafkaPublisher` and `KafkaConsumer` likewise drop their `RayTreeMeter?` parameter. The RabbitMQ/Kafka builder + subscriber extensions no longer forward a meter. Most callers go through the builder extensions and are unaffected; direct constructor callers drop the argument.
+
+### Migration
+- Recovery options — rename the type at the use site; field names and JSON keys below the section parent are unchanged:
+
+  ```csharp
+  // Before
+  builder.UseKafka(o => o.ConnectionRecovery = new RayTree.Core.Resilience.ConnectionRecoveryOptions { MaxAttempts = 5 });
+  // After
+  builder.UseKafka(o => o.ConnectionRecovery = new KafkaConnectionRecoveryOptions { MaxAttempts = 5 });
+  ```
+
+  The former host-bound `ChangeTracking:*:ConnectionRecovery` sections never auto-applied (callers had to merge them by hand); set recovery in the `UseKafka` / `UsePostgreSqlOutbox` configure lambda instead, reading your own bound section if desired.
+- Observability — drop any `raytree.connection.*` series from dashboards/alerts and switch to the recovery log signal.
+
+---
+
 ## [0.0.18-pre-release]
 
 ### Added
diff --git a/CLAUDE.md b/CLAUDE.md
index c46f048..63d46b1 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -60,7 +60,7 @@ EntityChangeTracker
 - **`IChangeSerializer`** / **`IChangeCompressor`** — stream-based interfaces. Serializers handle `EntityChange<TEntity>` with typed `State`. `NoOpCompressorPlugin` (built-in) is a passthrough for testing.
 - **`IOutbox`** — ten methods: `InitializeAsync`, `WriteAsync<TEntity>`, two `GetUnpublishedAsync<TEntity>` overloads (by batch size; or by `ChangeType?`, `DateTime? since`, batch size), `MarkPublishedAsync`, `TryClaimForPublishingAsync(id)` (atomically sets `published = TRUE WHERE published = FALSE`, returns `true` if this caller claimed it), `RevertClaimAsync(id)` (sets `published = FALSE` — used to undo a claim when publish fails so the fallback loop can retry), `GetByIdAsync<TEntity>`, `GetPendingCountAsync(Type entityType)` (returns `long` — count of unpublished records for the given entity type; used by the `raytree.outbox.pending` observable gauge; throws `InvalidOperationException` if called with the wrong entity type for a typed implementation), `CleanupPublishedAsync(retentionPeriod)`, `CleanupStaleUnpublishedAsync(staleThreshold)`. Both cleanup methods return the count of rows deleted.
 
-- **`RayTreeMeter`** (`src/RayTree.Core/Telemetry`) — owns a single `System.Diagnostics.Metrics.Meter("RayTree", <assembly-version>)` and all 18 instruments (counters, histograms, and one observable gauge). Created by `ChangeTrackingBuilder` when `UseMeter` is not called; `EntityChangeTracker` disposes it only when it created it (the `ownsMeter` flag tracks this). When the caller supplies their own meter via `UseMeter(RayTreeMeter)`, the caller owns disposal. `RegisterPendingGauge(Func<IEnumerable<(Type, IOutbox)>>)` registers the `raytree.outbox.pending` observable gauge; the callback samples `IOutbox.GetPendingCountAsync` per registered entity type and caches results for `DefaultPendingCacheTtl = 10s` to bound DB round-trips. All instruments are tagged with `entity_type`; change-specific instruments add `change_type`; skipped-message counters add `reason`. The class exposes `internal` instrument properties consumed by `EntityChangeTracker`, `OutboxPublisherService`, and `ChangeSubscriber`. `RayTreeMeter.MeterName` is a public constant equal to `"RayTree"`. See [docs/opentelemetry-metrics.md](docs/opentelemetry-metrics.md) for the full instrument inventory and unit conventions (`s` for durations, `By` for bytes).
+- **`RayTreeMeter`** (`src/RayTree.Core/Telemetry`) — owns a single `System.Diagnostics.Metrics.Meter("RayTree", <assembly-version>)` and all 14 outbox/subscriber instruments (counters, histograms, and the `raytree.outbox.pending` observable gauge). The four `raytree.connection.*` instruments were removed — connection recovery is now observed via logs only. Created by `ChangeTrackingBuilder` when `UseMeter` is not called; `EntityChangeTracker` disposes it only when it created it (the `ownsMeter` flag tracks this). When the caller supplies their own meter via `UseMeter(RayTreeMeter)`, the caller owns disposal. `RegisterPendingGauge(Func<IEnumerable<(Type, IOutbox)>>)` (now `internal`) registers the `raytree.outbox.pending` observable gauge; the callback samples `IOutbox.GetPendingCountAsync` per registered entity type and caches results for `DefaultPendingCacheTtl = 10s` to bound DB round-trips. All instruments are tagged with `entity_type`; change-specific instruments add `change_type`; skipped-message counters add `reason`. The class exposes `internal` instrument properties and `internal` emit methods (`RecordPublishSuccess`, `RecordPublishFailure`, `RecordPayloadSize`, `RecordBatchSize`, `RegisterPendingGauge`) consumed by `EntityChangeTracker`, `OutboxPublisherService`, `ChangeSubscriber`, and the IVT-privileged `NotificationBasedPublisher`. The public surface is now construct-and-observe only: `MeterName`, the constructors, `DefaultPendingCacheTtl`, and `Dispose()` — all metric emission is internal. `RayTreeMeter.MeterName` is a public constant equal to `"RayTree"`. See [docs/opentelemetry-metrics.md](docs/opentelemetry-metrics.md) for the full instrument inventory and unit conventions (`s` for durations, `By` for bytes).
 - **`ChangeSubscriber`** — internal implementation detail owned by `EntityChangeTracker`. Receives `MessageEnvelope` from an `IQueueConsumer`, deduplicates on `CorrelationId` via `IDeduplicationStore`, decompresses and deserializes the payload using reflection (`DeserializeCoreAsync<TEntity>` via `MethodInfo.MakeGenericMethod`), then dispatches to registered `ChangeHandlerAsync<TEntity>` handlers with retry. `ConsumeFromConsumerAsync` and `ConsumeFromQueueAsync` use `Parallel.ForEachAsync` bounded by `SubscriberOptions.MaxDegreeOfParallelism` (default 1 — sequential, preserves per-partition ordering). When all handlers succeed, calls `MaybeDedupCleanupAsync` to periodically evict old dedup entries (gated by `SubscriberOptions.DeduplicationCleanupInterval`); a `SemaphoreSlim` gate ensures only one concurrent invocation runs cleanup at a time. When a handler exhausts retries and throws (`SkipOnFailure = false`), reverts the dedup mark via `RevertProcessedAsync` before rethrowing — this ensures the redelivered message can be retried rather than silently dropped by a persistent dedup store. Still public for direct low-level usage (e.g., standalone subscriber tests), but not the primary API. Constructor signature: `(ILogger<ChangeSubscriber> logger, RayTreeMeter meter, IDeduplicationStore? dedupStore = null, SubscriberOptions? options = null)` — logger and meter are required non-null parameters. Emits `raytree.subscriber.messages.skipped` (with `reason="unknown_type"` or `reason="no_handler"`), `raytree.subscriber.messages.deduplicated`, `raytree.subscriber.messages.processed`, and `raytree.subscriber.lag.duration` from `ProcessMessageAsync`. `InvokeWithRetryAsync` records `raytree.subscriber.processing.duration` per attempt (success or failure), `raytree.subscriber.handler.attempts` on every completed dispatch (success or failure), and `raytree.subscriber.handler.failures` on exhaustion. Logs unknown entity types at `Warning`; dedup hits at `Debug`; no-handler-match at `Debug`; successful message dispatch at `Debug`; dedup revert on handler failure at `Warning`; retry attempts at `Warning`; SkipOnFailure drops at `Error`; dedup cleanup errors at `Error`.
 - **`ChangeSubscriberBuilder` / `IChangeSubscriberBuilder`** — standalone subscriber-only builder. Produces a `ChangeSubscriber` via `Build()`. `ChangeTrackingBuilder` composes one internally; `BuildInternal()` calls `_subscriberBuilder.Build()` and passes the result to the `EntityChangeTracker` constructor.
 
@@ -115,25 +115,23 @@ All durations are emitted in seconds (`s`) per OTel semantic conventions; bytes
 
 `EntityChangeInterceptor` hooks into `SaveChangesAsync` to automatically call `TrackInsertAsync`/`TrackUpdateAsync`/`TrackDeleteAsync` based on EF change tracker state.
 
-### Connection recovery (`src/RayTree.Core/Resilience` + per-plugin)
+### Connection recovery (per-plugin)
 
-Every connection-bearing plugin emits four shared metric instruments on the `"RayTree"` meter so broker / database connection state is uniformly observable: `raytree.connection.disconnects` (counter), `raytree.connection.recoveries` (counter with `outcome=succeeded|exhausted`), `raytree.connection.recovery.duration` (histogram, seconds), `raytree.connection.state` (observable gauge: `1` connected / `0` in fault cycle). All four are tagged with `component` and `endpoint`. Helper methods `RayTreeMeter.RecordConnectionDisconnect` / `RecordConnectionRecovery` / `RegisterConnectionStateGauge` are public — **no `InternalsVisibleTo` is granted to plugin assemblies for this purpose**; plugins consume Core via the public API only.
+Connection recovery is **behavior + logs only — there are no connection metrics**. The recovery-owning plugins each define their own options type carrying the exponential-backoff shape: `PostgresConnectionRecoveryOptions` (`src/RayTree.Plugins.PostgreSQL/Resilience`) and `KafkaConnectionRecoveryOptions` (`src/RayTree.Plugins.Kafka`). Both are near-verbatim copies of the same six members (`Enabled`, `InitialDelay`, `MaxDelay`, `Factor`, `JitterFraction`, `MaxAttempts`) with per-field init guards and a `Validate()` cross-field check. There is **no** shared Core options type (the former `RayTree.Core.Resilience.ConnectionRecoveryOptions` was removed) and **no** Hosting binding (the former `ChangeTrackingRecoveryKeys` + `services.Configure<ConnectionRecoveryOptions>(...)` calls were removed); callers configure recovery per plugin in the `UseKafka` / `UsePostgreSqlOutbox` configure lambda.
 
-Recovery shape per plugin:
+Recovery shape per plugin (logs only — disconnect/recovery are no longer counted):
 
-- **`postgres.notification`** (`NotificationBasedPublisher.ListenLoopAsync`) — single long-lived `NpgsqlConnection` as a local `await using var` (no class field). On a fault classified by the shared `PostgresFault.IsConnectionFault` static helper (uses `Npgsql.PostgresErrorCodes` constants — admin/crash shutdown, `08xxx` connection_exception family, transient `NpgsqlException`, `SocketException`/`IOException` inner, `ObjectDisposedException`), runs an inline exponential-backoff loop bounded by `NotificationBasedPublisherOptions.ConnectionRecovery` that disposes the connection, opens a fresh one, reissues `LISTEN`. Single method, one `try`, two `catch` arms. Fallback polling continues throughout.
-- **`postgres.outbox`** — **observation only, no rebuild.** Two seams emit the metric:
-  - *OutboxPublisherService.ProcessBatchAsync*: `HandleBatchError` consults `IOutbox.IsConnectionFault` + `ConnectionComponent` in the existing batch-error catch. On a classified fault: emit `disconnects`, demote per-batch `Error` log to `Warning`, set `_outboxUnhealthy = true` + `_firstUnhealthyAt`. On the first subsequent successful batch: emit `recoveries{outcome="succeeded"}` + duration via `EmitOutboxRecovered`.
+- **`postgres.notification`** (`NotificationBasedPublisher.ListenLoopAsync`) — single long-lived `NpgsqlConnection` as a local `await using var` (no class field). On a fault classified by the shared `PostgresFault.IsConnectionFault` static helper (uses `Npgsql.PostgresErrorCodes` constants — admin/crash shutdown, `08xxx` connection_exception family, transient `NpgsqlException`, `SocketException`/`IOException` inner, `ObjectDisposedException`), logs a `Warning` once per fault cycle, then runs an inline exponential-backoff loop bounded by `NotificationBasedPublisherOptions.ConnectionRecovery` (a `PostgresConnectionRecoveryOptions`) that disposes the connection, opens a fresh one, reissues `LISTEN`. On reconnect logs `Information`; on `MaxAttempts` exhaustion logs `Error` and exits the loop. Fallback polling continues throughout.
+- **`postgres.outbox`** — **observation only, no rebuild.** Two seams classify faults:
+  - *OutboxPublisherService.ProcessBatchAsync*: `HandleBatchError` consults `IOutbox.IsConnectionFault` + `ConnectionComponent` in the existing batch-error catch. On a classified fault: demote per-batch `Error` log to `Warning`, set `_unhealthySince`. On the first subsequent successful batch: log an `Information` "outbox connection recovered" entry via `EmitOutboxRecovered`.
   - *NotificationBasedPublisher.FallbackPollingLoopAsync*: `ProcessSingleOutboxAsync` does the same classification per outbox, keyed on entity type via a `ConcurrentDictionary<Type, FallbackOutboxState>` so each outbox tracks its own transitions independently.
 
   `IOutbox` exposes three default-implemented members (`IsConnectionFault`, `ConnectionComponent`, `ConnectionEndpoint`) that `PostgreSqlOutbox<TEntity>` overrides via `PostgresFault`. The polling cadence is the natural retry — no rebuild loop. Non-fault exceptions preserve the original `Error` path. `InMemoryOutbox` and third-party `IOutbox` implementations inherit no-op defaults — no breaking change.
-- **`kafka.publisher`** — `SetErrorHandler` callback flips an atomic `Interlocked.CompareExchange` flag (`_faultTicks` UTC-ticks) and emits the disconnect metric. The callback does **no locking** and **no disposal** (avoids the documented Confluent.Kafka footgun of disposing inside the native callback). The next `PublishAsync` enters `GetProducerAsync` under a single `_buildLock`, disposes the dead producer on a normal call thread, re-runs the `WaitForTopic` probe (when enabled), builds a fresh producer, and emits the recovery metric. No inner backoff loop — the outbox-publisher retry loop is the outer cadence. State: 2 fields (`_producer`, `_faultTicks`) + 1 lock.
-- **`kafka.consumer`** — fatal `KafkaException` on the dedicated poll thread → drops pending deferred-ack actions (broker redelivers via at-least-once contract on the new consumer's join) → disposes the dying consumer → runs an inline exponential-backoff `RebuildConsumer` on the same poll thread (re-runs `WaitForTopic` probe + `Subscribe`). Backoff math is a small private static helper (`Task.Delay(...).GetAwaiter().GetResult()` is safe here — the poll thread is dedicated with no SyncContext). On exhaustion completes the buffer channel with the fatal exception.
-- **`rabbitmq.publisher`** / **`rabbitmq.consumer`** — **observe, don't own**. `RabbitMQ.Client.AutomaticRecoveryEnabled` (library default — RayTree does **not** disable it) performs the actual rebuild. Publisher subscribes to `ConnectionShutdownAsync` (Warning + disconnect metric when `Initiator != Application`), `RecoverySucceededAsync` (Information + recovery metric + duration), `ConnectionRecoveryErrorAsync` (Information only — per-internal-attempt, no metric). Consumer subscribes to shutdown + recovery events for metrics only (no logger field — pre-existing exception to the logging-placement rule stands). `RabbitMqPublisherOptions` / `RabbitMqConsumerOptions` do **not** expose `ConnectionRecovery` — the library's `NetworkRecoveryInterval` controls timing, exposed via `ConnectionFactory` not through RayTree.
+- **`kafka.publisher`** — `SetErrorHandler` callback flips an atomic `Interlocked.CompareExchange` flag (`_faultTicks` UTC-ticks) and logs a `Warning`. The callback does **no locking** and **no disposal** (avoids the documented Confluent.Kafka footgun of disposing inside the native callback). The next `PublishAsync` enters `GetProducerAsync` under a single `_buildLock`, disposes the dead producer on a normal call thread, re-runs the `WaitForTopic` probe (when enabled), builds a fresh producer, and logs `Information`. No inner backoff loop — the outbox-publisher retry loop is the outer cadence. State: 2 fields (`_producer`, `_faultTicks`) + 1 lock.
+- **`kafka.consumer`** — fatal `KafkaException` on the dedicated poll thread → drops pending deferred-ack actions (broker redelivers via at-least-once contract on the new consumer's join) → disposes the dying consumer → runs an inline exponential-backoff `RebuildConsumer` on the same poll thread (re-runs `WaitForTopic` probe + `Subscribe`), bounded by `KafkaConsumerOptions.ConnectionRecovery` (a `KafkaConnectionRecoveryOptions`). Backoff math is a small private static helper (`Task.Delay(...).GetAwaiter().GetResult()` is safe here — the poll thread is dedicated with no SyncContext). On exhaustion completes the buffer channel with the fatal exception.
+- **`rabbitmq.publisher`** / **`rabbitmq.consumer`** — **observe, don't own**. `RabbitMQ.Client.AutomaticRecoveryEnabled` (library default — RayTree does **not** disable it) performs the actual rebuild. Publisher subscribes to `ConnectionShutdownAsync` (Warning when `Initiator != Application`), `RecoverySucceededAsync` (Information + duration), `ConnectionRecoveryErrorAsync` (Information only — per-internal-attempt). The publisher constructor no longer takes a `RayTreeMeter`. Consumer no longer subscribes to recovery events at all (its subscriptions existed solely to feed the removed metrics) and its constructor no longer takes a `RayTreeMeter` — it is silent for recovery, consistent with its no-logger posture. `RabbitMqPublisherOptions` / `RabbitMqConsumerOptions` do **not** expose `ConnectionRecovery` — the library's `NetworkRecoveryInterval` controls timing, exposed via `ConnectionFactory` not through RayTree.
 
-The retry math (~20 LoC: exponential backoff with `±JitterFraction` jitter, capped at `MaxDelay`, optionally bounded by `MaxAttempts`) is duplicated across the two plugins that need it (Postgres LISTEN, Kafka consumer). This is intentional — extracting a shared helper would require either `InternalsVisibleTo` exposure to plugins (architectural smell — plugins must consume Core via public API only) or a public-API commitment to a specific retry shape. Two short copies is cheaper than either of those.
-
-`ConnectionRecoveryOptions` is bound from `appsettings.json` via `AddChangeTracking` into named options (`ChangeTrackingRecoveryKeys.Publisher` / `.Subscriber` constants). Plugins do **not** auto-swap the bound default into their own `ConnectionRecovery` property (would require `IServiceProvider` plumbing through plugin builder extension signatures — out of scope); callers who want to honor the bound defaults resolve them via `IOptionsMonitor<ConnectionRecoveryOptions>.Get(key)` and assign explicitly. In practice most callers tune per plugin anyway.
+The retry math (~20 LoC: exponential backoff with `±JitterFraction` jitter, capped at `MaxDelay`, optionally bounded by `MaxAttempts`) is duplicated across the two plugins that need it (Postgres LISTEN, Kafka consumer), as are the `Validate()`d options records. This is intentional — extracting a shared helper/type would require either `InternalsVisibleTo` exposure to plugins (architectural smell — plugins must consume Core via public API only) or a public-API commitment to a specific retry shape. Two short copies is cheaper than either of those.
 
 ## Key Design Decisions
 
diff --git a/Directory.Build.props b/Directory.Build.props
index 626595f..87714c2 100644
--- a/Directory.Build.props
+++ b/Directory.Build.props
@@ -7,7 +7,7 @@
     <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
     <WarningsAsErrors>nullable</WarningsAsErrors>
 
-    <VersionPrefix>0.0.18</VersionPrefix>
+    <VersionPrefix>0.0.19</VersionPrefix>
     <VersionSuffix>pre-release</VersionSuffix>
 
     <Authors>bitc0der</Authors>
diff --git a/Directory.Packages.props b/Directory.Packages.props
index 971fb6e..a142424 100644
--- a/Directory.Packages.props
+++ b/Directory.Packages.props
@@ -14,13 +14,13 @@
     <PackageVersion Include="Microsoft.EntityFrameworkCore" Version="10.0.8" />
     <PackageVersion Include="Microsoft.EntityFrameworkCore.InMemory" Version="10.0.8" />
     <!-- Database -->
-    <PackageVersion Include="Npgsql" Version="10.0.2" />
-    <PackageVersion Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="10.0.1" />
+    <PackageVersion Include="Npgsql" Version="10.0.3" />
+    <PackageVersion Include="Npgsql.EntityFrameworkCore.PostgreSQL" Version="10.0.2" />
     <!-- Redis -->
-    <PackageVersion Include="StackExchange.Redis" Version="2.13.1" />
+    <PackageVersion Include="StackExchange.Redis" Version="2.13.17" />
     <!-- Queue brokers -->
     <PackageVersion Include="RabbitMQ.Client" Version="7.2.1" />
-    <PackageVersion Include="Confluent.Kafka" Version="2.14.0" />
+    <PackageVersion Include="Confluent.Kafka" Version="2.14.2" />
     <!-- Serialization -->
     <PackageVersion Include="protobuf-net" Version="3.2.56" />
     <PackageVersion Include="MessagePack" Version="3.1.6" />
@@ -31,9 +31,9 @@
     <PackageVersion Include="OpenTelemetry.Api" Version="1.15.3" />
     <!-- Testing -->
     <PackageVersion Include="NUnit" Version="4.6.1" />
-    <PackageVersion Include="NUnit.Analyzers" Version="4.13.0" />
+    <PackageVersion Include="NUnit.Analyzers" Version="4.14.0" />
     <PackageVersion Include="NUnit3TestAdapter" Version="6.2.0" />
-    <PackageVersion Include="Microsoft.NET.Test.Sdk" Version="18.5.1" />
+    <PackageVersion Include="Microsoft.NET.Test.Sdk" Version="18.6.0" />
     <PackageVersion Include="Moq" Version="4.20.72" />
     <PackageVersion Include="Testcontainers.PostgreSql" Version="4.12.0" />
     <PackageVersion Include="Testcontainers.RabbitMq" Version="4.12.0" />
diff --git a/docs/opentelemetry-metrics.md b/docs/opentelemetry-metrics.md
index d8bdbc1..f9893e2 100644
--- a/docs/opentelemetry-metrics.md
+++ b/docs/opentelemetry-metrics.md
@@ -72,25 +72,7 @@ All instruments are tagged with `entity_type`. Counters and histograms tied to a
 
 ### Connection recovery
 
-Emitted by every connection-bearing plugin to make broker / database connection state observable. Tagged with `component` (one of `"rabbitmq.publisher"`, `"rabbitmq.consumer"`, `"kafka.publisher"`, `"kafka.consumer"`, `"postgres.notification"`, `"postgres.outbox"`) and `endpoint` (broker host:port or LISTEN channel name — never caller-supplied data).
-
-| Instrument | Kind | Unit | Tags | Source |
-|---|---|---|---|---|
-| `raytree.connection.disconnects` | counter | `{disconnects}` | `component`, `endpoint` | Each new fault cycle. RabbitMQ: `ConnectionShutdownAsync` with non-`Application` initiator. Kafka publisher: producer error handler with `Error.IsFatal`. Kafka consumer: fatal `KafkaException` from `Consume`. Postgres LISTEN: `WaitAsync` throws a classified connection fault. Postgres outbox: `OutboxPublisherService.ProcessBatchAsync` catches an exception classified by `IOutbox.IsConnectionFault`. |
-| `raytree.connection.recoveries` | counter | `{recoveries}` | `component`, `endpoint`, `outcome` (`"succeeded"` \| `"exhausted"`) | One per completed recovery cycle. RabbitMQ: `RecoverySucceededAsync` event (always `"succeeded"`). Kafka / Postgres: emitted when the plugin's rebuild loop completes or exhausts `ConnectionRecovery.MaxAttempts`. Postgres outbox: emitted on the first successful batch after a fault. |
-| `raytree.connection.recovery.duration` | histogram | `s` | `component`, `endpoint`, `outcome` | Wall-clock seconds from first detection to recovery completion (success or exhaustion). |
-| `raytree.connection.state` | observable gauge | `{state}` | `component`, `endpoint` | `1` while connected, `0` while in a fault cycle. Sampled per OTel collection tick. |
-
-#### Postgres has two components
-
-Postgres emits two distinct `component` values because they observe different code paths with different recovery shapes:
-
-- **`postgres.notification`** — the long-lived LISTEN connection inside `NotificationBasedPublisher.ListenLoopAsync`. Recovery is **active**: the plugin reconnects with exponential backoff bounded by `NotificationBasedPublisherOptions.ConnectionRecovery`.
-- **`postgres.outbox`** — the short-lived pooled connections used by `PostgreSqlOutbox` operations called from `OutboxPublisherService` and `NotificationBasedPublisher.FallbackPollingLoopAsync`. Recovery is **passive observation only**: the polling loop already retries naturally on the next tick; we just emit metrics + demote the per-batch `Error` log to `Warning` so a transient Postgres blip looks like one fault cycle, not a stream of unrelated errors.
-
-#### RabbitMQ recovery owned by the SDK
-
-RabbitMQ recovery is performed by `RabbitMQ.Client`'s built-in `AutomaticRecoveryEnabled = true`. RayTree subscribes to the SDK's `ConnectionShutdownAsync` / `RecoverySucceededAsync` events for metric emission only — no recovery code lives in RayTree. The library's `NetworkRecoveryInterval` controls timing; RayTree's `ConnectionRecoveryOptions` does not apply to RabbitMQ.
+Connection recovery is **not** exposed as metrics. The reconnect loops (Postgres LISTEN, Kafka publisher/consumer rebuild) and the outbox connection-fault log demotion all remain, but disconnect/recovery visibility is **log-only**: Postgres/Kafka emit retry, recovery, and exhaustion logs at `Information`/`Error`; the RabbitMQ publisher logs `Warning` on shutdown and `Information` on recovery (the RabbitMQ consumer has no logger and is silent for recovery). Each recovery-owning plugin tunes its loop via its own options type — `PostgresConnectionRecoveryOptions` (PostgreSQL) and `KafkaConnectionRecoveryOptions` (Kafka). RabbitMQ recovery is owned by `RabbitMQ.Client`'s `AutomaticRecoveryEnabled` (library default) and has no RayTree options.
 
 ## Conventions
 
@@ -116,7 +98,6 @@ Defaults from OTel's histogram aggregation are tuned for HTTP latencies. For Ray
 .AddView("raytree.outbox.publish.attempts",     new ExplicitBucketHistogramConfiguration { Boundaries = new[] { 1d, 2, 3, 5, 10 } })
 .AddView("raytree.subscriber.handler.attempts", new ExplicitBucketHistogramConfiguration { Boundaries = new[] { 1d, 2, 3, 5, 10 } })
 .AddView("raytree.outbox.payload.size",         new ExplicitBucketHistogramConfiguration { Boundaries = new[] { 256d, 1024, 4096, 16384, 65536, 262144, 1048576 } })
-.AddView("raytree.connection.recovery.duration", new ExplicitBucketHistogramConfiguration { Boundaries = new[] { 0.1, 0.5, 1, 2, 5, 10, 30, 60, 120 } })
 ```
 
 ## Sample dashboards
@@ -129,9 +110,8 @@ Typical queries against the published metric names:
 - **Failure ratio**: `rate(raytree_outbox_messages_failed_total[5m]) / rate(raytree_outbox_writes_total[5m])`
 - **Outbox backlog alert**: `raytree_outbox_pending > 10000 for 5m`
 - **Retry shape**: `histogram_quantile(0.99, sum by (le) (rate(raytree_subscriber_handler_attempts_bucket[5m])))` — values > 1 indicate handlers are retrying
-- **Currently disconnected**: `raytree_connection_state == 0` — alert on `for: 1m` to allow normal in-flight recoveries to complete before paging
-- **Recovery flapping**: `rate(raytree_connection_recoveries_total{outcome="succeeded"}[15m]) > 0.1` — more than 6 recoveries per hour suggests a broker / network issue
-- **Recovery exhausted**: `increase(raytree_connection_recoveries_total{outcome="exhausted"}[1h]) > 0` — paging-grade alert; the plugin gave up
+
+Connection disconnect/recovery is no longer exposed as metrics — observe it through the plugin recovery logs (Postgres/Kafka retry + recovery, RabbitMQ publisher `Warning`/`Information`).
 
 ## Custom meter injection
 
diff --git a/openspec/changes/archive/2026-06-02-per-place-recovery-options/.openspec.yaml b/openspec/changes/archive/2026-06-02-per-place-recovery-options/.openspec.yaml
new file mode 100644
index 0000000..db47328
--- /dev/null
+++ b/openspec/changes/archive/2026-06-02-per-place-recovery-options/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-06-02
diff --git a/openspec/changes/archive/2026-06-02-per-place-recovery-options/design.md b/openspec/changes/archive/2026-06-02-per-place-recovery-options/design.md
new file mode 100644
index 0000000..aa19d1d
--- /dev/null
+++ b/openspec/changes/archive/2026-06-02-per-place-recovery-options/design.md
@@ -0,0 +1,82 @@
+## Context
+
+Connection recovery (PR archived 2026-05-24) introduced two deliberately asymmetric decisions:
+
+1. **Retry logic is per-plugin.** Each plugin that owns a reconnect loop (Postgres LISTEN, Kafka publisher/consumer) hand-rolls ~20 lines of exponential-backoff math. There is **no** shared `ConnectionRetry` helper in Core — extracting one was explicitly rejected because it would force `InternalsVisibleTo` exposure (plugins reaching into Core internals) or a public-API commitment to one retry shape. The exception classifiers (`PostgresFault.IsConnectionFault`, Kafka's `Error.IsFatal` check) are likewise per-plugin.
+
+2. **Config shape is shared.** A single `ConnectionRecoveryOptions` record lives in `RayTree.Core.Resilience` and is referenced by `NotificationBasedPublisherOptions`, `KafkaPublisherOptions`, and `KafkaConsumerOptions`. `RayTree.Hosting` binds it generically from `ChangeTracking:{Publisher,Subscriber}:ConnectionRecovery` into named options via `ChangeTrackingRecoveryKeys`.
+
+The asymmetry is the problem. The shared record is the *only* remaining config coupling from Core to recovery-capable plugins, and it sits directly on top of duplicated loops that consume it. It also leaks: RabbitMQ never references it (SDK owns recovery), and `Factor`/`MaxAttempts`/`InitialDelay` are only meaningful to a hand-rolled exponential loop — a future library-managed plugin would inherit fields that silently do nothing. The host-bound default is also notional: `AddChangeTracking` binds the record into named options, but nothing auto-injects it into plugin construction — callers must resolve `IOptionsMonitor<ConnectionRecoveryOptions>.Get(key)` and merge by hand (documented in `ChangeTrackingRecoveryKeys`). So the "shared default" buys almost nothing in practice.
+
+This change moves the config next to the loop that consumes it, completing decision (1)'s logic: if the loop is per-plugin, the loop's tuning record should be too.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Remove `ConnectionRecoveryOptions` from `RayTree.Core`. Give each recovery-owning plugin its own options type carrying only the fields its loop uses: `PostgresConnectionRecoveryOptions` (PostgreSQL), `KafkaConnectionRecoveryOptions` (Kafka).
+- Repoint the three plugin options classes' `ConnectionRecovery` property to the plugin-local type, preserving field names, defaults, and validation semantics (type-identity move, not behavioral).
+- Remove the Hosting generic binding (`ChangeTrackingRecoveryKeys` + the two `Configure<ConnectionRecoveryOptions>` calls), since the shared type it bound no longer exists and the merge was manual anyway.
+- Remove the connection-recovery **metrics** entirely: all four `raytree.connection.*` instruments, the three `RayTreeMeter` facade methods, the internal state-gauge registry, and every emission call site. The other `RayTreeMeter` instruments stay; `RayTreeMeter` itself stays a required constructor dependency where it already was (it still serves outbox/subscriber metrics).
+- Preserve all recovery *behavior* and *logs*: reconnect loops, exception classifiers, the `IOutbox` connection-fault members, the `Error→Warning` outbox log demotion, and every recovery log entry are untouched.
+
+**Non-Goals:**
+- Changing the retry/backoff math, the exception classifiers, or any log levels/messages (beyond deleting the now-orphaned metric calls inside otherwise-unchanged log handlers).
+- Removing recovery *behavior* or recovery *logs*. Only metric emission is removed.
+- Adding per-plugin configuration binding in Hosting (callers bind their own sections, or configure in code).
+- Extracting a shared backoff helper or value type. (See Decisions — explicitly rejected to avoid re-introducing the coupling we're removing.)
+- Removing other `RayTreeMeter` instruments or the meter itself.
+
+## Decisions
+
+### 1. Two plugin-local options types, not one shared and not one per consumer
+
+`RayTree.Plugins.PostgreSQL` defines `PostgresConnectionRecoveryOptions`; `RayTree.Plugins.Kafka` defines `KafkaConnectionRecoveryOptions`. Both are near-verbatim copies of the current `ConnectionRecoveryOptions` (same six members, same per-field init guards, same `Validate()` cross-field check).
+
+- **Why two and not three** (publisher vs consumer in Kafka): both Kafka loops have identical tuning needs and live in the same assembly. One `KafkaConnectionRecoveryOptions` shared by `KafkaPublisherOptions` and `KafkaConsumerOptions` keeps the Kafka surface DRY *within its own boundary* — that's intra-assembly reuse, not cross-package coupling, so it's free.
+- **Why copy the validation** rather than share a Core helper: the project already accepted this exact trade for the retry loop ("two short copies is cheaper than `InternalsVisibleTo` or a public-API retry-shape commitment"). The validated options record is ~90 lines of pure, stable data with no plugin-specific branching; duplicating it across two assemblies is the same honest cost as the duplicated loops it pairs with. **Alternative considered:** a shared public `BackoffSchedule` value type in Core. Rejected *for this change* — it re-introduces the Core→plugin type dependency we're removing, just under a different name. If a third recovery-owning plugin ever lands and a true common shape is proven, extract then (YAGNI).
+
+### 2. Keep field names and defaults identical
+
+`Enabled=true`, `InitialDelay=1s`, `MaxDelay=30s`, `Factor=2.0`, `JitterFraction=0.2`, `MaxAttempts=null`. Validation: `InitialDelay>0`, `MaxDelay>=InitialDelay` (via `Validate()`), `Factor>=1`, `0<=JitterFraction<=1`, `MaxAttempts==null||>0`. Identical names mean the appsettings *keys* a caller binds don't change — only the section's parent and the bound CLR type do. Identical defaults mean no behavioral drift for callers who never set the options.
+
+### 3. Remove Hosting binding outright (no replacement plumbing)
+
+Delete `ChangeTrackingRecoveryKeys` and the two `services.Configure<ConnectionRecoveryOptions>(...)` calls in `ServiceCollectionExtensions`. Callers who want config-driven recovery set it on the plugin options directly in the `UseKafka`/`UsePostgreSqlOutbox` configure lambda, optionally reading their own bound section. **Why no per-plugin binding:** wiring bound defaults into plugin construction would require `IServiceProvider` plumbing through every plugin builder-extension signature — out of scope when this change was archived, and still out of scope. The manual-merge pattern the old keys documented had no automatic effect; removing it loses no working behavior.
+
+### 4. Remove the connection metrics, keep the logs
+
+The connection-recovery metrics were the *second* piece of Core that plugins reach into (via the `RayTreeMeter` facade). Removing them alongside the config completes the decoupling: after this change, recovery is observed through logs only, and plugins touch Core's recovery surface not at all.
+
+- **All four instruments go** (`disconnects`, `recoveries`, `recovery.duration`, `state`) plus `RecordConnectionDisconnect` / `RecordConnectionRecovery` / `RegisterConnectionStateGauge`, the `_connectionStateSources` list, the `_connectionStateGate` lock, the `ObserveConnectionStates` callback, and the `ConnectionStateSubscription` nested type.
+- **Logs are the surviving signal.** Postgres/Kafka already log retry attempts, recovery, and exhaustion at `Information`/`Error`; RabbitMQ publisher logs `Warning` on shutdown and `Information` on recovery. None of that changes. The `Error→Warning` outbox-batch demotion (driven by `IOutbox.IsConnectionFault`) also stays — it is a logging behavior, not a metric one, and the classifier members it depends on remain.
+- **RabbitMQ is asymmetric and must be handled as two cases:**
+  - *Publisher* keeps all three event handlers — they emit the recovery logs. Strip only the `_meter` field, the constructor `RayTreeMeter?` parameter, the gauge registration, and the two `RecordConnection*` calls. The `_lastShutdownAt` duration tracking stays (the recovery log prints `{Duration}`).
+  - *Consumer* has **no logger**; its event subscriptions existed solely to feed metrics. Remove the `ConnectionShutdownAsync`/`RecoverySucceededAsync` subscriptions, their handlers, the gauge registration, and the `RayTreeMeter? meter` constructor parameter outright. The consumer stops observing recovery entirely — which is acceptable because it never produced any operator-visible signal except the metrics now being removed.
+- **`OutboxPublisherService` / `NotificationBasedPublisher`** keep their `_outboxUnhealthy` / per-outbox unhealthy-state tracking because it still gates the log demotion and the single "outbox connection recovered" `Information` log. Only the `RecordConnectionDisconnect` / `RecordConnectionRecovery` calls are deleted from those paths. `RayTreeMeter` remains a required constructor parameter on both (still used for outbox metrics).
+- **Builder/extension plumbing:** the RabbitMQ builder and subscriber extensions stop forwarding a `RayTreeMeter` into the publisher/consumer constructors. Wherever the meter was passed only for connection metrics, the argument is dropped.
+
+**Alternative considered:** keep the instruments but stop emitting (no-op). Rejected — dead instruments on the public meter mislead operators into thinking the series exist; a clean removal is honest and shrinks `RayTreeMeter`. **Alternative considered:** move the metrics per-plugin (each plugin owns its own meter). Rejected — the user's intent is removal, not relocation, and per-plugin meters would fragment the single `"RayTree"` meter that the OTel integration deliberately exposes.
+
+### 5. Narrow RayTreeMeter's public emit surface to internal
+
+Removing the connection facade exposes a latent simplification. `RayTreeMeter` had three categories of public method: the connection facade (now removed), and the publisher-side emit/register methods (`RecordPublishSuccess`, `RecordPublishFailure`, `RecordPayloadSize`, `RecordBatchSize`, `RegisterPendingGauge`). The connection facade was public **out of necessity** — Kafka and RabbitMQ plugins have no `InternalsVisibleTo` and could only reach it through the public API. The other five were public only by association; their actual callers are:
+
+- Core itself (`OutboxPublisherService`, `ChangeSubscriber`, `EntityChangeTracker`, `ChangeTrackingBuilder`), and
+- `NotificationBasedPublisher` in `RayTree.Plugins.PostgreSQL` (the NOTIFY fast-path emits the same publish metrics) — which **is** an `InternalsVisibleTo`-privileged assembly (`RayTree.Core.csproj` grants it, alongside `RayTree.EntityFrameworkCore` and the test projects).
+
+So all five can become `internal` with no loss of reachability: every caller already sees Core internals. Kafka/RabbitMQ never call them (their publish metrics are emitted by Core's `OutboxPublisherService` on their behalf). The net result is that **`RayTreeMeter` exposes no public way to emit a metric** — its public surface is `MeterName`, the two constructors, `DefaultPendingCacheTtl`, and `Dispose()`. It becomes a construct-it / let-Core-fill-it / observe-via-OTel type. This is the correct shape: metric *emission* is a Core-internal implementation concern; metric *observation* is the public contract, and that lives in `RayTree.OpenTelemetry` (`AddRayTreeMetrics`) and the `"RayTree"` meter name, both untouched.
+
+**Why fold it in now rather than later:** the visibility change is only *safe and obvious* once the connection facade is gone — while that facade existed, "all emit methods are internal" was false, so the narrowing had no clean line to draw. Doing both in one change leaves the type in a coherent end state instead of a half-public one. **Alternative considered:** leave them public for hypothetical caller "custom instrumentation." Rejected — these methods take RayTree-internal shapes (`ChangeType`, entity `Type`, lag seconds) that only Core can meaningfully populate; they were never a usable public extension point. A caller wanting custom metrics uses their own `Meter`, not RayTree's emit methods.
+
+### 6. Test relocation
+
+`ConnectionRecoveryOptionsTests` (validation/defaults) splits into the PostgreSQL and Kafka test projects, asserting against the plugin-local type. `ConnectionRecoveryConfigurationTests` (Hosting binding) is removed — the binding it tested is gone. `NotificationBasedPublisherRecoveryTests` and the Kafka recovery tests update the referenced type name only.
+
+## Risks / Trade-offs
+
+- **[Loss of metric-based recovery observability]** → Deliberate, per the request. Operators relying on `raytree.connection.*` dashboards/alerts lose them; mitigation is the retained log signal (recovery logs at `Warning`/`Information`/`Error` with `{Component}`/`{Endpoint}`/`{Duration}`). Call this out prominently in CHANGELOG as a breaking observability change, since it fails silently — a metric that stops existing produces no error, just a flat-lined chart. The RabbitMQ *consumer* becomes entirely unobservable for recovery (no logger, no metrics); accept, as it matches its pre-existing no-logger posture.
+- **[Breaking change for callers referencing the type or the bound config sections]** → Migration is mechanical: rename `ConnectionRecoveryOptions` → `PostgresConnectionRecoveryOptions` / `KafkaConnectionRecoveryOptions` at the use site; move `ChangeTracking:Publisher:ConnectionRecovery` appsettings under the plugin's own options binding (or set in code). Field names are unchanged, so JSON key paths below the section parent are unaffected. Documented in CHANGELOG with a before/after snippet.
+- **[Removing the meter param from RabbitMQ constructors is a source break for direct constructor callers]** → The param was optional (`RayTreeMeter? meter = null`); most callers go through the builder extensions and are unaffected. Direct constructor callers drop the argument. Documented in CHANGELOG.
+- **[Validation logic now lives in two files; a future fix could be applied to one and missed in the other]** → Accept, consistent with the existing duplicated-loop decision. The records are stable (no churn since introduction). A shared unit-test helper asserting the invariant set can run against both types to catch drift without sharing production code.
+- **[Loss of a single cross-plugin "recovery default" knob]** → Accept. The knob was manual-merge-only and never auto-applied; no caller relied on it taking effect without writing the merge themselves. Per-plugin configuration is more explicit and matches how callers already tune brokers individually.
+- **[Two new public types increase the plugin API surface]** → Net public surface is roughly flat: one Core type + one Hosting type removed, two plugin types added. Each new type lives in the assembly that owns its behavior, which is the point.
diff --git a/openspec/changes/archive/2026-06-02-per-place-recovery-options/proposal.md b/openspec/changes/archive/2026-06-02-per-place-recovery-options/proposal.md
new file mode 100644
index 0000000..e24cf77
--- /dev/null
+++ b/openspec/changes/archive/2026-06-02-per-place-recovery-options/proposal.md
@@ -0,0 +1,50 @@
+## Why
+
+`RayTree.Core` owns a shared `ConnectionRecoveryOptions` record consumed by the Postgres and Kafka plugins. This is the **last remaining piece of config coupling** between Core and the plugins that own a reconnect loop — and it sits awkwardly next to a design decision that already went the other way: the retry *loop* is deliberately **not** shared (each plugin hand-rolls ~20 lines so plugins consume Core via its public API only). The shared options record contradicts that stance: it makes every recovery-capable plugin depend on the exact shape of a Core type, even though the "universal" record is already not universal — RabbitMQ ignores it entirely, and fields like `Factor`/`MaxAttempts` are meaningless to any plugin that doesn't hand-roll an exponential loop. Moving the options next to the loop that consumes them makes the coupling honest and lets each plugin evolve its recovery surface independently.
+
+## What Changes
+
+### Per-place recovery options
+
+- **BREAKING** — Remove `ConnectionRecoveryOptions` from `RayTree.Core` (`src/RayTree.Core/Resilience/`).
+- Each plugin that owns a reconnect loop defines its **own** recovery options type in its own assembly, carrying only the fields that loop actually uses:
+  - `RayTree.Plugins.PostgreSQL` → `PostgresConnectionRecoveryOptions` (consumed by `NotificationBasedPublisher`'s LISTEN reconnect).
+  - `RayTree.Plugins.Kafka` → `KafkaConnectionRecoveryOptions` (consumed by both `KafkaPublisher` and `KafkaConsumer` rebuild loops).
+- Repoint the `ConnectionRecovery` property on `NotificationBasedPublisherOptions`, `KafkaPublisherOptions`, and `KafkaConsumerOptions` from the Core type to the plugin-local type. Field names, defaults, and validation semantics are preserved so this is a type-identity break, not a behavioral one.
+- **BREAKING** — `RayTree.Hosting` drops the generic shared-type binding: `ChangeTrackingRecoveryKeys` and the two `services.Configure<ConnectionRecoveryOptions>(...)` calls are removed. The host no longer binds a single cross-plugin recovery default; callers configure recovery per plugin in code (or bind their own sections to the plugin-local type). This removes `IServiceProvider` plumbing that was never wired into plugin construction anyway — the bound defaults required callers to merge them manually, so the convenience was largely notional.
+
+### Remove connection-recovery metrics
+
+- **BREAKING** — Remove all four connection-recovery metric instruments from `RayTreeMeter` and the three public facade methods that emit them: `raytree.connection.disconnects`, `raytree.connection.recoveries`, `raytree.connection.recovery.duration`, `raytree.connection.state` (observable gauge), and `RecordConnectionDisconnect` / `RecordConnectionRecovery` / `RegisterConnectionStateGauge` (plus the internal `_connectionStateSources` registry and `ConnectionStateSubscription`). The other `RayTreeMeter` instruments (outbox, subscriber, etc.) are untouched.
+- Remove every metric-emission call site across the plugins: `OutboxPublisherService`, `NotificationBasedPublisher`, `KafkaPublisher`, `KafkaConsumer`, `RabbitMqPublisher`, `RabbitMqConsumer`.
+- **`RabbitMqConsumer`** subscribed to the SDK recovery events *only* to emit metrics (it has no logger); those event subscriptions and its `RayTreeMeter? meter` constructor parameter are removed entirely.
+- **`RabbitMqPublisher`** keeps its `ConnectionShutdownAsync` / `RecoverySucceededAsync` / `ConnectionRecoveryErrorAsync` handlers because they also emit `Warning`/`Information` recovery **logs** — only the `_meter` field, its constructor `RayTreeMeter?` parameter, the state-gauge registration, and the `RecordConnection*` calls are removed. The duration tracking stays (still used in the log message).
+- **Behavior and logs are otherwise unchanged.** All reconnect loops (Postgres LISTEN, Kafka rebuild), the `IOutbox` connection-fault classification (`IsConnectionFault` / `ConnectionComponent` / `ConnectionEndpoint`), the `Error→Warning` outbox log demotion, and every recovery log entry are retained. This change removes observability-via-metrics only.
+- RabbitMQ still exposes no recovery options (SDK-owned).
+
+### Narrow the RayTreeMeter public surface
+
+- The connection facade was the **only** metric-emission API that had to be public (Kafka/RabbitMQ plugins have no `InternalsVisibleTo`). With it gone, the remaining emit/register methods — `RecordPublishSuccess`, `RecordPublishFailure`, `RecordPayloadSize`, `RecordBatchSize`, `RegisterPendingGauge` — are called only from Core and from the PostgreSQL plugin/tests, all of which already see Core internals via `InternalsVisibleTo`. Make these five methods `internal`. `RayTreeMeter`'s public surface collapses to `MeterName`, its constructors, `DefaultPendingCacheTtl`, and `Dispose()` — a construct-and-observe type with **all metric emission internal**.
+
+## Capabilities
+
+### New Capabilities
+<!-- none — recovery behavior is unchanged; only the ownership/location of the config type moves -->
+
+### Modified Capabilities
+- `connection-recovery`: (a) the options-shape, options-exposure, and config-binding requirements change — the validated backoff record moves out of Core to per-plugin types and the Hosting binding is removed; (b) the requirements that emit connection metrics change — `NotificationBasedPublisher` reconnect, Kafka publisher/consumer rebuild, "RabbitMQ recovery is observed", "Outbox connection-fault observability", and "Recovery logs are emitted at documented levels" drop all metric clauses while retaining their reconnect/log behavior.
+- `opentelemetry-metrics`: the "Connection-recovery instruments are emitted" requirement is removed — those four instruments no longer exist.
+
+## Impact
+
+- **Public API (breaking):**
+  - Removed: `RayTree.Core.Resilience.ConnectionRecoveryOptions`, `RayTree.Hosting.ChangeTrackingRecoveryKeys`, and the `ChangeTracking:*:ConnectionRecovery` configuration binding.
+  - Removed: `RayTreeMeter.RecordConnectionDisconnect`, `RecordConnectionRecovery`, `RegisterConnectionStateGauge`, and the four `raytree.connection.*` instruments.
+  - Narrowed to `internal`: `RayTreeMeter.RecordPublishSuccess`, `RecordPublishFailure`, `RecordPayloadSize`, `RecordBatchSize`, `RegisterPendingGauge` (no longer part of the public API; callers all have `InternalsVisibleTo`).
+  - Removed: the `RayTreeMeter?` constructor parameter on `RabbitMqConsumer` and `RabbitMqPublisher` (and the corresponding meter forwarding in the RabbitMQ builder/subscriber extensions).
+  - Added: `PostgresConnectionRecoveryOptions` (PostgreSQL plugin), `KafkaConnectionRecoveryOptions` (Kafka plugin).
+  - Changed property types: `ConnectionRecovery` on the three plugin options classes now returns the plugin-local type.
+- **Affected packages:** `RayTree.Core` (type + instrument removal), `RayTree.Plugins.PostgreSQL` (new type, drop metric calls), `RayTree.Plugins.Kafka` (new type, drop metric calls), `RayTree.Plugins.RabbitMQ` (drop meter param + consumer event handlers, keep publisher logs), `RayTree.Hosting` (binding removal). No new dependencies.
+- **Observability change:** dashboards/alerts built on any `raytree.connection.*` series break — those series cease to exist. Disconnect/recovery visibility is now log-only (Postgres/Kafka retry + recovery logs; RabbitMQ publisher Warning/Information; RabbitMQ consumer becomes silent, as before for logs). The `IOutbox` connection-fault members and the `Error→Warning` log demotion remain.
+- **Callers** referencing `ConnectionRecoveryOptions`, the host-bound config sections, or the removed meter facade methods must update. Type migration is mechanical; metric consumers must drop the series.
+- **Tests:** delete `RecoveryMetricsTests` and `RabbitMqRecoveryMetricsTests`; strip metric assertions from `KafkaRecoveryMetricsTests`, `OutboxPublisherServiceConnectionFaultTests`, and `NotificationBasedPublisherRecoveryTests` (keep their log/behavior assertions); split `ConnectionRecoveryOptionsTests` into the plugin test projects; delete `ConnectionRecoveryConfigurationTests`. CHANGELOG, CLAUDE.md, AGENTS.md, `docs/opentelemetry-metrics.md`, and plugin READMEs updated.
diff --git a/openspec/changes/archive/2026-06-02-per-place-recovery-options/specs/connection-recovery/spec.md b/openspec/changes/archive/2026-06-02-per-place-recovery-options/specs/connection-recovery/spec.md
new file mode 100644
index 0000000..f56c55f
--- /dev/null
+++ b/openspec/changes/archive/2026-06-02-per-place-recovery-options/specs/connection-recovery/spec.md
@@ -0,0 +1,170 @@
+## MODIFIED Requirements
+
+### Requirement: Connection recovery options shape
+Each plugin that owns a connection-recovery loop SHALL define its **own** public recovery-options type in its own assembly; `RayTree.Core` SHALL NOT define a shared recovery-options type. `RayTree.Plugins.PostgreSQL` SHALL expose `PostgresConnectionRecoveryOptions`; `RayTree.Plugins.Kafka` SHALL expose `KafkaConnectionRecoveryOptions`. Each type SHALL carry the fields `Enabled` (bool, default `true`), `InitialDelay` (TimeSpan, default `1s`), `MaxDelay` (TimeSpan, default `30s`), `Factor` (double, default `2.0`), `JitterFraction` (double, default `0.2`), and `MaxAttempts` (int?, default `null` — unlimited). Each type SHALL validate per-field invariants at init time — `InitialDelay > TimeSpan.Zero`, `Factor >= 1.0`, `0 <= JitterFraction <= 1`, and `MaxAttempts == null || MaxAttempts > 0` — throwing `ArgumentOutOfRangeException`, and SHALL expose a `Validate()` method enforcing the cross-field invariant `MaxDelay >= InitialDelay` (also throwing `ArgumentOutOfRangeException`), which the consuming plugin calls before entering its retry loop.
+
+#### Scenario: Defaults match documented values
+- **WHEN** `new PostgresConnectionRecoveryOptions()` or `new KafkaConnectionRecoveryOptions()` is constructed with no overrides
+- **THEN** the field values SHALL be exactly `Enabled = true`, `InitialDelay = 1s`, `MaxDelay = 30s`, `Factor = 2.0`, `JitterFraction = 0.2`, `MaxAttempts = null`.
+
+#### Scenario: Invalid factor is rejected
+- **WHEN** `Factor = 0.5` is supplied to either plugin-local options type
+- **THEN** construction SHALL throw `ArgumentOutOfRangeException` with `paramName = "Factor"`.
+
+#### Scenario: Cross-field invariant is rejected on Validate
+- **WHEN** an options instance with `MaxDelay < InitialDelay` is constructed AND `Validate()` is called
+- **THEN** `Validate()` SHALL throw `ArgumentOutOfRangeException` with `paramName = "MaxDelay"`.
+
+#### Scenario: Core exposes no shared recovery-options type
+- **WHEN** a caller inspects `RayTree.Core` (e.g. via reflection or autocomplete)
+- **THEN** no `ConnectionRecoveryOptions` type SHALL be present in the `RayTree.Core.Resilience` namespace
+- **AND** the connection-metric facade (`RayTreeMeter.RecordConnectionDisconnect` / `RecordConnectionRecovery` / `RegisterConnectionStateGauge`) SHALL NOT be present — those methods are removed along with the `raytree.connection.*` instruments.
+
+#### Scenario: Disabled options short-circuit recovery
+- **WHEN** `Enabled = false` AND the owning Postgres or Kafka plugin observes a connection-fault exception
+- **THEN** the plugin SHALL surface the exception on the next caller-facing call (or, for the Kafka consumer poll thread, on the next iteration) — no rebuild attempt SHALL be made.
+
+### Requirement: Recovery options exposure on plugin options classes
+`NotificationBasedPublisherOptions` SHALL expose a `ConnectionRecovery` property of type `PostgresConnectionRecoveryOptions` initialised to `new PostgresConnectionRecoveryOptions()`. `KafkaPublisherOptions` and `KafkaConsumerOptions` SHALL each expose a `ConnectionRecovery` property of type `KafkaConnectionRecoveryOptions` initialised to `new KafkaConnectionRecoveryOptions()`. `RabbitMqPublisherOptions` and `RabbitMqConsumerOptions` SHALL NOT expose this property — RabbitMQ recovery is owned by the SDK and is not configurable through RayTree.
+
+#### Scenario: Default property value is enabled
+- **WHEN** `NotificationBasedPublisherOptions`, `KafkaPublisherOptions`, or `KafkaConsumerOptions` is constructed via its parameterless constructor
+- **THEN** `ConnectionRecovery.Enabled` SHALL be `true` and the other fields SHALL match the documented defaults.
+
+#### Scenario: Property type is the plugin-local options type
+- **WHEN** a caller reads `KafkaPublisherOptions.ConnectionRecovery`
+- **THEN** the value SHALL be a `KafkaConnectionRecoveryOptions` instance
+- **AND** reading `NotificationBasedPublisherOptions.ConnectionRecovery` SHALL yield a `PostgresConnectionRecoveryOptions` instance.
+
+#### Scenario: RabbitMQ options do not expose ConnectionRecovery
+- **WHEN** a caller inspects `RabbitMqPublisherOptions` / `RabbitMqConsumerOptions` via reflection or autocomplete
+- **THEN** no `ConnectionRecovery` property SHALL be present
+- **AND** the SDK's recovery options (e.g. `NetworkRecoveryInterval`) remain accessible through the underlying `ConnectionFactory` only if the caller constructs one explicitly.
+
+### Requirement: PostgreSQL NotificationBasedPublisher reconnects LISTEN
+`NotificationBasedPublisher` SHALL, upon catching an exception from `NpgsqlConnection.WaitAsync` for which `IsConnectionFault(ex)` returns `true`, dispose the broken connection and run an inline exponential-backoff reconnect loop bounded by `NotificationBasedPublisherOptions.ConnectionRecovery`. The loop SHALL open a fresh `NpgsqlConnection`, re-attach the `Notification` event handler, issue `LISTEN {ChannelName}`, and resume `WaitAsync` against the new connection. The fallback polling loop SHALL continue running throughout, providing the safety net for records written during reconnect.
+
+`IsConnectionFault` for the Postgres plugin SHALL return `true` for: `NpgsqlException` with `IsTransient = true`; `NpgsqlException` whose inner exception is `SocketException` or `IOException`; `PostgresException` with `SqlState` in `{"57P01", "57P02", "57P03"}` (admin_shutdown, crash_shutdown, cannot_connect_now); and `ObjectDisposedException`. All other exceptions SHALL propagate without triggering reconnect.
+
+#### Scenario: LISTEN connection drop triggers reconnect
+- **WHEN** `WaitAsync` throws an exception that `IsConnectionFault` classifies as a connection fault
+- **THEN** the loop SHALL dispose the broken connection, open a fresh `NpgsqlConnection`, issue `LISTEN {ChannelName}`, and resume `WaitAsync` against the new connection.
+
+#### Scenario: Fallback polling continues during reconnect
+- **WHEN** the LISTEN connection is being rebuilt
+- **THEN** `FallbackPollingLoopAsync` SHALL continue processing unpublished records at `FallbackPollingInterval` cadence until `_listenerHealthy` returns to `true`.
+
+#### Scenario: Non-connection exception propagates
+- **WHEN** `WaitAsync` throws an exception that `IsConnectionFault` returns `false` for (e.g. an unexpected internal error)
+- **THEN** the exception SHALL propagate out of `ListenLoopAsync` — no reconnect SHALL be attempted.
+
+#### Scenario: Recovery is logged at Information
+- **WHEN** reconnect completes successfully
+- **THEN** the existing `Information` "LISTEN connection on {ChannelName} recovered" log SHALL be emitted (unchanged from current behaviour)
+- **AND** no connection metric SHALL be recorded (the `raytree.connection.*` instruments no longer exist).
+
+### Requirement: Kafka publisher rebuilds on fatal error
+`KafkaPublisher` SHALL register `IProducerBuilder.SetErrorHandler` during producer construction. When the handler receives an error with `Error.IsFatal = true`, the publisher SHALL dispose the current `IProducer` and null out the cached reference. The next `PublishAsync` call SHALL re-enter the existing lazy `GetProducerAsync` build path — which re-runs the `WaitForTopic` probe when enabled — bounded by `KafkaPublisherOptions.ConnectionRecovery`. Non-fatal errors SHALL NOT trigger rebuild; librdkafka recovers those internally. No connection metric SHALL be emitted (the `raytree.connection.*` instruments no longer exist).
+
+#### Scenario: Fatal error disposes the producer
+- **WHEN** the error handler receives an error with `Error.IsFatal = true`
+- **THEN** the cached `IProducer` SHALL be disposed and the cached reference SHALL be set to `null`
+- **AND** no connection metric SHALL be recorded.
+
+#### Scenario: Next publish rebuilds via existing path
+- **WHEN** a subsequent `PublishAsync` is invoked after a fatal-error dispose
+- **THEN** the existing `GetProducerAsync` path SHALL build a fresh producer
+- **AND** the probe SHALL re-run when `WaitForTopic = true`.
+
+#### Scenario: Non-fatal error is ignored
+- **WHEN** the error handler receives a non-fatal error
+- **THEN** the publisher SHALL log at `Warning` and SHALL NOT dispose the producer.
+
+### Requirement: RabbitMQ recovery is observed via logs, not metrics
+The RabbitMQ publisher and consumer SHALL rely on `RabbitMQ.Client.AutomaticRecoveryEnabled = true` and `TopologyRecoveryEnabled = true` (the library defaults) for the actual recovery mechanism. RayTree SHALL NOT disable these flags.
+
+The `RabbitMqPublisher` SHALL subscribe to the SDK's `ConnectionShutdownAsync`, `RecoverySucceededAsync`, and `ConnectionRecoveryErrorAsync` events to emit the documented log entries (`Warning` on non-application shutdown, `Information` on recovery with elapsed `{Duration}`, `Information` per failed internal recovery attempt). It SHALL NOT emit any connection metric and SHALL NOT accept a `RayTreeMeter` constructor parameter.
+
+The `RabbitMqConsumer` has no logger and therefore SHALL NOT subscribe to any recovery event: with the connection metrics removed, those subscriptions produced no operator-visible signal. The consumer SHALL NOT accept a `RayTreeMeter` constructor parameter.
+
+#### Scenario: Publisher logs a Warning on non-application shutdown
+- **WHEN** the `RabbitMqPublisher`'s `IConnection` raises `ConnectionShutdownAsync` with `Initiator != Application`
+- **THEN** a `Warning` log SHALL be emitted with the shutdown reason, `{Endpoint}`, `{ReplyCode}`, and `{ReplyText}`
+- **AND** no metric SHALL be recorded.
+
+#### Scenario: Publisher logs Information on recovery
+- **WHEN** the publisher's `IConnection` raises `RecoverySucceededAsync`
+- **THEN** an `Information` log SHALL be emitted with `{Endpoint}` and `{Duration}` (seconds since the most recent non-application shutdown)
+- **AND** no metric SHALL be recorded.
+
+#### Scenario: Application-initiated shutdown is silent
+- **WHEN** `RabbitMqPublisher.DisposeAsync` is invoked and the resulting shutdown event has `Initiator = Application`
+- **THEN** no warning SHALL be logged and no metric SHALL be recorded.
+
+#### Scenario: Consumer does not observe recovery
+- **WHEN** the `RabbitMqConsumer`'s connection shuts down and later recovers
+- **THEN** the consumer SHALL emit neither a log entry nor a metric
+- **AND** the consumer constructor SHALL expose no `RayTreeMeter` parameter.
+
+### Requirement: Outbox connection-fault observability
+`IOutbox` SHALL expose three default-implemented members so consumers of an arbitrary `IOutbox` can classify transient connection faults without retry code:
+
+- `bool IsConnectionFault(Exception ex)` — default `false`. Concrete implementations override to classify connection-level exceptions versus application-level exceptions.
+- `string? ConnectionComponent { get; }` — default `null`. Returns a stable component identifier used as a structured-log property, or `null` when the outbox has no observable external connection.
+- `string? ConnectionEndpoint { get; }` — default `null`. Returns the endpoint identifier used as a structured-log property.
+
+`PostgreSqlOutbox<TEntity>` SHALL override these: `IsConnectionFault` returns `true` for `NpgsqlException { IsTransient: true }`, `NpgsqlException` with `SocketException`/`IOException` inner, `PostgresException` with `SqlState` in `{"57P01", "57P02", "57P03", "08000", "08003", "08006", "08001", "08004", "08007"}`, and `ObjectDisposedException`. `ConnectionComponent` returns `"postgres.outbox"`. `ConnectionEndpoint` returns `"{Host}:{Port}"`. The classifier used by `PostgreSqlOutbox` SHALL be the same `static bool PostgresFault.IsConnectionFault(Exception)` used by `NotificationBasedPublisher`.
+
+`OutboxPublisherService.ProcessBatchAsync`'s batch-error catch block SHALL consult `_outbox.IsConnectionFault(ex)` and `_outbox.ConnectionComponent`. When the classifier returns `true` AND `ConnectionComponent` is non-null, the failure SHALL be logged at `Warning` instead of `Error`, with `{Component}` and `{Endpoint}` structured properties, and a per-service `_outboxUnhealthy` flag SHALL be set. On the first subsequent batch that completes without throwing, an `Information` "outbox connection recovered" log SHALL be emitted with `{Duration}` (wall-clock seconds since the first failure) and the flag SHALL be cleared. When the classifier returns `false` OR `ConnectionComponent` is `null`, the existing `Error` log path SHALL be preserved unchanged. No connection metric SHALL be emitted in any of these paths. No retry code is added — the existing polling cadence is the retry.
+
+`NotificationBasedPublisher.FallbackPollingLoopAsync` SHALL apply the same `Warning`/`Information` log pattern per outbox, keyed by entity type in a `ConcurrentDictionary<Type, bool>`, with no metric emission.
+
+#### Scenario: Outbox publisher log demotion on connection fault
+- **WHEN** `OutboxPublisherService.ProcessBatchAsync` catches an exception and `_outbox.IsConnectionFault(ex)` returns `true` AND `ConnectionComponent` is non-null
+- **THEN** the failure SHALL be logged at `Warning` (not `Error`) with `{Component}` and `{Endpoint}`
+- **AND** no connection metric SHALL be emitted.
+
+#### Scenario: Outbox publisher recovery log on first success after failure
+- **WHEN** `OutboxPublisherService.ProcessBatchAsync` completes without throwing AND the service was previously unhealthy
+- **THEN** an `Information` "outbox connection recovered" log SHALL be emitted with `{Duration}`
+- **AND** the `_outboxUnhealthy` flag SHALL be cleared
+- **AND** no connection metric SHALL be emitted.
+
+#### Scenario: Non-connection-fault exception preserves existing Error log
+- **WHEN** `OutboxPublisherService.ProcessBatchAsync` catches an exception for which `_outbox.IsConnectionFault(ex)` returns `false`
+- **THEN** the existing `Error` log path SHALL be unchanged.
+
+#### Scenario: Write-path exceptions still propagate to the caller
+- **WHEN** a caller invokes `EntityChangeTracker.TrackInsertAsync` and the underlying `PostgreSqlOutbox.WriteAsync` throws a connection-fault exception
+- **THEN** the exception SHALL propagate to the caller unchanged
+- **AND** no automatic retry SHALL be performed by the library at the write path.
+
+### Requirement: Recovery logs are emitted at documented levels
+Each plugin that participates in connection recovery and owns an `ILogger<T>` SHALL emit the following log entries:
+
+- **First detection of disconnect per recovery cycle**: `Warning`, with the underlying exception (where available), `{Component}`, and `{Endpoint}`.
+- **Each retry attempt** (Postgres and Kafka only — the two plugins owning their own retry loop): `Information`, with `{Component}`, `{Endpoint}`, `{AttemptNumber}`, and `{Delay}` (the actually scheduled delay including jitter, in seconds).
+- **Successful recovery**: `Information`, with `{Component}`, `{Endpoint}`, `{AttemptCount}` (for Postgres/Kafka), and `{Duration}` (wall-clock seconds elapsed since the first detection in this cycle).
+- **Exhausted attempts** (Postgres and Kafka only): `Error`, with the most recent exception, `{Component}`, `{Endpoint}`, and `{AttemptCount}`.
+
+No connection metric SHALL accompany any of these logs — the `raytree.connection.*` instruments no longer exist. `RabbitMqConsumer` has no `ILogger` field and SHALL produce neither logs nor metrics for connection recovery.
+
+#### Scenario: First disconnect emits Warning with exception
+- **WHEN** a logger-owning participating plugin observes the first disconnect of a recovery cycle (Kafka error handler fires, Postgres `WaitAsync` throws a connection fault, RabbitMQ publisher `ConnectionShutdownAsync` fires non-application)
+- **THEN** a `Warning` log SHALL be emitted with `{Component}` and `{Endpoint}` and the underlying exception attached where available.
+
+#### Scenario: Retry attempt emits Information with delay
+- **WHEN** Postgres or Kafka schedules the Nth retry attempt
+- **THEN** an `Information` log SHALL be emitted with `{AttemptNumber} = N` and `{Delay}` equal to the actually-scheduled delay (including jitter) in seconds.
+
+#### Scenario: RabbitMqConsumer recovery is fully silent
+- **WHEN** a recovery cycle runs for `RabbitMqConsumer`
+- **THEN** no log entries SHALL be emitted
+- **AND** no connection metric SHALL be recorded.
+
+## REMOVED Requirements
+
+### Requirement: Recovery options bound from configuration
+**Reason**: The shared `ConnectionRecoveryOptions` type that this binding produced no longer exists; recovery options are now plugin-local. The bound named-options defaults were never auto-injected into plugin construction — callers had to resolve `IOptionsMonitor<ConnectionRecoveryOptions>.Get(key)` and merge manually — so the binding provided no automatic behavior to preserve.
+
+**Migration**: Configure recovery per plugin in the plugin's `Use*` configure lambda. To drive it from configuration, bind your own section to the plugin-local type and assign it, e.g. `UseKafka(o => o.ConnectionRecovery = config.GetSection("ChangeTracking:Kafka:ConnectionRecovery").Get<KafkaConnectionRecoveryOptions>() ?? new())`. The `ChangeTrackingRecoveryKeys` constants and the `ChangeTracking:{Publisher,Subscriber}:ConnectionRecovery` host-bound sections are removed.
diff --git a/openspec/changes/archive/2026-06-02-per-place-recovery-options/specs/opentelemetry-metrics/spec.md b/openspec/changes/archive/2026-06-02-per-place-recovery-options/specs/opentelemetry-metrics/spec.md
new file mode 100644
index 0000000..e1b3c54
--- /dev/null
+++ b/openspec/changes/archive/2026-06-02-per-place-recovery-options/specs/opentelemetry-metrics/spec.md
@@ -0,0 +1,21 @@
+## REMOVED Requirements
+
+### Requirement: Connection-recovery instruments are emitted
+**Reason**: The connection-recovery metrics are removed entirely. Recovery is now observed through logs only (Postgres/Kafka retry, recovery, and exhaustion logs; RabbitMQ publisher `Warning`/`Information` logs). The four `raytree.connection.*` instruments and the three `RayTreeMeter` facade methods that emitted them (`RecordConnectionDisconnect`, `RecordConnectionRecovery`, `RegisterConnectionStateGauge`) no longer exist, and every plugin emission call site is removed.
+
+**Migration**: Dashboards, alerts, and OTel views referencing `raytree.connection.disconnects`, `raytree.connection.recoveries`, `raytree.connection.recovery.duration`, or `raytree.connection.state` must be removed — those series cease to exist. To observe disconnect/recovery activity, consume the recovery log entries instead (filter on `{Component}` / `{Endpoint}` structured properties; recovery duration is available as the `{Duration}` property on the "recovered" `Information` log). No replacement metric is provided.
+
+## ADDED Requirements
+
+### Requirement: Metric emission is not part of the public API
+`RayTreeMeter` SHALL expose no public method for emitting or registering a metric. All emit/register members (`RecordPublishSuccess`, `RecordPublishFailure`, `RecordPayloadSize`, `RecordBatchSize`, `RegisterPendingGauge`) SHALL be `internal`, consumed only by `RayTree.Core` and by assemblies granted `InternalsVisibleTo` (`RayTree.Plugins.PostgreSQL`, `RayTree.EntityFrameworkCore`, and the test projects). `RayTreeMeter`'s public surface SHALL consist of `MeterName`, its constructors, `DefaultPendingCacheTtl`, and `Dispose()`. Metric *observation* SHALL remain public via the `"RayTree"` meter name and `RayTree.OpenTelemetry.AddRayTreeMetrics`.
+
+#### Scenario: No public emit method exists
+- **WHEN** a consumer outside Core and without `InternalsVisibleTo` references `RayTreeMeter`
+- **THEN** no metric-emitting or gauge-registering method SHALL be accessible
+- **AND** only `MeterName`, the constructors, `DefaultPendingCacheTtl`, and `Dispose()` SHALL be available.
+
+#### Scenario: Privileged assemblies still emit internally
+- **WHEN** `NotificationBasedPublisher` (in `RayTree.Plugins.PostgreSQL`, an `InternalsVisibleTo`-granted assembly) emits publish metrics on the NOTIFY fast-path
+- **THEN** it SHALL call the `internal` `RecordPublishSuccess` / `RecordPublishFailure` / `RecordPayloadSize` / `RecordBatchSize` members
+- **AND** the emitted instruments SHALL remain observable via `AddRayTreeMetrics`.
diff --git a/openspec/changes/archive/2026-06-02-per-place-recovery-options/tasks.md b/openspec/changes/archive/2026-06-02-per-place-recovery-options/tasks.md
new file mode 100644
index 0000000..7861244
--- /dev/null
+++ b/openspec/changes/archive/2026-06-02-per-place-recovery-options/tasks.md
@@ -0,0 +1,52 @@
+## 1. PostgreSQL plugin-local options type
+
+- [x] 1.1 Add `PostgresConnectionRecoveryOptions` to `src/RayTree.Plugins.PostgreSQL` (new file under `Outbox/Notification/` or a `Resilience/` folder): copy the six members, per-field init guards, and `Validate()` from the current Core `ConnectionRecoveryOptions`; update the XML doc to reference Postgres LISTEN reconnect only.
+- [x] 1.2 Repoint `NotificationBasedPublisherOptions.ConnectionRecovery` to `PostgresConnectionRecoveryOptions` (property type + `new()` initializer); remove the `using RayTree.Core.Resilience;` if now unused.
+- [x] 1.3 Update `NotificationBasedPublisher` to consume the plugin-local type (variable/parameter types, `Validate()` call site); confirm no other Core-type reference remains.
+- [x] 1.4 Build `dotnet build src/RayTree.Plugins.PostgreSQL -c Release` clean (warnings-as-errors).
+
+## 2. Kafka plugin-local options type
+
+- [x] 2.1 Add `KafkaConnectionRecoveryOptions` to `src/RayTree.Plugins.Kafka` (new file): same six members, guards, and `Validate()`; XML doc references the Kafka publisher/consumer fatal-error rebuild loops.
+- [x] 2.2 Repoint `KafkaPublisherOptions.ConnectionRecovery` and `KafkaConsumerOptions.ConnectionRecovery` to `KafkaConnectionRecoveryOptions`; remove now-unused `using RayTree.Core.Resilience;`.
+- [x] 2.3 Update `KafkaPublisher` and `KafkaConsumer` to consume the plugin-local type at all use sites (rebuild loop tuning, `Validate()` calls).
+- [x] 2.4 Build `dotnet build src/RayTree.Plugins.Kafka -c Release` clean.
+
+## 3. Remove Core type and Hosting binding
+
+- [x] 3.1 Delete `src/RayTree.Core/Resilience/ConnectionRecoveryOptions.cs`.
+- [x] 3.2 Delete `src/RayTree.Hosting/ChangeTrackingRecoveryKeys.cs` and remove the two `services.Configure<ConnectionRecoveryOptions>(...)` calls (plus the explanatory comment block) from `ServiceCollectionExtensions.AddChangeTracking`; remove now-unused usings.
+- [x] 3.3 Build `dotnet build RayTree.slnx -c Release` to surface every remaining reference to the removed type/keys across the solution; fix any stragglers.
+
+## 4. Remove connection-recovery metrics from RayTreeMeter
+
+- [x] 4.1 In `src/RayTree.Core/Telemetry/RayTreeMeter.cs` remove the four `raytree.connection.*` instruments (`ConnectionDisconnects`, `ConnectionRecoveries`, `ConnectionRecoveryDuration`, the `raytree.connection.state` observable gauge), their `CreateCounter`/`CreateHistogram`/`CreateObservableGauge` registrations, the `_connectionStateSources` list, the `_connectionStateGate` lock, the `ObserveConnectionStates` callback, and the nested `ConnectionStateSubscription` type.
+- [x] 4.2 Remove the three public facade methods `RecordConnectionDisconnect`, `RecordConnectionRecovery`, and `RegisterConnectionStateGauge`. Remove the now-orphaned `ComponentTag`/`EndpointTag`/`OutcomeTag` helpers if nothing else uses them.
+- [x] 4.3 Narrow the remaining emit/register methods to `internal`: `RecordPublishSuccess`, `RecordPublishFailure`, `RecordPayloadSize`, `RecordBatchSize`, `RegisterPendingGauge`. Verify `RayTreeMeter`'s public surface is now only `MeterName`, the constructors, `DefaultPendingCacheTtl`, and `Dispose()`.
+- [x] 4.4 Build `dotnet build src/RayTree.Core -c Release`, then `dotnet build src/RayTree.Plugins.PostgreSQL -c Release` to confirm the PostgreSQL plugin (IVT-privileged) still compiles against the internalized members; surface any remaining call sites of the removed connection facade.
+
+## 5. Remove metric emission at all call sites
+
+- [x] 5.1 `src/RayTree.Core/Distribution/OutboxPublisherService.cs`: delete the `RecordConnectionDisconnect`/`RecordConnectionRecovery` calls in `HandleBatchError`/`EmitOutboxRecovered`; keep the `_outboxUnhealthy` tracking, the `Error→Warning` log demotion, and the "outbox connection recovered" `Information` log.
+- [x] 5.2 `src/RayTree.Plugins.PostgreSQL/Outbox/Notification/NotificationBasedPublisher.cs`: delete connection-metric emission in the LISTEN reconnect and fallback-poll paths; keep the reconnect loop, `_listenerHealthy` handling, per-outbox unhealthy tracking, and all logs.
+- [x] 5.3 `src/RayTree.Plugins.Kafka/KafkaPublisher.cs` and `KafkaConsumer.cs`: delete connection-metric emission in the fatal-error/rebuild paths; keep rebuild behavior and logs.
+- [x] 5.4 `src/RayTree.Plugins.RabbitMQ/RabbitMqPublisher.cs`: remove the `_meter` field, the constructor `RayTreeMeter?` parameter, the `RegisterConnectionStateGauge` subscription, and the two `RecordConnection*` calls; keep the three event handlers, the `_lastShutdownAt` duration tracking, and the `Warning`/`Information` logs.
+- [x] 5.5 `src/RayTree.Plugins.RabbitMQ/RabbitMqConsumer.cs`: remove the `_meter` field, the constructor `RayTreeMeter? meter` parameter, the `_stateGaugeSubscription`, the `ConnectionShutdownAsync`/`RecoverySucceededAsync` subscriptions and their `OnConnectionShutdownAsync`/`OnRecoverySucceededAsync` handlers, and the matching `-=` detach in dispose.
+- [x] 5.6 Update the RabbitMQ builder/subscriber extensions (`RabbitMqBuilderExtensions.cs`, `RabbitMqSubscriberExtensions.cs`) and any Kafka extensions that forwarded a `RayTreeMeter` solely for connection metrics so they no longer pass it to the publisher/consumer constructors.
+- [x] 5.7 Build `dotnet build RayTree.slnx -c Release` clean.
+
+## 6. Tests
+
+- [x] 6.1 Move the validation/defaults assertions from `tests/RayTree.Core.Tests/Resilience/ConnectionRecoveryOptionsTests.cs` into the PostgreSQL and Kafka test projects, retargeting `PostgresConnectionRecoveryOptions` / `KafkaConnectionRecoveryOptions`; delete the Core test file.
+- [x] 6.2 Delete `tests/RayTree.Core.Tests/Resilience/ConnectionRecoveryConfigurationTests.cs` (host binding removed) and `tests/RayTree.Core.Tests/Resilience/RecoveryMetricsTests.cs` (instruments removed).
+- [x] 6.3 Delete `tests/RayTree.Plugins.RabbitMQ.Tests/RabbitMqRecoveryMetricsTests.cs` (RabbitMQ recovery metrics removed).
+- [x] 6.4 Strip metric assertions from `tests/RayTree.Plugins.Kafka.Tests/KafkaRecoveryMetricsTests.cs`, `tests/RayTree.Core.Tests/Resilience/OutboxPublisherServiceConnectionFaultTests.cs`, and `tests/RayTree.Plugins.PostgreSQL.Tests/NotificationBasedPublisherRecoveryTests.cs`; retarget the plugin-local option types and keep the log/behavior assertions.
+- [x] 6.5 Confirm tests still compile against the internalized emit methods (test projects have `InternalsVisibleTo`); any test that called a now-`internal` method as "public" needs no change beyond the build passing. If a test asserted on the removed public facade, delete that assertion.
+- [x] 6.6 Run `dotnet test tests/RayTree.Core.Tests`, the PostgreSQL/Kafka/RabbitMQ test projects (unit-only filter where Docker is unavailable); all green.
+
+## 7. Docs and changelog
+
+- [x] 7.1 Update `CLAUDE.md` (Connection recovery section + the `RayTreeMeter` "18 instruments" count and the four shared connection instruments paragraph; note that emit methods are now `internal` and the public surface is construct-and-observe only) and `AGENTS.md`: describe the per-plugin options types, the removed Hosting binding, the removed connection metrics (recovery is log-only), and the narrowed `RayTreeMeter` public surface.
+- [x] 7.2 Update `docs/opentelemetry-metrics.md` (remove the four `raytree.connection.*` rows and bucket guidance), and the plugin READMEs (`src/RayTree.Plugins.RabbitMQ/README.md`, `src/RayTree.Plugins.PostgreSQL/README.md`, `src/RayTree.Plugins.Kafka/README.md`) where they reference the Core type, the bound config sections, or the connection metrics.
+- [x] 7.3 Add a `CHANGELOG.md` entry under a new version: BREAKING — `ConnectionRecoveryOptions` + `ChangeTrackingRecoveryKeys` removed (replaced by `PostgresConnectionRecoveryOptions` / `KafkaConnectionRecoveryOptions`); all `raytree.connection.*` metrics + `RayTreeMeter.RecordConnection*`/`RegisterConnectionStateGauge` removed; RabbitMQ publisher/consumer constructors no longer take `RayTreeMeter`. Include the before/after migration snippet and the metrics-removal observability note.
+- [x] 7.4 Final full `dotnet build RayTree.slnx -c Release` + run the non-Docker unit-test suite; confirm clean.
diff --git a/openspec/specs/connection-recovery/spec.md b/openspec/specs/connection-recovery/spec.md
index 5f1b936..9b1aabc 100644
--- a/openspec/specs/connection-recovery/spec.md
+++ b/openspec/specs/connection-recovery/spec.md
@@ -1,18 +1,27 @@
 ## ADDED Requirements
 
 ### Requirement: Connection recovery options shape
-`RayTree.Core` SHALL expose a public `ConnectionRecoveryOptions` record with fields `Enabled` (bool, default `true`), `InitialDelay` (TimeSpan, default `1s`), `MaxDelay` (TimeSpan, default `30s`), `Factor` (double, default `2.0`), `JitterFraction` (double, default `0.2`), and `MaxAttempts` (int?, default `null` — unlimited). The record SHALL validate its values at construction: `InitialDelay > TimeSpan.Zero`, `MaxDelay >= InitialDelay`, `Factor >= 1.0`, `0 <= JitterFraction <= 1`, and `MaxAttempts == null || MaxAttempts > 0`. Invalid values SHALL throw `ArgumentOutOfRangeException`.
+Each plugin that owns a connection-recovery loop SHALL define its **own** public recovery-options type in its own assembly; `RayTree.Core` SHALL NOT define a shared recovery-options type. `RayTree.Plugins.PostgreSQL` SHALL expose `PostgresConnectionRecoveryOptions`; `RayTree.Plugins.Kafka` SHALL expose `KafkaConnectionRecoveryOptions`. Each type SHALL carry the fields `Enabled` (bool, default `true`), `InitialDelay` (TimeSpan, default `1s`), `MaxDelay` (TimeSpan, default `30s`), `Factor` (double, default `2.0`), `JitterFraction` (double, default `0.2`), and `MaxAttempts` (int?, default `null` — unlimited). Each type SHALL validate per-field invariants at init time — `InitialDelay > TimeSpan.Zero`, `Factor >= 1.0`, `0 <= JitterFraction <= 1`, and `MaxAttempts == null || MaxAttempts > 0` — throwing `ArgumentOutOfRangeException`, and SHALL expose a `Validate()` method enforcing the cross-field invariant `MaxDelay >= InitialDelay` (also throwing `ArgumentOutOfRangeException`), which the consuming plugin calls before entering its retry loop.
 
 #### Scenario: Defaults match documented values
-- **WHEN** `new ConnectionRecoveryOptions()` is constructed with no overrides
+- **WHEN** `new PostgresConnectionRecoveryOptions()` or `new KafkaConnectionRecoveryOptions()` is constructed with no overrides
 - **THEN** the field values SHALL be exactly `Enabled = true`, `InitialDelay = 1s`, `MaxDelay = 30s`, `Factor = 2.0`, `JitterFraction = 0.2`, `MaxAttempts = null`.
 
 #### Scenario: Invalid factor is rejected
-- **WHEN** `Factor = 0.5` is supplied
+- **WHEN** `Factor = 0.5` is supplied to either plugin-local options type
 - **THEN** construction SHALL throw `ArgumentOutOfRangeException` with `paramName = "Factor"`.
 
+#### Scenario: Cross-field invariant is rejected on Validate
+- **WHEN** an options instance with `MaxDelay < InitialDelay` is constructed AND `Validate()` is called
+- **THEN** `Validate()` SHALL throw `ArgumentOutOfRangeException` with `paramName = "MaxDelay"`.
+
+#### Scenario: Core exposes no shared recovery-options type
+- **WHEN** a caller inspects `RayTree.Core` (e.g. via reflection or autocomplete)
+- **THEN** no `ConnectionRecoveryOptions` type SHALL be present in the `RayTree.Core.Resilience` namespace
+- **AND** the connection-metric facade (`RayTreeMeter.RecordConnectionDisconnect` / `RecordConnectionRecovery` / `RegisterConnectionStateGauge`) SHALL NOT be present — those methods are removed along with the `raytree.connection.*` instruments.
+
 #### Scenario: Disabled options short-circuit recovery
-- **WHEN** `Enabled = false` AND a Postgres or Kafka plugin observes a connection-fault exception
+- **WHEN** `Enabled = false` AND the owning Postgres or Kafka plugin observes a connection-fault exception
 - **THEN** the plugin SHALL surface the exception on the next caller-facing call (or, for the Kafka consumer poll thread, on the next iteration) — no rebuild attempt SHALL be made.
 
 ### Requirement: PostgreSQL NotificationBasedPublisher reconnects LISTEN
@@ -34,14 +43,16 @@
 
 #### Scenario: Recovery is logged at Information
 - **WHEN** reconnect completes successfully
-- **THEN** the existing `Information` "LISTEN connection on {ChannelName} recovered" log SHALL be emitted (unchanged from current behaviour), accompanied by the `raytree.connection.recoveries{outcome="succeeded"}` metric and duration recording.
+- **THEN** the existing `Information` "LISTEN connection on {ChannelName} recovered" log SHALL be emitted (unchanged from current behaviour)
+- **AND** no connection metric SHALL be recorded (the `raytree.connection.*` instruments no longer exist).
 
 ### Requirement: Kafka publisher rebuilds on fatal error
-`KafkaPublisher` SHALL register `IProducerBuilder.SetErrorHandler` during producer construction. When the handler receives an error with `Error.IsFatal = true`, the publisher SHALL dispose the current `IProducer`, null out the cached reference, and emit the disconnect metric. The next `PublishAsync` call SHALL re-enter the existing lazy `GetProducerAsync` build path — which re-runs the `WaitForTopic` probe when enabled — bounded by `KafkaPublisherOptions.ConnectionRecovery`. Non-fatal errors SHALL NOT trigger rebuild; librdkafka recovers those internally.
+`KafkaPublisher` SHALL register `IProducerBuilder.SetErrorHandler` during producer construction. When the handler receives an error with `Error.IsFatal = true`, the publisher SHALL dispose the current `IProducer` and null out the cached reference. The next `PublishAsync` call SHALL re-enter the existing lazy `GetProducerAsync` build path — which re-runs the `WaitForTopic` probe when enabled — bounded by `KafkaPublisherOptions.ConnectionRecovery`. Non-fatal errors SHALL NOT trigger rebuild; librdkafka recovers those internally. No connection metric SHALL be emitted (the `raytree.connection.*` instruments no longer exist).
 
 #### Scenario: Fatal error disposes the producer
 - **WHEN** the error handler receives an error with `Error.IsFatal = true`
-- **THEN** the cached `IProducer` SHALL be disposed and the cached reference SHALL be set to `null`.
+- **THEN** the cached `IProducer` SHALL be disposed and the cached reference SHALL be set to `null`
+- **AND** no connection metric SHALL be recorded.
 
 #### Scenario: Next publish rebuilds via existing path
 - **WHEN** a subsequent `PublishAsync` is invoked after a fatal-error dispose
@@ -67,128 +78,101 @@
 - **WHEN** `Consume` returns a `ConsumeResult` carrying a non-fatal error (e.g. partition-level transient)
 - **THEN** the existing behaviour SHALL apply — no rebuild, librdkafka recovers internally.
 
-### Requirement: RabbitMQ recovery is observed, not implemented
-The RabbitMQ publisher and consumer SHALL rely on `RabbitMQ.Client.AutomaticRecoveryEnabled = true` and `TopologyRecoveryEnabled = true` (the library defaults) for the actual recovery mechanism. RayTree SHALL NOT disable these flags. The publisher and consumer SHALL subscribe to the SDK's `ConnectionShutdownAsync`, `RecoverySucceededAsync`, and `ConnectionRecoveryErrorAsync` events to emit the `raytree.connection.disconnects` / `raytree.connection.recoveries` / `raytree.connection.recovery.duration` metrics and the documented log entries.
-
-#### Scenario: ConnectionShutdownAsync records a disconnect
-- **WHEN** the `RabbitMqPublisher`'s `IConnection` raises `ConnectionShutdownAsync` with `Initiator != Application`
-- **THEN** `raytree.connection.disconnects` SHALL be incremented with `component = "rabbitmq.publisher"` and `endpoint = "{HostName}:{Port}"`
-- **AND** a `Warning` log SHALL be emitted with the shutdown reason.
-
-#### Scenario: RecoverySucceededAsync records a recovery
-- **WHEN** the `IConnection` raises `RecoverySucceededAsync`
-- **THEN** `raytree.connection.recoveries{outcome="succeeded"}` SHALL be incremented
-- **AND** `raytree.connection.recovery.duration` SHALL record the wall-clock seconds elapsed since the most recent `ConnectionShutdownAsync` for this component
-- **AND** an `Information` log SHALL be emitted.
+### Requirement: RabbitMQ recovery is observed via logs, not metrics
+The RabbitMQ publisher and consumer SHALL rely on `RabbitMQ.Client.AutomaticRecoveryEnabled = true` and `TopologyRecoveryEnabled = true` (the library defaults) for the actual recovery mechanism. RayTree SHALL NOT disable these flags.
 
-#### Scenario: ConnectionRecoveryErrorAsync logs at Information
-- **WHEN** the `IConnection` raises `ConnectionRecoveryErrorAsync` (a single library-internal retry failed; the library will keep trying)
-- **THEN** an `Information` log SHALL be emitted with the exception
-- **AND** no metric SHALL be incremented (only the *outcome* of the overall recovery cycle is metered, not per-internal-attempt).
+The `RabbitMqPublisher` SHALL subscribe to the SDK's `ConnectionShutdownAsync`, `RecoverySucceededAsync`, and `ConnectionRecoveryErrorAsync` events to emit the documented log entries (`Warning` on non-application shutdown, `Information` on recovery with elapsed `{Duration}`, `Information` per failed internal recovery attempt). It SHALL NOT emit any connection metric and SHALL NOT accept a `RayTreeMeter` constructor parameter.
 
-#### Scenario: Application-initiated shutdown is not counted
-- **WHEN** `RabbitMqPublisher.DisposeAsync` is invoked and the resulting shutdown event has `Initiator = Application`
-- **THEN** no disconnect metric SHALL be recorded and no warning SHALL be logged.
+The `RabbitMqConsumer` has no logger and therefore SHALL NOT subscribe to any recovery event: with the connection metrics removed, those subscriptions produced no operator-visible signal. The consumer SHALL NOT accept a `RayTreeMeter` constructor parameter.
 
-### Requirement: Outbox connection-fault observability
-`IOutbox` SHALL expose three default-implemented members so consumers of an arbitrary `IOutbox` can observe transient connection faults without retry code:
+#### Scenario: Publisher logs a Warning on non-application shutdown
+- **WHEN** the `RabbitMqPublisher`'s `IConnection` raises `ConnectionShutdownAsync` with `Initiator != Application`
+- **THEN** a `Warning` log SHALL be emitted with the shutdown reason, `{Endpoint}`, `{ReplyCode}`, and `{ReplyText}`
+- **AND** no metric SHALL be recorded.
 
-- `bool IsConnectionFault(Exception ex)` — default `false`. Concrete implementations override to classify connection-level exceptions (network drop, broker shutdown, transient transport) versus application-level exceptions (constraint violation, malformed SQL, business-rule rejection).
-- `string? ConnectionComponent { get; }` — default `null`. Returns the `component` tag value to use for connection metrics, or `null` when the outbox has no observable external connection (e.g. `InMemoryOutbox`).
-- `string? ConnectionEndpoint { get; }` — default `null`. Returns the `endpoint` tag value.
+#### Scenario: Publisher logs Information on recovery
+- **WHEN** the publisher's `IConnection` raises `RecoverySucceededAsync`
+- **THEN** an `Information` log SHALL be emitted with `{Endpoint}` and `{Duration}` (seconds since the most recent non-application shutdown)
+- **AND** no metric SHALL be recorded.
 
-`PostgreSqlOutbox<TEntity>` SHALL override these: `IsConnectionFault` returns `true` for `NpgsqlException { IsTransient: true }`, `NpgsqlException` with `SocketException`/`IOException` inner, `PostgresException` with `SqlState` in `{"57P01", "57P02", "57P03", "08000", "08003", "08006", "08001", "08004", "08007"}` (admin/crash shutdown, cannot_connect_now, and the `08xxx` connection_exception family), and `ObjectDisposedException`. `ConnectionComponent` returns `"postgres.outbox"`. `ConnectionEndpoint` returns `"{Host}:{Port}"` parsed once from the connection string.
+#### Scenario: Application-initiated shutdown is silent
+- **WHEN** `RabbitMqPublisher.DisposeAsync` is invoked and the resulting shutdown event has `Initiator = Application`
+- **THEN** no warning SHALL be logged and no metric SHALL be recorded.
 
-The classifier used by `PostgreSqlOutbox` SHALL be the same set as `NotificationBasedPublisher`'s classifier — both delegate to an internal `static bool PostgresFault.IsConnectionFault(Exception)` so the two stay in sync.
+#### Scenario: Consumer does not observe recovery
+- **WHEN** the `RabbitMqConsumer`'s connection shuts down and later recovers
+- **THEN** the consumer SHALL emit neither a log entry nor a metric
+- **AND** the consumer constructor SHALL expose no `RayTreeMeter` parameter.
 
-`OutboxPublisherService.ProcessBatchAsync`'s existing batch-error catch block SHALL consult `_outbox.IsConnectionFault(ex)` and `_outbox.ConnectionComponent`. When the classifier returns `true` AND `ConnectionComponent` is non-null:
+### Requirement: Outbox connection-fault observability
+`IOutbox` SHALL expose three default-implemented members so consumers of an arbitrary `IOutbox` can classify transient connection faults without retry code:
 
-1. Emit `raytree.connection.disconnects{component=ConnectionComponent, endpoint=ConnectionEndpoint}` exactly once per transition into the unhealthy state (tracked via a per-service `_outboxUnhealthy` flag).
-2. Log the exception at `Warning` instead of `Error`, with `{Component}` and `{Endpoint}` structured properties.
-3. On the first subsequent batch that completes without throwing, emit `raytree.connection.recoveries{outcome="succeeded"}` plus `raytree.connection.recovery.duration` (wall-clock seconds since the first failure), log `Information` "outbox connection recovered", and clear `_outboxUnhealthy`.
+- `bool IsConnectionFault(Exception ex)` — default `false`. Concrete implementations override to classify connection-level exceptions versus application-level exceptions.
+- `string? ConnectionComponent { get; }` — default `null`. Returns a stable component identifier used as a structured-log property, or `null` when the outbox has no observable external connection.
+- `string? ConnectionEndpoint { get; }` — default `null`. Returns the endpoint identifier used as a structured-log property.
 
-When the classifier returns `false` OR `ConnectionComponent` is `null`, the existing `Error` log path is preserved unchanged. No retry code is added — the existing polling cadence is the retry.
+`PostgreSqlOutbox<TEntity>` SHALL override these: `IsConnectionFault` returns `true` for `NpgsqlException { IsTransient: true }`, `NpgsqlException` with `SocketException`/`IOException` inner, `PostgresException` with `SqlState` in `{"57P01", "57P02", "57P03", "08000", "08003", "08006", "08001", "08004", "08007"}`, and `ObjectDisposedException`. `ConnectionComponent` returns `"postgres.outbox"`. `ConnectionEndpoint` returns `"{Host}:{Port}"`. The classifier used by `PostgreSqlOutbox` SHALL be the same `static bool PostgresFault.IsConnectionFault(Exception)` used by `NotificationBasedPublisher`.
 
-`NotificationBasedPublisher.FallbackPollingLoopAsync` SHALL apply the same pattern: in the existing `ProcessUnpublishedChangesAsync` per-outbox iteration, when an `IOutbox` call throws and `_outbox.IsConnectionFault(ex)` returns `true` AND `_outbox.ConnectionComponent` is non-null, emit the disconnect metric and log `Warning`; on next success per outbox, emit the recovery metric. Per-outbox `_unhealthy` state is tracked in a `ConcurrentDictionary<Type, bool>` keyed by entity type.
+`OutboxPublisherService.ProcessBatchAsync`'s batch-error catch block SHALL consult `_outbox.IsConnectionFault(ex)` and `_outbox.ConnectionComponent`. When the classifier returns `true` AND `ConnectionComponent` is non-null, the failure SHALL be logged at `Warning` instead of `Error`, with `{Component}` and `{Endpoint}` structured properties, and a per-service `_outboxUnhealthy` flag SHALL be set. On the first subsequent batch that completes without throwing, an `Information` "outbox connection recovered" log SHALL be emitted with `{Duration}` (wall-clock seconds since the first failure) and the flag SHALL be cleared. When the classifier returns `false` OR `ConnectionComponent` is `null`, the existing `Error` log path SHALL be preserved unchanged. No connection metric SHALL be emitted in any of these paths. No retry code is added — the existing polling cadence is the retry.
 
-#### Scenario: Outbox publisher disconnect metric is emitted once per transition
-- **WHEN** `OutboxPublisherService.ProcessBatchAsync` catches a connection-fault exception for the first time after a healthy period
-- **THEN** `raytree.connection.disconnects{component="postgres.outbox", endpoint="…"}` SHALL be incremented by 1
-- **AND** subsequent consecutive failed batches SHALL NOT increment the counter again (the service is already unhealthy).
+`NotificationBasedPublisher.FallbackPollingLoopAsync` SHALL apply the same `Warning`/`Information` log pattern per outbox, keyed by entity type in a `ConcurrentDictionary<Type, bool>`, with no metric emission.
 
 #### Scenario: Outbox publisher log demotion on connection fault
-- **WHEN** `OutboxPublisherService.ProcessBatchAsync` catches an exception and `_outbox.IsConnectionFault(ex)` returns `true`
-- **THEN** the failure SHALL be logged at `Warning` (not the usual `Error`) with `{Component}` and `{Endpoint}` structured properties.
+- **WHEN** `OutboxPublisherService.ProcessBatchAsync` catches an exception and `_outbox.IsConnectionFault(ex)` returns `true` AND `ConnectionComponent` is non-null
+- **THEN** the failure SHALL be logged at `Warning` (not `Error`) with `{Component}` and `{Endpoint}`
+- **AND** no connection metric SHALL be emitted.
 
-#### Scenario: Outbox publisher recovery metric is emitted on first success after failure
+#### Scenario: Outbox publisher recovery log on first success after failure
 - **WHEN** `OutboxPublisherService.ProcessBatchAsync` completes without throwing AND the service was previously unhealthy
-- **THEN** `raytree.connection.recoveries{outcome="succeeded"}` SHALL be incremented by 1
-- **AND** `raytree.connection.recovery.duration` SHALL record the wall-clock seconds elapsed since the first failure
-- **AND** an `Information` log "outbox connection recovered" SHALL be emitted with `{Duration}`
-- **AND** the internal `_outboxUnhealthy` flag SHALL be cleared.
+- **THEN** an `Information` "outbox connection recovered" log SHALL be emitted with `{Duration}`
+- **AND** the `_outboxUnhealthy` flag SHALL be cleared
+- **AND** no connection metric SHALL be emitted.
 
 #### Scenario: Non-connection-fault exception preserves existing Error log
 - **WHEN** `OutboxPublisherService.ProcessBatchAsync` catches an exception for which `_outbox.IsConnectionFault(ex)` returns `false`
-- **THEN** the existing `Error` log path SHALL be unchanged
-- **AND** no connection metric SHALL be emitted.
-
-#### Scenario: Outbox without ConnectionComponent is unobserved
-- **WHEN** an `IOutbox` implementation leaves `ConnectionComponent` at its default `null` (e.g. `InMemoryOutbox`)
-- **THEN** `OutboxPublisherService` SHALL fall through to the existing `Error` log path even when `IsConnectionFault` is true
-- **AND** no connection metric SHALL be emitted.
-
-#### Scenario: NotificationBasedPublisher fallback polling emits per-outbox metrics
-- **WHEN** `NotificationBasedPublisher.ProcessUnpublishedChangesAsync` calls into an `IOutbox` whose `IsConnectionFault(ex)` returns `true` for the thrown exception
-- **THEN** the disconnect/recovery metric and `Warning`/`Information` log pattern SHALL be applied per outbox (keyed by entity type) using the same transition semantics as `OutboxPublisherService`.
+- **THEN** the existing `Error` log path SHALL be unchanged.
 
 #### Scenario: Write-path exceptions still propagate to the caller
 - **WHEN** a caller invokes `EntityChangeTracker.TrackInsertAsync` and the underlying `PostgreSqlOutbox.WriteAsync` throws a connection-fault exception
 - **THEN** the exception SHALL propagate to the caller unchanged
-- **AND** no automatic retry SHALL be performed by the library at the write path (the caller's transaction context owns retry semantics).
+- **AND** no automatic retry SHALL be performed by the library at the write path.
 
 ### Requirement: Recovery options exposure on plugin options classes
-`NotificationBasedPublisherOptions`, `KafkaPublisherOptions`, and `KafkaConsumerOptions` SHALL each expose a `ConnectionRecovery` property of type `ConnectionRecoveryOptions` initialised to `new ConnectionRecoveryOptions()`. `RabbitMqPublisherOptions` and `RabbitMqConsumerOptions` SHALL NOT expose this property — RabbitMQ recovery is owned by the SDK and is not configurable through RayTree.
+`NotificationBasedPublisherOptions` SHALL expose a `ConnectionRecovery` property of type `PostgresConnectionRecoveryOptions` initialised to `new PostgresConnectionRecoveryOptions()`. `KafkaPublisherOptions` and `KafkaConsumerOptions` SHALL each expose a `ConnectionRecovery` property of type `KafkaConnectionRecoveryOptions` initialised to `new KafkaConnectionRecoveryOptions()`. `RabbitMqPublisherOptions` and `RabbitMqConsumerOptions` SHALL NOT expose this property — RabbitMQ recovery is owned by the SDK and is not configurable through RayTree.
 
 #### Scenario: Default property value is enabled
-- **WHEN** any of the three listed options classes is constructed via its parameterless constructor
+- **WHEN** `NotificationBasedPublisherOptions`, `KafkaPublisherOptions`, or `KafkaConsumerOptions` is constructed via its parameterless constructor
 - **THEN** `ConnectionRecovery.Enabled` SHALL be `true` and the other fields SHALL match the documented defaults.
 
+#### Scenario: Property type is the plugin-local options type
+- **WHEN** a caller reads `KafkaPublisherOptions.ConnectionRecovery`
+- **THEN** the value SHALL be a `KafkaConnectionRecoveryOptions` instance
+- **AND** reading `NotificationBasedPublisherOptions.ConnectionRecovery` SHALL yield a `PostgresConnectionRecoveryOptions` instance.
+
 #### Scenario: RabbitMQ options do not expose ConnectionRecovery
 - **WHEN** a caller inspects `RabbitMqPublisherOptions` / `RabbitMqConsumerOptions` via reflection or autocomplete
 - **THEN** no `ConnectionRecovery` property SHALL be present
 - **AND** the SDK's recovery options (e.g. `NetworkRecoveryInterval`) remain accessible through the underlying `ConnectionFactory` only if the caller constructs one explicitly.
 
-### Requirement: Recovery options bound from configuration
-`RayTree.Hosting.AddChangeTracking` SHALL bind `ConnectionRecoveryOptions` instances from configuration sections `ChangeTracking:Publisher:ConnectionRecovery` and `ChangeTracking:Subscriber:ConnectionRecovery`. The bound values SHALL be applied as the default for any plugin whose own `ConnectionRecovery` property is unchanged from the parameterless-constructor default. Explicit per-plugin overrides SHALL win.
-
-#### Scenario: Bound section sets the default
-- **WHEN** `appsettings.json` contains `"ChangeTracking:Publisher:ConnectionRecovery": { "MaxAttempts": 10 }`
-- **AND** a Kafka publisher is registered without an explicit `ConnectionRecovery` override
-- **THEN** that publisher's reconnect loop SHALL be bounded to 10 attempts.
-
-#### Scenario: Per-plugin override wins
-- **WHEN** the same configuration is set AND a Kafka publisher is registered with `UseKafka(o => o.ConnectionRecovery = new ConnectionRecoveryOptions { MaxAttempts = 3 })`
-- **THEN** the Kafka publisher SHALL use 3 attempts; other publishers SHALL use 10.
-
 ### Requirement: Recovery logs are emitted at documented levels
-Each plugin that participates in connection recovery (whether it implements the recovery itself or merely observes the SDK) SHALL emit the following log entries through its runtime-service `ILogger<T>`:
+Each plugin that participates in connection recovery and owns an `ILogger<T>` SHALL emit the following log entries:
 
-- **First detection of disconnect per recovery cycle**: `Warning`, with the underlying exception, `{Component}`, and `{Endpoint}`.
+- **First detection of disconnect per recovery cycle**: `Warning`, with the underlying exception (where available), `{Component}`, and `{Endpoint}`.
 - **Each retry attempt** (Postgres and Kafka only — the two plugins owning their own retry loop): `Information`, with `{Component}`, `{Endpoint}`, `{AttemptNumber}`, and `{Delay}` (the actually scheduled delay including jitter, in seconds).
-- **Successful recovery**: `Information`, with `{Component}`, `{Endpoint}`, `{AttemptCount}` (for Postgres/Kafka — the count of attempts), and `{Duration}` (wall-clock seconds elapsed since the first detection in this cycle).
+- **Successful recovery**: `Information`, with `{Component}`, `{Endpoint}`, `{AttemptCount}` (for Postgres/Kafka), and `{Duration}` (wall-clock seconds elapsed since the first detection in this cycle).
 - **Exhausted attempts** (Postgres and Kafka only): `Error`, with the most recent exception, `{Component}`, `{Endpoint}`, and `{AttemptCount}`.
 
-`RabbitMqConsumer` has no `ILogger` field (existing exception to the logging-placement rule). Its disconnects and recoveries SHALL still be observable via the metric instruments but SHALL NOT produce log entries.
+No connection metric SHALL accompany any of these logs — the `raytree.connection.*` instruments no longer exist. `RabbitMqConsumer` has no `ILogger` field and SHALL produce neither logs nor metrics for connection recovery.
 
 #### Scenario: First disconnect emits Warning with exception
-- **WHEN** any participating plugin observes the first disconnect of a recovery cycle (Kafka error handler fires, Postgres `WaitAsync` throws a connection fault, RabbitMQ `ConnectionShutdownAsync` fires non-application)
-- **THEN** a `Warning` log SHALL be emitted with `{Component}` and `{Endpoint}` structured properties and the underlying exception attached (where available).
+- **WHEN** a logger-owning participating plugin observes the first disconnect of a recovery cycle (Kafka error handler fires, Postgres `WaitAsync` throws a connection fault, RabbitMQ publisher `ConnectionShutdownAsync` fires non-application)
+- **THEN** a `Warning` log SHALL be emitted with `{Component}` and `{Endpoint}` and the underlying exception attached where available.
 
 #### Scenario: Retry attempt emits Information with delay
 - **WHEN** Postgres or Kafka schedules the Nth retry attempt
 - **THEN** an `Information` log SHALL be emitted with `{AttemptNumber} = N` and `{Delay}` equal to the actually-scheduled delay (including jitter) in seconds.
 
-#### Scenario: RabbitMqConsumer recovery is silent on logs but observable via metrics
+#### Scenario: RabbitMqConsumer recovery is fully silent
 - **WHEN** a recovery cycle runs for `RabbitMqConsumer`
-- **THEN** no log entries SHALL be emitted from the consumer
-- **AND** `raytree.connection.disconnects` and `raytree.connection.recoveries` with `component = "rabbitmq.consumer"` SHALL be recorded as usual.
+- **THEN** no log entries SHALL be emitted
+- **AND** no connection metric SHALL be recorded.
diff --git a/openspec/specs/opentelemetry-metrics/spec.md b/openspec/specs/opentelemetry-metrics/spec.md
index cbf6212..6d48090 100644
--- a/openspec/specs/opentelemetry-metrics/spec.md
+++ b/openspec/specs/opentelemetry-metrics/spec.md
@@ -142,41 +142,15 @@ The extension SHALL be a thin pass-through that does not configure exporters, vi
 - **THEN** its `unit` property is the string `"s"` per OTel semantic conventions
 
 
-### Requirement: Connection-recovery instruments are emitted
-The system SHALL emit four `System.Diagnostics.Metrics` instruments on the `"RayTree"` meter that describe connection-recovery activity across every connection-bearing plugin:
-
-- `raytree.connection.disconnects` — `Counter<long>`, tagged with `component` and `endpoint`. Incremented once each time a plugin observes a disconnect (Postgres connection-fault exception, Kafka fatal error, RabbitMQ `ConnectionShutdownAsync` with non-application initiator).
-- `raytree.connection.recoveries` — `Counter<long>`, tagged with `component`, `endpoint`, and `outcome ∈ {"succeeded", "exhausted"}`. Incremented once per completed recovery cycle.
-- `raytree.connection.recovery.duration` — `Histogram<double>`, unit `s`, tagged with `component`, `endpoint`, and `outcome`. Records wall-clock seconds elapsed for each completed recovery cycle (from first detection to completion).
-- `raytree.connection.state` — `ObservableGauge<int>` emitting `1` (connected) or `0` (disconnected), tagged with `component` and `endpoint`. Sampled per OTel collection tick.
-
-`component` values SHALL be drawn from the fixed set `{"rabbitmq.publisher", "rabbitmq.consumer", "kafka.publisher", "kafka.consumer", "postgres.notification", "postgres.outbox"}`. The `"postgres.outbox"` component is emitted by `OutboxPublisherService` and `NotificationBasedPublisher`'s fallback polling loop when an outbox call fails with a connection-fault classified by the `IOutbox` implementation. `endpoint` SHALL identify the broker host (`"{HostName}:{Port}"` for RabbitMQ, `BootstrapServers` for Kafka) or the LISTEN channel name (for Postgres) and SHALL be sourced from plugin configuration only — never from caller-supplied request data.
-
-Suggested histogram bucket boundaries for `raytree.connection.recovery.duration` are `[0.1, 0.5, 1, 2, 5, 10, 30, 60, 120]` seconds.
-
-#### Scenario: Disconnect increments counter with component tag
-- **WHEN** `RabbitMqPublisher` observes a `ConnectionShutdownAsync` event with non-application initiator
-- **THEN** `raytree.connection.disconnects` SHALL be incremented by 1 with `component = "rabbitmq.publisher"` and `endpoint` equal to `"{HostName}:{Port}"`.
-
-#### Scenario: Successful recovery records duration with outcome="succeeded"
-- **WHEN** a recovery cycle completes successfully for any participating component
-- **THEN** `raytree.connection.recoveries` SHALL be incremented by 1 with `outcome = "succeeded"`
-- **AND** `raytree.connection.recovery.duration` SHALL record the elapsed wall-clock seconds with the same tag set.
-
-#### Scenario: Exhausted recovery records duration with outcome="exhausted"
-- **WHEN** a Postgres or Kafka recovery cycle exhausts the configured `MaxAttempts` without success
-- **THEN** `raytree.connection.recoveries` SHALL be incremented by 1 with `outcome = "exhausted"`
-- **AND** `raytree.connection.recovery.duration` SHALL record the elapsed wall-clock seconds with the same tag set.
-
-#### Scenario: State gauge reflects current connectivity per component
-- **WHEN** an OTel `MeterProvider` performs a collection tick
-- **THEN** `raytree.connection.state` SHALL emit one observation per registered `(component, endpoint)` pair
-- **AND** the value SHALL be `1` when the component is connected and `0` when it is inside a recovery cycle.
-
-#### Scenario: Duration histogram uses seconds
-- **WHEN** `raytree.connection.recovery.duration` is created
-- **THEN** its `unit` property SHALL be the string `"s"` per the existing duration-unit requirement.
-
-#### Scenario: Outbox-side disconnect is tagged "postgres.outbox"
-- **WHEN** `OutboxPublisherService.ProcessBatchAsync` catches a connection-fault exception and the outbox's `ConnectionComponent` is `"postgres.outbox"`
-- **THEN** `raytree.connection.disconnects` SHALL be incremented with `component = "postgres.outbox"` and `endpoint = "{Host}:{Port}"` parsed from the connection string.
+### Requirement: Metric emission is not part of the public API
+`RayTreeMeter` SHALL expose no public method for emitting or registering a metric. All emit/register members (`RecordPublishSuccess`, `RecordPublishFailure`, `RecordPayloadSize`, `RecordBatchSize`, `RegisterPendingGauge`) SHALL be `internal`, consumed only by `RayTree.Core` and by assemblies granted `InternalsVisibleTo` (`RayTree.Plugins.PostgreSQL`, `RayTree.EntityFrameworkCore`, and the test projects). `RayTreeMeter`'s public surface SHALL consist of `MeterName`, its constructors, `DefaultPendingCacheTtl`, and `Dispose()`. Metric *observation* SHALL remain public via the `"RayTree"` meter name and `RayTree.OpenTelemetry.AddRayTreeMetrics`.
+
+#### Scenario: No public emit method exists
+- **WHEN** a consumer outside Core and without `InternalsVisibleTo` references `RayTreeMeter`
+- **THEN** no metric-emitting or gauge-registering method SHALL be accessible
+- **AND** only `MeterName`, the constructors, `DefaultPendingCacheTtl`, and `Dispose()` SHALL be available.
+
+#### Scenario: Privileged assemblies still emit internally
+- **WHEN** `NotificationBasedPublisher` (in `RayTree.Plugins.PostgreSQL`, an `InternalsVisibleTo`-granted assembly) emits publish metrics on the NOTIFY fast-path
+- **THEN** it SHALL call the `internal` `RecordPublishSuccess` / `RecordPublishFailure` / `RecordPayloadSize` / `RecordBatchSize` members
+- **AND** the emitted instruments SHALL remain observable via `AddRayTreeMetrics`.
diff --git a/src/RayTree.Core/Distribution/OutboxPublisherService.cs b/src/RayTree.Core/Distribution/OutboxPublisherService.cs
index a6da416..fe792da 100644
--- a/src/RayTree.Core/Distribution/OutboxPublisherService.cs
+++ b/src/RayTree.Core/Distribution/OutboxPublisherService.cs
@@ -364,10 +364,7 @@ private void HandleBatchError(Exception ex)
             {
                 var endpoint = outbox.ConnectionEndpoint ?? "<unknown>";
                 if (_unhealthySince is null)
-                {
                     _unhealthySince = DateTime.UtcNow;
-                    _meter.RecordConnectionDisconnect(component, endpoint);
-                }
                 _logger.LogWarning(rootCause,
                     "Outbox connection fault for {EntityType} ({Component} at {Endpoint}); polling will retry on next tick",
                     typeof(TEntity).Name, component, endpoint);
@@ -379,14 +376,13 @@ private void HandleBatchError(Exception ex)
         }
 
         /// <summary>
-        /// Emits the connection-recovery metric and log entry, then clears the unhealthy flag.
+        /// Emits the connection-recovery log entry, then clears the unhealthy flag.
         /// Called from the polling loop on the first successful batch following a fault.
         /// </summary>
         private void EmitOutboxRecovered()
         {
-            // Always clear the flag — even if metric emission throws or the outbox lookup
-            // fails (shutdown). Otherwise we'd loop emitting the recovery on every
-            // subsequent successful batch.
+            // Always clear the flag — even if the outbox lookup fails (shutdown). Otherwise
+            // we'd loop emitting the recovery log on every subsequent successful batch.
             try
             {
                 var outbox    = _publisher.GetOutbox(typeof(TEntity));
@@ -394,7 +390,6 @@ private void EmitOutboxRecovered()
                 var endpoint  = outbox.ConnectionEndpoint  ?? "<unknown>";
                 // Clamp at zero to defend against backward clock jumps.
                 var duration  = Math.Max(0, (DateTime.UtcNow - _unhealthySince!.Value).TotalSeconds);
-                _meter.RecordConnectionRecovery(component, endpoint, outcome: "succeeded", duration);
                 _logger.LogInformation(
                     "Outbox connection recovered for {EntityType} ({Component} at {Endpoint}) after {Duration:F2}s",
                     typeof(TEntity).Name, component, endpoint, duration);
@@ -402,7 +397,7 @@ private void EmitOutboxRecovered()
             catch (Exception ex)
             {
                 _logger.LogWarning(ex,
-                    "Failed to emit outbox recovery metric for {EntityType}; clearing unhealthy flag anyway",
+                    "Failed to emit outbox recovery log for {EntityType}; clearing unhealthy flag anyway",
                     typeof(TEntity).Name);
             }
             finally
diff --git a/src/RayTree.Core/Telemetry/RayTreeMeter.cs b/src/RayTree.Core/Telemetry/RayTreeMeter.cs
index 33b4c22..33455c1 100644
--- a/src/RayTree.Core/Telemetry/RayTreeMeter.cs
+++ b/src/RayTree.Core/Telemetry/RayTreeMeter.cs
@@ -67,17 +67,6 @@ public sealed class RayTreeMeter : IDisposable
     internal Histogram<double> SubscriberProcessingDuration { get; }
     internal Histogram<double> SubscriberLagDuration { get; }
 
-    // -------------------------------------------------------------------------
-    // Connection-recovery instruments — emitted by every connection-bearing
-    // plugin. See docs/opentelemetry-metrics.md for tag semantics.
-    // -------------------------------------------------------------------------
-    internal Counter<long>     ConnectionDisconnects { get; }
-    internal Counter<long>     ConnectionRecoveries { get; }
-    internal Histogram<double> ConnectionRecoveryDuration { get; }
-
-    private readonly List<(string Component, string Endpoint, Func<int> GetState)> _connectionStateSources = new();
-    private readonly object _connectionStateGate = new();
-
     /// <summary>Default pending-count gauge cache TTL (10 seconds). Roughly aligns with typical
     /// OTel collection cadence; tunable per-instance via the constructor.</summary>
     public static readonly TimeSpan DefaultPendingCacheTtl = TimeSpan.FromSeconds(10);
@@ -120,16 +109,6 @@ public RayTreeMeter(TimeSpan pendingCacheTtl)
             ObservePendingCounts,
             unit: "{messages}",
             description: "Unpublished outbox records per entity type.");
-
-        ConnectionDisconnects      = _meter.CreateCounter<long>   ("raytree.connection.disconnects",       unit: "{disconnects}");
-        ConnectionRecoveries       = _meter.CreateCounter<long>   ("raytree.connection.recoveries",        unit: "{recoveries}");
-        ConnectionRecoveryDuration = _meter.CreateHistogram<double>("raytree.connection.recovery.duration", unit: "s");
-
-        _meter.CreateObservableGauge(
-            "raytree.connection.state",
-            ObserveConnectionStates,
-            unit: "{state}",
-            description: "1 = connected, 0 = disconnected; tagged with component and endpoint.");
     }
 
     /// <summary>
@@ -137,7 +116,7 @@ public RayTreeMeter(TimeSpan pendingCacheTtl)
     /// callback is invoked once per OTel collection tick; each tuple yields one measurement
     /// tagged with <c>entity_type</c>.
     /// </summary>
-    public void RegisterPendingGauge(Func<IEnumerable<(Type entityType, IOutbox outbox)>> source)
+    internal void RegisterPendingGauge(Func<IEnumerable<(Type entityType, IOutbox outbox)>> source)
     {
         ArgumentNullException.ThrowIfNull(source);
         lock (_gaugeGate)
@@ -198,10 +177,11 @@ private IEnumerable<Measurement<long>> ObservePendingCounts()
     }
 
     // -------------------------------------------------------------------------
-    // Public emission facade — for first-party plugin assemblies that publish
-    // to the outbox but live outside RayTree.Core (e.g. NotificationBasedPublisher
-    // in RayTree.Plugins.PostgreSQL). Raw instrument properties stay internal;
-    // callers interact with named, semantically meaningful methods.
+    // Internal emission facade — for RayTree.Core and first-party plugin
+    // assemblies that publish to the outbox but live outside RayTree.Core
+    // (e.g. NotificationBasedPublisher in RayTree.Plugins.PostgreSQL, which sees
+    // Core internals via InternalsVisibleTo). Metric emission is a Core-internal
+    // concern; observation is the public contract (RayTree.OpenTelemetry).
     // -------------------------------------------------------------------------
 
     /// <summary>
@@ -213,7 +193,7 @@ private IEnumerable<Measurement<long>> ObservePendingCounts()
     /// <param name="lagSeconds">Time since the outbox record was written, in seconds.
     /// Clamped to zero if negative (clock skew).</param>
     /// <param name="attempts">Total attempts made — 1 for a first-try success.</param>
-    public void RecordPublishSuccess(
+    internal void RecordPublishSuccess(
         Type entityType, ChangeType changeType,
         double durationSeconds, double lagSeconds,
         int attempts = 1)
@@ -230,7 +210,7 @@ public void RecordPublishSuccess(
     /// Records the duration of a failed publish attempt. The caller is responsible for
     /// reverting the outbox claim so the record can be retried.
     /// </summary>
-    public void RecordPublishFailure(Type entityType, ChangeType changeType, double durationSeconds)
+    internal void RecordPublishFailure(Type entityType, ChangeType changeType, double durationSeconds)
     {
         OutboxPublishDuration.Record(durationSeconds, EntityTag(entityType), ChangeTag(changeType));
     }
@@ -239,7 +219,7 @@ public void RecordPublishFailure(Type entityType, ChangeType changeType, double
     /// Records the compressed payload byte size for one <c>MessageEnvelope</c>.
     /// Call after compression, before handing the envelope to the queue publisher.
     /// </summary>
-    public void RecordPayloadSize(Type entityType, ChangeType changeType, int bytes)
+    internal void RecordPayloadSize(Type entityType, ChangeType changeType, int bytes)
     {
         OutboxPayloadSize.Record(bytes, EntityTag(entityType), ChangeTag(changeType));
     }
@@ -247,91 +227,11 @@ public void RecordPayloadSize(Type entityType, ChangeType changeType, int bytes)
     /// <summary>
     /// Records the number of unpublished records retrieved in one outbox poll batch.
     /// </summary>
-    public void RecordBatchSize(Type entityType, int count)
+    internal void RecordBatchSize(Type entityType, int count)
     {
         OutboxBatchSize.Record(count, EntityTag(entityType));
     }
 
-    /// <summary>
-    /// Increments <c>raytree.connection.disconnects</c> with the supplied
-    /// <c>component</c> and <c>endpoint</c> tags. Called by plugins on the first
-    /// detection of a disconnect within a recovery cycle.
-    /// </summary>
-    public void RecordConnectionDisconnect(string component, string endpoint)
-    {
-        ConnectionDisconnects.Add(1, ComponentTag(component), EndpointTag(endpoint));
-    }
-
-    /// <summary>
-    /// Increments <c>raytree.connection.recoveries</c> and records
-    /// <c>raytree.connection.recovery.duration</c> with the supplied tags.
-    /// <paramref name="outcome"/> SHALL be either <c>"succeeded"</c> or <c>"exhausted"</c>.
-    /// </summary>
-    public void RecordConnectionRecovery(
-        string component, string endpoint, string outcome, double durationSeconds)
-    {
-        var componentTag = ComponentTag(component);
-        var endpointTag  = EndpointTag(endpoint);
-        var outcomeTag   = OutcomeTag(outcome);
-        ConnectionRecoveries.Add(1, componentTag, endpointTag, outcomeTag);
-        ConnectionRecoveryDuration.Record(durationSeconds, componentTag, endpointTag, outcomeTag);
-    }
-
-    /// <summary>
-    /// Registers a per-connection observable-gauge source. Each registration contributes one
-    /// measurement to <c>raytree.connection.state</c> per OTel collection tick. Disposing the
-    /// returned subscription removes the source.
-    /// </summary>
-    public IDisposable RegisterConnectionStateGauge(string component, string endpoint, Func<int> getState)
-    {
-        ArgumentNullException.ThrowIfNull(component);
-        ArgumentNullException.ThrowIfNull(endpoint);
-        ArgumentNullException.ThrowIfNull(getState);
-
-        var entry = (component, endpoint, getState);
-        lock (_connectionStateGate)
-            _connectionStateSources.Add(entry);
-        return new ConnectionStateSubscription(this, entry);
-    }
-
-    private IEnumerable<Measurement<int>> ObserveConnectionStates()
-    {
-        (string Component, string Endpoint, Func<int> GetState)[] snapshot;
-        lock (_connectionStateGate)
-            snapshot = _connectionStateSources.ToArray();
-
-        foreach (var (component, endpoint, getState) in snapshot)
-        {
-            int state;
-            try { state = getState(); }
-            catch { continue; }
-            yield return new Measurement<int>(state, ComponentTag(component), EndpointTag(endpoint));
-        }
-    }
-
-    private sealed class ConnectionStateSubscription : IDisposable
-    {
-        private readonly RayTreeMeter _owner;
-        private (string Component, string Endpoint, Func<int> GetState) _entry;
-        private bool _disposed;
-
-        public ConnectionStateSubscription(
-            RayTreeMeter owner,
-            (string Component, string Endpoint, Func<int> GetState) entry)
-        {
-            _owner = owner;
-            _entry = entry;
-        }
-
-        public void Dispose()
-        {
-            if (_disposed) return;
-            _disposed = true;
-            lock (_owner._connectionStateGate)
-                _owner._connectionStateSources.Remove(_entry);
-        }
-    }
-
     // -------------------------------------------------------------------------
     // Tag helpers — keep instrumentation call sites terse and consistent.
     // -------------------------------------------------------------------------
@@ -348,15 +248,6 @@ public void Dispose()
     internal static KeyValuePair<string, object?> ReasonTag(string reason)
         => new("reason", reason);
 
-    internal static KeyValuePair<string, object?> ComponentTag(string component)
-        => new("component", component);
-
-    internal static KeyValuePair<string, object?> EndpointTag(string endpoint)
-        => new("endpoint", endpoint);
-
-    internal static KeyValuePair<string, object?> OutcomeTag(string outcome)
-        => new("outcome", outcome);
-
     /// <summary>
     /// Resolves the simple class name from a full <c>EntityChange.EntityType</c> string
     /// (which holds <c>Type.FullName</c>) so gauge labels stay low-cardinality and aligned
diff --git a/src/RayTree.Hosting/ChangeTrackingRecoveryKeys.cs b/src/RayTree.Hosting/ChangeTrackingRecoveryKeys.cs
deleted file mode 100644
index 1938c4f..0000000
--- a/src/RayTree.Hosting/ChangeTrackingRecoveryKeys.cs
+++ /dev/null
@@ -1,24 +0,0 @@
-namespace RayTree.Hosting;
-
-/// <summary>
-/// Named-options keys for the bound <c>ConnectionRecoveryOptions</c> defaults registered by
-/// <see cref="ServiceCollectionExtensions.AddChangeTracking"/>. Plugins that want to honor
-/// the host's configured defaults resolve them via
-/// <c>IOptionsMonitor&lt;ConnectionRecoveryOptions&gt;.Get(ChangeTrackingRecoveryKeys.Publisher)</c>
-/// (or <see cref="Subscriber"/>) and merge into their own plugin options before constructing
-/// the publisher/consumer instance.
-/// </summary>
-public static class ChangeTrackingRecoveryKeys
-{
-    /// <summary>
-    /// Key for publisher-side recovery defaults (Postgres LISTEN reconnect, Kafka publisher
-    /// fatal-error rebuild). Bound from <c>ChangeTracking:Publisher:ConnectionRecovery</c>.
-    /// </summary>
-    public const string Publisher = "RayTree.Publisher.ConnectionRecovery";
-
-    /// <summary>
-    /// Key for subscriber-side recovery defaults (Kafka consumer fatal-error rebuild).
-    /// Bound from <c>ChangeTracking:Subscriber:ConnectionRecovery</c>.
-    /// </summary>
-    public const string Subscriber = "RayTree.Subscriber.ConnectionRecovery";
-}
diff --git a/src/RayTree.Hosting/ServiceCollectionExtensions.cs b/src/RayTree.Hosting/ServiceCollectionExtensions.cs
index 37b87e5..89b91da 100644
--- a/src/RayTree.Hosting/ServiceCollectionExtensions.cs
+++ b/src/RayTree.Hosting/ServiceCollectionExtensions.cs
@@ -4,7 +4,6 @@
 using Microsoft.Extensions.Logging;
 using RayTree.Core.Distribution;
 using RayTree.Core.Handling;
-using RayTree.Core.Resilience;
 using RayTree.Core.Telemetry;
 using RayTree.Core.Tracking;
 
@@ -38,19 +37,6 @@ public static IServiceCollection AddChangeTracking(
         {
             services.Configure<OutboxPublisherOptions>(configuration.GetSection("ChangeTracking:Publisher"));
             services.Configure<SubscriberOptions>(configuration.GetSection("ChangeTracking:Subscriber"));
-
-            // Connection-recovery defaults are bound as NAMED options so the same type can
-            // be configured independently for publisher-side (Postgres / Kafka publisher)
-            // and subscriber-side (Kafka consumer) plugins. Plugins that want to honor
-            // these defaults resolve them via
-            // <c>IOptionsMonitor&lt;ConnectionRecoveryOptions&gt;.Get(ChangeTrackingRecoveryKeys.Publisher)</c>
-            // and merge into their own options before constructing the publisher/consumer.
-            services.Configure<ConnectionRecoveryOptions>(
-                ChangeTrackingRecoveryKeys.Publisher,
-                configuration.GetSection("ChangeTracking:Publisher:ConnectionRecovery"));
-            services.Configure<ConnectionRecoveryOptions>(
-                ChangeTrackingRecoveryKeys.Subscriber,
-                configuration.GetSection("ChangeTracking:Subscriber:ConnectionRecovery"));
         }
 
         services.AddHostedService<ChangeTrackingHostedService>();
diff --git a/src/RayTree.Plugins.Kafka/KafkaBuilderExtensions.cs b/src/RayTree.Plugins.Kafka/KafkaBuilderExtensions.cs
index 56d821d..34753c1 100644
--- a/src/RayTree.Plugins.Kafka/KafkaBuilderExtensions.cs
+++ b/src/RayTree.Plugins.Kafka/KafkaBuilderExtensions.cs
@@ -1,6 +1,5 @@
 using Microsoft.Extensions.Logging;
 using RayTree.Core.Plugins.Publisher;
-using RayTree.Core.Telemetry;
 using RayTree.Core.Tracking;
 
 namespace RayTree.Plugins.Kafka;
@@ -10,22 +9,14 @@ public static class KafkaBuilderExtensions
     /// <summary>
     /// Registers <see cref="KafkaPublisher"/> as the queue publisher for every entity type.
     /// </summary>
-    /// <param name="meter">
-    /// Optional. When supplied, the publisher emits <c>raytree.connection.*</c> metrics on
-    /// fatal-error disposes and rebuilds. Pass the same <c>RayTreeMeter</c> the rest of the
-    /// tracker uses (e.g. resolved from the host DI container) so connection metrics share
-    /// the meter listener / OTel collection. When <c>null</c>, the publisher works normally
-    /// but emits no connection metrics.
-    /// </param>
     public static IChangeTrackingBuilder UseKafka(
         this IChangeTrackingBuilder builder,
         Action<KafkaPublisherOptions> configure,
-        ILoggerFactory? loggerFactory = null,
-        RayTreeMeter? meter = null)
+        ILoggerFactory? loggerFactory = null)
     {
         var options = new KafkaPublisherOptions();
         configure(options);
-        return builder.UsePublisher<IQueuePublisher>(_ => new KafkaPublisher(options, loggerFactory, meter));
+        return builder.UsePublisher<IQueuePublisher>(_ => new KafkaPublisher(options, loggerFactory));
     }
 
     public static KafkaPublisherOptions WithTopic(this KafkaPublisherOptions options, string topic)
diff --git a/src/RayTree.Plugins.Kafka/KafkaConnectionRecoveryOptions.cs b/src/RayTree.Plugins.Kafka/KafkaConnectionRecoveryOptions.cs
new file mode 100644
index 0000000..2220ac4
--- /dev/null
+++ b/src/RayTree.Plugins.Kafka/KafkaConnectionRecoveryOptions.cs
@@ -0,0 +1,110 @@
+namespace RayTree.Plugins.Kafka;
+
+/// <summary>
+/// Tunes the connection-recovery retry shape for the Kafka fatal-error rebuild loops owned by
+/// <c>KafkaPublisher</c> (producer rebuild on <c>SetErrorHandler</c> fault) and <c>KafkaConsumer</c>
+/// (consumer rebuild on a fatal <c>KafkaException</c> on the poll thread). The values describe an
+/// exponential-backoff schedule: the Nth retry waits <c>min(InitialDelay × Factor^(N-1), MaxDelay)</c>
+/// seconds, jittered by <c>±JitterFraction</c>.
+/// <para>
+/// <b>Validation timing:</b> per-field invariants (positive delays, factor &gt;= 1, jitter
+/// in [0, 1], positive MaxAttempts) are enforced at init time — they throw from object
+/// initializers before construction completes. Cross-field invariants
+/// (<c>MaxDelay &gt;= InitialDelay</c>) cannot be checked at init time because
+/// object-initializer assignment order is undefined; they're checked by <see cref="Validate"/>,
+/// which the publisher/consumer call on first use before entering their rebuild loop.
+/// </para>
+/// </summary>
+public sealed class KafkaConnectionRecoveryOptions
+{
+    private readonly TimeSpan _initialDelay = TimeSpan.FromSeconds(1);
+    private readonly TimeSpan _maxDelay = TimeSpan.FromSeconds(30);
+    private readonly double _factor = 2.0;
+    private readonly double _jitterFraction = 0.2;
+    private readonly int? _maxAttempts;
+
+    /// <summary>
+    /// Master switch. When <c>false</c>, the publisher/consumer SHALL surface connection-fault
+    /// exceptions to the caller without attempting any rebuild.
+    /// </summary>
+    public bool Enabled { get; init; } = true;
+
+    /// <summary>The delay before the second attempt (first retry). Must be greater than zero.</summary>
+    public TimeSpan InitialDelay
+    {
+        get => _initialDelay;
+        init
+        {
+            if (value <= TimeSpan.Zero)
+                throw new ArgumentOutOfRangeException(nameof(InitialDelay), value, "must be greater than zero");
+            _initialDelay = value;
+        }
+    }
+
+    /// <summary>The maximum delay between attempts. Must be greater than or equal to <see cref="InitialDelay"/>.</summary>
+    public TimeSpan MaxDelay
+    {
+        get => _maxDelay;
+        init
+        {
+            if (value <= TimeSpan.Zero)
+                throw new ArgumentOutOfRangeException(nameof(MaxDelay), value, "must be greater than zero");
+            _maxDelay = value;
+        }
+    }
+
+    /// <summary>The geometric backoff multiplier. Must be >= 1.0.</summary>
+    public double Factor
+    {
+        get => _factor;
+        init
+        {
+            if (value < 1.0)
+                throw new ArgumentOutOfRangeException(nameof(Factor), value, "must be greater than or equal to 1.0");
+            _factor = value;
+        }
+    }
+
+    /// <summary>
+    /// The symmetric jitter fraction applied independently to each scheduled delay.
+    /// A value of <c>0.2</c> yields a uniform draw from <c>[delay × 0.8, delay × 1.2]</c>.
+    /// Must be in <c>[0, 1]</c>.
+    /// </summary>
+    public double JitterFraction
+    {
+        get => _jitterFraction;
+        init
+        {
+            if (value < 0.0 || value > 1.0)
+                throw new ArgumentOutOfRangeException(nameof(JitterFraction), value, "must be in [0, 1]");
+            _jitterFraction = value;
+        }
+    }
+
+    /// <summary>
+    /// Maximum number of attempts before giving up and rethrowing the last exception.
+    /// <c>null</c> means unlimited. When non-null, must be greater than zero.
+    /// </summary>
+    public int? MaxAttempts
+    {
+        get => _maxAttempts;
+        init
+        {
+            if (value is not null && value.Value <= 0)
+                throw new ArgumentOutOfRangeException(nameof(MaxAttempts), value, "must be greater than zero (or null for unlimited)");
+            _maxAttempts = value;
+        }
+    }
+
+    /// <summary>
+    /// Validates cross-field invariants (e.g. <c>MaxDelay &gt;= InitialDelay</c>). Per-field
+    /// invariants are enforced at init time; this method catches combinations that the init
+    /// accessors cannot see because object-initializer ordering is undefined. The publisher/consumer
+    /// SHALL call this before entering their rebuild loop.
+    /// </summary>
+    public void Validate()
+    {
+        if (_maxDelay < _initialDelay)
+            throw new ArgumentOutOfRangeException(nameof(MaxDelay), _maxDelay, "must be greater than or equal to InitialDelay");
+    }
+}
diff --git a/src/RayTree.Plugins.Kafka/KafkaConsumer.cs b/src/RayTree.Plugins.Kafka/KafkaConsumer.cs
index 29cc1f0..302ebf7 100644
--- a/src/RayTree.Plugins.Kafka/KafkaConsumer.cs
+++ b/src/RayTree.Plugins.Kafka/KafkaConsumer.cs
@@ -5,16 +5,12 @@
 using Microsoft.Extensions.Logging;
 using RayTree.Core.Models;
 using RayTree.Core.Plugins.Consumer;
-using RayTree.Core.Resilience;
-using RayTree.Core.Telemetry;
 using RayTree.Core.Tracking;
 
 namespace RayTree.Plugins.Kafka;
 
 public class KafkaConsumer : IQueueConsumer, IDisposable
 {
-    private const string ComponentName = "kafka.consumer";
-
     /// <summary>
     /// Discriminator for the post-handler action the poll thread must perform on a
     /// <see cref="ConsumeResult{TKey, TValue}"/> handed back by the subscriber.
@@ -29,13 +25,10 @@ private enum PostHandlerAction
 
     private readonly KafkaConsumerOptions _options;
     private readonly ILogger<KafkaConsumer> _logger;
-    private readonly RayTreeMeter? _meter;
     private readonly CancellationTokenSource _disposeCts = new();
     private IConsumer<string, byte[]>? _consumer;
     private Task? _pollTask;
     private volatile bool _assigned;
-    private volatile bool _connected;
-    private readonly IDisposable? _stateGaugeSubscription;
 
     // When AckAfterHandler = true, the subscriber posts the original ConsumeResult here
     // and the poll thread drains the channel each iteration and calls Commit/Seek on its
@@ -56,20 +49,13 @@ private enum PostHandlerAction
 
     public KafkaConsumer(
         KafkaConsumerOptions options,
-        ILoggerFactory       loggerFactory,
-        RayTreeMeter?        meter = null)
+        ILoggerFactory       loggerFactory)
     {
         _options = options       ?? throw new ArgumentNullException(nameof(options));
         _logger  = (loggerFactory ?? throw new ArgumentNullException(nameof(loggerFactory)))
                        .CreateLogger<KafkaConsumer>();
-        _meter   = meter;
 
         _options.ConnectionRecovery.Validate();
-
-        _stateGaugeSubscription = _meter?.RegisterConnectionStateGauge(
-            component: ComponentName,
-            endpoint:  _options.BootstrapServers,
-            getState:  () => _connected ? 1 : 0);
     }
 
     public async Task InitializeAsync(CancellationToken cancellationToken = default)
@@ -103,7 +89,6 @@ await KafkaTopicProbe.WaitForTopicAsync(
 
         _consumer = new ConsumerBuilder<string, byte[]>(config).Build();
         _consumer.Subscribe(_options.Topic);
-        _connected = true;
     }
 
     /// <summary>
@@ -177,8 +162,6 @@ public async IAsyncEnumerable<MessageEnvelope> ConsumeAsync(
                         // same poll thread. Pending deferred-ack actions reference the dying
                         // consumer and must be dropped — the broker will redeliver via the
                         // standard at-least-once contract once the new consumer joins.
-                        _connected = false;
-                        _meter?.RecordConnectionDisconnect(ComponentName, _options.BootstrapServers);
                         _logger.LogWarning(ex,
                             "Kafka consumer fatal error on topic {Topic}, rebuilding", _options.Topic);
 
@@ -290,12 +273,9 @@ private bool RebuildConsumer(CancellationToken ct)
                 }
 
                 _consumer = BuildConsumer();
-                _connected = true;
 
                 // Clamp at zero — backward NTP clock jump between disconnect and recovery.
                 var duration = Math.Max(0, (DateTime.UtcNow - startedAt).TotalSeconds);
-                _meter?.RecordConnectionRecovery(ComponentName, _options.BootstrapServers,
-                    outcome: "succeeded", duration);
                 _logger.LogInformation(
                     "Kafka consumer rebuilt for topic {Topic} after {AttemptCount} attempt(s) in {Duration:F2}s",
                     _options.Topic, attempt, duration);
@@ -306,9 +286,6 @@ private bool RebuildConsumer(CancellationToken ct)
             {
                 if (recovery.MaxAttempts is int max && attempt >= max)
                 {
-                    var duration = Math.Max(0, (DateTime.UtcNow - startedAt).TotalSeconds);
-                    _meter?.RecordConnectionRecovery(ComponentName, _options.BootstrapServers,
-                        outcome: "exhausted", duration);
                     _logger.LogError(ex,
                         "Kafka consumer rebuild exhausted on topic {Topic} after {AttemptCount} attempts",
                         _options.Topic, attempt);
@@ -332,7 +309,7 @@ private bool RebuildConsumer(CancellationToken ct)
     // the design.md decision "No shared retry helper in Core" for why extracting this
     // would require InternalsVisibleTo to plugin assemblies (architectural smell).
     // Keep the two copies in sync by convention; any change here should be mirrored there.
-    private static TimeSpan ComputeBackoffDelay(ConnectionRecoveryOptions opts, int attemptNum)
+    private static TimeSpan ComputeBackoffDelay(KafkaConnectionRecoveryOptions opts, int attemptNum)
     {
         var baseTicks = opts.InitialDelay.Ticks * Math.Pow(opts.Factor, attemptNum - 1);
         var cappedTicks = Math.Min(baseTicks, opts.MaxDelay.Ticks);
@@ -469,7 +446,6 @@ public void Dispose()
         var waitMs = _options.PollTimeoutMs * 2 + 200;
         _pollTask?.Wait(TimeSpan.FromMilliseconds(waitMs));
 
-        _stateGaugeSubscription?.Dispose();
         _consumer?.Close();
         _consumer?.Dispose();
         _disposeCts.Dispose();
diff --git a/src/RayTree.Plugins.Kafka/KafkaConsumerOptions.cs b/src/RayTree.Plugins.Kafka/KafkaConsumerOptions.cs
index 1345044..c1149d0 100644
--- a/src/RayTree.Plugins.Kafka/KafkaConsumerOptions.cs
+++ b/src/RayTree.Plugins.Kafka/KafkaConsumerOptions.cs
@@ -1,5 +1,3 @@
-using RayTree.Core.Resilience;
-
 namespace RayTree.Plugins.Kafka;
 
 public class KafkaConsumerOptions
@@ -101,9 +99,9 @@ public class KafkaConsumerOptions
     /// re-runs the topic-wait probe (when <see cref="WaitForTopic"/> is set), and re-subscribes.
     /// Pending deferred-ack actions referencing the dying consumer are dropped — the broker
     /// will redeliver via the standard at-least-once contract.
-    /// When <see cref="ConnectionRecoveryOptions.Enabled"/> is <c>false</c>, the poll loop
+    /// When <see cref="KafkaConnectionRecoveryOptions.Enabled"/> is <c>false</c>, the poll loop
     /// surfaces the fatal error to <c>ConsumeAsync</c> callers via channel completion (the
     /// pre-change behaviour).
     /// </summary>
-    public ConnectionRecoveryOptions ConnectionRecovery { get; set; } = new();
+    public KafkaConnectionRecoveryOptions ConnectionRecovery { get; set; } = new();
 }
diff --git a/src/RayTree.Plugins.Kafka/KafkaPublisher.cs b/src/RayTree.Plugins.Kafka/KafkaPublisher.cs
index 052cf73..aef8dd5 100644
--- a/src/RayTree.Plugins.Kafka/KafkaPublisher.cs
+++ b/src/RayTree.Plugins.Kafka/KafkaPublisher.cs
@@ -4,23 +4,18 @@
 using Microsoft.Extensions.Logging.Abstractions;
 using RayTree.Core.Models;
 using RayTree.Core.Plugins.Publisher;
-using RayTree.Core.Telemetry;
 
 namespace RayTree.Plugins.Kafka;
 
 public class KafkaPublisher : IQueuePublisher, IDisposable
 {
-    private const string ComponentName = "kafka.publisher";
-
     private readonly KafkaPublisherOptions _options;
     private readonly ILogger<KafkaPublisher> _logger;
-    private readonly RayTreeMeter? _meter;
     private readonly SemaphoreSlim _buildLock = new(initialCount: 1, maxCount: 1);
-    private readonly IDisposable? _stateGaugeSubscription;
 
-    // volatile so the connection-state gauge callback (foreign thread, no lock) sees the
-    // latest reference rather than a JIT-cached read. Assignments under _buildLock provide
-    // a release barrier; the gauge does a Volatile.Read for the matching acquire.
+    // volatile so the librdkafka error callback (foreign thread, no lock) sees the latest
+    // reference rather than a JIT-cached read. Assignments under _buildLock provide a
+    // release barrier.
     private volatile IProducer<string, byte[]>? _producer;
 
     // 0 means "healthy". Any other value is the UTC ticks of the first fatal error in the
@@ -33,19 +28,12 @@ public class KafkaPublisher : IQueuePublisher, IDisposable
 
     public KafkaPublisher(
         KafkaPublisherOptions options,
-        ILoggerFactory?       loggerFactory = null,
-        RayTreeMeter?         meter         = null)
+        ILoggerFactory?       loggerFactory = null)
     {
         _options = options ?? throw new ArgumentNullException(nameof(options));
         _logger  = (loggerFactory ?? NullLoggerFactory.Instance).CreateLogger<KafkaPublisher>();
-        _meter   = meter;
 
         _options.ConnectionRecovery.Validate();
-
-        _stateGaugeSubscription = _meter?.RegisterConnectionStateGauge(
-            component: ComponentName,
-            endpoint:  _options.BootstrapServers,
-            getState:  () => _producer is not null && Interlocked.Read(ref _faultTicks) == 0 ? 1 : 0);
     }
 
     public Task InitializeAsync(CancellationToken cancellationToken = default)
@@ -93,18 +81,16 @@ await KafkaTopicProbe.WaitForTopicAsync(
                 .SetErrorHandler(OnError)
                 .Build();
 
-            // Emit recovery metric if this build closed a fault cycle. Interlocked.Exchange
-            // clears the flag and reads the original timestamp in one operation, so a
-            // concurrent error handler can't lose the next disconnect event.
+            // Log recovery if this build closed a fault cycle. Interlocked.Exchange clears
+            // the flag and reads the original timestamp in one operation, so a concurrent
+            // error handler can't lose the next disconnect event.
             var faultTicks = Interlocked.Exchange(ref _faultTicks, 0);
             if (faultTicks != 0)
             {
                 // Clamp at 0 to defend against NTP-driven backward clock jumps between the
-                // fault stamp and rebuild — keeps the histogram from recording negatives.
+                // fault stamp and rebuild.
                 var duration = Math.Max(0,
                     (DateTime.UtcNow - new DateTime(faultTicks, DateTimeKind.Utc)).TotalSeconds);
-                _meter?.RecordConnectionRecovery(ComponentName, _options.BootstrapServers,
-                    outcome: "succeeded", duration);
                 _logger.LogInformation(
                     "Kafka producer rebuilt for {BootstrapServers} after {Duration:F2}s",
                     _options.BootstrapServers, duration);
@@ -138,7 +124,7 @@ private ProducerConfig BuildConfig()
 
     /// <summary>
     /// librdkafka error callback. Runs on a foreign thread; does NO locking and NO disposal —
-    /// only atomic flag + metric + log. The real rebuild work happens on the next
+    /// only atomic flag + log. The real rebuild work happens on the next
     /// <see cref="GetProducerAsync"/> call where a normal call thread holds <see cref="_buildLock"/>.
     /// </summary>
     private void OnError(IProducer<string, byte[]> producer, Error error)
@@ -160,11 +146,10 @@ private void OnError(IProducer<string, byte[]> producer, Error error)
             return;
         }
 
-        // First fatal in this cycle: stamp the timestamp and emit the disconnect metric.
+        // First fatal in this cycle: stamp the timestamp and log the disconnect.
         // Subsequent fatals during the same cycle (before rebuild) are no-ops.
         if (Interlocked.CompareExchange(ref _faultTicks, DateTime.UtcNow.Ticks, 0) == 0)
         {
-            _meter?.RecordConnectionDisconnect(ComponentName, _options.BootstrapServers);
             _logger.LogWarning(
                 "Kafka producer fatal error: {Reason} (code={Code}); will rebuild on next publish",
                 error.Reason, error.Code);
@@ -198,7 +183,6 @@ public void Dispose()
         if (_disposed) return;
         _disposed = true;
 
-        _stateGaugeSubscription?.Dispose();
         _producer?.Dispose();
         _buildLock.Dispose();
     }
diff --git a/src/RayTree.Plugins.Kafka/KafkaPublisherOptions.cs b/src/RayTree.Plugins.Kafka/KafkaPublisherOptions.cs
index af5e957..cd2f9aa 100644
--- a/src/RayTree.Plugins.Kafka/KafkaPublisherOptions.cs
+++ b/src/RayTree.Plugins.Kafka/KafkaPublisherOptions.cs
@@ -1,5 +1,4 @@
 using RayTree.Core.Models;
-using RayTree.Core.Resilience;
 
 namespace RayTree.Plugins.Kafka;
 
@@ -77,5 +76,5 @@ public class KafkaPublisherOptions
     /// outer backoff; this property controls whether RayTree participates at all
     /// (<c>Enabled = false</c> surfaces the dead producer to callers without rebuilding).
     /// </summary>
-    public ConnectionRecoveryOptions ConnectionRecovery { get; set; } = new();
+    public KafkaConnectionRecoveryOptions ConnectionRecovery { get; set; } = new();
 }
diff --git a/src/RayTree.Plugins.Kafka/KafkaSubscriberExtensions.cs b/src/RayTree.Plugins.Kafka/KafkaSubscriberExtensions.cs
index b5dd411..cc05c8f 100644
--- a/src/RayTree.Plugins.Kafka/KafkaSubscriberExtensions.cs
+++ b/src/RayTree.Plugins.Kafka/KafkaSubscriberExtensions.cs
@@ -1,7 +1,6 @@
 using Microsoft.Extensions.Logging;
 using Microsoft.Extensions.Logging.Abstractions;
 using RayTree.Core.Handling;
-using RayTree.Core.Telemetry;
 
 namespace RayTree.Plugins.Kafka;
 
@@ -16,15 +15,10 @@ public static class KafkaSubscriberExtensions
     /// silences the topic-wait probe logs. Supply a real logger factory when using
     /// <c>WaitForTopic = true</c> so operators can observe startup progress.
     /// </param>
-    /// <param name="meter">
-    /// Optional. When supplied, the consumer emits <c>raytree.connection.*</c> metrics on
-    /// fatal-error rebuilds. Pass the same <c>RayTreeMeter</c> the rest of the tracker uses.
-    /// </param>
     public static IEntitySubscriberBuilder<TEntity> UseKafka<TEntity>(
         this IEntitySubscriberBuilder<TEntity> builder,
         Action<KafkaConsumerOptions> configure,
-        ILoggerFactory? loggerFactory = null,
-        RayTreeMeter? meter = null)
+        ILoggerFactory? loggerFactory = null)
         where TEntity : class
     {
         ArgumentNullException.ThrowIfNull(builder);
@@ -32,7 +26,7 @@ public static IEntitySubscriberBuilder<TEntity> UseKafka<TEntity>(
 
         var options = new KafkaConsumerOptions();
         configure(options);
-        return builder.UseConsumer(new KafkaConsumer(options, loggerFactory ?? NullLoggerFactory.Instance, meter));
+        return builder.UseConsumer(new KafkaConsumer(options, loggerFactory ?? NullLoggerFactory.Instance));
     }
 
     public static KafkaConsumerOptions WithTopic(this KafkaConsumerOptions options, string topic)
diff --git a/src/RayTree.Plugins.Kafka/README.md b/src/RayTree.Plugins.Kafka/README.md
index 9e7d327..c106802 100644
--- a/src/RayTree.Plugins.Kafka/README.md
+++ b/src/RayTree.Plugins.Kafka/README.md
@@ -357,8 +357,8 @@ The original `ConsumeResult` is broker-private state — `ChangeSubscriber` shou
 | Situation | Behaviour |
 |---|---|
 | `ParseEnvelope` throws (malformed message) | `Commit(result)` immediately, regardless of `AckAfterHandler`. Logged at `Warning`. Parse errors are not transient — committing past them prevents a poison-pill from blocking the partition |
-| `KafkaException` with `Error.IsFatal` on consumer poll thread | `KafkaConsumer` emits `raytree.connection.disconnects{component="kafka.consumer"}`, logs `Warning`, drops pending deferred-ack actions referencing the dying consumer, disposes it, and runs an inline exponential-backoff `RebuildConsumer` on the same poll thread (re-runs `WaitForTopic` probe when enabled). On success emits `raytree.connection.recoveries{outcome="succeeded"}` + duration and resumes polling. On `MaxAttempts` exhaustion (or `ConnectionRecovery.Enabled = false`) completes the buffer channel with the original exception. The broker redelivers via at-least-once semantics on the new consumer's join. |
-| `KafkaException` with `Error.IsFatal` on publisher | The producer's error handler stamps a fault timestamp (atomic) and emits `raytree.connection.disconnects{component="kafka.publisher"}`. The next `PublishAsync` rebuilds the producer via the existing lazy `GetProducerAsync` path under `_buildLock` — disposes the dead producer on a normal call thread (not the librdkafka callback thread), re-runs the `WaitForTopic` probe, and emits `raytree.connection.recoveries{outcome="succeeded"}` + duration. No inner backoff: the outbox-publisher retry loop provides the outer cadence. Set `ConnectionRecovery.Enabled = false` to surface the dead producer to callers instead of rebuilding. |
+| `KafkaException` with `Error.IsFatal` on consumer poll thread | `KafkaConsumer` logs `Warning`, drops pending deferred-ack actions referencing the dying consumer, disposes it, and runs an inline exponential-backoff `RebuildConsumer` on the same poll thread (re-runs `WaitForTopic` probe when enabled), bounded by `KafkaConsumerOptions.ConnectionRecovery` (a `KafkaConnectionRecoveryOptions`). On success logs `Information` (with duration) and resumes polling. On `MaxAttempts` exhaustion (or `ConnectionRecovery.Enabled = false`) logs `Error` and completes the buffer channel with the original exception. The broker redelivers via at-least-once semantics on the new consumer's join. |
+| `KafkaException` with `Error.IsFatal` on publisher | The producer's error handler stamps a fault timestamp (atomic) and logs `Warning`. The next `PublishAsync` rebuilds the producer via the existing lazy `GetProducerAsync` path under `_buildLock` — disposes the dead producer on a normal call thread (not the librdkafka callback thread), re-runs the `WaitForTopic` probe, and logs `Information` (with duration). No inner backoff: the outbox-publisher retry loop provides the outer cadence. Set `ConnectionRecovery.Enabled = false` to surface the dead producer to callers instead of rebuilding. |
 | Non-fatal `Exception` during `Consume()` | Logged at `Warning`, loop continues |
 | Deferred `Commit` / `Seek` throws | Logged at `Warning` with the offset and action. The poll loop continues so one bad commit doesn't abort the whole consumer |
 | `KafkaConsumer.Dispose` | Cancels `_disposeCts`; waits up to `2 × PollTimeoutMs + 200ms` for the poll thread to exit before freeing the native librdkafka handle (prevents `AccessViolationException`); a final drain flushes any pending Commits/Seeks that arrived during shutdown |
diff --git a/src/RayTree.Plugins.PostgreSQL/Outbox/Notification/NotificationBasedPublisher.cs b/src/RayTree.Plugins.PostgreSQL/Outbox/Notification/NotificationBasedPublisher.cs
index 6344a5e..b12df44 100644
--- a/src/RayTree.Plugins.PostgreSQL/Outbox/Notification/NotificationBasedPublisher.cs
+++ b/src/RayTree.Plugins.PostgreSQL/Outbox/Notification/NotificationBasedPublisher.cs
@@ -11,10 +11,10 @@
 using RayTree.Core.Plugins.Outbox;
 using RayTree.Core.Plugins.Publisher;
 using RayTree.Core.Plugins.Serialization;
-using RayTree.Core.Resilience;
 using RayTree.Core.Telemetry;
 using RayTree.Core.Tracking;
 using RayTree.Plugins.PostgreSQL.Internal;
+using RayTree.Plugins.PostgreSQL.Resilience;
 
 namespace RayTree.Plugins.PostgreSQL.Outbox.Notification;
 
@@ -30,7 +30,6 @@ public class NotificationBasedPublisher : IDisposable
     private Task? _fallbackTask;
     private volatile bool _listenerHealthy;
     private bool _firstFallbackPoll = true;
-    private IDisposable? _stateGaugeSubscription;
 
     // Per-outbox transition state for the fallback polling loop. Keyed by entity type;
     // the value's unhealthy flag flips on the first connection-fault for that outbox and
@@ -65,13 +64,6 @@ public NotificationBasedPublisher(
         // Validate the recovery options eagerly so misconfiguration fails at construction,
         // not on the first disconnect.
         _options.ConnectionRecovery.Validate();
-
-        // Register the connection-state gauge keyed on the LISTEN channel. The closure
-        // captures _listenerHealthy so OTel collection sees the live value.
-        _stateGaugeSubscription = _meter.RegisterConnectionStateGauge(
-            component: ComponentName,
-            endpoint:  _options.ChannelName,
-            getState:  () => _listenerHealthy ? 1 : 0);
     }
 
     public bool IsRunning => _listenTask != null && !_listenTask.IsCompleted;
@@ -104,8 +96,8 @@ public async Task StopAsync(CancellationToken cancellationToken = default)
     /// <summary>
     /// The full LISTEN lifecycle in one loop. Each iteration opens a fresh connection,
     /// issues <c>LISTEN</c>, and waits on notifications until the connection breaks or
-    /// the loop is cancelled. On a classified connection fault the loop emits one
-    /// disconnect metric per cycle, backs off, and tries again — bounded by
+    /// the loop is cancelled. On a classified connection fault the loop logs one
+    /// warning per cycle, backs off, and tries again — bounded by
     /// <c>_options.ConnectionRecovery.MaxAttempts</c>. Non-connection exceptions propagate
     /// out of the loop and surface to the caller of <see cref="StartAsync"/>.
     /// </summary>
@@ -125,11 +117,10 @@ private async Task ListenLoopAsync(CancellationToken ct)
                 await using (var listen = new NpgsqlCommand($"LISTEN {_options.ChannelName}", conn))
                     await listen.ExecuteNonQueryAsync(ct);
 
-                // Successful (re)connect. Emit recovery if we were in a fault cycle.
+                // Successful (re)connect. Log recovery if we were in a fault cycle.
                 if (cycleStartedAt is { } start)
                 {
                     var duration = Math.Max(0, (DateTime.UtcNow - start).TotalSeconds);
-                    _meter.RecordConnectionRecovery(ComponentName, _options.ChannelName, outcome: "succeeded", duration);
                     _logger.LogInformation(
                         "PostgreSQL LISTEN connection on {ChannelName} reconnected after {AttemptCount} attempt(s) in {Duration:F2}s",
                         _options.ChannelName, attemptInCycle + 1, duration);
@@ -146,12 +137,11 @@ private async Task ListenLoopAsync(CancellationToken ct)
             catch (OperationCanceledException) { return; }
             catch (Exception ex) when (IsConnectionFault(ex))
             {
-                // First detection in this cycle: flip state and emit disconnect metric.
+                // First detection in this cycle: flip state and log the disconnect.
                 if (cycleStartedAt is null)
                 {
                     cycleStartedAt   = DateTime.UtcNow;
                     _listenerHealthy = false;
-                    _meter.RecordConnectionDisconnect(ComponentName, _options.ChannelName);
                     _logger.LogWarning(ex,
                         "PostgreSQL LISTEN connection on {ChannelName} lost, reconnecting",
                         _options.ChannelName);
@@ -162,8 +152,6 @@ private async Task ListenLoopAsync(CancellationToken ct)
                 attemptInCycle++;
                 if (_options.ConnectionRecovery.MaxAttempts is int max && attemptInCycle >= max)
                 {
-                    var duration = Math.Max(0, (DateTime.UtcNow - cycleStartedAt.Value).TotalSeconds);
-                    _meter.RecordConnectionRecovery(ComponentName, _options.ChannelName, outcome: "exhausted", duration);
                     _logger.LogError(ex,
                         "PostgreSQL LISTEN reconnect exhausted on {ChannelName} after {AttemptCount} attempts",
                         _options.ChannelName, attemptInCycle);
@@ -185,7 +173,7 @@ private async Task ListenLoopAsync(CancellationToken ct)
     // retry helper in Core" for why extracting this would require InternalsVisibleTo
     // to plugin assemblies (architectural smell). Keep the two copies in sync by
     // convention; any change here should be mirrored there.
-    private static TimeSpan ComputeBackoffDelay(ConnectionRecoveryOptions opts, int attemptNum)
+    private static TimeSpan ComputeBackoffDelay(PostgresConnectionRecoveryOptions opts, int attemptNum)
     {
         var baseTicks = opts.InitialDelay.Ticks * Math.Pow(opts.Factor, attemptNum - 1);
         var cappedTicks = Math.Min(baseTicks, opts.MaxDelay.Ticks);
@@ -400,7 +388,6 @@ await Parallel.ForEachAsync(changes,
                 // Clamp at zero — backward NTP-driven clock jumps would otherwise feed a
                 // negative value into the duration histogram.
                 var duration = Math.Max(0, (DateTime.UtcNow - state.FirstFailureAt).TotalSeconds);
-                _meter.RecordConnectionRecovery(component, endpoint, outcome: "succeeded", duration);
                 _logger.LogInformation(
                     "Outbox connection recovered for {EntityType} ({Component} at {Endpoint}) after {Duration:F2}s",
                     entityType.Name, component, endpoint, duration);
@@ -412,18 +399,15 @@ await Parallel.ForEachAsync(changes,
         {
             // Classify all per-outbox errors HERE so the structured log entries are uniform
             // and the outer FallbackPollingLoopAsync catch only sees infrastructure-level
-            // issues (Task.Delay failures, etc.). Connection-faults emit the disconnect
-            // metric + Warning; everything else logs Error with the entity-type context.
+            // issues (Task.Delay failures, etc.). Connection-faults log a Warning;
+            // everything else logs Error with the entity-type context.
             if (outbox.IsConnectionFault(ex) && outbox.ConnectionComponent is { } component)
             {
                 var endpoint = outbox.ConnectionEndpoint ?? "<unknown>";
                 var state = _fallbackOutboxState.GetOrAdd(entityType,
                     _ => new FallbackOutboxState(Unhealthy: false, FirstFailureAt: DateTime.MinValue));
                 if (!state.Unhealthy)
-                {
                     _fallbackOutboxState[entityType] = new FallbackOutboxState(Unhealthy: true, FirstFailureAt: DateTime.UtcNow);
-                    _meter.RecordConnectionDisconnect(component, endpoint);
-                }
                 _logger.LogWarning(ex,
                     "Outbox connection fault for {EntityType} ({Component} at {Endpoint}); fallback polling will retry",
                     entityType.Name, component, endpoint);
@@ -495,7 +479,6 @@ public static string GenerateDropTrigger(string triggerName, string outboxTableN
     public void Dispose()
     {
         StopAsync().GetAwaiter().GetResult();
-        _stateGaugeSubscription?.Dispose();
         _cts.Dispose();
         _notificationSemaphore.Dispose();
     }
diff --git a/src/RayTree.Plugins.PostgreSQL/Outbox/Notification/NotificationBasedPublisherOptions.cs b/src/RayTree.Plugins.PostgreSQL/Outbox/Notification/NotificationBasedPublisherOptions.cs
index fce91e7..d9192c0 100644
--- a/src/RayTree.Plugins.PostgreSQL/Outbox/Notification/NotificationBasedPublisherOptions.cs
+++ b/src/RayTree.Plugins.PostgreSQL/Outbox/Notification/NotificationBasedPublisherOptions.cs
@@ -1,4 +1,4 @@
-using RayTree.Core.Resilience;
+using RayTree.Plugins.PostgreSQL.Resilience;
 
 namespace RayTree.Plugins.PostgreSQL.Outbox.Notification;
 
@@ -19,9 +19,9 @@ public class NotificationBasedPublisherOptions
     /// <summary>
     /// Tunes the LISTEN-connection reconnect policy. The publisher detects a connection fault
     /// via <see cref="ListenLoopAsync"/>'s catch block, then runs an inline exponential-backoff
-    /// loop bounded by these options. When <see cref="ConnectionRecoveryOptions.Enabled"/> is
+    /// loop bounded by these options. When <see cref="PostgresConnectionRecoveryOptions.Enabled"/> is
     /// <c>false</c>, the loop exits on the first failure and recovery falls entirely to the
     /// fallback polling path.
     /// </summary>
-    public ConnectionRecoveryOptions ConnectionRecovery { get; set; } = new();
+    public PostgresConnectionRecoveryOptions ConnectionRecovery { get; set; } = new();
 }
diff --git a/src/RayTree.Plugins.PostgreSQL/README.md b/src/RayTree.Plugins.PostgreSQL/README.md
index a4dac91..f63bb53 100644
--- a/src/RayTree.Plugins.PostgreSQL/README.md
+++ b/src/RayTree.Plugins.PostgreSQL/README.md
@@ -99,10 +99,10 @@ A single long-lived `NpgsqlConnection`. When `WaitAsync` throws an exception cla
 internal `PostgresFault` helper (transient `NpgsqlException`, `SocketException` / `IOException`
 inner, `08xxx` / `57P0x` SQL state, or `ObjectDisposedException`), the loop:
 
-1. Emits `raytree.connection.disconnects{component="postgres.notification", endpoint={ChannelName}}` once per fault cycle, logs `Warning`.
-2. Runs an inline exponential-backoff loop bounded by `NotificationBasedPublisherOptions.ConnectionRecovery` — disposes the broken connection, opens a fresh one, re-attaches the `Notification` handler, re-issues `LISTEN`.
-3. On success emits `raytree.connection.recoveries{outcome="succeeded"}` + duration, flips `_listenerHealthy = true` on the next `WaitAsync` wake.
-4. On `MaxAttempts` exhaustion emits `raytree.connection.recoveries{outcome="exhausted"}` and exits the LISTEN loop (fallback polling continues).
+1. Logs a `Warning` once per fault cycle.
+2. Runs an inline exponential-backoff loop bounded by `NotificationBasedPublisherOptions.ConnectionRecovery` (a `PostgresConnectionRecoveryOptions`) — disposes the broken connection, opens a fresh one, re-attaches the `Notification` handler, re-issues `LISTEN`.
+3. On success logs `Information` (with reconnect duration), flips `_listenerHealthy = true` on the next `WaitAsync` wake.
+4. On `MaxAttempts` exhaustion logs `Error` and exits the LISTEN loop (fallback polling continues).
 
 The fallback polling loop continues running throughout, providing best-effort delivery during the
 reconnect window. `TryClaimForPublishingAsync` prevents double-publish races between the two paths.
@@ -114,9 +114,8 @@ handles transient TCP errors, and the polling cadence is the retry. Instead, the
 classify each batch failure via `IOutbox.IsConnectionFault` (which `PostgreSqlOutbox` overrides
 to delegate to `PostgresFault`) and:
 
-- Emit `raytree.connection.disconnects{component="postgres.outbox"}` once per transition.
 - Demote the per-batch `Error` log to `Warning` so a transient Postgres blip looks like one fault cycle.
-- On the first subsequent successful batch, emit `raytree.connection.recoveries{outcome="succeeded"}` + duration.
+- On the first subsequent successful batch, log an `Information` "outbox connection recovered" entry (with duration).
 
 Non-connection-fault exceptions (e.g. unique-violation `23505`, syntax errors) bypass this path
 entirely — they still log at `Error` and surface to operators as application bugs.
@@ -135,7 +134,7 @@ write-side retry.
 | `PostgreSqlOutboxOptions.UseNotificationChannel` | `false` | Enable NOTIFY trigger |
 | `PostgreSqlOutboxOptions.NotificationChannel` | `null` | Channel name for NOTIFY |
 | `PostgreSqlOutboxOptions.FallbackPollingInterval` | `null` | Polling interval when LISTEN is down |
-| `NotificationBasedPublisherOptions.ConnectionRecovery` | `new()` (Enabled, 1s→30s, ×2, ±20% jitter, unlimited) | Tunes LISTEN reconnect backoff. Set `Enabled = false` to skip reconnect and rely on fallback polling only. |
+| `NotificationBasedPublisherOptions.ConnectionRecovery` | `new PostgresConnectionRecoveryOptions()` (Enabled, 1s→30s, ×2, ±20% jitter, unlimited) | Tunes LISTEN reconnect backoff. Set `Enabled = false` to skip reconnect and rely on fallback polling only. |
 | `PostgreSqlOutboxOptions.CleanupBatchSize` | `1000` | Rows per cleanup batch |
 | `PostgreSqlRepositoryOptions.ConnectionString` | `""` | PostgreSQL connection string |
 | `PostgreSqlRepositoryOptions.TableName` | `"{entity}_source"` | Source table name |
diff --git a/src/RayTree.Core/Resilience/ConnectionRecoveryOptions.cs b/src/RayTree.Plugins.PostgreSQL/Resilience/PostgresConnectionRecoveryOptions.cs
similarity index 82%
rename from src/RayTree.Core/Resilience/ConnectionRecoveryOptions.cs
rename to src/RayTree.Plugins.PostgreSQL/Resilience/PostgresConnectionRecoveryOptions.cs
index c8439b6..331b839 100644
--- a/src/RayTree.Core/Resilience/ConnectionRecoveryOptions.cs
+++ b/src/RayTree.Plugins.PostgreSQL/Resilience/PostgresConnectionRecoveryOptions.cs
@@ -1,21 +1,20 @@
-namespace RayTree.Core.Resilience;
+namespace RayTree.Plugins.PostgreSQL.Resilience;
 
 /// <summary>
-/// Tunes the connection-recovery retry shape for plugins that own their own reconnect loop
-/// (Postgres LISTEN, Kafka fatal-error rebuild). The values describe an exponential-backoff
-/// schedule: the Nth retry waits <c>min(InitialDelay × Factor^(N-1), MaxDelay)</c> seconds,
-/// jittered by <c>±JitterFraction</c>. RabbitMQ does not consume these options — the
-/// RabbitMQ.Client SDK owns its own recovery policy.
+/// Tunes the connection-recovery retry shape for the PostgreSQL LISTEN reconnect loop owned by
+/// <c>NotificationBasedPublisher</c>. The values describe an exponential-backoff schedule: the Nth
+/// retry waits <c>min(InitialDelay × Factor^(N-1), MaxDelay)</c> seconds, jittered by
+/// <c>±JitterFraction</c>.
 /// <para>
 /// <b>Validation timing:</b> per-field invariants (positive delays, factor &gt;= 1, jitter
 /// in [0, 1], positive MaxAttempts) are enforced at init time — they throw from object
 /// initializers before construction completes. Cross-field invariants
 /// (<c>MaxDelay &gt;= InitialDelay</c>) cannot be checked at init time because
 /// object-initializer assignment order is undefined; they're checked by <see cref="Validate"/>,
-/// which plugins call on first use before entering their retry loop.
+/// which the publisher calls on first use before entering its reconnect loop.
 /// </para>
 /// </summary>
-public sealed class ConnectionRecoveryOptions
+public sealed class PostgresConnectionRecoveryOptions
 {
     private readonly TimeSpan _initialDelay = TimeSpan.FromSeconds(1);
     private readonly TimeSpan _maxDelay = TimeSpan.FromSeconds(30);
@@ -24,7 +23,7 @@ public sealed class ConnectionRecoveryOptions
     private readonly int? _maxAttempts;
 
     /// <summary>
-    /// Master switch. When <c>false</c>, plugins SHALL surface connection-fault exceptions
+    /// Master switch. When <c>false</c>, the publisher SHALL surface connection-fault exceptions
     /// to the caller without attempting any reconnect.
     /// </summary>
     public bool Enabled { get; init; } = true;
@@ -99,8 +98,8 @@ public int? MaxAttempts
     /// <summary>
     /// Validates cross-field invariants (e.g. <c>MaxDelay &gt;= InitialDelay</c>). Per-field
     /// invariants are enforced at init time; this method catches combinations that the init
-    /// accessors cannot see because object-initializer ordering is undefined. Plugins SHALL
-    /// call this before entering their retry loop.
+    /// accessors cannot see because object-initializer ordering is undefined. The publisher SHALL
+    /// call this before entering its reconnect loop.
     /// </summary>
     public void Validate()
     {
diff --git a/src/RayTree.Plugins.RabbitMQ/README.md b/src/RayTree.Plugins.RabbitMQ/README.md
index ffc3778..d59fdf7 100644
--- a/src/RayTree.Plugins.RabbitMQ/README.md
+++ b/src/RayTree.Plugins.RabbitMQ/README.md
@@ -319,7 +319,7 @@ The delivery tag is broker-private state — `ChangeSubscriber` shouldn't know a
 | Situation | Behaviour |
 |---|---|
 | `ParseEnvelope` throws (malformed message) | `BasicNack(requeue: true)` — broker requeues; **no log** (acknowledged exception to the project's logging-placement rule: no useful context is available inside the RabbitMQ delivery callback, and NACK/requeue is the only correct recovery) |
-| Broker connection drops | `RabbitMQ.Client.AutomaticRecoveryEnabled` (library default — RayTree does **not** disable it) transparently rebuilds the connection, channel, topology, and consumer registration. RayTree subscribes to the SDK's `ConnectionShutdownAsync` / `RecoverySucceededAsync` events to emit `raytree.connection.disconnects` / `raytree.connection.recoveries` metrics keyed on `component = "rabbitmq.publisher"` or `"rabbitmq.consumer"`. The library's `NetworkRecoveryInterval` controls retry timing; RayTree's `ConnectionRecoveryOptions` is not consumed by the RabbitMQ plugin. Unacknowledged messages are returned to the queue automatically per AMQP semantics. |
+| Broker connection drops | `RabbitMQ.Client.AutomaticRecoveryEnabled` (library default — RayTree does **not** disable it) transparently rebuilds the connection, channel, topology, and consumer registration. The publisher subscribes to the SDK's `ConnectionShutdownAsync` / `RecoverySucceededAsync` events to log a `Warning` on shutdown and `Information` (with duration) on recovery; the consumer has no logger and is silent for recovery. No connection metrics are emitted. The library's `NetworkRecoveryInterval` controls retry timing; RabbitMQ has no RayTree recovery options. Unacknowledged messages are returned to the queue automatically per AMQP semantics. |
 | `RabbitMqConsumer.Dispose` | Closes channel + connection synchronously; any in-flight unacked deliveries are requeued by the broker |
 
 ### Tuning notes
diff --git a/src/RayTree.Plugins.RabbitMQ/RabbitMqBuilderExtensions.cs b/src/RayTree.Plugins.RabbitMQ/RabbitMqBuilderExtensions.cs
index 1cec772..48b75fe 100644
--- a/src/RayTree.Plugins.RabbitMQ/RabbitMqBuilderExtensions.cs
+++ b/src/RayTree.Plugins.RabbitMQ/RabbitMqBuilderExtensions.cs
@@ -1,30 +1,22 @@
 using Microsoft.Extensions.Logging;
 using RayTree.Core.Plugins.Publisher;
-using RayTree.Core.Telemetry;
 using RayTree.Core.Tracking;
 
 namespace RayTree.Plugins.RabbitMQ;
 
 public static class RabbitMqBuilderExtensions
 {
-    /// <param name="meter">
-    /// Optional. When supplied, the publisher emits <c>raytree.connection.*</c> metrics on
-    /// the SDK's <c>ConnectionShutdownAsync</c> / <c>RecoverySucceededAsync</c> events. No
-    /// recovery code is added — the RabbitMQ.Client library's <c>AutomaticRecoveryEnabled</c>
-    /// owns the rebuild; we only observe.
-    /// </param>
     public static IChangeTrackingBuilder UseRabbitMq(
         this IChangeTrackingBuilder builder,
         Action<RabbitMqPublisherOptions> configure,
-        ILoggerFactory? loggerFactory = null,
-        RayTreeMeter? meter = null)
+        ILoggerFactory? loggerFactory = null)
     {
         ArgumentNullException.ThrowIfNull(builder);
         ArgumentNullException.ThrowIfNull(configure);
 
         var options = new RabbitMqPublisherOptions();
         configure(options);
-        return builder.UsePublisher<IQueuePublisher>(_ => new RabbitMqPublisher(options, loggerFactory, meter));
+        return builder.UsePublisher<IQueuePublisher>(_ => new RabbitMqPublisher(options, loggerFactory));
     }
 
     public static RabbitMqPublisherOptions WithExchange(
diff --git a/src/RayTree.Plugins.RabbitMQ/RabbitMqConsumer.cs b/src/RayTree.Plugins.RabbitMQ/RabbitMqConsumer.cs
index 432fd3f..83656c6 100644
--- a/src/RayTree.Plugins.RabbitMQ/RabbitMqConsumer.cs
+++ b/src/RayTree.Plugins.RabbitMQ/RabbitMqConsumer.cs
@@ -4,41 +4,22 @@
 using RabbitMQ.Client.Events;
 using RayTree.Core.Models;
 using RayTree.Core.Plugins.Consumer;
-using RayTree.Core.Telemetry;
 using RayTree.Core.Tracking;
 
 namespace RayTree.Plugins.RabbitMQ;
 
 public class RabbitMqConsumer : IQueueConsumer, IDisposable
 {
-    private const string ComponentName = "rabbitmq.consumer";
-
     private readonly RabbitMqConsumerOptions _options;
-    private readonly RayTreeMeter? _meter;
-    private readonly string _endpoint;
 
     private IConnection? _connection;
     private IChannel? _channel;
 
     private readonly Channel<MessageEnvelope> _buffer = Channel.CreateUnbounded<MessageEnvelope>();
 
-    // Connection state for the gauge — true while a healthy channel is bound. Owned by
-    // the SDK's recovery events (we do NOT implement recovery here).
-    private volatile bool _connected;
-    private volatile bool _disposing;
-    private DateTime _lastShutdownAt = DateTime.MinValue;
-    private readonly IDisposable? _stateGaugeSubscription;
-
-    public RabbitMqConsumer(RabbitMqConsumerOptions options, RayTreeMeter? meter = null)
+    public RabbitMqConsumer(RabbitMqConsumerOptions options)
     {
         _options = options ?? throw new ArgumentNullException(nameof(options));
-        _meter   = meter;
-        _endpoint = $"{_options.HostName}:{_options.Port}";
-
-        _stateGaugeSubscription = _meter?.RegisterConnectionStateGauge(
-            component: ComponentName,
-            endpoint:  _endpoint,
-            getState:  () => _connected ? 1 : 0);
     }
 
     public async Task InitializeAsync(CancellationToken cancellationToken = default)
@@ -53,12 +34,6 @@ public async Task InitializeAsync(CancellationToken cancellationToken = default)
 
         _connection = await factory.CreateConnectionAsync(cancellationToken);
 
-        // Subscribe to SDK recovery events for metric observability. No log output here:
-        // RabbitMqConsumer intentionally has no logger (the documented exception to the
-        // logging-placement rule). The metrics still record disconnect / recovery cycles.
-        _connection.ConnectionShutdownAsync += OnConnectionShutdownAsync;
-        _connection.RecoverySucceededAsync  += OnRecoverySucceededAsync;
-
         try
         {
             // No logger is passed to the probe: RabbitMqConsumer intentionally has no logger
@@ -123,8 +98,6 @@ await _channel.BasicConsumeAsync(
                 consumer: consumer,
                 cancellationToken: cancellationToken
             );
-
-            _connected = true;
         }
         catch
         {
@@ -133,34 +106,6 @@ await _channel.BasicConsumeAsync(
         }
     }
 
-    private Task OnConnectionShutdownAsync(object sender, ShutdownEventArgs e)
-    {
-        // Suppress when shutdown is part of our own teardown — same race-guard pattern
-        // as the publisher (broker may already be dead when Dispose() runs, in which case
-        // the SDK reports the shutdown with Initiator=Library, not Application).
-        if (e.Initiator == ShutdownInitiator.Application || _disposing)
-            return Task.CompletedTask;
-
-        _connected      = false;
-        _lastShutdownAt = DateTime.UtcNow;
-        _meter?.RecordConnectionDisconnect(ComponentName, _endpoint);
-        // No logger — silent in logs by design; metric tells the story.
-        return Task.CompletedTask;
-    }
-
-    private Task OnRecoverySucceededAsync(object sender, AsyncEventArgs e)
-    {
-        // Clamp at zero — backward NTP-driven clock jumps would otherwise feed a negative
-        // value into the duration histogram.
-        var duration = _lastShutdownAt == DateTime.MinValue
-            ? 0
-            : Math.Max(0, (DateTime.UtcNow - _lastShutdownAt).TotalSeconds);
-        _connected      = true;
-        _lastShutdownAt = DateTime.MinValue;
-        _meter?.RecordConnectionRecovery(ComponentName, _endpoint, outcome: "succeeded", duration);
-        return Task.CompletedTask;
-    }
-
     private async Task CleanupAfterFailedInitAsync()
     {
         if (_channel is not null)
@@ -274,15 +219,6 @@ private static string GetHeader(IDictionary<string, object?> headers, string key
 
     public void Dispose()
     {
-        // Mark before detaching / closing so a non-Application shutdown surfaced during
-        // close (broker already dead) is suppressed by the handler's _disposing guard.
-        _disposing = true;
-        if (_connection is not null)
-        {
-            _connection.ConnectionShutdownAsync -= OnConnectionShutdownAsync;
-            _connection.RecoverySucceededAsync  -= OnRecoverySucceededAsync;
-        }
-        _stateGaugeSubscription?.Dispose();
         _buffer.Writer.TryComplete();
         try { _channel?.CloseAsync().GetAwaiter().GetResult();    } catch { /* may already be closed */ }
         try { _connection?.CloseAsync().GetAwaiter().GetResult(); } catch { /* may already be closed */ }
diff --git a/src/RayTree.Plugins.RabbitMQ/RabbitMqPublisher.cs b/src/RayTree.Plugins.RabbitMQ/RabbitMqPublisher.cs
index 1798b01..eb31505 100644
--- a/src/RayTree.Plugins.RabbitMQ/RabbitMqPublisher.cs
+++ b/src/RayTree.Plugins.RabbitMQ/RabbitMqPublisher.cs
@@ -4,49 +4,35 @@
 using RabbitMQ.Client.Events;
 using RayTree.Core.Models;
 using RayTree.Core.Plugins.Publisher;
-using RayTree.Core.Telemetry;
 
 namespace RayTree.Plugins.RabbitMQ;
 
 public class RabbitMqPublisher : IQueuePublisher, IDisposable
 {
-    private const string ComponentName = "rabbitmq.publisher";
-
     private readonly RabbitMqPublisherOptions _options;
     private readonly ILogger<RabbitMqPublisher> _logger;
-    private readonly RayTreeMeter? _meter;
     private readonly string _endpoint;
     private IConnection? _connection;
     private IChannel? _channel;
 
     private readonly SemaphoreSlim _semaphore = new(initialCount: 1, maxCount: 1);
 
-    // Connection state for the connection.state gauge. Set to true once GetChannelAsync
-    // returns a healthy channel; flipped by the SDK's ConnectionShutdownAsync /
-    // RecoverySucceededAsync events. RabbitMQ.Client owns the actual recovery (we have
-    // AutomaticRecoveryEnabled = true by default); we only observe.
-    private volatile bool _connected;
+    // Timestamp of the last non-Application shutdown, used to compute the recovery
+    // duration printed in the recovery log. RabbitMQ.Client owns the actual recovery
+    // (AutomaticRecoveryEnabled = true by default); we only observe via logs.
     private DateTime _lastShutdownAt = DateTime.MinValue;
-    private readonly IDisposable? _stateGaugeSubscription;
     // Set true from Dispose() before initiating CloseAsync so the shutdown handler can
-    // suppress spurious disconnect metrics even if the SDK reports the shutdown with
+    // suppress spurious disconnect logs even if the SDK reports the shutdown with
     // Initiator=Library (e.g. broker already dead when Dispose ran).
     private volatile bool _disposing;
 
     public RabbitMqPublisher(
         RabbitMqPublisherOptions options,
-        ILoggerFactory?          loggerFactory = null,
-        RayTreeMeter?            meter         = null)
+        ILoggerFactory?          loggerFactory = null)
     {
         _options = options ?? throw new ArgumentNullException(nameof(options));
         _logger  = (loggerFactory ?? NullLoggerFactory.Instance).CreateLogger<RabbitMqPublisher>();
-        _meter   = meter;
         _endpoint = $"{_options.HostName}:{_options.Port}";
-
-        _stateGaugeSubscription = _meter?.RegisterConnectionStateGauge(
-            component: ComponentName,
-            endpoint:  _endpoint,
-            getState:  () => _connected ? 1 : 0);
     }
 
     public async Task InitializeAsync(CancellationToken cancellationToken = default)
@@ -76,9 +62,9 @@ private async Task<IChannel> GetChannelAsync(CancellationToken cancellationToken
 
             _connection = await factory.CreateConnectionAsync(cancellationToken: cancellationToken);
 
-            // Hook SDK recovery events for metric/log observability. RabbitMQ.Client owns
-            // the actual recovery via AutomaticRecoveryEnabled = true (library default);
-            // we only emit raytree.connection.* on the transitions.
+            // Hook SDK recovery events for log observability. RabbitMQ.Client owns the
+            // actual recovery via AutomaticRecoveryEnabled = true (library default); we
+            // only emit Warning/Information logs on the transitions.
             _connection.ConnectionShutdownAsync       += OnConnectionShutdownAsync;
             _connection.RecoverySucceededAsync        += OnRecoverySucceededAsync;
             _connection.ConnectionRecoveryErrorAsync  += OnConnectionRecoveryErrorAsync;
@@ -106,7 +92,6 @@ await _channel.ExchangeDeclareAsync(
                         cancellationToken: cancellationToken
                     );
 
-                _connected = true;
                 return _channel;
             }
             catch
@@ -169,16 +154,14 @@ private async Task CleanupAfterFailedInitAsync()
 
     private Task OnConnectionShutdownAsync(object sender, ShutdownEventArgs e)
     {
-        // Suppress metric + log when shutdown is part of our own teardown — either because
+        // Suppress the log when shutdown is part of our own teardown — either because
         // the SDK reports the shutdown with Initiator=Application (clean Close path) OR
         // because Dispose has begun but the broker happened to be dead first so the SDK
         // reports a non-Application initiator. _disposing covers the latter race.
         if (e.Initiator == ShutdownInitiator.Application || _disposing)
             return Task.CompletedTask;
 
-        _connected      = false;
         _lastShutdownAt = DateTime.UtcNow;
-        _meter?.RecordConnectionDisconnect(ComponentName, _endpoint);
         _logger.LogWarning(
             "RabbitMQ publisher connection to {Endpoint} lost (code {ReplyCode}, {ReplyText}); library is recovering",
             _endpoint, e.ReplyCode, e.ReplyText);
@@ -192,9 +175,7 @@ private Task OnRecoverySucceededAsync(object sender, AsyncEventArgs e)
         var duration = _lastShutdownAt == DateTime.MinValue
             ? 0
             : Math.Max(0, (DateTime.UtcNow - _lastShutdownAt).TotalSeconds);
-        _connected      = true;
         _lastShutdownAt = DateTime.MinValue;
-        _meter?.RecordConnectionRecovery(ComponentName, _endpoint, outcome: "succeeded", duration);
         _logger.LogInformation(
             "RabbitMQ publisher connection to {Endpoint} recovered after {Duration:F2}s",
             _endpoint, duration);
@@ -204,7 +185,8 @@ private Task OnRecoverySucceededAsync(object sender, AsyncEventArgs e)
     private Task OnConnectionRecoveryErrorAsync(object sender, ConnectionRecoveryErrorEventArgs e)
     {
         // The library will keep retrying; this fires once per failed internal attempt.
-        // No metric — only the cycle outcome is counted via RecoverySucceeded/Disconnect.
+        // No log beyond Information — the cycle outcome is reported by
+        // OnConnectionShutdownAsync / OnRecoverySucceededAsync.
         _logger.LogInformation(e.Exception,
             "RabbitMQ publisher recovery attempt failed for {Endpoint}; library will retry",
             _endpoint);
@@ -226,7 +208,6 @@ public void Dispose()
             _connection.ConnectionRecoveryErrorAsync  -= OnConnectionRecoveryErrorAsync;
         }
 
-        _stateGaugeSubscription?.Dispose();
         try { _channel?.CloseAsync().GetAwaiter().GetResult();    } catch { /* may already be closed */ }
         try { _connection?.CloseAsync().GetAwaiter().GetResult(); } catch { /* may already be closed */ }
         _channel?.Dispose();
diff --git a/src/RayTree.Plugins.RabbitMQ/RabbitMqSubscriberExtensions.cs b/src/RayTree.Plugins.RabbitMQ/RabbitMqSubscriberExtensions.cs
index 530c12f..735fe43 100644
--- a/src/RayTree.Plugins.RabbitMQ/RabbitMqSubscriberExtensions.cs
+++ b/src/RayTree.Plugins.RabbitMQ/RabbitMqSubscriberExtensions.cs
@@ -1,5 +1,4 @@
 using RayTree.Core.Handling;
-using RayTree.Core.Telemetry;
 
 namespace RayTree.Plugins.RabbitMQ;
 
@@ -8,15 +7,9 @@ public static class RabbitMqSubscriberExtensions
     /// <summary>
     /// Configures a <see cref="RabbitMqConsumer"/> as the queue source for this entity type.
     /// </summary>
-    /// <param name="meter">
-    /// Optional. When supplied, the consumer emits <c>raytree.connection.*</c> metrics on
-    /// SDK recovery events. The consumer itself has no logger field (existing exception to
-    /// the logging-placement rule), so logs are not emitted regardless of meter setting.
-    /// </param>
     public static IEntitySubscriberBuilder<TEntity> UseRabbitMq<TEntity>(
         this IEntitySubscriberBuilder<TEntity> builder,
-        Action<RabbitMqConsumerOptions> configure,
-        RayTreeMeter? meter = null)
+        Action<RabbitMqConsumerOptions> configure)
         where TEntity : class
     {
         ArgumentNullException.ThrowIfNull(builder);
@@ -24,7 +17,7 @@ public static IEntitySubscriberBuilder<TEntity> UseRabbitMq<TEntity>(
 
         var options = new RabbitMqConsumerOptions();
         configure(options);
-        return builder.UseConsumer(new RabbitMqConsumer(options, meter));
+        return builder.UseConsumer(new RabbitMqConsumer(options));
     }
 
     public static RabbitMqConsumerOptions WithQueue(
diff --git a/tests/RayTree.Core.Tests/Resilience/ConnectionRecoveryConfigurationTests.cs b/tests/RayTree.Core.Tests/Resilience/ConnectionRecoveryConfigurationTests.cs
deleted file mode 100644
index 33ad09f..0000000
--- a/tests/RayTree.Core.Tests/Resilience/ConnectionRecoveryConfigurationTests.cs
+++ /dev/null
@@ -1,93 +0,0 @@
-using Microsoft.Extensions.Configuration;
-using Microsoft.Extensions.DependencyInjection;
-using Microsoft.Extensions.Options;
-using RayTree.Core.Resilience;
-using RayTree.Hosting;
-
-namespace RayTree.Core.Tests.Resilience;
-
-/// <summary>
-/// Verifies that <c>AddChangeTracking</c> binds <c>ChangeTracking:Publisher:ConnectionRecovery</c>
-/// and <c>ChangeTracking:Subscriber:ConnectionRecovery</c> as NAMED <see cref="ConnectionRecoveryOptions"/>
-/// retrievable via the documented <see cref="ChangeTrackingRecoveryKeys"/>.
-/// </summary>
-[TestFixture]
-public class ConnectionRecoveryConfigurationTests
-{
-    [Test]
-    public void AddChangeTracking_BindsPublisherRecoveryOptions_FromConfiguration()
-    {
-        var config = new ConfigurationBuilder()
-            .AddInMemoryCollection(new Dictionary<string, string?>
-            {
-                ["ChangeTracking:Publisher:ConnectionRecovery:MaxAttempts"]      = "10",
-                ["ChangeTracking:Publisher:ConnectionRecovery:InitialDelay"]    = "00:00:00.500",
-                ["ChangeTracking:Publisher:ConnectionRecovery:MaxDelay"]        = "00:01:00",
-                ["ChangeTracking:Publisher:ConnectionRecovery:Factor"]          = "3.0",
-                ["ChangeTracking:Publisher:ConnectionRecovery:JitterFraction"]  = "0.1",
-                ["ChangeTracking:Publisher:ConnectionRecovery:Enabled"]         = "true",
-            })
-            .Build();
-
-        var services = new ServiceCollection();
-        services.AddLogging();
-        services.AddChangeTracking(config);
-
-        using var sp = services.BuildServiceProvider();
-        var monitor = sp.GetRequiredService<IOptionsMonitor<ConnectionRecoveryOptions>>();
-        var publisher = monitor.Get(ChangeTrackingRecoveryKeys.Publisher);
-
-        Assert.That(publisher.MaxAttempts,    Is.EqualTo(10));
-        Assert.That(publisher.InitialDelay,   Is.EqualTo(TimeSpan.FromMilliseconds(500)));
-        Assert.That(publisher.MaxDelay,       Is.EqualTo(TimeSpan.FromMinutes(1)));
-        Assert.That(publisher.Factor,         Is.EqualTo(3.0));
-        Assert.That(publisher.JitterFraction, Is.EqualTo(0.1));
-        Assert.That(publisher.Enabled,        Is.True);
-    }
-
-    [Test]
-    public void AddChangeTracking_BindsSubscriberRecoveryOptions_Independently()
-    {
-        var config = new ConfigurationBuilder()
-            .AddInMemoryCollection(new Dictionary<string, string?>
-            {
-                ["ChangeTracking:Publisher:ConnectionRecovery:MaxAttempts"]  = "10",
-                ["ChangeTracking:Subscriber:ConnectionRecovery:MaxAttempts"] = "5",
-                ["ChangeTracking:Subscriber:ConnectionRecovery:Enabled"]     = "false",
-            })
-            .Build();
-
-        var services = new ServiceCollection();
-        services.AddLogging();
-        services.AddChangeTracking(config);
-
-        using var sp = services.BuildServiceProvider();
-        var monitor = sp.GetRequiredService<IOptionsMonitor<ConnectionRecoveryOptions>>();
-        var pub = monitor.Get(ChangeTrackingRecoveryKeys.Publisher);
-        var sub = monitor.Get(ChangeTrackingRecoveryKeys.Subscriber);
-
-        Assert.That(pub.MaxAttempts, Is.EqualTo(10));
-        Assert.That(sub.MaxAttempts, Is.EqualTo(5));
-        Assert.That(sub.Enabled,     Is.False);
-    }
-
-    [Test]
-    public void AddChangeTracking_WithoutConfiguration_DefaultsAreUsed()
-    {
-        var services = new ServiceCollection();
-        services.AddLogging();
-        services.AddChangeTracking(configuration: null);
-
-        using var sp = services.BuildServiceProvider();
-        var monitor = sp.GetRequiredService<IOptionsMonitor<ConnectionRecoveryOptions>>();
-        var publisher = monitor.Get(ChangeTrackingRecoveryKeys.Publisher);
-
-        // No config bound — the named options resolve to the parameterless-constructor defaults.
-        Assert.That(publisher.Enabled,        Is.True);
-        Assert.That(publisher.InitialDelay,   Is.EqualTo(TimeSpan.FromSeconds(1)));
-        Assert.That(publisher.MaxDelay,       Is.EqualTo(TimeSpan.FromSeconds(30)));
-        Assert.That(publisher.Factor,         Is.EqualTo(2.0));
-        Assert.That(publisher.JitterFraction, Is.EqualTo(0.2));
-        Assert.That(publisher.MaxAttempts,    Is.Null);
-    }
-}
diff --git a/tests/RayTree.Core.Tests/Resilience/OutboxPublisherServiceConnectionFaultTests.cs b/tests/RayTree.Core.Tests/Resilience/OutboxPublisherServiceConnectionFaultTests.cs
index 83f29ac..6323e82 100644
--- a/tests/RayTree.Core.Tests/Resilience/OutboxPublisherServiceConnectionFaultTests.cs
+++ b/tests/RayTree.Core.Tests/Resilience/OutboxPublisherServiceConnectionFaultTests.cs
@@ -17,10 +17,10 @@
 namespace RayTree.Core.Tests.Resilience;
 
 /// <summary>
-/// Covers the outbox connection-fault observability hooks added to
-/// <see cref="OutboxPublisherService"/> — disconnect/recovery metric emission, per-transition
-/// gating, and log-level demotion when <see cref="IOutbox.IsConnectionFault"/> classifies
-/// the batch failure as a connection-level fault.
+/// Covers the outbox connection-fault observability hooks on
+/// <see cref="OutboxPublisherService"/> — per-transition gating and log-level demotion when
+/// <see cref="IOutbox.IsConnectionFault"/> classifies the batch failure as a connection-level
+/// fault. Connection metrics were removed; recovery is now observed via logs only.
 /// </summary>
 [TestFixture]
 public class OutboxPublisherServiceConnectionFaultTests
@@ -150,7 +150,7 @@ private static async Task WaitForAsync(Func<bool> condition, TimeSpan timeout)
     }
 
     [Test]
-    public async Task ConnectionFault_FirstFailure_EmitsDisconnect_AndLogsWarningNotError()
+    public async Task ConnectionFault_FirstFailure_LogsWarningNotError()
     {
         var outbox = new StubOutbox { IsFault = true, Component = "postgres.outbox", Endpoint = "host:5432" };
         var (publisher, meter, collector, logs, factory) = Build(outbox);
@@ -158,15 +158,9 @@ public async Task ConnectionFault_FirstFailure_EmitsDisconnect_AndLogsWarningNot
 
         using var svc = new OutboxPublisherService(publisher, typeof(Sample), FastPolling, factory, meter);
         await svc.StartAsync();
-        await WaitForAsync(() => collector.Sum("raytree.connection.disconnects") >= 1, TimeSpan.FromSeconds(3));
+        await WaitForAsync(() => logs.Contains(LogLevel.Warning, "Outbox connection fault"), TimeSpan.FromSeconds(3));
         await svc.StopAsync();
 
-        Assert.That(collector.Sum("raytree.connection.disconnects"), Is.EqualTo(1),
-            "Disconnect counter should fire exactly once across multiple failed batches");
-        var disconnect = collector.Get("raytree.connection.disconnects")[0];
-        Assert.That(disconnect.Tags["component"], Is.EqualTo("postgres.outbox"));
-        Assert.That(disconnect.Tags["endpoint"],  Is.EqualTo("host:5432"));
-
         Assert.That(logs.Contains(LogLevel.Warning, "Outbox connection fault"), Is.True);
         // The Error log path for batch errors must NOT fire on connection faults.
         Assert.That(logs.Contains(LogLevel.Error, "Error processing outbox batch"), Is.False,
@@ -174,7 +168,7 @@ public async Task ConnectionFault_FirstFailure_EmitsDisconnect_AndLogsWarningNot
     }
 
     [Test]
-    public async Task ConnectionFault_RecoversOnNextSuccessfulBatch_EmitsRecoveryMetric_AndInfoLog()
+    public async Task ConnectionFault_RecoversOnNextSuccessfulBatch_LogsInfo()
     {
         var outbox = new StubOutbox { IsFault = true, Component = "postgres.outbox", Endpoint = "h:5432", HealAfter = 2 };
         var (publisher, meter, collector, logs, factory) = Build(outbox);
@@ -183,21 +177,17 @@ public async Task ConnectionFault_RecoversOnNextSuccessfulBatch_EmitsRecoveryMet
         using var svc = new OutboxPublisherService(publisher, typeof(Sample), FastPolling, factory, meter);
         await svc.StartAsync();
         await WaitForAsync(() =>
-            collector.Sum("raytree.connection.recoveries") >= 1, TimeSpan.FromSeconds(5));
+            logs.Contains(LogLevel.Information, "Outbox connection recovered"), TimeSpan.FromSeconds(5));
         await svc.StopAsync();
 
-        var recovery = collector.Get("raytree.connection.recoveries")[0];
-        Assert.That(recovery.Tags["component"], Is.EqualTo("postgres.outbox"));
-        Assert.That(recovery.Tags["outcome"],   Is.EqualTo("succeeded"));
-        Assert.That(collector.Get("raytree.connection.recovery.duration"), Has.Count.GreaterThanOrEqualTo(1));
         Assert.That(logs.Contains(LogLevel.Information, "Outbox connection recovered"), Is.True);
     }
 
     [Test]
-    public async Task NonConnectionFault_EmitsNoMetric_AndPreservesErrorLog()
+    public async Task NonConnectionFault_PreservesErrorLog()
     {
         // IsFault = false: outbox classifies the exception as non-connection. The existing
-        // Error log path SHALL be preserved and no connection metric SHALL be emitted.
+        // Error log path SHALL be preserved.
         var outbox = new StubOutbox { IsFault = false, Component = "postgres.outbox" };
         var (publisher, meter, collector, logs, factory) = Build(outbox);
         using var _ = meter; using var __ = collector; using var ___ = publisher; using var ____ = factory;
@@ -207,18 +197,15 @@ public async Task NonConnectionFault_EmitsNoMetric_AndPreservesErrorLog()
         await WaitForAsync(() => logs.Count(LogLevel.Error) >= 1, TimeSpan.FromSeconds(3));
         await svc.StopAsync();
 
-        Assert.That(collector.Sum("raytree.connection.disconnects"), Is.EqualTo(0),
-            "Non-fault exceptions must not emit the connection-disconnect metric");
         Assert.That(logs.Contains(LogLevel.Error, "Error processing outbox batch"), Is.True,
             "Non-fault exceptions must preserve the Error log path");
     }
 
     [Test]
-    public async Task ConnectionComponentNull_FallsThroughToErrorPath_NoMetric()
+    public async Task ConnectionComponentNull_FallsThroughToErrorPath()
     {
         // Even when IsFault = true, a null ConnectionComponent means the outbox declines
-        // to participate in connection observability. Fall through to the Error path,
-        // no metric emission.
+        // to participate in connection observability. Fall through to the Error path.
         var outbox = new StubOutbox { IsFault = true, Component = null };
         var (publisher, meter, collector, logs, factory) = Build(outbox);
         using var _ = meter; using var __ = collector; using var ___ = publisher; using var ____ = factory;
@@ -228,7 +215,6 @@ public async Task ConnectionComponentNull_FallsThroughToErrorPath_NoMetric()
         await WaitForAsync(() => logs.Count(LogLevel.Error) >= 1, TimeSpan.FromSeconds(3));
         await svc.StopAsync();
 
-        Assert.That(collector.Sum("raytree.connection.disconnects"), Is.EqualTo(0));
         Assert.That(logs.Contains(LogLevel.Error, "Error processing outbox batch"), Is.True);
     }
 
diff --git a/tests/RayTree.Core.Tests/Resilience/RecoveryMetricsTests.cs b/tests/RayTree.Core.Tests/Resilience/RecoveryMetricsTests.cs
deleted file mode 100644
index 6de5903..0000000
--- a/tests/RayTree.Core.Tests/Resilience/RecoveryMetricsTests.cs
+++ /dev/null
@@ -1,188 +0,0 @@
-using System.Diagnostics.Metrics;
-using RayTree.Core.Telemetry;
-using RayTree.Core.Tests.Telemetry;
-
-namespace RayTree.Core.Tests.Resilience;
-
-[TestFixture]
-public class RecoveryMetricsTests
-{
-    private sealed class InstrumentCollector : IDisposable
-    {
-        private readonly MeterListener _listener;
-        public List<Instrument> Instruments { get; } = new();
-
-        public InstrumentCollector(Meter target)
-        {
-            _listener = new MeterListener
-            {
-                InstrumentPublished = (instrument, _) =>
-                {
-                    if (ReferenceEquals(instrument.Meter, target))
-                        Instruments.Add(instrument);
-                }
-            };
-            _listener.Start();
-        }
-
-        public void Dispose() => _listener.Dispose();
-    }
-
-    [Test]
-    public void ConnectionInstruments_AreCreatedWithCorrectUnits()
-    {
-        using var meter = new RayTreeMeter();
-        using var collector = new InstrumentCollector(meter.InternalMeter);
-
-        var disconnects = collector.Instruments.SingleOrDefault(i => i.Name == "raytree.connection.disconnects");
-        var recoveries  = collector.Instruments.SingleOrDefault(i => i.Name == "raytree.connection.recoveries");
-        var duration    = collector.Instruments.SingleOrDefault(i => i.Name == "raytree.connection.recovery.duration");
-        var state       = collector.Instruments.SingleOrDefault(i => i.Name == "raytree.connection.state");
-
-        Assert.That(disconnects, Is.Not.Null, "raytree.connection.disconnects missing");
-        Assert.That(recoveries,  Is.Not.Null, "raytree.connection.recoveries missing");
-        Assert.That(duration,    Is.Not.Null, "raytree.connection.recovery.duration missing");
-        Assert.That(state,       Is.Not.Null, "raytree.connection.state missing");
-
-        Assert.That(duration!.Unit, Is.EqualTo("s"), "duration unit must be seconds");
-    }
-
-    [Test]
-    public void RecordConnectionDisconnect_EmitsCounter_WithComponentAndEndpointTags()
-    {
-        using var meter = new RayTreeMeter();
-        using var collector = new TestMetricsCollector(meter);
-
-        meter.RecordConnectionDisconnect("postgres.notification", "my_channel");
-
-        var measurements = collector.Get("raytree.connection.disconnects");
-        Assert.That(measurements, Has.Count.EqualTo(1));
-        Assert.That(measurements[0].Value, Is.EqualTo(1));
-        Assert.That(measurements[0].Tags["component"], Is.EqualTo("postgres.notification"));
-        Assert.That(measurements[0].Tags["endpoint"],  Is.EqualTo("my_channel"));
-    }
-
-    [Test]
-    public void RecordConnectionRecovery_Succeeded_EmitsCounterAndDuration()
-    {
-        using var meter = new RayTreeMeter();
-        using var collector = new TestMetricsCollector(meter);
-
-        meter.RecordConnectionRecovery(
-            component: "kafka.publisher",
-            endpoint: "broker:9092",
-            outcome: "succeeded",
-            durationSeconds: 2.5);
-
-        var counter = collector.Get("raytree.connection.recoveries");
-        Assert.That(counter, Has.Count.EqualTo(1));
-        Assert.That(counter[0].Value, Is.EqualTo(1));
-        Assert.That(counter[0].Tags["component"], Is.EqualTo("kafka.publisher"));
-        Assert.That(counter[0].Tags["endpoint"],  Is.EqualTo("broker:9092"));
-        Assert.That(counter[0].Tags["outcome"],   Is.EqualTo("succeeded"));
-
-        var duration = collector.Get("raytree.connection.recovery.duration");
-        Assert.That(duration, Has.Count.EqualTo(1));
-        Assert.That(duration[0].Value, Is.EqualTo(2.5));
-        Assert.That(duration[0].Tags["outcome"], Is.EqualTo("succeeded"));
-    }
-
-    [Test]
-    public void RecordConnectionRecovery_Exhausted_EmitsCounterAndDuration_WithExhaustedOutcome()
-    {
-        using var meter = new RayTreeMeter();
-        using var collector = new TestMetricsCollector(meter);
-
-        meter.RecordConnectionRecovery(
-            component: "postgres.notification",
-            endpoint: "my_channel",
-            outcome: "exhausted",
-            durationSeconds: 10.0);
-
-        var counter = collector.Get("raytree.connection.recoveries");
-        Assert.That(counter, Has.Count.EqualTo(1));
-        Assert.That(counter[0].Tags["outcome"], Is.EqualTo("exhausted"));
-
-        var duration = collector.Get("raytree.connection.recovery.duration");
-        Assert.That(duration[0].Tags["outcome"], Is.EqualTo("exhausted"));
-    }
-
-    [Test]
-    public void RegisterConnectionStateGauge_ReportsConnectedState()
-    {
-        using var meter = new RayTreeMeter();
-        using var collector = new TestMetricsCollector(meter);
-
-        using var sub = meter.RegisterConnectionStateGauge(
-            component: "rabbitmq.publisher",
-            endpoint: "broker:5672",
-            getState: () => 1);
-
-        collector.RecordObservableInstruments();
-
-        var measurements = collector.Get("raytree.connection.state");
-        Assert.That(measurements, Has.Count.GreaterThanOrEqualTo(1));
-        var latest = measurements[0];
-        Assert.That(latest.Value, Is.EqualTo(1));
-        Assert.That(latest.Tags["component"], Is.EqualTo("rabbitmq.publisher"));
-        Assert.That(latest.Tags["endpoint"],  Is.EqualTo("broker:5672"));
-    }
-
-    [Test]
-    public void RegisterConnectionStateGauge_ReflectsDisconnectedState()
-    {
-        using var meter = new RayTreeMeter();
-        using var collector = new TestMetricsCollector(meter);
-
-        var state = 1;
-        using var sub = meter.RegisterConnectionStateGauge("kafka.consumer", "broker:9092", () => state);
-
-        collector.RecordObservableInstruments();
-        state = 0;
-        collector.RecordObservableInstruments();
-
-        var measurements = collector.Get("raytree.connection.state");
-        // Most recent first; the second observation should be 0.
-        Assert.That(measurements[0].Value, Is.EqualTo(0));
-    }
-
-    [Test]
-    public void RegisterConnectionStateGauge_DisposeRemovesSource()
-    {
-        using var meter = new RayTreeMeter();
-        using var collector = new TestMetricsCollector(meter);
-
-        var sub = meter.RegisterConnectionStateGauge("kafka.publisher", "broker:9092", () => 1);
-        collector.RecordObservableInstruments();
-        var beforeDispose = collector.Get("raytree.connection.state").Count;
-
-        sub.Dispose();
-        collector.RecordObservableInstruments();
-        var afterDispose = collector.Get("raytree.connection.state").Count;
-
-        // After dispose, no new observation is recorded for this source.
-        Assert.That(afterDispose, Is.EqualTo(beforeDispose));
-    }
-
-    [Test]
-    public void RegisterConnectionStateGauge_GetStateThrowing_SkipsMeasurement_WithoutPropagating()
-    {
-        using var meter = new RayTreeMeter();
-        using var collector = new TestMetricsCollector(meter);
-
-        using var sub = meter.RegisterConnectionStateGauge(
-            component: "postgres.notification",
-            endpoint: "my_channel",
-            getState: () => throw new InvalidOperationException("transient"));
-
-        Assert.DoesNotThrow(() => collector.RecordObservableInstruments());
-        Assert.That(collector.Get("raytree.connection.state"), Is.Empty);
-    }
-
-    [Test]
-    public void RecordConnectionDisconnect_NoListener_DoesNotThrow()
-    {
-        using var meter = new RayTreeMeter();
-        Assert.DoesNotThrow(() => meter.RecordConnectionDisconnect("kafka.publisher", "broker:9092"));
-    }
-}
diff --git a/tests/RayTree.Core.Tests/Resilience/ConnectionRecoveryOptionsTests.cs b/tests/RayTree.Plugins.Kafka.Tests/KafkaConnectionRecoveryOptionsTests.cs
similarity index 65%
rename from tests/RayTree.Core.Tests/Resilience/ConnectionRecoveryOptionsTests.cs
rename to tests/RayTree.Plugins.Kafka.Tests/KafkaConnectionRecoveryOptionsTests.cs
index 91f03fd..e52a917 100644
--- a/tests/RayTree.Core.Tests/Resilience/ConnectionRecoveryOptionsTests.cs
+++ b/tests/RayTree.Plugins.Kafka.Tests/KafkaConnectionRecoveryOptionsTests.cs
@@ -1,14 +1,14 @@
-using RayTree.Core.Resilience;
+using RayTree.Plugins.Kafka;
 
-namespace RayTree.Core.Tests.Resilience;
+namespace RayTree.Plugins.Kafka.Tests;
 
 [TestFixture]
-public class ConnectionRecoveryOptionsTests
+public class KafkaConnectionRecoveryOptionsTests
 {
     [Test]
     public void Defaults_MatchSpec()
     {
-        var options = new ConnectionRecoveryOptions();
+        var options = new KafkaConnectionRecoveryOptions();
 
         Assert.That(options.Enabled,        Is.True);
         Assert.That(options.InitialDelay,   Is.EqualTo(TimeSpan.FromSeconds(1)));
@@ -21,7 +21,7 @@ public void Defaults_MatchSpec()
     [Test]
     public void Defaults_ValidateDoesNotThrow()
     {
-        var options = new ConnectionRecoveryOptions();
+        var options = new KafkaConnectionRecoveryOptions();
         Assert.DoesNotThrow(() => options.Validate());
     }
 
@@ -29,7 +29,7 @@ public void Defaults_ValidateDoesNotThrow()
     public void InitialDelay_Zero_Throws()
     {
         var ex = Assert.Throws<ArgumentOutOfRangeException>(
-            () => _ = new ConnectionRecoveryOptions { InitialDelay = TimeSpan.Zero });
+            () => _ = new KafkaConnectionRecoveryOptions { InitialDelay = TimeSpan.Zero });
         Assert.That(ex!.ParamName, Is.EqualTo("InitialDelay"));
     }
 
@@ -37,21 +37,21 @@ public void InitialDelay_Zero_Throws()
     public void InitialDelay_Negative_Throws()
     {
         Assert.Throws<ArgumentOutOfRangeException>(
-            () => _ = new ConnectionRecoveryOptions { InitialDelay = TimeSpan.FromSeconds(-1) });
+            () => _ = new KafkaConnectionRecoveryOptions { InitialDelay = TimeSpan.FromSeconds(-1) });
     }
 
     [Test]
     public void MaxDelay_Zero_Throws()
     {
         var ex = Assert.Throws<ArgumentOutOfRangeException>(
-            () => _ = new ConnectionRecoveryOptions { MaxDelay = TimeSpan.Zero });
+            () => _ = new KafkaConnectionRecoveryOptions { MaxDelay = TimeSpan.Zero });
         Assert.That(ex!.ParamName, Is.EqualTo("MaxDelay"));
     }
 
     [Test]
     public void MaxDelay_LessThanInitialDelay_ValidateThrows()
     {
-        var options = new ConnectionRecoveryOptions
+        var options = new KafkaConnectionRecoveryOptions
         {
             InitialDelay = TimeSpan.FromSeconds(10),
             MaxDelay     = TimeSpan.FromSeconds(5)
@@ -65,21 +65,21 @@ public void MaxDelay_LessThanInitialDelay_ValidateThrows()
     public void Factor_LessThanOne_Throws()
     {
         var ex = Assert.Throws<ArgumentOutOfRangeException>(
-            () => _ = new ConnectionRecoveryOptions { Factor = 0.5 });
+            () => _ = new KafkaConnectionRecoveryOptions { Factor = 0.5 });
         Assert.That(ex!.ParamName, Is.EqualTo("Factor"));
     }
 
     [Test]
     public void Factor_Exactly1_Allowed()
     {
-        Assert.DoesNotThrow(() => _ = new ConnectionRecoveryOptions { Factor = 1.0 });
+        Assert.DoesNotThrow(() => _ = new KafkaConnectionRecoveryOptions { Factor = 1.0 });
     }
 
     [Test]
     public void JitterFraction_Negative_Throws()
     {
         var ex = Assert.Throws<ArgumentOutOfRangeException>(
-            () => _ = new ConnectionRecoveryOptions { JitterFraction = -0.1 });
+            () => _ = new KafkaConnectionRecoveryOptions { JitterFraction = -0.1 });
         Assert.That(ex!.ParamName, Is.EqualTo("JitterFraction"));
     }
 
@@ -87,27 +87,27 @@ public void JitterFraction_Negative_Throws()
     public void JitterFraction_GreaterThanOne_Throws()
     {
         var ex = Assert.Throws<ArgumentOutOfRangeException>(
-            () => _ = new ConnectionRecoveryOptions { JitterFraction = 1.5 });
+            () => _ = new KafkaConnectionRecoveryOptions { JitterFraction = 1.5 });
         Assert.That(ex!.ParamName, Is.EqualTo("JitterFraction"));
     }
 
     [Test]
     public void JitterFraction_Zero_Allowed()
     {
-        Assert.DoesNotThrow(() => _ = new ConnectionRecoveryOptions { JitterFraction = 0.0 });
+        Assert.DoesNotThrow(() => _ = new KafkaConnectionRecoveryOptions { JitterFraction = 0.0 });
     }
 
     [Test]
     public void JitterFraction_One_Allowed()
     {
-        Assert.DoesNotThrow(() => _ = new ConnectionRecoveryOptions { JitterFraction = 1.0 });
+        Assert.DoesNotThrow(() => _ = new KafkaConnectionRecoveryOptions { JitterFraction = 1.0 });
     }
 
     [Test]
     public void MaxAttempts_Zero_Throws()
     {
         var ex = Assert.Throws<ArgumentOutOfRangeException>(
-            () => _ = new ConnectionRecoveryOptions { MaxAttempts = 0 });
+            () => _ = new KafkaConnectionRecoveryOptions { MaxAttempts = 0 });
         Assert.That(ex!.ParamName, Is.EqualTo("MaxAttempts"));
     }
 
@@ -115,19 +115,19 @@ public void MaxAttempts_Zero_Throws()
     public void MaxAttempts_Negative_Throws()
     {
         Assert.Throws<ArgumentOutOfRangeException>(
-            () => _ = new ConnectionRecoveryOptions { MaxAttempts = -3 });
+            () => _ = new KafkaConnectionRecoveryOptions { MaxAttempts = -3 });
     }
 
     [Test]
     public void MaxAttempts_Null_Allowed()
     {
-        Assert.DoesNotThrow(() => _ = new ConnectionRecoveryOptions { MaxAttempts = null });
+        Assert.DoesNotThrow(() => _ = new KafkaConnectionRecoveryOptions { MaxAttempts = null });
     }
 
     [Test]
     public void MaxAttempts_Positive_Allowed()
     {
-        var options = new ConnectionRecoveryOptions { MaxAttempts = 5 };
+        var options = new KafkaConnectionRecoveryOptions { MaxAttempts = 5 };
         Assert.That(options.MaxAttempts, Is.EqualTo(5));
     }
 }
diff --git a/tests/RayTree.Plugins.Kafka.Tests/KafkaRecoveryMetricsTests.cs b/tests/RayTree.Plugins.Kafka.Tests/KafkaRecoveryMetricsTests.cs
index 9d20c72..216e56a 100644
--- a/tests/RayTree.Plugins.Kafka.Tests/KafkaRecoveryMetricsTests.cs
+++ b/tests/RayTree.Plugins.Kafka.Tests/KafkaRecoveryMetricsTests.cs
@@ -1,55 +1,32 @@
-using System.Diagnostics.Metrics;
 using Microsoft.Extensions.Logging;
 using Microsoft.Extensions.Logging.Abstractions;
 using RayTree.Core.Models;
-using RayTree.Core.Telemetry;
 using RayTree.Core.Tracking;
 using Testcontainers.Kafka;
 
 namespace RayTree.Plugins.Kafka.Tests;
 
 /// <summary>
-/// Smoke tests for the connection-recovery metric wiring on <see cref="KafkaPublisher"/> and
-/// <see cref="KafkaConsumer"/>. <b>These tests do not attempt to trigger librdkafka fatal
-/// errors</b> — see task 7.1 / 7.2 in <c>tasks.md</c> for the rationale (fatal errors require
-/// pre-positioned broker-side state and are not deterministically reproducible from a black-box
-/// integration test). They verify that under normal operation:
-///
-/// 1. The connection-state gauge correctly reports 1 (connected) after init.
-/// 2. No spurious disconnect metrics are emitted during clean operation.
-/// 3. Application-initiated dispose does not register as a recovery event.
-///
-/// The fatal-error path itself is verified by code review against the spec; the metric helpers
-/// are exercised by <c>RecoveryMetricsTests</c> in the Core test project.
+/// Smoke tests for the connection-recovery wiring on <see cref="KafkaPublisher"/> and
+/// <see cref="KafkaConsumer"/>. Connection metrics were removed; recovery is now observed via
+/// logs only. <b>These tests do not attempt to trigger librdkafka fatal errors</b> (fatal errors
+/// require pre-positioned broker-side state and are not deterministically reproducible from a
+/// black-box integration test). They verify that under normal operation publisher/consumer init
+/// and clean dispose do not surface spurious faults, and that non-fatal transport errors against
+/// an unreachable broker are logged (not treated as a fatal fault).
 /// </summary>
 [NonParallelizable]
 public class KafkaRecoveryMetricsTests : IAsyncDisposable
 {
     private readonly KafkaContainer _kafka = new KafkaBuilder("confluentinc/cp-kafka:7.7.8").Build();
-    private RayTreeMeter _meter = null!;
-    private CapturingMeterListener _capture = null!;
 
     [OneTimeSetUp]
     public Task OneTimeSetUp() => _kafka.StartAsync();
 
-    [SetUp]
-    public void SetUp()
-    {
-        _meter = new RayTreeMeter();
-        _capture = new CapturingMeterListener();
-    }
-
-    [TearDown]
-    public void TearDown()
-    {
-        _capture.Dispose();
-        _meter.Dispose();
-    }
-
     public async ValueTask DisposeAsync() => await _kafka.DisposeAsync();
 
     [Test]
-    public async Task Publisher_AfterInitialize_StateGaugeReports1_NoSpuriousDisconnects()
+    public async Task Publisher_AfterInitialize_PublishesCleanly()
     {
         var topic = $"recovery-smoke-{Guid.NewGuid():N}";
 
@@ -57,37 +34,24 @@ public async Task Publisher_AfterInitialize_StateGaugeReports1_NoSpuriousDisconn
         {
             BootstrapServers = _kafka.GetBootstrapAddress(),
             Topic            = topic
-        }, loggerFactory: null, meter: _meter);
+        }, loggerFactory: null);
 
         await publisher.InitializeAsync();
 
         // Publish one message so the producer actually establishes a broker connection
-        // (Build alone is in-memory only).
-        await publisher.PublishAsync(SampleEnvelope(topic));
-
-        // Force the OTel gauge callback to fire so the meter listener sees a state observation.
-        _capture.RecordObservableInstruments();
-
-        Assert.Multiple(() =>
-        {
-            Assert.That(_capture.LatestGaugeValue("raytree.connection.state", "kafka.publisher"),
-                Is.EqualTo(1), "state gauge SHOULD report 1 (connected) after a successful publish");
-            Assert.That(_capture.SumOf("raytree.connection.disconnects", "kafka.publisher"),
-                Is.EqualTo(0), "no disconnect should fire during clean operation");
-            Assert.That(_capture.SumOf("raytree.connection.recoveries", "kafka.publisher"),
-                Is.EqualTo(0), "no recovery should fire when no fault occurred");
-        });
+        // (Build alone is in-memory only). Must not throw.
+        Assert.DoesNotThrowAsync(() => publisher.PublishAsync(SampleEnvelope(topic)));
     }
 
     [Test]
-    public async Task Consumer_AfterInitialize_StateGaugeReports1_NoSpuriousDisconnects()
+    public async Task Consumer_AfterInitialize_SubscribesCleanly()
     {
         var topic = $"consumer-smoke-{Guid.NewGuid():N}";
 
         // Create the topic first so the consumer can subscribe cleanly.
         using (var producer = new KafkaPublisher(
             new KafkaPublisherOptions { BootstrapServers = _kafka.GetBootstrapAddress(), Topic = topic },
-            loggerFactory: null, meter: null))
+            loggerFactory: null))
         {
             await producer.InitializeAsync();
             await producer.PublishAsync(SampleEnvelope(topic));
@@ -99,33 +63,18 @@ public async Task Consumer_AfterInitialize_StateGaugeReports1_NoSpuriousDisconne
             Topic            = topic,
             GroupId          = $"smoke-group-{Guid.NewGuid():N}",
             PollTimeoutMs    = 200
-        }, NullLoggerFactory.Instance, meter: _meter);
-
-        await consumer.InitializeAsync();
-        _capture.RecordObservableInstruments();
+        }, NullLoggerFactory.Instance);
 
-        Assert.Multiple(() =>
-        {
-            Assert.That(_capture.LatestGaugeValue("raytree.connection.state", "kafka.consumer"),
-                Is.EqualTo(1), "state gauge SHOULD report 1 after successful Subscribe");
-            Assert.That(_capture.SumOf("raytree.connection.disconnects", "kafka.consumer"),
-                Is.EqualTo(0));
-            Assert.That(_capture.SumOf("raytree.connection.recoveries", "kafka.consumer"),
-                Is.EqualTo(0));
-        });
+        Assert.DoesNotThrowAsync(() => consumer.InitializeAsync());
     }
 
     [Test]
-    public async Task Publisher_UnreachableBroker_NoFatalDisconnect_NoRebuild()
+    public async Task Publisher_UnreachableBroker_LogsNonFatalError_NoRebuild()
     {
         // Point at a port that has nothing listening. librdkafka emits non-fatal
         // transport errors continuously while trying to bootstrap. The publisher SHALL NOT
-        // treat these as a fault — _faultTicks stays 0, no disconnect counter, no rebuild.
-        // This verifies the `!error.IsFatal` short-circuit in OnError.
-        //
-        // To avoid a blind sleep, capture the publisher's Warning logs and poll until at
-        // least one fires — that proves librdkafka actually emitted a non-fatal error our
-        // handler observed. Once we have that, the metric assertion is deterministic.
+        // treat these as a fault — _faultTicks stays 0, no rebuild. This verifies the
+        // `!error.IsFatal` short-circuit in OnError via the Warning log it emits.
         var logs = new WarningCountingLoggerProvider();
         using var loggerFactory = LoggerFactory.Create(b => b.AddProvider(logs).SetMinimumLevel(LogLevel.Warning));
 
@@ -133,7 +82,7 @@ public async Task Publisher_UnreachableBroker_NoFatalDisconnect_NoRebuild()
         {
             BootstrapServers = "127.0.0.1:1",   // nothing here
             Topic            = "unreachable-test"
-        }, loggerFactory: loggerFactory, meter: _meter);
+        }, loggerFactory: loggerFactory);
 
         await publisher.InitializeAsync();
 
@@ -143,13 +92,6 @@ public async Task Publisher_UnreachableBroker_NoFatalDisconnect_NoRebuild()
             await Task.Delay(50);
         Assert.That(logs.NonFatalErrors, Is.GreaterThanOrEqualTo(1),
             "librdkafka SHOULD emit at least one non-fatal error against an unreachable broker");
-
-        // Now the assertion is deterministic: the OnError path was exercised, but the
-        // fatal-error branch was not. Metrics MUST be untouched.
-        Assert.That(_capture.SumOf("raytree.connection.disconnects", "kafka.publisher"), Is.EqualTo(0),
-            "non-fatal transient errors MUST NOT increment the disconnect counter");
-        Assert.That(_capture.SumOf("raytree.connection.recoveries", "kafka.publisher"), Is.EqualTo(0),
-            "without a fatal error there's nothing to recover from — no recovery should be emitted");
     }
 
     /// <summary>
@@ -180,7 +122,7 @@ public void Log<TState>(LogLevel level, EventId id, TState state, Exception? ex,
     }
 
     [Test]
-    public async Task Publisher_CleanDispose_DoesNotEmitDisconnectOrRecovery()
+    public async Task Publisher_CleanDispose_DoesNotThrow()
     {
         var topic = $"dispose-smoke-{Guid.NewGuid():N}";
 
@@ -188,17 +130,12 @@ public async Task Publisher_CleanDispose_DoesNotEmitDisconnectOrRecovery()
         {
             BootstrapServers = _kafka.GetBootstrapAddress(),
             Topic            = topic
-        }, loggerFactory: null, meter: _meter);
+        }, loggerFactory: null);
 
         await publisher.InitializeAsync();
         await publisher.PublishAsync(SampleEnvelope(topic));
 
-        publisher.Dispose();
-        await Task.Delay(100);   // brief settle window for any in-flight librdkafka callbacks
-
-        Assert.That(_capture.SumOf("raytree.connection.disconnects", "kafka.publisher"), Is.EqualTo(0),
-            "application-initiated dispose must not register as a disconnect");
-        Assert.That(_capture.SumOf("raytree.connection.recoveries", "kafka.publisher"), Is.EqualTo(0));
+        Assert.DoesNotThrow(() => publisher.Dispose());
     }
 
     // ---- helpers --------------------------------------------------------
@@ -213,56 +150,4 @@ public async Task Publisher_CleanDispose_DoesNotEmitDisconnectOrRecovery()
         Timestamp     = DateTime.UtcNow,
         Payload       = new byte[] { 0x01, 0x02, 0x03 }
     };
-
-    private sealed class CapturingMeterListener : IDisposable
-    {
-        private readonly MeterListener _listener;
-        private readonly List<Recorded> _measurements = new();
-        private readonly object _gate = new();
-
-        public CapturingMeterListener()
-        {
-            _listener = new MeterListener
-            {
-                InstrumentPublished = (instrument, l) =>
-                {
-                    if (instrument.Meter.Name == RayTreeMeter.MeterName)
-                        l.EnableMeasurementEvents(instrument);
-                }
-            };
-            _listener.SetMeasurementEventCallback<long>  ((i, v, t, _) => Append(i, v, t));
-            _listener.SetMeasurementEventCallback<int>   ((i, v, t, _) => Append(i, v, t));
-            _listener.SetMeasurementEventCallback<double>((i, v, t, _) => Append(i, v, t));
-            _listener.Start();
-        }
-
-        private void Append(Instrument instrument, double value, ReadOnlySpan<KeyValuePair<string, object?>> tags)
-        {
-            string? component = null;
-            foreach (var kv in tags)
-                if (kv.Key == "component") { component = kv.Value as string; break; }
-            lock (_gate) _measurements.Add(new Recorded(instrument.Name, value, component));
-        }
-
-        public void RecordObservableInstruments() => _listener.RecordObservableInstruments();
-
-        public double SumOf(string name, string component)
-        {
-            lock (_gate)
-                return _measurements.Where(m => m.Name == name && m.Component == component).Sum(m => m.Value);
-        }
-
-        public double? LatestGaugeValue(string name, string component)
-        {
-            lock (_gate)
-            {
-                var match = _measurements.LastOrDefault(m => m.Name == name && m.Component == component);
-                return match.Name is null ? null : match.Value;
-            }
-        }
-
-        public void Dispose() => _listener.Dispose();
-
-        private readonly record struct Recorded(string Name, double Value, string? Component);
-    }
 }
diff --git a/tests/RayTree.Plugins.PostgreSQL.Tests/NotificationBasedPublisherRecoveryTests.cs b/tests/RayTree.Plugins.PostgreSQL.Tests/NotificationBasedPublisherRecoveryTests.cs
index 173d95d..566fa63 100644
--- a/tests/RayTree.Plugins.PostgreSQL.Tests/NotificationBasedPublisherRecoveryTests.cs
+++ b/tests/RayTree.Plugins.PostgreSQL.Tests/NotificationBasedPublisherRecoveryTests.cs
@@ -1,23 +1,24 @@
-using System.Diagnostics.Metrics;
 using DotNet.Testcontainers.Containers;
 using Microsoft.Extensions.Logging.Abstractions;
 using Npgsql;
 using RayTree.Core.Models;
-using RayTree.Core.Resilience;
-using RayTree.Core.Telemetry;
 using RayTree.Core.Tracking;
 using RayTree.Plugins.Compressors.Gzip;
 using RayTree.Plugins.InMemory;
 using RayTree.Plugins.PostgreSQL.Outbox;
 using RayTree.Plugins.PostgreSQL.Outbox.Notification;
+using RayTree.Plugins.PostgreSQL.Resilience;
 using RayTree.Plugins.Serializers.Json;
 
 namespace RayTree.Plugins.PostgreSQL.Tests;
 
 /// <summary>
 /// Integration tests for the LISTEN-connection reconnect path in <see cref="NotificationBasedPublisher"/>
-/// and the outbox-side observability hooks in <see cref="RayTree.Core.Distribution.OutboxPublisherService"/>.
-/// Each test owns its own container so a permanent-kill negative case doesn't leak into the next test.
+/// and the outbox-side connection-fault classification used by
+/// <see cref="RayTree.Core.Distribution.OutboxPublisherService"/>. Connection metrics were removed;
+/// these tests assert recovery <i>behavior</i> (delivery continues, the listen loop exits when
+/// recovery is disabled/exhausted, the outbox classifies connection faults). Each test owns its
+/// own container so a permanent-kill negative case doesn't leak into the next test.
 /// </summary>
 [NonParallelizable]
 public class NotificationBasedPublisherRecoveryTests
@@ -29,8 +30,6 @@ public class NotificationBasedPublisherRecoveryTests
     /// </summary>
     private IContainer _postgres = null!;
     private string _connectionString = null!;
-    private RayTreeMeter _meter = null!;
-    private CapturingMeterListener _capture = null!;
 
     private const string OutboxTable = "recovery_test_outbox";
 
@@ -40,21 +39,16 @@ public async Task SetUp()
         _postgres = PostgresContainerFactory.Create();
         await _postgres.StartAsync();
         _connectionString = ((Testcontainers.PostgreSql.PostgreSqlContainer)_postgres).GetConnectionString();
-
-        _meter = new RayTreeMeter();
-        _capture = new CapturingMeterListener(_meter);
     }
 
     [TearDown]
     public async Task TearDown()
     {
-        _capture.Dispose();
-        _meter.Dispose();
         try { await _postgres.DisposeAsync(); } catch { /* may already be stopped */ }
     }
 
     [Test]
-    public async Task ListenConnectionKilled_DuringPublisherRunning_EmitsDisconnectThenRecovery_AndContinuesDelivering()
+    public async Task ListenConnectionKilled_DuringPublisherRunning_ContinuesDelivering()
     {
         // Arrange — kill the LISTEN connection from the Postgres side via pg_terminate_backend
         // rather than stop/restart the container. This is deterministic: the LISTEN session
@@ -62,7 +56,7 @@ public async Task ListenConnectionKilled_DuringPublisherRunning_EmitsDisconnectT
         // and the test is not at the mercy of Docker stop/start timing.
         var channel = $"channel_kill_{Guid.NewGuid():N}";
         await using var ctx = await BuildPublisherAsync(channel,
-            recovery: new ConnectionRecoveryOptions
+            recovery: new PostgresConnectionRecoveryOptions
             {
                 InitialDelay   = TimeSpan.FromMilliseconds(200),
                 MaxDelay       = TimeSpan.FromSeconds(2),
@@ -74,36 +68,19 @@ public async Task ListenConnectionKilled_DuringPublisherRunning_EmitsDisconnectT
         await ctx.Outbox.WriteAsync(SampleChange(1));
         await ctx.Publisher.StartAsync();
 
-        // Drain the pre-kill message so the post-recovery assertion is unambiguous.
+        // Drain the pre-kill message so the post-recovery assertion is unambiguous. Receiving it
+        // also proves the publisher is up and delivering before we kill the LISTEN backend.
         using (var cts = new CancellationTokenSource(TimeSpan.FromSeconds(10)))
             await ctx.Queue.Reader.ReadAsync(cts.Token);
 
-        // Wait until the state gauge reports 1 (LISTEN successfully attached). Polling
-        // is deterministic and exits as soon as ListenLoopAsync flips _listenerHealthy.
-        await WaitForAsync(
-            () => { _capture.RecordObservableInstruments();
-                    return _capture.LatestGaugeOf("raytree.connection.state", "postgres.notification") == 1; },
-            TimeSpan.FromSeconds(5),
-            "LISTEN session attached (gauge reports 1)");
-
         // Act — terminate the listener's backend process. pg_terminate_backend kills the
         // backend and closes the TCP connection so WaitAsync surfaces the drop on the next
         // network read (typically within a few hundred ms).
         await TerminateListenBackendsAsync(channel);
 
-        await WaitForAsync(
-            () => _capture.SumOf("raytree.connection.disconnects", "postgres.notification") >= 1,
-            TimeSpan.FromSeconds(15),
-            "disconnect metric on LISTEN drop");
-
-        await WaitForAsync(
-            () => _capture.SumOf("raytree.connection.recoveries", "postgres.notification", outcome: "succeeded") >= 1,
-            TimeSpan.FromSeconds(15),
-            "succeeded recovery after LISTEN reconnect");
-
         // Assert — a post-recovery message is delivered (NOTIFY fast-path or fallback poll).
         await ctx.Outbox.WriteAsync(SampleChange(2));
-        using (var cts = new CancellationTokenSource(TimeSpan.FromSeconds(15)))
+        using (var cts = new CancellationTokenSource(TimeSpan.FromSeconds(20)))
         {
             var received = await ctx.Queue.Reader.ReadAsync(cts.Token);
             Assert.That(received.EntityId, Is.EqualTo("2"));
@@ -147,11 +124,11 @@ FROM pg_stat_activity
     }
 
     [Test]
-    public async Task PermanentKill_WithMaxAttempts2_EmitsExhaustedRecovery_AndExitsListenLoop()
+    public async Task PermanentKill_WithMaxAttempts2_ExitsListenLoop()
     {
         var channel = $"channel_exhaust_{Guid.NewGuid():N}";
         await using var ctx = await BuildPublisherAsync(channel,
-            recovery: new ConnectionRecoveryOptions
+            recovery: new PostgresConnectionRecoveryOptions
             {
                 InitialDelay   = TimeSpan.FromMilliseconds(100),
                 MaxDelay       = TimeSpan.FromMilliseconds(200),
@@ -165,16 +142,11 @@ public async Task PermanentKill_WithMaxAttempts2_EmitsExhaustedRecovery_AndExits
         // Kill the container permanently — DisposeAsync removes it entirely.
         await _postgres.DisposeAsync();
 
-        // The disconnect should fire (LISTEN breaks), then two reconnect attempts both fail,
-        // then the exhausted recovery is emitted and the listen loop exits.
+        // The LISTEN breaks, two reconnect attempts both fail, then the listen loop exits.
         await WaitForAsync(
-            () => _capture.SumOf("raytree.connection.recoveries", "postgres.notification", outcome: "exhausted") >= 1,
+            () => !ctx.Publisher.IsRunning,
             TimeSpan.FromSeconds(30),
-            "exhausted recovery after MaxAttempts=2");
-
-        Assert.That(_capture.SumOf("raytree.connection.disconnects", "postgres.notification"),
-            Is.GreaterThanOrEqualTo(1),
-            "disconnect must precede exhausted recovery");
+            "ListenLoopAsync to exit after MaxAttempts=2 exhausted");
 
         await ctx.Publisher.StopAsync();
     }
@@ -188,45 +160,33 @@ public async Task RecoveryDisabled_DoesNotReconnect_AfterListenConnectionKilled(
         // process restart, by design.
         var channel = $"channel_disabled_{Guid.NewGuid():N}";
         await using var ctx = await BuildPublisherAsync(channel,
-            recovery: new ConnectionRecoveryOptions { Enabled = false });
+            recovery: new PostgresConnectionRecoveryOptions { Enabled = false });
 
+        await ctx.Outbox.WriteAsync(SampleChange(1));
         await ctx.Publisher.StartAsync();
 
-        // Poll until LISTEN attaches (gauge = 1) instead of a fixed warm-up delay.
-        await WaitForAsync(
-            () => { _capture.RecordObservableInstruments();
-                    return _capture.LatestGaugeOf("raytree.connection.state", "postgres.notification") == 1; },
-            TimeSpan.FromSeconds(5),
-            "LISTEN session attached");
+        // Receiving the first message proves the publisher is up and delivering.
+        using (var cts = new CancellationTokenSource(TimeSpan.FromSeconds(10)))
+            await ctx.Queue.Reader.ReadAsync(cts.Token);
 
         await TerminateListenBackendsAsync(channel);
 
         // With Enabled = false, ListenLoopAsync exits on the first fault. Wait until the
-        // task is done — at that point we have a strong invariant that no further
-        // recovery metrics CAN fire. Replaces a 2s blind delay with a polling check that
-        // exits as soon as the loop is provably done (typically within a few hundred ms).
+        // listen task is done — at that point the LISTEN fast-path is provably cold.
         await WaitForAsync(
             () => !ctx.Publisher.IsRunning,
             TimeSpan.FromSeconds(10),
             "ListenLoopAsync to exit (Enabled = false short-circuits reconnect)");
 
-        // Assert: disconnect fired, no recovery (succeeded or exhausted) was attempted.
-        Assert.That(_capture.SumOf("raytree.connection.disconnects", "postgres.notification"), Is.GreaterThanOrEqualTo(1),
-            "disconnect SHALL still be observed even with recovery disabled");
-        Assert.That(_capture.SumOf("raytree.connection.recoveries", "postgres.notification", outcome: "succeeded"),
-            Is.EqualTo(0), "Enabled = false SHALL skip reconnect — no succeeded recovery");
-        Assert.That(_capture.SumOf("raytree.connection.recoveries", "postgres.notification", outcome: "exhausted"),
-            Is.EqualTo(0), "Enabled = false SHALL skip reconnect — no exhausted recovery");
-
         await ctx.Publisher.StopAsync();
     }
 
     [Test]
-    public async Task OutboxOperations_DuringContainerStop_EmitPostgresOutboxDisconnect_ThenRecoveryOnRestart()
+    public async Task OutboxOperations_DuringContainerStop_ClassifiesConnectionFault()
     {
-        // 4b.5: cover the postgres.outbox observability path independently of postgres.notification.
-        // We exercise it directly via PostgreSqlOutbox calls (which is what OutboxPublisherService
-        // does internally) so the test is deterministic without standing up a full tracker.
+        // Cover the postgres.outbox connection-fault classification independently of
+        // postgres.notification. OutboxPublisherService relies on IsConnectionFault to demote
+        // its batch-error log from Error to Warning — verify the classifier here directly.
         var outbox = new PostgreSqlOutbox<TestEntity>(new PostgreSqlOutboxOptions
         {
             ConnectionString = _connectionString,
@@ -238,9 +198,8 @@ public async Task OutboxOperations_DuringContainerStop_EmitPostgresOutboxDisconn
         Assert.That(outbox.ConnectionComponent, Is.EqualTo("postgres.outbox"));
         Assert.That(outbox.ConnectionEndpoint,  Is.Not.Null.And.Contains(":"));
 
-        // Healthy call — no metric expected because we haven't simulated a fault.
+        // Healthy call — must not throw.
         await outbox.WriteAsync(SampleChange(1));
-        Assert.That(_capture.SumOf("raytree.connection.disconnects", "postgres.outbox"), Is.EqualTo(0));
 
         // Stop the container; the next outbox call should fail with a connection-classified exception.
         await _postgres.StopAsync();
@@ -252,12 +211,12 @@ public async Task OutboxOperations_DuringContainerStop_EmitPostgresOutboxDisconn
         Assert.That(thrown, Is.Not.Null, "Outbox write should throw when Postgres is stopped");
         Assert.That(outbox.IsConnectionFault(thrown!), Is.True,
             "The thrown exception SHALL be classified as a connection fault — that's the contract " +
-            "OutboxPublisherService relies on to emit the postgres.outbox disconnect metric.");
+            "OutboxPublisherService relies on to demote its batch-error log.");
     }
 
     // ---- helpers --------------------------------------------------------
 
-    private async Task<PublisherContext> BuildPublisherAsync(string channel, ConnectionRecoveryOptions recovery)
+    private async Task<PublisherContext> BuildPublisherAsync(string channel, PostgresConnectionRecoveryOptions recovery)
     {
         var queue = new InMemoryQueue();
         var outbox = new PostgreSqlOutbox<TestEntity>(new PostgreSqlOutboxOptions
@@ -270,7 +229,6 @@ private async Task<PublisherContext> BuildPublisherAsync(string channel, Connect
         await outbox.InitializeAsync();
 
         var tracker = EntityChangeTracker.Create()
-            .UseMeter(_meter)
             .ForEntity<TestEntity>(e => e
                 .UseOutbox(outbox)
                 .UsePublisher(queue)
@@ -333,68 +291,4 @@ public async ValueTask DisposeAsync()
             Tracker.Dispose();
         }
     }
-
-    /// <summary>
-    /// Filtered MeterListener — capture lives in-process for the duration of one test and tags
-    /// every measurement with its `component` / `outcome` tags so the assertions read like prose.
-    /// </summary>
-    private sealed class CapturingMeterListener : IDisposable
-    {
-        private readonly MeterListener _listener;
-        private readonly List<Recorded> _measurements = new();
-        private readonly object _gate = new();
-
-        public CapturingMeterListener(RayTreeMeter meter)
-        {
-            var owner = meter.InternalMeter;
-            _listener = new MeterListener
-            {
-                InstrumentPublished = (instrument, l) =>
-                {
-                    if (ReferenceEquals(instrument.Meter, owner)) l.EnableMeasurementEvents(instrument);
-                }
-            };
-            _listener.SetMeasurementEventCallback<long>  ((i, v, t, _) => Append(i, v, t));
-            _listener.SetMeasurementEventCallback<int>   ((i, v, t, _) => Append(i, v, t));
-            _listener.SetMeasurementEventCallback<double>((i, v, t, _) => Append(i, v, t));
-            _listener.Start();
-        }
-
-        private void Append(Instrument instrument, double value, ReadOnlySpan<KeyValuePair<string, object?>> tags)
-        {
-            string? component = null, outcome = null;
-            foreach (var kv in tags)
-            {
-                if (kv.Key == "component") component = kv.Value as string;
-                else if (kv.Key == "outcome")   outcome   = kv.Value as string;
-            }
-            lock (_gate) _measurements.Add(new Recorded(instrument.Name, value, component, outcome));
-        }
-
-        public double SumOf(string instrumentName, string component, string? outcome = null)
-        {
-            lock (_gate)
-                return _measurements
-                    .Where(m => m.Name == instrumentName && m.Component == component
-                                && (outcome is null || m.Outcome == outcome))
-                    .Sum(m => m.Value);
-        }
-
-        /// <summary>Forces the observable gauges to emit. Used to deterministically sample the
-        /// connection-state gauge inside a polling helper instead of relying on a sleep.</summary>
-        public void RecordObservableInstruments() => _listener.RecordObservableInstruments();
-
-        public double? LatestGaugeOf(string instrumentName, string component)
-        {
-            lock (_gate)
-            {
-                var hit = _measurements.LastOrDefault(m => m.Name == instrumentName && m.Component == component);
-                return hit.Name is null ? null : hit.Value;
-            }
-        }
-
-        public void Dispose() => _listener.Dispose();
-
-        private readonly record struct Recorded(string Name, double Value, string? Component, string? Outcome);
-    }
 }
diff --git a/tests/RayTree.Plugins.PostgreSQL.Tests/PostgresConnectionRecoveryOptionsTests.cs b/tests/RayTree.Plugins.PostgreSQL.Tests/PostgresConnectionRecoveryOptionsTests.cs
new file mode 100644
index 0000000..ae2ba38
--- /dev/null
+++ b/tests/RayTree.Plugins.PostgreSQL.Tests/PostgresConnectionRecoveryOptionsTests.cs
@@ -0,0 +1,133 @@
+using RayTree.Plugins.PostgreSQL.Resilience;
+
+namespace RayTree.Plugins.PostgreSQL.Tests;
+
+[TestFixture]
+public class PostgresConnectionRecoveryOptionsTests
+{
+    [Test]
+    public void Defaults_MatchSpec()
+    {
+        var options = new PostgresConnectionRecoveryOptions();
+
+        Assert.That(options.Enabled,        Is.True);
+        Assert.That(options.InitialDelay,   Is.EqualTo(TimeSpan.FromSeconds(1)));
+        Assert.That(options.MaxDelay,       Is.EqualTo(TimeSpan.FromSeconds(30)));
+        Assert.That(options.Factor,         Is.EqualTo(2.0));
+        Assert.That(options.JitterFraction, Is.EqualTo(0.2));
+        Assert.That(options.MaxAttempts,    Is.Null);
+    }
+
+    [Test]
+    public void Defaults_ValidateDoesNotThrow()
+    {
+        var options = new PostgresConnectionRecoveryOptions();
+        Assert.DoesNotThrow(() => options.Validate());
+    }
+
+    [Test]
+    public void InitialDelay_Zero_Throws()
+    {
+        var ex = Assert.Throws<ArgumentOutOfRangeException>(
+            () => _ = new PostgresConnectionRecoveryOptions { InitialDelay = TimeSpan.Zero });
+        Assert.That(ex!.ParamName, Is.EqualTo("InitialDelay"));
+    }
+
+    [Test]
+    public void InitialDelay_Negative_Throws()
+    {
+        Assert.Throws<ArgumentOutOfRangeException>(
+            () => _ = new PostgresConnectionRecoveryOptions { InitialDelay = TimeSpan.FromSeconds(-1) });
+    }
+
+    [Test]
+    public void MaxDelay_Zero_Throws()
+    {
+        var ex = Assert.Throws<ArgumentOutOfRangeException>(
+            () => _ = new PostgresConnectionRecoveryOptions { MaxDelay = TimeSpan.Zero });
+        Assert.That(ex!.ParamName, Is.EqualTo("MaxDelay"));
+    }
+
+    [Test]
+    public void MaxDelay_LessThanInitialDelay_ValidateThrows()
+    {
+        var options = new PostgresConnectionRecoveryOptions
+        {
+            InitialDelay = TimeSpan.FromSeconds(10),
+            MaxDelay     = TimeSpan.FromSeconds(5)
+        };
+
+        var ex = Assert.Throws<ArgumentOutOfRangeException>(() => options.Validate());
+        Assert.That(ex!.ParamName, Is.EqualTo("MaxDelay"));
+    }
+
+    [Test]
+    public void Factor_LessThanOne_Throws()
+    {
+        var ex = Assert.Throws<ArgumentOutOfRangeException>(
+            () => _ = new PostgresConnectionRecoveryOptions { Factor = 0.5 });
+        Assert.That(ex!.ParamName, Is.EqualTo("Factor"));
+    }
+
+    [Test]
+    public void Factor_Exactly1_Allowed()
+    {
+        Assert.DoesNotThrow(() => _ = new PostgresConnectionRecoveryOptions { Factor = 1.0 });
+    }
+
+    [Test]
+    public void JitterFraction_Negative_Throws()
+    {
+        var ex = Assert.Throws<ArgumentOutOfRangeException>(
+            () => _ = new PostgresConnectionRecoveryOptions { JitterFraction = -0.1 });
+        Assert.That(ex!.ParamName, Is.EqualTo("JitterFraction"));
+    }
+
+    [Test]
+    public void JitterFraction_GreaterThanOne_Throws()
+    {
+        var ex = Assert.Throws<ArgumentOutOfRangeException>(
+            () => _ = new PostgresConnectionRecoveryOptions { JitterFraction = 1.5 });
+        Assert.That(ex!.ParamName, Is.EqualTo("JitterFraction"));
+    }
+
+    [Test]
+    public void JitterFraction_Zero_Allowed()
+    {
+        Assert.DoesNotThrow(() => _ = new PostgresConnectionRecoveryOptions { JitterFraction = 0.0 });
+    }
+
+    [Test]
+    public void JitterFraction_One_Allowed()
+    {
+        Assert.DoesNotThrow(() => _ = new PostgresConnectionRecoveryOptions { JitterFraction = 1.0 });
+    }
+
+    [Test]
+    public void MaxAttempts_Zero_Throws()
+    {
+        var ex = Assert.Throws<ArgumentOutOfRangeException>(
+            () => _ = new PostgresConnectionRecoveryOptions { MaxAttempts = 0 });
+        Assert.That(ex!.ParamName, Is.EqualTo("MaxAttempts"));
+    }
+
+    [Test]
+    public void MaxAttempts_Negative_Throws()
+    {
+        Assert.Throws<ArgumentOutOfRangeException>(
+            () => _ = new PostgresConnectionRecoveryOptions { MaxAttempts = -3 });
+    }
+
+    [Test]
+    public void MaxAttempts_Null_Allowed()
+    {
+        Assert.DoesNotThrow(() => _ = new PostgresConnectionRecoveryOptions { MaxAttempts = null });
+    }
+
+    [Test]
+    public void MaxAttempts_Positive_Allowed()
+    {
+        var options = new PostgresConnectionRecoveryOptions { MaxAttempts = 5 };
+        Assert.That(options.MaxAttempts, Is.EqualTo(5));
+    }
+}
diff --git a/tests/RayTree.Plugins.RabbitMQ.Tests/RabbitMqRecoveryMetricsTests.cs b/tests/RayTree.Plugins.RabbitMQ.Tests/RabbitMqRecoveryMetricsTests.cs
deleted file mode 100644
index b06c03e..0000000
--- a/tests/RayTree.Plugins.RabbitMQ.Tests/RabbitMqRecoveryMetricsTests.cs
+++ /dev/null
@@ -1,179 +0,0 @@
-using System.Diagnostics.Metrics;
-using RayTree.Core.Telemetry;
-using Testcontainers.RabbitMq;
-
-namespace RayTree.Plugins.RabbitMQ.Tests;
-
-/// <summary>
-/// Verifies the RabbitMQ plugin's event-hook observability surface. RayTree does NOT own
-/// the recovery code for RabbitMQ — <c>AutomaticRecoveryEnabled = true</c> (library default)
-/// performs the rebuild. The plugin subscribes to <c>ConnectionShutdownAsync</c> /
-/// <c>RecoverySucceededAsync</c> / <c>ConnectionRecoveryErrorAsync</c> to emit the shared
-/// <c>raytree.connection.*</c> metrics. These tests exercise that wire-up against a real broker.
-/// </summary>
-[NonParallelizable]
-public class RabbitMqRecoveryMetricsTests : IAsyncDisposable
-{
-    private readonly RabbitMqContainer _rabbitMq = new RabbitMqBuilder("rabbitmq:4.3.0-alpine").Build();
-    private RayTreeMeter _meter = null!;
-    private CapturingMeterListener _capture = null!;
-
-    [OneTimeSetUp]
-    public Task OneTimeSetUp() => _rabbitMq.StartAsync();
-
-    [SetUp]
-    public void SetUp()
-    {
-        _meter = new RayTreeMeter();
-        _capture = new CapturingMeterListener(_meter);
-    }
-
-    [TearDown]
-    public void TearDown()
-    {
-        _capture.Dispose();
-        _meter.Dispose();
-    }
-
-    public async ValueTask DisposeAsync() => await _rabbitMq.DisposeAsync();
-
-    private RabbitMqPublisher BuildPublisher() => new(new RabbitMqPublisherOptions
-    {
-        HostName        = _rabbitMq.Hostname,
-        Port            = _rabbitMq.GetMappedPublicPort(5672),
-        UserName        = RabbitMqBuilder.DefaultUsername,
-        Password        = RabbitMqBuilder.DefaultPassword,
-        ExchangeName    = "recovery_metrics_test",
-        ExchangeType    = "topic",
-        DeclareExchange = true
-    }, loggerFactory: null, meter: _meter);
-
-    private RabbitMqConsumer BuildConsumer() => new(new RabbitMqConsumerOptions
-    {
-        HostName     = _rabbitMq.Hostname,
-        Port         = _rabbitMq.GetMappedPublicPort(5672),
-        UserName     = RabbitMqBuilder.DefaultUsername,
-        Password     = RabbitMqBuilder.DefaultPassword,
-        QueueName    = $"recovery_q_{Guid.NewGuid():N}",
-        DeclareQueue = true
-    }, meter: _meter);
-
-    [Test]
-    public async Task BrokerForcesConnectionClose_EmitsDisconnect_ThenRecoverySucceeded()
-    {
-        // We can't simply Stop+Start the container — Testcontainers reassigns the mapped
-        // public port on restart, so the library auto-recovery (which holds the original
-        // host:port) has nothing to reconnect to. Instead, ask the broker itself to close
-        // the AMQP connections via `rabbitmqctl close_all_connections`. The TCP connection
-        // dies (library observes ConnectionShutdownAsync with non-Application initiator),
-        // the broker stays up on the same port, the SDK reconnects, and
-        // RecoverySucceededAsync fires.
-
-        using var publisher = BuildPublisher();
-        await publisher.InitializeAsync();
-
-        using var consumer = BuildConsumer();
-        await consumer.InitializeAsync();
-
-        // Brief settle for RabbitMqConsumer's async BasicConsume registration. Polling
-        // here would require a public IsConnected accessor we don't currently expose.
-        await Task.Delay(200);
-
-        // Act — broker-driven close. The 'test' string is the rabbitmqctl reason.
-        var result = await _rabbitMq.ExecAsync(new[] {
-            "rabbitmqctl", "close_all_connections", "raytree-recovery-test"
-        });
-        Assert.That(result.ExitCode, Is.EqualTo(0), $"rabbitmqctl exit code: stderr={result.Stderr}");
-
-        // Assert — disconnect is observed on both ends, recovery follows.
-        await WaitForAsync(
-            () => _capture.SumOf("raytree.connection.disconnects", "rabbitmq.publisher") >= 1
-               && _capture.SumOf("raytree.connection.disconnects", "rabbitmq.consumer")  >= 1,
-            TimeSpan.FromSeconds(30),
-            "publisher and consumer disconnect metrics");
-
-        await WaitForAsync(
-            () => _capture.SumOf("raytree.connection.recoveries", "rabbitmq.publisher", "succeeded") >= 1
-               && _capture.SumOf("raytree.connection.recoveries", "rabbitmq.consumer",  "succeeded") >= 1,
-            TimeSpan.FromSeconds(60),
-            "publisher and consumer recovery metrics");
-    }
-
-    [Test]
-    public async Task ApplicationInitiatedDispose_DoesNotEmitDisconnect()
-    {
-        // Arrange
-        var publisher = BuildPublisher();
-        await publisher.InitializeAsync();
-
-        // Act — clean dispose; the SDK fires ConnectionShutdownAsync with Initiator=Application.
-        publisher.Dispose();
-        await Task.Delay(100);   // brief settle window for the shutdown handler
-
-        // Assert — the publisher MUST NOT count its own clean teardown as a recovery event.
-        // (Otherwise dashboards would show a spurious disconnect every time a host shuts down.)
-        Assert.That(_capture.SumOf("raytree.connection.disconnects", "rabbitmq.publisher"), Is.EqualTo(0),
-            "ConnectionShutdownAsync with Initiator=Application must not emit disconnect");
-    }
-
-    // ---- helpers --------------------------------------------------------
-
-    private static async Task WaitForAsync(Func<bool> condition, TimeSpan timeout, string what)
-    {
-        var sw = System.Diagnostics.Stopwatch.StartNew();
-        while (sw.Elapsed < timeout)
-        {
-            if (condition()) return;
-            await Task.Delay(200);
-        }
-        throw new TimeoutException($"Timed out waiting for: {what}");
-    }
-
-    private sealed class CapturingMeterListener : IDisposable
-    {
-        private readonly MeterListener _listener;
-        private readonly List<Recorded> _measurements = new();
-        private readonly object _gate = new();
-
-        public CapturingMeterListener(RayTreeMeter meter)
-        {
-            _ = meter;   // accepted for future scoping; we filter by meter name (public)
-            _listener = new MeterListener
-            {
-                InstrumentPublished = (instrument, l) =>
-                {
-                    if (instrument.Meter.Name == RayTreeMeter.MeterName)
-                        l.EnableMeasurementEvents(instrument);
-                }
-            };
-            _listener.SetMeasurementEventCallback<long>  ((i, v, t, _) => Append(i, v, t));
-            _listener.SetMeasurementEventCallback<int>   ((i, v, t, _) => Append(i, v, t));
-            _listener.SetMeasurementEventCallback<double>((i, v, t, _) => Append(i, v, t));
-            _listener.Start();
-        }
-
-        private void Append(Instrument instrument, double value, ReadOnlySpan<KeyValuePair<string, object?>> tags)
-        {
-            string? component = null, outcome = null;
-            foreach (var kv in tags)
-            {
-                if      (kv.Key == "component") component = kv.Value as string;
-                else if (kv.Key == "outcome")   outcome   = kv.Value as string;
-            }
-            lock (_gate) _measurements.Add(new Recorded(instrument.Name, value, component, outcome));
-        }
-
-        public double SumOf(string instrumentName, string component, string? outcome = null)
-        {
-            lock (_gate)
-                return _measurements
-                    .Where(m => m.Name == instrumentName && m.Component == component
-                                && (outcome is null || m.Outcome == outcome))
-                    .Sum(m => m.Value);
-        }
-
-        public void Dispose() => _listener.Dispose();
-
-        private readonly record struct Recorded(string Name, double Value, string? Component, string? Outcome);
-    }
-}