@aitne-sh/aitne 0.1.9 → 0.1.11

package/agent-assets/task-flows/message.received.dm_first.md

@@ -12,6 +12,10 @@ Apply the canonical capture-user-info routing below to `<user_input>`.
 
 {include:_partials/capture-user-info.md}
 
+Apply the canonical feedback-capture routing below to `<user_input>`.
+
+{include:_partials/feedback-capture.md}
+
 ### Step 2 — Profile-question reconcile / latent opportunity
 
 Two operations from the user-interview skill — run in order, before composing the reply.
@@ -67,7 +71,7 @@ If the preview clears all three gates, surface 1–2 tasks:
 
 #### Resolved User Tasks
 
-When the user reports completing one of their tasks, mark it `[x]` per the today / context skill. Do NOT modify Agent Plan rows from this handler — those flip in `scheduled.task` handlers and Evening Review only.
+When the user reports completing one of their tasks, mark it `[x]` per the today / context skill. Do NOT flip Agent Plan rows for execution outcomes — those flip at fire time in `scheduled.task` / `scheduled.dm` handlers. If the user's message invalidates a pending planned action, apply the today skill's "Agent Plan revision — cancel / amend" recipe. Unambiguous match only.
 
 #### Agent Plan is private — never surface as task status
 
@@ -76,7 +80,7 @@ Agent Plan rows in <today> are the agent's own pending actions, not user tasks.
 - Never frame an Agent Plan row as a user task ("your 9am task", "pending task", "still incomplete", "did-not-fire") — in any language.
 - Never quote the row's HH:MM, its action text, a task ID, or internal labels.
 - If a past-due `[ ]` row's content is a reminder relevant to the current DM, deliver the question as natural prose — no preamble.
-- Delivering a row's content does NOT execute it; the DM handler never flips Agent Plan rows.
+- Delivering a row's content does NOT execute it; execution-outcome flips happen only at fire time.
 
 Bad — exposes the row as a task with internal identifiers:
 
@@ -136,6 +140,8 @@ affirmative.
 
 Schedules go through this daemon — never through any cloud-hosted scheduled-agent feature your CLI may expose. Cloud routines cannot reach `localhost:8321`, so they cannot deliver via the user's chat platforms or use any integration registered here.
 
+**Background task** (a single long-running / open-ended job the user wants done while they keep chatting — deep research, a multi-repo / multi-file audit, "monitor X over time", a bulk compile) → hand it to the detached runner via the `background-task` skill. Resolve scope *this turn*, compose a self-contained brief (objective, inputs, output language, notification policy + concrete `if_significant` criteria), POST, ack in one line, and **end the turn** — never poll; the daemon delivers the result in your voice when it's done. Keep a plausibly-quick lookup inline, but if one you started inline balloons, promote it — fold the work already done into the brief so the worker continues rather than restarting, then POST + ack + end the turn. A recurring cadence is the Scheduling arm above (`agent-create`); an open-ended *browser* job is the `browser-task` skill.
+
 **Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → apply the decision tree below; the `roadmap` skill is the writer. Ambiguous or speculative items belong in `journal/agent.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `plans/roadmap.md` without a clear positive signal.
 
 {include:_partials/dm-intent.long-horizon.md}

package/agent-assets/task-flows/{routine.hourly_check.md → routine.activity_scan.md}

@@ -1,18 +1,18 @@
 {context}
 
-## Hourly Observation Review
+## Activity Scan — Observation Review
 
-This task-flow is the **daemon-internal** hourly cron — a built-in
-observation review the dispatcher fires every hour. It is NOT the
-user-facing recurring path. An operator who wants a custom recurring
-task creates a recurring **Agent** (`POST /api/agents`, e.g. an hourly
-cron `0 * * * *`); those fire `scheduled.task` / `scheduled.dm` events
-instead.
+This task-flow is the **daemon-internal** activity-scan cron — a built-in
+observation review the dispatcher fires every interval (default: every
+2 hours) within active hours. It is NOT the user-facing recurring path.
+An operator who wants a custom recurring task creates a recurring
+**Agent** (`POST /api/agents`, e.g. an hourly cron `0 * * * *`); those
+fire `scheduled.task` / `scheduled.dm` events instead.
 
 The "Vault policy files" block appended to this prompt includes
-`policies/routines/hourly.md` — your canonical check list for this cadence.
+`policies/routines/activity-scan.md` — your canonical check list for this cadence.
 The "Vault review context" block includes `context-index.md` and
-`knowledge/dossiers/hourly.md`; consult it before Step 1 and update the dossier's
+`knowledge/dossiers/activity-scan.md`; consult it before Step 1 and update the dossier's
 Open items / Last run before finishing. Writes to `knowledge/dossiers/<flow>.md`
 MUST preserve the existing YAML frontmatter block (`---\ntype: dossier\nowner: agent\nupdated: <date>\n---`); prefer `PATCH` with a
 section target to mutate a single block, and when doing a `PUT` full
@@ -45,7 +45,7 @@ only want the user-actor surface (e.g. early triage). Follow the
 context skill for today.md section formats and the day-type filter
 mapping — this prompt owns the decision workflow only. Most runs should
 do bookkeeping silently; only fire POST /api/notify on the urgency gate
-in Step 8 below.
+in Step 9 below.
 
 ### Step 0 — Read pre-pass `<fetch_report>`
 
@@ -108,33 +108,34 @@ observedAt) fall back to the legacy fetch-on-doubt rules in the
 observations skill.
 
 ### Default stance — silence + idempotence
-Most hourly runs are silent bookkeeping: consume observations, update
+Most scan runs are silent bookkeeping: consume observations, update
 today.md, log, done. The baseline assumption for every step below is
 that the user does NOT want another notification and does NOT want a
 new Agent Plan row unless this run has something genuinely new to add.
 The morning routine is authoritative for the day's plan; your job is
-to fold in new signals, not to re-plan. Two hard rules:
+to fold in new signals — adding rows and retiring invalidated ones
+(Step 5) — not to re-plan the day. Two hard rules:
 
 - **No duplicate Agent Plan rows / schedules.** Before appending to
   `## Agent Plan` or calling `POST /api/schedule`, run the dedup
   pre-check in Step 4. If a matching row/schedule already exists,
   skip and log — never add a second one.
 - **No duplicate notifications.** Before `POST /api/notify`, run the
