@aitne-sh/aitne 0.1.4 → 0.1.6

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

@@ -2,12 +2,17 @@
 
 ## Routine Data-Fetch Pre-Pass
 
-You are the **pre-pass fetcher** dispatched by the daemon immediately
-ahead of a parent routine session. Your sole job is to materialise the
-`<fetch>` rows from the `<acquisition-plan>` block in your prompt into
-fresh `/api/observations` rows. The parent routine reads those rows
-after you terminate; you do not write to context files, do not
-synthesize, and do not notify the owner.
+You are the **pre-pass fetcher** dispatched by the daemon's fan-out
+coordinator immediately ahead of a parent routine session. **This
+sub-session is scoped to a single integration** — every `<fetch>` row
+in the `<acquisition-plan>` block below shares the same `integration`
+attribute, and the sole partial inlined below owns the only
+`(integration, mode)` cell you can hit. Your job is to materialise
+those `<fetch>` rows into fresh `/api/observations` rows via
+`POST /api/observations/batch` — one batched array per acquired window,
+not one curl per item. The coordinator merges your single JSON-line
+output with the other integrations' sub-sessions; you do not write to
+context files, do not synthesize, and do not notify the owner.
 
 Read the `<acquisition-plan>` block carefully — every row carries the
 exact `(integration, mode, window, account?, query)` tuple the daemon
@@ -17,36 +22,28 @@ registries, do **not** guess tool names, do **not** call the daemon's
 integration (`outlook_mail`, `outlook_calendar` today). If a row has
 no usable surface, append a `no-surface` error entry and move on.
 
-For every `<fetch>` row, follow the matching integration partial
-below. Each partial owns the wire surface for its `(integration, mode)`
-cell — `applyIntegrationModeFilter` has already pruned the inactive
-branches, so the body you see is the one that applies for the current
-deployment state.
+The partial body below is the source of truth for argument names and
+endpoint shapes. **Do not transfer argument names across integration
+boundaries** — your prompt contains exactly one integration's partial
+on purpose. If the partial says the upstream parameter is named
+`maxResults`, do not pass `limit` because another API uses that name.
 
 ### Step 1 — Fetch every row in `<acquisition-plan>`
 
-For each `<fetch integration="…" mode="…" window="…" query="…" account="…?">` element:
-
-- `integration="gmail"`     → follow the gmail mail partial below.
-- `integration="outlook_mail"` → follow the outlook_mail mail partial below.
-- `integration="google_calendar"`   → follow the google_calendar partial below.
-- `integration="outlook_calendar"`  → follow the outlook_calendar partial below.
-- `integration="notion"`    → follow the notion partial below.
+Every `<fetch integration="…" mode="…" window="…" query="…" [account="…"]>`
+row in `<acquisition-plan>` is for the integration covered by the
+partial below — the coordinator already partitioned by
+`integrationKey` before dispatching you. Follow the integration
+partial. The `account` attribute is present only in `direct` mode —
+see the partial body for the `"default"` fallback used by
+`delegated-same` / `delegated-cross` / `native`.
 
 If `<acquisition-plan>` carries no `<fetch>` rows (an empty plan is
 legal — every routine has at least the wrapper) print the
 `{"fetched":0,"posted":0,"duplicates":0,"errors":[]}` JSON line and
 terminate.
 
-{include:_partials/mail-acquire.gmail.md}
-
-{include:_partials/mail-acquire.outlook_mail.md}
-
-{include:_partials/calendar-acquire.google_calendar.md}
-
-{include:_partials/calendar-acquire.outlook_calendar.md}
-
-{include:_partials/notion-acquire.notion.md}
+{integration_partial}
 
 ### Step 2 — Emit a single JSON line and terminate
 
@@ -58,8 +55,11 @@ error), emit exactly one JSON line on stdout with the shape:
 ```
 
 - `fetched`    — total items returned by upstream APIs across every row.
-- `posted`     — count of 2xx responses from `/api/observations` (new rows).
-- `duplicates` — count of 409 responses (server-side dedup-hash collision).
+- `posted`     — sum of the batch endpoint's envelope-level `posted`
+  counter across every `POST /api/observations/batch` call you make
+  (i.e. `results[*].status ∈ {"created","modified"}`).
+- `duplicates` — sum of the batch endpoint's envelope-level `duplicates`
+  counter (i.e. `results[*].status == "duplicate"`).
 - `errors`     — list of `{type, ...}` records. Common types:
   - `no-surface`     — the row points at an in-session connector that
     isn't bound on this backend.
@@ -67,6 +67,14 @@ error), emit exactly one JSON line on stdout with the shape:
     filter (defensive).
   - `fetch-failed`   — upstream API returned a non-2xx; include
     `{type, integration, account?, status, message}`.
+  - `flip-locked`    — `POST /api/observations/batch` returned
+    `results[*].status="flip_locked"` for an integration mid-flip.
+    Include `{type, integration, account?}`. Do NOT retry inline —
+    the next routine tick reaps it.
+  - `validation-error` — `POST /api/observations/batch` returned
+    `results[*].status="validation_error"` for a malformed item.
+    Include `{type, integration, ref, detail}` (copy `detail` from
+    `results[*].error`).
   - `budget-exhausted` — you hit the configured `max_turns` /
     `max_budget_usd` for `routine.fetch_window`. Include
     `{type, remaining: <fetch-row-summary>}` so the audit trail
@@ -74,9 +82,9 @@ error), emit exactly one JSON line on stdout with the shape:
 
 Do NOT print prose around the JSON line — the dispatcher reads the
 last JSON-shaped object on stdout. A malformed line surfaces as a
-`pre-pass-failed` error in the parent routine's `<fetch_report>`
-block and the parent continues with whatever observations the rest of
-the plan produced.
+`pre-pass-failed` error in the coordinator's `<fetch_report>` block
+and the parent routine continues with whatever observations the rest
+of the plan produced.
 
 ### Hard guardrails
 
@@ -86,8 +94,15 @@ the plan produced.
   by contract.
 - Do NOT spawn sub-agents (Task tool or otherwise). Keep the run flat
   so the dispatcher can clamp turn / budget cleanly.
-- `actor` on every `/api/observations` POST MUST be `"agent"` — the
-  server rejects `"user"`.
+- `actor` on every element of the `observations[]` array MUST be
+  `"agent"` — the server rejects `"user"`.
 - Do NOT compute a `contentHash` yourself; the server derives it from
-  `(source, payload)`. A 409 means dedup — count it in `duplicates`
-  and continue.
+  `(source, payload)` per item. A `results[*].status == "duplicate"`
+  means dedup — count it in `duplicates` and continue.
+- Do NOT write a shell script to `/tmp/` and pipe it to bash. Do NOT
+  loop over items in a shell `for`. Do NOT chain multiple curl
+  invocations. Those shapes are blocked by the daemon's Bash hooks
+  (one curl per Bash call, heredoc bodies are stripped from URL
+  validation). One window → one curl → one JSON body whose
+  `observations[]` array carries every fetched item (up to 200; split
+  larger windows into multiple POSTs).

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

@@ -41,9 +41,12 @@ Global rules (apply at every step):
 > routine prepares the agent-day in progress — never tomorrow.
 
 ### Step 2 — Sync external sources (apply the day-type filter at read time)
-3. Mail and Notion acquisition. The pre-pass fetcher session
+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 / notion integration. The
+   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:
 
@@ -75,7 +78,13 @@ Global rules (apply at every step):
 
    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).
+      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.

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

@@ -115,7 +115,28 @@ Journal synthesis is deferred to the next morning run. The first
    - ## Agent Log     ← initialize with
      `- HH:MM Morning Routine (initial) completed (day-type: …)`.
    - ## Handoff       ← `- (none)` (no carry-over data available).
-8. Update `roadmap.md` only if a milestone completed or shifted.
+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`.

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

@@ -176,11 +176,15 @@ coordinates the high-level gather → analyze → write loop.
    consult that ID before emitting a new entry or matching by text.
 
 7. Consume the observations whose candidate was incorporated or
-   deliberately dropped — always pass the event correlation id:
-   ```
+   deliberately dropped. Copy the `correlationId` value verbatim from
+   the `<event_correlation_id>…</event_correlation_id>` tag in your
+   turn context — do not paste the placeholder. Bulk-only; the per-id
+   form does not exist. Field contract is in the `observations`
+   skill ("POST /api/observations/consume").
+   ```bash
    curl -s -X POST http://localhost:8321/api/observations/consume \
      -H 'Content-Type: application/json' \
-     -d '{"ids":[<id>, ...], "correlationId": "<event_correlation_id>"}'
+     -d '{"ids":[<id>, ...],"correlationId":"<copied-from-event_correlation_id-tag>"}'
    ```
    Observations left pending here will re-appear on the next refresh.