dsh-env-manager-plugin 0.1.0 → 0.1.1

package/docs/02-harness/agent-behavior.md

@@ -1,36 +1,36 @@
-# Agent Behavior
-
-## Required Behavior
-
-Agents working on this project must:
-
-- preserve the file-system-first architecture
-- keep changes small and reviewable
-- write tests for core logic
-- update current-state.md after completion
-- avoid introducing infrastructure not requested by the user
-- keep tool functions thin
-- keep business logic in resolver/router modules
-- treat skill references as discovery, not execution authorization
-
-## Forbidden Behavior
-
-Agents must not:
-
-- introduce plain-text credentials into registry files
-- execute arbitrary JavaScript or shell in rule templates
-- auto-apply rule or skill changes without review
-- write hidden durable state outside documented directories
-- silently discard resolver/router failures
-- treat skill reference resolution as execution approval
-- perform unrelated refactoring
-- change storage contracts without documentation
-
-## When Unclear
-
-If the task is unclear:
-
-1. inspect relevant docs
-2. inspect source files
-3. propose a small plan
-4. avoid broad implementation
+# Agent Behavior
+
+## Required Behavior
+
+Agents working on this project must:
+
+- preserve the file-system-first architecture
+- keep changes small and reviewable
+- write tests for core logic
+- update current-state.md after completion
+- avoid introducing infrastructure not requested by the user
+- keep tool functions thin
+- keep business logic in resolver/router modules
+- treat skill references as discovery, not execution authorization
+
+## Forbidden Behavior
+
+Agents must not:
+
+- introduce plain-text credentials into registry files
+- execute arbitrary JavaScript or shell in rule templates
+- auto-apply rule or skill changes without review
+- write hidden durable state outside documented directories
+- silently discard resolver/router failures
+- treat skill reference resolution as execution approval
+- perform unrelated refactoring
+- change storage contracts without documentation
+
+## When Unclear
+
+If the task is unclear:
+
+1. inspect relevant docs
+2. inspect source files
+3. propose a small plan
+4. avoid broad implementation

package/docs/02-harness/change-snapshot-policy.md

@@ -1,29 +1,29 @@
-# Change Snapshot Policy
-
-## Purpose
-
-Preserve project continuity by documenting what changed and why after each meaningful change.
-
-## When to Update
-
-Update `docs/00-project/current-state.md` when:
-
-- a new feature is implemented
-- a bug is fixed
-- a storage contract changes
-- a module boundary changes
-- a known gap is closed
-
-## What to Record
-
-- What changed (high-level)
-- Which files were added/removed/modified
-- Any new constraints or dependencies
-- Remaining known gaps
-- Recommended next work
-
-## What Not to Record
-
-- Every single commit detail (git history covers that)
-- Temporary workarounds without context
-- Opinion or speculation
+# Change Snapshot Policy
+
+## Purpose
+
+Preserve project continuity by documenting what changed and why after each meaningful change.
+
+## When to Update
+
+Update `docs/00-project/current-state.md` when:
+
+- a new feature is implemented
+- a bug is fixed
+- a storage contract changes
+- a module boundary changes
+- a known gap is closed
+
+## What to Record
+
+- What changed (high-level)
+- Which files were added/removed/modified
+- Any new constraints or dependencies
+- Remaining known gaps
+- Recommended next work
+
+## What Not to Record
+
+- Every single commit detail (git history covers that)
+- Temporary workarounds without context
+- Opinion or speculation

package/docs/02-harness/client-ui-integration.md