-  dedup pre-check in Step 8. If the same item was already notified
+  dedup pre-check in Step 9. If the same item was already notified
   earlier today, stay silent and log.
 
 When in doubt, stay silent and log to `## Agent Log`.
 
-### External services are read-only this hour
+### External services are read-only during this run
 
-This routine reads external state for context — it does not push back. While running this hourly check, do **not**:
+This routine reads external state for context — it does not push back. While running this activity scan, do **not**:
 
 - Create / update / archive Notion pages or change Notion schema.
 - Send / draft / move / tag mail.
 - Create / update / delete calendar events.
 - Open / merge / comment on GitHub PRs or issues.
 
-External-source signals (`mail:*`, `notion:*`, `calendar:*`, `git:*`) reach you through `<observations>`. Consume them, route to `state/today.md` / `projects/*.md` / the `roadmap_candidate` queue per the Decision Framework below, but do **not** act back on the source system. Outbound writes against external services belong in the morning routine, evening review, or DM-reply paths — `routine.hourly_check` is a silent bookkeeping pass.
+External-source signals (`mail:*`, `notion:*`, `calendar:*`, `git:*`) reach you through `<observations>`. Consume them, route to `state/today.md` / `projects/*.md` / the `roadmap_candidate` queue per the Decision Framework below, but do **not** act back on the source system. Outbound writes against external services belong in the morning routine, evening review, or DM-reply paths — `routine.activity_scan` is a silent bookkeeping pass.
 
 This rule applies regardless of integration mode (direct, same-backend delegated, cross-backend delegated). It is owned by the routine, so a session whose `notion` / `mail` / `external-services` skill body was dropped under same-backend delegation (because the connector covers the surface) still inherits the constraint.
 
