feat(claude): update skills to know about closed tickets

.claude/skills/monthly-review/SKILL.md

@@ -138,7 +138,12 @@ the month was about and where the big threads landed, not the day-to-day.
   few plain sentences: what it was, how it progressed across the month's weeks,
   and where it ended the month (landed / merged / still in flight / handed off).
   Merge a theme that appears in several weekly summaries into one month-level
-  thread rather than repeating it per week.
+  thread rather than repeating it per week. To state where a thread ended with
+  confidence, check the backing story note's location in Joplin: a note in the
+  top-level `Work / Story Logs` is still active, one in
+  `Work / Story Logs / Archive / <year>` is finished (the user archives a story
+  log once its work is done). This confirms landed/closed vs still in flight
+  rather than guessing from the weekly prose alone.
 - **Recurring / continuous work** in a tighter list: bug-fixing load, the areas
   that came up repeatedly (specific subsystems), customer/incoming work, MCP/AI,
   security/ISMS, etc. Mirror the "Recurring areas" / "Continuous work" split in
@@ -172,7 +177,10 @@ month. Cover these three lenses (and only these unless the user asks for more):
      or recurring-story lists and never closed within the month.
    - Repeated rework: rebases of the same big branch, repeated rounds of fixing
      the same failing tests or de-flaking the same suite (e.g. Cypress).
-   - Threads that opened early in the month and were still open at month end.
+   - Threads that opened early in the month and were still open at month end. A
+     thread is genuinely still open if its backing story note is still in the
+     top-level `Work / Story Logs`; if the note has moved to an archive
+     subnotebook it closed within the month, so do not list it as stuck.
    - These are candidates the user may want to push to close or escalate.
 
 3. **Long weeks (only).**

.claude/skills/weekly-review/SKILL.md

@@ -96,8 +96,15 @@ described there.
   week, look for its backing note in `Work / Story Logs` (and
   `Work / Story Logs / Archive / <year>`): list the notebook and/or
   `find_notes("<ticket-number> <few title words>")`, and match by ticket number.
-  Build a map of `ticket -> note_id` for every story that has a note. Read the
-  ones with real content. Note titles follow `PBI <num>: <title>` /
+  Build a map of `ticket -> note_id` for every story that has a note, and record
+  **where** the note lives, because location signals whether the ticket is
+  finished:
+  - A note in the **top-level `Work / Story Logs`** notebook is an **active**
+    ticket: still in flight, not finished.
+  - A note in an **archive** subnotebook (`Work / Story Logs / Archive / <year>`)
+    is a **finished** ticket: the user archives a story log once its work is done.
+
+  Read the ones with real content. Note titles follow `PBI <num>: <title>` /
   `Bug <num>: <title>`, or a descriptive title for research notes
   (e.g. "Recticel profiling research"). Many notes are near-empty section
   templates; link them but do not mine them for narrative.
@@ -129,7 +136,11 @@ Then write the Summary:
 - For each significant theme, write a few plain sentences on what happened that
   week and where it landed. Convey the gist, not the precise detail (no exact
   percentages, config values, or internal symbol names; the story-log note holds
-  those). Someone reading it should know what the week was about.
+  those). Someone reading it should know what the week was about. Use the story
+  note's location (from step 2) to say whether the ticket finished: a ticket
+  whose note has moved to an archive subnotebook is done (say it landed / merged
+  / closed); one whose note is still in the top-level `Story Logs` is still
+  active, so do not imply it is finished.
 - Call out the shape of the week where it is real: a dominant feature, a heavy
   bug-fixing stretch, lots of context switching, an interruption (incoming
   requests, customer work like Recticel), or a spike/research day.
@@ -199,7 +210,10 @@ Carry-over is the point of this section. Include:
   in the previous week(s) and are clearly still in flight (still being reviewed,
   rebased, "respond to comments", failing tests, etc.). Use judgement from the
   `Note` column; do not flag a story as carry-over just because the number
-  recurs.
+  recurs. The story note's location corroborates this: a note still in the
+  top-level `Story Logs` confirms the ticket is active and a real carry-over
+  candidate, while one already moved to an archive subnotebook is finished and
+  should not be listed as a loose end.
 - **Still-open todos** from the previous week note that were never checked off
   and are still relevant.