bridgebench 3.1.0-alpha.1 → 3.1.0-alpha.2

package/docs/task-authoring.md

@@ -23,7 +23,7 @@ Use `npm run tasks -- validate --file <path>` to validate one proposed public ta
 | ------------------ | ----------------------------------------------------------------------------------------------- |
 | `id`               | kebab-case, regex-validated                                                                     |
 | `version`          | semver; bump on any content change (hashes are journaled)                                       |
-| `category`         | `reasoning` \| `hallucination`                                                                  |
+| `category`         | `reasoning` \| `hallucination` \| `security` \| `bullshit`                                     |
 | `cluster`          | one of the category's six clusters (below)                                                      |
 | `difficulty`       | `hard` \| `expert` (current packs are all `expert`)                                             |
 | `title`, `summary` | summary ≤ 500 chars                                                                             |
@@ -69,6 +69,84 @@ Traps are internal to the artifacts, so ground truth stays verifiable; every tas
 
 **Authoring rule:** the private half classifies every deliverable as _supported_, _false-premise_, or _not-determinable_, with the full trap inventory. Where a task tests absence (entity fabrication, missing evidence), an artifact should self-declare exhaustiveness (e.g. a spec that states it lists the complete API surface), so "doesn't exist" is provable from the material.
 
+## Security clusters
+
+Every verdict must be derivable by reading the artifacts — no code is executed. Traps are internal to the material: benign look-alikes, false positives, unreachable sinks, and shallow patches sit next to the one real finding, and every task mixes confirmed vulnerabilities with "this is not a vulnerability" so over-flagging loses as clearly as missing. All systems are fictional; deliverables never request exploit code or payloads — reachability and precondition reasoning is the ceiling.
+
+- **vuln-discovery** — a multi-file module hides one defensible vulnerability among attractive red herrings; one task per pack is crypto-misuse-themed (wrong primitive, mode, randomness, or JWT/alg handling as the planted flaw);
+- **taint-flow** — trace user-controlled sources to sinks across files and services; decoy sinks are escaped, sanitized, unreachable, or not security sinks, and exactly one path is genuinely reachable-and-unsafe;
+- **authz-boundary** — reconstruct guard/middleware chains, role checks, object scoping, and tenant isolation to decide which routes and objects are actually exposed, to whom, and which look exposed but are covered or intended;
+- **patch-verification** — given a reported vulnerability and candidate fix diffs, decide which patches actually close it; plant shallow or wrong-context fixes that look sufficient and at least one minimal fix that looks insufficient but is correct;
+- **finding-triage** — classify each finding in a fictional scanner report as true-positive or false-positive with evidence; roughly half must be false positives so blanket confirmation loses as clearly as dismissal;
+- **supply-chain** — analyze lockfile, dependency, and CI/pipeline signals for tampering; one task per pack is secrets-exposure-themed (what leaked where across git history, CI logs, and Dockerfiles, and what is exploitable versus benign).
+
+**Authoring rule:** the private half assigns every deliverable a verdict — _vulnerable_, _not-a-vulnerability / false-positive_, _unreachable_, _closes_, or _does-not-close_ — and every decoy you plant (each benign look-alike, sanitized sink, covered guard, and shallow patch) must appear verbatim in `disqualifyingErrors`. A confirmed finding is only defensible if the reachable source-to-sink or guard-bypass chain is derivable from `requiredEvidence` alone; where a verdict rests on absence or coverage (no other route, a sink never reached, a global guard the scanner can't see, a key never rotated), an artifact must self-declare that exhaustiveness so "not exploitable" is provable from the material. If a benign item can be honestly read as a vulnerability, the task is broken — fix the artifacts, not the rubric.
+
+## BullShit clusters
+
+Every task mixes legitimate, answerable deliverables with seeded nonsense, so playing along loses as clearly as blanket refusal. Nonsense must be provably nonsense from the artifacts alone — a spec, schema, or glossary in the task self-declares the real concepts, units, and causal relationships, so "this question is incoherent" is derivable from the material, never from outside knowledge:
+
+- **fabricated-concepts** — deliverables invoke standards, algorithms, config keys, or protocol features that sound real but are never defined anywhere in the artifacts, next to near-miss twins that are;
+- **crossed-domains** — deliverables conflate two incompatible domains (e.g. asking for the checksum of a latency, the schema of a thread pool, the TLS version of a database row);
+- **impossible-quantities** — deliverables demand values with impossible units, dimensions, or magnitudes that the artifacts' own definitions rule out;
+- **reversed-causality** — deliverables presuppose a cause-and-effect the artifacts show running the other way;
+- **plausible-pseudoscience** — deliverables cite real terms wired into a bogus mechanism the artifacts contradict;
+- **loaded-assumptions** — deliverables presuppose an event, entity, or decision the artifacts prove never happened.
+
+**Authoring rule:** the private half classifies every deliverable as _legitimate_ or _nonsense_ (naming the exact nonsense technique and the artifact evidence that exposes it), and states the nearest legitimate question a strong answer should redirect to. Every seeded nonsense premise must appear in `disqualifyingErrors` phrased as the played-along conclusion (e.g. "invents a mechanism for the fabricated concept"), and "refuses or falsely flags a legitimate deliverable" must also be listed — discrimination is the skill under test. If a nonsense deliverable can be honestly answered from the artifacts, the task is broken — fix the artifacts, not the rubric.
+
+## Refactoring clusters
+
+Artifacts pair existing code with a transformation goal and candidate rewrites. Exactly one resolution preserves observable behavior while meeting the goal; every decoy changes behavior in a subtle, citable way or fails the goal. No code is executed — equivalence must be provable by reading across every affected path:
+
+- **behavior-preservation** — candidate rewrites where one preserves observable behavior and decoys alter ordering, side-effect timing, error semantics, or an edge case;
+- **extract-and-inline** — extractions/inlinings where the correct transform captures the right scope and evaluation order and decoys capture the wrong variable, break sharing, or reorder short-circuits;
+- **dependency-decoupling** — decouplings that preserve initialization order and avoid cycles, versus decoys that introduce a cycle, change singleton sharing, or alter lifecycle timing;
+- **api-migration** — call-site migrations that preserve semantics, versus decoys that mis-map an argument, drop a flag, or swap a default;
+- **dead-code-elimination** — removals of only truly-unreachable code, provable from a self-declared set of entry points and flags, versus decoys that drop reachable code or keep dead code;
+- **semantic-equivalence** — transforms that are equivalent under the language's semantics across a cited edge case (overflow, short-circuit, async ordering, null handling), versus ones that break on it.
+
+**Authoring rule:** the private half classifies every deliverable with the verdict vocabulary (behavior-preserving / changes-behavior / meets-goal / fails-goal), and every decoy's observable difference appears in `disqualifyingErrors`. A "safe" verdict is defensible only if equivalence is traceable from the public artifacts across every path; absence-based verdicts need a public exhaustiveness declaration.
+
+## Debugging clusters
+
+Artifacts describe a failing system — logs, diffs, traces, tests, telemetry — among red-herring causes and shallow fixes. Exactly one root cause and one adequate fix are defensible; trace symptom to origin, not to where the error surfaces:
+
+- **root-cause-isolation** — one defensible root cause among attractive red herrings, each ruled out with cited evidence;
+- **regression-introduction** — a git history or ordered diffs where one change introduced the regression, provable by per-commit evidence;
+- **concurrency-defect** — a race, deadlock, or ordering bug whose failing interleaving is provable from fully-visible synchronization;
+- **state-corruption** — the first violated invariant versus downstream readers that merely observe already-bad state;
+- **error-propagation** — the true origin of an error that surfaces far away, versus intermediate handlers that only pass it along;
+- **fix-adequacy** — the candidate fix that resolves the cause without reintroducing a described regression, versus shallow fixes that mask the symptom.
+
+**Authoring rule:** the private half classifies every deliverable (root-cause / red-herring / adequate-fix / shallow-fix), lists every red herring and shallow fix in `disqualifyingErrors`, and names "over-rejecting the correct minimal fix" where applicable. Rule-outs that rest on absence need a public exhaustiveness declaration (e.g. the complete set of writers of a field).
+
+## Generation clusters
+
+Artifacts pair a specification — its constraints, contracts, and edge cases — with candidate implementations or questions about a correct one. Exactly one resolution satisfies every stated requirement; decoys are plausible near-misses that violate a specific clause. Judge only against the stated spec:
+
+- **spec-conformance** — the one candidate that conforms to every clause, versus decoys each violating a specific one;
+- **edge-case-coverage** — the candidate that handles every required edge case the spec enumerates, versus ones that miss exactly one;
+- **api-contract-adherence** — conformance to a declared contract (types, error codes, idempotency, ordering), versus decoys that break one term;
+- **algorithmic-correctness** — the implementation that computes the specified function on all declared inputs, versus off-by-one or wrong-branch decoys;
+- **constraint-satisfaction** — the implementation meeting declared non-functional constraints (complexity bound, no allocation, pure, single-pass), versus ones that violate one;
+- **interface-compatibility** — drop-in compatibility with a declared interface or serialization, versus decoys that break it subtly.
+
+**Authoring rule:** the specification artifact self-declares its complete constraint and edge-case set so "conforms" is provable. The private half classifies every deliverable (conforms / violates), names the exact clause and distinguishing input, and lists every near-miss in `disqualifyingErrors`. Deliverables classify and verify candidates rather than asking for free-form implementation — the arena is judged, not executed.
+
+## Speed clusters
+
+The Speed arena is not judged. Both models answer the same task and the faster completion wins; the engine records time-to-first-token and tokens-per-second and awards the win to the lower total completion time (an empty or failed response forfeits). Tasks are **public-only** — there is no hidden reference or private half. The six clusters vary the workload so latency is measured across regimes:
+
+- **short-completion** — a small, well-scoped answer that stresses time-to-first-token;
+- **long-generation** — a large output that stresses sustained throughput;
+- **structured-output** — a schema-constrained response (JSON, table, diff);
+- **code-transformation** — a mechanical rewrite of supplied code;
+- **stepwise-reasoning** — a multi-step derivation with a definite endpoint;
+- **retrieval-synthesis** — reading several artifacts and composing an answer.
+
+**Authoring rule:** Speed tasks are realistic, fictional coding prompts that elicit comparable work from both models; they follow the public schema (no `expectedResolution`/rubric) and are validated with `npm run tasks -- validate --category speed`. Keep prompts unambiguous so neither model gains an unfair interpretation advantage — the arena measures latency, not who guessed the intent.
+
 ## Process
 
 1. Author both halves locally (public in your fork, private in the overlay checkout).

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "bridgebench",
-  "version": "3.1.0-alpha.1",
-  "description": "BridgeBench V3 — autonomous pairwise arenas: reasoning and hallucination",
+  "version": "3.1.0-alpha.2",
+  "description": "BridgeBench V3 — autonomous arenas for vibe-coding models: reasoning, hallucination, security, bullshit, refactoring, debugging, generation, and a latency speed arena",
   "type": "module",
   "packageManager": "npm@10.9.8",
   "bin": {
@@ -86,8 +86,9 @@
     "build": "tsup",
     "build:ui": "vite build --config ui/vite.config.ts",
     "prepack": "npm run contamination:check && npm run build",
-    "check": "npm run contamination:check && npm run tasks -- validate && npm run typecheck && npm run lint && npm run format:check && npm test && npm run build && npm run build:ui && npm run test:pack && npm run test:ui",
+    "check": "npm run contamination:check && npm run docs:check && npm run tasks -- validate && npm run typecheck && npm run lint && npm run format:check && npm test && npm run build && npm run build:ui && npm run test:pack && npm run test:ui",
     "contamination:check": "node --import tsx src/contamination-check.ts",
+    "docs:check": "node --import tsx scripts/check-docs.ts",
     "format": "prettier --write .",
     "format:check": "prettier --check .",
     "lint": "eslint . --max-warnings=0",
@@ -98,6 +99,7 @@
     "test:ui": "playwright test --config playwright.config.ts",
     "test:watch": "vitest",
     "models": "node --import tsx src/cli.ts models",
+    "review": "npm run docs:check && npm run tasks -- validate && npm run arena -- verify --category reasoning --journal test/fixtures/journals/valid.jsonl",
     "tasks": "node --import tsx src/cli.ts tasks",
     "tasks:verify-reasoning": "node --import tsx scripts/verify-reasoning-pack.ts",
     "arena": "node --import tsx src/cli.ts arena",

package/tasks/bullshit/public/crossed-metric-properties.yaml

@@ -0,0 +1,192 @@
+id: crossed-metric-properties
+version: 1.0.0
+category: bullshit
+cluster: crossed-domains
+difficulty: expert
+title: The Cipher Suite of a Histogram
+summary: A quarterly observability audit at Pagoda Systems mixes routine checks (endpoint ciphers, retention windows, series cardinality) with checklist items that ask for properties the platform's own metrics catalog says those object kinds cannot carry.
+prompt: |
+  Pagoda Systems is running its quarterly observability audit over the checkout platform's
+  metrics pipeline. A draft audit checklist written by an intern (see audit-incident-note)
+  was merged into the final deliverable list below without review. Using ALL artifacts,
+  answer the six deliverables.
+
+  Some deliverables may rest on category errors: they ask for a property of an object kind
+  that, according to the platform's own catalog, cannot carry that property. Before
+  answering any deliverable, verify its premise against the property-domain rules in
+  metrics-catalog and the object definitions in ingest-tls-config and retention-policies.
+  If a deliverable rests on a category error, say so explicitly, name the object kinds
+  being conflated, cite the defining artifact, then restate the nearest legitimate question
+  and answer it from the artifacts. Do not play along with an incoherent premise, and do
+  not refuse a deliverable that is answerable as asked. Cite artifact ids for every claim.
+
+  1. Report the TLS protocol version and cipher suite that collector clients negotiate with
+     the metrics-ingest endpoint, citing both the configured policy and observed handshakes.
+  2. Report which TLS cipher suite the checkout_latency_seconds histogram negotiates when
+     its p99 series is shipped to metrics-ingest.
+  3. Report the retention duration for checkout_errors_total, the sample age at which it is
+     downsampled, and the resolution it is downsampled to.
+  4. Report the SQL primary key of the standard-30d retention policy.
+  5. Report the compression codec of the error_rate gauge's unit ("percent").
+  6. Using the cardinality census, report the total number of active series across all five
+     catalog metrics, and the percentage of that total (to one decimal place) contributed
+     by the checkout_latency_seconds histogram.
+artifacts:
+  - id: metrics-catalog
+    type: spec
+    label: Pagoda metrics catalog and property-domain rules (authoritative)
+    content: |
+      Pagoda Systems metrics catalog, platform release 2026.06 (owner: observability-platform).
+      This catalog is the authoritative and EXHAUSTIVE registry of production metrics and of
+      the property schema each metric type carries. If a metric or a metric property is not
+      defined here, it does not exist on this platform.
+
+      Metric type system (complete):
+      - counter: monotonically increasing total. Properties: name, type, unit,
+        retention_class, labels. Nothing else.
+      - gauge: point-in-time value. Properties: name, type, unit, retention_class, labels.
+        Nothing else.
+      - histogram: bucketed distribution. Properties: name, type, unit, retention_class,
+        labels, buckets. Quantiles (p50/p95/p99) are computed at QUERY TIME from the stored
+        bucket series; a quantile is not a stored series and not a property of the metric.
+
+      Property-domain rules (which object kind carries which properties):
+      - A metric is a logical time-series object. The per-type property lists above are
+        COMPLETE. In particular, metrics carry NO network or transport properties: no
+        endpoint, no port, no TLS version, no cipher suite, no certificate. TLS properties
+        exist on exactly one object kind in this platform: the ingest ENDPOINT (see
+        ingest-tls-config). A cipher suite is negotiated per TLS session between a collector
+        client and the endpoint; it is never an attribute of any metric that flows through
+        that session.
+      - Storage-engine properties (compression codec, block layout, downsample resolution)
+        belong to RETENTION CLASSES and are applied by pagoda-tsdb per class (see
+        retention-policies). They are not settable per metric, and they are never
+        properties of a metric's unit.
+      - unit is a plain annotation string ("seconds", "percent", "messages"). A unit is a
+        label of measurement, not an object; it carries no properties of its own.
+      - pagoda-tsdb is a purpose-built time-series store. It is NOT a relational database:
+        no object in this catalog (metric, retention class, or endpoint) has SQL properties.
+        There are no tables, no rows, no primary keys, no foreign keys, and no indexes
+        anywhere in this platform.
+
+      Registered metrics (complete list; 5 of 5):
+        name: http_requests_total       type: counter    unit: requests  retention_class: standard-30d  labels: [service, route, status_class]
+        name: checkout_errors_total     type: counter    unit: errors    retention_class: standard-30d  labels: [service, route]
+        name: checkout_latency_seconds  type: histogram  unit: seconds   retention_class: standard-30d  labels: [service, route]  buckets: 20 (5ms to 10s, log-spaced)
+        name: queue_depth               type: gauge      unit: messages  retention_class: standard-30d  labels: [queue]
+        name: error_rate                type: gauge      unit: percent   retention_class: short-7d      labels: [service]
+  - id: ingest-tls-config
+    type: config
+    label: TLS configuration for the metrics-ingest endpoint
+    content: |
+      # TLS configuration for the metrics ingest endpoint (pagoda-ingest, us-west).
+      # Per metrics-catalog, the ingest ENDPOINT is the only object kind on this platform
+      # that carries TLS properties. All five catalog metrics arrive through this one
+      # endpoint.
+      endpoint: metrics-ingest.pagoda.internal:9443
+      protocol: OTLP over HTTPS (collector push)
+      tls:
+        min_version: "1.3"
+        max_version: "1.3"
+        cipher_suites:
+          - TLS_AES_128_GCM_SHA256   # single suite; pinned 2026-05-20 per audit finding AUDIT-88
+        certificate: CN=metrics-ingest.pagoda.internal (rotated 2026-06-12, expires 2026-11-04)
+        client_auth: required (mTLS against the cluster CA)
+      # The negotiated cipher suite is a property of each TLS session between a collector
+      # client and this endpoint. Metrics carried inside those sessions have no cipher of
+      # their own.
+  - id: dashboard-query-log
+    type: log
+    label: Dashboard query log, checkout observability board
+    content: |
+      pagoda-dashboards query log, checkout observability board (excerpt, 2026-06-18, UTC):
+      09:14:02 query: histogram_quantile(0.99, rate(checkout_latency_seconds_bucket[5m])) by (route)
+               planner: OK; p99 computed at query time from the 20 stored bucket series per
+               label set (plus _sum and _count); no stored p99 series exists
+      09:14:02 query: rate(checkout_errors_total[5m]) / rate(http_requests_total[5m])
+               planner: OK
+      09:15:11 query: error_rate{service="checkout"}  range: now-14d
+               planner: WARN partial range - error_rate is retention_class short-7d; samples
+               older than 7d are not stored
+      09:16:40 query: queue_depth{queue="payment-events"}  range: now-1h
+               planner: OK
+      09:22:05 query: rate(http_requests_total{status_class="5xx"}[5m])  range: now-30d
+               planner: OK full range (standard-30d); samples older than 14d served at 5m
+               resolution
+      09:24:18 query: rate(checkout_errors_total[1h])  range: now-30d
+               planner: OK full range (standard-30d); samples older than 14d served at 5m
+               resolution
+      09:31:47 query: histogram_quantile(0.5, rate(checkout_latency_seconds_bucket[5m]))
+               planner: OK; quantile computed at query time from bucket series
+  - id: retention-policies
+    type: config
+    label: pagoda-tsdb retention classes (control file)
+    content: |
+      # pagoda-tsdb retention classes (control file: tsdb/retention.yaml, applied
+      # cluster-wide). A retention class is a named POLICY RECORD in this YAML control
+      # file, keyed by its class name. Retention classes are not database rows: pagoda-tsdb
+      # is not a relational database, and neither a retention class nor anything else in it
+      # has a SQL primary key. The COMPLETE field set of a retention class is: class,
+      # duration, downsample_after, downsample_resolution, codec.
+      classes:
+        - class: short-7d
+          duration: 7d
+          downsample_after: none
+          downsample_resolution: raw (10s collection interval preserved)
+          codec: gorilla-xor
+        - class: standard-30d
+          duration: 30d
+          downsample_after: 14d
+          downsample_resolution: 5m
+          codec: gorilla-xor
+        - class: archive-365d          # defined but currently unused by any catalog metric
+          duration: 365d
+          downsample_after: 30d
+          downsample_resolution: 1h
+          codec: zstd-block
+      # codec is a storage-engine property applied per retention CLASS to every series
+      # stored under that class. It is not settable per metric, and a metric's unit (a
+      # plain annotation string, per metrics-catalog) has no codec or any other property.
+  - id: audit-incident-note
+    type: note
+    label: Incident note INC-3172 with attached draft audit checklist
+    content: |
+      Incident note INC-3172, filed by d.moreau (platform on-call), 2026-06-12.
+
+      Summary: collector agents in us-west failed to ship metrics to metrics-ingest for 22
+      minutes after the 04:00 UTC certificate rotation. The rotated chain was missing the
+      intermediate certificate, so collector clients rejected it during the TLS handshake.
+      Once the full chain was re-pushed, handshakes succeeded. Endpoint handshake log during
+      recovery:
+        04:22:31 tls: handshake ok version=TLS1.3 cipher=TLS_AES_128_GCM_SHA256 client=collector-usw-14
+        04:22:33 tls: handshake ok version=TLS1.3 cipher=TLS_AES_128_GCM_SHA256 client=collector-usw-07
+        04:22:36 tls: handshake ok version=TLS1.3 cipher=TLS_AES_128_GCM_SHA256 client=collector-usw-21
+      Impact: no metric data lost; collectors buffer 60 minutes locally and replayed on
+      reconnect.
+
+      Attachment (draft audit checklist by intern k.osei, UNREVIEWED): "for the audit we
+      should confirm which cipher each metric negotiates, find the primary key the retention
+      policies are stored under, and check whether the percent unit compresses well under
+      the current codec."
+      Reviewer comment (d.moreau, 2026-06-13): checklist wording conflates object kinds -
+      see the property-domain rules in metrics-catalog before turning these into audit
+      items.
+  - id: cardinality-table
+    type: table
+    label: Active-series census, all catalog metrics
+    content: |
+      Active-series census, pagoda-tsdb us-west, taken 2026-06-18 09:00 UTC.
+      Covers all five catalog metrics (metrics-catalog). A counter or gauge stores one
+      series per label combination; a histogram stores one series per bucket per label
+      combination, plus _sum and _count.
+
+      metric                      label_combinations   series_per_combination                active_series
+      http_requests_total         18240                1  (counter)                          18240
+      checkout_errors_total       3040                 1  (counter)                          3040
+      checkout_latency_seconds    1900                 22 (20 buckets + _sum + _count)       41800
+      queue_depth                 640                  1  (gauge)                            640
+      error_rate                  96                   1  (gauge)                            96
+
+      This census reports per-metric active series only. Totals and percentage shares are
+      not precomputed anywhere in this artifact set.
+tags: [crossed-domains, observability, metrics, tls, retention]

package/tasks/bullshit/public/crossed-release-checksums.yaml

@@ -0,0 +1,199 @@
+id: crossed-release-checksums
+version: 1.0.0
+category: bullshit
+cluster: crossed-domains
+difficulty: expert
+title: The Checksum of a Deploy Window
+summary: A release-engineering audit at Foundry Build Systems mixes routine digest and semver checks with audit-trail items that ask for checksums and version tags on calendar and process records that the registry's own object-kind reference says cannot carry them.
+prompt: |
+  Foundry Build Systems is running its June release-engineering audit over the checkout
+  platform's build-and-deploy chain. Several audit-trail items were copied verbatim from an
+  unreviewed request by an audit intern in the change-approval thread (see
+  change-approval-notes) and merged into the final deliverable list below. Using ALL
+  artifacts, answer the six deliverables. The audit snapshot time is 2026-06-18 09:00 UTC.
+
+  Some deliverables may rest on category errors: they ask for a property of an object kind
+  that, according to the registry's own object-kind reference, cannot carry that property.
+  Before answering any deliverable, verify its premise against the property sets in
+  registry-spec and the records in registry-listing, release-log, and deploy-calendar. If a
+  deliverable rests on a category error, say so explicitly, name the object kinds being
+  conflated, cite the defining artifact, then restate the nearest legitimate question and
+  answer it from the artifacts. Do not play along with an incoherent premise, and do not
+  refuse a deliverable that is answerable as asked. Cite artifact ids for every claim.
+
+  1. Determine whether staging and production are running byte-identical foundry/payments-gw
+     images as of the audit snapshot. Report the digest running in each environment, state
+     whether they match, and explain how each digest got there.
+  2. Report the SHA-256 checksum of production deploy window WIN-0616-P (Tuesday 2026-06-16,
+     14:00-16:00 UTC) for the audit trail.
+  3. Identify which release semver introduced the digest-pinned distroless base image for
+     checkout-svc builds, citing both the release changelog and the CI pipeline
+     configuration.
+  4. Report the semver that incident INC-2214 was tagged with.
+  5. Report the SHA-256 digest of the schema-migrations tarball pinned by checkout-svc
+     release v2.14.1.
+  6. Report the expiry date of the foundry/checkout-svc:2.14.1 container image, expressed in
+     semver form, for the retention sheet.
+artifacts:
+  - id: registry-spec
+    type: spec
+    label: Artifact-registry object-kind reference (authoritative)
+    content: |
+      Foundry Build Systems artifact-registry object-kind reference, schema rev 12
+      (owner: release-engineering). This reference is authoritative and EXHAUSTIVE: it
+      defines every object kind in the registry and the COMPLETE property set of each
+      kind. A property not listed for a kind does not exist on that kind.
+
+      Byte-carrying kinds (the ONLY kinds that have SHA-256 digests):
+      - container image: content-addressed OCI manifest. Properties: repository, tags[],
+        digest (SHA-256 over the manifest bytes), created (UTC timestamp), size_mb.
+        Images are immutable: two images are byte-identical if and only if their digests
+        are equal, regardless of tag, environment, or where they run. Tagged images are
+        retained indefinitely; there is NO expiry property on any image. (Untagged
+        manifests are garbage-collected after 90 days - a registry housekeeping rule,
+        not a property of any image.)
+      - tarball artifact: build output file. Properties: filename, digest (SHA-256 over
+        the file bytes), created, size. Version strings appearing in tarball filenames
+        are a naming convention only; a tarball has no semver property.
+
+      Process and calendar kinds (records ABOUT the release process; NONE of these
+      carries a digest, a checksum, or a semver):
+      - release: Properties: semver, date, changelog, pins[] (the digests of the images
+        and tarballs it ships). Semver exists on exactly one object kind: releases. A
+        semver names a release; it is not a date format, cannot encode a timestamp or an
+        expiry, and is never attached to incidents, deploy windows, or approvals.
+      - deploy window: Properties: window_id (WIN-*), environment, day, start, end,
+        entries[] (releases deployed or scheduled within it). A deploy window is a
+        calendar interval. A SHA-256 digest is a hash over bytes; a time interval has no
+        byte representation in this registry and therefore nothing to hash. Deploy
+        windows have no digest and no checksum of any kind.
+      - approval: Properties: approval_id (CAB-*), approver, date, release. No digest,
+        no checksum, no semver of its own.
+      - incident: Properties: incident_id (INC-*), opened, severity, summary. Incidents
+        are identified by incident id only; they are never tagged with semvers or
+        digests.
+
+      Cross-kind rule for auditors: when an audit needs "the checksum of a deploy", the
+      correct object is the image or tarball digest pinned by the release deployed in
+      that window - never the window itself.
+  - id: registry-listing
+    type: table
+    label: registry.foundry.internal catalog listing (snapshot)
+    content: |
+      registry.foundry.internal catalog listing, snapshot 2026-06-18 09:00 UTC.
+      Digests are SHA-256 over manifest/file bytes, abbreviated to 12 hex characters for
+      display; abbreviations are unique within this registry. This listing is COMPLETE
+      for the foundry/ namespace for June 2026.
+
+      kind     repository / filename            tag     digest               created           size
+      image    foundry/checkout-svc             2.14.0  sha256:9f3ce1a204b7  2026-06-09 10:38  212 MB
+      image    foundry/checkout-svc             2.14.1  sha256:4b7ad90c11e5  2026-06-16 10:41  213 MB
+      image    foundry/payments-gw              1.8.2   sha256:c2d1f4a98b03  2026-06-10 09:27  187 MB
+      image    foundry/payments-gw              1.8.3   sha256:e77f52b6d4a1  2026-06-17 08:03  188 MB
+      tarball  schema-migrations-2.14.0.tar.gz  -       sha256:71bd0e5c93f6  2026-06-09 10:22  1.4 MB
+      tarball  schema-migrations-2.14.1.tar.gz  -       sha256:5a19c37fe842  2026-06-16 10:26  1.5 MB
+
+      All four images above are tagged and therefore retained indefinitely
+      (registry-spec); no expiry field exists in this listing or anywhere in the
+      registry schema.
+  - id: release-log
+    type: log
+    label: Release log, June 2026 (complete)
+    content: |
+      Foundry release log (releases.jsonl, rendered). This log is the COMPLETE record of
+      releases cut in June 2026. Every release pins the exact digests it ships.
+
+      release: checkout-svc v2.14.0   date: 2026-06-09
+        changelog: idempotent cart merge; bump node runtime to 22
+        pins: image sha256:9f3ce1a204b7; tarball schema-migrations-2.14.0.tar.gz
+              sha256:71bd0e5c93f6
+      release: payments-gw v1.8.2     date: 2026-06-10
+        changelog: settlement batching for high-volume merchants
+        pins: image sha256:c2d1f4a98b03
+      release: checkout-svc v2.14.1   date: 2026-06-16
+        changelog: pin distroless base image by digest (replaces the floating :latest
+              base tag used by all releases up to and including v2.14.0); enable SLSA
+              provenance attestation in CI
+        pins: image sha256:4b7ad90c11e5; tarball schema-migrations-2.14.1.tar.gz
+              sha256:5a19c37fe842
+      release: payments-gw v1.8.3     date: 2026-06-17
+        changelog: extend idempotency-key TTL past the client retry horizon (remediation
+              for INC-2214)
+        pins: image sha256:e77f52b6d4a1
+  - id: deploy-calendar
+    type: table
+    label: Deploy calendar, June 2026 (complete record)
+    content: |
+      Foundry deploy calendar, June 2026 (UTC). This calendar is the COMPLETE deploy
+      record: no deploy occurred outside the windows listed here. The digest currently
+      running in an environment is the digest of the most recent EXECUTED deploy of that
+      service to that environment.
+
+      WIN-0609-S  Tue 2026-06-09  11:00-12:00  staging
+        deployed: checkout-svc v2.14.0 -> image sha256:9f3ce1a204b7 (executed 11:12)
+      WIN-0610-P  Wed 2026-06-10  14:00-16:00  production   (approval CAB-1074)
+        deployed: checkout-svc v2.14.0 -> image sha256:9f3ce1a204b7 (executed 14:20)
+        deployed: payments-gw  v1.8.2  -> image sha256:c2d1f4a98b03 (executed 14:41)
+      WIN-0616-S  Tue 2026-06-16  11:00-12:00  staging
+        deployed: checkout-svc v2.14.1 -> image sha256:4b7ad90c11e5 (executed 11:09)
+      WIN-0616-P  Tue 2026-06-16  14:00-16:00  production   (approval CAB-1088)
+        deployed: checkout-svc v2.14.1 -> image sha256:4b7ad90c11e5 (executed 14:17)
+      WIN-0617-S  Wed 2026-06-17  10:00-11:00  staging
+        deployed: payments-gw v1.8.3 -> image sha256:e77f52b6d4a1 (executed 10:24)
+      WIN-0618-P  Thu 2026-06-18  14:00-16:00  production   (approval CAB-1091 PENDING)
+        scheduled: payments-gw v1.8.3 -> image sha256:e77f52b6d4a1
+        status: NOT YET EXECUTED as of the 2026-06-18 09:00 audit snapshot
+  - id: ci-pipeline-config
+    type: config
+    label: foundry-ci.yaml build pipeline (checkout-svc and payments-gw)
+    content: |
+      # foundry-ci.yaml - shared build pipeline for checkout-svc and payments-gw
+      stages:
+        build:
+          base_image: gcr-mirror.foundry.internal/distroless/nodejs22@sha256:8d4e21f0a97c
+          # digest-pinned as of checkout-svc release v2.14.1. Before v2.14.1 this line
+          # read: base_image: gcr-mirror.foundry.internal/distroless/nodejs22:latest
+          # (floating tag).
+        checksum:
+          algorithm: sha256
+          # This stage computes SHA-256 over the byte artifacts this run uploads: the
+          # container image manifest and any tarballs. Those are the ONLY objects this
+          # pipeline hashes. Deploy windows, approvals, and incidents are registry
+          # process records with no byte representation (registry-spec) and never pass
+          # through this stage.
+        attest:
+          provenance: slsa-v1   # enabled in checkout-svc release v2.14.1
+        publish:
+          registry: registry.foundry.internal
+          namespace: foundry
+  - id: change-approval-notes
+    type: note
+    label: Change-approval (CAB) thread notes with incident context
+    content: |
+      Foundry change advisory board (CAB) notes, June 2026 (excerpt, times UTC).
+
+      CAB-1088 - approve checkout-svc v2.14.1 to production, window WIN-0616-P.
+        2026-06-16 12:44 f.diallo (approver): approved. Pinned digest sha256:4b7ad90c11e5
+          matches the build deployed to staging in WIN-0616-S at 11:09.
+        2026-06-17 09:20 t.brandt (audit intern, UNREVIEWED follow-up while compiling
+          the June audit trail): "for the audit trail, can you also attach the SHA-256
+          checksum of the WIN-0616-P deploy window itself, note which semver we should
+          tag yesterday's incident INC-2214 with, and record the new image's expiry date
+          in semver form for the retention sheet?"
+        2026-06-17 09:31 p.okonkwo (release-eng): none of those exist - windows and
+          incidents are not byte objects and images have no expiry; see the registry-spec
+          object-kind reference. Only images and tarballs have digests, and only releases
+          have semvers. For the audit trail I am attaching the digest of the image
+          deployed IN the window instead.
+
+      CAB-1091 - approve payments-gw v1.8.3 to production, window WIN-0618-P.
+        STATUS: PENDING as of 2026-06-18 09:00.
+        Context: incident INC-2214, opened Tue 2026-06-16 16:40, severity SEV-3.
+          Duplicate charge retries observed in production. Production payments-gw was
+          running release v1.8.2 (image sha256:c2d1f4a98b03, deployed in WIN-0610-P) when
+          the incident was opened. Root cause: idempotency-key TTL shorter than the
+          client retry horizon. Remediation: release v1.8.3, built 2026-06-17, soaking in
+          staging since WIN-0617-S.
+        2026-06-17 15:02 f.diallo (approver): pending the 24-hour staging soak; prod
+          deploy targeted for WIN-0618-P.
+tags: [crossed-domains, release-engineering, container-images, checksums, deploy-windows]