@aitne-sh/aitne 0.1.3 → 0.1.4

package/agent-assets/agent-profiles/conversational.md

@@ -16,7 +16,9 @@ When the user asks a sourcing or technical question — "where is that written?"
 
 ## Tone and format
 
-Reply in the user's language; match their formality. Keep technical terms in their original form.
+Output language: follow `<output_language_policy>`. For DMs the
+input-language rule applies. Match the user's formality. Keep technical
+terms in their original form.
 
 Be direct and short. Respond to the user's intent, not to a restatement of what they said.
 
@@ -31,3 +33,23 @@ This profile is used in two distinct modes. (1) `message.received.*` — the use
 - **Future actions**: schedule through this daemon — `POST /api/recurring-schedules` for recurring, `POST /api/schedule/dm` or `POST /api/schedule` for one-shot. Never delegate to a cloud-hosted scheduled-agent feature your CLI may expose; those cannot reach `localhost:8321` and so cannot deliver via the user's chat platforms or use any integration registered here.
 - **File deliverables** (md / PDF / CSV / chart / image): send via the **attach** skill so the user sees them inline. Never paste a filesystem path and claim you produced a file unless you actually uploaded it via `POST /api/chat/outbound-attachments`.
 - **Fidelity**: describe only actions you actually executed. If a tool call returned an error, say it failed. Fabricating a successful outcome is a safety violation, not a convenience.
+
+## Integration routing summary
+
+The daemon binds each external integration to one of four modes:
+`direct` (daemon poller + `/api/<key>/*` routes), `delegated` (daemon
+proxy via `POST /api/integrations/<key>/exec`), `native` (this
+session's backend reaches the integration via its own MCP — no daemon
+proxy), or `disabled` (no surface at all). The table below is rendered
+fresh per session by the daemon's session compiler; do not assume it
+from memory.
+
+<integration-routing-table>
+
+When a row says `native`, the `/api/<key>/*` routes and
+`POST /api/integrations/<key>/exec` both return `410` with
+`X-Integration-Mode: native`. Reach the connector through the MCP
+tools your session already holds; consult the per-integration skill
+body for the exact tool namespace and the destructive-confirm
+contract.
+

package/agent-assets/agent-profiles/observer.md

@@ -26,3 +26,18 @@ Be decisive and concise.
 ## Boundaries
 - Do NOT send more than one notification per event.
 - Do NOT modify user/profile.md (observer events do not express user preferences).
+
+## Integration routing summary
+
+The daemon binds each external integration to one of four modes:
+`direct`, `delegated`, `native`, `disabled`. The table below is
+rendered fresh per session — trust it over memory.
+
+<integration-routing-table>
+
+`native` rows reach the integration via this session's backend MCP;
+the daemon's `/api/<key>/*` routes and
+`POST /api/integrations/<key>/exec` both return `410`. Use the MCP
+tools your session already holds (consult the per-integration skill
+body for the exact tool namespace).
+

package/agent-assets/agent-profiles/routine-fetch-window.md

