@aitne-sh/aitne 0.1.9 → 0.1.11

package/agent-assets/docs/features/routines/activity-scan.md

@@ -0,0 +1,220 @@
+---
+schema_version: 1
+slug: features/routines/activity-scan
+title: Activity Scan
+id: activity-scan
+aliases:
+  - hourly
+  - observation consumer
+  - activity scan gate
+category: features
+summary: |
+  A medium-tier routine that fires every interval (default: every 2
+  hours) during active hours,
+  drains the pending observations queue, and decides whether the
+  accumulated change pattern warrants surfacing. Runs through a
+  four-layer gate that keeps quiet days quiet.
+section: routines
+tags:
+  - routines
+  - autonomous
+  - observations
+  - polling
+  - activity-scan
+status: stable
+ui_anchors:
+  - /agents/activity-scan
+  - /settings/hours
+  - /activity?tab=system
+ask_examples:
+  - What does the activity scan do?
+  - When does it run?
+  - How does the activity scan decide whether to escalate?
+  - What is the harvest pre-pass?
+  - How do I tune the gate's freshness window?
+locale: en-US
+created: 2026-04-25
+updated: 2026-06-10
+keywords:
+  - hourly
+  - observations
+  - polling
+  - activity scan
+  - gate
+  - layer 1
+  - layer 2
+  - layer 3
+  - harvestForGate
+  - decideStage
+  - pre-pass
+related:
+  - concepts/observations
+  - concepts/routines
+  - concepts/delegated-mode
+  - features/integrations/browser-history
+process_keys:
+  - routine.activity_scan
+  - routine.activity_scan.triage
+  - routine.fetch_window
+config_keys:
+  - activityScanEnabled
+  - activityScanIntervalMinutes
+  - activityScanActiveStartHour
+  - activityScanActiveEndHour
+  - activityScanMinObservations
+  - activityScanStage2Enabled
+  - activityScanHeartbeatHours
+  - activityScanLowSignalPendingCeiling
+  - activityScanPrePassFreshnessMinutes
+---
+
+# Activity Scan
+
+A medium-tier routine that drains the observations queue every interval
+during active hours and decides whether the accumulated change
+pattern warrants notifying you or appending to `state/today.md`. The
+"decide" step is a four-layer gate designed to keep quiet days quiet
+without missing the moment when something piles up.
+
+## When It Runs
+
+Every **interval minutes** (default 120 — every 2 hours), inside the configured active
+window. Cadence, window, and the enable switch live on the
+activity-scan **agent** — edit them at `/agents/activity-scan`
+(Definition tab → Cadence card; Enable/Disable toggles the routine).
+The legacy `activityScan*` config keys are deprecated fallbacks (see
+[Configuration](#configuration)). The trigger:
+
+- **Skips** when the morning routine has not yet run today
+  (recoverable — the dispatcher enqueues a `queueMorningRoutineWake`
+  self-recovery and the activity scan resumes after the morning
+  routine succeeds).
+- **Skips** when another activity scan is in flight (atomic flag).
+- **Skips** when accumulated signal is below the agent's **min
+  observations** threshold and the heartbeat window
+  (`activityScanHeartbeatHours`) hasn't elapsed.
+
+Every tick writes one `agent_actions` row with
+`action_type = 'activity_scan.gate'` so the gate's decisions are
+auditable from `aitne audit` and the dashboard activity feed.
+
+## The Four-Layer Gate
+
+The gate replaced the pre-Phase-9 "30-minute rate-limit" gate. It
+runs on every cron tick; only Layer 4 actually spawns a medium-tier
+agent session.
+
+### Layer 1 — Harvest pre-pass
+
+`ActivityScanCoordinator.harvestForGate` spawns a lite-tier
+`routine.fetch_window` session for each delegated / native
+integration whose `runtime_state.pre_pass_last_run:<key>` is older
+than `activityScanPrePassFreshnessMinutes`. The pre-pass fetches the
+integration's scan window (mail / calendar / Notion) and POSTs the
+results to `/api/observations`, so the rest of the gate sees a
+populated queue instead of stale data.
+
+Telemetry: `agent_actions.detail.harvest_ran` /
+`harvest_integrations` / `harvest_failed_integrations`.
+
+### Layer 2 — Signal compute
+
+`computeActivityScanSignals` reads the observation table mode-blind —
+it filters by source-prefix sets derived from
+`INTEGRATION_DESCRIPTORS`, never by `actor`. Signal categories
+include unread-mail / event-change / repo-change / browser-history
+clusters; each category produces a (count, last-seen, summary)
+tuple. The pre-pass freshness gate from Layer 1 is what guarantees
+those counts reflect "now", not "an hour ago".
+
+### Layer 3 — Decide stage
+
+`decideStage` is a pure function over the signal snapshot plus the
+per-tick config (heartbeat status, `activityScanStage2Enabled`,
+`activityScanLowSignalPendingCeiling`). It returns one of three stages
+— `stage0_silent`, `stage2`, or `stage3`:
+
+| Stage | What happens |
+|---|---|
+| `stage0_silent` | No agent session. Consume the pending observations and append a single best-effort line to `state/today.md`'s `## Agent Log`. This is the verdict for both "no signals" and "low signal under the ceiling". |
+| `stage2` | Only reachable when `activityScanStage2Enabled = true` (default `false`, so low-signal ticks fall through to `stage3`). Runs a lite-tier `routine.activity_scan.triage` call whose strict JSON output decides `log_only` (→ silent path) vs. `escalate` (→ `stage3`). |
+| `stage3` | Spawn the full medium-tier `routine.activity_scan` session — the visible agent run. Reached directly on high-novelty signals (VIP mail, calendar conflict, overdue agent plan, approaching schedule) or as the cautious default when Stage 2 is off. |
+
+When a Layer 1 pre-pass fails (`harvest.failed`), the gate
+short-circuits to a cautious `stage3` with reason
+`cautious_escalate_prepass_failure` and tags the audit row
+`agent_actions.detail.cautious_escalate = true` — a failed fetch
+should never silently swallow a tick's worth of signals.
+
+### Layer 4 — Dispatch
+
+When Layer 3 returns `stage0_silent` (or Stage 2 returns
+`log_only`), the daemon runs `runSilentActivityScanPath` — a
+daemon-direct write, no agent. When it returns `stage3` (or Stage 2
+returns `escalate`), `enqueueStage3ActivityScan` puts a
+`routine.activity_scan` event on the bus, which becomes the visible
+agent session.
+
+## What It Outputs
+
+- A best-effort line in `state/today.md`'s `## Agent Log` — even the
+  silent path appends one (skipped only if `today.md` is missing or
+  the write lock is held; the observations are still consumed either
+  way).
+- Notifications when warranted (only on a `stage3` agent session).
+- An audit row on every tick:
+  `agent_actions.action_type = 'activity_scan.gate'`, carrying the
+  harvest + signal + stage detail.
+
+## Configuration
+
+The cadence, active window, min-observations threshold, and on/off
+switch are owned by the activity-scan agent: edit them at
+`/agents/activity-scan` (Definition tab → Cadence card;
+Enable/Disable for the switch). The matching `activityScan*` config
+keys below are **deprecated fallbacks** — still accepted by
+`PATCH /api/config` but no longer surfaced in the dashboard; values
+resolve agent override → legacy config key → built-in default.
+
+| Setting | Default | Layer | Notes |
+|---|---|---|---|
+| Enable/Disable (`/agents/activity-scan`) | enabled | trigger | Master switch — the agent's `enabled` flag. Legacy key `activityScanEnabled` (deprecated fallback). |
+| Interval minutes | `120` | trigger | Cron cadence. Cadence card. Legacy key `activityScanIntervalMinutes` (deprecated fallback). |
+| Active start hour | `4` | trigger | Active window start. Cadence card. Legacy key `activityScanActiveStartHour` (deprecated fallback). |
+| Active end hour | `24` | trigger | End-exclusive; `24` ≡ midnight. Cadence card. Legacy key `activityScanActiveEndHour` (deprecated fallback). |
+| Min observations | `1` | trigger | Minimum pending observations before a non-silent stage dispatches; below this the tick records a `below_threshold` skip. Cadence card. Legacy key `activityScanMinObservations` (deprecated fallback). |
+| `activityScanPrePassFreshnessMinutes` | `30` | Layer 1 | Range `0`–`480`. Skip a per-integration fetch if its pre-pass ran more recently; `0` fetches every tick, `480` is cost-minimal. |
+| `activityScanStage2Enabled` | `false` | Layer 3 | Adds the lite-tier triage call; while `false`, low-signal ticks route straight to `stage3`. |
+| `activityScanHeartbeatHours` | `4` | Layer 3 | Range `1`–`48`. Force a non-silent stage at least this often, even on a quiet day. |
+| `activityScanLowSignalPendingCeiling` | `0` | Layer 3 | Range `0`–`20`. At or below this pending count, a low-signal tick stays silent. `0` keeps the cautious default (any pending observation escalates). |
+
+(The agent was named "Hourly Check" until v0.1.11 — old `hourlyCheck*`
+config keys and the `/api/agents/hourly-check` URL are still accepted
+for one deprecation window. `hourlyCheckGateMode` was removed in
+HOURLY_CHECK_GATE_REDESIGN_PLAN
+Phase 4 — the gate has a single execution path now.)
+
+## When Something Goes Wrong
+
+- **Skipped because the morning routine hasn't run.** The
+  dispatcher's `morningRoutineRanToday` gate keys on
+  `agent_actions.result = 'success'`. The skip reason is
+  `morning_routine_pending_for_today` and triggers a
+  `queueMorningRoutineWake` self-recovery. See
+  [Morning Routine Didn't Run](../../troubleshooting/morning-routine-didnt-run.md).
+- **Stage 3 never fires on a quiet day.** Expected.
+  `activityScanHeartbeatHours` forces a tick occasionally so silence
+  doesn't last indefinitely.
+- **Pre-pass keeps failing for one integration.** Read
+  `agent_actions.detail.harvest_failed_integrations`; the failing
+  integration name is recorded. Usually an auth issue — check
+  `/health.integrationModes` and the integration's settings page.
+
+## Related
+
+- [Observations](../../concepts/observations.md) — what populates the
+  queue Layer 2 reads.
+- [Delegated Mode](../../concepts/delegated-mode.md) — the
+  delegated / native integrations that participate in Layer 1's
+  harvest.
+- [Routines](../../concepts/routines.md)

package/agent-assets/docs/features/routines/custom-routines.md

@@ -1,175 +1,123 @@
 ---
 schema_version: 1
 slug: features/routines/custom-routines
-title: Custom Routines
+title: Custom Routines (Retired)
 id: custom-routines
 aliases:
   - custom routine
   - cron routine
   - user routine
+  - migrated_to_agent
 category: features
 summary: |
-  Beyond the built-in morning / evening / weekly / hourly routines,
-  the operator can define custom routines that fire on any cron
-  schedule. Each routine is a Markdown file under
-  policies/routines/custom/, runs under the tier the operator picks,
-  and is bounded by the same safety layers as the built-ins.
+  Custom routines — cron-driven Markdown files under
+  policies/routines/custom/ — are retired. User Agents replaced them.
+  At the first daemon start after the upgrade, each valid custom
+  routine was converted once into a user Agent with the same cron,
+  tier, budget, and enabled state; the source file is kept but marked
+  inert. Recurring work now lives on /agents.
 section: routines
 tags:
   - routines
+  - agents
   - autonomous
   - scheduler
-  - core
   - advanced
-status: stable
+status: deprecated
 ask_examples:
-  - How do I add a custom routine?
-  - What can a custom routine do?
-  - Can I disable a custom routine?
-  - Which tier does a custom routine run under?
+  - What happened to my custom routines?
+  - Where did my custom routine go?
+  - What does migrated_to_agent mean?
+  - How do I create a recurring task now?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-10
 keywords:
   - custom routine
   - routine.custom.<slug>
-  - user-defined routine
-  - scheduled task
-  - recurring schedule
-  - cron routine
+  - migrated_to_agent
+  - user agent
+  - recurring agent
+  - migration
 related:
   - guides/add-a-custom-routine
   - concepts/routines
-  - features/memory-files/schedule
 prerequisites:
   - concepts/routines
 process_keys:
   - routine.custom.<slug>
 context_files:
   - policies/routines/custom/<slug>.md
+  - policies/agents/<slug>/agent.md
 api_endpoints:
-  - PUT /api/context/*
-  - POST /api/recurring-schedules
+  - POST /api/agents
 ui_anchors:
-  - /settings/routines
-  - /connections/routines
+  - /agents
 ---
 
-# Custom Routines
+# Custom Routines (Retired)
 
 ## In One Sentence
 
-Operator-defined routines fire on any cron schedule, run under the
-tier the operator picks (`lite` / `medium` / `high`), and are bounded
-by the same safety layers as the built-ins.
-
-## What It Does
-
-- Runs a vault-file-defined check list on a cron schedule.
-- Resolves the backend at fire time from the chosen tier (no concrete
-  model picker — tier resolution mirrors the built-in routines).
-- Logs its run to Activity exactly like a built-in routine.
-
-## When It Runs
-
-The cron expression in the routine's vault file
-`policies/routines/custom/<slug>.md` drives the cadence. The scheduler
-wires one `node-cron` job per enabled routine at startup and fires a
-`routine.custom.<slug>` event on each tick.
-
-It is a **standard 5-field cron expression** (`min hour day-of-month
-month day-of-week`); for example `0 11 * * 2` is every Tuesday at
-11:00 local time, in your configured timezone.
-
-## How Changes Are Picked Up
-
-There is **no filesystem watcher**. The scheduler reloads only when a
-write goes through the context API — a `PUT` / `PATCH` / `DELETE`
-under `policies/routines/custom/` triggers an automatic re-diff of the
-registered jobs against what is on disk, so edits made through the
-dashboard, the API, or the agent take effect without a daemon restart.
-
-A raw file edit that bypasses the API (for example, opening the `.md`
-in an external editor) is *not* picked up until the next API write to
-that directory or a daemon restart. Prefer editing through **Settings
-→ Routines** or the context API.
-
-## What It Outputs
-
-- Whatever the check list produces — a context-file write, a
-  notification, or a no-op.
-
-## Where in the Dashboard
-
-- **Settings → Routines** (`/settings/routines`) is the operator
-  surface for adding, editing, and disabling. `/connections/routines`
-  is an equivalent page that opens the same surface.
-
-## Configuration
-
-Each custom routine is a Markdown file under
-`~/.personal-agent/context/policies/routines/custom/<slug>.md` whose
-frontmatter carries:
-
-| Field | Type | Notes |
-|---|---|---|
-| `type` | `rule` | Always `rule` for custom routines. |
-| `slug` | string | Kebab-case; matches the file stem and the ProcessKey suffix. |
-| `cron` | string | Standard 5-field cron expression (e.g. `0 11 * * 2`). |
-| `process_key` | `routine.custom.<slug>` | Must match the slug. |
-| `enabled` | boolean (`true` / `false`) | Disable without deleting by setting `false`. |
-| `backend_tier` | `lite` \| `medium` \| `high` | Drives BackendRouter tier resolution. Legacy `light` (→ `medium`) and `heavy` (→ `high`) are still accepted for files written before the rename. |
-| `max_budget_usd` | number | Per-execute USD cap; must be a positive number (e.g. `0.05`). |
-
-Every field above is required; the body must contain a `## Checks`
-section — a routine that is missing any of them is rejected at write
-time with a validation error.
-
-The `## Checks` section is the list the agent runs through on each
-fire. To change a routine, write through the context API (the
-dashboard, the API, or the agent), which triggers an automatic reload
-as described above — no daemon restart is needed.
-
-### Example
-
-A `tuesday-standup-prep` routine at
-`policies/routines/custom/tuesday-standup-prep.md`:
-
-```markdown
----
-type: rule
-slug: tuesday-standup-prep
-cron: "0 11 * * 2"
-process_key: routine.custom.tuesday-standup-prep
-enabled: true
-backend_tier: medium
-max_budget_usd: 0.10
----
-
-## Checks
-
-- Summarize commits I pushed since last Tuesday.
-- List any calendar events for the rest of the week that mention
-  "standup" or "review".
-- If there is anything noteworthy, DM me a short prep note.
-```
-
-This fires every Tuesday at 11:00 (your configured timezone), runs
-under the `medium` tier (Sonnet on the Claude backend), and stops
-spending once the run reaches $0.10.
-
-> **Distinct from `recurring_schedules`.** The `recurring_schedules`
-> table powers DM-style scheduled tasks (`agent.task` /
-> `agent.dm_task`) — e.g. "remind me at 9am every weekday". Those
-> use a structured `RecurrenceRule` (frequency + time + dayOf*) and
-> are managed via `POST /api/recurring-schedules`. They are not the
-> same surface as `routine.custom.<slug>`.
-
-## When Something Goes Wrong
-
-- A cron expression that resolves to "never": the routine appears in
-  the list but never fires. The dashboard shows next-fire as N/A.
+Custom routines (`policies/routines/custom/<slug>.md` files fired as
+`routine.custom.<slug>`) no longer run — **user Agents replaced
+them**, and every valid routine was converted automatically, exactly
+once, at the first daemon start after the upgrade.
+
+## What Changed
+
+- The custom-routine scheduler was removed. Files under
+  `policies/routines/custom/` are no longer read by any scheduler, and
+  no `routine.custom.<slug>` events fire. (Historical Activity rows
+  tagged with those keys remain and still resolve to this page.)
+- Recurring work you define is now an **Agent**: a
+  `policies/agents/<slug>/agent.md` file that appears on the
+  **Agents** page (`/agents`) with its schedule, an enable toggle, run
+  metrics, execution history, and a **Run now** button — surfaces
+  custom routines never had. See
+  [Create a Recurring Agent](../../guides/add-a-custom-routine.md).
+
+## The One-Time Migration
+
+At the first daemon start after the upgrade — and only once, guarded
+by a persisted flag — every file under `policies/routines/custom/` is
+examined:
+
+- A **valid routine becomes a user Agent** at
+  `policies/agents/<slug>/agent.md` carrying over:
+  - the same **cron expression** (pinned to your configured timezone),
+  - the same **model tier** (`backend_tier` → the Agent's tier),
+  - the same **per-run budget** (`max_budget_usd`),
+  - the same **enabled state** — a disabled routine migrates disabled.
+
+  The routine's body (its `## Checks` section) becomes the Agent's
+  **task prompt** verbatim, and the Agent's description records where
+  it came from (`Migrated from custom routine "<slug>".`).
+- The **source file is never deleted.** It is rewritten in place with
+  `enabled: false` and a `migrated_to_agent: <slug>` marker in its
+  frontmatter, so it is visibly inert while your content is preserved.
+
+### Collisions and invalid files
+
+- **Slug collision** — if an Agent (built-in or user) already exists
+  under the routine's slug, the migration falls back to
+  `custom-<slug>`. If that also collides, the routine is skipped with
+  a warning and the file is left untouched.
+- **Invalid files** — a routine with broken frontmatter or missing
+  required fields is left untouched and logged; it is not migrated.
+  (Such files never fired under the old scheduler either.)
+
+## After the Migration
+
+- Find your migrated routines on **`/agents`** — each one's
+  description says which custom routine it came from.
+- Edit the schedule, tier, limits, or prompt there (or directly in the
+  `agent.md` file; the daemon picks up changes without a restart).
+- The inert files under `policies/routines/custom/` can stay as a
+  reference or be deleted whenever you like — they have no effect
+  either way.
 
 ## Related
 
-- [Add a Custom Routine](../../guides/add-a-custom-routine.md)
+- [Create a Recurring Agent](../../guides/add-a-custom-routine.md)
+- [Routines](../../concepts/routines.md)

package/agent-assets/docs/features/routines/evening-review.md

@@ -27,7 +27,7 @@ ask_examples:
   - How do I disable the evening review?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-10
 keywords:
   - evening review
   - retro
@@ -39,7 +39,7 @@ related:
   - features/memory-files/agent-journal
   - features/memory-files/today
   - features/routines/morning-routine
-  - features/routines/custom-routines
+  - guides/add-a-custom-routine
 process_keys:
   - routine.evening_review
 context_files:
@@ -48,9 +48,10 @@ context_files:
   - journal/agent.md
   - identity/profile.md
   - policies/routines/evening.md
+  - policies/agent-lessons.md
 ui_anchors:
-  - /connections/journal
-  - /settings/routines
+  - /knowledge?tab=context-files
+  - /agents/evening-review
 ---
 
 # Evening Review
@@ -64,7 +65,7 @@ your identity files.
 
 ## What It Does
 
-The routine runs three internal bookkeeping steps. These are quiet by
+The routine runs several internal bookkeeping steps. These are quiet by
 design — they prepare state that **tomorrow's morning routine depends on**
 rather than producing a chatty end-of-day report.
 
@@ -80,6 +81,11 @@ rather than producing a chatty end-of-day report.
 3. **Process profile signals.** Reads the day's Raw Signals from your
    profile and routes each into `character`, Learned Context, or a
    detailed identity file under `identity/`, then prunes stale entries.
+4. **Consolidate feedback signals into lessons.** When feedback learning is
+   on (default) and signals are pending, folds the day's unconsumed feedback
+   into the scoped lesson stores (`policies/agent-lessons.md` for agent-scope
+   lessons; identity files for owner directives), then marks them consumed.
+   Skipped entirely when no signals pend.
 
 ## When It Runs / How It Is Triggered
 
@@ -94,6 +100,8 @@ run is skipped while the agent is paused (`!stop`) or setup is incomplete.
 - Roadmap edits in `plans/roadmap.md` when a plan was promoted or fired.
 - A `journal/agent.md` line **only** when a roadmap review date fired or a
   validation error needs recording.
+- Lesson edits in `policies/agent-lessons.md` when feedback signals were
+  pending and consolidated.
 
 The built-in steps emit **no user-facing DM by default** — there is no
 "today wraps up here" message. (The one exception: any check you add to
@@ -102,19 +110,21 @@ including steps that call `POST /api/notify`.)
 
 ## Where in the Dashboard
 
-- **Connections → Journal** (`/connections/journal`) shows `journal/agent.md`
-  entries when the roadmap step logged one.
-- **Settings → Routines** (`/settings/routines`) is where you manage the
-  evening rulebook.
+- **Knowledge → Context Files** (`/knowledge?tab=context-files`) shows
+  `journal/agent.md` entries when the roadmap step logged one.
+- **Agents → Evening Review** (`/agents/evening-review`) is where you
+  manage the evening rulebook (Rulebook tab) and enable or disable the
+  routine.
 
 ## Configuration
 
 The fire time and tier are fixed in code, but the routine is not a black box:
 - **Add your own evening checks.** Append `### <label>` entries to
-  `policies/routines/evening.md` (via the dashboard, or the
-  [custom routines guide](../../guides/add-a-custom-routine.md)). They run
-  alongside the built-in steps using the same journaling conventions and
-  may notify you explicitly.
+  `policies/routines/evening.md` (via the dashboard or the context
+  API). They run alongside the built-in steps using the same
+  journaling conventions and may notify you explicitly. For a
+  standalone recurring job on its own schedule, create a
+  [recurring Agent](../../guides/add-a-custom-routine.md) instead.
 - **Verify it stays healthy.** `aitne verify evening-review-slimdown`
   checks that recent `routine.evening_review` sessions ran inside their
   seeded token envelope (read-only; `--days N` widens the window).

package/agent-assets/docs/features/routines/morning-routine.md

@@ -26,7 +26,7 @@ ask_examples:
   - What model does morning routine use?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-10
 keywords:
   - morning
   - day plan
@@ -42,7 +42,7 @@ related:
 prerequisites:
   - concepts/agent-day
 ui_anchors:
-  - /settings/routines
+  - /agents/morning-routine
   - /settings/models
   - /schedule
   - /activity
@@ -91,7 +91,7 @@ Within Stage A, the work proceeds in this order:
 2. Pull today's calendar events from any connected calendar integration.
 3. Scan recent unread mail and surface the few that need owner attention.
 4. Walk the roadmap for items whose **Preparation Timeline** rows fire today.
-5. Consume any pending observations the hourly check has already queued.
+5. Consume any pending observations the activity scan has already queued.
 6. Write the rebuilt `state/today.md`.
 7. Log a single status line to the dashboard activity feed.
 
@@ -109,8 +109,9 @@ the daemon injects a `<roadmap_skeleton>` block carrying the pre-aggregated
 Annual Goals / Quarterly Focus / Preparation Timeline facts so Stage A
 can populate the wizard's placeholder roadmap on medium tier instead of
 paying for a one-shot high-tier session. (The dedicated
-`routine.morning_routine_initial` process key was retired in Phase 4, and
-Phase 7 — 2026-05-16 — removed its high-tier seed entirely.)
+`routine.morning_routine_initial` process key — along with its high-tier
+seed — was retired in Phase 7, 2026-05-16; the first-run branch now flows
+through the parent `routine.morning_routine` envelope.)
 
 ## What It Outputs
 
@@ -125,6 +126,7 @@ Phase 7 — 2026-05-16 — removed its high-tier seed entirely.)
 - **Schedule view** — the column for today is rebuilt against the new schedule file.
 - **Activity feed** — a `routine.morning_routine` row appears at the run timestamp.
 - **Settings → Models** — the routine's backend, model, max-turns, and budget cap are configured here.
+- **Agents → Morning Routine** (`/agents/morning-routine`) — the agent's Rulebook tab edits the morning rulebook (`policies/routines/morning.md`) plus the daily-journal Format and Export rules.
 
 ## Configuration