@scardis/omnifocus-mcp 0.1.0 → 0.1.2

package/openspec/changes/archive/2026-04-10-task-recurrence/tasks.md

@@ -1,39 +0,0 @@
-## 1. Schema changes (src/schemas/)
-
-- [x] 1.1 Define `RepetitionRuleInput` zod schema: `{ frequency, interval (default 1), daysOfWeek?, method }` with `.refine()` that daysOfWeek is only valid when frequency is "weekly"
-- [x] 1.2 Define `RepetitionRuleDetail` zod schema: `{ frequency, interval, daysOfWeek?, method }` (no refine needed — read-only)
-- [x] 1.3 Add `repetitionRule: RepetitionRuleInput.optional()` to `CreateTaskInput`
-- [x] 1.4 Add `repetitionRule: RepetitionRuleInput.nullable().optional()` to `EditTaskInput`
-- [x] 1.5 Add `repetitionRule: RepetitionRuleDetail.nullable()` to `TaskDetail`
-- [x] 1.6 Export `RepetitionRuleInput` and `RepetitionRuleDetail` from `src/schemas/index.ts`
-
-## 2. Snippet updates (src/snippets/)
-
-- [x] 2.1 Update `create_task.js`: after task creation, if `args.repetitionRule` is provided, construct RRULE string from frequency/interval/daysOfWeek and call `Task.RepetitionRule.make(rrule, method)`; include `repetitionRule` in returned TaskDetail
-- [x] 2.2 Update `edit_task.js`: if `args.repetitionRule === null` assign `task.repetitionRule = null`; if `args.repetitionRule` is an object, construct and assign the rule; if `args.repetitionRule` is undefined, leave unchanged; include `repetitionRule` in returned TaskDetail
-- [x] 2.3 Update `get_task.js`: read `task.repetitionRule`; if null return `null`; otherwise parse `ruleString` (extract FREQ, INTERVAL, BYDAY via string ops) and map method enum to string; return structured `repetitionRule` field
-
-## 3. Helper: RRULE construction and parsing
-
-- [x] 3.1 In `create_task.js` and `edit_task.js`: implement `buildRrule(rule)` helper that produces the RRULE string — `FREQ=X;INTERVAL=N` plus `BYDAY=MO,WE,...` when daysOfWeek is present
-- [x] 3.2 In `create_task.js`, `edit_task.js`, and `get_task.js`: implement `parseRepetitionRule(rule)` helper that reads `rule.ruleString` and `rule.method`, extracts FREQ/INTERVAL/BYDAY via string split, maps back to structured fields
-
-## 4. Unit tests (test/unit/)
-
-- [x] 4.1 Add schema tests for `RepetitionRuleInput`: valid daily; valid weekly with daysOfWeek; valid monthly; valid yearly; invalid daysOfWeek on non-weekly frequency rejected; interval must be positive integer
-- [x] 4.2 Add schema tests for extended `CreateTaskInput`: valid with repetitionRule; valid without (backward compat)
-- [x] 4.3 Add schema tests for extended `EditTaskInput`: valid with repetitionRule object; valid with repetitionRule null (clear); valid omitting repetitionRule (unchanged)
-
-## 5. Integration tests (test/integration/)
-
-- [x] 5.1 `taskRecurrence.int.test.ts`: create task with daily repetition; verify get_task returns repetitionRule with frequency "daily"
-- [x] 5.2 `taskRecurrence.int.test.ts`: create task with weekly repetition on Mon/Wed/Fri; verify get_task returns correct daysOfWeek
-- [x] 5.3 `taskRecurrence.int.test.ts`: edit existing task to add monthly repetition; verify get_task reflects new rule
-- [x] 5.4 `taskRecurrence.int.test.ts`: edit task to clear repetition (null); verify get_task returns repetitionRule: null
-- [x] 5.5 `taskRecurrence.int.test.ts`: create task without repetitionRule; verify get_task returns repetitionRule: null (backward compat)
-
-## 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/config.yaml