@@ -170,15 +171,22 @@ This rule applies regardless of integration mode (direct, same-backend delegated
      and schedule entries are always in lock-step (see skill "User Tasks vs
      Agent Plan → The Agent Plan contract").
    - Day-time observation (git push, Notion status change) → append to ## Agent Notes.
-5. Update projects/*.md when the observation materially changes project
-   state. Do NOT write to roadmap.md from hourly — for long-horizon
+5. Retire invalidated rows — the reverse of dedup. When an observation
+   kills the premise behind a pending `## Agent Plan` row or schedule
+   (calendar event cancelled or moved, user already completed the item,
+   source artifact gone), apply the today skill's "Agent Plan revision —
+   cancel / amend" recipe: cancel or re-time the schedule, update the
+   row, log. Subject AND time must match unambiguously; uncertain →
+   leave the row, fire-time guards catch it.
+6. Update projects/*.md when the observation materially changes project
+   state. Do NOT write to roadmap.md from the activity scan — for long-horizon
    signals that don't belong in today.md but aren't yet strong enough
    for direct roadmap edits (e.g. a user edited a vault note mentioning
    a trip "sometime this summer", a far-future calendar event with an
    unclear prep window), **queue them as `roadmap_candidate`
    observations** via POST /api/observations (observations skill). The
    next roadmap_refresh run consumes them and decides routing; this
-   hourly flow intentionally does not load the long-term-plan taxonomy
+   activity-scan flow intentionally does not load the long-term-plan taxonomy
    at all.
    ```
    curl -s -X POST http://localhost:8321/api/observations \
@@ -186,15 +194,15 @@ This rule applies regardless of integration mode (direct, same-backend delegated
      -d '{"source":"roadmap_candidate:<subkind>","ref":"<stable-ref>","changeType":"created","actor":"agent","payload":{...}}'
    ```
    `<subkind>` examples: `travel`, `calendar`, `vault`, `dm`.
-6. Skip noise: journal-only edits, trivial formatting, auto-generated churn,
+7. Skip noise: journal-only edits, trivial formatting, auto-generated churn,
    already-processed agent writes, deletion of auto-generated artifacts.
-7. Mark processed observations consumed via POST /api/observations/consume.
+8. Mark processed observations consumed via POST /api/observations/consume.
    Shape: `{"ids":[<int>...],"correlationId":"<verbatim from <event_correlation_id>>"}`.
    Both fields are required and camelCase — `correlation_id` snake_case is
    rejected. `ids` must be integers (not strings). Copy `correlationId`
    verbatim from the `<event_correlation_id>…</event_correlation_id>` tag
    in this prompt; do not paste the angle-bracket placeholder.
-8. Urgency gate for POST /api/notify — the default is SILENCE. At most
+9. Urgency gate for POST /api/notify — the default is SILENCE. At most
    ONE call per run, and only after the dedup pre-check passes AND one
    of (a)(b)(c) holds with its concrete threshold:
 
@@ -230,6 +238,6 @@ This rule applies regardless of integration mode (direct, same-backend delegated
    queued, observations consumed.
 
    When in doubt, stay silent and log.
-9. Append one line to ## Agent Log even on no-op runs (Agent Log only — do
+10. Append one line to ## Agent Log even on no-op runs (Agent Log only — do
    not echo as final text, do not send via notify):
    `- HH:MM [observations] reviewed N items, added X tasks / Y plan rows, skipped Z`.

package/agent-assets/task-flows/{routine.hourly_check.triage.md → routine.activity_scan.triage.md}

@@ -1,9 +1,9 @@
 {context}
 
-## Hourly Check — Stage 2 Triage
+## Activity Scan — Stage 2 Triage
 
 You are the Stage-2 lite-tier triage gate of the three-stage
-`routine.hourly_check` funnel (cost-reduction-structural §B). The
+`routine.activity_scan` funnel (cost-reduction-structural §B). The
 deterministic Stage-1 gate already screened out the obviously-quiet
 cron ticks and the obviously-urgent ones. Your job is the narrow
 middle band: low-signal observations that *might* deserve a full
@@ -29,7 +29,7 @@ appends a one-line silent log via the daemon-direct writer.
    observations and append one bullet to today.md `## Agent Log`. No
    user-visible side effect.
 4. `action="escalate"` means: the daemon spawns the full Stage-3
-   hourly_check session with a `<gate_decision>` block that carries
+   activity_scan session with a `<gate_decision>` block that carries
    your `reason` so the routine knows what to prioritize.
 5. `reason` is short, mechanical, telemetry-friendly. Examples:
    `"calendar event needs review"`, `"only journal noise"`,

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

@@ -224,3 +224,83 @@ PATCH:
       Learned Context entries out to the matching user/*.md file and
       remove them from user/profile.md so the primary profile stays compact.
 
+### Step 4 — Consolidate feedback signals into lessons
+
+If a `<feedback_worksheet>` block is present in your context, fold the
+unconsumed feedback signals it lists into the scoped lesson stores. The daemon
+already did the mechanical work: every candidate carries a deterministic
+`decision`, `conf`, `weighted_ev`, and `reason`; every existing lesson carries a
+`rank` (rank 1 = lowest score = evict first); and the block ends with the exact
+`<consume ids="…">` set. Your job is only the **semantic** part — judge whether a
+candidate matches an existing lesson's intent, phrase the generalization, and
+detect contradictions. Do **not** recompute promotion or caps; honour the
+worksheet's `decision` and `rank` verbatim. If the block is absent, skip this
+step entirely. Like Steps 1–3 it is internal bookkeeping and emits no
+user-facing output.
+
+4a. **Lesson-store scopes** — process **every** `<scope … mode="lessons">` in the
+    worksheet, writing each to the `store=` path it declares: the global `agent`
+    scope (`store="policies/agent-lessons.md"`) and any per-agent
+    `agent:<slug>` scope (`store="policies/agents/<slug>/lessons.md"` — feedback
+    on one named agent's own output, injected only into that agent's runs). The
+    per-candidate rules below are identical for each; only the target file and
+    its H1 change. GET the scope's `store=` file first. If it 404s, PUT a fresh
+    file: frontmatter `type: rule` / `owner: agent` / `updated: <agent_day_date>`,
+    an H1 (`# Agent Lessons` for the global `agent` scope; `# Agent Lessons —
+    <label>` for an `agent:<slug>` scope, e.g. `# Agent Lessons — agent:report-writer`),
+    then a `## Lessons` section. Then, per candidate in that scope:
+    - `decision="promote"` → find an existing `## Lessons` bullet with the same
+      intent. If found, bump its `ev=` by `weighted_ev` (rounded to a whole
+      number), refresh `last=` to today, raise `conf`, and tighten the wording.
+      If not, add a new **active** bullet:
+      `- [<today>] <directive> <!-- ev=<round(weighted_ev), min 1> kind=<kind> src=<src> conf=<conf> last=<today> -->`
+      (`src`/`conf` come from the candidate; use the candidate's `kind=` when
+      present, otherwise infer it from the directive; `kind` ∈
+      preference|correction|do-more|do-less|constraint).
+    - `decision="hold-provisional"` with `reason="below-threshold"` → if it
+      matches an existing lesson's intent, bump that lesson's `ev`; otherwise add
+      the bullet with a trailing `<!-- provisional -->` marker (stored, not yet
+      injected — it promotes once corroboration reaches the threshold).
+    - `decision="hold-provisional"` with `reason="ignored-non-initiating"` →
+      silence never *starts* a lesson. Only use it to bump the `ev` of an
+      existing matching lesson; if none matches, write nothing for it.
+    - A newer `correction` that contradicts an active lesson **supersedes** it:
+      drop the stale bullet in the same rebuild so a changed mind leaves no
+      stale guidance.
+    - **Staleness prune** (§4 step 7): drop any existing lesson the worksheet
+      marks `stale="true"` (its `last=` is past the staleness horizon and it is
+      not a `constraint`) unless a fresh candidate re-reinforces it this pass —
+      a `constraint` is durable and is never stale-pruned.
+    Write the scope's section back with `PATCH <store= path> section=lessons
+    mode=replace`, applying the Step-2 section-body-rebuild discipline (GET fresh,
+    write the keep-list down first, byte-for-byte for unchanged bullets). Repeat
+    for each `mode="lessons"` scope; a write failure on one scope must not block
+    the others (omit only the failed scope's ids from the consume call, 4d).
+
+4b. **Cap enforcement.** After your edits to each scope, if its `## Lessons`
+    section exceeds that scope's `cap_bytes` or `max_entries`, remove existing
+    lessons starting from `rank="1"` (the worksheet's lowest-scored) upward until
+    it fits, then append exactly one marker line:
+    `- [...N lower-signal lessons omitted — full history in feedback_signals]`.
+    Never evict a `kind=constraint` lesson — drop the next-lowest instead.
+
+4c. **User-scope signals** (`<scope label="user" … mode="raw">`). These are
+    explicit owner directives captured via `POST /api/feedback`, *not* Raw
+    Signals. Route each into `## Learned Context` (or the matching
+    `identity/*.md` file) using the same bucket rules as Step 3 (a₂ / b),
+    respecting the ~600-token profile budget. Do not double-write a signal you
+    already folded from Raw Signals.
+
+4d. **Consume.** Once every scope above is written, mark the processed signals
+    consumed so they don't resurface tomorrow — send the worksheet's full
+    `<consume>` id list:
+    ```bash
+    curl -s -X POST http://localhost:8321/api/feedback/consume \
+      -H 'Content-Type: application/json' \
+      -d '{"ids": [<the ids from <consume ids="…"/>>]}'
+    ```
+    Consume is by id and race-safe: any signal the detector appended after the
+    worksheet was built has a higher id absent from the list and survives
+    untouched for tomorrow's pass. If a lesson write failed, omit that scope's
+    ids from the consume call so its signals are retried next Evening Review.
+

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

@@ -3,10 +3,11 @@
 
   The scheduler cron and boot-time catchup in
   `packages/daemon/src/{core/scheduler.ts,bootstrap/schedule-helpers.ts}`
-  consult `config.monthlyReviewEnabled` (default `false`) before
-  firing this routine. The task flow below is preserved verbatim as
-  the design-of-record but is not exercised at runtime until the kill
-  switch flips on.
+  consult the monthly-review AGENT row's `enabled` (ships `false`;
+  enable from /agents/monthly-review — AGENTS_HUB_REDESIGN_PLAN.md §2)
+  before firing this routine. The task flow below is preserved verbatim
+  as the design-of-record but is not exercised at runtime until the
+  agent is enabled.
 
   Why disabled: the current routine reads ~30 daily files + 4-5 weekly
   files + the agent journal to synthesise a user-facing snapshot whose
@@ -35,8 +36,8 @@
     5. Drop the agent-internal `## Monthly YYYY-MM` block — weekly's
        12-week journal already covers self-critique signal.
 
-  When the redesign ships, flip the default to `true` in
-  `packages/daemon/src/settings/runtime-settings.ts:monthlyReviewEnabled`
+  When the redesign ships, flip `defaultEnabled`/`enabled` to `true` in
+  `builtin-registry.ts` + `agent-assets/agents/monthly-review/agent.md`
   and re-introduce the docs under `agent-assets/docs/features/routines/`.
 -->
 
@@ -73,7 +74,7 @@ workflow; the skill owns the file contract.
 1. Determine the target file name from <current_time>:
    `journal/monthly/YYYY-MM.md`.
 
-**Pre-pass acquisition (none).** Unlike morning / hourly / today_refresh /
+**Pre-pass acquisition (none).** Unlike morning / activity-scan / today_refresh /
 evening / weekly, monthly_review does NOT trigger an `<acquisition-plan>`
 block — the 30-day calendar window already arrives via the
 `<calendar_events_30d>` ContextBuilder block (multi-provider after the
@@ -219,7 +220,7 @@ continue.
    ### Proposed adjustments
    - (max 3 bullets; concrete and testable — prompt tweak, schedule
      adjustment, filter rule, silence gate tuning. "Improve filter quality"
-     is not testable; "Lower hourly_check observation threshold from 2 to 1
+     is not testable; "Lower activity_scan observation threshold from 2 to 1
      on weekends" is)
    ### Metrics (agent side, monthly roll-up)
    - Agent plan rows completed: N
@@ -236,6 +237,27 @@ continue.
    cross-week frequency and drop the rest. Single-week anomalies are already
    in that week's journal entry and do not need re-listing.
 
+   For each concrete, actionable bullet in `### Proposed adjustments`, also
+   record a structured self-critique signal:
+
+   ```
+   POST /api/feedback
+   {
+     "source": "self_critique",
+     "summary": "<the specific testable adjustment, max 280 chars>",
+     "valence": "neutral",
+     "kind": "do-more",
+     "scope_type": "agent",
+     "action_kind": "agent_execution",
+     "evidence": { "excerpt": "monthly_review YYYY-MM proposed adjustment" }
+   }
+   ```
+
+   Post only concrete proposed adjustments. Do not post every retrospective
+   sentence, metrics row, or vague wish. If an adjustment is clearly about one
+   named Agent Definition's output, use `scope_type: "agent_slug"` and
+   `scope_ref` with that slug; otherwise keep `scope_type: "agent"`.
+
    If `journal/agent.md` does not yet exist, PUT a minimal file with
    `# Agent Journal\n\n` header plus this section, in a single call.
 
@@ -244,6 +266,57 @@ continue.
    rollup collapses duplicate keys last-write-wins, so your newer append
    automatically supersedes the earlier one within 24 hours.
 
+### Phase 3c: Re-generalize feedback lessons (internal)
+
+If a `<feedback_regeneralization>` block is present in your context, collapse
+accumulated specific lessons into a smaller set of higher-level principles. This
+is the monthly counterpart to the Evening Review's signal-folding: it processes
+**no new signals and consumes nothing** — it only re-reads the already-consolidated
+lesson stores the block lists and rewrites them. The daemon already did the
+mechanical work: every `<scope>` carries its `store=` path and caps, and every
+`<lesson>` carries a `rank` (rank 1 = lowest eviction score = drop-first), its
+`ev`/`kind`/`last`, and a `stale="true"` flag when it is past the staleness
+horizon. Your job is the **semantic** part — cluster lessons that share a theme
+and phrase the generalization. If the block is absent, skip this phase entirely.
+Like Phase 3b it is internal bookkeeping and emits no user-facing output.
+
+For **each** `<scope … >` in the block, writing back to the `store=` path it
+declares (`policies/agent-lessons.md` for the global `agent` scope;
+`policies/agents/<slug>/lessons.md` for a per-agent `agent:<slug>` scope):
+
+11. GET the scope's `store=` file. Identify clusters of two or more lessons that
+    express the same underlying preference at different surfaces — e.g.
+    "shorter mail summary", "shorter standup", "shorter report" all express
+    "default to terse output". For each cluster:
+    - Replace its members with **one** higher-level bullet that captures the
+      shared principle:
+      `- [<today>] <generalized directive> <!-- ev=<sum of the cluster's ev, min 1> kind=<the cluster's strongest kind> src=<strongest src> conf=<high if any member was high, else medium> last=<today> -->`
+      (summing `ev` keeps the merged lesson harder to evict — never re-derive it lower).
+    - Leave a lesson that belongs to no cluster untouched, byte-for-byte.
+    - **Never collapse, merge, or promote a `<!-- provisional -->` lesson.** The
+      worksheet block lists only active (promoted) lessons; the file also holds
+      provisional lessons awaiting corroboration, which the nightly evening pass
+      alone may promote. Preserve every provisional lesson in the file exactly as
+      it is — re-generalization is not a promotion path.
+    - **Do not** collapse across a contradiction: if two lessons give opposing
+      guidance, keep them separate and prefer the one with the more recent `last=`;
+      drop the stale opposite only when a `correction` superseded it.
+    - Drop any lesson the block marks `stale="true"` unless it joins a cluster —
+      a `kind=constraint` lesson is durable and is never collapsed away or
+      stale-pruned.
+    Re-generalization should make each store **smaller**, not larger; if a scope
+    has no genuine clusters, leave it unchanged.
+12. After your edits, if the section still exceeds the scope's `cap_bytes` or
+    `max_entries`, remove existing lessons starting from `rank="1"` upward until
+    it fits, then append exactly one marker line:
+    `- [...N lower-signal lessons omitted — full history in feedback_signals]`.
+    Never evict a `kind=constraint` lesson.
+    Write the scope's section back with `PATCH <store= path> section=lessons
+    mode=replace`, applying the same GET-fresh / write-the-keep-list discipline
+    Phase 3a uses. A write failure on one scope must not block the others or any
+    later phase. There is **no consume call** in this phase — re-generalization
+    rewrites lessons in place and touches no `feedback_signals` rows.
+
 ### Phase 4: Notify (user-facing only)
 10. The notification is for the USER, not a report of Phases 1–3. Never
    mention journal/monthly/YYYY-MM.md, journal/agent.md, "Monthly Review complete",

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

@@ -1,34 +1,48 @@
 {context}
 
-## Task: Append today's day-log entry to one research cluster
+## Task: Append the missing day-log entries to one research cluster
 
 The daemon enqueued this session because the cluster slug in
 `event.data.slug` has new meaningful activity since the last journal
-update. Your job is mechanical: read the delta, format one block,
-append it. Do NOT compose owner-facing DMs from this flow — engagement
-offer DMs are composed by the `routine.research_offer_dm` agent, not
-by you.
+update. Operate on that **one** slug only — the daemon already selected
+the cluster and fans out one event per cluster, so do not list or
+iterate clusters. Your job is mechanical: read the delta, format the
+day blocks that are still missing from the journal, append them. Do NOT
+compose owner-facing DMs from this flow — engagement offer DMs are
+composed by the `routine.research_offer_dm` agent, not by you.
 
 Follow the `browser-history` skill, "Flow: routine.research_cluster_update".
 
 1. Fetch `GET /api/browser-history/research-clusters/<slug>` for the
    `displayName`, `topDomains`, and `agentSummaryRevision`.
 2. Fetch `GET /api/browser-history/research-clusters/<slug>/delta`.
-   The response includes `days[]` with `date`, `meaningfulVisits`,
-   `meaningfulForegroundSec`, and `newDomains` for each bucketed
-   day. Identify the most-recent day not yet present in the existing
-   journal.
+   The response's `days[]` carries `date`, `meaningfulVisits`,
+   `meaningfulForegroundSec`, `newDomains`, and `complete` for each
+   bucketed day. `days[]` is ordered **oldest-first** and capped to the
+   most recent 31 days. `complete: false` marks the still-accumulating
+   current agent day — its counts are not final yet.
 3. Read the existing journal at
-   `context/research/<slug>.md` via `GET /api/context/research/<slug>.md`.
-   If the GET returns 404, create the file from the initial template
-   in the skill — populate frontmatter from the cluster detail; the
-   `## Day log` section starts with today's block. If the GET returns
-   200, leave existing content untouched and append today's block.
-4. Append (or create) via the context API. Use `PATCH` with an
-   `append:` body when the file already exists; use `PUT` for the
-   initial-file case.
-5. Optionally update the `## Cluster summary` block when the day's
-   `newDomains` materially shifts the topic — two short sentences,
+   `context/research/<slug>.md` via `GET /api/context/research/<slug>.md`,
+   and note which `### <YYYY-MM-DD>` headings already appear under
+   `## Day log`. If the GET returns 404, the file does not exist yet —
+   create it from the initial template in the skill (populate
+   frontmatter from the cluster detail). If the GET returns 200, leave
+   existing content untouched.
+4. Append a block for **every** day in `days[]` with `complete: true`
+   whose `date` is not already present under `## Day log`, **oldest
+   first** (iterate `days[]` in its natural order). Never append a
+   `complete: false` day — its counts are still growing and this ledger
+   is append-only, so a premature block would freeze an undercounted
+   day forever; it will arrive complete on a later run. This backfills
+   any nights the update was skipped or failed — a failed run waits a
+   full agent-day before retrying, so missed days accumulate until the
+   next successful run, and the 31-day delta window bounds the
+   catch-up. Use `PATCH` with an `append:` body when the file already
+   exists; use `PUT` for the initial-file case (the first block is the
+   oldest missing day). Never rewrite earlier days — this is an
+   append-only ledger.
+5. Optionally update the `## Cluster summary` block when the new
+   `newDomains` materially shift the topic — two short sentences,
    no thesis statements the data does not support. This is the only
    case where you re-write an earlier section; never edit the day log.
 

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

@@ -84,8 +84,8 @@ coordinates the high-level gather → analyze → write loop.
    see at morning review (e.g. "you'll be reminded about ESTA in 3 weeks").
 
 3. Fetch pending `roadmap_candidate` observations — weak signals queued
-   by `routine.hourly_check` (far-future calendar changes, user-edited
-   vault notes mentioning trips / deadlines, etc.) that the hourly flow
+   by `routine.activity_scan` (far-future calendar changes, user-edited
+   vault notes mentioning trips / deadlines, etc.) that the activity-scan flow
    deliberately did NOT write to roadmap directly:
    ```
    curl -s 'http://localhost:8321/api/observations?source=roadmap_candidate&pending=true&limit=50'

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

@@ -21,7 +21,7 @@ day rotation and **not** a morning routine.
   tries. If still locked after the final retry, **return a one-line
   status (`deferred — morning routine lock held`) and stop**. Do NOT
   attempt to append a deferred line to `## Agent Log` — that PATCH is
-  also blocked by the same lock. The next morning/hourly run will
+  also blocked by the same lock. The next morning/activity-scan run will
   reconcile.
 
 ### Step 1 — Read today's calendar from observations