@aitne-sh/aitne 0.1.7 → 0.1.8

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

@@ -1,204 +0,0 @@
-{context}
-
-## Task: Morning Routine — Initial run (no prior-day data)
-
-This is the first-boot variant of the B-007 §5.9 pipeline. No
-`yesterday.md` exists yet, so Steps 1 (handoff) and 5 (daily journal
-synthesis) are skipped. Everything else mirrors the standard morning
-routine. Follow the `context` skill for 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:
-- Do **not** add meta-maintenance tasks about context files, setup completion, or placeholder cleanup to User Tasks (there is no handoff to carry them from in the initial flow) 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 — Derive day-type (no handoff to read)
-1. Derive today's day-type header per the today skill "Header line —
-   day-type filter". Read `<user>` ## Notification Preferences for the
-   matching policy. Write the resulting line as line 2 of `today.md`.
-
-> **Date reference for today.md.** Take the H1 date from
-> `<current_agent_day date="…" weekday="…" />` in your prompt context, not
-> from `<current_time>`. They 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
-2. Mail and Notion acquisition. The pre-pass fetcher session
-   (`routine.fetch_window`) ran ahead of you and posted observations
-   for every active mail / notion integration. 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.
-
-   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 actionable item into a category tag and drop any
-      whose day-type focus is `off`. When `summary_text` is NULL fall
-      back to a one-line snippet from `payload.raw`. Mail data arrives
-      here regardless of integration mode — the pre-pass partial
-      handled the wire surface.
-
-   b. **Notion observations**:
-      `GET /api/observations?pending=true&source_prefix=notion:&limit=20`.
-      Use for project / decision context only.
-
-   c. **Calendar context** is already injected as `<calendar_events_7d>`
-      (multi-provider) ahead of this prompt — reference the block
-      directly in Step 6.
-
-   Skip the entire step when no integrations are active and no mail /
-   notion observations are pending.
-3. Source-of-Truth tasks: read `<management_rules>` ## Source of Truth →
-   Tasks, call the matching endpoint, drop filtered-off items.
-4. Roadmap ## Agent Action Plan — process items dated today or overdue:
-   - `[notify]` → `POST /api/schedule` + one row in ## Agent Plan
-   - `[today]`  → collect for ## User Tasks
-   - `[check]`  → `POST /api/schedule` (check-in) + one row in ## Agent Plan
-   - Mark processed items with ✓ via `PATCH /api/context/roadmap`,
-     `section=agent_action_plan`, `mode=replace`.
-   Generate look-ahead entries for tomorrow → +3 days (roadmap vs
-   `<calendar_events_7d>`) into ## Agent Notes using the skill's "Agent
-   Notes flavor 1: Look-ahead checklist" format.
-
-### Step 3 — Review overnight user-originated observations
-5. `GET /api/observations?pending=true&actor=user` (observations skill).
-   This is the user-actor complement to Step 2 — mail / notion rows
-   posted by the partials carry `actor=agent` and have already been
-   folded in. Step 3 picks up user-originated changes (manual file drops,
-   Obsidian edits, git commits) recorded under `actor=user`. Fold only
-   meaningful changes into the draft.
-
-### Step 4 — Inbox triage
-6. `GET /api/context/list/inbox` to enumerate any pasted memos the user
-   dropped during setup. For each file: `GET /api/context/inbox/<file>`,
-   classify (project / user / memo / task), integrate into the matching
-   target. After integration, `PUT /api/context/agent/scratch/inbox-YYYY-MM-DD-<slug>.md` with the original body, then `DELETE /api/context/inbox/<file>`. DM-confirm high-risk cases (new project creation, user-profile overwrites, financial or health numerics). **Hard stop**: if a memo contains anything that looks like a credential, password, API key, or private token, skip it — do NOT write it anywhere, log `- HH:MM [inbox] skipped <file>: secret suspected`, leave the file in `inbox/`, and move on (overrides the DM-confirm path; see _safety.md).
-
-### Step 5 — Skipped (no prior day to synthesize from)
-Journal synthesis is deferred to the next morning run. The first
-`daily/*.md` file is generated tomorrow.
-
-### Step 6 — Generate today.md (PUT full replace)
-7. Follow the context skill "Structure overview", "Entry formats", and
-   "Required sections for full replace". 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>`.
-   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 2 email actionables + SoT tasks + roadmap
-     `[today]`. Use `<active_projects>` for context. Drop meta-maintenance.
-   - ## Agent Plan    ← Step 2 `[notify]`/`[check]` rows plus any
-     proactive reminders you add. Each row will be registered in Step 7.
-   - ## Agent Notes   ← Step 2 look-ahead items + any date-bound memos
-     folded from Step 4 inbox triage.
-   - ## Agent Log     ← initialize with
-     `- HH:MM Morning Routine (initial) completed (day-type: …)`.
-   - ## Handoff       ← `- (none)` (no carry-over data available).
-8. **Populate `roadmap.md` inline (initial-day variant).** On the very first
-   morning routine the setup wizard's skeleton roadmap is still in place
-   (the `## Annual Goals`, `## Quarterly Focus`, and `## Agent Action Plan`
-   sections all contain the placeholder line `_(Not yet configured)_`).
-   When *any* of those placeholders is still present, run a full populate
-   per the `roadmap` skill — same forward-90-day scope as
-   `routine.roadmap_refresh` (Annual Goals from the management rules,
-   Quarterly Focus from active projects + `<calendar_events_7d>`,
-   Preparation Timeline from `travel_bookings` + dated calendar items,
-   Agent Action Plan seeded from User Tasks + roadmap-relevant
-   `agent_schedule` rows). Acquire the cross-request write lock via the
-   skill before any `PUT /api/context/roadmap` — the daemon enforces it
-   and a missing lock returns 423. If every placeholder has already been
-   replaced (rare: a previous initial run completed Step 6.8 then today.md
-   failed, or a manual edit landed), fall back to the regular
-   morning-routine semantics: spot-update only if a milestone completed
-   or shifted. Skipping this step leaves roadmap.md as the skeleton — the
-   daemon's `isRoadmapStale()` post-hook then schedules a separate
-   `routine.roadmap_refresh` to make it good, but the user will see a
-   blank-looking roadmap until that second session lands. Doing it inline
-   here is one Sonnet/Opus turn instead of two and removes ~1–2 minutes
-   of post-setup latency.
-
-### Step 7 — Register schedule
-9. Register every `## Agent Plan` row via `POST /api/schedule`.
-10. **Ensure the daily morning briefing recurring schedule exists.**
-    The setup wizard's `ensureMorningBriefingRecurring` (`packages/daemon/src/api/routes/setup.ts`)
-    normally seeds this row at first save-rules, so the daily fire
-    path is daemon-owned and the description is hardcoded. The check
-    below covers the rare case where setup completed without the
-    seeder (legacy setup, partial DB restore).
-
-    a. **Pre-flight.** `GET /api/recurring-schedules?enabled=true` and
-       scan for an item with `taskType === "dm_session"` AND
-       `taskContext.sub_flow === "morning_briefing"`. If found, skip
-       the rest of this step — duplicate insertion would cause double
-       daily fires. Log one line to `## Agent Log`:
-       `- HH:MM [morning_routine_initial] morning briefing recurring already seeded`.
-
-    b. **If absent, register via `POST /api/recurring-schedules`** with
-       this body (NOT `POST /api/schedule`):
-       ```json
-       {
-         "taskType": "dm_session",
-         "description": "morning briefing — daily summary",
-         "recurrenceRule": {
-           "frequency": "daily",
-           "time": "<quiet_hours_end or 08:00>",
-           "timezone": "<user timezone from <settings primary_timezone> or system default>"
-         },
-         "taskContext": {
-           "sub_flow": "morning_briefing",
-           "pin_to_quiet_hours_end": true
-         }
-       }
-       ```
-       The `dm_session` task_type + `sub_flow=morning_briefing` is the
-       activation key the daemon's scheduler keys off to emit a
-       `scheduled.dm` event (see `scheduler.ts` and the sub-flow
-       router in `scheduled.dm.md`). Description ≥ 20 chars per the
-       schema; `"morning briefing — daily summary"` matches the
-       wording the daemon's seeder uses verbatim.
-
-    Do **not** add a one-off `## Agent Plan` row for today's briefing
-    here. The recurring-schedule reconciler (poll loop in
-    `scheduler.ts`) materialises today's `agent_schedule` row
-    automatically from `next_run_at`; hand-seeding would duplicate.
-    Do **not** send the briefing yourself from this run — this runs
-    during quiet hours.
-
-### Step 8 — Extension checks from routines/morning.md
-11. Execute any check from the `Morning routine checks` policy block that
-    is not already covered by Steps 1-7 (typically user-added entries
-    with an `**Added:** ...` line).
-
-### Step 9 — Log to agent/journal.md (English, always)
-12. Append a one-paragraph English summary to `agent/journal.md` via
-    `PATCH /api/context/agent/journal` with `mode=append_to_file`:
-    ```
-    ## YYYY-MM-DD morning routine (initial)
-    - Day-type: …
-    - Journal synthesis: skipped (no prior-day data)
-    - 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">
-    ```
-    Always English (B-007 §3 P6).