@aitne-sh/aitne 0.1.7 → 0.1.9

package/agent-assets/docs/concepts/delegated-mode.md

@@ -6,18 +6,22 @@ id: delegated-mode
 aliases:
   - delegated
   - direct mode
+  - native mode
   - same-backend
   - cross-backend
   - integration delegation
 category: concepts
 summary: |
-  Each integration (Gmail, Google Calendar, …) runs in one of three
-  modes: direct (the daemon holds OAuth credentials), delegated (the
-  agent's backend connector holds them), or disabled. Under delegation,
-  the agent reaches the integration through one of two paths depending
-  on whether its DM session backend matches the connector's owner —
-  same-backend (native MCP, no daemon involved) or cross-backend
-  (`/api/integrations/:key/invoke` proxy).
+  Each integration (Gmail, Google Calendar, …) runs in one of four
+  modes: direct (the daemon holds OAuth credentials and polls),
+  delegated (the agent's backend connector holds them; the daemon syncs
+  on opt-in cadences), native (the main backend's MCP connector reaches
+  the integration on-demand; no daemon polling and no daemon-side
+  proxy), or disabled. Under `delegated`, the agent reaches the
+  integration through one of two paths depending on whether its DM
+  session backend matches the connector's owner — same-backend (native
+  MCP, no daemon involved) or cross-backend
+  (`/api/integrations/:key/exec` task-mode proxy).
 section: integrations
 tags:
   - core
@@ -32,16 +36,18 @@ ask_examples:
   - Why don't I see a SKILL.md for Gmail in my Codex session?
 locale: en-US
 created: 2026-04-26
-updated: 2026-04-26
+updated: 2026-05-28
 keywords:
   - delegated mode
   - direct mode
+  - native mode
   - same-backend
   - cross-backend
   - integrations.md
   - delegatedBackend
+  - nativeBackend
   - SKILL.delegated
-  - invoke endpoint
+  - exec endpoint
 related:
   - concepts/safety-model
   - concepts/skills
@@ -49,21 +55,29 @@ related:
   - features/integrations/mail
 ui_anchors:
   - /connections
+  - /connections/mail
+  - /connections/calendar
   - /settings/models
-config_keys:
-  - integrations
+api_endpoints:
+  - PATCH /api/integrations/:key
+  - POST /api/integrations/:key/exec
+  - POST /api/integrations/:key/probe
+  - POST /api/observations/batch
+context_files:
+  - policies/integrations.md
 ---
 
 # Delegated Mode (Integration Modes)
 
 ## TL;DR
 
-Each integration is in one of three modes:
+Each integration is in one of four modes:
 
 | Mode | Who holds credentials | What the agent calls |
 |---|---|---|
 | `direct` | Daemon (OAuth in macOS Keychain) | `curl /api/mail/*` / `curl /api/calendar/*` |
-| `delegated` | The agent's backend connector (claude.ai / ChatGPT / Google) | Native MCP tools or the `/api/integrations/:key/invoke` proxy |
+| `delegated` | The agent's backend connector (claude.ai / ChatGPT / Google) | Native MCP tools (same-backend) or the `/api/integrations/:key/exec` task-mode proxy (cross-backend) |
+| `native` | The main backend's connector (no daemon credentials, no daemon poller) | Native MCP tools on the main backend; observations are POSTed to `/api/observations/batch` for the routine pre-pass |
 | `disabled` | Nobody | Nothing — the integration is off |
 
 Under `delegated`, two sub-cases exist depending on whether the DM session's
@@ -72,9 +86,30 @@ backend is the same as the integration's `delegatedBackend`:
 - **Same-backend** — DM agent calls the connector's MCP tool directly.
   The daemon is not involved. No skill body is materialized.
 - **Cross-backend** — DM agent calls
