@scardis/omnifocus-mcp 0.1.0 → 0.1.2

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

@@ -1,26 +0,0 @@
-## Why
-
-`list_tasks` currently returns all tasks in scope with no filtering — an LLM asking "what's overdue?" on a large database receives thousands of tasks and must reason over the entire set. Filtering in the snippet before the JXA bridge means the LLM only sees the relevant tasks, making planning queries fast and practical.
-
-## What Changes
-
-- `list_tasks` accepts an optional `filter` object: `flagged`, `status` (array), `tagId`, `dueBeforeDate`
-- `list_tasks` accepts an optional `limit` (default 200)
-- **BREAKING**: Default behavior changes — when no `status` filter is given, complete and dropped tasks are excluded. Pass `status: ["complete"]` explicitly to retrieve completed tasks.
-- `TaskSummary` is enriched with `dueDate` and `tagIds` fields so the LLM can reason about results without fetching full task detail for each match
-
-## Capabilities
-
-### New Capabilities
-- `task-filtering`: Filter parameters and enriched summary for `list_tasks`
-
-### Modified Capabilities
-- `task-management`: `list_tasks` tool signature changes (new filter/limit params, enriched return shape, changed default behavior)
-
-## Impact
-
-- `src/snippets/list_tasks.js` — rewritten to apply filters and return enriched fields
-- `src/schemas/shapes.ts` — `TaskSummary` gains `dueDate` and `tagIds`; new `ListTasksFilter` schema
-- `src/tools/listTasks.ts` — input schema updated with filter and limit
-- `test/unit/tools.listTasks.test.ts` — existing unit tests may need updating for new schema shape
-- `test/integration/listTasks.int.test.ts` — new integration tests for filter combinations

package/openspec/changes/archive/2026-04-09-task-filtering/specs/task-filtering/spec.md

@@ -1,63 +0,0 @@
-## ADDED Requirements
-
-### Requirement: Filter list_tasks results
-
-The system SHALL allow `list_tasks` to accept an optional `filter` object that restricts which tasks are returned. All filter fields are optional and combine as AND conditions. When `filter.status` is omitted, the tool SHALL exclude tasks with status `complete` or `dropped` by default.
-
-Filter fields:
-- `flagged` (boolean): when `true`, return only flagged tasks
-- `status` (array of TaskStatus): return only tasks whose status is in the array; overrides the default exclusion of complete/dropped
-- `tagId` (string): return only tasks that have this tag assigned
-- `dueBeforeDate` (ISO datetime string): return only tasks where `dueDate` is non-null and on or before this date
-
-#### Scenario: Filter by flagged
-- **WHEN** `list_tasks` is called with `{ scope: { all: true }, filter: { flagged: true } }`
-- **THEN** the tool returns only tasks where `flagged` is `true`, excluding complete and dropped tasks
-
-#### Scenario: Filter by status array
-- **WHEN** `list_tasks` is called with `{ scope: { all: true }, filter: { status: ["overdue", "dueSoon"] } }`
-- **THEN** the tool returns only tasks with status `overdue` or `dueSoon`
-
-#### Scenario: Filter by tagId
-- **WHEN** `list_tasks` is called with `{ scope: { projectId: "abc123" }, filter: { tagId: "tag456" } }`
-- **THEN** the tool returns only tasks in that project that have the specified tag assigned
-
-#### Scenario: Filter by dueBeforeDate
-- **WHEN** `list_tasks` is called with `{ scope: { all: true }, filter: { dueBeforeDate: "2026-04-09T23:59:59Z" } }`
-- **THEN** the tool returns only tasks with a non-null dueDate on or before the specified date, excluding complete and dropped tasks
-
-#### Scenario: Default excludes complete and dropped
-- **WHEN** `list_tasks` is called with no filter
-- **THEN** the tool returns tasks with any status except `complete` and `dropped`
-
-#### Scenario: Explicit status filter overrides default exclusion
-- **WHEN** `list_tasks` is called with `{ filter: { status: ["complete"] } }`
-- **THEN** the tool returns completed tasks (the default exclusion does not apply)
-
-#### Scenario: Combined filters act as AND
-- **WHEN** `list_tasks` is called with `{ filter: { flagged: true, tagId: "tag456" } }`
-- **THEN** the tool returns only tasks that are both flagged AND have that tag
-
-### Requirement: Limit list_tasks results
-
-The system SHALL allow `list_tasks` to accept an optional `limit` integer that caps the number of tasks returned. When `limit` is omitted, a default of 200 SHALL apply.
-
-#### Scenario: Default limit of 200
-- **WHEN** `list_tasks` is called without a `limit` and more than 200 tasks match
-- **THEN** the tool returns at most 200 tasks
-
-#### Scenario: Custom limit
-- **WHEN** `list_tasks` is called with `{ limit: 50 }`
-- **THEN** the tool returns at most 50 tasks
-
-### Requirement: Enriched task summary includes dueDate and tagIds
-
-The `TaskSummary` returned by `list_tasks` SHALL include `dueDate` (ISO datetime or null) and `tagIds` (array of tag ID strings) in addition to existing fields.
-
-#### Scenario: Summary includes dueDate
-- **WHEN** `list_tasks` returns a task that has a due date set
-- **THEN** the task summary includes `dueDate` as an ISO datetime string
-
-#### Scenario: Summary includes tagIds
-- **WHEN** `list_tasks` returns a task that has tags assigned
-- **THEN** the task summary includes `tagIds` as an array of tag ID strings