@@ -1,20 +0,0 @@
-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

package/openspec/specs/attachments/spec.md

@@ -1,15 +0,0 @@
-# attachments
-
-## Purpose
-
-Covers listing, reading, adding, and removing file attachments on task notes via the OmniJS `FileWrapper` API. Individual tools and on-wire encoding decisions will be defined in the `attachments` change.
-
-## Requirements
-
-### Requirement: Capability declared
-
-The `attachments` capability SHALL cover listing, reading, adding, and removing file attachments on task notes via the OmniJS `FileWrapper` API. The on-wire representation of attachment contents across the MCP boundary (inline base64, filesystem path reference, or a hybrid with a size threshold) SHALL be decided when the `attachments` change is drafted. Requirements for individual tools SHALL be added by that change.
-
-#### Scenario: Capability is named and scoped
-- **WHEN** a future change proposes adding attachment tools
-- **THEN** it lands requirements under this capability and makes the on-wire encoding decision explicit

package/openspec/specs/batch-operations/spec.md

@@ -1,15 +0,0 @@
-# batch-operations
-
-## Purpose
-
-Covers batch variants of every mutating tool with typed-array validation, partial-success semantics, and single-snippet execution. Individual tools will be defined in the `batch-operations` change.
-
-## Requirements
-
-### Requirement: Capability declared
-
-The `batch-operations` capability SHALL cover batch variants of every mutating tool (create, update, delete, move, complete, assign). Batch tools SHALL accept strictly typed arrays validated at the TypeScript boundary (never serialized JSON strings) and SHALL return a per-item result array with partial-success semantics: each element is an `{ok, data?, error?}` envelope carrying that item's outcome independent of other items. Batch tools SHALL execute as a single OmniJS snippet that iterates internally, not as a loop of per-item bridge invocations. Requirements for individual batch tools SHALL be added by the `batch-operations` change.
-
-#### Scenario: Capability is named and semantics are fixed
-- **WHEN** a future change proposes adding batch tools
-- **THEN** it lands requirements under this capability with typed-array validation and partial-success result semantics as invariants

package/openspec/specs/database-inspection/spec.md

@@ -1,15 +0,0 @@
-# database-inspection
-
-## Purpose
-
-Covers scoped, paged, and filtered traversal of the full OmniFocus database, including a `dump_database` tool, inbox inspection, and database metadata. Individual tools will be defined in the `forecast-and-inspection` change.
-
-## Requirements
-
-### Requirement: Capability declared
-
-The `database-inspection` capability SHALL cover scoped, paged, and filtered traversal of the full OmniFocus database, including a `dump_database` tool that accepts `{scope, id?, include, format}` parameters, inbox inspection, and database metadata (name, sync status, object counts). The default behavior of `dump_database` SHALL exclude completed tasks, dropped entities, and task notes to keep payloads manageable; those are opt-in via the `include` parameter. Requirements for individual tools SHALL be added by the `forecast-and-inspection` change.
-
-#### Scenario: Capability is named and scoped
-- **WHEN** a future change proposes adding database-inspection tools
-- **THEN** it lands requirements under this capability rather than inventing a new capability name

package/openspec/specs/execution-runtime/spec.md

