@aitne-sh/aitne 0.1.7 → 0.1.9

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
+`policies/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
@@ -12,17 +11,17 @@ allowed-tools:
 A **management policy** is a durable, ongoing rule the user wants the
 agent to keep applying. It is NOT a one-off task.
 
-Each policy lives at `rules/policies/<slug>.md` and may link to:
+Each policy lives at `policies/management-captures/<slug>.md` and may link to:
 
-- `routines/custom/<slug>.md` — the cron-driven execution rulebook
-- `dossiers/<topic>.md` — where the policy's accumulating data lands
+- `policies/routines/custom/<slug>.md` — the cron-driven execution rulebook
+- `knowledge/dossiers/<topic>.md` — where the policy's accumulating data lands
 
-A readable summary of every policy lives at `rules/policies/_index.md`,
+A readable summary of every policy lives at `policies/management-captures/_index.md`,
 which the daemon's policy-index reconciler **auto-maintains** from the
-policy files on disk. The directory listing under `rules/policies/` is
+policy files on disk. The directory listing under `policies/management-captures/` is
 the source of truth; `_index.md` is a derived snapshot — **do not
 PATCH or PUT it by hand**. The same reconciler also re-renders the
-`## Active Policies` section in `rules/management.md` so it stays in
+`## Active Policies` section in `policies/management.md` so it stays in
 sync. Both files refresh within ~10 s of any policy file write.
 
 ## When to use this skill
@@ -43,7 +42,7 @@ Use when the user expresses a **durable, ongoing management rule**:
 | "Reply more tersely from now on" / tone, voice, style | `user-profile` (routes to `character`) |
 | "I'm an NYC-based dev" / single user fact | `user-profile` |
 | "Add a project for the Q3 roadmap" | `context` (`projects/*.md`) |
-| Pure data write — "log this transaction" | direct context write to the relevant `dossiers/<topic>.md` |
+| Pure data write — "log this transaction" | direct context write to the relevant `knowledge/dossiers/<topic>.md` |
 
 If the user's request is **a recurring task with no need for a recorded
 reason** (e.g. "ping me every Monday at 9 to start standup prep"), use
@@ -61,12 +60,12 @@ the directory listing if you need authoritative state.
 ```bash
 # Auto-maintained by the daemon — fastest read for slug / status /
 # cadence / linked routine + dossier / one-line why.
-curl -s "http://localhost:8321/api/context/rules/policies/_index"
+curl -s "http://localhost:8321/api/context/policies/management-captures/_index"
 
 # Directory listing — authoritative source of truth. Use this if a
 # specific policy file looks newer than the index (the reconciler
 # debounces ~10 s; fresh writes may not be reflected yet).
-curl -s "http://localhost:8321/api/context/list/rules"
+curl -s "http://localhost:8321/api/context/list/policies"
 ```
 
 If the listing and `_index.md` rows disagree, **prefer the listing**
@@ -104,98 +103,24 @@ wait again.
 
 ### Step 4 — Build the policy file
 
-Emit the full `rules/policies/<slug>.md` content as a fenced markdown
+Emit the full `policies/management-captures/<slug>.md` content as a fenced markdown
 block in the DM **before** writing, so the user sees what's about to be
 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 `routines/custom/<slug>.md` slug (if any) — keep
+- equal the linked `policies/routines/custom/<slug>.md` slug (if any) — keep
   them aligned in v1
 
 ### 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)
 
@@ -227,7 +152,7 @@ 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 `routines/custom/<slug>`, flip
+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.
 
@@ -248,7 +173,7 @@ Same fan-out, with `status: active` and `enabled: true`.
 1. GET the policy file, flip frontmatter `status: removed` and
    `updated: <today>`, PUT back.
 2. If `linked.routine` is set: `DELETE
-   /api/context/routines/custom/<slug>` (whitelisted).
+   /api/context/policies/routines/custom/<slug>` (whitelisted).
 
 The reconciler moves the row from `## Active` to `## Removed`
 automatically — the `removedAt` cell is read from the policy file's
@@ -260,10 +185,10 @@ is intentionally not whitelisted (see MANAGEMENT-POLICY-CAPTURE-PLAN
 
 ## What this skill does NOT do
 
-- Does NOT touch `rules/management.md` body sections (Source of Truth
+- 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
-  `routines/custom/` for cron, which gives the user a visible MD file
+  `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.
@@ -272,35 +197,39 @@ 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 |
-
-`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.
-
-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.
+- **Need a recurring task with no recorded `## Why`?** Recurring autonomous
+  **work** → create an Agent via the `agent-create` skill (`POST /api/agents`);
+  recurring scheduled **DM / briefing** → `schedule`'s
+  `/api/recurring-schedules` with `taskType: "dm_session"`. Default to
+  `tier:"medium"`; pin a specific model id 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/policies/management-captures/_index` (Step 1 summary)
+- `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)
+- `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)
+
+`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.
+
+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/curation.json

@@ -7,7 +7,7 @@
       "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",
-      "scope_paths": ["rules/policies/*.md"]
+      "scope_paths": ["policies/management-captures/*.md"]
     }
   ]
 }

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/knowledge/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/policies/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/policies/management-captures/<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 `policies/management-captures/_index.md` and `policies/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)_
+
+`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.
+
+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
+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 — 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.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/management-policy/seeds/policy-file-shape.seed.json

@@ -2,7 +2,7 @@
   "kind": "knowledge_layout",
   "files": [
     {
-      "path": "rules/policies/*.md",
+      "path": "policies/management-captures/*.md",
       "purpose": "Durable management policy capturing why a recurring rule exists, how it runs, and where data lands",
       "sections": [
         { "heading": "## Why", "contains": "one short paragraph stating the motivation behind the policy" },

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
 
@@ -49,7 +48,7 @@ these in any language also fail the positive rule.
 
 ### No internal mechanism names
 
-Never mention `today.md`, `user/profile.md`, `roadmap.md`, `## Agent
+Never mention `state/today.md`, `identity/profile.md`, `plans/roadmap.md`, `## Agent
 Plan`, `## Agent Log`, `## Handoff`, `did-not-fire`, "Morning
 Routine", "Evening Review", "scheduled.task", "scheduled.dm",
 "dm_session", "sub_flow", or any other internal mechanism in
@@ -72,7 +71,7 @@ rule above bars *introducing* such enumeration in any other surface.)
 ### Language and style
 
 Output language: follow `<output_language_policy>`. Tone: follow
-`user/profile.md` Communication Style and the Character block in your
+`identity/profile.md` Communication Style and the Character block in your
 system prompt. Keep technical terms in original form.
 
 ### Compactness
@@ -92,99 +91,28 @@ Notify when **all three** are true: (1) **actionable** or requires awareness, (2
   `[cal] ... — reminder sent` referencing the same item within the
   last 4 hours. If the injected log is truncated (`[...N earlier
   entries omitted ...]` marker) and you can't rule out a prior
-  notification, `GET /api/context/today` for the full log before
+  notification, `GET /api/context/state/today` for the full log before
   firing. Duplicate notifications are the #1 cause of noise.
 - **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
-- **Rate-limited (429)** — do NOT retry; log skip to Agent Log. If time-critical, upgrade priority at next opportunity
+- **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
 - **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