@scardis/omnifocus-mcp 0.1.0 → 0.1.2

package/openspec/changes/archive/2026-04-09-folder-tag-list-filtering/proposal.md

@@ -1,30 +0,0 @@
-## Why
-
-`list_folders` and `list_tags` return all items with no way to cap results or filter by status. While folders and tags are typically fewer than tasks or projects, users with large databases may have hundreds of tags (including dropped ones). Adding `limit` and optional `status` filtering completes the filtering pattern applied to `list_tasks` and `list_projects`.
-
-## What Changes
-
-- Add `limit` parameter to `list_folders` (default 200)
-- Add `status` filter to `list_folders`: when provided, restrict to folders with that status (`active` or `dropped`); when omitted, return all folders
-- Add `limit` parameter to `list_tags` (default 200)
-- Add `status` filter to `list_tags`: when provided, restrict to tags with that status (`active`, `onHold`, or `dropped`); when omitted, return all tags
-- All filtering happens inside the OmniJS snippet
-
-## Capabilities
-
-### New Capabilities
-
-_(none)_
-
-### Modified Capabilities
-
-- `folder-management`: `list_folders` gains `limit` and optional `status` filter
-- `tag-management`: `list_tags` gains `limit` and optional `status` filter
-
-## Impact
-
-- `src/schemas/shapes.ts`: add `ListFoldersFilter` and `ListTagsFilter` schemas
-- `src/schemas/index.ts`: export new filter schemas
-- `src/snippets/list_folders.js`, `list_tags.js`: add filter + limit logic
-- `src/tools/listFolders.ts`, `listTags.ts`: add filter + limit params
-- Unit and integration tests for both tools

package/openspec/changes/archive/2026-04-09-folder-tag-list-filtering/specs/folder-management/spec.md

@@ -1,21 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: List folders
-
-The system SHALL provide a `list_folders` tool that returns folders in the OmniFocus database as an array of summaries, each containing `{id, name, path, parentId, status}`. The `path` field SHALL use the canonical ` ▸ ` separator and SHALL equal the folder's name for top-level folders. The `parentId` field SHALL be `null` for top-level folders. The `status` field SHALL be one of `"active" | "dropped"`. The tool SHALL accept an optional `status` filter string and an optional `limit` integer (default 200). When `status` is omitted, all folders are returned regardless of status. When `limit` is omitted, at most 200 folders are returned.
-
-#### Scenario: All folders returned by default
-- **WHEN** `list_folders` is called with no arguments
-- **THEN** the tool returns all folders (active and dropped) up to the limit
-
-#### Scenario: Top-level folders have null parent
-- **WHEN** a folder exists at the root of the folder hierarchy
-- **THEN** its summary carries `parentId: null` and `path` equal to its name
-
-#### Scenario: Filter by status returns only matching folders
-- **WHEN** `list_folders` is called with `{ filter: { status: "active" } }`
-- **THEN** only active folders are returned
-
-#### Scenario: Limit caps the number of returned folders
-- **WHEN** `list_folders` is called with `{ limit: 5 }`
-- **THEN** at most 5 folders are returned

package/openspec/changes/archive/2026-04-09-folder-tag-list-filtering/specs/tag-management/spec.md

@@ -1,21 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: List tags
-
-The system SHALL provide a `list_tags` tool that returns tags in the OmniFocus database as an array of summaries, each containing `{id, name, path, parentId, status}`. Tags form a tree in OmniFocus; the `path` field SHALL use the canonical ` ▸ ` separator and represent the full ancestor chain. The `parentId` field SHALL be `null` for top-level tags. The `status` field SHALL be one of `"active" | "onHold" | "dropped"`. The tool SHALL accept an optional `status` filter string and an optional `limit` integer (default 200). When `status` is omitted, all tags are returned regardless of status. When `limit` is omitted, at most 200 tags are returned.
-
-#### Scenario: All tags returned by default
-- **WHEN** `list_tags` is called with no arguments
-- **THEN** the tool returns all tags (active, onHold, and dropped) up to the limit
-
-#### Scenario: On-hold tag is reported with correct status
-- **WHEN** the database contains a tag that has been placed on hold
-- **THEN** that tag appears in the result with `status: "onHold"`
-
-#### Scenario: Filter by status returns only matching tags
-- **WHEN** `list_tags` is called with `{ filter: { status: "active" } }`
-- **THEN** only active tags are returned
-
-#### Scenario: Limit caps the number of returned tags
-- **WHEN** `list_tags` is called with `{ limit: 5 }`
-- **THEN** at most 5 tags are returned

package/openspec/changes/archive/2026-04-09-folder-tag-list-filtering/tasks.md

