@aitne-sh/aitne 0.1.7 → 0.1.8

package/agent-assets/skills/managed-tasks/references/errors.md

@@ -0,0 +1,70 @@
+---
+kind: reference
+name: errors
+description: /api/managed-tasks error envelope — POST / PATCH / DELETE codes (validation_error, duplicate, cap_reached, invalid_id, not_found, internal_error).
+---
+
+# /api/managed-tasks error envelope
+
+Every endpoint returns the standard daemon error shape:
+
+```jsonc
+{
+  "error":   "<machine code>",
+  "message": "<human text — surface verbatim to the user>",
+  "details": [ /* Zod issue list when error === "validation_error" */ ],
+  "item":    { /* present on 409 duplicate — the existing row */ }
+}
+```
+
+`body.message` is intended for the user — preserve it verbatim. The
+daemon does NOT emit `cron_too_tight` (the recurrence schema only
+accepts daily / weekly / monthly, so sub-daily asks never reach the
+POST — refuse them client-side per the recurrence-rule reference) or
+`cadence_partial` (the recurrence rule is one structured field, so
+there is no partial-cadence shape to reject). A future schema gain
+would surface those codes for the first time; surface verbatim.
+
+## POST /api/managed-tasks
+
+| HTTP | `error` | When | What to do |
+|---|---|---|---|
+| 400 | `validation_error` | Body fails Zod (frequency unknown, time malformed, etc.) | Pick the offending field from `details[].path` and ask the user to clarify. |
+| 409 | `duplicate` | An existing row has the same `(app_normalized, cadence)` | DM `Already managed as <body.item.id>` and stop. The body's `item` is the existing row. |
+| 409 | `cap_reached` | §B already at the active-task cap (default 100) | Surface `body.message` (carries the cap value); user must stop something first. |
+| 5xx | `internal_error` | DB / cascade failure | DM "Couldn't register; daemon error. Try again, or check `aitne logs`." |
+
+## PATCH /api/managed-tasks/:id
+
+| HTTP | `error` | When | What to do |
+|---|---|---|---|
+| 400 | `invalid_id` | `:id` didn't match `^mt_[1-9]\d*$` | User typed the id wrong — ask them to repeat. |
+| 400 | `validation_error` | Body fails Zod (empty body, recurrenceRule.daysOfWeek on a `daily`, etc.) | Pin the failing path from `details[].path` and ask for a fix. |
+| 404 | `not_found` | No row for `:id` | DM "I don't have an `mt_<id>` to modify"; offer to register one. |
+| 5xx | `internal_error` | DB / cascade failure | Surface `body.message`; advise `aitne logs`. |
+
+## DELETE /api/managed-tasks/:id
+
+| HTTP | `error` | When | What to do |
+|---|---|---|---|
+| 400 | `invalid_id` | `:id` didn't match `^mt_[1-9]\d*$` | Ask the user to repeat. |
+| 404 | `not_found` | No row for `:id` | DM "No managed task with that id"; if you used a fuzzy match, re-list candidates. |
+| 5xx | `internal_error` | DB / cascade failure | Surface `body.message`; advise `aitne logs`. |
+
+## POST /api/managed-tasks/:id/run-now
+
+| HTTP | `error` | When | What to do |
+|---|---|---|---|
+| 400 | `invalid_id` | `:id` didn't match `^mt_[1-9]\d*$` | Ask the user to repeat. |
+| 404 | `not_found` | No row for `:id` | Cannot run a stopped task. |
+| 409 | `already_running` | A previous fire is still in flight | Tell the user; do NOT loop. |
+| 5xx | `internal_error` | Dispatcher / cascade failure | Surface `body.message`. |
+
+## Idempotency on POST
+
+Per-DM `Idempotency-Key` (recommended: SHA-256 of the inbound message
+id + app). Concurrent retries collapse to the same `mt_<n>`. A
+different key with the same `(app_normalized, cadence)` collides at
+the uniqueness check and the second POST returns `409 duplicate`
+with the existing `mt_id` — DM the user pointing at it rather than
+registering twice.

package/agent-assets/skills/managed-tasks/references/output-path.md

