@aitne-sh/aitne 0.1.5 → 0.1.7

package/agent-assets/docs/troubleshooting/wiki-ingest-full-blocked.md

@@ -0,0 +1,96 @@
+---
+schema_version: 1
+slug: troubleshooting/wiki-ingest-full-blocked
+title: "`!compile full` Is Blocked"
+id: wiki-ingest-full-blocked
+aliases:
+  - ingest full refused
+  - wiki approval pending
+  - wiki dirty tree refused
+category: troubleshooting
+summary: |
+  `!compile full` either refused with "uncommitted changes" (git
+  pre-compile gate) or returned "Sent for approval" (cost gate).
+  This entry tells you how to clear each branch.
+section: wiki-ingest-full-blocked
+tags:
+  - troubleshooting
+  - wiki
+  - cost
+  - git
+status: stable
+ask_examples:
+  - Why did !compile full refuse to run?
+  - Where do I approve a pending wiki compile?
+  - Why does !compile full want a clean git tree?
+locale: en-US
+created: 2026-05-12
+updated: 2026-05-12
+related:
+  - features/wiki/commands
+  - guides/budget-and-cost-for-wiki
+  - features/wiki/overview
+ui_anchors:
+  - /settings/wiki
+  - /approvals
+---
+
+# `!compile full` Is Blocked
+
+## What You See
+
+You ran `!compile full` and the bang reply says either:
+
+- "Cannot run `!compile full` — the external vault has uncommitted
+  changes."
+- "Sent for approval. Open `/settings/wiki` → Approvals to confirm
+  and the compile will start."
+
+## "Uncommitted Changes"
+
+This is the **git pre-compile gate** firing. Aitne refuses to start
+`!compile full` on an external git-tracked vault with a dirty working
+tree because the pre-compile snapshot it would create can no longer
+be a clean baseline.
+
+To proceed:
+
+1. `git -C <vault> status` — review the dirty paths Aitne listed.
+2. Commit or stash them: `git add -A && git commit -m "wip"` or
+   `git stash -u`.
+3. Re-run `!compile full`. On a clean tree Aitne runs
+   `git add -A && git commit -m "aitne wiki: pre-compile snapshot <ts>"`
+   automatically.
+
+If you don't want the auto-commit, disable **Auto-commit before
+`!compile full`** in **Settings → Wiki** (only visible for
+git-tracked external vaults). Aitne will then run without taking a
+snapshot — and the approval-gate DM will explicitly say "no git
+backup taken".
+
+## "Sent for Approval"
+
+The cost estimator's pessimistic bound (`2× expected`) exceeded the
+per-workspace approval threshold (default $2.00). To approve:
+
+1. Open the dashboard.
+2. Go to **Settings → Wiki → Approvals** (or hit the **Approvals**
+   notification card directly).
+3. Review the estimate. Click **Approve** to run, **Deny** to skip.
+
+If the estimate looks wrong, you have three levers:
+
+- **Lower the avg input tokens** — the default 1500 is conservative
+  for short raw notes; check whether your typical raw note is
+  smaller.
+- **Switch the `wiki.compile` model** to a lite tier in the
+  per-command selector. Sonnet's per-token cost is the dominant
+  variable.
+- **Raise the threshold** in **Settings → Wiki** so routine
+  recompiles don't queue an approval.
+
+## "Not Enabled"
+
+If `!compile full` replies "Wiki is not enabled", you have no active
+workspace row. Run **Enable Internal Workspace** (or **Probe &
+Create External**) on `/settings/wiki` first.

package/agent-assets/docs/troubleshooting/wiki-write-failed.md