-  `POST /api/integrations/:key/invoke {tool, args}`. The daemon spawns
-  a one-shot subprocess of `delegatedBackend`, runs the tool there,
-  and returns the raw result.
+  `POST /api/integrations/:key/exec` in **task mode** with body
+  `{task: "<natural-language description>", outputSchema, maxToolCalls,
+  cacheable}`. The daemon spawns a one-shot subprocess of
+  `delegatedBackend`, the task-mode planner picks the appropriate tool
+  from the integration's registered `capabilityTools`, runs it, and
+  returns a structured result conforming to `outputSchema`. The legacy
+  RPC route `POST /api/integrations/:key/invoke {tool, args}` was
+  retired 2026-05-01 — cross-backend tool-name divergence (Claude
+  `search_threads` vs Codex `search_emails` vs Gemini `search`) made
+  the RPC shape brittle. See `docs/design/17-delegated-mode-v2.md` §4.2 for the
+  retirement rationale and `docs/design/appendices/routine-data-acquisition.md` §8.1
+  for the task-mode body shape.
+
+`native` has no sub-cases. The integration's `nativeBackend` must equal
+the main DM backend — `BackendRouter.setMainBackend` cascades unmatched
+`native` rows to `disabled`. From the agent's call-site view, `native`
+is indistinguishable from `delegated` same-backend (both are in-session
+MCP); the difference is who polls (no one, for `native`).
+
+> The four modes are `direct | delegated | native | disabled`
+> (`INTEGRATION_MODES` in `packages/shared/src/integrations.ts`).
+> `git` and `github` support only `direct | delegated | disabled` — no
+> native mode (they use read-only CLI connectors), and `browser_history`
+> is `direct | disabled` only.
 
 ## Why This Concept Exists
 
@@ -97,25 +132,45 @@ that case the daemon spawns the other backend per call.
 - **`direct`** — daemon holds the credentials (OAuth refresh token in
   macOS Keychain, app-password for Yahoo / iCloud, …). Pollers run.
   Full feature set. The operator did the vendor-console setup.
-- **`delegated`** — daemon holds nothing for this integration. Pollers
-  are stopped. The connector running inside the agent's backend (or a
-  spawned-on-demand backend) does the work.
+- **`delegated`** — daemon holds nothing for this integration. The
+  daemon's `delegated-sync-worker` polls on opt-in cadences via the
+  delegated backend's connector. Per-DM-turn calls reach the connector
+  through the agent's backend (same-backend) or via the daemon's
+  `/exec` proxy (cross-backend).
+- **`native`** — daemon holds nothing AND runs no poller. The main
+  backend's MCP connector reaches the integration on-demand within the
+  agent's own turn (DM, hourly_check, routine pre-pass). The agent
+  POSTs results to `/api/observations/batch` so the rest of the
+  observation pipeline (summarizer, hourly check) still operates. See
+  `docs/design/appendices/native-integration-mode.md` for the full
+  spec, including the per-key `runtime_state.integration_flip_lock:<key>`
+  drain protocol.
 - **`disabled`** — nobody holds credentials. The integration is off.
 - **`delegatedBackend`** — when delegated, which backend's connector
   serves the calls. `claude` / `codex` / `gemini`. Editable per
   integration in **Connections → Gmail / Google Calendar**.
-- **Same-backend** — DM session backend matches `delegatedBackend`. The
-  daemon is not in the loop; the agent calls native MCP directly. No
-  skill body is materialized for the integration's slug — the connector
-  describes its own tools at session-init.
-- **Cross-backend** — DM session backend differs from `delegatedBackend`.
-  The agent reaches the integration through
-  `POST /api/integrations/:key/invoke` and the daemon spawns
-  `delegatedBackend` as a subprocess for each call. A
-  `SKILL.delegated.<sessionBackend>.md` file is materialized into the
-  session workdir.
+- **`nativeBackend`** — when native, which backend's connector is
+  expected. Must equal the main DM backend; changing the main backend
+  cascades unmatched `native` rows to `disabled` (the cascade is
+  triggered by `BackendRouter.setMainBackend` /
+  `PUT /api/backends/main`).
+- **Same-backend** — DM session backend matches `delegatedBackend` /
+  `nativeBackend`. The daemon is not in the loop; the agent calls
+  native MCP directly. No skill body is materialized for the
+  integration's slug — the connector describes its own tools at
+  session-init.
+- **Cross-backend** — DM session backend differs from
+  `delegatedBackend`. Cross-backend exists only for `delegated` — never
+  for `native`, which is locked to the main DM backend. The agent
+  reaches the integration through `POST /api/integrations/:key/exec`
+  in task mode and the daemon spawns `delegatedBackend` as a
+  subprocess for each call. A `SKILL.delegated.<sessionBackend>.md`
+  file is materialized into the session workdir.
 - **`integrations.md`** — daemon-rendered snapshot of every
-  integration's mode at `~/.personal-agent/integrations.md`. The agent
+  integration's mode. After the context-vault restructure it lives
+  inside the vault under the `policies` class at
+  `<contextDir>/policies/integrations.md` (the legacy
+  `~/.personal-agent/integrations.md` location was retired). The agent
   reads it to know which path to take.
 
 ## How to Choose
