Regenerate agent instructions from state-hub templates (CUST-WP-0055 T01)

Sync AGENTS.md, CLAUDE.md, and .claude/rules from updated project_rules
templates: workplan-first session protocol, legacy terminology footnote,
and GET /workplans/ examples.

.claude/rules/agents.md

@@ -0,0 +1,20 @@
+## Kaizen Agents
+
+Specialized agent personas available on demand via the state-hub MCP.
+
+**Discover:** `list_kaizen_agents()` — returns all agents with name, description, category
+**Load:** `get_kaizen_agent("tdd-workflow")` — returns full instructions; read and follow them
+
+Common agents:
+
+| Agent | Category | When to use |
+|-------|----------|-------------|
+| `tdd-workflow` | testing | Step-by-step TDD8 workflow for any feature |
+| `code-refactoring` | quality | Code quality analysis and safe refactoring |
+| `test-maintenance` | testing | Diagnose and fix failing tests |
+| `requirements-engineering` | process | Prevent interface/mock mismatches upfront |
+| `keepaTodofile` | process | Maintain TODO.md during work |
+| `project-management` | process | Track status, determine next steps |
+| `datamodel-optimization` | quality | Optimize dataclasses and data structures |
+
+All 17 agents: call `list_kaizen_agents()` for the full list.

.claude/rules/architecture.md

@@ -0,0 +1,8 @@
+## Architecture
+
+<!-- TODO: Describe the key design decisions and component structure.
+     Key modules, data flows, external integrations, state machines, etc. -->
+
+## Quick Reference
+
+`~/state-hub/mcp_server/TOOLS.md` — MCP tool reference

.claude/rules/credential-routing.md

