diff --git a/) {} b/) {}
new file mode 100644
index 0000000..2807556
--- /dev/null
+++ b/) {}	
@@ -0,0 +1,47 @@
+
+**Test Helper Complexity**
+`src/__tests__/helpers/runtime-smoke.ts` creates sophisticated mock environments. The `TestLinearAuth` class extends `LinearAuth` and overrides methods, which creates tight coupling to the implementation. Consider using interface-based mocking or dependency injection instead of class inheritance for tests.
+
+## Reliability Analysis
+
+### Strengths
+
+**Request Policy Resilience**
+The `executeWithRequestPolicy` function implements a robust retry mechanism with:
+- Exponential backoff calculation (`retryDelayMs * attempt`)
+- Attempt context passing for cancellation signals
+- Proper cleanup of AbortController listeners
+- Last error preservation for final throw
+
+**GraphQL Error Normalization**
+`src/graphql/client.ts` provides sophisticated error handling:
+- `normalizeErrors` converts unknown error shapes into structured `GraphQLErrorDetail` objects
+- `isRetryable` checks both HTTP status codes and GraphQL error codes
+- `createErrorResult` ensures consistent error shapes even for unexpected exceptions
+
+**Compensation Transactions**
+The `createProjectWithIssues` method implements saga pattern compensation:
+- If issue creation fails after project creation, it attempts to delete the orphaned project
+- Returns detailed failure context including `compensationAttempted` and `compensationSucceeded` flags
+- Preserves partial results (`project`, `issues`) for debugging
+
+**Safe SDK Operations**
+The `SAFE_SDK_READ_OPERATIONS` Set in `src/graphql/client.ts` explicitly whitelists operations that can be safely retried, preventing dangerous retries of mutations that may have already partially executed server-side.
+
+### Areas for Improvement
+
+**AbortController Listener Cleanup**
+In `executeWithTimeout`, the abort listener is added with `{ once: true }`, but if the promise resolves before abort, the listener is removed via `controller.signal.removeEventListener`. However, if `execute` throws synchronously (before the Promise microtask), the `onAbort` listener might not be cleaned up immediately. Consider using `AbortSignal.any` (Node 20+) or ensuring cleanup in a `finally` block.
+
+**Race Condition in Telemetry**
+`RuntimeObservability` maintains counters (`totalRequests`, `successfulRequests`, etc.) as private instance variables. If multiple async operations complete simultaneously, these increments could race. While JavaScript is single-threaded, the async boundary between await points could theoretically allow interleaving. Consider using atomic operations or ensuring these updates happen synchronously.
+
+**GraphQL Client State Management**
+The `LinearGraphQLClient` maintains a reference to `LinearClient` which may hold HTTP connection pools. If `LinearAuth` creates new `LinearClient` instances on token refresh (implied by `createScopedCopy`), old clients might not have their connections cleaned up. Ensure `LinearClient` instances are properly disposed or reused.
+
+**Test Port Reliability**
+`getAvailablePort` in `src/__tests__/helpers/runtime-smoke.ts` binds to port 0 to find an available port, then closes the server. This creates a race condition where another process could bind to that port between `getAvailablePort` returning and the actual test server starting. Consider using port 0 binding directly on the test server with retry logic.
+
+**Error Message Construction**
+The `buildErrorMessage` method in `src/graphql/client.ts` concatenates strings that could potentially be very large (GraphQL error messages). If error messages contain massive query dumps, this could cause memory pressure. Consider truncating error messages:
+
diff --git a/.claude/commands/opsx/apply.md b/.claude/commands/opsx/apply.md
new file mode 100644
index 0000000..bf23721
--- /dev/null
+++ b/.claude/commands/opsx/apply.md
@@ -0,0 +1,152 @@
+---
+name: "OPSX: Apply"
+description: Implement tasks from an OpenSpec change (Experimental)
+category: Workflow
+tags: [workflow, artifacts, experimental]
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! You can archive this change with `/opsx:archive`.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/commands/opsx/archive.md b/.claude/commands/opsx/archive.md
new file mode 100644
index 0000000..5e91608
--- /dev/null
+++ b/.claude/commands/opsx/archive.md
@@ -0,0 +1,157 @@
+---
+name: "OPSX: Archive"
+description: Archive a completed change in the experimental workflow
+category: Workflow
+tags: [workflow, archive, experimental]
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Spec sync status (synced / sync skipped / no delta specs)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success (No Delta Specs)**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** No delta specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success With Warnings**
+
+```
+## Archive Complete (with warnings)
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** Sync skipped (user chose to skip)
+
+**Warnings:**
+- Archived with 2 incomplete artifacts
+- Archived with 3 incomplete tasks
+- Delta spec sync was skipped (user chose to skip)
+
+Review the archive if this was not intentional.
+```
+
+**Output On Error (Archive Exists)**
+
+```
+## Archive Failed
+
+**Change:** <change-name>
+**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+
+Target archive directory already exists.
+
+**Options:**
+1. Rename the existing archive
+2. Delete the existing archive if it's a duplicate
+3. Wait until a different date to archive
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/commands/opsx/explore.md b/.claude/commands/opsx/explore.md
new file mode 100644
index 0000000..30d9c57
--- /dev/null
+++ b/.claude/commands/opsx/explore.md
@@ -0,0 +1,173 @@
+---
+name: "OPSX: Explore"
+description: "Enter explore mode - think through ideas, investigate problems, clarify requirements"
+category: Workflow
+tags: [workflow, explore, experimental, thinking]
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
+- A vague idea: "real-time collaboration"
+- A specific problem: "the auth system is getting unwieldy"
+- A change name: "add-dark-mode" (to explore in context of that change)
+- A comparison: "postgres vs sqlite for this"
+- Nothing (just enter explore mode)
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+If the user mentioned a specific change name, read its artifacts for context.
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/commands/opsx/propose.md b/.claude/commands/opsx/propose.md
new file mode 100644
index 0000000..05276f4
--- /dev/null
+++ b/.claude/commands/opsx/propose.md
@@ -0,0 +1,106 @@
+---
+name: "OPSX: Propose"
+description: Propose a new change - create it and generate all artifacts in one step
+category: Workflow
+tags: [workflow, artifacts, experimental]
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+1. **If no input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` to start implementing."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.claude/skills/gitnexus/gitnexus-cli/SKILL.md b/.claude/skills/gitnexus/gitnexus-cli/SKILL.md
new file mode 100644
index 0000000..c9e0af3
--- /dev/null
+++ b/.claude/skills/gitnexus/gitnexus-cli/SKILL.md
@@ -0,0 +1,82 @@
+---
+name: gitnexus-cli
+description: "Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \"Index this repo\", \"Reanalyze the codebase\", \"Generate a wiki\""
+---
+
+# GitNexus CLI Commands
+
+All commands work via `npx` — no global install required.
+
+## Commands
+
+### analyze — Build or refresh the index
+
+```bash
+npx gitnexus analyze
+```
+
+Run from the project root. This parses all source files, builds the knowledge graph, writes it to `.gitnexus/`, and generates CLAUDE.md / AGENTS.md context files.
+
+| Flag           | Effect                                                           |
+| -------------- | ---------------------------------------------------------------- |
+| `--force`      | Force full re-index even if up to date                           |
+| `--embeddings` | Enable embedding generation for semantic search (off by default) |
+
+**When to run:** First time in a project, after major code changes, or when `gitnexus://repo/{name}/context` reports the index is stale. In Claude Code, a PostToolUse hook runs `analyze` automatically after `git commit` and `git merge`, preserving embeddings if previously generated.
+
+### status — Check index freshness
+
+```bash
+npx gitnexus status
+```
+
+Shows whether the current repo has a GitNexus index, when it was last updated, and symbol/relationship counts. Use this to check if re-indexing is needed.
+
+### clean — Delete the index
+
+```bash
+npx gitnexus clean
+```
+
+Deletes the `.gitnexus/` directory and unregisters the repo from the global registry. Use before re-indexing if the index is corrupt or after removing GitNexus from a project.
+
+| Flag      | Effect                                            |
+| --------- | ------------------------------------------------- |
+| `--force` | Skip confirmation prompt                          |
+| `--all`   | Clean all indexed repos, not just the current one |
+
+### wiki — Generate documentation from the graph
+
+```bash
+npx gitnexus wiki
+```
+
+Generates repository documentation from the knowledge graph using an LLM. Requires an API key (saved to `~/.gitnexus/config.json` on first use).
+
+| Flag                | Effect                                    |
+| ------------------- | ----------------------------------------- |
+| `--force`           | Force full regeneration                   |
+| `--model <model>`   | LLM model (default: minimax/minimax-m2.5) |
+| `--base-url <url>`  | LLM API base URL                          |
+| `--api-key <key>`   | LLM API key                               |
+| `--concurrency <n>` | Parallel LLM calls (default: 3)           |
+| `--gist`            | Publish wiki as a public GitHub Gist      |
+
+### list — Show all indexed repos
+
+```bash
+npx gitnexus list
+```
+
+Lists all repositories registered in `~/.gitnexus/registry.json`. The MCP `list_repos` tool provides the same information.
+
+## After Indexing
+
+1. **Read `gitnexus://repo/{name}/context`** to verify the index loaded
+2. Use the other GitNexus skills (`exploring`, `debugging`, `impact-analysis`, `refactoring`) for your task
+
+## Troubleshooting
+
+- **"Not inside a git repository"**: Run from a directory inside a git repo
+- **Index is stale after re-analyzing**: Restart Claude Code to reload the MCP server
+- **Embeddings slow**: Omit `--embeddings` (it's off by default) or set `OPENAI_API_KEY` for faster API-based embedding
diff --git a/.claude/skills/gitnexus/gitnexus-debugging/SKILL.md b/.claude/skills/gitnexus/gitnexus-debugging/SKILL.md
new file mode 100644
index 0000000..9510b97
--- /dev/null
+++ b/.claude/skills/gitnexus/gitnexus-debugging/SKILL.md
@@ -0,0 +1,89 @@
+---
+name: gitnexus-debugging
+description: "Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: \"Why is X failing?\", \"Where does this error come from?\", \"Trace this bug\""
+---
+
+# Debugging with GitNexus
+
+## When to Use
+
+- "Why is this function failing?"
+- "Trace where this error comes from"
+- "Who calls this method?"
+- "This endpoint returns 500"
+- Investigating bugs, errors, or unexpected behavior
+
+## Workflow
+
+```
+1. gitnexus_query({query: "<error or symptom>"})            → Find related execution flows
+2. gitnexus_context({name: "<suspect>"})                    → See callers/callees/processes
+3. READ gitnexus://repo/{name}/process/{name}                → Trace execution flow
+4. gitnexus_cypher({query: "MATCH path..."})                 → Custom traces if needed
+```
+
+> If "Index is stale" → run `npx gitnexus analyze` in terminal.
+
+## Checklist
+
+```
+- [ ] Understand the symptom (error message, unexpected behavior)
+- [ ] gitnexus_query for error text or related code
+- [ ] Identify the suspect function from returned processes
+- [ ] gitnexus_context to see callers and callees
+- [ ] Trace execution flow via process resource if applicable
+- [ ] gitnexus_cypher for custom call chain traces if needed
+- [ ] Read source files to confirm root cause
+```
+
+## Debugging Patterns
+
+| Symptom              | GitNexus Approach                                          |
+| -------------------- | ---------------------------------------------------------- |
+| Error message        | `gitnexus_query` for error text → `context` on throw sites |
+| Wrong return value   | `context` on the function → trace callees for data flow    |
+| Intermittent failure | `context` → look for external calls, async deps            |
+| Performance issue    | `context` → find symbols with many callers (hot paths)     |
+| Recent regression    | `detect_changes` to see what your changes affect           |
+
+## Tools
+
+**gitnexus_query** — find code related to error:
+
+```
+gitnexus_query({query: "payment validation error"})
+→ Processes: CheckoutFlow, ErrorHandling
+→ Symbols: validatePayment, handlePaymentError, PaymentException
+```
+
+**gitnexus_context** — full context for a suspect:
+
+```
+gitnexus_context({name: "validatePayment"})
+→ Incoming calls: processCheckout, webhookHandler
+→ Outgoing calls: verifyCard, fetchRates (external API!)
+→ Processes: CheckoutFlow (step 3/7)
+```
+
+**gitnexus_cypher** — custom call chain traces:
+
+```cypher
+MATCH path = (a)-[:CodeRelation {type: 'CALLS'}*1..2]->(b:Function {name: "validatePayment"})
+RETURN [n IN nodes(path) | n.name] AS chain
+```
+
+## Example: "Payment endpoint returns 500 intermittently"
+
+```
+1. gitnexus_query({query: "payment error handling"})
+   → Processes: CheckoutFlow, ErrorHandling
+   → Symbols: validatePayment, handlePaymentError
+
+2. gitnexus_context({name: "validatePayment"})
+   → Outgoing calls: verifyCard, fetchRates (external API!)
+
+3. READ gitnexus://repo/my-app/process/CheckoutFlow
+   → Step 3: validatePayment → calls fetchRates (external)
+
+4. Root cause: fetchRates calls external API without proper timeout
+```
diff --git a/.claude/skills/gitnexus/gitnexus-exploring/SKILL.md b/.claude/skills/gitnexus/gitnexus-exploring/SKILL.md
new file mode 100644
index 0000000..927a4e4
--- /dev/null
+++ b/.claude/skills/gitnexus/gitnexus-exploring/SKILL.md
@@ -0,0 +1,78 @@
+---
+name: gitnexus-exploring
+description: "Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: \"How does X work?\", \"What calls this function?\", \"Show me the auth flow\""
+---
+
+# Exploring Codebases with GitNexus
+
+## When to Use
+
+- "How does authentication work?"
+- "What's the project structure?"
+- "Show me the main components"
+- "Where is the database logic?"
+- Understanding code you haven't seen before
+
+## Workflow
+
+```
+1. READ gitnexus://repos                          → Discover indexed repos
+2. READ gitnexus://repo/{name}/context             → Codebase overview, check staleness
+3. gitnexus_query({query: "<what you want to understand>"})  → Find related execution flows
+4. gitnexus_context({name: "<symbol>"})            → Deep dive on specific symbol
+5. READ gitnexus://repo/{name}/process/{name}      → Trace full execution flow
+```
+
+> If step 2 says "Index is stale" → run `npx gitnexus analyze` in terminal.
+
+## Checklist
+
+```
+- [ ] READ gitnexus://repo/{name}/context
+- [ ] gitnexus_query for the concept you want to understand
+- [ ] Review returned processes (execution flows)
+- [ ] gitnexus_context on key symbols for callers/callees
+- [ ] READ process resource for full execution traces
+- [ ] Read source files for implementation details
+```
+
+## Resources
+
+| Resource                                | What you get                                            |
+| --------------------------------------- | ------------------------------------------------------- |
+| `gitnexus://repo/{name}/context`        | Stats, staleness warning (~150 tokens)                  |
+| `gitnexus://repo/{name}/clusters`       | All functional areas with cohesion scores (~300 tokens) |
+| `gitnexus://repo/{name}/cluster/{name}` | Area members with file paths (~500 tokens)              |
+| `gitnexus://repo/{name}/process/{name}` | Step-by-step execution trace (~200 tokens)              |
+
+## Tools
+
+**gitnexus_query** — find execution flows related to a concept:
+
+```
+gitnexus_query({query: "payment processing"})
+→ Processes: CheckoutFlow, RefundFlow, WebhookHandler
+→ Symbols grouped by flow with file locations
+```
+
+**gitnexus_context** — 360-degree view of a symbol:
+
+```
+gitnexus_context({name: "validateUser"})
+→ Incoming calls: loginHandler, apiMiddleware
+→ Outgoing calls: checkToken, getUserById
+→ Processes: LoginFlow (step 2/5), TokenRefresh (step 1/3)
+```
+
+## Example: "How does payment processing work?"
+
+```
+1. READ gitnexus://repo/my-app/context       → 918 symbols, 45 processes
+2. gitnexus_query({query: "payment processing"})
+   → CheckoutFlow: processPayment → validateCard → chargeStripe
+   → RefundFlow: initiateRefund → calculateRefund → processRefund
+3. gitnexus_context({name: "processPayment"})
+   → Incoming: checkoutHandler, webhookHandler
+   → Outgoing: validateCard, chargeStripe, saveTransaction
+4. Read src/payments/processor.ts for implementation details
+```
diff --git a/.claude/skills/gitnexus/gitnexus-guide/SKILL.md b/.claude/skills/gitnexus/gitnexus-guide/SKILL.md
new file mode 100644
index 0000000..937ac73
--- /dev/null
+++ b/.claude/skills/gitnexus/gitnexus-guide/SKILL.md
@@ -0,0 +1,64 @@
+---
+name: gitnexus-guide
+description: "Use when the user asks about GitNexus itself — available tools, how to query the knowledge graph, MCP resources, graph schema, or workflow reference. Examples: \"What GitNexus tools are available?\", \"How do I use GitNexus?\""
+---
+
+# GitNexus Guide
+
+Quick reference for all GitNexus MCP tools, resources, and the knowledge graph schema.
+
+## Always Start Here
+
+For any task involving code understanding, debugging, impact analysis, or refactoring:
+
+1. **Read `gitnexus://repo/{name}/context`** — codebase overview + check index freshness
+2. **Match your task to a skill below** and **read that skill file**
+3. **Follow the skill's workflow and checklist**
+
+> If step 1 warns the index is stale, run `npx gitnexus analyze` in the terminal first.
+
+## Skills
+
+| Task                                         | Skill to read       |
+| -------------------------------------------- | ------------------- |
+| Understand architecture / "How does X work?" | `gitnexus-exploring`         |
+| Blast radius / "What breaks if I change X?"  | `gitnexus-impact-analysis`   |
+| Trace bugs / "Why is X failing?"             | `gitnexus-debugging`         |
+| Rename / extract / split / refactor          | `gitnexus-refactoring`       |
+| Tools, resources, schema reference           | `gitnexus-guide` (this file) |
+| Index, status, clean, wiki CLI commands      | `gitnexus-cli`               |
+
+## Tools Reference
+
+| Tool             | What it gives you                                                        |
+| ---------------- | ------------------------------------------------------------------------ |
+| `query`          | Process-grouped code intelligence — execution flows related to a concept |
+| `context`        | 360-degree symbol view — categorized refs, processes it participates in  |
+| `impact`         | Symbol blast radius — what breaks at depth 1/2/3 with confidence         |
+| `detect_changes` | Git-diff impact — what do your current changes affect                    |
+| `rename`         | Multi-file coordinated rename with confidence-tagged edits               |
+| `cypher`         | Raw graph queries (read `gitnexus://repo/{name}/schema` first)           |
+| `list_repos`     | Discover indexed repos                                                   |
+
+## Resources Reference
+
+Lightweight reads (~100-500 tokens) for navigation:
+
+| Resource                                       | Content                                   |
+| ---------------------------------------------- | ----------------------------------------- |
+| `gitnexus://repo/{name}/context`               | Stats, staleness check                    |
+| `gitnexus://repo/{name}/clusters`              | All functional areas with cohesion scores |
+| `gitnexus://repo/{name}/cluster/{clusterName}` | Area members                              |
+| `gitnexus://repo/{name}/processes`             | All execution flows                       |
+| `gitnexus://repo/{name}/process/{processName}` | Step-by-step trace                        |
+| `gitnexus://repo/{name}/schema`                | Graph schema for Cypher                   |
+
+## Graph Schema
+
+**Nodes:** File, Function, Class, Interface, Method, Community, Process
+**Edges (via CodeRelation.type):** CALLS, IMPORTS, EXTENDS, IMPLEMENTS, DEFINES, MEMBER_OF, STEP_IN_PROCESS
+
+```cypher
+MATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: "myFunc"})
+RETURN caller.name, caller.filePath
+```
diff --git a/.claude/skills/gitnexus/gitnexus-impact-analysis/SKILL.md b/.claude/skills/gitnexus/gitnexus-impact-analysis/SKILL.md
new file mode 100644
index 0000000..e19af28
--- /dev/null
+++ b/.claude/skills/gitnexus/gitnexus-impact-analysis/SKILL.md
@@ -0,0 +1,97 @@
+---
+name: gitnexus-impact-analysis
+description: "Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: \"Is it safe to change X?\", \"What depends on this?\", \"What will break?\""
+---
+
+# Impact Analysis with GitNexus
+
+## When to Use
+
+- "Is it safe to change this function?"
+- "What will break if I modify X?"
+- "Show me the blast radius"
+- "Who uses this code?"
+- Before making non-trivial code changes
+- Before committing — to understand what your changes affect
+
+## Workflow
+
+```
+1. gitnexus_impact({target: "X", direction: "upstream"})  → What depends on this
+2. READ gitnexus://repo/{name}/processes                   → Check affected execution flows
+3. gitnexus_detect_changes()                               → Map current git changes to affected flows
+4. Assess risk and report to user
+```
+
+> If "Index is stale" → run `npx gitnexus analyze` in terminal.
+
+## Checklist
+
+```
+- [ ] gitnexus_impact({target, direction: "upstream"}) to find dependents
+- [ ] Review d=1 items first (these WILL BREAK)
+- [ ] Check high-confidence (>0.8) dependencies
+- [ ] READ processes to check affected execution flows
+- [ ] gitnexus_detect_changes() for pre-commit check
+- [ ] Assess risk level and report to user
+```
+
+## Understanding Output
+
+| Depth | Risk Level       | Meaning                  |
+| ----- | ---------------- | ------------------------ |
+| d=1   | **WILL BREAK**   | Direct callers/importers |
+| d=2   | LIKELY AFFECTED  | Indirect dependencies    |
+| d=3   | MAY NEED TESTING | Transitive effects       |
+
+## Risk Assessment
+
+| Affected                       | Risk     |
+| ------------------------------ | -------- |
+| <5 symbols, few processes      | LOW      |
+| 5-15 symbols, 2-5 processes    | MEDIUM   |
+| >15 symbols or many processes  | HIGH     |
+| Critical path (auth, payments) | CRITICAL |
+
+## Tools
+
+**gitnexus_impact** — the primary tool for symbol blast radius:
+
+```
+gitnexus_impact({
+  target: "validateUser",
+  direction: "upstream",
+  minConfidence: 0.8,
+  maxDepth: 3
+})
+
+→ d=1 (WILL BREAK):
+  - loginHandler (src/auth/login.ts:42) [CALLS, 100%]
+  - apiMiddleware (src/api/middleware.ts:15) [CALLS, 100%]
+
+→ d=2 (LIKELY AFFECTED):
+  - authRouter (src/routes/auth.ts:22) [CALLS, 95%]
+```
+
+**gitnexus_detect_changes** — git-diff based impact analysis:
+
+```
+gitnexus_detect_changes({scope: "staged"})
+
+→ Changed: 5 symbols in 3 files
+→ Affected: LoginFlow, TokenRefresh, APIMiddlewarePipeline
+→ Risk: MEDIUM
+```
+
+## Example: "What breaks if I change validateUser?"
+
+```
+1. gitnexus_impact({target: "validateUser", direction: "upstream"})
+   → d=1: loginHandler, apiMiddleware (WILL BREAK)
+   → d=2: authRouter, sessionManager (LIKELY AFFECTED)
+
+2. READ gitnexus://repo/my-app/processes
+   → LoginFlow and TokenRefresh touch validateUser
+
+3. Risk: 2 direct callers, 2 processes = MEDIUM
+```
diff --git a/.claude/skills/gitnexus/gitnexus-refactoring/SKILL.md b/.claude/skills/gitnexus/gitnexus-refactoring/SKILL.md
new file mode 100644
index 0000000..f48cc01
--- /dev/null
+++ b/.claude/skills/gitnexus/gitnexus-refactoring/SKILL.md
@@ -0,0 +1,121 @@
+---
+name: gitnexus-refactoring
+description: "Use when the user wants to rename, extract, split, move, or restructure code safely. Examples: \"Rename this function\", \"Extract this into a module\", \"Refactor this class\", \"Move this to a separate file\""
+---
+
+# Refactoring with GitNexus
+
+## When to Use
+
+- "Rename this function safely"
+- "Extract this into a module"
+- "Split this service"
+- "Move this to a new file"
+- Any task involving renaming, extracting, splitting, or restructuring code
+
+## Workflow
+
+```
+1. gitnexus_impact({target: "X", direction: "upstream"})  → Map all dependents
+2. gitnexus_query({query: "X"})                            → Find execution flows involving X
+3. gitnexus_context({name: "X"})                           → See all incoming/outgoing refs
+4. Plan update order: interfaces → implementations → callers → tests
+```
+
+> If "Index is stale" → run `npx gitnexus analyze` in terminal.
+
+## Checklists
+
+### Rename Symbol
+
+```
+- [ ] gitnexus_rename({symbol_name: "oldName", new_name: "newName", dry_run: true}) — preview all edits
+- [ ] Review graph edits (high confidence) and ast_search edits (review carefully)
+- [ ] If satisfied: gitnexus_rename({..., dry_run: false}) — apply edits
+- [ ] gitnexus_detect_changes() — verify only expected files changed
+- [ ] Run tests for affected processes
+```
+
+### Extract Module
+
+```
+- [ ] gitnexus_context({name: target}) — see all incoming/outgoing refs
+- [ ] gitnexus_impact({target, direction: "upstream"}) — find all external callers
+- [ ] Define new module interface
+- [ ] Extract code, update imports
+- [ ] gitnexus_detect_changes() — verify affected scope
+- [ ] Run tests for affected processes
+```
+
+### Split Function/Service
+
+```
+- [ ] gitnexus_context({name: target}) — understand all callees
+- [ ] Group callees by responsibility
+- [ ] gitnexus_impact({target, direction: "upstream"}) — map callers to update
+- [ ] Create new functions/services
+- [ ] Update callers
+- [ ] gitnexus_detect_changes() — verify affected scope
+- [ ] Run tests for affected processes
+```
+
+## Tools
+
+**gitnexus_rename** — automated multi-file rename:
+
+```
+gitnexus_rename({symbol_name: "validateUser", new_name: "authenticateUser", dry_run: true})
+→ 12 edits across 8 files
+→ 10 graph edits (high confidence), 2 ast_search edits (review)
+→ Changes: [{file_path, edits: [{line, old_text, new_text, confidence}]}]
+```
+
+**gitnexus_impact** — map all dependents first:
+
+```
+gitnexus_impact({target: "validateUser", direction: "upstream"})
+→ d=1: loginHandler, apiMiddleware, testUtils
+→ Affected Processes: LoginFlow, TokenRefresh
+```
+
+**gitnexus_detect_changes** — verify your changes after refactoring:
+
+```
+gitnexus_detect_changes({scope: "all"})
+→ Changed: 8 files, 12 symbols
+→ Affected processes: LoginFlow, TokenRefresh
+→ Risk: MEDIUM
+```
+
+**gitnexus_cypher** — custom reference queries:
+
+```cypher
+MATCH (caller)-[:CodeRelation {type: 'CALLS'}]->(f:Function {name: "validateUser"})
+RETURN caller.name, caller.filePath ORDER BY caller.filePath
+```
+
+## Risk Rules
+
+| Risk Factor         | Mitigation                                |
+| ------------------- | ----------------------------------------- |
+| Many callers (>5)   | Use gitnexus_rename for automated updates |
+| Cross-area refs     | Use detect_changes after to verify scope  |
+| String/dynamic refs | gitnexus_query to find them               |
+| External/public API | Version and deprecate properly            |
+
+## Example: Rename `validateUser` to `authenticateUser`
+
+```
+1. gitnexus_rename({symbol_name: "validateUser", new_name: "authenticateUser", dry_run: true})
+   → 12 edits: 10 graph (safe), 2 ast_search (review)
+   → Files: validator.ts, login.ts, middleware.ts, config.json...
+
+2. Review ast_search edits (config.json: dynamic reference!)
+
+3. gitnexus_rename({symbol_name: "validateUser", new_name: "authenticateUser", dry_run: false})
+   → Applied 12 edits across 8 files
+
+4. gitnexus_detect_changes({scope: "all"})
+   → Affected: LoginFlow, TokenRefresh
+   → Risk: MEDIUM — run tests for these flows
+```
diff --git a/.claude/skills/openspec-apply-change/SKILL.md b/.claude/skills/openspec-apply-change/SKILL.md
new file mode 100644
index 0000000..d474dc1
--- /dev/null
+++ b/.claude/skills/openspec-apply-change/SKILL.md
@@ -0,0 +1,156 @@
+---
+name: openspec-apply-change
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready to archive this change.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.claude/skills/openspec-archive-change/SKILL.md b/.claude/skills/openspec-archive-change/SKILL.md
new file mode 100644
index 0000000..9b1f851
--- /dev/null
+++ b/.claude/skills/openspec-archive-change/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: openspec-archive-change
+description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Whether specs were synced (if applicable)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
+
+All artifacts complete. All tasks complete.
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use openspec-sync-specs approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.claude/skills/openspec-explore/SKILL.md b/.claude/skills/openspec-explore/SKILL.md
new file mode 100644
index 0000000..ffa10ca
--- /dev/null
+++ b/.claude/skills/openspec-explore/SKILL.md
@@ -0,0 +1,288 @@
+---
+name: openspec-explore
+description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Handling Different Entry Points
+
+**User brings a vague idea:**
+```
+User: I'm thinking about adding real-time collaboration
+
+You: Real-time collab is a big space. Let me think about this...
+
+      COLLABORATION SPECTRUM
+      ════════════════════════════════════════════
+
+      Awareness          Coordination         Sync
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │Presence│         │Cursors │        │  CRDT  │
+      │  "3    │         │ Multi  │        │Conflict│
+      │online" │         │ select │        │  free  │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+       trivial            moderate           complex
+
+      Where's your head at?
+```
+
+**User brings a specific problem:**
+```
+User: The auth system is a mess
+
+You: [reads codebase]
+
+     ┌─────────────────────────────────────────────┐
+     │              CURRENT AUTH FLOW              │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Session  │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     I see three tangles. Which one's burning?
+```
+
+**User is stuck mid-implementation:**
+```
+User: /opsx:explore add-auth-system
+      The OAuth integration is more complex than expected
+
+You: [reads change artifacts]
+
+     You're on task 4: "Implement OAuth flow"
+
+     Let me trace what's involved...
+
+     [draws diagram, explores options, suggests paths]
+
+     Want to update the design to reflect this?
+     Or add a spike task to investigate?
+```
+
+**User wants to compare options:**
+```
+User: Should we use Postgres or SQLite?
+
+You: Generic answer is boring. What's the context?
+
+User: A CLI tool that tracks local dev environments
+
+You: That changes everything.
+
+     ┌─────────────────────────────────────────────────┐
+     │         CLI TOOL DATA STORAGE                  │
+     └─────────────────────────────────────────────────┘
+
+     Key constraints:
+     • No daemon running
+     • Must work offline
+     • Single user
+
+                  SQLite          Postgres
+     Deployment   embedded ✓      needs server ✗
+     Offline      yes ✓           no ✗
+     Single file  yes ✓           no ✗
+
+     SQLite. Not even close.
+
+     Unless... is there a sync component?
+```
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When it feels like things are crystallizing, you might summarize:
+
+```
+## What We Figured Out
+
+**The problem**: [crystallized understanding]
+
+**The approach**: [if one emerged]
+
+**Open questions**: [if any remain]
+
+**Next steps** (if ready):
+- Create a change proposal
+- Keep exploring: just keep talking
+```
+
+But this summary is optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.claude/skills/openspec-propose/SKILL.md b/.claude/skills/openspec-propose/SKILL.md
new file mode 100644
index 0000000..d27bc53
--- /dev/null
+++ b/.claude/skills/openspec-propose/SKILL.md
@@ -0,0 +1,110 @@
+---
+name: openspec-propose
+description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.codex/skills/openspec-apply-change/SKILL.md b/.codex/skills/openspec-apply-change/SKILL.md
new file mode 100644
index 0000000..d474dc1
--- /dev/null
+++ b/.codex/skills/openspec-apply-change/SKILL.md
@@ -0,0 +1,156 @@
+---
+name: openspec-apply-change
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready to archive this change.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.codex/skills/openspec-archive-change/SKILL.md b/.codex/skills/openspec-archive-change/SKILL.md
new file mode 100644
index 0000000..9b1f851
--- /dev/null
+++ b/.codex/skills/openspec-archive-change/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: openspec-archive-change
+description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Whether specs were synced (if applicable)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
+
+All artifacts complete. All tasks complete.
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use openspec-sync-specs approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.codex/skills/openspec-explore/SKILL.md b/.codex/skills/openspec-explore/SKILL.md
new file mode 100644
index 0000000..ffa10ca
--- /dev/null
+++ b/.codex/skills/openspec-explore/SKILL.md
@@ -0,0 +1,288 @@
+---
+name: openspec-explore
+description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Handling Different Entry Points
+
+**User brings a vague idea:**
+```
+User: I'm thinking about adding real-time collaboration
+
+You: Real-time collab is a big space. Let me think about this...
+
+      COLLABORATION SPECTRUM
+      ════════════════════════════════════════════
+
+      Awareness          Coordination         Sync
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │Presence│         │Cursors │        │  CRDT  │
+      │  "3    │         │ Multi  │        │Conflict│
+      │online" │         │ select │        │  free  │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+       trivial            moderate           complex
+
+      Where's your head at?
+```
+
+**User brings a specific problem:**
+```
+User: The auth system is a mess
+
+You: [reads codebase]
+
+     ┌─────────────────────────────────────────────┐
+     │              CURRENT AUTH FLOW              │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Session  │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     I see three tangles. Which one's burning?
+```
+
+**User is stuck mid-implementation:**
+```
+User: /opsx:explore add-auth-system
+      The OAuth integration is more complex than expected
+
+You: [reads change artifacts]
+
+     You're on task 4: "Implement OAuth flow"
+
+     Let me trace what's involved...
+
+     [draws diagram, explores options, suggests paths]
+
+     Want to update the design to reflect this?
+     Or add a spike task to investigate?
+```
+
+**User wants to compare options:**
+```
+User: Should we use Postgres or SQLite?
+
+You: Generic answer is boring. What's the context?
+
+User: A CLI tool that tracks local dev environments
+
+You: That changes everything.
+
+     ┌─────────────────────────────────────────────────┐
+     │         CLI TOOL DATA STORAGE                  │
+     └─────────────────────────────────────────────────┘
+
+     Key constraints:
+     • No daemon running
+     • Must work offline
+     • Single user
+
+                  SQLite          Postgres
+     Deployment   embedded ✓      needs server ✗
+     Offline      yes ✓           no ✗
+     Single file  yes ✓           no ✗
+
+     SQLite. Not even close.
+
+     Unless... is there a sync component?
+```
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When it feels like things are crystallizing, you might summarize:
+
+```
+## What We Figured Out
+
+**The problem**: [crystallized understanding]
+
+**The approach**: [if one emerged]
+
+**Open questions**: [if any remain]
+
+**Next steps** (if ready):
+- Create a change proposal
+- Keep exploring: just keep talking
+```
+
+But this summary is optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.codex/skills/openspec-propose/SKILL.md b/.codex/skills/openspec-propose/SKILL.md
new file mode 100644
index 0000000..d27bc53
--- /dev/null
+++ b/.codex/skills/openspec-propose/SKILL.md
@@ -0,0 +1,110 @@
+---
+name: openspec-propose
+description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.crush/commands/opsx/apply.md b/.crush/commands/opsx/apply.md
new file mode 100644
index 0000000..e385b1e
--- /dev/null
+++ b/.crush/commands/opsx/apply.md
@@ -0,0 +1,152 @@
+---
+name: OPSX: Apply
+description: Implement tasks from an OpenSpec change (Experimental)
+category: Workflow
+tags: [workflow, artifacts, experimental]
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! You can archive this change with `/opsx:archive`.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.crush/commands/opsx/archive.md b/.crush/commands/opsx/archive.md
new file mode 100644
index 0000000..a0f63f1
--- /dev/null
+++ b/.crush/commands/opsx/archive.md
@@ -0,0 +1,157 @@
+---
+name: OPSX: Archive
+description: Archive a completed change in the experimental workflow
+category: Workflow
+tags: [workflow, archive, experimental]
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Spec sync status (synced / sync skipped / no delta specs)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success (No Delta Specs)**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** No delta specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success With Warnings**
+
+```
+## Archive Complete (with warnings)
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** Sync skipped (user chose to skip)
+
+**Warnings:**
+- Archived with 2 incomplete artifacts
+- Archived with 3 incomplete tasks
+- Delta spec sync was skipped (user chose to skip)
+
+Review the archive if this was not intentional.
+```
+
+**Output On Error (Archive Exists)**
+
+```
+## Archive Failed
+
+**Change:** <change-name>
+**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+
+Target archive directory already exists.
+
+**Options:**
+1. Rename the existing archive
+2. Delete the existing archive if it's a duplicate
+3. Wait until a different date to archive
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.crush/commands/opsx/explore.md b/.crush/commands/opsx/explore.md
new file mode 100644
index 0000000..9c55939
--- /dev/null
+++ b/.crush/commands/opsx/explore.md
@@ -0,0 +1,173 @@
+---
+name: OPSX: Explore
+description: Enter explore mode - think through ideas, investigate problems, clarify requirements
+category: Workflow
+tags: [workflow, explore, experimental, thinking]
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
+- A vague idea: "real-time collaboration"
+- A specific problem: "the auth system is getting unwieldy"
+- A change name: "add-dark-mode" (to explore in context of that change)
+- A comparison: "postgres vs sqlite for this"
+- Nothing (just enter explore mode)
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+If the user mentioned a specific change name, read its artifacts for context.
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.crush/commands/opsx/propose.md b/.crush/commands/opsx/propose.md
new file mode 100644
index 0000000..2a1a88a
--- /dev/null
+++ b/.crush/commands/opsx/propose.md
@@ -0,0 +1,106 @@
+---
+name: OPSX: Propose
+description: Propose a new change - create it and generate all artifacts in one step
+category: Workflow
+tags: [workflow, artifacts, experimental]
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+1. **If no input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` to start implementing."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.crush/skills/openspec-apply-change/SKILL.md b/.crush/skills/openspec-apply-change/SKILL.md
new file mode 100644
index 0000000..d474dc1
--- /dev/null
+++ b/.crush/skills/openspec-apply-change/SKILL.md
@@ -0,0 +1,156 @@
+---
+name: openspec-apply-change
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready to archive this change.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.crush/skills/openspec-archive-change/SKILL.md b/.crush/skills/openspec-archive-change/SKILL.md
new file mode 100644
index 0000000..9b1f851
--- /dev/null
+++ b/.crush/skills/openspec-archive-change/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: openspec-archive-change
+description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Whether specs were synced (if applicable)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
+
+All artifacts complete. All tasks complete.
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use openspec-sync-specs approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.crush/skills/openspec-explore/SKILL.md b/.crush/skills/openspec-explore/SKILL.md
new file mode 100644
index 0000000..ffa10ca
--- /dev/null
+++ b/.crush/skills/openspec-explore/SKILL.md
@@ -0,0 +1,288 @@
+---
+name: openspec-explore
+description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Handling Different Entry Points
+
+**User brings a vague idea:**
+```
+User: I'm thinking about adding real-time collaboration
+
+You: Real-time collab is a big space. Let me think about this...
+
+      COLLABORATION SPECTRUM
+      ════════════════════════════════════════════
+
+      Awareness          Coordination         Sync
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │Presence│         │Cursors │        │  CRDT  │
+      │  "3    │         │ Multi  │        │Conflict│
+      │online" │         │ select │        │  free  │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+       trivial            moderate           complex
+
+      Where's your head at?
+```
+
+**User brings a specific problem:**
+```
+User: The auth system is a mess
+
+You: [reads codebase]
+
+     ┌─────────────────────────────────────────────┐
+     │              CURRENT AUTH FLOW              │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Session  │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     I see three tangles. Which one's burning?
+```
+
+**User is stuck mid-implementation:**
+```
+User: /opsx:explore add-auth-system
+      The OAuth integration is more complex than expected
+
+You: [reads change artifacts]
+
+     You're on task 4: "Implement OAuth flow"
+
+     Let me trace what's involved...
+
+     [draws diagram, explores options, suggests paths]
+
+     Want to update the design to reflect this?
+     Or add a spike task to investigate?
+```
+
+**User wants to compare options:**
+```
+User: Should we use Postgres or SQLite?
+
+You: Generic answer is boring. What's the context?
+
+User: A CLI tool that tracks local dev environments
+
+You: That changes everything.
+
+     ┌─────────────────────────────────────────────────┐
+     │         CLI TOOL DATA STORAGE                  │
+     └─────────────────────────────────────────────────┘
+
+     Key constraints:
+     • No daemon running
+     • Must work offline
+     • Single user
+
+                  SQLite          Postgres
+     Deployment   embedded ✓      needs server ✗
+     Offline      yes ✓           no ✗
+     Single file  yes ✓           no ✗
+
+     SQLite. Not even close.
+
+     Unless... is there a sync component?
+```
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When it feels like things are crystallizing, you might summarize:
+
+```
+## What We Figured Out
+
+**The problem**: [crystallized understanding]
+
+**The approach**: [if one emerged]
+
+**Open questions**: [if any remain]
+
+**Next steps** (if ready):
+- Create a change proposal
+- Keep exploring: just keep talking
+```
+
+But this summary is optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.crush/skills/openspec-propose/SKILL.md b/.crush/skills/openspec-propose/SKILL.md
new file mode 100644
index 0000000..d27bc53
--- /dev/null
+++ b/.crush/skills/openspec-propose/SKILL.md
@@ -0,0 +1,110 @@
+---
+name: openspec-propose
+description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.env.example b/.env.example
index 0ec0843..72815f3 100644
--- a/.env.example
+++ b/.env.example
@@ -1,6 +1,9 @@
 # API Key Authentication (Recommended for testing)
+# Set either LINEAR_API_KEY or LINEAR_ACCESS_TOKEN.
+# If both are set, LINEAR_API_KEY takes precedence.
 # See README.md for instructions on key generation
 LINEAR_API_KEY=your_api_key
+# LINEAR_ACCESS_TOKEN=your_api_key
 
 # OAuth Authentication (Optional)
 # Only needed if using OAuth flow instead of API Key
diff --git a/.github/prompts/opsx-apply.prompt.md b/.github/prompts/opsx-apply.prompt.md
new file mode 100644
index 0000000..494e10e
--- /dev/null
+++ b/.github/prompts/opsx-apply.prompt.md
@@ -0,0 +1,149 @@
+---
+description: Implement tasks from an OpenSpec change (Experimental)
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue`
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! You can archive this change with `/opsx:archive`.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.github/prompts/opsx-archive.prompt.md b/.github/prompts/opsx-archive.prompt.md
new file mode 100644
index 0000000..1163776
--- /dev/null
+++ b/.github/prompts/opsx-archive.prompt.md
@@ -0,0 +1,154 @@
+---
+description: Archive a completed change in the experimental workflow
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name after `/opsx:archive` (e.g., `/opsx:archive add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Prompt user for confirmation to continue
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Spec sync status (synced / sync skipped / no delta specs)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success (No Delta Specs)**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** No delta specs
+
+All artifacts complete. All tasks complete.
+```
+
+**Output On Success With Warnings**
+
+```
+## Archive Complete (with warnings)
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** Sync skipped (user chose to skip)
+
+**Warnings:**
+- Archived with 2 incomplete artifacts
+- Archived with 3 incomplete tasks
+- Delta spec sync was skipped (user chose to skip)
+
+Review the archive if this was not intentional.
+```
+
+**Output On Error (Archive Exists)**
+
+```
+## Archive Failed
+
+**Change:** <change-name>
+**Target:** openspec/changes/archive/YYYY-MM-DD-<name>/
+
+Target archive directory already exists.
+
+**Options:**
+1. Rename the existing archive
+2. Delete the existing archive if it's a duplicate
+3. Wait until a different date to archive
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use the Skill tool to invoke `openspec-sync-specs` (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.github/prompts/opsx-explore.prompt.md b/.github/prompts/opsx-explore.prompt.md
new file mode 100644
index 0000000..b21a226
--- /dev/null
+++ b/.github/prompts/opsx-explore.prompt.md
@@ -0,0 +1,170 @@
+---
+description: Enter explore mode - think through ideas, investigate problems, clarify requirements
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+**Input**: The argument after `/opsx:explore` is whatever the user wants to think about. Could be:
+- A vague idea: "real-time collaboration"
+- A specific problem: "the auth system is getting unwieldy"
+- A change name: "add-dark-mode" (to explore in context of that change)
+- A comparison: "postgres vs sqlite for this"
+- Nothing (just enter explore mode)
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+If the user mentioned a specific change name, read its artifacts for context.
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.github/prompts/opsx-propose.prompt.md b/.github/prompts/opsx-propose.prompt.md
new file mode 100644
index 0000000..cf30b2a
--- /dev/null
+++ b/.github/prompts/opsx-propose.prompt.md
@@ -0,0 +1,103 @@
+---
+description: Propose a new change - create it and generate all artifacts in one step
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The argument after `/opsx:propose` is the change name (kebab-case), OR a description of what the user wants to build.
+
+**Steps**
+
+1. **If no input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` to start implementing."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.github/skills/openspec-apply-change/SKILL.md b/.github/skills/openspec-apply-change/SKILL.md
new file mode 100644
index 0000000..d474dc1
--- /dev/null
+++ b/.github/skills/openspec-apply-change/SKILL.md
@@ -0,0 +1,156 @@
+---
+name: openspec-apply-change
+description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Implement tasks from an OpenSpec change.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **Select the change**
+
+   If a name is provided, use it. Otherwise:
+   - Infer from conversation context if the user mentioned a change
+   - Auto-select if only one active change exists
+   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
+
+   Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`).
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
+
+3. **Get apply instructions**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns:
+   - Context file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
+   - Progress (total, complete, remaining)
+   - Task list with status
+   - Dynamic instruction based on current state
+
+   **Handle states:**
+   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
+   - If `state: "all_done"`: congratulate, suggest archive
+   - Otherwise: proceed to implementation
+
+4. **Read context files**
+
+   Read the files listed in `contextFiles` from the apply instructions output.
+   The files depend on the schema being used:
+   - **spec-driven**: proposal, specs, design, tasks
+   - Other schemas: follow the contextFiles from CLI output
+
+5. **Show current progress**
+
+   Display:
+   - Schema being used
+   - Progress: "N/M tasks complete"
+   - Remaining tasks overview
+   - Dynamic instruction from CLI
+
+6. **Implement tasks (loop until done or blocked)**
+
+   For each pending task:
+   - Show which task is being worked on
+   - Make the code changes required
+   - Keep changes minimal and focused
+   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
+   - Continue to next task
+
+   **Pause if:**
+   - Task is unclear → ask for clarification
+   - Implementation reveals a design issue → suggest updating artifacts
+   - Error or blocker encountered → report and wait for guidance
+   - User interrupts
+
+7. **On completion or pause, show status**
+
+   Display:
+   - Tasks completed this session
+   - Overall progress: "N/M tasks complete"
+   - If all done: suggest archive
+   - If paused: explain why and wait for guidance
+
+**Output During Implementation**
+
+```
+## Implementing: <change-name> (schema: <schema-name>)
+
+Working on task 3/7: <task description>
+[...implementation happening...]
+✓ Task complete
+
+Working on task 4/7: <task description>
+[...implementation happening...]
+✓ Task complete
+```
+
+**Output On Completion**
+
+```
+## Implementation Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 7/7 tasks complete ✓
+
+### Completed This Session
+- [x] Task 1
+- [x] Task 2
+...
+
+All tasks complete! Ready to archive this change.
+```
+
+**Output On Pause (Issue Encountered)**
+
+```
+## Implementation Paused
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Progress:** 4/7 tasks complete
+
+### Issue Encountered
+<description of the issue>
+
+**Options:**
+1. <option 1>
+2. <option 2>
+3. Other approach
+
+What would you like to do?
+```
+
+**Guardrails**
+- Keep going through tasks until done or blocked
+- Always read context files before starting (from the apply instructions output)
+- If task is ambiguous, pause and ask before implementing
+- If implementation reveals issues, pause and suggest artifact updates
+- Keep code changes minimal and scoped to each task
+- Update task checkbox immediately after completing each task
+- Pause on errors, blockers, or unclear requirements - don't guess
+- Use contextFiles from CLI output, don't assume specific file names
+
+**Fluid Workflow Integration**
+
+This skill supports the "actions on a change" model:
+
+- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
+- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
diff --git a/.github/skills/openspec-archive-change/SKILL.md b/.github/skills/openspec-archive-change/SKILL.md
new file mode 100644
index 0000000..9b1f851
--- /dev/null
+++ b/.github/skills/openspec-archive-change/SKILL.md
@@ -0,0 +1,114 @@
+---
+name: openspec-archive-change
+description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Archive a completed change in the experimental workflow.
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show only active changes (not already archived).
+   Include the schema used for each change if available.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check artifact completion status**
+
+   Run `openspec status --change "<name>" --json` to check artifact completion.
+
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used
+   - `artifacts`: List of artifacts with their status (`done` or other)
+
+   **If any artifacts are not `done`:**
+   - Display warning listing incomplete artifacts
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+3. **Check task completion status**
+
+   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
+
+   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
+
+   **If incomplete tasks found:**
+   - Display warning showing count of incomplete tasks
+   - Use **AskUserQuestion tool** to confirm user wants to proceed
+   - Proceed if user confirms
+
+   **If no tasks file exists:** Proceed without task-related warning.
+
+4. **Assess delta spec sync state**
+
+   Check for delta specs at `openspec/changes/<name>/specs/`. If none exist, proceed without sync prompt.
+
+   **If delta specs exist:**
+   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
+   - Determine what changes would be applied (adds, modifications, removals, renames)
+   - Show a combined summary before prompting
+
+   **Prompt options:**
+   - If changes needed: "Sync now (recommended)", "Archive without syncing"
+   - If already synced: "Archive now", "Sync anyway", "Cancel"
+
+   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
+
+5. **Perform the archive**
+
+   Create the archive directory if it doesn't exist:
+   ```bash
+   mkdir -p openspec/changes/archive
+   ```
+
+   Generate target name using current date: `YYYY-MM-DD-<change-name>`
+
+   **Check if target already exists:**
+   - If yes: Fail with error, suggest renaming existing archive or using different date
+   - If no: Move the change directory to archive
+
+   ```bash
+   mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
+   ```
+
+6. **Display summary**
+
+   Show archive completion summary including:
+   - Change name
+   - Schema that was used
+   - Archive location
+   - Whether specs were synced (if applicable)
+   - Note about any warnings (incomplete artifacts/tasks)
+
+**Output On Success**
+
+```
+## Archive Complete
+
+**Change:** <change-name>
+**Schema:** <schema-name>
+**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
+**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
+
+All artifacts complete. All tasks complete.
+```
+
+**Guardrails**
+- Always prompt for change selection if not provided
+- Use artifact graph (openspec status --json) for completion checking
+- Don't block archive on warnings - just inform and confirm
+- Preserve .openspec.yaml when moving to archive (it moves with the directory)
+- Show clear summary of what happened
+- If sync is requested, use openspec-sync-specs approach (agent-driven)
+- If delta specs exist, always run the sync assessment and show the combined summary before prompting
diff --git a/.github/skills/openspec-explore/SKILL.md b/.github/skills/openspec-explore/SKILL.md
new file mode 100644
index 0000000..ffa10ca
--- /dev/null
+++ b/.github/skills/openspec-explore/SKILL.md
@@ -0,0 +1,288 @@
+---
+name: openspec-explore
+description: Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
+
+**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
+
+**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
+
+---
+
+## The Stance
+
+- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
+- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
+- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
+- **Adaptive** - Follow interesting threads, pivot when new information emerges
+- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
+- **Grounded** - Explore the actual codebase when relevant, don't just theorize
+
+---
+
+## What You Might Do
+
+Depending on what the user brings, you might:
+
+**Explore the problem space**
+- Ask clarifying questions that emerge from what they said
+- Challenge assumptions
+- Reframe the problem
+- Find analogies
+
+**Investigate the codebase**
+- Map existing architecture relevant to the discussion
+- Find integration points
+- Identify patterns already in use
+- Surface hidden complexity
+
+**Compare options**
+- Brainstorm multiple approaches
+- Build comparison tables
+- Sketch tradeoffs
+- Recommend a path (if asked)
+
+**Visualize**
+```
+┌─────────────────────────────────────────┐
+│     Use ASCII diagrams liberally        │
+├─────────────────────────────────────────┤
+│                                         │
+│   ┌────────┐         ┌────────┐        │
+│   │ State  │────────▶│ State  │        │
+│   │   A    │         │   B    │        │
+│   └────────┘         └────────┘        │
+│                                         │
+│   System diagrams, state machines,      │
+│   data flows, architecture sketches,    │
+│   dependency graphs, comparison tables  │
+│                                         │
+└─────────────────────────────────────────┘
+```
+
+**Surface risks and unknowns**
+- Identify what could go wrong
+- Find gaps in understanding
+- Suggest spikes or investigations
+
+---
+
+## OpenSpec Awareness
+
+You have full context of the OpenSpec system. Use it naturally, don't force it.
+
+### Check for context
+
+At the start, quickly check what exists:
+```bash
+openspec list --json
+```
+
+This tells you:
+- If there are active changes
+- Their names, schemas, and status
+- What the user might be working on
+
+### When no change exists
+
+Think freely. When insights crystallize, you might offer:
+
+- "This feels solid enough to start a change. Want me to create a proposal?"
+- Or keep exploring - no pressure to formalize
+
+### When a change exists
+
+If the user mentions a change or you detect one is relevant:
+
+1. **Read existing artifacts for context**
+   - `openspec/changes/<name>/proposal.md`
+   - `openspec/changes/<name>/design.md`
+   - `openspec/changes/<name>/tasks.md`
+   - etc.
+
+2. **Reference them naturally in conversation**
+   - "Your design mentions using Redis, but we just realized SQLite fits better..."
+   - "The proposal scopes this to premium users, but we're now thinking everyone..."
+
+3. **Offer to capture when decisions are made**
+
+   | Insight Type | Where to Capture |
+   |--------------|------------------|
+   | New requirement discovered | `specs/<capability>/spec.md` |
+   | Requirement changed | `specs/<capability>/spec.md` |
+   | Design decision made | `design.md` |
+   | Scope changed | `proposal.md` |
+   | New work identified | `tasks.md` |
+   | Assumption invalidated | Relevant artifact |
+
+   Example offers:
+   - "That's a design decision. Capture it in design.md?"
+   - "This is a new requirement. Add it to specs?"
+   - "This changes scope. Update the proposal?"
+
+4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
+
+---
+
+## What You Don't Have To Do
+
+- Follow a script
+- Ask the same questions every time
+- Produce a specific artifact
+- Reach a conclusion
+- Stay on topic if a tangent is valuable
+- Be brief (this is thinking time)
+
+---
+
+## Handling Different Entry Points
+
+**User brings a vague idea:**
+```
+User: I'm thinking about adding real-time collaboration
+
+You: Real-time collab is a big space. Let me think about this...
+
+      COLLABORATION SPECTRUM
+      ════════════════════════════════════════════
+
+      Awareness          Coordination         Sync
+          │                   │                 │
+          ▼                   ▼                 ▼
+      ┌────────┐         ┌────────┐        ┌────────┐
+      │Presence│         │Cursors │        │  CRDT  │
+      │  "3    │         │ Multi  │        │Conflict│
+      │online" │         │ select │        │  free  │
+      └────────┘         └────────┘        └────────┘
+          │                   │                 │
+       trivial            moderate           complex
+
+      Where's your head at?
+```
+
+**User brings a specific problem:**
+```
+User: The auth system is a mess
+
+You: [reads codebase]
+
+     ┌─────────────────────────────────────────────┐
+     │              CURRENT AUTH FLOW              │
+     └─────────────────────────────────────────────┘
+                        │
+          ┌─────────────┼─────────────┐
+          ▼             ▼             ▼
+     ┌─────────┐  ┌─────────┐  ┌─────────┐
+     │ Google  │  │  GitHub │  │  Email  │
+     │  OAuth  │  │  OAuth  │  │  Magic  │
+     └────┬────┘  └────┬────┘  └────┬────┘
+          │             │             │
+          └─────────────┼─────────────┘
+                        ▼
+                  ┌───────────┐
+                  │  Session  │
+                  └─────┬─────┘
+                        │
+                        ▼
+                  ┌───────────┐
+                  │   Perms   │
+                  └───────────┘
+
+     I see three tangles. Which one's burning?
+```
+
+**User is stuck mid-implementation:**
+```
+User: /opsx:explore add-auth-system
+      The OAuth integration is more complex than expected
+
+You: [reads change artifacts]
+
+     You're on task 4: "Implement OAuth flow"
+
+     Let me trace what's involved...
+
+     [draws diagram, explores options, suggests paths]
+
+     Want to update the design to reflect this?
+     Or add a spike task to investigate?
+```
+
+**User wants to compare options:**
+```
+User: Should we use Postgres or SQLite?
+
+You: Generic answer is boring. What's the context?
+
+User: A CLI tool that tracks local dev environments
+
+You: That changes everything.
+
+     ┌─────────────────────────────────────────────────┐
+     │         CLI TOOL DATA STORAGE                  │
+     └─────────────────────────────────────────────────┘
+
+     Key constraints:
+     • No daemon running
+     • Must work offline
+     • Single user
+
+                  SQLite          Postgres
+     Deployment   embedded ✓      needs server ✗
+     Offline      yes ✓           no ✗
+     Single file  yes ✓           no ✗
+
+     SQLite. Not even close.
+
+     Unless... is there a sync component?
+```
+
+---
+
+## Ending Discovery
+
+There's no required ending. Discovery might:
+
+- **Flow into a proposal**: "Ready to start? I can create a change proposal."
+- **Result in artifact updates**: "Updated design.md with these decisions"
+- **Just provide clarity**: User has what they need, moves on
+- **Continue later**: "We can pick this up anytime"
+
+When it feels like things are crystallizing, you might summarize:
+
+```
+## What We Figured Out
+
+**The problem**: [crystallized understanding]
+
+**The approach**: [if one emerged]
+
+**Open questions**: [if any remain]
+
+**Next steps** (if ready):
+- Create a change proposal
+- Keep exploring: just keep talking
+```
+
+But this summary is optional. Sometimes the thinking IS the value.
+
+---
+
+## Guardrails
+
+- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
+- **Don't fake understanding** - If something is unclear, dig deeper
+- **Don't rush** - Discovery is thinking time, not task time
+- **Don't force structure** - Let patterns emerge naturally
+- **Don't auto-capture** - Offer to save insights, don't just do it
+- **Do visualize** - A good diagram is worth many paragraphs
+- **Do explore the codebase** - Ground discussions in reality
+- **Do question assumptions** - Including the user's and your own
diff --git a/.github/skills/openspec-propose/SKILL.md b/.github/skills/openspec-propose/SKILL.md
new file mode 100644
index 0000000..d27bc53
--- /dev/null
+++ b/.github/skills/openspec-propose/SKILL.md
@@ -0,0 +1,110 @@
+---
+name: openspec-propose
+description: Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.2.0"
+---
+
+Propose a new change - create the change and generate all artifacts in one step.
+
+I'll create a change with artifacts:
+- proposal.md (what & why)
+- design.md (how)
+- tasks.md (implementation steps)
+
+When ready to implement, run /opsx:apply
+
+---
+
+**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
+
+**Steps**
+
+1. **If no clear input provided, ask what they want to build**
+
+   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
+   > "What change do you want to work on? Describe what you want to build or fix."
+
+   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
+
+   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
+
+2. **Create the change directory**
+   ```bash
+   openspec new change "<name>"
+   ```
+   This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
+
+3. **Get the artifact build order**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to get:
+   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
+   - `artifacts`: list of all artifacts with their status and dependencies
+
+4. **Create artifacts in sequence until apply-ready**
+
+   Use the **TodoWrite tool** to track progress through the artifacts.
+
+   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
+
+   a. **For each artifact that is `ready` (dependencies satisfied)**:
+      - Get instructions:
+        ```bash
+        openspec instructions <artifact-id> --change "<name>" --json
+        ```
+      - The instructions JSON includes:
+        - `context`: Project background (constraints for you - do NOT include in output)
+        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
+        - `template`: The structure to use for your output file
+        - `instruction`: Schema-specific guidance for this artifact type
+        - `outputPath`: Where to write the artifact
+        - `dependencies`: Completed artifacts to read for context
+      - Read any completed dependency files for context
+      - Create the artifact file using `template` as the structure
+      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
+      - Show brief progress: "Created <artifact-id>"
+
+   b. **Continue until all `applyRequires` artifacts are complete**
+      - After creating each artifact, re-run `openspec status --change "<name>" --json`
+      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
+      - Stop when all `applyRequires` artifacts are done
+
+   c. **If an artifact requires user input** (unclear context):
+      - Use **AskUserQuestion tool** to clarify
+      - Then continue with creation
+
+5. **Show final status**
+   ```bash
+   openspec status --change "<name>"
+   ```
+
+**Output**
+
+After completing all artifacts, summarize:
+- Change name and location
+- List of artifacts created with brief descriptions
+- What's ready: "All artifacts created! Ready for implementation."
+- Prompt: "Run `/opsx:apply` or ask me to implement to start working on the tasks."
+
+**Artifact Creation Guidelines**
+
+- Follow the `instruction` field from `openspec instructions` for each artifact type
+- The schema defines what each artifact should contain - follow it
+- Read dependency artifacts for context before creating new ones
+- Use `template` as the structure for your output file - fill in its sections
+- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
+  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
+  - These guide what you write, but should never appear in the output
+
+**Guardrails**
+- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
+- Always read dependency artifacts before creating a new one
+- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
+- If a change with that name already exists, ask if user wants to continue it or create a new one
+- Verify each artifact file exists after writing before proceeding to next
diff --git a/.gitignore b/.gitignore
index 6a90281..38f82f3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -30,3 +30,5 @@ Thumbs.db
 
 # Test coverage
 coverage/
+.gitnexus
+.aider*
diff --git a/AGENT.md b/AGENT.md
new file mode 100644
index 0000000..df7c390
--- /dev/null
+++ b/AGENT.md
@@ -0,0 +1,35 @@
+# Linear MCP — Agent Guide
+
+This is the generic agent-facing snapshot for the current MCP server. The fuller repo-specific guidance lives in `CLAUDE.md`.
+
+## Current state
+
+- Default runtime is **stdio**. Set `LINEAR_MCP_TRANSPORT=stream` to expose MCP streamable HTTP at `LINEAR_MCP_PATH` (default `/mcp`). `/sse` is intentionally unsupported.
+- Auth supports both `LINEAR_API_KEY` and the tool-driven OAuth flow through `linear_auth` and `linear_auth_callback`. OAuth callback state is single-use.
+- `linear_search_issues` is query-backed and keeps free-text `query` separate from optional list-style filters.
+- The built and packaged server is validated through `npm run verify:release`.
+
+## Main commands
+
+- `npm run build`
+- `npm test`
+- `npm run verify:tool-catalog`
+- `npm run verify:package-install`
+- `npm run verify:release`
+
+## Important code paths
+
+- `src/index.ts` — stdio vs streamable HTTP runtime bootstrap
+- `src/core/capabilities.ts` — runtime capability metadata
+- `src/core/handlers/handler.factory.ts` — tool-to-handler routing
+- `src/core/types/tool.types.ts` — MCP tool schemas
+- `src/graphql/client.ts` — shared SDK/GraphQL boundary, including query-backed issue search
+- `src/features/issues/handlers/issue.handler.ts` — issue list/search/update behavior
+
+## Working conventions
+
+- Do not edit `build/`.
+- ESM imports in TS source must use `.js` extensions.
+- Keep `linear_list_issues` filter-based and `linear_search_issues` query-based.
+- Keep runtime-gated subscription tools aligned with capability metadata.
+- If the tool surface changes, update the schemas, handler routing, `README.md`, and release verification together.
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000..cf4ddd4
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,101 @@
+<!-- gitnexus:start -->
+# GitNexus — Code Intelligence
+
+This project is indexed by GitNexus as **linear-mcp** (899 symbols, 2670 relationships, 67 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.
+
+> If any GitNexus tool warns the index is stale, run `npx gitnexus analyze` in terminal first.
+
+## Always Do
+
+- **MUST run impact analysis before editing any symbol.** Before modifying a function, class, or method, run `gitnexus_impact({target: "symbolName", direction: "upstream"})` and report the blast radius (direct callers, affected processes, risk level) to the user.
+- **MUST run `gitnexus_detect_changes()` before committing** to verify your changes only affect expected symbols and execution flows.
+- **MUST warn the user** if impact analysis returns HIGH or CRITICAL risk before proceeding with edits.
+- When exploring unfamiliar code, use `gitnexus_query({query: "concept"})` to find execution flows instead of grepping. It returns process-grouped results ranked by relevance.
+- When you need full context on a specific symbol — callers, callees, which execution flows it participates in — use `gitnexus_context({name: "symbolName"})`.
+
+## When Debugging
+
+1. `gitnexus_query({query: "<error or symptom>"})` — find execution flows related to the issue
+2. `gitnexus_context({name: "<suspect function>"})` — see all callers, callees, and process participation
+3. `READ gitnexus://repo/linear-mcp/process/{processName}` — trace the full execution flow step by step
+4. For regressions: `gitnexus_detect_changes({scope: "compare", base_ref: "main"})` — see what your branch changed
+
+## When Refactoring
+
+- **Renaming**: MUST use `gitnexus_rename({symbol_name: "old", new_name: "new", dry_run: true})` first. Review the preview — graph edits are safe, text_search edits need manual review. Then run with `dry_run: false`.
+- **Extracting/Splitting**: MUST run `gitnexus_context({name: "target"})` to see all incoming/outgoing refs, then `gitnexus_impact({target: "target", direction: "upstream"})` to find all external callers before moving code.
+- After any refactor: run `gitnexus_detect_changes({scope: "all"})` to verify only expected files changed.
+
+## Never Do
+
+- NEVER edit a function, class, or method without first running `gitnexus_impact` on it.
+- NEVER ignore HIGH or CRITICAL risk warnings from impact analysis.
+- NEVER rename symbols with find-and-replace — use `gitnexus_rename` which understands the call graph.
+- NEVER commit changes without running `gitnexus_detect_changes()` to check affected scope.
+
+## Tools Quick Reference
+
+| Tool | When to use | Command |
+|------|-------------|---------|
+| `query` | Find code by concept | `gitnexus_query({query: "auth validation"})` |
+| `context` | 360-degree view of one symbol | `gitnexus_context({name: "validateUser"})` |
+| `impact` | Blast radius before editing | `gitnexus_impact({target: "X", direction: "upstream"})` |
+| `detect_changes` | Pre-commit scope check | `gitnexus_detect_changes({scope: "staged"})` |
+| `rename` | Safe multi-file rename | `gitnexus_rename({symbol_name: "old", new_name: "new", dry_run: true})` |
+| `cypher` | Custom graph queries | `gitnexus_cypher({query: "MATCH ..."})` |
+
+## Impact Risk Levels
+
+| Depth | Meaning | Action |
+|-------|---------|--------|
+| d=1 | WILL BREAK — direct callers/importers | MUST update these |
+| d=2 | LIKELY AFFECTED — indirect deps | Should test |
+| d=3 | MAY NEED TESTING — transitive | Test if critical path |
+
+## Resources
+
+| Resource | Use for |
+|----------|---------|
+| `gitnexus://repo/linear-mcp/context` | Codebase overview, check index freshness |
+| `gitnexus://repo/linear-mcp/clusters` | All functional areas |
+| `gitnexus://repo/linear-mcp/processes` | All execution flows |
+| `gitnexus://repo/linear-mcp/process/{name}` | Step-by-step execution trace |
+
+## Self-Check Before Finishing
+
+Before completing any code modification task, verify:
+1. `gitnexus_impact` was run for all modified symbols
+2. No HIGH/CRITICAL risk warnings were ignored
+3. `gitnexus_detect_changes()` confirms changes match expected scope
+4. All d=1 (WILL BREAK) dependents were updated
+
+## Keeping the Index Fresh
+
+After committing code changes, the GitNexus index becomes stale. Re-run analyze to update it:
+
+```bash
+npx gitnexus analyze
+```
+
+If the index previously included embeddings, preserve them by adding `--embeddings`:
+
+```bash
+npx gitnexus analyze --embeddings
+```
+
+To check whether embeddings exist, inspect `.gitnexus/meta.json` — the `stats.embeddings` field shows the count (0 means no embeddings). **Running analyze without `--embeddings` will delete any previously generated embeddings.**
+
+> Claude Code users: A PostToolUse hook handles this automatically after `git commit` and `git merge`.
+
+## CLI
+
+| Task | Read this skill file |
+|------|---------------------|
+| Understand architecture / "How does X work?" | `.claude/skills/gitnexus/gitnexus-exploring/SKILL.md` |
+| Blast radius / "What breaks if I change X?" | `.claude/skills/gitnexus/gitnexus-impact-analysis/SKILL.md` |
+| Trace bugs / "Why is X failing?" | `.claude/skills/gitnexus/gitnexus-debugging/SKILL.md` |
+| Rename / extract / split / refactor | `.claude/skills/gitnexus/gitnexus-refactoring/SKILL.md` |
+| Tools, resources, schema reference | `.claude/skills/gitnexus/gitnexus-guide/SKILL.md` |
+| Index, status, clean, wiki CLI commands | `.claude/skills/gitnexus/gitnexus-cli/SKILL.md` |
+
+<!-- gitnexus:end -->
\ No newline at end of file
diff --git a/Actually, looking back at my response, I see this section b/Actually, looking back at my response, I see this section
new file mode 100644
index 0000000..c346f83
--- /dev/null
+++ b/Actually, looking back at my response, I see this section	
@@ -0,0 +1,10 @@
+// Instead of
+return typeof value === 'object' && value !== null && !Array.isArray(value)
+  ? value as Record<string, unknown>
+  : undefined;
+
+// Use
+return typeof value === 'object' && value !== null && !Array.isArray(value)
+  ? (value as Record<string, unknown>)
+  : undefined;
+// But preferably validate keys/structure
diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 0000000..0adac05
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1,183 @@
+# Linear MCP — Claude Code Guide
+
+MCP server exposing Linear's API as tools for MCP-compatible clients such as Cline, Claude Code, and Copilot CLI.
+
+## Current state
+
+- Default runtime is **stdio**. Set `LINEAR_MCP_TRANSPORT=stream` to expose MCP streamable HTTP at `LINEAR_MCP_PATH` (default `/mcp`). `/sse` is intentionally unsupported.
+- Auth supports both `LINEAR_API_KEY` and the tool-driven OAuth flow through `linear_auth` and `linear_auth_callback`. OAuth callback state is single-use and must not be reused from stale links.
+- `linear_search_issues` is the query-backed search path. Keep the free-text `query` separate from filter fields and route it through `LinearGraphQLClient.searchIssues(query, ...)`.
+- The released server surface includes issues, comments, projects, milestones, cycles, teams, users, attachments, webhooks, portfolio entities, agent workflows, and runtime capability/subscription tools.
+- Release validation is `npm run verify:release` (build + built tool catalog + fresh packaged-install smoke test).
+
+## Stack
+
+- TypeScript (ESM, `"type": "module"`)
+- `@modelcontextprotocol/sdk` for the MCP server and stdio client smoke tests
+- `@linear/sdk` plus raw GraphQL (`graphql`, `graphql-tag`) for Linear API access
+- Jest + ts-jest for unit and integration tests
+- Auth via `LINEAR_API_KEY` or the MCP OAuth helper flow
+
+## Commands
+
+- `npm run build` — compile TS to `build/` and chmod the entry
+- `npm start` — run `build/index.js`
+- `npm run dev` — nodemon: rebuild + restart on `src/` changes
+- `npm test` — Jest (all)
+- `npm run test:watch` / `npm run test:coverage`
+- `npm run test:integration` — only `*.integration.test.ts`
+- `npm run verify:tool-catalog` — compare built `ListTools` output with the expected release surface
+- `npm run verify:package-install` — pack, install into a temp directory, and smoke-test the packaged server
+- `npm run verify:release` — run build + tool-catalog verification + packaged-install verification
+
+## Layout
+
+```
+src/
+├── index.ts                # MCP server entrypoint + stdio/stream transport bootstrap
+├── auth.ts                 # API key and OAuth helpers
+├── core/
+│   ├── capabilities.ts     # Runtime transport/capability metadata
+│   ├── handlers/           # Base handler + handler factory
+│   ├── interfaces/         # Tool handler interfaces
+│   └── types/              # MCP tool schemas and shared tool types
+├── features/
+│   ├── agents/
+│   ├── attachments/
+│   ├── auth/
+│   ├── comments/
+│   ├── cycles/
+│   ├── issues/
+│   ├── milestones/
+│   ├── portfolio/
+│   ├── projects/
+│   ├── subscriptions/
+│   ├── teams/
+│   ├── users/
+│   └── webhooks/
+├── graphql/                # GraphQL client, queries, and mutations
+├── types/                  # SDK helpers and shared mapping utilities
+└── __tests__/              # Jest tests, including runtime and tool-surface regressions
+```
+
+Architecture is domain-driven and layered. New Linear capability = new folder under `src/features/<domain>/` with `handlers/` + `types/`, registration in `src/core/handlers/handler.factory.ts`, and schema exposure in `src/core/types/tool.types.ts`.
+
+## Conventions
+
+- ESM imports require `.js` extensions in TS source.
+- Tool schemas live in `src/core/types/tool.types.ts`; handler routing lives in `src/core/handlers/handler.factory.ts`.
+- Runtime-aware tools must respect `src/core/capabilities.ts` so subscription/stream behavior matches the active transport.
+- `linear_list_issues` is filter-first; `linear_search_issues` is query-first and must stay query-backed.
+- Tests live under `src/__tests__/`; keep search regressions in `graphql-client.test.ts` and `issue-handler.test.ts`.
+- Update `README.md` and release verification when the advertised tool surface or runtime behavior changes.
+
+## Notes for Claude
+
+- Read the existing feature handler before changing behavior; most domains already have patterns to copy.
+- Do not edit `build/`; it is generated.
+- Keep `/sse` unsupported unless the runtime design changes everywhere, including docs and capability metadata.
+- For tool-surface changes, update schemas, handler routing, docs, and release verification together.
+- After non-trivial edits, run `npm run build`, `npm test`, and `npm run verify:release`.
+- See `architecture.md` for the architectural rationale and cross-feature behavior.
+
+<!-- gitnexus:start -->
+# GitNexus — Code Intelligence
+
+This project is indexed by GitNexus as **linear-mcp** (899 symbols, 2670 relationships, 67 execution flows). Use the GitNexus MCP tools to understand code, assess impact, and navigate safely.
+
+> If any GitNexus tool warns the index is stale, run `npx gitnexus analyze` in terminal first.
+
+## Always Do
+
+- **MUST run impact analysis before editing any symbol.** Before modifying a function, class, or method, run `gitnexus_impact({target: "symbolName", direction: "upstream"})` and report the blast radius (direct callers, affected processes, risk level) to the user.
+- **MUST run `gitnexus_detect_changes()` before committing** to verify your changes only affect expected symbols and execution flows.
+- **MUST warn the user** if impact analysis returns HIGH or CRITICAL risk before proceeding with edits.
+- When exploring unfamiliar code, use `gitnexus_query({query: "concept"})` to find execution flows instead of grepping. It returns process-grouped results ranked by relevance.
+- When you need full context on a specific symbol — callers, callees, which execution flows it participates in — use `gitnexus_context({name: "symbolName"})`.
+
+## When Debugging
+
+1. `gitnexus_query({query: "<error or symptom>"})` — find execution flows related to the issue
+2. `gitnexus_context({name: "<suspect function>"})` — see all callers, callees, and process participation
+3. `READ gitnexus://repo/linear-mcp/process/{processName}` — trace the full execution flow step by step
+4. For regressions: `gitnexus_detect_changes({scope: "compare", base_ref: "main"})` — see what your branch changed
+
+## When Refactoring
+
+- **Renaming**: MUST use `gitnexus_rename({symbol_name: "old", new_name: "new", dry_run: true})` first. Review the preview — graph edits are safe, text_search edits need manual review. Then run with `dry_run: false`.
+- **Extracting/Splitting**: MUST run `gitnexus_context({name: "target"})` to see all incoming/outgoing refs, then `gitnexus_impact({target: "target", direction: "upstream"})` to find all external callers before moving code.
+- After any refactor: run `gitnexus_detect_changes({scope: "all"})` to verify only expected files changed.
+
+## Never Do
+
+- NEVER edit a function, class, or method without first running `gitnexus_impact` on it.
+- NEVER ignore HIGH or CRITICAL risk warnings from impact analysis.
+- NEVER rename symbols with find-and-replace — use `gitnexus_rename` which understands the call graph.
+- NEVER commit changes without running `gitnexus_detect_changes()` to check affected scope.
+
+## Tools Quick Reference
+
+| Tool | When to use | Command |
+|------|-------------|---------|
+| `query` | Find code by concept | `gitnexus_query({query: "auth validation"})` |
+| `context` | 360-degree view of one symbol | `gitnexus_context({name: "validateUser"})` |
+| `impact` | Blast radius before editing | `gitnexus_impact({target: "X", direction: "upstream"})` |
+| `detect_changes` | Pre-commit scope check | `gitnexus_detect_changes({scope: "staged"})` |
+| `rename` | Safe multi-file rename | `gitnexus_rename({symbol_name: "old", new_name: "new", dry_run: true})` |
+| `cypher` | Custom graph queries | `gitnexus_cypher({query: "MATCH ..."})` |
+
+## Impact Risk Levels
+
+| Depth | Meaning | Action |
+|-------|---------|--------|
+| d=1 | WILL BREAK — direct callers/importers | MUST update these |
+| d=2 | LIKELY AFFECTED — indirect deps | Should test |
+| d=3 | MAY NEED TESTING — transitive | Test if critical path |
+
+## Resources
+
+| Resource | Use for |
+|----------|---------|
+| `gitnexus://repo/linear-mcp/context` | Codebase overview, check index freshness |
+| `gitnexus://repo/linear-mcp/clusters` | All functional areas |
+| `gitnexus://repo/linear-mcp/processes` | All execution flows |
+| `gitnexus://repo/linear-mcp/process/{name}` | Step-by-step execution trace |
+
+## Self-Check Before Finishing
+
+Before completing any code modification task, verify:
+1. `gitnexus_impact` was run for all modified symbols
+2. No HIGH/CRITICAL risk warnings were ignored
+3. `gitnexus_detect_changes()` confirms changes match expected scope
+4. All d=1 (WILL BREAK) dependents were updated
+
+## Keeping the Index Fresh
+
+After committing code changes, the GitNexus index becomes stale. Re-run analyze to update it:
+
+```bash
+npx gitnexus analyze
+```
+
+If the index previously included embeddings, preserve them by adding `--embeddings`:
+
+```bash
+npx gitnexus analyze --embeddings
+```
+
+To check whether embeddings exist, inspect `.gitnexus/meta.json` — the `stats.embeddings` field shows the count (0 means no embeddings). **Running analyze without `--embeddings` will delete any previously generated embeddings.**
+
+> Claude Code users: A PostToolUse hook handles this automatically after `git commit` and `git merge`.
+
+## CLI
+
+| Task | Read this skill file |
+|------|---------------------|
+| Understand architecture / "How does X work?" | `.claude/skills/gitnexus/gitnexus-exploring/SKILL.md` |
+| Blast radius / "What breaks if I change X?" | `.claude/skills/gitnexus/gitnexus-impact-analysis/SKILL.md` |
+| Trace bugs / "Why is X failing?" | `.claude/skills/gitnexus/gitnexus-debugging/SKILL.md` |
+| Rename / extract / split / refactor | `.claude/skills/gitnexus/gitnexus-refactoring/SKILL.md` |
+| Tools, resources, schema reference | `.claude/skills/gitnexus/gitnexus-guide/SKILL.md` |
+| Index, status, clean, wiki CLI commands | `.claude/skills/gitnexus/gitnexus-cli/SKILL.md` |
+
+<!-- gitnexus:end -->
diff --git a/README.md b/README.md
index 39b9055..4362344 100644
--- a/README.md
+++ b/README.md
@@ -1,210 +1,281 @@
 # Linear MCP Server
 
-An MCP server for interacting with Linear's API. This server provides a set of tools for managing Linear issues, projects, and teams through Cline.
-
-## Setup Guide
-
-### 1. Environment Setup
-
-1. Clone the repository
-2. Install dependencies:
-   ```bash
-   npm install
-   ```
-3. Copy `.env.example` to `.env`:
-   ```bash
-   cp .env.example .env
-   ```
-
-### 2. Authentication
-
-The server supports two authentication methods:
-
-#### API Key (Recommended)
-
-1. Go to Linear Settings
-2. Navigate to the "Security & access" section
-3. Find the "Personal API keys" section
-4. Click "New API key"
-5. Give the key a descriptive label (e.g. "Cline MCP")
-6. Copy the generated token immediately
-7. Add the token to your `.env` file:
-   ```
-   LINEAR_API_KEY=your_api_key
-   ```
-
-#### OAuth Flow (Alternative) ***NOT IMPLEMENTED***
-
-1. Create an OAuth application at https://linear.app/settings/api/applications
-2. Configure OAuth environment variables in `.env`:
-   ```
-   LINEAR_CLIENT_ID=your_oauth_client_id
-   LINEAR_CLIENT_SECRET=your_oauth_client_secret
-   LINEAR_REDIRECT_URI=http://localhost:3000/callback
-   ```
-
-### 3. Running the Server
-
-1. Build the server:
-   ```bash
-   npm run build
-   ```
-2. Start the server:
-   ```bash
-   npm start
-   ```
-
-### 4. Cline Integration
-
-1. Open your Cline MCP settings file:
-   - macOS: `~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json`
-   - Windows: `%APPDATA%/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json`
-   - Linux: `~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json`
-
-2. Add the Linear MCP server configuration:
-   ```json
-   {
-     "mcpServers": {
-       "linear": {
-         "command": "node",
-         "args": ["/path/to/linear-mcp/build/index.js"],
-         "env": {
-           "LINEAR_API_KEY": "your_personal_access_token"
-         },
-         "disabled": false,
-         "autoApprove": []
-       }
-     }
-   }
-   ```
-
-## Available Actions
-
-The server currently supports the following operations:
-
-### Issue Management
-- ✅ Create issues with full field support (title, description, team, project, etc.)
-- ✅ Update existing issues (priority, description, etc.)
-- ✅ Delete issues (single or bulk deletion)
-- ✅ Search issues with filtering
-- ✅ Associate issues with projects
-- ✅ Create parent/child issue relationships
-- ✅ Read and create comments and threaded comments
-
-### Project Management
-- ✅ Create projects with associated issues
-- ✅ Get project information **with rich text descriptions**
-- ✅ Search projects **with rich text descriptions**
-- ✅ Associate issues with projects
-- ✅ Proper description handling using Linear's `documentContent` field
-
-### Team Management
-- ✅ Get team information (with states and workflow details)
-- ✅ Access team states and labels
-
-### Authentication
-- ✅ API Key authentication
-- ✅ Secure token storage
-
-### Batch Operations
-- ✅ Bulk issue creation
-- ✅ Bulk issue deletion
-
-### Bulk Updates (In Testing)
-- 🚧 Bulk issue updates (parallel processing implemented, needs testing)
-
-## Rich Text Description Support
-
-The server now properly handles Linear's rich text descriptions for projects:
-
-- **Legacy Support**: Maintains compatibility with the old `description` field
-- **Rich Content**: Uses Linear's `documentContent` field for actual description content
-- **Automatic Fallback**: Falls back to legacy field if rich content is unavailable
-- **Type Safety**: Includes proper TypeScript types for both description formats
-
-### How It Works
-
-Linear uses a dual-field system for descriptions:
-1. `description` - Legacy field (often empty for backward compatibility)
-2. `documentContent.content` - Contains the actual rich text description content
-
-The MCP server automatically:
-- Queries both fields from Linear's API
-- Prioritizes `documentContent.content` over the legacy `description` field
-- Provides a utility function `getProjectDescription()` for consistent access
-- Returns an `actualDescription` field in responses for easy access
-
-## Features in Development
-
-The following features are currently being worked on:
-
-### Issue Management
-- 🚧 Complex search filters
-- 🚧 Pagination support for large result sets
-
-### Metadata Operations
-- 🚧 Label management (create/update/assign)
-- 🚧 Cycle/milestone management
-
-### Project Management
-- 🚧 Project template support
-- 🚧 Advanced project operations
-
-### Authentication
-- 🚧 OAuth flow with automatic token refresh
-
-### Performance & Security
-- 🚧 Rate limiting
-- 🚧 Detailed logging
-- 🚧 Load testing and optimization
+An MCP server for Linear built in TypeScript. It exposes a structured tool surface for issues, projects, workflow metadata, attachments, portfolio entities, webhooks, and agent workflows.
+
+## Current status
+
+- Default runtime is **stdio**. Set `LINEAR_MCP_TRANSPORT=stream` to expose MCP streamable HTTP at `LINEAR_MCP_PATH` (default `/mcp`). The server does **not** expose `/sse`.
+- Auth supports `LINEAR_API_KEY`, the `LINEAR_ACCESS_TOKEN` alias, and the tool-driven OAuth flow through `linear_auth` and `linear_auth_callback`. OAuth callback `state` values are single-use.
+- Advertised tool schemas are enforced at runtime before handler dispatch, so malformed tool payloads fail with structured validation errors at the MCP boundary.
+- Advertised tool schemas avoid top-level `oneOf`/`allOf`/`anyOf` combinators so Claude-compatible MCP clients can ingest the full tool catalog.
+- `linear_get_capabilities` reports transport details together with server build provenance so clients can confirm the packaged runtime name/version they are connected to.
+- Each MCP tool request emits structured stderr telemetry with tool name, transport, duration, and sanitized failure metadata for troubleshooting.
+- `linear_get_runtime_diagnostics` reports live low-cardinality request counters, recent failure context, and active stream session state without exposing secrets.
+- `linear_search_issues` is the query-backed issue search path. The built server advertises a required `query` string and keeps the free-text query separate from optional list-style filters.
+- OAuth token exchange and the shared Linear request boundary enforce explicit time budgets. Approved safe reads use bounded retry/backoff on retryable failures, while non-idempotent writes stay single-attempt by default.
+- Release validation is gated by `npm run verify:release`, which rebuilds the server, audits guarded Linear issue contracts, checks the built tool catalog, runs critical issue workflow smoke tests, and smoke-tests a fresh packaged install.
+
+## What it supports
+
+### Core work management
+- Issues: get, create one issue with `linear_create_issue`, batch create with `linear_create_issues`, bulk update, list, search, delete, hierarchy via `parentId`, and general issue relations
+- Projects: create, update, delete, get, list, search, create-with-issues, project updates, and initiative association via `initiativeId`
+- Comments: get a single comment, list comments globally or by issue, create threaded replies with `parentId`, update, delete, resolve, and unresolve threads
+- Project milestones: create, update, delete, get, search, list, bulk create
+
+### Workflow and discovery
+- Teams: get, list
+- Users: viewer, get, list, search
+- Workflow states: list
+- Labels: list, create, update, delete
+- Cycles: get, list, current cycle
+
+### Integrations and advanced surfaces
+- Attachments: get, list, create, update, delete
+- Webhooks: get, list, create, delete
+- Portfolio entities: initiatives and customers
+- Agents: agent sessions and agent activities
+- Capabilities: runtime capability discovery
+- Runtime diagnostics: live troubleshooting counters and session state through `linear_get_runtime_diagnostics`
+
+### Runtime-aware behavior
+- Subscription tools are only advertised when the runtime reports streaming transport support.
+- If a subscription tool is invoked on stdio, the server returns a structured capability-limitation error instead of a generic failure.
+- The default runtime is stdio. Set `LINEAR_MCP_TRANSPORT=stream` to expose a remote MCP streamable HTTP endpoint instead.
+- Stream mode uses MCP streamable HTTP at `LINEAR_MCP_PATH` (default `/mcp`). The server does **not** expose a legacy `/sse` endpoint.
+- `linear_get_capabilities` reports `authScope` as `server` for stdio and `session` for stream transport.
+- Structured per-tool telemetry is emitted to stderr so stdio protocol traffic on stdout stays untouched.
+
+## Authentication
+
+### API key
+
+Set a personal API key in either supported environment variable:
+
+```bash
+LINEAR_API_KEY=your_api_key
+# or
+LINEAR_ACCESS_TOKEN=your_api_key
+```
+
+If both are set, the server uses `LINEAR_API_KEY`. This is the simplest way to run the server locally.
+
+### OAuth
+
+The OAuth flow is available through MCP tools:
+
+1. Call `linear_auth` with `clientId`, `clientSecret`, and `redirectUri`.
+2. Open the returned `authorizationUrl`.
+3. Call `linear_auth_callback` with both `code` and the exact returned `state`.
+
+Notes:
+- OAuth uses `actor=app`.
+- Callback state is single-use and validated against the issued authorization request. If a link goes stale, call `linear_auth` again to get a fresh URL and state.
+- The generated authorization URL uses only Linear-supported parameters. The server does not request offline-only OAuth parameters.
+- Token refresh is awaited before handlers resolve the active client.
+- In stream mode, each MCP session gets its own isolated auth context. Pending OAuth state, active tokens, and auth configuration do not leak across remote sessions.
+
+## Webhook security
+
+Webhook management tools only register webhooks with Linear. They do **not** host a public receiver for you.
+
+If you create a webhook:
+- store the webhook secret outside the repository,
+- verify the Linear signature on every delivered payload,
+- reject unsigned or invalid payloads before processing them.
 
 ## Development
 
 ```bash
-# Install dependencies
 npm install
-
-# Run tests
+npm run build
 npm test
+npm start
+```
+
+Additional commands:
 
-# Run integration tests (requires LINEAR_API_KEY)
+```bash
+npm run dev
+npm run test:coverage
 npm run test:integration
+npm run verify:linear-api-contracts
+npm run verify:issue-workflows
+```
 
-# Build the server
-npm run build
+## MCP setup
+
+Example MCP configuration:
+
+```json
+{
+  "mcpServers": {
+    "linear": {
+      "command": "node",
+      "args": ["C:\\path\\to\\linear-mcp\\build\\index.js"],
+      "env": {
+        "LINEAR_API_KEY": "your_personal_access_token"
+      }
+    }
+  }
+}
+```
 
-# Start the server
-npm start
+Use either `LINEAR_API_KEY` or `LINEAR_ACCESS_TOKEN` in MCP client config. If both are present, `LINEAR_API_KEY` wins.
+
+## Runtime transports
+
+### Stdio
+
+- Default mode for local clients such as Cline.
+- No remote HTTP endpoint is available in stdio mode.
+- Startup diagnostics report the packaged server build as `Build: linear-mcp@<version>` before auth/setup messages.
+
+### Streamable HTTP
+
+Set these environment variables before starting the server:
+
+```bash
+LINEAR_MCP_TRANSPORT=stream
+LINEAR_MCP_HOST=127.0.0.1
+LINEAR_MCP_PORT=3000
+LINEAR_MCP_PATH=/mcp
+```
+
+- Clients should connect to `http://127.0.0.1:3000/mcp` by default.
+- `/sse` is not a supported endpoint; use the configured streamable HTTP path instead.
+- If you need a public tunnel for a remote client, expose the configured port and forward the `/mcp` path. For example, `ngrok http 3000` should target the stream endpoint, not `/sse`.
+- Stream transport auth is session-scoped. Each connected MCP session keeps its own pending OAuth state and credentials.
+
+## Issue workflows
+
+### Hierarchy vs. relations
+
+- Use `linear_create_issue` for a single issue and `linear_create_issues` for one or more issues submitted through the batch-create contract.
+- `linear_create_project_with_issues` creates the project first and reuses the same batch-create contract for its follow-on issues.
+- `linear_create_project_with_issues` stops before issue creation if project creation does not return a usable project ID, and it reports compensation or partial-state details when downstream issue creation fails.
+- Use `parentId` on `linear_create_issue` and `linear_bulk_update_issues` for parent-child hierarchy.
+- Use `linear_create_issue_relation` and `linear_delete_issue_relation` for non-hierarchical relationships such as blocked-by or duplicate links.
+- `linear_get_issue` is the canonical hierarchy read and returns both `parent` and `children` references when they exist.
+- `linear_delete_issues` returns deterministic `deletedIds` and failure details when some requested issue deletions do not complete.
+
+Example hierarchy update:
+
+```json
+{
+  "issueIds": ["ENG-124"],
+  "update": {
+    "parentId": "ENG-100"
+  }
+}
+```
+
+### Existing issue project assignment
+
+Use `linear_bulk_update_issues` for the released existing-issue update path, even when updating a single issue:
+
+```json
+{
+  "issueIds": ["ENG-123"],
+  "update": {
+    "projectId": "project-abc"
+  }
+}
+```
+
+- Set or change a project assignment by sending a project ID.
+- Clear an existing project assignment explicitly with `"projectId": null`.
+- Omitting `projectId` leaves the current project unchanged.
+
+## Project and initiative workflows
+
+- Initiative lifecycle tools are available through `linear_get_initiative`, `linear_list_initiatives`, `linear_create_initiative`, and `linear_update_initiative`.
+- Project create and update workflows accept `initiativeId` so clients can attach a project to an initiative.
+- Clear an existing initiative association explicitly with `"initiativeId": null` on `linear_update_project`.
+- Project reads and mutation responses include linked initiative summary data when the association exists.
+
+Example project update:
+
+```json
+{
+  "id": "project-abc",
+  "initiativeId": "initiative-42"
+}
+```
+
+## Search semantics
+
+- `linear_list_issues` is the filter-and-pagination path.
+- `linear_search_issues` is the free-text search path and always requires `query`.
+- Optional `teamId`, `projectId`, `assigneeId`, `stateId`, `states`, `priority`, and `cycleId` filters are applied alongside the text query.
+- `stateId` and `states` are mutually exclusive on both list and search requests.
+- `linear_search_issues` does not accept a generic `filter` object or `orderBy`; those list-style controls stay on `linear_list_issues`.
+- The search path sends `query` through Linear's search backend instead of encoding it as an issue filter field.
+- Exact issue identifiers like `POL-431` resolve through a deterministic team-key + issue-number lookup before falling back to ranked search results.
+- Current regression coverage covers both query-only and query-plus-filter search behavior.
+
+## Guarded issue workflow contracts
+
+- `linear_create_issue` uses the audited raw GraphQL single-create helper so the MCP tool does not inherit SDK mutation-shape regressions. `linear_create_issues` remains on the SDK-backed batch-create path.
+- Raw GraphQL single-create stays on `IssueCreateInput!` and batch-create stays on `IssueBatchCreateInput!`; the repo guards against reintroducing array-shaped single-create input.
+- Raw GraphQL bulk delete stays on `issueDelete(ids: $ids)` and the repo audits that helper contract separately from the MCP handler's deterministic per-ID result shaping.
+- `linear_search_issues` keeps free-text queries on the raw `searchIssues(term: ...)` GraphQL path, with exact identifier lookups handled separately so issue references like `POL-431` stay reliable.
+- Run `npm run verify:linear-api-contracts` to audit those guarded contracts locally. `npm run verify:release` includes the same audit before packaging.
+
+## Critical issue workflow smoke coverage
+
+- `npm run verify:issue-workflows` runs credential-free MCP-boundary smoke tests for `linear_create_issue`, `linear_create_issues`, and `linear_search_issues`.
+- The smoke harness boots the real MCP server against a fake Linear backend, so the tool boundary is exercised without live Linear credentials or network access.
+- `npm run verify:release` includes the smoke suite so critical issue workflows cannot drift silently between source and released builds.
+
+## Marketplace and packaged installs
+
+- The application is published to npm as `@kkaminsk/linear-mcp`.
+- The published package exposes the `linear-mcp` executable from `build/index.js`.
+- Release verification uses:
+
+```bash
+npm run verify:tool-catalog
+npm run verify:package-install
 ```
 
-## Integration Testing
-
-Integration tests verify that authentication and API calls work correctly:
-
-1. Set up authentication (API Key recommended for testing)
-2. Run integration tests:
-   ```bash
-   npm run test:integration
-   ```
-
-For OAuth testing:
-1. Configure OAuth credentials in `.env`
-2. Remove `.skip` from OAuth tests in `src/__tests__/auth.integration.test.ts`
-3. Run integration tests
-
-## Recent Improvements
-
-### Project Description Support (Latest)
-- ✅ Fixed empty project descriptions by implementing Linear's `documentContent` field support
-- ✅ Added proper TypeScript types for rich text content
-- ✅ Implemented automatic fallback from rich content to legacy description
-- ✅ Updated all project-related queries and handlers
-- ✅ Added comprehensive tests for new description handling
-- ✅ Maintained backward compatibility with existing API consumers
-
-### Previous Improvements
-- ✅ Enhanced type safety across all operations
-- ✅ Implemented true batch operations for better performance
-- ✅ Improved error handling and validation
-- ✅ Added comprehensive test coverage
-- ✅ Refactored architecture for better maintainability
\ No newline at end of file
+### Troubleshooting
+
+- Run `linear_get_capabilities` to confirm the runtime is reporting the expected packaged server name/version before debugging tool behavior.
+- Run `linear_get_runtime_diagnostics` for a live snapshot of request totals, failure counters, recent sanitized failure context, and active stream session count.
+- Inspect stderr telemetry records to correlate a tool name, transport, duration, outcome, retryability, and upstream request ID without exposing raw headers or request bodies.
+- If `linear_search_issues` fails with an `IssueFilter.search` GraphQL error, the client is still connected to a stale build or package that predates the raw search fix. Rebuild or reinstall the package, restart the MCP server, and re-check `linear_get_capabilities`.
+- If startup logs say `Auth: no LINEAR_API_KEY or LINEAR_ACCESS_TOKEN detected`, the package installed correctly and you only need to finish auth setup.
+- If a remote client hangs on `/sse`, switch it to the configured streamable HTTP endpoint such as `/mcp`, or run the server in stdio mode for local clients.
+- If a request reaches its time budget, the returned failure identifies the timed-out operation and keeps the retryable timeout classification (`TIMEOUT` / HTTP 408) in the structured GraphQL error payload.
+- Safe read operations may retry within the bounded request policy before failing. Non-idempotent writes do not auto-retry, so rerun those manually only after confirming the upstream state.
+- Before publishing, run `npm run verify:release` to rebuild, validate the built tool catalog, and smoke-test a fresh package install.
+
+## Comment tools
+
+- `linear_get_comment` returns a direct comment payload with stable IDs, author metadata, issue context, parent linkage, and resolution state when present.
+- `linear_list_comments` and `linear_get_issue_comments` both accept Linear-style collection controls: `first`, `after`, `last`, `before`, `filter`, `includeArchived`, and `orderBy`.
+- `linear_get_issue_comments` accepts either a Linear issue ID or a human-friendly issue identifier such as `POL-431`.
+- `linear_create_comment` and `linear_update_comment` use markdown `body` as the primary content field. `bodyData` remains optional advanced structured content for clients that need it.
+
+## Released tool surface (Version 1.0.0)
+
+Version 1.0.0 ships the released issue-update and comment workflow surface:
+
+- `linear_bulk_update_issues`
+- `linear_get_comment`
+- `linear_list_comments`
+- `linear_get_issue_comments`
+- `linear_create_comment`
+- `linear_update_comment`
+- `linear_delete_comment`
+- `linear_resolve_comment`
+- `linear_unresolve_comment`
+
+## Implementation notes
+
+- Tool schemas in `src/core/types/tool.types.ts` use standard JSON Schema.
+- Tool responses return machine-readable `structuredContent`.
+- Comment tools use markdown-first `body` fields; `bodyData` is optional advanced structured content.
+- The server uses both raw GraphQL operations and the current `@linear/sdk` surface.
+- GraphQL errors preserve status, request correlation, retryability, and normalized error details without forwarding raw upstream headers.
diff --git a/[408, 409, 425, 429, 500, 502, 503, 504].includes(status) b/[408, 409, 425, 429, 500, 502, 503, 504].includes(status)
new file mode 100644
index 0000000..9eddede
--- /dev/null
+++ b/[408, 409, 425, 429, 500, 502, 503, 504].includes(status)	
@@ -0,0 +1 @@
+Extract these to a named constant:
diff --git a/aidercodereview-kimi.md b/aidercodereview-kimi.md
new file mode 100644
index 0000000..01b1f75
--- /dev/null
+++ b/aidercodereview-kimi.md
@@ -0,0 +1,26 @@
+# Code Review: Linear MCP Server (Kimi Analysis)
+
+## Overview
+
+This review analyzes the Linear MCP server codebase with specific focus on the runtime, concurrency, request policy, GraphQL client, and testing infrastructure implementations. The codebase demonstrates sophisticated TypeScript patterns for API resilience, concurrent operations, and observability.
+
+## Performance Analysis
+
+### Strengths
+
+**Worker Pool Concurrency Implementation**
+The `mapWithConcurrencyLimit` function in `src/core/concurrency.ts` implements an efficient worker pool pattern that maintains memory bounds regardless of input size. By using `workerCount = Math.min(concurrency, items.length)` and tracking `nextIndex` atomically across workers, it prevents the memory explosion that would occur with `Promise.all(Array.from({length: items.length}, ...))`.
+
+**AbortController Integration**
+The request policy implementation in `src/core/request-policy.ts` properly utilizes `AbortController` for timeout handling, ensuring that underlying HTTP requests are actually cancelled rather than just ignoring responses. The `signal` listener cleanup with `{ once: true }` prevents event listener leaks.
+
+**Lazy Query Loading**
+`src/graphql/client.ts` uses dynamic imports for GraphQL operations (`await import('./mutations.js')`), enabling code splitting and reducing initial bundle size. This is particularly effective for a CLI tool where not all operations are used in every session.
+
+**Telemetry Compaction**
+The `compactRecord` method in `src/core/runtime-observability.ts` filters undefined values and falsy flags before logging, reducing log volume and I/O overhead.
+
+### Areas for Improvement
+
+**Repeated Dynamic Imports**
+While dynamic imports enable code splitting, the current implementation in `src/graphql/client.ts` re-imports mutation/query modules on every method call:
diff --git a/aidercodereview.md b/aidercodereview.md
new file mode 100644
index 0000000..ddbf140
--- /dev/null
+++ b/aidercodereview.md
@@ -0,0 +1,68 @@
+# Code Review: Linear MCP Server
+
+## Overview
+
+This review covers the Linear MCP server codebase, focusing on performance, best practices, reliability, and security. The codebase is a TypeScript project implementing a Model Context Protocol (MCP) server for Linear, providing tools for managing issues, projects, comments, etc. The architecture uses handlers, authentication, and runtime capabilities.
+
+## Performance
+
+### Strengths
+- **Concurrency control**: The `mapWithConcurrencyLimit` utility prevents overwhelming external APIs.
+- **Request policies**: Configurable timeouts and retries (`RequestPolicyOptions`) help avoid hanging requests.
+- **Caching**: `WeakMap` used in `HandlerFactory` for handler caching avoids memory leaks and re‑creates handlers per auth instance appropriately.
+
+### Areas for Improvement
+- **GraphQL query efficiency**: Ensure that GraphQL queries are minimal and use pagination where applicable (e.g., `first`/`after`). The existing `list` operations appear to support pagination, but the actual queries should be audited.
+- **Streaming sessions cleanup**: The `streamSessions` map in `LinearServer` holds server references; ensure they are properly removed on session end to prevent memory accumulation.
+- **Large payloads**: Some handlers may return large arrays (e.g., listing all issues). Consider implementing response size limits or encouraging filtering.
+
+## Best Practices
+
+### Strengths
+- **Separation of concerns**: Clear division between features (issues, projects, comments) and layers (handlers, types, validation).
+- **TypeScript usage**: Strong typing across most of the codebase, with dedicated interfaces for inputs and outputs.
+- **Error handling**: Consistent use of `try/catch` in handlers and structured error responses (`BaseToolResponse` with `isError` flag).
+- **Validation**: `ToolValidatorRegistry` uses AJV for JSON schema validation, providing clear error messages.
+
+### Areas for Improvement
+- **`any` types**: Some handler methods (e.g., `handleAuth(args: any)`) accept `any`, reducing type safety. Replace with concrete interfaces.
+- **Missing async/await hygiene**: A few places may call async functions without `await` (e.g., inside `Promise.all`). Review for unhandled rejections.
+- **Code duplication**: Similar validation patterns appear across handlers; consider extracting common validation logic into a shared utility.
+- **Documentation**: Many methods lack JSDoc comments. Adding documentation would improve maintainability.
+
+## Reliability
+
+### Strengths
+- **Retry logic**: The `LinearGraphQLClient` includes retry mechanisms for transient failures.
+- **Authentication resilience**: OAuth flow includes state verification and token refresh handling.
+- **Graceful shutdown**: The `LinearServer.close()` method attempts to clean up all resources (HTTP servers, stream sessions).
+
+### Areas for Improvement
+- **Unhandled promise rejections**: Ensure all async operations are wrapped in try/catch or have a `.catch`. The `withStdioClient` pattern should guarantee error propagation.
+- **Circular dependencies**: The import graph between `core` and `features` should be checked for cycles (e.g., `HandlerFactory` depends on runtime capabilities, which may import feature modules).
+- **Testing gaps**: While unit tests exist for some handlers, there may be insufficient integration tests for the full OAuth flow and error scenarios.
+
+## Security
+
+### Strengths
+- **OAuth implementation**: Uses PKCE‑like state parameter and secure token exchange. Tokens are stored in memory, not persisted to disk.
+- **Environment variable filtering**: `buildProcessEnv` filters out empty strings, preventing accidental empty values from being used.
+- **Input validation**: All tool arguments are validated via JSON schemas before processing, mitigating injection risks.
+
+### Areas for Improvement
+- **Sensitive data logging**: Ensure that tokens, API keys, and user data are never logged, even in debug mode. Review `RuntimeObservability` telemetry for potential exposure.
+- **HTTP headers security**: If serving HTTP endpoints (stream transport), implement security headers (CSP, HSTS) and ensure TLS in production.
+- **Dependency vulnerabilities**: Regularly audit dependencies (e.g., `ajv`, `@linear/sdk`) for known vulnerabilities.
+
+## Recommendations
+
+1. **Replace `any` types** – Define explicit interfaces for all handler arguments.
+2. **Add comprehensive integration tests** – Cover OAuth flows, error paths, and concurrency scenarios.
+3. **Implement a health check endpoint** – For stream transport, provide a lightweight `/health` endpoint to monitor server status.
+4. **Adopt a logging library** – Replace `console` usage with a structured logger (e.g., `pino` or `winston`) for better log management.
+5. **Conduct a security audit** – Focus on token storage, session management, and HTTP header security.
+6. **Monitor memory usage** – Profile long‑running processes for potential leaks, especially in the stream session management.
+
+## Conclusion
+
+The Linear MCP server is a well‑structured codebase with good attention to error handling and validation. By addressing the above points, the project can further improve its performance, maintainability, and security posture.
diff --git a/architecture.md b/architecture.md
index c3fe9f1..0beef76 100644
--- a/architecture.md
+++ b/architecture.md
@@ -1,321 +1,132 @@
 # Linear MCP Architecture
 
-This document outlines the architecture of the Linear MCP (Model Context Protocol) implementation.
-
 ## Overview
 
-The Linear MCP provides a type-safe, modular interface to the Linear API. It abstracts away the complexity of GraphQL operations while providing a clean, domain-driven API surface through MCP tools.
-
-## Core Concepts
-
-### Domain-Driven Design
-
-The codebase is organized around business domains:
-- Authentication
-- Issues
-- Projects
-- Teams
-- Users
+The server defaults to stdio and can optionally expose MCP streamable HTTP with a domain-driven handler layer on top of Linear's API. It uses a hybrid integration model:
 
-Each domain has its own set of:
-- Handlers (for MCP tool operations)
-- Types
-- Tests
+- raw GraphQL for legacy operations that still rely on explicit documents,
+- current `@linear/sdk` methods for newer capability areas,
+- structured MCP responses for both reads and mutations.
 
-### Layered Architecture
+## Repository layout
 
-The codebase follows a layered architecture pattern:
-
-```
+```text
 src/
-├── core/               # Core infrastructure
-│   ├── handlers/      # Base handler and factory
+├── index.ts
+├── auth.ts
+├── graphql/
+│   └── client.ts
+├── core/
+│   ├── capabilities.ts
+│   ├── handlers/
 │   │   ├── base.handler.ts
 │   │   └── handler.factory.ts
-│   ├── types/         # Shared type definitions
-│   │   ├── tool.types.ts     # MCP tool schemas
-│   │   └── common.types.ts
-│   └── interfaces/    # Core interfaces
-│       └── tool-handler.interface.ts
-│
-├── features/          # Feature modules by domain
-│   ├── auth/         # Authentication
-│   │   └── handlers/
-│   ├── issues/       # Issue management
-│   │   └── handlers/
-│   ├── projects/     # Project operations
-│   │   └── handlers/
-│   ├── teams/        # Team operations
-│   │   └── handlers/
-│   └── users/        # User operations
-│       └── handlers/
-│
-├── infrastructure/    # Infrastructure concerns
-│   ├── graphql/      # GraphQL implementation
-│   │   ├── operations/   # GraphQL operations by domain
-│   │   └── fragments/    # Shared GraphQL fragments
-│   └── http/         # HTTP client
-│
-└── utils/            # Shared utilities
-    ├── logger.ts     # Logging system
-    └── config.ts     # Configuration management
+│   ├── interfaces/
+│   └── types/
+│       └── tool.types.ts
+├── features/
+│   ├── auth/
+│   ├── issues/
+│   ├── projects/
+│   ├── comments/
+│   ├── milestones/
+│   ├── teams/
+│   ├── users/
+│   ├── cycles/
+│   ├── attachments/
+│   ├── webhooks/
+│   ├── portfolio/
+│   ├── agents/
+│   └── subscriptions/
+└── types/
+    └── sdk.utils.ts
 ```
 
-## Key Components
-
-### Handler Architecture
-
-The handler system provides a clean separation of concerns for MCP tool operations:
-
-```typescript
-// Base handler with shared functionality
-abstract class BaseHandler {
-  protected verifyAuth(): LinearGraphQLClient;
-  protected createResponse(text: string): BaseToolResponse;
-  protected createJsonResponse(data: unknown): BaseToolResponse;
-  protected handleError(error: unknown, operation: string): never;
-  protected validateRequiredParams(params: Record<string, unknown>, required: string[]): void;
-}
-
-// Feature-specific handlers extend the base
-class IssueHandler extends BaseHandler {
-  handleCreateIssue(args: any): Promise<BaseToolResponse>;
-  handleSearchIssues(args: any): Promise<BaseToolResponse>;
-  // ... other issue operations
-}
-
-// Factory for managing handlers
-class HandlerFactory {
-  private authHandler: AuthHandler;
-  private issueHandler: IssueHandler;
-  // ... other handlers
-
-  getHandlerForTool(toolName: string): { handler: BaseHandler; method: string };
-}
-```
+## Request flow
 
-### Authentication Layer
+1. `index.ts` accepts MCP `ListTools` and `CallTool` requests.
+2. `tool.types.ts` provides strict JSON Schema input contracts.
+3. `handler.factory.ts` maps tool names to feature handlers.
+4. Feature handlers extend `BaseHandler` for validation, auth checks, structured success responses, and structured errors.
+5. `auth.ts` resolves the active Linear client lazily so auth changes are visible to every handler.
 
-The authentication system supports both API Key and OAuth flows:
+## Authentication model
 
-```typescript
-class AuthHandler extends BaseHandler {
-  handleAuth(args: any): Promise<BaseToolResponse>;
-  handleAuthCallback(args: any): Promise<BaseToolResponse>;
-}
+`LinearAuth` supports:
 
-interface AuthConfig {
-  type: 'apikey' | 'oauth';
-  accessToken?: string;
-  clientId?: string;
-  clientSecret?: string;
-  redirectUri?: string;
-}
-```
+- API key authentication from `LINEAR_API_KEY` or `LINEAR_ACCESS_TOKEN` (with `LINEAR_API_KEY` taking precedence when both are set)
+- OAuth authorization URL generation with Linear-supported parameters
+- single-use callback state validation
+- awaited token refresh
+- late-bound client access through `ensureAuthenticatedClient()` and `getGraphQLClient()`
 
-### GraphQL Layer
-
-The GraphQL layer provides domain-specific operations with atomic and composite patterns:
-
-```typescript
-class LinearGraphQLClient {
-  // Execute GraphQL operations
-  async execute<T>(document: DocumentNode, variables?: any): Promise<T>;
-  
-  // Atomic operations
-  async createProject(input: ProjectInput): Promise<ProjectResponse>;
-  async createBatchIssues(issues: CreateIssueInput[]): Promise<IssueBatchResponse>;
-  
-  // Composite operations (built from atomic operations)
-  async createProjectWithIssues(
-    projectInput: ProjectInput, 
-    issues: CreateIssueInput[]
-  ): Promise<ProjectResponse> {
-    // Creates project first, then creates issues with project reference
-    const project = await this.createProject(projectInput);
-    const issuesWithProject = issues.map(issue => ({
-      ...issue,
-      projectId: project.projectCreate.project.id
-    }));
-    const batchResult = await this.createBatchIssues(issuesWithProject);
-    return { projectCreate: project.projectCreate, issueBatchCreate: batchResult.issueBatchCreate };
-  }
-}
-```
+OAuth authorization requests use `actor=app` and require the freshly issued `state` on callback.
 
-This pattern ensures:
-- Clear separation between atomic and composite operations
-- Type safety through the entire operation chain
-- Proper error handling at each step
-- Reusable atomic operations
+## GraphQL and SDK layer
 
-### Error Handling
+`src/graphql/client.ts` is the shared execution boundary.
 
-Errors are handled consistently through the MCP error system:
+It provides:
 
-```typescript
-interface BaseToolResponse {
-  content: Array<{
-    type: string;
-    text: string;
-  }>;
-}
+- raw GraphQL execution with preserved status, headers, GraphQL errors, and extensions
+- `executeSdk()` for SDK calls that should share the same structured error behavior
+- `LinearGraphQLRequestError` for surfacing GraphQL metadata at the MCP boundary
 
-interface ErrorToolResponse extends BaseToolResponse {
-  isError: true;
-}
-```
+## Response contract
 
-## Best Practices
-
-1. **Handler Organization**
-   - Each domain has its own handler
-   - Handlers extend BaseHandler
-   - Keep handler methods focused and single-purpose
-
-2. **Type Safety**
-   - Define tool schemas in tool.types.ts
-   - Use interfaces for handler methods
-   - Minimize use of 'any' type
-
-3. **Error Handling**
-   - Use BaseHandler error methods
-   - Provide clear error messages
-   - Include operation context in errors
-
-4. **Testing**
-   - Test each handler independently
-   - Use integration tests for full flows
-   - Mock GraphQL responses
-
-## Planned Improvements
-
-### Type Safety & Validation
-- Replace all 'any' types with proper interfaces
-- Generate types from GraphQL schema
-- Add runtime type checking
-- Implement JSON schema validation for inputs
-- Improve error messages for validation failures
-
-### Performance Optimizations
-- Implement true batch mutations for bulk operations
-- Pre-import and cache GraphQL operations
-- Add query batching for related operations
-- Implement proper error handling for GraphQL errors
-- Move to GraphQL code generation
-- Add operation validation
-
-### Handler Enhancements
-- Add comprehensive input validation
-- Implement response caching with invalidation
-- Add retry logic with backoff strategy
-- Add handler lifecycle hooks
-- Improve error context and debugging
-
-### OAuth Implementation
-- Complete OAuth flow with proper state management
-- Add token refresh with automatic retry
-- Implement secure token storage
-- Add proper error handling for OAuth flows
-- Support multiple OAuth scopes
-
-### GraphQL Operations
-- Implement true batching for bulk operations
-- Move to code generation for type safety
-- Add operation validation and optimization
-- Implement proper error handling
-- Add query complexity analysis
-
-### Authentication Refactoring
-- Split authentication into separate implementations:
-  ```typescript
-  interface ILinearAuth {
-    initialize(config: AuthConfig): void;
-    isAuthenticated(): boolean;
-    getClient(): LinearClient;
-  }
-
-  class OAuthLinearAuth implements ILinearAuth {
-    // OAuth-specific implementation
-  }
-
-  class APILinearAuth implements ILinearAuth {
-    // API-specific implementation
-  }
-  ```
-
-### Caching Layer
-- Implement caching for frequently accessed data:
-  ```typescript
-  interface CacheConfig {
-    ttl: number;
-    maxSize: number;
-  }
-
-  class CacheManager {
-    private cache: Map<string, CacheEntry>;
-    
-    get<T>(key: string): T | undefined;
-    set<T>(key: string, value: T, ttl?: number): void;
-    invalidate(pattern: string): void;
-  }
-  ```
-
-### Rate Limiting
-- Add rate limiting middleware:
-  ```typescript
-  class RateLimiter {
-    private readonly limits: Map<string, number>;
-    private readonly windowMs: number;
-
-    async checkLimit(operation: string): Promise<boolean>;
-    async waitForAvailability(operation: string): Promise<void>;
-  }
-  ```
-
-### Error Handling
-- Implement domain-specific error types:
-  ```typescript
-  class LinearApiError extends Error {
-    constructor(
-      public code: string,
-      public operation: string,
-      message: string
-    ) {
-      super(message);
-    }
-  }
-  ```
-
-## Contributing
-
-When contributing to this codebase:
-
-1. Follow the handler pattern
-2. Maintain domain separation
-3. Add tests for new handlers
-4. Update tool schemas
-5. Keep handlers focused
-6. Document new tools
-
-## File Organization
-
-Keep related code together:
+Handlers return MCP-compatible results shaped around:
 
-```
-features/issues/
-├── handlers/          # Issue-related handlers
-│   └── issue.handler.ts
-├── types/            # Issue-specific types
-│   └── issue.types.ts
-└── __tests__/        # Tests
-    ├── issue.test.ts
-    └── issue.integration.test.ts
-```
+- human-readable text summaries in `content`
+- machine-readable payloads in `structuredContent`
+- `isError: true` for tool-visible failures
+
+Error responses distinguish:
 
-## Dependency Management
+- GraphQL failures
+- auth failures
+- permission failures
+- MCP validation failures
+- capability limitations
 
-- Keep dependencies minimal
-- Use peer dependencies where appropriate
-- Lock dependency versions
-- Document breaking changes
+## Runtime capability gating
+
+`src/core/capabilities.ts` describes runtime support, endpoint metadata, and subscription behavior.
+
+- On stdio, subscription tools are not advertised in the tool list.
+- On stdio, no remote endpoint is exposed.
+- On stream transport, capability metadata includes the active streamable HTTP endpoint.
+- If a client still invokes a subscription tool directly, the server returns a structured capability error.
+- `linear_get_capabilities` exposes the active runtime and feature availability.
+
+This keeps advanced surfaces explicit without pretending that stdio can sustain streaming semantics it does not support or that `/sse` exists when the runtime is configured for streamable HTTP at `/mcp`.
+
+## Domain boundaries
+
+- **Issues** own detailed issue reads, hierarchy via `parentId`, planning-field mutations, search/list semantics, and general relations.
+- **Projects** own standalone lifecycle, shared read shape, project updates, and initiative association.
+- **Teams / Users** own discovery surfaces.
+- **Cycles / Labels / Workflow states** expose workflow primitives needed by issue automation.
+- **Portfolio** owns initiative and customer lifecycle, while project handlers surface initiative linkage in project-oriented reads and mutations.
+- **Attachments / Webhooks / Agents** keep integration-focused behavior out of the issue and project handlers.
+
+## Testing strategy
+
+The test suite mixes:
+
+- unit tests for auth and GraphQL client behavior,
+- contract tests for tool schemas and capability gating,
+- handler tests for hierarchy, project assignment, and initiative association semantics,
+- runtime transport tests for streamable HTTP interoperability,
+- optional integration tests for live Linear credentials.
+
+Release verification also includes built-artifact checks:
+
+- `npm run verify:tool-catalog` validates the built server's advertised tool surface,
+- `npm run verify:package-install` smoke-tests a fresh packaged install before publishing.
+
+The expected local verification path is:
+
+```bash
+npm run build
+npm test
+```
diff --git a/const RETRYABLE_HTTP_STATUS_CODES = [408, 409, 425, 429, 500, 502, 503, 504] as const; b/const RETRYABLE_HTTP_STATUS_CODES = [408, 409, 425, 429, 500, 502, 503, 504] as const;
new file mode 100644
index 0000000..00be9a8
--- /dev/null
+++ b/const RETRYABLE_HTTP_STATUS_CODES = [408, 409, 425, 429, 500, 502, 503, 504] as const;	
@@ -0,0 +1,4 @@
+
+**Console Usage in Production**
+`src/core/runtime-observability.ts` uses `console.error(JSON.stringify(...))` for telemetry. In production environments, this bypasses structured logging pipelines and may interleave with other console output. Consider injecting a logger interface:
+
diff --git a/copilotreview.md b/copilotreview.md
new file mode 100644
index 0000000..93efe52
--- /dev/null
+++ b/copilotreview.md
@@ -0,0 +1,134 @@
+# Copilot Review: Linear MCP
+
+This review combines **GitNexus graph analysis** with direct inspection of the runtime boundary and the files that sit on the highest-traffic execution paths:
+
+- `src/index.ts`
+- `src/core/handlers/base.handler.ts`
+- `src/core/handlers/handler.factory.ts`
+- `src/core/validation/tool-validator.ts`
+- `src/graphql/client.ts`
+- `src/auth.ts`
+- `src/features/issues/handlers/issue.handler.ts`
+- `src/features/subscriptions/handlers/subscription.handler.ts`
+- `src/__tests__/runtime-server.test.ts`
+- `scripts/verify-packaged-install.mjs`
+
+## GitNexus snapshot
+
+- Indexed repo: **899 symbols**, **2670 relationships**, **67 execution flows**, **39 communities**
+- Most central execution symbols by process participation:
+  - `verifyAuth` - 36 flows
+  - `ensureAuthenticatedClient` - 28 flows
+  - `executeSdk` - 28 flows
+  - `createErrorResult` - 28 flows
+- Largest classes by graph size:
+  - `LinearGraphQLClient` - 45 methods, `src/graphql/client.ts`
+  - `IssueHandler` - 25 methods, `src/features/issues/handlers/issue.handler.ts`
+  - `LinearAuth` - 18 methods, `src/auth.ts`
+  - `LinearServer` - 11 methods, `src/index.ts`
+
+**Takeaway:** the main architectural center of gravity is the auth -> handler -> GraphQL boundary. That is where the code is strongest today, and also where the most valuable performance and troubleshooting improvements sit.
+
+## Executive assessment
+
+The codebase already follows several strong best-practice patterns:
+
+- input validation happens before handler dispatch,
+- auth and session scope are explicit,
+- GraphQL failures are sanitized into structured MCP errors,
+- runtime capabilities are advertised honestly,
+- release validation checks the **built package**, not just source code.
+
+The main gaps are:
+
+1. **Performance:** handler dispatch does unnecessary object allocation on every tool call, and some bulk workflows fan out without concurrency limits.
+2. **Reliability:** retryable failures are detected but not retried, and network calls do not show explicit timeout budgets.
+3. **Troubleshooting:** runtime diagnostics are good at startup and on explicit failures, but thin for tracing live request behavior.
+
+## Performance review
+
+| Pattern | Assessment | Evidence | Review |
+| --- | --- | --- | --- |
+| Validator compilation is cached at startup | **Strong** | `src/core/validation/tool-validator.ts:25-43` | AJV validators are compiled once and stored in a `Map`, which avoids repeated schema compilation during tool execution. |
+| GraphQL documents are loaded lazily | **Good** | `src/graphql/client.ts:193-205`, `207-217`, `302-330`, `497-549` | Dynamic imports keep startup lighter. Because ESM caches modules, repeated calls should pay only the first-load cost. |
+| Handler dispatch allocates far too much per call | **Needs improvement** | `src/core/handlers/handler.factory.ts:46-167` | `getHandlerForTool()` rebuilds the entire tool-to-handler map and creates many fresh handler instances every time a tool is called. This is the clearest avoidable hot-path cost in the repo. |
+| Bulk issue operations use unbounded fan-out | **Needs improvement** | `src/features/issues/handlers/issue.handler.ts:124-136`, `247-272` | `Promise.all()` over user-provided ID arrays can create bursty traffic against Linear and increase rate-limit pressure. |
+| Large multi-purpose classes concentrate runtime work | **Watch** | GitNexus size/method-count analysis; `src/graphql/client.ts`, `src/features/issues/handlers/issue.handler.ts` | This is more of a performance-maintainability risk than a raw latency bug, but it makes targeted optimization harder. |
+
+### Performance recommendations
+
+1. **Replace per-call handler map construction with a static registry.**  
+   Store `{ handlerType, methodName }` metadata once, then memoize one handler instance per auth context or per feature.
+
+2. **Add bounded concurrency to bulk workflows.**  
+   A small concurrency cap for update/delete loops would reduce avoidable 429s while keeping throughput predictable.
+
+3. **Treat `LinearGraphQLClient` and `IssueHandler` as optimization boundaries.**  
+   They are the two biggest hotspots in the graph and should be the first files profiled or split when performance work starts.
+
+## Reliability review
+
+| Pattern | Assessment | Evidence | Review |
+| --- | --- | --- | --- |
+| Tool input is validated before handler dispatch | **Strong** | `src/index.ts:142-158`, `src/core/validation/tool-validator.ts:49-74`, `src/__tests__/runtime-server.test.ts:122-155` | This is exactly the right boundary. Bad payloads fail early and do not leak into business logic. |
+| Auth/session boundaries are explicit | **Strong** | `src/auth.ts:57-114`, `131-144`, `200-228`; `src/index.ts:347-376`; `src/__tests__/runtime-server.test.ts:239-348` | Single-use OAuth state and session-scoped auth copies are a solid reliability pattern, especially for stream transport. |
+| GraphQL failures are sanitized and structured | **Strong** | `src/core/handlers/base.handler.ts:103-145`, `215-309`; `src/__tests__/runtime-server.test.ts:161-233` | The code preserves retryability, status, and request ID while stripping unsafe headers and extension fields. This is a strong production-grade pattern. |
+| Runtime capability gating is honest | **Strong** | `src/core/types/tool.types.ts:1143-1150`, `src/features/subscriptions/handlers/subscription.handler.ts:30-88` | Subscription tools are only advertised when supported, and unsupported calls fail with a structured capability response. |
+| Multi-step workflow compensation is explicit | **Strong** | `src/graphql/client.ts:214-275`, `711-767` | `createProjectWithIssues()` returns partial-state details and attempts compensation instead of hiding failure. That is the right reliability posture for composite writes. |
+| Retryable failures are detected but not acted on | **Gap** | `src/graphql/client.ts:684-699`, `src/core/handlers/base.handler.ts:103-117` | The code correctly classifies retryable failures but does not wrap safe operations in backoff/retry behavior. |
+| No explicit timeout budget is visible on external calls | **Gap** | `src/auth.ts:283-320` | OAuth token exchange uses `fetch()` without `AbortController` or explicit timeout handling. The same concern likely applies to SDK/raw GraphQL calls unless enforced below the current abstraction. |
+
+### Reliability recommendations
+
+1. **Add a narrow retry policy for safe operations.**  
+   Use the existing `retryable` classification, but only for idempotent reads or carefully chosen writes.
+
+2. **Add explicit timeout budgets around external calls.**  
+   Timeouts are reliability features because they turn hangs into failures that can be surfaced and retried intentionally.
+
+3. **Keep the compensation pattern.**  
+   `createProjectWithIssues()` is one of the better reliability designs in the repo and should be the template for future multi-step workflows.
+
+## Troubleshooting review
+
+| Pattern | Assessment | Evidence | Review |
+| --- | --- | --- | --- |
+| Startup diagnostics include build provenance and auth state | **Strong** | `src/index.ts:275-287`, `README.md:236-242`, `scripts/verify-packaged-install.mjs:95-135` | This makes stale builds and bad auth setup much easier to spot quickly. |
+| Runtime capabilities are introspectable | **Strong** | `src/features/subscriptions/handlers/subscription.handler.ts:15-27`, `src/__tests__/runtime-server.test.ts:41-70` | `linear_get_capabilities` is a useful diagnostic surface and should stay central to support workflows. |
+| Error payloads expose sanitized request IDs | **Strong** | `src/core/handlers/base.handler.ts:219-245`, `292-309`; `src/__tests__/runtime-server.test.ts:161-233` | This is exactly the kind of data needed for vendor support and cross-system incident debugging. |
+| Packaged-install smoke tests defend against stale or broken releases | **Strong** | `package.json:24-30`, `scripts/verify-packaged-install.mjs:76-135` | The repo validates the shipped package, not just local TypeScript behavior. That is a strong operational practice. |
+| Runtime observability is still sparse | **Needs improvement** | `src/index.ts:199`, `246`, `275-286`, `410` | Current logging is mostly startup and top-level error output. There is no structured per-tool logging, latency data, or request correlation at the server boundary. |
+| No lightweight diagnostics for live server health | **Needs improvement** | No equivalent beyond capability metadata | There is no cheap way to inspect session count, rate-limit frequency, refresh failures, or recent error trends. |
+| Production auth file contains implementation-history notes | **Needs improvement** | `src/auth.ts:6-22` | The "Solution Attempts" comment block documents past experiments rather than current behavior. That can mislead future maintainers during incident work. |
+
+### Troubleshooting recommendations
+
+1. **Add structured per-tool request logs.**  
+   At minimum: tool name, duration, transport, success/error, and sanitized Linear request ID when available.
+
+2. **Add a lightweight diagnostics surface.**  
+   Even a low-cost summary of session count, auth mode, recent rate-limit hits, and refresh failures would improve supportability.
+
+3. **Keep startup diagnostics and capability introspection as first-line support tools.**  
+   They are already some of the strongest troubleshooting patterns in the project.
+
+## Highest-value changes to make first
+
+1. **Fix handler dispatch allocation overhead** in `HandlerFactory`.
+2. **Add bounded concurrency** to batch issue update/delete workflows.
+3. **Add retry + timeout policy** around Linear-facing calls.
+4. **Add structured request logging** at the MCP boundary.
+5. **Split `LinearGraphQLClient` and `IssueHandler`** into smaller execution units as the codebase grows.
+
+## Patterns worth preserving
+
+- Pre-dispatch schema validation
+- Honest capability advertisement and capability errors
+- Session-scoped auth isolation for stream transport
+- Sanitized structured GraphQL failures with request IDs
+- Compensation reporting for multi-step writes
+- Built-package verification before release
+
+## Bottom line
+
+This is a **well-structured boundary-first codebase**. Its strongest qualities are correctness at the MCP edge, explicit auth/session handling, and release safety. The next maturity step is to improve **runtime efficiency and observability** so the server is not only correct, but also easier to operate under load and faster to debug when Linear or client behavior gets messy.
diff --git a/openspec/changes/add-comment-management-parity/.openspec.yaml b/openspec/changes/add-comment-management-parity/.openspec.yaml
new file mode 100644
index 0000000..23ef75a
--- /dev/null
+++ b/openspec/changes/add-comment-management-parity/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-08
diff --git a/openspec/changes/add-comment-management-parity/design.md b/openspec/changes/add-comment-management-parity/design.md
new file mode 100644
index 0000000..8f09d77
--- /dev/null
+++ b/openspec/changes/add-comment-management-parity/design.md
@@ -0,0 +1,70 @@
+## Context
+
+The current comment surface is intentionally small: the server can fetch comments for a specific issue and create a comment or reply, but it does not expose direct comment lookup, workspace comment listing, or the rest of Linear's comment lifecycle mutations. The existing issue-thread query also hard-codes ordering, omits filter support, and formats responses with a bespoke projection that is useful for summaries but not broad enough for general MCP automation.
+
+The public Linear schema and SDK support a wider comment model: direct comment reads, top-level comment collections, issue-scoped comment collections, child-comment traversal, and lifecycle mutations for update, delete, resolve, and unresolve. This design brings the server closer to that public surface while staying aligned with the repository's structured-response conventions and the in-flight platform-fidelity work.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Add first-class comment read tools for direct comment lookup and paginated comment collections.
+- Expand issue comment reads to support Linear-style pagination, ordering, archived inclusion, and filtering.
+- Add comment lifecycle tools for update, delete, resolve, and unresolve operations.
+- Standardize structured comment payloads so read and write tools expose stable identifiers, thread metadata, association metadata, and status fields.
+
+**Non-Goals:**
+- Add webhook or subscription runtime support for comment changes; that belongs to the advanced integrations change.
+- Expose every internal comment field from the public schema if it does not improve MCP workflows.
+- Rework unrelated issue, project, or auth surfaces beyond the comment-specific integration points touched by this change.
+
+## Decisions
+
+### 1. Keep the existing issue comment entry point and add complementary comment tools
+
+`linear_get_issue_comments` and `linear_create_comment` already exist in the source tree, so this change should extend that surface rather than replace it. The server should add direct and collection-oriented tools such as `linear_get_comment`, `linear_list_comments`, `linear_update_comment`, `linear_delete_comment`, `linear_resolve_comment`, and `linear_unresolve_comment` so clients can work with comments as first-class entities without overloading issue reads.
+
+This keeps the tool catalog additive and discoverable. Existing issue-thread callers continue to work, while new comment-centric automations can use dedicated tools with clearer semantics.
+
+### 2. Introduce a shared comment projection instead of bespoke handler formatting
+
+The current issue comment handler shapes response data inline and truncates parts of the thread for readability. That is fine for a narrow display-oriented tool, but it becomes hard to extend once comment reads and writes must return consistent fields across multiple tools.
+
+The implementation should introduce a shared comment-mapping layer in the comment feature or GraphQL client boundary. All comment tools should compose that shared projection so identifiers, timestamps, author data, parent linkage, resolution metadata, URL, and association identifiers stay consistent across reads and writes.
+
+### 3. Use Markdown `body` as the primary public content contract
+
+Linear's public docs treat Markdown body content as the portable contract for comments, while `bodyData` is exposed in the schema as an internal ProseMirror representation. The server should therefore make `body` the primary documented field for read and write workflows, while still allowing optional `bodyData` pass-through for advanced callers when the underlying API supports it.
+
+This keeps the public MCP contract understandable and stable without blocking richer editor-aware integrations later.
+
+### 4. Preserve Linear collection semantics instead of inventing comment-specific pagination behavior
+
+Comment collections should follow the same control surface Linear already uses: `first`, `after`, `last`, `before`, `filter`, `includeArchived`, and `orderBy`. The issue-thread read tool should be expanded to accept those arguments, and the new top-level comment list tool should expose the same semantics.
+
+Using the native collection contract avoids surprising edge cases and makes it easier for MCP clients to reason about archived comments, filtered comment sets, and continuation cursors.
+
+### 5. Keep deep thread traversal explicit
+
+Issue-level comment tools should return the current page of comments with stable thread metadata, but they should not hide arbitrary child-comment truncation behind a display-oriented formatter. Deeper traversal should be explicit through direct comment reads with child pagination or through filtered collection reads keyed by parent comment context.
+
+This reduces ambiguity about whether reply sets are complete and avoids silently dropping thread detail behind a fixed `children(first: 10)` preview.
+
+## Risks / Trade-offs
+
+- **Broader tool surface:** Adding multiple comment tools increases discovery surface. → **Mitigation:** keep names consistent with the rest of the server and group them under the comment domain.
+- **Payload growth:** Richer comment metadata can make read responses larger. → **Mitigation:** keep list payloads structured but focused, and reserve deeper thread traversal for direct comment reads.
+- **`bodyData` ambiguity:** The public schema exposes `bodyData`, but it is not the best default contract for most clients. → **Mitigation:** document `body` as primary and treat `bodyData` as optional advanced input or output.
+- **Filter-schema breadth:** Linear comment filters are broad and can be difficult to model exhaustively in strict MCP schemas. → **Mitigation:** use the repository's existing typed loose-object pattern for advanced filter pass-through where appropriate, with docs and tests around supported shapes.
+
+## Migration Plan
+
+1. Add shared GraphQL queries and mutations for direct comment reads, top-level comment listing, update, delete, resolve, and unresolve.
+2. Extend comment feature types, handlers, and tool schemas to expose the new tool surface and collection arguments.
+3. Refactor issue-thread comment loading to use the shared comment projection and native collection arguments instead of bespoke formatting-only logic.
+4. Add unit and contract tests for the new read and write tools, including pagination and thread-state cases.
+5. Update README and related documentation so the advertised MCP surface matches the implemented comment capabilities.
+
+## Open Questions
+
+- Should direct comment reads embed the first page of child replies by default, or should reply expansion remain opt-in?
+- Should `bodyData` be returned only by direct detail reads, or by list and issue-thread reads when explicitly requested?
diff --git a/openspec/changes/add-comment-management-parity/proposal.md b/openspec/changes/add-comment-management-parity/proposal.md
new file mode 100644
index 0000000..b0c29ef
--- /dev/null
+++ b/openspec/changes/add-comment-management-parity/proposal.md
@@ -0,0 +1,33 @@
+## Why
+
+The current MCP server only exposes a narrow slice of Linear's comment surface. Clients can fetch issue-scoped comments and create a comment, but they cannot load a single comment directly, enumerate comments with the platform's filter and pagination semantics, or manage comment lifecycle operations such as update, delete, resolve, and unresolve.
+
+That gap makes comment-centric workflows brittle and prevents MCP clients from matching the public Linear API for loading and managing comment threads. Closing it now also reduces ambiguity around comment body fields, thread metadata, and archived-comment behavior before more advanced integration work lands.
+
+## What Changes
+
+- Add first-class comment read tools for direct comment lookup, workspace comment listing, and richer issue-thread retrieval.
+- Expand comment read contracts to support Linear-style pagination, filtering, archived inclusion, ordering, and structured thread metadata.
+- Add first-class comment lifecycle tools for update, delete, resolve, and unresolve operations in addition to create.
+- Standardize comment payloads around Markdown body content, parent and child thread context, resolved state, association metadata, and pagination metadata.
+- Add tests and documentation for the new comment tool surface and its expected behavior.
+
+## Capabilities
+
+### New Capabilities
+- `comment-thread-loading`: Load direct comments, issue comment threads, and paginated comment collections with filtering, ordering, archived inclusion, and structured thread metadata.
+- `comment-lifecycle-management`: Create, update, delete, resolve, and unresolve comments with contracts aligned to Linear's public comment lifecycle.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\features\comments\**`
+- `src\core\types\tool.types.ts`
+- `src\core\handlers\handler.factory.ts`
+- `src\graphql\client.ts`
+- `src\graphql\queries.ts`
+- `src\graphql\mutations.ts`
+- comment-focused tests under `src\__tests__\**`
+- `README.md` and any documentation that describes the advertised tool surface
diff --git a/openspec/changes/add-comment-management-parity/specs/comment-lifecycle-management/spec.md b/openspec/changes/add-comment-management-parity/specs/comment-lifecycle-management/spec.md
new file mode 100644
index 0000000..548cc5d
--- /dev/null
+++ b/openspec/changes/add-comment-management-parity/specs/comment-lifecycle-management/spec.md
@@ -0,0 +1,34 @@
+## ADDED Requirements
+
+### Requirement: Comment creation supports root comments and threaded replies
+The server SHALL allow clients to create both issue-root comments and threaded replies using Linear's comment association and parent-comment semantics.
+
+#### Scenario: Create issue comment with markdown body
+- **WHEN** a client creates a comment with an issue identifier and markdown body
+- **THEN** the server SHALL create the comment through Linear and SHALL return a structured mutation payload for the created comment
+
+#### Scenario: Create threaded reply with parentId
+- **WHEN** a client creates a reply by providing `parentId`
+- **THEN** the server SHALL create the nested comment under that parent and SHALL return a structured mutation payload that preserves the created comment's parent linkage
+
+### Requirement: Comment lifecycle tools cover update, delete, resolve, and unresolve
+The server SHALL expose first-class tools for updating, deleting, resolving, and unresolving comments.
+
+#### Scenario: Update comment body
+- **WHEN** a client updates a comment with supported body fields
+- **THEN** the server SHALL apply the change through Linear and SHALL return the updated comment in a structured mutation payload
+
+#### Scenario: Delete comment returns stable mutation status
+- **WHEN** a client deletes a comment
+- **THEN** the server SHALL return a structured delete payload containing the deleted entity identifier and mutation success metadata
+
+#### Scenario: Resolve and unresolve comment thread
+- **WHEN** a client resolves or unresolves a comment thread
+- **THEN** the server SHALL invoke the corresponding Linear mutation and SHALL return the updated thread state in a structured mutation payload
+
+### Requirement: Markdown body remains the primary public content contract
+The server SHALL treat markdown `body` as the primary documented field for comment reads and writes while allowing optional advanced structured content fields when supported by Linear.
+
+#### Scenario: Comment write succeeds without bodyData
+- **WHEN** a client creates or updates a comment using markdown `body` without providing `bodyData`
+- **THEN** the server SHALL treat that request as valid and SHALL not require editor-specific structured content fields for normal comment workflows
diff --git a/openspec/changes/add-comment-management-parity/specs/comment-thread-loading/spec.md b/openspec/changes/add-comment-management-parity/specs/comment-thread-loading/spec.md
new file mode 100644
index 0000000..f1ed50d
--- /dev/null
+++ b/openspec/changes/add-comment-management-parity/specs/comment-thread-loading/spec.md
@@ -0,0 +1,27 @@
+## ADDED Requirements
+
+### Requirement: Direct comment reads support first-class lookup
+The server SHALL provide a direct comment read tool that loads a single Linear comment as a first-class entity instead of requiring clients to traverse through issue-scoped comment listings.
+
+#### Scenario: Get comment returns structured comment detail
+- **WHEN** a client requests a specific comment by a supported Linear identifier
+- **THEN** the server SHALL return a structured comment payload that includes the comment id, body, URL, timestamps, author metadata, parent linkage, association identifiers, and resolution metadata when available
+
+### Requirement: Issue comment thread reads preserve Linear collection semantics
+The server SHALL provide an issue comment thread read tool that accepts Linear-style collection controls and returns issue comments with pagination metadata.
+
+#### Scenario: Issue comment thread read supports paging and archive controls
+- **WHEN** a client requests comments for an issue with pagination arguments, archived inclusion, or ordering controls
+- **THEN** the server SHALL query the issue comment collection with those controls and SHALL return the matching comment nodes together with page information
+
+#### Scenario: Issue comment thread read supports comment filters
+- **WHEN** a client requests issue comments with supported comment filter criteria
+- **THEN** the server SHALL apply those filters to the underlying Linear comment collection and SHALL return only the matching comments
+
+### Requirement: Comment collections are available outside a single issue context
+The server SHALL provide a top-level comment collection tool so clients can enumerate comments with the same filter and pagination semantics that Linear exposes for the workspace-wide comment connection.
+
+#### Scenario: List comments returns filtered paginated results
+- **WHEN** a client requests a top-level comment collection with filter, pagination, archived inclusion, or ordering arguments
+- **THEN** the server SHALL return a structured comment collection payload with matching comments and page information
+
diff --git a/openspec/changes/add-comment-management-parity/tasks.md b/openspec/changes/add-comment-management-parity/tasks.md
new file mode 100644
index 0000000..afba0dc
--- /dev/null
+++ b/openspec/changes/add-comment-management-parity/tasks.md
@@ -0,0 +1,16 @@
+## 1. GraphQL and type layer
+
+- [x] 1.1 Add comment query and mutation documents for direct comment lookup, top-level comment listing, comment update, comment delete, comment resolve, and comment unresolve.
+- [x] 1.2 Extend comment feature types and the GraphQL client with typed request and response helpers for the new comment read and lifecycle operations.
+- [x] 1.3 Introduce a shared comment-mapping helper so read and write tools return consistent comment metadata and pagination fields.
+
+## 2. MCP comment tool surface
+
+- [x] 2.1 Add MCP tool schemas and handler-factory wiring for `linear_get_comment`, `linear_list_comments`, `linear_update_comment`, `linear_delete_comment`, `linear_resolve_comment`, and `linear_unresolve_comment`.
+- [x] 2.2 Expand `linear_get_issue_comments` to accept native collection controls such as filter, ordering, archived inclusion, and pagination while reusing the shared comment projection.
+- [x] 2.3 Update comment handlers so create, update, delete, resolve, and unresolve operations return structured machine-readable payloads with stable identifiers and mutation status.
+
+## 3. Validation and documentation
+
+- [x] 3.1 Add or update unit and contract tests for direct comment reads, paginated comment collections, threaded reply creation, and comment lifecycle mutations.
+- [x] 3.2 Update README and related server documentation to describe the expanded comment tool surface and the markdown-first comment content contract.
diff --git a/openspec/changes/add-issue-workflow-parity/.openspec.yaml b/openspec/changes/add-issue-workflow-parity/.openspec.yaml
new file mode 100644
index 0000000..23ef75a
--- /dev/null
+++ b/openspec/changes/add-issue-workflow-parity/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-08
diff --git a/openspec/changes/add-issue-workflow-parity/design.md b/openspec/changes/add-issue-workflow-parity/design.md
new file mode 100644
index 0000000..59cdbfd
--- /dev/null
+++ b/openspec/changes/add-issue-workflow-parity/design.md
@@ -0,0 +1,61 @@
+## Context
+
+The current issue surface covers create, batch create, batch update, filtered search, and delete, but it does not provide a detailed issue read or many of the planning fields supported by modern Linear issue mutations. Labels and workflow states are only exposed indirectly through team reads, issue relations are not first-class, and cycles are missing entirely.
+
+This proposal assumes the platform-fidelity work lands first so schema contracts, search semantics, and structured outputs are already stable.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Add a canonical detailed issue read tool for inspection before mutation.
+- Extend issue read and write models with the planning and hierarchy fields agents need for triage and sprint workflows.
+- Add explicit workflow state, label, relation, and cycle tools instead of relying on indirect or overloaded responses.
+- Keep issue results identifier-rich and structured for machine consumption.
+
+**Non-Goals:**
+- Add attachment, standalone project lifecycle, project updates, or advanced integration features.
+- Rework OAuth or GraphQL fidelity concerns that belong to the platform-fidelity change.
+- Implement every possible issue-adjacent entity in Linear if it is not required for the review's recommended parity set.
+
+## Decisions
+
+### 1. Add `linear_get_issue` as the canonical issue inspection tool
+
+Search results are not a good substitute for detailed inspection because they do not consistently expose hierarchy, relations, milestone associations, or planning context. A dedicated issue read tool should return the detailed issue model that other automations can depend on before deciding what to mutate.
+
+### 2. Extend issue inputs from the current Linear schema instead of ad hoc local fields
+
+The issue create and update contracts should be expanded from the current Linear schema surface rather than by adding custom local arguments case by case. That keeps the code aligned with the SDK baseline refreshed in the platform change and reduces future drift.
+
+### 3. Treat workflow states, labels, relations, and cycles as explicit feature surfaces
+
+These concepts drive real Linear workflows and should not be hidden inside team payloads or overloaded issue fields. The implementation can use new or expanded feature modules, but the MCP surface should make these concepts discoverable as dedicated tools.
+
+### 4. Keep hierarchy and relations distinct
+
+Parent and child issue hierarchy is not the same as broader issue relations such as blocked-by or duplicate. The read model should expose both, and relation mutations should use dedicated tools instead of trying to encode them through parent-child behavior.
+
+### 5. Make cycles part of both read tools and issue operations
+
+Cycle support is only useful if clients can both inspect cycles and use them in issue filtering and mutation flows. The cycle tools should therefore ship together with cycle-aware issue support.
+
+## Risks / Trade-offs
+
+- **Larger issue payloads:** Detailed issue reads can become verbose. Mitigation: keep the full detail in `linear_get_issue` and keep list or search results more focused.
+- **Tool surface growth:** Labels, states, relations, and cycles add several tools. Mitigation: keep naming consistent and group them by clear domain concepts.
+- **Schema breadth:** The Linear issue schema is broad and can keep evolving. Mitigation: scope this change to the review's recommended planning and triage fields.
+- **Cross-module reuse:** Teams, issues, and new cycle logic may share fragments or filters. Mitigation: centralize shared GraphQL fragments and typed connection helpers.
+
+## Migration Plan
+
+1. Add the detailed issue read tool and expand issue type models.
+2. Extend issue create, update, list, and search inputs and outputs.
+3. Add workflow state and label tools.
+4. Add relation tools and relation projection on issue reads.
+5. Add cycle tools and cycle-aware issue operations.
+
+## Open Questions
+
+- Should richer description support use markdown strings only, or should it expose document-content fields when Linear supports them?
+- Should workflow state listing be team-scoped only, or support a broader discovery mode with optional team filters?
+- How much relation detail belongs in list and search results versus the dedicated issue detail tool?
diff --git a/openspec/changes/add-issue-workflow-parity/proposal.md b/openspec/changes/add-issue-workflow-parity/proposal.md
new file mode 100644
index 0000000..ae1234a
--- /dev/null
+++ b/openspec/changes/add-issue-workflow-parity/proposal.md
@@ -0,0 +1,32 @@
+## Why
+
+After the platform-fidelity fixes, the most important remaining gaps are in the issue workflow itself. The current server cannot model several core Linear planning and triage primitives, which limits day-to-day use for agents and teams.
+
+## What Changes
+
+- Add a first-class `linear_get_issue` tool and expand issue read models with identifiers, hierarchy, relations, cycle, milestone, subscriber, and label data.
+- Expand issue create, update, list, and search contracts to cover the planning fields called out in the review, including `dueDate`, `cycleId`, `labelIds`, `parentId`, `projectMilestoneId`, `subscriberIds`, `stateId`, `delegateId`, and `templateId`.
+- Add first-class workflow state and label tools instead of exposing that information only through broader team responses.
+- Add dedicated issue relation create and delete tools and expose relation data in issue reads.
+- Add cycle read tools and cycle-aware issue filtering and mutation support.
+
+## Capabilities
+
+### New Capabilities
+- `issue-detail-and-mutation-parity`: Bring issue reads and writes closer to the current Linear issue surface used for planning and triage.
+- `workflow-state-and-label-management`: Expose workflow states and labels as first-class tools for state transitions and triage labeling.
+- `issue-relation-management`: Support issue relation reads and relation mutation workflows.
+- `cycle-management`: Expose cycle reads and cycle-aware issue operations for sprint planning.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\features\issues\**`
+- `src\features\teams\**`
+- `src\core\types\tool.types.ts`
+- `src\core\handlers\handler.factory.ts`
+- `src\graphql\queries.ts` and `src\graphql\mutations.ts`
+- issue, team, and workflow-related tests and documentation
+- possible new feature modules for cycles and relation-focused handlers or types
diff --git a/openspec/changes/add-issue-workflow-parity/specs/cycle-management/spec.md b/openspec/changes/add-issue-workflow-parity/specs/cycle-management/spec.md
new file mode 100644
index 0000000..8dc5a61
--- /dev/null
+++ b/openspec/changes/add-issue-workflow-parity/specs/cycle-management/spec.md
@@ -0,0 +1,23 @@
+## ADDED Requirements
+
+### Requirement: Cycle tools support get, list, and current-cycle reads
+The server SHALL provide tools to get a cycle by identifier, list cycles, and fetch the current cycle for a team or context supported by Linear.
+
+#### Scenario: List cycles for planning
+- **WHEN** a client requests cycles for a supported team or planning context
+- **THEN** the server SHALL return the matching cycles with identifiers, names, date ranges, and active-state metadata
+
+#### Scenario: Get the current cycle
+- **WHEN** a client requests the current cycle for a supported context
+- **THEN** the server SHALL return the active cycle or an explicit empty result when no active cycle exists
+
+### Requirement: Issue operations support cycle-aware filters and mutations
+The server SHALL support `cycleId` in issue create and update tools and SHALL allow issue list and search tools to filter by cycle-aware criteria supported by Linear.
+
+#### Scenario: Create an issue in a cycle
+- **WHEN** a client creates or updates an issue with `cycleId`
+- **THEN** the server SHALL pass that cycle assignment through to Linear and return the resulting issue state
+
+#### Scenario: Filter issues by cycle
+- **WHEN** a client requests issues filtered by a supported cycle criterion
+- **THEN** the server SHALL return the matching issues and related pagination metadata
diff --git a/openspec/changes/add-issue-workflow-parity/specs/issue-detail-and-mutation-parity/spec.md b/openspec/changes/add-issue-workflow-parity/specs/issue-detail-and-mutation-parity/spec.md
new file mode 100644
index 0000000..036bbeb
--- /dev/null
+++ b/openspec/changes/add-issue-workflow-parity/specs/issue-detail-and-mutation-parity/spec.md
@@ -0,0 +1,26 @@
+## ADDED Requirements
+
+### Requirement: Detailed issue reads expose planning and hierarchy fields
+The server SHALL provide a detailed issue read tool that returns the issue identifier together with the planning and hierarchy fields needed for triage and sprint workflows.
+
+#### Scenario: Get issue returns planning context
+- **WHEN** a client requests a specific issue
+- **THEN** the server SHALL return the issue identifier, due date, cycle, milestone, labels, parent, children, subscribers, and other supported planning fields in a structured payload
+
+### Requirement: Issue create and update support planning fields from the current Linear surface
+The server SHALL allow issue create and update operations to accept the review's recommended planning fields, including `dueDate`, `cycleId`, `labelIds`, `parentId`, `projectMilestoneId`, `subscriberIds`, `stateId`, `delegateId`, and `templateId` when supported by Linear.
+
+#### Scenario: Create issue with planning fields
+- **WHEN** a client creates an issue with supported planning, hierarchy, and workflow arguments
+- **THEN** the server SHALL pass those fields through to the corresponding Linear mutation and return the created issue in a structured response
+
+#### Scenario: Update issue with planning fields
+- **WHEN** a client updates an issue with supported planning, hierarchy, and workflow arguments
+- **THEN** the server SHALL apply those fields through the corresponding Linear mutation and return the updated issue in a structured response
+
+### Requirement: Issue collections preserve human-friendly identifiers
+Issue list and search results SHALL include Linear identifiers so clients can reference issues without a second lookup.
+
+#### Scenario: Issue list results include identifiers
+- **WHEN** a client lists or searches issues
+- **THEN** each returned issue SHALL include its human-friendly Linear identifier in the structured payload
diff --git a/openspec/changes/add-issue-workflow-parity/specs/issue-relation-management/spec.md b/openspec/changes/add-issue-workflow-parity/specs/issue-relation-management/spec.md
new file mode 100644
index 0000000..0fb4b28
--- /dev/null
+++ b/openspec/changes/add-issue-workflow-parity/specs/issue-relation-management/spec.md
@@ -0,0 +1,19 @@
+## ADDED Requirements
+
+### Requirement: Relation tools create and delete issue relations
+The server SHALL provide dedicated tools to create and delete issue relations without overloading parent-child hierarchy behavior.
+
+#### Scenario: Create a blocking relation
+- **WHEN** a client requests creation of a supported issue relation between two issues
+- **THEN** the server SHALL create that relation through Linear and return a structured mutation result
+
+#### Scenario: Delete an existing issue relation
+- **WHEN** a client requests deletion of an existing issue relation
+- **THEN** the server SHALL remove that relation through Linear and return a structured success result
+
+### Requirement: Detailed issue reads expose relation data
+The detailed issue read tool SHALL expose issue relations with relation type and linked issue identity information.
+
+#### Scenario: Get issue returns linked relations
+- **WHEN** a client requests a specific issue that has linked relations
+- **THEN** the server SHALL return those relations with relation type and linked issue identifiers in the issue payload
diff --git a/openspec/changes/add-issue-workflow-parity/specs/workflow-state-and-label-management/spec.md b/openspec/changes/add-issue-workflow-parity/specs/workflow-state-and-label-management/spec.md
new file mode 100644
index 0000000..ff9dceb
--- /dev/null
+++ b/openspec/changes/add-issue-workflow-parity/specs/workflow-state-and-label-management/spec.md
@@ -0,0 +1,19 @@
+## ADDED Requirements
+
+### Requirement: Workflow state tools expose state metadata needed for safe transitions
+The server SHALL provide workflow state tools that expose the state identifiers, names, categories, and team context needed to move issues safely through a workflow.
+
+#### Scenario: List workflow states for a team
+- **WHEN** a client requests workflow states for a team
+- **THEN** the server SHALL return the available states with their identifiers, names, types, and team context in a structured payload
+
+### Requirement: Label tools support team-scoped label lifecycle operations
+The server SHALL provide label tools that can list, create, update, and delete labels within the team or scope required by Linear.
+
+#### Scenario: Create a triage label
+- **WHEN** a client creates a label with the required team context and label fields
+- **THEN** the server SHALL create the label through Linear and return the structured label result
+
+#### Scenario: Update or delete an existing label
+- **WHEN** a client updates or deletes a previously created label
+- **THEN** the server SHALL apply the requested mutation and return a structured success result
diff --git a/openspec/changes/add-issue-workflow-parity/tasks.md b/openspec/changes/add-issue-workflow-parity/tasks.md
new file mode 100644
index 0000000..6aa74a7
--- /dev/null
+++ b/openspec/changes/add-issue-workflow-parity/tasks.md
@@ -0,0 +1,17 @@
+## 1. Issue read and write parity
+
+- [x] 1.1 Add `linear_get_issue` and expand issue GraphQL fragments and types for hierarchy, relations, milestone, cycle, subscriber, and identifier fields
+- [x] 1.2 Extend issue create and update schemas, types, and handlers with the review's recommended planning fields
+- [x] 1.3 Update issue list and search responses so identifiers and other required planning fields are preserved consistently
+
+## 2. Workflow and relation primitives
+
+- [x] 2.1 Add first-class workflow state listing tools with structured outputs
+- [x] 2.2 Add label list, create, update, and delete tools with team-scoped inputs
+- [x] 2.3 Add issue relation create and delete tools and surface issue relation data in the issue detail response
+
+## 3. Cycle support and validation
+
+- [x] 3.1 Add cycle get, list, and current-cycle tools with supporting GraphQL queries and types
+- [x] 3.2 Add cycle-aware issue filters and `cycleId` mutation support across issue handlers
+- [x] 3.3 Add tests and documentation for detailed issue reads, workflow tools, relation flows, and cycle workflows
diff --git a/openspec/changes/add-runtime-observability-diagnostics/.openspec.yaml b/openspec/changes/add-runtime-observability-diagnostics/.openspec.yaml
new file mode 100644
index 0000000..11393ea
--- /dev/null
+++ b/openspec/changes/add-runtime-observability-diagnostics/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-11
diff --git a/openspec/changes/add-runtime-observability-diagnostics/design.md b/openspec/changes/add-runtime-observability-diagnostics/design.md
new file mode 100644
index 0000000..9294121
--- /dev/null
+++ b/openspec/changes/add-runtime-observability-diagnostics/design.md
@@ -0,0 +1,60 @@
+## Context
+
+The runtime already exposes strong startup provenance and sanitized structured failures, but live troubleshooting still depends on sparse startup logs and ad hoc reproduction. The review identified two missing layers: structured per-request telemetry at the MCP boundary, and a lightweight diagnostics surface that reports live operational state without exposing secrets.
+
+This change crosses request handling, session tracking, handler wiring, tool schemas, and operator documentation. A design is useful because the diagnostics surface should add observability without breaking MCP transports, leaking sensitive data, or turning the server into a verbose logging system by default.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Emit structured per-tool request telemetry that is safe for both stdio and stream runtimes.
+- Expose a lightweight, read-only runtime diagnostics surface for troubleshooting live health signals.
+- Keep diagnostics sanitized so secrets, raw headers, and upstream payload bodies do not leak.
+- Document how telemetry, runtime diagnostics, and capability discovery fit together for operator troubleshooting.
+
+**Non-Goals:**
+- Build a full metrics backend, tracing pipeline, or external log shipper integration.
+- Persist long-term operational history across process restarts.
+- Expose secrets, raw request bodies, or sensitive upstream headers through logs or diagnostics.
+
+## Decisions
+
+### 1. Emit structured telemetry at the MCP boundary to stderr
+
+Request telemetry should be produced at the MCP server boundary, where tool name, transport, duration, and final outcome are all known. For stdio compatibility, telemetry should be emitted to stderr in a structured format rather than stdout, which is reserved for MCP protocol traffic.
+
+**Alternatives considered**
+- Log inside each individual handler: rejected because it duplicates logic and misses consistent cross-cutting fields such as total duration.
+- Emit logs to stdout: rejected because MCP stdio transport depends on stdout remaining protocol-only.
+
+### 2. Add a dedicated read-only diagnostics tool instead of overloading capabilities
+
+Static runtime capabilities and live operational diagnostics solve different problems. The server should keep `linear_get_capabilities` focused on transport and packaged runtime support, and introduce a dedicated diagnostics tool for live state such as active sessions and recent failure counters.
+
+**Alternatives considered**
+- Extend `linear_get_capabilities` with live counters: rejected because it mixes static capability discovery with volatile runtime health data.
+- Rely on logs alone: rejected because operators also need an on-demand snapshot tool.
+
+### 3. Track low-cardinality in-memory counters and sanitized identifiers only
+
+The diagnostics surface should use in-memory counters and summaries that are cheap to maintain and safe to expose: total requests, error counts, active stream sessions, recent retryable failures, auth refresh failures, and sanitized upstream request IDs when available. It should not retain tokens, auth headers, raw payloads, or unbounded request history.
+
+**Alternatives considered**
+- Store full recent request histories: rejected because it increases memory and privacy risk without being necessary for a first troubleshooting surface.
+
+## Risks / Trade-offs
+
+- **[Telemetry adds runtime overhead]** -> Keep fields low-cardinality and compute them once at the boundary.
+- **[Diagnostics can leak sensitive data if they mirror raw errors]** -> Reuse the existing sanitization posture and explicitly exclude headers, tokens, and request bodies.
+- **[In-memory counters reset on restart]** -> Treat the tool as a live troubleshooting surface, not a persistent audit system.
+
+## Migration Plan
+
+1. Add MCP-boundary telemetry emission with consistent success and failure fields.
+2. Introduce a diagnostics feature or handler and wire a read-only diagnostics tool into the runtime.
+3. Track low-cardinality counters for requests, failures, retries, auth refresh failures, and active stream sessions.
+4. Update tests and README guidance to cover diagnostics behavior and sanitization.
+
+## Open Questions
+
+- Should the first diagnostics response include per-tool counters, or start with aggregated totals plus the most recent failure summaries only?
diff --git a/openspec/changes/add-runtime-observability-diagnostics/proposal.md b/openspec/changes/add-runtime-observability-diagnostics/proposal.md
new file mode 100644
index 0000000..51dfeb8
--- /dev/null
+++ b/openspec/changes/add-runtime-observability-diagnostics/proposal.md
@@ -0,0 +1,24 @@
+## Why
+
+The server has strong startup diagnostics and structured failure payloads, but it still offers little visibility into live request behavior once the process is running. Without structured per-tool telemetry or a lightweight runtime diagnostics surface, troubleshooting latency spikes, rate limits, auth refresh problems, and session growth is slower than it needs to be.
+
+## What Changes
+
+- Add structured MCP-boundary request telemetry with tool name, transport, duration, outcome, and sanitized upstream request identifiers when available.
+- Add a lightweight runtime diagnostics surface for live operational state, including transport, auth scope or mode, session counts, and recent failure counters that help troubleshoot without attaching a debugger.
+- Document how operators use startup provenance, `linear_get_capabilities`, structured request logs, and runtime diagnostics together when troubleshooting.
+- Add focused tests that verify diagnostics stay sanitized and telemetry remains stable across stdio and stream runtimes.
+
+## Capabilities
+
+### New Capabilities
+- `mcp-request-telemetry`: the server emits structured, sanitized per-tool telemetry for request execution and failure analysis.
+- `runtime-operational-diagnostics`: operators can query lightweight live diagnostics for server health and troubleshooting signals without exposing secrets.
+
+### Modified Capabilities
+
+## Impact
+
+- Affected code: `src\index.ts`, `src\features\subscriptions\handlers\subscription.handler.ts`, any new diagnostics handler or tool schema, and runtime support code that tracks counters or session metrics.
+- Affected behavior: operators gain consistent logs and a live diagnostics surface for troubleshooting without changing core tool semantics.
+- Affected verification: runtime tests and packaged-install guidance should cover diagnostics output, sanitization, and transport-aware behavior.
diff --git a/openspec/changes/add-runtime-observability-diagnostics/specs/mcp-request-telemetry/spec.md b/openspec/changes/add-runtime-observability-diagnostics/specs/mcp-request-telemetry/spec.md
new file mode 100644
index 0000000..0f333c0
--- /dev/null
+++ b/openspec/changes/add-runtime-observability-diagnostics/specs/mcp-request-telemetry/spec.md
@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: The server SHALL emit structured per-tool request telemetry
+The server SHALL emit structured telemetry for each MCP tool request with enough information to troubleshoot latency and failures without inspecting raw protocol traffic.
+
+#### Scenario: Tool request completes
+- **WHEN** an MCP tool request completes successfully or with an error
+- **THEN** the server SHALL emit a structured telemetry record that includes the tool name, runtime transport, duration, and final outcome
+
+### Requirement: Request telemetry SHALL stay sanitized
+The server SHALL keep per-tool telemetry free of secrets and raw sensitive payload data.
+
+#### Scenario: Upstream failure contributes request metadata
+- **WHEN** telemetry includes upstream request identifiers or failure context
+- **THEN** the emitted telemetry SHALL exclude tokens, auth headers, and raw request bodies while allowing sanitized identifiers needed for troubleshooting
diff --git a/openspec/changes/add-runtime-observability-diagnostics/specs/runtime-operational-diagnostics/spec.md b/openspec/changes/add-runtime-observability-diagnostics/specs/runtime-operational-diagnostics/spec.md
new file mode 100644
index 0000000..6b060a3
--- /dev/null
+++ b/openspec/changes/add-runtime-observability-diagnostics/specs/runtime-operational-diagnostics/spec.md
@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: The server SHALL expose a read-only runtime diagnostics surface
+The server SHALL provide a read-only MCP diagnostics surface that reports lightweight live operational state for troubleshooting.
+
+#### Scenario: Operator requests runtime diagnostics
+- **WHEN** an operator invokes the runtime diagnostics tool
+- **THEN** the server SHALL return a live summary that includes transport details, auth scope or mode, active stream session count, and low-cardinality request or failure counters
+
+### Requirement: Runtime diagnostics SHALL exclude secrets
+The runtime diagnostics surface SHALL report operational health without exposing sensitive authentication or upstream request data.
+
+#### Scenario: Diagnostics include auth and upstream context
+- **WHEN** runtime diagnostics are returned to the caller
+- **THEN** the response SHALL exclude API keys, OAuth tokens, auth headers, and raw upstream payload bodies
diff --git a/openspec/changes/add-runtime-observability-diagnostics/tasks.md b/openspec/changes/add-runtime-observability-diagnostics/tasks.md
new file mode 100644
index 0000000..c7ddaaf
--- /dev/null
+++ b/openspec/changes/add-runtime-observability-diagnostics/tasks.md
@@ -0,0 +1,13 @@
+## 1. MCP Request Telemetry
+
+- [x] 1.1 Add structured stderr telemetry at the MCP boundary with tool name, transport, duration, outcome, and sanitized upstream identifiers
+- [x] 1.2 Add runtime tests that lock in telemetry shape and sanitization for both success and failure paths
+
+## 2. Runtime Diagnostics Surface
+
+- [x] 2.1 Add a read-only runtime diagnostics tool and wire low-cardinality counters plus active session tracking into the runtime
+- [x] 2.2 Add focused tests that verify diagnostics stay transport-aware, useful for troubleshooting, and free of secrets
+
+## 3. Troubleshooting Guidance
+
+- [x] 3.1 Update README and adjacent troubleshooting guidance to explain how to use capabilities, telemetry, and runtime diagnostics together
diff --git a/openspec/changes/design-advanced-linear-integrations/.openspec.yaml b/openspec/changes/design-advanced-linear-integrations/.openspec.yaml
new file mode 100644
index 0000000..23ef75a
--- /dev/null
+++ b/openspec/changes/design-advanced-linear-integrations/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-08
diff --git a/openspec/changes/design-advanced-linear-integrations/design.md b/openspec/changes/design-advanced-linear-integrations/design.md
new file mode 100644
index 0000000..4647a51
--- /dev/null
+++ b/openspec/changes/design-advanced-linear-integrations/design.md
@@ -0,0 +1,61 @@
+## Context
+
+The current repository is a stdio MCP server with no event-driven or streaming feature surface. The review recommends moving toward webhooks, subscriptions, initiatives, customers, and agent APIs, but those capabilities require runtime-aware design and stronger security guidance than the current repo provides.
+
+This proposal is intentionally sequenced after the platform, issue, and project parity changes so advanced integrations can build on a stable auth, tool-contract, and GraphQL foundation.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Add a clear design and spec surface for advanced Linear integrations that fits the current repository architecture.
+- Expose advanced capabilities only when the active runtime and transport can support them safely.
+- Make auth, security, and capability limitations explicit for operators and MCP clients.
+- Keep advanced tool outputs structured and consistent with the rest of the roadmap.
+
+**Non-Goals:**
+- Force subscription or inbound webhook delivery behavior into runtimes that cannot support it.
+- Build external hosting infrastructure inside this repository.
+- Expand unrelated issue, project, or attachment features that belong to earlier proposals.
+
+## Decisions
+
+### 1. Gate advanced capabilities on runtime support
+
+Webhook management, subscriptions, and agent workflows do not all map cleanly to a pure stdio runtime. The server should explicitly gate advanced capabilities based on transport and runtime support instead of advertising a feature that cannot actually function in the current environment.
+
+### 2. Separate webhook management from webhook delivery hosting
+
+The MCP server can manage webhook registrations through Linear's API without pretending it is also the public webhook receiver. This change should expose management tools and verification guidance while documenting the boundary between registration and externally hosted delivery endpoints.
+
+### 3. Treat subscriptions as an optional streaming capability
+
+Subscriptions should only be exposed when the runtime can sustain the streaming or long-lived semantics they need. Unsupported runtimes should return a clear capability limitation rather than a generic error or a hanging operation.
+
+### 4. Group initiatives and customers as portfolio entities
+
+Initiatives and customers both extend the server from issue-level workflows into higher-level portfolio planning. Grouping them under a portfolio entity capability gives them a shared discovery and lifecycle pattern without tying them to project CRUD.
+
+### 5. Expose agent sessions and activities as dedicated structured tools
+
+Agent APIs are a distinct product surface and should be represented with dedicated tools and structured outputs. They should not be hidden behind generic GraphQL passthrough behavior because clients need clear auth expectations and stable result shapes.
+
+## Risks / Trade-offs
+
+- **Runtime mismatch:** Some advanced features may not work in the current stdio server shape. Mitigation: capability gating and explicit unsupported-runtime responses.
+- **Security complexity:** Webhooks and agent workflows add signature, secret, and callback concerns. Mitigation: include operator guidance and explicit auth requirements in the surfaced contract.
+- **Upstream API movement:** Agent and AI-adjacent APIs may evolve quickly. Mitigation: scope the initial surface to the stable endpoints and structured contracts available at implementation time.
+- **Testing cost:** Streaming and event-driven features are harder to test than request-response tools. Mitigation: isolate runtime gating, mock transport constraints, and keep the first pass incremental.
+
+## Migration Plan
+
+1. Add capability-gating infrastructure and operator-facing documentation.
+2. Add webhook management tools and verification guidance.
+3. Add initiatives and customers support with shared portfolio patterns.
+4. Add agent session and activity tools.
+5. Add subscription support only in runtimes that satisfy the streaming requirements.
+
+## Open Questions
+
+- Should capability-gated tools be omitted entirely from the tool list, or listed with a clear unsupported-runtime behavior?
+- Which webhook verification helpers belong in code versus documentation?
+- Which agent endpoints are stable enough to expose in the first iteration?
diff --git a/openspec/changes/design-advanced-linear-integrations/proposal.md b/openspec/changes/design-advanced-linear-integrations/proposal.md
new file mode 100644
index 0000000..cdd4d14
--- /dev/null
+++ b/openspec/changes/design-advanced-linear-integrations/proposal.md
@@ -0,0 +1,30 @@
+## Why
+
+The review highlights that Linear is moving toward event-driven and AI-native workflows through webhooks, subscriptions, portfolio entities, and agent APIs. The server needs a forward-looking change that defines how to expose those capabilities without assuming runtime behavior the current stdio implementation cannot guarantee.
+
+## What Changes
+
+- Add first-class webhook management tools and define the signature-verification guidance that operators need to use them safely.
+- Add a runtime-aware subscription surface that only enables streaming behavior when the active transport can support it.
+- Add initiatives and customers support for larger portfolio and customer-facing workflows.
+- Add agent session and agent activity tools aligned with Linear's AI workflow direction.
+- Establish capability gating, auth expectations, and documentation for advanced integrations so the surface is explicit instead of implicit.
+
+## Capabilities
+
+### New Capabilities
+- `webhook-management`: Manage Linear webhooks and make verification expectations explicit.
+- `subscription-runtime-support`: Expose subscription workflows only when the active runtime can support them safely.
+- `portfolio-entity-support`: Add initiatives and customers as first-class portfolio entities.
+- `agent-api-alignment`: Add agent session and activity tools aligned with Linear's AI-oriented APIs.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- new advanced feature modules under `src\features\`
+- possible transport and capability-gating logic in `src\index.ts` and handler initialization
+- webhook, subscription, initiative, customer, and agent GraphQL operations
+- security, runtime, and operator documentation
+- tests that cover capability gating and structured advanced-tool outputs
diff --git a/openspec/changes/design-advanced-linear-integrations/specs/agent-api-alignment/spec.md b/openspec/changes/design-advanced-linear-integrations/specs/agent-api-alignment/spec.md
new file mode 100644
index 0000000..3f2b5d9
--- /dev/null
+++ b/openspec/changes/design-advanced-linear-integrations/specs/agent-api-alignment/spec.md
@@ -0,0 +1,19 @@
+## ADDED Requirements
+
+### Requirement: Agent tools manage agent sessions and activities
+The server SHALL provide dedicated tools for agent session and agent activity workflows exposed by the supported Linear API baseline.
+
+#### Scenario: Start or inspect an agent session
+- **WHEN** a client requests an agent session workflow supported by the server
+- **THEN** the server SHALL return a structured agent session result with the identifiers and state fields supported by the API
+
+#### Scenario: Create or inspect agent activity
+- **WHEN** a client requests an agent activity workflow supported by the server
+- **THEN** the server SHALL return a structured agent activity result with the identifiers and status fields supported by the API
+
+### Requirement: Agent tools surface explicit auth failures
+The server SHALL surface agent-tool auth or permission failures explicitly instead of collapsing them into generic internal errors.
+
+#### Scenario: Missing permission blocks an agent workflow
+- **WHEN** Linear rejects an agent-tool request because the caller lacks the required auth or permission
+- **THEN** the server SHALL return a structured auth or permission failure that preserves the relevant error detail
diff --git a/openspec/changes/design-advanced-linear-integrations/specs/portfolio-entity-support/spec.md b/openspec/changes/design-advanced-linear-integrations/specs/portfolio-entity-support/spec.md
new file mode 100644
index 0000000..2eac0fd
--- /dev/null
+++ b/openspec/changes/design-advanced-linear-integrations/specs/portfolio-entity-support/spec.md
@@ -0,0 +1,12 @@
+## ADDED Requirements
+
+### Requirement: Portfolio entity tools support initiatives and customers
+The server SHALL provide tools to read and mutate initiatives and customers using structured outputs consistent with the rest of the MCP surface.
+
+#### Scenario: List or get portfolio entities
+- **WHEN** a client requests initiatives or customers through supported read tools
+- **THEN** the server SHALL return structured portfolio-entity results with the identifiers and planning metadata supported by the server
+
+#### Scenario: Mutate a portfolio entity
+- **WHEN** a client creates or updates a supported initiative or customer record
+- **THEN** the server SHALL apply that mutation through Linear and return the structured result
diff --git a/openspec/changes/design-advanced-linear-integrations/specs/subscription-runtime-support/spec.md b/openspec/changes/design-advanced-linear-integrations/specs/subscription-runtime-support/spec.md
new file mode 100644
index 0000000..6343934
--- /dev/null
+++ b/openspec/changes/design-advanced-linear-integrations/specs/subscription-runtime-support/spec.md
@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: Subscription tools require a supported runtime
+The server SHALL only enable subscription workflows when the active runtime can support the streaming semantics required by those workflows.
+
+#### Scenario: Supported runtime enables subscription tools
+- **WHEN** the server runs in a runtime and transport configuration that supports the required subscription semantics
+- **THEN** the server SHALL expose or enable the subscription tools for client use
+
+### Requirement: Unsupported runtimes fail with a clear capability limitation
+The server SHALL return a clear unsupported-runtime or capability-limitation response when a subscription workflow is requested in a runtime that cannot support it.
+
+#### Scenario: Unsupported runtime rejects a subscription request clearly
+- **WHEN** a client requests a subscription workflow in a runtime that lacks the required transport support
+- **THEN** the server SHALL return a structured capability-limitation response instead of a generic internal error
diff --git a/openspec/changes/design-advanced-linear-integrations/specs/webhook-management/spec.md b/openspec/changes/design-advanced-linear-integrations/specs/webhook-management/spec.md
new file mode 100644
index 0000000..52ca2f6
--- /dev/null
+++ b/openspec/changes/design-advanced-linear-integrations/specs/webhook-management/spec.md
@@ -0,0 +1,19 @@
+## ADDED Requirements
+
+### Requirement: Webhook tools manage webhook registrations
+The server SHALL provide tools to query, create, and delete Linear webhook registrations.
+
+#### Scenario: Create a webhook registration
+- **WHEN** a client creates a webhook registration with the required endpoint and event configuration
+- **THEN** the server SHALL create the webhook through Linear and return the structured webhook result
+
+#### Scenario: Delete a webhook registration
+- **WHEN** a client deletes an existing webhook registration
+- **THEN** the server SHALL remove that webhook through Linear and return a structured success result
+
+### Requirement: Webhook management surfaces verification expectations
+The server SHALL make webhook signature-verification expectations explicit in operator-facing documentation or structured tool guidance.
+
+#### Scenario: Webhook guidance includes verification expectations
+- **WHEN** a client or operator inspects webhook-related documentation or structured guidance
+- **THEN** the server materials SHALL describe the signature-verification expectations required to validate delivered webhooks safely
diff --git a/openspec/changes/design-advanced-linear-integrations/tasks.md b/openspec/changes/design-advanced-linear-integrations/tasks.md
new file mode 100644
index 0000000..e3f617c
--- /dev/null
+++ b/openspec/changes/design-advanced-linear-integrations/tasks.md
@@ -0,0 +1,17 @@
+## 1. Runtime and security groundwork
+
+- [x] 1.1 Add capability-gating rules for advanced integrations based on runtime and transport support
+- [x] 1.2 Document security expectations for webhook verification, callback handling, and advanced auth requirements
+- [x] 1.3 Add tests for capability discovery and unsupported-runtime behavior
+
+## 2. Webhooks and portfolio entities
+
+- [x] 2.1 Add webhook query, create, and delete tools with structured outputs
+- [x] 2.2 Add initiatives and customers tools using shared portfolio-entity patterns
+- [x] 2.3 Add tests and docs for webhook management and portfolio-entity workflows
+
+## 3. Agent and subscription surface
+
+- [x] 3.1 Add agent session and activity tools with explicit auth and permission handling
+- [x] 3.2 Add subscription tooling only for supported runtimes and transports
+- [x] 3.3 Add tests and documentation for agent workflows and subscription capability gating
diff --git a/openspec/changes/enforce-mcp-tool-contracts/.openspec.yaml b/openspec/changes/enforce-mcp-tool-contracts/.openspec.yaml
new file mode 100644
index 0000000..e49efd1
--- /dev/null
+++ b/openspec/changes/enforce-mcp-tool-contracts/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-10
diff --git a/openspec/changes/enforce-mcp-tool-contracts/design.md b/openspec/changes/enforce-mcp-tool-contracts/design.md
new file mode 100644
index 0000000..582b2dc
--- /dev/null
+++ b/openspec/changes/enforce-mcp-tool-contracts/design.md
@@ -0,0 +1,55 @@
+## Context
+
+The MCP server exposes tool schemas through `tool.types.ts`, but the runtime dispatch path does not validate incoming arguments against those schemas before handing them to feature handlers. That leaves the server relying on top-level required-field checks and downstream Linear SDK failures. The same execution boundary returns raw upstream headers in structured GraphQL error payloads, which is more exposure than most MCP clients need.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Enforce advertised tool schemas at runtime before handler dispatch.
+- Return deterministic, machine-readable validation failures.
+- Sanitize structured GraphQL error metadata.
+- Keep handler-specific invariant checks where they still add value.
+
+**Non-Goals:**
+- Rewrite every handler around a new validation framework.
+- Remove all useful upstream diagnostics from error responses.
+- Redesign tool schemas beyond what is needed for enforceable runtime behavior.
+
+## Decisions
+
+### 1. Use the advertised tool schema map as the single validation source of truth
+Compile validators from the same schema objects already used for `ListTools` so the server cannot drift between what it advertises and what it enforces. Validation will happen in the `CallTool` path before a handler method is invoked.
+
+**Alternatives considered**
+- Keep manual per-handler validation: rejected because it has already drifted from the advertised contracts.
+- Create a second set of runtime-only schemas: rejected because dual sources of truth are likely to drift.
+
+### 2. Fail fast with structured validation errors
+Schema violations should produce consistent MCP error responses that identify the offending field or rule. Handlers should then treat `validateRequiredParams` as a local invariant check rather than the primary contract guard.
+
+**Alternatives considered**
+- Let invalid payloads flow into the SDK: rejected because it produces inconsistent and less actionable failures.
+
+### 3. Sanitize GraphQL error metadata with an allowlist
+Structured GraphQL errors should preserve useful diagnostics such as status, retryability, normalized GraphQL errors, and possibly a small correlation identifier, but should not forward raw upstream headers wholesale.
+
+**Alternatives considered**
+- Return all headers as today: rejected because it leaks unnecessary transport metadata.
+- Remove all upstream metadata: rejected because callers still need enough detail to reason about retryability and request failures.
+
+## Risks / Trade-offs
+
+- **[Stricter runtime validation can break permissive clients]** -> Document the change and align validation errors with the advertised schemas so the break is deterministic and correct.
+- **[Schema compilation adds startup/runtime complexity]** -> Compile validators once and reuse them rather than validating ad hoc in each handler.
+- **[Allowlisting metadata can hide a useful header]** -> Start with a minimal allowlist and expand only when a concrete client need exists.
+
+## Migration Plan
+
+1. Add schema compilation and runtime validation at the MCP boundary.
+2. Update error serialization to remove raw headers and keep approved fields only.
+3. Extend tests to cover runtime validation and error sanitization.
+4. Update any docs or client notes that depended on permissive runtime behavior.
+
+## Open Questions
+
+- Should validation failures be returned as MCP `InvalidParams` errors only, or always as structured tool errors to match the existing response style?
diff --git a/openspec/changes/enforce-mcp-tool-contracts/proposal.md b/openspec/changes/enforce-mcp-tool-contracts/proposal.md
new file mode 100644
index 0000000..d051ed8
--- /dev/null
+++ b/openspec/changes/enforce-mcp-tool-contracts/proposal.md
@@ -0,0 +1,24 @@
+## Why
+
+The server advertises strict tool schemas but does not enforce them at the MCP boundary, leaving bulk, nested, and freeform payloads to fail deep inside handlers or the Linear SDK. The same boundary also returns more upstream error metadata than most clients need, which weakens the server's reliability and security posture.
+
+## What Changes
+
+- Enforce advertised JSON Schema contracts before dispatching tool calls to handlers.
+- Normalize validation failures into consistent MCP error responses.
+- Limit structured GraphQL error payloads to safe, intentional metadata instead of forwarding all upstream headers.
+- Add regression coverage proving that schema contracts are enforced at runtime, not only declared in tool metadata.
+
+## Capabilities
+
+### New Capabilities
+- `runtime-tool-input-validation`: validate MCP tool arguments against the advertised input schemas before handler dispatch.
+- `sanitized-error-metadata`: expose only approved upstream error metadata to MCP clients.
+
+### Modified Capabilities
+
+## Impact
+
+- Affected code: `src/index.ts`, `src/core/types/tool.types.ts`, `src/core/handlers/base.handler.ts`, and related tests.
+- Affected behavior: invalid tool payloads fail fast with deterministic MCP validation errors.
+- Affected clients: MCP clients may now receive earlier validation failures for malformed requests.
diff --git a/openspec/changes/enforce-mcp-tool-contracts/specs/runtime-tool-input-validation/spec.md b/openspec/changes/enforce-mcp-tool-contracts/specs/runtime-tool-input-validation/spec.md
new file mode 100644
index 0000000..7a01469
--- /dev/null
+++ b/openspec/changes/enforce-mcp-tool-contracts/specs/runtime-tool-input-validation/spec.md
@@ -0,0 +1,16 @@
+## ADDED Requirements
+
+### Requirement: Tool calls SHALL be validated against advertised schemas
+The server SHALL validate each tool call argument object against the advertised JSON Schema for that tool before invoking its handler.
+
+#### Scenario: Invalid payload is rejected before handler dispatch
+- **WHEN** a client sends arguments that violate the tool schema
+- **THEN** the server SHALL return a structured validation error
+- **AND** the target handler SHALL NOT be invoked
+
+### Requirement: Validation errors SHALL be deterministic
+The server SHALL report validation failures using consistent machine-readable error details that identify the invalid field or rule.
+
+#### Scenario: Missing or conflicting fields surface structured details
+- **WHEN** a client omits required fields or sends mutually invalid combinations
+- **THEN** the response SHALL identify the failing field path or schema rule in structured error content
diff --git a/openspec/changes/enforce-mcp-tool-contracts/specs/sanitized-error-metadata/spec.md b/openspec/changes/enforce-mcp-tool-contracts/specs/sanitized-error-metadata/spec.md
new file mode 100644
index 0000000..78d609d
--- /dev/null
+++ b/openspec/changes/enforce-mcp-tool-contracts/specs/sanitized-error-metadata/spec.md
@@ -0,0 +1,16 @@
+## ADDED Requirements
+
+### Requirement: Structured GraphQL errors SHALL exclude raw upstream headers
+The server SHALL NOT forward the full upstream HTTP header set in structured MCP error payloads.
+
+#### Scenario: GraphQL request fails
+- **WHEN** a GraphQL or SDK-backed request fails
+- **THEN** the structured error SHALL omit raw upstream headers
+- **AND** the response MAY include only approved diagnostic fields such as status, retryability, request correlation, and normalized GraphQL errors
+
+### Requirement: Error metadata SHALL use an allowlist
+The server SHALL expose only intentionally approved upstream diagnostic metadata to MCP clients.
+
+#### Scenario: Upstream response contains extra headers
+- **WHEN** the upstream response includes headers or extensions outside the allowlist
+- **THEN** those values SHALL NOT appear in the structured MCP error payload
diff --git a/openspec/changes/enforce-mcp-tool-contracts/tasks.md b/openspec/changes/enforce-mcp-tool-contracts/tasks.md
new file mode 100644
index 0000000..58b950f
--- /dev/null
+++ b/openspec/changes/enforce-mcp-tool-contracts/tasks.md
@@ -0,0 +1,9 @@
+## 1. Runtime Tool Validation
+
+- [x] 1.1 Compile validators from the advertised tool schemas and enforce them in the `CallTool` dispatch path
+- [x] 1.2 Normalize schema validation failures into consistent structured MCP error responses
+
+## 2. Error Metadata Hardening
+
+- [x] 2.1 Replace raw upstream header passthrough with an allowlisted GraphQL error metadata shape
+- [x] 2.2 Add runtime tests covering malformed payload rejection and sanitized structured error responses
diff --git a/openspec/changes/expand-project-collaboration-parity/.openspec.yaml b/openspec/changes/expand-project-collaboration-parity/.openspec.yaml
new file mode 100644
index 0000000..23ef75a
--- /dev/null
+++ b/openspec/changes/expand-project-collaboration-parity/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-08
diff --git a/openspec/changes/expand-project-collaboration-parity/design.md b/openspec/changes/expand-project-collaboration-parity/design.md
new file mode 100644
index 0000000..4fd1aed
--- /dev/null
+++ b/openspec/changes/expand-project-collaboration-parity/design.md
@@ -0,0 +1,61 @@
+## Context
+
+The current repository can create a project together with issues, fetch a single project, and search projects narrowly by name. It does not expose attachment operations, project updates, or discovery-grade user and team tools beyond the current viewer and broad team read.
+
+This change assumes the platform-fidelity proposal has already normalized list and search semantics so collection tools can build on a stable contract.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Add dedicated attachment tools that are usable for external-system integrations.
+- Add richer standalone project lifecycle support, including planning metadata that current project work needs.
+- Add first-class project update tooling.
+- Add user and team discovery tools with structured pagination and filters.
+
+**Non-Goals:**
+- Revisit issue labels, workflow states, relations, or cycles, which belong to the issue-workflow change.
+- Implement webhook, subscription, or agent APIs.
+- Turn the MCP server into a file-upload host beyond the attachment patterns explicitly supported by Linear.
+
+## Decisions
+
+### 1. Model attachments as a dedicated feature surface
+
+Attachments have their own lifecycle and are especially valuable for integrations because they connect external URLs and metadata to issues. They should be implemented as their own tool surface instead of being hidden inside the issue handler.
+
+### 2. Separate project lifecycle from project updates
+
+Project updates are narrative collaboration artifacts, not just another field on a project mutation. Splitting them into their own capability keeps the MCP surface clearer and lets update workflows evolve without overloading project CRUD logic.
+
+### 3. Enrich project representations across read tools instead of creating a second project model
+
+The project handlers should use a richer shared project shape that includes the planning fields called out in the review, such as statuses, labels, lead or member context, and schedule fields. That shared shape can then power get, list, and search responses consistently.
+
+### 4. Treat user and team discovery as first-class collection tools
+
+Automations need to look up assignees, team keys, and related workspace data. User and team discovery should therefore expose explicit get, list, and search semantics with structured pagination rather than relying on the current viewer-only or broad team response.
+
+### 5. Keep convenience project flows layered on top of primitives
+
+`linear_create_project_with_issues` remains useful, but it should become a convenience wrapper over the richer standalone project and issue primitives rather than the only practical way to create projects.
+
+## Risks / Trade-offs
+
+- **Broader tool surface:** More project, attachment, user, and team tools increase the MCP surface area. Mitigation: keep naming consistent and reuse connection patterns.
+- **Attachment ambiguity:** Some workflows may expect direct upload handling. Mitigation: document whether the server supports URL-backed attachments only or a broader upload flow.
+- **Project payload size:** Richer project representations can grow quickly. Mitigation: keep structured summaries concise and reserve deeper detail for get-oriented tools.
+- **Workspace variance:** Teams and users can be large in enterprise Linear workspaces. Mitigation: require pagination and filters on list or search endpoints.
+
+## Migration Plan
+
+1. Add attachment queries and mutations with structured responses.
+2. Expand standalone project lifecycle operations and shared project read shapes.
+3. Add project update tools.
+4. Add user and team discovery tools with pagination and filters.
+5. Rebase existing convenience project flows on top of the richer primitives where appropriate.
+
+## Open Questions
+
+- Should the server support attachment upload mediation, or document URL-backed attachment flows only?
+- Which project member or lead fields are most important to include in the initial shared project representation?
+- Should team discovery continue to include inline workflow states and labels, or leave those to dedicated tools from the issue-workflow change?
diff --git a/openspec/changes/expand-project-collaboration-parity/proposal.md b/openspec/changes/expand-project-collaboration-parity/proposal.md
new file mode 100644
index 0000000..191e442
--- /dev/null
+++ b/openspec/changes/expand-project-collaboration-parity/proposal.md
@@ -0,0 +1,33 @@
+## Why
+
+Once issue workflows are covered, the next gaps are the collaboration surfaces around them: attachments, richer project operations, project updates, and user or team discovery. Those capabilities are essential for integrations, portfolio planning, and multi-team automation.
+
+## What Changes
+
+- Add first-class attachment tools for create, update, delete, and query flows, including the metadata fields that make attachments useful for integrations.
+- Expand project support from the current narrow surface to a fuller lifecycle that covers standalone mutations and richer project representations for planning.
+- Add first-class project update tools instead of limiting project collaboration to project creation and lookup.
+- Add user list and search support and expand team tools with get and list behavior, pagination, and filters.
+- Keep collection responses structured and paginated so larger workspaces remain automatable.
+
+## Capabilities
+
+### New Capabilities
+- `attachment-management`: Manage issue attachments as first-class integration objects.
+- `project-lifecycle-management`: Support standalone project lifecycle operations and richer project planning data.
+- `project-update-management`: Manage project updates as a dedicated collaboration surface.
+- `user-and-team-discovery`: Support user and team lookup, listing, and search workflows needed by automations.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- possible new attachment-focused feature module under `src\features\`
+- `src\features\projects\**`
+- `src\features\users\**`
+- `src\features\teams\**`
+- `src\core\types\tool.types.ts`
+- `src\core\handlers\handler.factory.ts`
+- project, user, team, and attachment GraphQL queries and mutations
+- documentation and tests for project, attachment, user, and team workflows
diff --git a/openspec/changes/expand-project-collaboration-parity/specs/attachment-management/spec.md b/openspec/changes/expand-project-collaboration-parity/specs/attachment-management/spec.md
new file mode 100644
index 0000000..290e06e
--- /dev/null
+++ b/openspec/changes/expand-project-collaboration-parity/specs/attachment-management/spec.md
@@ -0,0 +1,26 @@
+## ADDED Requirements
+
+### Requirement: Attachment tools manage attachment lifecycle operations
+The server SHALL provide tools to create, update, delete, and query attachments associated with issues.
+
+#### Scenario: Create an attachment for an issue
+- **WHEN** a client creates an attachment with the required issue reference and attachment fields
+- **THEN** the server SHALL create the attachment through Linear and return a structured attachment result
+
+#### Scenario: Update or delete an attachment
+- **WHEN** a client updates or deletes an existing attachment
+- **THEN** the server SHALL apply the requested mutation and return a structured success result
+
+### Requirement: Attachments preserve integration metadata
+Attachment tools SHALL support the metadata fields needed for integrations, including URL-backed attachments, metadata payloads, and icon URLs when supported by Linear.
+
+#### Scenario: Attachment result includes integration metadata
+- **WHEN** a client creates or fetches an attachment that includes supported metadata fields
+- **THEN** the server SHALL preserve those fields in the structured attachment payload
+
+### Requirement: Attachment creation is idempotent for the same issue and URL
+The server SHALL preserve Linear's idempotent attachment behavior for the same `(issueId, url)` pair.
+
+#### Scenario: Repeated attachment create uses the same issue and URL
+- **WHEN** a client creates an attachment for an issue using a URL that is already attached to that issue
+- **THEN** the server SHALL preserve the idempotent behavior defined by Linear instead of creating duplicate attachments in the MCP contract
diff --git a/openspec/changes/expand-project-collaboration-parity/specs/project-lifecycle-management/spec.md b/openspec/changes/expand-project-collaboration-parity/specs/project-lifecycle-management/spec.md
new file mode 100644
index 0000000..ab3abac
--- /dev/null
+++ b/openspec/changes/expand-project-collaboration-parity/specs/project-lifecycle-management/spec.md
@@ -0,0 +1,23 @@
+## ADDED Requirements
+
+### Requirement: Project tools support standalone lifecycle operations
+The server SHALL provide standalone project create, update, delete, and get operations in addition to convenience flows that create projects together with issues.
+
+#### Scenario: Create and update a standalone project
+- **WHEN** a client creates or updates a project with the fields supported by the server
+- **THEN** the server SHALL apply the corresponding Linear mutation and return the structured project result
+
+#### Scenario: Delete a standalone project
+- **WHEN** a client requests deletion of a project
+- **THEN** the server SHALL delete that project through Linear and return a structured success result
+
+### Requirement: Project reads preserve planning fields
+Project read results SHALL preserve the planning data needed for portfolio workflows, including status, labels, lead or member context, and scheduling fields supported by Linear.
+
+#### Scenario: Get project returns planning metadata
+- **WHEN** a client requests a project through a supported project read tool
+- **THEN** the server SHALL return the project's planning metadata in a structured payload
+
+#### Scenario: Project discovery results use the shared project shape
+- **WHEN** a client lists or searches projects through the discovery tools introduced by the platform-fidelity change
+- **THEN** the returned projects SHALL use the shared structured project shape for the planning fields supported by the server
diff --git a/openspec/changes/expand-project-collaboration-parity/specs/project-update-management/spec.md b/openspec/changes/expand-project-collaboration-parity/specs/project-update-management/spec.md
new file mode 100644
index 0000000..6dd30bb
--- /dev/null
+++ b/openspec/changes/expand-project-collaboration-parity/specs/project-update-management/spec.md
@@ -0,0 +1,12 @@
+## ADDED Requirements
+
+### Requirement: Project update tools manage project updates
+The server SHALL provide tools to create and update project updates associated with a Linear project.
+
+#### Scenario: Create a project update
+- **WHEN** a client creates a project update for a project with the required content and status fields
+- **THEN** the server SHALL create the update through Linear and return the structured project update result
+
+#### Scenario: Update an existing project update
+- **WHEN** a client updates an existing project update
+- **THEN** the server SHALL apply the requested mutation and return the updated structured result
diff --git a/openspec/changes/expand-project-collaboration-parity/specs/user-and-team-discovery/spec.md b/openspec/changes/expand-project-collaboration-parity/specs/user-and-team-discovery/spec.md
new file mode 100644
index 0000000..9dcb73c
--- /dev/null
+++ b/openspec/changes/expand-project-collaboration-parity/specs/user-and-team-discovery/spec.md
@@ -0,0 +1,23 @@
+## ADDED Requirements
+
+### Requirement: User tools support lookup, listing, and search
+The server SHALL provide user tools that support viewer access together with user lookup, list, and search workflows appropriate to the Linear surface exposed by the server.
+
+#### Scenario: Search users for assignment
+- **WHEN** a client searches for users to assign or mention
+- **THEN** the server SHALL return matching users with identifiers and other structured user metadata supported by the server
+
+#### Scenario: List users with pagination
+- **WHEN** a client requests a paginated user list
+- **THEN** the server SHALL return a structured user collection with pagination metadata
+
+### Requirement: Team tools support get and list semantics with filters
+The server SHALL provide team tools that can get or list teams with pagination and filter behavior supported by Linear.
+
+#### Scenario: Get a specific team
+- **WHEN** a client requests a specific team by identifier
+- **THEN** the server SHALL return the structured team result
+
+#### Scenario: List teams with filters
+- **WHEN** a client requests teams using supported filters and pagination
+- **THEN** the server SHALL return a structured team collection with pagination metadata
diff --git a/openspec/changes/expand-project-collaboration-parity/tasks.md b/openspec/changes/expand-project-collaboration-parity/tasks.md
new file mode 100644
index 0000000..a78935d
--- /dev/null
+++ b/openspec/changes/expand-project-collaboration-parity/tasks.md
@@ -0,0 +1,17 @@
+## 1. Attachment surface
+
+- [x] 1.1 Add attachment GraphQL queries, mutations, types, and handler methods for create, update, delete, and query flows
+- [x] 1.2 Define attachment tool schemas and structured outputs, including metadata and idempotent `(issueId, url)` behavior
+- [x] 1.3 Add tests and docs for attachment lifecycle and integration usage
+
+## 2. Project lifecycle and updates
+
+- [x] 2.1 Add standalone project create, update, and delete tools and expand shared project read models with planning fields
+- [x] 2.2 Add project update create and update tools with supporting GraphQL operations and types
+- [x] 2.3 Rebase convenience project flows on top of the richer project primitives where appropriate
+
+## 3. User and team discovery
+
+- [x] 3.1 Add user lookup, list, and search tools with structured pagination support
+- [x] 3.2 Add team get and list tools with structured pagination and filters
+- [x] 3.3 Add tests and documentation for project, attachment, user, and team discovery workflows
diff --git a/openspec/changes/fix-17-expose-issue-hierarchy/.openspec.yaml b/openspec/changes/fix-17-expose-issue-hierarchy/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-17-expose-issue-hierarchy/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-17-expose-issue-hierarchy/design.md b/openspec/changes/fix-17-expose-issue-hierarchy/design.md
new file mode 100644
index 0000000..7f6c1d1
--- /dev/null
+++ b/openspec/changes/fix-17-expose-issue-hierarchy/design.md
@@ -0,0 +1,47 @@
+## Context
+
+The repository has already moved toward richer issue data, but issue #17 shows that hierarchy support was still not visible to clients in a reliable way. Parent and child issues are a core planning concept and should be represented as an explicit contract rather than as an undocumented field or README claim.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make parent assignment visible in the released issue mutation contract.
+- Make hierarchy inspection visible in the canonical issue read contract.
+- Keep parent and child hierarchy distinct from broader issue-relation features.
+
+**Non-Goals:**
+- Replace or overload generic issue relations such as blocked-by or duplicate.
+- Add unrelated cycle, label, or project feature breadth.
+- Hide hierarchy support behind implementation-only fields.
+
+## Decisions
+
+### 1. Put hierarchy inputs on the issue mutation contract directly
+
+Clients should be able to see parent-assignment support on the create and update path they already use. That is more discoverable than requiring a separate relation tool or undocumented argument.
+
+### 2. Use issue detail as the canonical hierarchy read
+
+Hierarchy is most useful when clients can inspect both parent and child references on demand. The detailed issue read should therefore carry the authoritative parent and child view, with lighter read surfaces staying focused.
+
+### 3. Keep hierarchy and relations distinct
+
+Parent-child hierarchy is not the same as general issue relations. The implementation and docs should keep those concepts separate so clients do not confuse nesting with relation graphs.
+
+## Risks / Trade-offs
+
+- **Payload growth:** Child references add more data to issue reads. -> **Mitigation:** keep hierarchy detail primarily on the issue-detail tool.
+- **Surface overlap:** Hierarchy and relations can look similar in docs. -> **Mitigation:** document the distinction explicitly with examples.
+- **Discoverability drift:** Source support without released docs can recreate the same confusion. -> **Mitigation:** update schemas, examples, and tests together.
+
+## Migration Plan
+
+1. Make parent input visible on the released issue mutation path.
+2. Return parent and child references from issue-detail reads.
+3. Add regression tests for create, update, and read hierarchy workflows.
+4. Refresh README examples to show parent and child issue usage.
+
+## Open Questions
+
+- Should list or search results include lightweight parent information, or should hierarchy stay detail-only at first?
+- Do clients need an explicit example for reparenting an existing issue in the README?
diff --git a/openspec/changes/fix-17-expose-issue-hierarchy/proposal.md b/openspec/changes/fix-17-expose-issue-hierarchy/proposal.md
new file mode 100644
index 0000000..5d7e49c
--- /dev/null
+++ b/openspec/changes/fix-17-expose-issue-hierarchy/proposal.md
@@ -0,0 +1,23 @@
+## Why
+
+GitHub issue #17 reports that the README claimed parent and child issue support, but MCP clients could not find that capability in the tool schemas they received. The issue hierarchy contract needs to be explicit in schemas, reads, and documentation so clients can rely on it.
+
+## What Changes
+
+- Expose parent-reference support directly in the released issue create and update contract.
+- Return parent and child issue references in the canonical issue-detail workflow.
+- Update docs and examples so hierarchy support is discoverable without reading implementation code.
+
+## Capabilities
+
+### New Capabilities
+- `issue-hierarchy-support`: Support parent and child issue hierarchy through explicit mutation inputs, detail reads, and released documentation.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- issue create, update, and detail tool schemas
+- issue handler mapping for parent and child references
+- issue hierarchy tests and README examples
diff --git a/openspec/changes/fix-17-expose-issue-hierarchy/specs/issue-hierarchy-support/spec.md b/openspec/changes/fix-17-expose-issue-hierarchy/specs/issue-hierarchy-support/spec.md
new file mode 100644
index 0000000..078b9bd
--- /dev/null
+++ b/openspec/changes/fix-17-expose-issue-hierarchy/specs/issue-hierarchy-support/spec.md
@@ -0,0 +1,19 @@
+## ADDED Requirements
+
+### Requirement: Issue mutations support explicit parent assignment
+The server SHALL expose parent-assignment support on the released issue create and update workflow.
+
+#### Scenario: Create issue with parent reference
+- **WHEN** a client creates an issue with a supported parent reference
+- **THEN** the server SHALL persist the parent-child relationship and SHALL return issue data that identifies the parent
+
+#### Scenario: Update issue parent reference
+- **WHEN** a client updates an existing issue with a supported parent reference
+- **THEN** the server SHALL update the parent-child relationship and SHALL return issue data that identifies the resulting parent
+
+### Requirement: Issue detail returns hierarchy references
+The server SHALL return parent and child issue references in the canonical issue-detail workflow.
+
+#### Scenario: Get issue returns parent and child references
+- **WHEN** a client loads a detailed issue that participates in parent-child hierarchy
+- **THEN** the response SHALL include the linked parent reference and any child issue references available to the server
diff --git a/openspec/changes/fix-17-expose-issue-hierarchy/tasks.md b/openspec/changes/fix-17-expose-issue-hierarchy/tasks.md
new file mode 100644
index 0000000..deea559
--- /dev/null
+++ b/openspec/changes/fix-17-expose-issue-hierarchy/tasks.md
@@ -0,0 +1,14 @@
+## 1. Mutation schema
+
+- [x] 1.1 Expose parent-assignment support clearly on the released issue create and update path.
+- [x] 1.2 Ensure hierarchy inputs remain distinct from generic issue-relation workflows.
+
+## 2. Read behavior
+
+- [x] 2.1 Return parent and child references from the canonical issue-detail workflow.
+- [x] 2.2 Add regression coverage for creating, updating, and reading parent-child issue links.
+
+## 3. Documentation
+
+- [x] 3.1 Update README and tool examples to show parent and child issue workflows.
+- [x] 3.2 Document the difference between hierarchy support and general issue relations.
diff --git a/openspec/changes/fix-19-support-project-assignment-updates/.openspec.yaml b/openspec/changes/fix-19-support-project-assignment-updates/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-19-support-project-assignment-updates/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-19-support-project-assignment-updates/design.md b/openspec/changes/fix-19-support-project-assignment-updates/design.md
new file mode 100644
index 0000000..ea76777
--- /dev/null
+++ b/openspec/changes/fix-19-support-project-assignment-updates/design.md
@@ -0,0 +1,47 @@
+## Context
+
+The repository already supports project assignment during issue creation, but issue #19 shows that the update path is still confusing or unreliable for existing issues. The current surface also centers updates around batch semantics, which makes the single-issue project-assignment workflow less obvious than it should be.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make project assignment on existing issues a supported, testable update workflow.
+- Clarify the single-issue update path clients should use.
+- Define explicit behavior for setting, changing, and clearing project association.
+
+**Non-Goals:**
+- Rework unrelated issue fields or project lifecycle operations.
+- Force clients to use undocumented side effects to clear project assignment.
+- Replace batch update support for multi-issue workflows.
+
+## Decisions
+
+### 1. Treat project assignment as a first-class issue mutation
+
+Existing issues should be able to join or leave projects through the same issue-update surface that handles other planning changes. Clients should not need a project-specific workaround to move an issue into a project.
+
+### 2. Keep single-issue ergonomics explicit
+
+Whether the implementation uses the current batch update tool with one issue id or introduces a dedicated alias, the released surface should make the single-issue project-assignment path obvious in schemas and docs.
+
+### 3. Separate clear semantics from omission
+
+The update contract should distinguish between leaving the current project unchanged and intentionally clearing the current project. That behavior must be explicit so client calls are predictable.
+
+## Risks / Trade-offs
+
+- **Contract choice:** Adding a single-issue alias improves clarity but expands the tool surface. -> **Mitigation:** preserve the batch path and document the preferred single-issue flow.
+- **Clear behavior:** Removing a project link may require a different input shape from setting one. -> **Mitigation:** decide and document a single supported clear-project contract.
+- **Regression overlap:** Issue-update changes can affect other planning fields. -> **Mitigation:** keep regression tests focused on project-assignment behavior and existing update coverage.
+
+## Migration Plan
+
+1. Confirm the supported single-issue update path for project assignment.
+2. Implement explicit set, change, and clear behavior for `projectId`.
+3. Add regression tests for existing-issue project movement.
+4. Update docs and examples for the supported issue-update workflow.
+
+## Open Questions
+
+- Should clearing project assignment use a nullable `projectId`, a dedicated clear flag, or another explicit contract?
+- Is a dedicated `linear_update_issue` alias worth shipping for clarity, or is stronger documentation on the current update path sufficient?
diff --git a/openspec/changes/fix-19-support-project-assignment-updates/proposal.md b/openspec/changes/fix-19-support-project-assignment-updates/proposal.md
new file mode 100644
index 0000000..ce0a3cb
--- /dev/null
+++ b/openspec/changes/fix-19-support-project-assignment-updates/proposal.md
@@ -0,0 +1,23 @@
+## Why
+
+GitHub issue #19 reports that existing issues cannot be assigned to projects through the issue-update workflow, even though project assignment is expected to work for new issues. The issue-update contract needs an explicit, tested project-assignment path for existing issues.
+
+## What Changes
+
+- Ensure the supported issue-update path accepts project-assignment changes for existing issues.
+- Define how clients set, change, and clear a project's association on an existing issue without relying on undocumented behavior.
+- Add regression tests and documentation for project assignment through issue updates.
+
+## Capabilities
+
+### New Capabilities
+- `issue-project-assignment-updates`: Support project assignment changes on existing issues through the released issue-update workflow.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- issue update tool schemas and handler logic
+- any shared issue input types used for update operations
+- issue-mutation tests and README examples
diff --git a/openspec/changes/fix-19-support-project-assignment-updates/specs/issue-project-assignment-updates/spec.md b/openspec/changes/fix-19-support-project-assignment-updates/specs/issue-project-assignment-updates/spec.md
new file mode 100644
index 0000000..595daf3
--- /dev/null
+++ b/openspec/changes/fix-19-support-project-assignment-updates/specs/issue-project-assignment-updates/spec.md
@@ -0,0 +1,19 @@
+## ADDED Requirements
+
+### Requirement: Existing issues support project-assignment updates
+The server SHALL let clients set, change, and clear a project's association on an existing issue through the supported issue-update workflow.
+
+#### Scenario: Issue update assigns an existing issue to a project
+- **WHEN** a client updates an existing issue with a supported project reference
+- **THEN** the server SHALL persist the new project association and SHALL return issue data that reflects the linked project
+
+#### Scenario: Issue update clears an existing issue's project association
+- **WHEN** a client calls the supported issue-update workflow with the explicit clear-project input
+- **THEN** the server SHALL remove the project's association from the issue and SHALL return issue data without a linked project
+
+### Requirement: Project assignment is advertised on the released update path
+The server SHALL expose project-assignment support in the schema and documentation for the released single-issue update workflow.
+
+#### Scenario: Released update contract shows project-assignment support
+- **WHEN** a client inspects the released tool schema or README examples for the supported issue-update path
+- **THEN** the project-assignment field and its supported clear behavior SHALL be described explicitly
diff --git a/openspec/changes/fix-19-support-project-assignment-updates/tasks.md b/openspec/changes/fix-19-support-project-assignment-updates/tasks.md
new file mode 100644
index 0000000..9ba9b7b
--- /dev/null
+++ b/openspec/changes/fix-19-support-project-assignment-updates/tasks.md
@@ -0,0 +1,14 @@
+## 1. Update contract
+
+- [x] 1.1 Confirm the released single-issue update path and expose project-assignment support clearly in its schema.
+- [x] 1.2 Define and implement explicit set, change, and clear semantics for project assignment on existing issues.
+
+## 2. Handler behavior
+
+- [x] 2.1 Wire the issue-update handler to persist project-assignment changes for one existing issue.
+- [x] 2.2 Add regression coverage for assigning, changing, and clearing project membership on existing issues.
+
+## 3. Documentation
+
+- [x] 3.1 Update README and tool examples to show how to move an existing issue into a project.
+- [x] 3.2 Document the supported clear-project behavior so clients do not rely on omission semantics.
diff --git a/openspec/changes/fix-20-clarify-stream-transport-support/.openspec.yaml b/openspec/changes/fix-20-clarify-stream-transport-support/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-20-clarify-stream-transport-support/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-20-clarify-stream-transport-support/design.md b/openspec/changes/fix-20-clarify-stream-transport-support/design.md
new file mode 100644
index 0000000..d7d7ba3
--- /dev/null
+++ b/openspec/changes/fix-20-clarify-stream-transport-support/design.md
@@ -0,0 +1,51 @@
+## Context
+
+The current server entrypoint only starts `StdioServerTransport`, but users are still trying to connect to a remote `/sse` endpoint. That mismatch creates timeouts and confusion about whether the project is stdio-only, Cline-only, or generally usable with other MCP clients.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make the supported transport modes explicit and machine-discernible.
+- Support a documented remote streaming deployment path or fail fast when only stdio is available.
+- Keep capability advertisement consistent with the active transport.
+
+**Non-Goals:**
+- Build arbitrary hosting infrastructure inside the repository.
+- Add unrelated feature breadth beyond transport interoperability.
+- Pretend that stdio deployments expose a remote endpoint when they do not.
+
+## Decisions
+
+### 1. Choose transport mode explicitly at startup
+
+The server should start in an explicit transport mode rather than implying that stream-capable runtime flags automatically create a remote endpoint. That keeps startup behavior aligned with the actual transport implementation.
+
+### 2. Keep stdio as the default and remote stream as opt-in
+
+Local stdio execution is still the safest default for current usage, but remote clients need a supported path when stream mode is intentionally enabled. Making remote transport opt-in avoids accidental exposure while still enabling interoperability.
+
+### 3. Reflect transport truth in capabilities and docs
+
+The runtime capability surface, startup messaging, and docs should all agree on whether remote streaming is supported. A client should never infer `/sse` support from a capability flag that does not correspond to an active server transport.
+
+### 4. Fail fast on unsupported remote assumptions
+
+If the server is running in stdio-only mode, the docs and runtime behavior should make that obvious immediately rather than letting clients hang on a guessed endpoint.
+
+## Risks / Trade-offs
+
+- **Additional server complexity:** Remote transport introduces more startup and test paths. -> **Mitigation:** keep the transport abstraction narrow and default to stdio.
+- **Security exposure:** Remote endpoints can be exposed accidentally. -> **Mitigation:** require explicit configuration and document deployment expectations.
+- **Interop variance:** Different MCP clients may expect different stream flavors. -> **Mitigation:** target one documented MCP-compatible remote transport and test it directly.
+
+## Migration Plan
+
+1. Introduce explicit transport selection at startup.
+2. Add the supported remote stream implementation or explicit stdio-only guardrails.
+3. Align capability advertisement with the active transport.
+4. Update docs with remote-client setup and stdio-only guidance.
+
+## Open Questions
+
+- Which MCP remote transport should be the first supported network mode for this repository?
+- Should remote transport live in the main entrypoint or in a separate bootstrap command?
diff --git a/openspec/changes/fix-20-clarify-stream-transport-support/proposal.md b/openspec/changes/fix-20-clarify-stream-transport-support/proposal.md
new file mode 100644
index 0000000..f5b7e39
--- /dev/null
+++ b/openspec/changes/fix-20-clarify-stream-transport-support/proposal.md
@@ -0,0 +1,24 @@
+## Why
+
+GitHub issue #20 shows users attempting to connect through an `/sse` endpoint and timing out because the server's transport story is ambiguous. The project needs an explicit interoperability contract for stdio versus remote streaming so non-Cline clients do not have to guess.
+
+## What Changes
+
+- Add a clear transport contract for local stdio usage and remote streaming deployments.
+- Provide a supported remote streaming entrypoint or fail-fast behavior when the server is running in stdio-only mode.
+- Align runtime capability advertisement and documentation with the active transport so clients know whether remote connections are supported.
+
+## Capabilities
+
+### New Capabilities
+- `remote-stream-transport-support`: Support a documented remote streaming transport mode and keep capability advertisement aligned with the active transport.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\index.ts`
+- runtime capability detection and subscription gating
+- deployment and interoperability documentation for non-stdio clients
+- transport and interop tests
diff --git a/openspec/changes/fix-20-clarify-stream-transport-support/specs/remote-stream-transport-support/spec.md b/openspec/changes/fix-20-clarify-stream-transport-support/specs/remote-stream-transport-support/spec.md
new file mode 100644
index 0000000..8b8d943
--- /dev/null
+++ b/openspec/changes/fix-20-clarify-stream-transport-support/specs/remote-stream-transport-support/spec.md
@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: Server startup supports an explicit remote stream transport mode
+The server SHALL support an explicit startup mode for the documented remote streaming transport in addition to stdio mode.
+
+#### Scenario: Remote stream mode starts a network-accessible MCP endpoint
+- **WHEN** the server is started in the supported remote stream transport mode
+- **THEN** it SHALL expose the documented MCP-compatible remote endpoint for client connections
+
+### Requirement: Stdio deployments do not imply a remote endpoint
+The server SHALL make stdio-only operation explicit so clients do not assume `/sse` or another remote endpoint exists.
+
+#### Scenario: Stdio mode advertises no remote endpoint
+- **WHEN** the server is started in stdio mode
+- **THEN** its startup guidance and documentation SHALL indicate that no remote stream endpoint is available
+
+### Requirement: Capability advertisement matches the active transport
+The server SHALL report runtime capability information that matches the transport mode it actually started.
+
+#### Scenario: Runtime capabilities reflect stdio mode
+- **WHEN** the server is running in stdio mode
+- **THEN** any transport or streaming capability output SHALL report stdio semantics and SHALL not claim remote stream availability
diff --git a/openspec/changes/fix-20-clarify-stream-transport-support/tasks.md b/openspec/changes/fix-20-clarify-stream-transport-support/tasks.md
new file mode 100644
index 0000000..1a06ee5
--- /dev/null
+++ b/openspec/changes/fix-20-clarify-stream-transport-support/tasks.md
@@ -0,0 +1,14 @@
+## 1. Transport contract
+
+- [x] 1.1 Add explicit startup configuration for stdio versus supported remote stream transport.
+- [x] 1.2 Ensure the active transport mode is surfaced clearly in startup output and runtime capability metadata.
+
+## 2. Remote interoperability
+
+- [x] 2.1 Implement the supported remote stream transport path or explicit stdio-only guardrails for remote connection attempts.
+- [x] 2.2 Add interop coverage that exercises the supported remote path and verifies stdio mode does not imply an `/sse` endpoint.
+
+## 3. Documentation
+
+- [x] 3.1 Update README and deployment guidance for non-Cline or ngrok-based clients.
+- [x] 3.2 Document which transport modes support streaming-only capabilities and which remain stdio-only.
diff --git a/openspec/changes/fix-23-add-initiative-support/.openspec.yaml b/openspec/changes/fix-23-add-initiative-support/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-23-add-initiative-support/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-23-add-initiative-support/design.md b/openspec/changes/fix-23-add-initiative-support/design.md
new file mode 100644
index 0000000..7cccd71
--- /dev/null
+++ b/openspec/changes/fix-23-add-initiative-support/design.md
@@ -0,0 +1,47 @@
+## Context
+
+The source tree already contains initiative CRUD handlers, but issue #23 asks for a fuller workflow that is useful in practice and contribution-ready. The most obvious remaining gap is project association: the current portfolio and project surfaces do not expose an initiative link that teams can manage through the MCP server.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Let project workflows set, change, and clear initiative associations.
+- Return enough initiative and project metadata for clients to inspect the link after mutation.
+- Document and test the initiative surface so users can rely on what is actually shipped.
+
+**Non-Goals:**
+- Expand unrelated customer or agent capabilities.
+- Rebuild project lifecycle logic that is not affected by initiative association.
+- Depend on informal contribution guidance outside the repository docs.
+
+## Decisions
+
+### 1. Keep initiative CRUD in the portfolio domain and association in project flows
+
+Initiatives are portfolio entities, but the association is exercised through project creation and update flows. The implementation should therefore keep initiative lifecycle handlers in `features\portfolio` while extending project inputs and mapping for the association itself.
+
+### 2. Return linked initiative metadata in project-oriented reads
+
+A project mutation that sets or clears an initiative should return the resulting initiative linkage in the structured project payload. That makes the workflow inspectable without forcing a second round-trip for every mutation.
+
+### 3. Treat documentation and tests as part of the capability
+
+This issue exists partly because users need confidence about what is supported and worth upstreaming. The initiative capability should therefore include contract tests and released documentation instead of leaving that work as optional cleanup.
+
+## Risks / Trade-offs
+
+- **Cross-domain touch points:** Portfolio and project handlers both need updates. -> **Mitigation:** keep the association field mapping small and shared.
+- **Linear model variance:** Initiative linkage may have workspace-specific limits. -> **Mitigation:** scope the first pass to the supported project association shape available in the SDK or GraphQL schema.
+- **Surface drift:** Source support without released docs can recreate the same issue later. -> **Mitigation:** tie tests and docs to the shipped catalog.
+
+## Migration Plan
+
+1. Extend project inputs and project mapping with initiative association support.
+2. Reuse existing initiative handlers for linked reads where needed.
+3. Add tests for association set, change, and clear workflows.
+4. Update README and contribution-facing docs to describe the released initiative support.
+
+## Open Questions
+
+- Should list-project responses always include linked initiative summary data, or only project-detail and mutation responses?
+- Is project-association support sufficient for the first pass, or are initiative-specific search filters also needed immediately?
diff --git a/openspec/changes/fix-23-add-initiative-support/proposal.md b/openspec/changes/fix-23-add-initiative-support/proposal.md
new file mode 100644
index 0000000..4bb8d01
--- /dev/null
+++ b/openspec/changes/fix-23-add-initiative-support/proposal.md
@@ -0,0 +1,25 @@
+## Why
+
+GitHub issue #23 asks for initiative support that is practical for real planning workflows and contribution-ready for upstreaming. The repository already has basic initiative operations in source, but it still needs a complete, documented workflow that covers project association and released tool-surface expectations.
+
+## What Changes
+
+- Add initiative-to-project association support so project workflows can set, change, and clear an initiative reference.
+- Expand initiative and project responses enough to make the association visible in normal planning reads.
+- Document and test the initiative surface so the released tool catalog and contribution expectations are clear.
+
+## Capabilities
+
+### New Capabilities
+- `initiative-project-association`: Support initiative lifecycle workflows that include project association and released documentation parity.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\features\portfolio\**`
+- `src\features\projects\**`
+- `src\core\types\tool.types.ts`
+- `src\core\handlers\handler.factory.ts`
+- initiative and project tests plus README coverage
diff --git a/openspec/changes/fix-23-add-initiative-support/specs/initiative-project-association/spec.md b/openspec/changes/fix-23-add-initiative-support/specs/initiative-project-association/spec.md
new file mode 100644
index 0000000..37c4b44
--- /dev/null
+++ b/openspec/changes/fix-23-add-initiative-support/specs/initiative-project-association/spec.md
@@ -0,0 +1,19 @@
+## ADDED Requirements
+
+### Requirement: Projects support initiative association updates
+The server SHALL let clients set, change, and clear an initiative association when creating or updating a project through the MCP surface.
+
+#### Scenario: Project update assigns an initiative
+- **WHEN** a client updates a project with a supported initiative reference
+- **THEN** the server SHALL persist the association and SHALL return project data that includes the linked initiative summary
+
+#### Scenario: Project update clears an initiative association
+- **WHEN** a client updates a project to remove the initiative reference
+- **THEN** the server SHALL clear the association and SHALL return the updated project data without a linked initiative
+
+### Requirement: Initiative support is documented and tested as a released workflow
+The server SHALL document and test the released initiative lifecycle and project-association workflow.
+
+#### Scenario: Released docs advertise initiative workflows consistently
+- **WHEN** a user reviews the released README or tool catalog
+- **THEN** the initiative lifecycle and project-association workflows SHALL be described consistently with the shipped MCP surface
diff --git a/openspec/changes/fix-23-add-initiative-support/tasks.md b/openspec/changes/fix-23-add-initiative-support/tasks.md
new file mode 100644
index 0000000..b75214f
--- /dev/null
+++ b/openspec/changes/fix-23-add-initiative-support/tasks.md
@@ -0,0 +1,14 @@
+## 1. Initiative association contract
+
+- [x] 1.1 Extend project create and update inputs to support setting, changing, and clearing an initiative association.
+- [x] 1.2 Update structured project mapping so linked initiative metadata is visible after reads and mutations.
+
+## 2. Handler implementation
+
+- [x] 2.1 Wire project handlers to persist initiative association changes using the supported Linear API shape.
+- [x] 2.2 Reuse initiative mapping or read helpers where needed so project and portfolio views stay consistent.
+
+## 3. Validation and documentation
+
+- [x] 3.1 Add contract tests for initiative association workflows on projects.
+- [x] 3.2 Update README and contribution-facing documentation to describe the released initiative tool surface and project-link workflow.
diff --git a/openspec/changes/fix-24-correct-linear-oauth-flow/.openspec.yaml b/openspec/changes/fix-24-correct-linear-oauth-flow/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-24-correct-linear-oauth-flow/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-24-correct-linear-oauth-flow/design.md b/openspec/changes/fix-24-correct-linear-oauth-flow/design.md
new file mode 100644
index 0000000..c2acfef
--- /dev/null
+++ b/openspec/changes/fix-24-correct-linear-oauth-flow/design.md
@@ -0,0 +1,47 @@
+## Context
+
+The current OAuth helper still carries parameters that do not match Linear's supported authorization flow, and the single-use state requirement is not obvious to callers. Because OAuth is already sensitive to redirect, token, and state mismatches, the contract needs to be precise and well documented.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Generate authorization URLs that use only supported Linear OAuth parameters.
+- Keep callback-state validation strict and single-use.
+- Make the auth tool outputs and docs clear enough that clients do not reuse stale links accidentally.
+
+**Non-Goals:**
+- Introduce persistent credential storage or long-lived session recovery.
+- Add browser hosting or redirect infrastructure inside this repository.
+- Change the API-key auth path.
+
+## Decisions
+
+### 1. Restrict the authorization URL to documented Linear parameters
+
+The authorization URL should include only the parameters Linear expects for app-based OAuth. Unsupported scope fragments and offline-only parameters should be removed rather than left in place as harmless-looking extras.
+
+### 2. Keep state validation strict and single-use
+
+The issued OAuth state should remain bound to a single pending authorization request and be cleared after successful exchange. Reuse and mismatch should continue to fail, but the error and docs should make that behavior explicit.
+
+### 3. Surface callback requirements directly in the auth workflow
+
+The `linear_auth` response and documentation should tell clients that both `code` and the freshly issued `state` must be supplied to `linear_auth_callback`. That reduces confusion when a caller copies an old URL or omits the state value.
+
+## Risks / Trade-offs
+
+- **Client expectation changes:** Some callers may have built around the old URL shape. -> **Mitigation:** document the corrected contract clearly and keep the tool names stable.
+- **State lifecycle strictness:** One-time state makes retries more explicit but less forgiving. -> **Mitigation:** make the retry path obvious by issuing a fresh authorization URL.
+- **OAuth surface complexity:** The flow remains sensitive to redirect and credential setup. -> **Mitigation:** separate configuration guidance from runtime error reporting.
+
+## Migration Plan
+
+1. Correct the OAuth URL parameter set.
+2. Keep callback validation strict while clarifying the state lifecycle.
+3. Add tests for URL generation and reused-state rejection.
+4. Refresh README and auth guidance with the corrected flow.
+
+## Open Questions
+
+- Should the auth response include a short reminder that the authorization URL is single-use?
+- Do any existing helper scripts need output changes to surface the returned state more clearly?
diff --git a/openspec/changes/fix-24-correct-linear-oauth-flow/proposal.md b/openspec/changes/fix-24-correct-linear-oauth-flow/proposal.md
new file mode 100644
index 0000000..6ab6e90
--- /dev/null
+++ b/openspec/changes/fix-24-correct-linear-oauth-flow/proposal.md
@@ -0,0 +1,24 @@
+## Why
+
+GitHub issue #24 reports that the generated Linear OAuth URL includes unsupported scope and parameter values, and that stale authorization links lead to confusing state failures. The OAuth flow needs to match Linear's actual contract so remote auth attempts fail only for real user or credential errors.
+
+## What Changes
+
+- Generate Linear-compatible authorization URLs without unsupported `offline_access` scope or `access_type=offline` parameters.
+- Preserve callback-state validation while making the state contract explicitly single-use and clearly surfaced to clients.
+- Update tests and docs so the OAuth tool pair explains the issued state, callback requirements, and stale-link behavior.
+
+## Capabilities
+
+### New Capabilities
+- `linear-oauth-flow-correctness`: Keep OAuth authorization URLs, callback validation, and user guidance aligned with Linear's supported flow.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\auth.ts`
+- OAuth-related handlers and any auth response summaries
+- OAuth tests and helper scripts
+- README authentication guidance
diff --git a/openspec/changes/fix-24-correct-linear-oauth-flow/specs/linear-oauth-flow-correctness/spec.md b/openspec/changes/fix-24-correct-linear-oauth-flow/specs/linear-oauth-flow-correctness/spec.md
new file mode 100644
index 0000000..2f98e18
--- /dev/null
+++ b/openspec/changes/fix-24-correct-linear-oauth-flow/specs/linear-oauth-flow-correctness/spec.md
@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: OAuth authorization URLs use only supported Linear parameters
+The server SHALL generate Linear OAuth authorization URLs that omit unsupported offline-only parameters.
+
+#### Scenario: Generated URL excludes unsupported offline parameters
+- **WHEN** a client calls `linear_auth`
+- **THEN** the returned authorization URL SHALL not include `offline_access` in the scope or `access_type=offline`
+
+### Requirement: OAuth callback state is single-use
+The server SHALL require `linear_auth_callback` to receive the current issued state and SHALL reject reused or mismatched state values.
+
+#### Scenario: Reused or mismatched state is rejected
+- **WHEN** a client calls `linear_auth_callback` with a state that was not issued for the current pending authorization request
+- **THEN** the server SHALL reject the callback with a clear state-validation error
+
+### Requirement: OAuth workflow guidance includes the returned state
+The server SHALL tell callers that `linear_auth_callback` requires both the authorization `code` and the newly issued `state`.
+
+#### Scenario: Auth response explains callback inputs
+- **WHEN** a client initializes OAuth with `linear_auth`
+- **THEN** the response guidance SHALL tell the client to pass both the returned `state` and the authorization `code` to `linear_auth_callback`
diff --git a/openspec/changes/fix-24-correct-linear-oauth-flow/tasks.md b/openspec/changes/fix-24-correct-linear-oauth-flow/tasks.md
new file mode 100644
index 0000000..ef11118
--- /dev/null
+++ b/openspec/changes/fix-24-correct-linear-oauth-flow/tasks.md
@@ -0,0 +1,14 @@
+## 1. Authorization URL correctness
+
+- [x] 1.1 Remove unsupported Linear OAuth scope or parameter values from authorization URL generation.
+- [x] 1.2 Verify the generated URL still preserves the required client, redirect, response type, actor, and state inputs.
+
+## 2. Callback and state handling
+
+- [x] 2.1 Keep callback validation single-use and ensure reused or mismatched state errors remain explicit.
+- [x] 2.2 Update auth tool responses or helper output so callers know they must pass the newly issued `state` to `linear_auth_callback`.
+
+## 3. Validation and docs
+
+- [x] 3.1 Add tests for authorization URL contents and stale-state rejection.
+- [x] 3.2 Update README and auth guidance to describe the corrected Linear OAuth flow.
diff --git a/openspec/changes/fix-30-repair-query-backed-issue-search/.openspec.yaml b/openspec/changes/fix-30-repair-query-backed-issue-search/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-30-repair-query-backed-issue-search/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-30-repair-query-backed-issue-search/design.md b/openspec/changes/fix-30-repair-query-backed-issue-search/design.md
new file mode 100644
index 0000000..e5850c8
--- /dev/null
+++ b/openspec/changes/fix-30-repair-query-backed-issue-search/design.md
@@ -0,0 +1,47 @@
+## Context
+
+The failure in issue #30 is a contract bug: the MCP tool accepts a free-text query but the backend path behaves like a filtered listing and triggers a GraphQL validation error. Search needs its own verified execution path and regression tests so the contract stops drifting.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make `linear_search_issues` succeed when a client provides `query`.
+- Keep text search semantics distinct from filtered list semantics.
+- Return structured results with pagination metadata that remain stable for callers.
+
+**Non-Goals:**
+- Expand unrelated issue fields or add new issue-management domains.
+- Hide search failures behind fallback list behavior.
+- Rework project search or auth behavior in this change.
+
+## Decisions
+
+### 1. Use a true query-aware search backend
+
+The handler should call a search-specific SDK or GraphQL path that accepts the free-text query explicitly. Query-backed search should not be emulated by inventing unsupported fields on `IssueFilter`.
+
+### 2. Keep search and list as separate contracts
+
+`linear_list_issues` should remain the filter-and-pagination entry point, while `linear_search_issues` should remain the free-text search entry point. Keeping them separate preserves predictable semantics and aligns with the user-visible tool names.
+
+### 3. Regression-test the exact failure mode
+
+The implementation should add tests that exercise a non-empty `query`, optional filters, and pagination so the invalid `IssueFilter.search` pattern cannot silently return.
+
+## Risks / Trade-offs
+
+- **Search API variance:** Linear search semantics may differ from list filters. -> **Mitigation:** document the difference and test supported combinations.
+- **Result-shape drift:** Search endpoints can return data shaped differently from list endpoints. -> **Mitigation:** map search results through the existing structured issue summary projection.
+- **Regression breadth:** Search bugs can hide behind happy-path mocks. -> **Mitigation:** add targeted tests for the reported failure and mixed query/filter cases.
+
+## Migration Plan
+
+1. Replace the invalid query execution path with a search-aware call.
+2. Reuse the structured issue mapping for search results.
+3. Add regression tests covering query input and mixed filter usage.
+4. Update README examples to describe the repaired semantics.
+
+## Open Questions
+
+- Should empty-string queries be rejected at schema validation time or handler validation time?
+- Which optional filters should remain supported on top of free-text search in the first pass?
diff --git a/openspec/changes/fix-30-repair-query-backed-issue-search/proposal.md b/openspec/changes/fix-30-repair-query-backed-issue-search/proposal.md
new file mode 100644
index 0000000..9947e96
--- /dev/null
+++ b/openspec/changes/fix-30-repair-query-backed-issue-search/proposal.md
@@ -0,0 +1,24 @@
+## Why
+
+GitHub issue #30 shows that `linear_search_issues` accepts a `query` argument but fails at runtime with a GraphQL error instead of returning results. The search contract needs to be repaired so the MCP surface matches the behavior it advertises.
+
+## What Changes
+
+- Route `linear_search_issues` through a query-aware Linear search path instead of an invalid filter-only path.
+- Keep filtered listing semantics separate from text search semantics so `linear_list_issues` and `linear_search_issues` are not interchangeable.
+- Add regression coverage for query-only and query-plus-filter searches and document the expected result shape.
+
+## Capabilities
+
+### New Capabilities
+- `query-backed-issue-search`: Support issue search requests that accept `query` and execute a valid search backend path.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\features\issues\handlers\issue.handler.ts`
+- any shared GraphQL or SDK search helpers used by issue search
+- MCP tool-schema documentation for `linear_search_issues`
+- issue-search tests and README examples
diff --git a/openspec/changes/fix-30-repair-query-backed-issue-search/specs/query-backed-issue-search/spec.md b/openspec/changes/fix-30-repair-query-backed-issue-search/specs/query-backed-issue-search/spec.md
new file mode 100644
index 0000000..3eaaaa9
--- /dev/null
+++ b/openspec/changes/fix-30-repair-query-backed-issue-search/specs/query-backed-issue-search/spec.md
@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: Issue search executes a query-aware backend path
+The server SHALL execute `linear_search_issues` through a Linear search operation that accepts the client-provided `query`.
+
+#### Scenario: Query-backed issue search returns matching issues
+- **WHEN** a client calls `linear_search_issues` with a non-empty `query`
+- **THEN** the server SHALL execute a search operation using that query and SHALL return matching issue results with pagination metadata
+
+### Requirement: Issue search keeps filters separate from the text query
+The server SHALL not encode the `query` argument as a field on `IssueFilter`.
+
+#### Scenario: Query is not forwarded as an invalid issue filter field
+- **WHEN** a client supplies `query` together with supported filter arguments
+- **THEN** the server SHALL send the query through the search-specific parameter and SHALL apply additional constraints only through supported filter inputs
diff --git a/openspec/changes/fix-30-repair-query-backed-issue-search/tasks.md b/openspec/changes/fix-30-repair-query-backed-issue-search/tasks.md
new file mode 100644
index 0000000..b75ae54
--- /dev/null
+++ b/openspec/changes/fix-30-repair-query-backed-issue-search/tasks.md
@@ -0,0 +1,14 @@
+## 1. Search execution path
+
+- [x] 1.1 Update `linear_search_issues` to call a query-aware search backend instead of encoding the query as an issue filter.
+- [x] 1.2 Normalize search results into the existing structured issue summary shape with pagination metadata.
+
+## 2. Regression coverage
+
+- [x] 2.1 Add tests for successful query-only issue search.
+- [x] 2.2 Add tests for query-plus-filter searches so unsupported filter encoding does not return.
+
+## 3. Documentation
+
+- [x] 3.1 Update README and tool docs to distinguish issue listing from free-text issue search.
+- [x] 3.2 Document any supported filter combinations or known limits on the search path.
diff --git a/openspec/changes/fix-31-sync-advertised-tool-surface/.openspec.yaml b/openspec/changes/fix-31-sync-advertised-tool-surface/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-31-sync-advertised-tool-surface/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-31-sync-advertised-tool-surface/design.md b/openspec/changes/fix-31-sync-advertised-tool-surface/design.md
new file mode 100644
index 0000000..f166ff0
--- /dev/null
+++ b/openspec/changes/fix-31-sync-advertised-tool-surface/design.md
@@ -0,0 +1,47 @@
+## Context
+
+The current repository includes comment handlers and richer issue-update inputs in source, but issue #31 shows that at least one client distribution still exposed an older tool surface. The real compatibility boundary is therefore the built artifact clients install, not the TypeScript sources alone.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make the advertised tool catalog deterministic and testable from the built server artifact.
+- Ensure shipped clients can discover the supported comment workflows and issue-update path.
+- Keep docs and release artifacts synchronized when the tool surface changes.
+
+**Non-Goals:**
+- Add unrelated new domains or redesign the full release process.
+- Depend on manual spot checks to detect stale published surfaces.
+- Solve marketplace packaging concerns that belong to the marketplace-installation change.
+
+## Decisions
+
+### 1. Validate tool advertisement from the built server boundary
+
+The change should verify the `ListTools` response produced by the built executable or packaged artifact, not only exported schema objects in source. That is the surface clients actually consume, so release validation must happen there.
+
+### 2. Treat tool availability as versioned compatibility
+
+When new tools become available, the README and release notes should describe the minimum released version that contains them. This avoids a repo-versus-package split where users see capabilities in GitHub before they are actually installable.
+
+### 3. Make the supported issue-update path explicit
+
+Clients should not need to infer single-issue mutation support from a source fragment. The released catalog and docs should clearly identify the supported issue-update path for one existing issue, whether that remains `linear_bulk_update_issues` or is complemented by a dedicated alias.
+
+## Risks / Trade-offs
+
+- **Broader release checks:** Build verification adds CI and release work. -> **Mitigation:** keep the check lightweight and focused on the MCP `ListTools` contract.
+- **Compatibility choices:** Clarifying the issue-update path may require aliasing or renaming. -> **Mitigation:** preserve backward compatibility where possible and document the preferred path.
+- **Distribution lag:** Some channels may publish more slowly than GitHub changes land. -> **Mitigation:** tie released documentation to shipped versions rather than main-branch assumptions.
+
+## Migration Plan
+
+1. Add a tool-catalog smoke test against the built server boundary.
+2. Align the shipped catalog with the supported comment and issue-update workflows.
+3. Update docs and release notes to state when the expanded surface is available.
+4. Publish and verify the updated distribution channels.
+
+## Open Questions
+
+- Should the explicit single-issue update path be a dedicated tool name or a documented alias of the batch update flow?
+- Which distribution channels need automated catalog verification first?
diff --git a/openspec/changes/fix-31-sync-advertised-tool-surface/proposal.md b/openspec/changes/fix-31-sync-advertised-tool-surface/proposal.md
new file mode 100644
index 0000000..47209bb
--- /dev/null
+++ b/openspec/changes/fix-31-sync-advertised-tool-surface/proposal.md
@@ -0,0 +1,25 @@
+## Why
+
+GitHub issue #31 reports that MCP clients cannot see comment tools or a practical issue-update path even though the repository source and README advertise those workflows. The project needs a release-safe contract that keeps the published tool catalog, built artifact, and documentation aligned.
+
+## What Changes
+
+- Define the advertised MCP tool catalog as a tested compatibility contract for built and published artifacts.
+- Ensure shipped distributions expose the comment lifecycle tools and a documented issue-update mutation path, not just the source tree.
+- Add release-time validation and versioned documentation so stale distributions do not silently advertise an older surface.
+
+## Capabilities
+
+### New Capabilities
+- `advertised-tool-surface-parity`: Keep the built and published MCP tool catalog aligned with implemented handlers and released documentation.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\index.ts`
+- `src\core\types\tool.types.ts`
+- `src\core\handlers\handler.factory.ts`
+- packaging, build, and release validation for the distributed server
+- README and release documentation for supported tool availability
diff --git a/openspec/changes/fix-31-sync-advertised-tool-surface/specs/advertised-tool-surface-parity/spec.md b/openspec/changes/fix-31-sync-advertised-tool-surface/specs/advertised-tool-surface-parity/spec.md
new file mode 100644
index 0000000..314c7e1
--- /dev/null
+++ b/openspec/changes/fix-31-sync-advertised-tool-surface/specs/advertised-tool-surface-parity/spec.md
@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: Shipped tool catalog matches documented workflow support
+The server SHALL advertise the released comment workflows and issue-update path in the tool catalog returned by the built or packaged distribution.
+
+#### Scenario: Built artifact advertises released comment and issue update tools
+- **WHEN** a client requests the tool list from a built or packaged server artifact
+- **THEN** the returned catalog SHALL include `linear_get_comment`, `linear_list_comments`, `linear_get_issue_comments`, `linear_create_comment`, `linear_update_comment`, `linear_delete_comment`, `linear_resolve_comment`, `linear_unresolve_comment`, and the released issue-update path described by the documentation
+
+### Requirement: Release validation detects stale tool surfaces
+The release process SHALL verify the built server's advertised tool catalog before publishing a distribution.
+
+#### Scenario: Release validation blocks stale catalog output
+- **WHEN** the built server's tool list differs from the expected released catalog
+- **THEN** the release validation SHALL fail before the distribution is published
diff --git a/openspec/changes/fix-31-sync-advertised-tool-surface/tasks.md b/openspec/changes/fix-31-sync-advertised-tool-surface/tasks.md
new file mode 100644
index 0000000..08f3c56
--- /dev/null
+++ b/openspec/changes/fix-31-sync-advertised-tool-surface/tasks.md
@@ -0,0 +1,14 @@
+## 1. Tool catalog contract
+
+- [x] 1.1 Define the released tool-catalog entries for comment workflows and the supported issue-update path.
+- [x] 1.2 Add a smoke test that asks the built server for its tool list and compares it with the expected released catalog.
+
+## 2. Build and distribution alignment
+
+- [x] 2.1 Ensure the packaged build includes the handlers and tool schema exports required for the released catalog.
+- [x] 2.2 Decide whether the supported single-issue update path remains `linear_bulk_update_issues` or also ships a dedicated alias, then reflect that choice in the advertised surface.
+
+## 3. Documentation and release checks
+
+- [x] 3.1 Update README and release notes to describe the released comment and issue-update workflows by version.
+- [x] 3.2 Add CI or release validation that blocks publishing when the built catalog drifts from released documentation.
diff --git a/openspec/changes/fix-32-clean-issue-create-contracts/.openspec.yaml b/openspec/changes/fix-32-clean-issue-create-contracts/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-32-clean-issue-create-contracts/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-32-clean-issue-create-contracts/design.md b/openspec/changes/fix-32-clean-issue-create-contracts/design.md
new file mode 100644
index 0000000..e40caf3
--- /dev/null
+++ b/openspec/changes/fix-32-clean-issue-create-contracts/design.md
@@ -0,0 +1,49 @@
+## Context
+
+The current repository mixes two representations of issue creation. The MCP handlers already distinguish single issue creation from batch issue creation through separate SDK operations, but the lower-level GraphQL helper layer still contains a `CREATE_ISSUES_MUTATION` that sends an array into `issueCreate`, and the bulk-create tests still model a response shape that looks like the wrong mutation. That mismatch mirrors the runtime error seen from the tool surface, where a create path behaved like an array-backed single create instead of a true single-item mutation.
+
+This change needs a design document because it cuts across handlers, GraphQL helpers, project workflows, tests, and release validation. The goal is not only to repair code, but to remove the ambiguity that let single and batch create semantics drift apart.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Establish one authoritative contract for `linear_create_issue`, `linear_create_issues`, and project-attached follow-on issue creation.
+- Align GraphQL helpers, SDK usage, and tests so single and batch creation cannot silently swap payload shapes.
+- Add regression coverage at both helper and tool boundaries so released artifacts preserve the repaired behavior.
+
+**Non-Goals:**
+- Redesign issue update, delete, or relation workflows.
+- Add unrelated issue fields or change the user-facing response model for successful creates.
+- Replace every GraphQL helper with SDK calls if that is unrelated to issue creation parity.
+
+## Decisions
+
+### 1. Treat the SDK-backed tool behavior as the canonical create contract
+
+The handlers already separate single and batch creation using distinct SDK entry points, so the MCP tool surface should keep that distinction as the authoritative contract. Lower-level GraphQL helpers may remain only if they match the same semantics exactly. Keeping parallel raw GraphQL definitions as equally authoritative was considered, but rejected because the observed array-vs-single drift already proves that duplicated contracts do not stay aligned.
+
+### 2. Remove or rewrite ambiguous create helpers and test fixtures
+
+The invalid array-based `issueCreate` mutation and any tests that bless that shape should be removed or rewritten so they reflect the real Linear contract. The preferred approach is to keep one valid single-create definition and one valid batch-create definition, then update project-with-issues flows to reuse the batch helper consistently. Leaving dead helpers in place with comments was considered, but rejected because they continue to mislead future edits and make runtime regressions harder to spot.
+
+### 3. Add tool-boundary regression checks in addition to helper tests
+
+Unit tests at the GraphQL client level are necessary but not sufficient, because the reported break happened at the MCP tool boundary. The change should therefore add handler or runtime-level tests that exercise `linear_create_issue` and `linear_create_issues` as distinct tools and assert they invoke different underlying create contracts. Relying only on helper tests was considered, but rejected because it does not protect the released server behavior clients actually call.
+
+## Risks / Trade-offs
+
+- **More opinionated create layering** -> Keep the tool contract canonical at the handler boundary and allow lower-level helpers only when they preserve the same semantics.
+- **Test maintenance overhead** -> Favor a small number of high-signal runtime or handler contract tests over many duplicated mocks.
+- **Potential hidden internal callers of stale helpers** -> Search for references before removal and migrate any remaining internal use to the authoritative create helpers.
+
+## Migration Plan
+
+1. Remove or align conflicting single and batch issue-create helpers.
+2. Update project-with-issues creation to reuse the same batch contract as `linear_create_issues`.
+3. Rewrite tests so they assert the correct payload and response shape for each create path.
+4. Add runtime or packaged-server validation for the issue-create tools before release.
+
+## Open Questions
+
+- Is any internal code outside the issue and project handlers still using the raw GraphQL create helpers directly?
+- Should packaged-server validation live in the existing runtime transport test suite or a separate release-smoke test?
diff --git a/openspec/changes/fix-32-clean-issue-create-contracts/proposal.md b/openspec/changes/fix-32-clean-issue-create-contracts/proposal.md
new file mode 100644
index 0000000..590daad
--- /dev/null
+++ b/openspec/changes/fix-32-clean-issue-create-contracts/proposal.md
@@ -0,0 +1,28 @@
+## Why
+
+Issue creation is currently represented by multiple partially overlapping paths: the handlers use distinct Linear SDK calls, the GraphQL client still carries an invalid array-shaped `issueCreate` mutation, and the bulk-create tests still accept a response shape that looks like the wrong mutation. The runtime failure observed through the MCP tools matches this drift, so the create contract needs one authoritative implementation and regression coverage that protects the released tool surface.
+
+## What Changes
+
+- Make single-issue, batch-issue, and project-with-issues creation follow one authoritative contract per tool path.
+- Remove or align stale GraphQL helpers and tests that imply unsupported array input on `issueCreate`.
+- Add regression coverage that proves `linear_create_issue` uses single-item input, `linear_create_issues` uses batch input, and project-associated issue creation reuses the same batch path.
+- Add runtime or packaged-server verification so released issue-create tools cannot drift from handler semantics.
+
+## Capabilities
+
+### New Capabilities
+- `issue-create-contract-parity`: Keep single, batch, and project-scoped issue creation aligned with the documented Linear creation contracts.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\graphql\mutations.ts`
+- `src\graphql\client.ts`
+- `src\features\issues\handlers\issue.handler.ts`
+- `src\features\projects\handlers\project.handler.ts`
+- `src\__tests__\graphql-client.test.ts`
+- `src\__tests__\issue-handler.test.ts`
+- runtime or release validation for issue-create tool calls
diff --git a/openspec/changes/fix-32-clean-issue-create-contracts/specs/issue-create-contract-parity/spec.md b/openspec/changes/fix-32-clean-issue-create-contracts/specs/issue-create-contract-parity/spec.md
new file mode 100644
index 0000000..6768ab1
--- /dev/null
+++ b/openspec/changes/fix-32-clean-issue-create-contracts/specs/issue-create-contract-parity/spec.md
@@ -0,0 +1,29 @@
+## ADDED Requirements
+
+### Requirement: Single issue creation uses a single-item contract
+The server SHALL execute `linear_create_issue` using a single-issue creation contract that accepts one `IssueCreateInput` object.
+
+#### Scenario: Single create does not send array input
+- **WHEN** a client calls `linear_create_issue`
+- **THEN** the server SHALL send one issue-create input object and SHALL return one created issue summary
+
+### Requirement: Batch issue creation uses batch semantics
+The server SHALL execute `linear_create_issues` through a batch creation contract instead of reusing a single-issue mutation with array input.
+
+#### Scenario: Batch create sends an issues array through the batch path
+- **WHEN** a client calls `linear_create_issues` with one or more issue objects
+- **THEN** the server SHALL send those issues through a batch create request and SHALL return the created issue summaries
+
+### Requirement: Project-attached follow-on issues reuse the batch contract
+The server SHALL reuse the same batch issue creation contract for project workflows that create a project and then create associated issues.
+
+#### Scenario: Project-with-issues creation reuses the batch create path
+- **WHEN** a workflow creates a project together with associated issues
+- **THEN** the server SHALL create the project first and SHALL create the follow-on issues through the same batch contract used by `linear_create_issues`
+
+### Requirement: Released issue-create tools preserve single and batch contract separation
+The released server SHALL keep `linear_create_issue` and `linear_create_issues` mapped to distinct create contracts at the MCP tool boundary.
+
+#### Scenario: Tool boundary prevents single-versus-batch contract drift
+- **WHEN** a built or packaged server handles both `linear_create_issue` and `linear_create_issues`
+- **THEN** the single-create tool SHALL use the single-issue contract and the batch-create tool SHALL use the batch contract without sharing an array-shaped `issueCreate` request
diff --git a/openspec/changes/fix-32-clean-issue-create-contracts/tasks.md b/openspec/changes/fix-32-clean-issue-create-contracts/tasks.md
new file mode 100644
index 0000000..6c41e89
--- /dev/null
+++ b/openspec/changes/fix-32-clean-issue-create-contracts/tasks.md
@@ -0,0 +1,14 @@
+## 1. Contract cleanup
+
+- [x] 1.1 Remove or rewrite conflicting issue-create GraphQL helpers so single and batch creation each have one valid contract.
+- [x] 1.2 Align project-with-issues creation to reuse the same batch create path behind `linear_create_issues`.
+
+## 2. Regression coverage
+
+- [x] 2.1 Update GraphQL client tests to assert the correct payload and response shape for single versus batch creation.
+- [x] 2.2 Add handler or runtime tool-call tests that verify `linear_create_issue` and `linear_create_issues` invoke distinct underlying create operations.
+
+## 3. Release parity
+
+- [x] 3.1 Update tool or README documentation anywhere issue creation still implies ambiguous single-vs-batch behavior.
+- [x] 3.2 Add publish-time or packaged-server validation for the issue-create tool contract.
diff --git a/openspec/changes/fix-33-prune-stale-issue-search-paths/.openspec.yaml b/openspec/changes/fix-33-prune-stale-issue-search-paths/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-33-prune-stale-issue-search-paths/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-33-prune-stale-issue-search-paths/design.md b/openspec/changes/fix-33-prune-stale-issue-search-paths/design.md
new file mode 100644
index 0000000..92a482d
--- /dev/null
+++ b/openspec/changes/fix-33-prune-stale-issue-search-paths/design.md
@@ -0,0 +1,49 @@
+## Context
+
+Fix-30 established the intended behavior for `linear_search_issues`: use a query-aware search backend instead of treating a free-text query like a filter-only listing request. The current source reflects that at the handler layer, but the repository still carries `searchIssuesRaw` and a filter-based search query helper, and the tool failure seen at runtime still resembles the old invalid path. That means the codebase still has enough stale search surface for released behavior to drift away from the intended contract.
+
+This change needs a design document because it spans helper cleanup, handler guarantees, tool schema expectations, and runtime verification. The problem is not just the search code itself; it is the persistence of alternative search paths that can survive in tests or released artifacts.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make the query-backed search helper the only supported backend for `linear_search_issues`.
+- Remove or isolate stale raw search helpers that can reintroduce filter-only behavior.
+- Add runtime or packaged-server tests that verify the released tool surface preserves query-backed search semantics.
+
+**Non-Goals:**
+- Change `linear_list_issues` semantics or merge list and search into one tool.
+- Expand the search schema beyond filter combinations that the Linear SDK path can actually support.
+- Redesign project search or broader authentication behavior.
+
+## Decisions
+
+### 1. Keep `linear_search_issues` on the SDK-backed query path only
+
+The MCP tool should have exactly one authoritative backend: the SDK search call that accepts the client query directly. The stale raw filter-based helper should be removed or explicitly isolated from the issue-search tool path. Keeping both helpers available for convenience was considered, but rejected because it preserves the same ambiguity that produced the observed regression.
+
+### 2. Verify issue search through the MCP server boundary
+
+Existing unit tests prove that the handler and client helpers can call the right methods, but they do not guarantee the released tool surface does the same. This change should add a server-boundary test that invokes `linear_search_issues` through the MCP runtime and verifies the query and filters stay separated. Relying only on helper-level tests was considered, but rejected because that gap already allowed runtime behavior to drift.
+
+### 3. Document search and list as different contracts
+
+The documentation and tool expectations should state clearly that `linear_search_issues` is a free-text search entry point with optional supported filters, while `linear_list_issues` remains the filter-first listing path. Allowing search to silently fall back to listing behavior was considered, but rejected because it makes failures harder to diagnose and breaks the meaning of the tool names.
+
+## Risks / Trade-offs
+
+- **Removing stale helpers could affect hidden internal callers** -> Search for all references before deletion and migrate any remaining uses deliberately.
+- **Runtime tests can be slower than unit tests** -> Keep the server-boundary coverage narrowly focused on the issue search contract.
+- **Supported filter scope may stay narrower than list semantics** -> Document the supported combinations explicitly instead of guessing or silently widening behavior.
+
+## Migration Plan
+
+1. Remove or isolate raw filter-only issue search helpers from the `linear_search_issues` path.
+2. Keep the handler and tool schema aligned with the query-backed search semantics.
+3. Add unit and runtime regression coverage for query-only and query-plus-filter searches.
+4. Update documentation and release validation to describe and protect the repaired behavior.
+
+## Open Questions
+
+- Is `searchIssuesRaw` used anywhere outside tests or experiments that still needs a supported replacement?
+- Should the runtime parity test live in the existing transport suite or in a dedicated release-smoke harness?
diff --git a/openspec/changes/fix-33-prune-stale-issue-search-paths/proposal.md b/openspec/changes/fix-33-prune-stale-issue-search-paths/proposal.md
new file mode 100644
index 0000000..75f83a6
--- /dev/null
+++ b/openspec/changes/fix-33-prune-stale-issue-search-paths/proposal.md
@@ -0,0 +1,29 @@
+## Why
+
+Issue search is supposed to be query-backed after fix-30, but the repository still carries a raw filter-only search helper and the observed MCP failure still looks like the pre-fix path that tried to behave like filtered listing instead of free-text search. The search contract needs to make the query-backed path authoritative from source to released artifact so stale search code cannot resurface.
+
+## What Changes
+
+- Remove or isolate stale filter-only issue search helpers that can masquerade as the `linear_search_issues` implementation.
+- Keep the SDK-backed query search path as the only supported backend for the issue search tool.
+- Add runtime or packaged-server regression coverage that calls `linear_search_issues` through the MCP boundary and verifies `query` stays separate from filters.
+- Clarify documentation for search-versus-list semantics and supported filter combinations.
+
+## Capabilities
+
+### New Capabilities
+- `issue-search-path-parity`: Ensure issue search stays query-backed and consistent from source code to the released tool surface.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\graphql\client.ts`
+- `src\graphql\queries.ts`
+- `src\features\issues\handlers\issue.handler.ts`
+- `src\core\types\tool.types.ts`
+- `src\__tests__\graphql-client.test.ts`
+- `src\__tests__\issue-handler.test.ts`
+- `src\__tests__\runtime-server.test.ts`
+- README and release validation for issue search behavior
diff --git a/openspec/changes/fix-33-prune-stale-issue-search-paths/specs/issue-search-path-parity/spec.md b/openspec/changes/fix-33-prune-stale-issue-search-paths/specs/issue-search-path-parity/spec.md
new file mode 100644
index 0000000..d11776f
--- /dev/null
+++ b/openspec/changes/fix-33-prune-stale-issue-search-paths/specs/issue-search-path-parity/spec.md
@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: Issue search uses a query-backed search path
+The server SHALL execute `linear_search_issues` through a search operation that accepts the client-provided `query` as a first-class search parameter.
+
+#### Scenario: Query-only issue search returns structured results
+- **WHEN** a client calls `linear_search_issues` with a non-empty `query`
+- **THEN** the server SHALL execute a query-aware search and SHALL return structured issue results with pagination metadata
+
+### Requirement: Issue search keeps the free-text query separate from filters
+The server SHALL forward the `query` argument separately from supported filters and SHALL not encode the query as a field on a filter-only issues request.
+
+#### Scenario: Query is not transformed into a filter-only request
+- **WHEN** a client calls `linear_search_issues` with a `query` and supported filter arguments
+- **THEN** the server SHALL send the query through the search-specific parameter and SHALL apply the filters only through supported filter inputs
+
+### Requirement: Released issue search tools preserve query-backed semantics
+The released server SHALL preserve the query-backed behavior of `linear_search_issues` at the MCP tool boundary.
+
+#### Scenario: MCP runtime does not fall back to stale search helpers
+- **WHEN** a built or packaged server handles `linear_search_issues`
+- **THEN** it SHALL route the request to the query-backed search implementation and SHALL not invoke a stale filter-only helper for that tool call
diff --git a/openspec/changes/fix-33-prune-stale-issue-search-paths/tasks.md b/openspec/changes/fix-33-prune-stale-issue-search-paths/tasks.md
new file mode 100644
index 0000000..502e754
--- /dev/null
+++ b/openspec/changes/fix-33-prune-stale-issue-search-paths/tasks.md
@@ -0,0 +1,14 @@
+## 1. Search path cleanup
+
+- [x] 1.1 Remove or isolate stale raw issue search helpers and any filter-only queries behind `linear_search_issues`.
+- [x] 1.2 Keep the handler and tool schema focused on query-backed search with separately forwarded supported filters.
+
+## 2. Regression coverage
+
+- [x] 2.1 Add runtime or server-boundary tests that call `linear_search_issues` through the MCP tool surface.
+- [x] 2.2 Extend unit tests to fail on any attempt to encode the free-text query as a filter-only request.
+
+## 3. Documentation and release parity
+
+- [x] 3.1 Update README and tool docs to distinguish issue listing from free-text issue search and enumerate supported filters.
+- [x] 3.2 Add release or packaged-server validation that blocks stale issue-search behavior from shipping.
diff --git a/openspec/changes/fix-34-expose-server-build-provenance/.openspec.yaml b/openspec/changes/fix-34-expose-server-build-provenance/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-34-expose-server-build-provenance/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-34-expose-server-build-provenance/design.md b/openspec/changes/fix-34-expose-server-build-provenance/design.md
new file mode 100644
index 0000000..f778b7c
--- /dev/null
+++ b/openspec/changes/fix-34-expose-server-build-provenance/design.md
@@ -0,0 +1,49 @@
+## Context
+
+The local `linear-mcp` source can now be fixed while an external or packaged server still behaves like an older build. Today the server gives clients almost no way to tell the difference. `LinearServer` announces itself with a hardcoded `0.1.0` version, the `linear_get_capabilities` tool returns runtime transport data but not server identity, and the release scripts verify tool surfaces without checking that the packaged server reports its own packaged version.
+
+This change crosses runtime metadata, tool output, startup diagnostics, and packaged-install verification. A design is useful because the fix needs one stable source of truth for build identity rather than more scattered literals.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make the server expose the actual packaged build identity and version at runtime.
+- Keep the MCP server handshake metadata, `linear_get_capabilities`, and startup diagnostics aligned to the same source of truth.
+- Verify the built and packaged server report the expected provenance before release.
+
+**Non-Goals:**
+- Implement full deployment orchestration or remote server rollout logic.
+- Guarantee that a third-party hosted server upgrades itself automatically.
+- Add sensitive release metadata that should not be exposed to clients.
+
+## Decisions
+
+### 1. Resolve server build info from package metadata with optional environment-supplied commit data
+
+The authoritative version should come from `package.json`, because that is what the built and packaged artifact actually ships. Optional commit metadata can be attached from environment variables such as `LINEAR_MCP_BUILD_SHA` or `GITHUB_SHA` when present, but the server should remain useful when that metadata is absent. Reading git state directly at runtime was considered, but rejected because packaged installs and production environments often lack a git checkout.
+
+### 2. Thread build provenance through runtime capabilities and MCP server metadata
+
+The same build info should drive both the MCP server descriptor passed to `new Server(...)` and the structured response from `linear_get_capabilities`. That keeps human-visible diagnostics and machine-readable capability discovery aligned. Keeping one value in startup logs and another in capabilities was considered, but rejected because it preserves the ambiguity this change is meant to remove.
+
+### 3. Validate provenance from the built and packaged server boundary
+
+Release checks should connect to the built and freshly packaged server and confirm the reported build provenance matches the packaged metadata. Unit tests alone are not enough here because the problem is specifically about what the packaged server reports after build and install.
+
+## Risks / Trade-offs
+
+- **Environment-dependent commit metadata** -> Treat commit SHA as optional and make version reporting the required baseline.
+- **More release assertions can be brittle** -> Compare only stable provenance fields and keep the checks focused on packaged metadata.
+- **Capability payload growth** -> Add only small, operationally useful fields such as package name, version, and optional commit SHA.
+
+## Migration Plan
+
+1. Introduce a shared server build metadata source derived from package metadata.
+2. Feed that metadata into runtime capabilities, the MCP server descriptor, and startup logs.
+3. Update capability and runtime tests to assert the new provenance fields.
+4. Extend built/package release verification to fail when provenance drifts from the packaged metadata.
+
+## Open Questions
+
+- Should the startup diagnostics print the optional commit SHA only when available, or always include a placeholder value?
+- Is a build timestamp useful enough to expose now, or should provenance stay limited to package version and commit SHA?
diff --git a/openspec/changes/fix-34-expose-server-build-provenance/proposal.md b/openspec/changes/fix-34-expose-server-build-provenance/proposal.md
new file mode 100644
index 0000000..36b3850
--- /dev/null
+++ b/openspec/changes/fix-34-expose-server-build-provenance/proposal.md
@@ -0,0 +1,30 @@
+## Why
+
+The running Linear MCP server does not currently tell clients which packaged build they are talking to: `src/index.ts` hardcodes `0.1.0`, `linear_get_capabilities` omits package version metadata, and startup logs do not identify the build. That made it difficult to distinguish fixed local source from a stale deployed server while troubleshooting the broken issue-create tools.
+
+## What Changes
+
+- Derive the server identity and version from the packaged build instead of hardcoded literals.
+- Expose server build provenance through `linear_get_capabilities` and startup diagnostics, including package name, package version, and optional commit metadata when available.
+- Add release verification that checks the built and packaged server report the expected build provenance.
+- Document how operators can inspect server provenance when troubleshooting runtime drift.
+
+## Capabilities
+
+### New Capabilities
+- `server-build-provenance`: Report the packaged server identity and version through runtime capability discovery and release-safe diagnostics.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\core\capabilities.ts`
+- `src\features\subscriptions\handlers\subscription.handler.ts`
+- `src\index.ts`
+- `src\__tests__\capabilities.test.ts`
+- `src\__tests__\runtime-server.test.ts`
+- `scripts\release-utils.mjs`
+- `scripts\verify-tool-catalog.mjs`
+- `scripts\verify-packaged-install.mjs`
+- `README.md`
diff --git a/openspec/changes/fix-34-expose-server-build-provenance/specs/server-build-provenance/spec.md b/openspec/changes/fix-34-expose-server-build-provenance/specs/server-build-provenance/spec.md
new file mode 100644
index 0000000..8f7d624
--- /dev/null
+++ b/openspec/changes/fix-34-expose-server-build-provenance/specs/server-build-provenance/spec.md
@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: Runtime capabilities report packaged server provenance
+The server SHALL report its packaged build identity through `linear_get_capabilities`, including the packaged server name and version.
+
+#### Scenario: Capability discovery returns packaged version metadata
+- **WHEN** a client calls `linear_get_capabilities`
+- **THEN** the server SHALL return its runtime transport details together with the packaged server name and packaged server version
+
+### Requirement: Server startup uses the same provenance source as capability discovery
+The server SHALL use the same build provenance source for its MCP server descriptor and human-readable startup diagnostics.
+
+#### Scenario: Startup metadata does not use a stale hardcoded version
+- **WHEN** the server starts from a built or packaged artifact
+- **THEN** the reported server version SHALL come from the packaged build metadata instead of a hardcoded source-only literal
+
+### Requirement: Release validation checks build provenance from the built boundary
+The release process SHALL fail when the built or packaged server reports build provenance that differs from the packaged metadata.
+
+#### Scenario: Packaged install reports expected build provenance
+- **WHEN** release validation boots the built server and a freshly packaged install
+- **THEN** both runtimes SHALL report the packaged server name and version that match the artifact metadata
diff --git a/openspec/changes/fix-34-expose-server-build-provenance/tasks.md b/openspec/changes/fix-34-expose-server-build-provenance/tasks.md
new file mode 100644
index 0000000..435c2b7
--- /dev/null
+++ b/openspec/changes/fix-34-expose-server-build-provenance/tasks.md
@@ -0,0 +1,14 @@
+## 1. Build metadata source
+
+- [x] 1.1 Add a shared server build metadata source that resolves package name and version from the packaged artifact, with optional commit metadata from the environment.
+- [x] 1.2 Replace hardcoded server version literals with the shared build metadata in runtime capability reporting and server startup.
+
+## 2. Capability and release parity
+
+- [x] 2.1 Expose build provenance through `linear_get_capabilities` and update runtime tests to assert the new fields.
+- [x] 2.2 Extend built and packaged release verification to confirm the reported provenance matches the packaged metadata.
+
+## 3. Documentation and diagnostics
+
+- [x] 3.1 Update README guidance to explain how to inspect server provenance when troubleshooting runtime drift.
+- [x] 3.2 Update startup diagnostics or adjacent developer guidance to keep the reported build identity visible during local and packaged runs.
diff --git a/openspec/changes/fix-35-add-linear-api-contract-audits/.openspec.yaml b/openspec/changes/fix-35-add-linear-api-contract-audits/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-35-add-linear-api-contract-audits/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-35-add-linear-api-contract-audits/design.md b/openspec/changes/fix-35-add-linear-api-contract-audits/design.md
new file mode 100644
index 0000000..869af63
--- /dev/null
+++ b/openspec/changes/fix-35-add-linear-api-contract-audits/design.md
@@ -0,0 +1,55 @@
+## Context
+
+The current Linear MCP repository mixes hand-written GraphQL documents with SDK-backed issue workflow helpers. That is workable only if the repository has a clear, enforced boundary for which contract comes from raw GraphQL and which comes from the official SDK. The recent issue-create and issue-search failures show that this boundary drifted: stale array input on `issueCreate` and an invalid `IssueFilter.search` assumption both survived long enough to reach users.
+
+This change needs a design because it spans source files, verification scripts, and developer guidance. The goal is not just to repair one bug; it is to make stale Linear API assumptions fail fast before packaging.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Add a repository-level verification step that checks critical issue workflow contracts against the authoritative Linear behavior already established by official docs and SDK usage.
+- Keep issue creation and issue search on explicitly approved contract paths.
+- Make release verification fail when the repository reintroduces the known-invalid create/search shapes.
+
+**Non-Goals:**
+- Run live GraphQL introspection against Linear on every CI or release invocation.
+- Replace all raw GraphQL usage in the repository with SDK calls.
+- Expand the first audit pass beyond the critical issue create/search workflows.
+
+## Decisions
+
+### 1. Use a local contract audit instead of live network validation
+
+The repository should store a small, explicit set of guarded contract expectations for issue create/search and verify source artifacts against them locally. This keeps release verification deterministic and avoids making CI depend on external network access, credentials, or schema explorer availability.
+
+Live introspection against `api.linear.app` was considered, but rejected because it would make the safety check slower, flakier, and harder to run in contributor environments. The audit should codify the authoritative contracts already confirmed from the official docs and SDK.
+
+### 2. Audit both document shape and helper ownership
+
+The check should not only inspect GraphQL document strings; it should also guard which helper owns each workflow. Single-create and batch-create can be raw GraphQL if their shapes remain correct, while free-text issue search should remain on the SDK path instead of a raw filter helper.
+
+Auditing only document text was considered, but rejected because the search failure came from a stale alternative helper path as much as from a wrong field. The verification needs to protect both the GraphQL contract and the code path selection.
+
+### 3. Integrate the audit into existing release verification
+
+The new audit should run alongside the existing tool-catalog and packaged-install checks so it becomes part of the normal release gate. That keeps the repository’s safety story in one place and avoids another optional script that can be forgotten.
+
+Keeping the audit as a standalone developer-only check was considered, but rejected because the recent regressions were costly precisely because invalid contracts reached released MCP builds.
+
+## Risks / Trade-offs
+
+- **The audit may become stale if Linear changes again** -> Keep the guarded scope small and documented so updates are straightforward when official contracts move.
+- **Static checks can miss a runtime-only edge case** -> Pair the contract audit with the existing and proposed MCP-boundary runtime coverage instead of treating it as the only safety net.
+- **Too much rigidity could block legitimate refactors** -> Encode behavior-level assertions rather than fragile formatting or file-layout assumptions.
+
+## Migration Plan
+
+1. Add a small authoritative contract-audit source for the issue create/search workflows.
+2. Wire the audit into release verification.
+3. Update GraphQL helpers and docs to align with the audited contract boundaries.
+4. Expand the same pattern to other high-risk Linear workflows only if this first pass proves valuable.
+
+## Open Questions
+
+- Should the contract audit read from a small JSON manifest, code assertions in a script, or a typed helper module shared by tests and release scripts?
+- After issue workflows are guarded, which next Linear surfaces are high-risk enough to justify the same treatment?
diff --git a/openspec/changes/fix-35-add-linear-api-contract-audits/proposal.md b/openspec/changes/fix-35-add-linear-api-contract-audits/proposal.md
new file mode 100644
index 0000000..9a30b2f
--- /dev/null
+++ b/openspec/changes/fix-35-add-linear-api-contract-audits/proposal.md
@@ -0,0 +1,26 @@
+## Why
+
+Two separate MCP failures came from the same root problem: the repository allowed stale Linear API assumptions to survive after the official contract had moved on. Public reports and the official Linear docs both confirm that `issueCreate` expects a single `IssueCreateInput`, while free-text issue search belongs on the SDK query path instead of an `IssueFilter.search` field.
+
+## What Changes
+
+- Add a repository-level contract audit for the Linear issue-create and issue-search surfaces.
+- Fail verification when hand-written GraphQL documents or helper entry points encode unsupported create/search contracts, including array input on `issueCreate` or `search` inside `IssueFilter`.
+- Define one authoritative source for when this server should use raw GraphQL documents versus official SDK operations for issue workflows.
+- Document the guarded create/search contracts so future tool-surface changes do not reintroduce the same drift.
+
+## Capabilities
+
+### New Capabilities
+- `linear-api-contract-audit`: Guard the repository against stale Linear create/search contract assumptions before code ships.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\graphql\mutations.ts`
+- `src\graphql\queries.ts`
+- `src\graphql\client.ts`
+- `scripts\verify-tool-catalog.mjs` or a new dedicated contract-verification script
+- release verification and developer documentation for issue workflow contracts
diff --git a/openspec/changes/fix-35-add-linear-api-contract-audits/specs/linear-api-contract-audit/spec.md b/openspec/changes/fix-35-add-linear-api-contract-audits/specs/linear-api-contract-audit/spec.md
new file mode 100644
index 0000000..cd8cf6b
--- /dev/null
+++ b/openspec/changes/fix-35-add-linear-api-contract-audits/specs/linear-api-contract-audit/spec.md
@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: Issue creation contracts MUST match the guarded Linear create shapes
+The repository SHALL reject issue-create implementations that encode unsupported GraphQL input shapes for single-create or batch-create workflows.
+
+#### Scenario: Audit rejects array input on single issue creation
+- **WHEN** repository verification inspects the single-issue create contract
+- **THEN** it MUST fail if `issueCreate` is defined or invoked with array-shaped input instead of one `IssueCreateInput`
+
+### Requirement: Free-text issue search MUST stay separate from filter-only issue listing fields
+The repository SHALL reject issue-search implementations that encode the user query as an `IssueFilter` field instead of the authoritative query-backed search path.
+
+#### Scenario: Audit rejects filter-based free-text search encoding
+- **WHEN** repository verification inspects the issue search implementation
+- **THEN** it MUST fail if free-text search is routed through a raw `IssueFilter.search`-style contract or an equivalent stale filter-only helper
+
+### Requirement: Release verification MUST run the contract audit
+The release workflow SHALL include the Linear API contract audit before a build is considered ready to ship.
+
+#### Scenario: Release fails on contract drift
+- **WHEN** the guarded create/search contract audit detects a stale or unsupported contract shape
+- **THEN** release verification MUST fail before packaging succeeds
diff --git a/openspec/changes/fix-35-add-linear-api-contract-audits/tasks.md b/openspec/changes/fix-35-add-linear-api-contract-audits/tasks.md
new file mode 100644
index 0000000..711791f
--- /dev/null
+++ b/openspec/changes/fix-35-add-linear-api-contract-audits/tasks.md
@@ -0,0 +1,9 @@
+## 1. Contract audit source
+
+- [x] 1.1 Define the guarded create/search contract expectations and approved helper ownership for the audited issue workflows.
+- [x] 1.2 Add a repository-level audit that fails on invalid single-create, batch-create, or free-text search contract shapes.
+
+## 2. Verification integration
+
+- [x] 2.1 Wire the Linear API contract audit into the existing verification path so release validation fails on contract drift.
+- [x] 2.2 Update tests or documentation to explain the guarded create/search contracts and how the audit should be maintained.
diff --git a/openspec/changes/fix-36-smoke-critical-issue-workflows/.openspec.yaml b/openspec/changes/fix-36-smoke-critical-issue-workflows/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-36-smoke-critical-issue-workflows/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-36-smoke-critical-issue-workflows/design.md b/openspec/changes/fix-36-smoke-critical-issue-workflows/design.md
new file mode 100644
index 0000000..0a1ac1e
--- /dev/null
+++ b/openspec/changes/fix-36-smoke-critical-issue-workflows/design.md
@@ -0,0 +1,55 @@
+## Context
+
+Recent user-visible failures happened at the MCP tool boundary: creating an issue and searching issues both broke in ways that were obvious to clients but not fully prevented by the repository’s local safety checks. The repo now has better local fixes and provenance reporting, but it still lacks a deterministic way to exercise the critical issue workflows through the server boundary without real Linear credentials.
+
+This change needs a design because it likely introduces a test seam in server or handler wiring, plus new runtime coverage that sits between unit tests and real authenticated integration tests. The goal is to catch tool-boundary regressions without relying on live Linear access.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Add deterministic MCP-boundary smoke coverage for single issue create, batch issue create, and free-text issue search.
+- Make those tests runnable without real Linear credentials or network access.
+- Tie the smoke coverage into normal verification so critical issue workflows cannot silently drift again.
+
+**Non-Goals:**
+- Add live end-to-end tests against a real Linear workspace.
+- Smoke-test every MCP tool in the server.
+- Redesign the authentication flow or broader transport model.
+
+## Decisions
+
+### 1. Add a fake-backend test seam instead of live authenticated smoke tests
+
+The MCP server should be runnable in tests with an injected fake Linear backend or factory so the tool boundary can be exercised deterministically. This makes the tests fast, local, and credential-free while still verifying handler routing and tool responses through the real MCP server surface.
+
+Live authenticated smoke tests were considered, but rejected because they would be brittle, secret-dependent, and difficult to require for every release or contributor workflow.
+
+### 2. Focus the first smoke suite on critical issue workflows only
+
+The suite should cover the workflows that are currently proven user pain points: `linear_create_issue`, `linear_create_issues`, and `linear_search_issues`. That gives the repository a high-value safety net without turning the smoke harness into a second full integration suite.
+
+Testing the entire tool catalog was considered, but rejected because it would add too much setup and noise before the harness proves its value on the most failure-prone paths.
+
+### 3. Keep release gating aligned with deterministic smoke behavior
+
+The repository should treat the smoke harness as part of its normal verification story, either within the existing Jest/runtime suites or a release-adjacent script that uses the same fake backend setup. That ensures critical issue workflows are checked through the same MCP entry points that clients use.
+
+Keeping the smoke suite purely optional was considered, but rejected because the current problem is exactly that these workflows can look healthy in source while still failing where users invoke them.
+
+## Risks / Trade-offs
+
+- **Injectable test seams can complicate production wiring** -> Keep the seam narrow and default to the current production construction path.
+- **Smoke tests may overlap with unit tests** -> Use them only for behavior that matters specifically at the MCP boundary.
+- **A fake backend could miss one real SDK nuance** -> Pair this suite with the contract audit and existing helper-level tests instead of replacing them.
+
+## Migration Plan
+
+1. Introduce a narrow test seam for supplying a fake Linear backend to the MCP server or handler wiring.
+2. Add MCP-boundary smoke tests for single create, batch create, and free-text search.
+3. Wire the smoke coverage into the normal verification path.
+4. Expand coverage only if future regressions justify more boundary-level checks.
+
+## Open Questions
+
+- Should the fake backend be injected at `LinearServer`, `HandlerFactory`, or `LinearGraphQLClient` construction time?
+- Is the best release gate a Jest suite, a release helper script, or a combination where release calls the focused Jest smoke suite?
diff --git a/openspec/changes/fix-36-smoke-critical-issue-workflows/proposal.md b/openspec/changes/fix-36-smoke-critical-issue-workflows/proposal.md
new file mode 100644
index 0000000..9691641
--- /dev/null
+++ b/openspec/changes/fix-36-smoke-critical-issue-workflows/proposal.md
@@ -0,0 +1,26 @@
+## Why
+
+The repository can now contain the right local fixes while the released MCP still breaks the most important issue workflows. Public issue reports and the current CLI repro both show that issue creation and issue search can fail at the MCP boundary even when the intended source-level contract is known.
+
+## What Changes
+
+- Add MCP-boundary smoke coverage for the critical issue workflows: single create, batch create, and free-text issue search.
+- Introduce a deterministic test seam so the server can be exercised end-to-end with a fake Linear client instead of real credentials.
+- Extend release verification or adjacent runtime validation so stale issue-workflow behavior cannot ship unnoticed.
+- Document the critical smoke-tested workflows that must remain operational for released MCP builds.
+
+## Capabilities
+
+### New Capabilities
+- `mcp-issue-workflow-smoke-tests`: Verify that the released MCP server preserves critical issue workflow behavior through the tool boundary.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\index.ts`
+- `src\core\handlers\handler.factory.ts`
+- issue handlers or shared client wiring used by MCP tool execution
+- `src\__tests__\runtime-server.test.ts` and adjacent test utilities
+- release verification and README guidance for critical issue workflows
diff --git a/openspec/changes/fix-36-smoke-critical-issue-workflows/specs/mcp-issue-workflow-smoke-tests/spec.md b/openspec/changes/fix-36-smoke-critical-issue-workflows/specs/mcp-issue-workflow-smoke-tests/spec.md
new file mode 100644
index 0000000..d6723b3
--- /dev/null
+++ b/openspec/changes/fix-36-smoke-critical-issue-workflows/specs/mcp-issue-workflow-smoke-tests/spec.md
@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: The MCP server MUST support deterministic smoke execution of critical issue workflows
+The repository SHALL provide a credential-free way to boot the MCP server against a fake Linear backend for critical issue workflow verification.
+
+#### Scenario: Smoke harness boots the server without real Linear credentials
+- **WHEN** the critical issue workflow smoke suite runs
+- **THEN** it MUST be able to execute the MCP server and exercise the target issue tools without requiring live Linear credentials
+
+### Requirement: Critical issue workflow smoke coverage MUST include single create, batch create, and free-text search
+The repository SHALL verify the MCP boundary behavior for the highest-risk issue workflows that users invoke directly.
+
+#### Scenario: Smoke suite covers critical issue tools
+- **WHEN** the MCP smoke suite runs
+- **THEN** it MUST exercise `linear_create_issue`, `linear_create_issues`, and `linear_search_issues` through the MCP tool boundary
+
+### Requirement: Verification MUST fail when critical issue workflows drift at the MCP boundary
+The repository SHALL block release or verification success when the MCP smoke coverage detects stale issue workflow behavior.
+
+#### Scenario: Verification fails on boundary regression
+- **WHEN** a critical issue workflow smoke test observes incorrect MCP-boundary behavior
+- **THEN** the verification step that runs the smoke suite MUST fail before the release is treated as valid
diff --git a/openspec/changes/fix-36-smoke-critical-issue-workflows/tasks.md b/openspec/changes/fix-36-smoke-critical-issue-workflows/tasks.md
new file mode 100644
index 0000000..5842ffe
--- /dev/null
+++ b/openspec/changes/fix-36-smoke-critical-issue-workflows/tasks.md
@@ -0,0 +1,9 @@
+## 1. Smoke harness setup
+
+- [x] 1.1 Add a narrow fake-backend injection seam for the MCP server or handler wiring used by critical issue workflow tests.
+- [x] 1.2 Create reusable smoke-test helpers that execute the MCP server without live Linear credentials.
+
+## 2. Critical issue workflow coverage
+
+- [x] 2.1 Add MCP-boundary smoke tests for `linear_create_issue` and `linear_create_issues`.
+- [x] 2.2 Add MCP-boundary smoke tests for `linear_search_issues` and wire the smoke suite into the normal verification path or release guidance.
diff --git a/openspec/changes/fix-4-harden-marketplace-installation/.openspec.yaml b/openspec/changes/fix-4-harden-marketplace-installation/.openspec.yaml
new file mode 100644
index 0000000..98d7681
--- /dev/null
+++ b/openspec/changes/fix-4-harden-marketplace-installation/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-09
diff --git a/openspec/changes/fix-4-harden-marketplace-installation/design.md b/openspec/changes/fix-4-harden-marketplace-installation/design.md
new file mode 100644
index 0000000..fa476f3
--- /dev/null
+++ b/openspec/changes/fix-4-harden-marketplace-installation/design.md
@@ -0,0 +1,47 @@
+## Context
+
+The repository builds and runs locally, but the current package metadata and install story are thin for marketplace distribution. If the packaged artifact is missing executable wiring, build outputs, or clear startup errors, users see a generic marketplace failure instead of an actionable message.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make the packaged server installable and bootable from marketplace distribution.
+- Verify the packaged artifact can start and answer the MCP tool-list handshake after a fresh install.
+- Distinguish packaging failures from normal auth or environment setup errors.
+
+**Non-Goals:**
+- Redesign the full release infrastructure beyond what marketplace compatibility needs.
+- Embed secrets or default credentials in the package.
+- Replace runtime auth validation with install-time assumptions.
+
+## Decisions
+
+### 1. Treat the published package as the artifact under test
+
+Marketplace users consume the packaged artifact, not the local repository checkout. Compatibility checks should therefore run against the built package shape that is actually published.
+
+### 2. Ship explicit executable metadata and required build assets
+
+The package should declare the executable entrypoint and include every asset required to start the server after installation. Marketplace installation should not depend on a post-install build step or an implicit local repository layout.
+
+### 3. Separate install failures from setup guidance
+
+A package that starts successfully but lacks `LINEAR_API_KEY` or OAuth input should return a clear setup error, not a generic crash that looks like an installation failure. Clear diagnostics reduce false marketplace bug reports and speed up operator setup.
+
+## Risks / Trade-offs
+
+- **Packaging drift:** Local builds may keep working while published packages regress. -> **Mitigation:** add fresh-install smoke tests against the packaged artifact.
+- **Bigger release surface:** Packaging metadata changes can affect existing install flows. -> **Mitigation:** keep entrypoint changes backward compatible where possible.
+- **Diagnostic noise:** More startup guidance can clutter logs. -> **Mitigation:** keep diagnostics concise and reserve detail for actual setup failures.
+
+## Migration Plan
+
+1. Add executable packaging metadata and include required build assets.
+2. Add a fresh-install smoke test for the packaged distribution.
+3. Improve startup error messages for missing auth or setup input.
+4. Update marketplace-facing install guidance.
+
+## Open Questions
+
+- Which marketplace packaging assumptions need explicit automated coverage beyond a simple start-and-list-tools smoke test?
+- Should install guidance live only in the README, or also in package metadata and startup output?
diff --git a/openspec/changes/fix-4-harden-marketplace-installation/proposal.md b/openspec/changes/fix-4-harden-marketplace-installation/proposal.md
new file mode 100644
index 0000000..6fe7ae2
--- /dev/null
+++ b/openspec/changes/fix-4-harden-marketplace-installation/proposal.md
@@ -0,0 +1,24 @@
+## Why
+
+GitHub issue #4 reports a server error when the package is installed through the Cline marketplace. The published package needs marketplace-safe metadata, startup behavior, and diagnostics so installation problems can be distinguished from normal runtime configuration errors.
+
+## What Changes
+
+- Package the server with the executable metadata and built assets required for marketplace installation.
+- Add a fresh-install smoke test that validates boot and MCP tool listing from the packaged distribution.
+- Improve startup diagnostics so missing auth configuration is reported as setup guidance instead of a generic installation failure.
+
+## Capabilities
+
+### New Capabilities
+- `marketplace-installation-compatibility`: Ensure the packaged server installs, boots, and reports setup errors cleanly when distributed through the marketplace.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `package.json` and packaging metadata
+- build output and publish-time asset selection
+- startup diagnostics and install smoke tests
+- marketplace-oriented documentation
diff --git a/openspec/changes/fix-4-harden-marketplace-installation/specs/marketplace-installation-compatibility/spec.md b/openspec/changes/fix-4-harden-marketplace-installation/specs/marketplace-installation-compatibility/spec.md
new file mode 100644
index 0000000..e428681
--- /dev/null
+++ b/openspec/changes/fix-4-harden-marketplace-installation/specs/marketplace-installation-compatibility/spec.md
@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: Published package installs and boots as a marketplace artifact
+The server SHALL ship a package artifact that can be installed through the marketplace and started without a local source checkout.
+
+#### Scenario: Fresh-installed package starts and lists tools
+- **WHEN** the packaged server is installed into a fresh environment and started through its published entrypoint
+- **THEN** it SHALL boot successfully and SHALL answer the MCP tool-list request
+
+### Requirement: Startup diagnostics distinguish setup errors from packaging failures
+The server SHALL report missing auth or environment setup as actionable startup guidance instead of a generic installation failure.
+
+#### Scenario: Missing auth setup returns configuration guidance
+- **WHEN** a user starts the installed package without the required auth configuration
+- **THEN** the server SHALL report a clear setup error that distinguishes missing configuration from package-install failure
diff --git a/openspec/changes/fix-4-harden-marketplace-installation/tasks.md b/openspec/changes/fix-4-harden-marketplace-installation/tasks.md
new file mode 100644
index 0000000..7e4a8f1
--- /dev/null
+++ b/openspec/changes/fix-4-harden-marketplace-installation/tasks.md
@@ -0,0 +1,14 @@
+## 1. Packaging metadata
+
+- [x] 1.1 Add the executable packaging metadata and publish-time asset list required for marketplace installation.
+- [x] 1.2 Ensure the packaged server can start without relying on a local source checkout or post-install build.
+
+## 2. Installation verification
+
+- [x] 2.1 Add a fresh-install smoke test that boots the packaged artifact and requests the MCP tool list.
+- [x] 2.2 Verify marketplace installation failures are reproducible in the packaging test harness before release.
+
+## 3. Diagnostics and docs
+
+- [x] 3.1 Improve startup diagnostics so missing auth setup is reported separately from package-install failures.
+- [x] 3.2 Update marketplace-facing installation guidance and troubleshooting notes.
diff --git a/openspec/changes/harden-auth-session-lifecycle/.openspec.yaml b/openspec/changes/harden-auth-session-lifecycle/.openspec.yaml
new file mode 100644
index 0000000..e49efd1
--- /dev/null
+++ b/openspec/changes/harden-auth-session-lifecycle/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-10
diff --git a/openspec/changes/harden-auth-session-lifecycle/design.md b/openspec/changes/harden-auth-session-lifecycle/design.md
new file mode 100644
index 0000000..46cc442
--- /dev/null
+++ b/openspec/changes/harden-auth-session-lifecycle/design.md
@@ -0,0 +1,62 @@
+## Context
+
+The current auth lifecycle is implemented through a mutable `LinearAuth` instance that stores OAuth configuration, pending callback state, token data, and the active Linear client. That model is acceptable for stdio's single-client runtime, but stream transport creates multiple remote sessions while still sharing the same auth object. The same auth lifecycle also uses a weak OAuth state generator and only clears matched state after a successful token exchange.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Use a cryptographically strong OAuth state primitive.
+- Make pending OAuth state single-use on every matched callback attempt.
+- Isolate mutable auth state per MCP stream session.
+- Preserve the existing stdio and API-key workflows.
+
+**Non-Goals:**
+- Persist auth state across process restarts.
+- Introduce a new auth provider or credential store.
+- Redesign the Linear OAuth flow beyond session isolation and state hardening.
+
+## Decisions
+
+### 1. Use a cryptographically secure state generator
+Use Node crypto to generate OAuth state values instead of `Math.random()`. `randomBytes(...).toString('base64url')` is preferred over a shorter UUID because it is purpose-built for bearer-style state tokens and avoids predictable output.
+
+**Alternatives considered**
+- `randomUUID()`: acceptable, but less explicit about state-token entropy and formatting.
+- Keep `Math.random()`: rejected because it is not a CSPRNG.
+
+### 2. Consume pending state before the token exchange can be retried
+Once a callback presents the expected pending state, remove that state from the auth context before or during the first exchange attempt so the same state cannot be replayed after a failed exchange.
+
+**Alternatives considered**
+- Clear state only on successful exchange: rejected because it violates the documented single-use contract.
+- Clear state only in a `finally` block after the exchange: acceptable, but consuming state immediately after a successful match makes replay behavior simpler and easier to reason about.
+
+### 3. Resolve auth through a session-scoped auth context in stream mode
+Introduce an auth-context layer that distinguishes stdio from stream transport. In stdio, the server can keep a single local auth context. In stream mode, the server shall resolve auth state from the MCP session identifier so pending OAuth state, tokens, and client configuration are isolated per remote session.
+
+**Alternatives considered**
+- Keep one shared `LinearAuth` and document the limitation: rejected because remote stream access is already documented and a shared auth context is unsafe.
+- Create a fresh handler factory per request: viable, but the important design change is session-scoped auth resolution rather than the factory lifecycle itself.
+
+### 4. Fail closed if stream-session auth binding is unavailable
+If the MCP runtime cannot provide a stable per-session identifier at the request boundary, stream-mode OAuth should fail closed rather than silently falling back to a shared auth context.
+
+**Alternatives considered**
+- Silent fallback to process-global auth: rejected because it recreates the original race and session-mixing problem.
+
+## Risks / Trade-offs
+
+- **[Session metadata availability]** -> If the SDK does not expose a stable stream-session identifier at the handler boundary, the implementation will need a small auth-context abstraction or a stream-mode restriction for OAuth until that metadata is available.
+- **[Behavior divergence between stdio and stream]** -> Keep the difference explicit in code, tests, and docs so clients understand why stream mode requires session-scoped auth.
+- **[More auth lifecycle tests]** -> The surface area increases slightly, but the risk is mitigated by adding direct tests for replay, failed exchange, and concurrent stream-session behavior.
+
+## Migration Plan
+
+1. Introduce the session-aware auth context abstraction.
+2. Switch OAuth state generation and consumption to the hardened flow.
+3. Update stream-mode auth handling and documentation together.
+4. Add auth/session regression tests before enabling the new behavior by default.
+
+## Open Questions
+
+- Should API-key auth in stream mode be duplicated into each session context automatically, or treated as a global read-only default that OAuth can override per session?
diff --git a/openspec/changes/harden-auth-session-lifecycle/proposal.md b/openspec/changes/harden-auth-session-lifecycle/proposal.md
new file mode 100644
index 0000000..bceeeaa
--- /dev/null
+++ b/openspec/changes/harden-auth-session-lifecycle/proposal.md
@@ -0,0 +1,24 @@
+## Why
+
+The MCP server's auth lifecycle currently has two security gaps: OAuth state is weak and not always consumed after a callback attempt, and stream transport shares one mutable auth context across all clients. These behaviors undermine the server's security boundary right where remote clients and OAuth flows intersect.
+
+## What Changes
+
+- Replace the current OAuth state generator with a cryptographically secure primitive.
+- Make OAuth callback state single-use even when token exchange fails.
+- Isolate auth configuration, pending OAuth state, and active Linear credentials per MCP stream session instead of per server process.
+- Clarify stream-mode auth behavior in runtime responses and documentation where session-scoped auth is required.
+
+## Capabilities
+
+### New Capabilities
+- `oauth-state-hardening`: secure OAuth state generation and strict single-use callback handling.
+- `session-scoped-auth-context`: isolate auth lifecycle state for each MCP stream session.
+
+### Modified Capabilities
+
+## Impact
+
+- Affected code: `src/auth.ts`, `src/index.ts`, `src/features/auth/handlers/auth.handler.ts`, runtime capability reporting, and auth/session tests.
+- Affected behavior: stream transport auth becomes session-scoped instead of process-scoped.
+- Affected documentation: README transport and OAuth guidance.
diff --git a/openspec/changes/harden-auth-session-lifecycle/specs/oauth-state-hardening/spec.md b/openspec/changes/harden-auth-session-lifecycle/specs/oauth-state-hardening/spec.md
new file mode 100644
index 0000000..d59c8ea
--- /dev/null
+++ b/openspec/changes/harden-auth-session-lifecycle/specs/oauth-state-hardening/spec.md
@@ -0,0 +1,22 @@
+## ADDED Requirements
+
+### Requirement: OAuth state SHALL be cryptographically strong
+The server SHALL generate OAuth `state` values using a cryptographically secure random source and SHALL bind each callback to the exact issued state.
+
+#### Scenario: Authorization URL includes secure state
+- **WHEN** `linear_auth` generates an authorization URL
+- **THEN** the response SHALL include a newly generated non-empty state derived from a cryptographically secure source
+- **AND** the same state SHALL be embedded in the authorization URL returned to the client
+
+### Requirement: OAuth state SHALL be single-use
+The server SHALL invalidate a pending OAuth state after the first matched callback attempt, regardless of whether the token exchange succeeds.
+
+#### Scenario: Failed token exchange consumes the state
+- **WHEN** `linear_auth_callback` receives the correct pending state but the token exchange fails
+- **THEN** the server SHALL return an error
+- **AND** the same state SHALL be rejected on any later callback attempt
+
+#### Scenario: Successful token exchange consumes the state
+- **WHEN** `linear_auth_callback` receives the correct pending state and the token exchange succeeds
+- **THEN** the server SHALL authenticate the caller
+- **AND** the same state SHALL be rejected on any later callback attempt
diff --git a/openspec/changes/harden-auth-session-lifecycle/specs/session-scoped-auth-context/spec.md b/openspec/changes/harden-auth-session-lifecycle/specs/session-scoped-auth-context/spec.md
new file mode 100644
index 0000000..fa140cb
--- /dev/null
+++ b/openspec/changes/harden-auth-session-lifecycle/specs/session-scoped-auth-context/spec.md
@@ -0,0 +1,16 @@
+## ADDED Requirements
+
+### Requirement: Stream sessions SHALL not share mutable auth state
+The server SHALL isolate OAuth configuration, pending state, token data, and active client state for each stream transport session.
+
+#### Scenario: Concurrent stream sessions authenticate independently
+- **WHEN** two stream transport sessions start separate OAuth flows
+- **THEN** each session SHALL retain its own pending state and credentials
+- **AND** one session SHALL NOT overwrite or invalidate the other session's auth context
+
+### Requirement: Stdio auth SHALL remain local to the active server instance
+The server SHALL preserve the existing single-client auth lifecycle for stdio transport while applying stream-session isolation only where multiple remote sessions are supported.
+
+#### Scenario: Stdio auth continues to work
+- **WHEN** the server runs in stdio mode and a client completes API-key or OAuth setup
+- **THEN** subsequent tool calls in that stdio session SHALL use the same authenticated context
diff --git a/openspec/changes/harden-auth-session-lifecycle/tasks.md b/openspec/changes/harden-auth-session-lifecycle/tasks.md
new file mode 100644
index 0000000..fd57dbf
--- /dev/null
+++ b/openspec/changes/harden-auth-session-lifecycle/tasks.md
@@ -0,0 +1,9 @@
+## 1. OAuth State Hardening
+
+- [x] 1.1 Replace the OAuth state generator with a cryptographically secure primitive and consume matched state on every callback attempt
+- [x] 1.2 Add auth tests covering successful callback, failed token exchange, and replay rejection after a matched callback
+
+## 2. Session-Scoped Auth Context
+
+- [x] 2.1 Introduce session-aware auth context resolution for stream transport while preserving current stdio behavior
+- [x] 2.2 Update auth handlers, runtime documentation, and regression tests for isolated stream-session auth behavior
diff --git a/openspec/changes/harden-linear-request-resilience/.openspec.yaml b/openspec/changes/harden-linear-request-resilience/.openspec.yaml
new file mode 100644
index 0000000..11393ea
--- /dev/null
+++ b/openspec/changes/harden-linear-request-resilience/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-11
diff --git a/openspec/changes/harden-linear-request-resilience/design.md b/openspec/changes/harden-linear-request-resilience/design.md
new file mode 100644
index 0000000..993eea9
--- /dev/null
+++ b/openspec/changes/harden-linear-request-resilience/design.md
@@ -0,0 +1,60 @@
+## Context
+
+The runtime already classifies upstream failures as retryable based on status codes and GraphQL error metadata, but it does not use that signal to recover safe operations. The code also lacks explicit timeout budgets at the Linear-facing boundary, especially in OAuth token exchange and the shared GraphQL client. As a result, transient failures fail too eagerly while hung requests can take too long to surface.
+
+This change touches auth, raw GraphQL execution, SDK-backed helpers, and structured MCP error reporting. A design is useful because timeout and retry policy must be centralized enough to stay consistent, while still protecting non-idempotent mutations from accidental duplicate execution.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Enforce explicit timeout budgets for external auth and Linear-facing requests.
+- Add bounded retry and backoff for approved safe operations when failures are classified as retryable.
+- Keep unsafe writes off automatic retry paths unless they opt in explicitly.
+- Preserve structured MCP errors so timeout and retry exhaustion remain diagnosable.
+
+**Non-Goals:**
+- Introduce transactional guarantees that the upstream Linear API does not provide.
+- Add blanket automatic retries to all mutations.
+- Build a full circuit breaker or distributed resiliency framework in this change.
+
+## Decisions
+
+### 1. Centralize timeout and retry policy in a shared request-policy layer
+
+Timeout and retry behavior should live in one shared request-policy helper that can be used by OAuth token exchange, raw GraphQL execution, and approved SDK-backed operations. That keeps the semantics aligned and prevents drift across multiple ad hoc wrappers.
+
+**Alternatives considered**
+- Add timeouts and retries independently in `auth.ts` and `client.ts`: rejected because policy drift is likely over time.
+- Rely on upstream SDK defaults: rejected because the current boundary already needs its own structured error behavior.
+
+### 2. Retry only approved safe operations
+
+The retry policy should be opt-in for operations that are known to be safe to repeat, such as reads and other idempotent calls. Non-idempotent writes should remain single-attempt by default unless their workflow explicitly proves retry safety.
+
+**Alternatives considered**
+- Retry every operation with a retryable error: rejected because duplicate writes can corrupt caller expectations.
+- Never retry anything automatically: rejected because it leaves easy resilience wins on the table for reads.
+
+### 3. Treat timeout as part of the structured MCP failure contract
+
+When a request exceeds its time budget or exhausts bounded retries, the MCP boundary should still return a structured error that preserves the operation name and retryability context. That keeps timeout policy observable instead of turning it into a hidden implementation detail.
+
+**Alternatives considered**
+- Let timeout failures bubble up as generic internal errors: rejected because it weakens troubleshooting at the MCP boundary.
+
+## Risks / Trade-offs
+
+- **[Retries increase total latency before failure]** -> Keep attempt counts low and combine them with explicit per-attempt timeout budgets.
+- **[Timeout budgets can be tuned too aggressively]** -> Start with conservative defaults and validate them with focused tests around auth and GraphQL paths.
+- **[SDK calls may not support native cancellation uniformly]** -> Apply timeout policy at the wrapper layer and keep failure shaping consistent even if cancellation falls back to bounded waiting.
+
+## Migration Plan
+
+1. Introduce a shared request-policy helper for timeout and bounded retry behavior.
+2. Apply timeout enforcement to OAuth token exchange and the shared Linear client boundary.
+3. Opt approved safe reads into retry policy while keeping mutations single-attempt unless explicitly safe.
+4. Add focused tests for timeout enforcement, retry exhaustion, and non-retry behavior on unsafe writes.
+
+## Open Questions
+
+- Should future operator tuning expose retry and timeout settings, or should the first version stay on repository-controlled constants only?
diff --git a/openspec/changes/harden-linear-request-resilience/proposal.md b/openspec/changes/harden-linear-request-resilience/proposal.md
new file mode 100644
index 0000000..efffba1
--- /dev/null
+++ b/openspec/changes/harden-linear-request-resilience/proposal.md
@@ -0,0 +1,24 @@
+## Why
+
+The server already identifies retryable upstream failures, but it does not act on that signal, and external calls do not advertise explicit timeout budgets. That leaves safe reads vulnerable to transient Linear or network failures and makes hung requests harder to fail fast, diagnose, and recover from predictably.
+
+## What Changes
+
+- Introduce explicit timeout budgets for OAuth token exchange and Linear-facing SDK or raw GraphQL operations.
+- Add bounded retry and backoff for approved safe operations when the existing error classifier marks a failure as retryable.
+- Keep non-idempotent write paths opt-in for retry behavior so the server does not silently duplicate unsafe mutations.
+- Add focused tests and documentation for timeout and retry behavior at the MCP boundary.
+
+## Capabilities
+
+### New Capabilities
+- `linear-request-time-budgets`: Linear-facing requests fail within documented timeout budgets instead of hanging indefinitely.
+- `retryable-linear-request-recovery`: approved safe Linear operations retry bounded transient failures using the server's retryable error classification.
+
+### Modified Capabilities
+
+## Impact
+
+- Affected code: `src\auth.ts`, `src\graphql\client.ts`, `src\core\handlers\base.handler.ts`, and any shared request-policy helper introduced for timeouts and retries.
+- Affected behavior: safe reads become more resilient to transient upstream failures, while long-running or hung requests fail in a controlled, diagnosable way.
+- Affected verification: runtime, auth, and GraphQL client tests should cover timeout enforcement, bounded retries, and non-retry behavior for unsafe writes.
diff --git a/openspec/changes/harden-linear-request-resilience/specs/linear-request-time-budgets/spec.md b/openspec/changes/harden-linear-request-resilience/specs/linear-request-time-budgets/spec.md
new file mode 100644
index 0000000..e170ff1
--- /dev/null
+++ b/openspec/changes/harden-linear-request-resilience/specs/linear-request-time-budgets/spec.md
@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: Linear-facing requests SHALL enforce explicit time budgets
+The server SHALL enforce explicit timeout budgets for OAuth token exchange and for Linear-facing SDK or raw GraphQL operations instead of allowing those requests to hang indefinitely.
+
+#### Scenario: Upstream request exceeds its time budget
+- **WHEN** an external auth or Linear-facing request runs longer than its configured time budget
+- **THEN** the server SHALL stop waiting for that request and surface a structured failure at the MCP boundary
+
+### Requirement: Timeout failures SHALL remain diagnosable
+The server SHALL preserve structured failure context when a timeout budget is exceeded.
+
+#### Scenario: Timeout failure reaches the MCP boundary
+- **WHEN** a request fails because its time budget is exceeded
+- **THEN** the returned MCP error SHALL identify the operation as a timeout-driven failure without exposing sensitive request data
diff --git a/openspec/changes/harden-linear-request-resilience/specs/retryable-linear-request-recovery/spec.md b/openspec/changes/harden-linear-request-resilience/specs/retryable-linear-request-recovery/spec.md
new file mode 100644
index 0000000..cce5d50
--- /dev/null
+++ b/openspec/changes/harden-linear-request-resilience/specs/retryable-linear-request-recovery/spec.md
@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: Approved safe operations SHALL retry bounded transient failures
+The server SHALL retry retryable failures for approved safe Linear operations using a bounded attempt count and backoff policy.
+
+#### Scenario: Safe read receives a retryable upstream failure
+- **WHEN** an approved safe operation fails with a retryable status or upstream error classification
+- **THEN** the server SHALL retry that operation up to the configured bounded limit before returning failure
+
+### Requirement: Unsafe writes SHALL not auto-retry by default
+The server SHALL not automatically retry non-idempotent write operations unless the workflow explicitly documents retry safety.
+
+#### Scenario: Non-idempotent mutation receives a retryable error
+- **WHEN** a non-idempotent write operation encounters a retryable upstream failure
+- **THEN** the server SHALL return the failure without automatically issuing a duplicate write attempt
diff --git a/openspec/changes/harden-linear-request-resilience/tasks.md b/openspec/changes/harden-linear-request-resilience/tasks.md
new file mode 100644
index 0000000..ad67de3
--- /dev/null
+++ b/openspec/changes/harden-linear-request-resilience/tasks.md
@@ -0,0 +1,13 @@
+## 1. Shared Request Policy
+
+- [x] 1.1 Introduce a shared timeout and retry policy helper for external auth and Linear-facing operations
+- [x] 1.2 Apply explicit timeout budgets to OAuth token exchange and the shared GraphQL or SDK execution boundary
+
+## 2. Safe Retry Semantics
+
+- [x] 2.1 Opt approved safe read operations into bounded retry and keep non-idempotent write paths single-attempt by default
+- [x] 2.2 Add focused tests for timeout failures, retry exhaustion, and no-auto-retry behavior on unsafe writes
+
+## 3. Documentation and Verification
+
+- [x] 3.1 Update contributor or operator guidance for timeout and retry behavior and run the build, test, and release verification paths
diff --git a/openspec/changes/optimize-runtime-dispatch-and-batching/.openspec.yaml b/openspec/changes/optimize-runtime-dispatch-and-batching/.openspec.yaml
new file mode 100644
index 0000000..11393ea
--- /dev/null
+++ b/openspec/changes/optimize-runtime-dispatch-and-batching/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-11
diff --git a/openspec/changes/optimize-runtime-dispatch-and-batching/design.md b/openspec/changes/optimize-runtime-dispatch-and-batching/design.md
new file mode 100644
index 0000000..8c1e508
--- /dev/null
+++ b/openspec/changes/optimize-runtime-dispatch-and-batching/design.md
@@ -0,0 +1,60 @@
+## Context
+
+The review surfaced two related runtime inefficiencies. First, `HandlerFactory.getHandlerForTool()` rebuilds the full tool-to-handler map and allocates many handler instances for every MCP tool call, even though the routing table is static. Second, issue bulk workflows use unbounded `Promise.all`, which can burst upstream Linear traffic when users submit large batches.
+
+This change crosses core dispatch, auth-aware handler construction, and issue workflow execution. A design is useful because the implementation has to improve performance without breaking auth isolation, MCP response semantics, or existing transport behavior.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Replace per-call handler-map construction with a stable dispatch registry.
+- Reuse compatible handler instances within the same auth context without leaking across sessions.
+- Add bounded concurrency to bulk Linear fan-out workflows, starting with issue update and delete.
+- Preserve current MCP tool contracts while making runtime behavior more predictable under load.
+
+**Non-Goals:**
+- Redesign the entire feature-handler architecture.
+- Add benchmark infrastructure or operator-facing concurrency tuning in this change.
+- Change unrelated issue or project tool response shapes beyond what is needed to preserve existing semantics.
+
+## Decisions
+
+### 1. Use a static dispatch registry plus auth-scoped handler caching
+
+The handler routing table should be defined once as metadata instead of recreated for every request. `HandlerFactory` should resolve handler instances from that static registry and cache them per auth context so repeated calls reuse the same compatible feature handler instead of rebuilding the entire map.
+
+**Alternatives considered**
+- Keep building the map per call: rejected because the tool surface is already large and the cost scales with every invocation.
+- Reuse one global handler instance for all requests: rejected because stream transport requires strict session-scoped auth isolation.
+
+### 2. Introduce one shared bounded-concurrency helper for fan-out workflows
+
+The server should use one shared helper for batch workflows that execute many upstream operations independently. That helper should cap concurrent in-flight operations while preserving input order for collected results and allowing callers to choose whether failures are settled or thrown.
+
+**Alternatives considered**
+- Leave `Promise.all` in place and only document the risk: rejected because it does not reduce rate-limit pressure.
+- Make all batch work sequential: rejected because it sacrifices too much throughput for moderate batch sizes.
+
+### 3. Preserve handler and MCP response semantics while changing execution strategy
+
+This change should improve how work is scheduled and resolved, not redefine the public response model. Handlers that currently surface per-item failures, such as bulk delete, should keep doing so. Handlers that currently behave as a single workflow may continue to fail as a workflow, but they should execute through the bounded helper internally.
+
+**Alternatives considered**
+- Use the performance change to redesign all batch responses: rejected because that broadens scope and makes the proposal harder to implement safely.
+
+## Risks / Trade-offs
+
+- **[Handler caching could leak auth across sessions]** -> Scope handler reuse to the current `LinearAuth` instance and keep stream sessions isolated.
+- **[Concurrency limits can reduce peak throughput]** -> Use a modest default cap that avoids bursts while still allowing parallelism.
+- **[A shared helper can hide workflow-specific semantics]** -> Keep the helper low-level and let each handler choose ordered aggregation versus per-item settled outcomes.
+
+## Migration Plan
+
+1. Replace ad hoc handler-map construction with a static registry and auth-scoped handler cache.
+2. Add a shared bounded-concurrency helper and migrate bulk issue update and delete to it.
+3. Add targeted runtime and issue-handler tests that lock in registry stability, auth isolation, and bounded execution behavior.
+4. Expand the helper to other fan-out workflows only after the first handlers are verified.
+
+## Open Questions
+
+- Should the bounded concurrency limit remain an internal constant for now, or is there a compelling operator use case for making it configurable later?
diff --git a/openspec/changes/optimize-runtime-dispatch-and-batching/proposal.md b/openspec/changes/optimize-runtime-dispatch-and-batching/proposal.md
new file mode 100644
index 0000000..5259f98
--- /dev/null
+++ b/openspec/changes/optimize-runtime-dispatch-and-batching/proposal.md
@@ -0,0 +1,24 @@
+## Why
+
+The runtime spends avoidable work on every MCP tool call by rebuilding a full handler map and creating many short-lived handler instances in `HandlerFactory`. Bulk issue workflows also fan out with unbounded `Promise.all`, which raises the risk of bursty upstream traffic and unnecessary Linear rate-limit pressure as request sizes grow.
+
+## What Changes
+
+- Replace per-call handler map construction with a precomputed dispatch registry and stable handler resolution for each auth context.
+- Add bounded concurrency for bulk issue workflows that fan out to Linear one item at a time, starting with issue update and delete paths.
+- Preserve current MCP response shapes while making bulk workflow execution more predictable under larger input sets.
+- Add focused tests that lock in dispatch-path behavior and concurrency limits so performance regressions do not drift back in silently.
+
+## Capabilities
+
+### New Capabilities
+- `runtime-dispatch-efficiency`: MCP tool dispatch resolves handlers from a precomputed registry instead of rebuilding the full tool map on every invocation.
+- `bounded-batch-concurrency`: bulk Linear workflows execute within a documented concurrency limit instead of issuing unbounded parallel upstream requests.
+
+### Modified Capabilities
+
+## Impact
+
+- Affected code: `src\core\handlers\handler.factory.ts`, `src\index.ts`, `src\features\issues\handlers\issue.handler.ts`, and any shared helper introduced for bounded concurrency.
+- Affected behavior: dispatch overhead becomes stable per request, and large bulk issue operations become less bursty against Linear.
+- Affected verification: runtime and issue handler tests should assert handler reuse or registry stability and bounded bulk execution behavior.
diff --git a/openspec/changes/optimize-runtime-dispatch-and-batching/specs/bounded-batch-concurrency/spec.md b/openspec/changes/optimize-runtime-dispatch-and-batching/specs/bounded-batch-concurrency/spec.md
new file mode 100644
index 0000000..0f45107
--- /dev/null
+++ b/openspec/changes/optimize-runtime-dispatch-and-batching/specs/bounded-batch-concurrency/spec.md
@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: Bulk Linear fan-out workflows SHALL enforce bounded concurrency
+The server SHALL execute batch workflows that fan out into independent Linear operations within a documented maximum concurrency instead of issuing unbounded parallel requests.
+
+#### Scenario: Batch workload exceeds the concurrency cap
+- **WHEN** a batch workflow receives more work items than the configured maximum concurrency
+- **THEN** the server SHALL queue the remaining items and start them only as active slots become available
+
+### Requirement: Bounded concurrency SHALL preserve deterministic aggregation
+The server SHALL preserve deterministic result aggregation when a batch workflow runs through the bounded-concurrency execution path.
+
+#### Scenario: Batch results are collected after bounded execution
+- **WHEN** a bounded batch workflow completes
+- **THEN** the server SHALL aggregate results in a deterministic order that callers can map back to the original request items
diff --git a/openspec/changes/optimize-runtime-dispatch-and-batching/specs/runtime-dispatch-efficiency/spec.md b/openspec/changes/optimize-runtime-dispatch-and-batching/specs/runtime-dispatch-efficiency/spec.md
new file mode 100644
index 0000000..023fb20
--- /dev/null
+++ b/openspec/changes/optimize-runtime-dispatch-and-batching/specs/runtime-dispatch-efficiency/spec.md
@@ -0,0 +1,15 @@
+## ADDED Requirements
+
+### Requirement: Tool dispatch SHALL resolve handlers from a precomputed registry
+The server SHALL resolve MCP tool handlers from a precomputed routing registry instead of rebuilding the full tool-to-handler map on every tool invocation.
+
+#### Scenario: Repeated tool calls reuse stable routing metadata
+- **WHEN** the server handles repeated MCP tool calls after startup
+- **THEN** it SHALL resolve the target handler and method from precomputed routing metadata rather than rebuilding the full handler map for each call
+
+### Requirement: Handler reuse SHALL preserve auth isolation
+The server SHALL keep any handler reuse scoped to the active auth context so performance optimizations do not leak auth or session state across requests.
+
+#### Scenario: Concurrent stream sessions invoke the same feature tools
+- **WHEN** two stream sessions invoke tools that resolve to the same handler type
+- **THEN** the server SHALL keep handler reuse isolated to each session's auth context instead of sharing a handler instance across sessions
diff --git a/openspec/changes/optimize-runtime-dispatch-and-batching/tasks.md b/openspec/changes/optimize-runtime-dispatch-and-batching/tasks.md
new file mode 100644
index 0000000..9890922
--- /dev/null
+++ b/openspec/changes/optimize-runtime-dispatch-and-batching/tasks.md
@@ -0,0 +1,13 @@
+## 1. Dispatch Registry and Handler Reuse
+
+- [x] 1.1 Replace per-call handler-map construction in `HandlerFactory` with static routing metadata and auth-scoped handler reuse
+- [x] 1.2 Add runtime coverage that proves handler resolution remains correct and session-isolated after the dispatch-path optimization
+
+## 2. Bounded Batch Execution
+
+- [x] 2.1 Introduce a shared bounded-concurrency helper and migrate issue bulk update and delete workflows to it
+- [x] 2.2 Add handler tests that cover deterministic aggregation and bounded execution behavior for larger batch sizes
+
+## 3. Verification
+
+- [x] 3.1 Run the build, test, and release verification paths after the dispatch and batch changes land
diff --git a/openspec/changes/repair-issue-workflow-reliability/.openspec.yaml b/openspec/changes/repair-issue-workflow-reliability/.openspec.yaml
new file mode 100644
index 0000000..e49efd1
--- /dev/null
+++ b/openspec/changes/repair-issue-workflow-reliability/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-10
diff --git a/openspec/changes/repair-issue-workflow-reliability/design.md b/openspec/changes/repair-issue-workflow-reliability/design.md
new file mode 100644
index 0000000..59214c8
--- /dev/null
+++ b/openspec/changes/repair-issue-workflow-reliability/design.md
@@ -0,0 +1,61 @@
+## Context
+
+The issue and project workflow surface mixes strong batch semantics with ad hoc multi-step orchestration. `linear_create_project_with_issues` can progress without proving project creation returned a usable identifier, bulk delete does not yet expose a trustworthy end-to-end bulk contract, and issue-state filters can silently override one another. These behaviors make automation difficult to reason about because the MCP boundary does not always describe the final state clearly.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make project-plus-issues workflows return deterministic outcomes.
+- Repair bulk issue delete end to end before depending on it.
+- Eliminate ambiguous issue-state filter behavior.
+- Centralize or align multi-step workflow logic so it does not drift across layers.
+
+**Non-Goals:**
+- Introduce transactional guarantees that the upstream Linear API does not support.
+- Redesign unrelated issue or project read paths.
+- Broaden the workflow surface beyond the reviewed reliability fixes.
+
+## Decisions
+
+### 1. Use one shared orchestration contract for project-with-issues
+The server should consolidate project-plus-issues orchestration into one shared path so the MCP handler and lower-level helper cannot diverge on success checks, project-ID guards, or failure semantics.
+
+**Alternatives considered**
+- Keep duplicate implementations and update both: rejected because the existing divergence is already a source of bugs.
+
+### 2. Treat project creation and issue creation as a compensating workflow
+The workflow cannot be truly atomic across two upstream operations, so the server should adopt explicit compensating behavior: validate project success and identifier before creating issues, attempt cleanup if issue creation fails, and if cleanup cannot complete, return a partial-state response that names the created project and failed step.
+
+**Alternatives considered**
+- Return a generic error after issue-batch failure: rejected because it leaves callers unable to reason about server state.
+- Ignore compensation and document orphan risk: rejected because the tool is intended for automation.
+
+### 3. Verify the bulk-delete contract before switching the MCP handler to it
+Because the existing lower-level bulk-delete mutation appears suspicious, the implementation should add a contract audit or live-facing verification first. Once the contract is confirmed, the MCP handler should use that verified path; until then, it must not return ambiguous all-or-nothing results when partial deletion occurs.
+
+**Alternatives considered**
+- Wire the existing helper into the handler immediately: rejected because it may encode the wrong upstream contract.
+
+### 4. Reject conflicting state filters
+`stateId` and `states` should be treated as mutually exclusive at the MCP boundary. Rejecting the ambiguous combination is clearer than silently picking a precedence order.
+
+**Alternatives considered**
+- Let one field win silently: rejected because the current overwrite behavior is confusing.
+- Merge the two into a compound filter: rejected because it complicates semantics without clear user benefit.
+
+## Risks / Trade-offs
+
+- **[Compensation can also fail]** -> Surface explicit partial-state details whenever rollback cannot restore the original state.
+- **[Bulk delete contract uncertainty]** -> Add verification before changing the public handler path.
+- **[Rejecting conflicting filters changes permissive behavior]** -> Make the validation error explicit and update docs/tests so the change is predictable.
+
+## Migration Plan
+
+1. Consolidate the project-with-issues orchestration path and define compensation semantics.
+2. Verify the bulk-delete contract and update the handler accordingly.
+3. Add validation for conflicting issue-state filters.
+4. Backfill focused regression tests for each workflow.
+
+## Open Questions
+
+- If the upstream API lacks a true bulk-delete operation, should the long-term MCP contract return per-ID settled results permanently instead of a boolean success shape?
diff --git a/openspec/changes/repair-issue-workflow-reliability/proposal.md b/openspec/changes/repair-issue-workflow-reliability/proposal.md
new file mode 100644
index 0000000..affb81d
--- /dev/null
+++ b/openspec/changes/repair-issue-workflow-reliability/proposal.md
@@ -0,0 +1,25 @@
+## Why
+
+Several issue and project workflow paths are reliable only in the happy case: project-plus-issues creation can leave behind incomplete state, bulk delete does not use a trustworthy bulk contract end to end, and state filters can silently override each other. These gaps make automation harder to trust because callers cannot reason about outcomes from the MCP boundary alone.
+
+## What Changes
+
+- Make `linear_create_project_with_issues` fail fast when project creation is incomplete and define how partial failures are surfaced or compensated.
+- Repair and validate the bulk issue delete contract before routing MCP bulk delete through it.
+- Stop `stateId` and `states` from silently conflicting in issue list/search filters.
+- Add focused tests for project-with-issues, bulk delete, and conflicting issue-filter inputs.
+
+## Capabilities
+
+### New Capabilities
+- `project-with-issues-reliability`: project-plus-issue workflows return deterministic outcomes and never create orphaned issue batches silently.
+- `bulk-issue-delete-reliability`: MCP bulk issue deletion uses a verified bulk contract and returns reliable outcomes.
+- `deterministic-issue-state-filtering`: issue search and list flows handle `stateId` and `states` predictably.
+
+### Modified Capabilities
+
+## Impact
+
+- Affected code: `src/features/projects/handlers/project.handler.ts`, `src/features/issues/handlers/issue.handler.ts`, `src/graphql/client.ts`, `src/graphql/mutations.ts`, and workflow tests.
+- Affected behavior: callers receive clearer, safer results for multi-step issue and project automation.
+- Potential compatibility note: ambiguous filter combinations may become explicit validation errors.
diff --git a/openspec/changes/repair-issue-workflow-reliability/specs/bulk-issue-delete-reliability/spec.md b/openspec/changes/repair-issue-workflow-reliability/specs/bulk-issue-delete-reliability/spec.md
new file mode 100644
index 0000000..240cf16
--- /dev/null
+++ b/openspec/changes/repair-issue-workflow-reliability/specs/bulk-issue-delete-reliability/spec.md
@@ -0,0 +1,16 @@
+## ADDED Requirements
+
+### Requirement: Bulk issue delete SHALL use a verified contract
+The server SHALL execute bulk issue deletion through a contract that has been validated against the real Linear API surface before the MCP handler depends on it.
+
+#### Scenario: Release verification runs
+- **WHEN** release or contract verification checks the bulk issue delete path
+- **THEN** the verification suite SHALL confirm that the configured bulk delete operation matches the Linear API contract
+
+### Requirement: Bulk issue delete SHALL return deterministic outcomes
+The server SHALL not return an ambiguous bulk-delete result when some requested issues are deleted and others fail.
+
+#### Scenario: One or more issue deletions fail
+- **WHEN** a bulk delete request cannot delete every requested issue
+- **THEN** the response SHALL identify which issue IDs were deleted and which failed
+- **AND** the top-level result SHALL indicate that the bulk request did not complete fully
diff --git a/openspec/changes/repair-issue-workflow-reliability/specs/deterministic-issue-state-filtering/spec.md b/openspec/changes/repair-issue-workflow-reliability/specs/deterministic-issue-state-filtering/spec.md
new file mode 100644
index 0000000..69fbb4b
--- /dev/null
+++ b/openspec/changes/repair-issue-workflow-reliability/specs/deterministic-issue-state-filtering/spec.md
@@ -0,0 +1,8 @@
+## ADDED Requirements
+
+### Requirement: Issue state filters SHALL be unambiguous
+The server SHALL define one deterministic behavior when `stateId` and `states` are both provided on issue list or search requests.
+
+#### Scenario: Conflicting state filters are supplied
+- **WHEN** a client sends both `stateId` and `states` in the same issue list or search request
+- **THEN** the server SHALL reject the request with a validation error that explains the conflict
diff --git a/openspec/changes/repair-issue-workflow-reliability/specs/project-with-issues-reliability/spec.md b/openspec/changes/repair-issue-workflow-reliability/specs/project-with-issues-reliability/spec.md
new file mode 100644
index 0000000..6d012ae
--- /dev/null
+++ b/openspec/changes/repair-issue-workflow-reliability/specs/project-with-issues-reliability/spec.md
@@ -0,0 +1,17 @@
+## ADDED Requirements
+
+### Requirement: Project-with-issues creation SHALL require a valid project result before issue creation
+The server SHALL create follow-on issues only after project creation succeeds and returns a concrete project identifier.
+
+#### Scenario: Project creation lacks an identifier
+- **WHEN** the project creation step reports success false or returns no project identifier
+- **THEN** the server SHALL stop before creating any issues
+- **AND** the response SHALL report that the project-with-issues workflow failed before issue creation began
+
+### Requirement: Project-with-issues failures SHALL surface final state deterministically
+The server SHALL either compensate for downstream issue-creation failures or return explicit partial-state details to the caller.
+
+#### Scenario: Issue batch fails after project creation
+- **WHEN** project creation succeeds and the subsequent issue batch fails
+- **THEN** the server SHALL attempt its documented compensation path
+- **AND** if compensation cannot fully restore the original state, the response SHALL identify the created project and the failed issue step
diff --git a/openspec/changes/repair-issue-workflow-reliability/tasks.md b/openspec/changes/repair-issue-workflow-reliability/tasks.md
new file mode 100644
index 0000000..dc2cab5
--- /dev/null
+++ b/openspec/changes/repair-issue-workflow-reliability/tasks.md
@@ -0,0 +1,9 @@
+## 1. Project-With-Issues Reliability
+
+- [x] 1.1 Consolidate project-with-issues orchestration and require a successful project result with a concrete `projectId` before issue creation
+- [x] 1.2 Implement compensation or explicit partial-state reporting for issue-batch failure and add focused project workflow tests
+
+## 2. Bulk Delete and Filter Determinism
+
+- [x] 2.1 Verify the Linear bulk-delete contract, repair the client mutation/helper, and wire the MCP handler to the verified path or a per-ID settled result shape
+- [x] 2.2 Reject conflicting `stateId` and `states` filters in issue list/search flows and cover the behavior in regression tests
diff --git a/openspec/changes/stabilize-platform-fidelity/.openspec.yaml b/openspec/changes/stabilize-platform-fidelity/.openspec.yaml
new file mode 100644
index 0000000..23ef75a
--- /dev/null
+++ b/openspec/changes/stabilize-platform-fidelity/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-08
diff --git a/openspec/changes/stabilize-platform-fidelity/design.md b/openspec/changes/stabilize-platform-fidelity/design.md
new file mode 100644
index 0000000..418f7b5
--- /dev/null
+++ b/openspec/changes/stabilize-platform-fidelity/design.md
@@ -0,0 +1,77 @@
+## Context
+
+The review found several P0 fidelity problems in the current implementation. `src\index.ts` creates the handler factory once with a possibly stale `LinearGraphQLClient`, `BaseHandler.verifyAuth()` does not await token refresh, search tools call filtered list queries instead of current search endpoints, tool schemas use non-standard JSON Schema patterns, and `src\graphql\client.ts` discards GraphQL errors and operational metadata.
+
+This change is the foundation for the rest of the roadmap. If auth state, tool contracts, and response fidelity remain unstable, later feature work will inherit the same drift and operational blind spots.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make authenticated handler calls use the current GraphQL client after OAuth callback and token refresh.
+- Align issue and project search behavior with Linear's current search endpoints while keeping filtered list behavior available.
+- Replace non-standard schema declarations and mismatched parameter names with portable, strict tool contracts.
+- Return machine-readable tool outputs and preserve GraphQL error and metadata fidelity.
+- Bring repository documentation and tests into alignment with the implemented platform behavior.
+
+**Non-Goals:**
+- Add new issue, project, cycle, attachment, or webhook breadth beyond the foundation required for later changes.
+- Introduce long-term credential storage beyond the current environment-variable and in-memory OAuth approach.
+- Redesign the server transport or implement advanced event-driven capabilities.
+
+## Decisions
+
+### 1. Resolve the GraphQL client lazily instead of injecting a fixed instance once
+
+The current constructor flow creates handlers with a client snapshot that becomes stale after OAuth callback or token refresh. The server should provide handlers with a late-bound client resolver or shared client provider so every request can fetch the current authenticated client.
+
+This is preferred over rebuilding the entire handler factory after auth changes because it keeps auth propagation centralized and avoids re-instantiating unrelated handler state.
+
+### 2. Make auth verification asynchronous and gate downstream calls on refresh completion
+
+`verifyAuth()` must become asynchronous so it can await token refresh before any GraphQL request runs. A fire-and-forget refresh is not safe because the next request can race ahead with an expired client and drop refresh errors.
+
+This decision requires handler methods to await auth verification, but it removes the race the review identified and creates a single place to apply refresh failure behavior.
+
+### 3. Separate list and search tools explicitly
+
+The current `linear_search_issues` and `linear_search_projects` behave like filtered listings. The server should expose distinct list and search tools:
+
+- list tools use filter and pagination semantics
+- search tools use current Linear search endpoints and return ranked results
+
+Keeping the behaviors explicit is better than overloading one tool name because it makes client expectations, docs, and tests match the product surface.
+
+### 4. Standardize tool contracts around strict schemas and structured results
+
+`tool.types.ts` should only use standard JSON Schema keywords, and all layers must agree on field names such as `parentId`. Write and read tools should produce stable JSON payloads with identifiers, URLs, and pagination metadata so MCP clients can automate reliably.
+
+Human-readable text can remain as a companion summary, but not as the only result shape.
+
+### 5. Preserve GraphQL errors and operational metadata until the MCP boundary
+
+The GraphQL layer should return response envelopes that can carry `data`, `errors`, `extensions`, rate-limit headers, complexity headers, and retryability hints. Handler-level error mapping should happen after that fidelity is preserved so callers can distinguish validation failures, auth failures, throttling, and retryable conditions.
+
+### 6. Update docs and tests from implementation behavior instead of outdated assumptions
+
+The repository currently mixes stale OAuth, actor, and architecture descriptions. This change should refresh docs and tests from the implemented behavior so future feature work starts from a reliable baseline.
+
+## Risks / Trade-offs
+
+- **Cross-cutting refactor risk:** Async auth verification and client resolution touch many handlers. Mitigation: make the provider pattern small and shared before updating feature handlers.
+- **Client-facing contract changes:** Structured outputs and new list tools may change how existing clients consume results. Mitigation: document response shapes clearly and stage search/list changes with explicit tests.
+- **Upstream schema drift exposure:** Upgrading the SDK may surface more mismatches than the review already found. Mitigation: refresh queries and tool types directly from the current schema baseline before adding new feature breadth.
+- **More verbose responses:** Preserving GraphQL metadata can enlarge payloads. Mitigation: keep metadata structured and scoped to fields clients actually need.
+
+## Migration Plan
+
+1. Refresh the SDK and schema baseline.
+2. Introduce the late-bound client provider and async auth verification flow.
+3. Update issue and project tools to split list from search behavior.
+4. Normalize tool schemas and response envelopes.
+5. Refresh docs and tests to match the new contracts.
+
+## Open Questions
+
+- Should every tool return both structured JSON and a companion text summary, or should some read tools return JSON only?
+- How should rate-limit and complexity metadata be surfaced in MCP responses so they remain useful without becoming noisy?
+- Should legacy search behavior remain available temporarily as an alias, or should the semantic correction happen in place?
diff --git a/openspec/changes/stabilize-platform-fidelity/proposal.md b/openspec/changes/stabilize-platform-fidelity/proposal.md
new file mode 100644
index 0000000..7504094
--- /dev/null
+++ b/openspec/changes/stabilize-platform-fidelity/proposal.md
@@ -0,0 +1,37 @@
+## Why
+
+The current server has correctness and contract drift in the auth, search, schema, and GraphQL layers. Those gaps break core flows today and make later feature expansion risky because handlers and clients do not consistently reflect Linear's current API behavior.
+
+## What Changes
+
+- Rework auth and GraphQL client lifecycle handling so OAuth callback and token refresh update the active client used by all handlers.
+- Upgrade the Linear SDK and schema baseline, then align the server's query assumptions and actor semantics to that baseline.
+- Split list semantics from true search semantics and route search tools to Linear's current search endpoints.
+- Replace non-standard tool schema patterns and mismatched field names with strict JSON Schema and consistent argument contracts.
+- Standardize tool responses on structured JSON payloads while preserving human-readable summaries as companion output.
+- Preserve GraphQL fidelity by surfacing `errors`, extensions, rate-limit metadata, complexity metadata, and retryability signals instead of collapsing them into generic text errors.
+- Refresh README, architecture notes, and tests so the documented behavior matches the implemented contracts.
+
+## Capabilities
+
+### New Capabilities
+- `auth-session-lifecycle`: Keep OAuth state, token refresh, and the active GraphQL client synchronized across all handlers.
+- `search-and-list-semantics`: Distinguish filtered listing from ranked search for issue and project tools.
+- `tool-contract-fidelity`: Enforce strict schemas, aligned field names, and structured tool outputs for MCP clients.
+- `graphql-response-fidelity`: Preserve GraphQL response data, errors, and operational metadata for callers.
+
+### Modified Capabilities
+- None.
+
+## Impact
+
+- `src\index.ts`
+- `src\auth.ts`
+- `src\core\handlers\base.handler.ts`
+- `src\core\handlers\handler.factory.ts`
+- `src\core\types\tool.types.ts`
+- `src\graphql\client.ts`
+- `src\graphql\queries.ts`
+- feature handlers that currently return prose-only responses
+- `README.md`, `architecture.md`, and OAuth/search tests
+- `@linear/sdk` version and schema assumptions used by the repository
diff --git a/openspec/changes/stabilize-platform-fidelity/specs/auth-session-lifecycle/spec.md b/openspec/changes/stabilize-platform-fidelity/specs/auth-session-lifecycle/spec.md
new file mode 100644
index 0000000..0a1f80e
--- /dev/null
+++ b/openspec/changes/stabilize-platform-fidelity/specs/auth-session-lifecycle/spec.md
@@ -0,0 +1,33 @@
+## ADDED Requirements
+
+### Requirement: Authenticated tools use the active GraphQL client
+The server SHALL make the current authenticated GraphQL client available to every handler invocation after a successful OAuth callback or API key initialization.
+
+#### Scenario: OAuth callback activates the authenticated client
+- **WHEN** `linear_auth_callback` completes successfully for a pending OAuth flow
+- **THEN** the next authenticated tool invocation SHALL use the newly authenticated GraphQL client without requiring a process restart
+
+### Requirement: Token refresh completes before protected GraphQL operations run
+The server SHALL await token refresh before executing a protected GraphQL operation when the active OAuth token is within the refresh window.
+
+#### Scenario: Refresh occurs before the next API request
+- **WHEN** an authenticated tool call arrives while the active OAuth token needs refresh
+- **THEN** the server SHALL refresh the token, update the active GraphQL client, and only then execute the requested GraphQL operation
+
+#### Scenario: Refresh failure prevents the downstream request
+- **WHEN** token refresh fails for an authenticated tool call
+- **THEN** the server SHALL return an auth-related failure and SHALL NOT execute the downstream GraphQL operation with stale credentials
+
+### Requirement: OAuth callbacks validate issued state
+The server SHALL validate the callback state value against the state issued during authorization before mutating auth state.
+
+#### Scenario: Invalid callback state is rejected
+- **WHEN** `linear_auth_callback` receives a state value that does not match the issued authorization request
+- **THEN** the server SHALL reject the callback and SHALL NOT replace the current auth state or active GraphQL client
+
+### Requirement: Authorization URLs use the current Linear actor contract
+The server SHALL generate OAuth authorization URLs using the actor semantics and scope set supported by the current Linear platform baseline.
+
+#### Scenario: Authorization URL uses the current actor setting
+- **WHEN** `linear_auth` generates an authorization URL
+- **THEN** the URL SHALL include the actor setting and scopes supported by the current Linear API baseline used by the repository
diff --git a/openspec/changes/stabilize-platform-fidelity/specs/graphql-response-fidelity/spec.md b/openspec/changes/stabilize-platform-fidelity/specs/graphql-response-fidelity/spec.md
new file mode 100644
index 0000000..c2962fb
--- /dev/null
+++ b/openspec/changes/stabilize-platform-fidelity/specs/graphql-response-fidelity/spec.md
@@ -0,0 +1,26 @@
+## ADDED Requirements
+
+### Requirement: GraphQL responses preserve data and GraphQL errors
+The server SHALL preserve GraphQL response data together with any GraphQL `errors` and `extensions` data until the MCP response boundary.
+
+#### Scenario: Partial GraphQL success preserves both data and errors
+- **WHEN** Linear returns GraphQL data together with GraphQL errors
+- **THEN** the server SHALL preserve both in the response handling pipeline instead of collapsing the result to a generic text error
+
+### Requirement: Operational metadata is exposed when available
+The server SHALL preserve rate-limit headers, complexity headers, and similar operational response metadata when Linear includes them.
+
+#### Scenario: Rate-limit metadata is surfaced
+- **WHEN** a GraphQL response includes rate-limit or complexity metadata
+- **THEN** the server SHALL expose that metadata in a machine-readable form to the caller
+
+### Requirement: Failure handling distinguishes retryable and permanent conditions
+The server SHALL classify GraphQL failures so callers can distinguish retryable conditions such as throttling from permanent conditions such as validation failures.
+
+#### Scenario: Retryable failures are labeled as retryable
+- **WHEN** Linear rejects a request because of throttling or another transient condition
+- **THEN** the server SHALL surface the failure as retryable and SHALL preserve the relevant response metadata
+
+#### Scenario: Permanent failures remain non-retryable
+- **WHEN** Linear rejects a request because of a validation or permission failure
+- **THEN** the server SHALL surface the failure as non-retryable and SHALL preserve the relevant error details
diff --git a/openspec/changes/stabilize-platform-fidelity/specs/search-and-list-semantics/spec.md b/openspec/changes/stabilize-platform-fidelity/specs/search-and-list-semantics/spec.md
new file mode 100644
index 0000000..3e24e06
--- /dev/null
+++ b/openspec/changes/stabilize-platform-fidelity/specs/search-and-list-semantics/spec.md
@@ -0,0 +1,30 @@
+## ADDED Requirements
+
+### Requirement: List tools provide filtered pagination semantics
+The server SHALL expose dedicated list tools for issues and projects that use Linear filter and pagination semantics instead of ranked search semantics.
+
+#### Scenario: Listing issues uses filters and page info
+- **WHEN** a client calls the issue list tool with filters and pagination arguments
+- **THEN** the server SHALL query the corresponding Linear list endpoint and SHALL return the matching items with pagination metadata
+
+#### Scenario: Listing projects uses filters and page info
+- **WHEN** a client calls the project list tool with filters and pagination arguments
+- **THEN** the server SHALL query the corresponding Linear list endpoint and SHALL return the matching projects with pagination metadata
+
+### Requirement: Search tools use current Linear search endpoints
+The server SHALL implement issue and project search tools with the current Linear search endpoints so search results reflect ranked search behavior instead of filtered list behavior.
+
+#### Scenario: Issue search returns ranked search results
+- **WHEN** a client calls the issue search tool with a text query
+- **THEN** the server SHALL execute Linear's current issue search endpoint and SHALL return ranked results with search-relevant metadata when available
+
+#### Scenario: Project search returns true project search results
+- **WHEN** a client calls the project search tool with a text query
+- **THEN** the server SHALL execute Linear's current project search endpoint instead of an exact-name filter query
+
+### Requirement: Tool discovery distinguishes list from search
+The server SHALL advertise list tools and search tools as distinct MCP tools with descriptions that match their semantics.
+
+#### Scenario: Clients can discover separate list and search capabilities
+- **WHEN** an MCP client requests the server's tool list
+- **THEN** the tool catalog SHALL distinguish issue and project listing tools from issue and project search tools
diff --git a/openspec/changes/stabilize-platform-fidelity/specs/tool-contract-fidelity/spec.md b/openspec/changes/stabilize-platform-fidelity/specs/tool-contract-fidelity/spec.md
new file mode 100644
index 0000000..5d6f973
--- /dev/null
+++ b/openspec/changes/stabilize-platform-fidelity/specs/tool-contract-fidelity/spec.md
@@ -0,0 +1,26 @@
+## ADDED Requirements
+
+### Requirement: Tool schemas use strict JSON Schema
+The server SHALL define MCP input schemas with standard JSON Schema keywords and SHALL express optionality through the `required` array rather than non-standard properties.
+
+#### Scenario: Optional fields are represented with standard schema rules
+- **WHEN** an MCP client inspects a tool schema
+- **THEN** the schema SHALL use standard JSON Schema constructs for optional and required fields
+
+### Requirement: Comment reply inputs use a single parentId contract
+The server SHALL use `parentId` consistently across tool schemas, handler argument types, and GraphQL input mapping for threaded comment creation.
+
+#### Scenario: Threaded comment creation uses parentId consistently
+- **WHEN** a client creates a reply comment by passing `parentId`
+- **THEN** the declared tool schema, handler input parsing, and GraphQL mutation input SHALL all treat that field as the comment parent identifier
+
+### Requirement: Tool results include machine-readable payloads
+The server SHALL return structured JSON payloads for read and write tools so MCP clients can reliably parse identifiers, URLs, pagination metadata, and mutation status.
+
+#### Scenario: Mutation results include stable fields
+- **WHEN** a client invokes a write tool successfully
+- **THEN** the response SHALL include a machine-readable payload with the created or updated entity identifiers and relevant status fields
+
+#### Scenario: Read results include structured collection metadata
+- **WHEN** a client invokes a paginated read tool
+- **THEN** the response SHALL include a machine-readable payload with collection items and pagination metadata
diff --git a/openspec/changes/stabilize-platform-fidelity/tasks.md b/openspec/changes/stabilize-platform-fidelity/tasks.md
new file mode 100644
index 0000000..ca9a02d
--- /dev/null
+++ b/openspec/changes/stabilize-platform-fidelity/tasks.md
@@ -0,0 +1,17 @@
+## 1. Auth and client lifecycle
+
+- [x] 1.1 Upgrade the Linear SDK and refresh schema-driven query assumptions against the current Linear platform baseline
+- [x] 1.2 Introduce a late-bound GraphQL client provider so auth changes are visible to all handlers
+- [x] 1.3 Convert auth verification and token refresh to an awaited flow and validate OAuth callback state and actor semantics
+
+## 2. Tool contract alignment
+
+- [x] 2.1 Replace non-standard JSON Schema usage in `src\core\types\tool.types.ts` and align mismatched fields such as comment `parentId`
+- [x] 2.2 Add dedicated issue and project list tools and move search tools to the current Linear search endpoints
+- [x] 2.3 Normalize handler responses onto structured JSON payloads with stable identifiers, URLs, status fields, and pagination metadata
+
+## 3. GraphQL fidelity and documentation
+
+- [x] 3.1 Update `src\graphql\client.ts` to preserve GraphQL errors, extensions, and operational headers
+- [x] 3.2 Propagate retryability and GraphQL metadata through handler error handling at the MCP boundary
+- [x] 3.3 Refresh README, architecture notes, and OAuth and search tests to match the implemented contracts
diff --git a/openspec/changes/support-access-token-env-alias/.openspec.yaml b/openspec/changes/support-access-token-env-alias/.openspec.yaml
new file mode 100644
index 0000000..e49efd1
--- /dev/null
+++ b/openspec/changes/support-access-token-env-alias/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-10
diff --git a/openspec/changes/support-access-token-env-alias/design.md b/openspec/changes/support-access-token-env-alias/design.md
new file mode 100644
index 0000000..2f6c28f
--- /dev/null
+++ b/openspec/changes/support-access-token-env-alias/design.md
@@ -0,0 +1,39 @@
+## Context
+
+The server currently bootstraps startup API-key auth only from `LINEAR_API_KEY`, while some MCP clients and operator setups provide the same credential as `LINEAR_ACCESS_TOKEN`. That mismatch makes a valid configured token look like missing auth when the server is started directly, inspected in package-install smoke tests, or wired into a client config outside the host that injected the value.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Accept `LINEAR_ACCESS_TOKEN` anywhere startup API-key auth currently accepts `LINEAR_API_KEY`.
+- Keep startup auth precedence deterministic when both env vars are present.
+- Align startup diagnostics, runtime/package smoke coverage, and operator docs with the same env contract.
+
+**Non-Goals:**
+- Change OAuth behavior or add a new auth mode.
+- Redesign `LinearAuth` beyond the startup env bootstrap path.
+- Introduce persistent credential storage.
+
+## Decisions
+
+### 1. Resolve startup API-key env selection once and prefer `LINEAR_API_KEY`
+Startup should choose a single API-key value before auth initialization and use the same selection for diagnostics. `LINEAR_API_KEY` remains the primary variable to preserve existing behavior and avoid ambiguity when both variables are set.
+
+### 2. Surface deterministic startup diagnostics for every env state
+Startup output should say whether it detected `LINEAR_API_KEY`, detected `LINEAR_ACCESS_TOKEN`, detected both and chose `LINEAR_API_KEY`, or detected neither variable. That keeps packaged-install smoke tests and operator troubleshooting aligned with the real bootstrap path.
+
+### 3. Extend regression coverage across runtime and packaged entrypoints
+The runtime smoke harness should be able to start the real server with either env name, and packaged-install verification should assert that both names are accepted. Integration-test credential detection should also accept either variable so local verification matches documented startup behavior.
+
+## Risks / Trade-offs
+
+- **Two valid env names increase config drift risk** -> Prefer `LINEAR_API_KEY` when both are set and document that precedence explicitly.
+- **Startup diagnostics become more specific** -> Keep them derived from the same env resolver used for bootstrap so messaging cannot drift from behavior.
+- **More smoke-test permutations** -> Limit the added checks to credential-free startup paths so coverage stays fast and deterministic.
+
+## Migration Plan
+
+1. Add a startup env resolver that accepts both variable names and records which source was selected.
+2. Update startup diagnostics and runtime helpers to use the new env contract.
+3. Extend runtime, integration, and packaged-install coverage for both variable names.
+4. Update operator-facing docs and examples to match the released behavior.
diff --git a/openspec/changes/support-access-token-env-alias/proposal.md b/openspec/changes/support-access-token-env-alias/proposal.md
new file mode 100644
index 0000000..f278761
--- /dev/null
+++ b/openspec/changes/support-access-token-env-alias/proposal.md
@@ -0,0 +1,27 @@
+## Why
+
+The server currently initializes API-key auth only from `LINEAR_API_KEY` and reports startup guidance only for that variable. In practice, MCP client configurations and operator habits also use `LINEAR_ACCESS_TOKEN`, so a valid configured token can look like missing auth when the server is run directly or inspected outside the host client.
+
+## What Changes
+
+- Accept `LINEAR_ACCESS_TOKEN` as a supported API-key environment variable for startup auth while preserving `LINEAR_API_KEY` compatibility.
+- Define deterministic precedence and startup diagnostics when one or both API-key environment variables are present.
+- Add regression coverage for startup auth initialization and packaged/runtime smoke checks using both environment-variable names.
+- Update README, examples, and operator guidance so manual CLI use, packaged installs, and MCP client configs describe the same auth contract.
+
+## Capabilities
+
+### New Capabilities
+
+- `api-key-env-alias`: Support startup API-key auth through either `LINEAR_API_KEY` or `LINEAR_ACCESS_TOKEN`, with clear precedence and operator diagnostics.
+
+### Modified Capabilities
+
+- None.
+
+## Impact
+
+- `src/index.ts`
+- startup diagnostics and auth bootstrap behavior
+- auth integration tests and runtime smoke helpers
+- `README.md`, `architecture.md`, and `.env.example`
diff --git a/openspec/changes/support-access-token-env-alias/specs/api-key-env-alias/spec.md b/openspec/changes/support-access-token-env-alias/specs/api-key-env-alias/spec.md
new file mode 100644
index 0000000..221a858
--- /dev/null
+++ b/openspec/changes/support-access-token-env-alias/specs/api-key-env-alias/spec.md
@@ -0,0 +1,25 @@
+## ADDED Requirements
+
+### Requirement: Startup API-key auth SHALL accept either supported env name
+The server SHALL initialize startup API-key auth from `LINEAR_API_KEY` or `LINEAR_ACCESS_TOKEN`.
+
+#### Scenario: Startup bootstraps from `LINEAR_ACCESS_TOKEN`
+- **WHEN** the server starts without `LINEAR_API_KEY` and with `LINEAR_ACCESS_TOKEN`
+- **THEN** startup auth SHALL initialize with the `LINEAR_ACCESS_TOKEN` value
+- **AND** startup diagnostics SHALL report that `LINEAR_ACCESS_TOKEN` was detected
+
+### Requirement: Startup API-key env precedence SHALL be deterministic
+The server SHALL prefer `LINEAR_API_KEY` when both supported API-key env variables are present.
+
+#### Scenario: Both API-key env vars are present
+- **WHEN** the server starts with both `LINEAR_API_KEY` and `LINEAR_ACCESS_TOKEN`
+- **THEN** startup auth SHALL use the `LINEAR_API_KEY` value
+- **AND** startup diagnostics SHALL state that both env vars were detected and `LINEAR_API_KEY` was chosen
+
+### Requirement: Startup guidance SHALL document both API-key env names
+Startup diagnostics and operator docs SHALL describe the same API-key env contract.
+
+#### Scenario: Neither API-key env var is present
+- **WHEN** the server starts without `LINEAR_API_KEY` and without `LINEAR_ACCESS_TOKEN`
+- **THEN** startup diagnostics SHALL explain that neither supported API-key env var was detected
+- **AND** the guidance SHALL tell operators to set either env var for API-key auth or use OAuth instead
diff --git a/openspec/changes/support-access-token-env-alias/tasks.md b/openspec/changes/support-access-token-env-alias/tasks.md
new file mode 100644
index 0000000..6c13283
--- /dev/null
+++ b/openspec/changes/support-access-token-env-alias/tasks.md
@@ -0,0 +1,13 @@
+## 1. Startup env resolution
+
+- [x] 1.1 Add startup API-key env resolution that accepts `LINEAR_ACCESS_TOKEN` and prefers `LINEAR_API_KEY` when both are set.
+- [x] 1.2 Update startup diagnostics so they report the selected env source or explain that neither supported API-key env var is present.
+
+## 2. Regression coverage
+
+- [x] 2.1 Extend runtime smoke helpers and tests to cover alias-only startup auth and the both-vars precedence case.
+- [x] 2.2 Update integration/package-install verification so both `LINEAR_API_KEY` and `LINEAR_ACCESS_TOKEN` are accepted by the documented startup path.
+
+## 3. Documentation
+
+- [x] 3.1 Update README, architecture.md, and `.env.example` to document both API-key env names and the precedence rule.
diff --git a/openspec/changes/tighten-agent-workflow-contracts/.openspec.yaml b/openspec/changes/tighten-agent-workflow-contracts/.openspec.yaml
new file mode 100644
index 0000000..e49efd1
--- /dev/null
+++ b/openspec/changes/tighten-agent-workflow-contracts/.openspec.yaml
@@ -0,0 +1,2 @@
+schema: spec-driven
+created: 2026-04-10
diff --git a/openspec/changes/tighten-agent-workflow-contracts/design.md b/openspec/changes/tighten-agent-workflow-contracts/design.md
new file mode 100644
index 0000000..d8cbf7b
--- /dev/null
+++ b/openspec/changes/tighten-agent-workflow-contracts/design.md
@@ -0,0 +1,54 @@
+## Context
+
+The agent workflow tools currently accept several mostly freeform objects and have little direct handler or contract coverage compared with the rest of the MCP surface. That is risky because agent payloads are one of the easiest places for malformed, oversized, or unintended data to cross the boundary between the MCP client and the Linear API.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Make agent input contracts more explicit where the server owns stable structure.
+- Add bounded validation for the remaining flexible objects.
+- Return intentionally shaped agent response fields.
+- Add direct regression coverage for the agent tool surface.
+
+**Non-Goals:**
+- Eliminate every flexible field from the Linear agent API surface.
+- Redesign the underlying Linear agent model.
+- Add new agent product features unrelated to contract hardening.
+
+## Decisions
+
+### 1. Use a two-tier contract for agent payloads
+Server-owned structures such as top-level tool arguments, external URL entries, and any stable wrapper fields should use explicit schemas. Truly provider-owned opaque objects such as activity content or metadata may remain objects, but they should be validated for type, size, and complexity bounds before being forwarded.
+
+**Alternatives considered**
+- Keep all freeform objects unbounded: rejected because it preserves the current risk.
+- Fully schema every nested agent object: rejected because the upstream payload shape may intentionally remain flexible.
+
+### 2. Shape agent responses intentionally
+Agent handlers should return only documented safe fields rather than echoing arbitrary upstream structures by default. Flexible nested fields that remain exposed should be explicitly chosen and bounded.
+
+**Alternatives considered**
+- Mirror upstream responses wholesale: rejected because it couples clients to internal upstream details and increases leakage risk.
+
+### 3. Treat agent regression coverage as part of the contract
+Because the agent surface is both flexible and lightly tested today, direct tool-contract and handler tests are part of the change rather than an optional implementation detail.
+
+**Alternatives considered**
+- Rely on generic tool-contract tests only: rejected because they do not currently exercise handler behavior or flexible payload edge cases.
+
+## Risks / Trade-offs
+
+- **[Tighter validation may reject payloads that passed before]** -> Keep explicit bounds and document them so callers can adapt predictably.
+- **[Opaque upstream payloads may evolve]** -> Preserve bounded passthrough objects only where strict schemas would create brittle coupling.
+- **[More tests increase maintenance]** -> Limit the suite to critical create/get/update/list flows and validation boundaries.
+
+## Migration Plan
+
+1. Narrow the explicit schemas for agent tools where structure is stable.
+2. Add shared validation helpers for bounded freeform agent objects.
+3. Update response shaping for session and activity handlers.
+4. Add direct contract and handler coverage for the agent tool surface.
+
+## Open Questions
+
+- Which agent response fields must remain fully transparent to MCP clients for compatibility, and which can be reduced to safe summaries without breaking existing usage?
diff --git a/openspec/changes/tighten-agent-workflow-contracts/proposal.md b/openspec/changes/tighten-agent-workflow-contracts/proposal.md
new file mode 100644
index 0000000..b1f8e32
--- /dev/null
+++ b/openspec/changes/tighten-agent-workflow-contracts/proposal.md
@@ -0,0 +1,23 @@
+## Why
+
+The agent workflow surface is the least-constrained part of the MCP server: it accepts largely freeform payloads and has little direct regression coverage. That makes agent automation brittle and raises the chance of malformed, oversized, or unintended data crossing the MCP boundary unnoticed.
+
+## What Changes
+
+- Narrow agent session and activity contracts where the server can express stable structure.
+- Add explicit bounds or validation rules for the remaining flexible payloads such as activity content, metadata, plans, filters, and user state entries.
+- Define what agent response fields are safe to echo back to MCP clients.
+- Add direct tool-contract and handler tests for agent sessions and activities.
+
+## Capabilities
+
+### New Capabilities
+- `agent-workflow-contract-hardening`: agent session and activity tools validate inputs and return intentionally shaped outputs.
+- `agent-workflow-regression-coverage`: agent tools have direct contract and handler tests for critical create/get/update flows.
+
+### Modified Capabilities
+
+## Impact
+
+- Affected code: `src/core/types/tool.types.ts`, `src/features/agents/types/agent.types.ts`, `src/features/agents/handlers/agent.handler.ts`, and new/updated tests under `src/__tests__`.
+- Affected behavior: malformed or unsafe agent payloads fail earlier and agent responses become more predictable.
diff --git a/openspec/changes/tighten-agent-workflow-contracts/specs/agent-workflow-contract-hardening/spec.md b/openspec/changes/tighten-agent-workflow-contracts/specs/agent-workflow-contract-hardening/spec.md
new file mode 100644
index 0000000..4431b1f
--- /dev/null
+++ b/openspec/changes/tighten-agent-workflow-contracts/specs/agent-workflow-contract-hardening/spec.md
@@ -0,0 +1,16 @@
+## ADDED Requirements
+
+### Requirement: Agent flexible payloads SHALL be validated for type and bounds
+The server SHALL validate agent payload objects for expected type and documented size or complexity bounds before sending them to Linear.
+
+#### Scenario: Oversized agent activity content
+- **WHEN** a client sends agent activity content or metadata that exceeds the documented bounds
+- **THEN** the server SHALL reject the request with a validation error before invoking the Linear API
+
+### Requirement: Agent responses SHALL use documented safe fields
+The server SHALL return only intentionally documented agent response fields to MCP clients.
+
+#### Scenario: Agent session or activity is returned
+- **WHEN** the server returns an agent session or agent activity payload
+- **THEN** the response SHALL include only the documented safe fields for that tool
+- **AND** the server SHALL omit any unsupported or internal upstream fields
diff --git a/openspec/changes/tighten-agent-workflow-contracts/specs/agent-workflow-regression-coverage/spec.md b/openspec/changes/tighten-agent-workflow-contracts/specs/agent-workflow-regression-coverage/spec.md
new file mode 100644
index 0000000..41926a3
--- /dev/null
+++ b/openspec/changes/tighten-agent-workflow-contracts/specs/agent-workflow-regression-coverage/spec.md
@@ -0,0 +1,9 @@
+## ADDED Requirements
+
+### Requirement: Agent tools SHALL have direct regression coverage
+The repository SHALL include direct contract and handler tests for critical agent session and activity flows.
+
+#### Scenario: Release validation runs agent regression coverage
+- **WHEN** the repository test and release validation suites run
+- **THEN** they SHALL execute direct tests for agent session create, get, and update flows
+- **AND** they SHALL execute direct tests for agent activity create, get, and list flows
diff --git a/openspec/changes/tighten-agent-workflow-contracts/tasks.md b/openspec/changes/tighten-agent-workflow-contracts/tasks.md
new file mode 100644
index 0000000..b3b4196
--- /dev/null
+++ b/openspec/changes/tighten-agent-workflow-contracts/tasks.md
@@ -0,0 +1,9 @@
+## 1. Agent Contract Hardening
+
+- [x] 1.1 Replace or narrow loose agent schemas where structure is stable and add bounded validation for the remaining flexible payload objects
+- [x] 1.2 Shape agent session and activity responses around documented safe fields only
+
+## 2. Agent Regression Coverage
+
+- [x] 2.1 Add tool-contract tests for agent input validation and response shape
+- [x] 2.2 Add direct handler tests for agent session and activity create, get, update, and list flows
diff --git a/openspec/config.yaml b/openspec/config.yaml
new file mode 100644
index 0000000..392946c
--- /dev/null
+++ b/openspec/config.yaml
@@ -0,0 +1,20 @@
+schema: spec-driven
+
+# Project context (optional)
+# This is shown to AI when creating artifacts.
+# Add your tech stack, conventions, style guides, domain knowledge, etc.
+# Example:
+#   context: |
+#     Tech stack: TypeScript, React, Node.js
+#     We use conventional commits
+#     Domain: e-commerce platform
+
+# Per-artifact rules (optional)
+# Add custom rules for specific artifacts.
+# Example:
+#   rules:
+#     proposal:
+#       - Keep proposals under 500 words
+#       - Always include a "Non-goals" section
+#     tasks:
+#       - Break tasks into chunks of max 2 hours
diff --git a/package.json b/package.json
index e9ab025..c8f1bc4 100644
--- a/package.json
+++ b/package.json
@@ -1,8 +1,15 @@
 {
-  "name": "linear-mcp",
+  "name": "@kkaminsk/linear-mcp",
   "version": "1.0.0",
-  "description": "",
-  "main": "index.js",
+  "description": "Model Context Protocol server for Linear",
+  "main": "./build/index.js",
+  "bin": {
+    "linear-mcp": "./build/index.js"
+  },
+  "files": [
+    "build",
+    "README.md"
+  ],
   "type": "module",
   "scripts": {
     "test": "jest",
@@ -11,9 +18,16 @@
     "test:integration": "jest --testPathPattern '\\.integration\\.test\\.ts$'",
     "get-test-tokens": "node --loader ts-node/esm scripts/get-test-tokens.ts",
     "test:oauth": "node --loader ts-node/esm scripts/test-oauth.ts",
-    "build": "tsc && chmod +x build/index.js",
+    "build": "tsc && node -e \"const fs=require('fs');const file='build/index.js';if(fs.existsSync(file)){fs.chmodSync(file,0o755);}\"",
     "start": "node build/index.js",
-    "dev": "nodemon --watch src --ext ts --exec \"npm run build && npm start\""
+    "dev": "nodemon --watch src --ext ts --exec \"npm run build && npm start\"",
+    "verify:linear-api-contracts": "node scripts/verify-linear-api-contracts.mjs",
+    "verify:tool-catalog": "node scripts/verify-tool-catalog.mjs",
+    "verify:issue-workflows": "jest --runTestsByPath src/__tests__/issue-workflow-smoke.test.ts",
+    "verify:package-install": "node scripts/verify-packaged-install.mjs",
+    "verify:release": "npm run build && npm run verify:linear-api-contracts && npm run verify:tool-catalog && npm run verify:issue-workflows && npm run verify:package-install",
+    "prepack": "npm run build",
+    "prepublishOnly": "npm run verify:release"
   },
   "keywords": [],
   "author": "",
@@ -34,8 +48,9 @@
   },
   "dependencies": {
     "@graphql-typed-document-node/core": "^3.2.0",
-    "@linear/sdk": "^38.0.0",
+    "@linear/sdk": "^81.0.0",
     "@modelcontextprotocol/sdk": "^1.4.0",
+    "ajv": "^8.18.0",
     "graphql": "^16.10.0",
     "graphql-tag": "^2.12.6"
   },
diff --git a/scripts/linear-api-contract-audit.mjs b/scripts/linear-api-contract-audit.mjs
new file mode 100644
index 0000000..b1f3c2f
--- /dev/null
+++ b/scripts/linear-api-contract-audit.mjs
@@ -0,0 +1,128 @@
+export const guardedIssueWorkflowContracts = [
+  {
+    name: 'single-create GraphQL document',
+    owner: 'LinearGraphQLClient.createIssue raw GraphQL helper',
+    file: 'src/graphql/mutations.ts',
+    requiredSnippets: [
+      'mutation CreateIssue($input: IssueCreateInput!)',
+      'issueCreate(input: $input)',
+    ],
+    forbiddenSnippets: [
+      '$input: [IssueCreateInput!]!',
+    ],
+  },
+  {
+    name: 'single-create helper',
+    owner: 'LinearGraphQLClient.createIssue',
+    file: 'src/graphql/client.ts',
+    requiredSnippets: [
+      'async createIssue(input: CreateIssueInput): Promise<CreateIssueResponse>',
+      "const { CREATE_ISSUE_MUTATION } = await import('./mutations.js');",
+      'return this.executeData<CreateIssueResponse>(CREATE_ISSUE_MUTATION, { input });',
+    ],
+    forbiddenSnippets: [],
+  },
+  {
+    name: 'single-create MCP tool',
+    owner: 'IssueHandler.handleCreateIssue raw GraphQL path',
+    file: 'src/features/issues/handlers/issue.handler.ts',
+    requiredSnippets: [
+      'const payload = await client.createIssue(args);',
+    ],
+    forbiddenSnippets: [
+      'client.sdk.createIssue(args)',
+    ],
+  },
+  {
+    name: 'batch-create GraphQL document',
+    owner: 'LinearGraphQLClient.createIssues raw GraphQL helper',
+    file: 'src/graphql/mutations.ts',
+    requiredSnippets: [
+      'mutation CreateBatchIssues($input: IssueBatchCreateInput!)',
+      'issueBatchCreate(input: $input)',
+    ],
+    forbiddenSnippets: [
+      '$input: [IssueCreateInput!]!',
+    ],
+  },
+  {
+    name: 'batch-create helper',
+    owner: 'LinearGraphQLClient.createIssues',
+    file: 'src/graphql/client.ts',
+    requiredSnippets: [
+      'async createIssues(issues: CreateIssueInput[]): Promise<IssueBatchResponse>',
+      "const { CREATE_BATCH_ISSUES } = await import('./mutations.js');",
+      'input: { issues }',
+    ],
+    forbiddenSnippets: [],
+  },
+  {
+    name: 'batch-create MCP tool',
+    owner: 'IssueHandler.handleCreateIssues SDK path',
+    file: 'src/features/issues/handlers/issue.handler.ts',
+    requiredSnippets: [
+      "'createIssueBatch'",
+      '() => client.sdk.createIssueBatch({ issues: args.issues })',
+    ],
+    forbiddenSnippets: [
+      'client.createIssues(args.issues)',
+    ],
+  },
+  {
+    name: 'bulk-delete GraphQL document',
+    owner: 'LinearGraphQLClient.deleteIssues raw GraphQL helper',
+    file: 'src/graphql/mutations.ts',
+    requiredSnippets: [
+      'mutation DeleteIssues($ids: [String!]!)',
+      'issueDelete(ids: $ids)',
+    ],
+    forbiddenSnippets: [],
+  },
+  {
+    name: 'bulk-delete helper',
+    owner: 'LinearGraphQLClient.deleteIssues',
+    file: 'src/graphql/client.ts',
+    requiredSnippets: [
+      'async deleteIssues(ids: string[]): Promise<DeleteIssuesResponse>',
+      "const { DELETE_ISSUES_MUTATION } = await import('./mutations.js');",
+      'return this.executeData<DeleteIssuesResponse>(DELETE_ISSUES_MUTATION, { ids });',
+    ],
+    forbiddenSnippets: [],
+  },
+  {
+    name: 'issue search handler ownership',
+    owner: 'IssueHandler.handleSearchIssues query-aware MCP path',
+    file: 'src/features/issues/handlers/issue.handler.ts',
+    requiredSnippets: [
+      'const payload = await client.searchIssues(args.query, searchOptions);',
+    ],
+    forbiddenSnippets: [
+      'SEARCH_ISSUES_QUERY',
+    ],
+  },
+  {
+    name: 'issue search client ownership',
+    owner: 'LinearGraphQLClient.searchIssues raw GraphQL path',
+    file: 'src/graphql/client.ts',
+    requiredSnippets: [
+      'async searchIssues(',
+      "const { SEARCH_ISSUES_QUERY } = await import('./queries.js');",
+      'term: query',
+    ],
+    forbiddenSnippets: [
+      'this.linearClient.searchIssues(',
+    ],
+  },
+  {
+    name: 'issue search query document',
+    owner: 'Raw issue search GraphQL document',
+    file: 'src/graphql/queries.ts',
+    requiredSnippets: [
+      'SEARCH_ISSUES_QUERY',
+      'query SearchIssues(',
+      '$term: String!',
+      '$filter: IssueFilter',
+    ],
+    forbiddenSnippets: [],
+  },
+];
diff --git a/scripts/release-utils.mjs b/scripts/release-utils.mjs
new file mode 100644
index 0000000..746ccb4
--- /dev/null
+++ b/scripts/release-utils.mjs
@@ -0,0 +1,98 @@
+import { dirname, resolve } from 'node:path';
+import { fileURLToPath } from 'node:url';
+import { Client } from '@modelcontextprotocol/sdk/client/index.js';
+import { StdioClientTransport } from '@modelcontextprotocol/sdk/client/stdio.js';
+
+export const repoRoot = resolve(dirname(fileURLToPath(import.meta.url)), '..');
+export const npmCommand = process.platform === 'win32' ? 'npm.cmd' : 'npm';
+
+export function buildProcessEnv(extra = {}) {
+  const merged = {
+    ...process.env,
+    ...extra,
+  };
+
+  return Object.fromEntries(
+    Object.entries(merged).filter(([, value]) => typeof value === 'string' && value.length > 0)
+  );
+}
+
+export function assert(condition, message) {
+  if (!condition) {
+    throw new Error(message);
+  }
+}
+
+export function sortedToolNames(tools) {
+  return [...tools].map(tool => tool.name).sort();
+}
+
+async function withStdioClient({
+  command,
+  args = [],
+  cwd = repoRoot,
+  env,
+}, callback) {
+  const transport = new StdioClientTransport({
+    command,
+    args,
+    cwd,
+    env,
+    stderr: 'pipe',
+  });
+  let stderr = '';
+  transport.stderr?.on('data', chunk => {
+    stderr += chunk.toString();
+  });
+
+  const client = new Client(
+    {
+      name: 'linear-release-smoke',
+      version: '1.0.0',
+    },
+    {
+      capabilities: {},
+    }
+  );
+
+  await client.connect(transport);
+
+  try {
+    const result = await callback(client);
+    await new Promise(resolve => setTimeout(resolve, 50));
+    return {
+      result,
+      stderr,
+    };
+  } finally {
+    await client.close();
+  }
+}
+
+export async function listToolsFromStdio(options) {
+  const { result, stderr } = await withStdioClient(options, client => client.listTools());
+
+  return {
+    tools: result.tools,
+    stderr,
+  };
+}
+
+export async function callToolFromStdio({
+  name,
+  arguments: toolArguments = {},
+  ...clientOptions
+}) {
+  const { result, stderr } = await withStdioClient(
+    clientOptions,
+    client => client.callTool({
+      name,
+      arguments: toolArguments,
+    })
+  );
+
+  return {
+    result,
+    stderr,
+  };
+}
diff --git a/scripts/verify-linear-api-contracts.mjs b/scripts/verify-linear-api-contracts.mjs
new file mode 100644
index 0000000..d97db7a
--- /dev/null
+++ b/scripts/verify-linear-api-contracts.mjs
@@ -0,0 +1,46 @@
+import { readFileSync } from 'node:fs';
+import { join } from 'node:path';
+import { guardedIssueWorkflowContracts } from './linear-api-contract-audit.mjs';
+import { assert, repoRoot } from './release-utils.mjs';
+
+function readRepoFile(relativePath) {
+  return readFileSync(join(repoRoot, ...relativePath.split('/')), 'utf8');
+}
+
+for (const contract of guardedIssueWorkflowContracts) {
+  const source = readRepoFile(contract.file);
+
+  for (const snippet of contract.requiredSnippets) {
+    assert(
+      source.includes(snippet),
+      `Linear API contract audit failed for ${contract.name}: expected ${contract.owner} to include ${JSON.stringify(snippet)} in ${contract.file}.`
+    );
+  }
+
+  for (const snippet of contract.forbiddenSnippets) {
+    assert(
+      !source.includes(snippet),
+      `Linear API contract audit failed for ${contract.name}: ${contract.owner} must not include ${JSON.stringify(snippet)} in ${contract.file}.`
+    );
+  }
+}
+
+const packageJson = JSON.parse(readRepoFile('package.json'));
+const readme = readRepoFile('README.md');
+
+assert(
+  typeof packageJson.scripts?.['verify:linear-api-contracts'] === 'string',
+  'package.json must expose npm run verify:linear-api-contracts.'
+);
+assert(
+  typeof packageJson.scripts?.['verify:release'] === 'string'
+    && packageJson.scripts['verify:release'].includes('verify:linear-api-contracts'),
+  'verify:release must run the Linear API contract audit.'
+);
+assert(
+  readme.includes('## Guarded issue workflow contracts')
+    && readme.includes('`npm run verify:linear-api-contracts`'),
+  'README must document the guarded issue workflow contract audit.'
+);
+
+console.log(`Linear API contract audit passed for ${guardedIssueWorkflowContracts.length} guarded issue workflow surfaces.`);
diff --git a/scripts/verify-packaged-install.mjs b/scripts/verify-packaged-install.mjs
new file mode 100644
index 0000000..804ad0d
--- /dev/null
+++ b/scripts/verify-packaged-install.mjs
@@ -0,0 +1,143 @@
+import { execFileSync } from 'node:child_process';
+import { existsSync, mkdtempSync, readFileSync, rmSync, unlinkSync } from 'node:fs';
+import { tmpdir } from 'node:os';
+import { join } from 'node:path';
+import {
+  assert,
+  buildProcessEnv,
+  callToolFromStdio,
+  listToolsFromStdio,
+  repoRoot,
+} from './release-utils.mjs';
+
+function runNpm(args, options = {}) {
+  const npmExecPath = process.env.npm_execpath;
+  if (npmExecPath) {
+    return execFileSync(process.execPath, [npmExecPath, ...args], options);
+  }
+
+  const npmCommand = process.platform === 'win32' ? 'npm.cmd' : 'npm';
+  return execFileSync(npmCommand, args, {
+    ...options,
+    shell: process.platform === 'win32',
+  });
+}
+
+function readInstalledFile(installedRoot, relativePath) {
+  return readFileSync(join(installedRoot, ...relativePath.split('/')), 'utf8');
+}
+
+const packageJson = JSON.parse(readFileSync(join(repoRoot, 'package.json'), 'utf8'));
+assert(packageJson.bin?.['linear-mcp'] === './build/index.js', 'package.json must publish the linear-mcp executable from build/index.js.');
+assert(Array.isArray(packageJson.files) && packageJson.files.includes('build'), 'package.json must publish the build directory.');
+
+const packOutput = runNpm(
+  ['pack', '--json', '--ignore-scripts'],
+  {
+    cwd: repoRoot,
+    encoding: 'utf8',
+  }
+);
+const [{ filename }] = JSON.parse(packOutput);
+const tarballPath = join(repoRoot, filename);
+const tempDir = mkdtempSync(join(tmpdir(), 'linear-mcp-package-'));
+
+async function listToolsWithAuthEnv(installedBuild, authEnv = {}) {
+  return await listToolsFromStdio({
+    command: process.execPath,
+    args: [installedBuild],
+    cwd: tempDir,
+    env: buildProcessEnv({
+      LINEAR_MCP_TRANSPORT: 'stdio',
+      LINEAR_API_KEY: undefined,
+      LINEAR_ACCESS_TOKEN: undefined,
+      ...authEnv,
+    }),
+  });
+}
+
+try {
+  runNpm(['init', '-y'], {
+    cwd: tempDir,
+    stdio: 'ignore',
+  });
+  runNpm(
+    ['install', '--ignore-scripts', '--no-package-lock', '--prefer-offline', tarballPath],
+    {
+      cwd: tempDir,
+      stdio: 'ignore',
+    }
+  );
+
+  const installedPackageRoot = join(tempDir, 'node_modules', packageJson.name);
+  const installedBuild = join(installedPackageRoot, 'build', 'index.js');
+  assert(existsSync(installedBuild), 'Fresh package install is missing build/index.js.');
+
+  const packagedSearchClient = readInstalledFile(installedPackageRoot, 'build/graphql/client.js');
+  const packagedSearchQuery = readInstalledFile(installedPackageRoot, 'build/graphql/queries.js');
+
+  assert(
+    packagedSearchClient.includes('term: query')
+      && packagedSearchClient.includes('this.executeData(SEARCH_ISSUES_QUERY, variables'),
+    'Fresh package install must ship the raw issue-search helper that sends the free-text term separately from IssueFilter variables.'
+  );
+  assert(
+    !packagedSearchClient.includes('this.linearClient.searchIssues('),
+    'Fresh package install must not delegate linear_search_issues to the SDK searchIssues path, which can leak the query term into IssueFilter.search.'
+  );
+  assert(
+    packagedSearchQuery.includes('query SearchIssues(')
+      && packagedSearchQuery.includes('term: $term')
+      && packagedSearchQuery.includes('filter: $filter'),
+    'Fresh package install must include the raw SearchIssues GraphQL document with separate term and filter variables.'
+  );
+
+  const { tools, stderr } = await listToolsWithAuthEnv(installedBuild);
+  const { stderr: apiKeyStderr } = await listToolsWithAuthEnv(installedBuild, {
+    LINEAR_API_KEY: 'packaged-api-key',
+  });
+  const { stderr: accessTokenStderr } = await listToolsWithAuthEnv(installedBuild, {
+    LINEAR_ACCESS_TOKEN: 'packaged-access-token',
+  });
+  const { result: capabilitiesResult } = await callToolFromStdio({
+    command: process.execPath,
+    args: [installedBuild],
+    cwd: tempDir,
+    env: buildProcessEnv({
+      LINEAR_MCP_TRANSPORT: 'stdio',
+      LINEAR_API_KEY: undefined,
+      LINEAR_ACCESS_TOKEN: undefined,
+    }),
+    name: 'linear_get_capabilities',
+  });
+
+  assert(tools.length > 0, 'Fresh package install did not return any tools.');
+  assert(
+    stderr.includes('Auth: no LINEAR_API_KEY or LINEAR_ACCESS_TOKEN detected.'),
+    'Packaged startup must explain how to configure API-key auth when neither env variable is set.'
+  );
+  assert(
+    stderr.includes(`Build: ${packageJson.name}@${packageJson.version}`),
+    'Packaged startup must emit package-derived build provenance diagnostics.'
+  );
+  assert(
+    apiKeyStderr.includes('Auth: LINEAR_API_KEY detected.'),
+    'Packaged startup must accept LINEAR_API_KEY for API-key auth.'
+  );
+  assert(
+    accessTokenStderr.includes('Auth: LINEAR_ACCESS_TOKEN detected.'),
+    'Packaged startup must accept LINEAR_ACCESS_TOKEN for API-key auth.'
+  );
+  assert(
+    capabilitiesResult.structuredContent?.server?.name === packageJson.name
+      && capabilitiesResult.structuredContent?.server?.version === packageJson.version,
+    'Fresh package install must report package-derived build provenance through linear_get_capabilities.'
+  );
+
+  console.log('Fresh package install boots and lists MCP tools.');
+} finally {
+  if (existsSync(tarballPath)) {
+    unlinkSync(tarballPath);
+  }
+  rmSync(tempDir, { recursive: true, force: true });
+}
diff --git a/scripts/verify-tool-catalog.mjs b/scripts/verify-tool-catalog.mjs
new file mode 100644
index 0000000..a4b62ee
--- /dev/null
+++ b/scripts/verify-tool-catalog.mjs
@@ -0,0 +1,150 @@
+import { readFileSync } from 'node:fs';
+import { join } from 'node:path';
+import { getAdvertisedToolSchemas } from '../build/core/types/tool.types.js';
+import { getRuntimeCapabilities } from '../build/core/capabilities.js';
+import {
+  assert,
+  buildProcessEnv,
+  callToolFromStdio,
+  listToolsFromStdio,
+  repoRoot,
+  sortedToolNames,
+} from './release-utils.mjs';
+
+function stableStringify(value) {
+  if (Array.isArray(value)) {
+    return `[${value.map(item => stableStringify(item)).join(',')}]`;
+  }
+
+  if (value && typeof value === 'object') {
+    return `{${Object.entries(value)
+      .sort(([left], [right]) => left.localeCompare(right))
+      .map(([key, nestedValue]) => `${JSON.stringify(key)}:${stableStringify(nestedValue)}`)
+      .join(',')}}`;
+  }
+
+  return JSON.stringify(value);
+}
+
+const REQUIRED_RELEASED_TOOLS = [
+  'linear_bulk_update_issues',
+  'linear_get_comment',
+  'linear_list_comments',
+  'linear_get_issue_comments',
+  'linear_create_comment',
+  'linear_update_comment',
+  'linear_delete_comment',
+  'linear_resolve_comment',
+  'linear_unresolve_comment',
+];
+
+const readme = readFileSync(join(repoRoot, 'README.md'), 'utf8');
+const packageJson = JSON.parse(readFileSync(join(repoRoot, 'package.json'), 'utf8'));
+const serverPath = join(repoRoot, 'build', 'index.js');
+const expectedTools = getAdvertisedToolSchemas(getRuntimeCapabilities({ transport: 'stdio' }));
+const { tools } = await listToolsFromStdio({
+  command: process.execPath,
+  args: [serverPath],
+  env: buildProcessEnv({
+    LINEAR_MCP_TRANSPORT: 'stdio',
+  }),
+});
+const { result: capabilitiesResult } = await callToolFromStdio({
+  command: process.execPath,
+  args: [serverPath],
+  env: buildProcessEnv({
+    LINEAR_MCP_TRANSPORT: 'stdio',
+  }),
+  name: 'linear_get_capabilities',
+});
+
+const actualNames = sortedToolNames(tools);
+const expectedNames = sortedToolNames(expectedTools);
+const actualToolMap = new Map(tools.map(tool => [tool.name, tool]));
+const expectedToolMap = new Map(expectedTools.map(tool => [tool.name, tool]));
+const builtCapabilities = capabilitiesResult.structuredContent;
+
+assert(
+  JSON.stringify(actualNames) === JSON.stringify(expectedNames),
+  `Built server tool catalog drifted from the expected stdio release catalog.\nExpected: ${expectedNames.join(', ')}\nActual: ${actualNames.join(', ')}`
+);
+
+for (const toolName of REQUIRED_RELEASED_TOOLS) {
+  assert(actualNames.includes(toolName), `Built server is missing released tool ${toolName}.`);
+  assert(readme.includes(toolName), `README release surface is missing ${toolName}.`);
+}
+
+for (const toolName of ['linear_create_issue', 'linear_create_issues']) {
+  const actualTool = actualToolMap.get(toolName);
+  const expectedTool = expectedToolMap.get(toolName);
+
+  assert(actualTool, `Built server is missing ${toolName}.`);
+  assert(expectedTool, `Expected release catalog is missing ${toolName}.`);
+  assert(
+    stableStringify(actualTool.inputSchema) === stableStringify(expectedTool.inputSchema),
+    `Built server schema for ${toolName} drifted from the expected release schema.`
+  );
+  assert(readme.includes(toolName), `README release surface is missing ${toolName}.`);
+}
+
+const singleCreateTool = actualToolMap.get('linear_create_issue');
+const batchCreateTool = actualToolMap.get('linear_create_issues');
+const singleRequired = Array.isArray(singleCreateTool?.inputSchema?.required)
+  ? singleCreateTool.inputSchema.required
+  : [];
+const batchRequired = Array.isArray(batchCreateTool?.inputSchema?.required)
+  ? batchCreateTool.inputSchema.required
+  : [];
+const batchIssuesProperty = batchCreateTool?.inputSchema?.properties?.issues;
+
+assert(
+  singleRequired.includes('title') && singleRequired.includes('teamId'),
+  'Built server must advertise linear_create_issue as a single-item create contract.'
+);
+assert(
+  batchRequired.includes('issues')
+    && batchIssuesProperty?.type === 'array'
+    && batchIssuesProperty?.minItems === 1,
+  'Built server must advertise linear_create_issues as the batch-create contract.'
+);
+assert(
+  JSON.stringify(singleCreateTool?.inputSchema) !== JSON.stringify(batchCreateTool?.inputSchema),
+  'Built server must keep single and batch issue-create schemas distinct.'
+);
+
+const searchTool = actualToolMap.get('linear_search_issues');
+const searchRequired = Array.isArray(searchTool?.inputSchema?.required)
+  ? searchTool.inputSchema.required
+  : [];
+const searchProperties = searchTool?.inputSchema?.properties ?? {};
+
+assert(searchTool, 'Built server is missing linear_search_issues.');
+assert(
+  searchRequired.includes('query'),
+  'Built server must advertise linear_search_issues as a query-backed search contract.'
+);
+assert(
+  !Object.prototype.hasOwnProperty.call(searchProperties, 'filter'),
+  'Built server must not advertise a generic filter object on linear_search_issues.'
+);
+assert(
+  !Object.prototype.hasOwnProperty.call(searchProperties, 'orderBy'),
+  'Built server must keep ranked issue search distinct from filter-first issue listing.'
+);
+assert(
+  readme.includes('`linear_search_issues` is the free-text search path')
+    && readme.includes('The search path sends `query` through Linear\'s search backend'),
+  'README release surface must document query-backed issue search semantics.'
+);
+
+assert(
+  readme.includes('Version 1.0.0'),
+  'README release surface notes must describe the current released workflow version.'
+);
+assert(
+  builtCapabilities?.server?.name === packageJson.name
+    && builtCapabilities?.server?.version === packageJson.version,
+  'Built server must report package-derived build provenance through linear_get_capabilities.'
+);
+
+console.log('Built tool catalog matches the expected stdio release surface.');
diff --git a/src/__tests__/agent-handler.test.ts b/src/__tests__/agent-handler.test.ts
new file mode 100644
index 0000000..2323e0d
--- /dev/null
+++ b/src/__tests__/agent-handler.test.ts
@@ -0,0 +1,382 @@
+import { beforeEach, describe, expect, it, jest } from '@jest/globals';
+import { LinearAuth } from '../auth.js';
+import { AgentHandler } from '../features/agents/handlers/agent.handler.js';
+import {
+  CreateAgentActivityInput,
+  CreateAgentSessionOnCommentInput,
+  CreateAgentSessionOnIssueInput,
+  UpdateAgentSessionInput,
+} from '../features/agents/types/agent.types.js';
+
+type MockAgentSdk = {
+  agentSession: jest.MockedFunction<(id: string) => Promise<unknown>>;
+  agentSessions: jest.MockedFunction<(args?: Record<string, unknown>) => Promise<unknown>>;
+  agentSessionCreateOnIssue: jest.MockedFunction<(args: CreateAgentSessionOnIssueInput) => Promise<unknown>>;
+  agentSessionCreateOnComment: jest.MockedFunction<(args: CreateAgentSessionOnCommentInput) => Promise<unknown>>;
+  updateAgentSession: jest.MockedFunction<(id: string, input: Record<string, unknown>) => Promise<unknown>>;
+  agentActivity: jest.MockedFunction<(id: string) => Promise<unknown>>;
+  agentActivities: jest.MockedFunction<(args?: Record<string, unknown>) => Promise<unknown>>;
+  createAgentActivity: jest.MockedFunction<(args: CreateAgentActivityInput) => Promise<unknown>>;
+};
+
+type MockAgentClient = {
+  sdk: MockAgentSdk;
+  executeSdk: jest.MockedFunction<(operation: string, request: () => Promise<unknown>) => Promise<unknown>>;
+};
+
+describe('AgentHandler', () => {
+  let handler: AgentHandler;
+  let mockClient: MockAgentClient;
+
+  beforeEach(() => {
+    const sdk: MockAgentSdk = {
+      agentSession: jest.fn<(id: string) => Promise<unknown>>(),
+      agentSessions: jest.fn<(args?: Record<string, unknown>) => Promise<unknown>>(),
+      agentSessionCreateOnIssue: jest.fn<(args: CreateAgentSessionOnIssueInput) => Promise<unknown>>(),
+      agentSessionCreateOnComment: jest.fn<(args: CreateAgentSessionOnCommentInput) => Promise<unknown>>(),
+      updateAgentSession: jest.fn<(id: string, input: Record<string, unknown>) => Promise<unknown>>(),
+      agentActivity: jest.fn<(id: string) => Promise<unknown>>(),
+      agentActivities: jest.fn<(args?: Record<string, unknown>) => Promise<unknown>>(),
+      createAgentActivity: jest.fn<(args: CreateAgentActivityInput) => Promise<unknown>>(),
+    };
+
+    mockClient = {
+      sdk,
+      executeSdk: jest.fn<(operation: string, request: () => Promise<unknown>) => Promise<unknown>>()
+        .mockImplementation(async (_operation, request) => request()),
+    };
+
+    const auth = {
+      isAuthenticated: jest.fn(() => true),
+      ensureAuthenticatedClient: jest.fn(async () => undefined),
+      getGraphQLClient: jest.fn(() => mockClient),
+    } as unknown as LinearAuth;
+
+    handler = new AgentHandler(auth);
+  });
+
+  it('returns safe fields when reading an agent session', async () => {
+    mockClient.sdk.agentSession.mockResolvedValueOnce({
+      id: 'session-1',
+      status: 'running',
+      state: 'active',
+      externalLink: 'https://example.com/session/1',
+      externalUrls: [
+        {
+          label: 'Transcript',
+          url: 'https://example.com/transcript/1',
+          secret: 'hidden',
+        },
+      ],
+      issue: Promise.resolve({
+        id: 'issue-1',
+        identifier: 'TEAM-1',
+        title: 'Issue',
+      }),
+      internalOnly: 'hidden',
+    });
+
+    const result = await handler.handleGetAgentSession({ id: 'session-1' });
+
+    expect(result.structuredContent).toMatchObject({
+      agentSession: {
+        id: 'session-1',
+        status: 'running',
+        externalLink: 'https://example.com/session/1',
+        externalUrls: [
+          {
+            label: 'Transcript',
+            url: 'https://example.com/transcript/1',
+          },
+        ],
+        issue: {
+          id: 'issue-1',
+          identifier: 'TEAM-1',
+        },
+      },
+    });
+    expect(result.structuredContent?.agentSession).toEqual(
+      expect.not.objectContaining({
+        internalOnly: expect.anything(),
+      })
+    );
+  });
+
+  it('creates agent sessions on issues with shaped response fields', async () => {
+    const args: CreateAgentSessionOnIssueInput = {
+      issueId: 'TEAM-1',
+      externalLink: 'https://example.com/session/1',
+      externalUrls: [
+        {
+          label: 'Transcript',
+          url: 'https://example.com/transcript/1',
+        },
+      ],
+    };
+
+    mockClient.sdk.agentSessionCreateOnIssue.mockResolvedValueOnce({
+      success: true,
+      agentSession: {
+        id: 'session-1',
+        status: 'running',
+        externalLink: 'https://example.com/session/1',
+        issue: Promise.resolve({
+          id: 'issue-1',
+          identifier: 'TEAM-1',
+          title: 'Issue',
+        }),
+      },
+    });
+
+    const result = await handler.handleCreateAgentSessionOnIssue(args);
+
+    expect(mockClient.sdk.agentSessionCreateOnIssue).toHaveBeenCalledWith(args);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      agentSession: {
+        id: 'session-1',
+        issue: {
+          identifier: 'TEAM-1',
+        },
+      },
+    });
+  });
+
+  it('creates agent sessions on comments with shaped response fields', async () => {
+    const args: CreateAgentSessionOnCommentInput = {
+      commentId: 'comment-1',
+      externalLink: 'https://example.com/session/2',
+    };
+
+    mockClient.sdk.agentSessionCreateOnComment.mockResolvedValueOnce({
+      success: true,
+      agentSession: {
+        id: 'session-2',
+        status: 'running',
+        externalLink: 'https://example.com/session/2',
+        comment: Promise.resolve({
+          id: 'comment-1',
+          body: 'Comment body',
+        }),
+      },
+    });
+
+    const result = await handler.handleCreateAgentSessionOnComment(args);
+
+    expect(mockClient.sdk.agentSessionCreateOnComment).toHaveBeenCalledWith(args);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      agentSession: {
+        id: 'session-2',
+        comment: {
+          id: 'comment-1',
+          body: 'Comment body',
+        },
+      },
+    });
+  });
+
+  it('updates agent sessions with parsed timestamps and safe response fields', async () => {
+    const args: UpdateAgentSessionInput = {
+      id: 'session-1',
+      dismissedAt: '2026-04-10T00:00:00.000Z',
+      plan: {
+        next: 'summarize',
+      },
+      userState: [
+        {
+          userId: 'user-1',
+          lastReadAt: '2026-04-10T00:10:00.000Z',
+        },
+      ],
+    };
+
+    mockClient.sdk.updateAgentSession.mockResolvedValueOnce({
+      success: true,
+      agentSession: {
+        id: 'session-1',
+        status: 'completed',
+      },
+    });
+
+    const result = await handler.handleUpdateAgentSession(args);
+
+    expect(mockClient.sdk.updateAgentSession).toHaveBeenCalledWith(
+      'session-1',
+      expect.objectContaining({
+        dismissedAt: expect.any(Date),
+        userState: [
+          expect.objectContaining({
+            userId: 'user-1',
+            lastReadAt: expect.any(Date),
+          }),
+        ],
+      })
+    );
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      agentSession: {
+        id: 'session-1',
+        status: 'completed',
+      },
+    });
+  });
+
+  it('lists agent sessions with safe response shape', async () => {
+    mockClient.sdk.agentSessions.mockResolvedValueOnce({
+      nodes: [
+        {
+          id: 'session-1',
+          status: 'running',
+          externalLink: 'https://example.com/session/1',
+        },
+      ],
+      pageInfo: {
+        hasNextPage: false,
+        endCursor: null,
+      },
+    });
+
+    const result = await handler.handleListAgentSessions({ first: 1 });
+
+    expect(result.structuredContent).toMatchObject({
+      agentSessions: [
+        {
+          id: 'session-1',
+          status: 'running',
+        },
+      ],
+      pageInfo: {
+        hasNextPage: false,
+        endCursor: null,
+      },
+    });
+  });
+
+  it('returns bounded flexible fields for agent activity reads', async () => {
+    mockClient.sdk.agentActivity.mockResolvedValueOnce({
+      id: 'activity-1',
+      signal: 'PROGRESS',
+      ephemeral: false,
+      content: {
+        summary: 'Working',
+        nested: {
+          step: 'fetch',
+        },
+        oversized: 'x'.repeat(5001),
+      },
+      signalMetadata: {
+        code: 'info',
+      },
+      contextualMetadata: {
+        source: 'linear',
+      },
+      agentSession: Promise.resolve({
+        id: 'session-1',
+        status: 'running',
+      }),
+      internalOnly: 'hidden',
+    });
+
+    const result = await handler.handleGetAgentActivity({ id: 'activity-1' });
+    const agentActivity = result.structuredContent?.agentActivity as Record<string, unknown>;
+    const content = agentActivity.content as Record<string, unknown>;
+
+    expect(result.structuredContent).toMatchObject({
+      agentActivity: {
+        id: 'activity-1',
+        content: {
+          summary: 'Working',
+          nested: {
+            step: 'fetch',
+          },
+        },
+        signalMetadata: {
+          code: 'info',
+        },
+        contextualMetadata: {
+          source: 'linear',
+        },
+        agentSession: {
+          id: 'session-1',
+          status: 'running',
+        },
+      },
+    });
+    expect(content).not.toHaveProperty('oversized');
+    expect(agentActivity).toEqual(
+      expect.not.objectContaining({
+        internalOnly: expect.anything(),
+      })
+    );
+  });
+
+  it('lists agent activities with safe response shape', async () => {
+    mockClient.sdk.agentActivities.mockResolvedValueOnce({
+      nodes: [
+        {
+          id: 'activity-1',
+          content: {
+            summary: 'Working',
+          },
+        },
+      ],
+      pageInfo: {
+        hasNextPage: false,
+        endCursor: null,
+      },
+    });
+
+    const result = await handler.handleListAgentActivities({ first: 1 });
+
+    expect(result.structuredContent).toMatchObject({
+      agentActivities: [
+        {
+          id: 'activity-1',
+          content: {
+            summary: 'Working',
+          },
+        },
+      ],
+      pageInfo: {
+        hasNextPage: false,
+        endCursor: null,
+      },
+    });
+  });
+
+  it('creates agent activities with shaped response fields', async () => {
+    const args: CreateAgentActivityInput = {
+      agentSessionId: 'session-1',
+      content: {
+        summary: 'Working',
+      },
+      contextualMetadata: {
+        source: 'linear',
+      },
+    };
+
+    mockClient.sdk.createAgentActivity.mockResolvedValueOnce({
+      success: true,
+      agentActivity: {
+        id: 'activity-1',
+        content: {
+          summary: 'Working',
+        },
+      },
+    });
+
+    const result = await handler.handleCreateAgentActivity(args);
+
+    expect(mockClient.sdk.createAgentActivity).toHaveBeenCalledWith(args);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      agentActivity: {
+        id: 'activity-1',
+        content: {
+          summary: 'Working',
+        },
+      },
+    });
+  });
+});
diff --git a/src/__tests__/auth-handler.test.ts b/src/__tests__/auth-handler.test.ts
new file mode 100644
index 0000000..ab9b788
--- /dev/null
+++ b/src/__tests__/auth-handler.test.ts
@@ -0,0 +1,23 @@
+import { describe, expect, it } from '@jest/globals';
+import { LinearAuth } from '../auth.js';
+import { AuthHandler } from '../features/auth/handlers/auth.handler.js';
+
+describe('AuthHandler', () => {
+  it('returns callback guidance with the issued OAuth state', async () => {
+    const handler = new AuthHandler(new LinearAuth());
+
+    const result = await handler.handleAuth({
+      clientId: 'client-id',
+      clientSecret: 'client-secret',
+      redirectUri: 'http://localhost:3000/callback',
+    });
+
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      actor: 'app',
+    });
+    expect(result.structuredContent?.state).toEqual(expect.any(String));
+    expect(result.structuredContent?.nextStep).toContain('linear_auth_callback');
+    expect(result.structuredContent?.nextStep).toContain('single-use');
+  });
+});
diff --git a/src/__tests__/auth.integration.test.ts b/src/__tests__/auth.integration.test.ts
index ba1ff5c..ec09784 100644
--- a/src/__tests__/auth.integration.test.ts
+++ b/src/__tests__/auth.integration.test.ts
@@ -1,9 +1,10 @@
 import { describe, it, expect, beforeAll } from '@jest/globals';
-import { LinearAuth } from '../auth';
 import { LinearClient } from '@linear/sdk';
+import { LinearAuth } from '../auth.js';
 
 // Skip tests if no credentials are configured
-const hasAPIKeyCredentials = process.env.LINEAR_API_KEY;
+const apiKeyCredential = process.env.LINEAR_API_KEY ?? process.env.LINEAR_ACCESS_TOKEN;
+const hasAPIKeyCredentials = Boolean(apiKeyCredential);
 const hasOAuthCredentials = process.env.LINEAR_CLIENT_ID && 
                           process.env.LINEAR_CLIENT_SECRET && 
                           process.env.LINEAR_REDIRECT_URI;
@@ -19,7 +20,7 @@ const hasOAuthCredentials = process.env.LINEAR_CLIENT_ID &&
       auth = new LinearAuth();
       auth.initialize({
         type: 'api',
-        apiKey: process.env.LINEAR_API_KEY!
+        apiKey: apiKeyCredential!
       });
     });
 
@@ -59,9 +60,11 @@ const hasOAuthCredentials = process.env.LINEAR_CLIENT_ID &&
       expect(url).toContain(`client_id=${process.env.LINEAR_CLIENT_ID}`);
       expect(url).toContain(`redirect_uri=${encodeURIComponent(process.env.LINEAR_REDIRECT_URI!)}`);
       expect(url).toContain('response_type=code');
-      expect(url).toContain('scope=read%2Cwrite%2Cissues%3Acreate%2Coffline_access');
-      expect(url).toContain('actor=application');
+      expect(url).toContain('scope=read%2Cwrite%2Cissues%3Acreate');
+      expect(url).toContain('actor=app');
       expect(url).toContain('state=');
+      expect(url).not.toContain('offline_access');
+      expect(url).not.toContain('access_type=');
     });
 
     // Skip token tests if we don't have auth code and refresh token
@@ -72,7 +75,9 @@ const hasOAuthCredentials = process.env.LINEAR_CLIENT_ID &&
         throw new Error('LINEAR_AUTH_CODE environment variable is required');
       }
 
-      await auth.handleCallback(authCode);
+      auth.getAuthorizationUrl();
+      const state = auth.getPendingOAuthState();
+      await auth.handleCallback(authCode, state!);
       expect(auth.isAuthenticated()).toBe(true);
     });
 
diff --git a/src/__tests__/auth.test.ts b/src/__tests__/auth.test.ts
index 5dc7dd7..749c120 100644
--- a/src/__tests__/auth.test.ts
+++ b/src/__tests__/auth.test.ts
@@ -65,6 +65,29 @@ describe('LinearAuth', () => {
       expect(url).toContain('https://linear.app/oauth/authorize');
       expect(url).toContain('client_id=test-client-id');
       expect(url).toContain('redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fcallback');
+      expect(url).toContain('scope=read%2Cwrite%2Cissues%3Acreate');
+      expect(url).toContain('actor=app');
+      expect(url).toContain('state=');
+      expect(url).not.toContain('offline_access');
+      expect(url).not.toContain('access_type=');
+    });
+
+    it('should generate cryptographically strong single-use state values', () => {
+      auth.initialize({
+        type: 'oauth',
+        clientId: 'test-client-id',
+        clientSecret: 'test-client-secret',
+        redirectUri: 'http://localhost:3000/callback'
+      });
+
+      auth.getAuthorizationUrl();
+      const firstState = auth.getPendingOAuthState();
+      auth.getAuthorizationUrl();
+      const secondState = auth.getPendingOAuthState();
+
+      expect(firstState).toMatch(/^[A-Za-z0-9_-]{20,}$/);
+      expect(secondState).toMatch(/^[A-Za-z0-9_-]{20,}$/);
+      expect(secondState).not.toBe(firstState);
     });
 
     it('should throw error when called with API Key config', () => {
@@ -104,7 +127,10 @@ describe('LinearAuth', () => {
         { status: 200 }
       ));
 
-      await expect(auth.handleCallback('valid-code')).resolves.not.toThrow();
+      auth.getAuthorizationUrl();
+      const state = auth.getPendingOAuthState();
+
+      await expect(auth.handleCallback('valid-code', state!)).resolves.not.toThrow();
       expect(auth.isAuthenticated()).toBe(true);
     });
 
@@ -114,7 +140,7 @@ describe('LinearAuth', () => {
         apiKey: 'test-access-token'
       });
 
-      await expect(auth.handleCallback('valid-code')).rejects.toThrow();
+      await expect(auth.handleCallback('valid-code', 'state')).rejects.toThrow();
     });
 
     it('should throw error for invalid authorization code', async () => {
@@ -133,7 +159,97 @@ describe('LinearAuth', () => {
         { status: 400 }
       ));
 
-      await expect(auth.handleCallback('invalid-code')).rejects.toThrow();
+      auth.getAuthorizationUrl();
+      const state = auth.getPendingOAuthState();
+
+      await expect(auth.handleCallback('invalid-code', state!)).rejects.toThrow();
+    });
+
+    it('should reject state replay after a failed token exchange', async () => {
+      auth.initialize({
+        type: 'oauth',
+        clientId: 'test-client-id',
+        clientSecret: 'test-client-secret',
+        redirectUri: 'http://localhost:3000/callback'
+      });
+
+      mockFetch.mockResolvedValueOnce(new Response(
+        JSON.stringify({
+          error: 'invalid_grant'
+        }),
+        { status: 400 }
+      ));
+
+      auth.getAuthorizationUrl();
+      const state = auth.getPendingOAuthState();
+
+      await expect(auth.handleCallback('invalid-code', state!)).rejects.toThrow(
+        'OAuth token exchange failed'
+      );
+      await expect(auth.handleCallback('invalid-code', state!)).rejects.toThrow(
+        'No pending OAuth authorization request was found'
+      );
+    });
+
+    it('should reject callback state mismatches', async () => {
+      auth.initialize({
+        type: 'oauth',
+        clientId: 'test-client-id',
+        clientSecret: 'test-client-secret',
+        redirectUri: 'http://localhost:3000/callback'
+      });
+
+      auth.getAuthorizationUrl();
+
+      await expect(auth.handleCallback('valid-code', 'wrong-state')).rejects.toThrow(
+        'OAuth callback state did not match the issued authorization request'
+      );
+    });
+
+    it('should surface timeout-driven token exchange failures', async () => {
+      const timeoutAuth = new LinearAuth({ oauthRequestTimeoutMs: 1 });
+      timeoutAuth.initialize({
+        type: 'oauth',
+        clientId: 'test-client-id',
+        clientSecret: 'test-client-secret',
+        redirectUri: 'http://localhost:3000/callback'
+      });
+
+      mockFetch.mockImplementation(() => new Promise<Response>(() => undefined));
+
+      timeoutAuth.getAuthorizationUrl();
+      const state = timeoutAuth.getPendingOAuthState();
+
+      await expect(timeoutAuth.handleCallback('valid-code', state!)).rejects.toThrow(
+        'OAuth token exchange failed: OAuth token exchange timed out after 1ms'
+      );
+    });
+
+    it('should require a fresh state after a successful callback', async () => {
+      auth.initialize({
+        type: 'oauth',
+        clientId: 'test-client-id',
+        clientSecret: 'test-client-secret',
+        redirectUri: 'http://localhost:3000/callback'
+      });
+
+      mockFetch.mockResolvedValueOnce(new Response(
+        JSON.stringify({
+          access_token: 'test-access-token',
+          refresh_token: 'test-refresh-token',
+          expires_in: 3600
+        }),
+        { status: 200 }
+      ));
+
+      auth.getAuthorizationUrl();
+      const state = auth.getPendingOAuthState();
+
+      await auth.handleCallback('valid-code', state!);
+
+      await expect(auth.handleCallback('valid-code', state!)).rejects.toThrow(
+        'No pending OAuth authorization request was found'
+      );
     });
   });
 
@@ -239,6 +355,27 @@ describe('LinearAuth', () => {
       await expect(auth.refreshAPIKey()).rejects.toThrow();
     });
 
+    it('should throw timeout-driven errors when token refresh hangs', async () => {
+      const timeoutAuth = new LinearAuth({ oauthRequestTimeoutMs: 1 });
+      timeoutAuth.initialize({
+        type: 'oauth',
+        clientId: 'test-client-id',
+        clientSecret: 'test-client-secret',
+        redirectUri: 'http://localhost:3000/callback'
+      });
+      timeoutAuth.setTokenData({
+        apiKey: 'test-access-token',
+        refreshToken: 'test-refresh-token',
+        expiresAt: Date.now() - 1000
+      });
+
+      mockFetch.mockImplementation(() => new Promise<Response>(() => undefined));
+
+      await expect(timeoutAuth.refreshAPIKey()).rejects.toThrow(
+        'Token refresh failed: OAuth token refresh timed out after 1ms'
+      );
+    });
+
     it('should throw error when called with API Key config', async () => {
       auth.initialize({
         type: 'api',
diff --git a/src/__tests__/capabilities.test.ts b/src/__tests__/capabilities.test.ts
new file mode 100644
index 0000000..42e6f1b
--- /dev/null
+++ b/src/__tests__/capabilities.test.ts
@@ -0,0 +1,62 @@
+import { describe, expect, it } from '@jest/globals';
+import { LinearAuth } from '../auth';
+import { getRuntimeCapabilities } from '../core/capabilities';
+import { getServerBuildInfo } from '../core/server-build';
+import { SubscriptionHandler } from '../features/subscriptions/handlers/subscription.handler';
+import { getAdvertisedToolSchemas } from '../core/types/tool.types';
+
+describe('runtime capabilities', () => {
+  it('hides subscription tools for stdio transport', () => {
+    const capabilities = getRuntimeCapabilities({ transport: 'stdio' });
+    const toolNames = getAdvertisedToolSchemas(capabilities).map(tool => tool.name);
+
+    expect(capabilities.authScope).toBe('server');
+    expect(capabilities.endpoint).toBeNull();
+    expect(toolNames).toContain('linear_get_capabilities');
+    expect(toolNames).not.toContain('linear_start_subscription');
+    expect(toolNames).not.toContain('linear_stop_subscription');
+  });
+
+  it('advertises subscription tools for streaming transport', () => {
+    const capabilities = getRuntimeCapabilities({
+      transport: 'stream',
+      streamingSupported: true,
+    });
+    const toolNames = getAdvertisedToolSchemas(capabilities).map(tool => tool.name);
+
+    expect(capabilities.authScope).toBe('session');
+    expect(capabilities.endpoint).toBe('http://127.0.0.1:3000/mcp');
+    expect(toolNames).toContain('linear_start_subscription');
+    expect(toolNames).toContain('linear_stop_subscription');
+  });
+
+  it('returns a structured capability limitation for unsupported subscriptions', async () => {
+    const handler = new SubscriptionHandler(
+      new LinearAuth(),
+      getRuntimeCapabilities({ transport: 'stdio' })
+    );
+
+    const result = await handler.handleStartSubscription({ topic: 'issues' });
+
+    expect(result.isError).toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      authScope: 'server',
+      error: {
+        type: 'capability',
+        capability: 'subscriptions',
+        runtimeSupported: false,
+        transport: 'stdio',
+      },
+    });
+  });
+
+  it('reports packaged server build provenance through runtime capabilities', () => {
+    const buildInfo = getServerBuildInfo({ buildCommitSha: 'abc123' });
+    const capabilities = getRuntimeCapabilities({
+      transport: 'stdio',
+      server: buildInfo,
+    });
+
+    expect(capabilities.server).toEqual(buildInfo);
+  });
+});
diff --git a/src/__tests__/comment-handler.test.ts b/src/__tests__/comment-handler.test.ts
new file mode 100644
index 0000000..832432e
--- /dev/null
+++ b/src/__tests__/comment-handler.test.ts
@@ -0,0 +1,418 @@
+import { beforeEach, describe, expect, it, jest } from '@jest/globals';
+import { LinearAuth } from '../auth.js';
+import { CommentHandler } from '../features/comments/handlers/comment.handler.js';
+import {
+  CreateCommentInput,
+  CreateCommentResponse,
+  DeleteCommentInput,
+  DeleteCommentResponse,
+  GetCommentInput,
+  GetCommentResponse,
+  GetIssueCommentsInput,
+  GetIssueCommentsResponse,
+  ListCommentsInput,
+  ListCommentsResponse,
+  ResolveCommentInput,
+  ResolveCommentResponse,
+  UnresolveCommentInput,
+  UnresolveCommentResponse,
+  UpdateCommentInput,
+  UpdateCommentResponse,
+} from '../features/comments/types/comment.types.js';
+
+type MockCommentClient = {
+  getComment: jest.MockedFunction<(args: GetCommentInput) => Promise<GetCommentResponse>>;
+  listComments: jest.MockedFunction<(args?: ListCommentsInput) => Promise<ListCommentsResponse>>;
+  getIssueComments: jest.MockedFunction<(args: GetIssueCommentsInput) => Promise<GetIssueCommentsResponse>>;
+  findIssueByIdentifier: jest.MockedFunction<(identifier: string, extraFilter?: Record<string, unknown>) => Promise<unknown | undefined>>;
+  createComment: jest.MockedFunction<(args: CreateCommentInput) => Promise<CreateCommentResponse>>;
+  updateComment: jest.MockedFunction<(args: UpdateCommentInput) => Promise<UpdateCommentResponse>>;
+  deleteComment: jest.MockedFunction<(args: DeleteCommentInput) => Promise<DeleteCommentResponse>>;
+  resolveComment: jest.MockedFunction<(args: ResolveCommentInput) => Promise<ResolveCommentResponse>>;
+  unresolveComment: jest.MockedFunction<(args: UnresolveCommentInput) => Promise<UnresolveCommentResponse>>;
+};
+
+describe('CommentHandler', () => {
+  let handler: CommentHandler;
+  let mockClient: MockCommentClient;
+
+  beforeEach(() => {
+    mockClient = {
+      getComment: jest.fn<(args: GetCommentInput) => Promise<GetCommentResponse>>(),
+      listComments: jest.fn<(args?: ListCommentsInput) => Promise<ListCommentsResponse>>(),
+      getIssueComments: jest.fn<(args: GetIssueCommentsInput) => Promise<GetIssueCommentsResponse>>(),
+      findIssueByIdentifier: jest.fn<(identifier: string, extraFilter?: Record<string, unknown>) => Promise<unknown | undefined>>(),
+      createComment: jest.fn<(args: CreateCommentInput) => Promise<CreateCommentResponse>>(),
+      updateComment: jest.fn<(args: UpdateCommentInput) => Promise<UpdateCommentResponse>>(),
+      deleteComment: jest.fn<(args: DeleteCommentInput) => Promise<DeleteCommentResponse>>(),
+      resolveComment: jest.fn<(args: ResolveCommentInput) => Promise<ResolveCommentResponse>>(),
+      unresolveComment: jest.fn<(args: UnresolveCommentInput) => Promise<UnresolveCommentResponse>>(),
+    };
+
+    const auth = {
+      isAuthenticated: jest.fn(() => true),
+      ensureAuthenticatedClient: jest.fn(async () => undefined),
+      getGraphQLClient: jest.fn(() => mockClient),
+    } as unknown as LinearAuth;
+
+    handler = new CommentHandler(auth);
+  });
+
+  it('returns a structured direct comment payload', async () => {
+    mockClient.getComment.mockResolvedValueOnce({
+      comment: {
+        id: 'comment-1',
+        body: 'Hello from Linear',
+        createdAt: '2024-01-01T00:00:00.000Z',
+        updatedAt: '2024-01-01T00:00:00.000Z',
+        issueId: 'issue-1',
+        user: {
+          id: 'user-1',
+          name: 'Test User',
+          email: 'test@example.com',
+        },
+        issue: {
+          id: 'issue-1',
+          identifier: 'TEST-1',
+          title: 'Test Issue',
+          url: 'https://linear.app/test/issue/TEST-1',
+        },
+      },
+    });
+
+    const result = await handler.handleGetComment({ id: 'comment-1' });
+
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      comment: {
+        id: 'comment-1',
+        body: 'Hello from Linear',
+        issueId: 'issue-1',
+        issue: {
+          id: 'issue-1',
+          identifier: 'TEST-1',
+        },
+        user: {
+          id: 'user-1',
+          email: 'test@example.com',
+        },
+      },
+    });
+  });
+
+  it('returns paginated top-level comments with shared projection metadata', async () => {
+    mockClient.listComments.mockResolvedValueOnce({
+      comments: {
+        nodes: [
+          {
+            id: 'comment-1',
+            body: 'Workspace comment',
+            createdAt: '2024-01-01T00:00:00.000Z',
+            updatedAt: '2024-01-01T00:00:00.000Z',
+            issueId: 'issue-1',
+            user: {
+              id: 'user-1',
+              name: 'Commenter',
+            },
+          },
+        ],
+        pageInfo: {
+          hasNextPage: false,
+          endCursor: null,
+          hasPreviousPage: true,
+          startCursor: 'cursor-1',
+        },
+      },
+    });
+
+    const result = await handler.handleListComments({
+      last: 5,
+      before: 'cursor-1',
+      includeArchived: true,
+    });
+
+    expect(mockClient.listComments).toHaveBeenCalledWith({
+      last: 5,
+      before: 'cursor-1',
+      includeArchived: true,
+    });
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      comments: [
+        {
+          id: 'comment-1',
+          body: 'Workspace comment',
+          issueId: 'issue-1',
+        },
+      ],
+      pageInfo: {
+        hasNextPage: false,
+        endCursor: null,
+        hasPreviousPage: true,
+        startCursor: 'cursor-1',
+      },
+    });
+  });
+
+  it('returns paginated issue comments with shared projection metadata', async () => {
+    mockClient.findIssueByIdentifier.mockResolvedValueOnce({
+      id: 'issue-1',
+      identifier: 'TEST-1',
+    });
+    mockClient.getIssueComments.mockResolvedValueOnce({
+      issue: {
+        id: 'issue-1',
+        identifier: 'TEST-1',
+        title: 'Test Issue',
+        url: 'https://linear.app/test/issue/TEST-1',
+        comments: {
+          nodes: [
+            {
+              id: 'comment-1',
+              body: 'Top-level comment',
+              createdAt: '2024-01-01T00:00:00.000Z',
+              updatedAt: '2024-01-01T00:00:00.000Z',
+              user: {
+                id: 'user-1',
+                name: 'Commenter',
+              },
+            },
+          ],
+          pageInfo: {
+            hasNextPage: true,
+            endCursor: 'cursor-2',
+            hasPreviousPage: false,
+            startCursor: 'cursor-1',
+          },
+        },
+      },
+    });
+
+    const result = await handler.handleGetIssueComments({
+      issueId: 'TEST-1',
+      first: 10,
+      filter: {
+        parent: {
+          null: true,
+        },
+      },
+      orderBy: 'updatedAt',
+    });
+
+    expect(mockClient.findIssueByIdentifier).toHaveBeenCalledWith('TEST-1');
+    expect(mockClient.getIssueComments).toHaveBeenCalledWith({
+      issueId: 'issue-1',
+      first: 10,
+      filter: {
+        parent: {
+          null: true,
+        },
+      },
+      orderBy: 'updatedAt',
+    });
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      issue: {
+        id: 'issue-1',
+        identifier: 'TEST-1',
+        title: 'Test Issue',
+      },
+      comments: [
+        {
+          id: 'comment-1',
+          body: 'Top-level comment',
+          user: {
+            id: 'user-1',
+            name: 'Commenter',
+          },
+        },
+      ],
+      pageInfo: {
+        hasNextPage: true,
+        endCursor: 'cursor-2',
+        hasPreviousPage: false,
+        startCursor: 'cursor-1',
+      },
+    });
+  });
+
+  it('creates a threaded reply with parentId-only input', async () => {
+    mockClient.createComment.mockResolvedValueOnce({
+      commentCreate: {
+        success: true,
+        lastSyncId: 101,
+        comment: {
+          id: 'comment-2',
+          body: 'Reply body',
+          createdAt: '2024-01-01T01:00:00.000Z',
+          updatedAt: '2024-01-01T01:00:00.000Z',
+          parentId: 'comment-1',
+          user: {
+            id: 'user-1',
+            name: 'Commenter',
+          },
+          parent: {
+            id: 'comment-1',
+            body: 'Parent comment',
+            createdAt: '2024-01-01T00:00:00.000Z',
+            updatedAt: '2024-01-01T00:00:00.000Z',
+            user: {
+              id: 'user-2',
+              name: 'Parent User',
+            },
+          },
+        },
+      },
+    });
+
+    const result = await handler.handleCreateComment({
+      body: 'Reply body',
+      parentId: 'comment-1',
+    });
+
+    expect(mockClient.createComment).toHaveBeenCalledWith({
+      body: 'Reply body',
+      parentId: 'comment-1',
+    });
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      lastSyncId: 101,
+      comment: {
+        id: 'comment-2',
+        body: 'Reply body',
+        parentId: 'comment-1',
+        parent: {
+          id: 'comment-1',
+        },
+      },
+    });
+  });
+
+  it('returns a structured update payload with advanced body data passthrough', async () => {
+    mockClient.updateComment.mockResolvedValueOnce({
+      commentUpdate: {
+        success: true,
+        lastSyncId: 104,
+        comment: {
+          id: 'comment-1',
+          body: 'Updated body',
+          bodyData: {
+            type: 'doc',
+          },
+          createdAt: '2024-01-01T00:00:00.000Z',
+          updatedAt: '2024-01-01T03:00:00.000Z',
+        },
+      },
+    });
+
+    const result = await handler.handleUpdateComment({
+      id: 'comment-1',
+      body: 'Updated body',
+    });
+
+    expect(mockClient.updateComment).toHaveBeenCalledWith({
+      id: 'comment-1',
+      body: 'Updated body',
+    });
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      lastSyncId: 104,
+      comment: {
+        id: 'comment-1',
+        body: 'Updated body',
+        bodyData: {
+          type: 'doc',
+        },
+      },
+    });
+  });
+
+  it('returns stable deletion metadata for delete comment', async () => {
+    mockClient.deleteComment.mockResolvedValueOnce({
+      commentDelete: {
+        success: true,
+        entityId: 'comment-1',
+        lastSyncId: 102,
+      },
+    });
+
+    const result = await handler.handleDeleteComment({ id: 'comment-1' });
+
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      id: 'comment-1',
+      lastSyncId: 102,
+    });
+  });
+
+  it('returns structured resolution payloads', async () => {
+    mockClient.resolveComment.mockResolvedValueOnce({
+      commentResolve: {
+        success: true,
+        lastSyncId: 103,
+        comment: {
+          id: 'comment-1',
+          body: 'Resolved comment',
+          createdAt: '2024-01-01T00:00:00.000Z',
+          updatedAt: '2024-01-01T02:00:00.000Z',
+          resolvedAt: '2024-01-01T02:00:00.000Z',
+          resolvingCommentId: 'comment-2',
+          resolvingUser: {
+            id: 'user-3',
+            name: 'Resolver',
+          },
+        },
+      },
+    });
+
+    const result = await handler.handleResolveComment({
+      id: 'comment-1',
+      resolvingCommentId: 'comment-2',
+    });
+
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      lastSyncId: 103,
+      comment: {
+        id: 'comment-1',
+        resolvedAt: '2024-01-01T02:00:00.000Z',
+        resolvingCommentId: 'comment-2',
+        resolvingUser: {
+          id: 'user-3',
+          name: 'Resolver',
+        },
+      },
+    });
+  });
+
+  it('returns structured unresolve payloads', async () => {
+    mockClient.unresolveComment.mockResolvedValueOnce({
+      commentUnresolve: {
+        success: true,
+        lastSyncId: 105,
+        comment: {
+          id: 'comment-1',
+          body: 'Unresolved comment',
+          createdAt: '2024-01-01T00:00:00.000Z',
+          updatedAt: '2024-01-01T04:00:00.000Z',
+        },
+      },
+    });
+
+    const result = await handler.handleUnresolveComment({ id: 'comment-1' });
+
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      lastSyncId: 105,
+      comment: {
+        id: 'comment-1',
+        body: 'Unresolved comment',
+      },
+    });
+  });
+});
diff --git a/src/__tests__/graphql-client.test.ts b/src/__tests__/graphql-client.test.ts
index 4a60f00..933f492 100644
--- a/src/__tests__/graphql-client.test.ts
+++ b/src/__tests__/graphql-client.test.ts
@@ -1,11 +1,12 @@
 import { jest, describe, it, expect, beforeEach } from '@jest/globals';
-import { LinearGraphQLClient } from '../graphql/client';
+import { LinearGraphQLClient, LinearGraphQLRequestError } from '../graphql/client';
 import { LinearClient } from '@linear/sdk';
 import { 
   CreateIssueInput, 
   CreateIssueResponse,
-  CreateIssuesResponse,
+  DeleteIssuesResponse,
   UpdateIssueInput,
+  UpdateIssueResponse,
   UpdateIssuesResponse,
   SearchIssuesInput,
   SearchIssuesResponse,
@@ -14,6 +15,7 @@ import {
 } from '../features/issues/types/issue.types';
 import {
   ProjectInput,
+  ProjectWithIssuesOutcome,
   ProjectResponse,
   SearchProjectsResponse,
   GetProjectResponse
@@ -43,18 +45,44 @@ type GraphQLResponse<T> = {
   data: T;
 };
 
+const createRetryableRawFailure = (message: string = 'Temporary outage') => ({
+  data: undefined,
+  errors: [
+    {
+      message,
+      extensions: {
+        code: 'SERVICE_UNAVAILABLE'
+      }
+    }
+  ],
+  status: 503
+});
+
+const createRetryableSdkFailure = (message?: string) => ({
+  response: createRetryableRawFailure(message)
+});
+
 describe('LinearGraphQLClient', () => {
   let graphqlClient: LinearGraphQLClient;
   let linearClient: LinearClient;
   let mockRawRequest: jest.MockedFunction<(query: string, variables?: Record<string, unknown>) => Promise<GraphQLResponse<unknown>>>;
+  let mockDeleteProject: jest.MockedFunction<(id: string) => Promise<unknown>>;
+  let mockIssue: jest.MockedFunction<(id: string) => Promise<unknown>>;
+  let mockIssues: jest.MockedFunction<(args?: Record<string, unknown>) => Promise<unknown>>;
 
   beforeEach(() => {
     mockRawRequest = jest.fn();
+    mockDeleteProject = jest.fn<(id: string) => Promise<unknown>>();
+    mockIssue = jest.fn<(id: string) => Promise<unknown>>();
+    mockIssues = jest.fn<(args?: Record<string, unknown>) => Promise<unknown>>();
     // Mock the Linear client's GraphQL client
     linearClient = {
       client: {
         rawRequest: mockRawRequest
-      }
+      },
+      deleteProject: mockDeleteProject,
+      issue: mockIssue,
+      issues: mockIssues,
     } as unknown as LinearClient;
 
     // Clear mocks
@@ -64,29 +92,73 @@ describe('LinearGraphQLClient', () => {
   });
 
   describe('searchIssues', () => {
-    it('should successfully search issues with project filter', async () => {
-      const mockResponse = {
+    it('should successfully search issues with only a free-text query', async () => {
+      mockRawRequest.mockResolvedValueOnce({
         data: {
-          issues: {
+          searchIssues: {
+            nodes: [
+              {
+                id: 'issue-9',
+                identifier: 'TEST-9',
+                title: 'Query only hit',
+                url: 'https://linear.app/test/issue/TEST-9'
+              }
+            ],
             pageInfo: {
               hasNextPage: false,
               endCursor: null
             },
+            totalCount: 1,
+          }
+        }
+      });
+
+      const result: SearchIssuesResponse = await graphqlClient.searchIssues('query only hit');
+
+      expect(result).toEqual({
+        issues: {
+          nodes: [
+            {
+              id: 'issue-9',
+              identifier: 'TEST-9',
+              title: 'Query only hit',
+              url: 'https://linear.app/test/issue/TEST-9'
+            }
+          ],
+          pageInfo: {
+            hasNextPage: false,
+            endCursor: null
+          }
+        },
+        totalCount: 1,
+      });
+      const [query, variables] = mockRawRequest.mock.calls[0];
+      expect(query).toContain('searchIssues');
+      expect(variables).toEqual({ term: 'query only hit', first: 50 });
+    });
+
+    it('should successfully search issues with a query and filters', async () => {
+      mockRawRequest.mockResolvedValueOnce({
+        data: {
+          searchIssues: {
             nodes: [
               {
                 id: 'issue-1',
                 identifier: 'TEST-1',
-                title: 'Test Issue 1',
+                title: 'Bug in search feature',
                 url: 'https://linear.app/test/issue/TEST-1'
               }
-            ]
+            ],
+            pageInfo: {
+              hasNextPage: false,
+              endCursor: null
+            },
+            totalCount: 1,
           }
         }
-      };
-
-      mockRawRequest.mockResolvedValueOnce(mockResponse);
+      });
 
-      const searchInput = {
+      const result: SearchIssuesResponse = await graphqlClient.searchIssues('search feature', {
         filter: {
           project: {
             id: {
@@ -94,130 +166,414 @@ describe('LinearGraphQLClient', () => {
             }
           }
         },
-        first: 1
-      };
-
-      const result: SearchIssuesResponse = await graphqlClient.searchIssues(
-        searchInput.filter,
-        searchInput.first
-      );
+        first: 1,
+        after: 'cursor-1',
+      });
 
-      expect(result).toEqual(mockResponse.data);
-      expect(mockRawRequest).toHaveBeenCalled();
-      expect(mockRawRequest).toHaveBeenCalledWith(
-        expect.any(String),
-        expect.objectContaining({
-          filter: searchInput.filter
-        })
-      );
+      expect(result).toEqual({
+        issues: {
+          nodes: [
+            {
+              id: 'issue-1',
+              identifier: 'TEST-1',
+              title: 'Bug in search feature',
+              url: 'https://linear.app/test/issue/TEST-1'
+            }
+          ],
+          pageInfo: {
+            hasNextPage: false,
+            endCursor: null
+          }
+        },
+        totalCount: 1,
+      });
+      const [query, variables] = mockRawRequest.mock.calls[0];
+      expect(query).toContain('searchIssues');
+      expect(variables).toEqual({
+        term: 'search feature',
+        filter: {
+          project: {
+            id: {
+              eq: 'project-1'
+            }
+          }
+        },
+        first: 1,
+        after: 'cursor-1',
+      });
     });
 
-    it('should successfully search issues with text query', async () => {
-      const mockResponse = {
+    it('keeps the free-text query separate from issue filters', async () => {
+      mockRawRequest.mockResolvedValueOnce({
         data: {
-          issues: {
+          searchIssues: {
+            nodes: [],
             pageInfo: {
               hasNextPage: false,
               endCursor: null
             },
+            totalCount: 0,
+          }
+        }
+      });
+
+      await graphqlClient.searchIssues('TEST-123', {
+        filter: {
+          state: {
+            name: {
+              in: ['Done']
+            }
+          }
+        },
+      });
+
+      const [, variables] = mockRawRequest.mock.calls[0];
+      expect(variables).toEqual(expect.objectContaining({
+        term: 'TEST-123',
+        first: 50,
+        filter: {
+          team: {
+            key: {
+              eq: 'TEST'
+            }
+          },
+          number: {
+            eq: 123
+          },
+          state: {
+            name: {
+              in: ['Done']
+            }
+          }
+        },
+      }));
+      // The query term must NOT leak into the filter object
+      expect((variables as Record<string, unknown>).filter).not.toHaveProperty('search');
+    });
+
+    it('keeps exact identifier lookups on the search path so pagination metadata stays intact', async () => {
+      mockRawRequest.mockResolvedValueOnce({
+        data: {
+          searchIssues: {
             nodes: [
               {
-                id: 'issue-1',
-                identifier: 'TEST-1',
-                title: 'Bug in search feature',
-                url: 'https://linear.app/test/issue/TEST-1'
+                id: 'issue-431',
+                identifier: 'POL-431',
+                title: 'Exact identifier hit',
+                url: 'https://linear.app/test/issue/POL-431'
               }
-            ]
+            ],
+            pageInfo: {
+              hasNextPage: false,
+              endCursor: null
+            },
+            totalCount: 1,
           }
         }
-      };
-
-      mockRawRequest.mockResolvedValueOnce(mockResponse);
+      });
 
-      // This simulates what our handler would create for a text search
-      const filter: Record<string, unknown> = {
-        or: [
-          { title: { containsIgnoreCase: 'search' } },
-          { number: { eq: null } }
-        ]
-      };
+      const result: SearchIssuesResponse = await graphqlClient.searchIssues('pol-431');
 
-      const result: SearchIssuesResponse = await graphqlClient.searchIssues(
-        filter,
-        10
-      );
-
-      expect(result).toEqual(mockResponse.data);
-      expect(mockRawRequest).toHaveBeenCalled();
-      expect(mockRawRequest).toHaveBeenCalledWith(
-        expect.any(String),
-        expect.objectContaining({
-          filter: filter
-        })
-      );
+      expect(result).toEqual({
+        issues: {
+          nodes: [
+            {
+              id: 'issue-431',
+              identifier: 'POL-431',
+              title: 'Exact identifier hit',
+              url: 'https://linear.app/test/issue/POL-431'
+            }
+          ],
+          pageInfo: {
+            hasNextPage: false,
+            endCursor: null
+          }
+        },
+        totalCount: 1,
+      });
+      const [query, variables] = mockRawRequest.mock.calls[0];
+      expect(query).toContain('searchIssues');
+      expect(variables).toEqual({
+        term: 'pol-431',
+        filter: {
+          team: {
+            key: {
+              eq: 'POL'
+            }
+          },
+          number: {
+            eq: 431
+          }
+        },
+        first: 50,
+      });
+      expect(mockIssues).not.toHaveBeenCalled();
     });
 
-    it('should successfully search issues with issue identifier', async () => {
-      const mockResponse = {
+    it('falls back to deterministic identifier lookup when exact search returns no hits', async () => {
+      mockRawRequest.mockResolvedValueOnce({
         data: {
-          issues: {
+          searchIssues: {
+            nodes: [],
             pageInfo: {
               hasNextPage: false,
               endCursor: null
             },
-            nodes: [
-              {
-                id: 'issue-1',
-                identifier: 'TEST-123',
-                title: 'Test Issue 123',
-                url: 'https://linear.app/test/issue/TEST-123'
-              }
-            ]
+            totalCount: 0,
           }
         }
-      };
-
-      mockRawRequest.mockResolvedValueOnce(mockResponse);
-
-      // This simulates what our handler would create for an identifier search
-      const filter: Record<string, unknown> = {
-        or: [
-          { title: { containsIgnoreCase: 'TEST-123' } },
-          { number: { eq: 123 } }
-        ]
-      };
+      });
+      mockIssues.mockResolvedValueOnce({
+        nodes: [
+          {
+            id: 'issue-431',
+            identifier: 'POL-431',
+            title: 'Exact identifier hit',
+            url: 'https://linear.app/test/issue/POL-431'
+          }
+        ],
+        pageInfo: {
+          hasNextPage: false,
+          endCursor: null
+        }
+      });
 
-      const result: SearchIssuesResponse = await graphqlClient.searchIssues(
-        filter,
-        10
-      );
+      const result: SearchIssuesResponse = await graphqlClient.searchIssues('pol-431');
 
-      expect(result).toEqual(mockResponse.data);
-      expect(mockRawRequest).toHaveBeenCalled();
-      expect(mockRawRequest).toHaveBeenCalledWith(
-        expect.any(String),
-        expect.objectContaining({
-          filter: filter
-        })
-      );
+      expect(result).toEqual({
+        issues: {
+          nodes: [
+            {
+              id: 'issue-431',
+              identifier: 'POL-431',
+              title: 'Exact identifier hit',
+              url: 'https://linear.app/test/issue/POL-431'
+            }
+          ],
+          pageInfo: {
+            hasNextPage: false,
+            endCursor: null
+          }
+        },
+        totalCount: 1,
+      });
+      expect(mockIssues).toHaveBeenCalledWith({
+        filter: {
+          team: {
+            key: {
+              eq: 'POL'
+            }
+          },
+          number: {
+            eq: 431
+          }
+        },
+        first: 1,
+      });
     });
 
     it('should handle search errors', async () => {
       mockRawRequest.mockRejectedValueOnce(new Error('Search failed'));
 
-      const searchInput = {
+      await expect(
+        graphqlClient.searchIssues('search feature')
+      ).rejects.toThrow('GraphQL operation SearchIssues failed');
+    });
+  });
+
+  describe('findIssueByIdentifier', () => {
+    it('returns undefined for non-identifier queries without calling issue listing', async () => {
+      await expect(graphqlClient.findIssueByIdentifier('search feature')).resolves.toBeUndefined();
+      expect(mockIssues).not.toHaveBeenCalled();
+    });
+
+    it('merges exact identifier lookup with existing issue filters', async () => {
+      mockIssues.mockResolvedValueOnce({
+        nodes: [
+          {
+            id: 'issue-431',
+            identifier: 'POL-431',
+            title: 'Filtered identifier hit'
+          }
+        ],
+        pageInfo: {
+          hasNextPage: false,
+          endCursor: null
+        }
+      });
+
+      const result = await graphqlClient.findIssueByIdentifier('POL-431', {
+        project: {
+          id: {
+            eq: 'project-1'
+          }
+        }
+      });
+
+      expect(result).toMatchObject({
+        id: 'issue-431',
+        identifier: 'POL-431',
+      });
+      expect(mockIssues).toHaveBeenCalledWith({
         filter: {
           project: {
             id: {
               eq: 'project-1'
             }
+          },
+          team: {
+            key: {
+              eq: 'POL'
+            }
+          },
+          number: {
+            eq: 431
+          }
+        },
+        first: 1,
+      });
+    });
+  });
+
+  describe('request resilience', () => {
+    it('retries approved raw GraphQL reads before succeeding', async () => {
+      graphqlClient = new LinearGraphQLClient(linearClient, {
+        safeReadRetryDelayMs: 0
+      });
+
+      const successResponse = {
+        data: {
+          teams: {
+            nodes: [
+              {
+                id: 'team-1',
+                name: 'Platform'
+              }
+            ]
           }
         }
       };
 
-      await expect(
-        graphqlClient.searchIssues(searchInput.filter)
-      ).rejects.toThrow('GraphQL operation failed: Search failed');
+      mockRawRequest
+        .mockResolvedValueOnce(createRetryableRawFailure() as unknown as GraphQLResponse<unknown>)
+        .mockResolvedValueOnce(createRetryableRawFailure() as unknown as GraphQLResponse<unknown>)
+        .mockResolvedValueOnce(successResponse as GraphQLResponse<unknown>);
+
+      await expect(graphqlClient.getTeams()).resolves.toEqual(successResponse.data);
+      expect(mockRawRequest).toHaveBeenCalledTimes(3);
+    });
+
+    it('retries approved SDK reads before succeeding', async () => {
+      graphqlClient = new LinearGraphQLClient(linearClient, {
+        safeReadRetryDelayMs: 0
+      });
+
+      mockIssues
+        .mockRejectedValueOnce(createRetryableSdkFailure())
+        .mockResolvedValueOnce({
+          nodes: [
+            {
+              id: 'issue-431',
+              identifier: 'POL-431'
+            }
+          ]
+        });
+
+      await expect(graphqlClient.findIssueByIdentifier('POL-431')).resolves.toMatchObject({
+        id: 'issue-431',
+        identifier: 'POL-431'
+      });
+      expect(mockIssues).toHaveBeenCalledTimes(2);
+    });
+
+    it('surfaces retry exhaustion after bounded safe-read retries', async () => {
+      graphqlClient = new LinearGraphQLClient(linearClient, {
+        safeReadMaxAttempts: 2,
+        safeReadRetryDelayMs: 0
+      });
+
+      mockRawRequest.mockResolvedValue(
+        createRetryableRawFailure() as unknown as GraphQLResponse<unknown>
+      );
+
+      let caughtError: unknown;
+      try {
+        await graphqlClient.getTeams();
+      } catch (error) {
+        caughtError = error;
+      }
+
+      expect(caughtError).toBeInstanceOf(LinearGraphQLRequestError);
+      expect(caughtError).toMatchObject({
+        message: 'GraphQL operation GetTeams failed: Temporary outage',
+        result: {
+          meta: {
+            status: 503,
+            retryable: true,
+          },
+        },
+      });
+      expect(mockRawRequest).toHaveBeenCalledTimes(2);
+    });
+
+    it('classifies timed out requests as structured timeout failures', async () => {
+      graphqlClient = new LinearGraphQLClient(linearClient, {
+        requestTimeoutMs: 1,
+        safeReadMaxAttempts: 1,
+        safeReadRetryDelayMs: 0
+      });
+
+      mockRawRequest.mockImplementation(
+        () => new Promise<GraphQLResponse<unknown>>(() => undefined)
+      );
+
+      let caughtError: unknown;
+      try {
+        await graphqlClient.getTeams();
+      } catch (error) {
+        caughtError = error;
+      }
+
+      expect(caughtError).toBeInstanceOf(LinearGraphQLRequestError);
+      expect(caughtError).toMatchObject({
+        message: 'GraphQL operation GetTeams failed: GetTeams timed out after 1ms',
+        result: {
+          errors: [
+            {
+              message: 'GetTeams timed out after 1ms',
+              extensions: {
+                code: 'TIMEOUT'
+              }
+            }
+          ],
+          meta: {
+            status: 408,
+            retryable: true,
+          },
+        },
+      });
+      expect(mockRawRequest).toHaveBeenCalledTimes(1);
+    });
+
+    it('does not auto-retry non-idempotent writes', async () => {
+      graphqlClient = new LinearGraphQLClient(linearClient, {
+        safeReadRetryDelayMs: 0
+      });
+
+      mockRawRequest.mockResolvedValueOnce(
+        createRetryableRawFailure() as unknown as GraphQLResponse<unknown>
+      );
+
+      const input: CreateIssueInput = {
+        title: 'New Issue',
+        description: 'Description',
+        teamId: 'team-1'
+      };
+
+      await expect(graphqlClient.createIssue(input)).rejects.toThrow(
+        'GraphQL operation CreateIssue failed: Temporary outage'
+      );
+      expect(mockRawRequest).toHaveBeenCalledTimes(1);
     });
   });
 
@@ -246,15 +602,11 @@ describe('LinearGraphQLClient', () => {
       };
       
       const result: CreateIssueResponse = await graphqlClient.createIssue(input);
+      const [query, variables] = mockRawRequest.mock.calls[0];
 
-      // Verify single mutation call with direct input (not array)
-      expect(mockRawRequest).toHaveBeenCalledWith(
-        expect.any(String),
-        expect.objectContaining({
-          input: input
-        })
-      );
-
+      expect(query).toContain('issueCreate(input: $input)');
+      expect(query).not.toContain('issueBatchCreate(');
+      expect(variables).toEqual(expect.objectContaining({ input }));
       expect(result).toEqual(mockResponse.data);
       expect(mockRawRequest).toHaveBeenCalled();
     });
@@ -270,7 +622,7 @@ describe('LinearGraphQLClient', () => {
 
       await expect(
         graphqlClient.createIssue(input)
-      ).rejects.toThrow('GraphQL operation failed: Creation failed');
+      ).rejects.toThrow('GraphQL operation CreateIssue failed: Creation failed');
     });
   });
 
@@ -448,28 +800,61 @@ describe('LinearGraphQLClient', () => {
         const result = await graphqlClient.createProjectWithIssues(
           projectInput,
           [issueInput]
-        );
+        ) as ProjectWithIssuesOutcome;
+        const [projectQuery, projectVariables] = mockRawRequest.mock.calls[0];
+        const [issueQuery, issueVariables] = mockRawRequest.mock.calls[1];
 
         expect(result).toEqual({
+          success: true,
+          project: projectMockResponse.data.projectCreate.project,
+          issues: issueMockResponse.data.issueBatchCreate.issues,
+          lastSyncId: 124,
           projectCreate: projectMockResponse.data.projectCreate,
           issueBatchCreate: issueMockResponse.data.issueBatchCreate
         });
+        expect(mockRawRequest).toHaveBeenCalledTimes(2);
+        expect(projectQuery).toContain('projectCreate(input: $input)');
+        expect(projectVariables).toEqual(expect.objectContaining({ input: projectInput }));
+        expect(issueQuery).toContain('issueBatchCreate(input: $input)');
+        expect(issueVariables).toEqual(expect.objectContaining({
+          input: {
+            issues: [{ ...issueInput, projectId: 'project-1' }]
+          }
+        }));
+      });
 
-        // Verify project creation call
-        expect(mockRawRequest).toHaveBeenCalledWith(
-          expect.any(String),
-          expect.objectContaining({ input: projectInput })
-        );
-
-        // Verify issue creation call
-        expect(mockRawRequest).toHaveBeenCalledWith(
-          expect.any(String),
-          expect.objectContaining({
-            input: {
-              issues: [{ ...issueInput, projectId: 'project-1' }]
+      it('should skip batch issue creation when no project issues are supplied', async () => {
+        const projectMockResponse = {
+          data: {
+            projectCreate: {
+              success: true,
+              project: {
+                id: 'project-1',
+                name: 'New Project',
+                url: 'https://linear.app/test/project/1',
+              },
+              lastSyncId: 123,
             }
-          })
-        );
+          }
+        };
+
+        mockRawRequest.mockResolvedValueOnce(projectMockResponse);
+
+        const projectInput: ProjectInput = {
+          name: 'New Project',
+          teamIds: ['team-1']
+        };
+
+        const result = await graphqlClient.createProjectWithIssues(projectInput, []);
+
+        expect(result).toEqual({
+          success: true,
+          project: projectMockResponse.data.projectCreate.project,
+          issues: [],
+          lastSyncId: 123,
+          projectCreate: projectMockResponse.data.projectCreate,
+        });
+        expect(mockRawRequest).toHaveBeenCalledTimes(1);
       });
 
       it('should handle project creation errors', async () => {
@@ -496,9 +881,17 @@ describe('LinearGraphQLClient', () => {
           teamId: 'team-1'
         };
 
-        await expect(
-          graphqlClient.createProjectWithIssues(projectInput, [issueInput])
-        ).rejects.toThrow('Failed to create project');
+        const result = await graphqlClient.createProjectWithIssues(projectInput, [issueInput]);
+
+        expect(result).toEqual({
+          success: false,
+          failedStep: 'projectCreate',
+          message: 'Project creation did not complete before issue creation began.',
+          issueCreationAttempted: false,
+          compensationAttempted: false,
+          lastSyncId: 123,
+          projectCreate: errorResponse.data.projectCreate,
+        });
       });
 
       it('should handle issue creation errors', async () => {
@@ -529,6 +922,9 @@ describe('LinearGraphQLClient', () => {
         mockRawRequest
           .mockResolvedValueOnce(projectResponse)
           .mockResolvedValueOnce(errorResponse);
+        mockDeleteProject.mockResolvedValueOnce({
+          success: true,
+        });
 
         const projectInput: ProjectInput = {
           name: 'New Project',
@@ -541,18 +937,31 @@ describe('LinearGraphQLClient', () => {
           teamId: 'team-1'
         };
 
-        await expect(
-          graphqlClient.createProjectWithIssues(projectInput, [issueInput])
-        ).rejects.toThrow('Failed to create issues');
+        const result = await graphqlClient.createProjectWithIssues(projectInput, [issueInput]);
+
+        expect(result).toEqual({
+          success: false,
+          failedStep: 'issueBatchCreate',
+          message: 'Issue creation failed after project creation. The created project was deleted during compensation. Issue creation did not complete successfully.',
+          issueCreationAttempted: true,
+          compensationAttempted: true,
+          compensationSucceeded: true,
+          project: projectResponse.data.projectCreate.project,
+          issues: [],
+          lastSyncId: 124,
+          projectCreate: projectResponse.data.projectCreate,
+          issueBatchCreate: errorResponse.data.issueBatchCreate,
+        });
+        expect(mockDeleteProject).toHaveBeenCalledWith('project-1');
       });
     });
   });
 
   describe('Bulk Operations', () => {
-    it('should create multiple issues with a single mutation', async () => {
+    it('should create multiple issues through the batch mutation', async () => {
       const mockResponse = {
         data: {
-          issueCreate: {
+          issueBatchCreate: {
             success: true,
             issues: [
               {
@@ -588,16 +997,15 @@ describe('LinearGraphQLClient', () => {
       ];
 
       const result: IssueBatchResponse = await graphqlClient.createIssues(issues);
+      const [query, variables] = mockRawRequest.mock.calls[0];
 
       expect(result).toEqual(mockResponse.data);
-      // Verify single mutation call
       expect(mockRawRequest).toHaveBeenCalledTimes(1);
-      expect(mockRawRequest).toHaveBeenCalledWith(
-        expect.any(String),
-        expect.objectContaining({
-          input: { issues }
-        })
-      );
+      expect(query).toContain('issueBatchCreate(input: $input)');
+      expect(query).not.toContain('issueCreate(input: $input)');
+      expect(variables).toEqual(expect.objectContaining({
+        input: { issues }
+      }));
     });
 
     it('should update multiple issues with a single mutation', async () => {
@@ -647,7 +1055,7 @@ describe('LinearGraphQLClient', () => {
       const updateInput: UpdateIssueInput = { stateId: 'state-2' };
       await expect(
         graphqlClient.updateIssues(['issue-1'], updateInput)
-      ).rejects.toThrow('GraphQL operation failed: Update failed');
+      ).rejects.toThrow('GraphQL operation UpdateIssues failed: Update failed');
     });
 
     it('should delete multiple issues with a single mutation', async () => {
@@ -662,7 +1070,7 @@ describe('LinearGraphQLClient', () => {
       mockRawRequest.mockResolvedValueOnce(mockResponse);
 
       const ids = ['issue-1', 'issue-2'];
-      const result: DeleteIssueResponse = await graphqlClient.deleteIssues(ids);
+      const result: DeleteIssuesResponse = await graphqlClient.deleteIssues(ids);
 
       expect(result).toEqual(mockResponse.data);
       // Verify single mutation call
@@ -711,7 +1119,7 @@ describe('LinearGraphQLClient', () => {
       mockRawRequest.mockRejectedValueOnce(new Error('Team fetch failed'));
 
       await expect(graphqlClient.getTeams()).rejects.toThrow(
-        'GraphQL operation failed: Team fetch failed'
+        'GraphQL operation GetTeams failed: Team fetch failed'
       );
     });
   });
@@ -740,7 +1148,7 @@ describe('LinearGraphQLClient', () => {
       mockRawRequest.mockRejectedValueOnce(new Error('User fetch failed'));
 
       await expect(graphqlClient.getCurrentUser()).rejects.toThrow(
-        'GraphQL operation failed: User fetch failed'
+        'GraphQL operation GetUser failed: User fetch failed'
       );
     });
   });
@@ -783,7 +1191,7 @@ describe('LinearGraphQLClient', () => {
 
       await expect(
         graphqlClient.createIssueLabels([labelInput])
-      ).rejects.toThrow('GraphQL operation failed: Label creation failed');
+      ).rejects.toThrow('GraphQL operation CreateIssueLabels failed: Label creation failed');
     });
   });
 
@@ -810,7 +1218,7 @@ describe('LinearGraphQLClient', () => {
 
       const id = 'issue-1';
       const updateInput: UpdateIssueInput = { stateId: 'state-2' };
-      const result: UpdateIssuesResponse = await graphqlClient.updateIssue(id, updateInput);
+      const result: UpdateIssueResponse = await graphqlClient.updateIssue(id, updateInput);
 
       expect(result).toEqual(mockResponse.data);
       // Verify single mutation call with direct id (not array)
@@ -852,6 +1260,293 @@ describe('LinearGraphQLClient', () => {
     })
   })
 
+  describe('comment operations', () => {
+    const comment = {
+      id: 'comment-1',
+      body: 'Hello from Linear',
+      bodyData: '{"type":"doc"}',
+      quotedText: 'Quoted text',
+      url: 'https://linear.app/test/comment/comment-1',
+      createdAt: '2024-01-01T00:00:00.000Z',
+      updatedAt: '2024-01-01T00:00:00.000Z',
+      issueId: 'issue-1',
+      parentId: 'comment-parent',
+      user: {
+        id: 'user-1',
+        name: 'Test User',
+        email: 'test@example.com',
+      },
+      issue: {
+        id: 'issue-1',
+        identifier: 'TEST-1',
+        title: 'Test Issue',
+        url: 'https://linear.app/test/issue/TEST-1',
+      },
+      parent: {
+        id: 'comment-parent',
+        body: 'Parent comment',
+        createdAt: '2023-12-31T00:00:00.000Z',
+        updatedAt: '2023-12-31T00:00:00.000Z',
+        user: {
+          id: 'user-2',
+          name: 'Parent User',
+          email: 'parent@example.com',
+        },
+      },
+    };
+
+    it('should get a single comment', async () => {
+      const mockResponse = {
+        data: {
+          comment,
+        },
+      };
+
+      mockRawRequest.mockResolvedValueOnce(mockResponse);
+
+      const result = await graphqlClient.getComment({ id: 'comment-1' });
+
+      expect(result).toEqual(mockResponse.data);
+      expect(mockRawRequest).toHaveBeenCalledWith(
+        expect.any(String),
+        expect.objectContaining({
+          id: 'comment-1',
+        })
+      );
+    });
+
+    it('should list comments with native pagination controls', async () => {
+      const mockResponse = {
+        data: {
+          comments: {
+            pageInfo: {
+              hasNextPage: true,
+              endCursor: 'cursor-2',
+              hasPreviousPage: true,
+              startCursor: 'cursor-1',
+            },
+            nodes: [comment],
+          },
+        },
+      };
+
+      const filter = {
+        issue: {
+          id: {
+            eq: 'issue-1',
+          },
+        },
+      };
+
+      mockRawRequest.mockResolvedValueOnce(mockResponse);
+
+      const result = await graphqlClient.listComments({
+        last: 5,
+        before: 'cursor-1',
+        filter,
+        includeArchived: true,
+        orderBy: 'updatedAt',
+      });
+
+      expect(result).toEqual(mockResponse.data);
+      expect(mockRawRequest).toHaveBeenCalledWith(
+        expect.any(String),
+        expect.objectContaining({
+          first: undefined,
+          last: 5,
+          before: 'cursor-1',
+          filter,
+          includeArchived: true,
+          orderBy: 'updatedAt',
+        })
+      );
+    });
+
+    it('should get issue comments with expanded collection controls', async () => {
+      const mockResponse = {
+        data: {
+          issue: {
+            id: 'issue-1',
+            identifier: 'TEST-1',
+            title: 'Test Issue',
+            url: 'https://linear.app/test/issue/TEST-1',
+            comments: {
+              pageInfo: {
+                hasNextPage: true,
+                endCursor: 'cursor-2',
+                hasPreviousPage: false,
+                startCursor: 'cursor-1',
+              },
+              nodes: [comment],
+            },
+          },
+        },
+      };
+
+      const filter = {
+        parent: {
+          null: true,
+        },
+      };
+
+      mockRawRequest.mockResolvedValueOnce(mockResponse);
+
+      const result = await graphqlClient.getIssueComments({
+        issueId: 'issue-1',
+        first: 25,
+        after: 'cursor-1',
+        filter,
+        includeArchived: true,
+        orderBy: 'updatedAt',
+      });
+
+      expect(result).toEqual(mockResponse.data);
+      expect(mockRawRequest).toHaveBeenCalledWith(
+        expect.any(String),
+        expect.objectContaining({
+          issueId: 'issue-1',
+          first: 25,
+          after: 'cursor-1',
+          filter,
+          includeArchived: true,
+          orderBy: 'updatedAt',
+        })
+      );
+    });
+
+    it('should create a threaded reply using parentId', async () => {
+      const mockResponse = {
+        data: {
+          commentCreate: {
+            success: true,
+            comment,
+            lastSyncId: 101,
+          },
+        },
+      };
+
+      const input = {
+        body: 'Reply body',
+        parentId: 'comment-parent',
+      };
+
+      mockRawRequest.mockResolvedValueOnce(mockResponse);
+
+      const result = await graphqlClient.createComment(input);
+
+      expect(result).toEqual(mockResponse.data);
+      expect(mockRawRequest).toHaveBeenCalledWith(
+        expect.any(String),
+        expect.objectContaining({
+          input,
+        })
+      );
+    });
+
+    it('should update a comment', async () => {
+      const mockResponse = {
+        data: {
+          commentUpdate: {
+            success: true,
+            comment,
+            lastSyncId: 102,
+          },
+        },
+      };
+
+      mockRawRequest.mockResolvedValueOnce(mockResponse);
+
+      const result = await graphqlClient.updateComment({
+        id: 'comment-1',
+        body: 'Updated comment body',
+      });
+
+      expect(result).toEqual(mockResponse.data);
+      expect(mockRawRequest).toHaveBeenCalledWith(
+        expect.any(String),
+        expect.objectContaining({
+          id: 'comment-1',
+          input: {
+            body: 'Updated comment body',
+          },
+        })
+      );
+    });
+
+    it('should delete a comment', async () => {
+      const mockResponse = {
+        data: {
+          commentDelete: {
+            success: true,
+            entityId: 'comment-1',
+            lastSyncId: 103,
+          },
+        },
+      };
+
+      mockRawRequest.mockResolvedValueOnce(mockResponse);
+
+      const result = await graphqlClient.deleteComment({ id: 'comment-1' });
+
+      expect(result).toEqual(mockResponse.data);
+      expect(mockRawRequest).toHaveBeenCalledWith(
+        expect.any(String),
+        expect.objectContaining({
+          id: 'comment-1',
+        })
+      );
+    });
+
+    it('should resolve and unresolve a comment thread', async () => {
+      const resolveResponse = {
+        data: {
+          commentResolve: {
+            success: true,
+            comment,
+            lastSyncId: 104,
+          },
+        },
+      };
+      const unresolveResponse = {
+        data: {
+          commentUnresolve: {
+            success: true,
+            comment,
+            lastSyncId: 105,
+          },
+        },
+      };
+
+      mockRawRequest
+        .mockResolvedValueOnce(resolveResponse)
+        .mockResolvedValueOnce(unresolveResponse);
+
+      const resolveResult = await graphqlClient.resolveComment({
+        id: 'comment-1',
+        resolvingCommentId: 'comment-parent',
+      });
+      const unresolveResult = await graphqlClient.unresolveComment({ id: 'comment-1' });
+
+      expect(resolveResult).toEqual(resolveResponse.data);
+      expect(unresolveResult).toEqual(unresolveResponse.data);
+      expect(mockRawRequest).toHaveBeenNthCalledWith(
+        1,
+        expect.any(String),
+        expect.objectContaining({
+          id: 'comment-1',
+          resolvingCommentId: 'comment-parent',
+        })
+      );
+      expect(mockRawRequest).toHaveBeenNthCalledWith(
+        2,
+        expect.any(String),
+        expect.objectContaining({
+          id: 'comment-1',
+        })
+      );
+    });
+  });
+
   describe('Project Milestone Operations', () => {
     describe('createProjectMilestone', () => {
       it('should successfully create a project milestone', async () => {
@@ -906,7 +1601,7 @@ describe('LinearGraphQLClient', () => {
 
         await expect(
           graphqlClient.createProjectMilestone(input)
-        ).rejects.toThrow('GraphQL operation failed: Milestone creation failed');
+        ).rejects.toThrow('GraphQL operation CreateProjectMilestone failed: Milestone creation failed');
       });
     });
 
@@ -962,7 +1657,7 @@ describe('LinearGraphQLClient', () => {
 
         await expect(
           graphqlClient.updateProjectMilestone('milestone-1', input)
-        ).rejects.toThrow('GraphQL operation failed: Milestone update failed');
+        ).rejects.toThrow('GraphQL operation UpdateProjectMilestone failed: Milestone update failed');
       });
     });
 
@@ -995,7 +1690,7 @@ describe('LinearGraphQLClient', () => {
 
         await expect(
           graphqlClient.deleteProjectMilestone('milestone-1')
-        ).rejects.toThrow('GraphQL operation failed: Milestone deletion failed');
+        ).rejects.toThrow('GraphQL operation DeleteProjectMilestone failed: Milestone deletion failed');
       });
     });
 
@@ -1044,7 +1739,7 @@ describe('LinearGraphQLClient', () => {
 
         await expect(
           graphqlClient.getProjectMilestone('milestone-1')
-        ).rejects.toThrow('GraphQL operation failed: Milestone fetch failed');
+        ).rejects.toThrow('GraphQL operation GetProjectMilestone failed: Milestone fetch failed');
       });
     });
 
@@ -1102,7 +1797,7 @@ describe('LinearGraphQLClient', () => {
 
         await expect(
           graphqlClient.searchProjectMilestones({})
-        ).rejects.toThrow('GraphQL operation failed: Milestone search failed');
+        ).rejects.toThrow('GraphQL operation SearchProjectMilestones failed: Milestone search failed');
       });
     });
 
@@ -1269,7 +1964,7 @@ describe('LinearGraphQLClient', () => {
 
         await expect(
           graphqlClient.createProjectMilestone(milestones[1])
-        ).rejects.toThrow('GraphQL operation failed: Second milestone failed');
+        ).rejects.toThrow('GraphQL operation CreateProjectMilestone failed: Second milestone failed');
 
         expect(mockRawRequest).toHaveBeenCalledTimes(2);
       });
diff --git a/src/__tests__/handler-factory.test.ts b/src/__tests__/handler-factory.test.ts
new file mode 100644
index 0000000..5c7b525
--- /dev/null
+++ b/src/__tests__/handler-factory.test.ts
@@ -0,0 +1,53 @@
+import { describe, expect, it } from '@jest/globals';
+import { LinearAuth } from '../auth.js';
+import { getRuntimeCapabilities } from '../core/capabilities.js';
+import { HandlerFactory } from '../core/handlers/handler.factory.js';
+
+describe('HandlerFactory', () => {
+  const runtimeCapabilities = getRuntimeCapabilities({
+    transport: 'stream',
+    host: '127.0.0.1',
+    port: 43111,
+    path: '/mcp',
+  });
+
+  it('reuses feature handlers within the same auth context', () => {
+    const factory = new HandlerFactory(runtimeCapabilities);
+    const auth = new LinearAuth();
+
+    const getIssue = factory.getHandlerForTool('linear_get_issue', auth);
+    const createIssue = factory.getHandlerForTool('linear_create_issue', auth);
+    const capabilities = factory.getHandlerForTool('linear_get_capabilities', auth);
+    const stopSubscription = factory.getHandlerForTool('linear_stop_subscription', auth);
+
+    expect(getIssue.handler).toBe(createIssue.handler);
+    expect(getIssue.method).toBe('handleGetIssue');
+    expect(createIssue.method).toBe('handleCreateIssue');
+
+    expect(capabilities.handler).toBe(stopSubscription.handler);
+    expect(capabilities.method).toBe('handleGetCapabilities');
+    expect(stopSubscription.method).toBe('handleStopSubscription');
+  });
+
+  it('keeps handler reuse isolated to the active auth context', () => {
+    const factory = new HandlerFactory(runtimeCapabilities);
+    const firstAuth = new LinearAuth();
+    const secondAuth = new LinearAuth();
+
+    const firstIssueHandler = factory.getHandlerForTool('linear_get_issue', firstAuth);
+    const secondIssueHandler = factory.getHandlerForTool('linear_get_issue', secondAuth);
+    const firstAuthHandler = factory.getHandlerForTool('linear_auth', firstAuth);
+    const secondAuthHandler = factory.getHandlerForTool('linear_auth', secondAuth);
+
+    expect(firstIssueHandler.handler).not.toBe(secondIssueHandler.handler);
+    expect(firstAuthHandler.handler).not.toBe(secondAuthHandler.handler);
+  });
+
+  it('throws for unknown tools', () => {
+    const factory = new HandlerFactory(runtimeCapabilities);
+
+    expect(() => factory.getHandlerForTool('linear_unknown_tool', new LinearAuth())).toThrow(
+      'No handler found for tool: linear_unknown_tool'
+    );
+  });
+});
diff --git a/src/__tests__/helpers/runtime-smoke.ts b/src/__tests__/helpers/runtime-smoke.ts
new file mode 100644
index 0000000..ac7d754
--- /dev/null
+++ b/src/__tests__/helpers/runtime-smoke.ts
@@ -0,0 +1,181 @@
+import { createServer as createNetServer } from 'node:net';
+import { LinearClient } from '@linear/sdk';
+import { jest } from '@jest/globals';
+import { Client } from '@modelcontextprotocol/sdk/client/index.js';
+import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp.js';
+import { LinearAuth } from '../../auth.js';
+import { SearchIssuesResponse } from '../../features/issues/types/issue.types.js';
+import { LinearGraphQLClient } from '../../graphql/client.js';
+import { LinearServer, LinearServerOptions } from '../../index.js';
+
+export interface RuntimeEnvSnapshot {
+  transport?: string;
+  host?: string;
+  port?: string;
+  path?: string;
+  apiKey?: string;
+  accessToken?: string;
+}
+
+function restoreEnvVariable(name: string, value?: string): void {
+  if (value === undefined) {
+    delete process.env[name];
+    return;
+  }
+
+  process.env[name] = value;
+}
+
+export function captureRuntimeEnv(): RuntimeEnvSnapshot {
+  return {
+    transport: process.env.LINEAR_MCP_TRANSPORT,
+    host: process.env.LINEAR_MCP_HOST,
+    port: process.env.LINEAR_MCP_PORT,
+    path: process.env.LINEAR_MCP_PATH,
+    apiKey: process.env.LINEAR_API_KEY,
+    accessToken: process.env.LINEAR_ACCESS_TOKEN,
+  };
+}
+
+export function restoreRuntimeEnv(snapshot: RuntimeEnvSnapshot): void {
+  restoreEnvVariable('LINEAR_MCP_TRANSPORT', snapshot.transport);
+  restoreEnvVariable('LINEAR_MCP_HOST', snapshot.host);
+  restoreEnvVariable('LINEAR_MCP_PORT', snapshot.port);
+  restoreEnvVariable('LINEAR_MCP_PATH', snapshot.path);
+  restoreEnvVariable('LINEAR_API_KEY', snapshot.apiKey);
+  restoreEnvVariable('LINEAR_ACCESS_TOKEN', snapshot.accessToken);
+}
+
+export async function getAvailablePort(): Promise<number> {
+  return new Promise((resolve, reject) => {
+    const server = createNetServer();
+    server.once('error', reject);
+    server.listen(0, '127.0.0.1', () => {
+      const address = server.address();
+      if (!address || typeof address === 'string') {
+        server.close();
+        reject(new Error('Failed to acquire a test port'));
+        return;
+      }
+
+      server.close(error => error ? reject(error) : resolve(address.port));
+    });
+  });
+}
+
+export class TestLinearAuth extends LinearAuth {
+  constructor(
+    private readonly graphQLClient: LinearGraphQLClient,
+    private readonly smokeClient: LinearClient = {} as LinearClient
+  ) {
+    super();
+  }
+
+  override isAuthenticated(): boolean {
+    return true;
+  }
+
+  override async ensureAuthenticatedClient(): Promise<LinearClient> {
+    return this.smokeClient;
+  }
+
+  override getGraphQLClient(): LinearGraphQLClient {
+    return this.graphQLClient;
+  }
+
+  override createScopedCopy(): LinearAuth {
+    return new TestLinearAuth(this.graphQLClient, this.smokeClient);
+  }
+}
+
+export interface RuntimeSmokeHarness {
+  server: LinearServer;
+  client: Client;
+  port: number;
+  endpoint: string;
+  close(): Promise<void>;
+}
+
+export async function createRuntimeSmokeHarness(options: {
+  clientName: string;
+  clientVersion?: string;
+  serverOptions?: LinearServerOptions;
+  apiKeyEnv?: {
+    LINEAR_API_KEY?: string;
+    LINEAR_ACCESS_TOKEN?: string;
+  };
+}): Promise<RuntimeSmokeHarness> {
+  const port = await getAvailablePort();
+  process.env.LINEAR_MCP_TRANSPORT = 'stream';
+  process.env.LINEAR_MCP_HOST = '127.0.0.1';
+  process.env.LINEAR_MCP_PORT = String(port);
+  process.env.LINEAR_MCP_PATH = '/mcp';
+  restoreEnvVariable('LINEAR_API_KEY', options.apiKeyEnv?.LINEAR_API_KEY);
+  restoreEnvVariable('LINEAR_ACCESS_TOKEN', options.apiKeyEnv?.LINEAR_ACCESS_TOKEN);
+
+  const server = new LinearServer(options.serverOptions);
+  const client = new Client(
+    {
+      name: options.clientName,
+      version: options.clientVersion ?? '1.0.0',
+    },
+    {
+      capabilities: {},
+    }
+  );
+  const endpoint = `http://127.0.0.1:${port}/mcp`;
+
+  try {
+    await server.run();
+    const transport = new StreamableHTTPClientTransport(new URL(endpoint));
+    await client.connect(transport);
+  } catch (error) {
+    await client.close().catch(() => undefined);
+    await server.close().catch(() => undefined);
+    throw error;
+  }
+
+  return {
+    server,
+    client,
+    port,
+    endpoint,
+    close: async () => {
+      await client.close();
+      await server.close();
+    },
+  };
+}
+
+export function createIssueWorkflowSmokeBackend(): {
+  auth: LinearAuth;
+  executeSdk: ReturnType<typeof jest.fn>;
+  createIssue: ReturnType<typeof jest.fn>;
+  createIssueBatch: ReturnType<typeof jest.fn>;
+  searchIssues: ReturnType<typeof jest.fn>;
+} {
+  const createIssue = jest.fn<(input: Record<string, unknown>) => Promise<Record<string, unknown>>>();
+  const createIssueBatch = jest.fn<(input: { issues: Record<string, unknown>[] }) => Promise<Record<string, unknown>>>();
+  const searchIssues = jest.fn<(query: string, options?: Record<string, unknown>) => Promise<SearchIssuesResponse>>();
+  const executeSdk = jest.fn(
+    async (_operationName: string, request: () => Promise<unknown>) => await request()
+  );
+
+  const graphQLClient = {
+    createIssue,
+    sdk: {
+      createIssue,
+      createIssueBatch,
+    },
+    executeSdk: executeSdk as LinearGraphQLClient['executeSdk'],
+    searchIssues,
+  } as unknown as LinearGraphQLClient;
+
+  return {
+    auth: new TestLinearAuth(graphQLClient),
+    executeSdk,
+    createIssue,
+    createIssueBatch,
+    searchIssues,
+  };
+}
diff --git a/src/__tests__/issue-handler.test.ts b/src/__tests__/issue-handler.test.ts
new file mode 100644
index 0000000..2721149
--- /dev/null
+++ b/src/__tests__/issue-handler.test.ts
@@ -0,0 +1,556 @@
+import { beforeEach, describe, expect, it, jest } from '@jest/globals';
+import { LinearAuth } from '../auth.js';
+import {
+  IssueHandler,
+  ISSUE_BULK_CONCURRENCY_LIMIT,
+} from '../features/issues/handlers/issue.handler.js';
+import {
+  CreateIssueInput,
+  CreateIssuesInput,
+  SearchIssuesInput,
+  SearchIssuesResponse,
+  UpdateIssueInput,
+} from '../features/issues/types/issue.types.js';
+
+type MockIssueSdk = {
+  issue: jest.MockedFunction<(id: string) => Promise<unknown>>;
+  createIssue: jest.MockedFunction<(args: CreateIssueInput) => Promise<unknown>>;
+  createIssueBatch: jest.MockedFunction<(args: CreateIssuesInput) => Promise<unknown>>;
+  updateIssue: jest.MockedFunction<(id: string, input: UpdateIssueInput) => Promise<unknown>>;
+  deleteIssue: jest.MockedFunction<(id: string) => Promise<unknown>>;
+};
+
+type MockIssueClient = {
+  sdk: MockIssueSdk;
+  executeSdk: jest.MockedFunction<(operation: string, request: () => Promise<unknown>) => Promise<unknown>>;
+  createIssue: jest.MockedFunction<(args: CreateIssueInput) => Promise<unknown>>;
+  searchIssues: jest.MockedFunction<(query: string, options?: Omit<SearchIssuesInput, 'query'>) => Promise<SearchIssuesResponse>>;
+  findIssueByIdentifier: jest.MockedFunction<(identifier: string, extraFilter?: Record<string, unknown>) => Promise<unknown | undefined>>;
+};
+
+describe('IssueHandler', () => {
+  let handler: IssueHandler;
+  let mockClient: MockIssueClient;
+
+  beforeEach(() => {
+    const sdk: MockIssueSdk = {
+      issue: jest.fn<(id: string) => Promise<unknown>>(),
+      createIssue: jest.fn<(args: CreateIssueInput) => Promise<unknown>>(),
+      createIssueBatch: jest.fn<(args: CreateIssuesInput) => Promise<unknown>>(),
+      updateIssue: jest.fn<(id: string, input: UpdateIssueInput) => Promise<unknown>>(),
+      deleteIssue: jest.fn<(id: string) => Promise<unknown>>(),
+    };
+
+    mockClient = {
+      sdk,
+      executeSdk: jest.fn<(operation: string, request: () => Promise<unknown>) => Promise<unknown>>()
+        .mockImplementation(async (_operation, request) => request()),
+      createIssue: jest.fn<(args: CreateIssueInput) => Promise<unknown>>(),
+      searchIssues: jest.fn<(query: string, options?: Omit<SearchIssuesInput, 'query'>) => Promise<SearchIssuesResponse>>(),
+      findIssueByIdentifier: jest.fn<(identifier: string, extraFilter?: Record<string, unknown>) => Promise<unknown | undefined>>(),
+    };
+
+    const auth = {
+      isAuthenticated: jest.fn(() => true),
+      ensureAuthenticatedClient: jest.fn(async () => undefined),
+      getGraphQLClient: jest.fn(() => mockClient),
+    } as unknown as LinearAuth;
+
+    handler = new IssueHandler(auth);
+  });
+
+  it('returns parent and child hierarchy data from issue detail reads', async () => {
+    mockClient.sdk.issue.mockResolvedValueOnce({
+      id: 'issue-2',
+      identifier: 'TEAM-2',
+      title: 'Child issue',
+      url: 'https://linear.app/test/issue/TEAM-2',
+      _children: {
+        nodes: [
+          {
+            id: 'issue-3',
+            identifier: 'TEAM-3',
+            title: 'Nested child',
+            url: 'https://linear.app/test/issue/TEAM-3',
+          },
+        ],
+        pageInfo: {
+          hasNextPage: false,
+          endCursor: null,
+        },
+      },
+      parent: Promise.resolve({
+        id: 'issue-1',
+        identifier: 'TEAM-1',
+        title: 'Parent issue',
+        url: 'https://linear.app/test/issue/TEAM-1',
+      }),
+      children: async function(this: { _children: unknown }) {
+        return this._children;
+      },
+    });
+
+    const result = await handler.handleGetIssue({ id: 'issue-2' });
+
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      issue: {
+        id: 'issue-2',
+        parent: {
+          id: 'issue-1',
+          identifier: 'TEAM-1',
+        },
+        children: [
+          {
+            id: 'issue-3',
+            identifier: 'TEAM-3',
+          },
+        ],
+      },
+    });
+  });
+
+  it('resolves issue identifiers before loading detailed issue data', async () => {
+    mockClient.findIssueByIdentifier.mockResolvedValueOnce({
+      id: 'issue-431',
+      identifier: 'POL-431',
+    });
+    mockClient.sdk.issue.mockResolvedValueOnce({
+      id: 'issue-431',
+      identifier: 'POL-431',
+      title: 'Exact identifier hit',
+      url: 'https://linear.app/test/issue/POL-431',
+    });
+
+    const result = await handler.handleGetIssue({ id: 'pol-431' });
+
+    expect(mockClient.findIssueByIdentifier).toHaveBeenCalledWith('pol-431');
+    expect(mockClient.sdk.issue).toHaveBeenCalledWith('issue-431');
+    expect(result.isError).not.toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      issue: {
+        id: 'issue-431',
+        identifier: 'POL-431',
+        title: 'Exact identifier hit',
+      },
+    });
+  });
+
+  it('returns the assigned parent on issue creation responses', async () => {
+    const args: CreateIssueInput = {
+      title: 'Child issue',
+      teamId: 'team-1',
+      parentId: 'issue-1',
+    };
+
+    mockClient.createIssue.mockResolvedValueOnce({
+      success: true,
+      issue: {
+        id: 'issue-2',
+        identifier: 'TEAM-2',
+        title: 'Child issue',
+        url: 'https://linear.app/test/issue/TEAM-2',
+        parent: Promise.resolve({
+          id: 'issue-1',
+          identifier: 'TEAM-1',
+          title: 'Parent issue',
+          url: 'https://linear.app/test/issue/TEAM-1',
+        }),
+      },
+    });
+
+    const result = await handler.handleCreateIssue(args);
+
+    expect(mockClient.createIssue).toHaveBeenCalledWith(args);
+    expect(mockClient.sdk.createIssueBatch).not.toHaveBeenCalled();
+    expect(result.structuredContent).toMatchObject({
+      issue: {
+        id: 'issue-2',
+        parent: {
+          id: 'issue-1',
+          identifier: 'TEAM-1',
+        },
+      },
+    });
+  });
+
+  it('uses batch issue creation for multi-issue create requests', async () => {
+    const args: CreateIssuesInput = {
+      issues: [
+        {
+          title: 'Issue 1',
+          teamId: 'team-1',
+        },
+        {
+          title: 'Issue 2',
+          teamId: 'team-1',
+        },
+      ],
+    };
+
+    mockClient.sdk.createIssueBatch.mockResolvedValueOnce({
+      success: true,
+      issues: [
+        {
+          id: 'issue-1',
+          identifier: 'TEAM-1',
+          title: 'Issue 1',
+          url: 'https://linear.app/test/issue/TEAM-1',
+        },
+        {
+          id: 'issue-2',
+          identifier: 'TEAM-2',
+          title: 'Issue 2',
+          url: 'https://linear.app/test/issue/TEAM-2',
+        },
+      ],
+      lastSyncId: 42,
+    });
+
+    const result = await handler.handleCreateIssues(args);
+
+    expect(mockClient.sdk.createIssueBatch).toHaveBeenCalledWith(args);
+    expect(mockClient.sdk.createIssue).not.toHaveBeenCalled();
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      issues: [
+        {
+          id: 'issue-1',
+          identifier: 'TEAM-1',
+        },
+        {
+          id: 'issue-2',
+          identifier: 'TEAM-2',
+        },
+      ],
+      lastSyncId: 42,
+    });
+  });
+
+  it('uses explicit null to clear an existing project assignment', async () => {
+    const update: UpdateIssueInput = {
+      projectId: null,
+    };
+
+    mockClient.sdk.updateIssue.mockResolvedValueOnce({
+      success: true,
+      issue: {
+        id: 'issue-2',
+        identifier: 'TEAM-2',
+        title: 'Moved issue',
+        url: 'https://linear.app/test/issue/TEAM-2',
+      },
+    });
+
+    const result = await handler.handleBulkUpdateIssues({
+      issueIds: ['issue-2'],
+      update,
+    });
+
+    expect(mockClient.sdk.updateIssue).toHaveBeenCalledWith('issue-2', update);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      issues: [
+        {
+          id: 'issue-2',
+        },
+      ],
+    });
+    expect(result.structuredContent?.issues).toEqual(
+      expect.not.arrayContaining([
+        expect.objectContaining({
+          project: expect.anything(),
+        }),
+      ])
+    );
+  });
+
+  it('routes free-text issue search through the query-aware search helper', async () => {
+    mockClient.searchIssues.mockResolvedValueOnce({
+      issues: {
+        nodes: [
+          {
+            id: 'issue-2',
+            identifier: 'TEAM-2',
+            title: 'Search hit',
+            url: 'https://linear.app/test/issue/TEAM-2',
+          },
+        ],
+        pageInfo: {
+          hasNextPage: false,
+          endCursor: null,
+        },
+      },
+      totalCount: 1,
+    });
+
+    const result = await handler.handleSearchIssues({
+      query: 'Search hit',
+      projectId: 'project-1',
+      first: 5,
+    });
+
+    expect(mockClient.searchIssues).toHaveBeenCalledWith('Search hit', {
+      filter: {
+        project: {
+          id: {
+            eq: 'project-1',
+          },
+        },
+      },
+      first: 5,
+    });
+    expect(result.structuredContent).toMatchObject({
+      issues: [
+        {
+          id: 'issue-2',
+        },
+      ],
+      pageInfo: {
+        hasNextPage: false,
+        endCursor: null,
+      },
+      totalCount: 1,
+    });
+  });
+
+  it('rejects conflicting stateId and states filters before search execution', async () => {
+    const result = await handler.handleSearchIssues({
+      query: 'Search hit',
+      stateId: 'state-1',
+      states: ['Todo'],
+    });
+
+    expect(result.isError).toBe(true);
+    expect(mockClient.searchIssues).not.toHaveBeenCalled();
+    expect(result.structuredContent).toMatchObject({
+      error: {
+        type: 'mcp',
+        message: 'MCP error -32602: stateId and states cannot both be provided in the same issue query.',
+      },
+    });
+  });
+
+  it('returns results for a query-only issue search', async () => {
+    mockClient.searchIssues.mockResolvedValueOnce({
+      issues: {
+        nodes: [
+          {
+            id: 'issue-7',
+            identifier: 'TEAM-7',
+            title: 'Only query result',
+            url: 'https://linear.app/test/issue/TEAM-7',
+          },
+        ],
+        pageInfo: {
+          hasNextPage: false,
+          endCursor: null,
+        },
+      },
+      totalCount: 1,
+    });
+
+    const result = await handler.handleSearchIssues({
+      query: 'Only query result',
+    });
+
+    expect(mockClient.searchIssues).toHaveBeenCalledWith('Only query result', {
+      first: 50,
+    });
+    expect(result.structuredContent).toMatchObject({
+      issues: [
+        {
+          id: 'issue-7',
+          identifier: 'TEAM-7',
+        },
+      ],
+      pageInfo: {
+        hasNextPage: false,
+        endCursor: null,
+      },
+      totalCount: 1,
+    });
+  });
+
+  it('returns the updated parent when reparenting an existing issue', async () => {
+    mockClient.sdk.updateIssue.mockResolvedValueOnce({
+      success: true,
+      issue: {
+        id: 'issue-2',
+        identifier: 'TEAM-2',
+        title: 'Child issue',
+        url: 'https://linear.app/test/issue/TEAM-2',
+        parent: Promise.resolve({
+          id: 'issue-9',
+          identifier: 'TEAM-9',
+          title: 'New parent',
+          url: 'https://linear.app/test/issue/TEAM-9',
+        }),
+      },
+    });
+
+    const result = await handler.handleBulkUpdateIssues({
+      issueIds: ['issue-2'],
+      update: {
+        parentId: 'issue-9',
+      },
+    });
+
+    expect(mockClient.sdk.updateIssue).toHaveBeenCalledWith('issue-2', {
+      parentId: 'issue-9',
+    });
+    expect(result.structuredContent).toMatchObject({
+      issues: [
+        {
+          id: 'issue-2',
+          parent: {
+            id: 'issue-9',
+            identifier: 'TEAM-9',
+          },
+        },
+      ],
+    });
+  });
+
+  it('uses projectId to move an existing issue into a project', async () => {
+    mockClient.sdk.updateIssue.mockResolvedValueOnce({
+      success: true,
+      issue: {
+        id: 'issue-2',
+        identifier: 'TEAM-2',
+        title: 'Moved issue',
+        url: 'https://linear.app/test/issue/TEAM-2',
+        project: Promise.resolve({
+          id: 'project-2',
+          name: 'Roadmap',
+          url: 'https://linear.app/test/project/project-2',
+        }),
+      },
+    });
+
+    const result = await handler.handleBulkUpdateIssues({
+      issueIds: ['issue-2'],
+      update: {
+        projectId: 'project-2',
+      },
+    });
+
+    expect(mockClient.sdk.updateIssue).toHaveBeenCalledWith('issue-2', {
+      projectId: 'project-2',
+    });
+    expect(result.structuredContent).toMatchObject({
+      issues: [
+        {
+          id: 'issue-2',
+          project: {
+            id: 'project-2',
+            name: 'Roadmap',
+          },
+        },
+      ],
+    });
+  });
+
+  it('returns deterministic partial results when bulk issue deletion is only partially successful', async () => {
+    mockClient.sdk.deleteIssue
+      .mockResolvedValueOnce({ success: true })
+      .mockRejectedValueOnce(new Error('Delete failed'));
+
+    const result = await handler.handleDeleteIssues({
+      ids: ['issue-1', 'issue-2'],
+    });
+
+    expect(result.isError).toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      success: false,
+      deletedIds: ['issue-1'],
+      failedIds: ['issue-2'],
+      failed: [
+        {
+          id: 'issue-2',
+          message: 'Delete failed',
+        },
+      ],
+      error: {
+        type: 'partial',
+      },
+    });
+  });
+
+  it('bounds concurrent issue updates while preserving result order for larger batches', async () => {
+    const issueIds = Array.from(
+      { length: ISSUE_BULK_CONCURRENCY_LIMIT + 3 },
+      (_, index) => `issue-${index + 1}`
+    );
+    let activeUpdates = 0;
+    let maxActiveUpdates = 0;
+
+    mockClient.sdk.updateIssue.mockImplementation(async (issueId) => {
+      activeUpdates += 1;
+      maxActiveUpdates = Math.max(maxActiveUpdates, activeUpdates);
+      await new Promise(resolve => setTimeout(resolve, 0));
+      activeUpdates -= 1;
+
+      return {
+        success: true,
+        issue: {
+          id: issueId,
+          identifier: issueId.toUpperCase(),
+          title: `Updated ${issueId}`,
+          url: `https://linear.app/test/issue/${issueId}`,
+        },
+      };
+    });
+
+    const result = await handler.handleBulkUpdateIssues({
+      issueIds,
+      update: {
+        priority: 2,
+      },
+    });
+
+    expect(result.isError).not.toBe(true);
+    expect(maxActiveUpdates).toBe(ISSUE_BULK_CONCURRENCY_LIMIT);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      issues: issueIds.map(id => ({
+        id,
+      })),
+    });
+    expect(
+      (result.structuredContent?.issues as Array<Record<string, unknown>>).map(issue => issue.id)
+    ).toEqual(issueIds);
+  });
+
+  it('bounds concurrent issue deletions while preserving deletedIds order for larger batches', async () => {
+    const issueIds = Array.from(
+      { length: ISSUE_BULK_CONCURRENCY_LIMIT + 4 },
+      (_, index) => `issue-${index + 1}`
+    );
+    let activeDeletes = 0;
+    let maxActiveDeletes = 0;
+
+    mockClient.sdk.deleteIssue.mockImplementation(async () => {
+      activeDeletes += 1;
+      maxActiveDeletes = Math.max(maxActiveDeletes, activeDeletes);
+      await new Promise(resolve => setTimeout(resolve, 0));
+      activeDeletes -= 1;
+
+      return {
+        success: true,
+      };
+    });
+
+    const result = await handler.handleDeleteIssues({
+      ids: issueIds,
+    });
+
+    expect(result.isError).not.toBe(true);
+    expect(maxActiveDeletes).toBe(ISSUE_BULK_CONCURRENCY_LIMIT);
+    expect(result.structuredContent).toMatchObject({
+      success: true,
+      ids: issueIds,
+      deletedIds: issueIds,
+    });
+  });
+});
diff --git a/src/__tests__/issue-workflow-smoke.test.ts b/src/__tests__/issue-workflow-smoke.test.ts
new file mode 100644
index 0000000..93ec9dc
--- /dev/null
+++ b/src/__tests__/issue-workflow-smoke.test.ts
@@ -0,0 +1,210 @@
+import { afterEach, beforeEach, describe, expect, it, jest } from '@jest/globals';
+import {
+  captureRuntimeEnv,
+  createIssueWorkflowSmokeBackend,
+  createRuntimeSmokeHarness,
+  restoreRuntimeEnv,
+} from './helpers/runtime-smoke.js';
+
+describe('issue workflow smoke tests', () => {
+  const runtimeEnv = captureRuntimeEnv();
+  let consoleErrorSpy: ReturnType<typeof jest.spyOn>;
+
+  beforeEach(() => {
+    consoleErrorSpy = jest.spyOn(console, 'error').mockImplementation(() => undefined);
+  });
+
+  afterEach(() => {
+    consoleErrorSpy.mockRestore();
+    restoreRuntimeEnv(runtimeEnv);
+  });
+
+  it('executes linear_create_issue through the MCP boundary without live credentials', async () => {
+    const backend = createIssueWorkflowSmokeBackend();
+    backend.createIssue.mockResolvedValue({
+      success: true,
+      issue: {
+        id: 'issue-1',
+        identifier: 'TEAM-1',
+        title: 'Smoke created issue',
+        url: 'https://linear.app/test/issue/TEAM-1',
+        team: {
+          id: 'team-1',
+          name: 'Smoke Team',
+        },
+      },
+    });
+
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'issue-create-smoke',
+      serverOptions: {
+        auth: backend.auth,
+      },
+    });
+
+    try {
+      const result = await harness.client.callTool({
+        name: 'linear_create_issue',
+        arguments: {
+          title: 'Smoke created issue',
+          teamId: 'team-1',
+          priority: 2,
+        },
+      }) as { structuredContent?: Record<string, unknown> };
+
+      expect(backend.createIssue).toHaveBeenCalledWith({
+        title: 'Smoke created issue',
+        teamId: 'team-1',
+        priority: 2,
+      });
+      expect(result.structuredContent).toMatchObject({
+        success: true,
+        issue: {
+          id: 'issue-1',
+          identifier: 'TEAM-1',
+          title: 'Smoke created issue',
+          team: {
+            id: 'team-1',
+            name: 'Smoke Team',
+          },
+        },
+      });
+    } finally {
+      await harness.close();
+    }
+  });
+
+  it('executes linear_create_issues through the MCP boundary without live credentials', async () => {
+    const backend = createIssueWorkflowSmokeBackend();
+    backend.createIssueBatch.mockResolvedValue({
+      success: true,
+      issues: [
+        {
+          id: 'issue-2',
+          identifier: 'TEAM-2',
+          title: 'First batched issue',
+          url: 'https://linear.app/test/issue/TEAM-2',
+        },
+        {
+          id: 'issue-3',
+          identifier: 'TEAM-3',
+          title: 'Second batched issue',
+          url: 'https://linear.app/test/issue/TEAM-3',
+        },
+      ],
+      lastSyncId: 41,
+    });
+
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'issue-batch-smoke',
+      serverOptions: {
+        auth: backend.auth,
+      },
+    });
+
+    try {
+      const issues = [
+        {
+          title: 'First batched issue',
+          teamId: 'team-1',
+        },
+        {
+          title: 'Second batched issue',
+          teamId: 'team-1',
+          projectId: 'project-1',
+        },
+      ];
+      const result = await harness.client.callTool({
+        name: 'linear_create_issues',
+        arguments: {
+          issues,
+        },
+      }) as { structuredContent?: Record<string, unknown> };
+
+      expect(backend.executeSdk).toHaveBeenCalledWith('createIssueBatch', expect.any(Function));
+      expect(backend.createIssueBatch).toHaveBeenCalledWith({ issues });
+      expect(result.structuredContent).toMatchObject({
+        success: true,
+        lastSyncId: 41,
+        issues: [
+          {
+            id: 'issue-2',
+            identifier: 'TEAM-2',
+          },
+          {
+            id: 'issue-3',
+            identifier: 'TEAM-3',
+          },
+        ],
+      });
+    } finally {
+      await harness.close();
+    }
+  });
+
+  it('executes linear_search_issues through the MCP boundary without live credentials', async () => {
+    const backend = createIssueWorkflowSmokeBackend();
+    backend.searchIssues.mockResolvedValue({
+      issues: {
+        nodes: [
+          {
+            id: 'issue-4',
+            identifier: 'TEAM-4',
+            title: 'Search hit',
+            url: 'https://linear.app/test/issue/TEAM-4',
+          },
+        ],
+        pageInfo: {
+          hasNextPage: false,
+          endCursor: null,
+        },
+      },
+      totalCount: 1,
+    });
+
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'issue-search-smoke',
+      serverOptions: {
+        auth: backend.auth,
+      },
+    });
+
+    try {
+      const result = await harness.client.callTool({
+        name: 'linear_search_issues',
+        arguments: {
+          query: 'Search hit',
+          projectId: 'project-1',
+          first: 5,
+        },
+      }) as { structuredContent?: Record<string, unknown> };
+
+      expect(backend.searchIssues).toHaveBeenCalledWith('Search hit', {
+        filter: {
+          project: {
+            id: {
+              eq: 'project-1',
+            },
+          },
+        },
+        first: 5,
+      });
+      expect(result.structuredContent).toMatchObject({
+        totalCount: 1,
+        pageInfo: {
+          hasNextPage: false,
+          endCursor: null,
+        },
+        issues: [
+          {
+            id: 'issue-4',
+            identifier: 'TEAM-4',
+            title: 'Search hit',
+          },
+        ],
+      });
+    } finally {
+      await harness.close();
+    }
+  });
+});
diff --git a/src/__tests__/project-handler.test.ts b/src/__tests__/project-handler.test.ts
new file mode 100644
index 0000000..de81764
--- /dev/null
+++ b/src/__tests__/project-handler.test.ts
@@ -0,0 +1,215 @@
+import { beforeEach, describe, expect, it, jest } from '@jest/globals';
+import { LinearAuth } from '../auth.js';
+import { ProjectHandler } from '../features/projects/handlers/project.handler.js';
+import {
+  ProjectInput,
+  ProjectWithIssuesInput,
+  ProjectWithIssuesOutcome,
+  UpdateProjectInput,
+} from '../features/projects/types/project.types.js';
+
+type MockProjectSdk = {
+  createProject: jest.MockedFunction<(args: ProjectInput) => Promise<unknown>>;
+  updateProject: jest.MockedFunction<(id: string, input: UpdateProjectInput) => Promise<unknown>>;
+};
+
+type MockProjectClient = {
+  sdk: MockProjectSdk;
+  executeSdk: jest.MockedFunction<(operation: string, request: () => Promise<unknown>) => Promise<unknown>>;
+  createProjectWithIssues: jest.MockedFunction<(
+    project: ProjectInput,
+    issues: ProjectWithIssuesInput['issues']
+  ) => Promise<ProjectWithIssuesOutcome>>;
+};
+
+describe('ProjectHandler', () => {
+  let handler: ProjectHandler;
+  let mockClient: MockProjectClient;
+
+  beforeEach(() => {
+    const sdk: MockProjectSdk = {
+      createProject: jest.fn<(args: ProjectInput) => Promise<unknown>>(),
+      updateProject: jest.fn<(id: string, input: UpdateProjectInput) => Promise<unknown>>(),
+    };
+
+    mockClient = {
+      sdk,
+      executeSdk: jest.fn<(operation: string, request: () => Promise<unknown>) => Promise<unknown>>()
+        .mockImplementation(async (_operation, request) => request()),
+      createProjectWithIssues: jest.fn<(
+        project: ProjectInput,
+        issues: ProjectWithIssuesInput['issues']
+      ) => Promise<ProjectWithIssuesOutcome>>(),
+    };
+
+    const auth = {
+      isAuthenticated: jest.fn(() => true),
+      ensureAuthenticatedClient: jest.fn(async () => undefined),
+      getGraphQLClient: jest.fn(() => mockClient),
+    } as unknown as LinearAuth;
+
+    handler = new ProjectHandler(auth);
+  });
+
+  it('returns linked initiative metadata on project creation', async () => {
+    const args: ProjectInput = {
+      name: 'Roadmap',
+      teamIds: ['team-1'],
+      initiativeId: 'initiative-1',
+    };
+
+    mockClient.sdk.createProject.mockResolvedValueOnce({
+      success: true,
+      project: {
+        id: 'project-1',
+        name: 'Roadmap',
+        url: 'https://linear.app/test/project/project-1',
+        initiative: Promise.resolve({
+          id: 'initiative-1',
+          name: 'Platform',
+          url: 'https://linear.app/test/initiative/initiative-1',
+        }),
+      },
+    });
+
+    const result = await handler.handleCreateProject(args);
+
+    expect(mockClient.sdk.createProject).toHaveBeenCalledWith(args);
+    expect(result.structuredContent).toMatchObject({
+      project: {
+        id: 'project-1',
+        initiative: {
+          id: 'initiative-1',
+          name: 'Platform',
+        },
+      },
+    });
+  });
+
+  it('uses explicit null to clear an initiative association', async () => {
+    const args: UpdateProjectInput & { id: string } = {
+      id: 'project-1',
+      initiativeId: null,
+    };
+
+    mockClient.sdk.updateProject.mockResolvedValueOnce({
+      success: true,
+      project: {
+        id: 'project-1',
+        name: 'Roadmap',
+        url: 'https://linear.app/test/project/project-1',
+      },
+    });
+
+    const result = await handler.handleUpdateProject(args);
+
+    expect(mockClient.sdk.updateProject).toHaveBeenCalledWith('project-1', {
+      initiativeId: null,
+    });
+    expect(result.structuredContent).toMatchObject({
+      project: {
+        id: 'project-1',
+      },
+    });
+    expect(result.structuredContent?.project).toEqual(
+      expect.not.objectContaining({
+        initiative: expect.anything(),
+      })
+    );
+  });
+
+  it('fails before issue creation when project creation does not return a usable identifier', async () => {
+    const args: ProjectWithIssuesInput = {
+      project: {
+        name: 'Roadmap',
+        teamIds: ['team-1'],
+      },
+      issues: [
+        {
+          title: 'First issue',
+          teamId: 'team-1',
+        },
+      ],
+    };
+
+    mockClient.createProjectWithIssues.mockResolvedValueOnce({
+      success: false,
+      failedStep: 'projectCreate',
+      message: 'Project creation did not complete before issue creation began.',
+      issueCreationAttempted: false,
+      compensationAttempted: false,
+      projectCreate: {
+        success: false,
+        project: undefined,
+      },
+    });
+
+    const result = await handler.handleCreateProjectWithIssues(args);
+
+    expect(mockClient.createProjectWithIssues).toHaveBeenCalledWith(args.project, args.issues);
+    expect(result.isError).toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      success: false,
+      error: {
+        type: 'workflow',
+        failedStep: 'projectCreate',
+        issueCreationAttempted: false,
+      },
+    });
+  });
+
+  it('surfaces explicit partial state when issue creation fails and compensation does not complete', async () => {
+    const args: ProjectWithIssuesInput = {
+      project: {
+        name: 'Roadmap',
+        teamIds: ['team-1'],
+      },
+      issues: [
+        {
+          title: 'First issue',
+          teamId: 'team-1',
+        },
+      ],
+    };
+
+    mockClient.createProjectWithIssues.mockResolvedValueOnce({
+      success: false,
+      failedStep: 'issueBatchCreate',
+      message: 'Issue creation failed after project creation and compensation did not remove the created project.',
+      issueCreationAttempted: true,
+      compensationAttempted: true,
+      compensationSucceeded: false,
+      project: {
+        id: 'project-1',
+        name: 'Roadmap',
+        url: 'https://linear.app/test/project/project-1',
+      },
+      issues: [],
+      projectCreate: {
+        success: true,
+        project: {
+          id: 'project-1',
+          name: 'Roadmap',
+          url: 'https://linear.app/test/project/project-1',
+        },
+      },
+    });
+
+    const result = await handler.handleCreateProjectWithIssues(args);
+
+    expect(result.isError).toBe(true);
+    expect(result.structuredContent).toMatchObject({
+      partialState: {
+        projectId: 'project-1',
+        projectName: 'Roadmap',
+        failedStep: 'issueBatchCreate',
+      },
+      error: {
+        type: 'workflow',
+        failedStep: 'issueBatchCreate',
+        compensationAttempted: true,
+        compensationSucceeded: false,
+      },
+    });
+  });
+});
diff --git a/src/__tests__/runtime-server.test.ts b/src/__tests__/runtime-server.test.ts
new file mode 100644
index 0000000..5ca21f9
--- /dev/null
+++ b/src/__tests__/runtime-server.test.ts
@@ -0,0 +1,529 @@
+import { afterEach, beforeEach, describe, expect, it, jest } from '@jest/globals';
+import { Client } from '@modelcontextprotocol/sdk/client/index.js';
+import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp.js';
+import { getRuntimeCapabilities } from '../core/capabilities.js';
+import { getServerBuildInfo } from '../core/server-build.js';
+import { LinearGraphQLClient, LinearGraphQLRequestError } from '../graphql/client.js';
+import {
+  captureRuntimeEnv,
+  createIssueWorkflowSmokeBackend,
+  createRuntimeSmokeHarness,
+  restoreRuntimeEnv,
+  TestLinearAuth,
+} from './helpers/runtime-smoke.js';
+
+function getTelemetryEntries(
+  consoleErrorSpy: ReturnType<typeof jest.spyOn>
+): Array<Record<string, unknown>> {
+  return consoleErrorSpy.mock.calls.flatMap((call: unknown[]) => {
+    const entry = call[0];
+    if (typeof entry !== 'string') {
+      return [];
+    }
+
+    try {
+      const parsed = JSON.parse(entry) as Record<string, unknown>;
+      return parsed.event === 'mcp_tool_request' ? [parsed] : [];
+    } catch {
+      return [];
+    }
+  });
+}
+
+describe('runtime transport server', () => {
+  const runtimeEnv = captureRuntimeEnv();
+  let consoleErrorSpy: ReturnType<typeof jest.spyOn>;
+
+  beforeEach(() => {
+    consoleErrorSpy = jest.spyOn(console, 'error').mockImplementation(() => undefined);
+  });
+
+  afterEach(() => {
+    consoleErrorSpy.mockRestore();
+    restoreRuntimeEnv(runtimeEnv);
+  });
+
+  it('reports a remote endpoint for stream transport capabilities', () => {
+    const capabilities = getRuntimeCapabilities({
+      transport: 'stream',
+      host: '127.0.0.1',
+      port: 43111,
+      path: '/mcp',
+    });
+
+    expect(capabilities.transport).toBe('stream');
+    expect(capabilities.authScope).toBe('session');
+    expect(capabilities.endpoint).toBe('http://127.0.0.1:43111/mcp');
+  });
+
+  it('serves MCP over streamable HTTP and does not expose /sse', async () => {
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'runtime-transport-test',
+    });
+
+    try {
+      const tools = await harness.client.listTools();
+      expect(tools.tools.some(tool => tool.name === 'linear_get_capabilities')).toBe(true);
+
+      const capabilitiesResult = await harness.client.callTool({
+        name: 'linear_get_capabilities',
+        arguments: {},
+      }) as { structuredContent?: Record<string, unknown> };
+      const buildInfo = getServerBuildInfo();
+
+      expect(consoleErrorSpy).toHaveBeenCalledWith(`Build: ${buildInfo.name}@${buildInfo.version}`);
+      expect(capabilitiesResult.structuredContent).toMatchObject({
+        server: {
+          name: buildInfo.name,
+          version: buildInfo.version,
+        },
+        transport: 'stream',
+        authScope: 'session',
+        endpoint: harness.endpoint,
+      });
+
+      const response = await fetch(`http://127.0.0.1:${harness.port}/sse`);
+      expect(response.status).toBe(404);
+      expect(await response.text()).toContain('/mcp');
+    } finally {
+      await harness.close();
+    }
+  });
+
+  it('bootstraps startup API-key auth from LINEAR_ACCESS_TOKEN', async () => {
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'runtime-access-token-alias-test',
+      apiKeyEnv: {
+        LINEAR_ACCESS_TOKEN: 'access-token-alias',
+      },
+    });
+
+    try {
+      await harness.client.listTools();
+
+      expect((harness.server as any).stdioAuth.isAuthenticated()).toBe(true);
+      expect((harness.server as any).stdioAuth.config).toMatchObject({
+        type: 'api',
+        apiKey: 'access-token-alias',
+      });
+      expect(consoleErrorSpy).toHaveBeenCalledWith('Auth: LINEAR_ACCESS_TOKEN detected.');
+    } finally {
+      await harness.close();
+    }
+  });
+
+  it('prefers LINEAR_API_KEY when both startup API-key env vars are set', async () => {
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'runtime-api-key-precedence-test',
+      apiKeyEnv: {
+        LINEAR_API_KEY: 'primary-api-key',
+        LINEAR_ACCESS_TOKEN: 'alias-api-key',
+      },
+    });
+
+    try {
+      await harness.client.listTools();
+
+      expect((harness.server as any).stdioAuth.isAuthenticated()).toBe(true);
+      expect((harness.server as any).stdioAuth.config).toMatchObject({
+        type: 'api',
+        apiKey: 'primary-api-key',
+      });
+      expect(consoleErrorSpy).toHaveBeenCalledWith(
+        'Auth: both LINEAR_API_KEY and LINEAR_ACCESS_TOKEN detected. Using LINEAR_API_KEY.'
+      );
+    } finally {
+      await harness.close();
+    }
+  });
+
+  it('rejects malformed tool arguments before handler dispatch', async () => {
+    const backend = createIssueWorkflowSmokeBackend();
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'runtime-validation-test',
+      serverOptions: {
+        auth: backend.auth,
+      },
+    });
+
+    try {
+      const result = await harness.client.callTool({
+        name: 'linear_create_issue',
+        arguments: {
+          teamId: 'team-1',
+        },
+      }) as { isError?: boolean; structuredContent?: Record<string, unknown> };
+
+      expect(result.isError).toBe(true);
+      expect(result.structuredContent).toMatchObject({
+        tool: 'linear_create_issue',
+        error: {
+          type: 'validation',
+        },
+      });
+      expect(backend.createIssue).not.toHaveBeenCalled();
+      expect(result.structuredContent?.error).toEqual(
+        expect.objectContaining({
+          details: expect.arrayContaining([
+            expect.objectContaining({
+              path: '$.title',
+            }),
+          ]),
+        })
+      );
+    } finally {
+      await harness.close();
+    }
+  });
+
+  it('emits structured telemetry for successful tool requests', async () => {
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'runtime-telemetry-success-test',
+    });
+
+    try {
+      await harness.client.callTool({
+        name: 'linear_get_capabilities',
+        arguments: {},
+      });
+
+      const telemetry = getTelemetryEntries(consoleErrorSpy).at(-1);
+      expect(telemetry).toMatchObject({
+        event: 'mcp_tool_request',
+        tool: 'linear_get_capabilities',
+        transport: 'stream',
+        authScope: 'session',
+        outcome: 'success',
+      });
+      expect(telemetry?.durationMs).toEqual(expect.any(Number));
+      expect(telemetry).not.toHaveProperty('upstreamRequestId');
+    } finally {
+      await harness.close();
+    }
+  });
+
+  it('sanitizes structured GraphQL errors at the MCP boundary', async () => {
+    const graphQLClient = {
+      sdk: {
+        issue: jest.fn(),
+      },
+      executeSdk: jest.fn(async () => {
+        throw new LinearGraphQLRequestError(
+          'issue',
+          {
+            errors: [
+              {
+                message: 'Rate limited',
+                extensions: {
+                  code: 'RATE_LIMITED',
+                  secret: 'hidden',
+                },
+              },
+            ],
+            meta: {
+              status: 429,
+              retryable: true,
+              headers: {
+                authorization: 'Bearer secret',
+                'x-request-id': 'req-123',
+              },
+            },
+            extensions: {
+              requestId: 'req-999',
+              traceId: 'hidden',
+            },
+          },
+          'GraphQL operation issue failed: Rate limited'
+        );
+      }),
+    } as unknown as LinearGraphQLClient;
+
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'runtime-error-shape-test',
+      serverOptions: {
+        auth: new TestLinearAuth(graphQLClient),
+      },
+    });
+
+    try {
+      const result = await harness.client.callTool({
+        name: 'linear_get_issue',
+        arguments: {
+          id: 'ISS-1',
+        },
+      }) as { isError?: boolean; structuredContent?: Record<string, any> };
+
+      expect(result.isError).toBe(true);
+      expect(result.structuredContent).toMatchObject({
+        error: {
+          type: 'graphql',
+          graphql: {
+            status: 429,
+            retryable: true,
+            requestId: 'req-123',
+            errors: [
+              {
+                message: 'Rate limited',
+                extensions: {
+                  code: 'RATE_LIMITED',
+                },
+              },
+            ],
+          },
+        },
+      });
+      expect(result.structuredContent?.error.graphql).not.toHaveProperty('headers');
+      expect(result.structuredContent?.error.graphql).not.toHaveProperty('extensions');
+      expect(result.structuredContent?.error.graphql.errors[0].extensions).not.toHaveProperty('secret');
+    } finally {
+      await harness.close();
+    }
+  });
+
+  it('emits sanitized telemetry for failed tool requests', async () => {
+    const graphQLClient = {
+      sdk: {
+        issue: jest.fn(),
+      },
+      executeSdk: jest.fn(async () => {
+        throw new LinearGraphQLRequestError(
+          'issue',
+          {
+            errors: [
+              {
+                message: 'Rate limited',
+                extensions: {
+                  code: 'RATE_LIMITED',
+                  secret: 'hidden',
+                },
+              },
+            ],
+            meta: {
+              status: 429,
+              retryable: true,
+              headers: {
+                authorization: 'Bearer secret',
+                'x-request-id': 'req-123',
+              },
+            },
+            extensions: {
+              requestId: 'req-999',
+              traceId: 'hidden',
+            },
+          },
+          'GraphQL operation issue failed: Rate limited'
+        );
+      }),
+    } as unknown as LinearGraphQLClient;
+
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'runtime-telemetry-failure-test',
+      serverOptions: {
+        auth: new TestLinearAuth(graphQLClient),
+      },
+    });
+
+    try {
+      await harness.client.callTool({
+        name: 'linear_get_issue',
+        arguments: {
+          id: 'ISS-1',
+        },
+      });
+
+      const telemetry = getTelemetryEntries(consoleErrorSpy).at(-1);
+      expect(telemetry).toMatchObject({
+        event: 'mcp_tool_request',
+        tool: 'linear_get_issue',
+        transport: 'stream',
+        authScope: 'session',
+        outcome: 'error',
+        errorType: 'graphql',
+        retryable: true,
+        upstreamRequestId: 'req-123',
+        upstreamStatus: 429,
+      });
+
+      const serializedTelemetry = JSON.stringify(telemetry);
+      expect(serializedTelemetry).not.toContain('authorization');
+      expect(serializedTelemetry).not.toContain('Bearer secret');
+      expect(serializedTelemetry).not.toContain('hidden');
+    } finally {
+      await harness.close();
+    }
+  });
+
+  it('reports transport-aware runtime diagnostics without secrets', async () => {
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'runtime-diagnostics-test',
+    });
+
+    try {
+      const tools = await harness.client.listTools();
+      expect(tools.tools.some(tool => tool.name === 'linear_get_runtime_diagnostics')).toBe(true);
+
+      await harness.client.callTool({
+        name: 'linear_get_capabilities',
+        arguments: {},
+      });
+
+      const validationResult = await harness.client.callTool({
+        name: 'linear_create_issue',
+        arguments: {
+          teamId: 'team-1',
+        },
+      }) as { isError?: boolean };
+      expect(validationResult.isError).toBe(true);
+
+      const diagnosticsResult = await harness.client.callTool({
+        name: 'linear_get_runtime_diagnostics',
+        arguments: {},
+      }) as { structuredContent?: Record<string, any> };
+
+      expect(diagnosticsResult.structuredContent).toMatchObject({
+        transport: 'stream',
+        authScope: 'session',
+        sessions: {
+          activeStreamSessions: 1,
+        },
+        requests: {
+          total: 2,
+          successful: 1,
+          failed: 1,
+        },
+        failures: {
+          validation: 1,
+          retryable: 0,
+        },
+        auth: {
+          startupMode: 'tool-driven',
+          startupSource: null,
+        },
+        lastFailure: {
+          tool: 'linear_create_issue',
+          type: 'validation',
+          retryable: false,
+        },
+      });
+
+      const serializedDiagnostics = JSON.stringify(diagnosticsResult.structuredContent);
+      expect(serializedDiagnostics).not.toContain('LINEAR_API_KEY');
+      expect(serializedDiagnostics).not.toContain('LINEAR_ACCESS_TOKEN');
+      expect(serializedDiagnostics).not.toContain('authorization');
+      expect(serializedDiagnostics).not.toContain('Bearer');
+    } finally {
+      await harness.close();
+    }
+  });
+
+  it('isolates OAuth state across concurrent stream sessions', async () => {
+    const originalFetch = global.fetch.bind(globalThis);
+    const tokenResponses = [
+      new Response(JSON.stringify({
+        access_token: 'token-1',
+        refresh_token: 'refresh-1',
+        expires_in: 3600,
+      }), {
+        status: 200,
+        headers: {
+          'content-type': 'application/json',
+        },
+      }),
+      new Response(JSON.stringify({
+        access_token: 'token-2',
+        refresh_token: 'refresh-2',
+        expires_in: 3600,
+      }), {
+        status: 200,
+        headers: {
+          'content-type': 'application/json',
+        },
+      }),
+    ];
+    const fetchSpy = jest.spyOn(global, 'fetch').mockImplementation(async (input, init) => {
+      const url = typeof input === 'string'
+        ? input
+        : input instanceof URL
+          ? input.toString()
+          : input.url;
+
+      if (url === 'https://api.linear.app/oauth/token') {
+        const response = tokenResponses.shift();
+        if (!response) {
+          throw new Error('Unexpected extra Linear OAuth token exchange');
+        }
+
+        return response;
+      }
+
+      return originalFetch(input, init);
+    });
+
+    const harness = await createRuntimeSmokeHarness({
+      clientName: 'runtime-auth-session-1',
+    });
+    const secondClient = new Client(
+      {
+        name: 'runtime-auth-session-2',
+        version: '1.0.0',
+      },
+      {
+        capabilities: {},
+      }
+    );
+
+    try {
+      await secondClient.connect(new StreamableHTTPClientTransport(new URL(harness.endpoint)));
+
+      const firstAuth = await harness.client.callTool({
+        name: 'linear_auth',
+        arguments: {
+          clientId: 'client-id',
+          clientSecret: 'client-secret',
+          redirectUri: 'http://localhost:3000/callback',
+        },
+      }) as { structuredContent?: Record<string, unknown> };
+      const secondAuth = await secondClient.callTool({
+        name: 'linear_auth',
+        arguments: {
+          clientId: 'client-id',
+          clientSecret: 'client-secret',
+          redirectUri: 'http://localhost:3000/callback',
+        },
+      }) as { structuredContent?: Record<string, unknown> };
+
+      const firstState = firstAuth.structuredContent?.state as string;
+      const secondState = secondAuth.structuredContent?.state as string;
+
+      expect(firstState).toEqual(expect.any(String));
+      expect(secondState).toEqual(expect.any(String));
+      expect(secondState).not.toBe(firstState);
+
+      const firstCallback = await harness.client.callTool({
+        name: 'linear_auth_callback',
+        arguments: {
+          code: 'code-1',
+          state: firstState,
+        },
+      }) as { structuredContent?: Record<string, unknown> };
+      const secondCallback = await secondClient.callTool({
+        name: 'linear_auth_callback',
+        arguments: {
+          code: 'code-2',
+          state: secondState,
+        },
+      }) as { structuredContent?: Record<string, unknown> };
+
+      expect(firstCallback.structuredContent).toMatchObject({
+        authenticated: true,
+      });
+      expect(secondCallback.structuredContent).toMatchObject({
+        authenticated: true,
+      });
+    } finally {
+      fetchSpy.mockRestore();
+      await secondClient.close().catch(() => undefined);
+      await harness.close();
+    }
+  });
+});
diff --git a/src/__tests__/tool-contracts.test.ts b/src/__tests__/tool-contracts.test.ts
new file mode 100644
index 0000000..9dbb3a7
--- /dev/null
+++ b/src/__tests__/tool-contracts.test.ts
@@ -0,0 +1,226 @@
+import { describe, expect, it } from '@jest/globals';
+import { getAdvertisedToolSchemas, toolSchemas } from '../core/types/tool.types';
+
+function containsOptionalKeyword(value: unknown): boolean {
+  if (Array.isArray(value)) {
+    return value.some(containsOptionalKeyword);
+  }
+
+  if (value && typeof value === 'object') {
+    const record = value as Record<string, unknown>;
+    if (Object.prototype.hasOwnProperty.call(record, 'optional')) {
+      return true;
+    }
+
+    return Object.values(record).some(containsOptionalKeyword);
+  }
+
+  return false;
+}
+
+describe('tool contracts', () => {
+  it('requires OAuth state for the auth callback schema', () => {
+    expect(toolSchemas.linear_auth_callback.inputSchema).toMatchObject({
+      required: ['code', 'state'],
+    });
+  });
+
+  it('advertises distinct list and search tools for issues and projects', () => {
+    expect(toolSchemas.linear_list_issues.name).toBe('linear_list_issues');
+    expect(toolSchemas.linear_search_issues.name).toBe('linear_search_issues');
+    expect(toolSchemas.linear_list_projects.name).toBe('linear_list_projects');
+    expect(toolSchemas.linear_search_projects.name).toBe('linear_search_projects');
+  });
+
+  it('advertises issue search as query-backed instead of a generic filter-only list call', () => {
+    expect(toolSchemas.linear_search_issues.inputSchema).toMatchObject({
+      required: ['query'],
+      properties: {
+        query: {
+          type: 'string',
+        },
+        projectId: {
+          type: 'string',
+        },
+      },
+    });
+    expect(toolSchemas.linear_search_issues.inputSchema.properties).not.toHaveProperty('filter');
+    expect(toolSchemas.linear_search_issues.inputSchema.properties).not.toHaveProperty('orderBy');
+  });
+
+  it('advertises distinct single and batch issue creation schemas', () => {
+    expect(toolSchemas.linear_create_issue.inputSchema).toMatchObject({
+      required: ['title', 'teamId'],
+      properties: {
+        title: {
+          type: 'string',
+        },
+        teamId: {
+          type: 'string',
+        },
+      },
+    });
+    expect(toolSchemas.linear_create_issues.inputSchema).toMatchObject({
+      required: ['issues'],
+      properties: {
+        issues: {
+          type: 'array',
+          minItems: 1,
+        },
+      },
+    });
+    expect(toolSchemas.linear_create_issue.inputSchema).not.toEqual(toolSchemas.linear_create_issues.inputSchema);
+  });
+
+  it('uses standard JSON Schema keywords without non-standard optional flags', () => {
+    expect(containsOptionalKeyword(toolSchemas)).toBe(false);
+  });
+
+  it('avoids top-level union combinators in advertised tool schemas for Claude compatibility', () => {
+    expect(
+      getAdvertisedToolSchemas().every(tool =>
+        !['anyOf', 'allOf', 'oneOf'].some(keyword =>
+          Object.prototype.hasOwnProperty.call(tool.inputSchema, keyword)
+        )
+      )
+    ).toBe(true);
+  });
+
+  it('uses parentId consistently for threaded comment creation', () => {
+    expect(toolSchemas.linear_create_comment.inputSchema).toMatchObject({
+      required: ['body'],
+      properties: {
+        parentId: {
+          type: 'string',
+        },
+      },
+      not: {
+        properties: {
+          issueId: false,
+          parentId: false,
+        },
+      },
+    });
+  });
+
+  it('rejects conflicting issue state filters in list and search schemas', () => {
+    expect(toolSchemas.linear_list_issues.inputSchema).toMatchObject({
+      not: {
+        required: ['stateId', 'states'],
+        properties: {
+          states: {
+            type: 'array',
+            minItems: 1,
+          },
+        },
+      },
+    });
+    expect(toolSchemas.linear_search_issues.inputSchema).toMatchObject({
+      not: {
+        required: ['stateId', 'states'],
+        properties: {
+          states: {
+            type: 'array',
+            minItems: 1,
+          },
+        },
+      },
+    });
+  });
+
+  it('advertises direct and lifecycle comment tools', () => {
+    expect(toolSchemas.linear_get_comment.name).toBe('linear_get_comment');
+    expect(toolSchemas.linear_list_comments.name).toBe('linear_list_comments');
+    expect(toolSchemas.linear_update_comment.name).toBe('linear_update_comment');
+    expect(toolSchemas.linear_delete_comment.name).toBe('linear_delete_comment');
+    expect(toolSchemas.linear_resolve_comment.name).toBe('linear_resolve_comment');
+    expect(toolSchemas.linear_unresolve_comment.name).toBe('linear_unresolve_comment');
+  });
+
+  it('requires at least one editable field when updating a comment', () => {
+    expect(toolSchemas.linear_update_comment.inputSchema).toMatchObject({
+      required: ['id'],
+      not: {
+        properties: {
+          body: false,
+          bodyData: false,
+          quotedText: false,
+        },
+      },
+    });
+  });
+
+  it('allows explicit null to clear issue project assignment', () => {
+    expect(toolSchemas.linear_bulk_update_issues.inputSchema).toMatchObject({
+      properties: {
+        update: {
+          properties: {
+            projectId: {
+              type: ['string', 'null'],
+            },
+          },
+        },
+      },
+    });
+  });
+
+  it('advertises initiative association on project create and update schemas', () => {
+    expect(toolSchemas.linear_create_project.inputSchema).toMatchObject({
+      properties: {
+        initiativeId: {
+          type: 'string',
+        },
+      },
+    });
+    expect(toolSchemas.linear_update_project.inputSchema).toMatchObject({
+      properties: {
+        initiativeId: {
+          type: ['string', 'null'],
+        },
+      },
+    });
+  });
+
+  it('bounds flexible agent payload objects and narrows user state entries', () => {
+    expect(toolSchemas.linear_update_agent_session.inputSchema).toMatchObject({
+      properties: {
+        plan: {
+          type: 'object',
+          maxProperties: 20,
+        },
+        userState: {
+          type: 'array',
+          items: {
+            required: ['userId'],
+            properties: {
+              userId: {
+                type: 'string',
+              },
+              lastReadAt: {
+                type: 'string',
+              },
+            },
+          },
+        },
+      },
+    });
+
+    expect(toolSchemas.linear_create_agent_activity.inputSchema).toMatchObject({
+      required: ['agentSessionId', 'content'],
+      properties: {
+        content: {
+          type: 'object',
+          maxProperties: 20,
+        },
+        contextualMetadata: {
+          type: 'object',
+          maxProperties: 20,
+        },
+        signalMetadata: {
+          type: 'object',
+          maxProperties: 20,
+        },
+      },
+    });
+  });
+});
diff --git a/src/auth.ts b/src/auth.ts
index a48045c..627fc63 100644
--- a/src/auth.ts
+++ b/src/auth.ts
@@ -1,23 +1,11 @@
+import { randomBytes } from 'node:crypto';
 import { LinearClient } from '@linear/sdk';
 import { McpError, ErrorCode } from '@modelcontextprotocol/sdk/types.js';
-
-/**
- * Solution Attempts:
- * 
- * 1. OAuth Flow with Browser (Initial Attempt)
- * - Used browser redirect and local server for OAuth flow
- * - Issues: Browser extensions interfering, CORS issues
- * - Status: Failed - Browser extensions and CORS blocking requests
- * 
- * 2. Personal Access Token (Current Attempt)
- * - Using API Key for initial integration tests
- * - Simpler approach without browser interaction
- * - Status: Working - Successfully authenticates and makes API calls
- * 
- * 3. Direct OAuth Token Exchange (Current Attempt)
- * - Using form-urlencoded content type as required by Linear
- * - Status: In Progress - Testing token exchange
- */
+import {
+  DEFAULT_OAUTH_REQUEST_TIMEOUT_MS,
+  executeWithRequestPolicy,
+} from './core/request-policy.js';
+import { LinearGraphQLClient } from './graphql/client.js';
 
 export interface OAuthConfig {
   type: 'oauth';
@@ -39,77 +27,73 @@ export interface TokenData {
   expiresAt: number;
 }
 
+export interface LinearAuthOptions {
+  oauthRequestTimeoutMs?: number;
+}
+
 export class LinearAuth {
   private static readonly OAUTH_AUTH_URL = 'https://linear.app/oauth';
   private static readonly OAUTH_TOKEN_URL = 'https://api.linear.app';
+  private static readonly OAUTH_SCOPE = 'read,write,issues:create';
+  private static readonly OAUTH_ACTOR = 'app';
   private config?: AuthConfig;
   private tokenData?: TokenData;
   private linearClient?: LinearClient;
+  private pendingOAuthState?: string;
+  private refreshPromise?: Promise<void>;
 
-  constructor() {}
+  constructor(private readonly options: LinearAuthOptions = {}) {}
 
   public getAuthorizationUrl(): string {
-    if (!this.config || this.config.type !== 'oauth') {
-      throw new McpError(
-        ErrorCode.InvalidRequest,
-        'OAuth config not initialized'
-      );
-    }
+    const config = this.getOAuthConfig();
+    const state = this.generateState();
+    this.pendingOAuthState = state;
 
     const params = new URLSearchParams({
-      client_id: this.config.clientId,
-      redirect_uri: this.config.redirectUri,
+      client_id: config.clientId,
+      redirect_uri: config.redirectUri,
       response_type: 'code',
-      scope: 'read,write,issues:create,offline_access',
-      actor: 'application', // Enable OAuth Actor Authorization
-      state: this.generateState(),
-      access_type: 'offline',
+      scope: LinearAuth.OAUTH_SCOPE,
+      actor: LinearAuth.OAUTH_ACTOR,
+      state,
     });
 
     return `${LinearAuth.OAUTH_AUTH_URL}/authorize?${params.toString()}`;
   }
 
-  public async handleCallback(code: string): Promise<void> {
-    if (!this.config || this.config.type !== 'oauth') {
+  public async handleCallback(code: string, state: string): Promise<void> {
+    const config = this.getOAuthConfig();
+
+    if (!this.pendingOAuthState) {
       throw new McpError(
         ErrorCode.InvalidRequest,
-        'OAuth config not initialized'
+        'No pending OAuth authorization request was found. Call linear_auth again to obtain a fresh authorization URL and state.'
       );
     }
 
+    if (state !== this.pendingOAuthState) {
+      throw new McpError(
+        ErrorCode.InvalidRequest,
+        'OAuth callback state did not match the issued authorization request. Authorization URLs are single-use; call linear_auth again to obtain a fresh state.'
+      );
+    }
+
+    this.pendingOAuthState = undefined;
+
     try {
       const params = new URLSearchParams({
         grant_type: 'authorization_code',
-        client_id: this.config.clientId,
-        client_secret: this.config.clientSecret,
-        redirect_uri: this.config.redirectUri,
+        client_id: config.clientId,
+        client_secret: config.clientSecret,
+        redirect_uri: config.redirectUri,
         code,
-        access_type: 'offline'
       });
 
-      const response = await fetch(`${LinearAuth.OAUTH_TOKEN_URL}/oauth/token`, {
-        method: 'POST',
-        headers: {
-          'Content-Type': 'application/x-www-form-urlencoded',
-          'Accept': 'application/json'
-        },
-        body: params.toString()
-      });
-
-      if (!response.ok) {
-        const errorText = await response.text();
-        throw new Error(`Token request failed: ${response.statusText}. Response: ${errorText}`);
-      }
-
-      const data = await response.json();
-      this.tokenData = {
+      const data = await this.exchangeToken(params, 'OAuth token exchange');
+      this.setActiveToken({
         apiKey: data.access_token,
-        refreshToken: data.refresh_token,
+        refreshToken: data.refresh_token ?? '',
         expiresAt: Date.now() + data.expires_in * 1000,
-      };
-
-      this.linearClient = new LinearClient({
-        apiKey: this.tokenData.apiKey,
       });
     } catch (error) {
       throw new McpError(
@@ -120,73 +104,54 @@ export class LinearAuth {
   }
 
   public async refreshAPIKey(): Promise<void> {
-    if (!this.config || this.config.type !== 'oauth' || !this.tokenData?.refreshToken) {
-      throw new McpError(
-        ErrorCode.InvalidRequest,
-        'OAuth not initialized or no refresh token available'
-      );
+    if (this.refreshPromise) {
+      await this.refreshPromise;
+      return;
     }
 
-    try {
-      const params = new URLSearchParams({
-        grant_type: 'refresh_token',
-        client_id: this.config.clientId,
-        client_secret: this.config.clientSecret,
-        refresh_token: this.tokenData.refreshToken
-      });
-
-      const response = await fetch(`${LinearAuth.OAUTH_TOKEN_URL}/oauth/token`, {
-        method: 'POST',
-        headers: {
-          'Content-Type': 'application/x-www-form-urlencoded',
-          'Accept': 'application/json'
-        },
-        body: params.toString()
-      });
+    this.refreshPromise = this.performRefresh();
 
-      if (!response.ok) {
-        const errorText = await response.text();
-        throw new Error(`Token refresh failed: ${response.statusText}. Response: ${errorText}`);
-      }
-
-      const data = await response.json();
-      this.tokenData = {
-        apiKey: data.access_token,
-        refreshToken: data.refresh_token,
-        expiresAt: Date.now() + data.expires_in * 1000,
-      };
+    try {
+      await this.refreshPromise;
+    } finally {
+      this.refreshPromise = undefined;
+    }
+  }
 
-      this.linearClient = new LinearClient({
-        apiKey: this.tokenData.apiKey,
-      });
-    } catch (error) {
+  public async ensureAuthenticatedClient(): Promise<LinearClient> {
+    if (!this.isAuthenticated()) {
       throw new McpError(
-        ErrorCode.InternalError,
-        `Token refresh failed: ${error instanceof Error ? error.message : 'Unknown error'}`
+        ErrorCode.InvalidRequest,
+        'Not authenticated. Call linear_auth first.'
       );
     }
+
+    if (this.needsTokenRefresh()) {
+      await this.refreshAPIKey();
+    }
+
+    return this.getClient();
   }
 
   public initialize(config: AuthConfig): void {
+    this.config = config;
+    this.pendingOAuthState = undefined;
+
     if (config.type === 'api') {
-      // Personal Access Token flow
-      this.tokenData = {
-        apiKey: config.apiKey,
-        refreshToken: '', // Not needed for API Key
-        expiresAt: Number.MAX_SAFE_INTEGER, // API Keys don't expire
-      };
-      this.linearClient = new LinearClient({
+      this.setActiveToken({
         apiKey: config.apiKey,
+        refreshToken: '',
+        expiresAt: Number.MAX_SAFE_INTEGER,
       });
     } else {
-      // OAuth flow
       if (!config.clientId || !config.clientSecret || !config.redirectUri) {
         throw new McpError(
           ErrorCode.InvalidParams,
           'Missing required OAuth parameters: clientId, clientSecret, redirectUri'
         );
       }
-      this.config = config;
+      this.tokenData = undefined;
+      this.linearClient = undefined;
     }
   }
 
@@ -200,6 +165,10 @@ export class LinearAuth {
     return this.linearClient;
   }
 
+  public getGraphQLClient(): LinearGraphQLClient {
+    return new LinearGraphQLClient(this.getClient());
+  }
+
   public isAuthenticated(): boolean {
     return !!this.linearClient && !!this.tokenData;
   }
@@ -211,13 +180,141 @@ export class LinearAuth {
 
   // For testing purposes
   public setTokenData(tokenData: TokenData): void {
+    this.setActiveToken(tokenData);
+  }
+
+  public getPendingOAuthState(): string | undefined {
+    return this.pendingOAuthState;
+  }
+
+  public createScopedCopy(): LinearAuth {
+    const copy = new LinearAuth(this.options);
+
+    if (!this.config) {
+      return copy;
+    }
+
+    copy.initialize(
+      this.config.type === 'api'
+        ? {
+            type: 'api',
+            apiKey: this.config.apiKey,
+          }
+        : {
+            type: 'oauth',
+            clientId: this.config.clientId,
+            clientSecret: this.config.clientSecret,
+            redirectUri: this.config.redirectUri,
+          }
+    );
+
+    if (this.tokenData) {
+      copy.setTokenData({
+        ...this.tokenData,
+      });
+    }
+
+    return copy;
+  }
+
+  private generateState(): string {
+    return randomBytes(32).toString('base64url');
+  }
+
+  private getOAuthConfig(): OAuthConfig {
+    if (!this.config || this.config.type !== 'oauth') {
+      throw new McpError(
+        ErrorCode.InvalidRequest,
+        'OAuth config not initialized'
+      );
+    }
+
+    return this.config;
+  }
+
+  private setActiveToken(tokenData: TokenData): void {
     this.tokenData = tokenData;
     this.linearClient = new LinearClient({
       apiKey: tokenData.apiKey,
     });
   }
 
-  private generateState(): string {
-    return Math.random().toString(36).substring(2, 15);
+  private async performRefresh(): Promise<void> {
+    const config = this.getOAuthConfig();
+    if (!this.tokenData?.refreshToken) {
+      throw new McpError(
+        ErrorCode.InvalidRequest,
+        'OAuth not initialized or no refresh token available'
+      );
+    }
+
+    try {
+      const params = new URLSearchParams({
+        grant_type: 'refresh_token',
+        client_id: config.clientId,
+        client_secret: config.clientSecret,
+        refresh_token: this.tokenData.refreshToken
+      });
+
+      const data = await this.exchangeToken(params, 'OAuth token refresh');
+      this.setActiveToken({
+        apiKey: data.access_token,
+        refreshToken: data.refresh_token ?? this.tokenData.refreshToken,
+        expiresAt: Date.now() + data.expires_in * 1000,
+      });
+    } catch (error) {
+      throw new McpError(
+        ErrorCode.InternalError,
+        `Token refresh failed: ${error instanceof Error ? error.message : 'Unknown error'}`
+      );
+    }
+  }
+
+  private async exchangeToken(
+    params: URLSearchParams,
+    context: string
+  ): Promise<{
+    access_token: string;
+    refresh_token?: string;
+    expires_in: number;
+  }> {
+    return executeWithRequestPolicy(
+      context,
+      async ({ signal }) => {
+        const response = await fetch(`${LinearAuth.OAUTH_TOKEN_URL}/oauth/token`, {
+          method: 'POST',
+          headers: {
+            'Content-Type': 'application/x-www-form-urlencoded',
+            'Accept': 'application/json'
+          },
+          body: params.toString(),
+          signal,
+        });
+
+        if (!response.ok) {
+          const errorText = await response.text();
+          throw new Error(`${context} failed: ${response.statusText}. Response: ${errorText}`);
+        }
+
+        const data = await response.json() as Partial<{
+          access_token: string;
+          refresh_token: string;
+          expires_in: number;
+        }>;
+
+        if (!data.access_token || typeof data.expires_in !== 'number') {
+          throw new Error(`${context} returned an incomplete token response`);
+        }
+
+        return {
+          access_token: data.access_token,
+          refresh_token: data.refresh_token,
+          expires_in: data.expires_in,
+        };
+      },
+      {
+        timeoutMs: this.options.oauthRequestTimeoutMs ?? DEFAULT_OAUTH_REQUEST_TIMEOUT_MS,
+      }
+    );
   }
 }
diff --git a/src/core/capabilities.ts b/src/core/capabilities.ts
new file mode 100644
index 0000000..3bece5b
--- /dev/null
+++ b/src/core/capabilities.ts
@@ -0,0 +1,103 @@
+import { ServerBuildInfo, getServerBuildInfo } from './server-build.js';
+
+export type RuntimeTransport = 'stdio' | 'stream';
+
+export interface StreamTransportOptions {
+  host?: string;
+  port?: number;
+  path?: string;
+}
+
+export interface RuntimeCapabilityOptions {
+  transport?: RuntimeTransport;
+  streamingSupported?: boolean;
+  host?: string;
+  port?: number;
+  path?: string;
+  server?: ServerBuildInfo;
+}
+
+export interface StreamTransportConfig {
+  host: string;
+  port: number;
+  path: string;
+  endpoint: string;
+}
+
+export interface RuntimeCapabilities {
+  server: ServerBuildInfo;
+  runtime: 'node';
+  transport: RuntimeTransport;
+  authScope: 'server' | 'session';
+  streamingSupported: boolean;
+  supportsSubscriptions: boolean;
+  endpoint: string | null;
+  capabilities: {
+    webhookManagement: boolean;
+    portfolioEntities: boolean;
+    agentWorkflows: boolean;
+    subscriptions: boolean;
+  };
+}
+
+function normalizeTransportPath(value?: string): string {
+  if (!value) {
+    return '/mcp';
+  }
+
+  return value.startsWith('/') ? value : `/${value}`;
+}
+
+function parseTransportPort(value?: string): number {
+  if (!value) {
+    return 3000;
+  }
+
+  const parsed = Number.parseInt(value, 10);
+  return Number.isInteger(parsed) && parsed > 0 ? parsed : 3000;
+}
+
+export function getStreamTransportConfig(
+  options: StreamTransportOptions = {}
+): StreamTransportConfig {
+  const host = options.host ?? process.env.LINEAR_MCP_HOST ?? '127.0.0.1';
+  const port = options.port ?? parseTransportPort(process.env.LINEAR_MCP_PORT);
+  const path = normalizeTransportPath(options.path ?? process.env.LINEAR_MCP_PATH);
+
+  return {
+    host,
+    port,
+    path,
+    endpoint: `http://${host}:${port}${path}`,
+  };
+}
+
+export function getRuntimeCapabilities(
+  options: RuntimeCapabilityOptions = {}
+): RuntimeCapabilities {
+  const server = options.server ?? getServerBuildInfo();
+  const transport = options.transport
+    ?? (process.env.LINEAR_MCP_TRANSPORT === 'stream' ? 'stream' : 'stdio');
+  const streamConfig = transport === 'stream'
+    ? getStreamTransportConfig(options)
+    : undefined;
+  const streamingSupported = options.streamingSupported
+    ?? transport === 'stream';
+  const supportsSubscriptions = streamingSupported && transport === 'stream';
+
+  return {
+    server,
+    runtime: 'node',
+    transport,
+    authScope: transport === 'stream' ? 'session' : 'server',
+    streamingSupported,
+    supportsSubscriptions,
+    endpoint: streamConfig?.endpoint ?? null,
+    capabilities: {
+      webhookManagement: true,
+      portfolioEntities: true,
+      agentWorkflows: true,
+      subscriptions: supportsSubscriptions,
+    },
+  };
+}
diff --git a/src/core/concurrency.ts b/src/core/concurrency.ts
new file mode 100644
index 0000000..c87e3b5
--- /dev/null
+++ b/src/core/concurrency.ts
@@ -0,0 +1,29 @@
+export async function mapWithConcurrencyLimit<TItem, TResult>(
+  items: readonly TItem[],
+  concurrency: number,
+  mapItem: (item: TItem, index: number) => Promise<TResult>
+): Promise<TResult[]> {
+  if (!Number.isInteger(concurrency) || concurrency < 1) {
+    throw new Error('concurrency must be a positive integer');
+  }
+
+  if (items.length === 0) {
+    return [];
+  }
+
+  const results = new Array<TResult>(items.length);
+  let nextIndex = 0;
+  const workerCount = Math.min(concurrency, items.length);
+
+  await Promise.all(
+    Array.from({ length: workerCount }, async () => {
+      while (nextIndex < items.length) {
+        const currentIndex = nextIndex;
+        nextIndex += 1;
+        results[currentIndex] = await mapItem(items[currentIndex] as TItem, currentIndex);
+      }
+    })
+  );
+
+  return results;
+}
diff --git a/src/core/handlers/base.handler.ts b/src/core/handlers/base.handler.ts
index 0d66019..c9268a2 100644
--- a/src/core/handlers/base.handler.ts
+++ b/src/core/handlers/base.handler.ts
@@ -1,6 +1,11 @@
 import { McpError, ErrorCode } from '@modelcontextprotocol/sdk/types.js';
 import { LinearAuth } from '../../auth.js';
-import { LinearGraphQLClient } from '../../graphql/client.js';
+import {
+  GraphQLErrorDetail,
+  GraphQLResult,
+  LinearGraphQLClient,
+  LinearGraphQLRequestError,
+} from '../../graphql/client.js';
 import { BaseToolResponse } from '../interfaces/tool-handler.interface.js';
 
 /**
@@ -8,35 +13,32 @@ import { BaseToolResponse } from '../interfaces/tool-handler.interface.js';
  * All feature-specific handlers should extend this class.
  */
 export abstract class BaseHandler {
-  constructor(
-    protected readonly auth: LinearAuth,
-    protected readonly graphqlClient: LinearGraphQLClient | undefined
-  ) {}
+  constructor(protected readonly auth: LinearAuth) {}
 
   /**
    * Verifies authentication and returns the GraphQL client.
    * Should be called at the start of each handler method.
    */
-  protected verifyAuth(): LinearGraphQLClient {
-    if (!this.auth.isAuthenticated() || !this.graphqlClient) {
+  protected async verifyAuth(): Promise<LinearGraphQLClient> {
+    if (!this.auth.isAuthenticated()) {
       throw new McpError(
         ErrorCode.InvalidRequest,
         'Not authenticated. Call linear_auth first.'
       );
     }
 
-    if (this.auth.needsTokenRefresh()) {
-      this.auth.refreshAPIKey();
-    }
-
-    return this.graphqlClient;
+    await this.auth.ensureAuthenticatedClient();
+    return this.auth.getGraphQLClient();
   }
 
   /**
    * Creates a successful response with the given text content.
    */
-  protected createResponse(text: string): BaseToolResponse {
-    return {
+  protected createResponse(
+    text: string,
+    structuredContent?: Record<string, unknown>
+  ): BaseToolResponse {
+    const response: BaseToolResponse = {
       content: [
         {
           type: 'text',
@@ -44,25 +46,130 @@ export abstract class BaseHandler {
         },
       ],
     };
+
+    if (structuredContent) {
+      response.structuredContent = structuredContent;
+    }
+
+    return response;
   }
 
   /**
    * Creates a JSON response with the given data.
    */
-  protected createJsonResponse(data: unknown): BaseToolResponse {
-    return this.createResponse(JSON.stringify(data, null, 2));
+  protected createStructuredResponse(
+    summary: string,
+    data: Record<string, unknown>,
+    graphqlResult?: GraphQLResult<unknown>
+  ): BaseToolResponse {
+    return this.createResponse(summary, this.withGraphQLResult(data, graphqlResult));
+  }
+
+  /**
+   * Creates a structured JSON response with the given data.
+   */
+  protected createJsonResponse(
+    data: unknown,
+    summary: string = 'Returned structured data',
+    graphqlResult?: GraphQLResult<unknown>
+  ): BaseToolResponse {
+    if (typeof data === 'object' && data !== null && !Array.isArray(data)) {
+      return this.createStructuredResponse(
+        summary,
+        data as Record<string, unknown>,
+        graphqlResult
+      );
+    }
+
+    return this.createStructuredResponse(summary, { value: data }, graphqlResult);
+  }
+
+  /**
+   * Creates a structured error response that MCP clients can inspect.
+   */
+  protected createErrorResponse(
+    message: string,
+    details?: Record<string, unknown>
+  ): BaseToolResponse {
+    return {
+      ...this.createResponse(message, details),
+      isError: true,
+    };
   }
 
   /**
    * Handles errors consistently across all handlers.
    */
-  protected handleError(error: unknown, operation: string): never {
-    throw new McpError(
-      ErrorCode.InternalError,
-      `Failed to ${operation}: ${error instanceof Error ? error.message : 'Unknown error'}`
+  protected handleError(error: unknown, operation: string): BaseToolResponse {
+    if (error instanceof LinearGraphQLRequestError) {
+      const errorType = this.getGraphQLErrorType(error);
+      return this.createErrorResponse(
+        `Failed to ${operation}: ${error.message}`,
+        {
+          operation,
+          error: {
+            type: errorType,
+            message: error.message,
+            retryable: error.result.meta.retryable,
+            graphql: this.serializeGraphQLResult(error.result),
+          },
+        }
+      );
+    }
+
+    if (error instanceof McpError) {
+      return this.createErrorResponse(
+        `Failed to ${operation}: ${error.message}`,
+        {
+          operation,
+          error: {
+            type: 'mcp',
+            code: error.code,
+            message: error.message,
+          },
+        }
+      );
+    }
+
+    return this.createErrorResponse(
+      `Failed to ${operation}: ${error instanceof Error ? error.message : 'Unknown error'}`,
+      {
+        operation,
+        error: {
+          type: 'internal',
+          message: error instanceof Error ? error.message : 'Unknown error',
+        },
+      }
     );
   }
 
+  private getGraphQLErrorType(error: LinearGraphQLRequestError): 'graphql' | 'auth' | 'permission' {
+    const graphQLErrorText = (error.result.errors ?? [])
+      .flatMap(detail => [
+        detail.message,
+        ...(detail.extensions ? Object.values(detail.extensions).map(value => String(value)) : []),
+      ])
+      .join(' ')
+      .toLowerCase();
+    const combined = `${error.message} ${graphQLErrorText}`.toLowerCase();
+
+    if (combined.includes('forbidden') || combined.includes('permission')) {
+      return 'permission';
+    }
+
+    if (
+      combined.includes('unauthorized')
+      || combined.includes('authentication')
+      || combined.includes('not authenticated')
+      || combined.includes('invalid api key')
+      || combined.includes('oauth')
+    ) {
+      return 'auth';
+    }
+
+    return 'graphql';
+  }
+
   /**
    * Validates that required parameters are present.
    * @param params The parameters object to validate
@@ -73,7 +180,11 @@ export abstract class BaseHandler {
     params: T,
     required: Array<keyof T & string>
   ): void {
-    const missing = required.filter(param => !params[param]);
+    const missing = required.filter(param => {
+      const value = params[param];
+      return value === undefined || value === null || (typeof value === 'string' && value.trim() === '');
+    });
+
     if (missing.length > 0) {
       throw new McpError(
         ErrorCode.InvalidParams,
@@ -81,4 +192,119 @@ export abstract class BaseHandler {
       );
     }
   }
+
+  protected withGraphQLResult<T extends Record<string, unknown>>(
+    content: T,
+    graphqlResult?: GraphQLResult<unknown>
+  ): T & { graphql?: Record<string, unknown> } {
+    if (!graphqlResult) {
+      return content;
+    }
+
+    const serialized = this.serializeGraphQLResult(graphqlResult);
+    if (!serialized) {
+      return content;
+    }
+
+    return {
+      ...content,
+      graphql: serialized,
+    };
+  }
+
+  private serializeGraphQLResult(
+    result: GraphQLResult<unknown>
+  ): Record<string, unknown> | undefined {
+    const sanitizedErrors = this.sanitizeGraphQLErrors(result.errors);
+    const requestId = this.getGraphQLRequestId(result);
+    const hasErrors = (sanitizedErrors?.length ?? 0) > 0;
+    const hasStatus = typeof result.meta.status === 'number';
+    const hasRequestId = typeof requestId === 'string' && requestId.length > 0;
+
+    if (!hasErrors && !hasStatus && !hasRequestId && !result.meta.retryable) {
+      return undefined;
+    }
+
+    const graphql: Record<string, unknown> = {
+      retryable: result.meta.retryable,
+    };
+
+    if (hasStatus) {
+      graphql.status = result.meta.status;
+    }
+
+    if (hasRequestId) {
+      graphql.requestId = requestId;
+    }
+
+    if (hasErrors) {
+      graphql.errors = sanitizedErrors;
+    }
+
+    return graphql;
+  }
+
+  private sanitizeGraphQLErrors(
+    errors?: GraphQLErrorDetail[]
+  ): GraphQLErrorDetail[] | undefined {
+    if (!errors || errors.length === 0) {
+      return undefined;
+    }
+
+    return errors.map(error => {
+      const sanitized: GraphQLErrorDetail = {
+        message: error.message,
+      };
+
+      if (error.path) {
+        sanitized.path = error.path;
+      }
+
+      const sanitizedExtensions = this.sanitizeGraphQLErrorExtensions(error.extensions);
+      if (sanitizedExtensions) {
+        sanitized.extensions = sanitizedExtensions;
+      }
+
+      return sanitized;
+    });
+  }
+
+  private sanitizeGraphQLErrorExtensions(
+    extensions?: Record<string, unknown>
+  ): Record<string, unknown> | undefined {
+    if (!extensions) {
+      return undefined;
+    }
+
+    const allowedKeys = ['code', 'type', 'statusCode', 'reason', 'classification'];
+    const sanitized = Object.fromEntries(
+      allowedKeys.flatMap(key => {
+        const value = extensions[key];
+        return value === undefined || Array.isArray(value) || (typeof value === 'object' && value !== null)
+          ? []
+          : [[key, value]];
+      })
+    );
+
+    return Object.keys(sanitized).length > 0 ? sanitized : undefined;
+  }
+
+  private getGraphQLRequestId(
+    result: GraphQLResult<unknown>
+  ): string | undefined {
+    const requestIdHeaders = ['x-request-id', 'x-linear-request-id', 'request-id'];
+
+    for (const header of requestIdHeaders) {
+      const value = result.meta.headers[header];
+      if (typeof value === 'string' && value.length > 0) {
+        return value;
+      }
+    }
+
+    if (result.extensions && typeof result.extensions.requestId === 'string') {
+      return result.extensions.requestId;
+    }
+
+    return undefined;
+  }
 }
diff --git a/src/core/handlers/handler.factory.ts b/src/core/handlers/handler.factory.ts
index 141a53d..f5b8f78 100644
--- a/src/core/handlers/handler.factory.ts
+++ b/src/core/handlers/handler.factory.ts
@@ -1,5 +1,5 @@
 import { LinearAuth } from '../../auth.js';
-import { LinearGraphQLClient } from '../../graphql/client.js';
+import { RuntimeCapabilities, getRuntimeCapabilities } from '../capabilities.js';
 import { AuthHandler } from '../../features/auth/handlers/auth.handler.js';
 import { IssueHandler } from '../../features/issues/handlers/issue.handler.js';
 import { ProjectHandler } from '../../features/projects/handlers/project.handler.js';
@@ -7,82 +7,221 @@ import { TeamHandler } from '../../features/teams/handlers/team.handler.js';
 import { UserHandler } from '../../features/users/handlers/user.handler.js';
 import { CommentHandler } from '../../features/comments/handlers/comment.handler.js';
 import { MilestoneHandler } from '../../features/milestones/handlers/milestone.handler.js';
+import { CycleHandler } from '../../features/cycles/handlers/cycle.handler.js';
+import { AttachmentHandler } from '../../features/attachments/handlers/attachment.handler.js';
+import { WebhookHandler } from '../../features/webhooks/handlers/webhook.handler.js';
+import { PortfolioHandler } from '../../features/portfolio/handlers/portfolio.handler.js';
+import { AgentHandler } from '../../features/agents/handlers/agent.handler.js';
+import { SubscriptionHandler } from '../../features/subscriptions/handlers/subscription.handler.js';
+
+type HandlerInstance =
+  | AuthHandler
+  | IssueHandler
+  | ProjectHandler
+  | TeamHandler
+  | UserHandler
+  | CommentHandler
+  | MilestoneHandler
+  | CycleHandler
+  | AttachmentHandler
+  | WebhookHandler
+  | PortfolioHandler
+  | AgentHandler
+  | SubscriptionHandler;
+
+type HandlerKey =
+  | 'auth'
+  | 'issue'
+  | 'project'
+  | 'team'
+  | 'user'
+  | 'comment'
+  | 'milestone'
+  | 'cycle'
+  | 'attachment'
+  | 'webhook'
+  | 'portfolio'
+  | 'agent'
+  | 'subscription';
+
+type ToolRoute = {
+  handlerKey: HandlerKey;
+  method: string;
+};
+
+type HandlerBuilder = (
+  auth: LinearAuth,
+  runtimeCapabilities: RuntimeCapabilities
+) => HandlerInstance;
+
+const HANDLER_BUILDERS: Record<HandlerKey, HandlerBuilder> = {
+  auth: auth => new AuthHandler(auth),
+  issue: auth => new IssueHandler(auth),
+  project: auth => new ProjectHandler(auth),
+  team: auth => new TeamHandler(auth),
+  user: auth => new UserHandler(auth),
+  comment: auth => new CommentHandler(auth),
+  milestone: auth => new MilestoneHandler(auth),
+  cycle: auth => new CycleHandler(auth),
+  attachment: auth => new AttachmentHandler(auth),
+  webhook: auth => new WebhookHandler(auth),
+  portfolio: auth => new PortfolioHandler(auth),
+  agent: auth => new AgentHandler(auth),
+  subscription: (auth, runtimeCapabilities) => new SubscriptionHandler(auth, runtimeCapabilities),
+};
+
+const TOOL_ROUTES: Record<string, ToolRoute> = {
+  // Auth tools
+  linear_auth: { handlerKey: 'auth', method: 'handleAuth' },
+  linear_auth_callback: { handlerKey: 'auth', method: 'handleAuthCallback' },
+
+  // Issue tools
+  linear_get_issue: { handlerKey: 'issue', method: 'handleGetIssue' },
+  linear_create_issue: { handlerKey: 'issue', method: 'handleCreateIssue' },
+  linear_create_issues: { handlerKey: 'issue', method: 'handleCreateIssues' },
+  linear_bulk_update_issues: { handlerKey: 'issue', method: 'handleBulkUpdateIssues' },
+  linear_list_issues: { handlerKey: 'issue', method: 'handleListIssues' },
+  linear_search_issues: { handlerKey: 'issue', method: 'handleSearchIssues' },
+  linear_create_issue_relation: { handlerKey: 'issue', method: 'handleCreateIssueRelation' },
+  linear_delete_issue_relation: { handlerKey: 'issue', method: 'handleDeleteIssueRelation' },
+  linear_delete_issue: { handlerKey: 'issue', method: 'handleDeleteIssue' },
+  linear_delete_issues: { handlerKey: 'issue', method: 'handleDeleteIssues' },
+
+  // Project tools
+  linear_create_project: { handlerKey: 'project', method: 'handleCreateProject' },
+  linear_update_project: { handlerKey: 'project', method: 'handleUpdateProject' },
+  linear_delete_project: { handlerKey: 'project', method: 'handleDeleteProject' },
+  linear_create_project_with_issues: { handlerKey: 'project', method: 'handleCreateProjectWithIssues' },
+  linear_get_project: { handlerKey: 'project', method: 'handleGetProject' },
+  linear_list_projects: { handlerKey: 'project', method: 'handleListProjects' },
+  linear_search_projects: { handlerKey: 'project', method: 'handleSearchProjects' },
+  linear_create_project_update: { handlerKey: 'project', method: 'handleCreateProjectUpdate' },
+  linear_update_project_update: { handlerKey: 'project', method: 'handleUpdateProjectUpdate' },
+
+  // Team tools
+  linear_get_team: { handlerKey: 'team', method: 'handleGetTeam' },
+  linear_get_teams: { handlerKey: 'team', method: 'handleGetTeams' },
+  linear_list_teams: { handlerKey: 'team', method: 'handleListTeams' },
+  linear_list_workflow_states: { handlerKey: 'team', method: 'handleListWorkflowStates' },
+  linear_list_labels: { handlerKey: 'team', method: 'handleListLabels' },
+  linear_create_label: { handlerKey: 'team', method: 'handleCreateLabel' },
+  linear_update_label: { handlerKey: 'team', method: 'handleUpdateLabel' },
+  linear_delete_label: { handlerKey: 'team', method: 'handleDeleteLabel' },
+
+  // User tools
+  linear_get_user: { handlerKey: 'user', method: 'handleGetUser' },
+  linear_list_users: { handlerKey: 'user', method: 'handleListUsers' },
+  linear_search_users: { handlerKey: 'user', method: 'handleSearchUsers' },
+
+  // Cycle tools
+  linear_get_cycle: { handlerKey: 'cycle', method: 'handleGetCycle' },
+  linear_list_cycles: { handlerKey: 'cycle', method: 'handleListCycles' },
+  linear_get_current_cycle: { handlerKey: 'cycle', method: 'handleGetCurrentCycle' },
+
+  // Attachment tools
+  linear_get_attachment: { handlerKey: 'attachment', method: 'handleGetAttachment' },
+  linear_list_attachments: { handlerKey: 'attachment', method: 'handleListAttachments' },
+  linear_create_attachment: { handlerKey: 'attachment', method: 'handleCreateAttachment' },
+  linear_update_attachment: { handlerKey: 'attachment', method: 'handleUpdateAttachment' },
+  linear_delete_attachment: { handlerKey: 'attachment', method: 'handleDeleteAttachment' },
+
+  // Webhook tools
+  linear_get_webhook: { handlerKey: 'webhook', method: 'handleGetWebhook' },
+  linear_list_webhooks: { handlerKey: 'webhook', method: 'handleListWebhooks' },
+  linear_create_webhook: { handlerKey: 'webhook', method: 'handleCreateWebhook' },
+  linear_delete_webhook: { handlerKey: 'webhook', method: 'handleDeleteWebhook' },
+
+  // Portfolio tools
+  linear_get_initiative: { handlerKey: 'portfolio', method: 'handleGetInitiative' },
+  linear_list_initiatives: { handlerKey: 'portfolio', method: 'handleListInitiatives' },
+  linear_create_initiative: { handlerKey: 'portfolio', method: 'handleCreateInitiative' },
+  linear_update_initiative: { handlerKey: 'portfolio', method: 'handleUpdateInitiative' },
+  linear_get_customer: { handlerKey: 'portfolio', method: 'handleGetCustomer' },
+  linear_list_customers: { handlerKey: 'portfolio', method: 'handleListCustomers' },
+  linear_create_customer: { handlerKey: 'portfolio', method: 'handleCreateCustomer' },
+  linear_update_customer: { handlerKey: 'portfolio', method: 'handleUpdateCustomer' },
+
+  // Agent tools
+  linear_get_agent_session: { handlerKey: 'agent', method: 'handleGetAgentSession' },
+  linear_list_agent_sessions: { handlerKey: 'agent', method: 'handleListAgentSessions' },
+  linear_create_agent_session_on_issue: { handlerKey: 'agent', method: 'handleCreateAgentSessionOnIssue' },
+  linear_create_agent_session_on_comment: { handlerKey: 'agent', method: 'handleCreateAgentSessionOnComment' },
+  linear_update_agent_session: { handlerKey: 'agent', method: 'handleUpdateAgentSession' },
+  linear_get_agent_activity: { handlerKey: 'agent', method: 'handleGetAgentActivity' },
+  linear_list_agent_activities: { handlerKey: 'agent', method: 'handleListAgentActivities' },
+  linear_create_agent_activity: { handlerKey: 'agent', method: 'handleCreateAgentActivity' },
+
+  // Capability and subscription tools
+  linear_get_capabilities: { handlerKey: 'subscription', method: 'handleGetCapabilities' },
+  linear_start_subscription: { handlerKey: 'subscription', method: 'handleStartSubscription' },
+  linear_stop_subscription: { handlerKey: 'subscription', method: 'handleStopSubscription' },
+
+  // Comment tools
+  linear_get_comment: { handlerKey: 'comment', method: 'handleGetComment' },
+  linear_list_comments: { handlerKey: 'comment', method: 'handleListComments' },
+  linear_get_issue_comments: { handlerKey: 'comment', method: 'handleGetIssueComments' },
+  linear_create_comment: { handlerKey: 'comment', method: 'handleCreateComment' },
+  linear_update_comment: { handlerKey: 'comment', method: 'handleUpdateComment' },
+  linear_delete_comment: { handlerKey: 'comment', method: 'handleDeleteComment' },
+  linear_resolve_comment: { handlerKey: 'comment', method: 'handleResolveComment' },
+  linear_unresolve_comment: { handlerKey: 'comment', method: 'handleUnresolveComment' },
+
+  // Milestone tools
+  linear_create_project_milestone: { handlerKey: 'milestone', method: 'handleCreateProjectMilestone' },
+  linear_update_project_milestone: { handlerKey: 'milestone', method: 'handleUpdateProjectMilestone' },
+  linear_delete_project_milestone: { handlerKey: 'milestone', method: 'handleDeleteProjectMilestone' },
+  linear_get_project_milestone: { handlerKey: 'milestone', method: 'handleGetProjectMilestone' },
+  linear_search_project_milestones: { handlerKey: 'milestone', method: 'handleSearchProjectMilestones' },
+  linear_get_project_milestones: { handlerKey: 'milestone', method: 'handleGetProjectMilestones' },
+  linear_create_project_milestones: { handlerKey: 'milestone', method: 'handleCreateProjectMilestones' },
+};
 
 /**
  * Factory for creating and managing feature-specific handlers.
  * Ensures consistent initialization and dependency injection across handlers.
  */
 export class HandlerFactory {
-  private authHandler: AuthHandler;
-  private issueHandler: IssueHandler;
-  private projectHandler: ProjectHandler;
-  private teamHandler: TeamHandler;
-  private userHandler: UserHandler;
-  private commentHandler: CommentHandler;
-  private milestoneHandler: MilestoneHandler;
-
-  constructor(auth: LinearAuth, graphqlClient?: LinearGraphQLClient) {
-    // Initialize all handlers with shared dependencies
-    this.authHandler = new AuthHandler(auth, graphqlClient);
-    this.issueHandler = new IssueHandler(auth, graphqlClient);
-    this.projectHandler = new ProjectHandler(auth, graphqlClient);
-    this.teamHandler = new TeamHandler(auth, graphqlClient);
-    this.userHandler = new UserHandler(auth, graphqlClient);
-    this.commentHandler = new CommentHandler(auth, graphqlClient);
-    this.milestoneHandler = new MilestoneHandler(auth, graphqlClient);
-  }
+  private readonly handlerCache = new WeakMap<LinearAuth, Map<HandlerKey, HandlerInstance>>();
+
+  constructor(
+    private readonly runtimeCapabilities: RuntimeCapabilities = getRuntimeCapabilities()
+  ) {}
 
   /**
    * Gets the appropriate handler for a given tool name.
    */
-  getHandlerForTool(toolName: string): {
-    handler: AuthHandler | IssueHandler | ProjectHandler | TeamHandler | UserHandler | CommentHandler | MilestoneHandler;
+  getHandlerForTool(toolName: string, auth: LinearAuth): {
+    handler: HandlerInstance;
     method: string;
   } {
-    // Map tool names to their handlers and methods
-    const handlerMap: Record<string, { handler: any; method: string }> = {
-      // Auth tools
-      linear_auth: { handler: this.authHandler, method: 'handleAuth' },
-      linear_auth_callback: { handler: this.authHandler, method: 'handleAuthCallback' },
-
-      // Issue tools
-      linear_create_issue: { handler: this.issueHandler, method: 'handleCreateIssue' },
-      linear_create_issues: { handler: this.issueHandler, method: 'handleCreateIssues' },
-      linear_bulk_update_issues: { handler: this.issueHandler, method: 'handleBulkUpdateIssues' },
-      linear_search_issues: { handler: this.issueHandler, method: 'handleSearchIssues' },
-      linear_delete_issue: { handler: this.issueHandler, method: 'handleDeleteIssue' },
-      linear_delete_issues: { handler: this.issueHandler, method: 'handleDeleteIssues' },
-
-      // Project tools
-      linear_create_project_with_issues: { handler: this.projectHandler, method: 'handleCreateProjectWithIssues' },
-      linear_get_project: { handler: this.projectHandler, method: 'handleGetProject' },
-      linear_search_projects: { handler: this.projectHandler, method: 'handleSearchProjects' },
-
-      // Team tools
-      linear_get_teams: { handler: this.teamHandler, method: 'handleGetTeams' },
-
-      // User tools
-      linear_get_user: { handler: this.userHandler, method: 'handleGetUser' },
-
-      // Comment tools
-      linear_get_issue_comments: { handler: this.commentHandler, method: 'handleGetIssueComments' },
-      linear_create_comment: { handler: this.commentHandler, method: 'handleCreateComment' },
-
-      // Milestone tools
-      linear_create_project_milestone: { handler: this.milestoneHandler, method: 'handleCreateProjectMilestone' },
-      linear_update_project_milestone: { handler: this.milestoneHandler, method: 'handleUpdateProjectMilestone' },
-      linear_delete_project_milestone: { handler: this.milestoneHandler, method: 'handleDeleteProjectMilestone' },
-      linear_get_project_milestone: { handler: this.milestoneHandler, method: 'handleGetProjectMilestone' },
-      linear_search_project_milestones: { handler: this.milestoneHandler, method: 'handleSearchProjectMilestones' },
-      linear_get_project_milestones: { handler: this.milestoneHandler, method: 'handleGetProjectMilestones' },
-      linear_create_project_milestones: { handler: this.milestoneHandler, method: 'handleCreateProjectMilestones' },
+    const route = TOOL_ROUTES[toolName];
+    if (!route) {
+      throw new Error(`No handler found for tool: ${toolName}`);
+    }
+
+    return {
+      handler: this.getOrCreateHandler(auth, route.handlerKey),
+      method: route.method,
     };
+  }
 
-    const handlerInfo = handlerMap[toolName];
-    if (!handlerInfo) {
-      throw new Error(`No handler found for tool: ${toolName}`);
+  private getOrCreateHandler(
+    auth: LinearAuth,
+    handlerKey: HandlerKey
+  ): HandlerInstance {
+    let handlersForAuth = this.handlerCache.get(auth);
+    if (!handlersForAuth) {
+      handlersForAuth = new Map<HandlerKey, HandlerInstance>();
+      this.handlerCache.set(auth, handlersForAuth);
+    }
+
+    const cachedHandler = handlersForAuth.get(handlerKey);
+    if (cachedHandler) {
+      return cachedHandler;
     }
 
-    return handlerInfo;
+    const handler = HANDLER_BUILDERS[handlerKey](auth, this.runtimeCapabilities);
+    handlersForAuth.set(handlerKey, handler);
+    return handler;
   }
 }
diff --git a/src/core/interfaces/tool-handler.interface.ts b/src/core/interfaces/tool-handler.interface.ts
index 35806cb..1d889a5 100644
--- a/src/core/interfaces/tool-handler.interface.ts
+++ b/src/core/interfaces/tool-handler.interface.ts
@@ -1,45 +1,24 @@
-/**
- * Interface for handling MCP tool requests.
- * Each handler corresponds to a specific Linear API operation.
- */
-export interface ToolHandler {
-  // Authentication
-  handleAuth(args: any): Promise<BaseToolResponse>;
-  handleAuthCallback(args: any): Promise<BaseToolResponse>;
-
-  // Issue Operations
-  handleCreateIssue(args: any): Promise<BaseToolResponse>;
-  handleCreateIssues(args: any): Promise<BaseToolResponse>;
-  handleBulkUpdateIssues(args: any): Promise<BaseToolResponse>;
-  handleSearchIssues(args: any): Promise<BaseToolResponse>;
-  handleDeleteIssue(args: any): Promise<BaseToolResponse>;
-  handleDeleteIssues(args: any): Promise<BaseToolResponse>;
-
-  // Project Operations
-  handleCreateProjectWithIssues(args: any): Promise<BaseToolResponse>;
-  handleGetProject(args: any): Promise<BaseToolResponse>;
-  handleSearchProjects(args: any): Promise<BaseToolResponse>;
-
-  // Team Operations
-  handleGetTeams(args: any): Promise<BaseToolResponse>;
-
-  // User Operations
-  handleGetUser(args: any): Promise<BaseToolResponse>;
-}
+import type { CallToolResult } from '@modelcontextprotocol/sdk/types.js';
 
-/**
- * Base response type for all tool handlers
- */
-export interface BaseToolResponse {
+export interface BaseToolResponse extends CallToolResult {
   content: Array<{
-    type: string;
+    type: 'text';
     text: string;
   }>;
+  structuredContent?: Record<string, unknown>;
+  isError?: boolean;
 }
 
+export type ToolHandlerMethod<TArgs = unknown> = (args: TArgs) => Promise<BaseToolResponse>;
+
 /**
- * Error response for tool handlers
+ * Marker interface for MCP tool handlers.
+ * Concrete handlers expose method names that the handler factory maps from tool names.
  */
+export interface ToolHandler {
+  [methodName: string]: ToolHandlerMethod | unknown;
+}
+
 export interface ErrorToolResponse extends BaseToolResponse {
   isError: true;
 }
diff --git a/src/core/request-policy.ts b/src/core/request-policy.ts
new file mode 100644
index 0000000..6ba95d2
--- /dev/null
+++ b/src/core/request-policy.ts
@@ -0,0 +1,107 @@
+export const DEFAULT_LINEAR_REQUEST_TIMEOUT_MS = 10_000;
+export const DEFAULT_OAUTH_REQUEST_TIMEOUT_MS = 10_000;
+export const DEFAULT_SAFE_READ_MAX_ATTEMPTS = 3;
+export const DEFAULT_SAFE_READ_RETRY_DELAY_MS = 250;
+
+export interface RequestAttemptContext {
+  attempt: number;
+  signal: AbortSignal;
+}
+
+export interface RequestPolicyOptions {
+  timeoutMs: number;
+  maxAttempts?: number;
+  retryDelayMs?: number;
+  shouldRetry?: (error: unknown, attempt: number) => boolean;
+}
+
+export class RequestTimeoutError extends Error {
+  constructor(
+    public readonly operation: string,
+    public readonly timeoutMs: number
+  ) {
+    super(`${operation} timed out after ${timeoutMs}ms`);
+    this.name = 'RequestTimeoutError';
+  }
+}
+
+export async function executeWithRequestPolicy<T>(
+  operation: string,
+  execute: (context: RequestAttemptContext) => Promise<T>,
+  options: RequestPolicyOptions
+): Promise<T> {
+  const timeoutMs = Math.max(options.timeoutMs, 1);
+  const maxAttempts = Math.max(options.maxAttempts ?? 1, 1);
+  const retryDelayMs = Math.max(options.retryDelayMs ?? 0, 0);
+  let lastError: unknown;
+
+  for (let attempt = 1; attempt <= maxAttempts; attempt += 1) {
+    try {
+      return await executeWithTimeout(operation, timeoutMs, attempt, execute);
+    } catch (error) {
+      lastError = error;
+      const shouldRetry = attempt < maxAttempts && (options.shouldRetry?.(error, attempt) ?? false);
+
+      if (!shouldRetry) {
+        throw error;
+      }
+
+      const backoffMs = retryDelayMs * attempt;
+      if (backoffMs > 0) {
+        await delay(backoffMs);
+      }
+    }
+  }
+
+  throw lastError instanceof Error
+    ? lastError
+    : new Error(`${operation} failed after ${maxAttempts} attempts`);
+}
+
+async function executeWithTimeout<T>(
+  operation: string,
+  timeoutMs: number,
+  attempt: number,
+  execute: (context: RequestAttemptContext) => Promise<T>
+): Promise<T> {
+  const controller = new AbortController();
+  const timeoutError = new RequestTimeoutError(operation, timeoutMs);
+
+  return await new Promise<T>((resolve, reject) => {
+    let settled = false;
+
+    const finish = (callback: () => void): void => {
+      if (settled) {
+        return;
+      }
+
+      settled = true;
+      clearTimeout(timeoutId);
+      controller.signal.removeEventListener('abort', onAbort);
+      callback();
+    };
+
+    const onAbort = (): void => {
+      finish(() => reject(timeoutError));
+    };
+
+    const timeoutId = setTimeout(() => {
+      controller.abort();
+    }, timeoutMs);
+
+    controller.signal.addEventListener('abort', onAbort, { once: true });
+
+    Promise.resolve()
+      .then(() => execute({ attempt, signal: controller.signal }))
+      .then(
+      value => finish(() => resolve(value)),
+      error => finish(() => reject(error))
+      );
+  });
+}
+
+function delay(ms: number): Promise<void> {
+  return new Promise(resolve => {
+    setTimeout(resolve, ms);
+  });
+}
diff --git a/src/core/runtime-observability.ts b/src/core/runtime-observability.ts
new file mode 100644
index 0000000..599d245
--- /dev/null
+++ b/src/core/runtime-observability.ts
@@ -0,0 +1,248 @@
+import { McpError } from '@modelcontextprotocol/sdk/types.js';
+import { RuntimeCapabilities } from './capabilities.js';
+import { BaseToolResponse } from './interfaces/tool-handler.interface.js';
+
+type TelemetryOutcome = 'success' | 'error';
+
+export interface RuntimeTelemetryRecord {
+  event: 'mcp_tool_request';
+  tool: string;
+  transport: RuntimeCapabilities['transport'];
+  authScope: RuntimeCapabilities['authScope'];
+  durationMs: number;
+  outcome: TelemetryOutcome;
+  errorType?: string;
+  retryable?: boolean;
+  upstreamRequestId?: string;
+  upstreamStatus?: number;
+  authRefreshFailure?: boolean;
+}
+
+export interface RuntimeDiagnosticsContext {
+  startupSource?: string;
+  hasPrimaryEnv: boolean;
+  hasAliasEnv: boolean;
+  stdioAuthenticated: boolean;
+}
+
+interface RuntimeFailureSummary {
+  tool: string;
+  type: string;
+  retryable: boolean;
+  occurredAt: string;
+  requestId?: string;
+  status?: number;
+}
+
+export class RuntimeObservability {
+  private readonly startedAt = Date.now();
+  private totalRequests = 0;
+  private successfulRequests = 0;
+  private failedRequests = 0;
+  private validationFailures = 0;
+  private mcpFailures = 0;
+  private internalFailures = 0;
+  private graphqlFailures = 0;
+  private authFailures = 0;
+  private permissionFailures = 0;
+  private capabilityFailures = 0;
+  private retryableFailures = 0;
+  private authRefreshFailures = 0;
+  private lastFailure?: RuntimeFailureSummary;
+
+  constructor(
+    private readonly capabilities: RuntimeCapabilities,
+    private readonly getActiveStreamSessions: () => number
+  ) {}
+
+  recordResponse(
+    tool: string,
+    response: BaseToolResponse,
+    durationMs: number
+  ): void {
+    this.recordTelemetry(this.buildTelemetryFromResponse(tool, response, durationMs));
+  }
+
+  recordError(
+    tool: string,
+    error: unknown,
+    durationMs: number
+  ): void {
+    this.recordTelemetry(this.buildTelemetryFromError(tool, error, durationMs));
+  }
+
+  createDiagnosticsSnapshot(
+    context: RuntimeDiagnosticsContext
+  ): Record<string, unknown> {
+    return {
+      server: this.capabilities.server,
+      runtime: this.capabilities.runtime,
+      transport: this.capabilities.transport,
+      authScope: this.capabilities.authScope,
+      endpoint: this.capabilities.endpoint,
+      uptimeMs: Math.max(Date.now() - this.startedAt, 0),
+      auth: {
+        startupMode: context.startupSource ? 'api-key-env' : 'tool-driven',
+        startupSource: context.startupSource ?? null,
+        dualEnvDetected: context.hasPrimaryEnv && context.hasAliasEnv,
+        stdioAuthenticated: this.capabilities.transport === 'stdio'
+          ? context.stdioAuthenticated
+          : undefined,
+      },
+      sessions: {
+        activeStreamSessions: this.getActiveStreamSessions(),
+      },
+      requests: {
+        total: this.totalRequests,
+        successful: this.successfulRequests,
+        failed: this.failedRequests,
+      },
+      failures: {
+        validation: this.validationFailures,
+        mcp: this.mcpFailures,
+        internal: this.internalFailures,
+        graphql: this.graphqlFailures,
+        auth: this.authFailures,
+        permission: this.permissionFailures,
+        capability: this.capabilityFailures,
+        retryable: this.retryableFailures,
+        authRefresh: this.authRefreshFailures,
+      },
+      lastFailure: this.lastFailure ?? null,
+    };
+  }
+
+  private buildTelemetryFromResponse(
+    tool: string,
+    response: BaseToolResponse,
+    durationMs: number
+  ): RuntimeTelemetryRecord {
+    const structuredContent = this.asRecord(response.structuredContent);
+    const error = this.asRecord(structuredContent?.error);
+    const graphql = this.asRecord(error?.graphql) ?? this.asRecord(structuredContent?.graphql);
+    const retryable = this.readBoolean(error?.retryable) ?? this.readBoolean(graphql?.retryable);
+    const upstreamRequestId = this.readString(graphql?.requestId);
+    const upstreamStatus = this.readNumber(graphql?.status);
+    const errorMessage = this.readString(error?.message)
+      ?? this.readString(response.content[0]?.text);
+
+    return {
+      event: 'mcp_tool_request',
+      tool,
+      transport: this.capabilities.transport,
+      authScope: this.capabilities.authScope,
+      durationMs,
+      outcome: response.isError === true || error ? 'error' : 'success',
+      errorType: this.readString(error?.type),
+      retryable,
+      upstreamRequestId,
+      upstreamStatus,
+      authRefreshFailure: this.isAuthRefreshFailure(errorMessage),
+    };
+  }
+
+  private buildTelemetryFromError(
+    tool: string,
+    error: unknown,
+    durationMs: number
+  ): RuntimeTelemetryRecord {
+    return {
+      event: 'mcp_tool_request',
+      tool,
+      transport: this.capabilities.transport,
+      authScope: this.capabilities.authScope,
+      durationMs,
+      outcome: 'error',
+      errorType: error instanceof McpError ? 'mcp' : 'internal',
+      retryable: false,
+      authRefreshFailure: error instanceof McpError && this.isAuthRefreshFailure(error.message),
+    };
+  }
+
+  private recordTelemetry(record: RuntimeTelemetryRecord): void {
+    this.totalRequests += 1;
+
+    if (record.outcome === 'success') {
+      this.successfulRequests += 1;
+    } else {
+      this.failedRequests += 1;
+      this.incrementFailureCounter(record.errorType);
+
+      if (record.retryable) {
+        this.retryableFailures += 1;
+      }
+
+      if (record.authRefreshFailure) {
+        this.authRefreshFailures += 1;
+      }
+
+      this.lastFailure = {
+        tool: record.tool,
+        type: record.errorType ?? 'unknown',
+        retryable: record.retryable ?? false,
+        occurredAt: new Date().toISOString(),
+        requestId: record.upstreamRequestId,
+        status: record.upstreamStatus,
+      };
+    }
+
+    console.error(JSON.stringify(this.compactRecord(record)));
+  }
+
+  private incrementFailureCounter(errorType?: string): void {
+    switch (errorType) {
+      case 'validation':
+        this.validationFailures += 1;
+        break;
+      case 'mcp':
+        this.mcpFailures += 1;
+        break;
+      case 'graphql':
+        this.graphqlFailures += 1;
+        break;
+      case 'auth':
+        this.authFailures += 1;
+        break;
+      case 'permission':
+        this.permissionFailures += 1;
+        break;
+      case 'capability':
+        this.capabilityFailures += 1;
+        break;
+      default:
+        this.internalFailures += 1;
+        break;
+    }
+  }
+
+  private isAuthRefreshFailure(message?: string): boolean {
+    return typeof message === 'string'
+      && message.toLowerCase().includes('token refresh failed');
+  }
+
+  private compactRecord(record: RuntimeTelemetryRecord): RuntimeTelemetryRecord {
+    return Object.fromEntries(
+      Object.entries(record).filter(([key, value]) =>
+        value !== undefined && !(key === 'authRefreshFailure' && value === false)
+      )
+    ) as RuntimeTelemetryRecord;
+  }
+
+  private asRecord(value: unknown): Record<string, unknown> | undefined {
+    return typeof value === 'object' && value !== null && !Array.isArray(value)
+      ? value as Record<string, unknown>
+      : undefined;
+  }
+
+  private readBoolean(value: unknown): boolean | undefined {
+    return typeof value === 'boolean' ? value : undefined;
+  }
+
+  private readNumber(value: unknown): number | undefined {
+    return typeof value === 'number' && Number.isFinite(value) ? value : undefined;
+  }
+
+  private readString(value: unknown): string | undefined {
+    return typeof value === 'string' && value.length > 0 ? value : undefined;
+  }
+}
diff --git a/src/core/server-build.ts b/src/core/server-build.ts
new file mode 100644
index 0000000..46b0ef0
--- /dev/null
+++ b/src/core/server-build.ts
@@ -0,0 +1,97 @@
+import { existsSync, readFileSync } from 'node:fs';
+import { dirname, resolve } from 'node:path';
+
+interface PackageManifest {
+  name?: string;
+  version?: string;
+}
+
+export interface ServerBuildInfo {
+  name: string;
+  version: string;
+  commitSha: string | null;
+}
+
+export interface ServerBuildInfoOptions {
+  buildCommitSha?: string | null;
+}
+
+let cachedPackageManifest: Required<Pick<PackageManifest, 'name' | 'version'>> | null = null;
+let cachedPackageManifestPath: string | null = null;
+
+function getPackageManifestPath(): string {
+  if (cachedPackageManifestPath) {
+    return cachedPackageManifestPath;
+  }
+
+  const candidates = [
+    process.argv[1]
+      ? resolve(dirname(process.argv[1]), '..', 'package.json')
+      : null,
+    resolve(process.cwd(), 'package.json'),
+  ];
+
+  const manifestPath = candidates.find(
+    (candidate): candidate is string => typeof candidate === 'string' && existsSync(candidate)
+  );
+
+  if (!manifestPath) {
+    throw new Error('Unable to locate package.json for server build metadata.');
+  }
+
+  cachedPackageManifestPath = manifestPath;
+  return manifestPath;
+}
+
+function getPackageManifest(): Required<Pick<PackageManifest, 'name' | 'version'>> {
+  if (cachedPackageManifest) {
+    return cachedPackageManifest;
+  }
+
+  const manifest = JSON.parse(readFileSync(getPackageManifestPath(), 'utf8')) as PackageManifest;
+
+  if (typeof manifest.name !== 'string' || manifest.name.length === 0) {
+    throw new Error('package.json is missing a valid name for server build metadata.');
+  }
+
+  if (typeof manifest.version !== 'string' || manifest.version.length === 0) {
+    throw new Error('package.json is missing a valid version for server build metadata.');
+  }
+
+  cachedPackageManifest = {
+    name: manifest.name,
+    version: manifest.version,
+  };
+
+  return cachedPackageManifest;
+}
+
+function resolveBuildCommit(buildCommitSha?: string | null): string | null {
+  if (buildCommitSha !== undefined) {
+    return typeof buildCommitSha === 'string' && buildCommitSha.length > 0
+      ? buildCommitSha
+      : null;
+  }
+
+  const envCommit = process.env.LINEAR_MCP_BUILD_SHA ?? process.env.GITHUB_SHA;
+
+  return typeof envCommit === 'string' && envCommit.length > 0
+    ? envCommit
+    : null;
+}
+
+export function getServerBuildInfo(options: ServerBuildInfoOptions = {}): ServerBuildInfo {
+  const manifest = getPackageManifest();
+
+  return {
+    name: manifest.name,
+    version: manifest.version,
+    commitSha: resolveBuildCommit(options.buildCommitSha),
+  };
+}
+
+export function formatServerBuildInfo(buildInfo: ServerBuildInfo): string {
+  return buildInfo.commitSha
+    ? `${buildInfo.name}@${buildInfo.version} (commit ${buildInfo.commitSha})`
+    : `${buildInfo.name}@${buildInfo.version}`;
+}
diff --git a/src/core/types/tool.types.ts b/src/core/types/tool.types.ts
index 141918f..f86c899 100644
--- a/src/core/types/tool.types.ts
+++ b/src/core/types/tool.types.ts
@@ -1,719 +1,1155 @@
-/**
- * This file contains the schema definitions for all MCP tools exposed by the Linear server.
- * These schemas define the input parameters and validation rules for each tool.
- */
+import { RuntimeCapabilities, getRuntimeCapabilities } from '../capabilities.js';
+import {
+  AGENT_FLEXIBLE_ARRAY_MAX_ITEMS,
+  AGENT_FLEXIBLE_MAX_DEPTH,
+  AGENT_FLEXIBLE_OBJECT_MAX_PROPERTIES,
+  AGENT_FLEXIBLE_STRING_MAX_LENGTH,
+} from '../../features/agents/types/agent.types.js';
 
-export const toolSchemas = {
-  linear_auth: {
-    name: 'linear_auth',
-    description: 'Initialize OAuth flow with Linear',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        clientId: {
-          type: 'string',
-          description: 'Linear OAuth client ID',
-        },
-        clientSecret: {
-          type: 'string',
-          description: 'Linear OAuth client secret',
-        },
-        redirectUri: {
-          type: 'string',
-          description: 'OAuth redirect URI',
-        },
-      },
-      required: ['clientId', 'clientSecret', 'redirectUri'],
-    },
-  },
+type JsonSchema = Record<string, unknown>;
+type ToolSchema = {
+  name: string;
+  description: string;
+  inputSchema: JsonSchema;
+};
 
-  linear_auth_callback: {
-    name: 'linear_auth_callback',
-    description: 'Handle OAuth callback',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        code: {
-          type: 'string',
-          description: 'OAuth authorization code',
-        },
-      },
-      required: ['code'],
-    },
-  },
+const stringProp = (description: string, extras: JsonSchema = {}): JsonSchema => ({
+  type: 'string',
+  description,
+  ...extras,
+});
 
-  linear_create_issue: {
-    name: 'linear_create_issue',
-    description: 'Create a new issue in Linear',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        title: {
-          type: 'string',
-          description: 'Issue title',
-        },
-        description: {
-          type: 'string',
-          description: 'Issue description',
-        },
-        teamId: {
-          type: 'string',
-          description: 'Team ID',
-        },
-        assigneeId: {
-          type: 'string',
-          description: 'Assignee user ID',
-          optional: true,
-        },
-        priority: {
-          type: 'number',
-          description: 'Issue priority (0-4)',
-          optional: true,
-        },
-        estimate: {
-          type: 'number',
-          description: 'Issue estimate points (typically 1, 2, 3, 5, 8, etc.)',
-          optional: true,
-        },
-        projectId: {
-          type: 'string',
-          description: 'Project ID',
-          optional: true,
-        },
-        createAsUser: {
-          type: 'string',
-          description: 'Name to display for the created issue',
-          optional: true,
-        },
-        displayIconUrl: {
-          type: 'string',
-          description: 'URL of the avatar to display',
-          optional: true,
-        },
-      },
-      required: ['title', 'description', 'teamId'],
-    },
-  },
+const nullableStringProp = (description: string, extras: JsonSchema = {}): JsonSchema => ({
+  type: ['string', 'null'],
+  description,
+  ...extras,
+});
 
-  linear_create_project_with_issues: {
-    name: 'linear_create_project_with_issues',
-    description: 'Create a new project with associated issues. Note: Project requires teamIds (array) not teamId (single value).',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        project: {
-          type: 'object',
-          properties: {
-            name: {
-              type: 'string',
-              description: 'Project name',
-            },
-            description: {
-              type: 'string',
-              description: 'Project description (optional)',
-            },
-            teamIds: {
-              type: 'array',
-              items: {
-                type: 'string',
-              },
-              description: 'Array of team IDs this project belongs to (Required). Use linear_get_teams to get available team IDs.',
-              minItems: 1
-            },
-          },
-          required: ['name', 'teamIds'],
-        },
-        issues: {
-          type: 'array',
-          items: {
-            type: 'object',
-            properties: {
-              title: {
-                type: 'string',
-                description: 'Issue title',
-              },
-              description: {
-                type: 'string',
-                description: 'Issue description',
-              },
-              teamId: {
-                type: 'string',
-                description: 'Team ID (must match one of the project teamIds)',
-              },
-            },
-            required: ['title', 'description', 'teamId'],
-          },
-          description: 'List of issues to create with this project',
-        },
+const numberProp = (description: string, extras: JsonSchema = {}): JsonSchema => ({
+  type: 'number',
+  description,
+  ...extras,
+});
+
+const booleanProp = (description: string): JsonSchema => ({
+  type: 'boolean',
+  description,
+});
+
+const looseObjectProp = (description: string): JsonSchema => ({
+  type: 'object',
+  description,
+  additionalProperties: true,
+});
+
+const agentFlexibleValueSchemaCache = new Map<number, JsonSchema>();
+const agentFlexibleObjectSchemaCache = new Map<number, JsonSchema>();
+const agentFlexibleArraySchemaCache = new Map<number, JsonSchema>();
+
+const createAgentFlexibleValueSchema = (remainingDepth: number): JsonSchema => {
+  const cached = agentFlexibleValueSchemaCache.get(remainingDepth);
+  if (cached) {
+    return cached;
+  }
+
+  const schema: JsonSchema = {
+    anyOf: [
+      {
+        type: 'string',
+        maxLength: AGENT_FLEXIBLE_STRING_MAX_LENGTH,
       },
-      required: ['project', 'issues'],
-    },
-    examples: [
       {
-        description: "Create a project with a single team and issue",
-        value: {
-          project: {
-            name: "Q1 Planning",
-            description: "Q1 2025 Planning Project",
-            teamIds: ["team-id-1"]
-          },
-          issues: [
-            {
-              title: "Project Setup",
-              description: "Initial project setup tasks",
-              teamId: "team-id-1"
-            }
-          ]
-        }
+        type: 'number',
       },
       {
-        description: "Create a project with multiple teams",
-        value: {
-          project: {
-            name: "Cross-team Initiative",
-            description: "Project spanning multiple teams",
-            teamIds: ["team-id-1", "team-id-2"]
-          },
-          issues: [
-            {
-              title: "Team 1 Tasks",
-              description: "Tasks for team 1",
-              teamId: "team-id-1"
-            },
-            {
-              title: "Team 2 Tasks",
-              description: "Tasks for team 2",
-              teamId: "team-id-2"
-            }
-          ]
-        }
-      }
-    ]
-  },
-
-  linear_bulk_update_issues: {
-    name: 'linear_bulk_update_issues',
-    description: 'Update multiple issues at once',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        issueIds: {
-          type: 'array',
-          items: {
-            type: 'string',
-          },
-          description: 'List of issue IDs to update',
-        },
-        update: {
-          type: 'object',
-          properties: {
-            stateId: {
-              type: 'string',
-              description: 'New state ID',
-              optional: true,
-            },
-            assigneeId: {
-              type: 'string',
-              description: 'New assignee ID',
-              optional: true,
-            },
-            priority: {
-              type: 'number',
-              description: 'New priority (0-4)',
-              optional: true,
-            },
-            estimate: {
-              type: 'number',
-              description: 'Issue estimate points (typically 1, 2, 3, 5, 8, etc.)',
-              optional: true,
-            },
-          },
-        },
+        type: 'boolean',
       },
-      required: ['issueIds', 'update'],
-    },
-  },
-
-  linear_search_issues: {
-    name: 'linear_search_issues',
-    description: 'Search for issues with filtering and pagination',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        query: {
-          type: 'string',
-          description: 'Search query string',
-          optional: true,
-        },
-        teamIds: {
-          type: 'array',
-          items: {
-            type: 'string',
-          },
-          description: 'Filter by team IDs',
-          optional: true,
-        },
-        assigneeIds: {
-          type: 'array',
-          items: {
-            type: 'string',
-          },
-          description: 'Filter by assignee IDs',
-          optional: true,
-        },
-        states: {
-          type: 'array',
-          items: {
-            type: 'string',
-          },
-          description: 'Filter by state names',
-          optional: true,
-        },
-        priority: {
-          type: 'number',
-          description: 'Filter by priority (0-4)',
-          optional: true,
-        },
-        first: {
-          type: 'number',
-          description: 'Number of issues to return (default: 50)',
-          optional: true,
-        },
-        after: {
-          type: 'string',
-          description: 'Cursor for pagination',
-          optional: true,
-        },
-        orderBy: {
-          type: 'string',
-          description: 'Field to order by (default: updatedAt)',
-          optional: true,
-        },
+      {
+        type: 'null',
       },
-    },
-  },
+    ],
+  };
 
-  linear_get_teams: {
-    name: 'linear_get_teams',
-    description: 'Get all teams with their states and labels',
-    inputSchema: {
-      type: 'object',
-      properties: {},
-    },
-  },
+  if (remainingDepth > 0) {
+    (schema.anyOf as JsonSchema[]).push(
+      createAgentFlexibleObjectSchema(remainingDepth - 1),
+      createAgentFlexibleArraySchema(remainingDepth - 1)
+    );
+  }
 
-  linear_get_user: {
-    name: 'linear_get_user',
-    description: 'Get current user information',
-    inputSchema: {
-      type: 'object',
-      properties: {},
-    },
-  },
+  agentFlexibleValueSchemaCache.set(remainingDepth, schema);
+  return schema;
+};
 
-  linear_delete_issue: {
-    name: 'linear_delete_issue',
-    description: 'Delete an issue',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        id: {
-          type: 'string',
-          description: 'Issue identifier (e.g., ENG-123)',
-        },
-      },
-      required: ['id'],
-    },
-  },
+const createAgentFlexibleObjectSchema = (remainingDepth: number): JsonSchema => {
+  const cached = agentFlexibleObjectSchemaCache.get(remainingDepth);
+  if (cached) {
+    return cached;
+  }
 
-  linear_delete_issues: {
-    name: 'linear_delete_issues',
-    description: 'Delete multiple issues',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        ids: {
-          type: 'array',
-          items: {
-            type: 'string',
-          },
-          description: 'List of issue identifiers to delete',
-        },
-      },
-      required: ['ids'],
-    },
-  },
+  const schema: JsonSchema = {
+    type: 'object',
+    maxProperties: AGENT_FLEXIBLE_OBJECT_MAX_PROPERTIES,
+    additionalProperties: createAgentFlexibleValueSchema(remainingDepth),
+  };
 
-  linear_get_project: {
-    name: 'linear_get_project',
-    description: 'Get project information',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        id: {
-          type: 'string',
-          description: 'Project identifier',
-        },
-      },
-      required: ['id'],
-    },
-  },
+  agentFlexibleObjectSchemaCache.set(remainingDepth, schema);
+  return schema;
+};
 
-  linear_search_projects: {
-    name: 'linear_search_projects',
-    description: 'Search for projects by name',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        name: {
-          type: 'string',
-          description: 'Project name to search for (exact match)',
-        },
-      },
-      required: ['name'],
-    },
-  },
+const createAgentFlexibleArraySchema = (remainingDepth: number): JsonSchema => {
+  const cached = agentFlexibleArraySchemaCache.get(remainingDepth);
+  if (cached) {
+    return cached;
+  }
 
-  linear_create_issues: {
-    name: 'linear_create_issues',
-    description: 'Create multiple issues at once',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        issues: {
-          type: 'array',
-          items: {
-            type: 'object',
-            properties: {
-              title: {
-                type: 'string',
-                description: 'Issue title',
-              },
-              description: {
-                type: 'string',
-                description: 'Issue description',
-              },
-              teamId: {
-                type: 'string',
-                description: 'Team ID',
-              },
-              assigneeId: {
-                type: 'string',
-                description: 'Assignee user ID',
-                optional: true,
-              },
-              priority: {
-                type: 'number',
-                description: 'Issue priority (0-4)',
-                optional: true,
-              },
-              projectId: {
-                type: 'string',
-                description: 'Project ID',
-                optional: true,
-              },
-              estimate: {
-                type: 'number',
-                description: 'Issue estimate points (typically 1, 2, 3, 5, 8, etc.)',
-                optional: true,
-              },
-              labelIds: {
-                type: 'array',
-                items: {
-                  type: 'string',
-                },
-                description: 'Label IDs to apply',
-                optional: true,
-              }
-            },
-            required: ['title', 'description', 'teamId'],
-          },
-          description: 'List of issues to create',
-        },
-      },
-      required: ['issues'],
-    },
-  },
+  const schema: JsonSchema = {
+    type: 'array',
+    maxItems: AGENT_FLEXIBLE_ARRAY_MAX_ITEMS,
+    items: createAgentFlexibleValueSchema(remainingDepth),
+  };
 
-  linear_get_issue_comments: {
-    name: 'linear_get_issue_comments',
-    description: 'Get comments for a specific issue, including threaded replies',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        issueId: {
-          type: 'string',
-          description: 'Issue ID to get comments for',
-        },
-        first: {
-          type: 'number',
-          description: 'Number of comments to return (default: 50)',
-          optional: true,
-        },
-        after: {
-          type: 'string',
-          description: 'Cursor for pagination',
-          optional: true,
-        },
-        includeArchived: {
-          type: 'boolean',
-          description: 'Include archived comments (default: false)',
-          optional: true,
-        },
-      },
-      required: ['issueId'],
-    },
-  },
+  agentFlexibleArraySchemaCache.set(remainingDepth, schema);
+  return schema;
+};
 
-  linear_create_comment: {
-    name: 'linear_create_comment',
-    description: 'Create a new comment on an issue or reply to an existing comment',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        body: {
-          type: 'string',
-          description: 'Comment content in markdown format',
-        },
-        issueId: {
-          type: 'string',
-          description: 'Issue ID to comment on',
-        },
-        parentCommentId: {
-          type: 'string',
-          description: 'Parent comment ID for threaded replies (optional)',
-          optional: true,
-        },
-        createAsUser: {
-          type: 'string',
-          description: 'Name to display for the comment creator (OAuth apps only)',
-          optional: true,
-        },
-        displayIconUrl: {
-          type: 'string',
-          description: 'URL of the avatar to display (OAuth apps only)',
-          optional: true,
-        },
-      },
-      required: ['body', 'issueId'],
-    },
-  },
+const boundedFlexibleObjectProp = (description: string): JsonSchema => ({
+  ...createAgentFlexibleObjectSchema(AGENT_FLEXIBLE_MAX_DEPTH - 1),
+  description,
+});
 
-  linear_create_project_milestone: {
-    name: 'linear_create_project_milestone',
-    description: 'Create a new project milestone in Linear',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        name: {
-          type: 'string',
-          description: 'The name of the project milestone',
-        },
-        projectId: {
-          type: 'string',
-          description: 'The ID of the project this milestone belongs to',
-        },
-        description: {
-          type: 'string',
-          description: 'The description of the project milestone in markdown format',
-          optional: true,
-        },
-        targetDate: {
-          type: 'string',
-          description: 'The planned target date of the project milestone (ISO 8601 format)',
-          optional: true,
-        },
-        sortOrder: {
-          type: 'number',
-          description: 'The sort order for the project milestone within a project',
-          optional: true,
-        },
-      },
-      required: ['name', 'projectId'],
-    },
-  },
+const arrayProp = (
+  description: string,
+  items: JsonSchema,
+  extras: JsonSchema = {}
+): JsonSchema => ({
+  type: 'array',
+  items,
+  description,
+  ...extras,
+});
 
-  linear_update_project_milestone: {
-    name: 'linear_update_project_milestone',
-    description: 'Update an existing project milestone',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        id: {
-          type: 'string',
-          description: 'The ID of the project milestone to update',
-        },
-        name: {
-          type: 'string',
-          description: 'The name of the project milestone',
-          optional: true,
-        },
-        description: {
-          type: 'string',
-          description: 'The description of the project milestone in markdown format',
-          optional: true,
-        },
-        targetDate: {
-          type: 'string',
-          description: 'The planned target date of the project milestone (ISO 8601 format)',
-          optional: true,
-        },
-        projectId: {
-          type: 'string',
-          description: 'The ID of the project this milestone belongs to',
-          optional: true,
-        },
-        sortOrder: {
-          type: 'number',
-          description: 'The sort order for the project milestone within a project',
-          optional: true,
-        },
-      },
-      required: ['id'],
-    },
-  },
+const objectSchema = (
+  properties: Record<string, JsonSchema>,
+  required: string[] = [],
+  additionalProperties: boolean = false
+): JsonSchema => ({
+  type: 'object',
+  properties,
+  additionalProperties,
+  ...(required.length > 0 ? { required } : {}),
+});
 
-  linear_delete_project_milestone: {
-    name: 'linear_delete_project_milestone',
-    description: 'Delete a project milestone',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        id: {
-          type: 'string',
-          description: 'The ID of the project milestone to delete',
-        },
-      },
-      required: ['id'],
-    },
+const requireAtLeastOnePropertyRule = (propertyNames: string[]): JsonSchema => ({
+  not: {
+    properties: Object.fromEntries(propertyNames.map(propertyName => [propertyName, false])),
   },
+});
 
-  linear_get_project_milestone: {
-    name: 'linear_get_project_milestone',
-    description: 'Get information about a specific project milestone',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        id: {
-          type: 'string',
-          description: 'The ID of the project milestone to retrieve',
-        },
-      },
-      required: ['id'],
-    },
+const forbidPropertyCombinationRule = (
+  propertyNames: string[],
+  extras: JsonSchema = {}
+): JsonSchema => ({
+  not: {
+    required: propertyNames,
+    ...extras,
   },
+});
 
-  linear_search_project_milestones: {
-    name: 'linear_search_project_milestones',
-    description: 'Search for project milestones with filtering and pagination',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        name: {
-          type: 'string',
-          description: 'Filter by milestone name (exact match)',
-          optional: true,
-        },
-        projectId: {
-          type: 'string',
-          description: 'Filter by project ID',
-          optional: true,
-        },
-        targetDate: {
-          type: 'string',
-          description: 'Filter by target date (ISO 8601 format)',
-          optional: true,
-        },
-        first: {
-          type: 'number',
-          description: 'Number of milestones to return (default: 50)',
-          optional: true,
-        },
-        after: {
-          type: 'string',
-          description: 'Cursor for pagination',
-          optional: true,
-        },
-        orderBy: {
-          type: 'string',
-          description: 'Field to order by (default: updatedAt)',
-          optional: true,
-        },
-      },
-    },
+const tool = (
+  name: string,
+  description: string,
+  properties: Record<string, JsonSchema> = {},
+  required: string[] = [],
+  additionalProperties: boolean = false,
+  extras: JsonSchema = {}
+): ToolSchema => ({
+  name,
+  description,
+  inputSchema: {
+    ...objectSchema(properties, required, additionalProperties),
+    ...extras,
   },
+});
+
+const pageFields = {
+  first: numberProp('Number of results to return'),
+  after: stringProp('Pagination cursor'),
+};
+
+const filterField = {
+  filter: looseObjectProp('Filter object using Linear list semantics'),
+};
+
+const issueInputProperties = {
+  title: stringProp('Issue title'),
+  description: stringProp('Issue description'),
+  teamId: stringProp('Team ID'),
+  assigneeId: stringProp('Assignee user ID'),
+  priority: numberProp('Issue priority (0-4)'),
+  estimate: numberProp('Issue estimate points'),
+  projectId: stringProp('Project ID'),
+  projectMilestoneId: stringProp('Project milestone ID'),
+  dueDate: stringProp('Issue due date in YYYY-MM-DD format'),
+  cycleId: stringProp('Cycle ID'),
+  labelIds: arrayProp('Label IDs to attach', { type: 'string' }),
+  parentId: stringProp('Parent issue ID for hierarchy workflows; separate from issue relations'),
+  subscriberIds: arrayProp('Subscriber user IDs', { type: 'string' }),
+  stateId: stringProp('Workflow state ID'),
+  delegateId: stringProp('Delegate user ID'),
+  templateId: stringProp('Issue template ID'),
+  createAsUser: stringProp('OAuth display name for the created issue'),
+  displayIconUrl: stringProp('OAuth display icon URL'),
+};
 
-  linear_get_project_milestones: {
-    name: 'linear_get_project_milestones',
-    description: 'Get all milestones for a specific project',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        projectId: {
-          type: 'string',
-          description: 'The ID of the project to get milestones for',
-        },
-        first: {
-          type: 'number',
-          description: 'Number of milestones to return (default: 50)',
-          optional: true,
-        },
-        after: {
-          type: 'string',
-          description: 'Cursor for pagination',
-          optional: true,
-        },
-        orderBy: {
-          type: 'string',
-          description: 'Field to order by (default: sortOrder)',
-          optional: true,
-        },
+const updateIssueProperties = {
+  title: stringProp('Updated issue title'),
+  description: stringProp('Updated issue description'),
+  assigneeId: stringProp('Updated assignee user ID'),
+  priority: numberProp('Updated issue priority (0-4)'),
+  estimate: numberProp('Updated issue estimate points'),
+  projectId: nullableStringProp('Updated project ID. Pass null to clear the existing project assignment.'),
+  projectMilestoneId: stringProp('Updated project milestone ID'),
+  dueDate: stringProp('Updated due date in YYYY-MM-DD format'),
+  cycleId: stringProp('Updated cycle ID'),
+  labelIds: arrayProp('Replacement label IDs', { type: 'string' }),
+  addedLabelIds: arrayProp('Label IDs to add', { type: 'string' }),
+  removedLabelIds: arrayProp('Label IDs to remove', { type: 'string' }),
+  parentId: stringProp('Updated parent issue ID for hierarchy workflows; separate from issue relations'),
+  subscriberIds: arrayProp('Replacement subscriber user IDs', { type: 'string' }),
+  stateId: stringProp('Updated workflow state ID'),
+  delegateId: stringProp('Updated delegate user ID'),
+  templateId: stringProp('Updated issue template ID'),
+  teamId: stringProp('Updated team ID'),
+  trashed: booleanProp('Whether the issue is trashed'),
+};
+
+const projectProperties = {
+  name: stringProp('Project name'),
+  description: stringProp('Project description'),
+  content: stringProp('Project markdown content'),
+  teamIds: arrayProp('Team IDs associated with the project', { type: 'string' }, { minItems: 1 }),
+  initiativeId: stringProp('Initiative ID associated with the project'),
+  leadId: stringProp('Project lead user ID'),
+  memberIds: arrayProp('Project member user IDs', { type: 'string' }),
+  startDate: stringProp('Project start date in YYYY-MM-DD format'),
+  targetDate: stringProp('Project target date in YYYY-MM-DD format'),
+  statusId: stringProp('Project status ID'),
+  priority: numberProp('Project priority'),
+  icon: stringProp('Project icon'),
+  color: stringProp('Project color'),
+  labelIds: arrayProp('Project label IDs', { type: 'string' }),
+  templateId: stringProp('Project template ID'),
+  useDefaultTemplate: booleanProp('Whether to use the default template'),
+};
+
+const projectUpdateProperties = {
+  body: stringProp('Project update body in markdown'),
+  bodyData: looseObjectProp('Structured project update body'),
+  health: stringProp('Project update health status'),
+  isDiffHidden: booleanProp('Whether project update diffs are hidden'),
+};
+
+const issueItemSchema = objectSchema(issueInputProperties, ['title', 'teamId']);
+const projectSchema = objectSchema(projectProperties, ['name', 'teamIds']);
+const projectUpdateSchema = objectSchema(projectUpdateProperties);
+const agentExternalUrlSchema = objectSchema(
+  {
+    label: stringProp('External URL label'),
+    url: stringProp('External URL'),
+  },
+  ['label', 'url']
+);
+const agentSessionUserStateSchema = objectSchema(
+  {
+    userId: stringProp('User ID'),
+    lastReadAt: stringProp('Last read timestamp'),
+  },
+  ['userId']
+);
+const issueStateConflictRule = forbidPropertyCombinationRule(
+  ['stateId', 'states'],
+  {
+    properties: {
+      states: {
+        type: 'array',
+        minItems: 1,
       },
-      required: ['projectId'],
     },
-  },
+  }
+);
+
+const commentPageFields = {
+  first: numberProp('Number of results to return'),
+  after: stringProp('Pagination cursor'),
+  last: numberProp('Number of results to return from the end'),
+  before: stringProp('Pagination cursor for the previous page'),
+};
 
-  linear_create_project_milestones: {
-    name: 'linear_create_project_milestones',
-    description: 'Create multiple project milestones at once',
-    inputSchema: {
-      type: 'object',
-      properties: {
-        projectId: {
-          type: 'string',
-          description: 'The ID of the project to create milestones for',
-        },
-        milestones: {
-          type: 'array',
-          items: {
-            type: 'object',
-            properties: {
-              name: {
-                type: 'string',
-                description: 'The name of the project milestone',
-              },
-              description: {
-                type: 'string',
-                description: 'The description of the project milestone in markdown format',
-                optional: true,
-              },
-              targetDate: {
-                type: 'string',
-                description: 'The planned target date of the project milestone (ISO 8601 format)',
-                optional: true,
-              },
-              sortOrder: {
-                type: 'number',
-                description: 'The sort order for the project milestone within a project',
-                optional: true,
-              },
-            },
-            required: ['name'],
+const commentCollectionFields = {
+  ...filterField,
+  ...commentPageFields,
+  includeArchived: booleanProp('Whether to include archived comments'),
+  orderBy: stringProp('Pagination order field'),
+};
+
+const commentCreateProperties = {
+  body: stringProp('Markdown comment body'),
+  issueId: stringProp('Issue ID or identifier'),
+  parentId: stringProp('Parent comment ID for threaded replies'),
+  bodyData: looseObjectProp('Structured comment body'),
+  quotedText: stringProp('Quoted source text'),
+  createAsUser: stringProp('OAuth display name for the comment'),
+  displayIconUrl: stringProp('OAuth display icon URL'),
+};
+
+const commentUpdateProperties = {
+  id: stringProp('Comment ID'),
+  body: stringProp('Updated markdown comment body'),
+  bodyData: looseObjectProp('Updated structured comment body'),
+  quotedText: stringProp('Updated quoted source text'),
+};
+
+const createCommentToolSchema = tool(
+  'linear_create_comment',
+  'Create a comment or threaded reply. Provide issueId for a top-level comment or parentId for a reply.',
+  commentCreateProperties,
+  ['body'],
+  false,
+  requireAtLeastOnePropertyRule(['issueId', 'parentId'])
+);
+
+const updateCommentToolSchema = tool(
+  'linear_update_comment',
+  'Update a comment. Provide at least one of body, bodyData, or quotedText.',
+  commentUpdateProperties,
+  ['id'],
+  false,
+  requireAtLeastOnePropertyRule(['body', 'bodyData', 'quotedText'])
+);
+
+const baseToolSchemas: Record<string, ToolSchema> = {
+  linear_auth: tool(
+    'linear_auth',
+    'Initialize OAuth flow with Linear',
+    {
+      clientId: stringProp('Linear OAuth client ID'),
+      clientSecret: stringProp('Linear OAuth client secret'),
+      redirectUri: stringProp('OAuth redirect URI'),
+    },
+    ['clientId', 'clientSecret', 'redirectUri']
+  ),
+  linear_auth_callback: tool(
+    'linear_auth_callback',
+    'Handle OAuth callback',
+    {
+      code: stringProp('OAuth authorization code'),
+      state: stringProp('OAuth state returned from linear_auth'),
+    },
+    ['code', 'state']
+  ),
+  linear_get_issue: tool(
+    'linear_get_issue',
+    'Get detailed issue information',
+    {
+      id: stringProp('Issue identifier or ID'),
+    },
+    ['id']
+  ),
+  linear_create_issue: tool(
+    'linear_create_issue',
+    'Create a new issue in Linear',
+    issueInputProperties,
+    ['title', 'teamId']
+  ),
+  linear_create_issues: tool(
+    'linear_create_issues',
+    'Create multiple issues at once',
+    {
+      issues: arrayProp('Issues to create', issueItemSchema, { minItems: 1 }),
+    },
+    ['issues']
+  ),
+  linear_bulk_update_issues: tool(
+    'linear_bulk_update_issues',
+    'Update multiple issues at once',
+    {
+      issueIds: arrayProp('Issue IDs to update', { type: 'string' }, { minItems: 1 }),
+      update: objectSchema(updateIssueProperties),
+    },
+    ['issueIds', 'update']
+  ),
+  linear_list_issues: tool(
+    'linear_list_issues',
+    'List issues using Linear filter and pagination semantics',
+    {
+      ...filterField,
+      teamId: stringProp('Filter by team ID'),
+      projectId: stringProp('Filter by project ID'),
+      assigneeId: stringProp('Filter by assignee user ID'),
+      stateId: stringProp('Filter by workflow state ID'),
+      states: arrayProp('Filter by workflow state names', { type: 'string' }),
+      priority: numberProp('Filter by priority (0-4)'),
+      cycleId: stringProp('Filter by cycle ID'),
+      ...pageFields,
+      orderBy: stringProp('Pagination order field'),
+    },
+    [],
+    false,
+    issueStateConflictRule
+  ),
+  linear_search_issues: tool(
+    'linear_search_issues',
+    'Search issues using Linear ranked search semantics',
+    {
+      query: stringProp('Text query to search for'),
+      teamId: stringProp('Optional team ID filter'),
+      projectId: stringProp('Optional project ID filter'),
+      assigneeId: stringProp('Optional assignee user ID filter'),
+      stateId: stringProp('Optional workflow state ID filter'),
+      states: arrayProp('Optional workflow state names filter', { type: 'string' }),
+      priority: numberProp('Optional priority filter'),
+      cycleId: stringProp('Optional cycle ID filter'),
+      ...pageFields,
+    },
+    ['query'],
+    false,
+    issueStateConflictRule
+  ),
+  linear_create_issue_relation: tool(
+    'linear_create_issue_relation',
+    'Create an issue relation',
+    {
+      issueId: stringProp('Source issue ID'),
+      relatedIssueId: stringProp('Related issue ID'),
+      type: stringProp('Issue relation type'),
+    },
+    ['issueId', 'relatedIssueId', 'type']
+  ),
+  linear_delete_issue_relation: tool(
+    'linear_delete_issue_relation',
+    'Delete an issue relation',
+    {
+      id: stringProp('Issue relation ID'),
+    },
+    ['id']
+  ),
+  linear_delete_issue: tool(
+    'linear_delete_issue',
+    'Delete an issue',
+    {
+      id: stringProp('Issue identifier or ID'),
+    },
+    ['id']
+  ),
+  linear_delete_issues: tool(
+    'linear_delete_issues',
+    'Delete multiple issues',
+    {
+      ids: arrayProp('Issue identifiers or IDs', { type: 'string' }, { minItems: 1 }),
+    },
+    ['ids']
+  ),
+  linear_create_project: tool(
+    'linear_create_project',
+    'Create a standalone project',
+    projectProperties,
+    ['name', 'teamIds']
+  ),
+  linear_update_project: tool(
+    'linear_update_project',
+    'Update a standalone project',
+    {
+      id: stringProp('Project ID'),
+      name: stringProp('Updated project name'),
+      description: stringProp('Updated project description'),
+      content: stringProp('Updated project markdown content'),
+      teamIds: arrayProp('Updated team IDs', { type: 'string' }, { minItems: 1 }),
+      initiativeId: nullableStringProp('Updated initiative ID. Pass null to clear the existing initiative association.'),
+      leadId: stringProp('Updated project lead user ID'),
+      memberIds: arrayProp('Updated project member user IDs', { type: 'string' }),
+      startDate: stringProp('Updated start date in YYYY-MM-DD format'),
+      targetDate: stringProp('Updated target date in YYYY-MM-DD format'),
+      statusId: stringProp('Updated project status ID'),
+      priority: numberProp('Updated project priority'),
+      icon: stringProp('Updated project icon'),
+      color: stringProp('Updated project color'),
+      labelIds: arrayProp('Updated project label IDs', { type: 'string' }),
+      trashed: booleanProp('Whether the project is trashed'),
+    },
+    ['id']
+  ),
+  linear_delete_project: tool(
+    'linear_delete_project',
+    'Delete a standalone project',
+    {
+      id: stringProp('Project ID'),
+    },
+    ['id']
+  ),
+  linear_create_project_with_issues: tool(
+    'linear_create_project_with_issues',
+    'Create a project together with associated issues',
+    {
+      project: projectSchema,
+      issues: arrayProp('Issues to create in the project', issueItemSchema),
+    },
+    ['project', 'issues']
+  ),
+  linear_get_project: tool(
+    'linear_get_project',
+    'Get project information',
+    {
+      id: stringProp('Project ID'),
+    },
+    ['id']
+  ),
+  linear_list_projects: tool(
+    'linear_list_projects',
+    'List projects using Linear filter and pagination semantics',
+    {
+      ...filterField,
+      teamId: stringProp('Filter by team ID'),
+      leadId: stringProp('Filter by lead user ID'),
+      statusId: stringProp('Filter by status ID'),
+      ...pageFields,
+      orderBy: stringProp('Pagination order field'),
+    }
+  ),
+  linear_search_projects: tool(
+    'linear_search_projects',
+    'Search projects using Linear ranked search semantics',
+    {
+      query: stringProp('Text query to search for'),
+      teamId: stringProp('Optional team ID filter'),
+      leadId: stringProp('Optional lead user ID filter'),
+      statusId: stringProp('Optional status ID filter'),
+      ...pageFields,
+    },
+    ['query']
+  ),
+  linear_create_project_update: tool(
+    'linear_create_project_update',
+    'Create a project update',
+    {
+      projectId: stringProp('Project ID'),
+      ...projectUpdateProperties,
+    },
+    ['projectId']
+  ),
+  linear_update_project_update: tool(
+    'linear_update_project_update',
+    'Update a project update',
+    {
+      id: stringProp('Project update ID'),
+      ...projectUpdateProperties,
+    },
+    ['id']
+  ),
+  linear_get_team: tool(
+    'linear_get_team',
+    'Get a specific team',
+    {
+      id: stringProp('Team ID'),
+    },
+    ['id']
+  ),
+  linear_get_teams: tool(
+    'linear_get_teams',
+    'List teams with optional filters',
+    {
+      ...filterField,
+      key: stringProp('Filter by team key'),
+      name: stringProp('Filter by team name'),
+      ...pageFields,
+    }
+  ),
+  linear_list_teams: tool(
+    'linear_list_teams',
+    'List teams with optional filters',
+    {
+      ...filterField,
+      key: stringProp('Filter by team key'),
+      name: stringProp('Filter by team name'),
+      ...pageFields,
+    }
+  ),
+  linear_list_workflow_states: tool(
+    'linear_list_workflow_states',
+    'List workflow states for a team or workspace',
+    {
+      teamId: stringProp('Optional team ID'),
+      ...pageFields,
+    }
+  ),
+  linear_list_labels: tool(
+    'linear_list_labels',
+    'List issue labels',
+    {
+      teamId: stringProp('Optional team ID'),
+      ...pageFields,
+    }
+  ),
+  linear_create_label: tool(
+    'linear_create_label',
+    'Create an issue label',
+    {
+      name: stringProp('Label name'),
+      color: stringProp('Label color'),
+      description: stringProp('Label description'),
+      teamId: stringProp('Team ID'),
+      parentId: stringProp('Parent label ID'),
+      isGroup: booleanProp('Whether the label is a group'),
+    },
+    ['name', 'teamId']
+  ),
+  linear_update_label: tool(
+    'linear_update_label',
+    'Update an issue label',
+    {
+      id: stringProp('Label ID'),
+      name: stringProp('Updated label name'),
+      color: stringProp('Updated label color'),
+      description: stringProp('Updated label description'),
+      parentId: stringProp('Updated parent label ID'),
+      retiredAt: stringProp('Retired timestamp'),
+      isGroup: booleanProp('Whether the label is a group'),
+    },
+    ['id']
+  ),
+  linear_delete_label: tool(
+    'linear_delete_label',
+    'Delete an issue label',
+    {
+      id: stringProp('Label ID'),
+    },
+    ['id']
+  ),
+  linear_get_user: tool(
+    'linear_get_user',
+    'Get the current user or a specific user',
+    {
+      id: stringProp('Optional user ID'),
+    }
+  ),
+  linear_list_users: tool(
+    'linear_list_users',
+    'List users with pagination',
+    {
+      ...filterField,
+      ...pageFields,
+      orderBy: stringProp('Pagination order field'),
+    }
+  ),
+  linear_search_users: tool(
+    'linear_search_users',
+    'Search users for assignment or mention workflows',
+    {
+      query: stringProp('Text query to search for'),
+      ...filterField,
+      ...pageFields,
+    },
+    ['query']
+  ),
+  linear_get_cycle: tool(
+    'linear_get_cycle',
+    'Get a cycle by identifier',
+    {
+      id: stringProp('Cycle ID'),
+    },
+    ['id']
+  ),
+  linear_list_cycles: tool(
+    'linear_list_cycles',
+    'List cycles for planning workflows',
+    {
+      ...filterField,
+      teamId: stringProp('Optional team ID'),
+      ...pageFields,
+    }
+  ),
+  linear_get_current_cycle: tool(
+    'linear_get_current_cycle',
+    'Get the current active cycle',
+    {
+      ...filterField,
+      teamId: stringProp('Optional team ID'),
+    }
+  ),
+  linear_get_attachment: tool(
+    'linear_get_attachment',
+    'Get attachment information',
+    {
+      id: stringProp('Attachment ID'),
+    },
+    ['id']
+  ),
+  linear_list_attachments: tool(
+    'linear_list_attachments',
+    'List attachments for an issue or workspace',
+    {
+      filter: looseObjectProp('Attachment filter object'),
+      issueId: stringProp('Optional issue ID to scope attachments'),
+      ...pageFields,
+    }
+  ),
+  linear_create_attachment: tool(
+    'linear_create_attachment',
+    'Create a URL-backed attachment for an issue',
+    {
+      commentBody: stringProp('Optional linked comment body'),
+      commentBodyData: looseObjectProp('Optional structured linked comment body'),
+      createAsUser: stringProp('OAuth display name for the attachment'),
+      groupBySource: booleanProp('Whether to group attachments by source'),
+      iconUrl: stringProp('Attachment icon URL'),
+      id: stringProp('Attachment ID'),
+      issueId: stringProp('Issue ID or issue identifier'),
+      metadata: looseObjectProp('Attachment metadata payload'),
+      subtitle: stringProp('Attachment subtitle'),
+      title: stringProp('Attachment title'),
+      url: stringProp('Attachment URL used for idempotent matching'),
+    },
+    ['issueId', 'title', 'url']
+  ),
+  linear_update_attachment: tool(
+    'linear_update_attachment',
+    'Update an attachment',
+    {
+      id: stringProp('Attachment ID'),
+      iconUrl: stringProp('Updated attachment icon URL'),
+      metadata: looseObjectProp('Updated attachment metadata payload'),
+      subtitle: stringProp('Updated attachment subtitle'),
+      title: stringProp('Updated attachment title'),
+    },
+    ['id', 'title']
+  ),
+  linear_delete_attachment: tool(
+    'linear_delete_attachment',
+    'Delete an attachment',
+    {
+      id: stringProp('Attachment ID'),
+    },
+    ['id']
+  ),
+  linear_get_webhook: tool(
+    'linear_get_webhook',
+    'Get a webhook registration',
+    {
+      id: stringProp('Webhook ID'),
+    },
+    ['id']
+  ),
+  linear_list_webhooks: tool(
+    'linear_list_webhooks',
+    'List webhook registrations',
+    {
+      teamId: stringProp('Optional team ID'),
+      ...pageFields,
+    }
+  ),
+  linear_create_webhook: tool(
+    'linear_create_webhook',
+    'Create a webhook registration',
+    {
+      allPublicTeams: booleanProp('Whether the webhook applies to all public teams'),
+      enabled: booleanProp('Whether the webhook is enabled'),
+      id: stringProp('Webhook ID'),
+      label: stringProp('Webhook label'),
+      resourceTypes: arrayProp('Resource types to subscribe to', { type: 'string' }, { minItems: 1 }),
+      secret: stringProp('Webhook signing secret'),
+      teamId: stringProp('Optional team ID or key'),
+      url: stringProp('Webhook delivery URL'),
+    },
+    ['resourceTypes', 'url']
+  ),
+  linear_delete_webhook: tool(
+    'linear_delete_webhook',
+    'Delete a webhook registration',
+    {
+      id: stringProp('Webhook ID'),
+    },
+    ['id']
+  ),
+  linear_get_initiative: tool(
+    'linear_get_initiative',
+    'Get an initiative',
+    {
+      id: stringProp('Initiative ID'),
+    },
+    ['id']
+  ),
+  linear_list_initiatives: tool(
+    'linear_list_initiatives',
+    'List initiatives',
+    {
+      filter: looseObjectProp('Initiative filter object'),
+      ...pageFields,
+    }
+  ),
+  linear_create_initiative: tool(
+    'linear_create_initiative',
+    'Create an initiative',
+    {
+      color: stringProp('Initiative color'),
+      content: stringProp('Initiative markdown content'),
+      description: stringProp('Initiative description'),
+      icon: stringProp('Initiative icon'),
+      id: stringProp('Initiative ID'),
+      name: stringProp('Initiative name'),
+      ownerId: stringProp('Initiative owner user ID'),
+      sortOrder: numberProp('Initiative sort order'),
+      status: stringProp('Initiative status'),
+      targetDate: stringProp('Initiative target date in YYYY-MM-DD format'),
+      targetDateResolution: stringProp('Initiative target date resolution'),
+    },
+    ['name']
+  ),
+  linear_update_initiative: tool(
+    'linear_update_initiative',
+    'Update an initiative',
+    {
+      id: stringProp('Initiative ID'),
+      color: stringProp('Updated initiative color'),
+      content: stringProp('Updated initiative markdown content'),
+      description: stringProp('Updated initiative description'),
+      frequencyResolution: stringProp('Update reminder frequency resolution'),
+      icon: stringProp('Updated initiative icon'),
+      name: stringProp('Updated initiative name'),
+      ownerId: stringProp('Updated initiative owner user ID'),
+      sortOrder: numberProp('Updated initiative sort order'),
+      status: stringProp('Updated initiative status'),
+      targetDate: stringProp('Updated target date in YYYY-MM-DD format'),
+      targetDateResolution: stringProp('Updated target date resolution'),
+      trashed: booleanProp('Whether the initiative is trashed'),
+      updateReminderFrequency: numberProp('Reminder frequency'),
+      updateReminderFrequencyInWeeks: numberProp('Reminder frequency in weeks'),
+      updateRemindersDay: stringProp('Reminder weekday'),
+      updateRemindersHour: numberProp('Reminder hour'),
+    },
+    ['id']
+  ),
+  linear_get_customer: tool(
+    'linear_get_customer',
+    'Get a customer record',
+    {
+      id: stringProp('Customer ID'),
+    },
+    ['id']
+  ),
+  linear_list_customers: tool(
+    'linear_list_customers',
+    'List customer records',
+    {
+      filter: looseObjectProp('Customer filter object'),
+      ...pageFields,
+    }
+  ),
+  linear_create_customer: tool(
+    'linear_create_customer',
+    'Create a customer record',
+    {
+      domains: arrayProp('Customer domains', { type: 'string' }),
+      externalIds: arrayProp('External customer IDs', { type: 'string' }),
+      id: stringProp('Customer ID'),
+      logoUrl: stringProp('Customer logo URL'),
+      mainSourceId: stringProp('Primary external source ID'),
+      name: stringProp('Customer name'),
+      ownerId: stringProp('Customer owner user ID'),
+      revenue: numberProp('Annual revenue'),
+      size: numberProp('Customer size'),
+      slackChannelId: stringProp('Slack channel ID'),
+      statusId: stringProp('Customer status ID'),
+      tierId: stringProp('Customer tier ID'),
+    },
+    ['name']
+  ),
+  linear_update_customer: tool(
+    'linear_update_customer',
+    'Update a customer record',
+    {
+      id: stringProp('Customer ID'),
+      domains: arrayProp('Updated customer domains', { type: 'string' }),
+      externalIds: arrayProp('Updated external customer IDs', { type: 'string' }),
+      logoUrl: stringProp('Updated customer logo URL'),
+      mainSourceId: stringProp('Updated primary external source ID'),
+      name: stringProp('Updated customer name'),
+      ownerId: stringProp('Updated customer owner user ID'),
+      revenue: numberProp('Updated annual revenue'),
+      size: numberProp('Updated customer size'),
+      slackChannelId: stringProp('Updated Slack channel ID'),
+      statusId: stringProp('Updated customer status ID'),
+      tierId: stringProp('Updated customer tier ID'),
+    },
+    ['id']
+  ),
+  linear_get_agent_session: tool(
+    'linear_get_agent_session',
+    'Get an agent session',
+    {
+      id: stringProp('Agent session ID'),
+    },
+    ['id']
+  ),
+  linear_list_agent_sessions: tool(
+    'linear_list_agent_sessions',
+    'List agent sessions',
+    {
+      ...pageFields,
+      orderBy: stringProp('Pagination order field'),
+    }
+  ),
+  linear_create_agent_session_on_issue: tool(
+    'linear_create_agent_session_on_issue',
+    'Create an agent session on an issue',
+    {
+      issueId: stringProp('Issue ID or issue identifier'),
+      externalLink: stringProp('External agent-hosted page URL'),
+      externalUrls: arrayProp(
+        'External resources associated with the session',
+        agentExternalUrlSchema
+      ),
+    },
+    ['issueId']
+  ),
+  linear_create_agent_session_on_comment: tool(
+    'linear_create_agent_session_on_comment',
+    'Create an agent session on a comment',
+    {
+      commentId: stringProp('Comment ID'),
+      externalLink: stringProp('External agent-hosted page URL'),
+      externalUrls: arrayProp(
+        'External resources associated with the session',
+        agentExternalUrlSchema
+      ),
+    },
+    ['commentId']
+  ),
+  linear_update_agent_session: tool(
+    'linear_update_agent_session',
+    'Update an agent session',
+    {
+      id: stringProp('Agent session ID'),
+      addedExternalUrls: arrayProp(
+        'External URLs to add to the session',
+        agentExternalUrlSchema
+      ),
+      dismissedAt: stringProp('Dismissed timestamp'),
+      externalLink: stringProp('Updated external agent-hosted page URL'),
+      externalUrls: arrayProp(
+        'Replacement external URLs for the session',
+        agentExternalUrlSchema
+      ),
+      plan: boundedFlexibleObjectProp('Dynamic agent execution plan'),
+      removedExternalUrls: arrayProp('External URLs to remove', { type: 'string' }),
+      userState: arrayProp('User-specific session state entries', agentSessionUserStateSchema),
+    },
+    ['id']
+  ),
+  linear_get_agent_activity: tool(
+    'linear_get_agent_activity',
+    'Get an agent activity',
+    {
+      id: stringProp('Agent activity ID'),
+    },
+    ['id']
+  ),
+  linear_list_agent_activities: tool(
+    'linear_list_agent_activities',
+    'List agent activities',
+    {
+      filter: boundedFlexibleObjectProp('Agent activity filter object'),
+      ...pageFields,
+      orderBy: stringProp('Pagination order field'),
+    }
+  ),
+  linear_create_agent_activity: tool(
+    'linear_create_agent_activity',
+    'Create an agent activity',
+    {
+      agentSessionId: stringProp('Agent session ID'),
+      content: boundedFlexibleObjectProp('Agent activity content payload'),
+      contextualMetadata: boundedFlexibleObjectProp('Contextual metadata'),
+      ephemeral: booleanProp('Whether the activity is ephemeral'),
+      id: stringProp('Agent activity ID'),
+      signal: stringProp('Agent activity signal'),
+      signalMetadata: boundedFlexibleObjectProp('Signal metadata'),
+    },
+    ['agentSessionId', 'content']
+  ),
+  linear_get_capabilities: tool(
+    'linear_get_capabilities',
+    'Report runtime capabilities, server build provenance, and advanced feature availability'
+  ),
+  linear_get_runtime_diagnostics: tool(
+    'linear_get_runtime_diagnostics',
+    'Report live runtime diagnostics, low-cardinality request counters, and active session state'
+  ),
+  linear_get_comment: tool(
+    'linear_get_comment',
+    'Get a single comment by ID',
+    {
+      id: stringProp('Comment ID'),
+    },
+    ['id']
+  ),
+  linear_list_comments: tool(
+    'linear_list_comments',
+    'List comments using Linear filter and pagination semantics',
+    commentCollectionFields
+  ),
+  linear_get_issue_comments: tool(
+    'linear_get_issue_comments',
+    'Get comments for a specific issue using native collection controls',
+    {
+      issueId: stringProp('Issue ID or identifier'),
+      ...commentCollectionFields,
+    },
+    ['issueId']
+  ),
+  linear_create_comment: createCommentToolSchema,
+  linear_update_comment: updateCommentToolSchema,
+  linear_delete_comment: tool(
+    'linear_delete_comment',
+    'Delete a comment',
+    {
+      id: stringProp('Comment ID'),
+    },
+    ['id']
+  ),
+  linear_resolve_comment: tool(
+    'linear_resolve_comment',
+    'Resolve a comment thread',
+    {
+      id: stringProp('Comment ID'),
+      resolvingCommentId: stringProp('Reply comment ID that resolves the thread'),
+    },
+    ['id']
+  ),
+  linear_unresolve_comment: tool(
+    'linear_unresolve_comment',
+    'Unresolve a comment thread',
+    {
+      id: stringProp('Comment ID'),
+    },
+    ['id']
+  ),
+  linear_create_project_milestone: tool(
+    'linear_create_project_milestone',
+    'Create a project milestone',
+    {
+      name: stringProp('Milestone name'),
+      description: stringProp('Milestone description'),
+      targetDate: stringProp('Milestone target date in YYYY-MM-DD format'),
+      projectId: stringProp('Project ID'),
+      sortOrder: numberProp('Milestone sort order'),
+      id: stringProp('Milestone ID'),
+    },
+    ['name', 'projectId']
+  ),
+  linear_update_project_milestone: tool(
+    'linear_update_project_milestone',
+    'Update a project milestone',
+    {
+      id: stringProp('Milestone ID'),
+      name: stringProp('Updated milestone name'),
+      description: stringProp('Updated milestone description'),
+      targetDate: stringProp('Updated milestone target date in YYYY-MM-DD format'),
+      projectId: stringProp('Updated project ID'),
+      sortOrder: numberProp('Updated milestone sort order'),
+    },
+    ['id']
+  ),
+  linear_delete_project_milestone: tool(
+    'linear_delete_project_milestone',
+    'Delete a project milestone',
+    {
+      id: stringProp('Milestone ID'),
+    },
+    ['id']
+  ),
+  linear_get_project_milestone: tool(
+    'linear_get_project_milestone',
+    'Get a project milestone',
+    {
+      id: stringProp('Milestone ID'),
+    },
+    ['id']
+  ),
+  linear_search_project_milestones: tool(
+    'linear_search_project_milestones',
+    'Search project milestones',
+    {
+      name: stringProp('Optional milestone name'),
+      projectId: stringProp('Optional project ID'),
+      targetDate: stringProp('Optional milestone target date in YYYY-MM-DD format'),
+      ...pageFields,
+      orderBy: stringProp('Pagination order field'),
+    }
+  ),
+  linear_get_project_milestones: tool(
+    'linear_get_project_milestones',
+    'List milestones for a project',
+    {
+      projectId: stringProp('Project ID'),
+      ...pageFields,
+      orderBy: stringProp('Pagination order field'),
+    },
+    ['projectId']
+  ),
+  linear_create_project_milestones: tool(
+    'linear_create_project_milestones',
+    'Create multiple project milestones',
+    {
+      projectId: stringProp('Project ID'),
+      milestones: arrayProp(
+        'Milestones to create',
+        objectSchema(
+          {
+            name: stringProp('Milestone name'),
+            description: stringProp('Milestone description'),
+            targetDate: stringProp('Milestone target date in YYYY-MM-DD format'),
+            sortOrder: numberProp('Milestone sort order'),
           },
-          description: 'Array of milestones to create',
-        },
-      },
-      required: ['projectId', 'milestones'],
+          ['name']
+        ),
+        { minItems: 1 }
+      ),
     },
-  },
+    ['projectId', 'milestones']
+  ),
+};
+
+const subscriptionToolSchemas: Record<string, ToolSchema> = {
+  linear_start_subscription: tool(
+    'linear_start_subscription',
+    'Start a subscription workflow when the runtime supports streaming transports',
+    {
+      topic: stringProp('Subscription topic'),
+      filter: looseObjectProp('Optional subscription filter'),
+    },
+    ['topic']
+  ),
+  linear_stop_subscription: tool(
+    'linear_stop_subscription',
+    'Stop a subscription workflow',
+    {
+      subscriptionId: stringProp('Subscription ID'),
+    },
+    ['subscriptionId']
+  ),
 };
+
+export const toolSchemas = {
+  ...baseToolSchemas,
+  ...subscriptionToolSchemas,
+};
+
+export function getAdvertisedToolSchemas(
+  capabilities: RuntimeCapabilities = getRuntimeCapabilities()
+): ToolSchema[] {
+  return Object.values(
+    capabilities.supportsSubscriptions
+      ? toolSchemas
+      : baseToolSchemas
+  );
+}
diff --git a/src/core/validation/tool-validator.ts b/src/core/validation/tool-validator.ts
new file mode 100644
index 0000000..1f366a5
--- /dev/null
+++ b/src/core/validation/tool-validator.ts
@@ -0,0 +1,190 @@
+import Ajv, { ErrorObject, ValidateFunction } from 'ajv';
+import { RuntimeCapabilities, getRuntimeCapabilities } from '../capabilities.js';
+import { toolSchemas } from '../types/tool.types.js';
+
+type ToolArguments = Record<string, unknown>;
+
+export interface ToolValidationIssue {
+  path: string;
+  keyword: string;
+  message: string;
+  schemaPath: string;
+}
+
+export type ToolValidationResult =
+  | {
+      valid: true;
+      data: ToolArguments;
+    }
+  | {
+      valid: false;
+      message: string;
+      issues: ToolValidationIssue[];
+    };
+
+export class ToolValidatorRegistry {
+  private readonly validators = new Map<string, ValidateFunction<ToolArguments>>();
+
+  constructor(
+    _capabilities: RuntimeCapabilities = getRuntimeCapabilities()
+  ) {
+    const ajv = new Ajv({
+      allErrors: true,
+      strict: false,
+      validateFormats: false,
+    });
+
+    for (const tool of Object.values(toolSchemas)) {
+      this.validators.set(
+        tool.name,
+        ajv.compile<ToolArguments>(tool.inputSchema)
+      );
+    }
+  }
+
+  hasTool(toolName: string): boolean {
+    return this.validators.has(toolName);
+  }
+
+  validate(toolName: string, input: unknown): ToolValidationResult {
+    const validator = this.validators.get(toolName);
+    const normalizedInput = this.normalizeInput(input);
+
+    if (!validator) {
+      return {
+        valid: true,
+        data: normalizedInput,
+      };
+    }
+
+    if (validator(normalizedInput)) {
+      return {
+        valid: true,
+        data: normalizedInput,
+      };
+    }
+
+    const issues = this.formatIssues(toolName, normalizedInput, validator.errors ?? []);
+
+    return {
+      valid: false,
+      message: this.buildMessage(toolName, issues),
+      issues,
+    };
+  }
+
+  private normalizeInput(input: unknown): ToolArguments {
+    if (input === undefined || input === null) {
+      return {};
+    }
+
+    if (typeof input === 'object' && !Array.isArray(input)) {
+      return input as ToolArguments;
+    }
+
+    return input as ToolArguments;
+  }
+
+  private formatIssues(
+    toolName: string,
+    input: ToolArguments,
+    errors: ErrorObject[]
+  ): ToolValidationIssue[] {
+    return errors.map(error => {
+      const path = this.formatPath(error, toolName, input);
+      const message = this.formatMessage(error, toolName, input);
+
+      return {
+        path,
+        keyword: error.keyword,
+        message,
+        schemaPath: error.schemaPath,
+      };
+    });
+  }
+
+  private formatPath(
+    error: ErrorObject,
+    toolName: string,
+    input: ToolArguments
+  ): string {
+    if (
+      this.isConflictingIssueStateFilter(toolName, input)
+      && error.keyword === 'not'
+    ) {
+      return '$.stateId';
+    }
+
+    if (error.keyword === 'required') {
+      const missingProperty = this.getStringParam(error.params, 'missingProperty');
+      return this.pointerToPath(`${error.instancePath}/${missingProperty}`);
+    }
+
+    if (error.keyword === 'additionalProperties') {
+      const additionalProperty = this.getStringParam(error.params, 'additionalProperty');
+      return this.pointerToPath(`${error.instancePath}/${additionalProperty}`);
+    }
+
+    return this.pointerToPath(error.instancePath);
+  }
+
+  private formatMessage(
+    error: ErrorObject,
+    toolName: string,
+    input: ToolArguments
+  ): string {
+    if (
+      this.isConflictingIssueStateFilter(toolName, input)
+      && error.keyword === 'not'
+    ) {
+      return 'stateId and states cannot both be provided';
+    }
+
+    return error.message ?? 'Invalid value';
+  }
+
+  private buildMessage(
+    toolName: string,
+    issues: ToolValidationIssue[]
+  ): string {
+    const firstIssue = issues[0];
+    if (!firstIssue) {
+      return `Invalid arguments for ${toolName}`;
+    }
+
+    return `Invalid arguments for ${toolName}: ${firstIssue.path} ${firstIssue.message}`;
+  }
+
+  private pointerToPath(pointer?: string): string {
+    if (!pointer) {
+      return '$';
+    }
+
+    return `$${pointer
+      .split('/')
+      .slice(1)
+      .map(segment => segment.replace(/~1/g, '/').replace(/~0/g, '~'))
+      .map(segment => /^\d+$/.test(segment) ? `[${segment}]` : `.${segment}`)
+      .join('')}`;
+  }
+
+  private getStringParam(
+    params: Record<string, unknown>,
+    key: string
+  ): string {
+    const value = params[key];
+    return typeof value === 'string' ? value : '';
+  }
+
+  private isConflictingIssueStateFilter(
+    toolName: string,
+    input: ToolArguments
+  ): boolean {
+    return (
+      (toolName === 'linear_list_issues' || toolName === 'linear_search_issues')
+      && typeof input.stateId === 'string'
+      && Array.isArray(input.states)
+      && input.states.length > 0
+    );
+  }
+}
diff --git a/src/features/agents/handlers/agent.handler.ts b/src/features/agents/handlers/agent.handler.ts
new file mode 100644
index 0000000..ebe1723
--- /dev/null
+++ b/src/features/agents/handlers/agent.handler.ts
@@ -0,0 +1,382 @@
+import { LinearAuth } from '../../../auth.js';
+import { BaseHandler } from '../../../core/handlers/base.handler.js';
+import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
+import {
+  asRecord,
+  compactObject,
+  getBoolean,
+  getDateString,
+  getString,
+  mapConnection,
+  resolveValue,
+} from '../../../types/sdk.utils.js';
+import {
+  AGENT_FLEXIBLE_ARRAY_MAX_ITEMS,
+  AGENT_FLEXIBLE_MAX_DEPTH,
+  AGENT_FLEXIBLE_OBJECT_MAX_PROPERTIES,
+  AGENT_FLEXIBLE_STRING_MAX_LENGTH,
+  AgentFlexibleObject,
+  AgentFlexibleValue,
+  CreateAgentActivityInput,
+  CreateAgentSessionOnCommentInput,
+  CreateAgentSessionOnIssueInput,
+  GetAgentActivityInput,
+  GetAgentSessionInput,
+  ListAgentActivitiesInput,
+  ListAgentSessionsInput,
+  UpdateAgentSessionInput,
+} from '../types/agent.types.js';
+
+export class AgentHandler extends BaseHandler {
+  constructor(auth: LinearAuth) {
+    super(auth);
+  }
+
+  async handleGetAgentSession(args: GetAgentSessionInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const session = await client.executeSdk(
+        'agentSession',
+        () => client.sdk.agentSession(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Fetched agent session ${getString(session, 'id') ?? args.id}`,
+        {
+          agentSession: await this.mapAgentSession(session),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get agent session');
+    }
+  }
+
+  async handleListAgentSessions(args: ListAgentSessionsInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const connection = await client.executeSdk(
+        'agentSessions',
+        () => client.sdk.agentSessions({
+          first: args.first ?? 50,
+          after: args.after,
+          ...(args.orderBy ? { orderBy: args.orderBy } : {}),
+        })
+      );
+
+      const mapped = await mapConnection(connection, session => this.mapAgentSession(session));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} agent sessions`,
+        {
+          agentSessions: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list agent sessions');
+    }
+  }
+
+  async handleCreateAgentSessionOnIssue(args: CreateAgentSessionOnIssueInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['issueId']);
+
+      const payload = await client.executeSdk(
+        'agentSessionCreateOnIssue',
+        () => client.sdk.agentSessionCreateOnIssue(args)
+      );
+      const session = await resolveValue(asRecord(payload).agentSession as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Created agent session for issue ${args.issueId}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          agentSession: await this.mapAgentSession(session),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'create agent session on issue');
+    }
+  }
+
+  async handleCreateAgentSessionOnComment(args: CreateAgentSessionOnCommentInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['commentId']);
+
+      const payload = await client.executeSdk(
+        'agentSessionCreateOnComment',
+        () => client.sdk.agentSessionCreateOnComment(args)
+      );
+      const session = await resolveValue(asRecord(payload).agentSession as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Created agent session for comment ${args.commentId}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          agentSession: await this.mapAgentSession(session),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'create agent session on comment');
+    }
+  }
+
+  async handleUpdateAgentSession(args: UpdateAgentSessionInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const { id, ...input } = args;
+      const sdkInput = {
+        ...input,
+        dismissedAt: input.dismissedAt ? this.toDate(input.dismissedAt) : undefined,
+        userState: input.userState?.map(entry => ({
+          ...entry,
+          lastReadAt: entry.lastReadAt ? this.toDate(entry.lastReadAt) : undefined,
+        })),
+      };
+      const payload = await client.executeSdk(
+        'updateAgentSession',
+        () => client.sdk.updateAgentSession(id, sdkInput)
+      );
+      const session = await resolveValue(asRecord(payload).agentSession as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Updated agent session ${id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          agentSession: await this.mapAgentSession(session),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'update agent session');
+    }
+  }
+
+  async handleGetAgentActivity(args: GetAgentActivityInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const activity = await client.executeSdk(
+        'agentActivity',
+        () => client.sdk.agentActivity(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Fetched agent activity ${getString(activity, 'id') ?? args.id}`,
+        {
+          agentActivity: await this.mapAgentActivity(activity),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get agent activity');
+    }
+  }
+
+  async handleListAgentActivities(args: ListAgentActivitiesInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const connection = await client.executeSdk(
+        'agentActivities',
+        () => client.sdk.agentActivities({
+          filter: args.filter,
+          first: args.first ?? 50,
+          after: args.after,
+          ...(args.orderBy ? { orderBy: args.orderBy } : {}),
+        })
+      );
+
+      const mapped = await mapConnection(connection, activity => this.mapAgentActivity(activity));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} agent activities`,
+        {
+          agentActivities: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list agent activities');
+    }
+  }
+
+  async handleCreateAgentActivity(args: CreateAgentActivityInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['agentSessionId', 'content']);
+
+      const payload = await client.executeSdk(
+        'createAgentActivity',
+        () => client.sdk.createAgentActivity(args)
+      );
+      const activity = await resolveValue(asRecord(payload).agentActivity as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Created agent activity for session ${args.agentSessionId}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          agentActivity: await this.mapAgentActivity(activity),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'create agent activity');
+    }
+  }
+
+  private async mapAgentSession(session: unknown): Promise<Record<string, unknown>> {
+    if (!session) {
+      return {};
+    }
+
+    const record = asRecord(session);
+    const issue = await resolveValue(record.issue as Promise<unknown> | unknown);
+    const comment = await resolveValue(record.comment as Promise<unknown> | unknown);
+    const externalUrls = this.mapExternalUrls(record.externalUrls);
+
+    return compactObject({
+      id: getString(record, 'id'),
+      status: getString(record, 'status'),
+      state: getString(record, 'state'),
+      externalLink: getString(record, 'externalLink'),
+      externalUrls,
+      createdAt: getDateString(record, 'createdAt'),
+      updatedAt: getDateString(record, 'updatedAt'),
+      issue: issue ? compactObject({
+        id: getString(issue, 'id'),
+        identifier: getString(issue, 'identifier'),
+        title: getString(issue, 'title'),
+      }) : undefined,
+      comment: comment ? compactObject({
+        id: getString(comment, 'id'),
+        body: getString(comment, 'body'),
+      }) : undefined,
+    });
+  }
+
+  private async mapAgentActivity(activity: unknown): Promise<Record<string, unknown>> {
+    if (!activity) {
+      return {};
+    }
+
+    const record = asRecord(activity);
+    const agentSession = await resolveValue(record.agentSession as Promise<unknown> | unknown);
+
+    return compactObject({
+      id: getString(record, 'id'),
+      signal: getString(record, 'signal'),
+      ephemeral: getBoolean(record, 'ephemeral'),
+      content: this.sanitizeFlexibleObject(record.content),
+      signalMetadata: this.sanitizeFlexibleObject(record.signalMetadata),
+      contextualMetadata: this.sanitizeFlexibleObject(record.contextualMetadata),
+      createdAt: getDateString(record, 'createdAt'),
+      updatedAt: getDateString(record, 'updatedAt'),
+      agentSession: agentSession ? compactObject({
+        id: getString(agentSession, 'id'),
+        status: getString(agentSession, 'status'),
+        state: getString(agentSession, 'state'),
+        }) : undefined,
+    });
+  }
+
+  private mapExternalUrls(value: unknown): Array<Record<string, unknown>> | undefined {
+    if (!Array.isArray(value)) {
+      return undefined;
+    }
+
+    const externalUrls = value
+      .slice(0, AGENT_FLEXIBLE_ARRAY_MAX_ITEMS)
+      .map(item => {
+        const record = asRecord(item);
+        return compactObject({
+          label: getString(record, 'label'),
+          url: getString(record, 'url'),
+        });
+      })
+      .filter(item => Object.keys(item).length > 0);
+
+    return externalUrls.length > 0 ? externalUrls : undefined;
+  }
+
+  private sanitizeFlexibleObject(
+    value: unknown,
+    depth: number = 0
+  ): AgentFlexibleObject | undefined {
+    if (!this.isPlainObject(value) || depth > AGENT_FLEXIBLE_MAX_DEPTH) {
+      return undefined;
+    }
+
+    const entries = Object.entries(value);
+    if (entries.length > AGENT_FLEXIBLE_OBJECT_MAX_PROPERTIES) {
+      return undefined;
+    }
+
+    const sanitizedEntries = entries.flatMap(([key, entryValue]) => {
+      if (key.length > 200) {
+        return [];
+      }
+
+      const sanitizedValue = this.sanitizeFlexibleValue(entryValue, depth + 1);
+      return sanitizedValue === undefined ? [] : [[key, sanitizedValue] as const];
+    });
+
+    return Object.fromEntries(sanitizedEntries);
+  }
+
+  private sanitizeFlexibleValue(
+    value: unknown,
+    depth: number
+  ): AgentFlexibleValue | undefined {
+    if (depth > AGENT_FLEXIBLE_MAX_DEPTH) {
+      return undefined;
+    }
+
+    if (value === null) {
+      return null;
+    }
+
+    if (typeof value === 'string') {
+      return value.length <= AGENT_FLEXIBLE_STRING_MAX_LENGTH ? value : undefined;
+    }
+
+    if (typeof value === 'number') {
+      return Number.isFinite(value) ? value : undefined;
+    }
+
+    if (typeof value === 'boolean') {
+      return value;
+    }
+
+    if (Array.isArray(value)) {
+      if (value.length > AGENT_FLEXIBLE_ARRAY_MAX_ITEMS) {
+        return undefined;
+      }
+
+      const items = value.flatMap(item => {
+        const sanitizedItem = this.sanitizeFlexibleValue(item, depth + 1);
+        return sanitizedItem === undefined ? [] : [sanitizedItem];
+      });
+
+      return items;
+    }
+
+    return this.sanitizeFlexibleObject(value, depth + 1);
+  }
+
+  private isPlainObject(value: unknown): value is Record<string, unknown> {
+    return typeof value === 'object' && value !== null && !Array.isArray(value);
+  }
+
+  private toDate(value: string): Date {
+    const parsed = new Date(value);
+    if (Number.isNaN(parsed.getTime())) {
+      throw new Error(`Invalid ISO date value: ${value}`);
+    }
+
+    return parsed;
+  }
+}
diff --git a/src/features/agents/types/agent.types.ts b/src/features/agents/types/agent.types.ts
new file mode 100644
index 0000000..687b311
--- /dev/null
+++ b/src/features/agents/types/agent.types.ts
@@ -0,0 +1,86 @@
+import type { LinearClient } from '@linear/sdk';
+
+export interface GetAgentSessionInput {
+  id: string;
+}
+
+export const AGENT_FLEXIBLE_OBJECT_MAX_PROPERTIES = 20;
+export const AGENT_FLEXIBLE_ARRAY_MAX_ITEMS = 50;
+export const AGENT_FLEXIBLE_STRING_MAX_LENGTH = 4000;
+export const AGENT_FLEXIBLE_MAX_DEPTH = 5;
+
+export type AgentFlexibleValue =
+  | string
+  | number
+  | boolean
+  | null
+  | AgentFlexibleObject
+  | AgentFlexibleValue[];
+
+export interface AgentFlexibleObject {
+  [key: string]: AgentFlexibleValue;
+}
+
+type AgentSessionListArgs = NonNullable<Parameters<LinearClient['agentSessions']>[0]>;
+type AgentActivityListArgs = NonNullable<Parameters<LinearClient['agentActivities']>[0]>;
+type AgentActivityCreateSdkInput = Parameters<LinearClient['createAgentActivity']>[0];
+
+export interface ListAgentSessionsInput {
+  first?: AgentSessionListArgs['first'];
+  after?: AgentSessionListArgs['after'];
+  orderBy?: AgentSessionListArgs['orderBy'];
+}
+
+export interface AgentSessionExternalUrlInput {
+  label: string;
+  url: string;
+}
+
+export interface CreateAgentSessionOnIssueInput {
+  issueId: string;
+  externalLink?: string;
+  externalUrls?: AgentSessionExternalUrlInput[];
+}
+
+export interface CreateAgentSessionOnCommentInput {
+  commentId: string;
+  externalLink?: string;
+  externalUrls?: AgentSessionExternalUrlInput[];
+}
+
+export interface AgentSessionUserStateInput {
+  userId: string;
+  lastReadAt?: string;
+}
+
+export interface UpdateAgentSessionInput {
+  id: string;
+  addedExternalUrls?: AgentSessionExternalUrlInput[];
+  dismissedAt?: string;
+  externalLink?: string;
+  externalUrls?: AgentSessionExternalUrlInput[];
+  plan?: AgentFlexibleObject;
+  removedExternalUrls?: string[];
+  userState?: AgentSessionUserStateInput[];
+}
+
+export interface GetAgentActivityInput {
+  id: string;
+}
+
+export interface ListAgentActivitiesInput {
+  filter?: AgentActivityListArgs['filter'];
+  first?: AgentActivityListArgs['first'];
+  after?: AgentActivityListArgs['after'];
+  orderBy?: AgentActivityListArgs['orderBy'];
+}
+
+export interface CreateAgentActivityInput {
+  agentSessionId: string;
+  content: AgentFlexibleObject;
+  contextualMetadata?: AgentFlexibleObject;
+  ephemeral?: AgentActivityCreateSdkInput['ephemeral'];
+  id?: string;
+  signal?: AgentActivityCreateSdkInput['signal'];
+  signalMetadata?: AgentFlexibleObject;
+}
diff --git a/src/features/attachments/handlers/attachment.handler.ts b/src/features/attachments/handlers/attachment.handler.ts
new file mode 100644
index 0000000..9acbcb9
--- /dev/null
+++ b/src/features/attachments/handlers/attachment.handler.ts
@@ -0,0 +1,186 @@
+import { LinearAuth } from '../../../auth.js';
+import { BaseHandler } from '../../../core/handlers/base.handler.js';
+import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
+import {
+  asRecord,
+  compactObject,
+  getBoolean,
+  getDateString,
+  getString,
+  mapConnection,
+  resolveValue,
+} from '../../../types/sdk.utils.js';
+import {
+  CreateAttachmentInput,
+  GetAttachmentInput,
+  ListAttachmentsInput,
+  UpdateAttachmentInput,
+} from '../types/attachment.types.js';
+
+export class AttachmentHandler extends BaseHandler {
+  constructor(auth: LinearAuth) {
+    super(auth);
+  }
+
+  async handleGetAttachment(args: GetAttachmentInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const attachment = await client.executeSdk(
+        'attachment',
+        () => client.sdk.attachment(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Fetched attachment ${getString(attachment, 'title') ?? args.id}`,
+        {
+          attachment: await this.mapAttachment(attachment),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get attachment');
+    }
+  }
+
+  async handleListAttachments(args: ListAttachmentsInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const connection = args.issueId
+        ? await client.executeSdk('issue.attachments', async () => {
+            const issue = await client.sdk.issue(args.issueId!);
+            return issue.attachments({
+              filter: args.filter,
+              first: args.first ?? 50,
+              after: args.after,
+            });
+          })
+        : await client.executeSdk(
+            'attachments',
+            () => client.sdk.attachments({
+              filter: args.filter,
+              first: args.first ?? 50,
+              after: args.after,
+            })
+          );
+
+      const mapped = await mapConnection(connection, attachment => this.mapAttachment(attachment));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} attachments`,
+        {
+          attachments: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list attachments');
+    }
+  }
+
+  async handleCreateAttachment(args: CreateAttachmentInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['title', 'url', 'issueId']);
+
+      const payload = await client.executeSdk(
+        'createAttachment',
+        () => client.sdk.createAttachment(args)
+      );
+      const attachment = await resolveValue(asRecord(payload).attachment as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Created attachment ${getString(attachment, 'title') ?? args.title}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          attachment: await this.mapAttachment(attachment),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'create attachment');
+    }
+  }
+
+  async handleUpdateAttachment(args: UpdateAttachmentInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id', 'title']);
+
+      const { id, ...input } = args;
+      const payload = await client.executeSdk(
+        'updateAttachment',
+        () => client.sdk.updateAttachment(id, input)
+      );
+      const attachment = await resolveValue(asRecord(payload).attachment as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Updated attachment ${getString(attachment, 'title') ?? id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          attachment: await this.mapAttachment(attachment),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'update attachment');
+    }
+  }
+
+  async handleDeleteAttachment(args: GetAttachmentInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const payload = await client.executeSdk(
+        'deleteAttachment',
+        () => client.sdk.deleteAttachment(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Deleted attachment ${args.id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          id: args.id,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'delete attachment');
+    }
+  }
+
+  private async mapAttachment(attachment: unknown): Promise<Record<string, unknown>> {
+    if (!attachment) {
+      return {};
+    }
+
+    const record = asRecord(attachment);
+    const issue = await resolveValue(record.issue as Promise<unknown> | unknown);
+    const creator = await resolveValue(record.creator as Promise<unknown> | unknown);
+
+    return compactObject({
+      id: getString(record, 'id'),
+      title: getString(record, 'title'),
+      subtitle: getString(record, 'subtitle'),
+      url: getString(record, 'url'),
+      iconUrl: getString(record, 'iconUrl'),
+      metadata: record.metadata as Record<string, unknown> | undefined,
+      createdAt: getDateString(record, 'createdAt'),
+      updatedAt: getDateString(record, 'updatedAt'),
+      issue: this.mapReference(issue, ['id', 'identifier', 'title']),
+      creator: this.mapReference(creator, ['id', 'name', 'displayName']),
+    });
+  }
+
+  private mapReference(
+    value: unknown,
+    keys: string[]
+  ): Record<string, unknown> | undefined {
+    if (!value) {
+      return undefined;
+    }
+
+    const record = asRecord(value);
+    return compactObject(
+      Object.fromEntries(keys.map(key => [key, getString(record, key)]))
+    );
+  }
+}
diff --git a/src/features/attachments/types/attachment.types.ts b/src/features/attachments/types/attachment.types.ts
new file mode 100644
index 0000000..4ff6ac9
--- /dev/null
+++ b/src/features/attachments/types/attachment.types.ts
@@ -0,0 +1,18 @@
+import type { LinearClient } from '@linear/sdk';
+
+export interface GetAttachmentInput {
+  id: string;
+}
+
+export interface ListAttachmentsInput {
+  filter?: NonNullable<Parameters<LinearClient['attachments']>[0]>['filter'];
+  issueId?: string;
+  first?: number;
+  after?: string;
+}
+
+export type CreateAttachmentInput = Parameters<LinearClient['createAttachment']>[0];
+
+export type UpdateAttachmentInput = {
+  id: string;
+} & Parameters<LinearClient['updateAttachment']>[1];
diff --git a/src/features/auth/handlers/auth.handler.ts b/src/features/auth/handlers/auth.handler.ts
index b257bed..2a6c583 100644
--- a/src/features/auth/handlers/auth.handler.ts
+++ b/src/features/auth/handlers/auth.handler.ts
@@ -1,15 +1,14 @@
 import { BaseHandler } from '../../../core/handlers/base.handler.js';
 import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
 import { LinearAuth } from '../../../auth.js';
-import { LinearGraphQLClient } from '../../../graphql/client.js';
 
 /**
  * Handler for authentication-related operations.
  * Manages both OAuth and API Key authentication flows.
  */
 export class AuthHandler extends BaseHandler {
-  constructor(auth: LinearAuth, graphqlClient?: LinearGraphQLClient) {
-    super(auth, graphqlClient);
+  constructor(auth: LinearAuth) {
+    super(auth);
   }
 
   /**
@@ -28,11 +27,17 @@ export class AuthHandler extends BaseHandler {
 
       const authUrl = this.auth.getAuthorizationUrl();
 
-      return this.createResponse(
-        `Please visit the following URL to authorize the application:\n${authUrl}`
+      return this.createStructuredResponse(
+        'Generated Linear OAuth authorization URL',
+        {
+          authorizationUrl: authUrl,
+          state: this.auth.getPendingOAuthState() ?? null,
+          actor: 'app',
+          nextStep: 'Open authorizationUrl, authorize the app, then call linear_auth_callback with both the returned code and this exact state. The state is single-use.',
+        }
       );
     } catch (error) {
-      this.handleError(error, 'initialize authentication');
+      return this.handleError(error, 'initialize authentication');
     }
   }
 
@@ -41,13 +46,18 @@ export class AuthHandler extends BaseHandler {
    */
   async handleAuthCallback(args: any): Promise<BaseToolResponse> {
     try {
-      this.validateRequiredParams(args, ['code']);
+      this.validateRequiredParams(args, ['code', 'state']);
 
-      await this.auth.handleCallback(args.code);
+      await this.auth.handleCallback(args.code, args.state);
 
-      return this.createResponse('Successfully authenticated with Linear');
+      return this.createStructuredResponse(
+        'Successfully authenticated with Linear',
+        {
+          authenticated: true,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'handle authentication callback');
+      return this.handleError(error, 'handle authentication callback');
     }
   }
 }
diff --git a/src/features/comments/comment.mapper.ts b/src/features/comments/comment.mapper.ts
new file mode 100644
index 0000000..4437d59
--- /dev/null
+++ b/src/features/comments/comment.mapper.ts
@@ -0,0 +1,97 @@
+import {
+  asRecord,
+  compactObject,
+  getDateString,
+  getObject,
+  getString,
+  mapConnection,
+  resolveValue,
+} from '../../types/sdk.utils.js';
+
+type MappedComment = Record<string, unknown>;
+
+export type MappedCommentConnection = {
+  nodes: MappedComment[];
+  pageInfo: Record<string, unknown>;
+};
+
+function mapCommentUserReference(value: unknown): Record<string, unknown> | undefined {
+  const user = asRecord(value);
+  const id = getString(user, 'id');
+  if (!id) {
+    return undefined;
+  }
+
+  return compactObject({
+    id,
+    name: getString(user, 'name'),
+    email: getString(user, 'email'),
+  });
+}
+
+export function mapCommentIssueReference(value: unknown): Record<string, unknown> | undefined {
+  const issue = asRecord(value);
+  const id = getString(issue, 'id');
+  if (!id) {
+    return undefined;
+  }
+
+  return compactObject({
+    id,
+    identifier: getString(issue, 'identifier'),
+    title: getString(issue, 'title'),
+    url: getString(issue, 'url'),
+  });
+}
+
+async function mapCommentReference(value: unknown): Promise<Record<string, unknown> | undefined> {
+  const comment = asRecord(await resolveValue(value));
+  const id = getString(comment, 'id');
+  if (!id) {
+    return undefined;
+  }
+
+  return compactObject({
+    id,
+    body: getString(comment, 'body'),
+    url: getString(comment, 'url'),
+    createdAt: getDateString(comment, 'createdAt'),
+    updatedAt: getDateString(comment, 'updatedAt'),
+    user: mapCommentUserReference(await resolveValue(comment.user)),
+  });
+}
+
+export async function mapComment(value: unknown): Promise<MappedComment> {
+  const comment = asRecord(await resolveValue(value));
+  const parent = await mapCommentReference(comment.parent);
+  const resolvingComment = await mapCommentReference(comment.resolvingComment);
+  const user = mapCommentUserReference(await resolveValue(comment.user));
+  const issue = mapCommentIssueReference(await resolveValue(comment.issue));
+  const resolvingUser = mapCommentUserReference(await resolveValue(comment.resolvingUser));
+
+  return compactObject({
+    id: getString(comment, 'id'),
+    body: getString(comment, 'body'),
+    bodyData: getObject(comment, 'bodyData') ?? getString(comment, 'bodyData'),
+    quotedText: getString(comment, 'quotedText'),
+    url: getString(comment, 'url'),
+    archivedAt: getDateString(comment, 'archivedAt'),
+    createdAt: getDateString(comment, 'createdAt'),
+    updatedAt: getDateString(comment, 'updatedAt'),
+    editedAt: getDateString(comment, 'editedAt'),
+    resolvedAt: getDateString(comment, 'resolvedAt'),
+    issueId: getString(comment, 'issueId'),
+    parentId: getString(comment, 'parentId'),
+    resolvingCommentId: getString(comment, 'resolvingCommentId'),
+    reactionData: getObject(comment, 'reactionData'),
+    user,
+    issue,
+    parent,
+    resolvingComment,
+    resolvingUser,
+  });
+}
+
+export async function mapCommentConnection(connection: unknown): Promise<MappedCommentConnection> {
+  return mapConnection(connection, comment => mapComment(comment));
+}
diff --git a/src/features/comments/handlers/comment.handler.ts b/src/features/comments/handlers/comment.handler.ts
index 73efcfe..e57d5d4 100644
--- a/src/features/comments/handlers/comment.handler.ts
+++ b/src/features/comments/handlers/comment.handler.ts
@@ -1,117 +1,218 @@
 import { BaseHandler } from '../../../core/handlers/base.handler.js';
 import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
 import { LinearAuth } from '../../../auth.js';
-import { LinearGraphQLClient } from '../../../graphql/client.js';
+import {
+  getString,
+} from '../../../types/sdk.utils.js';
 import {
   CommentHandlerMethods,
   CreateCommentInput,
-  GetIssueCommentsInput,
   CreateCommentResponse,
-  GetIssueCommentsResponse
+  DeleteCommentInput,
+  DeleteCommentResponse,
+  GetCommentInput,
+  GetCommentResponse,
+  GetIssueCommentsInput,
+  GetIssueCommentsResponse,
+  ListCommentsInput,
+  ListCommentsResponse,
+  ResolveCommentResponse,
+  ResolveCommentInput,
+  UnresolveCommentInput,
+  UnresolveCommentResponse,
+  UpdateCommentInput,
+  UpdateCommentResponse,
 } from '../types/comment.types.js';
+import {
+  mapComment,
+  mapCommentConnection,
+  mapCommentIssueReference,
+} from '../comment.mapper.js';
 
-/**
- * Handler for comment-related operations.
- * Manages creating and retrieving comments on issues.
- */
 export class CommentHandler extends BaseHandler implements CommentHandlerMethods {
-  constructor(auth: LinearAuth, graphqlClient?: LinearGraphQLClient) {
-    super(auth, graphqlClient);
+  constructor(auth: LinearAuth) {
+    super(auth);
+  }
+
+  async handleGetComment(args: GetCommentInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const result = await client.getComment(args) as GetCommentResponse;
+      if (!result.comment) {
+        throw new Error(`Comment ${args.id} was not found`);
+      }
+
+      return this.createStructuredResponse(
+        `Fetched comment ${args.id}`,
+        {
+          comment: await mapComment(result.comment),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get comment');
+    }
+  }
+
+  async handleListComments(args: ListCommentsInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const result = await client.listComments(args) as ListCommentsResponse;
+      const comments = await mapCommentConnection(result.comments);
+
+      return this.createStructuredResponse(
+        `Listed ${comments.nodes.length} comments`,
+        {
+          comments: comments.nodes,
+          pageInfo: comments.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list comments');
+    }
   }
 
-  /**
-   * Gets comments for a specific issue, including threaded replies.
-   */
   async handleGetIssueComments(args: GetIssueCommentsInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['issueId']);
 
-      const result = await client.getIssueComments(
-        args.issueId,
-        args.first || 50,
-        args.after,
-        args.includeArchived || false
-      ) as GetIssueCommentsResponse;
-
-      // Format response for better readability
-      const comments = result.issue.comments.nodes;
-      const formattedResponse = {
-        issueId: result.issue.id,
-        issueTitle: result.issue.title,
-        totalComments: comments.length,
-        hasMoreComments: result.issue.comments.pageInfo.hasNextPage,
-        nextCursor: result.issue.comments.pageInfo.endCursor,
-        comments: comments.map(comment => ({
-          id: comment.id,
-          author: comment.user.name,
-          authorEmail: comment.user.email,
-          content: comment.body,
-          createdAt: comment.createdAt,
-          updatedAt: comment.updatedAt,
-          isReply: !!comment.parent,
-          parentComment: comment.parent ? {
-            id: comment.parent.id,
-            author: comment.parent.user.name,
-            preview: comment.parent.body.length > 100
-              ? comment.parent.body.substring(0, 100) + '...'
-              : comment.parent.body
-          } : null,
-          hasReplies: !!comment.children?.nodes && comment.children.nodes.length > 0,
-          replyCount: comment.children?.nodes ? comment.children.nodes.length : 0,
-          replies: comment.children?.nodes ? comment.children.nodes.map(reply => ({
-            id: reply.id,
-            author: reply.user.name,
-            content: reply.body.length > 150
-              ? reply.body.substring(0, 150) + '...'
-              : reply.body,
-            createdAt: reply.createdAt
-          })) : []
-        }))
-      };
-
-      return this.createJsonResponse(formattedResponse);
+      const issueReference = typeof client.findIssueByIdentifier === 'function'
+        ? await client.findIssueByIdentifier(args.issueId)
+        : undefined;
+      const result = await client.getIssueComments({
+        ...args,
+        issueId: getString(issueReference, 'id') ?? args.issueId,
+      }) as GetIssueCommentsResponse;
+      if (!result.issue) {
+        throw new Error(`Issue ${args.issueId} was not found`);
+      }
+
+      const comments = await mapCommentConnection(result.issue.comments);
+
+      return this.createStructuredResponse(
+        `Fetched ${comments.nodes.length} comments for issue ${result.issue.title ?? args.issueId}`,
+        {
+          issue: mapCommentIssueReference(result.issue),
+          comments: comments.nodes,
+          pageInfo: comments.pageInfo,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'get issue comments');
+      return this.handleError(error, 'get issue comments');
     }
   }
 
-  /**
-   * Creates a new comment on an issue or replies to an existing comment.
-   */
   async handleCreateComment(args: CreateCommentInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
-      this.validateRequiredParams(args, ['body', 'issueId']);
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['body']);
+
+      if (!args.issueId && !args.parentId) {
+        throw new Error('Creating a comment requires issueId or parentId');
+      }
 
       const result = await client.createComment(args) as CreateCommentResponse;
+      return this.createCommentMutationResponse(result.commentCreate, 'Created');
+    } catch (error) {
+      return this.handleError(error, 'create comment');
+    }
+  }
+
+  async handleUpdateComment(args: UpdateCommentInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
 
-      if (!result.commentCreate.success) {
-        throw new Error('Failed to create comment');
+      if (
+        args.body === undefined
+        && args.bodyData === undefined
+        && args.quotedText === undefined
+      ) {
+        throw new Error('Updating a comment requires body, bodyData, or quotedText');
       }
 
-      const comment = result.commentCreate.comment;
-      const responseText = [
-        `Successfully created comment`,
-        `Comment ID: ${comment.id}`,
-        `Author: ${comment.user.name} (${comment.user.email})`,
-        `Issue: ${comment.issue.title}`,
-        `Content: ${comment.body.length > 200
-          ? comment.body.substring(0, 200) + '...'
-          : comment.body}`,
-        `Created: ${comment.createdAt}`
-      ];
-
-      if (args.parentId && comment.parent) {
-        responseText.push(`Reply to: ${comment.parent.user.name}`);
-        responseText.push(`Parent comment: ${comment.parent.body.length > 100
-          ? comment.parent.body.substring(0, 100) + '...'
-          : comment.parent.body}`);
+      const result = await client.updateComment(args) as UpdateCommentResponse;
+      return this.createCommentMutationResponse(result.commentUpdate, 'Updated');
+    } catch (error) {
+      return this.handleError(error, 'update comment');
+    }
+  }
+
+  async handleDeleteComment(args: DeleteCommentInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const result = await client.deleteComment(args) as DeleteCommentResponse;
+      if (!result.commentDelete.success) {
+        throw new Error('Failed to delete comment');
       }
 
-      return this.createResponse(responseText.join('\n'));
+      return this.createStructuredResponse(
+        `Deleted comment ${result.commentDelete.entityId || args.id}`,
+        {
+          success: true,
+          id: result.commentDelete.entityId,
+          lastSyncId: result.commentDelete.lastSyncId,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'create comment');
+      return this.handleError(error, 'delete comment');
     }
   }
-}
\ No newline at end of file
+
+  async handleResolveComment(args: ResolveCommentInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const result = await client.resolveComment(args) as ResolveCommentResponse;
+      return this.createCommentMutationResponse(result.commentResolve, 'Resolved');
+    } catch (error) {
+      return this.handleError(error, 'resolve comment');
+    }
+  }
+
+  async handleUnresolveComment(args: UnresolveCommentInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const result = await client.unresolveComment(args) as UnresolveCommentResponse;
+      return this.createCommentMutationResponse(result.commentUnresolve, 'Unresolved');
+    } catch (error) {
+      return this.handleError(error, 'unresolve comment');
+    }
+  }
+
+  private async createCommentMutationResponse(
+    payload: {
+      success: boolean;
+      comment?: unknown;
+      lastSyncId: number;
+    },
+    verb: string
+  ): Promise<BaseToolResponse> {
+    if (!payload.success) {
+      throw new Error(`Failed to ${verb.toLowerCase()} comment`);
+    }
+
+    if (!payload.comment) {
+      throw new Error('Comment mutation did not return a comment');
+    }
+
+    const comment = await mapComment(payload.comment);
+    const commentId = getString(comment, 'id');
+
+    return this.createStructuredResponse(
+      commentId ? `${verb} comment ${commentId}` : `${verb} comment`,
+      {
+        success: true,
+        lastSyncId: payload.lastSyncId,
+        comment,
+      }
+    );
+  }
+}
diff --git a/src/features/comments/types/comment.types.ts b/src/features/comments/types/comment.types.ts
index efab5ac..e1f366a 100644
--- a/src/features/comments/types/comment.types.ts
+++ b/src/features/comments/types/comment.types.ts
@@ -4,31 +4,72 @@ import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interfac
  * Comment data structures
  */
 
+export type CommentOrderBy = 'createdAt' | 'updatedAt';
+
+export interface CommentUser {
+  id: string;
+  name?: string;
+  email?: string;
+}
+
+export interface CommentIssueReference {
+  id: string;
+  title?: string;
+  identifier?: string;
+  url?: string;
+}
+
+export interface CommentReference {
+  id: string;
+  body?: string;
+  url?: string;
+  createdAt?: string;
+  updatedAt?: string;
+  user?: CommentUser;
+}
+
 export interface Comment {
   id: string;
-  body: string;                    // Markdown content
-  bodyData?: string;               // ProseMirror JSON (optional)
-  user: {
-    id: string;
-    name: string;
-    email: string;
-  };
-  issue: {
-    id: string;
-    title: string;
-  };
-  parent?: Comment;                // For threading
-  children?: CommentConnection;    // For threading
+  body: string;
+  bodyData?: Record<string, unknown> | string;
+  quotedText?: string;
+  url?: string;
+  archivedAt?: string;
   createdAt: string;
   updatedAt: string;
+  editedAt?: string;
+  resolvedAt?: string;
+  issueId?: string;
+  parentId?: string;
+  resolvingCommentId?: string;
+  reactionData?: Record<string, unknown>;
+  user?: CommentUser;
+  issue?: CommentIssueReference;
+  parent?: CommentReference;
+  resolvingComment?: CommentReference;
+  resolvingUser?: CommentUser;
+}
+
+export interface CommentPageInfo {
+  hasNextPage: boolean;
+  endCursor: string | null;
+  hasPreviousPage?: boolean;
+  startCursor?: string | null;
 }
 
 export interface CommentConnection {
   nodes: Comment[];
-  pageInfo: {
-    hasNextPage: boolean;
-    endCursor: string | null;
-  };
+  pageInfo: CommentPageInfo;
+}
+
+export interface CommentCollectionInput {
+  first?: number;
+  after?: string;
+  last?: number;
+  before?: string;
+  filter?: Record<string, unknown>;
+  includeArchived?: boolean;
+  orderBy?: CommentOrderBy | string;
 }
 
 /**
@@ -36,36 +77,89 @@ export interface CommentConnection {
  */
 
 export interface CreateCommentInput {
-  body: string;                    // Markdown content
-  issueId: string;
-  parentId?: string;        // For threading
-  createAsUser?: string;           // For OAuth apps
-  displayIconUrl?: string;         // For OAuth apps
+  body: string;
+  issueId?: string;
+  parentId?: string;
+  bodyData?: Record<string, unknown>;
+  quotedText?: string;
+  createAsUser?: string;
+  displayIconUrl?: string;
+}
+
+export interface GetCommentInput {
+  id: string;
+}
+
+export interface ListCommentsInput extends CommentCollectionInput {}
+
+export interface UpdateCommentInput {
+  id: string;
+  body?: string;
+  bodyData?: Record<string, unknown>;
+  quotedText?: string;
 }
 
-export interface GetIssueCommentsInput {
+export interface DeleteCommentInput {
+  id: string;
+}
+
+export interface ResolveCommentInput {
+  id: string;
+  resolvingCommentId?: string;
+}
+
+export interface UnresolveCommentInput {
+  id: string;
+}
+
+export interface GetIssueCommentsInput extends CommentCollectionInput {
   issueId: string;
-  first?: number;                  // Pagination
-  after?: string;                  // Pagination cursor
-  includeArchived?: boolean;
 }
 
 /**
  * Response types for comment operations
  */
 
+export interface CommentMutationPayload {
+  success: boolean;
+  comment?: Comment;
+  lastSyncId: number;
+}
+
 export interface CreateCommentResponse {
-  commentCreate: {
+  commentCreate: CommentMutationPayload;
+}
+
+export interface UpdateCommentResponse {
+  commentUpdate: CommentMutationPayload;
+}
+
+export interface ResolveCommentResponse {
+  commentResolve: CommentMutationPayload;
+}
+
+export interface UnresolveCommentResponse {
+  commentUnresolve: CommentMutationPayload;
+}
+
+export interface DeleteCommentResponse {
+  commentDelete: {
     success: boolean;
-    comment: Comment;
+    entityId: string;
     lastSyncId: number;
   };
 }
 
+export interface GetCommentResponse {
+  comment: Comment;
+}
+
+export interface ListCommentsResponse {
+  comments: CommentConnection;
+}
+
 export interface GetIssueCommentsResponse {
-  issue: {
-    id: string;
-    title: string;
+  issue: CommentIssueReference & {
     comments: CommentConnection;
   };
 }
@@ -75,6 +169,12 @@ export interface GetIssueCommentsResponse {
  */
 
 export interface CommentHandlerMethods {
+  handleGetComment(args: GetCommentInput): Promise<BaseToolResponse>;
+  handleListComments(args: ListCommentsInput): Promise<BaseToolResponse>;
   handleGetIssueComments(args: GetIssueCommentsInput): Promise<BaseToolResponse>;
   handleCreateComment(args: CreateCommentInput): Promise<BaseToolResponse>;
-}
\ No newline at end of file
+  handleUpdateComment(args: UpdateCommentInput): Promise<BaseToolResponse>;
+  handleDeleteComment(args: DeleteCommentInput): Promise<BaseToolResponse>;
+  handleResolveComment(args: ResolveCommentInput): Promise<BaseToolResponse>;
+  handleUnresolveComment(args: UnresolveCommentInput): Promise<BaseToolResponse>;
+}
diff --git a/src/features/cycles/handlers/cycle.handler.ts b/src/features/cycles/handlers/cycle.handler.ts
new file mode 100644
index 0000000..c6e19aa
--- /dev/null
+++ b/src/features/cycles/handlers/cycle.handler.ts
@@ -0,0 +1,137 @@
+import { LinearAuth } from '../../../auth.js';
+import { BaseHandler } from '../../../core/handlers/base.handler.js';
+import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
+import {
+  asRecord,
+  compactObject,
+  getBoolean,
+  getDateString,
+  getNumber,
+  getString,
+  mapConnection,
+  resolveValue,
+} from '../../../types/sdk.utils.js';
+import { GetCurrentCycleInput, GetCycleInput, ListCyclesInput } from '../types/cycle.types.js';
+
+export class CycleHandler extends BaseHandler {
+  constructor(auth: LinearAuth) {
+    super(auth);
+  }
+
+  async handleGetCycle(args: GetCycleInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const cycle = await client.executeSdk(
+        'cycle',
+        () => client.sdk.cycle(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Fetched cycle ${getString(cycle, 'name') ?? args.id}`,
+        {
+          cycle: await this.mapCycle(cycle),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get cycle');
+    }
+  }
+
+  async handleListCycles(args: ListCyclesInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const filter = {
+        ...(args.filter ?? {}),
+        ...(args.teamId ? { team: { id: { eq: args.teamId } } } : {}),
+      };
+
+      const connection = await client.executeSdk(
+        'cycles',
+        () => client.sdk.cycles({
+          filter: Object.keys(filter).length > 0 ? filter : undefined,
+          first: args.first ?? 50,
+          after: args.after,
+        })
+      );
+
+      const mapped = await mapConnection(connection, cycle => this.mapCycle(cycle));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} cycles`,
+        {
+          cycles: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list cycles');
+    }
+  }
+
+  async handleGetCurrentCycle(args: GetCurrentCycleInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const filter = {
+        ...(args.filter ?? {}),
+        isActive: { eq: true },
+        ...(args.teamId ? { team: { id: { eq: args.teamId } } } : {}),
+      };
+
+      const connection = await client.executeSdk(
+        'cycles',
+        () => client.sdk.cycles({
+          filter,
+          first: 1,
+        })
+      );
+
+      const mapped = await mapConnection(connection, cycle => this.mapCycle(cycle));
+      const cycle = mapped.nodes[0] ?? null;
+
+      return this.createStructuredResponse(
+        cycle
+          ? `Fetched current cycle ${String(cycle.name ?? cycle.id ?? 'cycle')}`
+          : 'No active cycle found',
+        {
+          cycle,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get current cycle');
+    }
+  }
+
+  private async mapCycle(cycle: unknown): Promise<Record<string, unknown>> {
+    const record = asRecord(cycle);
+    const team = await resolveValue(record.team as Promise<unknown> | unknown);
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      number: getNumber(record, 'number'),
+      startsAt: getDateString(record, 'startsAt'),
+      endsAt: getDateString(record, 'endsAt'),
+      completedAt: getDateString(record, 'completedAt'),
+      createdAt: getDateString(record, 'createdAt'),
+      updatedAt: getDateString(record, 'updatedAt'),
+      isActive: getBoolean(record, 'isActive'),
+      progress: getNumber(record, 'progress'),
+      team: this.mapTeam(team),
+    });
+  }
+
+  private mapTeam(team: unknown): Record<string, unknown> | undefined {
+    if (!team) {
+      return undefined;
+    }
+
+    const record = asRecord(team);
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      key: getString(record, 'key'),
+    });
+  }
+}
diff --git a/src/features/cycles/types/cycle.types.ts b/src/features/cycles/types/cycle.types.ts
new file mode 100644
index 0000000..8ff2c5e
--- /dev/null
+++ b/src/features/cycles/types/cycle.types.ts
@@ -0,0 +1,15 @@
+export interface GetCycleInput {
+  id: string;
+}
+
+export interface ListCyclesInput {
+  filter?: Record<string, unknown>;
+  teamId?: string;
+  first?: number;
+  after?: string;
+}
+
+export interface GetCurrentCycleInput {
+  filter?: Record<string, unknown>;
+  teamId?: string;
+}
diff --git a/src/features/issues/handlers/issue.handler.ts b/src/features/issues/handlers/issue.handler.ts
index 737ad8b..b214a6f 100644
--- a/src/features/issues/handlers/issue.handler.ts
+++ b/src/features/issues/handlers/issue.handler.ts
@@ -1,256 +1,607 @@
+import { ErrorCode, McpError } from '@modelcontextprotocol/sdk/types.js';
 import { BaseHandler } from '../../../core/handlers/base.handler.js';
 import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
+import { mapWithConcurrencyLimit } from '../../../core/concurrency.js';
 import { LinearAuth } from '../../../auth.js';
-import { LinearGraphQLClient } from '../../../graphql/client.js';
 import {
-  IssueHandlerMethods,
+  asRecord,
+  callFetchMethod,
+  compactObject,
+  getBoolean,
+  getDateString,
+  getNumber,
+  getString,
+  mapConnection,
+  resolveValue,
+  toPageInfo,
+} from '../../../types/sdk.utils.js';
+import {
+  BulkUpdateIssuesInput,
   CreateIssueInput,
+  CreateIssueRelationInput,
   CreateIssuesInput,
-  BulkUpdateIssuesInput,
-  SearchIssuesInput,
   DeleteIssueInput,
+  DeleteIssueRelationInput,
   DeleteIssuesInput,
-  CreateIssueResponse,
-  CreateIssuesResponse,
-  UpdateIssuesResponse,
-  SearchIssuesResponse,
-  DeleteIssueResponse,
-  Issue,
-  IssueBatchResponse
+  GetIssueInput,
+  IssueHandlerMethods,
+  ListIssuesInput,
+  SearchIssuesInput,
 } from '../types/issue.types.js';
 
-/**
- * Handler for issue-related operations.
- * Manages creating, updating, searching, and deleting issues.
- */
+export const ISSUE_BULK_CONCURRENCY_LIMIT = 5;
+
 export class IssueHandler extends BaseHandler implements IssueHandlerMethods {
-  constructor(auth: LinearAuth, graphqlClient?: LinearGraphQLClient) {
-    super(auth, graphqlClient);
+  constructor(auth: LinearAuth) {
+    super(auth);
   }
 
-  /**
-   * Creates a single issue.
-   */
-  async handleCreateIssue(args: CreateIssueInput): Promise<BaseToolResponse> {
+  async handleGetIssue(args: GetIssueInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
-      this.validateRequiredParams(args, ['title', 'description', 'teamId']);
-
-      // Process input to ensure correct types
-      const processedArgs = { ...args };
-      
-      // Convert estimate to integer if present
-      if (processedArgs.estimate !== undefined) {
-        processedArgs.estimate = parseInt(String(processedArgs.estimate), 10);
-        
-        // If parsing fails, remove the estimate field
-        if (isNaN(processedArgs.estimate)) {
-          delete processedArgs.estimate;
-        }
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const issueReference = typeof client.findIssueByIdentifier === 'function'
+        ? await client.findIssueByIdentifier(args.id)
+        : undefined;
+      const issueId = getString(issueReference, 'id') ?? args.id;
+      const issue = await client.executeSdk('issue', () => client.sdk.issue(issueId));
+      if (Object.keys(asRecord(issue)).length === 0) {
+        throw new Error(`Issue ${args.id} was not found`);
       }
-      
-      // Convert priority to integer if present
-      if (processedArgs.priority !== undefined) {
-        processedArgs.priority = parseInt(String(processedArgs.priority), 10);
-        
-        // If parsing fails or out of range, use default priority
-        if (isNaN(processedArgs.priority) || processedArgs.priority < 0 || processedArgs.priority > 4) {
-          processedArgs.priority = 0;
+      const issueData = await this.mapIssueDetail(issue);
+
+      return this.createStructuredResponse(
+        `Fetched issue ${getString(issueData, 'identifier') ?? args.id}`,
+        {
+          issue: issueData,
         }
-      }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get issue');
+    }
+  }
 
-      const result = await client.createIssue(processedArgs) as CreateIssueResponse;
+  async handleCreateIssue(args: CreateIssueInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['title', 'teamId']);
 
-      if (!result.issueCreate.success || !result.issueCreate.issue) {
-        throw new Error('Failed to create issue');
-      }
+      const payload = await client.createIssue(args);
 
-      const issue = result.issueCreate.issue;
+      const issue = await resolveValue(asRecord(payload).issue as Promise<unknown> | unknown);
+      const issueData = await this.mapIssueSummary(issue);
 
-      return this.createResponse(
-        `Successfully created issue\n` +
-        `Issue: ${issue.identifier}\n` +
-        `Title: ${issue.title}\n` +
-        `URL: ${issue.url}\n` +
-        `Project: ${issue.project ? issue.project.name : 'None'}`
+      return this.createStructuredResponse(
+        `Created issue ${getString(issueData, 'identifier') ?? getString(issueData, 'id') ?? 'unknown'}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          issue: issueData,
+        }
       );
     } catch (error) {
-      this.handleError(error, 'create issue');
+      return this.handleError(error, 'create issue');
     }
   }
 
-  /**
-   * Creates multiple issues in bulk.
-   */
   async handleCreateIssues(args: CreateIssuesInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['issues']);
 
-      if (!Array.isArray(args.issues)) {
-        throw new Error('Issues parameter must be an array');
+      if (!Array.isArray(args.issues) || args.issues.length === 0) {
+        throw new Error('issues must be a non-empty array');
       }
 
-      const result = await client.createIssues(args.issues) as IssueBatchResponse;
-
-      if (!result.issueBatchCreate.success) {
-        throw new Error('Failed to create issues');
-      }
+      const payload = await client.executeSdk(
+        'createIssueBatch',
+        () => client.sdk.createIssueBatch({ issues: args.issues })
+      );
 
-      const createdIssues = result.issueBatchCreate.issues as Issue[];
+      const issues = Array.isArray(asRecord(payload).issues)
+        ? asRecord(payload).issues as unknown[]
+        : [];
 
-      return this.createResponse(
-        `Successfully created ${createdIssues.length} issues:\n` +
-        createdIssues.map(issue => 
-          `- ${issue.identifier}: ${issue.title}\n  URL: ${issue.url}`
-        ).join('\n')
+      return this.createStructuredResponse(
+        `Created ${issues.length} issues`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          issues: await Promise.all(issues.map(issue => this.mapIssueSummary(issue))),
+          lastSyncId: getNumber(payload, 'lastSyncId'),
+        }
       );
     } catch (error) {
-      this.handleError(error, 'create issues');
+      return this.handleError(error, 'create issues');
     }
   }
 
-  /**
-   * Updates multiple issues in bulk.
-   */
   async handleBulkUpdateIssues(args: BulkUpdateIssuesInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['issueIds', 'update']);
 
-      if (!Array.isArray(args.issueIds)) {
-        throw new Error('IssueIds parameter must be an array');
+      if (!Array.isArray(args.issueIds) || args.issueIds.length === 0) {
+        throw new Error('issueIds must be a non-empty array');
       }
 
-      let result;
-      
-      // Handle single issue update vs bulk update differently
-      if (args.issueIds.length === 1) {
-        // For a single issue, use updateIssue which uses the correct 'id' parameter
-        result = await client.updateIssue(args.issueIds[0], args.update) as UpdateIssuesResponse;
-        
-        if (!result.issueUpdate.success) {
-          throw new Error('Failed to update issue');
+      const results = await mapWithConcurrencyLimit(
+        args.issueIds,
+        ISSUE_BULK_CONCURRENCY_LIMIT,
+        async issueId => {
+          const payload = await client.executeSdk(
+            'updateIssue',
+            () => client.sdk.updateIssue(issueId, args.update)
+          );
+          const issue = await resolveValue(asRecord(payload).issue as Promise<unknown> | unknown);
+          return {
+            success: getBoolean(payload, 'success') ?? true,
+            issue: await this.mapIssueSummary(issue),
+          };
         }
-        
-        return this.createResponse(`Successfully updated issue`);
-      } else {
-        // For multiple issues, use updateIssues
-        result = await client.updateIssues(args.issueIds, args.update) as UpdateIssuesResponse;
-        
-        if (!result.issueUpdate.success) {
-          throw new Error('Failed to update issues');
+      );
+
+      const allSuccess = results.every(r => r.success);
+      const issueData = results.map(r => r.issue);
+
+      return this.createStructuredResponse(
+        `Updated ${issueData.length} issue${issueData.length === 1 ? '' : 's'}`,
+        {
+          success: allSuccess,
+          issues: issueData,
         }
-        
-        const updatedCount = result.issueUpdate.issues.length;
-        return this.createResponse(`Successfully updated ${updatedCount} issues`);
-      }
+      );
     } catch (error) {
-      this.handleError(error, 'update issues');
+      return this.handleError(error, 'update issues');
     }
   }
 
-  /**
-   * Searches for issues with filtering and pagination.
-   */
-  async handleSearchIssues(args: SearchIssuesInput): Promise<BaseToolResponse> {
+  async handleListIssues(args: ListIssuesInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
-
-      const filter: Record<string, unknown> = {};
-      
-      if (args.query) {
-        // For both identifier and text searches, use the title filter with contains
-        // This is a workaround since Linear API doesn't directly support identifier filtering
-        filter.or = [
-          { title: { containsIgnoreCase: args.query } },
-          { number: { eq: this.extractIssueNumber(args.query) } }
-        ];
-      }
-      
-      if (args.filter?.project?.id?.eq) {
-        filter.project = { id: { eq: args.filter.project.id.eq } };
-      }
-      if (args.teamIds) {
-        filter.team = { id: { in: args.teamIds } };
-      }
-      if (args.assigneeIds) {
-        filter.assignee = { id: { in: args.assigneeIds } };
-      }
-      if (args.states) {
-        filter.state = { name: { in: args.states } };
-      }
-      if (typeof args.priority === 'number') {
-        filter.priority = { eq: args.priority };
-      }
+      const client = await this.verifyAuth();
+      this.validateStateFilterConflict(args);
+      const filter = this.buildIssueFilter(args);
+
+      const connection = await client.executeSdk(
+        'issues',
+        () => client.sdk.issues({
+          filter: Object.keys(filter).length > 0 ? filter : undefined,
+          first: args.first ?? 50,
+          after: args.after,
+        })
+      );
 
-      const result = await client.searchIssues(
-        filter,
-        args.first || 50,
-        args.after,
-        args.orderBy || 'updatedAt'
-      ) as SearchIssuesResponse;
+      const mapped = await mapConnection(connection, issue => this.mapIssueSummary(issue));
 
-      return this.createJsonResponse(result);
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} issues`,
+        {
+          issues: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'search issues');
+      return this.handleError(error, 'list issues');
     }
   }
 
-  /**
-   * Helper method to extract the issue number from an identifier (e.g., "IDE-11" -> 11)
-   */
-  private extractIssueNumber(query: string): number | null {
-    const match = query.match(/^[A-Z]+-(\d+)$/);
-    if (match && match[1]) {
-      return parseInt(match[1], 10);
+  async handleSearchIssues(args: SearchIssuesInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['query']);
+      this.validateStateFilterConflict(args);
+      const filter = this.buildIssueFilter(args);
+      const searchOptions: Omit<SearchIssuesInput, 'query'> = {
+        first: args.first ?? 50,
+      };
+
+      if (Object.keys(filter).length > 0) {
+        searchOptions.filter = filter;
+      }
+
+      if (args.after !== undefined) {
+        searchOptions.after = args.after;
+      }
+
+      const payload = await client.searchIssues(args.query, searchOptions);
+      const nodes = payload.issues.nodes ?? [];
+
+      return this.createStructuredResponse(
+        `Found ${nodes.length} issue search results`,
+        {
+          issues: await Promise.all(nodes.map(issue => this.mapIssueSummary(issue))),
+          pageInfo: payload.issues.pageInfo,
+          totalCount: payload.totalCount,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'search issues');
     }
-    return null;
   }
 
-  /**
-   * Deletes a single issue.
-   */
   async handleDeleteIssue(args: DeleteIssueInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['id']);
 
-      const result = await client.deleteIssue(args.id) as DeleteIssueResponse;
-
-      if (!result.issueDelete.success) {
-        throw new Error('Failed to delete issue');
-      }
+      const payload = await client.executeSdk(
+        'deleteIssue',
+        () => client.sdk.deleteIssue(args.id)
+      );
 
-      return this.createResponse(`Successfully deleted issue ${args.id}`);
+      return this.createStructuredResponse(
+        `Deleted issue ${args.id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          id: args.id,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'delete issue');
+      return this.handleError(error, 'delete issue');
     }
   }
 
-  /**
-   * Deletes multiple issues in bulk.
-   */
   async handleDeleteIssues(args: DeleteIssuesInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['ids']);
 
-      if (!Array.isArray(args.ids)) {
-        throw new Error('Ids parameter must be an array');
+      if (!Array.isArray(args.ids) || args.ids.length === 0) {
+        throw new Error('ids must be a non-empty array');
       }
 
-      const result = await client.deleteIssues(args.ids) as DeleteIssueResponse;
+      const results = await mapWithConcurrencyLimit(
+        args.ids,
+        ISSUE_BULK_CONCURRENCY_LIMIT,
+        async id => {
+          try {
+            const payload = await client.executeSdk('deleteIssue', () => client.sdk.deleteIssue(id));
+
+            if (!(getBoolean(payload, 'success') ?? true)) {
+              return {
+                id,
+                success: false,
+                message: 'Issue deletion returned success false.',
+              };
+            }
 
-      if (!result.issueDelete.success) {
-        throw new Error('Failed to delete issues');
+            return {
+              id,
+              success: true,
+            };
+          } catch (error) {
+            return {
+              id,
+              success: false,
+              message: this.getDeleteFailureMessage(error),
+            };
+          }
+        }
+      );
+
+      const deletedIds = results.filter(result => result.success).map(result => result.id);
+      const failed = results
+        .filter((result): result is { id: string; success: false; message: string } => !result.success)
+        .map(result => ({
+          id: result.id,
+          message: result.message,
+        }));
+
+      if (failed.length > 0) {
+        return this.createErrorResponse(
+          `Deleted ${deletedIds.length} of ${args.ids.length} issues`,
+          {
+            success: false,
+            requestedIds: args.ids,
+            deletedIds,
+            failedIds: failed.map(result => result.id),
+            failed,
+            error: {
+              type: 'partial',
+              message: 'One or more requested issues could not be deleted.',
+            },
+          }
+        );
       }
 
-      return this.createResponse(
-        `Successfully deleted ${args.ids.length} issues: ${args.ids.join(', ')}`
+      return this.createStructuredResponse(
+        `Deleted ${args.ids.length} issues`,
+        {
+          success: true,
+          ids: args.ids,
+          deletedIds,
+        }
       );
     } catch (error) {
-      this.handleError(error, 'delete issues');
+      return this.handleError(error, 'delete issues');
     }
   }
+
+  async handleCreateIssueRelation(args: CreateIssueRelationInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['issueId', 'relatedIssueId', 'type']);
+
+      const payload = await client.executeSdk(
+        'createIssueRelation',
+        () => client.sdk.createIssueRelation(args as never)
+      );
+
+      const relation = await resolveValue(asRecord(payload).issueRelation as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        'Created issue relation',
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          relation: await this.mapIssueRelation(relation),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'create issue relation');
+    }
+  }
+
+  async handleDeleteIssueRelation(args: DeleteIssueRelationInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const payload = await client.executeSdk(
+        'deleteIssueRelation',
+        () => client.sdk.deleteIssueRelation(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Deleted issue relation ${args.id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          id: args.id,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'delete issue relation');
+    }
+  }
+
+  private buildIssueFilter(args: ListIssuesInput): Record<string, unknown> {
+    const filter = {
+      ...(args.filter ?? {}),
+    };
+
+    if (args.teamId) {
+      filter.team = { id: { eq: args.teamId } };
+    }
+
+    if (args.projectId) {
+      filter.project = { id: { eq: args.projectId } };
+    }
+
+    if (args.assigneeId) {
+      filter.assignee = { id: { eq: args.assigneeId } };
+    }
+
+    if (args.stateId) {
+      filter.state = { id: { eq: args.stateId } };
+    }
+
+    if (args.states?.length) {
+      filter.state = { name: { in: args.states } };
+    }
+
+    if (typeof args.priority === 'number') {
+      filter.priority = { eq: args.priority };
+    }
+
+    if (args.cycleId) {
+      filter.cycle = { id: { eq: args.cycleId } };
+    }
+
+    return filter;
+  }
+
+  private validateStateFilterConflict(
+    args: Pick<ListIssuesInput, 'stateId' | 'states'>
+  ): void {
+    if (args.stateId && args.states?.length) {
+      throw new McpError(
+        ErrorCode.InvalidParams,
+        'stateId and states cannot both be provided in the same issue query.'
+      );
+    }
+  }
+
+  private getDeleteFailureMessage(error: unknown): string {
+    return error instanceof Error ? error.message : 'Unknown delete failure';
+  }
+
+  private async mapIssueDetail(issue: unknown): Promise<Record<string, unknown>> {
+    const issueRecord = asRecord(issue);
+    const currentIssueId = getString(issueRecord, 'id');
+    const assignee = await resolveValue(issueRecord.assignee as Promise<unknown> | unknown);
+    const parent = await resolveValue(issueRecord.parent as Promise<unknown> | unknown);
+    const labels = await callFetchMethod(issueRecord, 'labels', { first: 50 });
+    const children = await callFetchMethod(issueRecord, 'children', { first: 50 });
+    const relations = await callFetchMethod(issueRecord, 'relations', { first: 50 });
+    const inverseRelations = await callFetchMethod(issueRecord, 'inverseRelations', { first: 50 });
+    const subscribers = await callFetchMethod(issueRecord, 'subscribers', { first: 50 });
+
+    return compactObject({
+      ...(await this.mapIssueSummary(issue)),
+      description: getString(issueRecord, 'description'),
+      assignee: this.mapUserReference(assignee),
+      parent: parent ? await this.mapIssueReference(parent) : undefined,
+      children: children
+        ? (await mapConnection(children, child => this.mapIssueReference(child))).nodes
+        : undefined,
+      labels: labels
+        ? (await mapConnection(labels, label => this.mapLabel(label))).nodes
+        : undefined,
+      relations: [
+        ...(relations
+          ? (await mapConnection(relations, relation => this.mapIssueRelation(relation, currentIssueId))).nodes
+          : []),
+        ...(inverseRelations
+          ? (await mapConnection(inverseRelations, relation => this.mapIssueRelation(relation, currentIssueId))).nodes
+          : []),
+      ],
+      subscribers: subscribers
+        ? (await mapConnection(subscribers, subscriber => this.mapUserReference(subscriber) ?? {})).nodes
+        : undefined,
+    });
+  }
+
+  private async mapIssueSummary(issue: unknown): Promise<Record<string, unknown>> {
+    const issueRecord = asRecord(issue);
+    const state = await resolveValue(issueRecord.state as Promise<unknown> | unknown);
+    const team = await resolveValue(issueRecord.team as Promise<unknown> | unknown);
+    const project = await resolveValue(issueRecord.project as Promise<unknown> | unknown);
+    const cycle = await resolveValue(issueRecord.cycle as Promise<unknown> | unknown);
+    const milestone = await resolveValue(issueRecord.projectMilestone as Promise<unknown> | unknown);
+    const parent = await resolveValue(issueRecord.parent as Promise<unknown> | unknown);
+
+    return compactObject({
+      id: getString(issueRecord, 'id'),
+      identifier: getString(issueRecord, 'identifier'),
+      title: getString(issueRecord, 'title'),
+      url: getString(issueRecord, 'url'),
+      priority: getNumber(issueRecord, 'priority'),
+      estimate: getNumber(issueRecord, 'estimate'),
+      dueDate: getString(issueRecord, 'dueDate'),
+      createdAt: getDateString(issueRecord, 'createdAt'),
+      updatedAt: getDateString(issueRecord, 'updatedAt'),
+      state: this.mapWorkflowState(state),
+      team: this.mapTeamReference(team),
+      parent: parent ? await this.mapIssueReference(parent) : undefined,
+      project: this.mapProjectReference(project),
+      cycle: this.mapCycleReference(cycle),
+      milestone: this.mapMilestoneReference(milestone),
+    });
+  }
+
+  private async mapIssueReference(issue: unknown): Promise<Record<string, unknown>> {
+    const issueRecord = asRecord(issue);
+    return compactObject({
+      id: getString(issueRecord, 'id'),
+      identifier: getString(issueRecord, 'identifier'),
+      title: getString(issueRecord, 'title'),
+      url: getString(issueRecord, 'url'),
+    });
+  }
+
+  private async mapIssueRelation(
+    relation: unknown,
+    currentIssueId?: string
+  ): Promise<Record<string, unknown>> {
+    const relationRecord = asRecord(relation);
+    const issue = await resolveValue(relationRecord.issue as Promise<unknown> | unknown);
+    const relatedIssue = await resolveValue(relationRecord.relatedIssue as Promise<unknown> | unknown);
+    const issueReference = issue ? await this.mapIssueReference(issue) : undefined;
+    const relatedIssueReference = relatedIssue ? await this.mapIssueReference(relatedIssue) : undefined;
+
+    const linkedIssue = issueReference && getString(issueReference, 'id') === currentIssueId
+      ? relatedIssueReference
+      : relatedIssueReference && getString(relatedIssueReference, 'id') === currentIssueId
+        ? issueReference
+        : relatedIssueReference ?? issueReference;
+
+    return compactObject({
+      id: getString(relationRecord, 'id'),
+      type: getString(relationRecord, 'type'),
+      linkedIssue,
+      issue: issueReference,
+      relatedIssue: relatedIssueReference,
+    });
+  }
+
+  private mapWorkflowState(state: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(state);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      type: getString(record, 'type'),
+      color: getString(record, 'color'),
+    });
+  }
+
+  private mapLabel(label: unknown): Record<string, unknown> {
+    const record = asRecord(label);
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      color: getString(record, 'color'),
+      description: getString(record, 'description'),
+    });
+  }
+
+  private mapUserReference(user: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(user);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      email: getString(record, 'email'),
+      displayName: getString(record, 'displayName'),
+    });
+  }
+
+  private mapTeamReference(team: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(team);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      key: getString(record, 'key'),
+    });
+  }
+
+  private mapProjectReference(project: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(project);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      url: getString(record, 'url'),
+    });
+  }
+
+  private mapCycleReference(cycle: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(cycle);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      number: getNumber(record, 'number'),
+      startsAt: getDateString(record, 'startsAt'),
+      endsAt: getDateString(record, 'endsAt'),
+      completedAt: getDateString(record, 'completedAt'),
+    });
+  }
+
+  private mapMilestoneReference(milestone: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(milestone);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      targetDate: getString(record, 'targetDate'),
+    });
+  }
 }
diff --git a/src/features/issues/types/issue.types.ts b/src/features/issues/types/issue.types.ts
index 2475e8c..ae0fc7f 100644
--- a/src/features/issues/types/issue.types.ts
+++ b/src/features/issues/types/issue.types.ts
@@ -1,17 +1,24 @@
 import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
 
-/**
- * Input types for issue operations
- */
-
 export interface CreateIssueInput {
-  title: string;
-  description: string;
+  title?: string;
+  description?: string;
   teamId: string;
   assigneeId?: string;
   priority?: number;
-  projectId?: string;
   estimate?: number;
+  projectId?: string;
+  projectMilestoneId?: string;
+  dueDate?: string;
+  cycleId?: string;
+  labelIds?: string[];
+  parentId?: string;
+  subscriberIds?: string[];
+  stateId?: string;
+  delegateId?: string;
+  templateId?: string;
+  createAsUser?: string;
+  displayIconUrl?: string;
 }
 
 export interface CreateIssuesInput {
@@ -23,8 +30,21 @@ export interface UpdateIssueInput {
   description?: string;
   assigneeId?: string;
   priority?: number;
-  projectId?: string;
+  estimate?: number;
+  projectId?: string | null;
+  projectMilestoneId?: string;
+  dueDate?: string;
+  cycleId?: string;
+  labelIds?: string[];
+  addedLabelIds?: string[];
+  removedLabelIds?: string[];
+  parentId?: string;
+  subscriberIds?: string[];
   stateId?: string;
+  delegateId?: string;
+  templateId?: string;
+  teamId?: string;
+  trashed?: boolean;
 }
 
 export interface BulkUpdateIssuesInput {
@@ -32,24 +52,38 @@ export interface BulkUpdateIssuesInput {
   update: UpdateIssueInput;
 }
 
-export interface SearchIssuesInput {
-  query?: string;
-  filter?: {
-    project?: {
-      id?: {
-        eq?: string;
-      };
-    };
-  };
-  teamIds?: string[];
-  assigneeIds?: string[];
+export interface GetIssueInput {
+  id: string;
+}
+
+export interface ListIssuesInput {
+  filter?: Record<string, unknown>;
+  teamId?: string;
+  projectId?: string;
+  assigneeId?: string;
+  stateId?: string;
   states?: string[];
   priority?: number;
+  cycleId?: string;
   first?: number;
   after?: string;
   orderBy?: string;
 }
 
+export interface SearchIssuesInput extends Omit<ListIssuesInput, 'orderBy'> {
+  query: string;
+}
+
+export interface CreateIssueRelationInput {
+  issueId: string;
+  relatedIssueId: string;
+  type: string;
+}
+
+export interface DeleteIssueRelationInput {
+  id: string;
+}
+
 export interface DeleteIssueInput {
   id: string;
 }
@@ -58,18 +92,17 @@ export interface DeleteIssuesInput {
   ids: string[];
 }
 
-/**
- * Response types for issue operations
- */
-
 export interface Issue {
-  id: string;
-  identifier: string;
-  title: string;
-  url: string;
-  project?: {
-    name: string;
-  };
+  id?: string;
+  identifier?: string;
+  title?: string;
+  description?: string;
+  url?: string;
+  priority?: number;
+  estimate?: number;
+  dueDate?: string;
+  createdAt?: string;
+  updatedAt?: string;
 }
 
 export interface CreateIssueResponse {
@@ -79,18 +112,10 @@ export interface CreateIssueResponse {
   };
 }
 
-export interface CreateIssuesResponse {
-  issueCreate: {
-    success: boolean;
-    issues: Issue[];
-  };
-}
-
-export interface IssueBatchResponse {
-  issueBatchCreate: {
+export interface UpdateIssueResponse {
+  issueUpdate: {
     success: boolean;
-    issues: Issue[];
-    lastSyncId: number;
+    issue?: Issue;
   };
 }
 
@@ -109,6 +134,7 @@ export interface SearchIssuesResponse {
     };
     nodes: Issue[];
   };
+  totalCount?: number;
 }
 
 export interface DeleteIssueResponse {
@@ -117,15 +143,29 @@ export interface DeleteIssueResponse {
   };
 }
 
-/**
- * Handler method types
- */
+export interface DeleteIssuesResponse {
+  issueDelete: {
+    success: boolean;
+  };
+}
+
+export interface IssueBatchResponse {
+  issueBatchCreate: {
+    success: boolean;
+    issues: Issue[];
+    lastSyncId?: number;
+  };
+}
 
 export interface IssueHandlerMethods {
+  handleGetIssue(args: GetIssueInput): Promise<BaseToolResponse>;
   handleCreateIssue(args: CreateIssueInput): Promise<BaseToolResponse>;
   handleCreateIssues(args: CreateIssuesInput): Promise<BaseToolResponse>;
   handleBulkUpdateIssues(args: BulkUpdateIssuesInput): Promise<BaseToolResponse>;
+  handleListIssues(args: ListIssuesInput): Promise<BaseToolResponse>;
   handleSearchIssues(args: SearchIssuesInput): Promise<BaseToolResponse>;
   handleDeleteIssue(args: DeleteIssueInput): Promise<BaseToolResponse>;
   handleDeleteIssues(args: DeleteIssuesInput): Promise<BaseToolResponse>;
+  handleCreateIssueRelation(args: CreateIssueRelationInput): Promise<BaseToolResponse>;
+  handleDeleteIssueRelation(args: DeleteIssueRelationInput): Promise<BaseToolResponse>;
 }
diff --git a/src/features/milestones/handlers/milestone.handler.ts b/src/features/milestones/handlers/milestone.handler.ts
index 2de1b0d..e960902 100644
--- a/src/features/milestones/handlers/milestone.handler.ts
+++ b/src/features/milestones/handlers/milestone.handler.ts
@@ -1,7 +1,6 @@
 import { BaseHandler } from '../../../core/handlers/base.handler.js';
 import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
 import { LinearAuth } from '../../../auth.js';
-import { LinearGraphQLClient } from '../../../graphql/client.js';
 import { ProjectMilestone } from '../types/milestone.types.js';
 
 /**
@@ -9,8 +8,8 @@ import { ProjectMilestone } from '../types/milestone.types.js';
  * Manages creating, updating, deleting, and retrieving project milestone information.
  */
 export class MilestoneHandler extends BaseHandler {
-  constructor(auth: LinearAuth, graphqlClient?: LinearGraphQLClient) {
-    super(auth, graphqlClient);
+  constructor(auth: LinearAuth) {
+    super(auth);
   }
 
   /**
@@ -18,7 +17,7 @@ export class MilestoneHandler extends BaseHandler {
    */
   async handleCreateProjectMilestone(args: any): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['name', 'projectId']);
 
       const result = await client.createProjectMilestone({
@@ -36,26 +35,15 @@ export class MilestoneHandler extends BaseHandler {
 
       const { projectMilestone } = result.projectMilestoneCreate;
 
-      const response = [
-        `Successfully created project milestone`,
-        `Name: ${projectMilestone.name}`,
-        `Project: ${projectMilestone.project.name}`,
-        `Status: ${projectMilestone.status}`,
-      ];
-
-      if (projectMilestone.description) {
-        response.push(`Description: ${projectMilestone.description}`);
-      }
-
-      if (projectMilestone.targetDate) {
-        response.push(`Target Date: ${projectMilestone.targetDate}`);
-      }
-
-      response.push(`Progress: ${projectMilestone.progress}%`);
-
-      return this.createResponse(response.join('\n'));
+      return this.createStructuredResponse(
+        `Created project milestone ${projectMilestone.name}`,
+        {
+          success: true,
+          projectMilestone,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'create project milestone');
+      return this.handleError(error, 'create project milestone');
     }
   }
 
@@ -64,7 +52,7 @@ export class MilestoneHandler extends BaseHandler {
    */
   async handleUpdateProjectMilestone(args: any): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['id']);
 
       const updateInput: any = {};
@@ -82,25 +70,15 @@ export class MilestoneHandler extends BaseHandler {
 
       const { projectMilestone } = result.projectMilestoneUpdate;
 
-      const response = [
-        `Successfully updated project milestone`,
-        `Name: ${projectMilestone.name}`,
-        `Project: ${projectMilestone.project.name}`,
-        `Status: ${projectMilestone.status}`,
-        `Progress: ${projectMilestone.progress}%`,
-      ];
-
-      if (projectMilestone.description) {
-        response.push(`Description: ${projectMilestone.description}`);
-      }
-
-      if (projectMilestone.targetDate) {
-        response.push(`Target Date: ${projectMilestone.targetDate}`);
-      }
-
-      return this.createResponse(response.join('\n'));
+      return this.createStructuredResponse(
+        `Updated project milestone ${projectMilestone.name}`,
+        {
+          success: true,
+          projectMilestone,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'update project milestone');
+      return this.handleError(error, 'update project milestone');
     }
   }
 
@@ -109,7 +87,7 @@ export class MilestoneHandler extends BaseHandler {
    */
   async handleDeleteProjectMilestone(args: any): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['id']);
 
       const result = await client.deleteProjectMilestone(args.id);
@@ -118,9 +96,15 @@ export class MilestoneHandler extends BaseHandler {
         throw new Error('Failed to delete project milestone');
       }
 
-      return this.createResponse(`Successfully deleted project milestone with ID: ${args.id}`);
+      return this.createStructuredResponse(
+        `Deleted project milestone ${args.id}`,
+        {
+          success: true,
+          id: args.id,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'delete project milestone');
+      return this.handleError(error, 'delete project milestone');
     }
   }
 
@@ -129,7 +113,7 @@ export class MilestoneHandler extends BaseHandler {
    */
   async handleGetProjectMilestone(args: any): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['id']);
 
       const result = await client.getProjectMilestone(args.id);
@@ -142,9 +126,12 @@ export class MilestoneHandler extends BaseHandler {
         }
       };
 
-      return this.createJsonResponse(processedResult);
+      return this.createStructuredResponse(
+        `Fetched project milestone ${result.projectMilestone.name}`,
+        processedResult as Record<string, unknown>
+      );
     } catch (error) {
-      this.handleError(error, 'get project milestone info');
+      return this.handleError(error, 'get project milestone info');
     }
   }
 
@@ -153,7 +140,7 @@ export class MilestoneHandler extends BaseHandler {
    */
   async handleSearchProjectMilestones(args: any): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
 
       const filter: any = {};
       
@@ -187,9 +174,12 @@ export class MilestoneHandler extends BaseHandler {
         }
       };
 
-      return this.createJsonResponse(processedResult);
+      return this.createStructuredResponse(
+        `Found ${processedResult.projectMilestones.nodes.length} project milestones`,
+        processedResult as Record<string, unknown>
+      );
     } catch (error) {
-      this.handleError(error, 'search project milestones');
+      return this.handleError(error, 'search project milestones');
     }
   }
 
@@ -198,7 +188,7 @@ export class MilestoneHandler extends BaseHandler {
    */
   async handleGetProjectMilestones(args: any): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['projectId']);
 
       const result = await client.searchProjectMilestones({
@@ -221,9 +211,12 @@ export class MilestoneHandler extends BaseHandler {
         }
       };
 
-      return this.createJsonResponse(processedResult);
+      return this.createStructuredResponse(
+        `Fetched ${processedResult.projectMilestones.nodes.length} milestones for project ${args.projectId}`,
+        processedResult as Record<string, unknown>
+      );
     } catch (error) {
-      this.handleError(error, 'get project milestones');
+      return this.handleError(error, 'get project milestones');
     }
   }
 
@@ -232,7 +225,7 @@ export class MilestoneHandler extends BaseHandler {
    */
   async handleCreateProjectMilestones(args: any): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['projectId', 'milestones']);
 
       if (!Array.isArray(args.milestones) || args.milestones.length === 0) {
@@ -273,29 +266,16 @@ export class MilestoneHandler extends BaseHandler {
         }
       }
 
-      const response = [
-        `Bulk milestone creation completed`,
-        `Successfully created: ${results.length} milestones`,
-        `Errors: ${errors.length}`,
-      ];
-
-      if (results.length > 0) {
-        response.push('\nCreated milestones:');
-        results.forEach(result => {
-          response.push(`- ${result.name} (ID: ${result.id})`);
-        });
-      }
-
-      if (errors.length > 0) {
-        response.push('\nErrors:');
-        errors.forEach(error => {
-          response.push(`- ${error}`);
-        });
-      }
-
-      return this.createResponse(response.join('\n'));
+      return this.createStructuredResponse(
+        `Bulk milestone creation created ${results.length} milestones${errors.length > 0 ? ` with ${errors.length} errors` : ''}`,
+        {
+          success: errors.length === 0,
+          created: results,
+          errors,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'create project milestones');
+      return this.handleError(error, 'create project milestones');
     }
   }
 
diff --git a/src/features/portfolio/handlers/portfolio.handler.ts b/src/features/portfolio/handlers/portfolio.handler.ts
new file mode 100644
index 0000000..8b950a6
--- /dev/null
+++ b/src/features/portfolio/handlers/portfolio.handler.ts
@@ -0,0 +1,288 @@
+import { LinearAuth } from '../../../auth.js';
+import { BaseHandler } from '../../../core/handlers/base.handler.js';
+import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
+import {
+  asRecord,
+  compactObject,
+  getArray,
+  getBoolean,
+  getDateString,
+  getNumber,
+  getString,
+  mapConnection,
+  resolveValue,
+} from '../../../types/sdk.utils.js';
+import {
+  CreateCustomerInput,
+  CreateInitiativeInput,
+  GetCustomerInput,
+  GetInitiativeInput,
+  ListCustomersInput,
+  ListInitiativesInput,
+  UpdateCustomerInput,
+  UpdateInitiativeInput,
+} from '../types/portfolio.types.js';
+
+export class PortfolioHandler extends BaseHandler {
+  constructor(auth: LinearAuth) {
+    super(auth);
+  }
+
+  async handleGetInitiative(args: GetInitiativeInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const initiative = await client.executeSdk(
+        'initiative',
+        () => client.sdk.initiative(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Fetched initiative ${getString(initiative, 'name') ?? args.id}`,
+        {
+          initiative: await this.mapInitiative(initiative),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get initiative');
+    }
+  }
+
+  async handleListInitiatives(args: ListInitiativesInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const connection = await client.executeSdk(
+        'initiatives',
+        () => client.sdk.initiatives({
+          filter: args.filter,
+          first: args.first ?? 50,
+          after: args.after,
+        })
+      );
+
+      const mapped = await mapConnection(connection, initiative => this.mapInitiative(initiative));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} initiatives`,
+        {
+          initiatives: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list initiatives');
+    }
+  }
+
+  async handleCreateInitiative(args: CreateInitiativeInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['name']);
+
+      const payload = await client.executeSdk(
+        'createInitiative',
+        () => client.sdk.createInitiative(args)
+      );
+      const initiative = await resolveValue(asRecord(payload).initiative as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Created initiative ${getString(initiative, 'name') ?? args.name}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          initiative: await this.mapInitiative(initiative),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'create initiative');
+    }
+  }
+
+  async handleUpdateInitiative(args: UpdateInitiativeInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const { id, ...input } = args;
+      const payload = await client.executeSdk(
+        'updateInitiative',
+        () => client.sdk.updateInitiative(id, input)
+      );
+      const initiative = await resolveValue(asRecord(payload).initiative as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Updated initiative ${getString(initiative, 'name') ?? id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          initiative: await this.mapInitiative(initiative),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'update initiative');
+    }
+  }
+
+  async handleGetCustomer(args: GetCustomerInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const customer = await client.executeSdk(
+        'customer',
+        () => client.sdk.customer(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Fetched customer ${getString(customer, 'name') ?? args.id}`,
+        {
+          customer: await this.mapCustomer(customer),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get customer');
+    }
+  }
+
+  async handleListCustomers(args: ListCustomersInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const connection = await client.executeSdk(
+        'customers',
+        () => client.sdk.customers({
+          filter: args.filter,
+          first: args.first ?? 50,
+          after: args.after,
+        })
+      );
+
+      const mapped = await mapConnection(connection, customer => this.mapCustomer(customer));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} customers`,
+        {
+          customers: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list customers');
+    }
+  }
+
+  async handleCreateCustomer(args: CreateCustomerInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['name']);
+
+      const payload = await client.executeSdk(
+        'createCustomer',
+        () => client.sdk.createCustomer(args)
+      );
+      const customer = await resolveValue(asRecord(payload).customer as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Created customer ${getString(customer, 'name') ?? args.name}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          customer: await this.mapCustomer(customer),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'create customer');
+    }
+  }
+
+  async handleUpdateCustomer(args: UpdateCustomerInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const { id, ...input } = args;
+      const payload = await client.executeSdk(
+        'updateCustomer',
+        () => client.sdk.updateCustomer(id, input)
+      );
+      const customer = await resolveValue(asRecord(payload).customer as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Updated customer ${getString(customer, 'name') ?? id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          customer: await this.mapCustomer(customer),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'update customer');
+    }
+  }
+
+  private async mapInitiative(initiative: unknown): Promise<Record<string, unknown>> {
+    if (!initiative) {
+      return {};
+    }
+
+    const record = asRecord(initiative);
+    const owner = await resolveValue(record.owner as Promise<unknown> | unknown);
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      description: getString(record, 'description'),
+      content: getString(record, 'content'),
+      color: getString(record, 'color'),
+      icon: getString(record, 'icon'),
+      status: getString(record, 'status'),
+      sortOrder: getNumber(record, 'sortOrder'),
+      targetDate: getDateString(record, 'targetDate'),
+      targetDateResolution: getString(record, 'targetDateResolution'),
+      url: getString(record, 'url'),
+      createdAt: getDateString(record, 'createdAt'),
+      updatedAt: getDateString(record, 'updatedAt'),
+      owner: owner ? compactObject({
+        id: getString(owner, 'id'),
+        name: getString(owner, 'name'),
+        displayName: getString(owner, 'displayName'),
+      }) : undefined,
+    });
+  }
+
+  private async mapCustomer(customer: unknown): Promise<Record<string, unknown>> {
+    if (!customer) {
+      return {};
+    }
+
+    const record = asRecord(customer);
+    const owner = await resolveValue(record.owner as Promise<unknown> | unknown);
+    const status = await resolveValue(record.status as Promise<unknown> | unknown);
+    const tier = await resolveValue(record.tier as Promise<unknown> | unknown);
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      logoUrl: getString(record, 'logoUrl'),
+      domains: getArray(record, 'domains'),
+      externalIds: getArray(record, 'externalIds'),
+      mainSourceId: getString(record, 'mainSourceId'),
+      revenue: getNumber(record, 'revenue'),
+      size: getNumber(record, 'size'),
+      slackChannelId: getString(record, 'slackChannelId'),
+      createdAt: getDateString(record, 'createdAt'),
+      updatedAt: getDateString(record, 'updatedAt'),
+      owner: owner ? compactObject({
+        id: getString(owner, 'id'),
+        name: getString(owner, 'name'),
+        displayName: getString(owner, 'displayName'),
+      }) : undefined,
+      status: status ? compactObject({
+        id: getString(status, 'id'),
+        name: getString(status, 'name'),
+        color: getString(status, 'color'),
+      }) : undefined,
+      tier: tier ? compactObject({
+        id: getString(tier, 'id'),
+        name: getString(tier, 'name'),
+        color: getString(tier, 'color'),
+      }) : undefined,
+    });
+  }
+}
diff --git a/src/features/portfolio/types/portfolio.types.ts b/src/features/portfolio/types/portfolio.types.ts
new file mode 100644
index 0000000..d5a62d0
--- /dev/null
+++ b/src/features/portfolio/types/portfolio.types.ts
@@ -0,0 +1,33 @@
+import type { LinearClient } from '@linear/sdk';
+
+export interface GetInitiativeInput {
+  id: string;
+}
+
+export interface ListInitiativesInput {
+  filter?: NonNullable<Parameters<LinearClient['initiatives']>[0]>['filter'];
+  first?: number;
+  after?: string;
+}
+
+export type CreateInitiativeInput = Parameters<LinearClient['createInitiative']>[0];
+
+export type UpdateInitiativeInput = {
+  id: string;
+} & Parameters<LinearClient['updateInitiative']>[1];
+
+export interface GetCustomerInput {
+  id: string;
+}
+
+export interface ListCustomersInput {
+  filter?: NonNullable<Parameters<LinearClient['customers']>[0]>['filter'];
+  first?: number;
+  after?: string;
+}
+
+export type CreateCustomerInput = Parameters<LinearClient['createCustomer']>[0];
+
+export type UpdateCustomerInput = {
+  id: string;
+} & Parameters<LinearClient['updateCustomer']>[1];
diff --git a/src/features/projects/handlers/project.handler.ts b/src/features/projects/handlers/project.handler.ts
index 5bef2da..d9f6fed 100644
--- a/src/features/projects/handlers/project.handler.ts
+++ b/src/features/projects/handlers/project.handler.ts
@@ -1,168 +1,464 @@
 import { BaseHandler } from '../../../core/handlers/base.handler.js';
 import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
 import { LinearAuth } from '../../../auth.js';
-import { LinearGraphQLClient } from '../../../graphql/client.js';
-import { getProjectDescription } from '../types/project.types.js';
-
-/**
- * Handler for project-related operations.
- * Manages creating, searching, and retrieving project information.
- */
-export class ProjectHandler extends BaseHandler {
-  constructor(auth: LinearAuth, graphqlClient?: LinearGraphQLClient) {
-    super(auth, graphqlClient);
-  }
-
-  /**
-   * Creates a new project with associated issues.
-   */
-  /**
-   * Creates a new project with associated issues
-   * @example
-   * ```typescript
-   * const result = await handler.handleCreateProjectWithIssues({
-   *   project: {
-   *     name: "Q1 Planning",
-   *     description: "Q1 2025 Planning Project",
-   *     teamIds: ["team-id-1"], // Required: Array of team IDs
-   *   },
-   *   issues: [{
-   *     title: "Project Setup",
-   *     description: "Initial project setup tasks",
-   *     teamId: "team-id-1"
-   *   }]
-   * });
-   * ```
-   */
-  async handleCreateProjectWithIssues(args: any): Promise<BaseToolResponse> {
+import {
+  asRecord,
+  callFetchMethod,
+  compactObject,
+  getBoolean,
+  getDateString,
+  getNumber,
+  getString,
+  mapConnection,
+  resolveValue,
+  toPageInfo,
+} from '../../../types/sdk.utils.js';
+import {
+  ProjectWithIssuesInput,
+  ListProjectsInput,
+  ProjectHandlerMethods,
+  ProjectInput,
+  ProjectUpdateCreateInput,
+  ProjectUpdateUpdateInput,
+  SearchProjectsInput,
+  UpdateProjectInput,
+} from '../types/project.types.js';
+
+export class ProjectHandler extends BaseHandler implements ProjectHandlerMethods {
+  constructor(auth: LinearAuth) {
+    super(auth);
+  }
+
+  async handleCreateProject(args: ProjectInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
-      this.validateRequiredParams(args, ['project', 'issues']);
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['name', 'teamIds']);
 
-      // Validate project input
-      if (!args.project.teamIds || !Array.isArray(args.project.teamIds) || args.project.teamIds.length === 0) {
-        throw new Error(
-          'Project requires teamIds as an array with at least one team ID.\n' +
-          'Example:\n' +
-          '{\n' +
-          '  project: {\n' +
-          '    name: "Project Name",\n' +
-          '    teamIds: ["team-id-1"]\n' +
-          '  },\n' +
-          '  issues: [{ title: "Issue Title", teamId: "team-id-1" }]\n' +
-          '}'
-        );
-      }
+      const payload = await client.executeSdk(
+        'createProject',
+        () => client.sdk.createProject(args)
+      );
 
-      if (!Array.isArray(args.issues)) {
-        throw new Error(
-          'Issues parameter must be an array of issue objects.\n' +
-          'Example: issues: [{ title: "Issue Title", teamId: "team-id-1" }]'
-        );
-      }
+      const project = await resolveValue(asRecord(payload).project as Promise<unknown> | unknown);
 
-      // Validate each issue has required teamId
-      args.issues.forEach((issue: any, index: number) => {
-        if (!issue.teamId) {
-          throw new Error(
-            `Issue at index ${index} is missing required teamId.\n` +
-            'Each issue must have a teamId that matches one of the project teamIds.'
-          );
+      return this.createStructuredResponse(
+        `Created project ${getString(project, 'name') ?? args.name}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          project: await this.mapProjectDetail(project),
+          lastSyncId: getNumber(payload, 'lastSyncId'),
         }
-      });
+      );
+    } catch (error) {
+      return this.handleError(error, 'create project');
+    }
+  }
 
-      const result = await client.createProjectWithIssues(
-        args.project,
-        args.issues
+  async handleUpdateProject(args: UpdateProjectInput & { id: string }): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const { id, ...input } = args;
+      const payload = await client.executeSdk(
+        'updateProject',
+        () => client.sdk.updateProject(id, input)
       );
 
-      if (!result.projectCreate.success || (result.issueBatchCreate && !result.issueBatchCreate.success)) {
-        throw new Error('Failed to create project or issues');
-      }
+      const project = await resolveValue(asRecord(payload).project as Promise<unknown> | unknown);
 
-      const { project } = result.projectCreate;
-      const issuesCreated = result.issueBatchCreate?.issues.length ?? 0;
+      return this.createStructuredResponse(
+        `Updated project ${getString(project, 'name') ?? id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          project: await this.mapProjectDetail(project),
+          lastSyncId: getNumber(payload, 'lastSyncId'),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'update project');
+    }
+  }
 
-      // Use utility function to get proper description
-      const projectDescription = getProjectDescription(project);
+  async handleDeleteProject(args: { id: string }): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
 
-      const response = [
-        `Successfully created project with issues`,
-        `Project: ${project.name}`,
-        `Project URL: ${project.url}`
-      ];
+      const payload = await client.executeSdk(
+        'deleteProject',
+        () => client.sdk.deleteProject(args.id)
+      );
 
-      // Add description if available
-      if (projectDescription) {
-        response.push(`Description: ${projectDescription}`);
+      return this.createStructuredResponse(
+        `Deleted project ${args.id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          id: args.id,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'delete project');
+    }
+  }
+
+  async handleCreateProjectWithIssues(args: ProjectWithIssuesInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['project', 'issues']);
+
+      if (!Array.isArray(args.project.teamIds) || args.project.teamIds.length === 0) {
+        throw new Error('project.teamIds must be a non-empty array');
       }
 
-      if (issuesCreated > 0) {
-        response.push(`Issues created: ${issuesCreated}`);
-        // Add details for each issue
-        result.issueBatchCreate?.issues.forEach(issue => {
-          response.push(`- ${issue.identifier}: ${issue.title} (${issue.url})`);
-        });
+      if (!Array.isArray(args.issues)) {
+        throw new Error('issues must be an array');
       }
 
-      return this.createResponse(response.join('\n'));
+      const workflow = await client.createProjectWithIssues(args.project, args.issues);
+
+      if (!workflow.success) {
+        const mappedProject = workflow.project
+          ? await this.mapProjectDetail(workflow.project)
+          : undefined;
+        const mappedIssues = await Promise.all((workflow.issues ?? []).map(issue => this.mapIssueReference(issue)));
+
+        return this.createErrorResponse(
+          workflow.message,
+          compactObject({
+            success: false,
+            project: mappedProject,
+            issues: mappedIssues,
+            lastSyncId: workflow.lastSyncId,
+            partialState: workflow.issueCreationAttempted && workflow.compensationSucceeded === false && workflow.project
+              ? compactObject({
+                  projectId: getString(workflow.project, 'id'),
+                  projectName: getString(workflow.project, 'name'),
+                  failedStep: workflow.failedStep,
+                })
+              : undefined,
+            error: {
+              type: 'workflow',
+              failedStep: workflow.failedStep,
+              issueCreationAttempted: workflow.issueCreationAttempted,
+              compensationAttempted: workflow.compensationAttempted,
+              compensationSucceeded: workflow.compensationSucceeded,
+              message: workflow.message,
+            },
+          })
+        );
+      }
+
+      return this.createStructuredResponse(
+        `Created project ${getString(workflow.project, 'name') ?? args.project.name}${workflow.issues.length > 0 ? ` with ${workflow.issues.length} issues` : ''}`,
+        {
+          success: true,
+          project: await this.mapProjectDetail(workflow.project),
+          issues: await Promise.all(workflow.issues.map(issue => this.mapIssueReference(issue))),
+          lastSyncId: workflow.lastSyncId,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'create project with issues');
+      return this.handleError(error, 'create project with issues');
     }
   }
 
-  /**
-   * Gets information about a specific project.
-   */
-  async handleGetProject(args: any): Promise<BaseToolResponse> {
+  async handleGetProject(args: { id: string }): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
       this.validateRequiredParams(args, ['id']);
 
-      const result = await client.getProject(args.id);
+      const project = await client.executeSdk(
+        'project',
+        () => client.sdk.project(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Fetched project ${getString(project, 'name') ?? args.id}`,
+        {
+          project: await this.mapProjectDetail(project),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get project');
+    }
+  }
+
+  async handleListProjects(args: ListProjectsInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const filter = this.buildProjectFilter(args);
+
+      const connection = await client.executeSdk(
+        'projects',
+        () => client.sdk.projects({
+          filter: Object.keys(filter).length > 0 ? filter : undefined,
+          first: args.first ?? 50,
+          after: args.after,
+        })
+      );
 
-      // Process the result to include proper description
-      const processedResult = {
-        ...result,
-        project: {
-          ...result.project,
-          actualDescription: getProjectDescription(result.project)
+      const mapped = await mapConnection(connection, project => this.mapProjectSummary(project));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} projects`,
+        {
+          projects: mapped.nodes,
+          pageInfo: mapped.pageInfo,
         }
-      };
+      );
+    } catch (error) {
+      return this.handleError(error, 'list projects');
+    }
+  }
+
+  async handleSearchProjects(args: SearchProjectsInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['query']);
 
-      return this.createJsonResponse(processedResult);
+      const payload = await client.executeSdk(
+        'searchProjects',
+        () => client.sdk.searchProjects(args.query, {
+          first: args.first ?? 50,
+          after: args.after,
+        })
+      );
+
+      const payloadRecord = asRecord(payload);
+      const nodes = Array.isArray(payloadRecord.nodes) ? payloadRecord.nodes as unknown[] : [];
+
+      return this.createStructuredResponse(
+        `Found ${nodes.length} project search results`,
+        {
+          projects: await Promise.all(nodes.map(project => this.mapProjectSummary(project))),
+          pageInfo: toPageInfo(payloadRecord.pageInfo),
+          totalCount: getNumber(payloadRecord, 'totalCount'),
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'get project info');
+      return this.handleError(error, 'search projects');
     }
   }
 
-  /**
-   * Searches for projects by name.
-   */
-  async handleSearchProjects(args: any): Promise<BaseToolResponse> {
+  async handleCreateProjectUpdate(args: ProjectUpdateCreateInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
-      this.validateRequiredParams(args, ['name']);
-
-      const result = await client.searchProjects({
-        name: { eq: args.name }
-      });
-
-      // Process the result to include proper descriptions for all projects
-      const processedResult = {
-        ...result,
-        projects: {
-          ...result.projects,
-          nodes: result.projects.nodes.map(project => ({
-            ...project,
-            actualDescription: getProjectDescription(project)
-          }))
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['projectId']);
+
+      const payload = await client.executeSdk(
+        'createProjectUpdate',
+        () => client.sdk.createProjectUpdate(args as never)
+      );
+      const projectUpdate = await resolveValue(asRecord(payload).projectUpdate as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        'Created project update',
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          projectUpdate: await this.mapProjectUpdate(projectUpdate),
         }
-      };
+      );
+    } catch (error) {
+      return this.handleError(error, 'create project update');
+    }
+  }
 
-      return this.createJsonResponse(processedResult);
+  async handleUpdateProjectUpdate(args: ProjectUpdateUpdateInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const { id, ...input } = args;
+      const payload = await client.executeSdk(
+        'updateProjectUpdate',
+        () => client.sdk.updateProjectUpdate(id, input as never)
+      );
+      const projectUpdate = await resolveValue(asRecord(payload).projectUpdate as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Updated project update ${id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          projectUpdate: await this.mapProjectUpdate(projectUpdate),
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'search projects');
+      return this.handleError(error, 'update project update');
+    }
+  }
+
+  private buildProjectFilter(args: ListProjectsInput): Record<string, unknown> {
+    const filter = {
+      ...(args.filter ?? {}),
+    };
+
+    if (args.teamId) {
+      filter.teams = { some: { id: { eq: args.teamId } } };
     }
+
+    if (args.leadId) {
+      filter.lead = { id: { eq: args.leadId } };
+    }
+
+    if (args.statusId) {
+      filter.status = { id: { eq: args.statusId } };
+    }
+
+    return filter;
+  }
+
+  private async mapProjectDetail(project: unknown): Promise<Record<string, unknown>> {
+    const projectRecord = asRecord(project);
+    const labels = await callFetchMethod(projectRecord, 'labels', { first: 50 });
+    const members = await callFetchMethod(projectRecord, 'members', { first: 50 });
+    const teams = await callFetchMethod(projectRecord, 'teams', { first: 50 });
+    const updates = await callFetchMethod(projectRecord, 'projectUpdates', { first: 10 });
+
+    return compactObject({
+      ...(await this.mapProjectSummary(project)),
+      labels: labels
+        ? (await mapConnection(labels, label => this.mapLabel(label))).nodes
+        : undefined,
+      members: members
+        ? (await mapConnection(members, member => this.mapUserReference(member) ?? {})).nodes
+        : undefined,
+      teams: teams
+        ? (await mapConnection(teams, team => this.mapTeamReference(team) ?? {})).nodes
+        : undefined,
+      updates: updates
+        ? (await mapConnection(updates, update => this.mapProjectUpdate(update))).nodes
+        : undefined,
+    });
+  }
+
+  private async mapProjectSummary(project: unknown): Promise<Record<string, unknown>> {
+    const projectRecord = asRecord(project);
+    const lead = await resolveValue(projectRecord.lead as Promise<unknown> | unknown);
+    const initiative = await resolveValue(projectRecord.initiative as Promise<unknown> | unknown);
+    const status = await resolveValue(projectRecord.status as Promise<unknown> | unknown);
+
+    return compactObject({
+      id: getString(projectRecord, 'id'),
+      name: getString(projectRecord, 'name'),
+      description: getString(projectRecord, 'description'),
+      content: getString(projectRecord, 'content'),
+      actualDescription: getString(projectRecord, 'content') ?? getString(projectRecord, 'description'),
+      url: getString(projectRecord, 'url'),
+      color: getString(projectRecord, 'color'),
+      icon: getString(projectRecord, 'icon'),
+      priority: getNumber(projectRecord, 'priority'),
+      startDate: getString(projectRecord, 'startDate'),
+      targetDate: getString(projectRecord, 'targetDate'),
+      createdAt: getDateString(projectRecord, 'createdAt'),
+      updatedAt: getDateString(projectRecord, 'updatedAt'),
+      initiative: this.mapInitiativeReference(initiative),
+      lead: this.mapUserReference(lead),
+      status: this.mapProjectStatus(status),
+    });
+  }
+
+  private async mapProjectUpdate(projectUpdate: unknown): Promise<Record<string, unknown>> {
+    const record = asRecord(projectUpdate);
+    const project = await resolveValue(record.project as Promise<unknown> | unknown);
+
+    return compactObject({
+      id: getString(record, 'id'),
+      body: getString(record, 'body'),
+      health: getString(record, 'health'),
+      isDiffHidden: getBoolean(record, 'isDiffHidden'),
+      createdAt: getDateString(record, 'createdAt'),
+      updatedAt: getDateString(record, 'updatedAt'),
+      project: this.mapProjectReference(project),
+    });
+  }
+
+  private mapProjectReference(project: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(project);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      url: getString(record, 'url'),
+    });
+  }
+
+  private mapInitiativeReference(initiative: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(initiative);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      description: getString(record, 'description'),
+      url: getString(record, 'url'),
+      targetDate: getDateString(record, 'targetDate'),
+    });
+  }
+
+  private mapProjectStatus(status: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(status);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      type: getString(record, 'type'),
+      color: getString(record, 'color'),
+    });
+  }
+
+  private mapUserReference(user: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(user);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      email: getString(record, 'email'),
+      displayName: getString(record, 'displayName'),
+    });
+  }
+
+  private mapTeamReference(team: unknown): Record<string, unknown> | undefined {
+    const record = asRecord(team);
+    if (Object.keys(record).length === 0) {
+      return undefined;
+    }
+
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      key: getString(record, 'key'),
+    });
+  }
+
+  private mapLabel(label: unknown): Record<string, unknown> {
+    const record = asRecord(label);
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      color: getString(record, 'color'),
+      description: getString(record, 'description'),
+    });
+  }
+
+  private async mapIssueReference(issue: unknown): Promise<Record<string, unknown>> {
+    const record = asRecord(issue);
+    return compactObject({
+      id: getString(record, 'id'),
+      identifier: getString(record, 'identifier'),
+      title: getString(record, 'title'),
+      url: getString(record, 'url'),
+    });
   }
-}
\ No newline at end of file
+}
diff --git a/src/features/projects/types/project.types.ts b/src/features/projects/types/project.types.ts
index 399d0d0..8ccc4da 100644
--- a/src/features/projects/types/project.types.ts
+++ b/src/features/projects/types/project.types.ts
@@ -1,93 +1,129 @@
-/**
- * Project operation types
- * These types define the structure for project-related operations in Linear
- */
+import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
+import { CreateIssueInput, Issue, IssueBatchResponse } from '../../issues/types/issue.types.js';
 
-/**
- * Document content structure for rich text descriptions
- */
-export interface DocumentContent {
-  /** Markdown/plain text version of the content */
+export interface ProjectInput {
+  name: string;
+  description?: string;
   content?: string;
-  /** Document state information for rich text formatting */
-  contentState?: string;
+  teamIds: string[];
+  initiativeId?: string;
+  leadId?: string;
+  memberIds?: string[];
+  startDate?: string;
+  targetDate?: string;
+  statusId?: string;
+  priority?: number;
+  icon?: string;
+  color?: string;
+  labelIds?: string[];
+  templateId?: string;
+  useDefaultTemplate?: boolean;
 }
 
-/**
- * Project information with proper description handling
- */
-export interface Project {
-  id: string;
-  name: string;
-  /** Legacy description field (usually empty) */
+export interface UpdateProjectInput {
+  name?: string;
   description?: string;
-  /** Rich content description field (actual content) */
-  documentContent?: DocumentContent;
-  url: string;
-  teams?: {
-    nodes: Array<{
-      id: string;
-      name: string;
-    }>;
-  };
+  content?: string;
+  teamIds?: string[];
+  initiativeId?: string | null;
+  leadId?: string;
+  memberIds?: string[];
+  startDate?: string;
+  targetDate?: string;
+  statusId?: string;
+  priority?: number;
+  icon?: string;
+  color?: string;
+  labelIds?: string[];
+  trashed?: boolean;
 }
 
-/**
- * Utility function to get the actual project description
- * Prioritizes documentContent.content over legacy description field
- */
-export function getProjectDescription(project: Project): string {
-  return project.documentContent?.content || project.description || '';
+export interface ListProjectsInput {
+  filter?: Record<string, unknown>;
+  teamId?: string;
+  leadId?: string;
+  statusId?: string;
+  first?: number;
+  after?: string;
+  orderBy?: string;
 }
 
-/**
- * Input for creating a new project
- * @example
- * ```typescript
- * const projectInput: ProjectInput = {
- *   name: "Q1 Planning",
- *   description: "Q1 2025 Planning Project",
- *   teamIds: ["team-id-1", "team-id-2"], // Required: Array of team IDs this project belongs to
- *   state: "started" // Optional: Project state
- * };
- * ```
- */
-export interface ProjectInput {
-  /** The name of the project */
-  name: string;
+export interface SearchProjectsInput extends Omit<ListProjectsInput, 'orderBy'> {
+  query: string;
+}
 
-  /** Optional description of the project */
-  description?: string;
+export interface ProjectUpdateCreateInput {
+  projectId: string;
+  body?: string;
+  bodyData?: Record<string, unknown>;
+  health?: string;
+  isDiffHidden?: boolean;
+}
 
-  /**
-   * Array of team IDs this project belongs to
-   * @required
-   * Note: Linear API requires teamIds (array) not teamId (single value)
-   */
-  teamIds: string[];
+export interface ProjectUpdateUpdateInput {
+  id: string;
+  body?: string;
+  bodyData?: Record<string, unknown>;
+  health?: string;
+  isDiffHidden?: boolean;
+}
 
-  /** Optional project state */
-  state?: string;
+export interface Project {
+  id?: string;
+  name?: string;
+  description?: string;
+  content?: string;
+  url?: string;
+  startDate?: string;
+  targetDate?: string;
 }
 
 export interface ProjectResponse {
   projectCreate: {
     success: boolean;
-    project: Project;
-    lastSyncId: number;
+    project?: Project;
+    lastSyncId?: number;
   };
   issueBatchCreate?: {
     success: boolean;
     issues: Array<{
-      id: string;
-      identifier: string;
-      title: string;
-      url: string;
+      id?: string;
+      identifier?: string;
+      title?: string;
+      url?: string;
     }>;
-    lastSyncId: number;
+    lastSyncId?: number;
   };
 }
 
+export interface ProjectWithIssuesInput {
+  project: ProjectInput;
+  issues: CreateIssueInput[];
+}
+
+export type ProjectWithIssuesOutcome =
+  | {
+      success: true;
+      project: Project;
+      issues: Issue[];
+      lastSyncId?: number;
+      projectCreate: ProjectResponse['projectCreate'];
+      issueBatchCreate?: IssueBatchResponse['issueBatchCreate'];
+    }
+  | {
+      success: false;
+      failedStep: 'projectCreate' | 'issueBatchCreate';
+      message: string;
+      issueCreationAttempted: boolean;
+      compensationAttempted: boolean;
+      compensationSucceeded?: boolean;
+      project?: Project;
+      issues?: Issue[];
+      lastSyncId?: number;
+      projectCreate: ProjectResponse['projectCreate'];
+      issueBatchCreate?: IssueBatchResponse['issueBatchCreate'];
+    };
+
 export interface SearchProjectsResponse {
   projects: {
     nodes: Project[];
@@ -96,4 +132,16 @@ export interface SearchProjectsResponse {
 
 export interface GetProjectResponse {
   project: Project;
-}
\ No newline at end of file
+}
+
+export interface ProjectHandlerMethods {
+  handleCreateProject(args: ProjectInput): Promise<BaseToolResponse>;
+  handleUpdateProject(args: UpdateProjectInput & { id: string }): Promise<BaseToolResponse>;
+  handleDeleteProject(args: { id: string }): Promise<BaseToolResponse>;
+  handleCreateProjectWithIssues(args: ProjectWithIssuesInput): Promise<BaseToolResponse>;
+  handleGetProject(args: { id: string }): Promise<BaseToolResponse>;
+  handleListProjects(args: ListProjectsInput): Promise<BaseToolResponse>;
+  handleSearchProjects(args: SearchProjectsInput): Promise<BaseToolResponse>;
+  handleCreateProjectUpdate(args: ProjectUpdateCreateInput): Promise<BaseToolResponse>;
+  handleUpdateProjectUpdate(args: ProjectUpdateUpdateInput): Promise<BaseToolResponse>;
+}
diff --git a/src/features/subscriptions/handlers/subscription.handler.ts b/src/features/subscriptions/handlers/subscription.handler.ts
new file mode 100644
index 0000000..5e87123
--- /dev/null
+++ b/src/features/subscriptions/handlers/subscription.handler.ts
@@ -0,0 +1,89 @@
+import { LinearAuth } from '../../../auth.js';
+import { RuntimeCapabilities } from '../../../core/capabilities.js';
+import { BaseHandler } from '../../../core/handlers/base.handler.js';
+import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
+import { StartSubscriptionInput, StopSubscriptionInput } from '../types/subscription.types.js';
+
+export class SubscriptionHandler extends BaseHandler {
+  constructor(
+    auth: LinearAuth,
+    private readonly runtimeCapabilities: RuntimeCapabilities
+  ) {
+    super(auth);
+  }
+
+  async handleGetCapabilities(): Promise<BaseToolResponse> {
+    return this.createStructuredResponse(
+      'Reported Linear MCP runtime capabilities',
+      {
+        server: this.runtimeCapabilities.server,
+        runtime: this.runtimeCapabilities.runtime,
+        transport: this.runtimeCapabilities.transport,
+        authScope: this.runtimeCapabilities.authScope,
+        endpoint: this.runtimeCapabilities.endpoint,
+        streamingSupported: this.runtimeCapabilities.streamingSupported,
+        capabilities: this.runtimeCapabilities.capabilities,
+      }
+    );
+  }
+
+  async handleStartSubscription(args: StartSubscriptionInput): Promise<BaseToolResponse> {
+    try {
+      this.validateRequiredParams(args, ['topic']);
+
+      if (!this.runtimeCapabilities.supportsSubscriptions) {
+        return this.createCapabilityResponse(
+          'Subscriptions require a streaming runtime and are not available over stdio.',
+          'subscriptions'
+        );
+      }
+
+      return this.createCapabilityResponse(
+        'Subscription runtime support is enabled, but no streaming subscription provider is configured for this server build.',
+        'subscriptions',
+        false
+      );
+    } catch (error) {
+      return this.handleError(error, 'start subscription');
+    }
+  }
+
+  async handleStopSubscription(args: StopSubscriptionInput): Promise<BaseToolResponse> {
+    try {
+      this.validateRequiredParams(args, ['subscriptionId']);
+
+      if (!this.runtimeCapabilities.supportsSubscriptions) {
+        return this.createCapabilityResponse(
+          'Subscriptions require a streaming runtime and are not available over stdio.',
+          'subscriptions'
+        );
+      }
+
+      return this.createCapabilityResponse(
+        'Subscription runtime support is enabled, but no streaming subscription provider is configured for this server build.',
+        'subscriptions',
+        false
+      );
+    } catch (error) {
+      return this.handleError(error, 'stop subscription');
+    }
+  }
+
+  private createCapabilityResponse(
+    message: string,
+    capability: string,
+    runtimeSupported: boolean = this.runtimeCapabilities.supportsSubscriptions
+  ): BaseToolResponse {
+    return this.createErrorResponse(message, {
+      authScope: this.runtimeCapabilities.authScope,
+      error: {
+        type: 'capability',
+        capability,
+        runtimeSupported,
+        transport: this.runtimeCapabilities.transport,
+        runtime: this.runtimeCapabilities.runtime,
+        message,
+      },
+    });
+  }
+}
diff --git a/src/features/subscriptions/types/subscription.types.ts b/src/features/subscriptions/types/subscription.types.ts
new file mode 100644
index 0000000..53e357f
--- /dev/null
+++ b/src/features/subscriptions/types/subscription.types.ts
@@ -0,0 +1,8 @@
+export interface StartSubscriptionInput {
+  topic: string;
+  filter?: Record<string, unknown>;
+}
+
+export interface StopSubscriptionInput {
+  subscriptionId: string;
+}
diff --git a/src/features/teams/handlers/team.handler.ts b/src/features/teams/handlers/team.handler.ts
index 686dbc7..d35bdd3 100644
--- a/src/features/teams/handlers/team.handler.ts
+++ b/src/features/teams/handlers/team.handler.ts
@@ -1,29 +1,284 @@
 import { BaseHandler } from '../../../core/handlers/base.handler.js';
 import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
 import { LinearAuth } from '../../../auth.js';
-import { LinearGraphQLClient } from '../../../graphql/client.js';
+import {
+  asRecord,
+  callFetchMethod,
+  compactObject,
+  getBoolean,
+  getDateString,
+  getNumber,
+  getString,
+  mapConnection,
+  resolveValue,
+} from '../../../types/sdk.utils.js';
+import {
+  DeleteLabelInput,
+  GetTeamInput,
+  LabelInput,
+  ListLabelsInput,
+  ListTeamsInput,
+  ListWorkflowStatesInput,
+  UpdateLabelInput,
+} from '../types/team.types.js';
 
-/**
- * Handler for team-related operations.
- * Manages retrieving team information, states, and labels.
- */
 export class TeamHandler extends BaseHandler {
-  constructor(auth: LinearAuth, graphqlClient?: LinearGraphQLClient) {
-    super(auth, graphqlClient);
+  constructor(auth: LinearAuth) {
+    super(auth);
   }
 
-  /**
-   * Gets information about all teams, including their states and labels.
-   */
-  async handleGetTeams(args: any): Promise<BaseToolResponse> {
+  async handleGetTeam(args: GetTeamInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
 
-      const result = await client.getTeams();
+      const team = await client.executeSdk(
+        'team',
+        () => client.sdk.team(args.id)
+      );
 
-      return this.createJsonResponse(result);
+      return this.createStructuredResponse(
+        `Fetched team ${getString(team, 'name') ?? args.id}`,
+        {
+          team: await this.mapTeamDetail(team),
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'get teams');
+      return this.handleError(error, 'get team');
     }
   }
+
+  async handleListTeams(args: ListTeamsInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const filter = {
+        ...(args.filter ?? {}),
+        ...(args.key ? { key: { eq: args.key } } : {}),
+        ...(args.name ? { name: { containsIgnoreCase: args.name } } : {}),
+      };
+
+      const connection = await client.executeSdk(
+        'teams',
+        () => client.sdk.teams({
+          filter: Object.keys(filter).length > 0 ? filter : undefined,
+          first: args.first ?? 50,
+          after: args.after,
+        })
+      );
+
+      const mapped = await mapConnection(connection, team => this.mapTeamSummary(team));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} teams`,
+        {
+          teams: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list teams');
+    }
+  }
+
+  async handleGetTeams(args: ListTeamsInput = {}): Promise<BaseToolResponse> {
+    return this.handleListTeams(args);
+  }
+
+  async handleListWorkflowStates(args: ListWorkflowStatesInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+
+      const connection = args.teamId
+        ? await client.executeSdk('team.states', async () => {
+            const team = await client.sdk.team(args.teamId!);
+            return team.states({
+              first: args.first ?? 50,
+              after: args.after,
+            });
+          })
+        : await client.executeSdk(
+            'workflowStates',
+            () => client.sdk.workflowStates({
+              first: args.first ?? 50,
+              after: args.after,
+            })
+          );
+
+      const mapped = await mapConnection(connection, state => this.mapWorkflowState(state));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} workflow states`,
+        {
+          states: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list workflow states');
+    }
+  }
+
+  async handleListLabels(args: ListLabelsInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+
+      const connection = args.teamId
+        ? await client.executeSdk('team.labels', async () => {
+            const team = await client.sdk.team(args.teamId!);
+            return team.labels({
+              first: args.first ?? 50,
+              after: args.after,
+            });
+          })
+        : await client.executeSdk(
+            'issueLabels',
+            () => client.sdk.issueLabels({
+              first: args.first ?? 50,
+              after: args.after,
+            })
+          );
+
+      const mapped = await mapConnection(connection, label => this.mapLabel(label));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} labels`,
+        {
+          labels: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list labels');
+    }
+  }
+
+  async handleCreateLabel(args: LabelInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['name', 'teamId']);
+
+      const payload = await client.executeSdk(
+        'createIssueLabel',
+        () => client.sdk.createIssueLabel(args as never)
+      );
+      const label = await resolveValue(asRecord(payload).issueLabel as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Created label ${getString(label, 'name') ?? args.name}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          label: this.mapLabel(label),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'create label');
+    }
+  }
+
+  async handleUpdateLabel(args: UpdateLabelInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const { id, ...input } = args;
+      const payload = await client.executeSdk(
+        'updateIssueLabel',
+        () => client.sdk.updateIssueLabel(id, input as never)
+      );
+      const label = await resolveValue(asRecord(payload).issueLabel as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Updated label ${getString(label, 'name') ?? id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          label: this.mapLabel(label),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'update label');
+    }
+  }
+
+  async handleDeleteLabel(args: DeleteLabelInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const payload = await client.executeSdk(
+        'deleteIssueLabel',
+        () => client.sdk.deleteIssueLabel(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Deleted label ${args.id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          id: args.id,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'delete label');
+    }
+  }
+
+  private async mapTeamDetail(team: unknown): Promise<Record<string, unknown>> {
+    const teamRecord = asRecord(team);
+    const states = await callFetchMethod(teamRecord, 'states', { first: 50 });
+    const labels = await callFetchMethod(teamRecord, 'labels', { first: 50 });
+    const cycles = await callFetchMethod(teamRecord, 'cycles', { first: 10 });
+
+    return compactObject({
+      ...(this.mapTeamSummary(team)),
+      states: states ? (await mapConnection(states, state => this.mapWorkflowState(state))).nodes : undefined,
+      labels: labels ? (await mapConnection(labels, label => this.mapLabel(label))).nodes : undefined,
+      cycles: cycles ? (await mapConnection(cycles, cycle => this.mapCycle(cycle))).nodes : undefined,
+    });
+  }
+
+  private mapTeamSummary(team: unknown): Record<string, unknown> {
+    const record = asRecord(team);
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      key: getString(record, 'key'),
+      description: getString(record, 'description'),
+      icon: getString(record, 'icon'),
+      createdAt: getDateString(record, 'createdAt'),
+      updatedAt: getDateString(record, 'updatedAt'),
+    });
+  }
+
+  private mapWorkflowState(state: unknown): Record<string, unknown> {
+    const record = asRecord(state);
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      type: getString(record, 'type'),
+      color: getString(record, 'color'),
+      description: getString(record, 'description'),
+    });
+  }
+
+  private mapLabel(label: unknown): Record<string, unknown> {
+    const record = asRecord(label);
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      color: getString(record, 'color'),
+      description: getString(record, 'description'),
+      parentId: getString(record, 'parentId'),
+    });
+  }
+
+  private mapCycle(cycle: unknown): Record<string, unknown> {
+    const record = asRecord(cycle);
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      number: getNumber(record, 'number'),
+      startsAt: getDateString(record, 'startsAt'),
+      endsAt: getDateString(record, 'endsAt'),
+      completedAt: getDateString(record, 'completedAt'),
+    });
+  }
 }
diff --git a/src/features/teams/types/team.types.ts b/src/features/teams/types/team.types.ts
index 4d4d5e7..773dc7c 100644
--- a/src/features/teams/types/team.types.ts
+++ b/src/features/teams/types/team.types.ts
@@ -1,38 +1,77 @@
-/**
- * Team operation types
- */
-
-export interface TeamState {
+export interface GetTeamInput {
   id: string;
-  name: string;
-  type: string;
 }
 
-export interface Team {
-  id: string;
-  name: string;
-  key: string;
-  states: TeamState[];
+export interface ListTeamsInput {
+  filter?: Record<string, unknown>;
+  key?: string;
+  name?: string;
+  first?: number;
+  after?: string;
 }
 
-export interface TeamResponse {
-  teams: {
-    nodes: Team[];
-  };
+export interface ListWorkflowStatesInput {
+  teamId?: string;
+  first?: number;
+  after?: string;
+}
+
+export interface ListLabelsInput {
+  teamId?: string;
+  first?: number;
+  after?: string;
 }
 
 export interface LabelInput {
   name: string;
   color?: string;
+  description?: string;
   teamId: string;
+  parentId?: string;
+  isGroup?: boolean;
+}
+
+export interface UpdateLabelInput {
+  id: string;
+  name?: string;
+  color?: string;
+  description?: string;
+  parentId?: string;
+  retiredAt?: string;
+  isGroup?: boolean;
+}
+
+export interface DeleteLabelInput {
+  id: string;
+}
+
+export interface TeamState {
+  id?: string;
+  name?: string;
+  type?: string;
+  color?: string;
+}
+
+export interface Team {
+  id?: string;
+  name?: string;
+  key?: string;
+  description?: string;
+}
+
+export interface TeamResponse {
+  teams: {
+    nodes: Team[];
+  };
 }
 
 export interface LabelResponse {
-  labelCreate: {
+  labelCreate?: {
     success: boolean;
-    label: {
-      id: string;
-      name: string;
+    label?: {
+      id?: string;
+      name?: string;
+      color?: string;
     };
   };
 }
diff --git a/src/features/users/handlers/user.handler.ts b/src/features/users/handlers/user.handler.ts
index 82f75c6..14a5150 100644
--- a/src/features/users/handlers/user.handler.ts
+++ b/src/features/users/handlers/user.handler.ts
@@ -1,29 +1,128 @@
 import { BaseHandler } from '../../../core/handlers/base.handler.js';
 import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
 import { LinearAuth } from '../../../auth.js';
-import { LinearGraphQLClient } from '../../../graphql/client.js';
+import {
+  asRecord,
+  compactObject,
+  getBoolean,
+  getString,
+  mapConnection,
+  toPageInfo,
+} from '../../../types/sdk.utils.js';
+import { GetUserInput, ListUsersInput, SearchUsersInput } from '../types/user.types.js';
 
-/**
- * Handler for user-related operations.
- * Manages retrieving user information and settings.
- */
 export class UserHandler extends BaseHandler {
-  constructor(auth: LinearAuth, graphqlClient?: LinearGraphQLClient) {
-    super(auth, graphqlClient);
+  constructor(auth: LinearAuth) {
+    super(auth);
   }
 
-  /**
-   * Gets information about the currently authenticated user.
-   */
-  async handleGetUser(args: any): Promise<BaseToolResponse> {
+  async handleGetUser(args: GetUserInput): Promise<BaseToolResponse> {
     try {
-      const client = this.verifyAuth();
+      const client = await this.verifyAuth();
 
-      const result = await client.getCurrentUser();
+      if (args?.id) {
+        const user = await client.executeSdk(
+          'user',
+          () => client.sdk.user(args.id!)
+        );
 
-      return this.createJsonResponse(result);
+        return this.createStructuredResponse(
+          `Fetched user ${getString(user, 'name') ?? args.id}`,
+          {
+            user: this.mapUser(user),
+          }
+        );
+      }
+
+      const viewer = await client.executeSdk(
+        'viewer',
+        () => client.sdk.viewer
+      );
+
+      return this.createStructuredResponse(
+        `Fetched current user ${getString(viewer, 'name') ?? 'viewer'}`,
+        {
+          viewer: this.mapUser(viewer),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get user info');
+    }
+  }
+
+  async handleListUsers(args: ListUsersInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const connection = await client.executeSdk(
+        'users',
+        () => client.sdk.users({
+          ...(args.filter ? { filter: args.filter } : {}),
+          first: args.first ?? 50,
+          after: args.after,
+        })
+      );
+
+      const mapped = await mapConnection(connection, user => this.mapUser(user));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} users`,
+        {
+          users: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list users');
+    }
+  }
+
+  async handleSearchUsers(args: SearchUsersInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['query']);
+
+      const filter = {
+        ...(args.filter ?? {}),
+        or: [
+          { name: { containsIgnoreCase: args.query } },
+          { displayName: { containsIgnoreCase: args.query } },
+          { email: { containsIgnoreCase: args.query } },
+        ],
+      };
+
+      const connection = await client.executeSdk(
+        'users',
+        () => client.sdk.users({
+          filter,
+          first: args.first ?? 50,
+          after: args.after,
+        })
+      );
+
+      const mapped = await mapConnection(connection, user => this.mapUser(user));
+
+      return this.createStructuredResponse(
+        `Found ${mapped.nodes.length} users`,
+        {
+          users: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+        }
+      );
     } catch (error) {
-      this.handleError(error, 'get user info');
+      return this.handleError(error, 'search users');
     }
   }
+
+  private mapUser(user: unknown): Record<string, unknown> {
+    const record = asRecord(user);
+    return compactObject({
+      id: getString(record, 'id'),
+      name: getString(record, 'name'),
+      displayName: getString(record, 'displayName'),
+      email: getString(record, 'email'),
+      avatarUrl: getString(record, 'avatarUrl'),
+      active: getBoolean(record, 'active'),
+      url: getString(record, 'url'),
+    });
+  }
 }
diff --git a/src/features/users/types/user.types.ts b/src/features/users/types/user.types.ts
index b13cb10..ee4ce56 100644
--- a/src/features/users/types/user.types.ts
+++ b/src/features/users/types/user.types.ts
@@ -1,11 +1,24 @@
-/**
- * User operation types
- */
+export interface GetUserInput {
+  id?: string;
+}
+
+export interface ListUsersInput {
+  filter?: Record<string, unknown>;
+  first?: number;
+  after?: string;
+  orderBy?: string;
+}
+
+export interface SearchUsersInput extends Omit<ListUsersInput, 'orderBy'> {
+  query: string;
+}
 
 export interface User {
-  id: string;
-  name: string;
-  email: string;
+  id?: string;
+  name?: string;
+  email?: string;
+  displayName?: string;
+  active?: boolean;
 }
 
 export interface UserResponse {
diff --git a/src/features/webhooks/handlers/webhook.handler.ts b/src/features/webhooks/handlers/webhook.handler.ts
new file mode 100644
index 0000000..a66213b
--- /dev/null
+++ b/src/features/webhooks/handlers/webhook.handler.ts
@@ -0,0 +1,154 @@
+import { LinearAuth } from '../../../auth.js';
+import { BaseHandler } from '../../../core/handlers/base.handler.js';
+import { BaseToolResponse } from '../../../core/interfaces/tool-handler.interface.js';
+import {
+  asRecord,
+  compactObject,
+  getArray,
+  getBoolean,
+  getDateString,
+  getString,
+  mapConnection,
+  resolveValue,
+} from '../../../types/sdk.utils.js';
+import { CreateWebhookInput, GetWebhookInput, ListWebhooksInput } from '../types/webhook.types.js';
+
+export class WebhookHandler extends BaseHandler {
+  constructor(auth: LinearAuth) {
+    super(auth);
+  }
+
+  async handleGetWebhook(args: GetWebhookInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const webhook = await client.executeSdk(
+        'webhook',
+        () => client.sdk.webhook(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Fetched webhook ${getString(webhook, 'label') ?? args.id}`,
+        {
+          webhook: await this.mapWebhook(webhook),
+          verificationGuidance: this.getVerificationGuidance(),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'get webhook');
+    }
+  }
+
+  async handleListWebhooks(args: ListWebhooksInput = {}): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      const connection = args.teamId
+        ? await client.executeSdk('team.webhooks', async () => {
+            const team = await client.sdk.team(args.teamId!);
+            return team.webhooks({
+              first: args.first ?? 50,
+              after: args.after,
+            });
+          })
+        : await client.executeSdk(
+            'webhooks',
+            () => client.sdk.webhooks({
+              first: args.first ?? 50,
+              after: args.after,
+            })
+          );
+
+      const mapped = await mapConnection(connection, webhook => this.mapWebhook(webhook));
+
+      return this.createStructuredResponse(
+        `Listed ${mapped.nodes.length} webhooks`,
+        {
+          webhooks: mapped.nodes,
+          pageInfo: mapped.pageInfo,
+          verificationGuidance: this.getVerificationGuidance(),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'list webhooks');
+    }
+  }
+
+  async handleCreateWebhook(args: CreateWebhookInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['url', 'resourceTypes']);
+
+      const payload = await client.executeSdk(
+        'createWebhook',
+        () => client.sdk.createWebhook(args)
+      );
+      const webhook = await resolveValue(asRecord(payload).webhook as Promise<unknown> | unknown);
+
+      return this.createStructuredResponse(
+        `Created webhook ${getString(webhook, 'label') ?? getString(webhook, 'id') ?? args.url}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          webhook: await this.mapWebhook(webhook),
+          verificationGuidance: this.getVerificationGuidance(),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'create webhook');
+    }
+  }
+
+  async handleDeleteWebhook(args: GetWebhookInput): Promise<BaseToolResponse> {
+    try {
+      const client = await this.verifyAuth();
+      this.validateRequiredParams(args, ['id']);
+
+      const payload = await client.executeSdk(
+        'deleteWebhook',
+        () => client.sdk.deleteWebhook(args.id)
+      );
+
+      return this.createStructuredResponse(
+        `Deleted webhook ${args.id}`,
+        {
+          success: getBoolean(payload, 'success') ?? true,
+          id: args.id,
+          verificationGuidance: this.getVerificationGuidance(),
+        }
+      );
+    } catch (error) {
+      return this.handleError(error, 'delete webhook');
+    }
+  }
+
+  private async mapWebhook(webhook: unknown): Promise<Record<string, unknown>> {
+    if (!webhook) {
+      return {};
+    }
+
+    const record = asRecord(webhook);
+    const team = await resolveValue(record.team as Promise<unknown> | unknown);
+
+    return compactObject({
+      id: getString(record, 'id'),
+      label: getString(record, 'label'),
+      url: getString(record, 'url'),
+      enabled: getBoolean(record, 'enabled'),
+      resourceTypes: getArray(record, 'resourceTypes'),
+      createdAt: getDateString(record, 'createdAt'),
+      updatedAt: getDateString(record, 'updatedAt'),
+      team: team ? compactObject({
+        id: getString(team, 'id'),
+        name: getString(team, 'name'),
+        key: getString(team, 'key'),
+      }) : undefined,
+    });
+  }
+
+  private getVerificationGuidance(): Record<string, unknown> {
+    return {
+      message: 'Validate the Linear webhook signature with the configured secret before accepting delivered webhook payloads.',
+      secretHandling: 'Store the webhook secret outside the repository and rotate it if delivery verification is compromised.',
+    };
+  }
+}
diff --git a/src/features/webhooks/types/webhook.types.ts b/src/features/webhooks/types/webhook.types.ts
new file mode 100644
index 0000000..cd5bcdf
--- /dev/null
+++ b/src/features/webhooks/types/webhook.types.ts
@@ -0,0 +1,13 @@
+import type { LinearClient } from '@linear/sdk';
+
+export interface GetWebhookInput {
+  id: string;
+}
+
+export interface ListWebhooksInput {
+  teamId?: string;
+  first?: number;
+  after?: string;
+}
+
+export type CreateWebhookInput = Parameters<LinearClient['createWebhook']>[0];
diff --git a/src/graphql/client.ts b/src/graphql/client.ts
index e2af9b3..6400ec2 100644
--- a/src/graphql/client.ts
+++ b/src/graphql/client.ts
@@ -1,10 +1,10 @@
 import { LinearClient } from '@linear/sdk';
-import { DocumentNode } from 'graphql';
+import { DocumentNode, Kind, OperationDefinitionNode } from 'graphql';
 import { 
   CreateIssueInput, 
-  CreateIssuesInput,
   CreateIssueResponse,
-  CreateIssuesResponse,
+  DeleteIssuesResponse,
+  UpdateIssueResponse,
   UpdateIssueInput,
   UpdateIssuesResponse,
   SearchIssuesInput,
@@ -16,6 +16,7 @@ import {
 import {
   ProjectInput,
   ProjectResponse,
+  ProjectWithIssuesOutcome,
   SearchProjectsResponse,
   GetProjectResponse
 } from '../features/projects/types/project.types.js';
@@ -30,7 +31,20 @@ import {
 import {
   CreateCommentInput,
   CreateCommentResponse,
-  GetIssueCommentsResponse
+  DeleteCommentInput,
+  DeleteCommentResponse,
+  GetCommentInput,
+  GetCommentResponse,
+  GetIssueCommentsInput,
+  GetIssueCommentsResponse,
+  ListCommentsInput,
+  ListCommentsResponse,
+  ResolveCommentInput,
+  ResolveCommentResponse,
+  UnresolveCommentInput,
+  UnresolveCommentResponse,
+  UpdateCommentInput,
+  UpdateCommentResponse
 } from '../features/comments/types/comment.types.js';
 import {
   ProjectMilestoneCreateInput,
@@ -41,43 +55,224 @@ import {
   SearchProjectMilestonesResponse,
   GetProjectMilestoneResponse
 } from '../features/milestones/types/milestone.types.js';
+import {
+  asRecord,
+  compactObject,
+  getString,
+  getBoolean,
+} from '../types/sdk.utils.js';
+import {
+  DEFAULT_LINEAR_REQUEST_TIMEOUT_MS,
+  DEFAULT_SAFE_READ_MAX_ATTEMPTS,
+  DEFAULT_SAFE_READ_RETRY_DELAY_MS,
+  executeWithRequestPolicy,
+  RequestPolicyOptions,
+  RequestTimeoutError,
+} from '../core/request-policy.js';
+
+export interface GraphQLErrorDetail {
+  message: string;
+  path?: Array<string | number>;
+  extensions?: Record<string, unknown>;
+}
+
+export interface GraphQLResponseMetadata {
+  status?: number;
+  retryable: boolean;
+  headers: Record<string, string>;
+}
+
+export interface GraphQLResult<T> {
+  data?: T;
+  errors?: GraphQLErrorDetail[];
+  extensions?: Record<string, unknown>;
+  meta: GraphQLResponseMetadata;
+}
+
+interface RawGraphQLResponse<T> {
+  data?: T;
+  errors?: unknown[];
+  extensions?: unknown;
+  headers?: Headers | Map<string, string> | Record<string, string>;
+  status?: number;
+}
+
+interface GraphQLExecutionOptions {
+  allowRetry?: boolean;
+}
+
+export interface LinearGraphQLClientOptions {
+  requestTimeoutMs?: number;
+  safeReadMaxAttempts?: number;
+  safeReadRetryDelayMs?: number;
+}
+
+const SAFE_SDK_READ_OPERATIONS = new Set<string>([
+  'agentActivities',
+  'agentActivity',
+  'agentSession',
+  'agentSessions',
+  'attachment',
+  'attachments',
+  'customer',
+  'customers',
+  'cycle',
+  'cycles',
+  'initiative',
+  'initiatives',
+  'issue',
+  'issue.attachments',
+  'issueLabels',
+  'issues',
+  'project',
+  'projects',
+  'searchProjects',
+  'team',
+  'team.labels',
+  'team.states',
+  'team.webhooks',
+  'teams',
+  'user',
+  'users',
+  'viewer',
+  'webhook',
+  'webhooks',
+  'workflowStates',
+]);
+
+export class LinearGraphQLRequestError extends Error {
+  constructor(
+    public readonly operation: string,
+    public readonly result: GraphQLResult<unknown>,
+    message?: string
+  ) {
+    super(message ?? `GraphQL operation ${operation} failed`);
+    this.name = 'LinearGraphQLRequestError';
+  }
+}
 
 export class LinearGraphQLClient {
   private linearClient: LinearClient;
 
-  constructor(linearClient: LinearClient) {
+  constructor(
+    linearClient: LinearClient,
+    private readonly options: LinearGraphQLClientOptions = {}
+  ) {
     this.linearClient = linearClient;
   }
 
+  get sdk(): LinearClient {
+    return this.linearClient;
+  }
+
   async execute<T, V extends Record<string, unknown> = Record<string, unknown>>(
     document: DocumentNode,
-    variables?: V
-  ): Promise<T> {
+    variables?: V,
+    options: GraphQLExecutionOptions = {}
+  ): Promise<GraphQLResult<T>> {
     const graphQLClient = this.linearClient.client;
+    const operationName = this.getOperationName(document);
+
     try {
-      const response = await graphQLClient.rawRequest(
-        document.loc?.source.body || '',
-        variables
+      return await executeWithRequestPolicy(
+        operationName,
+        async () => {
+          const response = await graphQLClient.rawRequest(
+            document.loc?.source.body || '',
+            variables
+          ) as unknown as RawGraphQLResponse<T>;
+
+          const result: GraphQLResult<T> = {
+            data: response.data,
+            errors: this.normalizeErrors(response.errors),
+            extensions: this.normalizeExtensions(response.extensions),
+            meta: {
+              status: response.status,
+              retryable: this.isRetryable(response.status, this.normalizeErrors(response.errors)),
+              headers: this.normalizeHeaders(response.headers),
+            },
+          };
+
+          if (!result.data && (result.errors?.length ?? 0) > 0) {
+            throw new LinearGraphQLRequestError(
+              operationName,
+              result,
+              this.buildErrorMessage(operationName, result.errors)
+            );
+          }
+
+          return result;
+        },
+        this.buildRequestPolicy(operationName, options.allowRetry === true)
       );
-      return response.data as T;
     } catch (error) {
-      if (error instanceof Error) {
-        throw new Error(`GraphQL operation failed: ${error.message}`);
+      if (error instanceof LinearGraphQLRequestError) {
+        throw error;
       }
-      throw error;
+
+      const result = this.createErrorResult(operationName, error);
+      throw new LinearGraphQLRequestError(
+        operationName,
+        result,
+        this.buildErrorMessage(operationName, result.errors)
+      );
+    }
+  }
+
+  async executeData<T, V extends Record<string, unknown> = Record<string, unknown>>(
+    document: DocumentNode,
+    variables?: V,
+    options: GraphQLExecutionOptions = {}
+  ): Promise<T> {
+    const result = await this.execute<T, V>(document, variables, options);
+    if (result.data === undefined) {
+      throw new LinearGraphQLRequestError(
+        this.getOperationName(document),
+        result,
+        `GraphQL operation ${this.getOperationName(document)} returned no data`
+      );
+    }
+
+    return result.data;
+  }
+
+  async executeSdk<T>(
+    operationName: string,
+    request: () => Promise<T>,
+    options: GraphQLExecutionOptions = {}
+  ): Promise<T> {
+    const allowRetry = options.allowRetry ?? SAFE_SDK_READ_OPERATIONS.has(operationName);
+
+    try {
+      return await executeWithRequestPolicy(
+        operationName,
+        async () => request(),
+        this.buildRequestPolicy(operationName, allowRetry)
+      );
+    } catch (error) {
+      if (error instanceof LinearGraphQLRequestError) {
+        throw error;
+      }
+
+      const result = this.createErrorResult(operationName, error);
+      throw new LinearGraphQLRequestError(
+        operationName,
+        result,
+        this.buildErrorMessage(operationName, result.errors)
+      );
     }
   }
 
   // Create single issue
   async createIssue(input: CreateIssueInput): Promise<CreateIssueResponse> {
     const { CREATE_ISSUE_MUTATION } = await import('./mutations.js');
-    return this.execute<CreateIssueResponse>(CREATE_ISSUE_MUTATION, { input });
+    return this.executeData<CreateIssueResponse>(CREATE_ISSUE_MUTATION, { input });
   }
 
   // Create multiple issues
   async createIssues(issues: CreateIssueInput[]): Promise<IssueBatchResponse> {
     const { CREATE_BATCH_ISSUES } = await import('./mutations.js');
-    return this.execute<IssueBatchResponse>(CREATE_BATCH_ISSUES, {
+    return this.executeData<IssueBatchResponse>(CREATE_BATCH_ISSUES, {
       input: { issues }
     });
   }
@@ -85,48 +280,78 @@ export class LinearGraphQLClient {
   // Create a project
   async createProject(input: ProjectInput): Promise<ProjectResponse> {
     const { CREATE_PROJECT } = await import('./mutations.js');
-    return this.execute<ProjectResponse>(CREATE_PROJECT, { input });
-  }
-
-  // Create batch of issues
-  async createBatchIssues(issues: CreateIssueInput[]): Promise<IssueBatchResponse> {
-    const { CREATE_BATCH_ISSUES } = await import('./mutations.js');
-    return this.execute<IssueBatchResponse>(CREATE_BATCH_ISSUES, {
-      input: { issues }
-    });
+    return this.executeData<ProjectResponse>(CREATE_PROJECT, { input });
   }
 
   // Helper method to create a project with associated issues
-  async createProjectWithIssues(projectInput: ProjectInput, issues: CreateIssueInput[]): Promise<ProjectResponse> {
-    // Create project first
+  async createProjectWithIssues(
+    projectInput: ProjectInput,
+    issues: CreateIssueInput[]
+  ): Promise<ProjectWithIssuesOutcome> {
     const projectResult = await this.createProject(projectInput);
-    
-    if (!projectResult.projectCreate.success) {
-      throw new Error('Failed to create project');
+
+    const project = projectResult.projectCreate.project;
+    const projectId = projectResult.projectCreate.project?.id;
+    if (!projectResult.projectCreate.success || !projectId || !project) {
+      return {
+        success: false,
+        failedStep: 'projectCreate',
+        message: 'Project creation did not complete before issue creation began.',
+        issueCreationAttempted: false,
+        compensationAttempted: false,
+        lastSyncId: projectResult.projectCreate.lastSyncId,
+        projectCreate: projectResult.projectCreate,
+      };
+    }
+
+    if (issues.length === 0) {
+      return {
+        success: true,
+        project,
+        issues: [],
+        lastSyncId: projectResult.projectCreate.lastSyncId,
+        projectCreate: projectResult.projectCreate,
+      };
     }
 
-    // Then create issues with project ID
     const issuesWithProject = issues.map(issue => ({
       ...issue,
-      projectId: projectResult.projectCreate.project.id
+      projectId
     }));
 
-    const issuesResult = await this.createBatchIssues(issuesWithProject);
+    try {
+      const issuesResult = await this.createIssues(issuesWithProject);
 
-    if (!issuesResult.issueBatchCreate.success) {
-      throw new Error('Failed to create issues');
-    }
+      if (!issuesResult.issueBatchCreate.success) {
+        return await this.compensateProjectIssueFailure(
+          project,
+          projectResult,
+          issuesResult
+        );
+      }
 
-    return {
-      projectCreate: projectResult.projectCreate,
-      issueBatchCreate: issuesResult.issueBatchCreate
-    };
+      return {
+        success: true,
+        project,
+        issues: issuesResult.issueBatchCreate.issues,
+        lastSyncId: issuesResult.issueBatchCreate.lastSyncId ?? projectResult.projectCreate.lastSyncId,
+        projectCreate: projectResult.projectCreate,
+        issueBatchCreate: issuesResult.issueBatchCreate,
+      };
+    } catch (error) {
+      return await this.compensateProjectIssueFailure(
+        project,
+        projectResult,
+        undefined,
+        error
+      );
+    }
   }
 
   // Update a single issue
-  async updateIssue(id: string, input: UpdateIssueInput): Promise<UpdateIssuesResponse> {
+  async updateIssue(id: string, input: UpdateIssueInput): Promise<UpdateIssueResponse> {
     const { UPDATE_ISSUE_MUTATION } = await import('./mutations.js');
-    return this.execute<UpdateIssuesResponse>(UPDATE_ISSUE_MUTATION, {
+    return this.executeData<UpdateIssueResponse>(UPDATE_ISSUE_MUTATION, {
       id,
       input,
     });
@@ -135,113 +360,272 @@ export class LinearGraphQLClient {
   // Bulk update issues
   async updateIssues(ids: string[], input: UpdateIssueInput): Promise<UpdateIssuesResponse> {
     const { UPDATE_ISSUES_MUTATION } = await import('./mutations.js');
-    return this.execute<UpdateIssuesResponse>(UPDATE_ISSUES_MUTATION, { ids, input });
+    return this.executeData<UpdateIssuesResponse>(UPDATE_ISSUES_MUTATION, { ids, input });
   }
 
   // Create multiple labels
   async createIssueLabels(labels: LabelInput[]): Promise<LabelResponse> {
     const { CREATE_ISSUE_LABELS } = await import('./mutations.js');
-    return this.execute<LabelResponse>(CREATE_ISSUE_LABELS, { labels });
+    return this.executeData<LabelResponse>(CREATE_ISSUE_LABELS, { labels });
   }
 
-  // Search issues with pagination
+  // Search issues with pagination — uses raw GraphQL to avoid SDK
+  // variable-mapping bugs (the SDK's searchIssues can leak the query
+  // term into the $filter variable on some SDK/API version combinations).
   async searchIssues(
-    filter: SearchIssuesInput['filter'], 
-    first: number = 50, 
-    after?: string, 
-    orderBy: string = "updatedAt"
+    query: string,
+    options: Omit<SearchIssuesInput, 'query'> = {}
   ): Promise<SearchIssuesResponse> {
+    const first = options.first ?? 50;
+    const exactIdentifierFilter = this.buildIssueIdentifierFilter(query, options.filter);
+    const filter = exactIdentifierFilter ?? options.filter;
+
     const { SEARCH_ISSUES_QUERY } = await import('./queries.js');
-    return this.execute<SearchIssuesResponse>(SEARCH_ISSUES_QUERY, {
-      filter,
+
+    const variables: Record<string, unknown> = {
+      term: query,
       first,
-      after,
-      orderBy,
-    });
+    };
+
+    if (filter && Object.keys(filter).length > 0) {
+      variables.filter = filter;
+    }
+
+    if (options.after !== undefined) {
+      variables.after = options.after;
+    }
+
+    const result = await this.executeData<{ searchIssues: {
+      totalCount?: number;
+      pageInfo: { hasNextPage: boolean; endCursor: string | null };
+      nodes: Issue[];
+    } }>(SEARCH_ISSUES_QUERY, variables, { allowRetry: true });
+
+    const payload = {
+      issues: {
+        pageInfo: result.searchIssues.pageInfo,
+        nodes: result.searchIssues.nodes ?? [],
+      },
+      totalCount: result.searchIssues.totalCount,
+    };
+
+    if (options.after === undefined && payload.issues.nodes.length === 0) {
+      const exactIssue = await this.findIssueByIdentifier(query, options.filter);
+      if (exactIssue) {
+        return {
+          issues: {
+            pageInfo: {
+              hasNextPage: false,
+              endCursor: null,
+            },
+            nodes: first > 0 ? [exactIssue as Issue] : [],
+          },
+          totalCount: 1,
+        };
+      }
+    }
+
+    return payload;
+  }
+
+  async findIssueByIdentifier(
+    identifier: string,
+    extraFilter: Record<string, unknown> = {}
+  ): Promise<unknown | undefined> {
+    const filter = this.buildIssueIdentifierFilter(identifier, extraFilter);
+    if (!filter) {
+      return undefined;
+    }
+
+    const connection = await this.executeSdk(
+      'issues',
+      () => this.sdk.issues({
+        filter,
+        first: 1,
+      })
+    );
+
+    const nodes = asRecord(connection).nodes;
+    return Array.isArray(nodes) ? nodes[0] : undefined;
   }
 
   // Get teams with their states and labels
   async getTeams(): Promise<TeamResponse> {
     const { GET_TEAMS_QUERY } = await import('./queries.js');
-    return this.execute<TeamResponse>(GET_TEAMS_QUERY);
+    return this.executeData<TeamResponse>(GET_TEAMS_QUERY, undefined, { allowRetry: true });
   }
 
   // Get current user info
   async getCurrentUser(): Promise<UserResponse> {
     const { GET_USER_QUERY } = await import('./queries.js');
-    return this.execute<UserResponse>(GET_USER_QUERY);
+    return this.executeData<UserResponse>(GET_USER_QUERY, undefined, { allowRetry: true });
   }
 
   // Get project info with documentContent support
   async getProject(id: string): Promise<GetProjectResponse> {
     const { GET_PROJECT_QUERY } = await import('./queries.js');
-    return this.execute<GetProjectResponse>(GET_PROJECT_QUERY, { id });
+    return this.executeData<GetProjectResponse>(GET_PROJECT_QUERY, { id }, { allowRetry: true });
   }
 
   // Search projects with documentContent support
   async searchProjects(filter: { name?: { eq: string } }): Promise<SearchProjectsResponse> {
     const { SEARCH_PROJECTS_QUERY } = await import('./queries.js');
-    return this.execute<SearchProjectsResponse>(SEARCH_PROJECTS_QUERY, { filter });
+    return this.executeData<SearchProjectsResponse>(SEARCH_PROJECTS_QUERY, { filter }, { allowRetry: true });
   }
 
   // Delete a single issue
   async deleteIssue(id: string): Promise<DeleteIssueResponse> {
     const { DELETE_ISSUE_MUTATION } = await import('./mutations.js');
-    return this.execute<DeleteIssueResponse>(DELETE_ISSUE_MUTATION, {
+    return this.executeData<DeleteIssueResponse>(DELETE_ISSUE_MUTATION, {
       id,
     })
   }
 
   // Delete multiple issues
-  async deleteIssues(ids: string[]): Promise<DeleteIssueResponse> {
+  async deleteIssues(ids: string[]): Promise<DeleteIssuesResponse> {
     const { DELETE_ISSUES_MUTATION } = await import('./mutations.js');
-    return this.execute<DeleteIssueResponse>(DELETE_ISSUES_MUTATION, { ids });
+    return this.executeData<DeleteIssuesResponse>(DELETE_ISSUES_MUTATION, { ids });
+  }
+
+  async getComment({ id }: GetCommentInput): Promise<GetCommentResponse> {
+    const { GET_COMMENT_QUERY } = await import('./queries.js');
+    return this.executeData<GetCommentResponse>(GET_COMMENT_QUERY, { id }, { allowRetry: true });
+  }
+
+  async listComments(options: ListCommentsInput = {}): Promise<ListCommentsResponse> {
+    const { LIST_COMMENTS_QUERY } = await import('./queries.js');
+    const first = options.first ?? (options.last === undefined ? 50 : undefined);
+
+    return this.executeData<ListCommentsResponse>(LIST_COMMENTS_QUERY, {
+      first,
+      after: options.after,
+      last: options.last,
+      before: options.before,
+      filter: options.filter,
+      includeArchived: options.includeArchived ?? false,
+      orderBy: options.orderBy ?? 'createdAt',
+    }, { allowRetry: true });
   }
 
   // Get comments for an issue
-  async getIssueComments(
-    issueId: string,
-    first: number = 50,
-    after?: string,
-    includeArchived: boolean = false
-  ): Promise<GetIssueCommentsResponse> {
+  async getIssueComments(options: GetIssueCommentsInput): Promise<GetIssueCommentsResponse> {
     const { GET_ISSUE_COMMENTS_QUERY } = await import('./queries.js');
-    return this.execute<GetIssueCommentsResponse>(GET_ISSUE_COMMENTS_QUERY, {
-      issueId,
+    const first = options.first ?? (options.last === undefined ? 50 : undefined);
+
+    return this.executeData<GetIssueCommentsResponse>(GET_ISSUE_COMMENTS_QUERY, {
+      issueId: options.issueId,
       first,
-      after,
-      includeArchived
+      after: options.after,
+      last: options.last,
+      before: options.before,
+      filter: options.filter,
+      includeArchived: options.includeArchived ?? false,
+      orderBy: options.orderBy ?? 'createdAt',
+    }, { allowRetry: true });
+  }
+
+  private parseIssueIdentifier(identifier: string): {
+    teamKey: string;
+    issueNumber: number;
+  } | undefined {
+    const match = identifier.trim().match(/^([A-Za-z][A-Za-z0-9]*)-(\d+)$/);
+    if (!match) {
+      return undefined;
+    }
+
+    const issueNumber = Number.parseInt(match[2], 10);
+    if (!Number.isSafeInteger(issueNumber)) {
+      return undefined;
+    }
+
+    return {
+      teamKey: match[1].toUpperCase(),
+      issueNumber,
+    };
+  }
+
+  private buildIssueIdentifierFilter(
+    identifier: string,
+    extraFilter: Record<string, unknown> = {}
+  ): Record<string, unknown> | undefined {
+    const parsed = this.parseIssueIdentifier(identifier);
+    if (!parsed) {
+      return undefined;
+    }
+
+    return compactObject({
+      ...extraFilter,
+      team: {
+        ...asRecord(extraFilter.team),
+        key: {
+          eq: parsed.teamKey,
+        },
+      },
+      number: {
+        eq: parsed.issueNumber,
+      },
     });
   }
 
   // Create a comment
   async createComment(input: CreateCommentInput): Promise<CreateCommentResponse> {
     const { CREATE_COMMENT_MUTATION } = await import('./mutations.js');
-    return this.execute<CreateCommentResponse>(CREATE_COMMENT_MUTATION, { input });
+    return this.executeData<CreateCommentResponse>(CREATE_COMMENT_MUTATION, { input });
+  }
+
+  async updateComment({ id, ...input }: UpdateCommentInput): Promise<UpdateCommentResponse> {
+    const { UPDATE_COMMENT_MUTATION } = await import('./mutations.js');
+    return this.executeData<UpdateCommentResponse>(UPDATE_COMMENT_MUTATION, {
+      id,
+      input,
+    });
+  }
+
+  async deleteComment({ id }: DeleteCommentInput): Promise<DeleteCommentResponse> {
+    const { DELETE_COMMENT_MUTATION } = await import('./mutations.js');
+    return this.executeData<DeleteCommentResponse>(DELETE_COMMENT_MUTATION, { id });
+  }
+
+  async resolveComment({
+    id,
+    resolvingCommentId,
+  }: ResolveCommentInput): Promise<ResolveCommentResponse> {
+    const { RESOLVE_COMMENT_MUTATION } = await import('./mutations.js');
+    return this.executeData<ResolveCommentResponse>(RESOLVE_COMMENT_MUTATION, {
+      id,
+      resolvingCommentId,
+    });
+  }
+
+  async unresolveComment({ id }: UnresolveCommentInput): Promise<UnresolveCommentResponse> {
+    const { UNRESOLVE_COMMENT_MUTATION } = await import('./mutations.js');
+    return this.executeData<UnresolveCommentResponse>(UNRESOLVE_COMMENT_MUTATION, {
+      id,
+    });
   }
 
   // Create a project milestone
   async createProjectMilestone(input: ProjectMilestoneCreateInput): Promise<ProjectMilestoneResponse> {
     const { CREATE_PROJECT_MILESTONE_MUTATION } = await import('./mutations.js');
-    return this.execute<ProjectMilestoneResponse>(CREATE_PROJECT_MILESTONE_MUTATION, { input });
+    return this.executeData<ProjectMilestoneResponse>(CREATE_PROJECT_MILESTONE_MUTATION, { input });
   }
 
   // Update a project milestone
   async updateProjectMilestone(id: string, input: ProjectMilestoneUpdateInput): Promise<ProjectMilestoneUpdateResponse> {
     const { UPDATE_PROJECT_MILESTONE_MUTATION } = await import('./mutations.js');
-    return this.execute<ProjectMilestoneUpdateResponse>(UPDATE_PROJECT_MILESTONE_MUTATION, { id, input });
+    return this.executeData<ProjectMilestoneUpdateResponse>(UPDATE_PROJECT_MILESTONE_MUTATION, { id, input });
   }
 
   // Delete a project milestone
   async deleteProjectMilestone(id: string): Promise<ProjectMilestoneDeleteResponse> {
     const { DELETE_PROJECT_MILESTONE_MUTATION } = await import('./mutations.js');
-    return this.execute<ProjectMilestoneDeleteResponse>(DELETE_PROJECT_MILESTONE_MUTATION, { id });
+    return this.executeData<ProjectMilestoneDeleteResponse>(DELETE_PROJECT_MILESTONE_MUTATION, { id });
   }
 
   // Get a specific project milestone
   async getProjectMilestone(id: string): Promise<GetProjectMilestoneResponse> {
     const { GET_PROJECT_MILESTONE_QUERY } = await import('./queries.js');
-    return this.execute<GetProjectMilestoneResponse>(GET_PROJECT_MILESTONE_QUERY, { id });
+    return this.executeData<GetProjectMilestoneResponse>(GET_PROJECT_MILESTONE_QUERY, { id }, { allowRetry: true });
   }
 
   // Search project milestones with filtering and pagination
@@ -252,11 +636,251 @@ export class LinearGraphQLClient {
     orderBy?: string;
   } = {}): Promise<SearchProjectMilestonesResponse> {
     const { SEARCH_PROJECT_MILESTONES_QUERY } = await import('./queries.js');
-    return this.execute<SearchProjectMilestonesResponse>(SEARCH_PROJECT_MILESTONES_QUERY, {
+    return this.executeData<SearchProjectMilestonesResponse>(SEARCH_PROJECT_MILESTONES_QUERY, {
       filter: options.filter,
       first: options.first || 50,
       after: options.after,
       orderBy: options.orderBy || 'updatedAt'
+    }, { allowRetry: true });
+  }
+
+  private getOperationName(document: DocumentNode): string {
+    const definition = document.definitions.find(
+      (item): item is OperationDefinitionNode => item.kind === Kind.OPERATION_DEFINITION
+    );
+
+    return definition?.name?.value ?? 'anonymousOperation';
+  }
+
+  private normalizeHeaders(
+    headers?: Headers | Map<string, string> | Record<string, string>
+  ): Record<string, string> {
+    if (!headers) {
+      return {};
+    }
+
+    if (headers instanceof Headers) {
+      return Object.fromEntries(headers.entries());
+    }
+
+    if (headers instanceof Map) {
+      return Object.fromEntries(headers.entries());
+    }
+
+    return headers;
+  }
+
+  private normalizeExtensions(
+    extensions?: unknown
+  ): Record<string, unknown> | undefined {
+    if (!extensions || typeof extensions !== 'object' || Array.isArray(extensions)) {
+      return undefined;
+    }
+
+    return extensions as Record<string, unknown>;
+  }
+
+  private createErrorResult(
+    operationName: string,
+    error: unknown
+  ): GraphQLResult<unknown> {
+    if (error instanceof RequestTimeoutError) {
+      return {
+        errors: [
+          {
+            message: error.message,
+            extensions: {
+              code: 'TIMEOUT',
+            },
+          },
+        ],
+        meta: {
+          status: 408,
+          retryable: true,
+          headers: {},
+        },
+      };
+    }
+
+    const response = this.extractRawResponse(error);
+    return {
+      data: response.data,
+      errors: this.normalizeErrors(response.errors) ?? [
+        {
+          message: error instanceof Error ? error.message : `GraphQL operation ${operationName} failed`,
+        },
+      ],
+      extensions: this.normalizeExtensions(response.extensions),
+      meta: {
+        status: response.status,
+        retryable: this.isRetryable(response.status, this.normalizeErrors(response.errors)),
+        headers: this.normalizeHeaders(response.headers),
+      },
+    };
+  }
+
+  private extractRawResponse(error: unknown): RawGraphQLResponse<unknown> {
+    if (typeof error !== 'object' || error === null) {
+      return {};
+    }
+
+    const response = (error as { response?: RawGraphQLResponse<unknown> }).response;
+    return response ?? {};
+  }
+
+  private normalizeErrors(errors?: unknown[]): GraphQLErrorDetail[] | undefined {
+    if (!errors || errors.length === 0) {
+      return undefined;
+    }
+
+    return errors.map(error => {
+      if (typeof error !== 'object' || error === null) {
+        return {
+          message: String(error),
+        };
+      }
+
+      const graphQLError = error as {
+        message?: unknown;
+        type?: unknown;
+        path?: unknown;
+        extensions?: unknown;
+      };
+
+      const message = typeof graphQLError.message === 'string'
+        ? graphQLError.message
+        : typeof graphQLError.type === 'string'
+          ? graphQLError.type
+          : 'Unknown GraphQL error';
+
+      const path = Array.isArray(graphQLError.path)
+        ? graphQLError.path.filter(
+            (segment): segment is string | number =>
+              typeof segment === 'string' || typeof segment === 'number'
+          )
+        : undefined;
+
+      const extensions = graphQLError.extensions && typeof graphQLError.extensions === 'object' && !Array.isArray(graphQLError.extensions)
+        ? graphQLError.extensions as Record<string, unknown>
+        : undefined;
+
+      return {
+        message,
+        path,
+        extensions,
+      };
     });
   }
+
+  private isRetryable(
+    status?: number,
+    errors?: GraphQLErrorDetail[]
+  ): boolean {
+    if (status !== undefined && [408, 409, 425, 429, 500, 502, 503, 504].includes(status)) {
+      return true;
+    }
+
+    return (errors ?? []).some(error => {
+      const code = typeof error.extensions?.code === 'string'
+        ? error.extensions.code.toUpperCase()
+        : '';
+
+      return ['RATE_LIMITED', 'THROTTLED', 'TIMEOUT', 'INTERNAL_SERVER_ERROR', 'SERVICE_UNAVAILABLE'].includes(code);
+    });
+  }
+
+  private buildErrorMessage(
+    operationName: string,
+    errors?: GraphQLErrorDetail[]
+  ): string {
+    const firstMessage = errors?.[0]?.message;
+    return firstMessage
+      ? `GraphQL operation ${operationName} failed: ${firstMessage}`
+      : `GraphQL operation ${operationName} failed`;
+  }
+
+  private buildRequestPolicy(
+    operationName: string,
+    allowRetry: boolean
+  ): RequestPolicyOptions {
+    return {
+      timeoutMs: this.options.requestTimeoutMs ?? DEFAULT_LINEAR_REQUEST_TIMEOUT_MS,
+      maxAttempts: allowRetry
+        ? Math.max(this.options.safeReadMaxAttempts ?? DEFAULT_SAFE_READ_MAX_ATTEMPTS, 1)
+        : 1,
+      retryDelayMs: allowRetry
+        ? Math.max(this.options.safeReadRetryDelayMs ?? DEFAULT_SAFE_READ_RETRY_DELAY_MS, 0)
+        : 0,
+      shouldRetry: error => allowRetry && this.isRetryableError(operationName, error),
+    };
+  }
+
+  private isRetryableError(
+    operationName: string,
+    error: unknown
+  ): boolean {
+    if (error instanceof LinearGraphQLRequestError) {
+      return error.result.meta.retryable;
+    }
+
+    return this.createErrorResult(operationName, error).meta.retryable;
+  }
+
+  private async compensateProjectIssueFailure(
+    project: ProjectResponse['projectCreate']['project'],
+    projectResult: ProjectResponse,
+    issuesResult?: IssueBatchResponse,
+    issueError?: unknown
+  ): Promise<ProjectWithIssuesOutcome> {
+    const projectId = project?.id;
+    const projectDeleteResult = projectId
+      ? await this.tryDeleteProject(projectId)
+      : { success: false, error: 'Project identifier was not available for compensation.' };
+
+    const baseMessage = issueError instanceof Error
+      ? issueError.message
+      : 'Issue creation did not complete successfully.';
+    const issues = issuesResult?.issueBatchCreate.issues ?? [];
+
+    return {
+      success: false,
+      failedStep: 'issueBatchCreate',
+      message: projectDeleteResult.success
+        ? `Issue creation failed after project creation. The created project was deleted during compensation. ${baseMessage}`
+        : `Issue creation failed after project creation and compensation did not remove the created project. ${baseMessage}`,
+      issueCreationAttempted: true,
+      compensationAttempted: true,
+      compensationSucceeded: projectDeleteResult.success,
+      project,
+      issues,
+      lastSyncId: issuesResult?.issueBatchCreate.lastSyncId ?? projectResult.projectCreate.lastSyncId,
+      projectCreate: projectResult.projectCreate,
+      issueBatchCreate: issuesResult?.issueBatchCreate,
+    };
+  }
+
+  private async tryDeleteProject(
+    projectId: string
+  ): Promise<{ success: true } | { success: false; error: string }> {
+    try {
+      const payload = await this.executeSdk(
+        'deleteProject',
+        () => this.linearClient.deleteProject(projectId)
+      );
+
+      if (getBoolean(payload, 'success') ?? true) {
+        return { success: true };
+      }
+
+      return {
+        success: false,
+        error: 'Project deletion returned success false during compensation.',
+      };
+    } catch (error) {
+      return {
+        success: false,
+        error: error instanceof Error ? error.message : 'Unknown compensation error',
+      };
+    }
+  }
 }
diff --git a/src/graphql/mutations.ts b/src/graphql/mutations.ts
index 9d82025..2835caf 100644
--- a/src/graphql/mutations.ts
+++ b/src/graphql/mutations.ts
@@ -1,29 +1,67 @@
 import { gql } from 'graphql-tag';
 
-export const CREATE_ISSUE_MUTATION = gql`
-  mutation CreateIssue($input: IssueCreateInput!) {
-    issueCreate(input: $input) {
-      success
-      issue {
-        id
-        identifier
-        title
-        url
-        team {
-          id
-          name
-        }
-        project {
-          id
-          name
-        }
-      }
-    }
+const COMMENT_USER_FIELDS = `
+  id
+  name
+  email
+`;
+
+const COMMENT_REFERENCE_FIELDS = `
+  id
+  body
+  url
+  createdAt
+  updatedAt
+  user {
+    ${COMMENT_USER_FIELDS}
+  }
+`;
+
+const COMMENT_FIELDS = `
+  id
+  body
+  bodyData
+  quotedText
+  url
+  archivedAt
+  createdAt
+  updatedAt
+  editedAt
+  resolvedAt
+  issueId
+  parentId
+  resolvingCommentId
+  reactionData
+  user {
+    ${COMMENT_USER_FIELDS}
+  }
+  issue {
+    id
+    identifier
+    title
+    url
+  }
+  parent {
+    ${COMMENT_REFERENCE_FIELDS}
+  }
+  resolvingComment {
+    ${COMMENT_REFERENCE_FIELDS}
+  }
+  resolvingUser {
+    ${COMMENT_USER_FIELDS}
+  }
+`;
+
+const COMMENT_MUTATION_PAYLOAD_FIELDS = `
+  success
+  comment {
+    ${COMMENT_FIELDS}
   }
+  lastSyncId
 `;
 
-export const CREATE_ISSUES_MUTATION = gql`
-  mutation CreateIssues($input: [IssueCreateInput!]!) {
+export const CREATE_ISSUE_MUTATION = gql`
+  mutation CreateIssue($input: IssueCreateInput!) {
     issueCreate(input: $input) {
       success
       issue {
@@ -139,35 +177,45 @@ export const CREATE_ISSUE_LABELS = gql`
 export const CREATE_COMMENT_MUTATION = gql`
   mutation CreateComment($input: CommentCreateInput!) {
     commentCreate(input: $input) {
+      ${COMMENT_MUTATION_PAYLOAD_FIELDS}
+    }
+  }
+`;
+
+export const UPDATE_COMMENT_MUTATION = gql`
+  mutation UpdateComment($id: String!, $input: CommentUpdateInput!) {
+    commentUpdate(id: $id, input: $input) {
+      ${COMMENT_MUTATION_PAYLOAD_FIELDS}
+    }
+  }
+`;
+
+export const DELETE_COMMENT_MUTATION = gql`
+  mutation DeleteComment($id: String!) {
+    commentDelete(id: $id) {
       success
-      comment {
-        id
-        body
-        user {
-          id
-          name
-          email
-        }
-        issue {
-          id
-          title
-        }
-        parent {
-          id
-          body
-          user {
-            id
-            name
-          }
-        }
-        createdAt
-        updatedAt
-      }
+      entityId
       lastSyncId
     }
   }
 `;
 
+export const RESOLVE_COMMENT_MUTATION = gql`
+  mutation ResolveComment($id: String!, $resolvingCommentId: String) {
+    commentResolve(id: $id, resolvingCommentId: $resolvingCommentId) {
+      ${COMMENT_MUTATION_PAYLOAD_FIELDS}
+    }
+  }
+`;
+
+export const UNRESOLVE_COMMENT_MUTATION = gql`
+  mutation UnresolveComment($id: String!) {
+    commentUnresolve(id: $id) {
+      ${COMMENT_MUTATION_PAYLOAD_FIELDS}
+    }
+  }
+`;
+
 export const CREATE_PROJECT_MILESTONE_MUTATION = gql`
   mutation CreateProjectMilestone($input: ProjectMilestoneCreateInput!) {
     projectMilestoneCreate(input: $input) {
diff --git a/src/graphql/queries.ts b/src/graphql/queries.ts
index 8c4b4f1..b84c2a8 100644
--- a/src/graphql/queries.ts
+++ b/src/graphql/queries.ts
@@ -1,60 +1,54 @@
 import { gql } from 'graphql-tag';
 
-export const SEARCH_ISSUES_QUERY = gql`
-  query SearchIssues(
-    $filter: IssueFilter
-    $first: Int
-    $after: String
-    $orderBy: PaginationOrderBy
-  ) {
-    issues(
-      filter: $filter
-      first: $first
-      after: $after
-      orderBy: $orderBy
-    ) {
-      pageInfo {
-        hasNextPage
-        endCursor
-      }
-      nodes {
-        id
-        identifier
-        title
-        description
-        url
-        state {
-          id
-          name
-          type
-          color
-        }
-        assignee {
-          id
-          name
-          email
-        }
-        team {
-          id
-          name
-          key
-        },
-        project {
-          id
-          name
-        },
-        priority
-        labels {
-          nodes {
-            id
-            name
-            color
-          }
-        }
-        createdAt
-        updatedAt
-      }
-    }
+const COMMENT_USER_FIELDS = `
+  id
+  name
+  email
+`;
+
+const COMMENT_REFERENCE_FIELDS = `
+  id
+  body
+  url
+  createdAt
+  updatedAt
+  user {
+    ${COMMENT_USER_FIELDS}
+  }
+`;
+
+const COMMENT_FIELDS = `
+  id
+  body
+  bodyData
+  quotedText
+  url
+  archivedAt
+  createdAt
+  updatedAt
+  editedAt
+  resolvedAt
+  issueId
+  parentId
+  resolvingCommentId
+  reactionData
+  user {
+    ${COMMENT_USER_FIELDS}
+  }
+  issue {
+    id
+    identifier
+    title
+    url
+  }
+  parent {
+    ${COMMENT_REFERENCE_FIELDS}
+  }
+  resolvingComment {
+    ${COMMENT_REFERENCE_FIELDS}
+  }
+  resolvingUser {
+    ${COMMENT_USER_FIELDS}
   }
 `;
 
@@ -147,62 +141,123 @@ export const GET_PROJECT_QUERY = gql`
   }
 `;
 
+export const GET_COMMENT_QUERY = gql`
+  query GetComment($id: String!) {
+    comment(id: $id) {
+      ${COMMENT_FIELDS}
+    }
+  }
+`;
+
+export const LIST_COMMENTS_QUERY = gql`
+  query ListComments(
+    $first: Int
+    $after: String
+    $last: Int
+    $before: String
+    $filter: CommentFilter
+    $includeArchived: Boolean
+    $orderBy: PaginationOrderBy
+  ) {
+    comments(
+      first: $first
+      after: $after
+      last: $last
+      before: $before
+      filter: $filter
+      includeArchived: $includeArchived
+      orderBy: $orderBy
+    ) {
+      pageInfo {
+        hasNextPage
+        endCursor
+        hasPreviousPage
+        startCursor
+      }
+      nodes {
+        ${COMMENT_FIELDS}
+      }
+    }
+  }
+`;
+
 export const GET_ISSUE_COMMENTS_QUERY = gql`
   query GetIssueComments(
     $issueId: String!
     $first: Int
     $after: String
+    $last: Int
+    $before: String
+    $filter: CommentFilter
     $includeArchived: Boolean
+    $orderBy: PaginationOrderBy
   ) {
     issue(id: $issueId) {
       id
+      identifier
       title
+      url
       comments(
         first: $first
         after: $after
+        last: $last
+        before: $before
+        filter: $filter
         includeArchived: $includeArchived
-        orderBy: createdAt
+        orderBy: $orderBy
       ) {
         pageInfo {
           hasNextPage
           endCursor
+          hasPreviousPage
+          startCursor
         }
         nodes {
-          id
-          body
-          bodyData
-          user {
-            id
-            name
-            email
-          }
-          parent {
-            id
-            body
-            user {
-              id
-              name
-            }
-          }
-          children(first: 10) {
-            nodes {
-              id
-              body
-              user {
-                id
-                name
-              }
-              createdAt
-            }
-          }
-          createdAt
-          updatedAt
+          ${COMMENT_FIELDS}
         }
       }
     }
   }
 `;
 
+export const SEARCH_ISSUES_QUERY = gql`
+  query SearchIssues(
+    $term: String!
+    $filter: IssueFilter
+    $first: Int
+    $after: String
+    $includeArchived: Boolean
+    $orderBy: PaginationOrderBy
+  ) {
+    searchIssues(
+      term: $term
+      filter: $filter
+      first: $first
+      after: $after
+      includeArchived: $includeArchived
+      orderBy: $orderBy
+    ) {
+      totalCount
+      pageInfo {
+        hasNextPage
+        endCursor
+      }
+      nodes {
+        id
+        identifier
+        title
+        description
+        url
+        priority
+        estimate
+        dueDate
+        createdAt
+        updatedAt
+      }
+    }
+  }
+`;
+
 export const SEARCH_PROJECT_MILESTONES_QUERY = gql`
   query SearchProjectMilestones(
     $filter: ProjectMilestoneFilter
diff --git a/src/index.ts b/src/index.ts
index ed8bbd3..5331abc 100644
--- a/src/index.ts
+++ b/src/index.ts
@@ -1,6 +1,9 @@
 #!/usr/bin/env node
+import { randomUUID } from 'node:crypto';
+import { createServer, Server as HttpServer } from 'node:http';
 import { Server } from '@modelcontextprotocol/sdk/server/index.js';
 import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
+import { StreamableHTTPServerTransport } from '@modelcontextprotocol/sdk/server/streamableHttp.js';
 import {
   CallToolRequestSchema,
   ErrorCode,
@@ -8,25 +11,128 @@ import {
   McpError,
 } from '@modelcontextprotocol/sdk/types.js';
 import { LinearAuth } from './auth.js';
-import { LinearGraphQLClient } from './graphql/client.js';
+import {
+  RuntimeCapabilities,
+  getRuntimeCapabilities,
+  getStreamTransportConfig,
+} from './core/capabilities.js';
+import { RuntimeObservability } from './core/runtime-observability.js';
+import { formatServerBuildInfo, getServerBuildInfo } from './core/server-build.js';
 import { HandlerFactory } from './core/handlers/handler.factory.js';
-import { toolSchemas } from './core/types/tool.types.js';
+import { BaseToolResponse, ToolHandlerMethod } from './core/interfaces/tool-handler.interface.js';
+import { getAdvertisedToolSchemas } from './core/types/tool.types.js';
+import { ToolValidationResult, ToolValidatorRegistry } from './core/validation/tool-validator.js';
+
+export interface LinearServerOptions {
+  auth?: LinearAuth;
+  capabilities?: RuntimeCapabilities;
+}
+
+type StartupApiKeyEnvName = 'LINEAR_API_KEY' | 'LINEAR_ACCESS_TOKEN';
+
+interface StartupApiKeySelection {
+  apiKey?: string;
+  source?: StartupApiKeyEnvName;
+  hasPrimary: boolean;
+  hasAlias: boolean;
+}
+
+function resolveStartupApiKeySelection(env: NodeJS.ProcessEnv = process.env): StartupApiKeySelection {
+  const primaryApiKey = env.LINEAR_API_KEY;
+  const aliasApiKey = env.LINEAR_ACCESS_TOKEN;
+
+  if (primaryApiKey) {
+    return {
+      apiKey: primaryApiKey,
+      source: 'LINEAR_API_KEY',
+      hasPrimary: true,
+      hasAlias: Boolean(aliasApiKey),
+    };
+  }
+
+  if (aliasApiKey) {
+    return {
+      apiKey: aliasApiKey,
+      source: 'LINEAR_ACCESS_TOKEN',
+      hasPrimary: false,
+      hasAlias: true,
+    };
+  }
+
+  return {
+    hasPrimary: false,
+    hasAlias: false,
+  };
+}
+
+function formatStartupAuthMessage(selection: StartupApiKeySelection): string {
+  if (selection.source === 'LINEAR_API_KEY' && selection.hasAlias) {
+    return 'Auth: both LINEAR_API_KEY and LINEAR_ACCESS_TOKEN detected. Using LINEAR_API_KEY.';
+  }
+
+  if (selection.source === 'LINEAR_API_KEY') {
+    return 'Auth: LINEAR_API_KEY detected.';
+  }
+
+  if (selection.source === 'LINEAR_ACCESS_TOKEN') {
+    return 'Auth: LINEAR_ACCESS_TOKEN detected.';
+  }
+
+  return 'Auth: no LINEAR_API_KEY or LINEAR_ACCESS_TOKEN detected. Set either variable for API-key auth or use linear_auth to start OAuth after installation.';
+}
 
 /**
  * Main server class that handles MCP protocol interactions.
  * Delegates tool operations to domain-specific handlers.
  */
-class LinearServer {
+export class LinearServer {
   private server: Server;
-  private auth: LinearAuth;
-  private graphqlClient?: LinearGraphQLClient;
+  private readonly authTemplate: LinearAuth;
+  private readonly stdioAuth: LinearAuth;
+  private readonly streamSessions = new Map<string, {
+    server: Server;
+    transport: StreamableHTTPServerTransport;
+  }>();
   private handlerFactory: HandlerFactory;
+  private readonly toolValidators: ToolValidatorRegistry;
+  private capabilities: RuntimeCapabilities;
+  private readonly buildInfo = getServerBuildInfo();
+  private readonly startupApiKeySelection: StartupApiKeySelection;
+  private readonly observability: RuntimeObservability;
+  private httpServer?: HttpServer;
+  private readonly shutdownHandler = (): void => {
+    void this.close().finally(() => process.exit(0));
+  };
+
+  constructor(options: LinearServerOptions = {}) {
+    this.authTemplate = options.auth ?? new LinearAuth();
+    this.capabilities = options.capabilities ?? getRuntimeCapabilities({ server: this.buildInfo });
+
+    this.startupApiKeySelection = resolveStartupApiKeySelection();
+    const apiKey = this.startupApiKeySelection.apiKey;
+    if (apiKey && !options.auth) {
+      this.authTemplate.initialize({
+        type: 'api',
+        apiKey,
+      });
+    }
+
+    this.stdioAuth = this.authTemplate.createScopedCopy();
+    this.handlerFactory = new HandlerFactory(this.capabilities);
+    this.toolValidators = new ToolValidatorRegistry(this.capabilities);
+    this.observability = new RuntimeObservability(
+      this.capabilities,
+      () => this.streamSessions.size
+    );
+    this.server = this.createProtocolServer(this.stdioAuth);
+    process.once('SIGINT', this.shutdownHandler);
+  }
 
-  constructor() {
-    this.server = new Server(
+  private createProtocolServer(auth: LinearAuth): Server {
+    const server = new Server(
       {
-        name: 'linear-server',
-        version: '0.1.0',
+        name: this.buildInfo.name,
+        version: this.buildInfo.version,
       },
       {
         capabilities: {
@@ -35,61 +141,319 @@ class LinearServer {
       }
     );
 
-    this.auth = new LinearAuth();
-    
-    // Initialize with API Key if available
-    const apiKey = process.env.LINEAR_API_KEY;
-    if (apiKey) {
-      this.auth.initialize({
-        type: 'api',
-        apiKey
-      });
-      this.graphqlClient = new LinearGraphQLClient(this.auth.getClient());
-    }
-    
-    // Initialize handler factory
-    this.handlerFactory = new HandlerFactory(this.auth, this.graphqlClient);
-    
-    this.setupRequestHandlers();
-    
-    // Error handling
-    this.server.onerror = (error) => console.error('[MCP Error]', error);
-    process.on('SIGINT', async () => {
-      await this.server.close();
-      process.exit(0);
-    });
-  }
-
-  private setupRequestHandlers() {
-    // List available tools
-    this.server.setRequestHandler(ListToolsRequestSchema, async () => ({
-      tools: Object.values(toolSchemas),
+    server.setRequestHandler(ListToolsRequestSchema, async () => ({
+      tools: getAdvertisedToolSchemas(this.capabilities),
     }));
 
-    // Handle tool calls
-    this.server.setRequestHandler(CallToolRequestSchema, async (request) => {
+    server.setRequestHandler(CallToolRequestSchema, async (request): Promise<BaseToolResponse> => {
+      const startedAt = Date.now();
+      let telemetryResponse: BaseToolResponse | undefined;
+      let telemetryError: unknown;
+
       try {
-        const { handler, method } = this.handlerFactory.getHandlerForTool(request.params.name);
-        // Use type assertion to handle dynamic method access
-        return await (handler as any)[method](request.params.arguments);
-      } catch (error) {
-        if (error instanceof Error && error.message.startsWith('No handler found')) {
+        if (!this.toolValidators.hasTool(request.params.name)) {
           throw new McpError(
             ErrorCode.MethodNotFound,
             `Unknown tool: ${request.params.name}`
           );
         }
-        throw error;
+
+        const validation = this.toolValidators.validate(
+          request.params.name,
+          request.params.arguments
+        );
+
+        if (!validation.valid) {
+          telemetryResponse = this.createValidationErrorResponse(request.params.name, validation);
+          return telemetryResponse;
+        }
+
+        if (request.params.name === 'linear_get_runtime_diagnostics') {
+          telemetryResponse = this.createRuntimeDiagnosticsResponse();
+          return telemetryResponse;
+        }
+
+        const { handler, method } = this.handlerFactory.getHandlerForTool(request.params.name, auth);
+        const toolMethod = (handler as unknown as Record<string, ToolHandlerMethod>)[method];
+
+        if (typeof toolMethod !== 'function') {
+          throw new Error(`Handler method not found: ${method}`);
+        }
+
+        telemetryResponse = await toolMethod.call(
+          handler,
+          validation.data
+        );
+        return telemetryResponse;
+      } catch (error) {
+        telemetryError = error;
+
+        if (error instanceof McpError && error.code === ErrorCode.MethodNotFound) {
+          telemetryError = new McpError(
+            ErrorCode.MethodNotFound,
+            `Unknown tool: ${request.params.name}`
+          );
+          throw telemetryError;
+        }
+
+        if (error instanceof McpError) {
+          telemetryResponse = this.createRuntimeErrorResponse(
+            request.params.name,
+            'mcp',
+            error.message,
+            {
+              code: error.code,
+            }
+          );
+          return telemetryResponse;
+        }
+
+        const message = error instanceof Error ? error.message : 'Unknown error';
+        telemetryResponse = this.createRuntimeErrorResponse(
+          request.params.name,
+          'internal',
+          message
+        );
+        return telemetryResponse;
+      } finally {
+        const durationMs = Math.max(Date.now() - startedAt, 0);
+        if (telemetryResponse) {
+          this.observability.recordResponse(request.params.name, telemetryResponse, durationMs);
+        } else if (telemetryError) {
+          this.observability.recordError(request.params.name, telemetryError, durationMs);
+        }
       }
     });
+
+    server.onerror = error => console.error('[MCP Error]', error);
+    return server;
   }
 
-  async run() {
+  async run(): Promise<void> {
+    if (this.capabilities.transport === 'stream') {
+      await this.runStreamTransport();
+      return;
+    }
+
+    await this.runStdioTransport();
+  }
+
+  async close(): Promise<void> {
+    process.off('SIGINT', this.shutdownHandler);
+
+    const streamSessionServers = Array.from(this.streamSessions.values()).map(session => session.server);
+    this.streamSessions.clear();
+    await Promise.all(streamSessionServers.map(server => server.close().catch(() => undefined)));
+
+    if (this.httpServer) {
+      await new Promise<void>((resolve, reject) => {
+        this.httpServer?.close(error => error ? reject(error) : resolve());
+      });
+      this.httpServer = undefined;
+    }
+
+    await this.server.close();
+  }
+
+  private async runStdioTransport(): Promise<void> {
     const transport = new StdioServerTransport();
     await this.server.connect(transport);
-    console.error('Linear MCP server running on stdio');
+    this.logStartup();
+  }
+
+  private async runStreamTransport(): Promise<void> {
+    const streamConfig = getStreamTransportConfig();
+
+    this.httpServer = createServer(async (req, res) => {
+      const baseUrl = `http://${req.headers.host ?? `${streamConfig.host}:${streamConfig.port}`}`;
+      const requestUrl = new URL(req.url ?? '/', baseUrl);
+
+      if (requestUrl.pathname === streamConfig.path) {
+        try {
+          await this.handleStreamRequest(req, res);
+        } catch (error) {
+          console.error('[MCP HTTP Error]', error);
+          if (!res.headersSent) {
+            res.statusCode = 500;
+            res.setHeader('content-type', 'text/plain; charset=utf-8');
+            res.end('Failed to handle MCP stream request.');
+          }
+        }
+        return;
+      }
+
+      res.statusCode = 404;
+      res.setHeader('content-type', 'text/plain; charset=utf-8');
+
+      if (requestUrl.pathname === '/sse') {
+        res.end(`Legacy /sse is not exposed. Use the MCP streamable HTTP endpoint at ${streamConfig.path}.`);
+        return;
+      }
+
+      res.end(`No MCP endpoint is available at ${requestUrl.pathname}. Use ${streamConfig.path}.`);
+    });
+
+    await new Promise<void>((resolve, reject) => {
+      this.httpServer?.once('error', reject);
+      this.httpServer?.listen(streamConfig.port, streamConfig.host, () => resolve());
+    });
+
+    this.logStartup(streamConfig.endpoint);
+  }
+
+  private logStartup(endpoint?: string): void {
+    console.error(`Build: ${formatServerBuildInfo(this.capabilities.server)}`);
+
+    if (this.capabilities.transport === 'stream' && endpoint) {
+      console.error(`Linear MCP server running on stream transport at ${endpoint}`);
+      console.error('Use MCP streamable HTTP clients against this endpoint. Legacy /sse is not exposed.');
+    } else {
+      console.error('Linear MCP server running on stdio');
+      console.error('Remote stream endpoint is disabled in stdio mode. Set LINEAR_MCP_TRANSPORT=stream to expose a remote MCP endpoint.');
+    }
+
+    console.error(formatStartupAuthMessage(this.startupApiKeySelection));
+  }
+
+  private createValidationErrorResponse(
+    toolName: string,
+    validation: Extract<ToolValidationResult, { valid: false }>
+  ): BaseToolResponse {
+    return this.createRuntimeErrorResponse(
+      toolName,
+      'validation',
+      validation.message,
+      {
+        code: ErrorCode.InvalidParams,
+        details: validation.issues,
+      }
+    );
+  }
+
+  private createRuntimeErrorResponse(
+    toolName: string,
+    type: 'internal' | 'mcp' | 'validation',
+    message: string,
+    details: Record<string, unknown> = {}
+  ): BaseToolResponse {
+    return {
+      content: [
+        {
+          type: 'text',
+          text: `Failed to execute ${toolName}: ${message}`,
+        },
+      ],
+      structuredContent: {
+        tool: toolName,
+        error: {
+          type,
+          message,
+          ...details,
+        },
+      },
+      isError: true,
+    };
+  }
+
+  private createRuntimeDiagnosticsResponse(): BaseToolResponse {
+    return {
+      content: [
+        {
+          type: 'text',
+          text: 'Reported live runtime diagnostics',
+        },
+      ],
+      structuredContent: this.observability.createDiagnosticsSnapshot({
+        startupSource: this.startupApiKeySelection.source,
+        hasPrimaryEnv: this.startupApiKeySelection.hasPrimary,
+        hasAliasEnv: this.startupApiKeySelection.hasAlias,
+        stdioAuthenticated: this.stdioAuth.isAuthenticated(),
+      }),
+    };
+  }
+
+  private async handleStreamRequest(
+    req: Parameters<StreamableHTTPServerTransport['handleRequest']>[0],
+    res: Parameters<StreamableHTTPServerTransport['handleRequest']>[1]
+  ): Promise<void> {
+    const sessionIdHeader = req.headers['mcp-session-id'];
+    const sessionId = Array.isArray(sessionIdHeader) ? sessionIdHeader[0] : sessionIdHeader;
+
+    if (sessionId) {
+      const existingSession = this.streamSessions.get(sessionId);
+      if (!existingSession) {
+        this.writeJsonRpcError(res, 404, -32001, 'Session not found');
+        return;
+      }
+
+      await existingSession.transport.handleRequest(req, res);
+      return;
+    }
+
+    const auth = this.authTemplate.createScopedCopy();
+    const server = this.createProtocolServer(auth);
+    const transport = new StreamableHTTPServerTransport({
+      sessionIdGenerator: () => randomUUID(),
+    });
+
+    transport.onclose = () => {
+      if (transport.sessionId) {
+        this.streamSessions.delete(transport.sessionId);
+      }
+    };
+
+    await server.connect(transport);
+
+    try {
+      await transport.handleRequest(req, res);
+
+      if (transport.sessionId) {
+        this.streamSessions.set(transport.sessionId, {
+          server,
+          transport,
+        });
+        return;
+      }
+    } catch (error) {
+      await server.close().catch(() => undefined);
+      throw error;
+    }
+
+    await server.close().catch(() => undefined);
+  }
+
+  private writeJsonRpcError(
+    res: Parameters<StreamableHTTPServerTransport['handleRequest']>[1],
+    status: number,
+    code: number,
+    message: string
+  ): void {
+    res.statusCode = status;
+    res.setHeader('content-type', 'application/json');
+    res.end(JSON.stringify({
+      jsonrpc: '2.0',
+      error: {
+        code,
+        message,
+      },
+      id: null,
+    }));
   }
 }
 
-const server = new LinearServer();
-server.run().catch(console.error);
+export async function runCli(): Promise<void> {
+  const server = new LinearServer();
+  await server.run();
+}
+
+const isMainModule = Boolean(
+  process.argv[1]
+  && /(?:^|[\\/])(?:build[\\/])?index\.(?:js|ts)$/.test(process.argv[1])
+);
+
+if (isMainModule) {
+  runCli().catch(error => {
+    console.error(error);
+    process.exitCode = 1;
+  });
+}
diff --git a/src/types/sdk.utils.ts b/src/types/sdk.utils.ts
new file mode 100644
index 0000000..0e875bb
--- /dev/null
+++ b/src/types/sdk.utils.ts
@@ -0,0 +1,106 @@
+export type SdkRecord = Record<string, unknown>;
+
+export function asRecord(value: unknown): SdkRecord {
+  return typeof value === 'object' && value !== null
+    ? value as SdkRecord
+    : {};
+}
+
+export function getString(value: unknown, key: string): string | undefined {
+  const record = asRecord(value);
+  return typeof record[key] === 'string' ? record[key] as string : undefined;
+}
+
+export function getNumber(value: unknown, key: string): number | undefined {
+  const record = asRecord(value);
+  return typeof record[key] === 'number' ? record[key] as number : undefined;
+}
+
+export function getBoolean(value: unknown, key: string): boolean | undefined {
+  const record = asRecord(value);
+  return typeof record[key] === 'boolean' ? record[key] as boolean : undefined;
+}
+
+export function getArray(value: unknown, key: string): unknown[] {
+  const record = asRecord(value);
+  return Array.isArray(record[key]) ? record[key] as unknown[] : [];
+}
+
+export function getDateString(value: unknown, key: string): string | undefined {
+  const property = asRecord(value)[key];
+  if (typeof property === 'string') {
+    return property;
+  }
+
+  if (property instanceof Date) {
+    return property.toISOString();
+  }
+
+  return undefined;
+}
+
+export function getObject(value: unknown, key: string): SdkRecord | undefined {
+  const record = asRecord(value);
+  return typeof record[key] === 'object' && record[key] !== null
+    ? record[key] as SdkRecord
+    : undefined;
+}
+
+export async function resolveValue<T>(value: Promise<T> | T | undefined | null): Promise<T | undefined> {
+  if (value === undefined || value === null) {
+    return undefined;
+  }
+
+  return Promise.resolve(value);
+}
+
+export async function callFetchMethod(
+  value: unknown,
+  methodName: string,
+  variables?: Record<string, unknown>
+): Promise<unknown | undefined> {
+  const record = asRecord(value);
+  const method = record[methodName];
+  if (typeof method !== 'function') {
+    return undefined;
+  }
+
+  return (method as (this: SdkRecord, variables?: Record<string, unknown>) => Promise<unknown>)
+    .call(record, variables);
+}
+
+export function compactObject<T extends Record<string, unknown>>(value: T): T {
+  return Object.fromEntries(
+    Object.entries(value).filter(([, entry]) => entry !== undefined)
+  ) as T;
+}
+
+export function toPageInfo(value: unknown): Record<string, unknown> {
+  const record = asRecord(value);
+  const startCursor = Object.prototype.hasOwnProperty.call(record, 'startCursor')
+    ? getString(record, 'startCursor') ?? null
+    : undefined;
+
+  return compactObject({
+    hasNextPage: getBoolean(record, 'hasNextPage') ?? false,
+    endCursor: getString(record, 'endCursor') ?? null,
+    hasPreviousPage: getBoolean(record, 'hasPreviousPage'),
+    startCursor,
+  });
+}
+
+export async function mapConnection(
+  connection: unknown,
+  mapNode: (node: unknown) => Promise<Record<string, unknown>> | Record<string, unknown>
+): Promise<{
+  nodes: Record<string, unknown>[];
+  pageInfo: Record<string, unknown>;
+}> {
+  const record = asRecord(connection);
+  const nodes = Array.isArray(record.nodes) ? record.nodes : [];
+
+  return {
+    nodes: await Promise.all(nodes.map(node => Promise.resolve(mapNode(node)))),
+    pageInfo: toPageInfo(record.pageInfo),
+  };
+}
diff --git a/} b/}
new file mode 100644
index 0000000..d0e848c
--- /dev/null
+++ b/}
@@ -0,0 +1,50 @@
+In a long-running process, these repeated imports may cause module cache lookups and minor GC pressure. Consider caching these imports at the module level or implementing an import-once pattern.
+
+**GraphQL Query Construction**
+The `searchIssues` method constructs filter objects through `buildIssueIdentifierFilter` which uses `compactObject` and `asRecord` utilities. This object manipulation on every search call adds overhead. Consider memoizing identifier parsing for repeated searches.
+
+**JSON Serialization in Telemetry**
+The `recordTelemetry` method uses `JSON.stringify(this.compactRecord(record))` on every request. For high-throughput scenarios, consider:
+- Using a structured logger that accepts objects directly
+- Implementing sampling for high-frequency operations
+- Batching telemetry records before output
+
+**Array Pre-allocation**
+In `mapWithConcurrencyLimit`, the results array is pre-allocated with `new Array<TResult>(items.length)`. While this is memory-efficient, consider whether sparse arrays (when concurrency < items.length during execution) cause deoptimization in V8.
+
+## Best Practices Analysis
+
+### Strengths
+
+**Strict Type Safety in Concurrency**
+The `mapWithConcurrencyLimit` function properly constrains generic types `TItem` and `TResult`, ensuring type safety across the concurrent mapping operation. The `readonly TItem[]` parameter declaration prevents accidental mutation of input arrays.
+
+**Exhaustive Error Handling**
+`src/core/request-policy.ts` implements comprehensive error propagation:
+- Distinguishes between timeout errors (`RequestTimeoutError`) and execution failures
+- Preserves error stack traces through the Promise chain
+- Implements exponential backoff with `retryDelayMs * attempt`
+
+**Defensive Programming**
+The codebase demonstrates excellent defensive patterns:
+- `Number.isInteger(concurrency) || concurrency < 1` validation prevents invalid concurrency configurations
+- `Math.max(options.timeoutMs, 1)` ensures minimum viable timeout values
+- `WeakMap` usage in handler caching (from summaries) prevents memory leaks
+
+**Structured Telemetry**
+`RuntimeObservability` implements a well-structured telemetry system with:
+- Discriminated unions for success/error outcomes
+- Private type guards (`asRecord`, `readBoolean`, `readNumber`, `readString`)
+- Immutable snapshot creation for diagnostics
+
+### Areas for Improvement
+
+**Type Assertion Usage**
+Several locations use `as` type assertions that could fail silently:
+- `src/core/concurrency.ts`: `items[currentIndex] as TItem` is unnecessary since `items` is already `readonly TItem[]`
+- `src/core/runtime-observability.ts`: Multiple `as Record<string, unknown>` casts bypass type safety
+
+Replace with runtime validation where possible, or remove unnecessary assertions.
+
+**Magic Numbers**
+`src/core/request-policy.ts` contains hardcoded status codes: