@aitne-sh/aitne 0.1.9 → 0.1.11

package/agent-assets/skills/management-policy/SKILL.md

@@ -13,7 +13,11 @@ agent to keep applying. It is NOT a one-off task.
 
 Each policy lives at `policies/management-captures/<slug>.md` and may link to:
 
-- `policies/routines/custom/<slug>.md` — the cron-driven execution rulebook
+- a recurring **Agent** (`policies/agents/<slug>/agent.md`, created via
+  `POST /api/agents`) — the cron-driven execution vehicle, recorded in the
+  policy frontmatter under `linked.routine` (legacy field name; the value is
+  the Agent slug — legacy `policies/routines/custom/` files no longer fire
+  and were auto-converted to same-slug Agents at upgrade).
 - `knowledge/dossiers/<topic>.md` — where the policy's accumulating data lands
 
 A readable summary of every policy lives at `policies/management-captures/_index.md`,
@@ -69,8 +73,8 @@ curl -s "http://localhost:8321/api/context/list/policies"
 ```
 
 If the listing and `_index.md` rows disagree, **prefer the listing**
-and trust the next reconcile pass to refresh the index. Do **not**
-hand-PATCH `_index.md` to fix the drift — that just creates more churn.
+and trust the next reconcile pass to refresh the index (`_index.md` is
+reconciler-owned — see body intro).
 
 ### Step 2 — Detect similarity
 
@@ -79,7 +83,7 @@ Heuristics to compare against existing policies:
 | Signal | Likely interpretation |
 |---|---|
 | Same `linked.dossier` topic | Likely a duplicate or extension of an existing policy |
-| Same cron expression on the linked routine | Likely a duplicate cadence |
+| Same cron expression on the linked Agent | Likely a duplicate cadence |
 | Slug stem matches an existing slug ("finance", "inbox", …) | Likely related |
 
 If a candidate matches, ask the user **before** creating:
@@ -110,12 +114,13 @@ saved. The slug must:
 - equal the filename stem
 - match `^[a-z0-9][a-z0-9-]*[a-z0-9]$` (or a single `[a-z0-9]`)
 - be ≤ 64 chars
-- equal the linked `policies/routines/custom/<slug>.md` slug (if any) — keep
-  them aligned in v1
+- equal the linked Agent's slug (if any) — keep them aligned in v1; Agent
+  slugs must start with a lowercase letter, so avoid digit-first slugs when
+  scheduling.
 
 ### Step 5 — Wire the dependencies (strict order; on failure, roll back in reverse)
 
-5.1 dossier → 5.2 routine → 5.3 policy file → 5.4 (auto-index — no
+5.1 dossier → 5.2 Agent → 5.3 policy file → 5.4 (auto-index — no
 manual step). Each step gates the next. The full curl recipes,
 when-to-skip rules, and rollback table are in the policy-workflow
 reference below.
@@ -152,13 +157,12 @@ the active policies first and ask.
    `updated: <today>`, PUT back. (The frontmatter parser is
    line-scalar so a per-field PATCH section call would not target a
    frontmatter key — always GET-merge-PUT for frontmatter edits.)
-2. If `linked.routine` is set: GET `policies/routines/custom/<slug>`, flip
-   frontmatter `enabled: false`, PUT back. The reload hook flips the
-   cron job off automatically.
+2. If `linked.routine` is set: `PATCH /api/agents/<slug>` with
+   `{"enabled": false}`. (User Agents stop without a warning ack; the
+   scheduler's fire-time gate takes effect immediately.)
 
-The policy-index reconciler picks the change up on the FS event and
-re-renders both `_index.md` and the management.md section within
-~10 s. Do not PATCH them manually.
+The policy-index reconciler re-renders both `_index.md` and the
+management.md section within ~10 s (reconciler-owned — see body intro).
 
 If step 2 fails after step 1 succeeded, **attempt to roll back step 1**
 (`status` back to `active`). If the rollback itself fails, report the
@@ -166,20 +170,22 @@ partial state to the user and tell them which file is in which state.
 
 ### Resume
 
-Same fan-out, with `status: active` and `enabled: true`.
+Same fan-out, with `status: active` and `PATCH /api/agents/<slug>`
+`{"enabled": true}`.
 
 ### Remove
 
 1. GET the policy file, flip frontmatter `status: removed` and
    `updated: <today>`, PUT back.
-2. If `linked.routine` is set: `DELETE
-   /api/context/policies/routines/custom/<slug>` (whitelisted).
+2. If `linked.routine` is set: `DELETE /api/agents/<slug>` with body
+   `{"keep_history": false}` — removes the Agent definition, schedule,
+   and execution history (the default `true` would merely disable it).
 
 The reconciler moves the row from `## Active` to `## Removed`
 automatically — the `removedAt` cell is read from the policy file's
 `updated` field, which step 1 set to today.
 
