docs: close item 206, the calendar windowcalendar

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

1 files changed, 1 insertions, 37 deletions

diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
index 84df4e6..ed7afac 100644
--- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
+++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md
@@ -143,7 +143,7 @@ taking that too literally.
 | 72 | No khard/khal integration | workflow | ? | **split 2026-09-18** into 204 (recipient completion), 205 (contact editing), 206 (calendar window) and 207 (invitations), after the user named what they want. Nothing is planned under this number any more; it stays as the index entry the notes' single line maps to. The edge-tts reminder half is out of scope: its own project |
 | 204 | No recipient completion, in the composer or the query bar | workflow | S | **done** 2026-09-24, shipped, built via subagent-driven-development, `3303c78..7454096`. `ContactStore` over the vdirsyncer vCard 3.0 directory feeds one shared `QCompleter` for the composer's To/Cc/Bcc and the query bar's `from:`/`to:`. Hand-tested and confirmed. One review fix (control-character/RFC 5322 sanitisation of `FN`) landed and was re-reviewed clean. Section in the closed file |
 | 205 | Contacts can be read but not edited from the app | workflow | M | open, 2026-09-18, from 72's split, **asked for by the user** while settling 204. Writing a vdir, so it shares the write-during-sync question with 206 and the fold/escape rules with 204's parser. Its write-during-sync question is answered by 206's spec, § Writing: the same writer and stale check serve a vCard. Needs a brainstorm of its own |
-| 206 | No calendar: events cannot be viewed, added or edited | workflow | L | open, **built on branch calendar** 2026-09-24, awaiting hand test; spec specs/2026-09-24-calendar-design.md, plan plans/2026-09-24-calendar.md |
+| 206 | No calendar: events cannot be viewed, added or edited | workflow | L | **done** 2026-09-29, shipped in 0.30.0, built via subagent-driven-development on branch calendar and merged. Month and Agenda views, a side pane that edits, undoable create/edit/delete over the vdirsyncer vdir. Hand-tested and confirmed; three hand-test fixes (cell colour flood, pane hidden while empty, Escape closes it). Writing a `VALARM` from the edit form was raised and deferred by the user. Section in the closed file |
 | 207 | An invitation cannot be accepted, refused or sent | workflow | M | open, 2026-09-18, from 72's split, **asked for by the user**: "as it is today I don't have a way of accepting an invitation." `text/calendar` in the pane, an iMIP reply through the existing `send_command`. **Blocked on 206**, which owns the calendar it writes to |
 | 208 | No way to add a new correspondent to the contacts | workflow | ? | open, 2026-09-18, **asked for by the user** while settling 204: an "add to contacts" button on mail from someone not in the store. Writes a vcard, so it lands on 205's writer rather than 204's reader. **Needs a brainstorm when picked up** |
 | 209 | The calendar has no Week view | presentation | M | open, from 206's brainstorm. The occurrence list is the seam: a new painter over CalendarItem, no store change |
@@ -1642,42 +1642,6 @@ rather than inventing a second mechanism. Decide it once, for both items.
 the composer's completion, a contacts window, or inside 206's window), and
 whether it manages collections at all or only cards.
 
-## 206. No calendar: events cannot be viewed, added or edited
-
-**Observed (user, 2026-09-18, in place of the notes' khal line):** "I'd prefer
-to be able to work on my calendar from inside qtmaildir. I'm talking view, add,
-remove, edit events, accept/refuse invitations, send invites to events, etc."
-
-**Two things are already settled by the user** and are not to be re-opened in
-the brainstorm: the calendar is **its own top-level window**, like
-`ComposeWindow`, not a third pane in the main one; and the iCalendar work uses
-**libical**, not a hand-rolled parse.
-
-**The dependency is present and easy, unlike notmuch.** libical 3.0.20 with
-headers in `/usr/include/libical/` and a `libical.pc`, so this one IS
-`pkg_check_modules`. It is the same C-handles-in-C++ shape `nmraii.h` already
-solves for notmuch, and the same rule applies: RAII aliases, and no libical
-pointer crossing a thread boundary.
-
-**The data is on disk and verified, 2026-09-18.** 312 `.ics` files across three
-collections under `~/.local/share/calendars/`, the `calendars` pair's local
-half. A vdir is plain files, so a write is a new file that vdirsyncer pushes on
-its next run; no daemon and no protocol work, which keeps the no-network rule
-intact exactly as `send_command` does for mail.
-
-**Why L rather than M.** This is a second application inside this one: a month
-or week or agenda VIEW is real UI with no existing counterpart here, recurrence
-(`RRULE`, `EXDATE`, and the expansion of an infinite series into a visible
-window) is where a naive implementation dies, and timezones are `VTIMEZONE`
-rather than the `QDateTime` habits the rest of the tree has. Compose-and-send
-(item 123) is the scale precedent: a spec, a branch and a plan of many tasks,
-not a backlog item picked up on a Tuesday.
-
-**Config.** A calendar path key, and which collection is the default to WRITE
-to, since there are three and nothing in the files names a preference.
-
-**Shares the write-during-sync question with 205.** Answer it once.
-
 ## 207. An invitation cannot be accepted, refused or sent
 
 **Observed (user, 2026-09-18):** "as it is today I don't have a way of accepting