@@ -1,110 +1,110 @@
-# Client UI Integration
-
-This note records the **host-side contract** a DSH bundle must follow when it adds a
-sidebar entry and a main panel. It is derived from the installed
-`@deepseek-ai/dsh-client-ui-sidebar` implementation (not from a mock), and from the
-working `dsh-image-router` bundle.
-
-Runtime source of truth:
-
-- `@deepseek-ai/dsh-client-ui-sidebar/lib/client.js`, function `PanelRow`.
-- The live slot catalog: `cordis_inspect_query` → `Slots.listSubTree` with root
-  `sidebar.panellist`, and root `main`.
-- Skill reference: `cordis-plugin-development/references/ui-plugin.md` and
-  `references/practices.md` (plugin UI is part of the Harness UI).
-
-## Sidebar entry
-
-The sidebar owns the row. A plugin contributes only the row's **icon** and **label**;
-it must not draw a button, row background, tooltip, margin, or hit area.
-
-### Registration
-
-```js
-ctx.slots.inject('sidebar.panellist', () =>
-  ctx.slots.register(
-    {
-      name: 'sidebar.panellist',
-      id: 'dsh-env-manager', // row key; also the main panel key
-      order: 40,
-      label: () => t('title'), // thunk, re-read on locale projection
-    },
-    SidebarGlyph,
-  ),
-)
-```
-
-Rules:
-
-1. `sidebar.panellist` is a **list** slot. Its registration fields are `id` (required),
-   `order`, and `label`. `id` must be unique; reusing a shipped id replaces that row.
-2. `name` is the common slots registration field. Include it; the live sidebar
-   registers only entries that carry their slot name.
-3. `label` is the row text and tooltip. Use a thunk when the text is localized so the
-   owner can re-read it without re-registering.
-4. The second argument is the glyph component. The owner renders it inside
-   `span.panelGlyph` and passes exactly `{ size, active }`.
-
-### Glyph contract
-
-The owner passes:
-
-- `size`: `16` when the sidebar is wide (`wide ? 16 : 18`);
-- `active`: whether this row is the selected panel.
-
-The glyph must:
-
-- render an inline `<svg>` with `viewBox="0 0 20 20"`,
-  `width={size}`, `height={size}`;
-- default defensively to `20` if `size` is missing or invalid;
-- use `fill="none"` and `stroke="currentColor"` (shipped icons are monochrome line
-  icons; they inherit light/dark theme colors);
-- use `opacity: 0.72` when `active === false`;
-- set `aria-hidden="true"` and omit `aria-label`/tooltip — the row button owns the
-  accessible name from `label`;
-- avoid fixed pixel width/height, background, border, border-radius, margin, or padding.
-
-A filled colored square at `48×48` is the common failure mode: it overflows the
-`panelGlyph` box, ignores the `size` prop, and looks like a different navigation
-control from the shipped rows.
-
-## Main panel
-
-```js
-ctx.slots.inject('main', () =>
-  ctx.slots.register(
-    { name: 'main', key: 'dsh-env-manager', inject: () => ({}) },
-    Panel,
-  ),
-)
-```
-
-- `main` is a **keyed** root slot. `key` must equal the sidebar `id`.
-- A sidebar id without a matching `main` key opens an empty page; a `main` key without
-  the sidebar id is unreachable.
-- The panel owns its own layout, header, and content. It fills the same region as
-  `conversation`.
-
-## Styling and localization
-
-- Use theme tokens (`--dsw-alias-*`) and `currentColor`; do not hard-code brand colors
-  in the sidebar glyph.
-- The host row supplies `.panelRow`, `.panelActive`, hover, focus, tooltip, and
-  `aria-current`.
-- Register the locale namespace best-effort, and make the sidebar `label` read the
-  active locale. Do not re-register the row to change language.
-
-## Verification
-
-After installing or changing the plugin:
-
-1. `Slots.listSubTree('sidebar.panellist')` must list the id with `active: true` and the
-   expected order.
-2. `Slots.listSubTree('main')` must list the same key as an occupant.
-3. Toggle the sidebar between wide and collapsed; the glyph must render at `16` and
-   `18` pixels respectively, with no clipping or colored background.
-4. Switch `en`/`zh`; the row label must change without a reload or duplicate row.
-5. Select the row and confirm the panel replaces the conversation region.
-
-Client changes are picked up by HMR while the Web client watcher is running; a newly
-installed bundle may need one page refresh before its module is present.
+# Client UI Integration
+
+This note records the **host-side contract** a DSH bundle must follow when it adds a
+sidebar entry and a main panel. It is derived from the installed
+`@deepseek-ai/dsh-client-ui-sidebar` implementation (not from a mock), and from the
+working `dsh-image-router` bundle.
+
+Runtime source of truth:
+
+- `@deepseek-ai/dsh-client-ui-sidebar/lib/client.js`, function `PanelRow`.
+- The live slot catalog: `cordis_inspect_query` → `Slots.listSubTree` with root
+  `sidebar.panellist`, and root `main`.
+- Skill reference: `cordis-plugin-development/references/ui-plugin.md` and
+  `references/practices.md` (plugin UI is part of the Harness UI).
+
+## Sidebar entry
+
+The sidebar owns the row. A plugin contributes only the row's **icon** and **label**;
+it must not draw a button, row background, tooltip, margin, or hit area.
+
+### Registration
+
+```js
+ctx.slots.inject('sidebar.panellist', () =>
+  ctx.slots.register(
+    {
+      name: 'sidebar.panellist',
+      id: 'dsh-env-manager', // row key; also the main panel key
+      order: 40,
+      label: () => t('title'), // thunk, re-read on locale projection
+    },
+    SidebarGlyph,
+  ),
+)
+```
+
+Rules:
+
+1. `sidebar.panellist` is a **list** slot. Its registration fields are `id` (required),
+   `order`, and `label`. `id` must be unique; reusing a shipped id replaces that row.
+2. `name` is the common slots registration field. Include it; the live sidebar
+   registers only entries that carry their slot name.
+3. `label` is the row text and tooltip. Use a thunk when the text is localized so the
+   owner can re-read it without re-registering.
+4. The second argument is the glyph component. The owner renders it inside
+   `span.panelGlyph` and passes exactly `{ size, active }`.
+
+### Glyph contract
+
+The owner passes:
+
+- `size`: `16` when the sidebar is wide (`wide ? 16 : 18`);
+- `active`: whether this row is the selected panel.
+
+The glyph must:
+
+- render an inline `<svg>` with `viewBox="0 0 20 20"`,
+  `width={size}`, `height={size}`;
+- default defensively to `20` if `size` is missing or invalid;
+- use `fill="none"` and `stroke="currentColor"` (shipped icons are monochrome line
+  icons; they inherit light/dark theme colors);
+- use `opacity: 0.72` when `active === false`;
+- set `aria-hidden="true"` and omit `aria-label`/tooltip — the row button owns the
+  accessible name from `label`;
+- avoid fixed pixel width/height, background, border, border-radius, margin, or padding.
+
+A filled colored square at `48×48` is the common failure mode: it overflows the
+`panelGlyph` box, ignores the `size` prop, and looks like a different navigation
+control from the shipped rows.
+
+## Main panel
+
+```js
+ctx.slots.inject('main', () =>
+  ctx.slots.register(
+    { name: 'main', key: 'dsh-env-manager', inject: () => ({}) },
+    Panel,
+  ),
+)
+```
+
+- `main` is a **keyed** root slot. `key` must equal the sidebar `id`.
+- A sidebar id without a matching `main` key opens an empty page; a `main` key without
+  the sidebar id is unreachable.
+- The panel owns its own layout, header, and content. It fills the same region as
+  `conversation`.
+
+## Styling and localization
+
+- Use theme tokens (`--dsw-alias-*`) and `currentColor`; do not hard-code brand colors
+  in the sidebar glyph.
+- The host row supplies `.panelRow`, `.panelActive`, hover, focus, tooltip, and
+  `aria-current`.
+- Register the locale namespace best-effort, and make the sidebar `label` read the
+  active locale. Do not re-register the row to change language.
+
+## Verification
+
+After installing or changing the plugin:
+
+1. `Slots.listSubTree('sidebar.panellist')` must list the id with `active: true` and the
+   expected order.
+2. `Slots.listSubTree('main')` must list the same key as an occupant.
+3. Toggle the sidebar between wide and collapsed; the glyph must render at `16` and
+   `18` pixels respectively, with no clipping or colored background.
+4. Switch `en`/`zh`; the row label must change without a reload or duplicate row.
+5. Select the row and confirm the panel replaces the conversation region.
+
+Client changes are picked up by HMR while the Web client watcher is running; a newly
+installed bundle may need one page refresh before its module is present.

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