-The policy file itself is **kept for history** — DELETE on `rules/*`
+The policy file itself is **kept for history** — DELETE on `policies/management-captures/*`
 is intentionally not whitelisted (see MANAGEMENT-POLICY-CAPTURE-PLAN
 §5.1).
 
@@ -187,11 +193,10 @@ is intentionally not whitelisted (see MANAGEMENT-POLICY-CAPTURE-PLAN
 
 - Does NOT touch `policies/management.md` body sections (Source of Truth
   table, Notification Rules, Schedule, etc.). Those are wizard-only.
-- Does NOT create rows in the `recurring_schedules` DB table — defer to
-  `policies/routines/custom/` for cron, which gives the user a visible MD file
-  to edit.
-- Does NOT migrate existing custom routines into policy files
-  retroactively. Migration is a separate one-time operation.
+- Does NOT write `recurring_schedules` rows or `agent.md` files by hand —
+  scheduling goes through `POST /api/agents`, which materialises the
+  user-visible `policies/agents/<slug>/agent.md` and pairs the schedule row
+  itself.
 
 ## Cross-skill pointers
 
@@ -217,17 +222,20 @@ skill targets these paths:
 - `GET /api/context/list/policies` (Step 1 authoritative — entries prefixed `management-captures/`)
 - `GET /api/context/policies/management-captures/<slug>` (read before pause / resume / remove)
 - `PUT /api/context/knowledge/dossiers/<topic>` (Step 5.1 — if new)
-- `PUT /api/context/policies/routines/custom/<slug>` (Step 5.2 — if scheduling)
+- `POST /api/agents` (Step 5.2 — if scheduling; the only non-context call)
 - `PUT /api/context/policies/management-captures/<slug>` (Step 5.3)
 - `PATCH /api/context/policies/management-captures/<slug>` (pause / resume / remove; frontmatter via GET-merge-PUT only — line-scalar parser)
-- `DELETE /api/context/policies/routines/custom/<slug>` (remove only)
+- `PATCH /api/agents/<slug>` (pause / resume — `{"enabled": …}`)
+- `DELETE /api/agents/<slug>` (remove only — `{"keep_history": false}`)
 
 `policies/management-captures/_index.md` and the `## Active Policies` section in
-`policies/management.md` are written by the daemon's policy-index
-reconciler — they are NOT in the agent's write surface for this skill.
+`policies/management.md` are reconciler-owned (see body intro) — NOT in
+the agent's write surface for this skill.
 
-Frontmatter validation enforces `kind: policy`, `owner: agent`, and
-the slug rules in Step 4. Malformed writes return 422 with the failing
+Frontmatter validation enforces `type: rule`, `kind: policy`,
+`owner: agent`, `status`, `created_at` (YYYY-MM-DD), `origin`,
+`updated` (ISO), an H1, and the slug rules in Step 4 — see 5.3 for the
+full required set. Malformed writes return 422 with the failing
 field — surface that text to the user verbatim rather than retrying
 blindly.
 

package/agent-assets/skills/management-policy/curation.json

@@ -6,7 +6,7 @@
       "kind": "knowledge_layout",
       "anchor": "<!-- CURATION:knowledge_layout id=\"policy-file-shape\" -->",
       "human_label": "Policy file section shape",
-      "description": "Required sections inside rules/policies/<slug>.md and what each holds",
+      "description": "Required sections inside policies/management-captures/<slug>.md and what each holds",
       "scope_paths": ["policies/management-captures/*.md"]
     }
   ]

