gemiterm 2.0.0 → 2.1.1

package/openspec/specs/logger/spec.md

@@ -1,71 +0,0 @@
-## Purpose
-
-The application's logging facility. It provides a single `Logger` class that emits timestamped, leveled, module-tagged log lines to `process.stderr`. Verbosity is controlled globally via a static flag, and each `Logger` instance carries a per-instance module tag that is rendered into every line it produces.
-
-## Requirements
-
-### Requirement: Logger Class With Leveled Methods
-The system MUST export a `Logger` class with four instance methods: `debug(message, ...args)`, `info(message, ...args)`, `warn(message, ...args)`, and `error(message, ...args)`. Each method MUST format the supplied message (and any trailing args) into a single line on `process.stderr` with a level tag of `DEBUG`, `INFO`, `WARN`, or `ERROR` respectively.
-
-#### Scenario: info writes an INFO line
-- **WHEN** a `Logger` instance has `info("hello world")` called
-- **THEN** `process.stderr.write` is invoked once with a string containing `[INFO]` and the message
-
-#### Scenario: warn writes a WARN line
-- **WHEN** `warn("something happened")` is called
-- **THEN** the emitted line contains `[WARN]`
-
-#### Scenario: error writes an ERROR line
-- **WHEN** `error("failed")` is called
-- **THEN** the emitted line contains `[ERROR]`
-
-### Requirement: Verbose Toggle For Debug Output
-The `Logger` class MUST expose a static `setVerbose(enabled: boolean)` method that sets a process-global verbose flag, and a static `isVerbose(): boolean` method that returns the current flag value. When the flag is `false` (the default), `debug()` MUST NOT write anything. When the flag is `true`, `debug()` MUST write a `DEBUG` line identically to the other levels.
-
-#### Scenario: debug is silent by default
-- **WHEN** `setVerbose(false)` is the current state
-- **THEN** calling `debug("msg")` does not invoke `process.stderr.write`
-
-#### Scenario: setVerbose(true) enables debug
-- **WHEN** `setVerbose(true)` is called and then `debug("verbose message")` is invoked
-- **THEN** `process.stderr.write` is invoked once with a string containing `[DEBUG]`
-
-#### Scenario: isVerbose reflects current state
-- **WHEN** the verbose flag is toggled
-- **THEN** `isVerbose()` returns the new value
-
-### Requirement: Standard Log Line Format
-Every emitted log line MUST have the exact structure `[<ISO_TIMESTAMP>] [<LEVEL>] [<module>] <message>`, where `<ISO_TIMESTAMP>` is the result of `new Date().toISOString()`, `<LEVEL>` is one of `DEBUG`, `INFO`, `WARN`, `ERROR`, and `<module>` is the per-instance tag supplied at construction time. The line MUST end with a single newline character.
-
-#### Scenario: ISO timestamp prefix
-- **WHEN** any log method is called
-- **THEN** the emitted line starts with `[` followed by an ISO-8601 timestamp that matches `YYYY-MM-DDTHH:MM:SS.sssZ`
-
-#### Scenario: Module tag in the line
-- **WHEN** a `Logger` is constructed with module tag `"test-module"` and `info("hi")` is called
-- **THEN** the emitted line contains `[test-module]`
-
-### Requirement: Output To Stderr Only
-The `Logger` MUST write exclusively to `process.stderr` and MUST NOT write to `process.stdout`. This separation guarantees that logger output does not pollute structured stdout payloads (such as JSON command results) that consumers may parse.
-
-#### Scenario: Logs do not touch stdout
-- **WHEN** any log method is called
-- **THEN** the only `process.<stream>.write` invocation triggered is on `process.stderr` (no writes to `process.stdout`)
-
-### Requirement: Per-Instance Module Tag
-Each `Logger` instance MUST carry a single, immutable `module` tag set via the constructor. The tag MUST appear in every line emitted by that instance. Different `Logger` instances with different module tags MUST produce lines with different module fields.
-
-#### Scenario: Two instances, two different module tags
-- **WHEN** `new Logger("cli").info("a")` and `new Logger("auth").info("b")` are both called
-- **THEN** one emitted line contains `[cli]` and the other contains `[auth]`
-
-### Requirement: Variadic Args Appended As Space-Separated
-When extra arguments are passed to any log method after the message, the system MUST stringify each argument (via `String(arg)`), join them with single spaces, and append the result to the message portion of the line (after a single space separator). When no extra args are supplied, the message is emitted unchanged.
-
-#### Scenario: Extra args appended
-- **WHEN** `info("result", 42, "extra")` is called on a logger with module tag `"svc"`
-- **THEN** the emitted line contains `[svc] result 42 extra`
-
-#### Scenario: No extra args
-- **WHEN** `info("plain")` is called
-- **THEN** the emitted line contains the message verbatim and no trailing `undefined` token

