@kya-os/cli 1.8.3 → 2.0.2

package/node_modules/@kya-os/contracts/dist/review/registry.d.ts

@@ -0,0 +1,349 @@
+/**
+ * Reviewer Registry Schema
+ *
+ * Maps a human reviewer to their GitHub login, their review agent's DID,
+ * and per-person operational config (which env var holds their publish
+ * token, where their `review-pr` delegation VC lives on disk). Nothing in
+ * the ecosystem persisted this mapping before this schema:
+ * `ReviewCoordinator`'s reviewer set
+ * (`packages/compute/src/didcomm/review-coordinator.ts`) is an in-memory
+ * `Map` filled only via `registerReviewer(did, delegationVC)`, with no
+ * file, table, or env format that seeds it, and the only place a GitHub
+ * login is read (`packages/cli/src/utils/dco/github.ts`'s `getGhUser`) is
+ * transient, used during `dco setup` and never persisted next to the agent
+ * DID.
+ *
+ * Everything downstream needs this mapping: hub wiring registers reviewers
+ * from it, a checkpoint credential script reads it to know which DIDs to
+ * issue VCs for, a publisher picks per-person GitHub tokens from it, and a
+ * fix dispatcher joins PR author login to author agent DID through it. See
+ * `packages/compute/src/didcomm/reviewer-registry.ts` for the loader that
+ * turns a registry file (or inline JSON) into this shape.
+ *
+ * Pure Zod schemas only, matching the rest of `@kya-os/contracts/review`.
+ *
+ * 2026-08-21 amendment (review-loop P15): one person can run more than one
+ * agent (e.g. a `dco setup`-configured agent plus a detected Claude Code
+ * profile from `kya-os init`'s agent-detection stage), so uniqueness moved
+ * from `githubLogin` alone to the `(githubLogin, slug)` pair -- see the
+ * `superRefine` below. `agentDid` stays fully unique across entries, and a
+ * new refinement caps `fixes: true` at one entry per `githubLogin`: the fix
+ * dispatcher's author-login join must stay single-valued even when a person
+ * has multiple agents.
+ *
+ * @package @kya-os/contracts/review
+ */
+import { z } from 'zod';
+/**
+ * Reviewer Registry Entry Schema
+ *
+ * One person and their review agent.
+ */
+export declare const ReviewerRegistryEntrySchema: z.ZodObject<{
+    /** Display name, e.g. "Marshall". */
+    person: z.ZodString;
+    /** GitHub login, e.g. "MarshallBorham". Must be unique across entries. */
+    githubLogin: z.ZodString;
+    /**
+     * DCO agent slug, e.g. "marshall-agent". Restricted to the same
+     * `[a-z0-9][a-z0-9-]*` shape as `SLUG_PATTERN` in
+     * `packages/cli/src/utils/cli-kit/paths.ts` (mirrored here rather than
+     * imported: contracts has no dependency on cli). That pattern's own doc
+     * comment explains why: slugs are often sourced from a file or env var
+     * an untrusted source can influence, and become a path segment -- the
+     * same shape of risk this registry's file/env-sourced `slug` carries.
+     */
+    slug: z.ZodString;
+    /** "did:web:knowthat.ai:agents:<slug>". Must be unique across entries. */
+    agentDid: z.ZodString;
+    /** Whether this person's agent acts as a reviewer (counts toward `quorumN`). */
+    reviews: z.ZodBoolean;
+    /** Whether this person receives fix dispatches for their own PRs. */
+    fixes: z.ZodBoolean;
+    /**
+     * NAME of an environment variable holding this person's GitHub publish
+     * token, never the token value itself. The registry file is expected to
+     * be committed to private deploy config; a literal token here would be a
+     * leak.
+     */
+    publishTokenEnv: z.ZodOptional<z.ZodString>;
+    /**
+     * Path to this agent's `review-pr` delegation VC. Resolved by the loader
+     * relative to the registry file's directory, not to the process cwd.
+     */
+    delegationVcPath: z.ZodOptional<z.ZodString>;
+}, "strip", z.ZodTypeAny, {
+    agentDid: string;
+    slug: string;
+    githubLogin: string;
+    reviews: boolean;
+    person: string;
+    fixes: boolean;
+    publishTokenEnv?: string | undefined;
+    delegationVcPath?: string | undefined;
+}, {
+    agentDid: string;
+    slug: string;
+    githubLogin: string;
+    reviews: boolean;
+    person: string;
+    fixes: boolean;
+    publishTokenEnv?: string | undefined;
+    delegationVcPath?: string | undefined;
+}>;
+export type ReviewerRegistryEntry = z.infer<typeof ReviewerRegistryEntrySchema>;
+/**
+ * Reviewer Registry Schema
+ *
+ * The full registry: org identity, quorum size, watched repos, and the
+ * per-person entries. Enforced invariants (see the `superRefine` below):
+ * `agentDid` unique across entries, `githubLogin` unique across entries,
+ * and `quorumN` no larger than the number of entries with `reviews: true`.
+ *
+ * Worked example, a three-person org where two of the three vote
+ * (`quorumN: 2`, Brian is a fix-only participant who doesn't review), and
+ * Marshall runs a second agent (a `kya-os init`-detected Claude Code
+ * profile) alongside his original one -- same `githubLogin`, distinct
+ * `slug`/`agentDid`, and `fixes: true` only on the original so fix dispatch
+ * stays single-valued per person:
+ *
+ * ```json
+ * {
+ *   "orgId": "vouched",
+ *   "orgRootDid": "did:web:kya.vouched.id:orgs:vouched",
+ *   "quorumN": 2,
+ *   "repos": ["modelcontextprotocol-identity/xmcp-i"],
+ *   "entries": [
+ *     {
+ *       "person": "Marshall",
+ *       "githubLogin": "marshall-vouched",
+ *       "slug": "marshall-agent",
+ *       "agentDid": "did:web:knowthat.ai:agents:marshall-agent",
+ *       "reviews": true,
+ *       "fixes": true,
+ *       "publishTokenEnv": "MARSHALL_GITHUB_TOKEN",
+ *       "delegationVcPath": "./vcs/marshall-agent.review-pr.vc.json"
+ *     },
+ *     {
+ *       "person": "Marshall",
+ *       "githubLogin": "marshall-vouched",
+ *       "slug": "marshall-claude-code",
+ *       "agentDid": "did:web:knowthat.ai:agents:marshall-claude-code",
+ *       "reviews": true,
+ *       "fixes": false
+ *     },
+ *     {
+ *       "person": "Dylan",
+ *       "githubLogin": "dylan-vouched",
+ *       "slug": "dylan-agent",
+ *       "agentDid": "did:web:knowthat.ai:agents:dylan-agent",
+ *       "reviews": true,
+ *       "fixes": true,
+ *       "publishTokenEnv": "DYLAN_GITHUB_TOKEN",
+ *       "delegationVcPath": "./vcs/dylan-agent.review-pr.vc.json"
+ *     },
+ *     {
+ *       "person": "Brian",
+ *       "githubLogin": "brian-vouched",
+ *       "slug": "brian-agent",
+ *       "agentDid": "did:web:knowthat.ai:agents:brian-agent",
+ *       "reviews": false,
+ *       "fixes": true,
+ *       "publishTokenEnv": "BRIAN_GITHUB_TOKEN"
+ *     }
+ *   ]
+ * }
+ * ```
+ */
+export declare const ReviewerRegistrySchema: z.ZodEffects<z.ZodObject<{
+    orgId: z.ZodString;
+    /** "did:web:kya.vouched.id:orgs:<slug>". */
+    orgRootDid: z.ZodString;
+    /**
+     * Minimum number of `reviews: true` entries whose verdicts must agree.
+     *
+     * SECURITY NOTE for whoever wires this registry into quorum counting
+     * (e.g. `ReviewCoordinator.registerReviewer()` /
+     * `packages/compute/src/didcomm/hub.ts`'s `recordApprovalAndCheckQuorum`,
+     * which tracks approvals in a `Set<agentDid>`): quorum there is counted
+     * per DID, not per person. Since the 2026-08-21 relaxation above allows
+     * one `githubLogin` to own multiple `reviews: true` entries (multiple
+     * agent DIDs), a single person running several locally-created agent
+     * profiles (e.g. via `kya-os init --profiles claude-code,codex`) can
+     * supply multiple distinct DIDs and, if each is registered as a
+     * reviewer, satisfy `quorumN >= 2` alone. Use `countDistinctApprovers`
+     * (exported below) wherever quorum is counted against this registry --
+     * it de-dupes by `githubLogin` instead of raw DID, closing exactly this
+     * gap. Restricting `reviews: true` to one entry per `githubLogin` is
+     * NOT the fix: the worked example above intentionally wants a person's
+     * second agent to also review.
+     */
+    quorumN: z.ZodNumber;
+    /**
+     * "owner/name" repo slugs this registry's reviewers watch. Character
+     * class matches `isValidRepoSlug`'s `REPO_SLUG_PATTERN` in
+     * `packages/compute/src/didcomm/github-client.ts` (mirrored here rather
+     * than imported: contracts has no dependency on compute). Downstream
+     * code concatenates these slugs directly into unencoded GitHub REST
+     * URLs, so a looser pattern (e.g. one that only excludes `/` and
+     * whitespace) would let `owner/repo?x` through as a "valid" slug.
+     *
+     * Each segment additionally can't be all dots (`.`, `..`, ...): the
+     * character class alone still accepts `../evil`, since `.` is a
+     * legal repo-name character and `..` is just two of them -- the same
+     * gap `REPO_SLUG_PATTERN` itself has. No real GitHub owner or repo
+     * name is ever pure punctuation, so excluding it closes the traversal
+     * case without rejecting any legitimate slug.
+     */
+    repos: z.ZodArray<z.ZodString, "many">;
+    entries: z.ZodArray<z.ZodObject<{
+        /** Display name, e.g. "Marshall". */
+        person: z.ZodString;
+        /** GitHub login, e.g. "MarshallBorham". Must be unique across entries. */
+        githubLogin: z.ZodString;
+        /**
+         * DCO agent slug, e.g. "marshall-agent". Restricted to the same
+         * `[a-z0-9][a-z0-9-]*` shape as `SLUG_PATTERN` in
+         * `packages/cli/src/utils/cli-kit/paths.ts` (mirrored here rather than
+         * imported: contracts has no dependency on cli). That pattern's own doc
+         * comment explains why: slugs are often sourced from a file or env var
+         * an untrusted source can influence, and become a path segment -- the
+         * same shape of risk this registry's file/env-sourced `slug` carries.
+         */
+        slug: z.ZodString;
+        /** "did:web:knowthat.ai:agents:<slug>". Must be unique across entries. */
+        agentDid: z.ZodString;
+        /** Whether this person's agent acts as a reviewer (counts toward `quorumN`). */
+        reviews: z.ZodBoolean;
+        /** Whether this person receives fix dispatches for their own PRs. */
+        fixes: z.ZodBoolean;
+        /**
+         * NAME of an environment variable holding this person's GitHub publish
+         * token, never the token value itself. The registry file is expected to
+         * be committed to private deploy config; a literal token here would be a
+         * leak.
+         */
+        publishTokenEnv: z.ZodOptional<z.ZodString>;
+        /**
+         * Path to this agent's `review-pr` delegation VC. Resolved by the loader
+         * relative to the registry file's directory, not to the process cwd.
+         */
+        delegationVcPath: z.ZodOptional<z.ZodString>;
+    }, "strip", z.ZodTypeAny, {
+        agentDid: string;
+        slug: string;
+        githubLogin: string;
+        reviews: boolean;
+        person: string;
+        fixes: boolean;
+        publishTokenEnv?: string | undefined;
+        delegationVcPath?: string | undefined;
+    }, {
+        agentDid: string;
+        slug: string;
+        githubLogin: string;
+        reviews: boolean;
+        person: string;
+        fixes: boolean;
+        publishTokenEnv?: string | undefined;
+        delegationVcPath?: string | undefined;
+    }>, "many">;
+}, "strip", z.ZodTypeAny, {
+    entries: {
+        agentDid: string;
+        slug: string;
+        githubLogin: string;
+        reviews: boolean;
+        person: string;
+        fixes: boolean;
+        publishTokenEnv?: string | undefined;
+        delegationVcPath?: string | undefined;
+    }[];
+    orgId: string;
+    orgRootDid: string;
+    quorumN: number;
+    repos: string[];
+}, {
+    entries: {
+        agentDid: string;
+        slug: string;
+        githubLogin: string;
+        reviews: boolean;
+        person: string;
+        fixes: boolean;
+        publishTokenEnv?: string | undefined;
+        delegationVcPath?: string | undefined;
+    }[];
+    orgId: string;
+    orgRootDid: string;
+    quorumN: number;
+    repos: string[];
+}>, {
+    entries: {
+        agentDid: string;
+        slug: string;
+        githubLogin: string;
+        reviews: boolean;
+        person: string;
+        fixes: boolean;
+        publishTokenEnv?: string | undefined;
+        delegationVcPath?: string | undefined;
+    }[];
+    orgId: string;
+    orgRootDid: string;
+    quorumN: number;
+    repos: string[];
+}, {
+    entries: {
+        agentDid: string;
+        slug: string;
+        githubLogin: string;
+        reviews: boolean;
+        person: string;
+        fixes: boolean;
+        publishTokenEnv?: string | undefined;
+        delegationVcPath?: string | undefined;
+    }[];
+    orgId: string;
+    orgRootDid: string;
+    quorumN: number;
+    repos: string[];
+}>;
+export type ReviewerRegistry = z.infer<typeof ReviewerRegistrySchema>;
+/**
+ * Counts DISTINCT PEOPLE (by `githubLogin`) among a set of approving agent
+ * DIDs -- not the raw DID count. Quorum counting against this registry MUST
+ * use this (or an equivalent per-person dedup), never `approvedDids.size`
+ * directly: since the 2026-08-21 relaxation above, one `githubLogin` can own
+ * more than one `reviews: true` entry (multiple agent DIDs), so counting raw
+ * DIDs lets one person satisfy a multi-reviewer `quorumN` alone by running
+ * several agents. See the `SECURITY NOTE` on `quorumN` above for the full
+ * threat and the consumer (`packages/compute/src/didcomm/hub.ts`'s
+ * `recordApprovalAndCheckQuorum`) this exists for.
+ *
+ * A DID not present in `registry.entries` is ignored (contributes nothing),
+ * matching the existing quorum consumer's own trust boundary: only DIDs the
+ * registry itself vouches for should ever count toward quorum. That
+ * boundary is `reviews: true` specifically, not "any real entry" -- a
+ * `fixes: true, reviews: false` entry (Brian in the worked example above)
+ * is a real, vouched-for registry entry, but not a DESIGNATED reviewer;
+ * his approval must contribute nothing toward quorum, same as a DID absent
+ * from the registry entirely (review-loop P9/P10 finding: this filter was
+ * missing, so a fixes-only agent's self-signed approve verdict silently
+ * counted).
+ */
+export declare function countDistinctApprovers(registry: ReviewerRegistry, approvedDids: ReadonlySet<string> | readonly string[]): number;
+/**
+ * Whether `agentDid` belongs to a `reviews: true` entry in `registry` -- a
+ * DESIGNATED reviewer, not merely an org-scoped agent whose verdict a hub
+ * happened to count. `data.counted` on a `review_verdict` hub event
+ * (`packages/compute/src/didcomm/hub.ts`'s `handleReviewVerdict`) proves
+ * shape + org-scope + signature + tenant/head match -- it does NOT check
+ * registry membership; that filter previously existed only inside
+ * {@link countDistinctApprovers}, scoped to the separate
+ * `pr_quorum_reached` path. Both `review-publisher.ts` and
+ * `fix-dispatcher.ts` (review-loop P9/P10) apply this SAME check
+ * independently before acting on a `review_verdict` event, so it lives here
+ * once rather than being copy-pasted into each consumer.
+ */
+export declare function isDesignatedReviewer(registry: ReviewerRegistry, agentDid: string): boolean;

