@lanes-sh/link 0.4.0 → 0.5.0

package/src/providers/assets/store.ts

@@ -0,0 +1,167 @@
+import { createHash } from 'node:crypto';
+import { guessContentType } from '#connectivity/mail';
+import type { BlobStore } from '#connectivity';
+
+/**
+ * How an asset is stored, and the only place that knows.
+ *
+ * **The key is the filename.** `invoice-2026-03.pdf` is stored at
+ * `assets/<connection>/invoice-2026-03.pdf`, and that is the whole of the
+ * layout — no id, no prefix, no sidecar, no index. `BlobStore.list()` already
+ * reports size and mtime, and the content type follows from the extension, so
+ * every fact a listing needs is either the key itself or something the store
+ * already had. Nothing is written twice and nothing can disagree.
+ *
+ * That is memory's design carried over rather than a new one: ADR-014 reversed
+ * an index-plus-body split for exactly this reason, and it applies harder here,
+ * because a sidecar holding an asset's name would be a second name for a file
+ * that already has one. What the owner sees under
+ * `~/.lanes-link/data/<profile>/assets/main/` is a directory of their files,
+ * with their names, openable by anything.
+ *
+ * The cost is that an asset carries no description, and that is deliberate:
+ * "the March invoice is in assets as invoice-2026-03.pdf" is a memory entry.
+ * Prose in a store with no way to search it would be worse than either.
+ */
+
+/**
+ * What may be a name, and why it is narrower than a filename.
+ *
+ * No path separator, so the namespace stays flat: `scopeBlobStore` would happily
+ * accept `a/b` and create a directory, and a listing that nests is one where
+ * `list()`'s single prefix scan stops describing what is there. No leading dot,
+ * because a dotfile is invisible in exactly the directory the owner is meant to
+ * be able to read. No control characters, which are not names.
+ *
+ * Spaces and unicode are allowed. Refusing them would reject the names files
+ * actually have, and the name is percent-encoded at the one boundary that needs
+ * it — a resource URI — rather than being restricted to survive it.
+ */
+const MAX_NAME = 200;
+const CONTROL = /[\x00-\x1F\x7F]/;
+
+/**
+ * Suffixes a blob adapter treats as its own bookkeeping.
+ *
+ * The filesystem adapter writes `<key>.meta` beside a blob whose content type its
+ * extension cannot express, `<key>.tmp` while a write is in flight, and skips
+ * both in `list()`. So an asset called `report.meta` would be stored, would
+ * never appear in a listing, and would read back only if you already knew the
+ * name — silent, and shaped like data loss. Memory never met this because every
+ * key it writes ends `.md`; an asset's key is whatever the file was called.
+ */
+const ADAPTER_SUFFIXES = ['.meta', '.tmp'];
+
+export function assertAssetName(name: string): void {
+  const why = nameProblem(name);
+  if (why) throw new Error(`Asset name ${JSON.stringify(name)} ${why}`);
+}
+
+function nameProblem(name: string): string | null {
+  if (name.length === 0) return 'must not be empty.';
+  if (name.length > MAX_NAME) return `must be at most ${MAX_NAME} characters.`;
+  if (name.includes('/') || name.includes('\\')) {
+    return 'must not contain a path separator — assets are a flat set of files, not a tree.';
+  }
+  if (name.startsWith('.')) return 'must not start with a dot.';
+  if (CONTROL.test(name)) return 'must not contain control characters.';
+
+  const reserved = ADAPTER_SUFFIXES.find((suffix) => name.endsWith(suffix));
+  if (reserved) {
+    return `must not end in "${reserved}" — a blob store keeps its own bookkeeping under that suffix and would hide the file.`;
+  }
+
+  return null;
+}
+
+/** Whether a listed key is an asset. Anything unnameable is skipped, not repaired. */
+export function nameFromKey(key: string): string | null {
+  return nameProblem(key) === null ? key : null;
+}
+
+export interface Asset {
+  readonly name: string;
+  readonly bytes: number;
+  readonly contentType: string;
+  readonly modifiedAt: string;
+}
+
+/**
+ * Every asset, newest first.
+ *
+ * One `list()` and no reads at all, which is the payoff for the key being the
+ * filename: memory has to open every entry to list it, and this does not.
+ */
+export async function allAssets(storage: BlobStore): Promise<Asset[]> {
+  return (await storage.list())
+    .flatMap((blob) => {
+      const name = nameFromKey(blob.key);
+      return name === null
+        ? []
+        : [
+            {
+              name,
+              bytes: blob.size,
+              contentType: blob.contentType ?? guessContentType(name),
+              modifiedAt: blob.modifiedAt.toISOString(),
+            },
+          ];
+    })
+    .sort((a, b) => b.modifiedAt.localeCompare(a.modifiedAt) || a.name.localeCompare(b.name));
+}
+
+export async function findAsset(storage: BlobStore, name: string): Promise<Asset | null> {
+  return (await allAssets(storage)).find((asset) => asset.name === name) ?? null;
+}
+
+export function digestOf(bytes: Uint8Array): string {
+  return createHash('sha256').update(bytes).digest('hex');
+}
+
+/**
+ * Whether these bytes can be handed to a model as text.
+ *
+ * Two questions, and both have to pass. The declared type has to be a text one
+ * — `text/*`, or a structured type that is text by construction — and the bytes
+ * have to contain no NUL, because a mislabelled binary is common and a content
+ * type is a claim rather than an observation. Failing either means the asset is
+ * described instead of returned, which is the honest answer: `ResourceContents`
+ * carries text and nothing else, and base64 into a conversation is the cost this
+ * whole mechanism exists to avoid.
+ */
+export function isTextual(contentType: string, bytes: Uint8Array): boolean {
+  const type = contentType.split(';')[0]!.trim().toLowerCase();
+
+  const declared =
+    type.startsWith('text/') ||
+    type.endsWith('+json') ||
+    type.endsWith('+xml') ||
+    ['application/json', 'application/xml', 'application/yaml', 'application/x-yaml'].includes(
+      type,
+    );
+
+  return declared && !bytes.includes(0);
+}
+
+/** `invoice.pdf  application/pdf  184 KB  2026-08-27` */
+export function describeAsset(asset: Asset): string {
+  return `${asset.name}  ${asset.contentType}  ${humanBytes(asset.bytes)}  ${asset.modifiedAt.slice(0, 10)}`;
+}
+
+export function humanBytes(bytes: number): string {
+  if (bytes < 1024) return `${bytes} B`;
+  if (bytes < 1024 * 1024) return `${Math.round(bytes / 1024)} KB`;
+  return `${(bytes / (1024 * 1024)).toFixed(1)} MB`;
+}
+
+/** The pieces `lanes link assets` needs to reach the same bytes the provider does. */
+export const assetStorage = {
+  all: allAssets,
+  find: findAsset,
+  describe: describeAsset,
+  humanBytes,
+  digest: digestOf,
+  assertName: assertAssetName,
+  nameFromKey,
+  isTextual,
+};

