codebyplan 1.11.1 → 1.12.0

package/templates/skills/cbp-e2e-setup/reference/tauri.md

@@ -0,0 +1,147 @@
+# Tauri Reference
+
+Full install, config, and test walkthrough for Tauri desktop apps using WebDriverIO +
+tauri-driver. Source: upstream WebDriverIO docs + `.claude/context/testing/e2e.md`.
+
+## Prerequisites
+
+- Rust toolchain: `rustup --version` (install via https://rustup.rs)
+- `tauri-driver` binary: installed via Cargo (see Install below)
+- Built Tauri binary: `cargo build` must complete before any tests run
+- Node.js / pnpm available
+
+## Install
+
+```bash
+# WebDriverIO runner + framework
+pnpm add -D @wdio/cli @wdio/local-runner @wdio/mocha-framework @wdio/spec-reporter
+
+# Tauri driver (native binary — needs Cargo)
+cargo install tauri-driver
+```
+
+Verify:
+
+```bash
+which tauri-driver
+tauri-driver --version
+```
+
+## wdio.conf.ts
+
+Place at `apps/desktop/wdio.conf.ts` (or repo root for single-app repos):
+
+```ts
+import { spawn, spawnSync } from "child_process";
+import type { Options } from "@wdio/types";
+
+// Path to your built Tauri binary
+const BINARY_PATH = "./src-tauri/target/debug/your-app-name";
+
+let tauriDriver: ReturnType<typeof spawn>;
+
+export const config: Options.Testrunner = {
+  specs: ["./e2e/**/*.spec.ts"],
+  maxInstances: 1,
+  capabilities: [
+    {
+      "tauri:options": { application: BINARY_PATH },
+      maxInstances: 1,
+    },
+  ],
+  services: ["chromedriver"],
+  framework: "mocha",
+  reporters: ["spec"],
+  mochaOpts: { timeout: 60_000 },
+
+  beforeSession: async () => {
+    // Start tauri-driver before each session
+    tauriDriver = spawn("tauri-driver", [], {
+      stdio: [null, process.stdout, process.stderr],
+    });
+  },
+
+  afterSession: async () => {
+    // Kill tauri-driver after each session
+    tauriDriver.kill();
+  },
+};
+```
+
+## Build before running
+
+Tests will fail if the binary is stale or absent. Always build before running tests:
+
+```bash
+# Build the Tauri app
+cargo build --manifest-path apps/desktop/src-tauri/Cargo.toml
+
+# Then run WebDriverIO
+pnpm --filter @codebyplan/desktop wdio run wdio.conf.ts
+```
+
+Or as a combined pnpm script:
+
+```json
+{
+  "scripts": {
+    "e2e": "cargo build --manifest-path src-tauri/Cargo.toml && wdio run wdio.conf.ts",
+    "e2e:test": "wdio run wdio.conf.ts"
+  }
+}
+```
+
+## Writing tests
+
+Use `data-testid` attributes for stable targeting (Tauri WebView renders HTML):
+
+```ts
+import { browser, $ } from "@wdio/globals";
+import { expect } from "@wdio/globals";
+
+describe("Desktop app", () => {
+  it("opens the main window", async () => {
+    const navBar = await $("[data-testid='nav']");
+    await expect(navBar).toBeDisplayed();
+  });
+
+  it("navigates to settings", async () => {
+    await $("[data-testid='settings-link']").click();
+    await expect($("[data-testid='settings-panel']")).toBeDisplayed();
+  });
+});
+```
+
+Prefer `data-testid` over CSS class selectors — SCSS Modules mangle class names.
+
+## Auth probe
+
+`apps/desktop/e2e/_probe/auth.spec.ts`:
+
+```ts
+import { browser, $ } from "@wdio/globals";
+import { expect } from "@wdio/globals";
+
+describe("auth probe", () => {
+  it("can reach the main window", async () => {
+    // Tauri desktop apps often skip network auth — adapt if your app has auth
+    const root = await $("[data-testid='app-root']");
+    await expect(root).toBeDisplayed();
+  });
+});
+```
+
+## Pitfalls
+
+**Must build before run** — tauri-driver launches the binary; if the binary doesn't
+exist or is stale the session fails immediately with a confusing error.
+
+**Binary path** — the `application` path in `capabilities` must be the exact path
+to the compiled binary. Debug builds are under `src-tauri/target/debug/`, release
+builds under `src-tauri/target/release/`.
+
+**Port conflicts** — tauri-driver listens on port 4444 by default. Ensure no other
+WebDriver session is running on the same port.
+
+**CI** — Tauri desktop E2E on CI requires a display (Xvfb on Linux) and the full Rust
+build toolchain. Use GitHub-hosted `ubuntu-latest` or `macos-latest` runners.

package/templates/skills/cbp-e2e-setup/reference/vscode.md

@@ -0,0 +1,154 @@
+# VS Code Extension Reference
+
+Full install, config, and test walkthrough for VS Code extension testing using
+`@vscode/test-cli` and `@vscode/test-electron`. Source: upstream VS Code extension
+testing docs.
+
+## Prerequisites
+
+- VS Code installed (used as the test host)
+- Node.js / pnpm available
+- On Linux CI: Xvfb for a display server (extensions require a GUI)
+
+## Install
+
+```bash
+pnpm add -D @vscode/test-cli @vscode/test-electron
+```
+
+Verify:
+
+```bash
+pnpm exec vscode-test --version
+```
+
+## .vscode-test.mjs
+
+Create `.vscode-test.mjs` at the extension package root (e.g. `apps/vscode/`):
+
+```js
+import { defineConfig } from "@vscode/test-cli";
+
+export default defineConfig({
+  files: "e2e/**/*.test.js",      // compiled output path (JS, not TS)
+  extensionDevelopmentPath: ".",  // path to the extension package root
+  workspaceFolder: "test-fixtures/workspace", // optional: open a fixture workspace
+  mocha: {
+    timeout: 20_000,
+    ui: "bdd",
+  },
+});
+```
+
+For TypeScript source, compile tests before running:
+
+```json
+{
+  "scripts": {
+    "test:e2e": "tsc -p tsconfig.test.json && vscode-test",
+    "test:e2e:watch": "vscode-test --watch"
+  }
+}
+```
+
+## Extension host lifecycle
+
+`@vscode/test-electron` downloads an isolated VS Code instance, installs your extension,
+opens the workspace, and runs the Mocha suite inside the extension host process.
+
+Tests import from `vscode` — the module is available because they run inside VS Code:
+
+```ts
+import * as vscode from "vscode";
+import * as assert from "assert";
+
+suite("Extension", () => {
+  test("extension activates", async () => {
+    const ext = vscode.extensions.getExtension("yourpublisher.yourextension");
+    assert.ok(ext, "extension not found");
+    await ext.activate();
+    assert.ok(ext.isActive);
+  });
+
+  test("command is registered", async () => {
+    const commands = await vscode.commands.getCommands();
+    assert.ok(
+      commands.includes("yourextension.yourCommand"),
+      "command not registered"
+    );
+  });
+});
+```
+
+The test file runs inside the VS Code extension host — full `vscode` API is available,
+including workspace, editors, commands, and diagnostics.
+
+## Directory structure
+
+```
+apps/vscode/
+  .vscode-test.mjs
+  e2e/
+    _probe/
+      activation.test.ts
+    commands/
+      my-command.test.ts
+  test-fixtures/
+    workspace/          # optional: committed fixture files opened in tests
+```
+
+## Activation probe
+
+`apps/vscode/e2e/_probe/activation.test.ts`:
+
+```ts
+import * as vscode from "vscode";
+import * as assert from "assert";
+
+suite("Activation probe", () => {
+  test("extension activates without error", async () => {
+    // Replace with your publisher.extensionname from package.json
+    const ext = vscode.extensions.getExtension("yourpublisher.yourextension");
+    assert.ok(ext, "Extension not installed in test host");
+    if (!ext.isActive) {
+      await ext.activate();
+    }
+    assert.ok(ext.isActive, "Extension did not activate");
+  });
+});
+```
+
+## CI (GitHub Actions)
+
+Linux runners require Xvfb. Use the `xvfb-run` wrapper:
+
+```yaml
+- name: Install dependencies
+  run: pnpm install
+
+- name: Compile extension tests
+  run: pnpm --filter @codebyplan/vscode test:compile
+
+- name: Run VS Code extension tests
+  run: xvfb-run -a pnpm --filter @codebyplan/vscode test:e2e
+  env:
+    DISPLAY: ':99.0'
+```
+
+On macOS/Windows runners, Xvfb is not needed — `vscode-test` uses the native display.
+
+## Pitfalls
+
+**Wrong extensionDevelopmentPath** — if the path in `.vscode-test.mjs` doesn't point
+to the package root (where `package.json` has the `contributes` block), VS Code won't
+find the extension and activation tests will fail silently.
+
+**TypeScript source vs compiled output** — `@vscode/test-cli` runs compiled JS.
+Always compile before invoking `vscode-test` in CI.
+
+**Extension host isolation** — each test run downloads a fresh VS Code binary into a
+temp dir. This is intentional; do not try to reuse the system VS Code installation.
+
+**`vscode` module availability** — tests run inside the extension host, so `import
+* as vscode from "vscode"` resolves correctly. The same import will fail if you try
+to run these files with plain Node.js outside the host.

package/templates/skills/cbp-e2e-setup/reference/xcuitest.md

@@ -0,0 +1,185 @@
+# XCUITest Reference
+
+Full walkthrough for iOS native E2E testing with XCUITest via the Expo `withXCUITests`
+plugin. Source: Apple XCUITest docs + Expo prebuild docs.
+
+## When to use XCUITest vs Maestro
+
+| Scenario | Use |
+| --- | --- |
+| Standard UI flows (login, navigation, forms) | Maestro — simpler, cross-platform |
+| Apple Watch companion app testing | XCUITest — Maestro can't target watchOS |
+| HealthKit permission dialogs | XCUITest — system dialogs not reachable by Maestro |
+| iOS system sheet interactions (share sheet, notification permissions) | XCUITest |
+| Face ID / Touch ID prompts | XCUITest |
+| Camera/microphone permission dialogs | XCUITest |
+
+Choose Maestro first; escalate to XCUITest only when Maestro genuinely cannot reach
+the target UI.
+
+## Prerequisites
+
+- macOS with Xcode 15+ installed
+- An active Apple Developer account (free tier sufficient for Simulator testing)
+- Expo managed workflow with prebuild enabled
+- `xcbeautify` for readable output: `brew install xcbeautify`
+
+## Setup — Expo withXCUITests plugin
+
+Add the plugin to `app.config.ts` (or `app.config.js`):
+
+```ts
+export default {
+  expo: {
+    plugins: [
+      ["expo-build-properties", { ios: { useFrameworks: "static" } }],
+      // Add your withXCUITests plugin config
+      ["./plugins/withXCUITests", {}],
+    ],
+  },
+};
+```
+
+If using the community `expo-xcuitest` plugin:
+
+```bash
+pnpm add -D expo-xcuitest
+```
+
+Then in `app.config.ts`:
+
+```ts
+plugins: [
+  ["expo-xcuitest", { testTargetName: "AppUITests" }]
+]
+```
+
+## Prebuild
+
+After updating `app.config.ts`, regenerate the native project:
+
+```bash
+expo prebuild --platform ios --clean
+```
+
+`--clean` ensures a fresh native project from the current config. Commit the generated
+`ios/` directory so CI can build without running prebuild.
+
+## Swift test class
+
+Create `ios/AppUITests/AppUITests.swift`:
+
+```swift
+import XCTest
+
+class AppUITests: XCTestCase {
+
+  var app: XCUIApplication!
+
+  override func setUpWithError() throws {
+    continueAfterFailure = false
+    app = XCUIApplication()
+
+    // Inject credentials via scheme environment variables
+    app.launchEnvironment["TEST_EMAIL"] = ProcessInfo.processInfo.environment["TEST_EMAIL"] ?? ""
+    app.launchEnvironment["TEST_PASSWORD"] = ProcessInfo.processInfo.environment["TEST_PASSWORD"] ?? ""
+
+    app.launch()
+  }
+
+  func testLoginFlow() throws {
+    // Wait for the login screen
+    let emailField = app.textFields["email-input"]
+    XCTAssertTrue(emailField.waitForExistence(timeout: 10))
+
+    emailField.tap()
+    emailField.typeText(app.launchEnvironment["TEST_EMAIL"]!)
+
+    let passwordField = app.secureTextFields["password-input"]
+    passwordField.tap()
+    passwordField.typeText(app.launchEnvironment["TEST_PASSWORD"]!)
+
+    app.buttons["sign-in-button"].tap()
+
+    // Assert post-login element
+    let dashboard = app.staticTexts["Dashboard"]
+    XCTAssertTrue(dashboard.waitForExistence(timeout: 15))
+  }
+}
+```
+
+## accessibilityIdentifier targeting
+
+Set `accessibilityIdentifier` in your React Native components so XCUITest can find them:
+
+```tsx
+// In React Native
+<TextInput
+  testID="email-input"          // becomes accessibilityIdentifier on iOS
+  accessibilityLabel="Email"
+/>
+```
+
+In XCUITest, query by identifier:
+
+```swift
+app.textFields["email-input"]     // TextInput
+app.buttons["sign-in-button"]     // TouchableOpacity / Pressable
+app.staticTexts["Dashboard"]      // Text component
+```
+
+## Credentials via scheme environment variables
+
+Rather than hardcoding credentials, inject them via the Xcode scheme.
+
+In Xcode: Product → Scheme → Edit Scheme → Run → Arguments → Environment Variables.
+Add `TEST_EMAIL` and `TEST_PASSWORD` pointing to your local values.
+
+For CI, pass them via `xcodebuild`:
+
+```bash
+xcodebuild test \
+  -workspace ios/YourApp.xcworkspace \
+  -scheme YourApp \
+  -destination 'platform=iOS Simulator,name=iPhone 16,OS=latest' \
+  TEST_EMAIL="$TEST_EMAIL" \
+  TEST_PASSWORD="$TEST_PASSWORD" \
+  | xcbeautify
+```
+
+## Running tests
+
+```bash
+xcodebuild test \
+  -workspace ios/YourApp.xcworkspace \
+  -scheme YourApp \
+  -destination 'platform=iOS Simulator,name=iPhone 16,OS=latest' \
+  | xcbeautify
+```
+
+## pnpm script
+
+```json
+{
+  "scripts": {
+    "xcuitest": "xcodebuild test -workspace ios/YourApp.xcworkspace -scheme YourApp -destination 'platform=iOS Simulator,name=iPhone 16,OS=latest' | xcbeautify"
+  }
+}
+```
+
+## Pitfalls
+
+**Simulator not booted** — `xcodebuild` will boot the simulator if needed, but the
+first run is slow. Pre-boot with `xcrun simctl boot "iPhone 16"` in CI setup.
+
+**accessibilityIdentifier vs testID** — React Native maps `testID` to
+`accessibilityIdentifier` on iOS. Ensure the component renders the prop all the way
+through; some wrappers drop it.
+
+**waitForExistence timeout** — always use `waitForExistence(timeout:)` rather than
+asserting element existence immediately. React Native renders asynchronously; the
+element may not be in the view hierarchy at the instant of the assertion.
+
+**Derived data cache** — stale derived data can cause confusing failures. Clear with
+`rm -rf ~/Library/Developer/Xcode/DerivedData` if tests pass locally but fail after
+a schema change.

package/templates/skills/cbp-frontend-ui/SKILL.md

@@ -10,7 +10,7 @@ effort: xhigh
 Invoked twice per round in non-`claude_only` profiles:
 
 1. `round-executor` Step 3.8 — `phase: 'style_only'`, no e2e screenshots. Reviews token/spacing/typography/color/cohesion against the just-written code.
-2. `/cbp-round-execute` Step 5b — `phase: 'screenshot_review'`, with screenshots from `test-e2e-agent`. Reviews rendered output and detects baseline regressions.
+2. `/cbp-round-execute` Step 5b — `phase: 'screenshot_review'`, with screenshots from the `cbp-e2e-*` specialists. Reviews rendered output and detects baseline regressions.
 
 Default `phase: 'full'` runs everything (back-compat for any caller not yet migrated). Inline counterpart of the up-front `frontend-design` skill — `frontend-design` decides direction before code; `frontend-ui` reviews and polishes after code.
 
@@ -36,7 +36,7 @@ input:
   context:
     checkpoint_goal: string
     round_requirements: string
-  e2e_screenshots:                          # Required for phase 'screenshot_review' or 'full' (when present); empty / omitted for 'style_only'. Sourced from round.context.e2e_output.screenshots (populated by test-e2e-agent at /cbp-round-execute Step 5).
+  e2e_screenshots:                          # Required for phase 'screenshot_review' or 'full' (when present); empty / omitted for 'style_only'. Sourced from the aggregated round.context.e2e_outputs[*].screenshots (populated by the cbp-e2e-* specialists at /cbp-round-execute Step 5).
     - test_name: string
       path: string                          # Repo-relative or absolute path to PNG
       page_or_screen: string
@@ -213,7 +213,7 @@ The skill's auto-fix capability is for in-scope polish, not opportunistic sweeps
 **Specifically forbidden** (always out of scope, never edited regardless of `files_changed`):
 
 - `.claude/**` — managed infrastructure under user-level governance
-- Project test infrastructure (e.g., `playwright.config.*`, `e2e/**`) — governed by `test-e2e-agent`
+- Project test infrastructure (e.g., `playwright.config.*`, `e2e/**`) — governed by the `cbp-e2e-*` specialist agents
 - DB migrations (e.g., `supabase/migrations/**`) — governed by `database-agent`
 - Vendor mirrors and read-only reference trees
 
@@ -254,9 +254,9 @@ Go beyond fixing violations — actively improve visual quality. If spacing coul
 
 - **Loaded twice per round** (non-`claude_only` profiles):
   1. `round-executor` Step 3.8 with `phase: 'style_only'` and empty `e2e_screenshots[]` — reviews the just-written code's tokens/spacing/typography/color/cohesion (mandatory when files_changed contains UI / styling files)
-  2. `/cbp-round-execute` Step 5b with `phase: 'screenshot_review'` and screenshots from `round.context.e2e_output.screenshots` — runs Phase 6.5 only (rendered-output review + baseline regressions). Skipped when no e2e ran (`claude_only` / `backend` / `has_ui_work === false`).
-- **Also invoked by**: `/cbp-checkpoint-check` (TASK-2 deliverable, future) with screenshots from a whole-checkpoint e2e run
-- **Consumes**: `e2e_screenshots[]` from `round.context.e2e_output.screenshots` (populated by `test-e2e-agent` at `/cbp-round-execute` Step 5)
+  2. `/cbp-round-execute` Step 5b with `phase: 'screenshot_review'` and screenshots aggregated from `round.context.e2e_outputs[*].screenshots` — runs Phase 6.5 only (rendered-output review + baseline regressions). Skipped when no e2e ran (`claude_only` / `backend`, or no eligible framework in `.codebyplan/e2e.json`).
+- **Also invoked by**: `/cbp-checkpoint-check` with screenshots aggregated from a whole-checkpoint e2e run
+- **Consumes**: `e2e_screenshots[]` aggregated from `round.context.e2e_outputs[*].screenshots` (populated by the `cbp-e2e-*` specialists at `/cbp-round-execute` Step 5)
 - **Output written to**: `round.context.frontend_ui_review` — when invoked twice per round, the second invocation merges with the first
 - **Downstream gate**: this skill emits `findings[]` only. Baseline-regression findings surface as a BLOCKING gate at `/cbp-round-end` Step 7 (baselines never auto-accepted); rendered-visual critical findings are surfaced in the Step 7 findings presentation.
 - **Paired with**: `frontend-design` (pre-implementation aesthetic decision), `frontend-ux` (interaction-quality self-review, also Step 3.8)

package/templates/skills/cbp-frontend-ux/SKILL.md

@@ -148,7 +148,7 @@ This rule applies to every file. The skill's auto-fix surface exists because in-
 **Specifically forbidden** (always out of scope, never edited regardless of `files_changed`):
 
 - `.claude/**` — managed infrastructure under user-level governance
-- Project test infrastructure (e.g., `playwright.config.*`, `e2e/**`) — governed by `test-e2e-agent`
+- Project test infrastructure (e.g., `playwright.config.*`, `e2e/**`) — governed by the `cbp-e2e-*` specialist agents
 - DB migrations (e.g., `supabase/migrations/**`) — governed by `database-agent`
 - Vendor mirrors and read-only reference trees
 

package/templates/skills/cbp-git-worktree-remove/SKILL.md

@@ -116,7 +116,12 @@ Only use `--force` if the user confirms.
 
 ### Step 9: Delete Branch (if requested)
 
-**Protected branch check:** If `$BRANCH_NAME` is `main`, `development`, or `preview` — refuse deletion and stop.
+**Protected branch check:** Read the protected set from `.codebyplan/git.json`:
+```bash
+PRODUCTION=$(jq -r '.branch_config.production // "main"' .codebyplan/git.json)
+PROTECTED=$(jq -r '.branch_config.protected[]? // empty' .codebyplan/git.json)
+```
+If `$BRANCH_NAME` equals `$PRODUCTION` or appears in `$PROTECTED` — refuse deletion and stop.
 
 **Checkpoint verification:** Before deleting a feat branch, verify that the associated checkpoint has completed via `/cbp-checkpoint-end`. If the checkpoint is still active, warn the user that unshipped work may be lost.
 
@@ -126,6 +131,17 @@ git branch -d "$BRANCH_NAME" && git push origin --delete "$BRANCH_NAME"
 
 Use `-d` (not `-D`) to prevent deleting unmerged work. If it fails because the branch is not fully merged, inform the user and ask if they want to force delete with `-D`.
 
+After the git branch delete succeeds, run a conditional Supabase preview-branch teardown for `$BRANCH_NAME`:
+
+> Lifecycle contract: see [[supabase-branch-lifecycle]].
+
+- Call `mcp__supabase__list_branches` with `project_id: rrvtrumtkhrsbhcyrwvf`.
+- Scan the returned list for an entry whose `name` exactly equals `$BRANCH_NAME`.
+- If found: call `mcp__supabase__delete_branch` with its `branch_id`. Report "Supabase preview branch deleted: `$BRANCH_NAME`".
+- If not found: no-op silently — the GitHub integration may have already removed it on PR close; not-found is success, NOT an error.
+- If the `list_branches` call itself fails (network, auth, or a non-success response — distinct from a successful lookup that returns no match): emit a non-blocking warning that the Supabase preview branch for `$BRANCH_NAME` may still exist and should be verified in the dashboard. Do not treat an API failure as a not-found success.
+- Never delete the parent project `rrvtrumtkhrsbhcyrwvf` itself or any persistent/production branch.
+
 ### Step 10: Show Result
 
 ```