package/agent-assets/skills/management-policy/references/policy-workflow.md

@@ -1,10 +1,10 @@
 ---
 kind: reference
 name: policy-workflow
-description: Step 5.1-5.4 dossier → routine → policy file → auto-index fan-out, with curl recipes and rollback ordering.
+description: Step 5.1-5.4 dossier → Agent → policy file → auto-index fan-out, with curl recipes and rollback ordering.
 ---
 
-# Step 5 fan-out — dossier → routine → policy file → auto-index
+# Step 5 fan-out — dossier → Agent → policy file → auto-index
 
 Each step gates the next. If step `N` fails, attempt to roll back
 steps `N-1 … 1` in reverse before reporting the failure to the user.
@@ -24,18 +24,29 @@ Skip this step if `linked.dossier` is not set or the dossier already
 exists. The dossier file is data only — no harm if it ends up empty
 when the rest of the flow rolls back.
 
-## 5.2 Create the custom routine (only if scheduling is needed)
+## 5.2 Create the execution Agent (only if scheduling is needed)
 
 ```bash
-curl -sS -X PUT http://localhost:8321/api/context/policies/routines/custom/<slug> \
+curl -sS -X POST http://localhost:8321/api/agents \
   -H 'Content-Type: application/json' \
   -d @- <<'JSON'
-{"content":"---\ntype: rule\nslug: <slug>\nprocess_key: routine.custom.<slug>\ncron: \"0 7 * * *\"\nbackend_tier: light\nmax_budget_usd: 0.20\nenabled: true\n---\n# <Title>\n\n## Checks\n\n### <step label>\n**Action**: …\n"}
+{
+  "slug": "<slug>",
+  "name": "<Title>",
+  "description": "Scheduled enforcement for management policy <slug>.",
+  "schedule": { "kind": "cron", "expression": "0 7 * * *" },
+  "backend": { "tier": "lite" },
+  "limits": { "max_budget_usd": 0.20 },
+  "prompt": "# <Title>\n\n## Checks\n\n### <step label>\n**Action**: …"
+}
 JSON
 ```
 
-The route's `onCustomRoutinesChanged` hook reloads the cron scheduler
-automatically — no separate reload call.
+The `prompt` becomes the Agent's task body verbatim; the daemon writes the
+user-visible `policies/agents/<slug>/agent.md` and pairs the recurring
+schedule row itself — no reload call needed. A 409 means the slug is taken
+(go back to Step 2 dedup); a 400 `invalid_definition` returns the failing
+field — surface it verbatim.
 
 Skip this step if the policy is purely passive (e.g. "from now on,
 when the user mentions X in DM, also …"). The policy file itself
@@ -68,19 +79,20 @@ needed.
 
 The `linked:` mapping uses nested YAML for human / LLM readability.
 The daemon's frontmatter validator does not parse nested keys, but
-the **policy-index reconciler does** — it reads `linked.routine` to
-populate the cadence column (by reading the routine file's `cron`
-field) and `linked.dossier` for the dossier column. Keep the slug
-values aligned with the filenames you created at 5.1 / 5.2 so the
-reconciler can resolve them.
+the **policy-index reconciler does** — it reads `linked.routine` (the
+Agent slug; field name kept from the pre-Agents era) to populate the
+cadence column (from `policies/agents/<slug>/agent.md`'s schedule
+expression, falling back to a legacy `policies/routines/custom/<slug>.md`
+cron) and `linked.dossier` for the dossier column. Keep the slug values
+aligned with what you created at 5.1 / 5.2 so the reconciler can
+resolve them.
 
 ## 5.4 _(no manual step required)_
 
-`policies/management-captures/_index.md` is auto-maintained by the daemon's
-policy-index reconciler — it re-renders within ~10 s of step 5.3's
-write. Same for the `## Active Policies` section in
-`policies/management.md`. **Do not PATCH or PUT either path manually**;
-doing so just races the reconciler and creates snapshot churn.
+Both `policies/management-captures/_index.md` and the `## Active Policies`
+section in `policies/management.md` are reconciler-owned and re-render
+within ~10 s of step 5.3's write (see SKILL.md body intro — no manual
+PATCH/PUT).
 
 If you need to confirm the index is up to date before replying to the
 user, GET `policies/management-captures/_index` after a short wait. The
