diff --git a/SPEC.md b/SPEC.md
index 96cc66d..1be75ee 100644
--- a/SPEC.md
+++ b/SPEC.md
@@ -177,4 +177,39 @@ Upstream is a single synchronous markdown-it content script with no data API acc
 
 ## 8. Licensing & Attribution
 
-Upstream is MIT (© Franco Speziali / WeMakeMachines). The fork retains the MIT license, preserves the original copyright notice, and credits upstream in the README per standard practice.
\ No newline at end of file
+Upstream is MIT (© Franco Speziali / WeMakeMachines). The fork retains the MIT license, preserves the original copyright notice, and credits upstream in the README per standard practice.
+---
+
+## 9. Roadmap (post-1.0 / post-launch)
+
+Recorded direction, not commitments. Each gets a focused design pass before work begins; real-world use of the shipped plugin may reorder this.
+
+### v0.2.0 — Repeating to-dos (visualisation) + configurable strip horizon
+
+Recurrence itself is delegated to an existing community plugin (open-environment approach; we don't reimplement it). Candidates evaluated: BeatLink's original *Repeating To-Dos* (unmaintained), the *[Revived]* fork (maintained, GitHub issues only), and *Repeating To-dos v2* by TheScriptingGuy (`com.github.TheScriptingGuy.joplin-plugin-repeating-todos`, best-documented). All share the same mechanic: on completion the to-do's alarm date is reset to the next occurrence and the to-do is unmarked — so at any moment a recurring to-do is a **single** to-do at its next due date, with the recurrence rule stored in the note body.
+
+- **Option A (chosen for 0.2.0):** detect the recurrence marker in the body and tag those events with a ↻ glyph. No series projection — the to-do shows at its next due date like any dated to-do. Minimal, robust, no hard coupling to another plugin's body format.
+- **Option B (in pocket):** parse the recurrence rule and project all future occurrences across the visible window. Deferred because the body format has proven to be a moving target across forks; promote to a 0.2.x only if Option A's single-occurrence view proves insufficient, and target a specific fork's format at that time.
+- **README:** recommend the maintained fork (v2 first, Revived as fallback); warn about the known "recurrence block injected into all notes" failure mode; note coexistence (their plugin moves the anchor, ours draws the marker).
+
+**Configurable strip horizon.** `day`/`week`/`month` strip views currently span first-event to last-event (plus today). Add a horizon option to `gtd-calendar` (working name `weeks:` or `horizon:`, default ~8 weeks forward) controlling how far ahead the strip extends — relevant both generally and for how many future occurrences Option B would draw. **`month-grid` is explicitly excluded**: it always shows the entire current calendar month, by design, and that is not configurable.
+
+*Note: multiple `gtd-calendar` blocks in one note already work as of 0.1.0 (each fence renders independently) — e.g. a "week ahead" strip plus a "month grid" in a single dashboard note. No work required; document as a recommended pattern.*
+
+### v0.3.0 — Kanban beneath the calendar (read-only)
+
+- **To-dos only** (notes excluded).
+- **Three columns, tag-driven:** an `in-progress` tag → *In Progress*; `todo_completed > 0` → *Done*; neither → *Backlog*.
+- Same architecture as the calendar: plugin queries to-dos + tags, buckets them, webview renders columns, chips drill down to notes.
+- Read-only: reflects state, does not change it. Cheap way to prove the columns and bucketing before adding write-back.
+
+### v0.4.0 — Drag-and-drop kanban (write-back)
+
+The first feature that makes the plugin a **controller** of data rather than a viewer — warrants its own design pass.
+
+- Dragging a card writes back to Joplin via the existing webview→plugin channel:
+  - → *In Progress*: add the `in-progress` tag (create the tag if absent; resolve its id; associate).
+  - → *Done*: set `todo_completed`.
+  - → *Backlog*: remove the tag / clear completion.
+- **Open design questions for that pass:** optimistic UI vs. wait-for-confirmation; behaviour on write failure; whether drops need undo; re-query/refresh of kanban and any affected calendars after a successful write; the trust implications of a rendered view mutating other notes.
+- Feasibility: confirmed possible (we already execute `openNote` from the webview; data writes use the same channel with more responsibility). Complexity lives in tag management and the write/refresh cycle, not the dragging.