Index plans and evaluations by lifecycle (V-674)

docs/plans/16-ambient-calendar.md

@@ -1,6 +1,6 @@
 # Plan: What the ambient calendar path should be
 
-**The decision Vikunja #432 asked for. Written 04-08-2026.**
+**The decision V-432 asked for. Written 04-08-2026.**
 
 **Verdict: keep the endpoint, change the contract.** The relay app sends structured
 fields, not a notification blob. The free-text parser stays as the degraded path, because
@@ -9,7 +9,7 @@ if the answer to the one open question below is no.
 
 ## First, the task's premise is out of date
 
-#432 states as confirmed that every ambient event lands on the day the notification was
+V-432 states as confirmed that every ambient event lands on the day the notification was
 posted, because there is no date parsing at all. That was true when the task was filed
 and it is not true now.
 
@@ -17,7 +17,7 @@ and it is not true now.
 "завтра в 15:00" now dates to tomorrow. The same commit added `ambientPastGrace`, which
 refuses an event landing more than two hours before the notification, on the reasoning
 that the day was inferred and a stale inference is wrong rather than late. `45a5e37`
-(#482, this week) fixed a second dating bug the task did not know about: the wall clock
+(V-482, this week) fixed a second dating bug the task did not know about: the wall clock
 was resolved against the notification's own zone, so every ambient meeting on a non-UTC
 box landed off by the deploy's UTC offset.
 
@@ -38,7 +38,7 @@ Everything follows from this and nothing in this repo can answer it.
 A `NotificationListenerService` sees a title and a body. It cannot know a meeting's real
 start, end or organiser, because those are not in the notification. So if the relay is
 limited to the notification stream, free-text parsing on this side is not a choice, it is
-the only thing available, and #432's suggestion that the phone send structured JSON
+the only thing available, and V-432's suggestion that the phone send structured JSON
 cannot be honoured.
 
 If the app may instead read `CalendarContract`, it has the actual event rows, and the
@@ -73,7 +73,7 @@ closes this without code, and it is his to give.
 
 ## What not to do
 
-Do not add date parsing to the free-text path yet. That is the patch #432 explicitly
+Do not add date parsing to the free-text path yet. That is the patch V-432 explicitly
 refuses to accept as closure, and it is the wrong order: if the relay can send a date, no
 date parser is needed, and if it cannot, the parser is guessing at a date from text that
 was never meant to carry one.