@@ -92,7 +104,7 @@ reconciler's last-run record lives at `runtime_state` key
 | Failure at | Roll back |
 |---|---|
 | 5.2 | undo 5.1 — the dossier path does **not** accept `DELETE` (`knowledge/dossiers/*` is PUT/PATCH only; a `DELETE` returns `403 context.write_forbidden`). If you created it new, PUT it to empty content / `status: removed`; an empty dossier is harmless (per 5.1). Leave a pre-existing dossier untouched. |
-| 5.3 | undo 5.2 (PUT routines file back to `enabled: false` and the next reconcile clears the cron job; or `DELETE` if you created it new — `policies/routines/custom/*` is DELETE-whitelisted), then undo 5.1 as above |
+| 5.3 | undo 5.2 — `DELETE /api/agents/<slug>` with `{"keep_history": false}` (you created it new at 5.2, so a hard delete leaves no orphan), then undo 5.1 as above |
 | 5.4 | none required — there is no manual 5.4. If the reconciler does not pick the change up within ~30 s, surface the diagnostics record (`runtime_state` key above) to the user rather than rolling back. |
 
 If any rollback step itself fails, **report the partial state to the

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

@@ -41,10 +41,9 @@ language-agnostic** — it applies whatever language the agent uses
 with the user.
 
 Anti-examples (non-exhaustive — the positive rule above is
-load-bearing, not this list): "Good morning!", "Evening check-in —",
-"Morning briefing —", "Summary:", "Done.", "Sent.", "OK.", "Here's
-your day:", "Heads-up —", "FYI:", "Quick update:". Near-synonyms of
-these in any language also fail the positive rule.
+load-bearing, not this list): "Good morning!", "Summary:", "Done.",
+"Heads-up —". Near-synonyms of these in any language also fail the
+positive rule.
 
 ### No internal mechanism names
 
@@ -56,9 +55,8 @@ user-visible text. Those go in Agent Log only.
 
 ### No filler timing commentary
 
-Forbidden — "Just a heads-up", "Still about N hours to go", "About N
-hours left", "FYI". If timing matters, the deadline / event time
-itself carries it.
+Forbidden — "Just a heads-up", "About N hours left", "FYI". If timing
+matters, the deadline / event time itself carries it.
 
 ### No table-of-contents readback
 
