dsh-env-manager-plugin 0.1.0 → 0.1.1

package/docs/02-harness/verification-policy.md

@@ -1,97 +1,97 @@
-# Verification Policy
-
-Every implementation task must include at least one of:
-
-- unit tests for pure logic
-- integration tests for storage / registry / tools
-- a manual UI checklist
-- a contract check against a fixture
-
-## Required by module
-
-### `domain`
-
-- Valid record accepted; unknown field rejected
-- Id pattern and `schemaVersion` enforced
-- Discriminated union rejects mismatched runtime/location
-- `parseRecordInput` accepts omitted timestamps; `finalizeRecord` stamps them
-
-### `storage`
-
-- Atomic write/read round trip
-- No temp file left after success or a caught failure
-- Missing directory handled
-- Invalid YAML skipped with diagnostic, file kept
-- Backup pruning (max 5)
-
-### `registry`
-
-- Load and lookup
-- Duplicate id detection
-- Broken reference detection for every reference kind
-- Reload after write reflects the change
-- Concurrent loads share one in-flight scan
-
-### `resolver`
-
-- Layer precedence
-- Field-level merge
-- Provenance for the worked example
-- Undefined variable, cycle, path traversal, type mismatch, malformed template
-- Only runtime-applicable log source and class location resolved
-
-### `router`
-
-- Every match level
-- Highest-level selection
-- Same-level conflict
-- Skill availability: present, missing, source mismatch, provider mismatch,
-  registry unavailable or incomplete
-- Production policy and approval defaults
-- Parameter mapping failures
-
-### `session`
-
-- Set, get, clear
-- Cross-session isolation
-- Corrupt state treated as "no default", `persisted: false`
-
-### `app`
-
-- Save→get round trip
-- Delete refused while referenced
-- Dry-run writes nothing
-- UI actor production denial
-
-### `tools`
-
-- Returned value matches the declared `output.schema`
-- Expected failures throw `EnvManagerError` with the right code
-- No credential value in serialized output
-- `env_validate` is read-only
-- Approval denial changes nothing on disk
-
-### `transport`
-
-- Header, origin, method and size rejection
-- Status mapping for each error class
-- Production UI write denied by default
-- No stack trace or file path in the response body
-
-### Client UI (manual)
-
-- Panels load with empty and populated registries
-- Create/edit/delete round trip through the HTTP API
-- Rule preview shows provenance
-- Conflict warning appears for same-level bindings
-- Production actions are visually distinct and confirmed
-- Locale switches between `en` and `zh`
-- Full checklist: `docs/01-architecture/ui-design.md` §12
-
-## Evidence to record
-
-For each completed task, `current-state.md` should state what was verified and what remains manual.
-
-## Regression rule
-
-A bugfix must add a test that fails before the fix and passes after it, unless the defect is UI-only.
+# Verification Policy
+
+Every implementation task must include at least one of:
+
+- unit tests for pure logic
+- integration tests for storage / registry / tools
+- a manual UI checklist
+- a contract check against a fixture
+
+## Required by module
+
+### `domain`
+
+- Valid record accepted; unknown field rejected
+- Id pattern and `schemaVersion` enforced
+- Discriminated union rejects mismatched runtime/location
+- `parseRecordInput` accepts omitted timestamps; `finalizeRecord` stamps them
+
+### `storage`
+
+- Atomic write/read round trip
+- No temp file left after success or a caught failure
+- Missing directory handled
+- Invalid YAML skipped with diagnostic, file kept
+- Backup pruning (max 5)
+
+### `registry`
+
+- Load and lookup
+- Duplicate id detection
+- Broken reference detection for every reference kind
+- Reload after write reflects the change
+- Concurrent loads share one in-flight scan
+
+### `resolver`
+
+- Layer precedence
+- Field-level merge
+- Provenance for the worked example
+- Undefined variable, cycle, path traversal, type mismatch, malformed template
+- Only runtime-applicable log source and class location resolved
+
+### `router`
+
+- Every match level
+- Highest-level selection
+- Same-level conflict
+- Skill availability: present, missing, source mismatch, provider mismatch,
+  registry unavailable or incomplete
+- Production policy and approval defaults
+- Parameter mapping failures
+
+### `session`
+
+- Set, get, clear
+- Cross-session isolation
+- Corrupt state treated as "no default", `persisted: false`
+
+### `app`
+
+- Save→get round trip
+- Delete refused while referenced
+- Dry-run writes nothing
+- UI actor production denial
+
+### `tools`
+
+- Returned value matches the declared `output.schema`
+- Expected failures throw `EnvManagerError` with the right code
+- No credential value in serialized output
+- `env_validate` is read-only
+- Approval denial changes nothing on disk
+
+### `transport`
+
+- Header, origin, method and size rejection
+- Status mapping for each error class
+- Production UI write denied by default
+- No stack trace or file path in the response body
+
+### Client UI (manual)
+
+- Panels load with empty and populated registries
+- Create/edit/delete round trip through the HTTP API
+- Rule preview shows provenance
+- Conflict warning appears for same-level bindings
+- Production actions are visually distinct and confirmed
+- Locale switches between `en` and `zh`
+- Full checklist: `docs/01-architecture/ui-design.md` §12
+
+## Evidence to record
+
+For each completed task, `current-state.md` should state what was verified and what remains manual.
+
+## Regression rule
+
+A bugfix must add a test that fails before the fix and passes after it, unless the defect is UI-only.