@@ -0,0 +1,75 @@
+---
+kind: reference
+name: output-path
+description: output_path grammar — `<domain>/<type-plural>/` only, trailing slash mandatory, no `..`, no leading `context/`. Daemon CHECKs at INSERT/UPDATE.
+---
+
+# output_path grammar
+
+The `output_path` field on `/api/managed-tasks` is the L2 directory
+under the primary context vault where the recurring fetch will write
+entity files. The daemon enforces the format with a CHECK constraint
+at INSERT / UPDATE time.
+
+## Format
+
+`<domain>/<type-plural>/`
+
+- Leading `context/` is **implicit** and must NOT be included; the
+  daemon prepends it.
+- The trailing `/` is **mandatory**.
+- No `..` segments. No absolute paths. No leading `/`.
+
+## Allowed values
+
+| Position | Allowed |
+|---|---|
+| `<domain>` | `work`, `travel`, `finance`, `personal`, `health`, `learning` |
+| `<type-plural>` | `meetings`, `trips`, `receipts`, `projects`, `books`, `notes` |
+
+Not every domain × type combination is meaningful in practice — pick
+the pair whose semantic prior best fits the fetch's data shape (see
+the §"Decide output path" table in the Register section of the skill
+body for the typical mapping).
+
+## Examples
+
+| Valid | Invalid | Why invalid |
+|---|---|---|
+| `work/meetings/` | `work/meetings` | Missing trailing `/` |
+| `finance/receipts/` | `/finance/receipts/` | Leading `/` |
+| `travel/trips/` | `context/travel/trips/` | Leading `context/` is implicit |
+| `learning/books/` | `random/dir/` | `<domain>` not in allowed set |
+| `personal/notes/` | `work/agendas/` | `<type-plural>` not in allowed set |
+| (path omitted) | `work/../etc/` | `..` segments rejected |
+
+## When to omit
+
+`output_path` is **optional** on POST. Omit when the data shape is
+genuinely ambiguous (e.g. the probe returned zero rows). The first
+scheduled run populates it from real data, and a subsequent PATCH
+back-fills the field if the user wants to pin it.
+
+## When to relocate
+
+A `PATCH /api/managed-tasks/:id` with a new `output_path` changes
+only the *future* runs — existing entity files written under the old
+path stay where they were. If the user wants reorganisation, stop
+the task, move the files manually (or ask the user to), and
+re-register.
+
+To clear an existing `output_path` back to "first run decides", send
+`{"output_path": null}` in the PATCH.
+
+## 422 envelope on rejection
+
+```json
+{
+  "error": "validation_error",
+  "message": "output_path 'work/meetings' is missing the trailing slash",
+  "field": "output_path"
+}
+```
+
+Surface the daemon's `message` verbatim — it names the exact rule
+that failed. Do not retry the same value.

package/agent-assets/skills/managed-tasks/references/recurrence-rule.md