@@ -1,43 +1,43 @@
-# Context Policy
-
-## What to Load Automatically
-
-For any non-trivial change, load:
-
-- `docs/00-project/project-brief.md`
-- `docs/00-project/current-state.md`
-- `docs/01-architecture/design.md`
-- `docs/01-architecture/detailed-design.md`
-- `docs/01-architecture/module-boundaries.md`
-- `docs/02-harness/harness-standard.md`
-
-## What to Load by Task Type
-
-### Adding or changing a tool
-
-- `docs/01-architecture/tool-contract.md`
-- `docs/01-architecture/detailed-design.md` §11
-- `docs/04-development/coding-style.md`
-- `docs/05-domain/operation-binding-template.md` (if routing related)
-
-### Changing rule resolution
-
-- `docs/01-architecture/design.md` §6
-- `docs/01-architecture/module-boundaries.md`
-- `docs/05-domain/rule-template.md`
-
-### Changing the HTTP transport or the UI
-
-- `docs/01-architecture/ui-design.md`
-- `docs/01-architecture/decisions/ADR-0009-client-host-http-transport.md`
-- `docs/01-architecture/security-model.md` §2, §4, §6
-- `docs/04-development/coding-style.md`
-
-### Checking a DSH runtime assumption
-
-- `docs/01-architecture/api-verification.md`
-
-### Deployment changes
-
-- `docs/06-operations/deployment-guide.md`
-- `docs/06-operations/security-policy.md`
+# Context Policy
+
+## What to Load Automatically
+
+For any non-trivial change, load:
+
+- `docs/00-project/project-brief.md`
+- `docs/00-project/current-state.md`
+- `docs/01-architecture/design.md`
+- `docs/01-architecture/detailed-design.md`
+- `docs/01-architecture/module-boundaries.md`
+- `docs/02-harness/harness-standard.md`
+
+## What to Load by Task Type
+
+### Adding or changing a tool
+
+- `docs/01-architecture/tool-contract.md`
+- `docs/01-architecture/detailed-design.md` §11
+- `docs/04-development/coding-style.md`
+- `docs/05-domain/operation-binding-template.md` (if routing related)
+
+### Changing rule resolution
+
+- `docs/01-architecture/design.md` §6
+- `docs/01-architecture/module-boundaries.md`
+- `docs/05-domain/rule-template.md`
+
+### Changing the HTTP transport or the UI
+
+- `docs/01-architecture/ui-design.md`
+- `docs/01-architecture/decisions/ADR-0009-client-host-http-transport.md`
+- `docs/01-architecture/security-model.md` §2, §4, §6
+- `docs/04-development/coding-style.md`
+
+### Checking a DSH runtime assumption
+
+- `docs/01-architecture/api-verification.md`
+
+### Deployment changes
+
+- `docs/06-operations/deployment-guide.md`
+- `docs/06-operations/security-policy.md`

