@lanes-sh/link 0.7.2 → 0.9.0

package/src/profile/layout.ts

@@ -1,123 +1,196 @@
 /**
- * Where a profile's data lives, in one place.
+ * Where a workspace's files live, in one place.
  *
  * ```
  * ~/.lanes-link/
- * ├── lanes-link.yaml           which profiles exist, which is default
- * ├── profiles/<name>.yaml      each profile's declared config
- * └── data/
- *     └── <profile>/            everything one profile owns
- *         ├── state.kv/         state, connections, cursors
- *         ├── audit.log/        one object per event
- *         ├── credentials.enc   system credentials, and its .key
- *         ├── vault.enc         the owner's items, its own key
- *         ├── skills.d/         procedures, one <name>/SKILL.md each
- *         ├── providers.d/      the operator's own provider manifests
+ * ├── workspaces.yaml           the workspaces this machine knows, and the default
+ * ├── connections.yaml          every account authorised in this workspace
+ * ├── credentials.enc           system credentials, and its .key
+ * ├── providers.d/              the operator's own provider manifests
+ * ├── audit.log/                one object per event, one chain
+ * ├── state.kv/                 connections, discovery, the endpoint's own OAuth server
+ * └── profiles/
+ *     └── <profile>/            everything one profile is
+ *         ├── profile.yaml      what it selects, and who may use it
+ *         ├── state.kv/         cursors, and each provider's own keys
+ *         ├── vault.d/<id>.enc  one sealed document per vault connection
+ *         ├── skills.d/<id>/    procedures, one <name>/SKILL.md each
  *         └── <provider>/<connection>/…   whatever that provider stores
  * ```
  *
- * **One profile, one directory.** Before this, `data/` held
- * `personal.db`, `personal.credentials.enc`, `personal.credentials.enc.key`,
- * `work.db`, and a `personal/` directory, all in one flat listing — three
- * profiles' worth of state interleaved, and no single thing to copy, back up, or
- * delete. Now `rm -r data/work` is exactly "remove the work profile's data" and
- * nothing else.
+ * **A profile is one directory, and it owns its bytes.** Both halves reverse
+ * something recent. ADR-059 put the owner layer's bytes beside the *connection*,
+ * so a profile owned nothing and two profiles granting `memory.lan1` read one
+ * note; ADR-066 makes the profile the container again, so they read two. And the
+ * declaration used to sit at `profiles/<name>.yaml` while the data sat under
+ * `data/<name>/` — the same structure in two places, for no reason anybody could
+ * state (ADR-067).
  *
- * **The blob root is the profile directory itself.** It used to be a `files/`
- * subdirectory, which bought nothing and cost a level: a memory entry landed at
- * `data/personal/files/memory/memory/entry/<id>.md`. The provider name and the
- * connection name are the isolation boundary (`scopeBlobStore` namespaces
- * `<provider>/<connection>`) and they are enough on their own, so an entry is
- * now `data/personal/memory/main/<id>.md`. There is no collision risk with the
- * files beside it: a provider id is `[a-z][a-z0-9_]*` and every reserved name
- * here contains a dot.
+ * **There is no `data/` any more.** It meant "what a deployed revision writes,
+ * as against the config it reads", which was worth a directory. `profile.yaml`
+ * lives beside the bytes now, so that line has to be drawn inside it regardless
+ * — and a directory holding everything names nothing. The IAM grant says which
+ * prefixes are writable instead of saying which one is not.
  *
- * **Skills and provider manifests are the profile's too**, which reverses where
- * both used to sit. They were at the workspace root, shared by every profile, on
- * the reasoning that a procedure is not private to a profile the way its
- * knowledge is. That was wrong twice over. A skill is instructions an agent will
- * be handed, and ADR-014 §1 already treats authoring one as a grant worth
- * governing — an odd thing to say about a document every profile reads anyway.
- * And a procedure written for work names work's accounts, its people, and its
- * conventions, so it is exactly as private as the knowledge it operates on.
- * ADR-030 has the argument; ADR-009's "profiles share nothing" is what it
- * restores.
+ * **The dot is load-bearing one level down, not here.** The root is not a
+ * provider blob root; a *profile's* directory is. A provider is namespaced
+ * `<provider>/<connection>` under it and a provider id is `[a-z][a-z0-9_]*`, so
+ * a name carrying a dot is one no provider can be scoped into. That is not
+ * hypothetical for three of the four names there — `skills`, `vault` and `state`
+ * would each otherwise be handed a store rooted inside the thing it is meant to
+ * be walled off from, which is a hole in ADR-007's wall rather than an untidy
+ * filename. `profile.yaml` carries one for the same reason.
  *
- * The `.d` suffix is the dot rule above rather than decoration. A plain
- * `data/<profile>/skills/` is precisely the namespace the skills provider's own
- * blobs scope into, so the one name that could not be used is the obvious one.
+ * `vault.d/<id>.enc` rather than `vault/<id>.enc` on the same grounds: the
+ * sealed document is not a blob the vault provider serves, and a shared `vault/`
+ * prefix would put the ciphertext inside the namespace the provider is given.
  *
- * These are **defaults**. A profile that declares its own paths keeps them.
+ * `audit.log/` and `state.kv/` stay at the workspace. One endpoint serves every
+ * profile and every event already records the profile it acted in, so one chain
+ * is both sufficient and better evidence than several; and a connection's
+ * reconcile status is a fact about an account, which a `connect` in one profile
+ * must not have to repeat in the next. What follows the profile is what a
+ * profile's use of an account produces — cursors, and the provider's own keys.
  *
- * There is no migration from the layout this replaced, deliberately: a
- * workspace is profiles, credentials, and whatever the owner has stored, and
- * re-creating one is `lanes link profile add` plus `lanes link connect` per account. Machinery
- * to move an old one would be more code than the thing it moves, and it would
- * have to keep working forever to be worth having. Skills and manifests left at
- * the old workspace-root paths are the same case: they stop loading, and moving
- * them is one `mv` per profile that should see them.
+ * These are **defaults**. A workspace that declares its own paths keeps them.
  */
 
