Providers create the credential the mesh minted, sealing nothing (ADR 0053)

redis, postgres and minio adapters drop generatePassword + the returned credential:
each creates the resource under the login the mesh derived (`as`) with the password
the mesh minted (`p.password`). minio's client gains a secret-key argument so it sets
the mesh's secret rather than generating one. umami (analytics) is re-pointed at the
new contract too; its siteId return is a data-provision concern ADR 0053 scopes out.

Proven: mesh-lab provider-uses-mesh-credential green — redis creates the consumer's
login with the mesh's password, the consumer authenticates (PONG), no seal key set.

Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF

modules/minio/client.ts

@@ -10,7 +10,7 @@
 //     creation the MinIO admin REST API guards behind an encrypted payload `fetch` cannot form.
 // This mirrors hal's MinIOClient/MinIOAdmin split, folded into one client the module builds from env.
 
-import { createHash, createHmac, randomBytes } from "node:crypto";
+import { createHash, createHmac } from "node:crypto";
 import { execFile } from "node:child_process";
 import { readFileSync, writeFileSync, unlinkSync } from "node:fs";
 import { tmpdir } from "node:os";
@@ -205,14 +205,15 @@ export class MinioClient {
   // --- admin plane (mc CLI) ------------------------------------------------
 
   /**
-   * Create a service account scoped to one bucket and return its credential. The MinIO admin REST
-   * API encrypts this request with a key derived (Argon2) from the root secret, which node built-ins
-   * cannot reproduce — so, as hal did, the module drives the `mc` CLI, which the provisioner image
-   * bundles.
+   * Create a service account scoped to one bucket, under a given access key and secret key, and
+   * return the pair. The secret key is the mesh's — the mesh mints one password per consumer and
+   * hands a copy to both ends (novox/hq ADR 0053), so minio sets that as the secret rather than
+   * generating one the consumer could never learn. The MinIO admin REST API encrypts this request
+   * with a key derived (Argon2) from the root secret, which node built-ins cannot reproduce — so, as
+   * hal did, the module drives the `mc` CLI, which the runtime image bundles.
    */
-  async createAccessKey(bucket: string, accessKey: string): Promise<AccessKey> {
+  async createAccessKey(bucket: string, accessKey: string, secretKey: string): Promise<AccessKey> {
     await this.ensureAlias();
-    const secretKey = randomBytes(20).toString("hex");
     const policyPath = join(this.mcConfigDir, `policy-${accessKey}.json`);
     writeFileSync(policyPath, bucketPolicy(bucket), { mode: 0o600 });
     try {

modules/minio/provisioner/index.ts

@@ -1,72 +1,62 @@
 // minio's provisioner — the adapter that makes minio a provider of the mesh `s3-bucket` interface
-// (the name in module.json's `provides`). The reconcile loop, sealing and grant-file handling are the
-// sdk harness's; this writes only the per-service half: how minio creates and removes a consumer's
-// bucket and its scoped access key (novox/hq ADR 0044/0045).
+// (the name in module.json's `provides`). The reconcile loop, the contributions file, and reading
+// the mesh's minted secret are the sdk harness's; this writes only the per-service half: how minio
+// creates and removes a consumer's bucket and its scoped access key (novox/hq ADR 0044/0045/0053).
 //
-// The `s3-bucket` interface: a consumer receives `{ endpoint, bucket, accessKey, secretKey, region }`
-// — an S3 endpoint and a credential confined to its own bucket. It depends on `s3-bucket`, not on
-// minio, so any S3-compatible provider could serve it.
+// The `s3-bucket` interface: a consumer connects to an S3 endpoint with an access key confined to
+// its own bucket. It depends on `s3-bucket`, not on minio, so any S3-compatible provider could serve
+// it.
 //
-// The bucket and access-key id are derived deterministically from the consumer's identity, because
-// the harness hands `remove` only that identity (no stored values) — so teardown recomputes exactly
-// what creation minted, with nothing to persist. The emits fire here, at the real provisioning
-// points (novox/hq ADR 0046/0047); the module's events entrypoint (../index.ts) consumes them.
+// **The access key and its secret are the mesh's, not the provisioner's (ADR 0053).** The mesh
+// derives the login (the access-key id) and hands it to both ends, and mints the secret key. minio
+// creates the service account under exactly that access key with exactly that secret — a credential
+// the provisioner invented is one the consumer could never present. The bucket is derived from the
+// login, so teardown recomputes it with nothing to persist.
 
-import { runProvisioner, type Grant, type Credential } from "@novox/mesh-sdk/provisioner";
+import { runProvisioner, type Provision } from "@novox/mesh-sdk/provisioner";
 import { emit } from "@novox/mesh-sdk/events";
-import { MinioClient, accessKeyFor, bucketFor } from "../client.js";
+import { MinioClient, bucketFor } from "../client.js";
 
 const minio = MinioClient.fromEnv();
 
 runProvisioner("s3-bucket", {
-  async create(grant: Grant): Promise<Credential> {
-    const bucket = bucketFor(grant.consumer);
-    const accessKeyId = accessKeyFor(grant.consumer);
+  async create(p: Provision): Promise<void> {
+    const bucket = bucketFor(p.as);
+    const accessKeyId = p.as;
 
     if (!(await minio.bucketExists(bucket))) await minio.createBucket(bucket);
-    // Re-mint the scoped key idempotently: drop any prior one under this id, then add fresh.
+    // Re-mint the scoped key idempotently: drop any prior one under this id, then add it back with
+    // the mesh's secret.
     try { await minio.removeAccessKey(accessKeyId); } catch { /* none yet — first provision */ }
-    const key = await minio.createAccessKey(bucket, accessKeyId);
+    await minio.createAccessKey(bucket, accessKeyId, p.password);
 
     await announce("module.minio.bucket.created", {
       bucket,
-      consumer: grant.consumer,
-      node: grant.node,
-      accessKey: key.accessKey, // the secret is never put on the bus — only the credential file carries it
+      consumer: p.consumer ?? "",
+      accessKey: accessKeyId,
       endpoint: minio.baseUrl,
     });
-
-    return {
-      fields: {
-        endpoint: minio.baseUrl,
-        bucket,
-        accessKey: key.accessKey,
-        secretKey: key.secretKey,
-        region: minio.region,
-      },
-    };
   },
 
-  async remove(grant: Grant): Promise<void> {
-    const bucket = bucketFor(grant.consumer);
-    const accessKeyId = accessKeyFor(grant.consumer);
+  async remove(p: { as: string }): Promise<void> {
+    const bucket = bucketFor(p.as);
 
     // Revoking the key is what cuts the consumer's access. The bucket is emptied-then-dropped only if
     // empty; a bucket that still holds objects is left for an operator rather than erroring on every
     // reconcile tick — access is already gone, and silently deleting a consumer's data would be worse.
-    try { await minio.removeAccessKey(accessKeyId); } catch { /* already gone */ }
+    try { await minio.removeAccessKey(p.as); } catch { /* already gone */ }
     try {
       await minio.removeBucket(bucket);
     } catch (err) {
       console.error(`[minio] bucket ${bucket} not removed (likely non-empty), access revoked: ${err}`);
     }
 
-    await announce("module.minio.bucket.removed", { bucket, consumer: grant.consumer, node: grant.node });
+    await announce("module.minio.bucket.removed", { bucket, accessKey: p.as });
   },
 });
 
-/** Emit best-effort: with no broker bound (a provisioner is not yet a runtime — novox/hq ADR 0052)
- *  the event is logged and dropped, never allowed to throw back and fail a bucket that was made. */
+/** Emit best-effort: a broker hiccup is logged and dropped, never allowed to throw back and fail a
+ *  bucket that was made. */
 async function announce(type: string, body: unknown): Promise<void> {
   try {
     await emit(type, body);