feat: VS Code extension MVP — ground-up rebuild with daemon architecture

.claude/commands/review-fix-converge.md → .claude/commands/converge.md

@@ -1,4 +1,4 @@
-# Review Fix Converge
+# Converge
 
 Orchestration loop that converges to PR-ready code. Runs gates, then impartial review, then fix, then repeat until clean. Tracks issue counts per cycle to prove convergence — if counts aren't decreasing, something is wrong.
 
@@ -28,13 +28,13 @@ Cycle | Gate | Review Critical | Review Important | Regressions | Verdict
 ### Step 2: Run Cycle
 
 **A. Quality Gates**
-Invoke `/automated-quality-gates` (use the skill).
+Invoke `/gates` (use the skill).
 - If gates FAIL: fix the failures first (dispatch fix agent), re-run gates
 - Gates must PASS before proceeding to review
 - Record: did fixes introduce any new gate failures? (= regression)
 
 **B. Impartial Code Review**
-Invoke `/impartial-code-review` (use the skill).
+Invoke `/review` (use the skill).
 - Record: count of CRITICAL and IMPORTANT findings
 
 **C. Evaluate Convergence**

.claude/commands/debug.md

@@ -7,6 +7,7 @@ Give Claude an interactive feedback loop for CLI, TUI, Extension, and MCP develo
 `/debug` - Auto-detect component and run appropriate feedback loop
 `/debug cli` - Test CLI commands
 `/debug tui` - Run TUI and inspect state
+`/debug extension` - Build, install, and test VS Code extension locally
 `/debug mcp` - Test MCP tools
 
 ## Process
@@ -16,6 +17,7 @@ Give Claude an interactive feedback loop for CLI, TUI, Extension, and MCP develo
 Based on recent changes or explicit argument:
 - `src/PPDS.Cli/Commands/` → CLI mode
 - `src/PPDS.Cli/Tui/` → TUI mode
+- `src/PPDS.Extension/` → Extension mode
 - `src/PPDS.Mcp/` → MCP mode
 - No clear match → Ask user
 
@@ -45,25 +47,60 @@ Run TUI tests and optionally launch interactive:
 dotnet test tests/PPDS.Cli.Tests/PPDS.Cli.Tests.csproj --filter "Category=TuiUnit" --no-build
 
 # Run TUI visual snapshots (if Node.js available)
-npm test --prefix tests/tui-e2e
+npm test --prefix tests/PPDS.Tui.E2eTests
 ```
 
 If visual issues, update snapshots:
 ```bash
-npm test --prefix tests/tui-e2e -- --update-snapshots
+npm test --prefix tests/PPDS.Tui.E2eTests -- --update-snapshots
 ```
 
-### 4. MCP Mode
+### 4. Extension Mode
 
-Test MCP tools via MCP client:
+**Build & install for manual testing:**
 
 ```bash
-# Build MCP server
-dotnet build src/PPDS.Mcp/PPDS.Mcp.csproj
+cd <root>/src/PPDS.Extension && npm run lint && npm run compile && npm run test && npm run local
+```
+
+Then reload VS Code (Ctrl+Shift+P -> Reload Window) and test manually.
+
+**Useful npm scripts** (run from repo root with `ext:` prefix, or from src/PPDS.Extension/ directly):
+
+| Request | Command |
+|---------|---------|
+| Build + install | `npm run ext:local` |
+| Just install existing build | `npm run ext:local:install` |
+| Revert to marketplace version | `npm run ext:local:revert` |
+| Uninstall local | `npm run ext:local:uninstall` |
+| Run unit tests only | `npm run ext:test` |
+| Run E2E tests | `npm run ext:test:e2e` |
+| Watch mode (hot reload) | `npm run ext:watch` |
+| Full release test | `npm run ext:release:test` |
+
+**F5 Launch Configurations** (from VS Code debug panel):
+
+| Configuration | When to use |
+|---------------|-------------|
+| Run Extension | Default — full build, then launch debug host |
+| Run Extension (Watch Mode) | Iterating — hot reloads on file changes |
+| Run Extension (No Build) | Quick — skip build, use existing compiled code |
+| Run Extension (Open Folder) | Testing with a specific project folder |
+| Run Extension Tests | Run VS Code extension integration tests |
 
-# Test tools (use MCP client if available)
+**For AI self-verification:** Use `/verify extension` to exercise commands,
+inspect state, and verify webview rendering via MCP tools.
+
+### 5. MCP Mode
+
+Test MCP tools via MCP Inspector:
+
+```bash
+npx @modelcontextprotocol/inspector --cli --server "ppds-mcp-server"
 ```
 
+Or use `/verify mcp` for structured verification.
+
 ## Iterative Fix Loop
 
 When issues found:

.claude/commands/automated-quality-gates.md → .claude/commands/gates.md

@@ -1,4 +1,4 @@
-# Automated Quality Gates
+# Gates
 
 Mechanical pass/fail checks. No judgment, no opinions — compiler, linter, and tests either pass or they don't. Run this before code reviews, after fix batches, and before PRs.
 
@@ -32,6 +32,14 @@ dotnet build PPDS.sln -v q
 Pass: 0 errors, 0 warnings treated as errors
 Fail: any error — report exact error messages with file:line
 
+**File-locking recovery:** If `dotnet build PPDS.sln` fails with "used by another process" errors (common when the daemon is running from debug output), retry by building only the changed projects individually:
+```bash
+dotnet build src/PPDS.Cli/PPDS.Cli.csproj -v q
+dotnet build src/PPDS.Query/PPDS.Query.csproj -v q
+# etc. — only the projects with changed files
+```
+This is expected when webview-cdp has VS Code open. The daemon runs from shadow-copied binaries but the solution build may still contend with other processes.
+
 **Gate 2: .NET Tests** (if C# files changed)
 
 ```bash