package/src/providers/bunq/hints.ts

@@ -29,7 +29,9 @@ export const BUNQ_HINTS: Record<string, string> = {
   UPDATE_DraftPayment_for_User_MonetaryAccount:
     'Changes a draft that is still pending — status ACCEPTED sends it, REJECTED cancels it. ' +
     'previous_updated_timestamp is required and comes from reading the draft first; it is what stops two ' +
-    'callers acting on the same draft.',
+    'callers acting on the same draft. Those two fields are the entire call — bunq refuses entries and ' +
+    'number_of_required_accepts here as superfluous — so changing what a draft pays means rejecting it and ' +
+    'creating another.',
 
   CREATE_PaymentBatch_for_User_MonetaryAccount:
     'Up to 350 payments in one call. Executes immediately, like a direct payment, and is all-or-nothing: bunq rejects ' +

package/src/providers/bunq/redact.ts

@@ -51,14 +51,25 @@ export const BUNQ_REDACT: Record<string, string[]> = {
     'status',
     'schedule',
   ],
+  // Five, not seven: `entries` and `number_of_required_accepts` are no longer
+  // arguments at all. This is the one write here whose event cannot name an
+  // amount or a counterparty, because the call does not carry them — it says
+  // which draft was accepted and against which version of it, and that is
+  // everything there is to keep.
+  //
+  // Not everything a reader wants, though, and worth being honest that the gap
+  // is real rather than closed. The entries are on the event that *created* the
+  // draft, and nothing joins the two: an `AuditEvent` records arguments only,
+  // and bunq returns the draft id in the create's response. Reconstructing what
+  // an ACCEPTED draft paid means matching by hand. `context.audit.annotate`,
+  // which `gmail.send_message` uses to record resolved facts, is the shape of a
+  // fix and is a change to dispatch rather than to this list.
   UPDATE_DraftPayment_for_User_MonetaryAccount: [
     'userID',
     'monetary-accountID',
     'itemId',
     'status',
-    'entries',
     'previous_updated_timestamp',
-    'number_of_required_accepts',
   ],
   CREATE_PaymentBatch_for_User_MonetaryAccount: ['userID', 'monetary-accountID', 'payments'],
 };