@@ -0,0 +1,82 @@
+---
+schema_version: 1
+slug: troubleshooting/wiki-write-failed
+title: Wiki Write Failed
+id: wiki-write-failed
+aliases:
+  - wiki EPERM
+  - obsidian cli not detected
+  - wiki write strategy stuck on cli
+category: troubleshooting
+summary: |
+  A wiki bang command failed to write, or the dashboard health card
+  shows a non-`fs` strategy with `cliAvailable: false`. Triage the
+  filesystem permission vs. the Obsidian CLI fallback path.
+section: wiki-write-failed
+tags:
+  - troubleshooting
+  - wiki
+  - obsidian
+status: stable
+ask_examples:
+  - Why can't the wiki write to my Obsidian vault?
+  - Why does the wiki health card say cliAvailable false?
+  - How do I retry the write-strategy probe?
+locale: en-US
+created: 2026-05-12
+updated: 2026-05-12
+related:
+  - features/wiki/overview
+  - guides/use-an-existing-obsidian-vault
+---
+
+# Wiki Write Failed
+
+## What You See
+
+A wiki bang command (`!ingest`, `!compile`) reports a write failure in
+the daemon log, or the dashboard `/api/wiki/:ws/health` endpoint
+surfaces a non-`fs` strategy with `cliAvailable: false`.
+
+## Quick Checklist
+
+1. **Internal mode?** Internal workspaces always write via the local
+   filesystem. If you see EPERM there, the underlying issue is
+   `dataDir` permissions — fix those rather than thinking the wiki
+   is the problem.
+2. **External mode + `write_strategy=fs`?** The filesystem rejected
+   the write. Common causes:
+   - iCloud sandbox (most frequent on macOS).
+   - Read-only volume / snapshot mount.
+   - Filesystem ACL on the parent directory.
+3. **External mode + `write_strategy=cli`?** The probe already fell
+   back to the Obsidian CLI but the CLI is unavailable. See the CLI
+   checklist below.
+
+## The CLI Fallback Path
+
+When direct fs writes fail with `EPERM` / `EACCES` / `EROFS` /
+`EBUSY`, Aitne falls back to the official Obsidian CLI (1.12+).
+Requirements:
+
+- Obsidian installed (1.12 or later).
+- **Settings → General → Command line interface** enabled inside
+  Obsidian.
+- The Obsidian app is running (the CLI is a thin client to the live
+  process).
+- The `obsidian` binary is on `PATH` (`~/.zprofile` is auto-updated
+  when CLI is enabled).
+
+If any of these is missing, the daemon surfaces a structured error:
+
+| Error code | Meaning |
+|---|---|
+| `EWIKI_CLI_UNAVAILABLE` | Aitne's `ObsidianService` is not configured. Open `Settings → Integrations → Obsidian` and complete the pairing. |
+| `EWIKI_CLI_NOT_RUNNING` | Obsidian is not running. Launch the app and retry. |
+
+## Force a Re-Probe
+
+If you've fixed the underlying issue (granted iCloud permission,
+mounted the disk read-write) but the cached strategy is still `cli`,
+flip the dropdown in **Settings → Wiki → Write strategy** back to
+`auto`. The next write probes again and persists the fresh outcome.

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

@@ -1,6 +1,6 @@
 ---
 name: context
-description: Load when reading or writing project notes, weekly/monthly summaries, or agent-journal.md. Owns GET/PATCH for context files except today.md and roadmap.md, which use their dedicated skills.
+description: Load when reading or writing project notes, weekly/monthly summaries, or agent/journal.md. Owns GET/PATCH for context files except today.md and roadmap.md, which use their dedicated skills.
 allowed-tools:
   - Bash(curl *)
   - Read
@@ -95,12 +95,58 @@ can copy the same pattern into their own skills.
 
 **Decision tree:**
 