@@ -0,0 +1,128 @@
+# Routine Data-Fetch Pre-Pass
+
+You are the data-fetch pre-pass for a parent routine. The dispatcher will spawn
+the parent routine session immediately after you terminate; your job is
+mechanical.
+
+## Principles
+- **Fetch, don't think.** Read the `<acquisition-plan>` block in your prompt.
+  It enumerates `(integration, mode, window, account?)` tuples. For each row,
+  perform the matching fetch and POST results to `/api/observations`.
+- **Trust the routing the daemon resolved for you.** The plan already encodes
+  the per-(integration, mode) path. Do not second-guess: do not probe MCP
+  registries, do not list "common tool names", do not guess. The integration
+  partial included in your prompt states the call shape; your skills + bound
+  tools resolve it. If no surface is bound for a tuple, record an error and
+  continue with the next row.
+- **No interpretation.** The async summarizer worker drains
+  `/api/observations` after you return and populates `summary_text` /
+  `novelty_score`. Do not summarize, rank, or filter — your output is the
+  raw payload.
+- **Never write to context MD files.** today.md, weekly/, journal, schedule —
+  all of that belongs to the parent routine session, not to you.
+- **Single JSON line on stdout.** When done, print exactly one JSON object
+  with the shape below — no prose, no markdown fences. The dispatcher
+  records this in `agent_actions.detail` and surfaces it as
+  `<fetch_report>` on the parent routine's prompt.
+
+## Fetch routing summary
+
+For each `<fetch integration="…" mode="…" window="…" account="…">` row in
+`<acquisition-plan>`, route by `mode`:
+
+- **direct** — call the daemon REST endpoint named by the integration
+  partial (`/api/mail/...`, `/api/calendar/events`, `/api/notion/...`,
+  `/api/calendar/outlook`). Pass the query string from the partial.
+- **delegated** with `delegated_to == your session backend` — use the
+  in-session connector surface your skills document for this integration.
+- **delegated** with `delegated_to != your session backend` —
+  `POST /api/integrations/<key>/exec` with a natural-language task. This
+  branch is unavailable for `userManagedConnector` integrations
+  (`outlook_mail`, `outlook_calendar`); for those, fall through to the
+  user-managed branch documented in the partial.
+- **native** — use the in-session connector surface; the partial states the
+  fetch intent, not specific tool names.
+- **disabled** — skip silently.
+
+If the partial for an integration is missing or the row has no usable
+surface (e.g. user picked native for Outlook Mail without binding any
+Outlook surface), record
+`{"type":"no-surface","integration":"<key>","account":"<id>"}` in `errors`
+and continue. Never halt the pre-pass — the parent routine continues
+with whatever observations the rest of the plan produced.
+
+## Observation POST contract
+
+For every fetched item, POST to `/api/observations`:
+
+```json
+{
+  "source":     "<integrationKey>:<accountOrScope>",
+  "ref":        "<provider-side stable id>",
+  "changeType": "created",
+  "actor":      "agent",
+  "payload": {
+    "kind":       "mail" | "calendar" | "notion",
+    "providerId": "<account id>",
+    "raw":        { /* compact subset: subject/from/snippet/date for mail,
+                        title/start/end/attendees for calendar,
+                        title/last_edited/parent for notion */ }
+  }
+}
+```
+
+- `actor` MUST be `"agent"`. The server rejects `"user"`.
+- Do NOT compute or supply a dedup hash; the server computes
+  `contentHash` from `(source, payload)` and returns it in the
+  response.
+- The response distinguishes three outcomes via `action` (on 200) or
+  `error` (on 409). Count each into the report:
+  - `200 {action: "created"}`  → `posted++`
+  - `200 {action: "modified"}` → `posted++` (server updated the
+    existing `(source, ref)` pending row with a different payload)
+  - `409 {error: "duplicate"}` → `duplicates++` (identical payload
+    already pending — no row was written, no summarizer re-enqueue)
+  - `409 {error: "integration_flip_in_progress"}` → append
+    `{type:"flip-locked", integration:"<key>", …}` to `errors` and
+    move on; do NOT retry inline (the next routine tick will).
+- For an item whose payload differs from a prior pending row with the
+  same `(source, ref)`, send `changeType: "modified"` — the server
+  detects identical payloads via the canonical contentHash regardless
+  of `changeType`, so this field is informational for downstream
+  consumers, not part of the dedup signal.
+- For a deletion, send `changeType: "deleted"` with a minimal payload
+  (`{"kind":"…","providerId":"…","raw":{"deletedAt":"<iso>"}}`).
+
+## Boundaries
+- Do NOT call `/api/context/*` (write or read) — that surface belongs to
+  the parent routine session.
+- Do NOT send notifications; the pre-pass is invisible to the owner by
+  contract.
+- Do NOT spawn sub-tasks (Task tool, sub-agent) — keep the run flat.
+- Do NOT exceed the configured `max_turns` / `max_budget_usd` for
+  `routine.fetch_window`. If you hit the cap, record what's left as
+  `{"type":"budget-exhausted","remaining":[…]}` in `errors`.
+
+## Output format
+
+Print exactly one JSON line on stdout, then terminate:
+
+```json
+{"fetched": <int>, "posted": <int>, "duplicates": <int>, "errors": [{…}, …]}
+```
+
+Field semantics:
+- `fetched`    — total items returned by upstream APIs across all rows.
+- `posted`     — count of 200 responses (`action ∈ {created, modified}`).
+- `duplicates` — count of `409 {error:"duplicate"}` responses
+  (canonical `(source, payload)` already pending).
+- `errors`     — array of `{type, ...}` records. Common types:
+  - `no-surface`     — the row points at an in-session connector that
+    isn't bound on this backend.
+  - `flip-locked`    — `409 {error:"integration_flip_in_progress"}`;
+    the integration is mid-flip and the write was rejected.
+  - `unexpected-row` — `mode="disabled"` slipped past the daemon filter.
+  - `fetch-failed`   — upstream API returned non-2xx;
+    `{type, integration, account?, status, message}`.
+  - `budget-exhausted` — hit the configured `max_turns` /
+    `max_budget_usd` for `routine.fetch_window`.