@@ -1,35 +0,0 @@
-## 1. Schema changes (src/schemas/)
-
-- [x] 1.1 Define `ListFoldersFilter` zod schema: `{ status: FolderStatus.optional() }` in `shapes.ts`
-- [x] 1.2 Define `ListTagsFilter` zod schema: `{ status: TagStatus.optional() }` in `shapes.ts`
-- [x] 1.3 Export `ListFoldersFilter` and `ListTagsFilter` from `src/schemas/index.ts`
-
-## 2. Snippet updates (src/snippets/)
-
-- [x] 2.1 Update `list_folders.js`: add `filter` and `limit` args; apply status filter when `args.filter?.status` is provided; apply limit (default 200) as slice after filter
-- [x] 2.2 Update `list_tags.js`: add `filter` and `limit` args; apply status filter when `args.filter?.status` is provided; apply limit (default 200) as slice after filter
-
-## 3. Tool handler updates (src/tools/)
-
-- [x] 3.1 Update `listFolders.ts`: add `filter: ListFoldersFilter.optional()` and `limit: z.number().int().positive().optional()` to schema; pass through to `runSnippet`; update description
-- [x] 3.2 Update `listTags.ts`: add `filter: ListTagsFilter.optional()` and `limit: z.number().int().positive().optional()` to schema; pass through to `runSnippet`; update description
-
-## 4. Unit tests (test/unit/)
-
-- [x] 4.1 Add schema tests for `ListFoldersFilter`: valid with status "active"; valid with status "dropped"; valid empty; invalid status value rejected
-- [x] 4.2 Add schema tests for `ListTagsFilter`: valid with status "active"; valid with status "onHold"; valid with status "dropped"; valid empty; invalid status value rejected
-
-## 5. Integration tests (test/integration/)
-
-- [x] 5.1 `listFoldersFiltered.int.test.ts`: verify status filter returns only folders with that status
-- [x] 5.2 `listFoldersFiltered.int.test.ts`: verify limit caps results
-- [x] 5.3 `listFoldersFiltered.int.test.ts`: verify no filter returns all folders (including dropped)
-- [x] 5.4 `listTagsFiltered.int.test.ts`: verify status filter returns only tags with that status
-- [x] 5.5 `listTagsFiltered.int.test.ts`: verify limit caps results
-- [x] 5.6 `listTagsFiltered.int.test.ts`: verify no filter returns all tags
-
-## 6. Verification
-
-- [x] 6.1 `npm run typecheck` clean
-- [x] 6.2 `npm test` (unit suite) clean
-- [x] 6.3 Manually run integration suite

package/openspec/changes/archive/2026-04-09-move-operations/.openspec.yaml

@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-04-10

package/openspec/changes/archive/2026-04-09-move-operations/design.md