@@ -1,75 +0,0 @@
-# execution-runtime
-
-## Purpose
-
-Defines the contract for executing OmniFocus domain operations through the OmniJS/JXA bridge, including snippet injection, result protocol, caching, and timeouts.
-
-## Requirements
-
-### Requirement: OmniJS execution via JXA bridge
-
-The system SHALL execute every OmniFocus domain operation inside OmniFocus's OmniJS runtime by invoking `Application('OmniFocus').evaluateJavascript(snippet)` from a JXA host process spawned via `osascript -l JavaScript`. The JXA host SHALL NOT invoke any OmniFocus scripting-dictionary method other than `evaluateJavascript` for domain operations.
-
-#### Scenario: Tool invocation routes through the bridge
-- **WHEN** a tool handler invokes the runtime with a snippet and args
-- **THEN** the runtime spawns `osascript -l JavaScript`, passes a JXA wrapper that calls `Application('OmniFocus').evaluateJavascript` with the prepared snippet, and awaits stdout
-
-#### Scenario: Scripting-dictionary domain methods are forbidden
-- **WHEN** a contributor adds a tool handler that calls e.g. `Application('OmniFocus').defaultDocument.projects` directly
-- **THEN** a unit test (or review) flags the call as a runtime-contract violation and the change is rejected
-
-### Requirement: Snippet argument injection via JSON literal
-
-The system SHALL construct executable scripts by replacing exactly one `__ARGS__` placeholder in a static `.js` snippet template with the result of `JSON.stringify(args)`. No other interpolation of user-supplied data into script source is permitted anywhere in the codebase.
-
-#### Scenario: Apostrophes and quotes survive injection
-- **WHEN** a tool is invoked with `args = {name: "Finn's \"birthday\""}`
-- **THEN** the executed snippet receives `args.name === "Finn's \"birthday\""` and no syntax error occurs
-
-#### Scenario: Unicode and newlines survive injection
-- **WHEN** a tool is invoked with `args = {note: "line1\nline2 — emoji 🎯"}`
-- **THEN** the executed snippet receives the note verbatim including the newline and unicode code points
-
-#### Scenario: Snippets are standalone and paste-ready
-- **WHEN** a developer opens any file under `src/snippets/`
-- **THEN** the file is a valid JavaScript program that can be pasted into OmniFocus's Automation Console after replacing `__ARGS__` with a hand-written object literal, with no additional preprocessing required
-
-### Requirement: One-line JSON result protocol
-
-The system SHALL represent every bridge invocation's result as exactly one line of JSON on the JXA host's stdout, matching the envelope `{ok: true, data: <value>} | {ok: false, error: {name: string, message: string, stack?: string}}`. The TypeScript runtime SHALL read stdout, extract the first JSON-parseable line, and return the parsed envelope to the caller. A result envelope with `ok: false` SHALL be thrown as a structured error with the error details preserved.
-
-#### Scenario: Successful operation returns data envelope
-- **WHEN** a snippet completes without throwing and its final expression is `JSON.stringify({ok: true, data: {id: "abc"}})`
-- **THEN** the TS runtime receives `{ok: true, data: {id: "abc"}}` and returns `{id: "abc"}` to the tool handler
-
-#### Scenario: Snippet exception produces error envelope
-- **WHEN** a snippet throws an `Error` with message "not found"
-- **THEN** the JXA shim catches the exception, prints `{ok: false, error: {name: "Error", message: "not found", ...}}` as one line on stdout, and the TS runtime throws a structured error carrying the name, message, and stack
-
-#### Scenario: Extraneous stdout chatter does not corrupt results
-- **WHEN** any process in the pipeline writes incidental non-JSON output to stdout before the result line
-- **THEN** the TS runtime still parses the result envelope correctly by selecting the first complete JSON-parseable line
-
-### Requirement: Snippet loader
-
-The system SHALL load snippet templates from `src/snippets/<name>.js` relative to the compiled server's known snippet root, caching the file contents in memory after the first read. The loader SHALL reject snippets that do not contain exactly one `__ARGS__` token.
-
-#### Scenario: Snippet is loaded and cached
-- **WHEN** a tool handler invokes the runtime with snippet name `"list_projects"` twice in the same process
-- **THEN** the file `list_projects.js` is read from disk exactly once and the cached content is used for the second invocation
-
-#### Scenario: Snippet with zero placeholders is rejected
-- **WHEN** a snippet file contains no `__ARGS__` token
-- **THEN** the loader throws a contract violation at load time, not at runtime
-
-#### Scenario: Snippet with multiple placeholders is rejected
-- **WHEN** a snippet file contains two or more `__ARGS__` tokens
-- **THEN** the loader throws a contract violation at load time
-
-### Requirement: Script timeout
-
-The system SHALL enforce a configurable per-invocation timeout on `osascript` execution, defaulting to 30 seconds, and SHALL terminate the child process and throw a timeout error when exceeded.
-
-#### Scenario: Long-running snippet is terminated
-- **WHEN** a snippet runs longer than the configured timeout
-- **THEN** the runtime sends SIGTERM to the `osascript` process and throws a timeout error identifying the snippet name and elapsed time