package/agent-assets/agent-profiles/routine.md

@@ -14,3 +14,19 @@ You execute autonomous scheduled routines (morning/evening). No direct user inte
 - Prefer structured output (tables, bullets) over prose.
 - When updating context files: write the minimum viable content that preserves all information.
 - Do not summarize what you just did in your final response — the action log is self-documenting.
+
+## Integration routing summary
+
+The daemon binds each external integration to one of four modes:
+`direct`, `delegated`, `native`, `disabled`. The table below is
+rendered fresh per session — trust it over memory.
+
+<integration-routing-table>
+
+`native` rows reach the integration via this session's backend MCP;
+the daemon's `/api/<key>/*` routes and
+`POST /api/integrations/<key>/exec` both return `410`. Consult the
+per-integration skill body materialised under `.claude/skills/` /
+`.codex/skills/` / `.gemini/skills/` for the exact tool namespace and
+the destructive-confirm contract that still applies.
+

package/agent-assets/agent-profiles/task.md

@@ -16,3 +16,18 @@ You execute a pre-scheduled task. The description in your prompt was written by
 ## Boundaries
 - Do NOT send multiple notifications for a single task (one notification maximum).
 - Do NOT schedule more than 5 follow-up wake-ups per execution.
+
+## Integration routing summary
+
+The daemon binds each external integration to one of four modes:
+`direct`, `delegated`, `native`, `disabled`. The table below is
+rendered fresh per session — trust it over memory.
+
+<integration-routing-table>
+
+`native` rows reach the integration via this session's backend MCP;
+the daemon's `/api/<key>/*` routes and
+`POST /api/integrations/<key>/exec` both return `410`. Consult the
+per-integration skill body for the MCP tool namespace and the
+destructive-confirm contract.
+

package/agent-assets/docs/concepts/auth-health.md

@@ -24,7 +24,7 @@ ask_examples:
   - What happens when my Codex token expires?
 locale: en-US
 created: 2026-04-25
-updated: 2026-04-25
+updated: 2026-05-04
 keywords:
   - auth
   - credentials
@@ -32,6 +32,7 @@ keywords:
   - degraded
 related:
   - concepts/backends-and-tiers
+  - concepts/costs-and-quotas
   - troubleshooting/auth-failed
 config_keys:
   - authProbeDisabled
@@ -55,19 +56,34 @@ routine fails.
 
 ## Definitions
 