-/** The directory under the workspace root that holds every profile's data. */
-export const DATA_DIR = 'data';
+/** The directory holding one subdirectory per profile. */
+export const PROFILES_DIR = 'profiles';
 
 /**
- * Everything one profile owns, relative to the workspace root.
+ * What a profile's declaration is called inside its own directory.
  *
- * No leading `./`. It used to carry one, which `path.resolve` discards and an
- * object key does not: a bucket read `./data/personal/state.kv/x` as a
- * directory literally named `.`, so every deployed key landed one level away
- * from where the config said it did. The visible cost was that the conditioned
- * IAM binding `deployments/gcp/provision.ts` writes — which grants writes under
- * `objects/data/` — matched nothing, and the first revision 403'd on its boot
- * reconcile. A relative path is relative without being spelled that way.
+ * Named here rather than spelled at the two call sites that need it — the path
+ * builder below and `listProfiles`, which matches on it to tell a profile
+ * directory from anything else under `profiles/`. Two spellings of one filename
+ * is how a listing and a loader come to disagree about what exists.
  */
-export function profileDir(profile: string): string {
-  return `${DATA_DIR}/${profile}`;
-}
+export const PROFILE_FILE = 'profile.yaml';
 
+/**
+ * No leading `./` on any of these.
+ *
+ * It used to carry one, which `path.resolve` discards and an object key does
+ * not: a bucket read `./state.kv/x` as a directory literally named `.`, so
+ * every deployed key landed one level away from where the config said it did.
+ * The visible cost was that the conditioned IAM binding
+ * `deployments/gcp/provision.ts` writes matched nothing, and the first revision
+ * 403'd on its boot reconcile. A relative path is relative without being
+ * spelled that way.
+ */
 export const layout = {
   /**
-   * Connections, provider state, and cursors: one object per key.
+   * System credentials — OAuth refresh tokens, the CI token. Never reachable
+   * from MCP.
+   *
+   * One store for the workspace, where there used to be one per profile. That
+   * is what makes a `credential_ref` unique by construction and retires
+   * `collidingRefs`, the deploy preflight that existed because two profiles
+   * deployed into one project shared this namespace and the collision was
+   * "silent until one profile is reading the other's account" (ADR-043,
+   * ADR-057).
+   */
+  credentials: (): string => 'credentials.enc',
+  /**
+   * The provider manifests this workspace declares.
+   *
+   * Workspace-level, where ADR-030 put them in the profile. A manifest names a
+   * host, an OpenAPI document, and the credential refs that reach them — which
+   * is to say it *defines a connection*, and connections do not live in a
+   * profile any more (ADR-057).
+   */
+  providers: (): string => 'providers.d',
+  /**
+   * The audit log: one object per event, one chain for the workspace.
+   *
+   * One chain rather than one per profile, because one endpoint serves them all
+   * (ADR-009) and every event already records the profile it acted in. It is
+   * also what lets `audit tail` filter where it used to select, and what gives
+   * the dashboard a single log to read.
+   */
+  audit: (): string => 'audit.log',
+  /**
+   * What the workspace knows about its accounts, and about itself.
    *
-   * The dot is load-bearing, exactly as it is for `audit` below — a provider
-   * is namespaced `<provider>/<connection>` under `blobs`, and a provider id
-   * is `[a-z][a-z0-9_]*`, so a name carrying a dot is one no provider can be
-   * scoped into.
+   * Connection records and the discovery cache, because both are facts about an
+   * account or a provider rather than about anybody's selection of it — a
+   * `connect` run once must read as connected from every profile. And the
+   * endpoint's own OAuth authorization-server state, which is not about a
+   * connection at all: it is the clients that have signed in *to* this endpoint,
+   * and there is one endpoint.
    */
-  state: (profile: string): string => `${profileDir(profile)}/state.kv`,
-  /** System credentials — OAuth tokens, the profile token. Never reachable from MCP. */
-  credentials: (profile: string): string => `${profileDir(profile)}/credentials.enc`,
-  /** The owner's own items, under their own key. */
-  vault: (profile: string): string => `${profileDir(profile)}/vault.enc`,
+  state: (): string => 'state.kv',
+
+  /** Every profile's directory sits under here. */
+  profilesRoot: (): string => PROFILES_DIR,
+  /** Everything one profile is. Also the blob root its providers are scoped under. */
+  profileDir: (profile: string): string => `${PROFILES_DIR}/${profile}`,
   /**
-   * This profile's skills — `<name>.md` or `<name>/SKILL.md`, either layout.
+   * What this profile selects, and who may use it.
    *
-   * The dot carries the same weight it does for `state` and `audit`, and here
-   * it is not hypothetical: `skills` is a real provider id, so `skills/` under
-   * the blob root is the prefix its own connection blobs would scope into.
+   * Inside the profile's own directory, which is the whole of ADR-067 — but it
+   * is therefore inside the tree a running endpoint writes, so the IAM condition
+   * carves it back out. ADR-007 says a deployed revision never mutates its own
+   * configuration, and that rule is older than where the file sits.
    */
-  skills: (profile: string): string => `${profileDir(profile)}/skills.d`,
+  profileConfig: (profile: string): string => `${PROFILES_DIR}/${profile}/${PROFILE_FILE}`,
+  /** Cursors, and each provider's own keys, for this profile's use of an account. */
+  profileState: (profile: string): string => `${PROFILES_DIR}/${profile}/state.kv`,
+  /** Every vault connection's sealed document, for this profile. */
+  vaultRoot: (profile: string): string => `${PROFILES_DIR}/${profile}/vault.d`,
+  /** One sealed document per vault connection, each under its own key. */
+  vault: (profile: string, connection: string): string =>
+    `${PROFILES_DIR}/${profile}/vault.d/${connection}.enc`,
   /**
-   * The provider manifests this profile declares.
+   * The same document, keyed relative to the blob store.
    *
-   * Per profile for the same reason a connection is. A manifest names a host,
-   * an OpenAPI document, and the credential refs that reach them — which is a
-   * description of somebody's infrastructure, and work's is not personal's to
-   * read.
+   * `blobs()` is already rooted at the profile's directory, so a blob adapter
+   * handed the path above would write `profiles/p/profiles/p/vault.d/...`. Two
+   * spellings of one location is exactly what this file exists to prevent, so
+   * the second one lives here beside the first rather than being assembled at
+   * the call site.
    */
-  providers: (profile: string): string => `${profileDir(profile)}/providers.d`,
-  /** The blob root every provider is namespaced under. */
-  blobs: (profile: string): string => profileDir(profile),
+  vaultKey: (connection: string): string => `vault.d/${connection}.enc`,
   /**
-   * The audit log: one object per event, under the profile's blob root.
+   * Every skills connection's procedures, for this profile.
    *
-   * The dot is doing real work. A provider is namespaced to
-   * `<provider>/<connection>` under `blobs` above, and a provider id is
-   * `[a-z][a-z0-9_]*` — so a name carrying a dot is one no provider can be
-   * scoped to. Without it, a provider called `audit` would be handed a store
-   * rooted inside the log, which is a hole in ADR-007's wall rather than an
-   * untidy filename.
+   * The root is exported beside the per-connection path because `deploy` needs
+   * to recognise the *area* without knowing which connections exist — and
+   * `upload.ts` composes its allowlist back out of these rather than comparing
+   * against literals, so a renamed directory moves the store and the thing that
+   * sends it together, or neither.
    */
-  audit: (profile: string): string => `${profileDir(profile)}/audit.log`,
+  skillsRoot: (profile: string): string => `${PROFILES_DIR}/${profile}/skills.d`,
+  /** One skills connection's procedures — `<name>.md` or `<name>/SKILL.md`, either layout. */
+  skills: (profile: string, connection: string): string =>
+    `${PROFILES_DIR}/${profile}/skills.d/${connection}`,
+  /** The blob root this profile's providers are namespaced under. */
+  blobs: (profile: string): string => `${PROFILES_DIR}/${profile}`,
 } as const;