package/openspec/changes/archive/2026-04-09-task-filtering/specs/task-management/spec.md

@@ -1,17 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: List tasks with scope filter
-
-The system SHALL provide a `list_tasks` tool that returns tasks within a caller-specified scope. The scope SHALL be one of: `{projectId: string}`, `{folderId: string}` (all tasks in projects under that folder, recursively), `{inbox: true}`, or `{all: true}` (the full flattened task list). The tool SHALL accept an optional `filter` object (see task-filtering spec) and an optional `limit` integer (default 200). The tool SHALL return an array of task summaries, each containing `{id, name, status, flagged, containerId, containerType, dueDate, tagIds}`. When no `filter.status` is provided, tasks with status `complete` or `dropped` SHALL be excluded by default.
-
-#### Scenario: List tasks in a specific project
-- **WHEN** `list_tasks` is called with `{projectId: "abc123"}`
-- **THEN** the tool returns actionable tasks (non-complete, non-dropped) directly or transitively contained in that project, each carrying the project id as `containerId` and `"project"` as `containerType`
-
-#### Scenario: List inbox tasks
-- **WHEN** `list_tasks` is called with `{inbox: true}`
-- **THEN** the tool returns actionable inbox tasks with `containerType` set to `"inbox"`
-
-#### Scenario: Invalid scope is rejected at the TS boundary
-- **WHEN** `list_tasks` is called with `{projectId: "abc", inbox: true}` (mutually exclusive scopes)
-- **THEN** the tool returns a validation error before any snippet executes

package/openspec/changes/archive/2026-04-09-task-filtering/tasks.md

@@ -1,42 +0,0 @@
-## 1. Schema changes (src/schemas/)
-
-- [x] 1.1 Add `dueDate: z.string().datetime().nullable()` and `tagIds: z.array(IdSchema)` to `TaskSummary` in `shapes.ts`
-- [x] 1.2 Define `ListTasksFilter` zod schema: `{ flagged: z.literal(true).optional(), status: z.array(TaskStatus).optional(), tagId: IdSchema.optional(), dueBeforeDate: z.string().datetime().optional() }`
-- [x] 1.3 Export `ListTasksFilter` from `src/schemas/index.ts`
-
-## 2. Snippet rewrite (src/snippets/list_tasks.js)
-
-- [x] 2.1 Add `dueDate` and `tagIds` to the `mapTask` helper
-- [x] 2.2 Implement default status exclusion: when `args.filter?.status` is absent, exclude `Task.Status.Completed` and `Task.Status.Dropped`
-- [x] 2.3 Implement `flagged` filter: when `args.filter?.flagged` is `true`, exclude non-flagged tasks
-- [x] 2.4 Implement `status` array filter: when `args.filter?.status` is provided, keep only tasks whose status maps to one of the given strings
-- [x] 2.5 Implement `tagId` filter: when `args.filter?.tagId` is provided, keep only tasks that have a tag whose `id.primaryKey` matches
-- [x] 2.6 Implement `dueBeforeDate` filter: when provided, keep only tasks where `task.dueDate` is non-null and `<= new Date(args.filter.dueBeforeDate)`
-- [x] 2.7 Apply `args.limit` (default 200) as a slice after all filters
-
-## 3. Tool handler update (src/tools/listTasks.ts)
-
-- [x] 3.1 Add `filter: ListTasksFilter.optional()` and `limit: z.number().int().positive().optional()` to `listTasksSchema`
-- [x] 3.2 Pass `filter` and `limit` through to `runSnippet`
-- [x] 3.3 Update tool description to document the filter params and the new default-exclusion behavior
-
-## 4. Unit tests (test/unit/)
-
-- [x] 4.1 Update `tools.listTasks.test.ts`: add `dueDate` and `tagIds` to any TaskSummary fixtures that are now required fields
-- [x] 4.2 Add schema tests for `ListTasksFilter`: valid filter passes; invalid status enum rejected; dueBeforeDate must be ISO datetime
-
-## 5. Integration tests (test/integration/)
-
-- [x] 5.1 `listTasksFiltered.int.test.ts`: create tasks with known properties in a fixture folder; verify `flagged: true` filter returns only flagged tasks
-- [x] 5.2 Verify `status` filter: create a completed task; confirm it is absent by default and present when `status: ["complete"]` is passed
-- [x] 5.3 Verify `tagId` filter: assign a tag to one task; confirm only that task is returned
-- [x] 5.4 Verify `dueBeforeDate` filter: create a task with a due date in the past; confirm it is returned; create one due far in the future; confirm it is not
-- [x] 5.5 Verify `limit`: create more tasks than the limit; confirm result is capped
-- [x] 5.6 Verify enriched summary: returned tasks include non-null `dueDate` and `tagIds` when applicable
-
-## 6. Verification
-
-- [x] 6.1 `npm run typecheck` clean
-- [x] 6.2 `npm test` (unit suite) clean
-- [x] 6.3 Manually run integration suite; verify fixture cleanup
-- [ ] 6.4 Connect to Claude Desktop; exercise filter queries against a real database