package/openspec/specs/folder-management/spec.md

@@ -1,39 +0,0 @@
-# folder-management
-
-## Purpose
-
-Defines tools for reading and listing OmniFocus folders, including full folder listing and detail retrieval by ID.
-
-## 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
-
-### Requirement: Get folder by ID
-
-The system SHALL provide a `get_folder` tool that accepts `{id: string}` and returns the full detail record of the named folder, including `{id, name, path, parentId, status, childFolderIds, projectIds}`. If no folder exists with that ID, the tool SHALL return a structured not-found error.
-
-#### Scenario: Existing folder returns full detail with children
-- **WHEN** `get_folder` is called with the ID of an existing folder
-- **THEN** the tool returns the folder's full detail including the IDs of its immediate child folders and immediate child projects
-
-#### Scenario: Missing folder returns not-found error
-- **WHEN** `get_folder` is called with an ID that does not correspond to any folder
-- **THEN** the tool returns a structured error with a not-found code

package/openspec/specs/folder-write/spec.md

@@ -1,45 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Create folder
-
-The system SHALL provide a `create_folder` tool that creates a new OmniFocus folder and returns its full detail record. The tool SHALL accept `{name: string, parentFolderId?: string}`. If `parentFolderId` is provided the folder SHALL be created nested inside that folder; otherwise it SHALL be created at the top level.
-
-#### Scenario: Create top-level folder
-- **WHEN** `create_folder` is called with `{name: "Work"}` and no `parentFolderId`
-- **THEN** the tool creates the folder at the top level and returns its full detail record including a stable `id`
-
-#### Scenario: Create nested folder
-- **WHEN** `create_folder` is called with `{name: "Active", parentFolderId: "abc123"}`
-- **THEN** the tool creates the folder inside the specified parent folder and returns its full detail record with `path` reflecting the full ancestor chain
-
-#### Scenario: Non-existent parent folder returns not-found error
-- **WHEN** `create_folder` is called with a `parentFolderId` that does not correspond to any folder
-- **THEN** the tool returns a structured not-found error
-
-### Requirement: Edit folder
-
-The system SHALL provide an `edit_folder` tool that renames an existing folder and returns its updated full detail record. The tool SHALL accept `{id: string, name: string}`.
-
-#### Scenario: Rename a folder
-- **WHEN** `edit_folder` is called with `{id: "abc123", name: "Personal"}`
-- **THEN** the folder's name is updated and the tool returns the updated detail record with the new name reflected in `path`
-
-#### Scenario: Non-existent folder returns not-found error
-- **WHEN** `edit_folder` is called with an ID that does not correspond to any folder
-- **THEN** the tool returns a structured not-found error
-
-### Requirement: Delete folder
-
-The system SHALL provide a `delete_folder` tool that permanently and recursively deletes a folder, all child folders, all projects within those folders, and all tasks within those projects. The tool description SHALL instruct the AI to confirm with the user before invoking, explicitly stating that the entire subtree — child folders, projects, and all tasks — is permanently deleted and cannot be undone.
-
-#### Scenario: Delete a folder and all its contents
-- **WHEN** `delete_folder` is called with the ID of an existing folder
-- **THEN** the folder, all descendant folders, all projects within those folders, and all tasks within those projects are permanently removed from OmniFocus and the tool returns a confirmation envelope
-
-#### Scenario: Delete empty folder
-- **WHEN** `delete_folder` is called with the ID of a folder that contains no projects or child folders
-- **THEN** the folder is removed and the tool returns a confirmation envelope
-
-#### Scenario: Non-existent folder returns not-found error
-- **WHEN** `delete_folder` is called with an ID that does not correspond to any folder
-- **THEN** the tool returns a structured not-found error