+
+/**
+ * `data/`, which no longer exists — kept for the migrations that address it.
+ *
+ * Contracts 1 through 3 put everything a profile owned under `data/<profile>/`,
+ * and contract 4 moves it out (ADR-067). A migration reads the layout it is
+ * migrating *from*, and that layout is frozen: asking `layout` above would
+ * compare a contract-3 path against a contract-4 default and match nothing.
+ * `migrate-plan.ts` already spells the contract-1 defaults out for the same
+ * reason. Nothing outside a migration should import this.
+ */
+export const LEGACY_DATA_DIR = 'data';
+
+/**
+ * The registry's name, and a profile's path, through contract 3.
+ *
+ * Recognised, never written. Two live functions answer to these — the ancestor
+ * walk and `listProfiles` — for one reason: a workspace that needs migrating
+ * has to be findable by the command that migrates it, or `doctor --fix` reports
+ * no workspace here and the operator has a wall with no door.
+ */
+export const LEGACY_WORKSPACE_FILE = 'lanes-link.yaml';
+
+export function legacyProfileConfig(profile: string): string {
+  return `${PROFILES_DIR}/${profile}.yaml`;
+}

package/src/profile/load.ts

@@ -1,10 +1,10 @@
 import { parse as parseYaml } from 'yaml';
 import { z } from 'zod';
 import {
+  SINGLE_INSTANCE_PROVIDERS,
   SUPPORTED_CONTRACT,
   configSchema,
   type Config,
-  type PolicyRuleConfig,
 } from './schema.ts';
 import { findSecrets, formatSecretFindings } from './secret-detection.ts';
 
