gemiterm 2.0.0 → 2.1.1

package/openspec/changes/archive/2026-06-08-command-spec-conformance/design.md

@@ -1,194 +0,0 @@
-## Context
-
-The GemiTerm Bun TypeScript CLI completed its Maestro migration in the recent `v2-install-migration` and `cross-platform-build-and-ci` changes. Three small but real spec-conformance gaps remain in the `continue`, `delete`, and `list` commands that were called out in the Maestro Phase 4 plan (`Phase-04-Commands.md:11, 31, 47`):
-
-1. `continue-command.ts:50-69` and `:75-130` never call `ProfileAuthManager.findProfileForConversation`; the `SendMessageCommand` is sent to the default profile regardless of where the conversation actually lives. In a multi-profile setup (e.g. a user with a `work` and a `personal` profile) the message goes to the wrong account.
-2. `delete-command.ts:51-77` has the same defect for `DeleteConversationCommand`.
-3. `list-command.ts:129-136` calls `formatChatList(chats)` without the new Profile column that the spec requires when `--all-profiles` is set. Multi-profile users can list chats from every profile but cannot tell which profile owns which conversation in the text output.
-
-Compounding problem #1: `ProfileAuthManager.findProfileForConversation` in `src/services/profile-auth-manager.ts:46-60` is itself broken. The method body iterates over all profiles, checks `profileManager.getStatus(name).isActive` for each, and returns the **first** active profile. The `conversationId` argument is never used. The method signature is correct (`findProfileForConversation(conversationId: string): string | null`) but the implementation is the first-active-wins fallback, which is a silent no-op for single-profile users and an outright wrong-profile return for multi-profile users. The 8 unit tests in `tests/services/profile-auth-manager.test.ts:88-223` currently encode the BUGGY behavior; updating them is part of the fix.
-
-Constraints:
-- **SENSITIVE AREA** (per the maintainer's note): `src/services/playwright-cli-driver.ts`, `src/services/cookie-monitor.ts`, and `src/services/auth-service.ts` are off-limits. This change touches only `profile-auth-manager.ts`, `gemini-client-wrapper.ts`, the three CLI command files, `core/types.ts`, `core/command-handlers.ts` (interface only), `infrastructure/formatters.ts`, and the test files. No cookie-capture or browser-lifecycle code is modified.
-- **Baseline gate:** 432/432 tests must continue to pass; the change adds new tests on top.
-- **No CLI-breaking changes**: the `profile` field added to `ChatInfo` is optional, and the Profile column only renders when the user passes `--all-profiles`. Existing serialized JSON output is byte-compatible.
-- **Public method signatures MUST NOT change** for `findProfileForConversation(conversationId: string): string | null` — it is wired into the registry and the test fixtures assert this exact shape.
-
-Stakeholders: multi-profile end users (the primary beneficiaries of the fix), single-profile users (whose behavior must not change), maintainers reviewing the test-file changes (need clear documentation that the 8 changed tests document a bug, not a regression), and the auth/playwright maintainers (who do not need to touch their code).
-
-## Goals / Non-Goals
-
-**Goals:**
-- `findProfileForConversation(conversationId)` MUST actually inspect each profile's chat list to find the one that owns the conversation; it MUST return `null` when no profile owns it.
-- `continue` and `delete` commands MUST look up the owning profile before sending the `SendMessageCommand` / `DeleteConversationCommand`, MUST route the request to that profile's GeminiClient, and MUST surface a clear `AuthenticationError` with remediation guidance when no profile owns the conversation.
-- `list --all-profiles` MUST render a Profile column in the text table and a `profile` field on each `ChatInfo` in the JSON output; `list` without `--all-profiles` MUST behave exactly as today (4 columns, no `profile` field on chats).
-- The 8 existing `profile-auth-manager.test.ts` tests MUST be updated to encode the new correct behavior. The test count for that file increases (8 → 11+) after the change.
-- The 432/432 baseline test count MUST continue to pass; the new tests are added on top.
-
-**Non-Goals:**
-- Modifying `src/services/playwright-cli-driver.ts`, `src/services/cookie-monitor.ts`, or `src/services/auth-service.ts`. The cookie-capture and browser-lifecycle paths are not touched.
-- Auto-migrating the per-profile conversation cache across logins. The cache is built fresh on every `findProfileForConversation` call (or per-session, if the simpler in-memory cache is chosen).
-- Adding a new `--profile <name>` flag to `continue` or `delete` for explicit override. The error message in the help text mentions it as a possible follow-up, but it is not implemented in this change.
-- Changing the public surface of `IGeminiClientService` in a breaking way. The new per-profile routing is additive: either the interface gains a `profileName` field on the existing payload, or a profile-scoped client constructor is added; either way, all existing callers keep working.
-- Multi-profile interactive flows (a session that switches profiles mid-conversation). Out of scope; the change is for one-shot `continue` and `delete` invocations.
-
-## Decisions
-
-### D1. `findProfileForConversation` uses a per-profile chat-list lookup, not first-active-wins
-
-The current implementation at `src/services/profile-auth-manager.ts:46-60` returns the first active profile in the loop, ignoring `conversationId`. The new implementation iterates over all profiles, calls a new `profileHasConversation(profileName, conversationId): Promise<boolean>` helper on `GeminiClientService` for each, and returns the first profile that returns `true`. If no profile returns `true`, the method returns `null` (the caller's cue to throw `AuthenticationError`).
-
-This is the only correct semantic: a profile's `isActive` flag (cookies are fresh) tells you nothing about whether the conversation lives in that profile. The current code confuses "active" (has valid cookies) with "owns the conversation" (the conversation ID is in that profile's server-side chat list). These are independent properties.
-
-**Why this approach over a fingerprint in the cookies themselves?** The conversation ID is generated server-side by Gemini; the local cookies do not contain it. There is no client-side signal that says "this conversation belongs to this account". The only authoritative answer is the server, and the only way to ask the server is to use that profile's cookies to call `listChats()` and look for the ID. The cookie-based cache path (D2) optimizes this for the common case.
-
-**Alternative considered:** Read the profile's `storage_state.json` and look for the conversation ID in the cookies' metadata. Rejected: the conversation ID is server-side state, not stored in the cookies.
-
-**Alternative considered:** Embed a profile-aware lookup in the GeminiClientService constructor and route every command through it. Rejected: a step too far for this change; see D3 for the routing decision.
-
-### D2. Conversation→profile cache is built on first lookup, scoped to the call
-
-The naive implementation of D1 calls `listChats()` once per profile, which is N network round-trips (where N is the number of active profiles). For a user with 3 active profiles, `continue` would issue 3 GETs to `gemini.google.com/app/api/chat/history` before sending the message. This is unacceptable latency on every `continue` and `delete` call.
-
-Mitigation: an in-memory `Map<string, string>` (conversationId → profileName) is built once per `findProfileForConversation` call by iterating over all profiles, calling `listChats()` for each, and recording each conversation ID's owning profile. The cache is then queried in a single `Map.get` per profile. Total work: still N `listChats` calls, but the iteration is `O(N + C)` where `C` is the total number of chats across all profiles, and the per-iteration cost is a `Map.has` check rather than a full loop. The cache is also reusable: a subsequent `findProfileForConversation` call within the same CLI invocation can reuse the cache (a follow-up task; this change scopes the cache to a single call for simplicity and to avoid stale-cache bugs after a delete).
-
-The cache is not persisted to disk. The Gemini conversation list is fetched fresh on every CLI invocation; the cache is purely a per-call optimization.
-
-**Alternative considered:** Persist the cache to disk under `%APPDATA%\gemiterm\conversation-cache.json` and reuse it across invocations. Rejected: stale-cache risk. A user who deletes a conversation from `work` would have the cache report the conversation as still being in `work` on the next `gemiterm delete`. Refreshing the cache is the same cost as the fresh call; persistence is not worth the staleness surface.
-
-**Alternative considered:** Build the cache on first `list-chats` query (which already iterates per profile in `--all-profiles` mode) and stash it in the mediator. Rejected: couples `list` and `continue`/`delete` lifecycle. The per-call cache is self-contained and easy to reason about.
-
-### D3. Per-profile routing is exposed via an additive `profileName` field on the command payloads, not a profile-scoped GeminiClient constructor
-
-The `IGeminiClientService` interface in `src/core/command-handlers.ts:90-94` exposes `deleteChat`, `sendMessage`, and `startNewChat` — none of which takes a profile. The `IGeminiClientQueryService` in `src/core/query-handlers.ts:56-60` exposes `listChats`, `fetchChat`, `listModels` — also none takes a profile. To route `continue` to a non-default profile, one of two shapes is needed:
-
-(a) **Additive `profileName` field** on `SendMessageCommandPayload` and `DeleteConversationCommandPayload`. The `SendMessageCommandHandler` and `DeleteConversationCommandHandler` read `payload.profileName` and forward it to a per-profile-aware method on the service (or to a factory that builds a per-profile `GeminiClientService`).
-
-(b) **Profile-scoped client constructor** on the command. The command builds a `GeminiClientService` with the resolved profile's cookies (`cookieStorageService.loadCookiesForProfile(profileName)`) and passes it explicitly to the mediator or to a new `IGeminiClientService.forProfile(name)` method.
-
-The chosen approach is **(a) with a thin factory helper**: add `profileName?: string` to `SendMessageCommandPayload` and `DeleteConversationCommandPayload`; add a `forProfile(name: string)` method to `GeminiClientService` that returns a new instance configured with that profile's cookies (does not mutate `this`); the `SendMessageCommandHandler` and `DeleteConversationCommandHandler` resolve the profile name from the payload, build the per-profile client via `forProfile`, and call its `sendMessage` / `deleteChat`. The mediator continues to own the **default-profile** client for backwards compatibility, and the command payload carries the **explicit** profile for multi-profile routing.
-
-Why (a) over (b):
-- (a) keeps the mediator wiring unchanged for the default profile. The existing `SendMessageCommandHandler` is constructed with a single `IGeminiClientService` in `src/cli/index.ts` (or wherever the handlers are registered) and the existing flow keeps working.
-- (a) localizes the per-profile routing inside the handler. The handler is the only place that needs to know "this is a multi-profile call", which is exactly where the knowledge belongs.
-- (b) would require either passing a per-profile client into the command's `execute(args, context)` (a new `CliCommandContext` field — invasive) or building a per-profile client inside the command and calling the mediator with a custom command handler. Both are more wiring than (a).
-- The `forProfile` factory method on `GeminiClientService` is a small, additive change to the class (it does not change the existing constructor signature).
-
-**Alternative considered:** Construct the per-profile client inside the command and call the method directly (bypass the mediator for the actual API call). Rejected: breaks the mediator pattern that the rest of the CLI uses; the `IGeminiClientService` injection at the handler boundary is the right place to inject the per-profile instance.
-
-**Alternative considered:** Make `IGeminiClientService` carry a `forProfile` method, and have the handler call it on its injected instance. The injected instance is the default-profile client; `forProfile` returns a new instance. This is the same as (a) — the payload's `profileName` field is the trigger. The "expose via interface" detail is implementation, not design.
-
-### D4. `ChatInfo.profile` is optional; `formatChatList` only renders the column when the flag is set
-
-The `ChatInfo` type at `src/core/types.ts:9-14` gains `profile?: string`. The `ListChatsQueryResult.chats` array is unchanged in shape (each chat may or may not have a `profile` field). The `ListChatsQueryHandler` propagates the profile name to each chat when `payload.allProfiles === true`; otherwise, the chats are returned without a `profile` field (matches today's behavior exactly).
-
-`formatChatList(chats)` keeps its 4-column layout (ID / TITLE / DATE / PIN) when called with no second argument — every existing caller's output is byte-identical. A new optional second argument `options?: { includeProfileColumn?: boolean }` flips on a 5th `PROFILE` column (width 14 chars, matching the style of the other columns).
-
-`list-command.ts:130` changes from `formatChatList(chats)` to `formatChatList(chats, { includeProfileColumn: options.allProfiles })`. The flag is plumbed through cleanly.
-
-**Why the column is gated on `--all-profiles`:** In single-profile mode the Profile column would always show the same value for every row — a column of identical strings is noise. The column only earns its space in multi-profile mode where the rows differ.
-
-**Why the JSON `profile` field is also gated:** JSON consumers (scripts, future web tools) that only deal with single-profile flows would see a `profile: "default"` field appear on every chat after this change, even though they don't need it. Gating on `allProfiles` keeps the JSON shape byte-compatible for the single-profile case.
-
-**Alternative considered:** Always include the `profile` field on every chat in JSON output. Rejected: changes the JSON contract for single-profile users. Backward compat wins.
-
-**Alternative considered:** Always include the `profile` field, default to the active profile name. Rejected: same reasoning — single-profile users don't need the field, and the field is undefined for any chat fetched without `--all-profiles`.
-
-### D5. The 8 existing `profile-auth-manager.test.ts` tests are updated; the change IS the fix
-
-The 8 unit tests in `tests/services/profile-auth-manager.test.ts:88-223` (in the `describe("findProfileForConversation")` block) currently assert:
-- "returns first active profile" — the BUG.
-- "returns null when no active profiles" — still correct under the new implementation.
-- "returns null when no profiles exist" — still correct under the new implementation.
-
-The first test encodes the bug. Updating it to assert "returns the profile whose chat list contains the conversation ID" is the fix, not a regression. The new test ("returns first active profile" → "returns the profile that owns the conversation") is part of the 3-4 new tests added in the same `describe` block, and the test count goes from 8 → 11+.
-
-The PR body MUST explicitly call this out: "the 8 existing tests document the bug; updating them to encode the correct per-profile lookup is the fix." The task list (group 3) includes a "document the test change in the test file's leading comment" sub-task to make this discoverable to reviewers.
-
-**Why we don't keep the old test as a separate `@deprecated` block:** it asserts wrong behavior. Leaving it in place would be a perpetual foot-gun for any future maintainer who runs `bun test` and sees a green light while the bug is present in production. The right move is to delete the wrong assertion and replace it with the correct one.
-
-### D6. When no profile owns the conversation, the command throws `AuthenticationError` with a remediation message
-
-If `findProfileForConversation(conversationId)` returns `null`, the command (`continue` or `delete`) throws `AuthenticationError` with this message:
-
-> "Could not find a profile that owns conversation '<id>'. Run 'gemiterm list --all-profiles' to see which profile it belongs to, then 'gemiterm continue <id> <msg> --profile <name>' to specify the profile explicitly."
-
-The error is thrown at the command layer (after the lookup, before the mediator send), so the user sees the message in the standard error-handling path that all CLI commands use (the `try/catch` in `continue-command.ts:112-116` and `delete-command.ts:77-81`). The exit code is non-zero (the existing error path sets `process.exitCode = 1` or `process.exit(1)`).
-
-**Why not silently fall back to the default profile:** that hides the bug. A user with two profiles, a typo'd conversation ID, and a silent fallback to the default profile would conclude "I sent a message to a non-existent chat and the server accepted it" — worse than a hard error. The hard error tells the user exactly what went wrong and how to fix it.
-
-**Why `AuthenticationError` specifically (not `ValidationError` or a new error class):** the conversation-ownership check is logically a "is this profile authenticated to act on this conversation" check; the existing `AuthenticationError` class in `src/core/errors.ts` is the right semantic. The error code stays the same so existing error-handling middleware doesn't need to change.
-
-**Alternative considered:** Print a warning and fall back to the default profile. Rejected: see above — silently doing the wrong thing is worse than failing loud.
-
-**Alternative considered:** Introduce a new `ConversationNotFoundError` class. Rejected: the message is the same shape as `AuthenticationError`, the user's remediation is the same, and adding a new error class for one call site is over-engineering. The follow-up could add `--profile <name>` to override, and the error class can be split later if needed.
-
-### D7. No separate test file for `profileHasConversation`; coverage is via the integration tests for `continue` and `delete`
-
-`GeminiClientService` (`src/services/gemini-client-wrapper.ts`) has no direct unit tests today; the existing coverage for its methods is the integration test suites for `list`, `fetch`, and the other commands that go through the mediator. Adding a unit test file `tests/services/gemini-client-wrapper.test.ts` is a separate change (the maintainer can add one when direct service-level unit tests are needed across the board). For this change, the new `profileHasConversation` helper is exercised by:
-
-- `tests/integration/commands/continue.test.ts` (new tests in group 10 of `tasks.md`): 2 tests covering "resolves the profile that owns the conversation" and "errors when no profile owns the conversation".
-- `tests/integration/commands/delete.test.ts` (new tests in group 10): 2 tests covering the analogous delete paths.
-- `tests/services/profile-auth-manager.test.ts` (new tests in group 3): 3-4 tests that mock `GeminiClientService.profileHasConversation` to return `true`/`false` and assert the `findProfileForConversation` behavior.
-
-The mock-based unit tests for `findProfileForConversation` are the primary gate for the helper's behavior, and the integration tests for `continue` and `delete` are the gate for the end-to-end flow.
-
-**Why no separate test file for `profileHasConversation`:** the helper is one method on `GeminiClientService`; unit-testing it would require mocking the entire HTTP layer (the existing service uses `fetch` directly, not a `HttpClient` interface). The mock surface is larger than the code being tested, which is a smell. The integration coverage is the right gate for this change.
-
-**Alternative considered:** Mock `fetch` in a `tests/services/gemini-client-wrapper.test.ts` test. Rejected: too much mock surface for a 1-line helper; the integration tests are sufficient and more representative of real usage.
-
-## Risks / Trade-offs
-
-- **Risk:** The cookie-based conversation→profile cache is built fresh on every `findProfileForConversation` call, which is N `listChats` calls. → **Mitigation:** the cache is built once per call, so the cost is bounded; subsequent calls within the same CLI invocation can short-circuit on a hit. For the typical `gemiterm continue <id> <msg>` invocation (one call, two profiles), the latency is 2 GETs + 1 POST. The optimization is to keep the cache in the `Mediator` instance for the lifetime of the CLI process (a follow-up; not in this change because it changes the mediator contract).
-
-- **Risk:** The 8 existing `profile-auth-manager` tests changing behavior could be flagged as a "test regression" by code reviewers who skim the diff. → **Mitigation:** the test file's leading comment (added in group 3, sub-task 3.1 of `tasks.md`) explicitly states: "The 8 tests in `describe('findProfileForConversation')` previously asserted the BUGGY 'first active profile' behavior; they have been updated to assert the CORRECT per-profile-lookup behavior. See `openspec/changes/command-spec-conformance/proposal.md` for context." The PR body will also call this out.
-
-- **Risk:** Adding `profile?: string` to `ChatInfo` is a type change that could ripple to consumers that do `exactOptionalPropertyTypes` checks. → **Mitigation:** the field is optional and unset when `allProfiles` is false; consumers that ignore unknown fields (the standard JSON behavior) keep working. The 432/432 baseline test count includes consumers that iterate `chats` and assert specific fields — those tests are the regression gate for the type change.
-
-- **Risk:** Multi-profile users on WSL (where Chromium is WSL-local, per `src/services/install-browser-service.ts:124-141`) might see inconsistent results if one profile's cookies are for a host-Windows Chromium and another is for a WSL-Linux Chromium. → **Mitigation:** out of scope. The existing single-profile path already handles WSL cookie storage (the per-profile lookup is the same code path, just iterating N profiles instead of 1).
-
-- **Risk:** The `SendMessageCommandPayload.profileName` and `DeleteConversationCommandPayload.profileName` fields are optional, but a future change could add a third command that needs the field and forget to thread it. → **Mitigation:** the spec (`specs/multi-profile-conversations/spec.md`) explicitly states the routing contract for the three commands in this change. The `IGeminiClientService` interface does not grow a profile parameter (D3), so future commands follow the same pattern by adding `profileName` to their payload and using `forProfile` on the injected client.
-
-- **Risk:** The `formatChatList` signature change (adding an optional second arg) could be a TypeScript error in any consumer that calls `formatChatList(chats)` with a different second-arg shape. → **Mitigation:** the new parameter is a single object `{ includeProfileColumn?: boolean }`; TypeScript allows passing no argument or passing an object literal; existing calls (`formatChatList(chats)`) compile without change. The `bun test` baseline run is the regression gate.
-
-- **Trade-off:** The per-profile cache is per-call, not per-session. → **Accepted:** a per-session cache requires the `Mediator` to know about the cache, which couples concerns. The per-call cost is bounded (N `listChats` calls per `findProfileForConversation` call, where N is the number of active profiles — usually 1 or 2). The follow-up to make the cache per-session is a small change to the mediator's constructor; it can be done in a separate change without breaking the API.
-
-- **Trade-off:** The `forProfile` method on `GeminiClientService` creates a new instance per call. Each instance is a thin wrapper around the profile's cookies; the underlying `fetch` is created per request, not per instance. → **Accepted:** the alternative (caching a single `fetch` and swapping cookies per request) is more complex for no measurable gain; the per-call cost is one object allocation and one method call.
-
-## Migration Plan
-
-The change is **purely additive at the public surface** and **behavior-changing at the fix boundary**. Deploy steps:
-
-1. Land the change behind a feature branch.
-2. Run `bun test` and confirm the 432/432 baseline still passes; the new tests raise the count to 432+12 = 444+ (8 updated profile-auth-manager tests + 3-4 new = 11-12 in that file; 2+2 new continue/delete integration tests; 2 new list integration tests).
-3. Land on `main` after CI passes. No data migration is required: the profile storage layout, cookie storage layout, and config dir layout are unchanged. The `ChatInfo` JSON output for single-profile users is byte-identical (the `profile` field is absent).
-4. Update the user-facing `gemiterm --help` and the README to mention the new Profile column in `list --all-profiles` output (a one-line addition to the existing `--all-profiles` flag description in `list-command.ts:215`).
-
-**Rollback strategy:**
-- Revert the commit. The `profile?: string` field on `ChatInfo` is the only additive type change; reverting removes it, which is a non-breaking deletion for consumers that ignore unknown fields. The `findProfileForConversation` fix is the load-bearing piece; reverting restores the buggy behavior, but the 432 baseline is preserved (the existing tests that encoded the bug still pass).
-- No data is at risk. The change does not modify any on-disk state.
-
-**Deploy verification:**
-- A multi-profile user (`gemiterm auth --profile work && gemiterm auth --profile personal`, then `gemiterm list --all-profiles`) sees a Profile column. The JSON output includes `profile: "work"` / `profile: "personal"` on each chat.
-- A `gemiterm continue <id> <msg>` against a conversation owned by `work` actually sends to `work` (verified by reading the response and confirming it references the work account's data).
-- A `gemiterm continue <unknown-id> <msg>` exits non-zero with the remediation message.
-- A `gemiterm delete <id> --force` against a conversation owned by `work` deletes from `work`, not from `personal`.
-- A single-profile user (the 99% case) sees no change in any output shape.
-
-## Open Questions
-
-- **Q1:** Should the per-profile conversation cache be lifted into the `Mediator` (or a shared `ConversationOwnershipCache` service) so that a `gemiterm list --all-profiles` call followed by a `gemiterm continue <id>` reuses the cache? **Decision:** not in this change. The follow-up is a small change to `Mediator`'s constructor and the `ListChatsQueryHandler`; the cache can be invalidated by writing to it (delete a conversation → remove from the map). Out of scope for a spec-conformance change; tracked in a follow-up.
-
-- **Q2:** Should `findProfileForConversation` short-circuit on the active profile if `conversationId` is `undefined` (a degenerate case where the caller forgot to pass the argument)? **Decision:** no. The method signature requires a `string`; passing `undefined` is a TypeScript error. The current 8 tests already cover the cases the change needs.
-
-- **Q3:** Should the `forProfile` factory on `GeminiClientService` be exposed on the `IGeminiClientService` interface, or kept as a concrete-class-only method (the handler downcasts to `GeminiClientService`)? **Decision:** expose on the interface. The interface is a contract; the concrete class is the implementation. Adding `forProfile(name: string): IGeminiClientService` to the interface keeps the handler type-safe and lets test mocks implement the method.
-
-- **Q4:** Should the error message include the list of active profiles as a hint? E.g. "Could not find a profile that owns conversation '<id>'. Active profiles: ['work', 'personal']. Run 'gemiterm list --all-profiles'…" **Decision:** no, in this change. Listing the active profiles leaks information about the user's setup in a multi-user log scenario. The remediation message stays generic; the user can run `gemiterm list --all-profiles` to see the active profiles themselves.
-
-- **Q5:** Should the Profile column in `formatChatList` show the default profile with a `*` marker (matching the profile table convention in `formatProfileTable` at `src/infrastructure/formatters.ts:92`)? **Decision:** not in this change. The Profile column in the chat list is for disambiguation, not for marking the default; mixing the two would confuse the column's purpose. A follow-up could add a separate "DEFAULT" column or a `*` suffix if the maintainer wants the marker.
-
-- **Q6:** Should the integration tests for `continue` and `delete` mock the `ProfileAuthManager` and `GeminiClientService` separately, or use a single integration-level mock at the mediator boundary? **Decision:** the existing integration tests in `tests/integration/commands/continue.test.ts` and `delete.test.ts` (when they exist) mock at the mediator boundary (`spyOn(context.mediator, "send")`). The new profile-lookup tests follow the same pattern: mock the mediator to simulate a "profile found" or "profile not found" response, and assert the command's behavior. This keeps the test surface consistent with the existing 432-test baseline.
-
-- **Q7:** Does the per-profile routing break the `--all-profiles` flag in `list`? Today `list --all-profiles` already routes through the mediator with `allProfiles: true` in the payload; the new behavior propagates the active profile name into each `ChatInfo.profile` field. The `formatChatList` call gets the flag and renders the column. **Decision:** no breakage; the change is purely additive at the rendering layer.
-
-- **Q8:** Should the `profileHasConversation` helper be `async` (the current `listChats` is `async`)? **Decision:** yes. The helper is a thin wrapper around `listChats`, which awaits `fetch`. Marking the helper `async` keeps the call-site clean (`await geminiClient.profileHasConversation(name, id)`). The alternative (a sync helper that returns a `Promise<boolean>` from a non-`async` function) is just a wrapper around `Promise.resolve(...)` and adds no value.

package/openspec/changes/archive/2026-06-08-command-spec-conformance/proposal.md

@@ -1,52 +0,0 @@
-## Why
-
-Three small but real spec-conformance gaps remain in the CLI commands after the Maestro migration:
-
-1. **`continue-command.ts` and `delete-command.ts` do not call `ProfileAuthManager.findProfileForConversation`.** Per Maestro Phase 4 (`Phase-04-Commands.md:31, 47`), both commands should look up the profile that owns the conversation before sending the mediator command, so that a user with multiple profiles (e.g. work + personal) sends the message to / deletes from the right profile. Currently both commands go to the default profile regardless of where the conversation lives.
-2. **`ProfileAuthManager.findProfileForConversation` ignores its `conversationId` argument** (`src/services/profile-auth-manager.ts:46-60`). The method body iterates over all profiles and returns the first active one, never inspecting the cookies or storage of each profile for ownership of the requested conversation. In a single-profile setup this is a no-op; in a multi-profile setup it returns a wrong profile. The method is wired up to the registry but is functionally broken, which means even if commands 1 were implemented they would still be wrong without this fix.
-3. **`list-command.ts` does not render a `Profile` column when `--all-profiles` is set.** Per Maestro Phase 4 (`Phase-04-Commands.md:11`), the table should include a `Profile` column in that mode. The mediator payload already carries `allProfiles: boolean` (`list-command.ts:62`) and the integration tests assert the JSON contains profile info, but the text output uses `formatChatList(chats)` (`formatters.ts:115-145`) which renders only `ID / TITLE / DATE / PIN`. Users with multiple profiles cannot tell which profile a chat belongs to in the text output.
-
-## What Changes
-
-- **Fix `ProfileAuthManager.findProfileForConversation(conversationId)` in `src/services/profile-auth-manager.ts:46-60`** so that the `conversationId` argument is actually used. The implementation should iterate over all profiles; for each, call `geminiClient.listChats({ profile: name })` (or a new lightweight `profileHasConversation(name, conversationId)` helper on the Gemini client) to check whether the conversation appears in that profile's chat list; return the first matching profile name, or `null` if no profile owns it. **The 8 existing unit tests in `tests/services/profile-auth-manager.test.ts:88-223` are the regression gate** — they must be updated to assert the new per-profile-lookup behavior, not the broken first-active behavior. **Do NOT change the public method signature** — it must remain `findProfileForConversation(conversationId: string): string | null`.
-- **Add `profileHasConversation(profileName, conversationId): Promise<boolean>` (or a non-async equivalent that reuses the same chat-listing path)** to `GeminiClientService` in `src/services/gemini-client-wrapper.ts` so `ProfileAuthManager` has a fast per-profile lookup. This is a small wrapper around the existing `listChats()` call scoped to a single profile. The existing `tests/integration/commands/list.test.ts` and the `IGeminiClientService` interface in `src/core/command-handlers.ts` already define the per-profile listing path.
-- **Update `src/cli/commands/continue-command.ts:50-69` and `:75-130`** to call `profileAuthManager.findProfileForConversation(conversationId)` before sending the `SendMessageCommand`. If the method returns `null`, throw `AuthenticationError` with a clear message ("Could not find a profile that owns conversation '<id>'. Run 'gemiterm list --all-profiles' to see which profile it belongs to, then 'gemiterm continue <id> <msg> --profile <name>' to specify the profile explicitly."). If it returns a profile name, send the command to that profile's mediator wiring (this may require extending the `IGeminiClientService` injection so commands can target a specific profile, or routing through a profile-scoped client constructor). Document the chosen approach in `design.md`.
-- **Update `src/cli/commands/delete-command.ts:51-77`** analogously — call `findProfileForConversation` before sending `DeleteConversationCommand`. Same error-handling pattern.
-- **Add `profile?: string` to `ChatInfo` in `src/core/types.ts:9-14`** (optional, backward-compatible).
-- **Update `formatChatList` in `src/infrastructure/formatters.ts:115-145`** to accept an optional `includeProfileColumn: boolean` parameter. When true, render a 5th `PROFILE` column (width 14 chars); when false, keep the current 4-column layout.
-- **Update `src/cli/commands/list-command.ts:129-136`** to pass `includeProfileColumn: options.allProfiles` to `formatChatList`.
-- **Add a new optional `profile` field to the `ListChatsQueryResult.chats` payload** by propagating the active profile name in `GeminiClientService.listChats(options)` when `options.allProfiles` is true.
-- **Tests:**
-  - Update `tests/services/profile-auth-manager.test.ts` so the 8 existing cases test the new per-profile-lookup behavior (mocking `profileHasConversation`).
-  - Add 3-4 new unit tests in `tests/services/profile-auth-manager.test.ts` covering: "conversation found in second profile", "conversation not in any profile", "throws when no active profiles".
-  - Add 2 new integration tests in `tests/integration/commands/continue.test.ts` and `tests/integration/commands/delete.test.ts` covering the profile-lookup code path.
-  - Add 2 new integration tests in `tests/integration/commands/list.test.ts` covering the new Profile column when `--all-profiles` is set.
-
-**No breaking changes** to the CLI user surface. The `profile` field in `ChatInfo` is optional; existing JSON output is unchanged. The Profile column only appears when the user explicitly passes `--all-profiles`.
-
-## Capabilities
-
-### New Capabilities
-- `multi-profile-conversations`: The ability for the `continue` and `delete` commands to locate the profile that owns a given conversation, and for `list --all-profiles` to display which profile each conversation belongs to. Creates `openspec/changes/command-spec-conformance/specs/multi-profile-conversations/spec.md`.
-
-### Modified Capabilities
-- (none) — there is no existing main `commands` spec yet, so this is a new capability rather than a modification.
-
-## Impact
-
-- **Code (8 files):**
-  - `src/services/profile-auth-manager.ts` — fix `findProfileForConversation`
-  - `src/services/gemini-client-wrapper.ts` — add `profileHasConversation` helper
-  - `src/cli/commands/continue-command.ts` — call `findProfileForConversation`
-  - `src/cli/commands/delete-command.ts` — call `findProfileForConversation`
-  - `src/cli/commands/list-command.ts` — pass `includeProfileColumn` flag
-  - `src/core/types.ts` — add optional `profile` to `ChatInfo`
-  - `src/infrastructure/formatters.ts` — add `includeProfileColumn` to `formatChatList`
-  - `src/core/command-handlers.ts` (or the `IGeminiClientService` interface) — ensure per-profile routing is exposed
-- **Tests (3 files):**
-  - `tests/services/profile-auth-manager.test.ts` — update 8 existing + add 3-4 new
-  - `tests/integration/commands/continue.test.ts` — add 2
-  - `tests/integration/commands/delete.test.ts` — add 2
-  - `tests/integration/commands/list.test.ts` — add 2
-- **Baseline gate:** 432/432 tests must continue to pass; the new tests bring the count higher.
-- **SENSITIVE AREA:** the auth/playwright-cli/cookie-monitor code paths are NOT touched. This change is purely about the `continue`, `delete`, and `list` commands and the `ProfileAuthManager` + `GeminiClientService` services. No cookie capture or browser lifecycle code is modified.

package/openspec/changes/archive/2026-06-08-command-spec-conformance/specs/multi-profile-conversations/spec.md

@@ -1,133 +0,0 @@
-## ADDED Requirements
-
-### Requirement: findProfileForConversation returns the profile that owns a conversation
-The system MUST return the name of the profile whose server-side chat list contains the given conversation ID. The `conversationId` argument MUST be passed to the per-profile lookup helper; it MUST NOT be ignored. When no profile owns the conversation, the system MUST return `null`. When multiple profiles report ownership of the same conversation ID (an inconsistent state the user is responsible for), the system MUST return the first profile in `profileManager.list()` order that reports ownership.
-
-#### Scenario: Conversation exists in one profile
-- **WHEN** `findProfileForConversation("abc-123")` is called and conversation `abc-123` exists in profile `work` but not in profile `personal`
-- **THEN** the method returns the string `"work"`
-
-#### Scenario: Conversation exists in no profile
-- **WHEN** `findProfileForConversation("abc-123")` is called and conversation `abc-123` does not exist in any active profile's chat list
-- **THEN** the method returns `null`
-
-#### Scenario: Conversation exists in multiple profiles (inconsistent state)
-- **WHEN** `findProfileForConversation("abc-123")` is called and conversation `abc-123` exists in both profile `work` and profile `personal`, and `profileManager.list()` returns `["work", "personal"]` in that order
-- **THEN** the method returns the string `"work"` (the first profile in list order that reports ownership)
-
-#### Scenario: The conversationId argument is actually used
-- **WHEN** a unit test calls `findProfileForConversation("abc-123")` and the `profileHasConversation` helper is mocked
-- **THEN** the mocked helper MUST have been invoked with the exact string `"abc-123"` (verified via `expect(mock).toHaveBeenCalledWith("work", "abc-123")` or an equivalent assertion); the method MUST NOT return early with a first-active-wins fallback
-
-### Requirement: continue-command targets the profile that owns the conversation
-The system MUST look up the profile that owns the conversation via `ProfileAuthManager.findProfileForConversation` before sending the `SendMessageCommand`. The system MUST route the message to that profile's `GeminiClientService` instance. When no profile owns the conversation, the system MUST throw `AuthenticationError` with a remediation message and exit non-zero. In a single-profile setup (only the default profile is active), the behavior MUST be unchanged: the default profile is used.
-
-#### Scenario: Multi-profile continue routes to the owning profile
-- **WHEN** a user with active profiles `work` and `personal` runs `gemiterm continue abc-123 "hello"` and conversation `abc-123` is owned by `work`
-- **THEN** the `SendMessageCommand` is sent via the `work` profile's `GeminiClientService` (verified by the response content being scoped to the `work` account); the `personal` profile's `GeminiClientService` is NOT invoked for this send
-
-#### Scenario: Continue on an unknown conversation ID exits non-zero
-- **WHEN** a user runs `gemiterm continue unknown-id "hello"` and no profile owns conversation `unknown-id`
-- **THEN** the command throws `AuthenticationError` whose message contains `"Could not find a profile that owns conversation 'unknown-id'"` and the suggested remediation `"gemiterm list --all-profiles"`, and the process exits with a non-zero exit code
-
-#### Scenario: Single-profile continue is unchanged
-- **WHEN** a user with only the default profile active runs `gemiterm continue abc-123 "hello"`
-- **THEN** the behavior is identical to before the change: the default profile is used, no `findProfileForConversation` call is required, and the response is returned normally
-
-### Requirement: delete-command targets the profile that owns the conversation
-The system MUST look up the profile that owns the conversation via `ProfileAuthManager.findProfileForConversation` before sending the `DeleteConversationCommand`. The system MUST route the delete to that profile's `GeminiClientService` instance. When no profile owns the conversation, the system MUST throw `AuthenticationError` with the same remediation message used by `continue` and exit non-zero. In a single-profile setup, the behavior MUST be unchanged.
-
-#### Scenario: Multi-profile delete routes to the owning profile
-- **WHEN** a user with active profiles `work` and `personal` runs `gemiterm delete abc-123 --force` and conversation `abc-123` is owned by `work`
-- **THEN** the `DeleteConversationCommand` is sent via the `work` profile's `GeminiClientService`; the `personal` profile's `GeminiClientService` is NOT invoked for this delete
-
-#### Scenario: Delete on an unknown conversation ID exits non-zero
-- **WHEN** a user runs `gemiterm delete unknown-id --force` and no profile owns conversation `unknown-id`
-- **THEN** the command throws `AuthenticationError` whose message contains `"Could not find a profile that owns conversation 'unknown-id'"` and the process exits with a non-zero exit code
-
-#### Scenario: Single-profile delete is unchanged
-- **WHEN** a user with only the default profile active runs `gemiterm delete abc-123 --force`
-- **THEN** the behavior is identical to before the change: the default profile is used, no `findProfileForConversation` call is required, and the conversation is deleted
-
-### Requirement: list --all-profiles renders a Profile column in the text table
-The system MUST render a `PROFILE` column in the text table output of `gemiterm list --all-profiles` and MUST NOT render it in any other mode. Each row MUST show the name of the profile that owns the conversation in that row. The column width MUST be 14 characters, matching the visual style of the other columns.
-
-#### Scenario: list --all-profiles shows 5 columns
-- **WHEN** a user with active profiles `work` and `personal` runs `gemiterm list --all-profiles`
-- **THEN** the text table header contains the columns `ID, TITLE, DATE, PIN, PROFILE` in that order, and each row's last cell contains the owning profile name (e.g. `work` or `personal`)
-
-#### Scenario: list without --all-profiles shows 4 columns
-- **WHEN** a user runs `gemiterm list` (no `--all-profiles` flag)
-- **THEN** the text table header contains the columns `ID, TITLE, DATE, PIN` only; the `PROFILE` column is absent and the chat output matches the pre-change format byte-for-byte
-
-#### Scenario: list --all-profiles --format json includes profile field
-- **WHEN** a user runs `gemiterm list --all-profiles --format json`
-- **THEN** the JSON output's `chats` array contains a `profile` field on every chat; each `profile` value is the name of the profile that owns that chat
-
-#### Scenario: list without --all-profiles --format json omits profile field
-- **WHEN** a user runs `gemiterm list --format json` (no `--all-profiles` flag)
-- **THEN** the JSON output's `chats` array does NOT contain a `profile` field on any chat; the JSON shape is byte-compatible with the pre-change output
-
-### Requirement: ChatInfo carries an optional profile field
-The `ChatInfo` type in `src/core/types.ts` MUST carry an optional `profile?: string` field. The field MUST be unset (or `undefined`) for chats returned by `list` without `--all-profiles` and MUST be the owning profile name for chats returned by `list --all-profiles`. Existing serialized JSON output for the non-`--all-profiles` path MUST be byte-compatible with the pre-change shape (the field is omitted, not set to `null` or `""`).
-
-#### Scenario: ChatInfo type allows optional profile field
-- **WHEN** a `ChatInfo` object is constructed with `{ id: "abc-123", title: "T", isPinned: false, timestamp: 0, profile: "work" }`
-- **THEN** the object is type-valid and the `profile` field is the string `"work"`
-
-#### Scenario: ChatInfo type allows absence of profile field
-- **WHEN** a `ChatInfo` object is constructed with `{ id: "abc-123", title: "T", isPinned: false, timestamp: 0 }` (no `profile` key)
-- **THEN** the object is type-valid and the `profile` field is `undefined`
-
-#### Scenario: ChatInfo serialized to JSON omits profile when unset
-- **WHEN** a `ChatInfo` object with no `profile` field is serialized via `JSON.stringify`
-- **THEN** the resulting JSON does NOT contain a `profile` key (matches the pre-change byte layout)
-
-### Requirement: formatChatList accepts an includeProfileColumn flag
-The `formatChatList` function in `src/infrastructure/formatters.ts` MUST accept an optional second argument `options?: { includeProfileColumn?: boolean }`. When `options.includeProfileColumn` is `true`, the rendered table MUST have 5 columns including `PROFILE`. When the flag is `false` or omitted, the rendered table MUST have the original 4 columns (`ID, TITLE, DATE, PIN`) and the output MUST be byte-compatible with the pre-change format.
-
-#### Scenario: formatChatList with includeProfileColumn: true renders 5 columns
-- **WHEN** `formatChatList(chats, { includeProfileColumn: true })` is called with chats that each have a `profile` field
-- **THEN** the rendered output contains the header `ID    TITLE    DATE    PIN    PROFILE` (with the column-padding and divider convention used elsewhere) and each row's last cell shows the chat's `profile` value
-
-#### Scenario: formatChatList without flag renders 4 columns (backward compat)
-- **WHEN** `formatChatList(chats)` is called with no second argument
-- **THEN** the rendered output contains the header `ID    TITLE    DATE    PIN` and the output is byte-compatible with the pre-change format for the same input (no `PROFILE` column)
-
-#### Scenario: Existing formatChatList callers continue to pass without modification
-- **WHEN** an existing test calls `formatChatList(chats)` (the pre-change call shape) after the change lands
-- **THEN** the test continues to pass without modification (regression gate for the formatter; the optional second argument is non-breaking)
-
-### Requirement: GeminiClientService exposes a profileHasConversation helper
-The `GeminiClientService` class in `src/services/gemini-client-wrapper.ts` MUST expose a `profileHasConversation(profileName: string, conversationId: string): Promise<boolean>` method. The method MUST return `true` if the given conversation ID appears in the named profile's chat list, and `false` otherwise. The `IGeminiClientService` interface in `src/core/command-handlers.ts` MUST declare the method so handlers and tests can use it without downcasting. The method MUST NOT mutate the calling instance's cookies or session state.
-
-#### Scenario: profileHasConversation returns true for owning profile
-- **WHEN** `await geminiClient.profileHasConversation("work", "abc-123")` is called and conversation `abc-123` exists in `work`'s chat list
-- **THEN** the method returns `true`
-
-#### Scenario: profileHasConversation returns false for non-owning profile
-- **WHEN** `await geminiClient.profileHasConversation("personal", "abc-123")` is called and conversation `abc-123` does NOT exist in `personal`'s chat list
-- **THEN** the method returns `false`
-
-#### Scenario: profileHasConversation is declared on the IGeminiClientService interface
-- **WHEN** a handler is typed against `IGeminiClientService` and calls `geminiClient.profileHasConversation(name, id)`
-- **THEN** the call type-checks (the method is part of the interface, not a concrete-class-only method)
-
-#### Scenario: profileHasConversation does not mutate the calling instance
-- **WHEN** `geminiClient.profileHasConversation("work", "abc-123")` is called on an instance configured for the default profile
-- **THEN** the calling instance's cookie config and `authenticated` flag are unchanged after the call returns (verified by reading the instance fields in a test)
-
-### Requirement: Regression test update for profile-auth-manager documents the bug fix
-The 8 existing unit tests in the `describe("findProfileForConversation")` block of `tests/services/profile-auth-manager.test.ts` MUST be updated to assert the correct per-profile-lookup behavior (not the previous first-active-wins behavior). The test count for that describe block MUST increase (8 → 11+) after the change. A leading comment in the test file MUST explain that the 8 changed tests previously documented the bug and the change is the fix.
-
-#### Scenario: The 8 existing tests are updated to mock profileHasConversation
-- **WHEN** `tests/services/profile-auth-manager.test.ts` is read after the change
-- **THEN** the 3 existing tests in the `findProfileForConversation` block (the original 8 minus the 5 that don't exercise the per-profile lookup) are rewritten to mock `GeminiClientService.profileHasConversation` and assert the new behavior; the new behavior is the first profile in list order whose `profileHasConversation` returns `true`
-
-#### Scenario: The test count for profile-auth-manager increases
-- **WHEN** `bun test tests/services/profile-auth-manager.test.ts` is run after the change
-- **THEN** the test count is at least 11 (8 original tests minus the deleted first-active-wins test plus 3-4 new tests covering: "conversation found in second profile", "conversation not in any profile", "throws when no active profiles")
-
-#### Scenario: The test file's leading comment documents the test changes
-- **WHEN** `tests/services/profile-auth-manager.test.ts` is read after the change
-- **THEN** the file contains a leading comment block stating: "The 8 tests in `describe('findProfileForConversation')` previously asserted the BUGGY 'first active profile' behavior; they have been updated to assert the CORRECT per-profile-lookup behavior. See `openspec/changes/command-spec-conformance/proposal.md` for context."

package/openspec/changes/archive/2026-06-08-command-spec-conformance/tasks.md

@@ -1,95 +0,0 @@
-## 1. Fix `findProfileForConversation` core logic in `ProfileAuthManager`
-
-- [x] 1.1 Read `src/services/profile-auth-manager.ts:46-60` to confirm the current implementation iterates `profileManager.list()` and returns the first profile with `getStatus(name).isActive === true`, never using the `conversationId` argument.
-- [x] 1.2 Read `src/services/profile-auth-manager.ts:10-39` to confirm the constructor signature and the `getActiveProfiles` pattern; the new method should follow the same shape (use `profileManager.list()`, then filter for the owning profile).
-- [x] 1.3 Refactor `findProfileForConversation(conversationId)` so it calls a `profileHasConversation` helper on the injected service for each active profile and returns the first profile whose helper returns `true`. If no profile returns `true`, the method MUST return `null`. The method signature MUST remain `findProfileForConversation(conversationId: string): string | null` (the public contract is unchanged).
-- [x] 1.4 Do NOT touch any of the SENSITIVE files (`src/services/playwright-cli-driver.ts`, `src/services/cookie-monitor.ts`, `src/services/auth-service.ts`); the change is scoped to `profile-auth-manager.ts` and its dependencies.
-- [x] 1.5 Do NOT change the public method signature; the only acceptable change is the method body.
-
-## 2. Add `profileHasConversation` helper to `GeminiClientService`
-
-- [x] 2.1 Read `src/services/gemini-client-wrapper.ts:91-141` to confirm the existing `listChats(options)` method; the new helper is a thin wrapper that scopes a `listChats` call to a single profile's cookies and returns a boolean.
-- [x] 2.2 Add `async profileHasConversation(profileName: string, conversationId: string): Promise<boolean>` to `GeminiClientService` in `src/services/gemini-client-wrapper.ts`. The method MUST construct a per-profile client (via the `forProfile` factory in task 2.3), call `listChats()` on it, and return `true` if the conversation ID is in the result.
-- [x] 2.3 Add a `forProfile(profileName: string): GeminiClientService` factory method on `GeminiClientService` that returns a NEW instance configured with the named profile's cookies (via `CookieStorageService.loadCookiesForProfile`). The method MUST NOT mutate the calling instance's `config` or `authenticated` fields.
-- [x] 2.4 Expose `profileHasConversation` on the `IGeminiClientService` interface in `src/core/command-handlers.ts:90-94` so handlers and tests can use it without downcasting. The interface method signature is `profileHasConversation(profileName: string, conversationId: string): Promise<boolean>`.
-- [x] 2.5 The helper MUST NOT make any changes to the on-disk cookie storage; it only reads via the injected `CookieStorageService`.
-
-## 3. Update `profile-auth-manager.test.ts` to encode the new behavior
-
-- [x] 3.1 Add a leading comment block at the top of `tests/services/profile-auth-manager.test.ts` (above the first `describe`) stating: "The 8 tests in `describe('findProfileForConversation')` previously asserted the BUGGY 'first active profile' behavior; they have been updated to assert the CORRECT per-profile-lookup behavior. See `openspec/changes/command-spec-conformance/proposal.md` for context." This is required so reviewers do not flag the test changes as a regression.
-- [x] 3.2 Rewrite the existing "returns first active profile" test (currently at `tests/services/profile-auth-manager.test.ts:188-200`) to: create two profiles, mock `GeminiClientService.profileHasConversation` to return `true` for `work` and `false` for `personal`, and assert the method returns `"work"`. The test name MUST be changed to "returns the profile that owns the conversation" (or similar) to reflect the new behavior.
-- [x] 3.3 Keep the "returns null when no active profiles" test (currently at `tests/services/profile-auth-manager.test.ts:202-212`) but update it to mock `profileHasConversation` to return `false` for the only active profile; the assertion (`toBeNull()`) is unchanged.
-- [x] 3.4 Keep the "returns null when no profiles exist" test (currently at `tests/services/profile-auth-manager.test.ts:214-222`) unchanged: the `profileManager.list()` returns an empty array, so the loop never runs and the method returns `null`.
-- [x] 3.5 Add a new test "returns null when conversation is not in any profile" that creates two profiles with valid cookies, mocks `profileHasConversation` to return `false` for both, and asserts `findProfileForConversation` returns `null`.
-- [x] 3.6 Add a new test "returns first profile in list order when multiple profiles report ownership" that creates three profiles, mocks `profileHasConversation` to return `true` for profiles 1 and 3 (and `false` for profile 2), and asserts the method returns profile 1 (the first in `list()` order). This guards the iteration-order contract.
-- [x] 3.7 Add a new test "passes the conversationId argument to the lookup helper" that mocks `profileHasConversation` with a spy and asserts the spy was called with the exact `conversationId` string the test passed in. This is the regression gate that catches the "first-active-wins" bug recurring.
-- [x] 3.8 The test count for `profile-auth-manager.test.ts` MUST be 11 or higher after the change (the original 8, minus 0 since we keep all but rename one, plus 3 new tests = 11; the new tests can be expanded to 4 if helpful for coverage).
-
-## 4. Add `profile?: string` to `ChatInfo`
-
-- [x] 4.1 Read `src/core/types.ts:9-14` to confirm the current `ChatInfo` shape: `{ id, title, isPinned, timestamp }`.
-- [x] 4.2 Add an optional `profile?: string` field to the `ChatInfo` interface. The field MUST be optional (declared with `?`) to preserve backward compatibility for single-profile consumers and for JSON serialization that does not include the field.
-- [x] 4.3 Do NOT change any other field in the interface. The type is purely additive.
-- [x] 4.4 Verify the change compiles via `bun run build` (or the project's TypeScript check command); the optional field MUST NOT break any existing `ChatInfo` construction sites.
-
-## 5. Add `includeProfileColumn` flag to `formatChatList`
-
-- [x] 5.1 Read `src/infrastructure/formatters.ts:115-145` to confirm the current `formatChatList(chats)` signature and 4-column layout (ID, TITLE, DATE, PIN).
-- [x] 5.2 Update the signature to `formatChatList(chats: ChatInfo[], options?: { includeProfileColumn?: boolean }): string`. The second argument is an optional options object.
-- [x] 5.3 When `options?.includeProfileColumn === true`, render a 5th `PROFILE` column with width 14 characters. The column header MUST be `PROFILE` and the column value MUST be `chat.profile ?? ""` (defensive: in case the chat is missing the field for any reason). The 5-column layout MUST match the visual style of the existing columns (header + dashed underline + per-row data).
-- [x] 5.4 When `options?.includeProfileColumn` is `false` or `undefined`, the output MUST be byte-compatible with the pre-change format. The 4-column layout is unchanged.
-- [x] 5.5 Verify all existing callers of `formatChatList` continue to compile: the new optional second argument is non-breaking.
-
-## 6. Wire `list-command.ts` to pass `includeProfileColumn` to `formatChatList`
-
-- [x] 6.1 Read `src/cli/commands/list-command.ts:129-136` to confirm the current `outputText` method calls `formatChatList(chats)` without a second argument.
-- [x] 6.2 Update the call to `formatChatList(chats, { includeProfileColumn: options.allProfiles })`. The flag is plumbed from the `ListCommandOptions.allProfiles` field that already exists at `list-command.ts:21`.
-- [x] 6.3 Read `src/cli/commands/list-command.ts:58-63` to confirm the `ListChatsQueryPayload` already carries `allProfiles: options.allProfiles`; this is the upstream signal that the mediator will populate `ChatInfo.profile` on the result.
-- [x] 6.4 Update the help text in `list-command.ts:215` to mention that the Profile column appears in `--all-profiles` mode. The existing `--all-profiles` description is "Show conversations from all profiles"; expand it to "Show conversations from all profiles (with Profile column in text output)" or similar.
-
-## 7. Update `continue-command.ts` to call `findProfileForConversation` and route per-profile
-
-- [x] 7.1 Read `src/cli/commands/continue-command.ts:50-69` and `:75-130` to confirm the current `sendNonInteractive` and `startInteractive` methods both send the `SendMessageCommand` to the default profile only.
-- [x] 7.2 Add a call to `findProfileForConversation(conversationId)` in `sendNonInteractive` before the mediator send. The lookup MUST use the `ProfileAuthManager` (added to the `CliCommandContext` — see task 9.2).
-- [x] 7.3 If the lookup returns `null`, throw `AuthenticationError` with the message: `"Could not find a profile that owns conversation '<id>'. Run 'gemiterm list --all-profiles' to see which profile it belongs to, then 'gemiterm continue <id> <msg> --profile <name>' to specify the profile explicitly."` (the `--profile` override is a follow-up; mentioned in the message as guidance, not as a current flag).
-- [x] 7.4 If the lookup returns a profile name, build a per-profile `GeminiClientService` via `forProfile(name)` and route the `SendMessageCommand` through that instance. The default profile is still used as a fallback when only one profile is active.
-- [x] 7.5 Apply the same pattern to `startInteractive` at `continue-command.ts:75-130` so that the interactive loop sends to the correct profile.
-- [x] 7.6 The error must propagate to the existing `try/catch` at `continue-command.ts:112-116`; the user sees the error in red and the process exits non-zero.
-
-## 8. Update `delete-command.ts` to call `findProfileForConversation` and route per-profile
-
-- [x] 8.1 Read `src/cli/commands/delete-command.ts:51-77` to confirm the current flow sends the `DeleteConversationCommand` to the default profile only.
-- [x] 8.2 Add a call to `findProfileForConversation(conversationId)` after the `validateConversationId` check at `delete-command.ts:44-49` and before the mediator send at `delete-command.ts:64-69`.
-- [x] 8.3 If the lookup returns `null`, throw `AuthenticationError` with the same remediation message as `continue` (task 7.3), adapted for delete: `"… then 'gemiterm delete <id> --profile <name>' to specify the profile explicitly."`.
-- [x] 8.4 If the lookup returns a profile name, route the `DeleteConversationCommand` through that profile's `GeminiClientService` (via `forProfile`).
-- [x] 8.5 The error must propagate to the existing `try/catch` at `delete-command.ts:77-81`; the process exits non-zero with the error message.
-
-## 9. Add per-profile routing via `IGeminiClientService` extension
-
-- [x] 9.1 Add `profileName?: string` to `SendMessageCommandPayload` and `DeleteConversationCommandPayload` in `src/core/command-handlers.ts:44-55`. The field is optional: when absent, the handler uses its injected (default-profile) client; when present, the handler builds a per-profile client via `forProfile` and uses that.
-- [x] 9.2 Add the `ProfileAuthManager` to `CliCommandContext` in `src/cli/command-registry.ts:14-17`. The `CliCommandContext` interface gains a new `profileAuthManager: ProfileAuthManager` field. Update the wiring at `src/cli/index.ts` (or wherever the context is constructed) to inject the `ProfileAuthManager` instance.
-- [x] 9.3 Update `SendMessageCommandHandler.handle` at `src/core/command-handlers.ts:198-213` so it reads `payload.profileName`; if set, it builds the per-profile client via `geminiClient.forProfile(profileName)` and calls `sendMessage` on the per-profile client. The injected `geminiClient` is treated as the default-profile client.
-- [x] 9.4 Update `DeleteConversationCommandHandler.handle` at `src/core/command-handlers.ts:178-196` with the same pattern: read `payload.profileName`, build the per-profile client, route `deleteChat` through it.
-- [x] 9.5 The per-profile client is created per `handle` call; the injection of `GeminiClientService` at the handler level continues to use the default-profile instance. The factory pattern (D3 in `design.md`) means no per-profile state is held in the handler.
-
-## 10. Add integration tests for continue/delete profile lookup
-
-- [x] 10.1 Read `tests/integration/commands/continue.test.ts` if it exists; if it does not, create it following the pattern in `tests/integration/commands/list.test.ts` (mock the mediator, assert command behavior). The new test file MUST follow the existing test conventions (Bun's `describe`/`test`/`expect`).
-- [x] 10.2 Add a new test in the continue integration suite: "resolves the profile that owns the conversation" — mock the `ProfileAuthManager.findProfileForConversation` to return `"work"`, mock the mediator to capture the `SendMessageCommandPayload`, and assert the payload's `profileName` is `"work"`.
-- [x] 10.3 Add a new test in the continue integration suite: "throws AuthenticationError when no profile owns the conversation" — mock `findProfileForConversation` to return `null`, run the command, and assert the error message contains the remediation text and the process exits non-zero.
-- [x] 10.4 Add a new test in the delete integration suite: "resolves the profile that owns the conversation" — analog of 10.2 for delete.
-- [x] 10.5 Add a new test in the delete integration suite: "throws AuthenticationError when no profile owns the conversation" — analog of 10.3 for delete.
-
-## 11. Add integration test for list Profile column
-
-- [x] 11.1 Add a new test in `tests/integration/commands/list.test.ts`: "renders Profile column when --all-profiles is set" — mock the mediator to return chats with a `profile` field, run `command.execute(["--all-profiles"], context)`, and assert the output contains the `PROFILE` header and the profile names from the mocks.
-- [x] 11.2 Add a new test in `tests/integration/commands/list.test.ts`: "omits Profile column when --all-profiles is not set" — mock the mediator to return chats (with or without a `profile` field), run `command.execute([], context)`, and assert the output does NOT contain the `PROFILE` header.
-- [x] 11.3 Add a new test in `tests/integration/commands/list.test.ts`: "JSON output includes profile field only when --all-profiles is set" — run the command with and without `--all-profiles --format json`, parse the JSON output, and assert the `profile` key is present in the `--all-profiles` case and absent in the other.
-
-## 12. Final verification
-
-- [x] 12.1 Run `bun test` from the repo root and confirm all tests pass. The baseline is 432/432; the new tests (4-5 in profile-auth-manager + 2 in continue integration + 2 in delete integration + 3 in list integration) bring the count to 442+ (exact count depends on how the new tests are split).
-- [x] 12.2 Run `bun test tests/services/profile-auth-manager.test.ts` and confirm the test count is at least 11 (8 original + 3-4 new) and the leading comment is in place.
-- [x] 12.3 Run `bun run build` (or the project's TypeScript check command) to confirm the `ChatInfo.profile` field and the `formatChatList` options object do not break any consumer.
-- [x] 12.4 Manually run `gemiterm list` (single-profile mode) and confirm the output is byte-compatible with the pre-change format. Manually run `gemiterm list --all-profiles` (multi-profile mode) and confirm the Profile column appears. Manually run `gemiterm continue <id> <msg>` against a known conversation and confirm it routes to the right profile.
-- [x] 12.5 Confirm no file under `src/services/playwright-cli-driver.ts`, `src/services/cookie-monitor.ts`, or `src/services/auth-service.ts` was modified. The git diff for those files MUST be empty.

package/openspec/changes/archive/2026-06-09-refactor-interactive-prompt-loop/.openspec.yaml

@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-06-09

package/openspec/changes/archive/2026-06-09-refactor-interactive-prompt-loop/design.md

@@ -1,28 +0,0 @@
-## Context
-
-The `new` and `continue` commands both implement interactive chat loops using `node:readline`'s `createInterface`. Both have essentially identical `startInteractive` implementations with only minor differences in:
-- How messages are processed (new chat vs. send to existing)
-- Profile resolution logic
-
-## Goals / Non-Goals
-
-**Goals:**
-- Extract shared interactive prompt logic into a reusable utility
-- Fix the bug where `new` command's interactive mode exits after one round
-- Reduce code duplication
-
-**Non-Goals:**
-- No new external dependencies
-- No changes to command-line argument parsing
-- No changes to the CLI command interface
-
-## Decisions
-
-1. **Create `src/cli/utils/interactive-prompt.ts`** as a shared utility module
-2. **Export a `runInteractiveLoop` function** that accepts a callback for message handling
-3. **Keep command-specific logic in the commands** - the shared utility handles only the prompt loop mechanics
-
-## Risks / Trade-offs
-
-- Minimal risk - this is a pure refactoring with no behavioral changes beyond fixing the bug
-- Trade-off: adds a new file, but reduces overall complexity

package/openspec/changes/archive/2026-06-09-refactor-interactive-prompt-loop/proposal.md

@@ -1,22 +0,0 @@
-## Why
-
-The `new` and `continue` commands both implement interactive chat loops using `createInterface` from `node:readline`, but the `startInteractive` logic is duplicated in each command with minor variations. Additionally, the `new` command's interactive mode has a bug where it exits after processing just one message instead of looping until the user quits.
-
-## What Changes
-
-- Extract shared `startInteractive` logic into a reusable utility function/class
-- Fix the bug where `new` command's interactive mode exits after one round
-- Reduce code duplication between `new-command.ts` and `continue-command.ts`
-
-## Capabilities
-
-### New Capabilities
-- `interactive-prompt-loop`: Shared interactive prompt loop utility for chat commands
-
-### Modified Capabilities
-<!-- No spec-level behavior changes - this is a pure refactoring with a bug fix -->
-
-## Impact
-
-- Files affected: `src/cli/commands/new-command.ts`, `src/cli/commands/continue-command.ts`
-- New file: `src/cli/utils/interactive-prompt.ts` (or similar shared location)