package/openspec/specs/forecast/spec.md

@@ -1,15 +0,0 @@
-# forecast
-
-## Purpose
-
-Covers OmniFocus Forecast data, including forecast days, tasks due or deferred on a given day, the configured forecast tag, and forecast badge counts. Individual tools will be defined in the `forecast-and-inspection` change.
-
-## Requirements
-
-### Requirement: Capability declared
-
-The `forecast` capability SHALL cover OmniFocus Forecast data, including forecast days, tasks due or deferred on a given day, the configured forecast tag, and forecast badge counts. Requirements for individual tools SHALL be added by the `forecast-and-inspection` change.
-
-#### Scenario: Capability is named and scoped
-- **WHEN** a future change proposes adding forecast tools
-- **THEN** it lands requirements under this capability rather than inventing a new capability name

package/openspec/specs/identity-resolution/spec.md

@@ -1,51 +0,0 @@
-# identity-resolution
-
-## Purpose
-
-Defines how OmniFocus entities are addressed and resolved — canonical ID addressing, name/path-based lookup with ambiguity reporting, and the folder path format.
-
-## Requirements
-
-### Requirement: Canonical ID addressing
-
-The system SHALL use `id.primaryKey` as the canonical identifier for every addressable OmniFocus entity (Task, Project, Folder, Tag, Perspective). Every read tool SHALL return an `id` field carrying this value. Every write tool (in this and future changes) SHALL accept an `id` parameter as its primary addressing mode.
-
-#### Scenario: Read tools return primary key
-- **WHEN** a caller invokes `list_projects`
-- **THEN** every returned element has an `id` field equal to the OmniJS expression `project.id.primaryKey` for that project
-
-#### Scenario: IDs are stable within a session
-- **WHEN** a caller reads a project's ID via `list_projects`, then reads the same project again via `get_project` using that ID
-- **THEN** the second read succeeds and returns the same project, without re-resolving by name
-
-### Requirement: Name and path resolution with ambiguity reporting
-
-The system SHALL provide a `resolve_name` tool that accepts `{type, query, scope?}` and returns a list of candidate entities `[{id, name, path, type, ...}]`. When more than one entity matches the query, the tool SHALL return all matches and SHALL NOT silently pick a winner. The caller is responsible for disambiguating.
-
-#### Scenario: Unique match returns single candidate
-- **WHEN** `resolve_name` is called with `{type: "project", query: "Q4 Planning"}` and exactly one project has that name
-- **THEN** the tool returns a list with one element containing the project's id, name, and full folder path
-
-#### Scenario: Ambiguous match returns all candidates
-- **WHEN** `resolve_name` is called with `{type: "project", query: "Inbox Cleanup"}` and two projects have that name under different folders
-- **THEN** the tool returns a list with both candidates, each carrying a distinct id and distinct folder path
-
-#### Scenario: No match returns empty list
-- **WHEN** `resolve_name` is called with a query that matches no entity of the requested type
-- **THEN** the tool returns an empty list and does not throw an error
-
-#### Scenario: Path-qualified query narrows scope
-- **WHEN** `resolve_name` is called with `{type: "folder", query: "Acme", scope: "Work ▸ Clients"}`
-- **THEN** the tool returns only folders named "Acme" that are direct or transitive children of the folder at path "Work ▸ Clients"
-
-### Requirement: Folder path addressing
-
-The system SHALL represent folder paths as strings using the separator ` ▸ ` (U+25B8 with surrounding spaces) and SHALL support resolving a folder by its full path as an alternative to its ID. When a path is ambiguous (the same path exists under multiple roots, which cannot occur for folders but can for tags), the resolution SHALL report the ambiguity through `resolve_name`.
-
-#### Scenario: Folder resolves by full path
-- **WHEN** `resolve_name` is called with `{type: "folder", query: "Work ▸ Clients ▸ Acme"}`
-- **THEN** the tool returns the folder whose full ancestor chain matches that path exactly
-
-#### Scenario: Returned paths use the canonical separator
-- **WHEN** any read tool returns a folder path or a project's containing folder path
-- **THEN** the path uses ` ▸ ` as the separator between ancestor names