@@ -44,25 +52,54 @@ Fail: report failing test names and assertion messages
 **Gate 3: TypeScript Build** (if TS/JS files changed)
 
 ```bash
-npm run compile --prefix extension
+npm run compile --prefix src/PPDS.Extension
 ```
 
 Pass: 0 errors
 Fail: report exact error messages with file:line
 
+**Gate 3.5: TypeScript Type Check** (if TS/JS files changed)
+
+```bash
+npm run typecheck:all --prefix src/PPDS.Extension
+```
+
+Pass: 0 errors across both host and webview tsconfigs
+Fail: report exact error messages with file:line
+
+Note: `compile` (Gate 3) only runs esbuild which does NOT type-check. This gate runs `tsc --noEmit` against both `tsconfig.json` (host) and `tsconfig.webview.json` (browser) to catch type errors.
+
 **Gate 4: TypeScript Lint** (if TS/JS files changed)
 
 ```bash
-npm run lint --prefix extension
+npm run lint --prefix src/PPDS.Extension
 ```
 
 Pass: 0 errors
 Fail: report lint violations
 
+**Gate 4.5: CSS Lint** (if CSS files changed)
+
+```bash
+npm run lint:css --prefix src/PPDS.Extension
+```
+
+Pass: 0 errors
+Fail: report CSS lint violations with file:line
+
+**Gate 4.6: Dead Code Analysis** (if TS/JS files changed)
+
+```bash
+npm run dead-code --prefix src/PPDS.Extension
+```
+
+Pass: 0 unused exports
+Fail: report unused exports/files
+
 **Gate 5: TypeScript Tests** (if TS/JS files changed)
 
 ```bash
-npm test --prefix extension
+npm test --prefix src/PPDS.Extension
 ```
 
 Pass: 0 failures
@@ -73,7 +110,7 @@ Fail: report failing test names and messages
 Read `specs/README.md` to map changed files to specs. For each relevant spec with ACs:
 - Extract test method names from the AC table
 - For .NET tests: `dotnet test --filter "FullyQualifiedName~{method}" -v q --no-build`
-- For TypeScript tests: `npx vitest run -t "{method}" --prefix extension`
+- For TypeScript tests: `npx vitest run -t "{method}" --prefix src/PPDS.Extension`
 - Report which ACs pass and which fail
 
 ### Step 3: Report