package/src/providers/bunq/specs/bunq.v1.json

@@ -144,7 +144,26 @@
           "content": {
             "application/json": {
               "schema": {
-                "$ref": "#/components/schemas/DraftPayment"
+                "type": "object",
+                "description": "The whole of what this call takes. bunq refuses any other field here as superfluous — the rest of the schema it shares belongs to the call that creates one.",
+                "properties": {
+                  "status": {
+                    "type": "string",
+                    "description": "The status of the DraftPayment.",
+                    "readOnly": false,
+                    "writeOnly": false
+                  },
+                  "previous_updated_timestamp": {
+                    "type": "string",
+                    "description": "The last updated_timestamp that you received for this DraftPayment. This needs to be provided to prevent race conditions.",
+                    "readOnly": false,
+                    "writeOnly": true
+                  }
+                },
+                "required": [
+                  "status",
+                  "previous_updated_timestamp"
+                ]
               }
             }
           }

package/src/providers/bunq/specs/vendor.ts

@@ -22,6 +22,7 @@ import { mkdir, writeFile } from 'node:fs/promises';
 import { join } from 'node:path';
 import { OpenAPIToolGenerator, type McpOpenAPITool } from 'mcp-from-openapi';
 import { cutCycles, referenced, type Spec } from '../../shared/openapi.ts';
+import { projectRequestBody } from '../../shared/vendor-operations.ts';
 
 const SOURCE = 'https://raw.githubusercontent.com/bunq/doc/master/swagger.json';
 const OUT = 'bunq.v1.json';
@@ -187,6 +188,34 @@ function dropReadOnly(node: unknown): number {
   return dropped;
 }
 