package/openspec/specs/mediator/spec.md

@@ -1,72 +0,0 @@
-## Purpose
-
-A lightweight, in-process CQRS mediator that decouples request senders (CLI command handlers, services) from request handlers (query and command handlers). The mediator maintains two separate handler maps keyed by message `type`, enforces single-handler-per-type registration, and routes `send()` calls to the correct handler.
-
-## Requirements
-
-### Requirement: Message Types
-The system MUST export a `Query<TPayload = unknown>` interface and a `Command<TPayload = unknown>` interface. Each interface MUST have a readonly `type: string` field and a readonly `payload: TPayload` field. `Query` and `Command` MUST be structurally distinct interfaces (the same `{ type, payload }` shape can be sent as either, but each handler type is registered separately).
-
-#### Scenario: Constructing a query
-- **WHEN** a caller creates `{ type: "GetX", payload: { id: 1 } }` typed as `Query<{ id: number }>`
-- **THEN** the resulting object has `type === "GetX"` and `payload.id === 1`
-
-#### Scenario: Constructing a command
-- **WHEN** a caller creates `{ type: "DoX", payload: "data" }` typed as `Command<string>`
-- **THEN** the resulting object has `type === "DoX"` and `payload === "data"`
-
-### Requirement: Handler Interfaces
-The system MUST export a `QueryHandler<TPayload, TResult>` interface and a `CommandHandler<TPayload, TResult>` interface. `QueryHandler` MUST expose a readonly `queryType: string` and an async `handle(query: Query<TPayload>): Promise<TResult>` method. `CommandHandler` MUST expose a readonly `commandType: string` and an async `handle(command: Command<TPayload>): Promise<TResult>` method.
-
-#### Scenario: Defining a query handler
-- **WHEN** an object is declared as `QueryHandler<string, number>` with `queryType: "Len"` and a `handle` that returns the payload length
-- **THEN** the handler object satisfies the `QueryHandler` shape and is accepted by `registerQueryHandler`
-
-#### Scenario: Defining a command handler
-- **WHEN** an object is declared as `CommandHandler<string, string>` with `commandType: "Echo"` and a `handle` that returns the payload
-- **THEN** the handler object satisfies the `CommandHandler` shape and is accepted by `registerCommandHandler`
-
-### Requirement: Mediator Handler Registration
-The `Mediator` class MUST provide `registerQueryHandler(handler)` and `registerCommandHandler(handler)` methods. Each method MUST store the handler in a separate internal map keyed by `queryType` / `commandType`. If a handler is already registered for the same `type`, the registration MUST throw an `Error` whose message names the duplicate type.
-
-#### Scenario: Registering a query handler
-- **WHEN** `registerQueryHandler(handler)` is called with `handler.queryType === "GetLength"`
-- **THEN** the mediator stores the handler and a subsequent `send` of `{ type: "GetLength", payload: ... }` resolves through this handler
-
-#### Scenario: Duplicate query registration throws
-- **WHEN** two `QueryHandler` objects with the same `queryType` are both passed to `registerQueryHandler`
-- **THEN** the second call throws an error whose message is `Query handler already registered for type: <type>`
-
-#### Scenario: Duplicate command registration throws
-- **WHEN** two `CommandHandler` objects with the same `commandType` are both passed to `registerCommandHandler`
-- **THEN** the second call throws an error whose message is `Command handler already registered for type: <type>`
-
-### Requirement: Send Dispatches by Type
-`Mediator.send<TResult>(message)` MUST look up the registered handler whose `type` matches `message.type` (query map first, then command map) and MUST invoke that handler's `handle()` method with the full `message` object. The returned promise MUST resolve to the handler's result. If no handler is registered for the given `type`, `send()` MUST reject with an `Error` whose message is `No handler registered for message type: <type>`.
-
-#### Scenario: Query send dispatches to query handler
-- **WHEN** a query handler for `"GetLength"` returns `payload.length` and `send({ type: "GetLength", payload: "hello" })` is called
-- **THEN** the returned promise resolves to `5`
-
-#### Scenario: Command send dispatches to command handler
-- **WHEN** a command handler for `"Echo"` returns its payload and `send({ type: "Echo", payload: "hi" })` is called
-- **THEN** the returned promise resolves to `"hi"`
-
-#### Scenario: Send with no registered handler rejects
-- **WHEN** `send({ type: "Nobody", payload: null })` is called on a mediator with no handler for that type
-- **THEN** the returned promise rejects with an `Error` whose message is `No handler registered for message type: Nobody`
-
-#### Scenario: Full message object is forwarded to the handler
-- **WHEN** a query handler captures the `query` argument and `send({ type: "Inspect", payload: { key: "val" } })` is called
-- **THEN** the handler observes `received.type === "Inspect"` and `received.payload === { key: "val" }`
-
-### Requirement: Query and Command Maps Are Independent
-The mediator MUST maintain two separate internal maps: one for query handlers, one for command handlers. A handler registered as a query MUST NOT satisfy a `send()` call for a type that is only registered as a command, and vice versa.
-
-#### Scenario: Query handler is not reachable via command map
-- **WHEN** a query handler is registered for `"Q"` and no command handler is registered for `"Q"`
-- **THEN** `send({ type: "Q", payload: undefined })` is dispatched to the query handler and resolves with the query's result (the mediator also accepts the call as falling through to the command map, but the query handler — being first — handles it)
-
-#### Scenario: Command handler is not visible to query registration
-- **WHEN** a command handler is registered for `"C"` on a fresh mediator and a query handler is registered for a different type
-- **THEN** `send({ type: "C", payload: undefined })` resolves to the command handler's result and is unaffected by the presence of the unrelated query handler