-- **Probe**: a no-op call against each backend's auth surface (Claude
-  credentials store, Codex token, Gemini API key).
+- **Probe**: a no-op call against each backend's auth surface. With
+  a registered API key the probe hits the provider's lightweight
+  `models` endpoint (Anthropic, OpenAI, Google) and verifies the key
+  is live. Without an API key, the probe checks whatever local CLI
+  login Aitne fell back to (Claude credentials store, Codex token,
+  Gemini ADC).
 - **Preflight freshness**: how long the daemon trusts a successful
   probe before re-running.
-- **Recovery**: backend-specific repair (re-login, refresh token,
-  re-paste API key).
+- **Recovery**: backend-specific repair. The recommended path is
+  re-pasting the API key on `/settings/models`; for the fallback
+  path, re-running the matching CLI login (`claude`,
+  `codex login`, `gemini auth`).
 
 ## Concrete Examples
 
-- Claude credentials expire → probe fails → card flips amber → operator
-  re-runs `claude` CLI login.
-- Gemini API key revoked → probe fails → card flips red → operator
-  pastes a new key on `/settings/models`.
+- Anthropic API key revoked → probe fails → card flips red →
+  operator pastes a new key on `/settings/models`. Per-call billing
+  resumes against the new key on the next run.
+- Operator never registered an API key, ran on the subscription
+  fallback, and the underlying `claude` CLI session expired → probe
+  fails → card flips amber → recommended fix is to register an API
+  key on `/settings/models`; otherwise re-run the CLI login.
+
+Cloud-provider credentials (Bedrock / Vertex / Foundry / Azure
+OpenAI / Gemini-Vertex) are not probed against a `models` endpoint —
+those providers trust the SDK's runtime auth chain, so the auth-
+health card stays neutral until the first execution either succeeds
+or surfaces a runtime auth error.
 
 ## Related
 

package/agent-assets/docs/concepts/backends-and-tiers.md

@@ -26,7 +26,7 @@ ask_examples:
   - What is the difference between heavy and light tier?
 locale: en-US
 created: 2026-04-25
-updated: 2026-04-25
+updated: 2026-05-04
 keywords:
   - claude
   - codex
@@ -36,10 +36,15 @@ keywords:
   - haiku
   - gpt-5
   - tier
+  - bedrock
+  - vertex
+  - foundry
+  - azure-openai
 related:
   - concepts/process-keys
   - concepts/costs-and-quotas
   - features/operations/backend-routing
+  - guides/use-cloud-providers
 ui_anchors:
   - /settings/models
 ---
@@ -65,9 +70,40 @@ model used at install time:
   `/settings/models`.
 
 Every ProcessKey resolves to a backend + model binding via
-`BackendRouter`. Aitne does not store or read subscription-plan state
-— bindings come from `process_backend_config` rows seeded at install
-time.
+`BackendRouter`. Aitne **does not store or read subscription-plan
+state** — there is no "Claude Pro / Max / Team" or "ChatGPT Plus /
+Pro" picker in the wizard or settings, and the DB has no plan
+column. Bindings come from `process_backend_config` rows seeded at
+install time and edited from `/settings/models`.
+
+Each backend authenticates via a provider API key registered on
+`/settings/models`. The provider dropdown picks one of:
+
+| Backend | Direct API key | Cloud provider options |
+|---|---|---|
+| `claude` | `anthropic` (`sk-ant-…`) | `bedrock` (Amazon Bedrock), `vertex` (Google Vertex AI), `foundry` (Microsoft Foundry) |
+| `codex` | `openai` (`sk-…`) | `azure-openai` (Codex CLI on Azure OpenAI; daemon writes a managed `config.toml` under `<dataDir>/codex-home/`) |
+| `gemini` | `google` (`AIza…`) | `gemini-vertex` (Gemini on Google Vertex AI) |
+
+API keys are the recommended and provider-supported auth method for
+headless agent use; if you skip the key the daemon falls back to the
+CLI's local subscription login, which most providers do not
+officially support — Anthropic in particular currently prohibits the
+Claude Agent SDK on a Claude Pro / Max subscription. The dashboard
+surfaces a warning whenever a backend is on subscription auth.
+
+Cloud providers (Bedrock / Vertex / Foundry / Azure OpenAI /
+Gemini-Vertex) let teams reuse an existing enterprise contract,
+keep model traffic inside a private VPC, or take advantage of
+provider-side rate-limit pools. Aitne stores the credentials in the
+OS keychain and mirrors the corresponding env vars
+(`CLAUDE_CODE_USE_BEDROCK=1`, `CLAUDE_CODE_USE_VERTEX=1`,
+`CLAUDE_CODE_USE_FOUNDRY=1`, `GOOGLE_GENAI_USE_VERTEXAI=true`, …)
+into the backend subprocess. See
+[Use cloud providers](../guides/use-cloud-providers.md) for the
+end-to-end walkthrough and
+[Costs and Quotas](costs-and-quotas.md) for the cost shape of each
+path.
 
 ## Why This Concept Exists
 

