@aitne-sh/aitne 0.1.7 → 0.1.8

package/agent-assets/task-flows/routine.roadmap_refresh.md

@@ -63,11 +63,19 @@ coordinates the high-level gather → analyze → write loop.
    log one line to `## Agent Log`, drop that provider's events for this
    run, and proceed — do not retry inline.
 
+   **Cover the full 90-day window with equal priority.** The live
+   calendar poller only watches the next ~15 days, so any event the
+   user scheduled farther out reaches `roadmap.md` *exclusively*
+   through this routine — under-coverage of the day+15 → day+90
+   horizon is the primary failure mode this refresh is designed to
+   prevent. Read every day of the block (including empty days, which
+   render as `- (no events)`), not just this week.
+
 2. Fetch pending and running scheduled tasks:
    ```
    curl -s 'http://localhost:8321/api/schedule?status=pending,running&roadmapEligible=true'
    ```
-   The response is `{ items: [{ id, scheduledFor, taskType, description, status, model, taskContext, createdAt }, ...] }`.
+   The response is `{ items: [{ id, scheduledFor, taskType, description, status, model, backendId, tier, taskContext, createdAt }, ...] }`. `model` is a registered id verbatim (`claude-opus-4-7`, `gpt-5.4`, …) paired with `backendId` when the row pins a specific model; otherwise the pin lives in `tier`.
    The daemon has already applied the roadmap visibility filter:
    `transient` / `low` are excluded, `normal` / unspecified rows are
    included only beyond the 7-day horizon, and `strategic` rows are
@@ -95,9 +103,10 @@ coordinates the high-level gather → analyze → write loop.
    ```
    Use these for the `roadmap` skill's `travel_bookings` cross-check
    when emitting or refining event entries — mark corresponding `[check]`
-   prep lines with `✓` and record the confirmation number in **Agent
-   Notes**. A booking whose `start_date` is ≥ 48h out without a matching
-   calendar event is itself a trigger for a new event entry.
+   prep lines as `completed` Preparation Timeline rows and record the
+   confirmation number in **Agent Notes**. A booking whose `start_date`
+   is ≥ 48h out without a matching calendar event is itself a trigger
+   for a new event entry.
 
 5. Scan `<recent_dm_conversation_log days="7">` for long-horizon user
    intent that has not yet landed anywhere (e.g. *"going to LA next
@@ -127,8 +136,14 @@ coordinates the high-level gather → analyze → write loop.
 
 4. Build `## Agent Action Plan` by **merge-by-id**, not wholesale
    anonymous regeneration.
-   1. For each significant calendar event or booking in the next 90
-      days, compute the intended roadmap ID. Prefer:
+   1. For each dated calendar event or booking in the next 90 days
+      that the `roadmap` skill's decision tree routes to Agent Action
+      Plan (specific date >48h out), compute the intended roadmap ID.
+      Apply the noise filter (see `### Important` below) conservatively
+      — events more than 30 days out **default to include**: at that
+      horizon they are almost always deliberate user signals, and
+      absence from the existing roadmap means creation, not noise.
+      Prefer:
       explicit `roadmap_entry_id` / `payload.roadmap_entry_id` from a
       queued observation; else an existing AAP entry with the same ID;
       else an existing Long-term Plan candidate matched conservatively
@@ -136,7 +151,7 @@ coordinates the high-level gather → analyze → write loop.
       matching only during migration; else mint a fresh ID via
       `POST /api/context/roadmap/id` using the Source/creation date.
    2. If an existing AAP entry has this ID, merge: keep every
-      `✓ completed ...` Preparation Timeline row byte-for-byte; re-emit
+      `completed ...` Preparation Timeline row byte-for-byte; re-emit
       non-completed taxonomy rows only for gaps by lead-time offset.
       Never drop a completed row.
    3. If no existing entry has this ID, emit a fresh entry with the ID