package/docs/03-openspec/archive-rule.md

@@ -1,25 +1,25 @@
-# Archive Rule
-
-Completed or superseded proposals and designs must be archived in `docs/99-archive/`.
-
-## When to Archive
-
-- A proposal is implemented and verified.
-- A design is superseded by a new one.
-- A spike or experiment is abandoned.
-
-## Format
-
-Prefix archived files with date:
-
-```text
-docs/99-archive/YYYY-MM-DD-proposal-name.md
-```
-
-## Content
-
-Each archived file must include:
-
-- Original title and date
-- Reason for archiving
-- Link to the current approach (if superseded)
+# Archive Rule
+
+Completed or superseded proposals and designs must be archived in `docs/99-archive/`.
+
+## When to Archive
+
+- A proposal is implemented and verified.
+- A design is superseded by a new one.
+- A spike or experiment is abandoned.
+
+## Format
+
+Prefix archived files with date:
+
+```text
+docs/99-archive/YYYY-MM-DD-proposal-name.md
+```
+
+## Content
+
+Each archived file must include:
+
+- Original title and date
+- Reason for archiving
+- Link to the current approach (if superseded)

package/docs/03-openspec/bugfix-rule.md

@@ -1,30 +1,30 @@
-# Bugfix Rule
-
-A bugfix addresses a specific, reproducible defect.
-
-## Required Sections
-
-### 1. Symptom
-
-What went wrong.
-
-### 2. Root Cause
-
-Why it happened.
-
-### 3. Fix
-
-What changed.
-
-### 4. Regression Test
-
-Test that prevents recurrence.
-
-### 5. Verification
-
-How to confirm the fix.
-
-## Rules
-
-- Include a regression test unless the bug is UI-only.
-- Update `current-state.md` if the bug affects implemented features.
+# Bugfix Rule
+
+A bugfix addresses a specific, reproducible defect.
+
+## Required Sections
+
+### 1. Symptom
+
+What went wrong.
+
+### 2. Root Cause
+
+Why it happened.
+
+### 3. Fix
+
+What changed.
+
+### 4. Regression Test
+
+Test that prevents recurrence.
+
+### 5. Verification
+
+How to confirm the fix.
+
+## Rules
+
+- Include a regression test unless the bug is UI-only.
+- Update `current-state.md` if the bug affects implemented features.

package/docs/03-openspec/design-rule.md

@@ -1,33 +1,33 @@
-# Design Rule
-
-A design document explains how a feature will be built.
-
-## Required Sections
-
-### 1. Overview
-
-What is being designed and why.
-
-### 2. Data Flow
-
-Step-by-step flow with input/output boundaries.
-
-### 3. Module Allocation
-
-Which modules are involved and what each owns.
-
-### 4. Schema Changes
-
-New or changed YAML/JSON schemas.
-
-### 5. Security Considerations
-
-Credential handling, approval policies, production access.
-
-### 6. Error Handling
-
-Expected failure modes and responses.
-
-### 7. Verification Plan
-
-Tests and manual checks.
+# Design Rule
+
+A design document explains how a feature will be built.
+
+## Required Sections
+
+### 1. Overview
+
+What is being designed and why.
+
+### 2. Data Flow
+
+Step-by-step flow with input/output boundaries.
+
+### 3. Module Allocation
+
+Which modules are involved and what each owns.
+
+### 4. Schema Changes
+
+New or changed YAML/JSON schemas.
+
+### 5. Security Considerations
+
+Credential handling, approval policies, production access.
+
+### 6. Error Handling
+
+Expected failure modes and responses.
+
+### 7. Verification Plan
+
+Tests and manual checks.

package/docs/03-openspec/openspec-usage-guide.md

@@ -1,31 +1,31 @@
-# OpenSpec Usage Guide
-
-Use OpenSpec artifacts to plan and track changes.
-
-## Artifact Types
-
-- **Proposal**: Why and what we will change.
-- **Design**: How we will build it.
-- **Spec**: Detailed implementation contract.
-- **Tasks**: Small, verifiable work items.
-- **Bugfix**: Specific defect resolution.
-
-## Workflow
-
-1. Create a proposal in `docs/03-openspec/proposals/` (or similar).
-2. Once accepted, write a design in `docs/01-architecture/designs/` (or update `design.md`).
-3. Turn the design into a spec.
-4. Break into tasks.
-5. Implement, verify, archive.
-
-## Naming
-
-- Proposals: `proposal-{short-name}.md`
-- Designs: `design-{short-name}.md`
-- Specs: `spec-{short-name}.md`
-- Tasks: embedded in implementation issue or PR description
-- Bugfixes: `bugfix-{short-name}.md`
-
-## Review
-
-Every OpenSpec artifact should be reviewed before implementation.
+# OpenSpec Usage Guide
+
+Use OpenSpec artifacts to plan and track changes.
+
+## Artifact Types
+
+- **Proposal**: Why and what we will change.
+- **Design**: How we will build it.
+- **Spec**: Detailed implementation contract.
+- **Tasks**: Small, verifiable work items.
+- **Bugfix**: Specific defect resolution.
+
+## Workflow
+
+1. Create a proposal in `docs/03-openspec/proposals/` (or similar).
+2. Once accepted, write a design in `docs/01-architecture/designs/` (or update `design.md`).
+3. Turn the design into a spec.
+4. Break into tasks.
+5. Implement, verify, archive.
+
+## Naming
+
+- Proposals: `proposal-{short-name}.md`
+- Designs: `design-{short-name}.md`
+- Specs: `spec-{short-name}.md`
+- Tasks: embedded in implementation issue or PR description
+- Bugfixes: `bugfix-{short-name}.md`
+
+## Review
+
+Every OpenSpec artifact should be reviewed before implementation.