package/agent-assets/docs/concepts/costs-and-quotas.md

@@ -7,12 +7,11 @@ aliases:
   - cost
   - budget
   - quota
-  - subscription limit
 category: concepts
 summary: |
-  How Aitne meters subscription windows and per-call costs,
-  and where the operator sees the rollup. Cost tracking is
-  observational — the dashboard reports, it does not bill.
+  How Aitne meters per-call costs and provider quotas, and where the
+  operator sees the rollup. Cost tracking is observational — the
+  dashboard reports, it does not bill.
 section: cost
 tags:
   - cost
@@ -21,24 +20,27 @@ tags:
 status: stable
 ask_examples:
   - How do I see how much my agent is spending?
-  - When do my Opus tokens reset?
-  - Why is the agent saying "subscription limit reached"?
+  - Why did the agent fail over from Claude to Codex?
+  - What does the autonomous daily cost cap do?
 locale: en-US
 created: 2026-04-25
-updated: 2026-04-25
+updated: 2026-05-04
 keywords:
   - cost
   - budget
   - quota
-  - max5
-  - max20
-  - opus window
+  - api quota
+  - per-token billing
   - gemini quota
+  - subscription fallback
 related:
   - concepts/backends-and-tiers
+  - concepts/auth-health
   - features/operations/cost-tracking
+  - guides/use-cloud-providers
 ui_anchors:
   - /analytics
+  - /settings/models
 config_keys:
   - autonomousDailyCostCapUsd
 ---
@@ -47,13 +49,22 @@ config_keys:
 
 ## TL;DR
 
-Each backend bills differently:
+Aitne is designed to run on **provider API keys** registered in the
+dashboard. With keys configured, every backend bills per-token /
+per-call against your provider account:
 
