@aitne-sh/aitne 0.1.7 → 0.1.9

package/agent-assets/skills/management-task-modify/SKILL.md

@@ -1,203 +0,0 @@
----
-name: management-task-modify
-description: Change cadence, intent, or output path on an existing managed task (`mt_<n>`) from a DM — "move daily Zoom check to 9am", "switch Gmail triage to Mondays". Owns PATCH on §B rows. SKIP for new registrations, stops, or app changes.
-when_to_use: User wants to keep a managed task running but adjust its cadence / intent / output path. SKIP for new registrations (`management-task-register`), stops (`management-task-stop`), or one-off run-now (`POST /api/managed-tasks/:id/run-now`).
-allowed-tools:
-  - Bash(curl *)
-  - Bash(jq *)
-  - Read
----
-
-# Modify a Managed Task
-
-Changes the cadence, intent, or `Output path` on an existing
-`mt_<n>` row in place. The `mt_id` is preserved across modifications
-so historical references in `agent_actions` and
-`_activity/<source>.md` remain unambiguous (§10.2).
-
-## When to use
-
-The user clearly references an existing recurring commitment and asks
-to change its **cadence**, **intent text**, or **output path**:
-
-- "Move the Zoom check to 9am instead of 10am"
-- "Switch the Gmail invoice triage to every Monday"
-- "Send Drive receipts to `finance/receipts/` instead of `personal/receipts/`"
-- "Rename the intent on `mt_42` to `Zoom recordings → meeting notes`"
-
-## When NOT to use
-
-| Shape | Use instead |
-|---|---|
-| New recurring commitment | `management-task-register` |
-| User wants to stop / pause it | `management-task-stop` (no soft-pause; hard-delete + re-register if they want to resume) |
-| User wants to run once off-schedule | `POST /api/managed-tasks/<id>/run-now` |
-| User wants to change which **app** an existing task targets | `management-task-stop` then `management-task-register` (different connector ⇒ different commitment) |
-| User wants to change the SoT for a category | `PUT /api/sot-bindings` (A-section flow) |
-
-A change of `app` is a different commitment — stop and re-register
-rather than mutating the row, because the connector probe must run
-fresh and the entity-mirror associations may differ.
-
-## Algorithm (mirror of design 21 §10.2)
-
-### Step 1 — Locate the row
-
-Read the registry and find the row the user means. If the user named
-an `mt_<n>` directly, fetch by id; otherwise dedup by `(app, cadence,
-intent)` the same way `management-task-register` does.
-
-```bash
-# By id when the user said "mt_42":
-curl -s "http://localhost:8321/api/managed-tasks/mt_42" | jq .item
-
-# By app fuzzy lookup:
-curl -s "http://localhost:8321/api/managed-tasks" | jq '.items[] | select(.app_normalized == "zoom")'
-```
-
-GET-by-id wraps the row in `{item:<row>}`; the list returns
-`{items:[…], count:N}`.
-
-If no row matches, DM:
-
-> No managed task for `<app>` is registered. Want me to register one?
-
-If multiple rows could plausibly match, list them with id + cadence +
-intent and ask the user to pick. Stop until they reply.
-
-### Step 2 — Diff the requested change
-
-Map the user's request to one or more of these fields:
-
-| User request | PATCH field | Notes |
-|---|---|---|
-| "9am instead of 10am" / "every Monday" | `cadence` + `recurrenceRule` (send both together) | Same `recurrenceRule` shape as `management-task-register` Step 5; only `daily`/`weekly`/`monthly` are representable |
-| "Rename intent" / "describe it as `<text>`" | `intent` | ≤ 200 chars, NFC, no `\n`, no `\|` |
-| "Send to `<dir>/`" | `output_path` | Validate against §9.3 (`<domain>/<type-plural>/`, trailing `/`, no `..`); send `null` to clear |
-
-If the request implies **app change**, stop and route the user to
-"stop + re-register" (Step 1 disambiguator above).
-
-### Step 3 — Confirm with the user before mutating (Notify tier)
-
-PATCH on a managed task is **Notify tier** (§13.1). DM the user
-verbatim with the proposed change and wait for an explicit yes:
-
-> `mt_42` Zoom check — change cadence from `daily 10:00 (Asia/Tokyo)`
-> to `daily 09:00 (Asia/Tokyo)`?
-
-Only after the user confirms do you issue the PATCH. If they decline
-or amend, restart at Step 2 with the new shape.
-
-When the user's confirmation also implies a different output path
-("…and write into `work/meetings/agendas/`"), include both fields in
-one PATCH so the audit row reflects the user's actual intent in a
-single transition.
-
-### Step 4 — PATCH /api/managed-tasks/:id
-
-```bash
-curl -sS -X PATCH http://localhost:8321/api/managed-tasks/mt_42 \
-  -H 'Content-Type: application/json' \
-  -d @- <<'JSON'
-{
-  "cadence":     "daily 09:00 (Asia/Tokyo)",
-  "recurrenceRule": {
-    "frequency": "daily",
-    "time":      "09:00",
-    "timezone":  "Asia/Tokyo"
-  }
-}
-JSON
-```
-
-| Field | When to send | Notes |
-|---|---|---|
-| `cadence` + `recurrenceRule` | Cadence change | Send both together so the rendered §B label matches the executable schedule. PATCH body must include at least one mutable field; an empty body returns `validation_error`. |
-| `intent` | Intent rename | ≤ 200 chars; trimmed + NFC at the boundary |
-| `output_path` | Output relocation | `<domain>/<type-plural>/` per §9.3; `null` clears it (back to "first run decides") |
-
-`app` / `app_normalized` / `last_run_at` / `last_result` /
-`consecutive_failures` are NOT mutable through this PATCH. Run-result
-writes go through the internal `/run-result` route used by
-`scheduled-managed-task`; app rename goes through the dedicated
-`POST /api/managed-tasks/:id/rename-app` (Step 1 disambiguator above
-already routes that case to "stop + re-register" for safety).
-
-The server-side transaction:
-
-a. UPDATEs `recurring_schedules` (if `recurrenceRule` changed),
-b. UPDATEs `managed_tasks.{intent,cadence,output_path,updated_at}`,
-c. re-renders `rules/management.md` from DB (locked + snapshotted),
-d. INSERTs `agent_actions` (`action_type='management_task.modified',
-detail={changed, from, to}`).
-
-The response is `{status:"updated", item:<ManagedTask>, render_status}`.
-
-The `mt_id`, `last_run_at`, `last_result`, and
-`consecutive_failures` are preserved across the PATCH — history is
-continuous (§10.2).
-
-A cadence change cancels any in-flight `agent_schedule` row tied to
-the old cron; the new cron takes effect from the next eligible slot.
-Do not separately DELETE `agent_schedule` items — the daemon owns
-that.
-
-**Output-path relocation does NOT move existing entity files.** Past
-entities stay where they were written. If the user wants
-re-organization, stop the task, move the entity files manually (or
-ask the user to), and re-register.
-
-### Step 5 — Confirm to user
-
-One DM, persona-tone (`notify` skill discipline applies). Read the
-resolved fields from the PATCH response — do NOT echo what you sent
-in case the daemon normalized something:
-
-> Updated `mt_42` Zoom check — now daily 09:00 JST. Next run 2026-12-05 09:00 JST.
-
-If the PATCH only changed `intent` or `output_path` (no cadence
-shift), do not announce a "next run" line — the next firing is
-unchanged.
-
-## Error envelope
-
-| HTTP | `error` | What to do |
-|---|---|---|
-| 400 | `invalid_id` | The `:id` segment didn't match `^mt_[1-9]\d*$`; the user typed the id wrong — ask them to repeat |
-| 400 | `validation_error` | Body has Zod `details`; pin the failing path (e.g. `recurrenceRule.daysOfWeek` not allowed for `daily`) and ask for a fix |
-| 404 | `not_found` | DM "I don't have an `mt_<id>` to modify"; offer to register one |
-| 5xx | `internal_error` | Surface `body.message` if present; advise `aitne logs` |
-
-The daemon does not currently emit `cron_too_tight` (the recurrence
-schema only accepts daily/weekly/monthly — sub-daily is impossible),
-nor `cadence_partial` (the recurrence rule is one structured field, so
-there is no partial-cadence shape to reject). If a future schema gain
-adds them, surface them verbatim.
-
-## What this skill does NOT do
-
-- Does NOT mutate `app` — that is a different commitment, stop +
-  re-register.
-- Does NOT pause / disable a task — there is no soft-pause; stop +
-  re-register if the user wants a hiatus.
-- Does NOT touch §A (SoT bindings) or §C (Active Policies).
-- Does NOT PUT `rules/management.md` directly. The daemon owns the
-  file write.
-- Does NOT migrate entity files when `output_path` changes; only
-  future runs honor the new path.
-- Does NOT auto-confirm "this looks right" — Notify-tier means a real
-  user-facing confirmation. Output language: follow
-  `<output_language_policy>`.
-
-## API summary
-
-| Verb + path | Used in |
-|---|---|
-| `GET /api/managed-tasks` | Step 1 (lookup by app/cadence) |
-| `GET /api/managed-tasks/:id` | Step 1 (lookup by id) |
-| `PATCH /api/managed-tasks/:id` | Step 4 (Notify-tier) |
-| `POST /api/notify` | Step 5 (user-facing confirmation) |
-
-The PATCH writes one `agent_actions` row and snapshots the file —
-do NOT post a separate audit event yourself.