package/openspec/changes/archive/2026-04-10-planned-date/.openspec.yaml

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

package/openspec/changes/archive/2026-04-10-planned-date/design.md

@@ -1,27 +0,0 @@
-## Context
-
-OmniFocus 4 distinguishes three date types on tasks: `deferDate` (hides until), `plannedDate` (Forecast target), and `dueDate` (hard deadline). The MCP server already handles defer and due with the pattern `isoOrNull(task.deferDate)` for reading and `task.deferDate = args.deferDate ? new Date(args.deferDate) : null` for writing. `plannedDate` follows the identical pattern — confirmed writable via OmniJS.
-
-## Goals / Non-Goals
-
-**Goals:**
-- Add `plannedDate` to `create_task`, `edit_task`, `get_task`, and all snippets returning `TaskDetail`
-- Follow the exact same pattern as `deferDate` and `dueDate`
-
-**Non-Goals:**
-- `effectiveDeferDate` / `effectiveDueDate` (computed fields inherited from projects — read-only, not actionable)
-- Planned date on projects (projects don't have `plannedDate` in OmniJS)
-
-## Decisions
-
-### Decision 1: Same pattern as existing dates
-
-`plannedDate` is added as `z.string().datetime().optional()` in `CreateTaskInput`, `z.string().datetime().nullable().optional()` in `EditTaskInput`, and `z.string().datetime().nullable()` in `TaskDetail`. No new abstractions needed.
-
-### Decision 2: All TaskDetail-returning snippets updated
-
-Five snippets return `TaskDetail`: `create_task`, `edit_task`, `get_task`, `complete_task`, `drop_task`. All five get `plannedDate: isoOrNull(task.plannedDate)` added to their return object.
-
-## Risks / Trade-offs
-
-- **Minimal risk** — purely additive, follows established patterns exactly. No behavioral change for existing callers.

package/openspec/changes/archive/2026-04-10-planned-date/proposal.md

@@ -1,29 +0,0 @@
-## Why
-
-OmniFocus 4 has three distinct date concepts — defer, planned, and due — but the MCP server only exposes `deferDate` and `dueDate`. The missing `plannedDate` is the soft "when I intend to work on this" date that shows up in Forecast view without hiding the task or triggering overdue status. This is the right date type for many recurring tasks (e.g., cleaning, reviews) where you want Forecast visibility without hard-deadline pressure.
-
-The OmniJS API already exposes `task.plannedDate` as a fully readable, writable, and clearable property — no API barrier.
-
-## What Changes
-
-- `create_task`: add optional `plannedDate` field
-- `edit_task`: add optional `plannedDate` field (nullable to clear)
-- `get_task` / `TaskDetail`: return `plannedDate` in the detail record
-- All snippets returning `TaskDetail` (`complete_task`, `drop_task`) include `plannedDate`
-
-## Capabilities
-
-### New Capabilities
-
-(none)
-
-### Modified Capabilities
-
-- `task-write`: `create_task` and `edit_task` gain a `plannedDate` parameter
-- `task-management`: `get_task` returns `plannedDate` in `TaskDetail`
-
-## Impact
-
-- `src/schemas/shapes.ts`: `CreateTaskInput`, `EditTaskInput`, `TaskDetail` extended
-- `src/snippets/create_task.js`, `edit_task.js`, `get_task.js`, `complete_task.js`, `drop_task.js`: add `plannedDate` field
-- No breaking changes — all new fields are optional; existing callers unaffected

package/openspec/changes/archive/2026-04-10-planned-date/specs/task-management/spec.md

@@ -1,29 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Get task by ID
-
-The system SHALL provide a `get_task` tool that accepts `{id: string}` and returns the full detail record of the named task, including `{id, name, note, status, flagged, deferDate, plannedDate, dueDate, completionDate, estimatedMinutes, containerId, containerType, tagIds, parentTaskId, repetitionRule}`. The `parentTaskId` field SHALL be `null` for top-level tasks and SHALL contain the parent task's `id.primaryKey` for subtasks. The `repetitionRule` field SHALL be `null` when no repetition rule is set, and SHALL be a structured object with `{frequency, interval, daysOfWeek?, method}` when a rule exists. The `plannedDate` field SHALL be `null` when no planned date is set. If no task exists with that ID, the tool SHALL return a structured not-found error.
-
-#### Scenario: Existing task returns full detail
-- **WHEN** `get_task` is called with the ID of an existing task
-- **THEN** the tool returns the task's full detail record including all scalar fields, the list of tag IDs assigned to it, `parentTaskId`, `repetitionRule`, and `plannedDate`
-
-#### Scenario: Subtask includes parentTaskId
-- **WHEN** `get_task` is called with the ID of a subtask
-- **THEN** the returned record includes `parentTaskId` set to the parent task's stable ID
-
-#### Scenario: Task without repetition returns null repetitionRule
-- **WHEN** `get_task` is called for a task with no repetition rule
-- **THEN** the returned TaskDetail includes `repetitionRule: null`
-
-#### Scenario: Task with repetition returns structured repetitionRule
-- **WHEN** `get_task` is called for a task that has a repetition rule
-- **THEN** the returned TaskDetail includes `repetitionRule` with `frequency`, `interval`, `method`, and `daysOfWeek` (if applicable)
-
-#### Scenario: Task with planned date returns plannedDate
-- **WHEN** `get_task` is called for a task that has a planned date set
-- **THEN** the returned TaskDetail includes `plannedDate` as an ISO datetime string
-
-#### Scenario: Missing task returns not-found error
-- **WHEN** `get_task` is called with an ID that does not correspond to any task
-- **THEN** the tool returns a structured error with a not-found code and does not throw an unhandled exception

package/openspec/changes/archive/2026-04-10-planned-date/specs/task-write/spec.md

@@ -1,69 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Create task
-
-The system SHALL provide a `create_task` tool that creates a new OmniFocus task and returns its full detail record. The tool SHALL accept `{name: string, note?: string, flagged?: boolean, deferDate?: string, plannedDate?: string, dueDate?: string, estimatedMinutes?: number, projectId?: string, parentTaskId?: string, tagIds?: string[], repetitionRule?: RepetitionRuleInput}`. Placement SHALL be determined as follows: if both `projectId` and `parentTaskId` are provided the tool SHALL return an error; if only `projectId` is provided the task is placed at the project root; if only `parentTaskId` is provided the task is created as a subtask inheriting its parent's project; if neither is provided the task is placed in the inbox. When `repetitionRule` is provided, the task SHALL have the specified recurrence set at creation.
-
-#### Scenario: Create inbox task
-- **WHEN** `create_task` is called with `{name: "Buy milk"}` and no `projectId` or `parentTaskId`
-- **THEN** the tool creates the task in the OmniFocus inbox and returns its full detail record including a stable `id`
-
-#### Scenario: Create task in a project
-- **WHEN** `create_task` is called with `{name: "Write tests", projectId: "abc123"}`
-- **THEN** the tool creates the task at the root of the specified project and returns its full detail record
-
-#### Scenario: Create subtask
-- **WHEN** `create_task` is called with `{name: "Review PR", parentTaskId: "xyz789"}`
-- **THEN** the tool creates the task as a child of the specified parent task and returns its full detail record
-
-#### Scenario: Ambiguous placement is rejected
-- **WHEN** `create_task` is called with both `projectId` and `parentTaskId`
-- **THEN** the tool returns a validation error before any snippet executes
-
-#### Scenario: Non-existent project returns not-found error
-- **WHEN** `create_task` is called with a `projectId` that does not correspond to any project
-- **THEN** the tool returns a structured not-found error
-
-#### Scenario: Create task with repetition rule
-- **WHEN** `create_task` is called with `{ name: "Weekly review", repetitionRule: { frequency: "weekly", interval: 1, method: "start" } }`
-- **THEN** the task is created with the specified recurrence and the returned TaskDetail includes the parsed repetitionRule
-
-#### Scenario: Create task with planned date
-- **WHEN** `create_task` is called with `{ name: "Clean kitchen", plannedDate: "2026-04-15T09:00:00Z" }`
-- **THEN** the task is created with the specified planned date and the returned TaskDetail includes `plannedDate`
-
-### Requirement: Edit task
-
-The system SHALL provide an `edit_task` tool that modifies an existing task and returns its updated full detail record. The tool SHALL accept `{id: string}` plus any subset of `{name?: string, note?: string, flagged?: boolean, deferDate?: string | null, plannedDate?: string | null, dueDate?: string | null, estimatedMinutes?: number | null, tagIds?: string[], repetitionRule?: RepetitionRuleInput | null}`. Fields omitted from the call SHALL be left unchanged. When `tagIds` is provided it SHALL replace the task's entire tag set; when omitted, tags SHALL be unchanged. Passing `null` for a date or `estimatedMinutes` SHALL clear the field. Passing `repetitionRule: null` SHALL clear the task's recurrence; passing a `RepetitionRuleInput` object SHALL set or replace the recurrence; omitting `repetitionRule` SHALL leave the existing recurrence unchanged.
-
-#### Scenario: Edit a single field
-- **WHEN** `edit_task` is called with `{id: "abc123", flagged: true}`
-- **THEN** only the `flagged` field is changed; all other fields retain their previous values
-
-#### Scenario: Replace tag set
-- **WHEN** `edit_task` is called with `{id: "abc123", tagIds: ["t1", "t2"]}`
-- **THEN** the task's tags are set to exactly `["t1", "t2"]`, replacing any previously assigned tags
-
-#### Scenario: Clear a date field
-- **WHEN** `edit_task` is called with `{id: "abc123", dueDate: null}`
-- **THEN** the task's due date is cleared
-
-#### Scenario: Clear planned date
-- **WHEN** `edit_task` is called with `{id: "abc123", plannedDate: null}`
-- **THEN** the task's planned date is cleared
-
-#### Scenario: Non-existent task returns not-found error
-- **WHEN** `edit_task` is called with an ID that does not correspond to any task
-- **THEN** the tool returns a structured not-found error
-
-#### Scenario: Non-existent tag ID returns not-found error
-- **WHEN** `edit_task` is called with a `tagIds` array containing an ID that does not correspond to any tag
-- **THEN** the tool returns a structured not-found error and the task is not modified
-
-#### Scenario: Set repetition via edit
-- **WHEN** `edit_task` is called with `{ id: "t1", repetitionRule: { frequency: "monthly", interval: 1, method: "dueDate" } }`
-- **THEN** the task's recurrence is set and all other fields are unchanged
-
-#### Scenario: Clear repetition via edit
-- **WHEN** `edit_task` is called with `{ id: "t1", repetitionRule: null }`
-- **THEN** the task's recurrence is cleared and all other fields are unchanged

package/openspec/changes/archive/2026-04-10-planned-date/tasks.md

@@ -1,26 +0,0 @@
-## 1. Schema changes (src/schemas/)
-
-- [x] 1.1 Add `plannedDate: z.string().datetime().optional()` to `CreateTaskInput` in `shapes.ts`
-- [x] 1.2 Add `plannedDate: z.string().datetime().nullable().optional()` to `EditTaskInput` in `shapes.ts`
-- [x] 1.3 Add `plannedDate: z.string().datetime().nullable()` to `TaskDetail` in `shapes.ts`
-
-## 2. Snippet updates (src/snippets/)
-
-- [x] 2.1 Update `create_task.js`: set `task.plannedDate` when provided; include `plannedDate: isoOrNull(task.plannedDate)` in returned TaskDetail
-- [x] 2.2 Update `edit_task.js`: set/clear `task.plannedDate` using same pattern as deferDate/dueDate; include in returned TaskDetail
-- [x] 2.3 Update `get_task.js`: include `plannedDate: isoOrNull(task.plannedDate)` in returned detail
-- [x] 2.4 Update `complete_task.js`: include `plannedDate: isoOrNull(task.plannedDate)` in returned TaskDetail
-- [x] 2.5 Update `drop_task.js`: include `plannedDate: isoOrNull(task.plannedDate)` in returned TaskDetail
-
-## 3. Integration tests (test/integration/)
-
-- [x] 3.1 `plannedDate.int.test.ts`: create task with plannedDate; verify get_task returns it
-- [x] 3.2 `plannedDate.int.test.ts`: edit task to set plannedDate; verify get_task reflects it
-- [x] 3.3 `plannedDate.int.test.ts`: edit task to clear plannedDate (null); verify get_task returns null
-- [x] 3.4 `plannedDate.int.test.ts`: create task without plannedDate; verify get_task returns null (backward compat)
-
-## 4. Verification
-
-- [x] 4.1 `npm run typecheck` clean
-- [x] 4.2 `npm test` (unit suite) clean
-- [x] 4.3 Manually run integration suite

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

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

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

@@ -1,81 +0,0 @@
-## Context
-
-OmniFocus tasks carry a `Task.RepetitionRule` which combines an ICS RRULE string with a `RepetitionMethod` enum (`Fixed`, `DueDate`, `Start`). The OmniJS API is:
-- `task.repetitionRule = new Task.RepetitionRule(rruleString, method)` — set
-- `task.repetitionRule = null` — clear
-- `task.repetitionRule.ruleString` — read the RRULE back
-- `task.repetitionRule.method` — read the method back
-
-The OmniFocus UI exposes: frequency (daily/weekly/monthly/yearly), interval (every N units), days-of-week (weekly only), and repeat method (fixed interval / due date / completion date). This change targets exactly that surface.
-
-## Goals / Non-Goals
-
-**Goals:**
-- `create_task`: accept optional `repetitionRule` to set recurrence at creation
-- `edit_task`: accept optional `repetitionRule` (nullable to clear) on existing tasks
-- `get_task` / `TaskDetail`: return current repetition as structured fields (or null)
-- Validate that `daysOfWeek` is only meaningful on `frequency: "weekly"`
-
-**Non-Goals:**
-- RRULE patterns not reachable from the OmniFocus UI (e.g., "every 2nd Tuesday of the month", end-by-count, end-by-date)
-- Project repetition (projects don't have `repetitionRule` in OmniJS)
-- Raw RRULE escape hatch — scope is UI surface only
-
-## Decisions
-
-### Decision 1: Structured schema, no raw rrule
-
-Input schema uses structured fields (`frequency`, `interval`, `daysOfWeek`, `method`). The snippet constructs the RRULE internally via `new Task.RepetitionRule(rruleString, methodEnum)`. This keeps the API LLM-friendly and prevents invalid RRULE strings from being passed in.
-
-Considered: raw `{ rrule, method }` input. Rejected because LLMs may produce invalid RRULE syntax, and the UI surface is small enough to model fully without an escape hatch.
-
-**OmniJS API notes (discovered empirically):**
-- Constructor: `new Task.RepetitionRule(rrule, method)` — NOT `.make()`
-- `Task.RepetitionMethod.Fixed` — fixed interval
-- `Task.RepetitionMethod.DueDate` — repeat from due date
-- `Task.RepetitionMethod.DeferUntilDate` — repeat from completion date (maps to our `"start"` method)
-- Enum values have no `.name` property; use `String(enumValue)` which returns e.g. `"[object Task.RepetitionMethod: DeferUntilDate]"`
-
-### Decision 2: RepetitionRuleInput is its own schema, embedded in CreateTaskInput and EditTaskInput
-
-```
-RepetitionRuleInput = z.object({
-  frequency: z.enum(["daily", "weekly", "monthly", "yearly"]),
-  interval: z.number().int().positive().default(1),
-  daysOfWeek: z.array(z.enum(["sunday","monday","tuesday","wednesday","thursday","friday","saturday"])).optional(),
-  method: z.enum(["fixed", "dueDate", "start"]),
-})
-.refine(d => !d.daysOfWeek || d.frequency === "weekly", {
-  message: "daysOfWeek is only valid when frequency is 'weekly'"
-})
-```
-
-In `EditTaskInput`: `repetitionRule: RepetitionRuleInput.nullable().optional()` — omit to leave unchanged, `null` to clear, object to set.
-
-### Decision 3: Read side returns structured fields parsed from RRULE
-
-`TaskDetail.repetitionRule` is `RepetitionRuleDetail | null`:
-```
-RepetitionRuleDetail = z.object({
-  frequency: z.enum(["daily","weekly","monthly","yearly"]),
-  interval: z.number(),
-  daysOfWeek: z.array(...).optional(),
-  method: z.enum(["fixed","dueDate","start"]),
-})
-```
-
-The snippet parses `task.repetitionRule.ruleString` using simple regex/split to extract FREQ, INTERVAL, and BYDAY. If parsing fails (unsupported RRULE set outside the UI), return `{ rrule: rawString, method }` as a fallback with a `_raw: true` flag — this way the LLM sees something rather than crashing.
-
-### Decision 4: RRULE construction in snippet, not TypeScript
-
-Keeps the logic next to the OmniJS API call. TypeScript layer only validates the structured input and passes it through.
-
-### Decision 5: daysOfWeek maps to BYDAY abbreviations
-
-Day mapping: sunday→SU, monday→MO, tuesday→TU, wednesday→WE, thursday→TH, friday→FR, saturday→SA. When `daysOfWeek` is absent for a weekly rule, no `BYDAY` component is added (repeats on the same weekday as the task's due/defer date).
-
-## Risks / Trade-offs
-
-- **Tasks without a due or defer date + Fixed method**: OmniFocus behavior is undefined (no anchor date). Document in tool description; not validated by the schema.
-- **RRULE parsing on read**: Simple regex parsing covers the UI surface; complex patterns set via OmniJS directly will hit the `_raw` fallback.
-- **interval default**: Schema defaults `interval` to 1 but it must be passed explicitly in the RRULE string (`INTERVAL=1`) — OmniFocus requires it.

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

@@ -1,28 +0,0 @@
-## Why
-
-OmniFocus tasks support repeat intervals, but the MCP server has no way to set, edit, or read repetition rules — forcing users to manually configure recurrence in OmniFocus after every task creation. This gap means AI-driven task creation is incomplete for any workflow that involves repeating tasks.
-
-## What Changes
-
-- `create_task`: add optional `repetitionRule` field to set recurrence at creation time
-- `edit_task`: add optional `repetitionRule` field (nullable to clear recurrence) on existing tasks
-- `get_task` / `TaskDetail`: return current `repetitionRule` as structured fields (or null if none)
-- New `RepetitionRuleInput` and `RepetitionRuleDetail` schemas covering the OmniFocus UI surface: frequency, interval, optional days-of-week (weekly only), and repeat method
-
-## Capabilities
-
-### New Capabilities
-
-- `recurrence`: Requirements for reading and writing OmniFocus task repetition rules (frequency, interval, daysOfWeek, method). Note: the `recurrence` spec already exists as a placeholder — this change fills it in.
-
-### Modified Capabilities
-
-- `task-write`: `create_task` and `edit_task` gain a `repetitionRule` parameter
-- `task-management`: `get_task` returns `repetitionRule` in `TaskDetail`
-
-## Impact
-
-- `src/schemas/shapes.ts`: new `RepetitionRuleInput` and `RepetitionRuleDetail` types; `CreateTaskInput`, `EditTaskInput`, `TaskDetail` extended
-- `src/schemas/index.ts`: new exports
-- `src/snippets/create_task.js`, `edit_task.js`, `get_task.js`: snippet updates
-- No breaking changes — all new fields are optional; existing callers unaffected

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

@@ -1,47 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Capability declared
-
-The `recurrence` capability covers the construction, assignment, reading, and clearing of `Task.RepetitionRule` values on OmniFocus tasks. The capability exposes a structured schema matching the OmniFocus UI surface: `frequency` (`daily` | `weekly` | `monthly` | `yearly`), `interval` (every N units, ≥1), `daysOfWeek` (weekly only, any subset of the 7 days), and `method` (`fixed` | `dueDate` | `start`). Repetition is set and cleared through `create_task` and `edit_task`; the current rule is returned by `get_task` as structured fields parsed from the underlying RRULE. Raw RRULE strings are not exposed as input — all recurrence is expressed through the structured schema.
-
-#### Scenario: Capability is named and scoped
-- **WHEN** a change proposes adding or modifying recurrence-related behavior
-- **THEN** it lands requirements under this capability
-
-## ADDED Requirements
-
-### Requirement: Set repetition rule on task
-
-The system SHALL accept a `repetitionRule` field in `create_task` and `edit_task`. When provided, the snippet SHALL construct an ICS RRULE string from the structured fields and assign it via `Task.RepetitionRule.make(rrule, method)`. The `daysOfWeek` field SHALL only be valid when `frequency` is `"weekly"`; providing it for any other frequency SHALL be a validation error. When `edit_task` receives `repetitionRule: null`, the snippet SHALL assign `task.repetitionRule = null` to clear the rule. When `edit_task` omits `repetitionRule` entirely, the existing rule SHALL be left unchanged.
-
-#### Scenario: Set daily repetition at creation
-- **WHEN** `create_task` is called with `{ name: "Stand-up", repetitionRule: { frequency: "daily", interval: 1, method: "fixed" } }`
-- **THEN** the created task has a repetition rule of every day (fixed interval) and the returned TaskDetail includes the parsed repetitionRule
-
-#### Scenario: Set weekly repetition on specific days
-- **WHEN** `create_task` is called with `{ repetitionRule: { frequency: "weekly", interval: 1, daysOfWeek: ["monday", "wednesday", "friday"], method: "start" } }`
-- **THEN** the task repeats every Mon/Wed/Fri from completion date
-
-#### Scenario: Edit task to add repetition
-- **WHEN** `edit_task` is called with `{ id: "t1", repetitionRule: { frequency: "monthly", interval: 1, method: "dueDate" } }`
-- **THEN** the task's repetition rule is set to monthly (due date) and all other fields are unchanged
-
-#### Scenario: Clear repetition via null
-- **WHEN** `edit_task` is called with `{ id: "t1", repetitionRule: null }`
-- **THEN** the task's repetition rule is cleared and `get_task` returns `repetitionRule: null` for that task
-
-#### Scenario: daysOfWeek on non-weekly frequency is a validation error
-- **WHEN** `create_task` or `edit_task` is called with `{ repetitionRule: { frequency: "daily", daysOfWeek: ["monday"], method: "fixed" } }`
-- **THEN** the tool returns a validation error before any snippet executes
-
-### Requirement: Return repetition rule from get_task
-
-The system SHALL include a `repetitionRule` field in the `TaskDetail` returned by `get_task`. When a task has no repetition rule, the field SHALL be `null`. When a task has a rule, the field SHALL be a structured object with `frequency`, `interval`, `daysOfWeek` (omitted when not applicable), and `method`, parsed from the underlying RRULE and RepetitionMethod.
-
-#### Scenario: get_task returns null when no repetition set
-- **WHEN** `get_task` is called for a task with no repetition rule
-- **THEN** the returned TaskDetail includes `repetitionRule: null`
-
-#### Scenario: get_task returns structured repetition fields
-- **WHEN** `get_task` is called for a task with a weekly repetition rule
-- **THEN** the returned TaskDetail includes `repetitionRule` with `frequency: "weekly"`, correct `interval`, `daysOfWeek` array, and `method`

package/openspec/changes/archive/2026-04-10-task-recurrence/specs/task-management/spec.md

@@ -1,25 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Get task by ID
-
-The system SHALL provide a `get_task` tool that accepts `{id: string}` and returns the full detail record of the named task, including `{id, name, note, status, flagged, deferDate, dueDate, completionDate, estimatedMinutes, containerId, containerType, tagIds, parentTaskId, repetitionRule}`. The `parentTaskId` field SHALL be `null` for top-level tasks and SHALL contain the parent task's `id.primaryKey` for subtasks. The `repetitionRule` field SHALL be `null` when no repetition rule is set, and SHALL be a structured object with `{frequency, interval, daysOfWeek?, method}` when a rule exists. If no task exists with that ID, the tool SHALL return a structured not-found error.
-
-#### Scenario: Existing task returns full detail
-- **WHEN** `get_task` is called with the ID of an existing task
-- **THEN** the tool returns the task's full detail record including all scalar fields, the list of tag IDs assigned to it, `parentTaskId`, and `repetitionRule`
-
-#### Scenario: Subtask includes parentTaskId
-- **WHEN** `get_task` is called with the ID of a subtask
-- **THEN** the returned record includes `parentTaskId` set to the parent task's stable ID
-
-#### Scenario: Task without repetition returns null repetitionRule
-- **WHEN** `get_task` is called for a task with no repetition rule
-- **THEN** the returned TaskDetail includes `repetitionRule: null`
-
-#### Scenario: Task with repetition returns structured repetitionRule
-- **WHEN** `get_task` is called for a task that has a repetition rule
-- **THEN** the returned TaskDetail includes `repetitionRule` with `frequency`, `interval`, `method`, and `daysOfWeek` (if applicable)
-
-#### Scenario: Missing task returns not-found error
-- **WHEN** `get_task` is called with an ID that does not correspond to any task
-- **THEN** the tool returns a structured error with a not-found code and does not throw an unhandled exception

package/openspec/changes/archive/2026-04-10-task-recurrence/specs/task-write/spec.md

@@ -1,61 +0,0 @@
-## MODIFIED Requirements
-
-### Requirement: Create task
-
-The system SHALL provide a `create_task` tool that creates a new OmniFocus task and returns its full detail record. The tool SHALL accept `{name: string, note?: string, flagged?: boolean, deferDate?: string, dueDate?: string, estimatedMinutes?: number, projectId?: string, parentTaskId?: string, tagIds?: string[], repetitionRule?: RepetitionRuleInput}`. Placement SHALL be determined as follows: if both `projectId` and `parentTaskId` are provided the tool SHALL return an error; if only `projectId` is provided the task is placed at the project root; if only `parentTaskId` is provided the task is created as a subtask inheriting its parent's project; if neither is provided the task is placed in the inbox. When `repetitionRule` is provided, the task SHALL have the specified recurrence set at creation.
-
-#### Scenario: Create inbox task
-- **WHEN** `create_task` is called with `{name: "Buy milk"}` and no `projectId` or `parentTaskId`
-- **THEN** the tool creates the task in the OmniFocus inbox and returns its full detail record including a stable `id`
-
-#### Scenario: Create task in a project
-- **WHEN** `create_task` is called with `{name: "Write tests", projectId: "abc123"}`
-- **THEN** the tool creates the task at the root of the specified project and returns its full detail record
-
-#### Scenario: Create subtask
-- **WHEN** `create_task` is called with `{name: "Review PR", parentTaskId: "xyz789"}`
-- **THEN** the tool creates the task as a child of the specified parent task and returns its full detail record
-
-#### Scenario: Ambiguous placement is rejected
-- **WHEN** `create_task` is called with both `projectId` and `parentTaskId`
-- **THEN** the tool returns a validation error before any snippet executes
-
-#### Scenario: Non-existent project returns not-found error
-- **WHEN** `create_task` is called with a `projectId` that does not correspond to any project
-- **THEN** the tool returns a structured not-found error
-
-#### Scenario: Create task with repetition rule
-- **WHEN** `create_task` is called with `{ name: "Weekly review", repetitionRule: { frequency: "weekly", interval: 1, method: "start" } }`
-- **THEN** the task is created with the specified recurrence and the returned TaskDetail includes the parsed repetitionRule
-
-### Requirement: Edit task
-
-The system SHALL provide an `edit_task` tool that modifies an existing task and returns its updated full detail record. The tool SHALL accept `{id: string}` plus any subset of `{name?: string, note?: string, flagged?: boolean, deferDate?: string | null, dueDate?: string | null, estimatedMinutes?: number | null, tagIds?: string[], repetitionRule?: RepetitionRuleInput | null}`. Fields omitted from the call SHALL be left unchanged. When `tagIds` is provided it SHALL replace the task's entire tag set; when omitted, tags SHALL be unchanged. Passing `null` for a date or `estimatedMinutes` SHALL clear the field. Passing `repetitionRule: null` SHALL clear the task's recurrence; passing a `RepetitionRuleInput` object SHALL set or replace the recurrence; omitting `repetitionRule` SHALL leave the existing recurrence unchanged.
-
-#### Scenario: Edit a single field
-- **WHEN** `edit_task` is called with `{id: "abc123", flagged: true}`
-- **THEN** only the `flagged` field is changed; all other fields retain their previous values
-
-#### Scenario: Replace tag set
-- **WHEN** `edit_task` is called with `{id: "abc123", tagIds: ["t1", "t2"]}`
-- **THEN** the task's tags are set to exactly `["t1", "t2"]`, replacing any previously assigned tags
-
-#### Scenario: Clear a date field
-- **WHEN** `edit_task` is called with `{id: "abc123", dueDate: null}`
-- **THEN** the task's due date is cleared
-
-#### Scenario: Non-existent task returns not-found error
-- **WHEN** `edit_task` is called with an ID that does not correspond to any task
-- **THEN** the tool returns a structured not-found error
-
-#### Scenario: Non-existent tag ID returns not-found error
-- **WHEN** `edit_task` is called with a `tagIds` array containing an ID that does not correspond to any tag
-- **THEN** the tool returns a structured not-found error and the task is not modified
-
-#### Scenario: Set repetition via edit
-- **WHEN** `edit_task` is called with `{ id: "t1", repetitionRule: { frequency: "monthly", interval: 1, method: "dueDate" } }`
-- **THEN** the task's recurrence is set and all other fields are unchanged
-
-#### Scenario: Clear repetition via edit
-- **WHEN** `edit_task` is called with `{ id: "t1", repetitionRule: null }`
-- **THEN** the task's recurrence is cleared and all other fields are unchanged