package/node_modules/@kya-os/contracts/dist/review/registry.js

@@ -0,0 +1,293 @@
+"use strict";
+/**
+ * Reviewer Registry Schema
+ *
+ * Maps a human reviewer to their GitHub login, their review agent's DID,
+ * and per-person operational config (which env var holds their publish
+ * token, where their `review-pr` delegation VC lives on disk). Nothing in
+ * the ecosystem persisted this mapping before this schema:
+ * `ReviewCoordinator`'s reviewer set
+ * (`packages/compute/src/didcomm/review-coordinator.ts`) is an in-memory
+ * `Map` filled only via `registerReviewer(did, delegationVC)`, with no
+ * file, table, or env format that seeds it, and the only place a GitHub
+ * login is read (`packages/cli/src/utils/dco/github.ts`'s `getGhUser`) is
+ * transient, used during `dco setup` and never persisted next to the agent
+ * DID.
+ *
+ * Everything downstream needs this mapping: hub wiring registers reviewers
+ * from it, a checkpoint credential script reads it to know which DIDs to
+ * issue VCs for, a publisher picks per-person GitHub tokens from it, and a
+ * fix dispatcher joins PR author login to author agent DID through it. See
+ * `packages/compute/src/didcomm/reviewer-registry.ts` for the loader that
+ * turns a registry file (or inline JSON) into this shape.
+ *
+ * Pure Zod schemas only, matching the rest of `@kya-os/contracts/review`.
+ *
+ * 2026-08-21 amendment (review-loop P15): one person can run more than one
+ * agent (e.g. a `dco setup`-configured agent plus a detected Claude Code
+ * profile from `kya-os init`'s agent-detection stage), so uniqueness moved
+ * from `githubLogin` alone to the `(githubLogin, slug)` pair -- see the
+ * `superRefine` below. `agentDid` stays fully unique across entries, and a
+ * new refinement caps `fixes: true` at one entry per `githubLogin`: the fix
+ * dispatcher's author-login join must stay single-valued even when a person
+ * has multiple agents.
+ *
+ * @package @kya-os/contracts/review
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.ReviewerRegistrySchema = exports.ReviewerRegistryEntrySchema = void 0;
+exports.countDistinctApprovers = countDistinctApprovers;
+exports.isDesignatedReviewer = isDesignatedReviewer;
+const zod_1 = require("zod");
+/**
+ * Reviewer Registry Entry Schema
+ *
+ * One person and their review agent.
+ */
+exports.ReviewerRegistryEntrySchema = zod_1.z.object({
+    /** Display name, e.g. "Marshall". */
+    person: zod_1.z.string().min(1),
+    /** GitHub login, e.g. "MarshallBorham". Must be unique across entries. */
+    githubLogin: zod_1.z.string().min(1),
+    /**
+     * DCO agent slug, e.g. "marshall-agent". Restricted to the same
+     * `[a-z0-9][a-z0-9-]*` shape as `SLUG_PATTERN` in
+     * `packages/cli/src/utils/cli-kit/paths.ts` (mirrored here rather than
+     * imported: contracts has no dependency on cli). That pattern's own doc
+     * comment explains why: slugs are often sourced from a file or env var
+     * an untrusted source can influence, and become a path segment -- the
+     * same shape of risk this registry's file/env-sourced `slug` carries.
+     */
+    slug: zod_1.z.string().regex(/^[a-z0-9][a-z0-9-]*$/, "must match [a-z0-9][a-z0-9-]*"),
+    /** "did:web:knowthat.ai:agents:<slug>". Must be unique across entries. */
+    agentDid: zod_1.z.string().min(1),
+    /** Whether this person's agent acts as a reviewer (counts toward `quorumN`). */
+    reviews: zod_1.z.boolean(),
+    /** Whether this person receives fix dispatches for their own PRs. */
+    fixes: zod_1.z.boolean(),
+    /**
+     * NAME of an environment variable holding this person's GitHub publish
+     * token, never the token value itself. The registry file is expected to
+     * be committed to private deploy config; a literal token here would be a
+     * leak.
+     */
+    publishTokenEnv: zod_1.z.string().min(1).optional(),
+    /**
+     * Path to this agent's `review-pr` delegation VC. Resolved by the loader
+     * relative to the registry file's directory, not to the process cwd.
+     */
+    delegationVcPath: zod_1.z.string().min(1).optional(),
+});
+/**
+ * Reviewer Registry Schema
+ *
+ * The full registry: org identity, quorum size, watched repos, and the
+ * per-person entries. Enforced invariants (see the `superRefine` below):
+ * `agentDid` unique across entries, `githubLogin` unique across entries,
+ * and `quorumN` no larger than the number of entries with `reviews: true`.
+ *
+ * Worked example, a three-person org where two of the three vote
+ * (`quorumN: 2`, Brian is a fix-only participant who doesn't review), and
+ * Marshall runs a second agent (a `kya-os init`-detected Claude Code
+ * profile) alongside his original one -- same `githubLogin`, distinct
+ * `slug`/`agentDid`, and `fixes: true` only on the original so fix dispatch
+ * stays single-valued per person:
+ *
+ * ```json
+ * {
+ *   "orgId": "vouched",
+ *   "orgRootDid": "did:web:kya.vouched.id:orgs:vouched",
+ *   "quorumN": 2,
+ *   "repos": ["modelcontextprotocol-identity/xmcp-i"],
+ *   "entries": [
+ *     {
+ *       "person": "Marshall",
+ *       "githubLogin": "marshall-vouched",
+ *       "slug": "marshall-agent",
+ *       "agentDid": "did:web:knowthat.ai:agents:marshall-agent",
+ *       "reviews": true,
+ *       "fixes": true,
+ *       "publishTokenEnv": "MARSHALL_GITHUB_TOKEN",
+ *       "delegationVcPath": "./vcs/marshall-agent.review-pr.vc.json"
+ *     },
+ *     {
+ *       "person": "Marshall",
+ *       "githubLogin": "marshall-vouched",
+ *       "slug": "marshall-claude-code",
+ *       "agentDid": "did:web:knowthat.ai:agents:marshall-claude-code",
+ *       "reviews": true,
+ *       "fixes": false
+ *     },
+ *     {
+ *       "person": "Dylan",
+ *       "githubLogin": "dylan-vouched",
+ *       "slug": "dylan-agent",
+ *       "agentDid": "did:web:knowthat.ai:agents:dylan-agent",
+ *       "reviews": true,
+ *       "fixes": true,
+ *       "publishTokenEnv": "DYLAN_GITHUB_TOKEN",
+ *       "delegationVcPath": "./vcs/dylan-agent.review-pr.vc.json"
+ *     },
+ *     {
+ *       "person": "Brian",
+ *       "githubLogin": "brian-vouched",
+ *       "slug": "brian-agent",
+ *       "agentDid": "did:web:knowthat.ai:agents:brian-agent",
+ *       "reviews": false,
+ *       "fixes": true,
+ *       "publishTokenEnv": "BRIAN_GITHUB_TOKEN"
+ *     }
+ *   ]
+ * }
+ * ```
+ */
+exports.ReviewerRegistrySchema = zod_1.z
+    .object({
+    orgId: zod_1.z.string().min(1),
+    /** "did:web:kya.vouched.id:orgs:<slug>". */
+    orgRootDid: zod_1.z.string().min(1),
+    /**
+     * Minimum number of `reviews: true` entries whose verdicts must agree.
+     *
+     * SECURITY NOTE for whoever wires this registry into quorum counting
+     * (e.g. `ReviewCoordinator.registerReviewer()` /
+     * `packages/compute/src/didcomm/hub.ts`'s `recordApprovalAndCheckQuorum`,
+     * which tracks approvals in a `Set<agentDid>`): quorum there is counted
+     * per DID, not per person. Since the 2026-08-21 relaxation above allows
+     * one `githubLogin` to own multiple `reviews: true` entries (multiple
+     * agent DIDs), a single person running several locally-created agent
+     * profiles (e.g. via `kya-os init --profiles claude-code,codex`) can
+     * supply multiple distinct DIDs and, if each is registered as a
+     * reviewer, satisfy `quorumN >= 2` alone. Use `countDistinctApprovers`
+     * (exported below) wherever quorum is counted against this registry --
+     * it de-dupes by `githubLogin` instead of raw DID, closing exactly this
+     * gap. Restricting `reviews: true` to one entry per `githubLogin` is
+     * NOT the fix: the worked example above intentionally wants a person's
+     * second agent to also review.
+     */
+    quorumN: zod_1.z.number().int().positive(),
+    /**
+     * "owner/name" repo slugs this registry's reviewers watch. Character
+     * class matches `isValidRepoSlug`'s `REPO_SLUG_PATTERN` in
+     * `packages/compute/src/didcomm/github-client.ts` (mirrored here rather
+     * than imported: contracts has no dependency on compute). Downstream
+     * code concatenates these slugs directly into unencoded GitHub REST
+     * URLs, so a looser pattern (e.g. one that only excludes `/` and
+     * whitespace) would let `owner/repo?x` through as a "valid" slug.
+     *
+     * Each segment additionally can't be all dots (`.`, `..`, ...): the
+     * character class alone still accepts `../evil`, since `.` is a
+     * legal repo-name character and `..` is just two of them -- the same
+     * gap `REPO_SLUG_PATTERN` itself has. No real GitHub owner or repo
+     * name is ever pure punctuation, so excluding it closes the traversal
+     * case without rejecting any legitimate slug.
+     */
+    repos: zod_1.z
+        .array(zod_1.z.string().regex(/^(?!\.+\/)[A-Za-z0-9._-]+\/(?!\.+$)[A-Za-z0-9._-]+$/, 'must be "owner/name"'))
+        .min(1),
+    entries: zod_1.z.array(exports.ReviewerRegistryEntrySchema).min(1),
+})
+    .superRefine((data, ctx) => {
+    const seenDids = new Map();
+    const seenLoginSlugPairs = new Map();
+    const fixesTrueIndexByLogin = new Map();
+    data.entries.forEach((entry, index) => {
+        const priorDidIndex = seenDids.get(entry.agentDid);
+        if (priorDidIndex !== undefined) {
+            ctx.addIssue({
+                code: zod_1.z.ZodIssueCode.custom,
+                message: `Duplicate agentDid "${entry.agentDid}" (also at entries[${priorDidIndex}])`,
+                path: ['entries', index, 'agentDid'],
+            });
+        }
+        else {
+            seenDids.set(entry.agentDid, index);
+        }
+        // One person may run more than one agent, so githubLogin alone is no
+        // longer unique; the (githubLogin, slug) pair still must be.
+        const pairKey = `${entry.githubLogin}${entry.slug}`;
+        const priorPairIndex = seenLoginSlugPairs.get(pairKey);
+        if (priorPairIndex !== undefined) {
+            ctx.addIssue({
+                code: zod_1.z.ZodIssueCode.custom,
+                message: `Duplicate (githubLogin, slug) "${entry.githubLogin}", "${entry.slug}" (also at entries[${priorPairIndex}])`,
+                path: ['entries', index, 'slug'],
+            });
+        }
+        else {
+            seenLoginSlugPairs.set(pairKey, index);
+        }
+        // The fix dispatcher joins PR author login to author agent DID, which
+        // must stay single-valued even when a person has multiple agents.
+        if (entry.fixes) {
+            const priorFixesIndex = fixesTrueIndexByLogin.get(entry.githubLogin);
+            if (priorFixesIndex !== undefined) {
+                ctx.addIssue({
+                    code: zod_1.z.ZodIssueCode.custom,
+                    message: `Duplicate fixes: true for githubLogin "${entry.githubLogin}" (also at entries[${priorFixesIndex}]); at most one agent per person may receive fix dispatches`,
+                    path: ['entries', index, 'fixes'],
+                });
+            }
+            else {
+                fixesTrueIndexByLogin.set(entry.githubLogin, index);
+            }
+        }
+    });
+    const reviewerCount = data.entries.filter((entry) => entry.reviews).length;
+    if (data.quorumN > reviewerCount) {
+        ctx.addIssue({
+            code: zod_1.z.ZodIssueCode.custom,
+            message: `quorumN (${data.quorumN}) exceeds the number of entries with reviews: true (${reviewerCount})`,
+            path: ['quorumN'],
+        });
+    }
+});
+/**
+ * Counts DISTINCT PEOPLE (by `githubLogin`) among a set of approving agent
+ * DIDs -- not the raw DID count. Quorum counting against this registry MUST
+ * use this (or an equivalent per-person dedup), never `approvedDids.size`
+ * directly: since the 2026-08-21 relaxation above, one `githubLogin` can own
+ * more than one `reviews: true` entry (multiple agent DIDs), so counting raw
+ * DIDs lets one person satisfy a multi-reviewer `quorumN` alone by running
+ * several agents. See the `SECURITY NOTE` on `quorumN` above for the full
+ * threat and the consumer (`packages/compute/src/didcomm/hub.ts`'s
+ * `recordApprovalAndCheckQuorum`) this exists for.
+ *
+ * A DID not present in `registry.entries` is ignored (contributes nothing),
+ * matching the existing quorum consumer's own trust boundary: only DIDs the
+ * registry itself vouches for should ever count toward quorum. That
+ * boundary is `reviews: true` specifically, not "any real entry" -- a
+ * `fixes: true, reviews: false` entry (Brian in the worked example above)
+ * is a real, vouched-for registry entry, but not a DESIGNATED reviewer;
+ * his approval must contribute nothing toward quorum, same as a DID absent
+ * from the registry entirely (review-loop P9/P10 finding: this filter was
+ * missing, so a fixes-only agent's self-signed approve verdict silently
+ * counted).
+ */
+function countDistinctApprovers(registry, approvedDids) {
+    const loginByDid = new Map(registry.entries.filter((e) => e.reviews).map((e) => [e.agentDid, e.githubLogin]));
+    const distinctLogins = new Set();
+    for (const did of approvedDids) {
+        const login = loginByDid.get(did);
+        if (login) {
+            distinctLogins.add(login);
+        }
+    }
+    return distinctLogins.size;
+}
+/**
+ * Whether `agentDid` belongs to a `reviews: true` entry in `registry` -- a
+ * DESIGNATED reviewer, not merely an org-scoped agent whose verdict a hub
+ * happened to count. `data.counted` on a `review_verdict` hub event
+ * (`packages/compute/src/didcomm/hub.ts`'s `handleReviewVerdict`) proves
+ * shape + org-scope + signature + tenant/head match -- it does NOT check
+ * registry membership; that filter previously existed only inside
+ * {@link countDistinctApprovers}, scoped to the separate
+ * `pr_quorum_reached` path. Both `review-publisher.ts` and
+ * `fix-dispatcher.ts` (review-loop P9/P10) apply this SAME check
+ * independently before acting on a `review_verdict` event, so it lives here
+ * once rather than being copy-pasted into each consumer.
+ */
+function isDesignatedReviewer(registry, agentDid) {
+    return registry.entries.some((e) => e.reviews && e.agentDid === agentDid);
+}