@@ -160,7 +175,7 @@ coordinates the high-level gather → analyze → write loop.
    ```
    ### Scheduled: <description>  (task #<id>)  <!-- id: rm-YYYYMMDD-abcdef -->
    Source: scheduled.task — wake-up YYYY-MM-DD HH:MM
-   Status: ⏳ pending   (or ▶ running / ✓ completed / ✗ failed)
+   Status: pending   (or running / completed / failed)
    ```
 
    Keep `Scheduled:` entries and event entries interleaved in
@@ -197,7 +212,28 @@ coordinates the high-level gather → analyze → write loop.
    a day ago).
 
 ### Phase 3: Write
-9. Always write the full roadmap via PUT, even when no substantive
+9. **Long-horizon coverage check (pre-PUT audit).** Before issuing the
+   PUT in step 10, walk every event in `<calendar_events_90d>` whose
+   start is between today+7d and today+90d and whose summary is
+   non-empty (skip `- (no events)` filler lines). Each such event must
+   end in exactly one of:
+   - represented in `## Agent Action Plan` (event entry or promotion
+     from `## Long-term Plans`), or
+   - represented in `## Long-term Plans` with a concrete horizon-tag
+     (when the calendar date is itself tentative and DM intent is the
+     stronger signal), or
+   - explicitly logged to `## Agent Log` with a one-line reason for
+     exclusion (e.g. `excluded: recurring weekly 1:1 — handled by
+     today.md`).
+
+   Silent drops are the failure mode this gate exists to surface. If
+   any event lacks one of the three resolutions, add the missing entry
+   or log line before proceeding to step 10. An audit with zero log
+   lines is fine when every event mapped cleanly into AAP / Long-term
+   Plans; a missed long-horizon trip / deadline / conference is the
+   specific regression this check is designed to prevent.
+
+10. Always write the full roadmap via PUT, even when no substantive
    changes were warranted. Update `> Last synced` to today's date on
    every run so the mtime advances deterministically. If
    `<roadmap_write_lock_id>` is in context, include it as the
@@ -235,7 +271,7 @@ coordinates the high-level gather → analyze → write loop.
 
    **Preparation Timeline:**
    - YYYY-MM-DD [tag]: Action description
-   - ✓ completed YYYY-MM-DD: YYYY-MM-DD [tag]: Completed action
+   - completed YYYY-MM-DD: YYYY-MM-DD [tag]: Completed action
    - ...
 
    **Agent Notes:**
@@ -243,17 +279,17 @@ coordinates the high-level gather → analyze → write loop.
 
    ### Scheduled: <description>  (task #<id>)  <!-- id: rm-YYYYMMDD-abcdef -->
    Source: scheduled.task — wake-up YYYY-MM-DD HH:MM
-   Status: ⏳ pending
+   Status: pending
 
    ## Recurring
    (preserved verbatim from existing)
    ```
 
-10. If the PUT returns 400 from the roadmap transition guard (for
+11. If the PUT returns 400 from the roadmap transition guard (for
     example, a completed row was dropped), recover once:
     1. Re-GET `/api/context/roadmap`.
     2. Re-run the merge using the current body as authoritative,
-       preserving every `✓ completed ...` row byte-for-byte.
+       preserving every `completed ...` row byte-for-byte.
     3. retry the full PUT once with the same lock id.
     4. If the second write also returns 400, do not write the regenerated
        Agent Action Plan. Instead, PUT a minimal update that only bumps
@@ -267,5 +303,14 @@ coordinates the high-level gather → analyze → write loop.
   write a minimal roadmap preserving existing goals / Long-term Plans /
   Recurring with an empty `## Agent Action Plan`. Always bump
   `> Last synced`.
-- Keep roadmap.md concise — only include events that benefit from advance preparation.
-  Skip routine daily meetings, standups, 1-on-1s, etc.
+- Keep roadmap.md concise — but apply the inclusion bar **asymmetrically by
+  horizon**:
+  - **within today+14d**: only include events that benefit from advance
+    preparation; skip routine standups, 1:1s, daily meetings.
+  - **beyond today+14d**: default to **include** every dated, non-recurring
+    calendar event with a real summary. At that horizon entries are almost
+    always deliberate user signals, and a missed long-horizon trip /
+    deadline / conference is the failure mode this refresh exists to
+    prevent.
+  Recurring-series instances always belong in `## Recurring`, never in
+  `## Agent Action Plan`, regardless of horizon.