@@ -96,16 +94,17 @@ Notify when **all three** are true: (1) **actionable** or requires awareness, (2
 - **A pending Agent Plan row / scheduled DM is already set to fire
   for this item within the next 2 hours** — let the planned channel
   deliver; don't pre-empt it.
-- **Quiet hours (default 22:00-08:00, configurable)** unless `critical` — schedule for after instead
-- **Over the rate-limit caps (3/hour, 12/day; `critical` bypasses both)** — do NOT spam-retry. The endpoint does NOT signal this: `/api/notify` returns `200 {status:"sent"}` even when quiet-hours or the rate-limit silently drops the message, so a `"sent"` response is not proof of delivery. Self-throttle by checking `<today>` `## Agent Log` before firing; if you suspect suppression, log the skip rather than re-posting. If time-critical, upgrade priority at next opportunity
+- **Already delivered this item** — a `200 {status:"sent"}` is proof of delivery and a `200 {status:"deferred_quiet_hours"}` is proof of queued delivery, so do NOT re-post on either. Self-throttle via `<today>` `## Agent Log` before firing and log the skip rather than re-posting. (The endpoint defers during quiet hours and enforces rate caps, but dedup and noise control are still your job.)
 - **Routine file changes** or **agent internal state** — use Agent Log instead
 - **When in doubt — prefer silence**
 
 ## Priority
 
 **Default to `normal`.** Reserve `high` for 8h-delay-matters. Reserve
-`critical` for 3am-matters. Full per-level table, examples, and
-rate-limit caps are in the priority reference below.
+`critical` for 3am-matters — it is the only level that bypasses the
+endpoint's quiet-hours deferral and rate caps; everything else is
+metadata recorded in the notification log. Full per-level table,
+examples, and delivery semantics are in the priority reference below.
 
 {{> ref:priority }}
 
@@ -120,5 +119,9 @@ curl -s -X POST http://localhost:8321/api/notify \
   -H 'Content-Type: application/json' \
   -d '{"message": "Design review starts in 15 minutes.", "priority": "normal"}'
 ```
-Fields: `message` (required, markdown), `priority` (optional: critical/high/normal/low), `platform` (optional, override target).
-Response: `{ "status": "sent", "notificationId": "..." }`. Risk tier: `Autonomous` — the agent decides when to notify; recorded in `notification_log` for the on-demand retrospective.
+Fields: `message` (required, markdown), `priority` (optional: critical/high/normal/low), `platform` (optional, override target) OR `platforms` (optional, array of targets) — mutually exclusive, not both.
+Responses:
+- `200 { "status": "sent", "notificationId": "...", "dispatchId": "..." }` = delivered to ≥1 channel; a total delivery failure returns HTTP 500 (not a silent 200-drop).
+- `200 { "status": "deferred_quiet_hours", "scheduleId": "...", "deliverAfter": "..." }` = fired inside the user's quiet hours; queued as a scheduled DM that delivers at `deliverAfter`. Treat as delivered — do NOT re-post. If the item will be stale by then, `DELETE /api/schedule/{scheduleId}` and use `<today>` `## Agent Log` instead.
+- `429 { "status": "rate_limited", "retryAfter": "..." }` = hourly/daily notification cap spent; nothing sent or queued. Don't retry-loop — drop to `<today>` `## Agent Log`.
+`critical` priority bypasses both gates and always sends immediately. Risk tier: `Autonomous` — the agent decides when to notify; recorded in `notification_log` for the on-demand retrospective.

package/agent-assets/skills/notify/references/priority.md

@@ -1,20 +1,25 @@
 ---
 kind: reference
 name: priority
-description: Notification priority levels — critical / high / normal / low — with quiet-hours behavior and per-level examples.
+description: Notification priority levels — critical / high / normal / low — as metadata you set, with per-level usage examples.
 ---
 
 # Notification priority levels
 
-Pick the lowest priority that still preserves the user-visible
-behavior the message needs. **Default to `normal`.**
-
-| Priority | Quiet-hours | Use for |
-|---|---|---|
-| `critical` | Bypasses | Security alerts (credential leak, account lockout), data-loss risk (about to overwrite without backup, irreversible deletion in flight), system errors blocking the user from working. Wakes the user. |
-| `high` | Bypasses | Hard deadlines firing in the next 8 hours, urgent inbound messages from people the user has flagged as priority, "meeting starting now". User wants to see this even during quiet hours but not at 3 am. |
-| `normal` | Respects (dropped during quiet hours) | Regular reminders (`15 min until standup`), digest-style summaries, single-recipient FYIs the user opted into. **Default.** |
-| `low` | Respects (dropped during quiet hours) | Background updates, observational FYIs the user did not explicitly ask for, optional context. Often better as an Agent Log entry instead of a notification at all. |
+`priority` is a metadata field you set on the `/api/notify` call. It
+travels into `notification_log` and helps the user (and the
+retrospective) gauge how urgent each message was. One level changes
+delivery: `critical` bypasses the endpoint's quiet-hours deferral and
+rate caps and always sends immediately — every other level rides the
+gates below. Pick the lowest priority that still honestly describes
+the message. **Default to `normal`.**
+
+| Priority | Use for |
+|---|---|
+| `critical` | Security alerts (credential leak, account lockout), data-loss risk (about to overwrite without backup, irreversible deletion in flight), system errors blocking the user from working. The "wake the user at 3 am" tier. |
+| `high` | Hard deadlines firing in the next 8 hours, urgent inbound messages from people the user has flagged as priority, "meeting starting now". Important but not 3 am. |
+| `normal` | Regular reminders (`15 min until standup`), digest-style summaries, single-recipient FYIs the user opted into. **Default.** |
+| `low` | Background updates, observational FYIs the user did not explicitly ask for, optional context. Often better as an Agent Log entry instead of a notification at all. |
 
 ## Examples by level
 
@@ -47,19 +52,30 @@ If the next morning would still be soon enough, it is not `high`.
 If the user did not opt in to receiving this category of update, do not
 send `low`. Drop it to an Agent Log entry instead.
 
-## Rate-limit defaults
-
-3/hour, 12/day across all priorities (`critical` bypasses both caps).
-The agent CANNOT query `notification_log` directly (Approve-tier). Use
-`<today>` `## Agent Log` as the authoritative dedup source (look for
-`notify sent` / `DM sent` lines).
-
-`/api/notify` does NOT report rate-limit or quiet-hours suppression
-back to you — it returns `200 {status:"sent"}` even when the message is
-silently dropped inside the delivery layer. A `"sent"` response is
-therefore not proof the user saw it. Do NOT re-post the same item
-hoping for delivery; self-throttle by scanning `<today>` `## Agent Log`
-first and log `notify skipped (rate_limited)` when you choose to hold.
-If the message is time-critical and the next opportunity arises,
-upgrade to `high` (or `critical` if the situation has escalated)
-rather than re-sending at the same level.
+## Delivery semantics
+
+`/api/notify` returns one of three envelopes:
+
+- `200 {status:"sent", ...}` — delivered to at least one channel right
+  now. `"sent"` IS proof of delivery — do NOT re-post the same item on
+  a 200. A total delivery failure THROWS and surfaces as HTTP 500 (not
+  a silent 200-drop).
+- `200 {status:"deferred_quiet_hours", scheduleId, deliverAfter}` —
+  you fired inside the user's quiet hours; the message was queued as a
+  scheduled DM that delivers at `deliverAfter` (quiet-hours end).
+  Nothing was lost; do NOT re-post. Repeat calls from the same origin
+  coalesce into the same pending DM. If the item will be stale by
+  `deliverAfter`, `DELETE /api/schedule/{scheduleId}` and record it in
+  `<today>` `## Agent Log` instead. `critical` priority bypasses this
+  gate entirely.
+- `429 {status:"rate_limited", retryAfter}` — the proactive hourly or
+  daily notification cap is spent. Nothing was sent or queued. Do not
+  retry-loop; drop the item to `<today>` `## Agent Log` (or escalate
+  honestly to `critical` if it truly cannot wait).
+
+Noise control is still YOUR job, not the endpoint's. The agent CANNOT
+query `notification_log` directly (Approve-tier), so use `<today>`
+`## Agent Log` as the authoritative dedup source (look for `notify
+sent` / `DM sent` lines) and self-throttle before firing. Don't
+re-send the same item at the same level; if the situation has
+genuinely escalated, raise the priority metadata to reflect that.

package/agent-assets/skills/notion/SKILL.delegated.claude.md

@@ -29,7 +29,7 @@ delegated mode:
 
 ```bash
 curl -s http://localhost:8321/api/notion/databases
-# → { databases: { "<label>": { "id": "<uuid>", "title": "..." }, ... } }
+# → { databases: [ { "label": "<label>", "id": "<uuid>" }, ... ] }
 ```
 
 Resolve label → UUID here BEFORE the `/exec` call so your `task`

package/agent-assets/skills/notion/SKILL.delegated.codex.md

@@ -26,7 +26,7 @@ delegated mode:
 
 ```bash
 curl -sS http://localhost:8321/api/notion/databases
-# → { databases: { "<label>": { "id": "<uuid>", "title": "..." }, ... } }
+# → { databases: [ { "label": "<label>", "id": "<uuid>" }, ... ] }
 ```
 
 Resolve label → UUID here BEFORE the `/exec` call so your `task`

package/agent-assets/skills/notion/SKILL.delegated.gemini.md

@@ -26,7 +26,7 @@ delegated mode:
 
 ```bash
 curl -sS http://localhost:8321/api/notion/databases
-# → { databases: { "<label>": { "id": "<uuid>", "title": "..." }, ... } }
+# → { databases: [ { "label": "<label>", "id": "<uuid>" }, ... ] }
 ```
 
 Resolve label → UUID here BEFORE the `/exec` call so your `task`

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

@@ -14,11 +14,10 @@ Base URL: `http://localhost:8321`. All calls via `curl -s` with
 `Content-Type: application/json` on POST/PATCH/PUT. URL-encode spaces in paths.
 
 Full CRUD over Notion pages plus workspace search. Reads and writes are
-Autonomous; writes are still serialized per-process and pre-marked
-`notion:<pageId>` for write attribution. The daemon does not DM the
-owner before a write — the user's `deniedTools` setting is the gate.
-Call `POST /api/notify` yourself when you judge the user would
-want immediate awareness.
+Autonomous; writes are serialized per-process and pre-marked
+`notion:<pageId>` for attribution. The daemon does not DM the owner before
+a write — the `deniedTools` setting is the gate. Call `POST /api/notify`
+yourself when you judge the user would want immediate awareness.
 
 **Parent shorthand**: `parent` accepts a label string (`"tasks"`),
 `{ database: "tasks" }`, `{ data_source_id }`, `{ database_id }`, or
@@ -34,8 +33,10 @@ curl -s "http://localhost:8321/api/notion/search?q=launch+plan"             # se
 curl -s http://localhost:8321/api/notion/pages/abc123...                    # retrieve page
 ```
 
-Pagination: `page_size` (1–100, default 20) + `start_cursor` from response's
-`next_cursor`. Check `has_more` to know if more pages exist.
+Query also accepts `sorts` (URL-encoded JSON) alongside `filter`, and
+`in_trash=true` to query trashed rows. Pagination: `page_size` (1–100,
+default 20) + `start_cursor` from response's `next_cursor`; check
+`has_more` to know if more pages exist.
 
 ## Create a page (write — Autonomous)
 
@@ -55,12 +56,13 @@ curl -s -X PATCH http://localhost:8321/api/notion/pages/abc123... \
 
 ## Update page content (write — Autonomous)
 
-**Concurrency warning**: Notion v5 has no etags. If another client edits
-between GET and PATCH, `oldStr` may fail silently. For high-risk edits,
-prefer `mode=replace_all`.
+**Concurrency**: Notion v5 has no etags — if another client edits between
+GET and PATCH, `oldStr` may fail silently; for high-risk edits prefer
+`mode=replace_all`.
 
 Modes: `append`, `replace_all`, `update` (find-and-replace via
-`updates: [{oldStr, newStr}]`).
+`updates: [{oldStr, newStr}]`), `replace_range` (in-place swap of a line
+range; requires `content` + `contentRange`, optional `allowDeleting`).
 
 ```bash
 curl -s -X PATCH http://localhost:8321/api/notion/pages/abc123.../content \
@@ -78,11 +80,9 @@ Moves to trash (~30 days). Restore via `PATCH` with `{ "in_trash": false }`.
 
 ## When NOT to act
 
-- During `routine.hourly_check` this skill is **read-only** — no creates,
+- During `routine.activity_scan` this skill is **read-only** — no creates,
   property updates, content patches, or archives.
-- No bulk operations without user confirmation. If you're about to update
-  3+ pages at once, stop and ask the user first.
-- Writes are Autonomous; the daemon does not DM the owner. Single ops
-  only — the agent's own judgment is the gate, not the daemon. The
-  message-discipline contract for any `POST /api/notify` call you issue
-  here is in the `notify` skill — do not invent ad-hoc phrasing rules.
+- No bulk operations without user confirmation: about to touch 3+ pages,
+  stop and ask first. Single ops only.
+- For any `POST /api/notify` call you issue, the message-discipline
+  contract lives in the `notify` skill — do not invent ad-hoc phrasing.

package/agent-assets/skills/notion/SKILL.native.claude.md

@@ -42,7 +42,7 @@ connector arguments carry concrete UUIDs.
 
 ```bash
 curl -s http://localhost:8321/api/notion/databases
-# → { "databases": { "<label>": { "id": "<uuid>", "title": "..." }, ... } }
+# → { "databases": [ { "label": "<label>", "id": "<uuid>" }, ... ] }
 ```
 
 This route is **not** part of the absolute deny set and is intentionally
@@ -135,9 +135,9 @@ instead).
 
 ## 5. Decision rules
 