@@ -123,7 +178,8 @@ that case the daemon spawns the other backend per call.
 | You want… | Pick |
 |---|---|
 | Full feature set (send mail, attachments, full search) and you're comfortable with one-time vendor-console setup | **direct** |
-| Zero setup tax, willing to live with whatever the connector exposes (Claude Gmail = draft-only; Codex Gmail = full) | **delegated** |
+| Zero setup tax, with opt-in background polling on the delegated backend's connector cadence | **delegated** |
+| Zero setup tax, on-demand only — main backend reaches the integration when the agent turns up a reason to look (no daemon polling, no proxy spawn) | **native** |
 | The integration off entirely | **disabled** |
 
 When you pick `delegated`, also pick `delegatedBackend`:
@@ -136,28 +192,63 @@ When you pick `delegated`, also pick `delegatedBackend`:
   connector you want (e.g. Codex's full Gmail) but a different backend
   is your preferred DM driver (e.g. Claude).
 
+When you pick `native`, `nativeBackend` is fixed to your main DM
+backend. Flipping the main backend re-targets every `native` row; rows
+whose new `nativeBackend` has no descriptor connector for the
+integration (e.g. `gmail` native on a backend that doesn't ship a Gmail
+connector) cascade to `disabled` and the operator gets a DM.
+
 ## Concrete Examples
 
-| Setup | What happens on a Gmail search |
-|---|---|
-| Gmail direct | Agent: `curl /api/mail/<acct>/messages?q=...` → daemon hits Gmail API with stored OAuth |
-| Gmail delegated to Codex × Codex DM (same-backend) | Agent: `mcp__codex_apps__gmail._search_emails(...)` → Codex's connector hits Gmail. No daemon involvement. No skill file. |
-| Gmail delegated to Codex × Claude DM (cross-backend) | Agent: `curl -X POST /api/integrations/gmail/invoke -d '{"tool":"search_emails","args":{...}}'` → daemon spawns Codex subprocess with `proxy.md` profile → Codex calls `mcp__codex_apps__gmail._search_emails` → returns raw result through daemon |
+What happens on a Gmail search, by setup:
 
-## How the Skill File Resolves
+| Setup | Path |
+|---|---|
+| Gmail **direct** | `curl /api/mail/<acct>/messages?q=...` → daemon hits Gmail API with stored OAuth |
+| Gmail **delegated** to Codex, Codex DM (same-backend) | Agent calls `mcp__codex_apps__gmail._search_emails(...)` → Codex's connector hits Gmail. No daemon involvement. No skill file. |
+| Gmail **delegated** to Codex, Claude DM (cross-backend) | Agent POSTs to `/api/integrations/gmail/exec` in task mode (see below) → daemon spawns a Codex subprocess → returns a structured result. |
+| Gmail **native** on Codex DM | Identical call to delegated same-backend (`mcp__codex_apps__gmail._search_emails(...)`). No daemon involvement. The daemon poller is OFF; the routine pre-pass POSTs results to `/api/observations/batch`. |
+
+The cross-backend row above issues a task-mode `/exec` call:
+
+```bash
+curl -X POST http://localhost:8321/api/integrations/gmail/exec \
+  -d '{
+    "task": "Search Gmail for newer_than:1d, return id/subject/from/snippet/date for each message",
+    "outputSchema": {
+      "type": "object",
+      "required": ["messages"],
+      "properties": { "messages": { "type": "array", "items": { } } }
+    },
+    "maxToolCalls": 3,
+    "cacheable": true
+  }'
+```
 
-`selectSkillVariantFile(skillSlug, sessionBackend, integrations)` returns
-one of three values:
+The daemon spawns a Codex subprocess with the `proxy.md` profile, the
+task-mode planner picks `_search_emails` from the registered
+`capabilityTools`, runs it, and returns a structured `{messages:[…]}`
+conforming to `outputSchema`.
 
-- `"SKILL.md"` — direct mode, or skill not gated by any integration.
-- `null` — every touched integration is delegated and same-backend.
-  No skill is materialized (the connector self-describes).
-- `"SKILL.delegated.<sessionBackend>.md"` — at least one touched
-  integration is delegated cross-backend; one body per session backend
-  covers every `delegatedBackend` because the API is uniform.
+## How the Skill File Resolves
 
-Mixed states (some same-backend, some cross-backend) fall back to
-`SKILL.md`.
+`selectSkillVariantFile(skillSlug, sessionBackend, integrations)`
+returns one of four values, picked by tie-break order
+(`docs/design/appendices/native-integration-mode.md` §5.4.1):
+
+1. `"SKILL.delegated.<sessionBackend>.md"` — at least one touched
+   integration is delegated cross-backend. The body documents the
+   `/exec` task-mode proxy and any native siblings inline (§7.4
+   mixed-mode prompts).
+2. `"SKILL.native.<sessionBackend>.md"` — at least one touched
+   integration is `native` (and no cross-backend wins above). Native
+   is always explicit-skill-required (§7.5 — never drops to `null`).
+3. `null` — every touched integration is delegated same-backend AND
+   each declares the skill in its descriptor's
+   `sameBackendDropsSkillBody`. The connector self-describes; no body
+   is materialized.
+4. `"SKILL.md"` — direct mode, mixed states, or skill not gated by any
+   integration.
 
 ## Where You See It in the Dashboard
 
@@ -166,52 +257,79 @@ Mixed states (some same-backend, some cross-backend) fall back to
 - **Settings → Models** — main backend switch. Flipping main flips the
   same-/cross-backend status of every delegated integration and
   re-materializes the active DM workdir.
-- **Setup wizard** — first-run integration mode picker; delegated mode
-  is gated on a live probe that confirms the connector reports every
-  `requiredCapability` for the integration.
+- **Setup wizard** — first-run integration mode picker; both
+  `delegated` and `native` are gated on a **live probe** (§4.12.2)
+  that confirms three things before the mode is written to
+  `integrations.md`: the backend binary is resolvable, backend auth
+  is valid, and the connector reports every `requiredCapabilities`
+  entry the descriptor demands. Cached probe rows are invalidated on mode
+  change. `POST /api/integrations/:key/probe` is the chokepoint.
 
 ## How `integrations.md` Reflects This
 
-`~/.personal-agent/integrations.md` is the operator-readable snapshot the
-agent consults at session-init. Example:
+`<contextDir>/policies/integrations.md` is the operator-readable snapshot
+the agent consults at session-init. It is rendered as a Markdown table:
 
 ```markdown
-## gmail
-mode: delegated
-delegatedBackend: codex
-deniedTools:
-  - send_email
-  - delete_emails
-
-## google_calendar
-mode: delegated
-delegatedBackend: claude
-deniedTools:
-  - delete_event
+## Current state
+
+| Integration | Mode | Backend | Sub-tier | Last changed |
+|---|---|---|---|---|
+| gmail | delegated | codex | full-auto | 2026-05-15T07:15:32.911Z |
+| google_calendar | native | codex | — | 2026-05-15T07:15:38.605Z |
+| notion | disabled | — | — | 2026-05-15T07:14:56Z |
 ```
 
+The "Backend" column surfaces whichever binding is active for the row —
+`delegatedBackend` for `delegated`, `nativeBackend` for `native`. For
+`direct` and `disabled` rows it is `—`. The "Sub-tier" column annotates
+delegated Gmail rows (`draft-only` for Claude, `full-auto` for Codex)
+and is `—` for everything else. The file also includes the per-backend
+connector support matrix and the `deniedTools` block; both are rendered
+by `renderManagementMd` (`packages/daemon/src/core/management-md.ts`).
+
 A daemon-side write chokepoint guarantees the file matches DB state. The
 fs-watcher reverts hand-edits that fail validation and DMs the operator.
 
 ## Failure Modes
 
 - **Cross-backend, connector signed out on `delegatedBackend`** — the
-  invoke endpoint returns `502 auth_error`. Skill prose tells the agent
-  to surface this as "re-sign-in to the connector."
-- **Same-backend, connector not signed in on the DM backend** — the
-  agent has no Gmail tools at all. The setup wizard's pre-commit live
-  probe is the primary defense; if the operator signs out
+  `/exec` endpoint returns `502 auth_error`. Skill prose tells the
+  agent to surface this as "re-sign-in to the connector."
+- **Cross-backend, daemon's delegated-task queue saturated** — `/exec`
+  returns `503 delegated_proxy_busy`. The skill body advises a 3–5s
+  backoff with one retry.
+- **Cross-backend, fully-denied surface** — when every tool in the
+  integration's `capabilityTools` is in `deniedTools`, the task-mode
+  planner has nothing to pick. `/exec` short-circuits with
+  `errorClass: "denied_tool"` before spawning a subprocess.
+- **Same-backend or native, connector not signed in on the DM backend**
+  — the agent has no Gmail tools at all. The setup wizard's pre-commit
+  live probe is the primary defense; if the operator signs out
   post-setup, the agent will report "no Gmail tools available" until
   re-signed.
-- **Mode flip mid-call** — the invoke endpoint returns
-  `409 precondition`; agent re-reads `integrations.md` and replans.
+- **Mode flip mid-call** — `/exec` returns `409 precondition`; agent
+  re-reads `integrations.md` and replans. `native` rows also flip-lock
+  via the per-key `runtime_state.integration_flip_lock:<key>` row —
+  observations posted during the drain receive
+  `results[*].status = "flip_locked"`; the partial / agent profile
+  records the row in `errors[]` and the next routine tick reaps it.
 
 ## Related
 
 - [Safety Model](safety-model.md) — how the deny list (the primary
   defense in delegated mode) works.
 - [Skills](skills.md) — how `selectSkillVariantFile` picks the body.
-- Integration Delegation Framework (design) — `docs/design/14-integration-delegation.md`,
-  the load-bearing spec.
-- Delegated Mode v2 (design) — `DELEGATED-MODE-V2-DESIGN.md`, the
-  canonical model for the current behavior.
+- Integration Delegation Framework (design) —
+  `docs/design/14-integration-delegation.md`, the load-bearing spec
+  (§14.14 covers the four modes and their cascade rules).
+- Delegated Mode v2 (design) — `docs/design/17-delegated-mode-v2.md` §4.2, the
+  `/exec` task-mode model that replaced the retired `/invoke` RPC
+  route.
+- Native Integration Mode (design) —
+  `docs/design/appendices/native-integration-mode.md`, the on-demand
+  surface used by `native` rows and its `integration_flip_lock:<key>`
+  drain protocol.
+- Routine Data Acquisition (design) — `docs/design/appendices/routine-data-acquisition.md`
+  §6.8 / §8.1, the per-(integration, mode) partial schema used by
+  `routine.fetch_window`.

package/agent-assets/docs/concepts/memory-model.md

@@ -17,24 +17,33 @@ section: memory
 tags:
   - core
   - memory
-  - storage
+  - knowledge
+  - context
+  - safety
 status: stable
 ask_examples:
   - Where are my context files stored?
   - How does the agent edit context files?
   - What is the difference between context MD and SQLite?
+  - Where do management rules and policies live?
+  - How does the daemon prevent the agent from writing to disk directly?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-04
+updated: 2026-05-28
 keywords:
   - context
   - markdown
   - SQLite
-  - today.md
-  - user/profile.md
-  - roadmap.md
-  - rules/management.md
-  - rules/policies
+  - state/today.md
+  - identity/profile.md
+  - plans/roadmap.md
+  - policies/management.md
+  - policies/management-captures
+  - journal/agent.md
+  - context API
+  - AgentWriteTracker
+  - durable memory
+  - context-vault v2
 related:
   - features/memory-files/today
   - features/memory-files/user-profile
@@ -42,20 +51,27 @@ related:
   - features/memory-files/agent-journal
   - features/memory-files/schedule
   - features/memory-files/projects
-  - features/memory-files/management-rules
 ui_anchors:
   - /knowledge
   - /connections/knowledge
 context_files:
-  - today.md
-  - user/profile.md
-  - roadmap.md
-  - agent/journal.md
-  - daily/<date>.md
-  - projects/<slug>.md
-  - rules/management.md
-  - rules/policies/<slug>.md
-  - rules/policies/_index.md
+  - state/today.md
+  - identity/profile.md
+  - plans/roadmap.md
+  - journal/agent.md
+  - journal/daily/<date>.md
+  - plans/projects/<slug>.md
+  - policies/management.md
+  - policies/management-captures/<slug>.md
+  - policies/management-captures/_index.md
+config_keys:
+  - dayBoundaryHour
+  - dataDir
+api_endpoints:
+  - GET /api/context/*
+  - PUT /api/context/*
+  - PATCH /api/context/*
+  - DELETE /api/context/*
 ---
 
 # Memory Model
@@ -66,7 +82,11 @@ Aitne treats Markdown files in `~/.personal-agent/context/`
 as its long-term memory and SQLite
 (`~/.personal-agent/data/personal_agent.db`) as session-scoped state.
 Anything you want the agent to remember between runs lives in an MD
-file you can read, diff, and edit by hand.
+file you can read, diff, and edit by hand. The vault is partitioned
+into six authority classes — `identity/`, `state/`, `plans/`, `journal/`,
+`knowledge/`, and `policies/` — each carrying its own authority and
+lifecycle contract. See [Knowledge Layout](../reference/knowledge-layout.md)
+for the canonical map.
 
 ## Why This Concept Exists
 
@@ -92,28 +112,52 @@ indexes, and configuration.
   legal write path. The agent does not have direct `Edit` / `Write`
   permissions on the filesystem; it must go through the daemon.
 
+## How the Agent Writes
+
+The agent has no `Edit` or `Write` tool. To change a context file it
+calls the daemon over HTTP, and every write funnels through one
+endpoint family so the daemon can validate, hold locks, and snapshot a
+backup before touching disk. Paths are class-prefixed
+(`/api/context/<class>/<path>`):
+
+```bash
+# Append a section to today.md
+curl -X PATCH http://localhost:8321/api/context/state/today.md \
+  -H 'Content-Type: application/json' \
+  -d '{"mode":"append","section":"Notes","content":"Booked the dentist."}'
+```
+
+- `PUT /api/context/*` replaces a whole file; `PATCH` does a section op
+  (`append`, `replace`, `clear`, `clear_before`, `append_to_file`);
+  `DELETE` removes a file (permitted only for custom routines).
+- Legacy bare paths (`/api/context/today.md`) still resolve — the daemon
+  rewrites them to the canonical class-prefixed form in process, so a
+  plain `curl -X PATCH` without `-L` keeps working — but new writes
+  emit the class-prefixed path.
+- `state/today.md` and `plans/roadmap.md` are serialized behind
+  dedicated write locks, so two flows can't clobber each other.
+
 ## Concrete Examples
 
-- `today.md` — rewritten by the morning routine.
-- `user/profile.md` — your profile, hand-edited or appended by the
+- `state/today.md` — rewritten by the morning routine.
+- `identity/profile.md` — your profile, hand-edited or appended by the
   agent on request. Topic-shaped slices live alongside it
-  (`user/people.md`, `user/work.md`, `user/expertise.md`,
-  `user/personal.md`, `user/goals.md`). See
+  (`identity/people.md`, `identity/work.md`, `identity/expertise.md`,
+  `identity/personal.md`, `identity/goals.md`). See
   [User Profile](../features/memory-files/user-profile.md).
-- `roadmap.md` — long-running goals + Preparation Timeline rows that
+- `plans/roadmap.md` — long-running goals + Preparation Timeline rows that
   fire daily during the morning routine.
-- `agent/journal.md` — the agent's own running log of decisions,
+- `journal/agent.md` — the agent's own running log of decisions,
   retros, and judgement calls.
-- `daily/2026-04-25.md` — per-date archive of that day's plan,
+- `journal/daily/2026-04-25.md` — per-date archive of that day's plan,
   synthesized by the morning routine.
-- `projects/<slug>.md` — one file per active project.
-- `rules/management.md` — the umbrella registry: Source-of-Truth
+- `plans/projects/<slug>.md` — one file per active project.
+- `policies/management.md` — the umbrella registry: Source-of-Truth
   bindings, Managed Tasks, an Active Policies summary. Always
-  injected into every flow. See
-  [rules/management.md and rules/policies/](../features/memory-files/management-rules.md).
-- `rules/policies/<slug>.md` — one file per durable management rule
+  injected into every flow.
+- `policies/management-captures/<slug>.md` — one file per durable management rule
   ("from now on, do X"). The daemon auto-maintains a slug index at
-  `rules/policies/_index.md`.
+  `policies/management-captures/_index.md`.
 
 ## Where You See It in the Dashboard
 
@@ -124,8 +168,9 @@ indexes, and configuration.
 
 ## Related
 
-- [today.md](../features/memory-files/today.md)
-- [user/profile.md](../features/memory-files/user-profile.md)
-- [roadmap.md](../features/memory-files/roadmap.md)
+- [Knowledge Layout](../reference/knowledge-layout.md) — canonical map of every vault file
+- [state/today.md](../features/memory-files/today.md)
+- [identity/profile.md](../features/memory-files/user-profile.md)
+- [plans/roadmap.md](../features/memory-files/roadmap.md)
 - [Skills](skills.md) — the per-skill SKILL.md files that tell the
   agent how to read and write each context file.