package/agent-assets/task-flows/routine.user_profile_sweep.md

@@ -29,12 +29,12 @@ Do not guess at the bounds.
 
 ### Step 2 — Extract fact candidates
 
-Scan the window using the trigger shapes in the **user-profile**
-skill's "When to Update" section (identity, explicit preference,
-correction, etc.). For detail-heavy facts the DM-time capture block
-already routes — people, work, expertise, personal, goals — see the
-trigger-shape list in `message.received.dm.md` §"Capture user info"
-for the canonical enumeration. Apply the same routing here.
+Apply the canonical capture-user-info routing below to the agent-day
+DM window (`<agent_day_messages>` + `<agent_day_dm_conversation_log>`).
+This is the same trigger/routing surface the DM handler uses — the
+sweep is the safety net for facts the DM-time capture missed.
+
+{include:_partials/capture-user-info.md}
 
 Focus on persistent facts the user **stated about themselves**. Ignore
 one-off references, speculative inferences, and facts already
@@ -83,9 +83,8 @@ Notification Preferences, Learned Context — plus the five
 Do **not** touch `## Raw Signals` — that section belongs to
 `SignalDetector` only. Tone / style / voice / formality / emoji /
 language preferences do **not** belong in profile.md either — route
-those to the `character` runtime-config field via PATCH
-/api/config/character (see user-profile skill §"Tone / character
-preferences"). Learned
+those per the **user-profile** skill §"Tone / character
+preferences". Learned
 Context has multiple writers (DM handler, this sweep, Evening Review
 Step 3a's Raw Signals graduation); read-before-write and merge, never
 rewrite the whole section to add a single bullet.
@@ -169,7 +168,7 @@ curl -s -X POST http://localhost:8321/api/schedule \
     "time": "<tomorrow ISO8601 with offset>",
     "taskType": "dm_session",
     "description": "profile_interview:<id> — <ask-hint from Pending row>",
-    "model": "sonnet",
+    "tier": "medium",
     "taskContext": {
       "scheduledBy": "user_profile_sweep_fallback",
       "queueId": "<id>",

package/agent-assets/task-flows/routine.weekly_review.md

@@ -16,9 +16,18 @@ a `PUT` full rewrite keep the frontmatter and only refresh `updated:`
 
 Generate the weekly review snapshot for the current ISO week and prepare next-week priorities.
 
+The `## Carry Over to Next Week`, `## Next Week Focus`, and `## Lessons
+for Next Week` sections you write here are not just a snapshot — they
+are lifted into **every** morning_routine of the next ISO week (Mon–Sun)
+via the `<previous_week>` context block. Treat them as load-bearing
+input to next week's daily planning, not as an artifact the user reads
+once. Full design: `docs/design/appendices/weekly-next-week-leverage.md`.
+
 This routine produces **two separate artifacts** with strict audience boundaries:
-  - **User-facing**: `weekly/YYYY-Www.md` + (optionally) a short notification.
-    Only real user outcomes and next-week focus. No agent mechanics.
+  - **User-facing**: `weekly/YYYY-Www.md` + a short Friday-evening
+    notification (default send; narrow silence gate in Phase 4a).
+    Only real user outcomes — no agent mechanics, no fabricated
+    positivity. Tone: brief, warm, weekend-close.
   - **Agent-internal**: `agent/journal.md` (append). Self-reflection, filter
     quality, system improvement ideas, failed scheduled actions, pipeline
     observations. **Never** surfaced to the user via notify.
@@ -29,32 +38,49 @@ workflow; the skill owns the file contract.
 ### Phase 1: Gather the week
 1. Determine the target file name from <current_time>:
    `weekly/YYYY-Www.md` (ISO week in the daemon timezone).
-2. Read the past-7-day calendar retrospective. The pre-pass fetcher
-   session (`routine.fetch_window`) ran ahead of you and posted
-   observations for the `cal_past_7d` window for every active calendar
-   integration (Google + Outlook). The `<fetch_report>` block in your
-   prompt tells you the pre-pass status — `success` / `partial` means
-   the table is fresh; `failed` / `skipped` means trust nothing newer
-   than the prior tick and treat the retrospective as best-effort. The
-   ContextBuilder block `<calendar_events_7d>` already covers the
-   forward-looking next-7-days view; this step adds the retrospective
-   complement so the review surfaces what actually happened, not just
-   what's coming next.
-
-   Drain pending past-week observations:
+2. Read the current-ISO-week calendar retrospective. The pre-pass
+   fetcher session (`routine.fetch_window`) ran ahead of you and posted
+   observations for the `cal_iso_week_to_now` window for every active
+   calendar integration (Google + Outlook). That window spans from
+   **Monday 00:00 local** of the current ISO week through **now**, so
+   the retrospective covers exactly the days the archived
+   `daily/YYYY-MM-DD.md` files are keyed on — no rolling drift into
+   last week's tail, and no missing today's events. The
+   `<fetch_report>` block in your prompt tells you the pre-pass
+   status — `success` / `partial` means the table is fresh;
+   `failed` / `skipped` means trust nothing newer than the prior tick
+   and treat the retrospective as best-effort. The ContextBuilder
+   block `<calendar_events_7d>` already covers the forward-looking
+   next-7-days view; this step adds the retrospective complement so the
+   review surfaces what actually happened this week, not just what's
+   coming next.
+
+   Drain pending current-ISO-week observations. The pre-pass posted
+   them just now under `pending=true`, so a single bounded fetch is
+   sufficient — no `observed_at_after` filter needed:
 
    ```
-   GET /api/observations?pending=true&source_prefix=google_calendar:,outlook_calendar:&observed_at_after=<week_start_iso>&limit=200
+   GET /api/observations?pending=true&source_prefix=google_calendar:,outlook_calendar:&limit=200
    ```
 
    Treat each row's `payload.raw` (`title` / `start` / `end` /
    `attendees` / `status`) as authoritative; cross-reference against the
    daily files in step 3 below to disambiguate attended vs cancelled
-   meetings.
-3. Fetch the source days for the current week:
+   meetings. If a row's `payload.raw.start` falls outside the current
+   ISO week (e.g. a stale pending row from an earlier weekly_review
+   that never reached the consume step), ignore it for this synthesis
+   but still let the consume call sweep it so it doesn't bias next
+   week's run.
+3. Fetch the source days for the current ISO week:
    - Use GET /api/context/list/daily to discover archived daily files.
    - Read each `daily/YYYY-MM-DD.md` whose date falls in the current ISO week.
-   - Include <today> as the in-progress final day if it belongs to the same week.
+   - Include <today> as the in-progress final day. On the Friday-evening
+     cron run, the daily archive carries Mon–Thu and `<today>` carries
+     Friday-in-progress; Saturday and Sunday have not happened yet, and
+     the next morning's `morning_routine` will not have archived
+     Friday's daily file yet either. That is the working dataset — do
+     not invent Sat/Sun content; the `## Metrics` and `## Period`
+     fields below describe this honestly.
 4. Use <roadmap>, <active_projects>, and <calendar_events_7d> to understand:
    - which milestones moved this week (cross-reference with Step 2's
      retrospective observations),
@@ -63,12 +89,32 @@ workflow; the skill owns the file contract.
 
 ### Phase 2: Synthesize — split into two buckets
 5. Build TWO separate mental lists before writing anything:
-   a. **User-facing bucket** (goes to `weekly/YYYY-Www.md` and possibly notify):
-      - What meaningful user work moved forward this week?
-      - Which user tasks or commitments slipped or stalled (with the reason
-        the USER cares about — "blocked on Sarah's reply", not "agent skipped
-        reminder")?
-      - What should the user focus on next week?
+   a. **User-facing bucket** (goes to `weekly/YYYY-Www.md` and possibly notify).
+      Synthesize along **three axes**:
+      i.   **Outcomes** — what meaningful user work moved forward this week,
+           and which user tasks / commitments slipped or stalled (with the
+           reason the USER cares about — "blocked on Sarah's reply", not
+           "agent skipped reminder").
+      ii.  **Forward items** — what should the user focus on next week, and
+           which open loops carry forward. Each carry-over needs the
+           one-line reason / blocker that lets the upcoming morning_routine
+           judge whether it is still hot.
+      iii. **Behavioral lessons** — patterns in *how* the user worked this
+           week, distilled into **a concrete forward adjustment** for next
+           week. The format is **observation → next-week action**, not
+           free-floating commentary. Each line must:
+             - Cite evidence from this week's `daily/*.md`,
+               `<yesterday_messages>`, or `<calendar_events_7d>` (not
+               speculation). If the data does not show a pattern, write no
+               lesson — fabrication is forbidden.
+             - End in a **testable, specific action** the user could take
+               next week. "Focus better" is not testable; "Block Tue/Wed
+               9-11 on calendar" is.
+             - Stay user-actionable. Agent-side filter-quality observations
+               belong in the agent-internal bucket (see (b) below), not
+               here.
+           Hard cap: 3 lessons. Two is fine; zero is fine. Padding to three
+           dilutes the signal that downstream morning_routines act on.
    b. **Agent-internal bucket** (goes to `agent/journal.md` only):
       - Scheduled tasks / reminders that did-not-fire or failed, and any
         pattern behind the failures
@@ -95,7 +141,8 @@ workflow; the skill owns the file contract.
    updated: YYYY-MM-DD
    ---
    # Weekly Review YYYY-Www
-   > Period: YYYY-MM-DD to YYYY-MM-DD
+   > ISO week: YYYY-MM-DD (Mon) – YYYY-MM-DD (Sun)
+   > Evaluated through: YYYY-MM-DD HH:MM (Sat/Sun not yet observed)
    > Generated at: YYYY-MM-DD HH:MM
 
    ## Highlights
@@ -112,12 +159,68 @@ workflow; the skill owns the file contract.
    - User tasks carried over: N
    - Key meetings / commitments kept: N
 
-   ## Next Week Priorities
-   - ...
+   ## Carry Over to Next Week
+   - <Open loop A> — <one-line user-meaningful reason / blocker>
+   - <Open loop B> — <one-line user-meaningful reason / blocker>
+
+   ## Next Week Focus
+   - <Top priority 1>
+   - <Top priority 2>
+
+   ## Lessons for Next Week
+   - <observation from this week's data> → <specific next-week action>
+   - <observation> → <specific next-week action>
    ```
    The `## Metrics` section tracks **user** activity only. Do not add rows
    like "agent plan rows completed", "scheduled tasks fired", "observations
    processed" — those are agent mechanics and belong in agent/journal.md.
+
+   **`## Carry Over to Next Week`, `## Next Week Focus`, and `## Lessons
+   for Next Week` are import-targeted sections** — every morning of the
+   next ISO week, `morning_routine` lifts these three sections
+   mechanically from this file via the `<previous_week>` context block
+   (see `routine.morning_routine.md` "Previous-week leverage" step).
+   Treat the contract as load-bearing:
+     - **Carry Over** — max **5** bullets. Each must point at a real
+       `## Open Loops` entry from this same file (not aspirational items),
+       and include a short reason / blocker so next week's morning_routines
+       can decide whether the loop is still hot or has been overtaken by
+       the week's events. If there are no genuine carry-overs, leave the
+       section body empty — the `<previous_week>` renderer surfaces an
+       explicit `(none recorded)` placeholder so next week's morning_routine
+       sees the same "deliberately none" signal it sees for an empty
+       Focus or Lessons section. Do not write `- (none)` (it would be
+       extracted verbatim and clash with the placeholder for the other
+       two sections).
+     - **Next Week Focus** — max **3** bullets, ordered. The "if you only
+       did three things next week" list. Each item should be specific
+       enough that next week's `today.md` priority selection can use it
+       verbatim as a candidate. If next week's focus is unclear from this
+       week's data, write fewer items rather than padding to three.
+     - **Lessons for Next Week** — max **3** bullets, format
+       `<observation> → <specific next-week action>`. Source the
+       observations from Phase 2 (a) (iii) "Behavioral lessons" axis.
+       Examples that conform:
+         - `Tue/Wed deep-work mornings were eaten by ad-hoc meetings → block Tue/Wed 9–11 on calendar`
+         - `Email replies started after 14:00 mostly slid to the next day → handle first wave by 11:00`
+       Examples that violate (do NOT write these):
+         - `Focus more next week` — no observation, no testable action.
+         - `Be more disciplined about email` — no concrete adjustment.
+         - `Agent over-notified on Tuesday` — agent mechanics; belongs in
+           agent/journal.md, never here.
+       Zero lessons is acceptable. Padding is worse than silence — the
+       morning_routine's only job with a fabricated lesson is to ignore it,
+       which trains the loop to ignore real ones too.
+     - All three lists are caps, not quotas. Exceeding any signals
+       over-promising; the morning_routine cannot productively act on a
+       Carry Over longer than 5, a Focus longer than 3, or Lessons longer
+       than 3.
+     - Section headings must match exactly — the digest extractor is
+       header-regex bound. Do not rename, translate, or pluralize.
+     - Body bullets are surfaced to the agent in
+       `<output_language_policy>`'s body language; the H2 headers
+       themselves stay in English per Policy B (skeleton headers fixed,
+       prose follows `<settings primary_language>`).
 8. If the review reveals roadmap drift or stale project status, update
    roadmap.md and the relevant projects/*.md in the same session.
 
@@ -167,62 +270,174 @@ workflow; the skill owns the file contract.
    overwrite the old section in place.
 
 ### Phase 4: Notify (user-facing only)
-10. The notification is for the USER, not a report of Phases 1–3. Never
-    mention weekly/YYYY-Www.md, agent/journal.md, "Weekly Review complete",
-    agent plan rows, did-not-fire, filter quality, observation processing,
-    or any other internal mechanism.
-
-#### 4a. Silence gate — decide whether to notify at all
-Prefer silence over noise. Send **no notification** if ALL of the following
-hold:
-  - Fewer than 2 Highlights worth naming (a quiet week)
-  - No Open Loops the user is not already aware of
-  - No Next Week priority that needs a heads-up tonight (the user will see
-    it in Monday's morning briefing anyway)
-  - No hard deadline within the next 7 days
-When the gate triggers: skip POST /api/notify entirely. The weekly/YYYY-Www.md
-file is still written (user can open it on demand); just no push. Also log
-one line into agent/journal.md's "What worked" subsection:
-`silent weekly wrap-up — nothing actionable`.
+10. The notification is a brief, warm end-of-week touchpoint for the USER
+    — not a report of Phases 1–3. Never mention weekly/YYYY-Www.md,
+    agent/journal.md, "Weekly Review complete", agent plan rows,
+    did-not-fire, filter quality, observation processing, or any other
+    internal mechanism.
+
+    The default posture for this notification is **send**. Friday evening
+    is a natural touchpoint and the user opted into receiving one. Skip
+    only under the narrow silence gate in 4a.
+
+#### 4a. Silence gate — skip only when the week was essentially blank
+Send **no notification** only if ALL of these hold:
+  - Zero daily files in `daily/` were updated this week, AND
+  - No completed user work surfaced in Phase 1 (highlights and completed
+    lists in the weekly file would both be empty)
+In a normal week — even a low-activity one — notify.
+
+When the gate triggers: skip POST /api/notify entirely. The weekly file
+is still written (user can open it on demand). Append one bullet under
+agent/journal.md "What worked": `silent weekly wrap-up — quiet week`.
+
+**Silence-path × leverage loop.** A silent-path week still PUTs the
+full Phase 3a structure. Carry Over / Next Week Focus / Lessons may be
+legitimately empty when the week was blank — leave their bodies empty
+(do **not** write `- (none)` placeholders). Next week's morning_routine
+will see `<carry_over>` / `<focus>` / `<lessons>` rendered as
+`(none recorded)` and skip them silently, which is the correct signal
+that the prior week had nothing to lift.
 
 #### 4b. When you DO notify — content rules
-Output language: follow `<output_language_policy>`. Answer:
-  1. **One concrete win** from this week (1 line).
-  2. **At most one open loop** that carries into next week, with a brief
-     user-meaningful reason. Omit if Open Loops is empty.
-  3. **The single most important focus for next week** (1 line).
-
-Optional 4th line: a hard deadline heads-up if one falls within the next 7
-days and the user has not yet acted on it.
+Output language: follow `<output_language_policy>`. Compose in this order:
+
+  1. **One concrete win from this week** (1 line). Must name an
+     artifact AND either the day it shipped or its concrete current
+     state.
+       ✓ "the design doc shipped Thursday" (artifact + day)
+       ✓ "auth refactor is in review, queued for Monday landing"
+         (artifact + state)
+       ✗ "solid progress on the auth refactor" (no artifact / day /
+         state — would read plausibly in any week)
+     If Phases 1–3 supply no concrete artifact + day/state, the
+     silence gate in 4a should fire — do not pad with generic praise.
+
+  2. **Optional insight line — default is OMIT.** The canonical correct
+     output is **2 lines** (win + weekend close). Include line 2 only
+     when ONE of bar (a) or (b) clears unambiguously.
+
+     a. **Personalized pattern** — a real pattern in **this week's**
+        data. Must (i) cite specific instances (named tasks, calendar
+        entries, daily-file rows), (ii) rest on **≥3 concrete
+        instances** within the week (N=1 anecdotes do not qualify),
+        (iii) be about the user's behavior or outcomes, not external
+        factors.
+        ✓ "Worth noticing — every task you started before 10:00 closed
+          the same day; the four after-lunch starts mostly slid to
+          tomorrow." (two buckets + a count)
+        ✗ "Your mornings seemed more productive than afternoons this
+          week." (vague, no count — true of any week)
+
+     b. **Academic finding** — a well-known finding from psychology,
+        behavioral economics, cognitive science, or productivity
+        research that maps **specifically** to a concrete thing the
+        user did this week. **If you reach for hedge phrasing —
+        "studies suggest…", "research often shows…", "it is said
+        that…" — you are not confident the finding is real; omit.**
+        Match a specific week activity, not a generic proverb.
+        Register: "Worth knowing…" not "You should…" (advice
+        forbidden).
+        ✓ "Worth knowing: deep-work researchers find three consecutive
+          focused days tend to outperform five scattered ones for
+          shipping work like this."
+        ✗ "Worth noticing — small, consistent efforts compound over
+          time." (proverb, no named research area, generic)
+
+     **No-fabrication rule** (both bars):
+       - Numbers, percentages, deltas, week-over-week comparisons must
+         appear **literally in the data**. "30% harder", "doubled
+         throughput", "twice the rate" — forbidden unless real counts
+         you can point at.
+       - Vague intensifiers are padding, not insight: "crushed it",
+         "big momentum", "small efforts compound", etc. **Paste-test**:
+         if line 2 could fit any user's review and still read as
+         plausible, delete it.
+       - **First 2–3 weeks of operation** (few prior `weekly/*.md`):
+         skip line 2 unconditionally — insufficient data for patterns,
+         premature citations erode trust.
+
+  3. **Weekend close** (1 line) — calendar-aware via
+     <calendar_events_7d>:
+     - Non-trivial commitment this weekend (work event, deadline,
+       exam, interview): brief specific encouragement tied to it
+       — e.g. "Good luck with the API review on Saturday."
+     - Something the user looks forward to (trip, celebration, hobby
+       block, social event): brief "enjoy" tied to it — e.g.
+       "Enjoy the trip to Portland."
+     - **Sensitive event categories** — medical / therapy / clinic /
+       legal / financial review / family-conflict titles (mediation,
+       custody, etc.): do NOT name the event. Use the neutral default
+       ("Have a good weekend.") — surfacing a sensitive event
+       unprompted in a Friday recap is intrusive even when the
+       category is right.
+     - Otherwise: a simple weekend close (e.g. "Have a good weekend.").
 
 #### 4c. Format rules (hard limits)
-  - Maximum 4 short lines total. No markdown headers. No bullet list.
+  - 2 or 3 lines for the Phase 4 message (3 only if line 2 genuinely
+    earns its place). Phase 5 may add at most one additional reading
+    line via a separate POST under its own contract — that is the only
+    way the total reaches 4 lines. No markdown headers. No bullet
+    list. Plain prose.
   - Lead with the win, not with "Weekly Review" or any ceremony.
   - Forbidden vocabulary in the user-facing message: "Weekly Review",
-    "weekly/", "agent-journal", "did-not-fire", "Agent Plan", "observations",
-    "processed", "summary", "completed the review". These describe agent
-    mechanics, not user outcomes. The same rule applies in whatever
-    language the user prefers — do not paste an equivalent meta-phrase.
+    "weekly/", "agent-journal", "did-not-fire", "Agent Plan",
+    "observations", "processed", "summary", "completed the review".
+    These describe agent mechanics, not user outcomes. The same rule
+    applies in whatever language `<output_language_policy>` resolves
+    to — do not paste an equivalent meta-phrase.
   - Priority `normal`. Respects quiet hours via the notify skill contract.
   - Exactly ONE notification via POST /api/notify. Do not split.
 
-#### 4d. Shape example (illustrative — render in the language `<output_language_policy>` resolves to)
-Good (something worth saying):
-    Big win this week: the design doc shipped Thursday.
-    Still open: the API spec review — Sarah back Monday.
-    Next week's focus: auth refactor landing before the Q2 deadline.
+#### 4d. Shape examples (illustrative — render in the language `<output_language_policy>` resolves to)
 
-Good (silent path — nothing is sent):
+Good (3 lines — the insight is grounded in the week's data):
+    Big win this week: the design doc shipped Thursday.
+    Worth noticing — every task you started before 10:00 closed the
+    same day; the after-lunch starts mostly slid to tomorrow.
+    Good luck with the API review on Saturday.
+
+Good (3 lines — the insight is a genuinely relevant academic tip):
+    You wrapped the auth refactor before the Q2 deadline — solid week.
+    Worth knowing: deep-work researchers find three consecutive focused
+    days tend to outperform five scattered ones for shipping work like
+    this.
+    Have a great weekend.
+
+Good (2 lines — nothing earned the insight slot, so it's correctly
+omitted):
+    The migration to the new schema landed Wednesday.
+    Enjoy the trip to Portland.
+
+Good (silent path — quiet week, nothing sent):
     (no POST /api/notify call; one-line note appended to agent/journal.md)
 
-Bad (this is the failure mode this prompt exists to prevent):
+Bad (fabricated positivity — the failure mode the strict rule prevents):
+    Big win: design doc shipped Thursday.
+    You worked 30% harder than last week — keep it up!
+    Have a great weekend!
+
+Bad (agent mechanics leaking):
     Weekly Review YYYY-Www complete. Wrote weekly/2026-W14.md with
     5 highlights, 3 open loops. Metrics: user tasks 7/10, agent plan
-    rows 24, did-not-fire 2. Observations processed: 18. Next week
-    priorities updated in roadmap.md.
-
-The bad example reports the agent's bookkeeping. Everything in it either
-belongs in agent/journal.md or was never worth telling the user.
+    rows 24, did-not-fire 2. ...
+
+Bad (subtle padding — proverb-shaped insight that fails the line-2 bar):
+    Solid progress on the auth refactor this week.
+    Worth noticing — small, consistent efforts often compound into
+    real momentum over time.
+    Have a good weekend.
+
+The first bad example invented "30% harder" — there is no such measurement
+in Phase 1. If you did not derive it from real data, do not write it.
+The second bad example reports the agent's bookkeeping; everything in it
+either belongs in agent/journal.md or was never worth telling the user.
+The third bad example is the most common failure mode the 4b bars
+prevent: a generic line 1 (no artifact, would read in any week) paired
+with a proverb-shaped line 2 (no named research area). Correct output
+for this scenario is a 2-line message with concrete artifact + state —
+e.g. "Auth refactor PR is open and queued for Monday review." — or, if
+even that does not exist, the silence gate in 4a should fire.
 
 ### Phase 5: Reading sweep (silent context update)