-- **Hourly check is read-only.** Native variants inherit the
+- **Activity scan is read-only.** Native variants inherit the
   "External services are read-only this hour" constraint from
-  `routine.hourly_check.native.claude.md`. No creates, property
+  `routine.activity_scan.native.claude.md`. No creates, property
   updates, content patches, or archives during the hourly pass.
 - **Mass-update — ask first.** A page-creation call can take up to
   100 pages in one shot, and move / update batches can touch many
@@ -151,7 +151,7 @@ instead).
 
 ## 6. Persisting observations from native fetches
 
-When `routine.hourly_check.native.claude.md`'s Step 0c fetches recent
+When `routine.activity_scan.native.claude.md`'s Step 0c fetches recent
 Notion edits, POST each materialised page to `/api/observations`. The
 daemon computes `contentHash` server-side via
 `@aitne/shared/observations-hash.ts`; pass `payload` verbatim.

package/agent-assets/skills/notion/SKILL.native.codex.md

@@ -36,7 +36,7 @@ the `<integration-routing-table>` block in the session preamble.
 
 ```bash
 curl -s http://localhost:8321/api/notion/databases
-# → { "databases": { "<label>": { "id": "<uuid>", "title": "..." }, ... } }
+# → { "databases": [ { "label": "<label>", "id": "<uuid>" }, ... ] }
 ```
 
 Resolve label → UUID before any Notion call so the connector arguments