package/agent-assets/skills/management-task-register/SKILL.md

@@ -1,330 +0,0 @@
----
-name: management-task-register
-description: Register a new recurring agent fetch against a third-party app from a DM — "check Zoom recordings daily at 10am", "check Gmail daily for invoices". Owns INSERT on §B "Managed tasks" rows. SKIP for one-off reminders, modify, stop.
-when_to_use: User asks to start a recurring external-app fetch / check / sync (Zoom, Gmail, Drive, Notion, custom MCP). SKIP for one-off reminders (`schedule`), durable rules without an external app (`management-policy`), or pure DM cadence (`schedule` recurring).
-allowed-tools:
-  - Bash(curl *)
-  - Bash(jq *)
-  - Read
----
-
-# Register a Managed Task
-
-A **managed task** (`mt_<n>`) is a user-delegated commitment: the agent
-runs a recurring fetch against a specific App at a user-specified
-Cadence and writes the resulting entities into a primary L2 directory
-(the `Output path`). Each row lives in `rules/management.md` §B. The
-authoritative store is the `managed_tasks` SQLite table; the file is
-re-rendered from the table after every mutation, so do **not** PUT the
-file yourself — every legal mutation goes through
-`/api/managed-tasks` and the daemon owns the file write.
-
-## When to use
-
-The user's DM clearly asks for a **recurring fetch / check / sync
-against a third-party app** with a cadence:
-
-- "Check Zoom recordings every day at 10am"
-- "Check Gmail daily and triage invoices into receipts"
-- "Every Monday at 9 pull new Drive PDFs into receipts"
-- "Check Notion 'Reading' DB every evening and surface unread"
-
-## When NOT to use
-
-| Shape | Use instead |
-|---|---|
-| One-off "remind me at 3pm to call the bank" | `schedule` (`/api/schedule/dm`) |
-| Recurring DM with no external-app fetch ("ping me every Monday at 9") | `schedule` recurring-schedules |
-| "From now on, when X happens, do Y" passive rule with no cadence | `management-policy` |
-| Tone / style / single fact about the user | `user-profile` |
-| Source-of-Truth declaration ("notes live in Obsidian") | A-section binding via `PUT /api/sot-bindings` (separate flow) |
-| Modify cadence / output of an existing `mt_<n>` | `management-task-modify` |
-| Stop an existing `mt_<n>` | `management-task-stop` |
-| Run an existing `mt_<n>` once, off-schedule | `POST /api/managed-tasks/<id>/run-now` |
-
-If the user already has `mt_<n>` for the same app+cadence, this skill
-**refuses** with a DM pointing at the existing row — that is the dedup
-contract (FR-2). Do not register a duplicate.
-
-## Algorithm (mirror of design 21 §10.1)
-
-Run the steps in order. Any step's failure DMs the user with the
-verbatim reason and ends the flow — never skip, never silently retry,
-never hardcode a tool name (FR-4 / ADR §8.4).
-
-### Step 1 — Read current state
-
-```bash
-curl -s "http://localhost:8321/api/context/rules/management" | jq -r .content
-```
-
-Extract §B (Managed tasks) and §A (Source-of-Truth bindings). §A tells
-you which app already owns a category (e.g. `tasks → notion`); a
-duplicate-cadence registration against an unrelated app for the same
-category is a smell and should be confirmed before registering.
-
-### Step 2 — Semantic dedup (LLM judgment)
-
-For each existing §B row, compare the requested
-`(app_normalized, cadence_semantic, intent_semantic)` against the row.
-Treat a row as a **high-confidence match** when:
-
-- `app_normalized` matches case-insensitively (e.g. `zoom` ≡ `Zoom`),
-  AND
-- the cadence resolves to the same structured recurrence, AND
-- the intent describes the same fetch shape (e.g. "recordings → meeting
-  entity" is the same as "new recordings → meeting entity").
-
-On a match, DM the user verbatim with the existing row's id, cadence
-and last result, and stop:
-
-> Already managed as `mt_42` (daily 10:00 — last run ok 3 new). Modify
-> or stop it via DM.
-
-If multiple plausible matches exist, ask the user which one to update
-and end the flow (the user's reply triggers `management-task-modify`).
-
-If §B already holds the cap (default 100, configurable
-`managementMaxActiveTasks`), refuse with a DM pointing at the cap; the
-user must stop something first.
-
-### Step 3 — Tool selection (LLM judgment, in-session)
-
-Enumerate the tools available to this session (`mcp__*`, native
-backend connectors, custom MCP servers the user installed). Ask
-yourself: *"Which of these, if any, lets me read the user-typed app
-label?"*
-
-- **Zero plausible** → DM "I don't see a connected tool for `<app>` on
-  this backend. Connect one and ask again." Stop.
-- **Multiple plausible** → DM the user with the candidates verbatim
-  and ask which one to use. Stop. (The user's reply re-enters this
-  flow with the chosen tool as a hint.)
-- **One plausible** → continue.
-
-NEVER hardcode tool names or pattern-match against a specific
-namespace prefix. The user may have installed a custom MCP with
-non-standard names — you read the tool description and pick by
-**capability**, not by name.
-
-### Step 4 — Read-only probe
-
-Invoke the chosen tool with the **smallest** read-only payload that
-proves connectivity and authorization (e.g. list the first page with
-`limit: 1`, fetch the user's profile / "me" endpoint, search for an
-empty string). Do NOT mutate state.
-
-On any error — auth failure, network error, schema error,
-out-of-quota — DM the verbatim error message with one line of context
-and stop:
-
-> Couldn't reach `<app>`: `<verbatim error from tool>`.
-
-The probe failure must surface the connector's own error string, not a
-paraphrase. The user is the one who can fix auth / quota / install.
-
-### Step 4a — Decide `Output path` (LLM judgment)
-
-From the probe sample, infer the primary L2 directory the recurring
-fetch will write into. Bias toward existing matches:
-
-1. If the entity-mirror already holds entities with `sources.<app>.*`
-   under one `<domain>/<type-plural>/`, reuse that path. Probe with:
-   ```bash
-   curl -s "http://localhost:8321/api/entities?source=<app>&limit=5" | jq .
-   ```
-   The response is `{tier:1, mode:"by_source_key", items:[…]}`; each
-   item's `path` (`<domain>/<type-plural>/<slug>.md`) reveals where
-   that source already lives. If 1+ rows agree on `<domain>/<type>`,
-   that path wins.
-2. Otherwise, pick the `(domain, type)` pair whose semantic prior best
-   fits the data shape. Reference table:
-
-   | Probe sample shape | Likely `<domain>/<type-plural>/` |
-   |---|---|
-   | Recording with attendees + duration | `work/meetings/` |
-   | PDF / image with monetary amount | `finance/receipts/` |
-   | Task / ticket / issue | one of the project domains' `projects/` (rare — typically the Tasks SoT mirror handles this; only register a managed task if the SoT is *another* app) |
-   | Travel itinerary / booking | `travel/trips/` |
-   | Long-form note / article | `<domain>/notes/` (pick by content topic) |
-   | Book metadata / progress | `learning/books/` |
-3. If the data shape is genuinely ambiguous (e.g. the probe returned
-   zero rows), set `output_path: null` — the first scheduled run will
-   populate it from real data.
-
-**Path validation invariant** (§9.3, §13.3):
-
-- Format: `<domain>/<type-plural>/` — leading `context/` is implicit
-  and must NOT be included; the trailing `/` is mandatory.
-- `<domain>` ∈ `{work, travel, finance, personal, health, learning}`.
-- `<type-plural>` ∈ `{meetings, trips, receipts, projects, books, notes}`.
-- No `..` segments. No absolute paths.
-
-The daemon CHECKs the constraint at INSERT/UPDATE time and rejects with
-a 422 — surface that error verbatim if it fires. Pre-validate to avoid
-the round-trip when you can.
-
-### Step 5 — Resolve cadence to a `recurrenceRule`
-
-Translate the user's natural-language cadence into:
-- a free-text `cadence` string (what gets rendered in §B), AND
-- a structured `recurrenceRule` (what the scheduler executes).
-
-The daemon's recurrence engine accepts only `daily` / `weekly` /
-`monthly`. Sub-daily ("every hour", "every 5 minutes") is **not
-representable** — refuse those with a DM and ask for a daily-or-coarser
-cadence. Times are `HH:MM` 24-hour local; timezone is IANA (auto-fills
-from daemon config when omitted, but it's safer to pass it explicitly
-so a roaming laptop doesn't surprise the user).
-
-| User said | `cadence` | `recurrenceRule` |
-|---|---|---|
-| 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]}` |
-| every hour | _refuse_ | _refuse_ |
-| every 5 minutes | _refuse_ | _refuse_ |
-
-`daysOfWeek` is `0=Sun..6=Sat`; `daysOfMonth` is `1..31` (29-31 clamp
-to last day of short months). `daysOfWeek` is forbidden on `daily` and
-`monthly`; `daysOfMonth` is forbidden on `daily` and `weekly` — the
-daemon's Zod refinements reject mismatches with a `validation_error`.
-
-For sub-daily requests, refuse with a DM:
-
-> The agent's recurrence engine only supports daily, weekly, or monthly
-> cadences. `every hour` is too tight — pick `daily` or coarser.
-
-### Step 6 — POST /api/managed-tasks
-
-```bash
-curl -sS -X POST http://localhost:8321/api/managed-tasks \
-  -H 'Content-Type: application/json' \
-  -H 'Idempotency-Key: <opaque uuid for this DM>' \
-  -d @- <<'JSON'
-{
-  "intent":      "Zoom recordings → meeting entity",
-  "app":         "zoom",
-  "cadence":     "daily 10:00 (Asia/Tokyo)",
-  "recurrenceRule": {
-    "frequency": "daily",
-    "time":      "10:00",
-    "timezone":  "Asia/Tokyo"
-  },
-  "output_path": "work/meetings/"
-}
-JSON
-```
-
-| Field | Required | Notes |
-|---|---|---|
-| `intent` | yes | ≤ 200 chars, NFC, no newlines, no pipe chars |
-| `app` | yes | ≤ 64 chars, NFC, no newlines, no pipe chars; user-typed label preserved verbatim (case + non-ASCII OK) |
-| `cadence` | yes | Human-readable; rendered in §B (≤ 200 chars) |
-| `recurrenceRule` | yes | `{frequency:"daily"\|"weekly"\|"monthly", time:"HH:MM", timezone?:<IANA>, daysOfWeek?:[0..6], daysOfMonth?:[1..31]}` — see Step 5 table |
-| `output_path` | no | `<domain>/<type-plural>/` per §9.3, ending `/`; omit while undecided (the first scheduled run back-fills it) |
-
-The response is `{status:"created", item:<ManagedTask>, render_status:"ok"|"lock_contended:..."}`.
-On an idempotent replay (same `Idempotency-Key` within 24 h, the row
-still exists) you get `{status:"idempotent_replay", item:<ManagedTask>}`
-with HTTP 200 — treat that as success, not a duplicate registration.
-
-**Idempotency-Key.** Generate a stable key per DM (e.g. SHA-256 of the
-inbound message id + app). Concurrent retries collapse to the same
-`mt_<n>`; a different key with the same `app+cadence` collides at the
-`(app_normalized, cadence)` uniqueness check and the second POST returns
-`409 conflict` with the existing `mt_id` — DM the user pointing at it
-instead of registering twice.
-
-**Server-side transaction (atomic).** The daemon allocates the next
-`mt_<n>` from `managed_task_seq`, INSERTs `recurring_schedules` and
-`managed_tasks` linked by FK, and writes one `agent_actions` row
-(`action_type='management_task.created'`). On any DB failure the
-transaction rolls back and you get a 5xx — surface the body verbatim.
-
-**File render.** Post-transaction the daemon re-renders
-`rules/management.md` from DB (locked, snapshotted into
-`md_file_snapshots`). You do NOT touch the file.
-
-### Step 7 — Confirm to user
-
-DM the user once with the assigned id (`item.id` from the POST
-response), the resolved output path (`item.output_path`), and the
-human cadence label (`item.cadence`). The next firing time is owned by
-the scheduler — phrase the confirmation around the cadence rather than
-fabricating a clock time.
-
-> Registered as `mt_43` (Zoom · daily 10:00 JST). Output → `work/meetings/`. Starts at the next 10:00 JST slot.
-
-Persona / language rules are in `notify` — the message itself follows
-the awareness gate and no-ceremony rules. Don't enumerate the steps
-("did probe, did INSERT, did re-render"); the daemon already audited
-them.
-
-## Validation cheatsheet (§13.3)
-
-| Field | Rule | Reject example |
-|---|---|---|
-| `app` | trimmed; NFC; ≤ 64 chars; no `\n`; no `\|` | `\|gmail` |
-| `intent` | trimmed; NFC; ≤ 200 chars; no `\n`; no `\|` | `<5×40 chars>` |
-| `cadence` | free text, ≤ 200 chars | _any non-empty string_ |
-| `recurrenceRule.frequency` | `daily` \| `weekly` \| `monthly` | `hourly`, `every-5-min` |
-| `recurrenceRule.time` | `HH:MM` zero-padded | `9:00`, `25:00` |
-| `recurrenceRule.timezone` | IANA zone string (auto-fills from daemon when omitted) | `EST+9` |
-| `recurrenceRule.daysOfWeek` | required for `weekly`; forbidden otherwise; ints `0..6` | `[7]`, `[]` |
-| `recurrenceRule.daysOfMonth` | required for `monthly`; forbidden otherwise; ints `1..31` | `[0]`, `[32]` |
-| `output_path` | `<domain>/<type-plural>/`; no `..`; trailing `/` | `work/meetings`, `../foo/`, `random/dir/` |
-| `mt_id` | server-allocated; never craft client-side | n/a |
-
-The daemon also enforces these — but pre-validating saves the user one
-round-trip of error chatter.
-
-## Error envelope
-
-| HTTP | `error` | What to do |
-|---|---|---|
-| 400 | `validation_error` | Body has Zod `details`; pick the offending field's message and ask the user to clarify. The Zod issue path tells you whether `recurrenceRule.*`, `app`, `output_path`, etc. is the culprit. |
-| 409 | `duplicate` | Body includes `item` (the existing row); DM "Already managed as `<item.id>`" and stop |
-| 409 | `cap_reached` | Surface `body.message` (cap value); user must stop something first |
-| 5xx | `internal_error` | DM "Couldn't register; daemon error. Try again, or check `aitne logs`." |
-
-`body.message` (when present) is intended for the user — preserve it
-verbatim. The daemon does not currently emit `cron_too_tight` because
-the recurrence schema only accepts daily/weekly/monthly — a sub-daily
-ask never reaches POST; refuse it client-side per Step 5.
-
-## What this skill does NOT do
-
-- Does NOT hardcode connector tool names — all tool selection is
-  LLM-judged (FR-4).
-- Does NOT PUT `rules/management.md` directly — the daemon owns that
-  write (FR-12). The only legal write is `POST /api/managed-tasks`.
-- Does NOT INSERT `recurring_schedules` directly. POST
-  `/api/managed-tasks` is the chokepoint that keeps the FK pair
-  consistent.
-- Does NOT touch §A (SoT bindings). Use `PUT /api/sot-bindings` for
-  that (separate "sot" flow).
-- Does NOT touch §C (Active Policies stub). Owned by
-  `management-policy`.
-- Does NOT silently re-register on retry. Use `Idempotency-Key`
-  per-DM; conflicts surface the existing `mt_id`.
-- Does NOT register a task that has no probe-passing connector. Probe
-  failure is a hard stop — never "register optimistically and hope".
-- Does NOT proceed when the vault is in degraded mode
-  (`Dispatcher.isAutonomousAllowed()` already filters). Trust that
-  upstream.
-
-## API summary
-
-| Verb + path | Used in |
-|---|---|
-| `GET /api/context/rules/management` | Step 1 (read §A + §B) |
-| `GET /api/entities?source=<app>` | Step 4a (output-path bias) |
-| `GET /api/managed-tasks` | Optional — alternative to parsing the file |
-| `POST /api/managed-tasks` | Step 6 (Notify-tier; the daemon DMs confirmation; no Approve gate) |
-| `POST /api/notify` | Step 7 (your own DM-to-user reply) — uses the `notify` skill's discipline |
-
-Every state-changing call is recorded in `agent_actions` and the file
-is snapshotted into `md_file_snapshots` — do NOT post a separate audit
-event yourself.