@@ -97,6 +134,17 @@ Read `specs/README.md` to map changed files to specs. For each relevant spec wit
 ### Verdict: FAIL — 2 issues must be resolved before proceeding
 ```
 
+## Post-Gate Reminder
+
+Gates are necessary but NOT sufficient. After gates pass:
+
+- **If changed files include webview TS/CSS/HTML** (`src/PPDS.Extension/src/panels/`): You MUST also run `/verify extension` and/or `/qa extension` for visual verification. Gates prove code compiles and tests pass — they do NOT prove it renders correctly or works as the user would experience.
+- **If changed files include CLI commands** (`src/PPDS.Cli/Commands/`, not `Serve/`): Run the command and verify the output.
+- **If changed files include MCP tools** (`src/PPDS.Mcp/`): Call the tool and verify the response.
+- **If changed files include TUI** (`src/PPDS.Cli/Tui/`): Run `npm run tui:test` for snapshot verification.
+
+**Do not commit UI/CLI/MCP changes with only gates passing.** That is how bugs ship undetected.
+
 ## Rules
 
 1. **Mechanical only** — no subjective judgments, no code review, no style opinions

.claude/commands/implement.md

@@ -39,6 +39,8 @@ Before dispatching any agents, load the specification context that will be injec
   - `src/PPDS.Mcp/` → `specs/mcp.md`
   - `src/PPDS.Migration/` → `specs/migration.md`
   - `src/PPDS.Auth/` → `specs/authentication.md`
+  - `src/PPDS.Extension/src/panels/` → `specs/per-panel-environment-scoping.md` (if panels) or relevant spec
+  - `src/PPDS.Extension/` → check `specs/README.md` for extension-related specs
 - Always include `specs/architecture.md`
 - Read each relevant spec and extract the `## Acceptance Criteria` section
 
@@ -101,7 +103,17 @@ For EACH phase in the plan, repeat this cycle:
 - If specs with ACs are relevant to this phase, check: do the AC test methods pass?
   Run: `dotnet test --filter "FullyQualifiedName~{TestMethodFromAC}" -v q --no-build`
   for each AC referenced by this phase's tasks
-- Re-run verification after fixes. Do NOT proceed until gate passes.
+- If the phase touches extension code (`src/PPDS.Extension/` directory):
+  Invoke `/verify extension` to check daemon status, tree views, and panel state.
+  Then invoke `/qa extension` to dispatch a blind verifier agent that tests the UI without seeing source code.
+- If the phase touches TUI code (`src/PPDS.Cli/Tui/`):
+  Invoke `/verify tui` to check TUI rendering.
+- If the phase touches MCP code (`src/PPDS.Mcp/`):
+  Invoke `/verify mcp` to check tool responses.
+  Then invoke `/qa mcp` to dispatch a blind verifier for tool responses.
+- If the phase touches CLI commands (`src/PPDS.Cli/Commands/`, not `Serve/`):
+  Invoke `/qa cli` to verify command output matches expectations.
+- Re-run verification after fixes. Do NOT proceed until gate passes AND /qa passes.
 
 **D. Review**
 - Use `superpowers:requesting-code-review` agent to review the phase's work against the plan

.claude/commands/panel-design.md