@@ -0,0 +1,86 @@
+---
+kind: reference
+name: recurrence-rule
+description: recurrenceRule grammar — hourly / daily / weekly / monthly. Engine accepts all four; the managed-tasks consumer specifically refuses sub-daily for app-fetch correctness (template below).
+---
+
+# recurrenceRule grammar
+
+The daemon's recurrence engine accepts four frequencies: `hourly`,
+`daily`, `weekly`, `monthly`. Each frequency requires its own set of
+fields and rejects fields that don't apply — the daemon's Zod
+refinements return a `schedule.frequency_field_mismatch` issue (with
+the offending field path) when the shape disagrees with the chosen
+frequency. Pre-validate to save a round-trip.
+
+Times are `HH:MM` 24-hour local; `timezone` is IANA (auto-fills from
+daemon config when omitted, but explicit is safer so a roaming laptop
+does not surprise the user).
+
+## Engine — per-frequency field rules
+
+| `frequency` | Required | Allowed | Forbidden |
+|---|---|---|---|
+| `hourly` | — | `intervalHours` (1..23, default 1), `minuteOfHour` (0..59, default 0), `timezone` | `time`, `daysOfWeek`, `daysOfMonth`, `onMissingDay` |
+| `daily` | `time` | `timezone` | `intervalHours`, `minuteOfHour`, `daysOfWeek`, `daysOfMonth`, `onMissingDay` |
+| `weekly` | `time`, `daysOfWeek` | `timezone` | `intervalHours`, `minuteOfHour`, `daysOfMonth`, `onMissingDay` |
+| `monthly` | `time`, `daysOfMonth` | `timezone`, `onMissingDay` (default `lastDayOfMonth`) | `intervalHours`, `minuteOfHour`, `daysOfWeek` |
+
+- `daysOfWeek` is `0=Sun..6=Sat`; 1..7 distinct entries, dupes rejected.
+- `daysOfMonth` is `1..31`; 1..31 distinct entries, dupes rejected.
+  Days 29-31 may not exist in a given month — see `onMissingDay`.
+- `onMissingDay`: `"skip"` (don't fire that month) or
+  `"lastDayOfMonth"` (fire on the actual last day, preserving the
+  pre-redesign clamp behavior). Default `"lastDayOfMonth"` for
+  back-compat. The engine also de-duplicates calendar dates that
+  collapse to the same fire (e.g. `[28,31]` in non-leap Feb with
+  `"lastDayOfMonth"` fires Feb 28 once, not twice).
+- `intervalHours=N` fires when `(localHour % N) == 0` at
+  `minuteOfHour` local, anchored at midnight in the rule's
+  `timezone`.
+
+## Mapping table
+
+| User said | `cadence` | `recurrenceRule` |
+|---|---|---|
+| every hour | `hourly :00 (UTC)` | `{frequency:"hourly"}` |
+| every 2 hours at :30 | `hourly /2 :30 (UTC)` | `{frequency:"hourly", intervalHours:2, minuteOfHour:30}` |
+| every day at 10am (Asia/Tokyo) | `daily 10:00 (Asia/Tokyo)` | `{frequency:"daily", time:"10:00", timezone:"Asia/Tokyo"}` |
+| every Monday 9am | `weekly Mon 09:00` | `{frequency:"weekly", time:"09:00", timezone:<user tz>, daysOfWeek:[1]}` |
+| every weekday at 8am | `weekdays 08:00` | `{frequency:"weekly", time:"08:00", timezone:<user tz>, daysOfWeek:[1,2,3,4,5]}` |
+| 1st of every month at noon | `monthly day 1 12:00` | `{frequency:"monthly", time:"12:00", timezone:<user tz>, daysOfMonth:[1]}` |
+| 25th of every month at 21:00 | `monthly day 25 21:00` | `{frequency:"monthly", time:"21:00", timezone:<user tz>, daysOfMonth:[25]}` |
+| last day of every month at 21:00 | `monthly last 21:00` | `{frequency:"monthly", time:"21:00", timezone:<user tz>, daysOfMonth:[31], onMissingDay:"lastDayOfMonth"}` |
+| every 5 minutes | _not representable_ | _refuse — sub-hour cadences are not supported_ |
+
+## Consumer-specific refusal — managed-tasks only
+
+The managed-tasks skill (`mt_<n>` rows) refuses sub-daily cadences
+because app-fetch correctness requires a daily-or-coarser window to
+amortise rate limits and to map cleanly onto the entity-mirror's
+daily granularity. Schedule callers (`/api/schedule`,
+`/api/recurring-schedules`) have no such constraint and may use any
+of the four frequencies the engine accepts.
+
+### managed-tasks sub-daily refusal — DM template
+
+> Managed tasks only support daily, weekly, or monthly cadences.
+> "every hour" / "every 5 minutes" is too tight for a recurring app
+> fetch — pick `daily` or coarser. (If you want a daemon-internal
+> hourly check, use `/api/recurring-schedules` via the `schedule`
+> skill.)
+
+Same template applies to "every 5 minutes", "every 30 minutes",
+"every 2 hours", etc. when the registering surface is managed-tasks.
+
+## Cadence string vs structured rule
+
+Always send both `cadence` (human-readable, rendered in
+`rules/management.md` §B) and `recurrenceRule` (structured, what the
+scheduler executes). They must agree — if they drift, the rendered
+file misleads the user about what the scheduler will actually do.
+
+When the user modifies just the time (`"9am instead of 10am"`),
+send the new `cadence` and new `recurrenceRule` together in the same
+PATCH so the §B label matches the executable schedule in one
+transition.

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

@@ -1,7 +1,6 @@
 ---
 name: management-policy
-description: Capture a durable management rule from a DM — "every morning X", "from now on when Y", or pause/resume/remove an existing one.
-when_to_use: Wires policy file + linked routine + dossier together. SKIP for one-off `schedule`, tone preferences, or single user facts (`user-profile`).
+description: Capture a durable management rule from a DM — 'every morning X', 'from now on when Y', pause/resume/remove. Wires policy file + linked routine + dossier together. SKIP for one-off `schedule`, tone/style (character), or single user facts (`user-profile`).
 allowed-tools:
   - Bash(curl *)
   - Read
@@ -116,86 +115,12 @@ saved. The slug must:
 
 ### Step 5 — Wire the dependencies (strict order; on failure, roll back in reverse)
 
-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.
+5.1 dossier → 5.2 routine → 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.
 
-#### 5.1 Create the dossier (if it doesn't exist)
-
-```bash
-# Optional — only if the policy accumulates data into a new topic.
-curl -sS -X PUT http://localhost:8321/api/context/dossiers/<topic> \
-  -H 'Content-Type: application/json' \
-  -d @- <<'JSON'
-{"content":"---\ntype: dossier\nowner: agent\nupdated: 2026-04-24\n---\n# <Topic>\n\n## Daily Log\n"}
-JSON
-```
-
-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 (if scheduling is needed)
-
-```bash
-curl -sS -X PUT http://localhost:8321/api/context/routines/custom/<slug> \
-  -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"}
-JSON
-```
-
-The route's `onCustomRoutinesChanged` hook reloads the cron scheduler
-automatically — no separate reload call.
-
-Skip this step if the policy is purely passive (e.g. "from now on, when
-the user mentions X in DM, also …"). In that case the policy file
-itself documents the rule and the relevant DM/event task-flow picks it
-up via the global injection.
-
-#### 5.3 Create the policy file
-
-`origin` MUST be a **single-line** YAML scalar. The frontmatter
-extractor is line-scalar only — block scalars (`origin: |`, `origin: >`)
-are silently truncated to the marker character and the validator
-rejects them. If the user's message is too long for one line, write a
-short summary in `origin` and put the verbatim quote in a body section
-called `## Captured From`.
-
-```bash
-curl -sS -X PUT http://localhost:8321/api/context/rules/policies/<slug> \
-  -H 'Content-Type: application/json' \
-  -d @- <<'JSON'
-{"content":"---\ntype: rule\nkind: policy\nowner: agent\nupdated: 2026-04-24\nslug: <slug>\nstatus: active\ncreated_at: 2026-04-24\ncreated_via: dm\norigin: \"User DM 2026-04-24T14:30Z: <one-line summary or short quote>\"\nlinked:\n  routine: <slug>\n  dossier: <topic>\ntemplate_version: 1\n---\n# <Title>\n\n## Why\n<one short paragraph>\n\n## How\n1. …\n\n## Source of Truth\n- Authoritative: …\n- Local cache: dossiers/<topic>.md\n\n## Captured From\n> <verbatim DM quote, only when too long for the origin line>\n\n## Notes\n- …\n"}
-JSON
-```
-
-The global FS-watch reconciler picks this up within ~1s and the policy
-appears in `context-index.md` automatically. The policy-index
-reconciler also fires on the same FS event (chained off the same
-debounce), so `rules/policies/_index.md` and `rules/management.md`'s
-`## Active Policies` section refresh within ~10 s — no manual PATCH
-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.
-
-#### 5.4 _(no manual step required)_
-
-`rules/policies/_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
-`rules/management.md`. Do not PATCH or PUT either path manually; doing
-so just races the reconciler and creates snapshot churn.
-
-If you need to confirm the index is up to date before replying to the
-user, GET `rules/policies/_index` after a short wait. The reconciler's
-last-run record lives at runtime_state key
-`reconciler.policy_index.last_run` for diagnostics.
+{{> ref:policy-workflow }}
 
 ### Step 6 — Confirm to the user (one DM)
 
@@ -273,34 +198,37 @@ is intentionally not whitelisted (see MANAGEMENT-POLICY-CAPTURE-PLAN
 - **Need a one-off wake-up?** Use `schedule` (`/api/schedule` or
   `/api/schedule/dm`) — no policy file needed.
 - **Need a recurring DB-driven task with no recorded `## Why`?** Use
-  `schedule`'s `/api/recurring-schedules`.
-- **Tone / voice / language preference?** Use `user-profile`'s
-  character path (`PATCH /api/config/character`), NOT a policy file.
-
-## API summary
-
-All writes go through the standard `/api/context/*` chokepoint. No new
-endpoint exists for this skill.
-
-| Verb + path | Used in |
-|---|---|
-| `GET /api/context/rules/policies/_index` | Step 1 (read summary) |
-| `GET /api/context/list/rules` (entries prefixed `policies/` are policy files) | Step 1 (authoritative) |
-| `GET /api/context/rules/policies/<slug>` | Read before pause/resume/remove |
-| `PUT /api/context/dossiers/<topic>` | Step 5.1 (if new dossier) |
-| `PUT /api/context/routines/custom/<slug>` | Step 5.2 (if scheduling) |
-| `PUT /api/context/rules/policies/<slug>` | Step 5.3 |
-| `PATCH /api/context/rules/policies/<slug>` | Pause / resume / remove (frontmatter via GET-merge-PUT) |
-| `DELETE /api/context/routines/custom/<slug>` | Remove only |
+  `schedule`'s `/api/recurring-schedules` — supports hourly / daily /
+  weekly / monthly cadences. Default to `tier:"medium"`; pin a
+  specific model id (`claude-opus-4-7`, `gpt-5.4`, …) only when the
+  rule needs to outlive a `/settings/models` re-route.
+- **Tone / voice / language preference?** Belongs in `user-profile`
+  (which routes to `PATCH /api/config/character`), NOT a policy file.
+  Full recipe in `user-profile/references/character-preferences.md`.
+
+## API surface
+
+All writes go through `/api/context/*` — see the **context** skill's
+`references/api.md` for verb / mode / error envelope details. This
+skill targets these paths:
+
+- `GET /api/context/rules/policies/_index` (Step 1 summary)
+- `GET /api/context/list/rules` (Step 1 authoritative — entries prefixed `policies/`)
+- `GET /api/context/rules/policies/<slug>` (read before pause / resume / remove)
+- `PUT /api/context/dossiers/<topic>` (Step 5.1 — if new)
+- `PUT /api/context/routines/custom/<slug>` (Step 5.2 — if scheduling)
+- `PUT /api/context/rules/policies/<slug>` (Step 5.3)
+- `PATCH /api/context/rules/policies/<slug>` (pause / resume / remove; frontmatter via GET-merge-PUT only — line-scalar parser)
+- `DELETE /api/context/routines/custom/<slug>` (remove only)
 
 `rules/policies/_index.md` and the `## Active Policies` section in
 `rules/management.md` are written by the daemon's policy-index
-reconciler — they are NOT in the agent's write surface for this
-skill.
+reconciler — they are NOT in the agent's write surface for this skill.
 
-Frontmatter validation enforces `kind: policy`, `owner: agent`, and the
-slug rules above. Malformed writes return 422 with the failing field —
-surface that text to the user verbatim rather than retrying blindly.
+Frontmatter validation enforces `kind: policy`, `owner: agent`, and
+the slug rules in Step 4. Malformed writes return 422 with the failing
+field — surface that text to the user verbatim rather than retrying
+blindly.
 
 ## Policy file section shape (auto-curated)
 

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

@@ -0,0 +1,101 @@
+---
+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.
+---
+
+# Step 5 fan-out — dossier → routine → 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.
+
+## 5.1 Create the dossier (only if it doesn't exist)
+
+```bash
+# Optional — only if the policy accumulates data into a new topic.
+curl -sS -X PUT http://localhost:8321/api/context/dossiers/<topic> \
+  -H 'Content-Type: application/json' \
+  -d @- <<'JSON'
+{"content":"---\ntype: dossier\nowner: agent\nupdated: 2026-04-24\n---\n# <Topic>\n\n## Daily Log\n"}
+JSON
+```
+
+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)
+
+```bash
+curl -sS -X PUT http://localhost:8321/api/context/routines/custom/<slug> \
+  -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"}
+JSON
+```
+
+The route's `onCustomRoutinesChanged` hook reloads the cron scheduler
+automatically — no separate reload call.
+
+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
+documents the rule and the relevant DM / event task-flow picks it up
+via the global injection.
+
+## 5.3 Create the policy file
+
+`origin` MUST be a **single-line** YAML scalar. The frontmatter
+extractor is line-scalar only — block scalars (`origin: |`,
+`origin: >`) are silently truncated to the marker character and the
+validator rejects them. If the user's message is too long for one
+line, write a short summary in `origin` and put the verbatim quote in
+a body section called `## Captured From`.
+
+```bash
+curl -sS -X PUT http://localhost:8321/api/context/rules/policies/<slug> \
+  -H 'Content-Type: application/json' \
+  -d @- <<'JSON'
+{"content":"---\ntype: rule\nkind: policy\nowner: agent\nupdated: 2026-04-24\nslug: <slug>\nstatus: active\ncreated_at: 2026-04-24\ncreated_via: dm\norigin: \"User DM 2026-04-24T14:30Z: <one-line summary or short quote>\"\nlinked:\n  routine: <slug>\n  dossier: <topic>\ntemplate_version: 1\n---\n# <Title>\n\n## Why\n<one short paragraph>\n\n## How\n1. …\n\n## Source of Truth\n- Authoritative: …\n- Local cache: dossiers/<topic>.md\n\n## Captured From\n> <verbatim DM quote, only when too long for the origin line>\n\n## Notes\n- …\n"}
+JSON
+```
+
+The global FS-watch reconciler picks this up within ~1 s and the
+policy appears in `context-index.md` automatically. The policy-index
+reconciler also fires on the same FS event (chained off the same
+debounce), so `rules/policies/_index.md` and `rules/management.md`'s
+`## Active Policies` section refresh within ~10 s — no manual PATCH
+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.
+
+## 5.4 _(no manual step required)_
+
+`rules/policies/_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
+`rules/management.md`. **Do not PATCH or PUT either path manually**;
+doing so just races the reconciler and creates snapshot churn.
+
+If you need to confirm the index is up to date before replying to the
+user, GET `rules/policies/_index` after a short wait. The
+reconciler's last-run record lives at `runtime_state` key
+`reconciler.policy_index.last_run` for diagnostics.
+
+## Rollback table
+
+| Failure at | Roll back |
+|---|---|
+| 5.2 | undo 5.1 (`DELETE` the dossier file you just created — only if you created it; do not delete a pre-existing dossier) |
+| 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), 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
+user verbatim** (which slugs / files are in which state) rather than
+silently re-attempting. The user can then decide whether to retry,
+hand-edit, or accept the partial.

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

@@ -1,7 +1,6 @@
 ---
 name: notify
 description: Load whenever composing user-facing text — DMs, notifications, briefings, replies, observer alerts. Owns awareness gate + /api/notify.
-when_to_use: Universal message discipline — awareness gate, no ceremony, no readback. Also covers the evening wrap-up contract and quiet-hours flushing.
 allowed-tools:
   - Bash(curl *)
   - Read
@@ -16,8 +15,8 @@ A bad notification (noisy, poorly timed, unclear) is worse than no notification.
 Every user-facing message — `/api/notify` call, `scheduled.dm`
 final-text DM (Morning briefing), `scheduled.task` final-text DM,
 message.received reply, observer alert — must clear the gates below.
-Specific contracts (Evening wrap-up, Morning briefing) layer
-additional rules on top; nothing they say overrides a universal rule.
+Specific contracts (Morning briefing) layer additional rules on top;
+nothing they say overrides a universal rule.
 
 ### Awareness gate
 
@@ -102,89 +101,18 @@ Notify when **all three** are true: (1) **actionable** or requires awareness, (2
 - **Routine file changes** or **agent internal state** — use Agent Log instead
 - **When in doubt — prefer silence**
 
-Rate-limit defaults: 3/hour, 12/day. The agent CANNOT query
-`notification_log` directly (Approve-tier); use `<today>` `## Agent
-Log` as the authoritative dedup source.
-
 ## Priority
 
-| Priority | Use for | Quiet-hours |
-|---|---|---|
-| `critical` | Security alerts, data-loss risk, system errors | Bypasses |
-| `high` | Hard deadlines, urgent messages, meeting starting now | Bypasses |
-| `normal` | Regular reminders, summaries, evening wrap-up | Respects (dropped) |
-| `low` | Background updates, informational FYI | Respects (dropped) |
+**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.
 
-**Default to `normal`.** Reserve `high` for 8h-delay-matters. Reserve `critical` for 3am-matters.
+{{> ref:priority }}
 
 ## Style
 
 One notification per task, under 5 bullets, lead with the action, follow the Character block. Actionable > informational: "3 emails from boss — 1 asks for Q2 plan by EOD" beats "3 emails from boss".
 
-## Evening wrap-up contract
-
-Used by `routine.evening_review`. The prompt owns go/no-go (silence is
-the default; see Step 4a's awareness gate). This section owns format
-rules for the rare evening where the gate plus a positive trigger
-clears the bar.
-
-### Content (follows `<output_language_policy>`)
-
-1. **The agent-discovered thing the user needs to know** — the
-   specific item that cleared the awareness gate. Lead with substance.
-2. **What's still open** — at most 2 carry-overs with brief reason.
-   Omit if nothing.
-3. **What's next** — only if the agent learned something new today
-   that affects tomorrow. Omit if it's just the user's own calendar
-   reading back to them.
-
-Optional 4th line: brief acknowledgement if today was emotionally
-significant.
-
-### Format — hard limits
-
-- **Maximum 4 short lines.** No markdown headers. No bullet list > 2 items.
-- **No ceremony.** Open with substance, not "Evening Review complete",
-  "Summary:", or "Evening check-in —". Any opener that announces the
-  routine itself rather than the content is forbidden.
-- **No internal names.** Never mention `today.md`, `user/profile.md`, `roadmap.md`, `## Handoff`, `## Agent Plan`, `## Agent Log`, `did-not-fire`, or "Evening Review".
-- **Don't enumerate agent actions.** Surface only what the user would
-  forget by morning AND only things the user couldn't already know
-  from their own calendar / syllabus / scheduled events.
-- **No filler timing commentary** ("Still about 6 hours to go", "Just
-  a heads-up", etc.) — if the timing matters, the deadline itself
-  carries it.
-- **Priority `high`.** The awareness gate raises the bar high enough
-  that anything reaching the user tonight genuinely deserves to. One
-  notification per evening.
-
-### Examples
-
-**Good** (agent surfaced something from new mail today that the user
-hasn't seen yet):
-```
-Sarah's reply on the API spec landed at 6pm — she's blocking on your call on the auth contract before tomorrow's standup.
-```
-
-**Bad — ceremony + internal-state recap:**
-```
-Evening Review complete. Summary:
-today.md updates: Agent Plan rows closed as did-not-fire, Handoff carried over.
-user/profile.md: Raw Signals cleared.
-```
-
-**Bad — agent reading the user's own calendar back to them** (the
-exact shape the user has flagged as unwanted; every element fails the
-awareness gate or the no-ceremony rule):
-```
-Evening check-in — [408019] Week 3 deadline tonight at 11:59pm PT:
-Procurement Plan, RACI Chart, Resource Plan. Still about 6 hours to go.
-Tomorrow: Agile class 6–9pm @ UCLA Extension Gayley.
-```
-The course assignment deadline is on the user's own syllabus and the
-class is on their own calendar — both fail the awareness gate. The
-correct response is silence + one line in ## Agent Log.
-
 ## API Reference — POST /api/notify
 
 ```bash