+/**
+ * The operations bunq describes with the schema of a *different* operation.
+ *
+ * `PUT .../draft-payment/{itemId}` points at `DraftPayment`, the same schema as
+ * the `POST` that creates one, which requires `entries` and
+ * `number_of_required_accepts`. For a create those two *are* the payment. For an
+ * update bunq refuses both as superfluous — its own generated SDK sends only
+ * `status`, `previous_updated_timestamp` and `schedule` here — so the tool asked
+ * for exactly what the bank rejects and every accept failed. Worse than the
+ * error: made to send `entries` for a draft that has them, a model reaches for
+ * the array echoed back or for `[]`, and both ask bunq to rewrite what the draft
+ * pays on the way to approving it. A hint cannot fix a required argument, which
+ * is the difference between this and the `payments`-is-really-an-array note
+ * above: nothing stops an agent sending an array, and nothing lets it omit a
+ * required field. `required` is asserted here rather than projected because
+ * bunq's own is the one written for the create.
+ *
+ * `schedule` is deliberately not projected: it carries `recurrence_unit` and
+ * `recurrence_size`, so approving a one-off draft would be a place to acquire a
+ * standing order — the risk `OPERATIONS` gives for leaving the scheduling
+ * *endpoints* out. Not the whole of that risk, though: `CREATE_DraftPayment`
+ * still offers the same field, because it comes with bunq's create schema.
+ * Closing that changes what the provider can do rather than whether a call
+ * works, and is not done here.
+ */
+const UPDATE_BODIES: Record<string, readonly string[]> = {
+  UPDATE_DraftPayment_for_User_MonetaryAccount: ['status', 'previous_updated_timestamp'],
+};
 
 async function vendor(): Promise<void> {
   const response = await fetch(SOURCE);
@@ -246,6 +275,34 @@ async function vendor(): Promise<void> {
   }
 
   const schemas = spec.components?.schemas ?? {};
+
+  const projected = new Set<string>();
+  for (const item of Object.values(paths)) {
+    for (const [method, operation] of Object.entries(item)) {
+      if (!METHODS.includes(method)) continue;
+      const fields = operation.operationId ? UPDATE_BODIES[operation.operationId] : undefined;
+      if (!fields || !operation.operationId) continue;
+
+      projectRequestBody(
+        operation as unknown as Record<string, unknown>,
+        operation.operationId,
+        schemas,
+        fields,
+        'The whole of what this call takes. bunq refuses any other field here as superfluous — the rest ' +
+          'of the schema it shares belongs to the call that creates one.',
+      );
+      projected.add(operation.operationId);
+    }
+  }
+
+  // The same refusal as `missing` above, and for a sharper reason: an entry that
+  // matches nothing narrows nothing, and what is left is the wide body this
+  // exists to remove — printed as a success.
+  const unprojected = Object.keys(UPDATE_BODIES).filter((id) => !projected.has(id));
+  if (unprojected.length > 0) {
+    throw new Error(`UPDATE_BODIES names operations the spec does not have — ${unprojected.join(', ')}`);
+  }
+
   const keep = referenced(paths, schemas);
   const trimmedSchemas = Object.fromEntries(
     Object.entries(schemas).filter(([name]) => keep.has(name)),
@@ -295,7 +352,8 @@ async function vendor(): Promise<void> {
     `  bunq   ${String(Object.keys(paths).length).padStart(2)} paths, ` +
       `${seen.size} operations, ${Object.keys(trimmedSchemas).length} schemas, ` +
       `${cuts} cycle${cuts === 1 ? '' : 's'} cut, ${headers} protocol params dropped, ` +
-      `${readOnly} read-only fields dropped, ${size}KB`,
+      `${readOnly} read-only fields dropped, ${projected.size} update ` +
+      `bod${projected.size === 1 ? 'y' : 'ies'} projected, ${size}KB`,
   );
 
   await report(trimmed);

package/src/providers/google/index.ts

@@ -7,5 +7,5 @@ export { driveMcp } from './drive-mcp/index.ts';
 export { gmail, GMAIL_SCOPES } from './gmail/index.ts';
 export { gmailImap } from './gmail-imap/index.ts';
 export { gmailMcp } from './gmail-mcp/index.ts';
+export { googleTasks } from './tasks/index.ts';
 export { sheets } from './sheets/index.ts';
-export { tasks } from './tasks/index.ts';

package/src/providers/google/tasks/index.ts

@@ -17,7 +17,7 @@ import { TASKS_REDACT } from './redact.ts';
  * What bounds it is what bounds the others. The token can delete a whole list;
  * the tool surface cannot, because `tasklists.delete` is not vendored — Tasks
  * has no trash, so destroying a list destroys every task in it. `lanes link
- * policy deny tasks.*` narrows it further.
+ * policy deny google_tasks.*` narrows it further.
  *
  * No `identity` block, and that is a decision rather than an omission. Nothing
  * reachable under `auth/tasks` returns an address: `tasklists.list` answers
@@ -32,8 +32,8 @@ import { TASKS_REDACT } from './redact.ts';
  */
 const TASKS_SCOPES = ['https://www.googleapis.com/auth/tasks'];
 
-export const tasks = defineProvider({
-  id: 'tasks',
+export const googleTasks = defineProvider({
+  id: 'google_tasks',
   name: 'Google Tasks',
   description:
     'Read and write task lists and tasks — create, edit, complete, reorder, and delete — via the Tasks REST API.',

package/src/providers/google/tasks/redact.ts

@@ -6,18 +6,28 @@
  * them. `due` and `status` are kept, because "marked the thing due Friday done"
  * is the shape of the change and neither argument says what the thing was.
  *
+ * **The keys carry Google's whole operationId**, `tasks.tasks.patch` rather than
+ * `tasks.patch`. `shortenName` strips the provider id from a discovered tool
+ * name, and this provider's id is `google_tasks` while the API namespaces its
+ * operations under `tasks` — so nothing is stripped and the capability is
+ * `google_tasks.tasks.patch`. `contacts` has read this way since it shipped: its
+ * id is `contacts` and the People API says `people.people.searchContacts`. The
+ * keys were the short form while the id was `tasks` and the prefix happened to
+ * match; renaming the provider for the built-in task list (ADR-051) ended the
+ * coincidence.
+ *
  * Two argument names are not what they look like, and a wrong key here fails
  * silently — the lookup misses, every value is withheld, and it reads exactly
  * like working redaction. The generator disambiguates a collision between a
  * path or query parameter and a body field by prefixing the location, so
- * `tasks.insert` takes `queryParent` (the query one) beside the body's
- * `parent`. `tasks.move` has no such collision and takes a plain `parent`.
+ * `tasks.tasks.insert` takes `queryParent` (the query one) beside the body's
+ * `parent`. `tasks.tasks.move` has no such collision and takes a plain `parent`.
  */
 export const TASKS_REDACT: Record<string, string[]> = {
-  'tasklists.list': ['maxResults'],
-  'tasklists.insert': [],
-  'tasklists.patch': ['tasklist'],
-  'tasks.list': [
+  'tasks.tasklists.list': ['maxResults'],
+  'tasks.tasklists.insert': [],
+  'tasks.tasklists.patch': ['tasklist'],
+  'tasks.tasks.list': [
     'tasklist',
     'showCompleted',
     'showDeleted',
@@ -26,9 +36,9 @@ export const TASKS_REDACT: Record<string, string[]> = {
     'dueMax',
     'maxResults',
   ],
-  'tasks.get': ['tasklist', 'task'],
-  'tasks.insert': ['tasklist', 'queryParent', 'previous', 'due', 'status'],
-  'tasks.patch': ['tasklist', 'task', 'due', 'status'],
-  'tasks.delete': ['tasklist', 'task'],
-  'tasks.move': ['tasklist', 'task', 'parent', 'previous'],
+  'tasks.tasks.get': ['tasklist', 'task'],
+  'tasks.tasks.insert': ['tasklist', 'queryParent', 'previous', 'due', 'status'],
+  'tasks.tasks.patch': ['tasklist', 'task', 'due', 'status'],
+  'tasks.tasks.delete': ['tasklist', 'task'],
+  'tasks.tasks.move': ['tasklist', 'task', 'parent', 'previous'],
 };

package/src/providers/index.ts

@@ -11,7 +11,7 @@ import { gmail } from './google/gmail/index.ts';
 import { gmailImap } from './google/gmail-imap/index.ts';
 import { gmailMcp } from './google/gmail-mcp/index.ts';
 import { sheets } from './google/sheets/index.ts';
-import { tasks } from './google/tasks/index.ts';
+import { googleTasks } from './google/tasks/index.ts';
 import { icloudCalendar } from './icloud/calendar/index.ts';
 import { icloudContacts } from './icloud/contacts/index.ts';
 import { icloudDrive } from './icloud/drive/index.ts';
@@ -63,7 +63,7 @@ export const PROVIDERS: readonly (ProviderManifest | ProviderDefinition)[] = [
   sheets,
   docs,
   calendar,
-  tasks,
+  googleTasks,
   contacts,
   gmailImap,
   gmailMcp,
@@ -97,8 +97,8 @@ export {
   gmail,
   gmailImap,
   gmailMcp,
+  googleTasks,
   sheets,
-  tasks,
 } from './google/index.ts';
 export { icloudCalendar, icloudContacts, icloudDrive, icloudMail } from './icloud/index.ts';
 export { bunq } from './bunq/index.ts';

package/src/providers/owner.ts

@@ -1,38 +1,58 @@
 /**
- * The owner layer — memory, skills, vault, setup, identity.
+ * The owner layer — memory, tasks, assets, skills, vault, setup, identity.
  *
- * Three providers that hold no third-party account: no OAuth, no vendor API, no
+ * Seven providers that hold no third-party account: no OAuth, no vendor API, no
  * rate limit anyone else imposes. They are ordinary `defineLocalProvider`
- * registrations, configured by the same `lanes link connect <provider>`, scoped by the
- * same profiles, and gated by the same policy evaluation as everything else —
- * which was the claim `docs/detailed/init.md` made and called the real test of the
- * architecture.
+ * registrations, scoped by the same profiles and gated by the same policy
+ * evaluation as everything else — which was the claim `docs/detailed/init.md`
+ * made and called the real test of the architecture. Since ADR-050 they are also
+ * the ones a fresh profile arrives with already granted, because what they reach
+ * is the owner's own material and there is no account behind them to protect.
  *
- * They live in `./memory/`, `./skills/` and `./vault/`, beside `google/` and
- * `icloud/`, because that claim is only true if they are providers in the
- * layout as well as in the prose. This file is the one thing they share: a
- * barrel, because each is *constructed* with a store rather than declared as
- * data, so `#profile`'s registry builder needs all three together.
+ * Each lives in its own folder beside `google/` and `icloud/`, because that
+ * claim is only true if they are providers in the layout as well as in the
+ * prose. This file is the one thing they share: a barrel, because several are
+ * *constructed* with a store rather than declared as data, so the registry
+ * builder needs them together.
  *
- * `setup` joined them later and is the same shape: it holds no account either,
- * and it describes the other three rather than reaching anything. It is
- * read-only by construction — see ADR-019 for why describing setup is not one
+ * `memory`, `tasks` and `assets` are the three that hold what the owner keeps,
+ * and they divide by what a thing *is* rather than by size: memory is what is
+ * true, tasks is what is to be done, assets is a file. That split is the whole
+ * of ADR-051, and the routing rule an agent needs is stated in
+ * `#server/mcp`'s instructions and in the bundled skill.
+ *
+ * `setup` is the same shape and holds no account either, but it describes the
+ * others rather than holding anything of the owner's. It is read-only by
+ * construction — see ADR-019 for why describing setup is not one
  * of ADR-007's control-plane exclusions.
  *
- * `identity` is the fifth and holds no account either. It says who the owner is
+ * `identity` holds no account either. It says who the owner is
  * — the names and addresses to write as them — and is read-only for the reason
  * `setup` is: what it reports is configuration, and configuration is changed in
  * the CLI. It is a provider of its own rather than a section of `setup` so that
  * naming the owner and describing what is connected are two policy decisions
  * instead of one.
  *
- * The ids `memory`, `skills`, `vault`, `setup`, and `identity` are reserved (`RESERVED_PROVIDER_IDS`)
- * and still refused by default — the registry has to be built with
- * `allowReserved` to hold them, so a third-party provider cannot claim a
- * namespace whose policy rules would then mean something else.
+ * All seven ids are reserved (`RESERVED_PROVIDER_IDS`) and still refused by
+ * default — the registry has to be built with `allowReserved` to hold them, so a
+ * third-party provider cannot claim a namespace whose policy rules would then
+ * mean something else. `tasks` cost something to reserve: Google Tasks held that
+ * id and was renamed `google_tasks`, because the plain noun belongs to the
+ * owner's own list and a manifest already registered under it would have thrown
+ * on the second registration rather than shadowing anything.
  */
 
 export { memoryProvider, memoryStorage, assertEntryId, type MemoryEntry } from './memory/provider.ts';
+export { tasksProvider } from './tasks/provider.ts';
+export {
+  ACTIVE_STATUSES,
+  TASK_STATUSES,
+  taskStorage,
+  type Task,
+  type TaskStatus,
+} from './tasks/store.ts';
+export { assetsProvider } from './assets/provider.ts';
+export { assetStorage, type Asset } from './assets/store.ts';
 export { createSkillsProvider, type SkillsProviderOptions } from './skills/provider.ts';
 export { createVaultProvider, type VaultProviderOptions } from './vault/provider.ts';
 export { createSetupProvider, type SetupProviderOptions } from './setup/provider.ts';

package/src/providers/setup/plan.ts

@@ -1,5 +1,5 @@
 import type { ProviderManifest } from '#connectivity';
-import { hasOwnClientPath, setupRequirements, type SetupRequirement } from '#connectivity';
+import { hasOwnClientPath, RESERVED_PROVIDER_IDS, setupRequirements, type SetupRequirement } from '#connectivity';
 
 /**
  * What connecting a provider involves, assembled from its manifest.
@@ -19,6 +19,21 @@ export interface ProviderPlan {
   readonly id: string;
   readonly name: string;
   readonly description: string;
+  /**
+   * This provider is part of what a profile *is*, not an account it holds.
+   *
+   * The owner layer — `memory`, `skills`, `vault`, `setup`, `identity` — keyed off
+   * `RESERVED_PROVIDER_IDS`, which is the same list the registry uses to stop a
+   * third-party manifest claiming one of those ids.
+   *
+   * Reported because it is the fact a surface needs and cannot derive.
+   * `multiAccount` is the nearest thing and it is not it: that is a credential
+   * test, and `icloud_drive` is `auth: none` without being owner-layer at all. A
+   * client wanting to group these, or to withhold a disconnect that would leave a
+   * dangling policy grant, was left hardcoding the list — which then goes stale
+   * the next time one is added here. This travels with the release instead.
+   */
+  readonly reserved: boolean;
   /** Connection keys of this provider already configured, e.g. `gmail.main`. */
   readonly connected: readonly string[];
   /**
@@ -122,6 +137,7 @@ export function planFor(
     id: manifest.id,
     name: manifest.name,
     description: manifest.description,
+    reserved: RESERVED_PROVIDER_IDS.includes(manifest.id),
     connected,
     multiAccount: manifest.auth.kind !== 'none',
     browser: manifest.auth.kind === 'oauth',

package/src/providers/shared/vendor-operations.ts

@@ -96,3 +96,84 @@ export function narrowRequestBody(
   body.content = Object.fromEntries(kept.map((type) => [type, body.content![type]]));
   return before.length - kept.length;
 }
+
+/**
+ * Replace a request body with a projection of the schema it points at.
+ *
+ * The third surgery on this axis, and the first about the body being *wrong*
+ * rather than too wide. A document that describes two operations with one schema
+ * describes at least one of them wrongly, and `required` is where it bites: the
+ * generated tool asks for arguments the vendor refuses on the call they are
+ * attached to, so there is no correct call to make. It fails at the vendor, on
+ * every attempt, and nothing before the request can see it.
+ *
+ * Projecting rather than hand-writing is what keeps this tied to the document.
+ * The named fields are copied out of the vendor's own schema with their types
+ * and descriptions, so the tool still says what the vendor says. Everything this
+ * cannot verify it refuses instead: a field that is gone, a field the document
+ * marks read-only, a body offering a content type this does not rewrite, a
+ * `$ref` that does not point into `components.schemas`. A vendor refresh should
+ * fail loudly here rather than quietly restore the body it was called to fix.
+ *
+ * `required` is the one thing NOT projected — it is the caller's assertion, and
+ * necessarily so, since the whole disease is a `required` written for the other
+ * operation. Say why in the caller.
+ *
+ * `note` becomes the body schema's description. It lands in the committed
+ * document for whoever reads it there; it does **not** reach the agent, because
+ * the generator flattens body properties to the top level and drops the body
+ * schema's own description. The sentence an agent needs goes in `hints`.
+ *
+ * Apply before reachability, so a schema the projection no longer reaches leaves
+ * the document rather than lingering unused.
+ */
+export function projectRequestBody(
+  operation: Record<string, unknown>,
+  operationId: string,
+  schemas: Record<string, unknown>,
+  fields: readonly string[],
+  note: string,
+): void {
+  const content = (operation['requestBody'] as { content?: Record<string, { schema?: { $ref?: string } }> })
+    ?.content;
+  const types = Object.keys(content ?? {});
+
+  const other = types.filter((type) => type !== 'application/json');
+  if (!content || types.length === 0 || other.length > 0) {
+    // A body left pointing at the wide schema on a second content type is the
+    // bug still present on whichever branch the generator happens to prefer.
+    throw new Error(
+      `${operationId}: expected a lone application/json request body to project, found ${types.join(', ') || 'none'}`,
+    );
+  }
+
+  const json = content['application/json'];
+  const reference = json?.schema?.$ref;
+  if (!json || typeof reference !== 'string' || !reference.startsWith('#/components/schemas/')) {
+    throw new Error(`${operationId}: request body is ${reference ?? 'not a $ref'}, not a schema reference`);
+  }
+
+  const name = reference.slice('#/components/schemas/'.length);
+  const source = (schemas[name] as { properties?: Record<string, unknown> } | undefined)?.properties ?? {};
+
+  const properties: Record<string, unknown> = {};
+  for (const field of fields) {
+    const property = source[field] as { readOnly?: boolean } | undefined;
+    if (!property) throw new Error(`${operationId}: ${name} no longer describes "${field}"`);
+    if (property.readOnly === true) {
+      // Projected fields are inlined into the path, where the read-only strip
+      // does not reach — so a field the vendor computes would survive here and
+      // be demanded as an argument it ignores.
+      throw new Error(`${operationId}: ${name}.${field} is read-only and cannot be a request field`);
+    }
+    properties[field] = property;
+  }
+
+  json.schema = {
+    type: 'object',
+    description: note,
+    properties,
+    required: [...fields],
+  } as never;
+}
+