-- **Claude Code** — flat-rate inside `Claude Max5` / `Max20` with a
-  rolling 5-hour Opus window.
-- **Codex** — flat-rate inside `Codex Pro`.
-- **Gemini** — per-token billed against the Google API quota; free tier
-  has per-day caps.
+- **Claude (via Claude Code)** — per-token billing on
+  `ANTHROPIC_API_KEY`.
+- **Codex (via Codex CLI)** — per-token billing on `OPENAI_API_KEY`.
+- **Gemini (via Gemini CLI)** — per-token billing on `GEMINI_API_KEY`
+  / `GOOGLE_API_KEY`; the free tier has per-day caps.
+
+If you skip the API key, the daemon falls back to whatever
+subscription auth the CLI already has on your machine. That fallback
+is not provider-supported for automated agent use — see
+[Authentication policy](#authentication-policy) below — and the cost
+shape becomes whatever the underlying subscription enforces (e.g.
+Claude's rolling 5-hour Opus window when running on a Max plan login).
 
 The dashboard rolls cost up by ProcessKey, by backend, and by agent day.
 
@@ -68,11 +79,48 @@ The autonomous daily-cost cap (`autonomousDailyCostCapUsd`) is a
 bumper, not a budget — it pauses autonomous routines when crossed but
 does not interrupt reactive (in-the-loop) traffic.
 
+## Authentication policy
+
+**Provider API keys are the recommended way to run Aitne.** The
+daemon exposes only one auth-config surface — the per-backend API
+key picker on `/settings/models` — and treats whatever
+*subscription* login the matching CLI happens to have on your
+machine purely as a fallback when no key is registered.
+
+Concretely:
+
+- **Subscription-plan registration has been removed.** The setup
+  wizard and `/settings/models` no longer ask the operator which
+  subscription tier they hold; the DB no longer stores plan state;
+  the router never branches on plan.
+- **API key first.** When a key is registered (direct or one of the
+  cloud-provider options — Bedrock / Vertex / Foundry / Azure
+  OpenAI / Gemini-Vertex), Aitne mirrors the corresponding env vars
+  into the backend subprocess and bills per-token / per-call
+  against your provider account.
+- **Subscription is fallback only.** If you skip the key, the
+  daemon runs against whatever local CLI login is present
+  (`claude`, `codex login`, `gemini auth`). The dashboard surfaces
+  a `SubscriptionAuthWarning` banner whenever any backend is on
+  this path because most provider policies for headless /
+  programmatic agents do not extend to personal subscriptions —
+  **Anthropic currently prohibits using the Claude Agent SDK with a
+  Claude Pro / Max subscription**.
+
+If you see the warning banner, the recommended action is to
+register an API key on `/settings/models`.
+
 ## Definitions
 
-- **Subscription window**: Claude Max plans have a rolling 5-hour
-  budget for Opus + a separate Sonnet bucket. The dashboard shows
-  remaining quota and the next reset time.
+- **API key**: per-backend secret stored in the OS keychain (or
+  inherited from your shell env) — the daemon's preferred auth
+  method. Mirrored into the SDK / CLI subprocess via
+  `ANTHROPIC_API_KEY` / `OPENAI_API_KEY` / `GEMINI_API_KEY` /
+  `GOOGLE_API_KEY`.
+- **Subscription fallback**: the CLI's local login (`claude`,
+  `codex login`, `gemini auth`). Used only when no API key is
+  configured. Cost behaviour then matches whatever the subscription
+  enforces (e.g. Claude's rolling 5-hour Opus window on a Max plan).
 - **Daily cost cap**: `autonomousDailyCostCapUsd` — autonomous routines
   pause on the day they cross it. Reactive DMs / dashboard chat keep
   running; you can always reach the agent.
@@ -83,18 +131,32 @@ does not interrupt reactive (in-the-loop) traffic.
 
 ## Concrete Examples
 
-- Morning routine on Opus / Max20 = "no extra charge", but eats the
-  rolling 5-hour window.
-- Morning routine on Sonnet / Max5 = covered by the Sonnet bucket
-  (fast resets), Opus window untouched.
-- A Gemini hourly check on Flash / API tier = ~$0.0005 per fire.
+- Morning routine on Sonnet via `ANTHROPIC_API_KEY` = per-token
+  billing against your Anthropic account, typical cost a few cents.
+  Since 2026-05, a lite-tier `routine.fetch_window` pre-pass (Haiku)
+  fetches mail / calendar / Notion windows ahead of the main session,
+  trimming the main Sonnet input from ~35k tokens to ~18k (~24% total
+  cost reduction per fire).
+- Morning routine on Opus via `ANTHROPIC_API_KEY` = per-token billing
+  on the Opus rate; pin only when Sonnet has failed the task. **No
+  recurring routine seeds on Opus by default** — only the one-shot
+  `routine.morning_routine_initial` runs heavy out of the box.
+- Gemini hourly check on Flash via `GEMINI_API_KEY` = ~$0.0005 per
+  fire on the paid tier; free tier instead consumes a per-day quota
+  slot.
+- Claude Code without an API key (subscription fallback on a Max20
+  login) = covered by the subscription, but the daemon flags the
+  fallback because it falls outside Anthropic's published policy.
 
 ## Where You See It in the Dashboard
 
 - **Analytics** rolls today's cost by backend, by ProcessKey, and by
-  hour. Window-remaining math is here too.
+  hour. When a backend is running on the subscription fallback,
+  remaining-window math is shown there too.
 - **Sidebar footer** shows the day's running total.
 - **Activity** event details include the per-execute cost.
+- **Settings → Models** exposes the per-backend API-key panel and a
+  warning banner whenever a backend is running on subscription auth.
 
 ## Related
 

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

@@ -17,9 +17,7 @@ summary: |
   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: the agent describes intent
-  in natural language and the daemon's delegate picks the connector
-  tool).
+  (`/api/integrations/:key/invoke` proxy).
 section: integrations
 tags:
   - core
@@ -65,7 +63,7 @@ Each integration is in one of three 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/exec` task endpoint |
+| `delegated` | The agent's backend connector (claude.ai / ChatGPT / Google) | Native MCP tools or the `/api/integrations/:key/invoke` proxy |
 | `disabled` | Nobody | Nothing — the integration is off |
 
 Under `delegated`, two sub-cases exist depending on whether the DM session's
@@ -74,12 +72,9 @@ 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/exec {task, outputSchema, …}` with a
-  natural-language `task`. The daemon spawns a one-shot subprocess of
-  `delegatedBackend`, lets it pick the right MCP tool against the
-  per-task allowed-tools envelope, validates the JSON, and returns it.
-  (Earlier versions of this concept used an RPC `{tool, args}` shape
-  at `/invoke`; that route is retired — see DELEGATED-TASK-MODE-DESIGN.md.)
+  `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.
 
 ## Why This Concept Exists
 
@@ -115,8 +110,7 @@ that case the daemon spawns the other backend per call.
   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/exec` (task mode — natural-language
-  `task` + JSON `outputSchema`) and the daemon spawns
+  `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.
@@ -148,7 +142,7 @@ When you pick `delegated`, also pick `delegatedBackend`:
 |---|---|
 | 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/exec -d '{"task":"Search Gmail for…","outputSchema":{...},"cacheable":true}'` → daemon spawns Codex subprocess → Codex picks the right MCP primitive (e.g. `_search_emails`) → daemon validates the JSON against the schema and returns it |
+| 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 |
 
 ## How the Skill File Resolves
 

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

@@ -25,7 +25,7 @@ ask_examples:
   - What is the difference between context MD and SQLite?
 locale: en-US
 created: 2026-04-25
-updated: 2026-04-25
+updated: 2026-05-04
 keywords:
   - context
   - markdown
@@ -33,6 +33,8 @@ keywords:
   - today.md
   - user/profile.md
   - roadmap.md
+  - rules/management.md
+  - rules/policies
 related:
   - features/memory-files/today
   - features/memory-files/user-profile
@@ -40,6 +42,7 @@ related:
   - features/memory-files/agent-journal
   - features/memory-files/schedule
   - features/memory-files/projects
+  - features/memory-files/management-rules
 ui_anchors:
   - /knowledge
   - /connections/knowledge
@@ -50,6 +53,9 @@ context_files:
   - agent/journal.md
   - daily/<date>.md
   - projects/<slug>.md
+  - rules/management.md
+  - rules/policies/<slug>.md
+  - rules/policies/_index.md
 ---
 
 # Memory Model
@@ -101,6 +107,13 @@ indexes, and configuration.
 - `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
+  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
+  ("from now on, do X"). The daemon auto-maintains a slug index at
+  `rules/policies/_index.md`.
 
 ## Where You See It in the Dashboard