fix(sessions): route new sessions to the correct project when server omits directory (#1637, #2270)

.agents/skills/clack-cli-patterns/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: clack-cli-patterns
-description: Use when creating or modifying terminal CLI commands, prompts, or output formatting in OpenChamber. Enforces Clack UX standards with strict parity and safety across TTY/non-TTY, --quiet, and --json modes.
+description: Use when creating or modifying OpenChamber CLI commands, prompts, terminal output, non-TTY behavior, `--quiet`, or `--json` behavior.
 license: MIT
 compatibility: opencode
 ---
@@ -150,56 +150,9 @@ For each command/subcommand, manually verify:
 4. non-TTY behavior (e.g. piped)
 5. error path in both human and json modes
 
-## Copy/Paste Snippets
-
-### Prompt Guard
-
-```js
-if (canPrompt(options)) {
-  const value = await select({
-    message: 'Choose an option',
-    options: [{ value: 'a', label: 'Option A' }],
-  });
-  if (isCancel(value)) {
-    cancel('Operation cancelled.');
-    return;
-  }
-}
-```
-
-### Non-Interactive Fallback
-
-```js
-if (!resolvedValue) {
-  if (canPrompt(options)) {
-    // prompt path
-  } else {
-    throw new Error('Missing required value. Provide --flag <value>.');
-  }
-}
-```
-
-### Spinner Guard
-
-```js
-const spin = createSpinner(options);
-spin?.start('Running operation...');
-// ...work...
-spin?.stop('Done');
-```
-
-### JSON vs Human Output
-
-```js
-if (options.json) {
-  printJson({ ok: true, data });
-  return;
-}
-
-intro('Operation');
-log.success('Completed');
-outro('done');
-```
+## Reusable Snippets
+
+Load `references/snippets.md` when implementing prompt guards, non-interactive fallback, spinner lifecycle, or JSON/human output branching.
 
 ## Implementation Checklist
 
@@ -211,6 +164,6 @@ outro('done');
 
 ## References
 
-- Policy source: `AGENTS.md` (CLI Parity and Safety Policy)
+- This skill is the canonical CLI parity and safety policy.
 - Terminal CLI precedent: `packages/web/bin/cli.js`
 - Output adapter precedent: `packages/web/bin/cli-output.js`

.agents/skills/clack-cli-patterns/references/snippets.md

@@ -0,0 +1,50 @@
+# CLI Output Snippets
+
+## Prompt Guard
+
+```js
+if (canPrompt(options)) {
+  const value = await select({
+    message: 'Choose an option',
+    options: [{ value: 'a', label: 'Option A' }],
+  });
+  if (isCancel(value)) {
+    cancel('Operation cancelled.');
+    return;
+  }
+}
+```
+
+## Non-Interactive Fallback
+
+```js
+if (!resolvedValue) {
+  if (canPrompt(options)) {
+    // prompt path
+  } else {
+    throw new Error('Missing required value. Provide --flag <value>.');
+  }
+}
+```
+
+## Spinner Guard
+
+```js
+const spin = createSpinner(options);
+spin?.start('Running operation...');
+// ...work...
+spin?.stop('Done');
+```
+
+## JSON vs Human Output
+
+```js
+if (options.json) {
+  printJson({ ok: true, data });
+  return;
+}
+
+intro('Operation');
+log.success('Completed');
+outro('done');
+```

.agents/skills/desktop-shell/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: desktop-shell
+description: Use when changing Electron main/preload code, desktop IPC, native windows, menus, dialogs, notifications, updater behavior, deep links, SSH or tunnels, child processes, packaged startup, or Windows process spawning.
+---
+
+# Desktop Shell
+
+## Read First
+
+Read `packages/electron/README.md` and nearby `packages/electron` code before editing.
+
+## Runtime Boundary
+
+- Electron boots `@openchamber/web` in the same Node process and loads the UI over loopback. Do not introduce a sidecar server process.
+- Keep OpenCode feature backends and shared domain logic in web/server or runtime APIs.
+- Keep Electron focused on inherently native behavior: windows, menus, dialogs, notifications, updater, deep links, runtime host switching, privileged IPC, SSH, and tunnel lifecycle.
+- Shared renderer-facing contracts belong in `packages/ui`; shared server behavior belongs in `packages/web`.
+- Electron is the desktop release target.
+
+## IPC And Security
+
+1. Add a preload bridge shape only when renderer-facing capability changes.
+2. Handle the native operation in `main.mjs`.
+3. Gate privileged commands in the main process; renderer checks are not security boundaries.
+4. Expose the narrowest payload and never expose filesystem, shell, tokens, or host secrets to remote pages.
+5. Do not import Electron from shared UI code.
+
+Remote runtime pages must not gain local desktop privileges. Treat deep links, host imports, stored credentials, and runtime switching as trust-boundary operations.
+
+## Windows Background Processes
+
+Non-user-visible child processes must never flash a console window.
+
+- Spawn the target executable directly with `windowsHide: true`.
+- Use `stdio: 'ignore'` for detached/background helpers and call `unref()` when they must outlive Electron.
+- Avoid `cmd.exe /c`, batch shims, `taskkill`, `ping` delays, and pipelines that create console grandchildren. `windowsHide` reliably controls only the directly spawned process.
+- Prefer native Node/Electron APIs when available.
+- For delayed work that must survive app exit, spawn one first-level hidden helper, such as `powershell.exe -NoProfile -NonInteractive -WindowStyle Hidden -EncodedCommand ...`; perform delay and work inside that process with cmdlets.
+- Omit hidden-process behavior only for intentionally user-visible terminals or applications.
+
+## Packaging And Lifecycle
+
+- Keep native/external modules configured according to `packages/electron/README.md` and `bundle-main.mjs`.
+- Preserve startup, quit, updater, notification, and deep-link behavior across development and packaged builds.
+- Ensure cleanup tolerates partial startup and repeated shutdown signals.
+- Do not infer readiness from stdout when an in-process callback or returned server handle exists.
+
+## Validation
+
+Run the Electron package type-check/lint commands from `package.json` and focused tests. For startup, preload, routing, or packaging changes, test both HMR development and bundled UI mode. For Windows process work, inspect the complete process tree and verify no console flash; a successful command alone is insufficient.

.agents/skills/drag-to-reorder/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: drag-to-reorder
-description: Use when implementing drag-to-reorder / sortable lists or chips in OpenChamber with @dnd-kit — covers the correct setup for BOTH desktop and mobile (touch), the variable-width "stretch" fix, the wrapping multi-row strategy choice, and the pitfalls (infinite update loop, offset overlay) we already hit and fixed.
+description: Use when implementing or modifying OpenChamber sortable or drag-to-reorder behavior, especially `@dnd-kit`, touch/mobile interactions, variable-width items, or wrapping layouts.
 license: MIT
 compatibility: opencode
 ---

.agents/skills/openchamber-change-discipline/SKILL.md

@@ -0,0 +1,122 @@
+---
+name: openchamber-change-discipline
+description: Use when implementing, fixing, refactoring, or otherwise modifying OpenChamber source code, dependencies, exports, build configuration, generated assets, package contracts, or module ownership.
+---
+
+# OpenChamber Change Discipline
+
+## Core Principle
+
+Make the smallest complete change and validate at the narrowest level that covers the real risk.
+
+Identify existing behavior covered by tests or callers; preserve it unless the requested change explicitly replaces it.
+
+## Before Editing
+
+1. Read the nearest `DOCUMENTATION.md` and package `README.md` when present.
+2. Inspect nearby implementation and tests before introducing a pattern.
+3. Load every additional project skill whose trigger matches the change.
+4. Classify the highest applicable change risk below.
+5. Identify affected consumers, runtimes, persisted data, and public exports.
+
+When instructions materially conflict, stop and resolve the conflict instead of silently choosing one.
+
+## Risk Classification
+
+| Risk | Examples | Planning consequence |
+|---|---|---|
+| Local implementation | Private helper or component behavior in one package | Preserve observable behavior; validate the owning package |
+| Module contract | Exported API/type or documented module invariant | Inspect consumers; update contract tests and owning docs |
+| Cross-workspace contract | Shared UI/runtime/package shape consumed by multiple workspaces | Trace every actual consumer and runtime; validate across workspaces |
+| Persisted or external behavior | Stored settings/data, routes, IDs, files, CLI output | Define compatibility, round-trip, failure, and conversion behavior for existing consumers |
+| Platform/runtime behavior | Electron, VS Code, mobile, relay, native or packaged behavior | Run the relevant runtime/build/integration validation |
+
+Apply every matching category. Do not escalate local work into workspace-wide ritual, and do not treat a type-only export as local merely because it emits no JavaScript.
+
+## Mandatory Rules
+
+- Identify existing behavior covered by tests or callers; preserve it unless explicitly replaced.
+- Do not add dependencies unless explicitly requested.
+- Do not add compatibility paths without a concrete persisted or external consumer.
+- Enforce security and correctness in core logic, not only UI controls or prompts.
+- Never add, persist, or log secrets, bearer tokens, pairing data, or sensitive user content.
+- Make data loss, partial failure, rollback, and fallback behavior explicit.
+- Update owning documentation when module ownership, contracts, or invariants change.
+- Complete the cumulative validation required by every applicable risk category.
+
+## Engineering Preferences
+
+- Prefer the smallest correct change; avoid drive-by refactors.
+- Keep orchestration entrypoints thin and move domain logic to focused modules.
+- Prefer explicit dependencies and dependency injection over hidden module coupling.
+- Follow local TypeScript types; avoid `any`, blind casts, and guessed payload shapes.
+- Prefer early returns and explicit branches over nested conditionals.
+
+## Review Prompts
+
+Before broadening a change, ask:
+
+- Is the new abstraction reused or merely possible to reuse?
+- Is the code in the package that owns the behavior?
+- Does the change alter shared UI contracts across web, desktop, VS Code, or mobile?
+- Does it change persisted data, IDs, routes, exports, generated files, or package entrypoints?
+- Can failure leave optimistic state, caches, files, or remote state stranded?
+
+For partial or destructive flows, answer explicitly:
+
+- What remains valid after the first failure?
+- What is rolled back or cleaned up?
+- What can be retried or resumed safely?
+- What does the user observe?
+
+For persisted data, require a migration only when existing stored data needs conversion. Test downgrade compatibility only when older application versions are a concrete supported consumer. "Rollback" means preserving/restoring valid state after a failed write or migration unless a broader contract explicitly says otherwise.
+
+Do not hide a required architectural migration behind a local heuristic. Do not turn a local fix into a speculative rewrite.
+
+## Validation Matrix
+
+Use `package.json` scripts as the command source of truth.
+
+| Change | Minimum validation |
+|---|---|
+| Executable source | Focused tests plus package-scoped type-check and lint |
+| Cross-workspace/shared contract | Workspace-wide type-check and lint plus affected builds/tests |
+| Added/deleted/renamed source file, export/type/entrypoint/import shape | `bun run dead-code` in addition to relevant checks |
+| Persisted or external contract | Compatibility and round-trip tests; conversion/malformed-old-data tests when old data needs migration; failed-write/migration rollback tests |
+| Dependency or lockfile | Workspace-wide checks and affected builds |
+| Generated asset | Regeneration check plus consumer build/test |
+| Docs-only or isolated config | Narrow syntax/schema/link validation; do not run unrelated full suites |
+| Platform/runtime behavior | Relevant runtime build or manual/integration check; static checks are insufficient |
+
+Use a sufficiently long timeout for broad checks. Report exactly what ran and what did not.
+
+Choose affected builds/tests by tracing real consumers and runtime boundaries, not by running everything reflexively.
+
+For type-only shared contracts, validate compile-time consumers. Add runtime serialization tests when the contract crosses a process, persistence, network, or untyped JavaScript boundary.
+
+## Test Design
+
+- Prefer observable contracts, state transitions, failure handling, rollback, and operation counts.
+- Test private helpers through public/module behavior when that captures the risk clearly.
+- Assert internal map shape, helper calls, or call order only when that structure/order is itself a contract.
+- Keep refactor tests resilient to equivalent internal implementations.
+- For behavior-preserving refactors, establish the current behavior before changing structure.
+
+## Completion Standard
+
+- Implement the behavior end to end, including rollback and cleanup.
+- Run focused regression tests for the changed contract.
+- Preserve unrelated changes encountered in shared files.
+- Re-read the owning docs and update them when the implementation changed their truth.
+- Do not claim runtime, relay, performance, or platform correctness from type-check/lint alone.
+
+## Common Failure Modes
+
+| Failure | Correction |
+|---|---|
+| Refactoring nearby code while fixing one bug | Keep the diff scoped unless the nearby change is required |
+| Adding a helper used once | Keep direct code until reuse or composability is real |
+| Swallowing an error for smoother UX | Preserve the failure signal and handle presentation separately |
+| Updating a bridge without all runtimes | Load the runtime/API skill and make parity explicit |
+| Running only broad checks | Add focused tests that exercise the changed behavior |
+| Running only focused checks after a shared-contract change | Add workspace-wide validation |