@aitne-sh/aitne 0.1.7 → 0.1.8

package/agent-assets/skills/travel/SKILL.md

@@ -1,132 +0,0 @@
----
-name: travel
-description: Load when the user asks about an upcoming trip or reservation, morning routines need to surface travel within the next 7 days, or reviews need a travel overview — flight, hotel, restaurant, train, and bus bookings detected by the Gmail observer.
-allowed-tools:
-  - Bash(curl *)
-  - Read
----
-
-# Travel & Booking Tracker
-
-The daemon's Gmail observer detects booking confirmation emails from airlines,
-hotels, OTAs, restaurant reservation platforms, and rail services. Data is
-stored in the `travel_bookings` SQLite table.
-
-## When to Use
-
-- **Morning routine**: include upcoming travel/bookings in today.md.
-- **Evening review**: report newly detected bookings.
-- **User asks about trips/reservations**: query bookings and summarize.
-- **Pre-trip reminders**: surface upcoming travel day before departure.
-
-## Workflow
-
-1. Fetch upcoming bookings from `/api/travel-bookings/upcoming`.
-2. For morning routine, highlight bookings within the next 7 days.
-3. For evening review, check for newly detected bookings (today's createdAt).
-
----
-
-## API Reference
-
-Base URL: `http://localhost:8321`
-
-### GET /api/travel-bookings
-
-List travel bookings with optional filters.
-
-```bash
-# All bookings
-curl -s "http://localhost:8321/api/travel-bookings?limit=20"
-
-# Filter by type
-curl -s "http://localhost:8321/api/travel-bookings?type=flight"
-
-# Upcoming only
-curl -s "http://localhost:8321/api/travel-bookings?status=upcoming"
-
-# Date range
-curl -s "http://localhost:8321/api/travel-bookings?from=2026-04-01&to=2026-05-01"
-```
-
-| Param | Type | Default | Description |
-|-------|------|---------|-------------|
-| `type` | string | — | flight, hotel, restaurant, train, bus, other |
-| `status` | string | all | upcoming, completed, cancelled, all |
-| `from` | ISO date | — | Bookings with start_date on or after |
-| `to` | ISO date | — | Bookings with start_date before |
-| `limit` | number | 50 | Max results (1–200) |
-
-Response:
-```json
-{
-  "bookings": [
-    {
-      "id": 1,
-      "type": "flight",
-      "provider": "United",
-      "destination": null,
-      "startDate": "2026-05-15T10:30:00Z",
-      "endDate": null,
-      "confirmationNumber": "ABC123",
-      "amount": 350,
-      "currency": "USD",
-      "status": "upcoming",
-      "gmailMessageId": "18f...",
-      "createdAt": "2026-04-12T10:00:00Z"
-    }
-  ],
-  "total": 1
-}
-```
-
-### GET /api/travel-bookings/upcoming
-
-Convenience endpoint for upcoming bookings sorted by start date.
-
-```bash
-curl -s "http://localhost:8321/api/travel-bookings/upcoming?limit=10"
-```
-
-### PATCH /api/travel-bookings/:id
-
-Update booking status or destination.
-
-```bash
-curl -s -X PATCH "http://localhost:8321/api/travel-bookings/1" \
-  -H "Content-Type: application/json" \
-  -d '{"status": "completed"}'
-```
-
----
-
-## Formatting Guide
-
-### Morning routine — today.md
-
-```
-## Travel & Reservations
-Upcoming flight: United to SFO (May 15) — confirmation ABC123
-Hotel: Marriott SF (May 15-17) — confirmation XYZ789
-Restaurant: OpenTable reservation tonight 19:00
-```
-
-Omit section if no upcoming bookings within 7 days.
-
-### Evening review
-
-```
-## New Bookings Detected
-- United flight: May 15, confirmation ABC123, $350
-```
-
-### Booking type display names
-
-| type value | Display name |
-|------------|-------------|
-| flight | Flight |
-| hotel | Hotel |
-| restaurant | Restaurant |
-| train | Train |
-| bus | Bus |
-| other | Reservation |

package/agent-assets/skills/travel-time/SKILL.md

@@ -1,158 +0,0 @@
----
-name: travel-time
-description: Load when a calendar event needs a departure time, the user asks about commute / transit duration, or a reminder includes "leave by HH:MM".
-when_to_use: Backed by Google Maps Directions — requires `googleMapsApiKey` in the daemon secret store; falls back gracefully when missing.
-allowed-tools:
-  - Bash(curl *)
-  - Read
----
-
-# Travel Time & Commute Optimizer
-
-Uses the Google Maps Directions API to estimate travel time between locations.
-Integrates with the calendar to compute departure times for events with
-location fields.
-
-**Prerequisite**: Google Maps API key must be configured in the daemon's
-secret store (`googleMapsApiKey`). The API key needs the Directions API
-enabled.
-
-## When to Use
-
-- **Morning routine**: check today's calendar events with locations,
-  compute departure times, add to today.md.
-- **User asks about commute/travel time**: query specific routes.
-- **Pre-event reminders**: DM departure time suggestions.
-
-## Workflow
-
-1. Fetch today's calendar events. The right call depends on the current
-   Google Calendar mode (read `<integration_modes>` injected at session
-   start):
-<!-- mode:direct:google_calendar -->
-   Direct mode → `GET /api/calendar/events?date=today&days=1`
-   (see the `external-services` skill).
-<!-- /mode:direct:google_calendar -->
-<!-- mode:delegated-same:google_calendar -->
-   Same-backend delegated → use this session backend's native Calendar
-   list-events MCP tool. `/api/calendar/events` returns 410.
-<!-- /mode:delegated-same:google_calendar -->
-<!-- mode:delegated-cross:google_calendar -->
-   Cross-backend delegated → `POST /api/integrations/google_calendar/exec`
-   with a natural-language `task` + `outputSchema` (see the
-   `external-services` skill — cross-backend variant for worked
-   examples).
-<!-- /mode:delegated-cross:google_calendar -->
-<!-- mode:native:google_calendar -->
-   Native mode → use this session backend's native Calendar
-   list-events MCP tool (same call shape as `delegated-same`). The
-   materialized `external-services` skill body
-   (`SKILL.native.<session-backend>.md`) lists the per-backend tool
-   names. The daemon does not proxy in native mode;
-   `/api/calendar/events` returns 410 and
-   `/api/integrations/google_calendar/exec` returns 410 too.
-<!-- /mode:native:google_calendar -->
-<!-- mode:disabled:google_calendar -->
-   Disabled → skip this skill; there is no calendar to source events from.
-<!-- /mode:disabled:google_calendar -->
-2. For events with a `location` field, call `/api/travel-time` or
-   `/api/travel-time/for-event/:eventId` to get travel duration.
-3. Include departure time recommendations in today.md or DM.
-
----
-
-## API Reference
-
-Base URL: `http://localhost:8321`
-
-### GET /api/travel-time
-
-Estimate travel time between two locations.
-
-```bash
-# Transit (default)
-curl -s "http://localhost:8321/api/travel-time?origin=Grand+Central&destination=Times+Square"
-
-# Driving with arrival time
-curl -s "http://localhost:8321/api/travel-time?origin=Brooklyn&destination=Newark&mode=driving&arrival=2026-04-12T14:00:00-04:00"
-```
-
-| Param | Type | Default | Description |
-|-------|------|---------|-------------|
-| `origin` | string | (required) | Origin address or place name |
-| `destination` | string | (required) | Destination address or place name |
-| `mode` | string | transit | driving, transit, walking, bicycling |
-| `arrival` | ISO 8601 | — | Desired arrival time (computes departure time) |
-
-Response:
-```json
-{
-  "origin": "Grand Central Terminal, NY",
-  "destination": "Times Square, NY",
-  "mode": "transit",
-  "durationSeconds": 1380,
-  "durationText": "23 mins",
-  "distanceMeters": 8500,
-  "distanceText": "8.5 km",
-  "departBy": "2026-04-12T13:34:00.000Z"
-}
-```
-
-### GET /api/travel-time/for-event/:eventId
-
-Estimate travel time for a specific calendar event.
-
-```bash
-curl -s "http://localhost:8321/api/travel-time/for-event/abc123?origin=Home&mode=transit"
-```
-
-| Param | Type | Default | Description |
-|-------|------|---------|-------------|
-| `origin` | string | (required) | Your starting location |
-| `mode` | string | transit | Travel mode |
-
-Response:
-```json
-{
-  "event": {
-    "id": "abc123",
-    "summary": "Team meeting",
-    "location": "WeWork Times Square",
-    "start": "2026-04-12T14:00:00-04:00"
-  },
-  "travelTime": {
-    "origin": "Home, NY",
-    "destination": "WeWork Times Square, NY",
-    "mode": "transit",
-    "durationSeconds": 2400,
-    "durationText": "40 mins",
-    "distanceMeters": 15000,
-    "distanceText": "15 km",
-    "departBy": "2026-04-12T13:16:00.000Z"
-  }
-}
-```
-
----
-
-## Formatting Guide
-
-### Morning routine — today.md
-
-```
-## Commute & Travel
-14:00 Team meeting @ WeWork Times Square — depart by 13:15 (transit, 40 min)
-18:30 Dinner @ Restaurant ABC — depart by 18:00 (transit, 25 min)
-```
-
-Only include events that have a `location` field.
-Omit section if no events with locations today.
-
-### Mode display names
-
-| mode | Display |
-|------|---------|
-| transit | Transit |
-| driving | Driving |
-| walking | Walking |
-| bicycling | Bicycle |

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

@@ -1,322 +0,0 @@
-{context}
-
-## Task: Morning Routine (04:00 pipeline)
-
-This is the B-007 §5.9 nine-step pipeline. The daemon has already rotated
-yesterday's `today.md` → `yesterday.md` before you start. Each numbered
-step below maps to a §5.9 step. Follow the `context` skill for section
-formats and entry shapes — this prompt owns the workflow; the skill owns
-the schema.
-
-The "Vault review context" block appended to this prompt includes
-`context-index.md` and `dossiers/morning.md`; consult it during context
-gathering and update the dossier's Open items / Last run before finishing.
-Writes to `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 rewrite keep the frontmatter and only refresh
-`updated:` — writes that drop the frontmatter are rejected with 422.
-
-Global rules (apply at every step):
-- Do **not** add meta-maintenance tasks about context files, setup completion, or placeholder cleanup (for example, "initialize context files") to User Tasks or Handoff, whether carried from yesterday or newly discovered, unless the user explicitly asked to track them.
-- If `<today_write_lock_id>` is present, every PUT/PATCH to
-  `/api/context/today` must send header `X-Lock-Id: <today_write_lock_id>`.
-- Silent-by-default: your final text is agent-internal. User notifications
-  require an explicit `POST /api/notify`.
-
-### Step 1 — Read handoff and derive day-type
-1. Read `<yesterday>` ## Handoff.
-   - "### Tomorrow" items → candidates for today's User Tasks / Agent Notes.
-   - "### Later" items → carry into the new `today.md` ## Handoff.
-2. Derive today's day-type header per the today skill "Header line —
-   day-type filter". Read `<user>` ## Notification Preferences for the
-   matching policy. The resulting line 2 of `today.md` is load-bearing —
-   every downstream event parses it.
-
-> **Date reference for today.md.** Take the H1 date from
-> `<current_agent_day date="…" weekday="…" />` in your prompt context, not
-> from `<current_time>`. The two diverge between local midnight and
-> `boundary_hour:00` local; the daemon validates line 1 against
-> `<current_agent_day>` and rejects mismatches with 422. The morning
-> routine prepares the agent-day in progress — never tomorrow.
-
-### Step 2 — Sync external sources (apply the day-type filter at read time)
-3. Mail, Calendar, and Notion acquisition. The pre-pass fetcher session
-   (`routine.fetch_window`) ran ahead of you and posted a `<fetch>` row's
-   worth of observations for every active mail / calendar / notion
-   integration. Calendar windows are pre-fetched ONLY for non-direct
-   modes (delegated / native); direct-mode calendar data is still
-   inlined into `<calendar_events_7d>` by ContextBuilder. The
-   `<fetch_report>` block injected ahead of this body tells you the
-   pre-pass status:
-
-   - `status="success"` or `"partial"` → freshly-fetched rows are
-     visible in `/api/observations?pending=true`. Trust the table.
-   - `status="failed"` → the pre-pass either crashed or its output was
-     unparseable. Pending observations from prior ticks may still be
-     present; treat the table as best-effort and skip integration
-     sections whose source_prefix returns nothing.
-   - `status="skipped"` → no integration was active for this routine
-     this tick; mail / notion sections are no-ops for this run.
-
-   Then drain pending observations and apply category / focus filtering:
-
-   a. **Mail observations**:
-      `GET /api/observations?pending=true&source_prefix=gmail:,outlook_mail:&limit=30`.
-      Classify each per the `mail` skill's category taxonomy. Drop any
-      whose day-type focus is `off`. When `summary_text` is NULL (the
-      async summarizer has not drained yet) fall back to a one-line
-      snippet from `payload.raw` (subject + from). Mail data arrives
-      here regardless of integration mode — the pre-pass partial
-      handled the direct / delegated-same / delegated-cross / native
-      wire surface for you.
-
-   b. **Notion observations**:
-      `GET /api/observations?pending=true&source_prefix=notion:&limit=20`.
-      Use for project / decision context only. Do NOT graduate Notion
-      edits into User Tasks unless the user explicitly tagged the entry.
-
-   c. **Calendar context** is already injected as `<calendar_events_7d>`
-      (multi-provider) ahead of this prompt — reference the block
-      directly in Step 6 (today.md generation). Mode-aware shape:
-      direct providers carry inline events; non-direct providers
-      (delegated / native) carry a hint pointing at
-      `/api/observations?source_prefix=google_calendar:,outlook_calendar:`
-      because the pre-pass already POSTed events there. Read the
-      observations table verbatim for non-direct providers — do NOT
-      re-drive the connector yourself.
-
-   Skip the entire step when no integrations are active and no mail /
-   notion observations are pending.
-4. Source-of-Truth tasks: read `<management_rules>` ## Source of Truth →
-   Tasks, call the matching endpoint, drop filtered-off items before merge.
-   Skip if no external source is configured.
-5. Roadmap ## Agent Action Plan — process items dated today or overdue
-   (not marked ✓). Drop items whose category focus is off, then:
-   - `[notify]` → `POST /api/schedule` + one row in `today.md` ## Agent Plan
-   - `[today]`  → collect for `today.md` ## User Tasks
-   - `[check]`  → `POST /api/schedule` (check-in) + one row in ## Agent Plan
-   - If a roadmap row includes `[provisional ...]`, copy that tag and
-     its meaning into the scheduled task `description` so
-     `scheduled.task.md` frames the first contact as a confirmation
-     question, not a directive.
-   - Mark processed roadmap rows complete via `PATCH /api/context/roadmap`,
-     `section=agent_action_plan`, `mode=replace`, rewriting the exact
-     row from `- YYYY-MM-DD [tag]: ...` to
-     `- ✓ completed <today>: YYYY-MM-DD [tag]: ...`. Keep the entry ID
-     marker and all existing completed rows byte-for-byte.
-   Then generate **look-ahead entries** for tomorrow → +3 days by cross-
-   referencing unprocessed roadmap items against `<calendar_events_7d>`.
-   These go into `today.md` ## Agent Notes using the skill's "Agent Notes
-   flavor 1: Look-ahead checklist" format (`- [ ] (HIGH/MID/LOW) ...`).
-   Skip this step entirely if no today-items and no look-ahead items exist.
-
-### Step 3 — Review overnight user-originated observations
-6. Call `GET /api/observations?pending=true&actor=user` (observations
-   skill). This is the **user-actor** complement to Step 2 — mail / notion
-   rows posted by the pre-pass / partials carry `actor=agent` and have
-   already been folded in. Step 3 picks up anything the user themselves
-   changed overnight (Obsidian edits, manual file drops, git commits)
-   that the daemon recorded under `actor=user`. Fold only meaningful
-   changes into the `today.md` draft you're building, respecting the
-   day-type filter.
-
-### Step 4 — Inbox triage (B-007 §5.9 Q5 case A)
-7. `GET /api/context/list/inbox` to enumerate pasted memos. For each file:
-   - `GET /api/context/inbox/<file>` to read the body, then classify:
-     **project**, **user**, **memo**, **task**.
-   - Integrate into the right target:
-     - existing project → append to `projects/<slug>.md` (notify tier).
-     - new-project shape → DM to confirm *"create project `<slug>`?"* and
-       wait for reply before creating the file.
-     - New `projects/<slug>.md` files must include YAML frontmatter: `type: project`, `owner: shared`, `updated: YYYY-MM-DD`, then an H1.
-     - user dictionary (people / health / goals / …) → append to the
-       matching `user/<area>.md`.
-     - date-bound memo → summarize into `today.md` ## Agent Notes.
-     - unclassifiable → DM the user an excerpt asking what to do; leave
-       the file in `inbox/` for next pass.
-   - After integration, move the original: (a) `PUT /api/context/agent/scratch/inbox-YYYY-MM-DD-<orig-slug>.md` with the original body, then (b) `DELETE /api/context/inbox/<file>` to remove the source. The 30-day retention on `agent/scratch/` is a convention for now — no sweeper exists yet.
-   - **High-risk triggers — DM for confirmation before writing:**
-     new project creation, wholesale overwrite of `user/profile.md`,
-     financial or health data with a numeric impact. The agent's own
-     judgment is the gate — call `POST /api/notify` with the
-     proposed change and wait for confirmation; don't auto-write.
-   - **Hard stop (never write)** — if the memo contains anything that
-     looks like a credential, password, API key, or private token, do
-     NOT write it to any context file. Log one line to ## Agent Log
-     (`- HH:MM [inbox] skipped <file>: secret suspected`), leave the
-     source file in `inbox/` for the user to handle, and move on. This
-     overrides the "DM then proceed" path above — see _safety.md.
-
-### Step 5 — Daily journal synthesis (skipped on first-run flow)
-8. Synthesize yesterday's journal from the data you already have:
-   - `<yesterday_agent_actions>` — previous agent-day execution rows from
-     SQLite. Use these for authoritative timing / result counts.
-   - `<yesterday_messages>` — previous agent-day non-system messages from
-     SQLite. Use these for conversations that never made it into
-     `yesterday.md`.
-   - `<yesterday_dm_conversation_log>` — rolling DM summaries recorded in
-     SQLite; useful when many message rows collapse into one thread.
-   - `<yesterday>` — User Schedule, User Tasks, Agent Plan, Agent Log,
-     Handoff sections are the primary source. The `## Agent Log` line
-     entries are authoritative for what the agent did; `## User Schedule`
-     for what was planned; conversations you handled yesterday surface
-     through Agent Log entries the agent wrote at the time.
-   - Step 4 inbox triage outcomes — in-memory from this very run.
-   - `<calendar_events_7d>` — reconcile against yesterday's column for
-     attended/skipped flags on the Schedule section.
-   If SQLite tags disagree with `yesterday.md`, prefer SQLite for counts,
-   timing, and whether an interaction/action happened at all; prefer
-   `yesterday.md` for curated phrasing already shown to the user.
-   Compose `daily/YYYY-MM-DD.md` (YYYY-MM-DD = yesterday's agent-day
-   date) following the **`Daily journal format spec`** policy block above.
-   - Output language: follow `<output_language_policy>` (Policy B —
-     skeleton H2 headers stay English; body prose in
-     `<settings primary_language>`). Keep technical terms in their
-     original form.
-   - When `<settings vault_mode>` is `obsidian`, render project / people
-     references as `[[wikilink]]`s resolving to `projects/<slug>.md` or
-     `user/people.md#...`. When `plain`, write plain text only.
-   - Apply redaction from the `Redaction patterns` and `Journal export
-     rules` policy blocks above.
-   - Include frontmatter fields `date`, `weekday`, `type: daily`, `owner: agent`, `updated`,
-     `agent_generated: true`, `agent_last_synced_at`, `content_hash`,
-     `projects`, `people`, `tags`, `calendar_events`, `messages_handled`.
-     If the API rejects unknown fields, write the ones it accepts and
-     log the gap in `agent/journal.md` (Step 9).
-   - If `<yesterday>` frontmatter carries `no_journal_export: true`,
-     write the placeholder `[Skipped by user request]` as body and still
-     populate required frontmatter fields.
-   - Conflict handling: first `GET /api/context/daily/YYYY-MM-DD.md`.
-     - 404 → `PUT /api/context/daily/YYYY-MM-DD.md` with the full body.
-     - 200 → the user (or a prior run) already wrote this date. Do **not**
-       PUT-overwrite. Instead `PATCH /api/context/daily/YYYY-MM-DD.md`
-       with `mode=append_to_file` and a new section
-       `## Agent revision — YYYY-MM-DDTHH:MM:SS` whose body is the
-       synthesized journal. B-006 content-hash protection.
-
-### Step 6 — Generate new today.md (PUT full replace)
-9. Follow the context skill "Structure overview", "Entry formats", and
-   "Required sections for full replace" sections for the exact schema.
-   The H1 (line 1) MUST be `# <current_agent_day.date> (<current_agent_day.weekday>)`
-   exactly — the daemon rejects mismatches with 422. No YAML frontmatter
-   on today.md. Agent Plan rows MUST match
-   `- [ ] HH:MM <action> [work|study|personal|home] →<DM|notify|check-in|wake>`;
-   any other category or trigger keyword is rejected and forces a retry
-   on Sonnet.
-   Source → section mapping:
-   - ## User Schedule ← `<calendar_events_7d>` (filtered). Write
-     `- (calendar unavailable)` when the block has been replaced by
-     `<calendar_status>Calendar service not available...</calendar_status>`
-     (no active provider) or when every `<provider>` sub-block's
-     directive fetch failed for this run.
-   - ## User Tasks    ← Step 1 handoff Tomorrow + Step 2 email actionables
-     + SoT tasks + roadmap `[today]`. Use `<active_projects>` for context.
-   - ## Agent Plan    ← Step 2 `[notify]`/`[check]` rows plus any
-     proactive reminders you add (meeting pre-briefs, deadline nudges).
-     Every row will be registered in Step 7 — the Agent Plan contract is
-     defined in the skill's "User Tasks vs Agent Plan" section.
-   - ## Agent Notes   ← Step 2 look-ahead items + date-bound memos folded
-     from Step 4 inbox triage.
-   - ## Agent Log     ← initialize with
-     `- HH:MM Morning Routine completed (day-type: …)`.
-   - ## Handoff       ← Step 1 "Later" items, dropping past dates.
-     Write `- (none)` if empty.
-10. Update `roadmap.md` only if a milestone completed or shifted today.
-
-### Step 7 — Register schedule
-11. Register every `## Agent Plan` row via `POST /api/schedule` (schedule skill owns the contract). This is the Agent Plan contract — every
-    `- [ ] HH:MM … [cat] → <trigger>` row must have exactly one matching
-    schedule entry.
-> **Morning briefing scheduling moved.** The morning briefing is no
-> longer registered here. It is a `recurring_schedules` row
-> (`task_type='dm_session'`, `task_context.sub_flow='morning_briefing'`)
-> created at setup completion and reconciled daily by the daemon. The
-> firing session runs under the `conversational` profile via the
-> `scheduled.dm.md` task-flow. See SCHEDULED-DM-IMPLEMENTATION-PLAN.md.
-
-### Step 7.5 — Profile-interview queue (latent, two-phase)
-
-Use the **user-interview** skill. This step has two phases — phase (a)
-ALWAYS runs (it is what keeps today.md's ## Agent Notes mirror in sync
-across day boundaries, since today.md is PUT-replaced fresh each
-morning); phase (b) only runs when there is no open question.
-
-#### Step 7.5a — Mirror existing latent entries to today.md (always)
-
-GET `agent/profile-questions.md ## In Progress`. For every entry whose
-state is `latent` (NOT `asked` — those have already been answered or
-will be cleaned up by the sweep), append one line to `today.md`
-`## Agent Notes` using the **today** skill's "Latent profile question"
-Agent Notes flavor:
-
-```
-- Profile question (latent): <id> — wait for natural opportunity
-```
-
-This is the only writer of the `Profile question (latent):` line.
-Without it, a row
-that stays latent across multiple days disappears from today.md after
-day 1's PUT-replace and the DM-handler / morning-briefing opportunity
-checks lose their visible cue.
-
-#### Step 7.5b — Pick a new question (conditional)
-
-Skip phase (b) entirely if any of:
-  (a) `## In Progress` is non-empty (a prior latent / asked entry is
-      already open — we hold to the 1-question-at-a-time invariant).
-  (b) The user has not sent a DM in the last 24h (no point if they're
-      absent).
-  (c) Day-type focus for `[personal]` on line 2 of `<today>` is `off`.
-  (d) `## Pending` is empty.
-
-Otherwise, walk Pending rows in priority order (HIGH → MID → LOW, then
-file order). For each candidate:
-  - If the row carries `<!-- last_attempted=YYYY-MM-DD -->` within the
-    last 7 days, skip — cooldown.
-  - GET `/api/profile-questions/slot-filled?path=<target>&section=<section?>&anchor=<anchor?>`
-    for the row. If `filled: true`, the slot was filled since the last
-    sweep — tick the row `[ ]` → `[x]` (read-rebuild + replace), append
-    `- [x] <today> → <id> (reconciled:morning)` to `## Answered`,
-    continue to the next candidate.
-  - Otherwise this is the chosen row. Stop walking.
-
-If a row was chosen:
-
-1. PATCH `agent/profile-questions.md ## In Progress` (read-rebuild +
-   replace) — add a single entry. The `since=<today>` field is
-   load-bearing for the evening sweep's 3-day fallback computation:
-   ```
-   - <id> :: state=latent :: since=<today>
-   ```
-2. PATCH `today.md ## Agent Notes` (mode=append) — same flavor as
-   phase (a):
-   ```
-   - Profile question (latent): <id> — wait for natural opportunity
-   ```
-
-**Do NOT register a `POST /api/schedule` for this row.** Latent rows
-are NOT scheduled DMs — they wait for a natural opportunity (DM topic
-match or morning briefing piggyback). The fallback DM path is owned by
-the evening sweep (Operation 5B), not the morning routine.
-
-### Step 8 — Extension checks from routines/morning.md
-12. The `Morning routine checks` policy block above is the user-editable
-    extension surface. Execute any check listed there that is **not
-    already covered by Steps 1-7**. User-added entries typically carry an
-    `**Added: YYYY-MM-DD by user via DM**` line — those are your target.
-
-### Step 9 — Log to agent/journal.md (English, always)
-13. Append a one-paragraph English summary to `agent/journal.md` via
-    `PATCH /api/context/agent/journal` with `mode=append_to_file` (this
-    is the only append mode that takes no `section` argument — it's
-    designed for append-only journals). Use this shape:
-    ```
-    ## YYYY-MM-DD morning routine
-    - Day-type: <weekday / weekend / focus / …>
-    - Journal: daily/YYYY-MM-DD.md (<N lines, M projects referenced>)
-    - Inbox: <N files triaged, M moved to scratch, K DM-confirmations sent>
-    - Checks from routines/morning.md: <list any user-added ones executed>
-    - Anomalies / skipped steps: <short notes or "none">
-    ```
-    <output_language>english_only — Policy A surface (agent journal, parsed log); `<output_language_policy>` carves this out explicitly.</output_language>