@@ -110,8 +110,8 @@ Surface the choice to the user before issuing.
 
 ## 4. Decision rules
 
-- **Hourly check is read-only** — inherits the constraint from
-  `routine.hourly_check.native.codex.md`.
+- **Activity scan is read-only** — inherits the constraint from
+  `routine.activity_scan.native.codex.md`.
 - **Mass-update — ask first.** Batch page-creation can take up to 100
   pages; page-move and page-update batches can touch many rows.
   Summarise and confirm anything >~10 pages.

package/agent-assets/skills/notion/SKILL.native.gemini.md

@@ -46,7 +46,7 @@ the `<integration-routing-table>` block in the session preamble.
 
 ```bash
 curl -s http://localhost:8321/api/notion/databases
-# → { "databases": { "<label>": { "id": "<uuid>", "title": "..." }, ... } }
+# → { "databases": [ { "label": "<label>", "id": "<uuid>" }, ... ] }
 ```
 
 Resolve label → UUID before any Notion call.
@@ -114,8 +114,8 @@ Surface the choice to the user.
 
 ## 4. Decision rules
 
-- **Hourly check is read-only** — inherits the constraint from
-  `routine.hourly_check.native.gemini.md`.
+- **Activity scan is read-only** — inherits the constraint from
+  `routine.activity_scan.native.gemini.md`.
 - **Mass-update — ask first.** Batch page-creation can take up to 100
   pages; batches >~10 pages warrant explicit confirmation.
 - **Schema admin — Approve-tier.** Database / view / data-source