@@ -0,0 +1,50 @@
+# Credential and access routing
+
+**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
+for inference. Run this check **before** requesting secrets, API keys, SSH access,
+login tokens, or database passwords — in any repo, not only `ops-warden`.
+
+ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
+other credential need belongs to another subsystem. **Do not** message
+`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
+
+### Lookup (do this first)
+
+```bash
+warden route find "<describe your need>" --json
+warden route show <catalog-id> --json
+```
+
+Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
+
+| Agent runtime | How to orient |
+| --- | --- |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=testdrive-jsui` is for coordination, not secret vending |
+| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workplans; **still** use `warden route` for credential ownership |
+| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
+
+### Quick routing table
+
+| I need… | Owner | ops-warden executes? |
+| --- | --- | --- |
+| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
+| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
+| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
+| Authorization decision | flex-auth | No — route only |
+| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
+| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
+
+### Anti-patterns (do not do these)
+
+- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
+- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
+- Pasting secrets into Git, State Hub, workplans, logs, or chat
+
+### Other capabilities (reuse-surface)
+
+Non-credential capabilities are usually discovered through **reuse-surface** federation
+(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
+every repo's agent instructions because it is high-frequency, high-risk, and easy to
+get wrong.
+
+**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`

.claude/rules/first-session.md

@@ -0,0 +1,42 @@
+## First Session Protocol
+
+Triggered when `get_domain_summary("infotech")` shows **no workplans**.
+The project is registered but work has not yet been structured.
+
+**Step 1 — Read, don't write**
+- `~/the-custodian/canon/projects/infotech/project_charter_v0.1.md` — purpose, scope
+- `~/the-custodian/canon/projects/infotech/roadmap_v0.1.md` — planned phases
+- Scan repo root: README, directory structure, existing code or docs
+
+**Step 2 — Survey in-progress work**
+Look for TODOs, open branches, half-finished files. Note done vs. started but incomplete.
+
+**Step 3 — Propose workplans to Bernd**
+Propose 1–3 workplans — each a coherent strand, weeks to months, anchored to a
+roadmap phase. **Wait for approval before creating.**
+
+**Step 4 — Write the workplan file; fix-consistency registers it (ADR-001)**
+```
+workplans/JSUI-WP-NNNN-<slug>.md   ← write this, commit it
+```
+Then register by running the consistency check — do **not** call
+`create_workplan`/`create_task` yourself; manual registration duplicates what
+C-06 creates from the file:
+```bash
+statehub fix-consistency --repo testdrive-jsui
+```
+C-06 creates the hub workplan + tasks and writes `state_hub_workstream_id`
+(legacy frontmatter name — holds the workplan UUID) and `state_hub_task_id`
+back into the file.
+
+**Step 5 — Record the setup**
+```
+add_progress_event(
+    summary="First session: structured infotech into N workplans, M tasks",
+    event_type="milestone",
+    topic_id="cee7bedf-2b48-46ef-8601-006474f2ad7a",
+    detail={"workplans": [...], "tasks_created": M}
+)
+```
+
+<!-- Delete or archive this file once past first session -->

.claude/rules/repo-boundary.md

@@ -0,0 +1,8 @@
+## Repo boundary
+
+This repo owns **testdrive-jsui** only. It does not own:
+
+<!-- TODO: List what belongs in adjacent repos, e.g.:
+- SSH key management → railiance-infra/
+- State hub code     → state-hub/
+-->

.claude/rules/repo-identity.md

@@ -0,0 +1,5 @@
+**Purpose:** TestDrive-JSUI is a standalone, JavaScript-first markdown editor and UI library (with an optional Python integration adapter) that is being packaged for npm distribution.
+
+**Domain:** infotech
+**Repo slug:** testdrive-jsui
+**Topic ID:** cee7bedf-2b48-46ef-8601-006474f2ad7a

.claude/rules/session-protocol.md

@@ -0,0 +1,92 @@
+## Session Protocol
+
+Dev Hub (State Hub API): http://127.0.0.1:8000
+MCP server name in `~/.claude.json`: `dev-hub`
+
+**Step 1 — Orient**
+
+Read the offline-safe brief first — it works without a live hub connection:
+```bash
+cat .custodian-brief.md
+```
+Then call the MCP tool for richer cross-domain context when MCP tools are exposed:
+```
+get_domain_summary("infotech")
+```
+If MCP tools are unavailable in the current agent session, use the REST API:
+```bash
+curl -s "http://127.0.0.1:8000/state/summary" | python3 -m json.tool
+```
+If the hub is offline: `cd ~/state-hub && make api`
+
+**Step 2 — Check inbox**
+With MCP tools:
+```
+get_messages(to_agent="testdrive-jsui", unread_only=True)
+```
+Mark read with `mark_message_read(message_id)`. Reply or act on coordination
+requests before proceeding.
+
+Without MCP tools:
+```bash
+curl -s "http://127.0.0.1:8000/messages/?to_agent=testdrive-jsui&unread_only=true" \
+  | python3 -m json.tool
+curl -s -X PATCH "http://127.0.0.1:8000/messages/<id>/read" \
+  -H "Content-Type: application/json" -d '{}'
+```
+
+**Step 3 — Scan workplans**
+```bash
+ls workplans/
+```
+For each file with `status: ready`, `active`, or `blocked`, note pending
+`wait`/`todo`/`progress` tasks.
+
+**Step 4 — Present brief**
+
+1. **Active workplans** for `infotech` — title, task counts, blocking decisions
+2. **Pending tasks** from `workplans/` + any `[repo:testdrive-jsui]` hub tasks
+3. **Goal guidance** — if `goal_guidance` in summary:
+   - `needs_workplan`: surface as top action — *"Repo goal '{title}' has no workplan yet"*
+   - `alignment_warnings`: flag if active work is not aligned with current goal
+4. **Suggested next action** — highest-priority open item
+5. **SBOM status** — flag if `last_sbom_at` is unset for this repo
+
+If no workplans: follow First Session Protocol (`first-session.md`).
+
+**During work:** `record_decision()` · `add_progress_event()` · `resolve_decision()`
+
+> State Hub is a *read model*. **Never register workplans or tasks by hand**
+> (`create_workplan`, `create_task`) — write the workplan file in `workplans/`
+> and run `fix-consistency`; C-06 registers the workplan and tasks and writes
+> IDs back into the file. Manual registration creates duplicates when
+> fix-consistency runs. Work structure belongs in repo files (ADR-001).
+>
+> Legacy: `create_workstream` and `/workstreams/` remain as metered aliases —
+> see `workplan-convention.md` (compatibility footnote).
+
+**Session close:**
+With MCP tools:
+```
+add_progress_event(summary="...", topic_id="cee7bedf-2b48-46ef-8601-006474f2ad7a", workplan_id="<uuid>")
+```
+Without MCP tools:
+```bash
+curl -s -X POST http://127.0.0.1:8000/progress/ \
+  -H "Content-Type: application/json" \
+  -d '{"topic_id":"cee7bedf-2b48-46ef-8601-006474f2ad7a","workplan_id":"<uuid>","event_type":"note","summary":"what changed","author":"codex"}'
+```
+If workplan files were modified, ensure the local copy is up to date first,
+then sync from the repo checkout:
+```bash
+git pull --ff-only
+statehub fix-consistency
+```
+For repos where implementation runs on a remote machine (e.g. CoulombCore),
+use the pull-before-fix mode from any shell with the State Hub CLI:
+```bash
+statehub fix-consistency --repo testdrive-jsui --remote
+```
+**C-15** (DB task ahead of file) is normal in multi-machine workflows — writeback
+will sync the file to match DB.  **C-16** (repo behind remote) blocks all writes
+until you pull — intentional to prevent clobbering remote progress.

.claude/rules/stack-and-commands.md

@@ -0,0 +1,19 @@
+## Stack
+
+<!-- TODO: Fill in language, frameworks, and key dependencies -->
+- **Language:**
+- **Key deps:**
+
+## Dev Commands
+
+```bash
+# TODO: Fill in the standard commands for this repo
+
+# Install dependencies
+
+# Run tests
+
+# Lint / type check
+
+# Build / package (if applicable)
+```

.claude/rules/workplan-convention.md

@@ -0,0 +1,55 @@
+## Workplan Convention (ADR-001)
+
+File location: `workplans/JSUI-WP-NNNN-<slug>.md`
+ID prefix: `JSUI-WP-`
+
+Work items originate as files in this repo **before** being registered in the hub.
+
+Canonical workplan frontmatter statuses are:
+`proposed`, `ready`, `active`, `blocked`, `backlog`, `finished`, `archived`.
+Use `proposed` for a newly drafted plan, `ready` after review against current
+repo state, and `finished` when implementation is complete. `stalled` and
+`needs_review` are derived health labels, not stored statuses.
+
+Closed workplans may be moved to `workplans/archived/` with a completion-date
+prefix: `YYMMDD-JSUI-WP-NNNN-<slug>.md`. The frontmatter id remains
+unchanged; the prefix is only for quick visual reference.
+
+Small opportunistic tasks discovered during another session use **Ad Hoc Tasks**:
+`workplans/ADHOC-YYYY-MM-DD.md`, workplan slug `adhoc-YYYY-MM-DD`, and task ids
+`ADHOC-YYYY-MM-DD-T01`, `T02`, etc. Use adhocs only for low-risk work completed
+directly. Promote anything requiring analysis, design, approval, dependencies, or
+multiple planned phases into a normal workplan.
+
+Ecosystem todos from other agents arrive as `[repo:testdrive-jsui]` hub tasks —
+visible at session start. Pick one up by creating the workplan file, committing,
+and running `statehub fix-consistency` — C-06 registers the workplan in the hub.
+Never register by hand with `create_workplan` (legacy MCP alias: `create_workstream`).
+
+Task blocks use this shape:
+
+```task
+id: JSUI-WP-NNNN-T01
+status: wait | todo | progress | done | cancel
+priority: high | medium | low
+state_hub_task_id: "<uuid>"         # written by fix-consistency — do not edit
+```
+
+Status progression is `todo` → `progress` → `done`; use `wait` for waiting or
+blocked work and `cancel` for stopped work.
+
+Workplan frontmatter carries `state_hub_workstream_id` — a legacy field name
+kept for compatibility; it holds the hub workplan UUID and is written by
+fix-consistency. Do not edit or rename it.
+
+### Legacy terminology (compatibility footnote)
+
+**Workplan** is the fleet term — see
+`the-custodian/canon/standards/workplan-terminology-fleet_v0.1.md`.
+**Workstream** is legacy only: some API routes (`/workstreams/`), params
+(`workstream_id`), MCP aliases (`create_workstream`), and the frontmatter field
+above remain until `STATE-WP-0069` retires them via legacy-meter. Treat those
+identifiers as workplan IDs. Prefer `GET /workplans/` and `workplan_id` in new
+examples and scripts.
+
+<!-- Ralph Loop rules and HEUREKA sequence: ~/.claude/CLAUDE.md — do not duplicate here -->

AGENTS.md

@@ -107,7 +107,56 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
 
 ---
 
-{CREDENTIAL_ROUTING}
+## Credential and access routing
+
+**Audience:** Codex, Claude Code, Grok, and custodian agents that call **llm-connect**
+for inference. Run this check **before** requesting secrets, API keys, SSH access,
+login tokens, or database passwords — in any repo, not only `ops-warden`.
+
+ops-warden **issues SSH certificates only** (`warden sign`, `cert_command`). Every
+other credential need belongs to another subsystem. **Do not** message
+`ops-warden` on State Hub expecting a secret value; the reply is a pointer, not a key.
+
+### Lookup (do this first)
+
+```bash
+warden route find "<describe your need>" --json
+warden route show <catalog-id> --json
+```
+
+Requires the `warden` CLI from `~/ops-warden` (`uv tool install .` or `uv run warden`).
+
+| Agent runtime | How to orient |
+| --- | --- |
+| **Codex / Grok** (shell, HTTP State Hub) | `warden route` commands above; inbox `to_agent=testdrive-jsui` is for coordination, not secret vending |
+| **Claude Code** (MCP when available) | `get_domain_summary("custodian")` for workplans; **still** use `warden route` for credential ownership |
+| **llm-connect** (inference service) | Never put secret retrieval in prompts; route custody to OpenBao/operator paths surfaced by `warden route` |
+
+### Quick routing table
+
+| I need… | Owner | ops-warden executes? |
+| --- | --- | --- |
+| SSH cert (`adm`/`agt`/`atm`) | ops-warden | **Yes** — `warden sign` |
+| API key, DB password, provider token | OpenBao (`railiance-platform`) | No — route only |
+| Login / OIDC / MFA | key-cape / Keycloak | No — route only |
+| Authorization decision | flex-auth | No — route only |
+| activity-core → issue-core emission | activity-core + issue-core | No — `warden route show activity-core-issue-sink` |
+| SSH tunnel | ops-bridge (+ `cert_command` from warden) | No — route only |
+
+### Anti-patterns (do not do these)
+
+- `POST /messages/` to `ops-warden` asking for `ISSUE_CORE_API_KEY`, `OPENROUTER_API_KEY`, etc.
+- Inventing `warden secret`, `warden login`, `warden bao`, `warden tunnel` — they do not exist
+- Pasting secrets into Git, State Hub, workplans, logs, or chat
+
+### Other capabilities (reuse-surface)
+
+Non-credential capabilities are usually discovered through **reuse-surface** federation
+(`reuse-surface` registry / `capability.*` indexes). Credential routing is inlined in
+every repo's agent instructions because it is high-frequency, high-risk, and easy to
+get wrong.
+
+**Canon:** `~/ops-warden/wiki/CredentialRouting.md` · catalog `~/ops-warden/registry/routing/catalog.yaml`
 
 <!-- REPO-AGENTS-EXTENSIONS -->
 <!-- Append repo-specific agent instructions below this marker.

CLAUDE.md

@@ -1,362 +1,12 @@
-# CLAUDE.md
-
-This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
-
-## Overview
-
-**TestDrive-JSUI is a JavaScript-first markdown editor library.**
-
-This is a pure JavaScript library for interactive markdown editing that works standalone in any browser. Language adapters (Python, Ruby, Java) are **optional integration helpers** - they do NOT provide core functionality.
-
-**Key Facts**:
-- **Core:** Complete JavaScript library (`js/testdrive-jsui.js`)
-- **Dependencies:** Only marked.js for markdown parsing
-- **Standalone:** Works without any backend (can run from file://)
-- **Optional Adapters:** Python/Ruby/Java adapters help with asset serving and backend integration
-- **Architecture:** JavaScript-first design (see `ARCHITECTURE.md`)
-
-## JavaScript Library
-
-### Quick Start
-
-```html
-<!DOCTYPE html>
-<html>
-<head>
-    <script src="https://cdn.jsdelivr.net/npm/marked/marked.min.js"></script>
-    <script src="js/testdrive-jsui.js"></script>
-</head>
-<body>
-    <div id="editor"></div>
-    <script>
-        const editor = new TestDriveJSUI({
-            container: '#editor',
-            markdown: '# Hello World\n\nEdit me!',
-            mode: 'edit',
-            theme: 'github'
-        });
-    </script>
-</body>
-</html>
-```
-
-### API
-
-**Constructor Options:**
-- `container` (required): CSS selector or DOM element
-- `markdown`: Initial content
-- `mode`: 'edit' or 'view' (default: 'edit')
-- `theme`: Theme name (default: 'github')
-- `autosave`: Auto-save enabled (default: false)
-- `shortcuts`: Keyboard shortcuts (default: true)
-- `sections`: Section-based editing (default: true)
-- `debug`: Debug mode (default: false)
-
-**Methods:**
-- `getMarkdown()`: Get current content
-- `setMarkdown(markdown)`: Set content
-- `getStatus()`: Get editor status
-- `save()`: Trigger save event
-- `download(filename)`: Download as .md file
-- `on(event, callback)`: Listen to events
-- `destroy()`: Clean up
-
-**Events:** `initialized`, `save`, `content-changed`, `autosave`, `download`, `reset`, `destroyed`
-
-### Examples
-
-See `/examples`:
-- `standalone.html` - Minimal proof of concept
-- `full-editor.html` - Complete demo with all features
-
-## Migration Status
-
-**✅ MIGRATION FULLY COMPLETE - ALL PHASES**
-
-This capability migration is now **fully complete** including cleanup. The main MarkiTect application exclusively uses the capability location, and legacy files have been removed.
-
-**Current Status**: ✅ Phase 4 Complete (December 16, 2025)
-- All 24 original JavaScript files copied to capability ✅
-- 84 automated tests passing (68 JS + 15 Python + 1 fixes) ✅
-- Templates updated to use capability location ✅
-- Main app **fully using capability** (no hybrid approach) ✅
-- Verified in both view and edit modes ✅
-- **Legacy files removed** - cleanup complete ✅
-
-**Key Facts**:
-- **Main app status**: Fully migrated to capability location
-- **Original files**: **REMOVED** from `/markitect/static/js/` (Phase 4 cleanup)
-- **Single source of truth**: All JavaScript in `/capabilities/testdrive-jsui/js/`
-- **Testing**: All rendering modes work correctly
-- **Migration**: Fully complete - no further phases needed
-
-**Documentation**: See `MIGRATION_STATUS.md` for complete migration details, all phases, and final verification results.
-
-## Build and Test Commands
-
-### Setup
-```bash
-# Complete setup (Python + JavaScript dependencies)
-make testdrive-jsui-setup
-
-# Check environment status
-make testdrive-jsui-status
-```
-
-### Testing
-```bash
-# Run all tests (recommended before commits)
-make testdrive-jsui-test-all
-
-# Run JavaScript tests only (Jest)
-make testdrive-jsui-test-js
-npm test
-
-# Run specific JavaScript test
-npm test -- --testNamePattern="SectionManager"
-
-# Run Python integration tests only
-make testdrive-jsui-test-python
-pytest tests/ -v
-
-# Run tests with coverage
-npm run test:coverage
-
-# Watch mode for development
-make testdrive-jsui-watch
-```
-
-### Linting and Formatting
-```bash
-# Lint JavaScript
-make testdrive-jsui-lint-js
-
-# Lint Python
-make testdrive-jsui-lint-python
-
-# Format Python code with black
-make testdrive-jsui-format-python
-```
-
-### Cleanup
-```bash
-make testdrive-jsui-clean
-```
-
-## Architecture
-
-### Directory Structure
-```
-testdrive-jsui/
-├── js/                          # JavaScript library (Core functionality)
-│   ├── testdrive-jsui.js        # 🎯 Main library entry point
-│   ├── core/                    # Core JS: debug-system, section-manager
-│   ├── components/              # UI components: dom-renderer, debug-panel, document-controls
-│   ├── controls/                # Control panels: edit, debug, status, contents
-│   ├── plugins/                 # JS plugins
-│   ├── widgets/                 # UI widgets
-│   ├── utils/                   # JS utilities
-│   ├── tests/                   # JavaScript tests (Jest)
-│   ├── config-loader.js         # Configuration loader
-│   ├── main.js                  # Legacy main entry point
-│   └── main-updated.js          # Refactored main entry
-├── examples/                    # 📚 Working examples
-│   ├── standalone.html          # Minimal proof of concept
-│   └── full-editor.html         # Complete demo
-├── src/testdrive_jsui/          # Python adapter (optional)
-│   ├── core/                    # Adapter core
-│   ├── components/              # Adapter helpers
-│   ├── utils/                   # Utilities
-│   └── testing/                 # Python-JS bridge
-│       ├── js_test_runner.py    # JavaScript test execution
-│       └── integration.py       # Pytest integration
-├── static/                      # Static assets
-│   ├── css/                     # Stylesheets (editor, controls, themes)
-│   ├── images/                  # Image assets and icons
-│   └── templates/               # HTML templates
-├── tests/                       # Python tests
-├── docs/                        # Documentation
-│   ├── prototypes/              # Archived HTML prototypes
-│   └── migration/               # Migration records
-├── ARCHITECTURE.md              # JavaScript-first architecture details
-└── README.md                    # Main documentation
-```
-
-### Key Design Principles
-
-**JavaScript-First Architecture** (NEW in v1.0.0)
-- **Core functionality in JavaScript**: All UI logic, rendering, and editing in JS
-- **Standalone capable**: Works without any backend (can run from file://)
-- **marked.js only dependency**: For markdown parsing
-- **Language adapters optional**: Python/Ruby/Java are integration helpers, not functionality providers
-- **Event-driven API**: Clean event system for integration
-- **See `ARCHITECTURE.md`** for complete architectural documentation
-
-**Plugin Independence**
-- **Self-declaring**: Plugin declares its own location - no hardcoded paths needed
-- **Single source of truth**: All assets in one capability directory
-- **Clean boundaries**: JSON config interface between adapters and JavaScript
-- **No code mixing**: JavaScript stays in `.js` files, never embedded in strings
-- Works regardless of installation location
-
-**Testing Architecture**
-- **Dual-track testing**: JavaScript tests (Jest) + Python integration tests (pytest)
-- **Python-JS bridge**: `JavaScriptTestRunner` executes JS tests from Python
-- **Test isolation**: Proper setup/teardown with JSDOM environment
-- **Coverage integration**: Combines Python and JavaScript coverage
-
-**Component Organization**
-- **Core**: `debug-system.js`, `section-manager.js` - fundamental framework components
-- **Components**: `dom-renderer.js`, `debug-panel.js` - UI rendering components
-- **Controls**: `control-base.js`, `edit-control.js`, `debug-control.js`, `status-control.js`, `contents-control.js` - interactive control panels
-- All components are modular and testable in isolation
-
-### Python-JavaScript Bridge
-
-The capability provides seamless integration between Python and JavaScript tests:
-
-**JavaScriptTestRunner** (`src/testdrive_jsui/testing/js_test_runner.py`):
-- Executes JavaScript tests via subprocess (Node.js + Jest)
-- Parses JSON test results into Python dataclasses (`JSTestResult`)
-- Provides methods: `run_js_tests()`, `run_specific_test()`, `list_available_tests()`
-- Auto-discovers capability root if not specified
-- Validates Node.js environment before execution
-
-**Usage Example**:
-```python
-from testdrive_jsui.testing import JavaScriptTestRunner
-
-runner = JavaScriptTestRunner()
-result = runner.run_js_tests(coverage=True)
-assert result.success
-assert result.tests_passed > 0
-```
-
-### Jest Configuration
-
-Located in `package.json` (no separate jest.config.js):
-- **Test environment**: jsdom
-- **Test patterns**: `**/js/tests/**/*.test.js`
-- **Coverage**: Collects from `js/core/`, `js/components/`, `js/utils/`
-- **Setup**: `js/tests/jest.setup.js`
-- **Ignored files**: `refactor-test-runner.js`, `setup.js`
-
-### Pytest Configuration
-
-Located in `pyproject.toml`:
-- **Test paths**: `tests/`, `src/testdrive_jsui/tests/`
-- **Markers**: `@pytest.mark.javascript` for JS integration tests
-- **Coverage target**: 58% minimum
-- **Addopts**: Strict markers, verbose output, coverage reports
-
-## Development Workflow
-
-### Adding JavaScript Components
-
-1. Create component in appropriate `js/` subdirectory (`core/`, `components/`, `controls/`, etc.)
-2. Write tests in `js/tests/` with naming: `component-name.test.js` or `test-component-name.js`
-3. Run tests: `npm test`
-4. Add Python integration tests if needed in `tests/`
-
-### Adding Python Integration
-
-1. Create test in `tests/` directory
-2. Use `JavaScriptTestRunner` to execute JS tests from Python
-3. Mark with `@pytest.mark.javascript` for selective test execution
-4. Run: `pytest tests/ -v -m javascript`
-
-### Migration Strategy (Copy-First)
-
-**Status**: ✅ ALL PHASES COMPLETE - See `MIGRATION_STATUS.md` for full details
-
-The capability followed a **copy-first, verify-later** migration principle:
-
-**Phase 1: Copy** ✅ COMPLETE (December 16, 2025)
-1. ✅ Copy all original files to `js/` directory
-2. ✅ Verify copies are correct
-3. ✅ Run all tests in capability
-4. ✅ Document current state
-
-**Phase 2: Dual-Track Testing** (SKIPPED)
-- Skipped as Phase 1 testing was comprehensive enough
-
-**Phase 3: Gradual Switch** ✅ COMPLETE (December 16, 2025)
-1. ✅ Update templates to use capability location
-2. ✅ Test each change individually (view & edit modes)
-3. ✅ Maintain rollback capability (originals preserved)
-4. ✅ Monitor for issues (none found)
-
-**Phase 4: Cleanup** ✅ COMPLETE (December 16, 2025)
-1. ✅ Remove original files (29 files deleted)
-2. ✅ Update documentation references
-3. ✅ Archive migration records
-4. ✅ Tag final migration commit
-
-**Final State**: Migration **fully complete**. Main app exclusively uses capability location. Legacy files removed. Single source of truth: `/capabilities/testdrive-jsui/js/`. All tests passing. See `MIGRATION_STATUS.md` for complete history.
-
-## Common Development Tasks
-
-### Running Single Test
-```bash
-# JavaScript
-npm test -- --testNamePattern="specific test name"
-
-# Python
-pytest tests/test_specific.py -v
-```
-
-### Debugging Tests
-```bash
-# Verbose JavaScript output
-npm run test:verbose
-
-# Python with debug output
-pytest tests/ -v -s
-```
-
-### Checking Test Coverage
-```bash
-# JavaScript coverage (generates coverage/ directory)
-npm run test:coverage
-
-# Python coverage (included in pytest runs)
-pytest tests/ -v --cov=testdrive_jsui --cov-report=html
-```
-
-### Development Watch Mode
-```bash
-# Auto-rerun tests on file changes
-make testdrive-jsui-watch
-# or
-npm run test:watch
-```
-
-## Important Notes
-
-### Code Quality Standards
-- **ESLint**: Standard config with Jest plugin, warns on `console`, errors on `debugger`
-- **Black**: Python formatting with 88 char line length
-- **MyPy**: Strict typing for Python code (can be disabled for tests)
-
-### Test Execution Order
-When running `make testdrive-jsui-test-all`:
-1. JavaScript tests (Jest)
-2. JavaScript fixes test (Python-based validation)
-3. Python integration tests (pytest)
-4. HTML manual tests (available for browser testing)
-
-### Node.js Requirements
-- Node.js 16+ required for JavaScript testing
-- npm automatically installs dependencies from `package.json`
-- If Node.js unavailable, JavaScript tests gracefully skip with warning
-
-### Rendering Modes
-The engine supports two modes:
-- `'edit'`: Interactive editing mode with controls
-- `'view'`: View-only mode
-
-Validate modes before rendering:
-```python
-if engine.validate_mode('edit'):
-    html = engine.render_document(content, 'edit', config)
-```
+# testdrive-jsui — Claude Code Instructions
+
+@SCOPE.md
+@.claude/rules/repo-identity.md
+@.claude/rules/session-protocol.md
+@.claude/rules/first-session.md
+@.claude/rules/workplan-convention.md
+@.claude/rules/stack-and-commands.md
+@.claude/rules/architecture.md
+@.claude/rules/repo-boundary.md
+@.claude/rules/credential-routing.md
+@.claude/rules/agents.md