@@ -0,0 +1,112 @@
+# Panel Design
+
+Design a new panel or feature across all four PPDS surfaces: Daemon RPC, VS Code extension, TUI, and MCP.
+
+## Input
+
+$ARGUMENTS = feature domain name (e.g., `import-jobs`, `plugin-traces`, `web-resources`)
+
+## Process
+
+### Step 1: Load Foundation
+
+Read before doing anything:
+- `specs/CONSTITUTION.md` — A1, A2 govern multi-surface design (services are single code path, UI is thin wrapper)
+- `specs/architecture.md` — cross-cutting patterns
+- Domain-relevant specs via `specs/README.md`
+
+### Step 2: Inventory Existing Infrastructure
+
+For the target domain, check what exists at each layer:
+
+| Layer | Location |
+|-------|----------|
+| Domain services | `src/PPDS.Dataverse/Services/` (Dataverse data access) |
+| Application services | `src/PPDS.Cli/Services/` (orchestration, cross-cutting) |
+| Entity classes | `src/PPDS.Dataverse/Generated/Entities/` |
+| CLI commands | `src/PPDS.Cli/Commands/{Domain}/` |
+| Daemon RPC methods | `src/PPDS.Cli/Commands/Serve/Handlers/RpcMethodHandler.cs` |
+| MCP tools | `src/PPDS.Mcp/Tools/` |
+| TUI screens/dialogs | `src/PPDS.Cli/Tui/Screens/`, `src/PPDS.Cli/Tui/Dialogs/` |
+| VS Code panels | Extension `src/panels/` |
+
+Classify each as: **Ready**, **Partial** (needs extension), or **Missing** (must create).
+
+**Prerequisites before UI design:**
+- If the service is Missing, design it first — A1/A2 mandate services as the single code path.
+- If required entity classes don't exist in `Generated/Entities/`, entity generation is a prerequisite (Constitution I2 — never hand-edit generated entities).
+- If the domain requires Power Platform APIs outside the Dataverse SDK (e.g., Connections API via `service.powerapps.com`), identify those endpoints and any auth scope differences (`IPowerPlatformTokenProvider`).
+
+### Step 3: Design RPC Endpoints and Data Contract
+
+For each user-facing operation, define an RPC method:
+
+- Method name: `{domain}/{operation}` (e.g., `importJobs/list`, `importJobs/get`, `pluginTraces/timeline`)
+- Request/Response DTOs with typed fields — these DTOs are the shared contract consumed by VS Code and MCP
+- Error codes as domain-specific `PpdsException` ErrorCodes (D4)
+- Thread `CancellationToken` through the entire async chain (R2)
+- Accept `IProgressReporter` for operations expected to take >1 second (A3)
+
+**RPC handler pattern:** Methods are decorated with `[JsonRpcMethod("domain/operation")]` in `RpcMethodHandler.cs`. Handlers use `IDaemonConnectionPoolManager` for Dataverse access. Read existing methods for the pattern — no business logic in the handler, just parameter mapping → service call → DTO mapping.
+
+### Step 4: Design VS Code Panel
+
+Reference the `@webview-panels` skill (`.claude/skills/webview-panels/SKILL.md`) for implementation patterns (panel anatomy, message protocol, CSS patterns, environment theming).
+
+Define:
+- Panel viewType and display name
+- Message protocol (host ↔ webview discriminated union types)
+- Data display format (table, tree, detail pane, split layout)
+- User actions (toolbar buttons, context menus, keyboard shortcuts)
+- Environment scoping behavior (per-panel environment selection)
+
+### Step 5: Design TUI Screen
+
+Reference existing screens in `src/PPDS.Cli/Tui/Screens/` for patterns.
+
+Define:
+- Screen class name and menu/tab integration
+- Layout (single table, split pane, tabbed)
+- Hotkey bindings via `HotkeyRegistry`
+- Dialog inventory (detail views, filters, confirmations)
+- Streaming vs batch data loading strategy
+
+TUI screens call Application Services directly (no RPC indirection).
+
+### Step 6: Design MCP Tools
+
+Define tools for what AI agents need from this domain:
+
+- Tool name: `ppds_{domain}_{operation}`
+- Input schema with parameter descriptions
+- Output format structured for AI reasoning
+
+Not every panel action needs an MCP tool. Focus on read/query operations. Skip UI-only actions (open in browser, keyboard shortcuts, export to clipboard).
+
+### Step 7: Define Acceptance Criteria
+
+For each surface, define "complete." Use legacy panel behavior as the floor:
+
+- **Data parity:** Same fields/columns displayed as legacy
+- **Action parity:** Same operations available (refresh, filter, export, open in Maker, etc.)
+- **UX parity:** Same drill-down navigation, solution filtering, detail views
+- **Enhancements:** Improvements enabled by new architecture (better data from existing services, environment theming, per-panel environment scoping)
+
+Number all criteria: AC-01, AC-02, etc. (Constitution I3).
+
+### Step 8: Map to Work Items
+
+- Map design to existing GitHub issues
+- Flag stale issues that need updating
+- Identify gaps requiring new issues
+- Recommend worktree/branch strategy based on complexity and dependencies
+
+## Rules
+
+1. **Services first, UI second** — if the Application Service doesn't exist, design that before any UI surface.
+2. **Reference existing panels** — the first panel designed establishes patterns. Subsequent panels follow them.
+3. **Legacy as floor, not ceiling** — match what existed, improve where the new architecture enables it.
+4. **Don't port code** — understand what the legacy did, then design the proper abstraction. No inheriting legacy patterns.
+5. **One panel at a time** — complete design for one panel across all surfaces before starting the next.
+6. **Cross-reference surface parity** — VS Code panel and TUI screen must expose equivalent functionality (same data, same filters, same actions). MCP tools must cover the same read/query operations for AI agent access.
+7. **Update skills after pattern-setting work** — when the first panel in a batch establishes new patterns (e.g., virtual scrolling, complex state management), update referenced skills (`@webview-panels`, TUI equivalents) with the proven patterns before implementing subsequent panels. Include this as an explicit step in the implementation plan.