package/docs/02-harness/harness-standard.md

@@ -1,91 +1,91 @@
-# Harness Standard
-
-## Purpose
-
-The harness ensures that AI-assisted development remains aligned with the project architecture, constraints, and verification expectations.
-
-## Harness Layers
-
-### 1. Context Layer
-
-Defines what the agent must know before work.
-
-Includes:
-
-- project brief
-- current state
-- design documents
-- module boundaries
-- storage contract
-
-### 2. Constraint Layer
-
-Defines what the agent must not violate.
-
-Includes:
-
-- no plain-text credentials in registry files
-- no arbitrary JavaScript/shell execution in rule templates
-- no auto-apply of production rule or skill changes
-- no unbounded evidence storage
-- no hidden durable state outside documented files
-
-### 3. Execution Layer
-
-Defines how work should be implemented.
-
-Includes:
-
-- small changes
-- testable modules
-- tools as thin wrappers over services
-- business logic in resolver/router modules
-- file-based state
-- clear output file contracts
-
-### 4. Verification Layer
-
-Defines how work is validated.
-
-Includes:
-
-- unit tests for resolvers and routers
-- fixture-based storage tests
-- manual Web/Desktop UI checklist
-- output file contract validation
-- regression tests for bugfixes
-
-### 5. Continuity Layer
-
-Defines how future agents resume work.
-
-Includes:
-
-- update `current-state.md`
-- update relevant docs
-- preserve ADRs
-- archive completed OpenSpec changes
-- avoid hidden assumptions
-
-## Required Agent Behavior
-
-Before implementation:
-
-1. Read the relevant docs.
-2. Identify affected modules.
-3. Identify storage contract impact.
-4. Identify tests to add.
-5. Keep scope small.
-
-During implementation:
-
-1. Prefer minimal changes.
-2. Avoid unrelated refactoring.
-3. Keep logic testable.
-4. Preserve file-based architecture.
-
-After implementation:
-
-1. Run or specify tests.
-2. Update docs if needed.
-3. Update `docs/00-project/current-state.md`.
+# Harness Standard
+
+## Purpose
+
+The harness ensures that AI-assisted development remains aligned with the project architecture, constraints, and verification expectations.
+
+## Harness Layers
+
+### 1. Context Layer
+
+Defines what the agent must know before work.
+
+Includes:
+
+- project brief
+- current state
+- design documents
+- module boundaries
+- storage contract
+
+### 2. Constraint Layer
+
+Defines what the agent must not violate.
+
+Includes:
+
+- no plain-text credentials in registry files
+- no arbitrary JavaScript/shell execution in rule templates
+- no auto-apply of production rule or skill changes
+- no unbounded evidence storage
+- no hidden durable state outside documented files
+
+### 3. Execution Layer
+
+Defines how work should be implemented.
+
+Includes:
+
+- small changes
+- testable modules
+- tools as thin wrappers over services
+- business logic in resolver/router modules
+- file-based state
+- clear output file contracts
+
+### 4. Verification Layer
+
+Defines how work is validated.
+
+Includes:
+
+- unit tests for resolvers and routers
+- fixture-based storage tests
+- manual Web/Desktop UI checklist
+- output file contract validation
+- regression tests for bugfixes
+
+### 5. Continuity Layer
+
+Defines how future agents resume work.
+
+Includes:
+
+- update `current-state.md`
+- update relevant docs
+- preserve ADRs
+- archive completed OpenSpec changes
+- avoid hidden assumptions
+
+## Required Agent Behavior
+
+Before implementation:
+
+1. Read the relevant docs.
+2. Identify affected modules.
+3. Identify storage contract impact.
+4. Identify tests to add.
+5. Keep scope small.
+
+During implementation:
+
+1. Prefer minimal changes.
+2. Avoid unrelated refactoring.
+3. Keep logic testable.
+4. Preserve file-based architecture.
+
+After implementation:
+
+1. Run or specify tests.
+2. Update docs if needed.
+3. Update `docs/00-project/current-state.md`.

package/docs/02-harness/task-execution-policy.md

@@ -1,26 +1,26 @@
-# Task Execution Policy
-
-## Scope
-
-Each task should be small enough to implement, test and review in one focused session.
-
-## Task Format
-
-Use the Tasks rule in `docs/03-openspec/tasks-rule.md`.
-
-## Execution Order
-
-1. Read context
-2. Propose plan
-3. Implement
-4. Test
-5. Update docs and current-state.md
-
-## Stopping Conditions
-
-Stop and report when:
-
-- the task scope becomes unclear
-- a storage contract change is required but not documented
-- a security or approval policy implication is discovered
-- tests fail and cannot be fixed within the task scope
+# Task Execution Policy
+
+## Scope
+
+Each task should be small enough to implement, test and review in one focused session.
+
+## Task Format
+
+Use the Tasks rule in `docs/03-openspec/tasks-rule.md`.
+
+## Execution Order
+
+1. Read context
+2. Propose plan
+3. Implement
+4. Test
+5. Update docs and current-state.md
+
+## Stopping Conditions
+
+Stop and report when:
+
+- the task scope becomes unclear
+- a storage contract change is required but not documented
+- a security or approval policy implication is discovered
+- tests fail and cannot be fixed within the task scope