@@ -1,43 +0,0 @@
-## Context
-
-OmniFocus supports moving tasks between containers (projects or parent tasks) and moving projects between folders via the `moveSections` and `append`/`prepend` OmniJS APIs. Currently no MCP tool exposes this capability.
-
-The OmniJS API for moving: `moveTasks([task], destination)` where destination is a `Project` or `Task`. For projects: `moveProjects([project], folder)` where folder is a `Folder` or `null` for top-level. Direct property assignment (`task.containingProject`, `project.parentFolder`) is read-only and does not work.
-
-## Goals / Non-Goals
-
-**Goals:**
-- `move_task`: move a task to a project (top-level) or make it a subtask of another task
-- `move_project`: move a project to a folder or to the top level
-
-**Non-Goals:**
-- Moving folders (rename/reparent of folders — separate concern)
-- Reordering within a container (OmniJS exposes position but it's complex)
-- Moving tags
-
-## Decisions
-
-### Decision 1: move_task requires exactly one destination
-
-`move_task` accepts `{ id, projectId?, parentTaskId? }`. Exactly one of `projectId` or `parentTaskId` must be provided — enforced by Zod `.refine()` at the TypeScript boundary and validated again in the snippet. Returns the updated task summary.
-
-### Decision 2: Moving to a project places task at end of project's task list
-
-OmniJS `task.containingProject = project` places the task at the end. This is the natural default; no position parameter needed.
-
-### Decision 3: move_project accepts folderId as string or null
-
-`null` means move to top level (no parent folder). OmniJS: `project.parentFolder = null` removes the folder assignment.
-
-### Decision 4: Not-found errors for all ID lookups
-
-Same pattern as existing write tools: `NotFoundError` if task, project, folder, or parentTask ID is not found. Snippet throws; bridge catches and wraps as `ExecutionError`.
-
-### Decision 5: Return updated summary, not full detail
-
-`move_task` returns a `TaskSummary`. `move_project` returns a `ProjectSummary`. Consistent with create/edit patterns.
-
-## Risks / Trade-offs
-
-- **OmniJS assignment semantics** — setting `task.containingProject` may behave differently than `task.parentTask`. Both need integration testing to verify the task ends up in the right place.
-- **Inbox tasks** — moving an inbox task to a project is valid and expected to work. Moving a project task to inbox is not supported (OmniJS doesn't expose inbox assignment on tasks directly). Document this limitation.

package/openspec/changes/archive/2026-04-09-move-operations/proposal.md

@@ -1,25 +0,0 @@
-## Why
-
-There is no way to move a task to a different project or make it a subtask, and no way to move a project to a different folder. These are common reorganization actions in OmniFocus that an LLM assistant should be able to perform on the user's behalf.
-
-## What Changes
-
-- Add `move_task` tool: moves a task to a project (top-level) or makes it a subtask of another task
-- Add `move_project` tool: moves a project to a folder or to the top level
-
-## Capabilities
-
-### New Capabilities
-
-- `move-operations`: moving tasks between projects/parents and moving projects between folders
-
-### Modified Capabilities
-
-_(none — new tools, no existing requirement changes)_
-
-## Impact
-
-- `src/snippets/move_task.js`, `src/snippets/move_project.js`: new OmniJS snippets
-- `src/tools/moveTask.ts`, `src/tools/moveProject.ts`: new tool handlers
-- `src/tools/index.ts`: register new tools
-- `src/runtime/snippetLoader.ts`: allowlist new snippet names

package/openspec/changes/archive/2026-04-09-move-operations/specs/move-operations/spec.md

@@ -1,41 +0,0 @@
-## Requirements
-
-### Requirement: Move task to a new container
-
-The system SHALL provide a `move_task` tool that accepts `{id: string, projectId?: string, parentTaskId?: string}` and moves the specified task to the given container. Exactly one of `projectId` or `parentTaskId` SHALL be provided; if both or neither are given, the tool SHALL return a validation error. When `projectId` is provided, the task SHALL become a top-level task in that project. When `parentTaskId` is provided, the task SHALL become a direct subtask of that task. The tool SHALL return a structured not-found error if any of the IDs do not correspond to existing objects.
-
-#### Scenario: Move task to a project
-- **WHEN** `move_task` is called with `{id: "t1", projectId: "p2"}`
-- **THEN** the task appears as a top-level task in project p2 and is no longer in its previous container
-
-#### Scenario: Make task a subtask
-- **WHEN** `move_task` is called with `{id: "t1", parentTaskId: "t2"}`
-- **THEN** the task becomes a direct child of task t2
-
-#### Scenario: Both destinations provided is a validation error
-- **WHEN** `move_task` is called with both `projectId` and `parentTaskId`
-- **THEN** the tool returns a validation error before any snippet executes
-
-#### Scenario: Non-existent task ID returns not-found error
-- **WHEN** `move_task` is called with an ID that does not correspond to any task
-- **THEN** the tool returns a structured not-found error
-
-### Requirement: Move project to a folder
-
-The system SHALL provide a `move_project` tool that accepts `{id: string, folderId: string | null}` and moves the specified project to the given folder. When `folderId` is `null`, the project SHALL be moved to the top level (no containing folder). The tool SHALL return a structured not-found error if the project ID or folder ID does not correspond to an existing object.
-
-#### Scenario: Move project to a folder
-- **WHEN** `move_project` is called with `{id: "p1", folderId: "f2"}`
-- **THEN** the project is now contained within folder f2
-
-#### Scenario: Move project to top level
-- **WHEN** `move_project` is called with `{id: "p1", folderId: null}`
-- **THEN** the project has no parent folder
-
-#### Scenario: Non-existent project ID returns not-found error
-- **WHEN** `move_project` is called with a project ID that does not exist
-- **THEN** the tool returns a structured not-found error
-
-#### Scenario: Non-existent folder ID returns not-found error
-- **WHEN** `move_project` is called with a folderId that does not correspond to any folder
-- **THEN** the tool returns a structured not-found error

package/openspec/changes/archive/2026-04-09-move-operations/tasks.md

@@ -1,40 +0,0 @@
-## 1. Schema changes (src/schemas/)
-
-- [x] 1.1 Define `MoveTaskInput` zod schema: `{ id: IdSchema, projectId: IdSchema.optional(), parentTaskId: IdSchema.optional() }` with `.refine()` that exactly one of `projectId` or `parentTaskId` is provided
-- [x] 1.2 Define `MoveProjectInput` zod schema: `{ id: IdSchema, folderId: IdSchema.nullable() }`
-- [x] 1.3 Export `MoveTaskInput` and `MoveProjectInput` from `src/schemas/index.ts`
-
-## 2. Snippets (src/snippets/)
-
-- [x] 2.1 Create `move_task.js`: resolve task by ID (NotFoundError if missing); if `projectId` provided, resolve project (NotFoundError if missing), assign `task.containingProject = project`; if `parentTaskId` provided, resolve parent task (NotFoundError if missing), assign `task.parentTask = parentTask`; return updated `TaskSummary` fields
-- [x] 2.2 Create `move_project.js`: resolve project by ID (NotFoundError if missing); if `folderId` is non-null, resolve folder (NotFoundError if missing), assign `project.parentFolder = folder`; if `folderId` is null, assign `project.parentFolder = null`; return updated `ProjectSummary` fields
-
-## 3. Tool handlers (src/tools/)
-
-- [x] 3.1 Create `moveTask.ts`: schema uses `MoveTaskInput`, handler calls `runSnippet("move_task", input)`, parses result as `TaskSummary`, exports `moveTaskTool`
-- [x] 3.2 Create `moveProject.ts`: schema uses `MoveProjectInput`, handler calls `runSnippet("move_project", input)`, parses result as `ProjectSummary`, exports `moveProjectTool`
-
-## 4. Registration
-
-- [x] 4.1 Add `move_task` and `move_project` to `ALLOWED_SNIPPETS` in `src/runtime/snippetLoader.ts`
-- [x] 4.2 Import and add `moveTaskTool` and `moveProjectTool` to `allTools` in `src/tools/index.ts`
-
-## 5. Unit tests (test/unit/)
-
-- [x] 5.1 Add schema tests for `MoveTaskInput`: valid with projectId only; valid with parentTaskId only; invalid with both; invalid with neither
-- [x] 5.2 Add schema tests for `MoveProjectInput`: valid with folderId string; valid with folderId null; invalid with missing id
-
-## 6. Integration tests (test/integration/)
-
-- [x] 6.1 `moveTask.int.test.ts`: create task in project A; move to project B; verify task appears in project B
-- [x] 6.2 `moveTask.int.test.ts`: create task; make it a subtask of another task via parentTaskId
-- [x] 6.3 `moveTask.int.test.ts`: non-existent task ID returns NotFoundError
-- [x] 6.4 `moveProject.int.test.ts`: create project in folder A; move to folder B; verify project is in folder B
-- [x] 6.5 `moveProject.int.test.ts`: move project to top level (folderId: null)
-- [x] 6.6 `moveProject.int.test.ts`: non-existent project ID returns NotFoundError
-
-## 7. Verification
-
-- [x] 7.1 `npm run typecheck` clean
-- [x] 7.2 `npm test` (unit suite) clean
-- [x] 7.3 Manually run integration suite

package/openspec/changes/archive/2026-04-09-project-crud/.openspec.yaml

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

package/openspec/changes/archive/2026-04-09-project-crud/design.md

@@ -1,60 +0,0 @@
-## Context
-
-Projects in OmniJS have more writable fields than tasks: type (`sequential`, `containsSingletonActions`), review interval, and folder placement. Status transitions use dedicated methods. This design follows the same patterns established in `task-crud`.
-
-OmniJS project write operations:
-- `new Project(name, position)` — creates a project; `position` is a `Folder` or omitted for top-level
-- Property assignment for scalars: `name`, `note`, `flagged`, `deferDate`, `dueDate`, `sequential`, `containsSingletonActions`
-- `project.status = Project.Status.Active / OnHold` — for hold/active transitions
-- `project.markComplete()` — dedicated method for done
-- `project.status = Project.Status.Dropped` — drops the project (`project.drop()` is not available via `evaluateJavascript`)
-- `project.reviewInterval.steps = n` — only `steps` can be mutated in-place; `Project.ReviewInterval` is a CallbackObject in the `evaluateJavascript` context and cannot be constructed with `new`, so the unit cannot be changed and the interval cannot be cleared (OmniJS rejects `null`)
-- Tags: `project.addTag(tag)` / `project.removeTag(tag)` — same pattern as tasks
-- `deleteObject(project)` — permanent deletion including all tasks
-
-## Goals / Non-Goals
-
-**Goals:**
-- Expose create, edit, complete, drop, and delete for projects
-- Support folder placement on create (top-level or inside a folder)
-- Edit any subset of fields in one call including review interval and type
-- Replace-not-merge tag semantics (consistent with task-crud)
-
-**Non-Goals:**
-- Moving a project to a different folder (separate `move-operations` change)
-- Creating tasks inside a new project in the same call (use `create_task` after)
-- Recurrence rules (separate `recurrence` change)
-
-## Decisions
-
-### Decision 1: `type` mapped to OmniJS properties
-
-Project type is not a single OmniJS property — it is encoded across two booleans:
-- `sequential: true` → `"sequential"`
-- `containsSingletonActions: true` → `"singleActions"`
-- both false → `"parallel"`
-
-`create_project` and `edit_project` accept the enum string `"parallel" | "sequential" | "singleActions"` and the snippet maps it to the correct property assignments.
-
-### Decision 2: `reviewInterval` — steps only, in-place mutation
-
-`edit_project` and `create_project` accept `reviewInterval` as `{steps: number, unit: "days" | "weeks" | "months" | "years"}`. Only the `steps` field can actually be applied: `project.reviewInterval.steps = n` mutates the existing interval in place.
-
-**Limitations discovered during implementation:** `Project.ReviewInterval` is a CallbackObject in the `evaluateJavascript` context — `new Project.ReviewInterval(steps, unit)` throws. `Project.ReviewInterval.Unit` is also undefined in this context, so the unit cannot be changed. Setting `project.reviewInterval = null` is rejected by OmniJS ("must be set to a non-null value"). As a result, the `unit` field in `reviewInterval` input is accepted by the schema but silently ignored at runtime.
-
-**Note:** Read output (`get_project`) returns the string form `"1 weeks"` — that is a read-side concern unchanged by this limitation.
-
-### Decision 3: Status transitions via dedicated tools and property assignment
-
-`complete_project` calls `markComplete()`. `drop_project` sets `project.status = Project.Status.Dropped` — `project.drop()` does not exist in the `evaluateJavascript` context. Active/on-hold are set via `project.status = Project.Status.Active / OnHold` inside `edit_project` (these are property assignments, not method calls). This keeps the common "put on hold" operation accessible through `edit_project` without requiring a dedicated tool.
-
-### Decision 4: `delete_project` description warns about task cascade
-
-`deleteObject(project)` removes the project and all its tasks. The tool description explicitly states this. Consistent with `delete_task` and `delete_folder` confirmation pattern.
-
-## Risks / Trade-offs
-
-- **`new Project(name)` without a position** creates a top-level project. Verified in OmniJS.
-- **`new Project(name, folder)` with a Folder object** places the project inside that folder.
-- **Review interval unit enum values** — OmniJS `Project.ReviewInterval.Unit` has `.days`, `.weeks`, `.months`, `.years`. Snippet should map string to the enum member, not pass the string directly.
-- **Changing type from `singleActions`** may silently fail if the project has tasks structured for that mode — low risk for typical usage, not worth guarding against in v1.

package/openspec/changes/archive/2026-04-09-project-crud/proposal.md

@@ -1,29 +0,0 @@
-## Why
-
-The bootstrap change delivered read-only project access. Callers can observe projects but cannot create, modify, complete, drop, or delete them — making the server unsuitable for any workflow that involves acting on projects.
-
-## What Changes
-
-- Add `create_project` tool: create a project in a folder or at the top level
-- Add `edit_project` tool: modify any subset of a project's scalar fields, type, tags, and review interval in a single call
-- Add `complete_project` tool: mark a project done
-- Add `drop_project` tool: mark a project dropped
-- Add `delete_project` tool: permanently delete a project and all its tasks (tool description instructs the AI to confirm with the user before invoking)
-
-## Capabilities
-
-### New Capabilities
-
-- `project-write`: Create, edit, complete, drop, and permanently delete OmniFocus projects
-
-### Modified Capabilities
-
-_(none — existing `project-management` read requirements are unchanged)_
-
-## Impact
-
-- 5 new MCP tools registered in `src/server.ts`
-- 5 new tool handler files in `src/tools/`
-- 5 new OmniJS snippets in `src/snippets/`
-- `ALLOWED_SNIPPETS` allowlist in `src/runtime/snippetLoader.ts` must be extended
-- Integration tests will mutate real OmniFocus data (scoped to fixture folder per existing pattern)

package/openspec/changes/archive/2026-04-09-project-crud/specs/project-write/spec.md

@@ -1,74 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Create project
-
-The system SHALL provide a `create_project` tool that creates a new OmniFocus project and returns its full detail record. The tool SHALL accept `{name: string, folderId?: string, note?: string, type?: "parallel" | "sequential" | "singleActions", status?: "active" | "onHold", flagged?: boolean, deferDate?: string, dueDate?: string, reviewInterval?: {steps: number, unit: "days" | "weeks" | "months" | "years"}, tagIds?: string[]}`. If `folderId` is provided the project SHALL be created inside that folder; otherwise it SHALL be created at the top level.
-
-#### Scenario: Create top-level project
-- **WHEN** `create_project` is called with `{name: "My Project"}` and no `folderId`
-- **THEN** the tool creates the project at the top level and returns its full detail record including a stable `id`
-
-#### Scenario: Create project inside a folder
-- **WHEN** `create_project` is called with `{name: "My Project", folderId: "abc123"}`
-- **THEN** the tool creates the project inside the specified folder and returns its full detail record with `folderPath` reflecting the folder
-
-#### Scenario: Create sequential project
-- **WHEN** `create_project` is called with `{name: "My Project", type: "sequential"}`
-- **THEN** the returned project detail includes `type: "sequential"`
-
-#### Scenario: Non-existent folder returns not-found error
-- **WHEN** `create_project` is called with a `folderId` that does not correspond to any folder
-- **THEN** the tool returns a structured not-found error
-
-### Requirement: Edit project
-
-The system SHALL provide an `edit_project` tool that modifies an existing project and returns its updated full detail record. The tool SHALL accept `{id: string}` plus any subset of `{name?: string, note?: string, type?: "parallel" | "sequential" | "singleActions", status?: "active" | "onHold", flagged?: boolean, deferDate?: string | null, dueDate?: string | null, reviewInterval?: {steps: number, unit: "days" | "weeks" | "months" | "years"}, tagIds?: string[]}`. Fields omitted from the call SHALL be left unchanged. When `tagIds` is provided it SHALL replace the project's entire tag set. Passing `null` for a date SHALL clear the field. When `reviewInterval` is provided, only the `steps` value is updated; the `unit` field is accepted by the schema but cannot be changed at runtime due to OmniJS API constraints in the `evaluateJavascript` context.
-
-#### Scenario: Put project on hold
-- **WHEN** `edit_project` is called with `{id: "abc123", status: "onHold"}`
-- **THEN** the project's status becomes `"onHold"` and all other fields are unchanged
-
-#### Scenario: Set review interval
-- **WHEN** `edit_project` is called with `{id: "abc123", reviewInterval: {steps: 2, unit: "weeks"}}`
-- **THEN** the project's review interval is updated and the returned detail reflects the change
-
-
-#### Scenario: Non-existent project returns not-found error
-- **WHEN** `edit_project` is called with an ID that does not correspond to any project
-- **THEN** the tool returns a structured not-found error
-
-### Requirement: Complete project
-
-The system SHALL provide a `complete_project` tool that marks an existing project done using OmniJS `markComplete()` and returns the project's updated full detail record.
-
-#### Scenario: Complete an existing project
-- **WHEN** `complete_project` is called with the ID of an active project
-- **THEN** the project's status becomes `"done"` and the tool returns the updated detail record
-
-#### Scenario: Non-existent project returns not-found error
-- **WHEN** `complete_project` is called with an ID that does not correspond to any project
-- **THEN** the tool returns a structured not-found error
-
-### Requirement: Drop project
-
-The system SHALL provide a `drop_project` tool that marks an existing project dropped using OmniJS `drop()` and returns the project's updated full detail record.
-
-#### Scenario: Drop an existing project
-- **WHEN** `drop_project` is called with the ID of an active project
-- **THEN** the project's status becomes `"dropped"` and the tool returns the updated detail record
-
-#### Scenario: Non-existent project returns not-found error
-- **WHEN** `drop_project` is called with an ID that does not correspond to any project
-- **THEN** the tool returns a structured not-found error
-
-### Requirement: Delete project
-
-The system SHALL provide a `delete_project` tool that permanently deletes a project and all its tasks using OmniJS `deleteObject()`. The tool description SHALL instruct the AI to confirm with the user before invoking this tool, noting that deletion is permanent and removes all tasks within the project.
-
-#### Scenario: Delete an existing project
-- **WHEN** `delete_project` is called with the ID of an existing project
-- **THEN** the project and all its tasks are permanently removed from OmniFocus and the tool returns a confirmation envelope
-
-#### Scenario: Non-existent project returns not-found error
-- **WHEN** `delete_project` is called with an ID that does not correspond to any project
-- **THEN** the tool returns a structured not-found error

package/openspec/changes/archive/2026-04-09-project-crud/tasks.md

@@ -1,48 +0,0 @@
-## 1. Snippets (src/snippets/)
-
-- [x] 1.1 `create_project.js`: accept `{name, folderId?, note?, type?, status?, flagged?, deferDate?, dueDate?, reviewInterval?, tagIds?}`; resolve folder by ID if provided; map `type` string to `sequential`/`containsSingletonActions` booleans; set `status` to `Project.Status.OnHold` if `"onHold"`; construct `new Project.ReviewInterval(steps, unit)` if `reviewInterval` provided; resolve and assign tags by ID; return full project detail envelope
-- [x] 1.2 `edit_project.js`: accept `{id, name?, note?, type?, status?, flagged?, deferDate?, dueDate?, reviewInterval?, tagIds?}`; resolve project by ID; apply only provided fields; map `type` and `status` to OmniJS equivalents; handle `null` for date/reviewInterval to clear; replace tag set when `tagIds` provided; return updated full detail envelope
-- [x] 1.3 `complete_project.js`: accept `{id}`; resolve project by ID; call `project.markComplete()`; return updated full detail envelope
-- [x] 1.4 `drop_project.js`: accept `{id}`; resolve project by ID; use `project.status = Project.Status.Dropped` (project.drop() is not available via evaluateJavascript); return updated full detail envelope
-- [x] 1.5 `delete_project.js`: accept `{id}`; resolve project by ID; call `deleteObject(project)`; return `{ok: true, data: {id}}`
-
-## 2. Snippet allowlist
-
-- [x] 2.1 Add `create_project`, `edit_project`, `complete_project`, `drop_project`, `delete_project` to `ALLOWED_SNIPPETS` in `src/runtime/snippetLoader.ts`
-
-## 3. Schemas (src/schemas/shapes.ts)
-
-- [x] 3.1 Define `ReviewIntervalInput` zod schema: `{steps: z.number().int().positive(), unit: z.enum(["days","weeks","months","years"])}`
-- [x] 3.2 Define `CreateProjectInput` zod schema with all optional fields including `reviewInterval: ReviewIntervalInput.optional()`
-- [x] 3.3 Define `EditProjectInput` zod schema — `id` required; date fields accept `string | null`; `reviewInterval` accepts `ReviewIntervalInput` (null not supported — OmniJS rejects null for this property)
-
-## 4. Tool handlers (src/tools/)
-
-- [x] 4.1 `createProject.ts`: validate input with `CreateProjectInput`; invoke `runSnippet("create_project", args)`; validate result against `ProjectDetail`; return
-- [x] 4.2 `editProject.ts`: validate input with `EditProjectInput`; invoke `runSnippet("edit_project", args)`; validate result against `ProjectDetail`; return
-- [x] 4.3 `completeProject.ts`: input `{id: IdSchema}`; invoke `runSnippet("complete_project", {id})`; validate result against `ProjectDetail`; return
-- [x] 4.4 `dropProject.ts`: input `{id: IdSchema}`; invoke `runSnippet("drop_project", {id})`; validate result against `ProjectDetail`; return
-- [x] 4.5 `deleteProject.ts`: input `{id: IdSchema}`; tool description MUST state the AI should confirm with the user before invoking and note that all tasks in the project are permanently deleted; invoke `runSnippet("delete_project", {id})`; return confirmation
-
-## 5. Server registration
-
-- [x] 5.1 Export all five new tool definitions from `src/tools/index.ts`
-
-## 6. Unit tests (test/unit/)
-
-- [x] 6.1 `schemas.createProject.test.ts`: valid inputs pass; invalid `type` enum rejected; invalid `reviewInterval.unit` rejected; null dates accepted in edit schema
-
-## 7. Integration tests (test/integration/)
-
-- [x] 7.1 `createProject.int.test.ts`: create top-level project; create project in folder; verify `folderPath` and `type`
-- [x] 7.2 `editProject.int.test.ts`: edit name; set on-hold; set review interval steps; (clear review interval not supported — OmniJS rejects null)
-- [x] 7.3 `completeProject.int.test.ts`: complete a project, verify status = `"done"`
-- [x] 7.4 `dropProject.int.test.ts`: drop a project, verify status = `"dropped"`
-- [x] 7.5 `deleteProject.int.test.ts`: delete a project, verify subsequent `get_project` returns not-found
-
-## 8. Verification
-
-- [x] 8.1 `npm run typecheck` clean
-- [x] 8.2 `npm test` (unit suite) clean
-- [x] 8.3 Manually run integration suite; verify fixture cleanup
-- [ ] 8.4 Connect to Claude Desktop; exercise all five tools against a real database

package/openspec/changes/archive/2026-04-09-project-filtering/.openspec.yaml

@@ -1,2 +0,0 @@
-schema: spec-driven
-created: 2026-04-10

package/openspec/changes/archive/2026-04-09-project-filtering/design.md

@@ -1,52 +0,0 @@
-## Context
-
-`list_projects` currently fetches all projects and returns a flat `ProjectSummary` array with no filtering. This mirrors the pre-filtering state of `list_tasks`. The task-filtering change established the pattern: filter inside the OmniJS snippet before data crosses the JXA bridge, enrich the summary shape with fields needed for filtering and display, change the default to exclude terminal statuses.
-
-`ProjectSummary` currently omits `flagged` and the parent folder ID (it has `folderPath` string but not `folderId`). Without `folderId`, the LLM cannot cross-reference a listed project with a known folder ID, and cannot filter by folder ID from returned results.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Filter projects by `status[]`, `folderId` (recursive subtree), and `flagged` inside the snippet
-- Enrich `ProjectSummary` with `flagged` and `folderId`
-- Change default behavior: exclude `done` and `dropped` projects when no `status` filter is provided
-- Cap results with a configurable `limit` (default 100)
-
-**Non-Goals:**
-- Filtering by tag, due date, or review date (can be added later)
-- Filtering `list_folders` or `list_tags` (separate changes if needed)
-- Pagination / cursor-based continuation
-
-## Decisions
-
-### Decision 1: Same pattern as task-filtering — filter in snippet
-
-All filter logic runs inside `evaluateJavascript`. The TypeScript layer validates the schema and passes filter args through. Consistent with task-filtering; avoids any future performance concerns if project counts grow.
-
-### Decision 2: Enrich ProjectSummary with flagged and folderId
-
-`ProjectSummary` gains:
-- `flagged: boolean` — needed to support the `flagged` filter and display flagged state in results
-- `folderId: string | null` — the direct parent folder's `id.primaryKey`, or `null` for top-level projects
-
-`folderPath` is kept as-is (useful for display). `folderId` is added alongside it as the machine-readable reference. No other detail fields are promoted to the summary.
-
-### Decision 3: Default excludes done and dropped
-
-When `filter.status` is omitted, the snippet excludes `Project.Status.Done` and `Project.Status.Dropped`. This mirrors the task-filtering default and is the correct behavior for LLM planning queries. Done/dropped projects can be retrieved explicitly with `status: ["done"]` or `status: ["dropped"]`.
-
-### Decision 4: folderId filter is recursive
-
-When `filter.folderId` is provided, the snippet returns projects whose parent folder chain includes the specified folder ID — i.e., direct children and all nested descendants. This is consistent with how `list_tasks` treats `scope.folderId`.
-
-Implementation: check `p.flattenedProjects` on the resolved folder rather than walking `flattenedProjects` globally and checking ancestry. More efficient and correct.
-
-### Decision 5: limit default 100
-
-Projects are fewer than tasks; 100 is a sensible default. Callers may increase it.
-
-## Risks / Trade-offs
-
-- **Breaking default behavior** — same risk as task-filtering. Acceptable: single consumer, new default is strictly more useful.
-- **folderId recursive filter uses folder.flattenedProjects** — this is the cleanest OmniJS approach. If the folder ID is invalid, return an empty array (not an error) since this is a filter, not a scope requirement. Actually: throw NotFoundError to be consistent with list_tasks scope behavior.
-- **flagged on ProjectSummary is a new required field** — any existing unit test fixtures for ProjectSummary will need updating (same situation as TaskSummary in task-filtering).

package/openspec/changes/archive/2026-04-09-project-filtering/proposal.md

@@ -1,26 +0,0 @@
-## Why
-
-`list_projects` currently returns every project in the database with no filtering. Users with years of OmniFocus history may have hundreds of completed (`done`) and dropped projects, making it impractical for an LLM to identify what's actually active. Applying the same filter-in-snippet pattern established by task-filtering gives the LLM a useful, scoped view of the project list.
-
-## What Changes
-
-- `list_projects` accepts an optional `filter` object: `status` (array), `folderId` (recursive subtree), `flagged`
-- `list_projects` accepts an optional `limit` (default 100)
-- **BREAKING**: Default behavior changes — when no `status` filter is given, `done` and `dropped` projects are excluded. Pass `status: ["done"]` explicitly to retrieve completed projects.
-- `ProjectSummary` is enriched with `flagged` (boolean) and `folderId` (string | null — the direct parent folder's ID) so the LLM can reason about results without fetching full project detail
-
-## Capabilities
-
-### New Capabilities
-- `project-filtering`: Filter parameters and enriched summary for `list_projects`
-
-### Modified Capabilities
-- `project-management`: `list_projects` tool signature changes (new filter/limit params, enriched return shape, changed default behavior)
-
-## Impact
-
-- `src/snippets/list_projects.js` — rewritten to apply filters and return enriched fields
-- `src/schemas/shapes.ts` — `ProjectSummary` gains `flagged` and `folderId`; new `ListProjectsFilter` schema
-- `src/tools/listProjects.ts` — input schema updated with filter and limit
-- `test/unit/` — schema tests for new filter type
-- `test/integration/listProjectsFiltered.int.test.ts` — new integration tests for filter combinations