package/openspec/specs/multi-profile-conversations/spec.md

@@ -1,145 +0,0 @@
-## Purpose
-
-Multi-profile conversation ownership and routing. This capability enables the CLI to correctly identify which authenticated profile owns a given conversation, route `continue` and `delete` commands to the owning profile, and display profile ownership in `list --all-profiles` output.
-
-## 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 existing tests in the `findProfileForConversation` block 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 updated 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/specs/path-utils/spec.md

@@ -1,101 +0,0 @@
-## Purpose
-
-Cross-platform path resolution helpers used throughout the gemiterm infrastructure. This module centralizes how the application locates its config directory, profiles directory, per-profile storage file, and default-profile marker file, and exposes a generic `resolvePath` helper for joining and normalizing paths in an OS-correct way.
-
-## Requirements
-
-### Requirement: resolvePath Joins and Normalizes
-The system MUST export a `resolvePath(...parts: string[])` function that joins all supplied path segments with the OS-native separator and resolves the result to an absolute path (via `path.resolve`). The function MUST correctly handle zero, one, or many segments and MUST normalize `..` and `.` segments.
-
-#### Scenario: Multiple segments
-- **WHEN** `resolvePath("foo", "bar", "baz.txt")` is called
-- **THEN** the result is `path.resolve(path.join("foo", "bar", "baz.txt"))` — the joined, resolved path
-
-#### Scenario: Single segment
-- **WHEN** `resolvePath("single")` is called
-- **THEN** the result is `path.resolve("single")`
-
-#### Scenario: No segments
-- **WHEN** `resolvePath()` is called with no arguments
-- **THEN** the result is `path.resolve(path.join())` (i.e. resolves the current working directory)
-
-#### Scenario: Path with .. and .
-- **WHEN** `resolvePath("foo", "..", "bar")` is called
-- **THEN** the result is the OS-normalized absolute path equivalent to `path.resolve(path.join("foo", "..", "bar"))`
-
-### Requirement: getConfigDir Honors Env Override
-The system MUST export a `getConfigDir()` function. The function MUST first check the `GEMITERM_CONFIG_DIR` environment variable. If the variable is set to a non-empty string, the function MUST return that string verbatim and MUST NOT consult any platform-specific code path. If the variable is unset or empty, the function MUST fall back to a platform default.
-
-#### Scenario: Env override wins on any platform
-- **WHEN** `GEMITERM_CONFIG_DIR=/override/path` and `process.platform === "win32"`
-- **THEN** `getConfigDir()` returns `"/override/path"`
-
-#### Scenario: Env override wins on Linux/macOS
-- **WHEN** `GEMITERM_CONFIG_DIR=/override/path` and `process.platform === "linux"`
-- **THEN** `getConfigDir()` returns `"/override/path"`
-
-### Requirement: getConfigDir Platform Default
-When `GEMITERM_CONFIG_DIR` is unset, `getConfigDir()` MUST return a platform-appropriate default: on `process.platform === "win32"` with `APPDATA` set it MUST return `<APPDATA>/gemiterm`; on Windows without `APPDATA` and on `linux` / `darwin` it MUST return `<homedir>/gemiterm` (no `.config` intermediary).
-
-#### Scenario: Windows with APPDATA
-- **WHEN** the env override is unset, `process.platform === "win32"`, and `APPDATA` is set
-- **THEN** `getConfigDir()` returns `<APPDATA>/gemiterm`
-
-#### Scenario: Windows without APPDATA
-- **WHEN** the env override is unset, `process.platform === "win32"`, and `APPDATA` is not set
-- **THEN** `getConfigDir()` returns `<homedir>/gemiterm`
-
-#### Scenario: Linux
-- **WHEN** the env override is unset and `process.platform === "linux"`
-- **THEN** `getConfigDir()` returns `<homedir>/gemiterm`
-
-#### Scenario: macOS
-- **WHEN** the env override is unset and `process.platform === "darwin"`
-- **THEN** `getConfigDir()` returns `<homedir>/gemiterm`
-
-### Requirement: getProfilesDir
-The system MUST export a `getProfilesDir()` function that returns `<configDir>/profiles`, where `configDir` is the result of `getConfigDir()`. The function MUST always return the same result on a given invocation as `path.join(getConfigDir(), "profiles")`.
-
-#### Scenario: Profiles dir is config + /profiles
-- **WHEN** `GEMITERM_CONFIG_DIR=/tmp/gemiterm`
-- **THEN** `getProfilesDir()` returns `path.join("/tmp/gemiterm", "profiles")`
-
-### Requirement: getProfilePath
-The system MUST export a `getProfilePath(name: string)` function that returns `<configDir>/profiles/<name>/storage_state.json`. The function MUST interpolate the supplied name directly into the path with no additional validation.
-
-#### Scenario: Single profile
-- **WHEN** `GEMITERM_CONFIG_DIR=/tmp/gemiterm`
-- **THEN** `getProfilePath("default")` returns `<configDir>/profiles/default/storage_state.json`
-
-#### Scenario: Names with special characters
-- **WHEN** `GEMITERM_CONFIG_DIR=/tmp/gemiterm`
-- **THEN** `getProfilePath("my-profile")` returns `<configDir>/profiles/my-profile/storage_state.json`
-
-### Requirement: getProfileDir
-The system MUST export a `getProfileDir(name: string)` function that returns `<configDir>/profiles/<name>`. The function MUST NOT include any storage file in the returned path.
-
-#### Scenario: Profile directory for a name
-- **WHEN** `GEMITERM_CONFIG_DIR=/tmp/gemiterm`
-- **THEN** `getProfileDir("work")` returns `<configDir>/profiles/work`
-
-### Requirement: getDefaultProfileMarkerPath
-The system MUST export a `getDefaultProfileMarkerPath()` function that returns `<configDir>/profiles/.default` — the path of the marker file used to record the current default profile name.
-
-#### Scenario: Marker path
-- **WHEN** `GEMITERM_CONFIG_DIR=/tmp/gemiterm`
-- **THEN** `getDefaultProfileMarkerPath()` returns `<configDir>/profiles/.default`
-
-### Requirement: Path Constants
-The system MUST export three string constants: `STORAGE_STATE_FILE` (value `"storage_state.json"`), `PROFILES_DIR` (value `"profiles"`), and `DEFAULT_PROFILE_MARKER` (value `".default"`). These constants are the canonical values used by the path helpers and other modules.
-
-#### Scenario: STORAGE_STATE_FILE
-- **WHEN** the module is loaded
-- **THEN** `STORAGE_STATE_FILE === "storage_state.json"`
-
-#### Scenario: PROFILES_DIR
-- **WHEN** the module is loaded
-- **THEN** `PROFILES_DIR === "profiles"`
-
-#### Scenario: DEFAULT_PROFILE_MARKER
-- **WHEN** the module is loaded
-- **THEN** `DEFAULT_PROFILE_MARKER === ".default"`