package/openspec/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/specs/perspective-management/spec.md

@@ -1,15 +0,0 @@
-# perspective-management
-
-## Purpose
-
-Covers listing built-in and custom perspectives, reading perspective metadata, and activating a perspective in a document window. Individual tools will be defined in the `perspectives-and-windows` change.
-
-## Requirements
-
-### Requirement: Capability declared
-
-The `perspective-management` capability SHALL cover listing built-in and custom perspectives, reading perspective metadata, and activating a perspective in a document window. Custom perspective *creation and editing* are a non-goal pending verification of OmniJS scriptability of `Perspective.Custom` definitions; if a future investigation proves the API is available, the non-goal may be revisited by a later change. Requirements for individual tools SHALL be added by the `perspectives-and-windows` change.
-
-#### Scenario: Capability is named and scoped
-- **WHEN** a future change proposes adding perspective tools
-- **THEN** it lands requirements under this capability rather than inventing a new capability name

package/openspec/specs/project-filtering/spec.md

@@ -1,72 +0,0 @@
-# project-filtering
-
-## Purpose
-
-Defines filtering and limiting behavior for the `list_projects` tool, including status, folder, and flagged filters, as well as result limits and enriched project summary fields.
-
-## Requirements
-
-### Requirement: Filter list_projects results
-
-The system SHALL allow `list_projects` to accept an optional `filter` object that restricts which projects are returned. All filter fields are optional and combine as AND conditions. When `filter.status` is omitted, the tool SHALL exclude projects with status `done` or `dropped` by default.
-
-Filter fields:
-- `status` (array of ProjectStatus): return only projects whose status is in the array; overrides the default exclusion of done/dropped
-- `folderId` (string): return only projects within the specified folder or any of its descendant folders; throws not-found if the folder ID does not exist
-- `flagged` (boolean): when `true`, return only flagged projects
-
-#### Scenario: Default excludes done and dropped projects
-- **WHEN** `list_projects` is called with no filter
-- **THEN** the tool returns only projects with status `active` or `onHold`
-
-#### Scenario: Filter by status array
-- **WHEN** `list_projects` is called with `{ filter: { status: ["active"] } }`
-- **THEN** the tool returns only active projects
-
-#### Scenario: Explicit status filter retrieves done projects
-- **WHEN** `list_projects` is called with `{ filter: { status: ["done"] } }`
-- **THEN** the tool returns completed projects (the default exclusion does not apply)
-
-#### Scenario: Filter by folderId returns projects in subtree
-- **WHEN** `list_projects` is called with `{ filter: { folderId: "abc123" } }`
-- **THEN** the tool returns only projects whose parent folder chain includes the specified folder
-
-#### Scenario: Non-existent folderId returns not-found error
-- **WHEN** `list_projects` is called with a `folderId` that does not correspond to any folder
-- **THEN** the tool returns a structured not-found error
-
-#### Scenario: Filter by flagged
-- **WHEN** `list_projects` is called with `{ filter: { flagged: true } }`
-- **THEN** the tool returns only flagged projects, excluding done and dropped projects
-
-#### Scenario: Combined filters act as AND
-- **WHEN** `list_projects` is called with `{ filter: { status: ["active"], flagged: true } }`
-- **THEN** the tool returns only projects that are both active AND flagged
-
-### Requirement: Limit list_projects results
-
-The system SHALL allow `list_projects` to accept an optional `limit` integer that caps the number of projects returned. When `limit` is omitted, a default of 100 SHALL apply.
-
-#### Scenario: Default limit of 100
-- **WHEN** `list_projects` is called without a `limit` and more than 100 projects match
-- **THEN** the tool returns at most 100 projects
-
-#### Scenario: Custom limit
-- **WHEN** `list_projects` is called with `{ limit: 20 }`
-- **THEN** the tool returns at most 20 projects
-
-### Requirement: Enriched project summary includes flagged and folderId
-
-The `ProjectSummary` returned by `list_projects` SHALL include `flagged` (boolean) and `folderId` (string or null) in addition to existing fields. `folderId` SHALL be the direct parent folder's `id.primaryKey`, or `null` for top-level projects.
-
-#### Scenario: Summary includes flagged
-- **WHEN** `list_projects` returns a flagged project
-- **THEN** the project summary includes `flagged: true`
-
-#### Scenario: Summary includes folderId for nested project
-- **WHEN** `list_projects` returns a project inside a folder
-- **THEN** the project summary includes `folderId` set to the parent folder's ID
-
-#### Scenario: Summary includes folderId null for top-level project
-- **WHEN** `list_projects` returns a top-level project with no containing folder
-- **THEN** the project summary includes `folderId: null`