package/docs/03-openspec/proposal-rule.md

@@ -1,70 +1,70 @@
-# Proposal Rule
-
-A proposal must explain why the change is needed and what it changes.
-
-## Required Sections
-
-### 1. Problem
-
-Describe the user-visible or engineering problem.
-
-### 2. Goal
-
-Describe the intended outcome.
-
-### 3. Scope
-
-List what is included.
-
-### 4. Out of Scope
-
-List what is explicitly excluded.
-
-### 5. Affected Modules
-
-Choose from:
-
-- tools
-- domain
-- config
-- storage
-- registry
-- resolver
-- router
-- session
-- memory-bridge
-- client
-- docs
-
-### 6. Storage Impact
-
-State whether the change affects:
-
-- `data/environments/*.yaml`
-- `data/services/*.yaml`
-- `data/deployments/*.yaml`
-- `data/rules/*.yaml`
-- `data/operations/*.yaml`
-- `data/sessions/*.json`
-- `schemaVersion` (record compatibility)
-
-### 7. Constraints
-
-Must confirm:
-
-- No plain-text credentials introduced.
-- No arbitrary code execution in rule templates.
-- No auto-apply of production changes.
-- File-based source of truth remains unchanged.
-
-### 8. Risks
-
-List implementation risks.
-
-### 9. Verification
-
-Describe how to verify.
-
-## Proposal Quality Bar
-
-A good proposal is small enough to implement and test in one focused change.
+# Proposal Rule
+
+A proposal must explain why the change is needed and what it changes.
+
+## Required Sections
+
+### 1. Problem
+
+Describe the user-visible or engineering problem.
+
+### 2. Goal
+
+Describe the intended outcome.
+
+### 3. Scope
+
+List what is included.
+
+### 4. Out of Scope
+
+List what is explicitly excluded.
+
+### 5. Affected Modules
+
+Choose from:
+
+- tools
+- domain
+- config
+- storage
+- registry
+- resolver
+- router
+- session
+- memory-bridge
+- client
+- docs
+
+### 6. Storage Impact
+
+State whether the change affects:
+
+- `data/environments/*.yaml`
+- `data/services/*.yaml`
+- `data/deployments/*.yaml`
+- `data/rules/*.yaml`
+- `data/operations/*.yaml`
+- `data/sessions/*.json`
+- `schemaVersion` (record compatibility)
+
+### 7. Constraints
+
+Must confirm:
+
+- No plain-text credentials introduced.
+- No arbitrary code execution in rule templates.
+- No auto-apply of production changes.
+- File-based source of truth remains unchanged.
+
+### 8. Risks
+
+List implementation risks.
+
+### 9. Verification
+
+Describe how to verify.
+
+## Proposal Quality Bar
+
+A good proposal is small enough to implement and test in one focused change.

package/docs/03-openspec/spec-rule.md

@@ -1,33 +1,33 @@
-# Spec Rule
-
-A spec document turns a proposal into actionable implementation details.
-
-## Required Sections
-
-### 1. Objectives
-
-Clear, measurable outcomes.
-
-### 2. Functional Requirements
-
-What the system must do.
-
-### 3. Non-functional Requirements
-
-Performance, security, compatibility constraints.
-
-### 4. Interface Definitions
-
-Tool names, parameters, return values, events.
-
-### 5. Data Definitions
-
-Schemas for inputs, outputs and storage records.
-
-### 6. Acceptance Criteria
-
-Specific conditions that must be met.
-
-### 7. Open Questions
-
-Unresolved items to confirm before implementation.
+# Spec Rule
+
+A spec document turns a proposal into actionable implementation details.
+
+## Required Sections
+
+### 1. Objectives
+
+Clear, measurable outcomes.
+
+### 2. Functional Requirements
+
+What the system must do.
+
+### 3. Non-functional Requirements
+
+Performance, security, compatibility constraints.
+
+### 4. Interface Definitions
+
+Tool names, parameters, return values, events.
+
+### 5. Data Definitions
+
+Schemas for inputs, outputs and storage records.
+
+### 6. Acceptance Criteria
+
+Specific conditions that must be met.
+
+### 7. Open Questions
+
+Unresolved items to confirm before implementation.