-1. **Existing or new?** `GET /api/context/list/projects` and match
-   the user's wording against returned filenames (slug stem) and, if
-   needed, against the H1 / title of each candidate via
-   `GET /api/context/projects/<slug>`. If multiple candidates match,
-   prefer the one with the closest slug stem; if still ambiguous,
-   ask *"is this for `<slug-A>` or `<slug-B>`?"* before writing.
+1. **Existing or new? (Plus decline-marker pre-check.)**
+   - `GET /api/context/list/projects` and match the user's wording
+     against returned filenames (slug stem) and, if needed, against
+     the H1 / title of each candidate via
+     `GET /api/context/projects/<slug>`. If multiple candidates
+     match, prefer the one with the closest slug stem; if still
+     ambiguous, ask *"is this for `<slug-A>` or `<slug-B>`?"* before
+     writing.
+   - **Decline-marker pre-check (Goal 3 — never ask twice).** Before
+     classifying a no-match as new, compute the candidate slug and
+     read `agent/journal.md ## Declined Intents`:
+     ```bash
+     curl -s "http://localhost:8321/api/context/agent/journal" \
+       | jq -r '.content // ""' \
+       | awk '/^## Declined Intents/{f=1;next} f && /^## /{exit} f'
+     ```
+     (404 from the GET means the journal file does not yet exist →
+     no marker can exist → treat as "no marker present" and continue
+     to the no-match path.) If any line under that section contains
+     `create_project:<slug>` (the dedup_key shape — see §"Reply
+     branches" below), the user previously declined this exact
+     intent. The default behaviour is **skip silently** — do NOT
+     re-ask, do NOT schedule a confirm, do NOT write.
+
+     **Reversal-signal carve-out (rare).** If the user's current DM
+     contains an unambiguous reversal phrase for this exact intent,
+     treat the DM as a fresh affirmative. Run the
+     §"Decline-marker reversal" recipe below (remove the matching
+     marker line, then PUT the project file per Step 4). Pattern
+     shape: explicit verb of resumption + the topic + action
+     consent. Match on intent, not surface vocabulary — any
+     language qualifies.
+
+     Counts as reversal (do the recipe):
+     - *"actually let's start that LA project after all"*
+     - *"go ahead and track LA PM"*
+     - *"changed my mind, let's do it"*
+
+     Does NOT count as reversal (skip silently, marker stays):
+     - bare re-mention without an action verb: *"still thinking
+       about LA PM"*, *"made a bit of progress on LA"*
+     - status update on the topic without consent: *"LA classes
+       started"*, *"midterm was hard"*
+     - ambiguous "maybe" / non-commitment: *"maybe I'll track it
+       eventually"*, *"might revisit this later"*
+
+     The examples are English for prompt clarity only; recognise the
+     same shapes in any language the user writes in. Bias
+     conservative — when in doubt, skip silently and wait for a
+     clearer signal. A missed reversal costs nothing (user can
+     re-state explicitly); a false reversal silently overwrites a
+     deliberate "no".
 
 2. **Existing match → append a dated bullet.** Default section is
    `## Log` (or whatever section the file already uses for time-ordered
@@ -128,13 +174,84 @@ can copy the same pattern into their own skills.
    frontmatter parser is line-scalar so per-key PATCH is not available.
    Bump `updated` to today on the same write.
 
-3. **No match — DM-confirm before any write.** Reply with one short
-   sentence: *"Create project `<slug>`? (one-line summary:
-   <paraphrase>)"*. Wait for an explicit yes. This mirrors the
-   morning-routine inbox-triage gate (`routine.morning_routine.md`,
-   "High-risk triggers — DM for confirmation before writing") so the
-   two paths can't fork — silently inferring a slug and writing is
-   forbidden regardless of how the project entered the system.
+   **Cross-path cancellation.** If this existing-match write resolves
+   what was previously a "no match" → confirm path (i.e. a confirm row
+   was scheduled and the user has since clarified the project is the
+   same as an existing one), delete the pending confirm rows before
+   completing the write. See §"Reply branches" below.
+
+3. **No match — schedule a confirm DM (do NOT ask inline).**
+   The universal "no topic-pivoting trailing question" rule in
+   `message.received.dm{,_first}.md` Step 3 forbids appending a
+   project-creation ask to a content-rich reply. Instead of inline
+   "Create project `<slug>`? (yes/no)" and waiting on the same DM
+   turn, schedule a `confirm:` sub-flow row for a natural follow-up
+   moment (default: next morning briefing slot, or `<current_time>
+   + 4h` if the DM landed well before quiet hours):
+
+   **a. Pre-flight idempotency check.** Compute the dedup_key
+   `create_project:<slug>` and ensure no row is already pending
+   (Goal 3):
+
+   ```bash
+   curl -s "http://localhost:8321/api/schedule?status=pending,running" \
+     | jq --arg k "create_project:<slug>" \
+         '[.items[] | select(.taskContext.confirm_dedup_key == $k)] | length'
+   ```
+
+   If the count is `≥ 1`, a confirm is already queued — do NOT
+   schedule a duplicate. Log to today.md `## Agent Log` and proceed:
+   ```
+   - HH:MM [confirm] skipped create_project:<slug>: row already pending
+   ```
+
+   **b. Schedule the confirm.** Use the shape documented in
+   `scheduled.dm.md` §"Confirmation follow-up":
+
+   ```bash
+   curl -s -X POST http://localhost:8321/api/schedule \
+     -H 'Content-Type: application/json' \
+     -d @- <<JSON
+   {
+     "time": "<next morning-briefing slot, or current_time + 4h — ISO 8601 with offset>",
+     "taskType": "dm_session",
+     "description": "confirm:create_project:<slug> — track <paraphrase> as a project?",
+     "model": "sonnet",
+     "taskContext": {
+       "scheduledBy": "dm_handler.project_creation_gate",
+       "sub_flow": "confirm",
+       "confirm_id": "<short uuid v4 first 8 chars>",
+       "confirm_dedup_key": "create_project:<slug>",
+       "confirm_hint": "create project \"<slug>\"? (origin: <one-line paraphrase of user's DM>)",
+       "confirm_recent_window_hours": 24,
+       "confirm_attempt": 1,
+       "confirm_max_attempts": 2,
+       "confirm_defer_count": 0,
+       "confirm_max_defers": 3,
+       "confirm_decline_marker": {
+         "path": "agent/journal.md",
+         "section": "declined_intents",
+         "match": "create_project:<slug>"
+       },
+       "confirm_slot": {
+         "path": "projects/<slug>.md"
+       },
+       "importance": "low"
+     }
+   }
+   JSON
+   ```
+
+   The `confirm_slot.path` (just the file path, no section / anchor)
+   makes the fire-time slot-filled probe abort if the project file
+   already exists by the time the confirm fires — covering the case
+   where the user volunteers an affirmative shape between scheduling
+   and fire.
+
+   **c. Do NOT inline-ask.** The DM reply must remain in the user's
+   thread per the universal rule. The confirm sub-flow will surface
+   the question at the next natural moment. Silently inferring a
+   slug and writing without confirmation remains forbidden.
 
 4. **On confirmed creation → PUT the file.** Required + conventional
    frontmatter and an H1:
@@ -150,6 +267,152 @@ can copy the same pattern into their own skills.
    Add `due`, `stakeholders`, `next_milestone`, `tags` only when the
    user supplied them. Do not invent values.
 
+5. **Reply branches — how the user's response to a scheduled confirm
+   is handled.** When the confirm sub-flow fires (`scheduled.dm.md`
+   ## Confirmation follow-up) and the user replies, the reply routes
+   through `message.received.dm.md` as usual; the dispatcher injects
+   `<conversation_history>` so the agent sees both the confirm DM and
+   the user's reply in the same turn. This gate is the writer for all
+   three branches; every branch is REQUIRED.
+
+   - **Affirmative** — user gave a clear positive answer to the
+     confirm question. Examples: *"yes"*, *"go ahead"*,
+     *"track it as X"*, *"sounds good"*, *"please do"*. Match on
+     intent, not surface vocabulary — recognise the same shape in
+     any language the user writes in. Execute the "On confirmed
+     creation → PUT the file" path in Step 4. Then run
+     §"Cross-path cancellation" below (delete any sibling confirm
+     rows with matching `confirm_dedup_key` so a parallel queued
+     row does not re-fire).
+
+   - **Counter-proposal** — user supplied new info ("call it
+     `la-pm` instead", "actually make it the syllabus dossier",
+     "rename it to `la-pm`").
+     Use the user's wording, not your original paraphrase:
+     re-compute the slug from the corrected wording, PUT the file,
+     then cancel pending confirm rows whose `confirm_dedup_key`
+     matches **either** the original or the new slug:
+     - `create_project:<original-slug>` — the chained-fire successor
+       inherits the original key, so this is the primary sweep.
+     - `create_project:<new-slug>` — a separate gate fire from an
+       earlier DM may have queued a confirm with the new slug (e.g.
+       the user previously paraphrased the same project differently
+       and that fire's confirm has not yet aborted). The fire-time
+       `slot-filled` probe would catch this (the project file now
+       exists), but a symmetric sweep here saves a wasted session.
+
+     Run the §"Cross-path cancellation" loop twice — once with each
+     key — or merge the two `select`s in jq.
+
+   - **Decline** — user wrote a clear negative answer to the
+     confirm question.
+
+     Counts as decline: *"no"*, *"don't bother"*, *"not now"*,
+     *"later"*, *"skip it"*, *"forget it"*, *"drop it"*.
+
+     Does NOT count as decline (treat as ambiguous → no DM action
+     this turn, marker NOT written, sweep NOT run; the chain's
+     softened re-check will handle it):
+     - non-answer continuations: *"hmm"*, *"not sure"*, *"I don't
+       know"*
+     - questions back to the agent: *"why are you asking?"*,
+       *"what would that involve?"* — these are clarification
+       requests, not declines
+
+     The examples are English for prompt clarity only; recognise
+     the same shapes in any language the user writes in. On a true
+     decline, do NOT write the project file. Two mandatory writes:
+
+     a. **Write the decline marker** to
+        `agent/journal.md ## Declined Intents`. Three cases — file
+        missing entirely, file present but section missing, file +
+        section both present — are handled in one read-then-branch
+        sequence:
+
+        ```bash
+        # 1. GET. HTTP 404 means the journal file does not yet exist.
+        body=$(curl -sS -w '\n%{http_code}' "http://localhost:8321/api/context/agent/journal")
+        status=$(printf '%s\n' "$body" | tail -n1)
+        content=$(printf '%s\n' "$body" | sed '$d' | jq -r '.content // ""' 2>/dev/null)
+
+        marker_line='- 2026-05-12 [create_project:<slug>] user declined inline (DM)'
+
+        if [ "$status" = "404" ]; then
+          # Case A — file missing. CREATE_ONLY_PUT is enabled for
+          # agent/journal, so PUT creates the file in a single call.
+          # Include both the H1 and the Declined Intents section.
+          curl -s -X PUT "http://localhost:8321/api/context/agent/journal" \
+            -H 'Content-Type: application/json' \
+            -d "$(jq -n --arg m "$marker_line" '{content: "# Agent Journal\n\n## Declined Intents\n\($m)\n"}')"
+        elif printf '%s' "$content" | grep -q '^## Declined Intents'; then
+          # Case B — file + section present. Append a bullet to the
+          # existing section.
+          curl -s -X PATCH "http://localhost:8321/api/context/agent/journal" \
+            -H 'Content-Type: application/json' \
+            -d "$(jq -n --arg m "$marker_line" '{section:"declined_intents",mode:"append",content:$m}')"
+        else
+          # Case C — file present but section missing. append_to_file
+          # adds the section header + bullet to the end of the file.
+          curl -s -X PATCH "http://localhost:8321/api/context/agent/journal" \
+            -H 'Content-Type: application/json' \
+            -d "$(jq -n --arg m "$marker_line" '{mode:"append_to_file",content:"\n## Declined Intents\n\($m)\n"}')"
+        fi
+        ```
+
+        Use today's date (resolve via `<current_time>`) for the
+        marker line.
+
+     b. **Cancellation** — see §"Cross-path cancellation" below.
+        The decline must also delete any pending confirm rows with
+        the matching `confirm_dedup_key`, otherwise the chained-fire
+        successor will re-ask 24h later despite the explicit "no".
+
+   The decline marker is what the next DM-intent detection (Step 1
+   above) consults — without it, the next time the user mentions LA
+   PM master's, this gate would compute the same slug, see no
+   existing project, and schedule another confirm. The marker is
+   how Goal 3 ("never ask the same question twice") survives across
+   sessions.
+
+   **Decline-marker reversal.** When the user later volunteers an
+   unambiguously affirmative shape ("OK now let's start that LA
+   project after all", "actually go ahead and track LA PM") — either
+   inline in a fresh DM (the carve-out in Step 1) or as a reply to a
+   confirm DM — run this recipe instead of skipping:
+
+   1. GET `agent/journal.md`, parse the `## Declined Intents`
+      section, drop the line whose bracketed dedup_key matches
+      `create_project:<slug>`, and PATCH the section with
+      `mode: "replace"` carrying the rebuilt body (the other lines
+      preserved byte-for-byte). If the rebuilt section is empty,
+      replace with the empty string — `mode: "replace"` accepts an
+      empty `content` and leaves the heading in place.
+   2. Proceed with Step 4 (PUT the project file).
+
+   Without the reversal, a previously-declined project would stay
+   dormant forever.
+
+   **Cross-path cancellation (required for affirmative,
+   counter-proposal, and decline branches).** When this gate
+   commits durable state via ANY of the three branches above, sweep
+   pending confirm rows with the same dedup_key so a queued
+   successor does not re-fire:
+
+   ```bash
+   curl -s "http://localhost:8321/api/schedule?status=pending,running" \
+     | jq -r --arg k "create_project:<slug>" \
+         '.items[] | select(.taskContext.confirm_dedup_key == $k) | .id' \
+     | while read -r id; do
+         curl -s -X DELETE "http://localhost:8321/api/schedule/$id" >/dev/null
+       done
+   ```
+
+   Apply this after the affirmative write, after the counter-proposal
+   write (with the ORIGINAL slug, not the corrected one), and after
+   the decline marker write. The cost is one GET plus zero-to-one
+   DELETE per write — bounded by "gate wrote something", which is
+   rare relative to inbound DM volume.
+
 **Slug grammar (convention only — no API-level validation today):**
 - match `^[a-z0-9][a-z0-9-]*[a-z0-9]$` (or a single `[a-z0-9]`)
 - ≤ 64 chars
@@ -235,11 +498,19 @@ curl -s -X PATCH http://localhost:8321/api/context/today \
 
 | Field | Type | Description |
 |---|---|---|
-| `section` | string | snake_case of heading. **Omit for `append_to_file`**. |
-| `mode` | `append` \| `replace` \| `clear` \| `append_to_file` | Default `append` |
-| `content` | string | Ignored for `clear` |
+| `section` | string | snake_case of heading. **Omit for `append_to_file`**; required for every other mode. |
+| `mode` | `append` \| `replace` \| `clear` \| `clear_before` \| `append_to_file` | Default `append` |
+| `content` | string | Ignored for `clear` / `clear_before` |
+| `cutoff` | string | **Required when `mode: "clear_before"`.** Format `YYYY-MM-DD HH:MM:SS` (zero-padded). Removes bullet rows whose `- [YYYY-MM-DD HH:MM:SS]` timestamp is ≤ cutoff. |
+| `maxEntries` | number | Optional for `mode: "append"`. After appending, trim oldest bullet entries from the top of the section body so at most `maxEntries` bullets remain. Non-bullet lines are preserved. |
 
 `append_to_file`: appends to end of file (no `section`). Use for agent/journal.md.
+`clear_before`: rolling-log trim — pass a SQLite-format `cutoff` to drop bullets older than it. Non-bullet lines are preserved.
+
+**Error responses worth knowing:**
+- `400 {error:"section_not_found", section, availableSections:[...]}` — the section name didn't match. The `availableSections` array lists every section heading the file actually has (snake_cased); pick the closest match from that list before retrying. Do NOT retry the same `section` value.
+- `400 {error:"validation_error", message, path}` — content failed the file-specific validator (e.g. today.md day-type line, roadmap.md preparation-timeline row). The `message` field names the offending line and (where applicable) the expected shape.
+- `400 {error:"cutoff_required", message}` — `clear_before` was called without a valid `cutoff`.
 
 ### GET /api/context/list/:dir — List files
 `curl -s http://localhost:8321/api/context/list/projects` → `{ "files": [{ "name", "lastModified" }] }`

package/agent-assets/skills/external-services/SKILL.delegated.claude.md

@@ -16,8 +16,8 @@ Your DM session runs on Claude Code. **Google Calendar** access has been
 delegated to a different backend whose Calendar connector is signed in.
 You describe Calendar intent in natural language; the daemon spawns the
 delegated backend, lets it pick the right MCP tool, and returns a
-schema-validated JSON result. The `mcp__claude_ai_Google_Calendar__*`
-tools are not on the inventory here (Calendar is not delegated to
+schema-validated JSON result. The hosted Google Calendar connector
+tools are not on this session's tool menu (Calendar is not delegated to
 Claude in this session).
 
 The rest of this skill — Obsidian, GitHub, recurring schedules, one-shot

package/agent-assets/skills/external-services/SKILL.delegated.codex.md

@@ -16,9 +16,9 @@ Your DM session runs on Codex CLI. **Google Calendar** access has been
 delegated to a different backend whose Calendar connector is signed
 in. You describe Calendar intent in natural language; the daemon
 spawns the delegated backend, lets it pick the right MCP tool, and
-returns a schema-validated JSON result. The
-`mcp__codex_apps__google_calendar._*` tools are not on the inventory
-for these calls (Calendar is not delegated to Codex here).
+returns a schema-validated JSON result. The in-session Google Calendar
+connector your Codex harness might expose is not on the inventory for
+these calls (Calendar is not delegated to Codex here).
 
 The rest of this skill — Obsidian, GitHub, recurring schedules, one-shot
 scheduling, skills CRUD — works identically to the direct-mode body.

package/agent-assets/skills/external-services/SKILL.delegated.gemini.md

@@ -15,12 +15,12 @@ Base URL: `http://localhost:8321`. All calls via `curl -s` with
 Your DM session runs on Gemini CLI. **Google Calendar** access has been
 delegated to a *different* backend (Claude or Codex) whose Calendar
 connector is signed in. Same-backend setups (DM on Gemini, Calendar
-also delegated to Gemini via the `google-workspace` extension) never
-load this skill — the resolver returns no body and the agent uses
-Gemini's native `mcp_google-workspace_calendar.*` tools directly. This
-skill body is the cross-backend variant only: every Calendar operation
-goes through the daemon proxy because the connector lives on a
-different backend than the one running the DM.
+also delegated to Gemini via the in-session Calendar connector your
+Gemini harness exposes) never load this skill — the resolver returns
+no body and the agent uses its in-session Calendar connector directly.
+This skill body is the cross-backend variant only: every Calendar
+operation goes through the daemon proxy because the connector lives on
+a different backend than the one running the DM.
 
 The rest of this skill — Obsidian, GitHub, recurring schedules, one-shot
 scheduling, skills CRUD — works identically to the direct-mode body.

package/agent-assets/skills/external-services/SKILL.md

@@ -61,9 +61,11 @@ Calendar's mode.
 Read the `<integration_modes>` block injected above. If
 `google_calendar="delegated"` (same-backend), the entire
 `/api/calendar/*` prefix returns `410 {"error": "integration_delegated"}`
-(route-prefix gate). Use the connector tools your session already holds
-natively — `mcp__claude_ai_Google_Calendar__*` (Claude session) or
-`mcp__codex_apps__google_calendar._*` (Codex session).
+(route-prefix gate). Use the in-session Google Calendar connector your
+harness exposes — your tool menu lists every available tool at session
+start. The exact tool namespace depends on which connector your
+harness has loaded (Claude / Codex sessions each surface Calendar under
+their own connector's namespace).
 
 The Calendar section below documents the direct-mode route shapes;
 consult it for tool argument shapes (native MCP tools mirror the route