@@ -21,7 +21,7 @@ export class ConfigError extends Error {
 export interface LoadedConfig {
   readonly config: Config;
   readonly source: string;
-  /** `provider.id` for every declared connection, in declaration order. */
+  /** `provider.id` for every connection this profile grants, in declaration order. */
   readonly connectionKeys: readonly string[];
 }
 
@@ -39,8 +39,12 @@ export interface LoadedConfig {
  *  3. Schema shape.
  *  4. Referential integrity, which needs a well-formed document to check.
  */
-export function validateConfig(raw: unknown, source = '<config>'): Config {
-  const config = validateConfigShape(raw, source);
+export function validateConfig(
+  raw: unknown,
+  source = '<config>',
+  contract = SUPPORTED_CONTRACT,
+): Config {
+  const config = validateConfigShape(raw, source, contract);
   assertReferentialIntegrity(config, source);
   return config;
 }
@@ -58,12 +62,16 @@ export function validateConfig(raw: unknown, source = '<config>'): Config {
  * through `validateConfig`, and the split exists so that the one command whose
  * job is to fix a refusal is not blocked by it.
  */
-export function validateConfigShape(raw: unknown, source = '<config>'): Config {
+export function validateConfigShape(
+  raw: unknown,
+  source = '<config>',
+  contract = SUPPORTED_CONTRACT,
+): Config {
   if (raw === null || typeof raw !== 'object' || Array.isArray(raw)) {
     throw new ConfigError(`${source}: expected a YAML mapping at the top level`);
   }
 
-  assertSupportedContract(raw, source);
+  assertSupportedContract(raw, source, contract);
 
   const secrets = findSecrets(raw);
   if (secrets.length > 0) {
@@ -88,7 +96,17 @@ export function validateConfigShape(raw: unknown, source = '<config>'): Config {
  * risks reading a document as more permissive than the operator wrote it, and
  * refusing to start is always the safer failure.
  */
-function assertSupportedContract(raw: object, source: string): void {
+/**
+ * The contract this document must declare.
+ *
+ * `expected` is `SUPPORTED_CONTRACT` everywhere except inside a migration,
+ * which writes intermediate shapes on the way to the newest one — contract 1 to
+ * 2 to 3 to 4, saving at each step. Refusing those would mean a migration
+ * cannot use `ConfigDocument` at all and has to write YAML past the validator,
+ * losing the secret-shaped-value check that is the reason the validator runs on
+ * every save. A step that declares which contract it is producing keeps both.
+ */
+function assertSupportedContract(raw: object, source: string, expected: number): void {
   const contract = (raw as { contract?: unknown }).contract;
 
   if (typeof contract !== 'number' || !Number.isInteger(contract)) {
@@ -97,14 +115,20 @@ function assertSupportedContract(raw: object, source: string): void {
     );
   }
 
-  if (contract !== SUPPORTED_CONTRACT) {
-    const direction = contract > SUPPORTED_CONTRACT ? 'newer than' : 'older than';
+  if (contract !== expected) {
+    const direction = contract > expected ? 'newer than' : 'older than';
     throw new ConfigError(
       `${source}: contract ${contract} is ${direction} the contract this binary implements (${SUPPORTED_CONTRACT}). ` +
         `Refusing to load rather than guessing at what the document means. ` +
+        // **Naming the command is the whole point of this branch.** ADR-051
+        // records what a refusal that names none costs: `validateConfig` runs
+        // from every command, so one stale workspace takes `status`, `start`,
+        // `plan` and `doctor` down together, and "migrate the config" left an
+        // operator with a wall and no door. `doctor --fix` runs every migration
+        // between the contract on disk and this one.
         (contract > SUPPORTED_CONTRACT
           ? 'Upgrade lanes-link.'
-          : 'Migrate the config, or use a matching lanes-link version.'),
+          : 'Migrate it with: lanes link doctor --fix'),
     );
   }
 }
@@ -166,8 +190,11 @@ function formatZodIssues(error: z.ZodError): string {
 export interface ProviderRename {
   /** What a row naming the old id should say instead. */
   readonly to: string;
-  /** The account label that means this row is the built-in, not a vendor one. */
-  readonly keeps: string;
+  /**
+   * The account label that meant this row was the built-in rather than a
+   * vendor's, or `null` where the id belongs to nobody now.
+   */
+  readonly keeps: string | null;
   /** What the plain noun now names, for the sentence below. */
   readonly becomes: string;
   /** What it used to name. */
@@ -190,8 +217,12 @@ export interface ProviderRename {
 export const RENAMED_PROVIDERS: Readonly<Record<string, ProviderRename>> = {
   tasks: {
     to: 'google_tasks',
-    keeps: 'Tasks',
-    becomes: 'the built-in task list',
+    // **`null`, where this was `'Tasks'`.** The refusal existed because the
+    // built-in claimed `tasks`, so a stale Google Tasks row rebound to it and
+    // the label was the only evidence of which was meant (ADR-051). The
+    // built-in is `lanes_tasks` now, so no label makes a row here legitimate.
+    keeps: null,
+    becomes: 'nobody\u2019s provider id \u2014 the built-in task list is lanes_tasks',
     was: 'Google Tasks',
     noun: 'task list',
   },
@@ -208,7 +239,7 @@ export const RENAMED_PROVIDERS: Readonly<Record<string, ProviderRename>> = {
  * and whoever is reading this refusal just typed which one.
  */
 function repairCommand(config: Config): string {
-  return `lanes link doctor --fix --profile ${config.instance.profile} --target <target>`;
+  return `lanes link doctor --fix --profile ${config.instance.profile} --workspace <name>`;
 }
 
 /** The rename a row is owed, or `null` when it is owed none. */
@@ -217,11 +248,12 @@ export function renamedProviderFor(connection: {
   account: string;
 }): ProviderRename | null {
   const moved = RENAMED_PROVIDERS[connection.provider];
-  if (!moved || connection.account === moved.keeps) return null;
-  return moved;
+  if (!moved) return null;
+  // `keeps === null` means the id belongs to nobody, so no label exempts a row.
+  return moved.keeps !== null && connection.account === moved.keeps ? null : moved;
 }
 
-function renamedProvider(
+export function describeRename(
   connection: { provider: string; account: string },
   repair: string,
 ): string | null {
@@ -229,11 +261,15 @@ function renamedProvider(
   if (!moved) return null;
 
   return (
-    `"${connection.provider}" is now ${moved.becomes}, and this row is labelled ` +
-    `"${connection.account}" rather than "${moved.keeps}".\n` +
+    (moved.keeps === null
+      ? `"${connection.provider}" is ${moved.becomes}.\n`
+      : `"${connection.provider}" is now ${moved.becomes}, and this row is labelled ` +
+        `"${connection.account}" rather than "${moved.keeps}".\n`) +
     `  If it was ${moved.was}: set provider to ${moved.to} here, and rename any ` +
     `"${connection.provider}.*" policy rule.\n` +
-    `  If it is your own ${moved.noun}: set account to ${moved.keeps}.\n` +
+    (moved.keeps === null
+      ? `  If it is your own ${moved.noun}: it is lanes_${connection.provider} now.\n`
+      : `  If it is your own ${moved.noun}: set account to ${moved.keeps}.\n`) +
     `  ${repair} applies the first, where a stored credential proves it.`
   );
 }
@@ -241,30 +277,74 @@ function renamedProvider(
 function assertReferentialIntegrity(config: Config, source: string): void {
   const problems: string[] = [];
 
-  // There is nothing to check about targets here any more. A profile declares
-  // none (ADR-052): the workspace holding this file declares the one target it
-  // lives in, and `workspaceSchema` is what validates that. A profile is now
-  // portable between targets precisely because it says nothing about them.
-
-  // Connection ids are unique per provider, so `gmail.main` and
-  // `icloud_mail.main` can coexist.
-  const connectionKeys = new Set<string>();
-  const providerNames = new Set(config.connections.map((connection) => connection.provider));
-
-  config.connections.forEach((connection, index) => {
-    const key = `${connection.provider}.${connection.id}`;
-    if (connectionKeys.has(key)) {
-      problems.push(`connections[${index}]: duplicate connection "${key}"`);
+  // Nothing about targets is checked here any more. A profile declares none
+  // (ADR-052): the workspace holding this file declares the one it lives in.
+  //
+  // Nothing about *connections* is either, and that is newer. A connection
+  // belongs to the workspace (ADR-057), so whether a grant names a real one is
+  // a question this file cannot answer on its own — `assertGrantsResolve` in
+  // `./connections.ts` answers it once `connections.yaml` has been read. What
+  // is checkable from one profile alone is checked here, and only that.
+
+  // A grant names one connection, so every capability in it belongs to that
+  // connection's provider. Worth refusing rather than warning: `allowedConnections`
+  // filters candidates to the capability's own provider before policy is
+  // consulted, so `allow: [calendar.*]` on a row granting `gmail.personal`
+  // matches nothing, ever, while reading exactly like a grant that works.
+  const grantKeys = new Set<string>();
+  config.grants.forEach((grant, index) => {
+    if (grantKeys.has(grant.connection)) {
+      problems.push(`grants[${index}]: duplicate grant for "${grant.connection}"`);
     }
-    connectionKeys.add(key);
+    grantKeys.add(grant.connection);
+
+    const provider = grant.connection.split('.')[0] ?? '';
+
+    // The renamed-provider check is not here any more. It compares a row's
+    // *account* against the label the built-in keeps — "is this really Google
+    // Tasks?" — and an account lives in `connections.yaml` now (ADR-057). A
+    // profile grant carries only the key, so asking here would either need the
+    // other file or answer from nothing; `assertNoRenamedProviders` asks where
+    // the answer is.
+
+    for (const [field, rules] of [
+      ['allow', grant.allow],
+      ['deny', grant.deny],
+    ] as const) {
+      rules.forEach((rule, ruleIndex) => {
+        if (rule.capability === '*') return;
+        const named = rule.capability.split('.')[0] ?? '';
+        if (named === provider) return;
 
-    const renamed = renamedProvider(connection, repairCommand(config));
-    if (renamed) problems.push(`connections[${index}]: ${renamed}`);
+        problems.push(
+          `grants[${index}].${field}[${ruleIndex}]: "${rule.capability}" names provider ` +
+            `"${named}", but this row grants "${grant.connection}". A rule here governs ` +
+            `that connection and nothing else, so it can only name "${provider}.*".`,
+        );
+      });
+    }
   });
 
-  // Same reason as a duplicate connection: two entries with the same kind and
-  // value cannot both be meant, and the one that loses is invisible. It matters
-  // more here than it looks, because the two would usually differ only in their
+  // At most one skills grant and one vault grant, for the reason
+  // `SINGLE_INSTANCE_PROVIDERS` gives: both surface as flat names with no
+  // argument to route on, so a second instance is a collision rather than a
+  // choice.
+  for (const provider of SINGLE_INSTANCE_PROVIDERS) {
+    const granted = config.grants
+      .map((grant) => grant.connection)
+      .filter((ref) => ref.startsWith(`${provider}.`));
+
+    if (granted.length > 1) {
+      problems.push(
+        `grants: ${granted.join(' and ')} — a profile may grant one "${provider}" connection. ` +
+          `It is surfaced by name with nothing to route on, so two would be one name for two things.`,
+      );
+    }
+  }
+
+  // Same reason as a duplicate grant: two entries with the same kind and value
+  // cannot both be meant, and the one that loses is invisible. It matters more
+  // here than it looks, because the two would usually differ only in their
   // `note` — so the discarded one is precisely the guidance someone wrote down
   // to stop an agent picking wrong.
   const identityKeys = new Set<string>();
@@ -276,28 +356,17 @@ function assertReferentialIntegrity(config: Config, source: string): void {
     identityKeys.add(key);
   });
 
-  const checkRules = (rules: readonly PolicyRuleConfig[], field: 'allow' | 'deny'): void => {
-    rules.forEach((rule, index) => {
-      const where = `policy.${field}[${index}]`;
-      if (rule.capability === '*') return;
-
-      // A rule naming a provider with no connection is almost always a typo,
-      // and one that fails open-looking: it reads as a grant while matching
-      // nothing. Worth saying, but not fatal for a `deny` — denying something
-      // you have not connected yet is a perfectly reasonable thing to write
-      // ahead of time.
-      const providerOfCapability = rule.capability.split('.')[0] ?? '';
-      if (field === 'allow' && !providerNames.has(providerOfCapability)) {
-        problems.push(
-          `${where}: "${rule.capability}" names provider "${providerOfCapability}", which has no connection` +
-            (providerNames.size > 0 ? ` (have: ${[...providerNames].join(', ')})` : ''),
-        );
-      }
-    });
-  };
-
-  checkRules(config.policy.allow, 'allow');
-  checkRules(config.policy.deny, 'deny');
+  // A subject listed twice is one row deciding the role and the other doing
+  // nothing, and which one wins is iteration order. Since the two would differ
+  // only in `role`, the silent loser is exactly the line someone added to
+  // promote or demote somebody (ADR-060).
+  const subjects = new Set<string>();
+  config.members.forEach((member, index) => {
+    if (subjects.has(member.subject)) {
+      problems.push(`members[${index}]: duplicate subject "${member.subject}"`);
+    }
+    subjects.add(member.subject);
+  });
 
   if (problems.length > 0) {
     throw new ConfigError(`${source}:\n${problems.map((p) => `  ${p}`).join('\n')}`, problems);
@@ -316,7 +385,7 @@ export function parseConfig(text: string, source = '<config>'): LoadedConfig {
   return {
     config,
     source,
-    connectionKeys: config.connections.map((c) => `${c.provider}.${c.id}`),
+    connectionKeys: config.grants.map((grant) => grant.connection),
   };
 }