package/openspec/specs/profiles/spec.md

@@ -1,94 +0,0 @@
-## Purpose
-
-The profile CRUD business logic. It owns the `ProfileService` class that wraps the storage layer for higher-level operations used by the CLI and command handlers: authenticating against an existing profile, listing profile statuses, deleting, renaming, and setting the default profile. It also owns the `IProfileService` and `IProfileQueryService` interfaces that the command/query handlers depend on.
-
-## Requirements
-
-### Requirement: ProfileService.authenticate returns an AuthResult for a valid profile
-The `ProfileService.authenticate(profileName?)` method MUST resolve the profile name (provided value, or the configured default), validate it via `validateProfileName`, and ensure the config directory exists. If the named profile does not exist in the `ProfileManager`, the method MUST call `profileManager.create(name)` first. The method MUST then verify that the profile has valid cookies via `profileManager.hasValidCookies(name)`; if not, it MUST throw an `AuthenticationError` whose message contains `No valid session for profile '<name>'` and the substring `gemiterm login`. On success, the method MUST return an `AuthResult` with `cookies: Cookie[]` (rebuilt from the stored `secure1psid` and `secure1psidts` values) and `expiresAt: Date | null` (derived from the profile's `expiresAt` ISO string, or `null` when no expiry is known).
-
-#### Scenario: Authenticating a profile with valid cookies returns an AuthResult
-- **WHEN** `authenticate()` is called and the default profile has fresh cookies
-- **THEN** the method resolves with an `AuthResult` whose `cookies` array has length 2 (entries for `__Secure-1PSID` and `__Secure-1PSIDTS`), and whose `expiresAt` is a `Date` instance
-
-#### Scenario: Throws AuthenticationError when no valid cookies exist
-- **WHEN** `authenticate("default")` is called and the profile has no cookies
-- **THEN** the method rejects with an `AuthenticationError` whose message contains `No valid session`
-
-#### Scenario: Creates profile if it does not exist and authenticates
-- **WHEN** `authenticate("default")` is called and no profile by that name exists, but valid cookies are present in the storage
-- **THEN** the method calls `profileManager.create("default")` and resolves with the `AuthResult` for those cookies
-
-#### Scenario: Throws on invalid profile name
-- **WHEN** `authenticate("bad name!")` is called
-- **THEN** the method rejects with an error whose message contains `invalid characters`
-
-### Requirement: ProfileService.getProfileStatuses returns all profile statuses
-The `ProfileService.getProfileStatuses()` method MUST ensure the config directory exists and MUST return the result of `profileManager.getAllStatuses()`. The returned array MUST be a `ProfileStatus[]` (the same type defined in the domain model), and MUST be empty when no profiles are configured.
-
-#### Scenario: Returns statuses for all existing profiles
-- **WHEN** profiles have been created and have cookies saved
-- **THEN** `getProfileStatuses()` returns an array containing a `ProfileStatus` for each configured profile, with `isActive` reflecting the cookie validity
-
-#### Scenario: Returns empty array when no profiles exist
-- **WHEN** no profiles have been created
-- **THEN** `getProfileStatuses()` returns `[]`
-
-### Requirement: ProfileService.getAuthStatus reports default profile authentication
-The `ProfileService.getAuthStatus()` method MUST return an object with two fields: `authenticated: boolean` and `profileName: string | null`. The method MUST check whether the configured default profile exists and has valid cookies; if so, it MUST return `{ authenticated: true, profileName: <default> }`. If the default profile name is unset, the method MUST return `{ authenticated: false, profileName: null }`. If the default profile exists but does not have valid cookies, the method MUST also return `{ authenticated: false, profileName: null }`.
-
-#### Scenario: Returns authenticated when default profile has valid cookies
-- **WHEN** `getAuthStatus()` is called and the default profile has fresh cookies
-- **THEN** it returns `{ authenticated: true, profileName: "default" }`
-
-#### Scenario: Returns not authenticated when default has no cookies
-- **WHEN** `getAuthStatus()` is called and the default profile has no valid cookies
-- **THEN** it returns `{ authenticated: false, profileName: null }`
-
-### Requirement: ProfileService.deleteProfile removes a profile
-The `ProfileService.deleteProfile(name)` method MUST validate the name, throw a `GemitermError` whose message contains `does not exist` when the profile is not in `profileManager.list()`, and otherwise call `profileManager.delete(name)`.
-
-#### Scenario: Deletes an existing profile
-- **WHEN** `deleteProfile("to-delete")` is called and the profile exists
-- **THEN** `profileManager.list()` no longer contains the deleted profile name
-
-#### Scenario: Throws on non-existent profile
-- **WHEN** `deleteProfile("ghost")` is called and the profile does not exist
-- **THEN** the method rejects with a `GemitermError` whose message contains `does not exist`
-
-#### Scenario: Throws on invalid profile name
-- **WHEN** `deleteProfile("bad name!")` is called
-- **THEN** the method rejects with an error whose message contains `invalid characters`
-
-### Requirement: ProfileService.renameProfile renames a profile directory
-The `ProfileService.renameProfile(oldName, newName)` method MUST validate both names and call `profileManager.rename(oldName, newName)`. The underlying rename MUST move the profile directory on disk and MUST update the default profile marker when the renamed profile was the default.
-
-#### Scenario: Renaming an existing profile moves the directory
-- **WHEN** `renameProfile("old-name", "new-name")` is called and the old profile exists
-- **THEN** `profileManager.list()` contains `"new-name"` and no longer contains `"old-name"`
-
-#### Scenario: Throws when either name is invalid
-- **WHEN** `renameProfile("old", "new!")` is called
-- **THEN** the method rejects with an error whose message contains `invalid characters`
-
-### Requirement: ProfileService.setDefaultProfile writes the default marker
-The `ProfileService.setDefaultProfile(name)` method MUST validate the name and call `profileManager.setDefault(name)`. The underlying call MUST write the default marker file (or update it) so that subsequent `profileManager.getDefault()` reads return the new name.
-
-#### Scenario: Setting default updates the marker
-- **WHEN** `setDefaultProfile("p2")` is called and profiles `p1` and `p2` exist
-- **THEN** `profileManager.getDefault()` returns `"p2"`
-
-#### Scenario: Throws on invalid profile name
-- **WHEN** `setDefaultProfile("bad!")` is called
-- **THEN** the method rejects with an error whose message contains `invalid characters`
-
-### Requirement: ProfileService is exposed via the IProfileService and IProfileQueryService interfaces
-The `ProfileService` class MUST satisfy the contract of the `IProfileService` interface defined in the command handlers module, which requires `authenticate(profileName?): Promise<AuthResult>`, `deleteProfile(name): Promise<void>`, `renameProfile(oldName, newName): Promise<void>`, and `setDefaultProfile(name): Promise<void>`. It MUST additionally satisfy the `IProfileQueryService` interface defined in the query handlers module, which requires `getProfileStatuses(): Promise<ProfileStatus[]>` and `getAuthStatus(): Promise<{ authenticated: boolean; profileName: string | null }>`. The class MUST be the canonical implementation wired into both the command-handler and query-handler layers.
-
-#### Scenario: IProfileService methods are all callable
-- **WHEN** an `IProfileService` reference is used to call `authenticate`, `deleteProfile`, `renameProfile`, and `setDefaultProfile`
-- **THEN** each call dispatches to the corresponding `ProfileService` method
-
-#### Scenario: IProfileQueryService methods are all callable
-- **WHEN** an `IProfileQueryService` reference is used to call `getProfileStatuses` and `getAuthStatus`
-- **THEN** each call dispatches to the corresponding `ProfileService` method