package/openspec/specs/project-management/spec.md

@@ -1,31 +0,0 @@
-# project-management
-
-## Purpose
-
-Defines tools for reading and listing OmniFocus projects, including full project listing and detail retrieval by ID.
-
-## Requirements
-
-### Requirement: List projects
-
-The system SHALL provide a `list_projects` tool that returns projects in the OmniFocus database as an array of summaries, each containing `{id, name, folderPath, folderId, status, type, flagged}`. The `status` field SHALL be one of `"active" | "onHold" | "done" | "dropped"`. The `type` field SHALL be one of `"parallel" | "sequential" | "singleActions"`. The `folderPath` field SHALL use the canonical ` ▸ ` separator and SHALL be an empty string for top-level projects. The `folderId` field SHALL be the direct parent folder's ID or `null` for top-level projects. The tool SHALL accept an optional `filter` object (see project-filtering spec) and an optional `limit` integer (default 100). When no `filter.status` is provided, projects with status `done` or `dropped` SHALL be excluded by default.
-
-#### Scenario: Active and on-hold projects returned by default
-- **WHEN** `list_projects` is called with no arguments
-- **THEN** the tool returns only projects with status `active` or `onHold`, each with id, name, folderPath, folderId, status, type, and flagged populated
-
-#### Scenario: Single Actions list is reported with correct type
-- **WHEN** the database contains a Single Actions list project
-- **THEN** that project appears in the result with `type: "singleActions"`, never as `"parallel"` or `"sequential"`
-
-### Requirement: Get project by ID
-
-The system SHALL provide a `get_project` tool that accepts `{id: string}` and returns the full detail record of the named project, including `{id, name, note, folderPath, status, type, flagged, deferDate, dueDate, completionDate, reviewInterval, nextReviewDate, lastReviewDate, tagIds}`. If no project exists with that ID, the tool SHALL return a structured not-found error.
-
-#### Scenario: Existing project returns full detail
-- **WHEN** `get_project` is called with the ID of an existing project
-- **THEN** the tool returns the project's full detail record
-
-#### Scenario: Missing project returns not-found error
-- **WHEN** `get_project` is called with an ID that does not correspond to any project
-- **THEN** the tool returns a structured error with a not-found code

package/openspec/specs/project-write/spec.md

@@ -1,79 +0,0 @@
-# Spec: Project Write
-
-## Purpose
-
-Provides MCP tools for creating and mutating OmniFocus projects: creating new projects, editing project properties, marking projects complete or dropped, and permanently deleting projects.
-
-## 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