[bokelley]

#2907 has merged; this now targets main directly. Two commits, reporting only.

Implements the rc.3 consumer-status contract in the seller ledger. Everything is projected from immutable ledger facts, so it stays correct across snapshots, pagination, and repeated polls without a second state table.

rc.3 coverage matrix

rc.3 requirement	Implemented in	Tested by
content_mismatch + closed mismatch_code, schema conditional requirements	Bundle-derived Zod arms (#2911) activated by the rc.3 pin (#2907); conflict projection in health.ts projectReportingConsumerStatusMismatchV1	generate-zod-consumer-status-content-mismatch.test.js (schema-enumerated arms); …projection.test.js content_mismatch is a contract-fact disagreement and escalates immediately; …narrative.test.js content_mismatch round trip
… valid only against the currently required revision (expected_period)	status-ingest.ts validateStatus — resolves the sibling set via listRevisionMetadata (or listRevisions) and rejects a superseded target; a store that can do neither refuses content_mismatch rather than under-enforcing	reporting-status-ingest-pg.test.js rejects content_mismatch against a superseded revision — asserts the current-revision dispute records, the superseded one fails with the specific diagnostic, and a stale received is still accepted
Stale-received grace: delayed until first superseding revision created_at + delivery_sla	health.ts projectReportingConsumerStatusMismatchV1 → firstSupersedingRevision	…projection.test.js a received statement made stale by a restatement is delayed inside the window, the window is bounded; …narrative.test.js restatement → within grace … past grace …
Fallback to automated_recovery_window_seconds when the SLA is zero	same, slaMilliseconds > 0 ? … : recoveryWindowMilliseconds	…projection.test.js a zero delivery SLA falls back to the automated recovery window
Later restatements must not restart the window	anchored to the first supersession of the revision the buyer named	…projection.test.js later restatements do not restart the window
Escalation window takes precedence over grace	health.ts, !escalated && withinGrace	…projection.test.js the escalation boundary overrides an open grace window; …narrative.test.js an advertised escalation window forces a contact_* action past its boundary
Buyer posting deadline expected_at + automated_recovery_window_seconds	handler.ts, compared against obligation.recoveryDeadlineAt (producer.ts sets it to exactly that sum)	…narrative.test.js consumer_status_pending appears after the deadline
obligation_counts.consumer_status_pending, required on summary when consumer_status_task is advertised	handler.ts counts(healthValues, consumerStatusPending); emitted iff a consumer principal resolves	…narrative.test.js consumer_status_pending appears after the deadline and clears on any posted status — also validateResponsed against the rc.3 schema
… counted strictly after the deadline (the duty is "no later than")	handler.ts, compareReportingInstants(...) > 0	…narrative.test.js consumer_status_pending appears after the deadline
…never a health input; overlaps rather than partitions	computed independently of healthValues	same test asserts health unchanged, no issue created, and healthy+complete == total while pending is also 1
opened_at required on CONSUMER_STATUS_MISMATCH, stable across re-emission	health.ts, anchored to immutable ledger instants (later of first supersession and recorded_at), never ledgerAsOf; preserved across issue upsert in postgres.ts	…projection.test.js opened_at does not advance across re-emission, opened_at never predates the statement that caused the issue, the escalation clock runs from opened_at, not from the poll
issue_state, external_ref	types.ts ReportingIssueStateV1; handler.ts wireIssue; validated in reporting-status-response.ts	generate-zod-reporting-status.test.js …accepts the rc.3 consumer mismatch issue / …rejects an unanchored or unattributed consumer mismatch
consumer_mismatch_lifecycle retirement rules	handler.ts drops resolved/waived and never republishes a persisted CONSUMER_STATUS_MISMATCH; the projection recomputes from the current leaf, so a period cannot return to healthy while the causing statement is the leaf	…narrative.test.js content_mismatch round trip asserts it stays degraded a day later and clears only on supersession
operations_contact + consumer_mismatch_escalation_seconds advertisement	health.ts reportingConsumerStatusCapabilityV1 — projects the same option the handler enforces	…projection.test.js projects the wire fields from the same option the handler enforces, advertises nothing when no commitment is made, refuses to advertise a commitment the handler would not honor
recommended_action escalates to a contact_* value	health.ts consumerStatusMismatchAction	…projection.test.js escalation names the diagnosed party and retires repair_access
authoritative_party: accept seller, reject consumer with UNSUPPORTED_FEATURE at config install	producer.ts assertSupportedReportingAuthoritativeParty, called first in validateConfigurationAgainstOffering; exported from the package root	…projection.test.js consumer is refused with UNSUPPORTED_FEATURE rather than coerced, an explicit null is not treated as absence, a wrong-shaped argument is refused
Harness restate_after_received (within_grace | past_grace, convergent)	examples/reliable-reporting-lifecycle/index.js	see the deviation note below
Narrative: within_grace → delayed → past_grace → action_required → supersede with received on the new revision → healthy	handler.ts end to end	…narrative.test.js restatement → within grace is delayed, past grace is action_required, then received on the new revision is healthy again
consumer_status_pending clears on any posted status	handler.ts	…narrative.test.js — asserts a negative status clears pending while still conflicting

…projection.test.js = test/lib/reporting-consumer-status-projection.test.js; …narrative.test.js = test/lib/reporting-consumer-status-narrative.test.js.

One deviation, unchanged and still worth your eye

The harness op reports the grace boundary rather than moving a clock: PostgresReportingLedgerStore takes ledger_as_of from statement_timestamp(), and a test-only clock in a production read path would also disagree with snapshot expiry, which stays on clock_timestamp(). Instead NarrativeStore in the new narrative test is a minimal ReportingLedgerStore whose clock the test owns, so every transition above is graded against the live createReportingStatusHandler, not against the pure projection. That closes the gap I flagged earlier without putting a clock seam in the shipped store. Say the word if you'd still rather have the store seam.

What changed

content_mismatch

Wire validation landed with the bundle bump in #2907. Here it joins the conflict set: it degrades a healthy/complete caller-scoped projection like the other negative statuses and is immediately action_required. It is a contract-fact disagreement naming the exact bytes the consumer read — not a measurement dispute.

Stale-received grace

A received statement made stale only by a seller restatement is now delayed with wait_for_retry until a bounded re-read deadline, then action_required. Previously every conflict escalated instantly, which punished the buyer for the seller's own restatement.

The deadline is anchored to the created_at of the first revision superseding the one the buyer named, plus the generation's delivery_sla — falling back to automated_recovery_window_seconds when that SLA is zero, so a zero-SLA feed still gets a bounded window. Anchoring to the first supersession is what makes later restatements unable to restart the clock; otherwise a seller could hold an unresolved mismatch below action_required by restating on a timer. Test: later restatements do not restart the window.

Fail-closed detail worth a look: when no revision claims to supersede the one the buyer named, the SDK cannot prove the buyer read what the seller then required, so it escalates immediately rather than granting an unearned grace.

opened_at

Fixed at first emission and carried unchanged across re-emission, including across the delayed → action_required transition, which reuses one issue_id so consumers age one work item instead of two.

The design constraint here is subtle and I want it flagged for review: opened_at is derived from immutable ledger instants (the first superseding revision's created_at for a stale read, the statement's recorded_at otherwise), never from ledgerAsOf. Deriving it from the read time would reset the escalation clock on every poll — precisely the failure consumer_mismatch_escalation exists to prevent. Test: opened_at does not advance across re-emission and the escalation clock runs from opened_at, not from the poll.

Escalation

createReportingStatusHandler takes consumerMismatchEscalation (escalationSeconds + operationsContact), mirroring the capability block's both-or-neither rule. Past the boundary an open mismatch is action_required with a contact_* action naming the diagnosed party; wait_for_retry and repair_access are automation hints and neither survives. Escalation takes precedence over an open grace window.

obligation_counts.consumer_status_pending

Summary-view count of obligations past expected_at + automated_recovery_window_seconds with an empty chain for the caller — a chain with any unsuperseded leaf counts as current whatever it says. Computed independently of the health values so it cannot become a health input, and emitted only when a consumer principal is resolved, which is exactly when this handler advertises consumer_status_task.

Reserved authoritative_party

assertSupportedReportingAuthoritativeParty refuses 'consumer' with a typed UNSUPPORTED_FEATURE rather than coercing to 'seller' — coercion would install a different contract than the buyer asked for, and relaxing the billing implication for that value would let a buyer-authoritative billing feed through with no consumer receipt and no method. It runs first in installConfiguration so the buyer gets the capability answer instead of an incidental complaint about a field it would have had to change anyway. Exported for sync_accounts.

Response-boundary validator

opened_at + reporting_status_id required on CONSUMER_STATUS_MISMATCH; issue_state restricted to open / acknowledged (a retired issue leaves the projection rather than being published at resolved / waived, which keeps "nonempty issues[] means degraded" true for readers); external_ref bounded to inert non-dereferenceable text; consumer_status_pending bounded by total.

One deliberate deviation, please sanity-check it

The brief asked the harness's restate_after_received to grade within_grace | past_grace the way the comply controller does. The comply controller has a virtual clock; PostgresReportingLedgerStore takes ledger_as_of from statement_timestamp(). Making the live read grade both sides would mean injecting a test-only clock into a production read path — and ledger_as_of also participates in snapshot expiry, which stays on clock_timestamp(), so a skewed clock would put those two out of agreement.

So the harness op does the contract-bearing parts — binds the restatement to the revision the caller currently reports as received, refuses to restate into a vacuum, stays convergent on repeat, and returns stale_received_grace_deadline plus the project_at instant for each side — and both sides of the boundary are graded deterministically against projectReportingConsumerStatusMismatchV1, which is the same function the live handler calls. No wall-clock wait, no test-only clock in the store.

Say the word if you'd rather have the store clock seam and I'll add it.

Test-was-asserting-rc.2

test/generate-zod-reporting-status.test.js had current reporting-status guard accepts the rc.2 consumer mismatch issue, which asserted a CONSUMER_STATUS_MISMATCH with no opened_at and no reporting_status_id is valid. rc.3's reporting-status-issue.json allOf makes both required on that code, so the assertion is now wrong rather than the code. Per CLAUDE.md's triage order I checked the spec first — it is explicit — and moved the test to rc.3, adding a negative case for each newly-required and newly-constrained field.

27 new/updated tests. 120/120 pass across the reporting suite locally.

🤖 Generated with Claude Code

---

Open workspace in Conductor

[aao-secretariat]

Medium: consumer_status_pending ships with no test coverage. The new count computed here (empty caller-scoped chain past recoveryDeadlineAt), its summary wiring at handler.ts:333, and the wire-validation bound in reporting-status-response.ts:797 (> total rejection) are all new branches, and grep consumer_status_pending test/ returns nothing. Everything else in this PR is exhaustively covered (357-line projection suite); this advertised obligation-count field is the one path where a regression — wrong count, off-by-recovery-window, or a bound that never fires — lands silently on the summary view. Add a handler test asserting the count and a guard test for the > total rejection.

[aao-secretariat]

Ladon verdict: Approve

Approve — AdCP 3.2.0-rc.3 consumer-status hardening verifies cleanly.

Checked:

• Core projection logic: caller-scoped mismatch, immutable-fact openedAt/issueId, first-supersession grace anchor, escalation-over-grace precedence, and fail-closed authoritative_party refusal — all verified against the 357-line test suite.
• Type plumbing, caller-scoping, and wire-shape fidelity (witness-not-translator preserved; no fabrication or re-shaping at seams).
• Changeset present and correctly typed for the wire-impacting src/lib/** changes.

Medium findings (non-blocking):

• src/lib/utils/reporting-status-response.ts — the new consumer_status_pending obligation count and its > total wire-validation bound have no test coverage.

With a single medium finding and no critical/high findings, no gated paths, no team gate, and no escalation triggers, this falls through to row 9 (approve). The uncovered validation bound is worth a follow-up test but does not block.

[bokelley]

Review stack results — 5c1472a9

Ran the full REVIEW-STACKS.md dual stack: four Claude experts (protocol, code, security, DX) in parallel plus review:codex --all.

Codex was initially blocked — its sandbox needs bwrap, absent from this VM, so it read no files and returned "review blocked" for all three personas. I installed bubblewrap; the kernel still refuses the namespace (Unexpected capabilities but not setuid). Re-ran with the diff piped via stdin, which is the documented fallback, and got three real passes. Flagging because a blocked codex run reads like a clean one if you only look at the exit code.

Convergent — fixed

Finding	Stacks
Persisted CONSUMER_STATUS_MISMATCH leaks across consumers	security (H1)
Grace-window obligation unreachable under every health filter	code-reviewer (BLOCKER)
opened_at can predate the causing statement → issue born escalated	codex ×3, code-reviewer, protocol
Date.parse in grace/escalation arithmetic	codex ×2, code-reviewer, security
escalationSeconds unvalidated (NaN silently disables escalation)	codex, code-reviewer, DX, security
UnsupportedReportingFeatureError outside AdcpError → SERVICE_UNAVAILABLE/transient	DX (P2), protocol
Guard fails open on a wrong-shaped argument	DX (P3)
issueState: 'resolved' typechecks but publishes as open	DX (A1)

Two deserve calling out because neither is a lint-level nit:

The health-filter blocker was found by exactly one reviewer. PostgresReportingLedgerStore applies health while building the snapshot and carried its own copy of the mismatch rule hardcoding action_required. With rc.3's new delayed severity, a stale-received obligation in grace was excluded from the snapshot when you filtered for delayed, and dropped by the handler when you filtered for action_required — invisible under both, while still counted in pagination.total_count. The projection moved to ./health (which the handler and the store already both import) and the duplicate is deleted, so there is now one copy of the rule.

The cross-tenant leak is the one I'd most want a second opinion on. adcp_reporting_issues is keyed by obligation with no consumer dimension, but a CONSUMER_STATUS_MISMATCH is caller-scoped. The derived issue shadowed the persisted one only for the consumer who caused it — so every other consumer on that obligation kept getting the persisted copy, including the causing reporting_status_id, its opened_at (another tenant's exact ingest timing), and any external_ref ticket key. I took the cheap fix: never republish a persisted issue with that code, since the projection recomputes it per-caller anyway. The deeper fix — a consumer_id column on the issues table — is a migration I did not want to smuggle into this PR.

I verified the prototype-injection finding by running it rather than reasoning about it:

resolveTargetingInput(JSON.parse('{"__proto__":{"geo_regions":["INJECTED"]},"geo_countries":["US"]}'))
Object.keys(result)  -> ['geo_countries']
result.geo_regions   -> ['INJECTED']     ← invisible to every own-key check

Same for the codegen slice bug — the new four-repair test fails against the previous implementation and passes against the fix, so it's a real regression test rather than a restatement.

Not fixed, with reasons

• responsible_party can never be buyer, so contact_buyer is unreachable (protocol fix the a2a sdk client import issue #5). Correct, and the spec does say the seller assigns it from the diagnosed cause. But a diagnosis is a seller judgement the SDK cannot derive — the right shape is a diagnoseResponsibleParty? hook, which is a new public API. Worth doing; I didn't want to design it under review pressure.
• Ingest doesn't enforce the content_mismatch binding/currency MUSTs (protocol Rebrand to Ad Context Protocol and remove side navigation #4). Real gap: status-ingest.ts gates the binding check on received only, so a buyer can content_mismatch a superseded revision with a fabricated digest and pin its own view. Caller-scoped blast radius. Belongs with PR C, where I'm touching the buyer side of the same contract.
• Storyboard asserts root issues[]/health on a periods read (protocol Fix Fly.io deployment host/port configuration and add regression tests #8). Per CLAUDE.md's spec → mock → SDK order the response schema makes both optional on that view, so this looks like a storyboard bug to file upstream rather than an SDK change. I'd rather file it than bake storyboard opinion into the SDK.
• consumer_status_pending over-counts under changes_after for a custom store that populates only consumerStatuses (code-reviewer Fix agent configuration to use .env only approach #7, protocol Implement official MCP/A2A clients with HTTP streaming and UI improvements #6). Pre-existing fallback; the bundled store always populates the full projection. Wants an interface change.
• Migration guide has zero reporting coverage (DX A4) and the targeting null-clear semantics appear in no doc or skill (DX A5). Both fair. Docs-only, so I'd rather land them as a separate PR than expand this one.

One false positive, noted so it doesn't get re-raised: code-reviewer #6 says the changeset describes a restate_after_received harness op the PR doesn't contain. It does — in examples/reliable-reporting-lifecycle/index.js; the grep covered src/ test/ bin/ only.

Also

Rebased onto current main (#2909, #2910 landed). PR A's CI had silently stopped running because the PR had gone CONFLICTING — GitHub won't build a PR whose merge commit it can't compute, so the green checks on the old head were only the pull_request_target workflows. Both branches are rebased and the pipeline is running again. Package budget re-measured after the rebase: 6,059 files, 101.8 MiB unpacked.

🤖 Generated with Claude Code

[aao-secretariat]

Ladon verdict: Approve

Approve — AdCP 3.2.0-rc.3 consumer-status hardening.

No blocking findings. Reviewer verified: changeset shape (minor, additive — new exports/optional wire fields, no interface break); witness-not-translator holds (seller-side authority store, no fabrication); projection inputs carry required createdAt/supersedes fields; fail-closed grace/escalation logic keyed off immutable openedAt with exact bigint instant comparators; and full test coverage of every new branch.

One non-blocking Low (omitted from gate): handler.ts leaves an unused local instant function (no build impact).

Gate check: no critical/high/medium findings; gated_paths false (and review_decision APPROVED regardless); high_risk false; no no-auto-approve team match; prior decision was approve. Falls through to row 9 → approve.

[aao-secretariat]

Medium: This rc.3 example wires consumerMismatchEscalation into the handler only. PostgresReportingLedgerStore now takes the same option, and postgres.ts's own comment says why it must: the health filter runs while building the snapshot, before the handler projects. Configure escalation on the handler but not the store and the two disagree at exactly the boundary — a stale-received mismatch the handler escalates is still delayed to the store filter, so a periods read filtered health: ['action_required'] omits it from the snapshot and the handler never sees it. That is the same "unreachable under every filter" bug this PR fixes for the old hardcoded rule. The store constructor at REPORTING-LEDGER.md:21 should pass the same consumerMismatchEscalation object, or the guide should state that both must be configured identically.

[aao-secretariat]

Ladon verdict: Approve

Approve — rc.3 consumer-status hardening looks sound.

What I checked:

• Core projection, escalation-precedence, opened_at anchoring, and UNSUPPORTED_FEATURE error mapping are correct.
• Postgres jsonb_set / shared-filter changes preserve wire-shape fidelity (witness-not-translator honored).
• .changeset/reporting-rc3-consumer-status-hardening.md present for the src/lib/** changes — changeset-vs-wire-impact satisfied.
• No V1 contamination, no reimplemented transport, no fabricated fields.

Medium findings:

• src/lib/reporting/ledger/postgres.ts — the rc.3 guide wires consumerMismatchEscalation into the handler only; PostgresReportingLedgerStore should receive the same option or a filtered periods read may drop escalated obligations. Worth a follow-up but non-blocking.

Decision path: no critical/high findings; gated_paths false; high_risk false; review_decision APPROVED; no team gate; only 1 medium finding → falls through to row 9 (approve). Prior decision was also approve; this is a net-consistent result.

[aao-secretariat]

Ladon verdict: Approve

Approve — subsequent pass on rc.3 consumer-status hardening is clean.

No blocking findings. The reviewer re-reviewed the full diff (base c9dbdcd → head c6f51ea) and verified projection correctness in health.ts (opened_at anchoring, escalation-over-grace precedence, exact-instant comparison, fail-closed on unproven supersession), escalation option validation, postgres opened_at durability and health-filter unification, the cross-tenant leak fix, changeset correctness (minor/additive), and witness-not-translator compliance.

Gates checked: no no-auto-approve team match; gated_paths is false; review_decision is APPROVED; high_risk is false. Prior decision was approve, so no sticky escalation applies.

Only one Low non-blocking finding (dead unused instant() helper at handler.ts:553 duplicating health.ts) — Low findings are omitted from the gate and do not block.

Decision table: rows 1–8 do not fire (no critical/high/medium findings, no gate triggers), so this falls through to row 9 → approve.

Nit (non-blocking): consider removing the dead instant() helper at src/lib/reporting/ledger/handler.ts:553.

The base branch was changed.

[aao-secretariat]

Ladon verdict: Approve

Approve — rc.3 consumer-status hardening across the reporting ledger.

Checked:

• No no-auto-approve team match; gated_paths: false; high_risk: false.
• Reviewer verified grace/escalation math against instant.ts, confirmed the projection receives createdAt+supersedes so grace fires in production, and that opened_at anchors to immutable facts across all emitters.
• Cross-tenant leak fix and postgres health-filter/jsonb_set changes reviewed.
• Exports and changeset (minor) are correct — witness-not-translator and changeset-vs-wire-impact checks satisfied.
• Consistent with the prior clean approve; no new critical/high/medium findings.

No blocking or medium findings — falls through to row 9.

[aao-secretariat]

Ladon verdict: Approve

Approve — clean additive change, no blocking findings.

Checked:

• New reportingConsumerStatusCapabilityV1 (health.ts:91-104) projects the escalation commitment into the capability document (consumer_mismatch_escalation_seconds + operations_contact) through the same assertReportingConsumerMismatchEscalation gate the read handler uses, so advertised and enforced windows cannot drift — consistent with witness-not-translator posture.
• Changeset present and typed minor, matching the additive SDK-surface change under src/lib/**.
• Re-export via ledger index and unit + live-handler narrative/projection tests included.

No critical/high/medium findings. gated_paths false, high_risk false, no author-team gate, review_decision unknown but not required (gate not applicable). Falls through to row 9 → approve. Consistent with the prior clean approve on the earlier head.

[bokelley]

Coordinator safety hold: this PR is exposed to the legacy approval-capable Ladon path while the repository lacks a trusted human-only exact-head gate. I marked it Draft and confirmed auto-merge is off. This is not a patch finding and review/run history has not been erased. An authorized administrator must neutralize legacy bot approvals/runs auditably, validate native human enforcement, then require current-base CI and actual non-author human review before lifting the hold.

[aao-secretariat]

Ladon verdict: Approve

Approve — rc.3 consumer-status hardening is clean.

Checked against decision table:

• No critical/high/medium findings (row 1, 4, 5, 6, 8 do not fire).
• gated_paths: false (row 2 N/A).
• high_risk: false, no deletions (row 3 N/A).
• No no-auto-approve team match (row 7 N/A).
• Prior decision was approve, not escalate (row 6 N/A).

Falls through to row 9 → approve.

Reviewer confirmed the key wire-fidelity concerns hold up: the cross-tenant leak fix recomputes the caller-scoped CONSUMER_STATUS_MISMATCH rather than republishing a persisted copy, exact bigint instant comparisons, stale-received grace/escalation projection, openedAt-preserving Postgres upserts, UNSUPPORTED_FEATURE refusal, and an additive minor changeset. Coverage is well-tested. No witness-not-translator violations, no unofficial transport reimplementation, changeset type matches impact.

[aao-secretariat]

Medium: The doc says "ingest validation must never materialize them," but this fallback does exactly that for the bundled store. PostgresReportingLedgerStore implements listRevisions (not listRevisionMetadata), and its listRevisions runs SELECT data ... where data is the full revision JSON including rows (postgres.ts:677-684). So every content_mismatch dispute on the shipped store loads every retained revision's complete row payload into memory just to read supersession metadata, then discards rows. For a long-lived obligation with many/large revisions this is real per-dispute memory + latency on a buyer-triggered path. Consider a projecting listRevisionMetadata on the Postgres store (SELECT data - 'rows' or a metadata-only query) so the narrow port — which exists precisely to avoid this — is actually taken.

[aao-secretariat]

Ladon verdict: Approve

Approve — rc.3 consumer-status hardening delta.

Checked this subsequent pass against the prior clean approve. All hardening logic is sound: the escalation cross-check, content_mismatch superseded-revision currency check, earliestObservable/openedAt dating, and the >= 0→> 0 pending fix all verify correctly. Changeset is present and correctly typed minor. The removed handler.ts instant() is confirmed dead code (health.ts retains its own copy). Witness-not-translator and changeset-vs-wire-impact rules are satisfied.

Medium findings

• src/lib/reporting/ledger/status-ingest.ts:803 — bundled Postgres store's listRevisions fallback materializes every revision's full row payload per content_mismatch dispute, contradicting the "never materialize" note. Non-blocking.

A single Medium finding with no Critical/High and no escalation trigger (not data-loss/schema/infra category, high_risk false, no gated paths, no team gate) falls through to row 9 → approve.

[aao-secretariat]

Ladon verdict: Approve

Approve — clean pass on the rc.3 Reliable Reporting consumer-status hardening.

Checked:

• Shared mismatch projection (health.ts:768-816)
• Cross-tenant leak fix and per-caller recompute (handler.ts:398-445)
• Health-filter/handler escalation agreement (postgres.ts:1015-1023, handler.ts:388-390)
• opened_at durability across upsert
• content_mismatch currency check
• AdcpError-based UNSUPPORTED_FEATURE mapping
• Changeset present and correctly scoped as a minor bump (changeset-vs-wire-impact satisfied)

No blocking or medium findings. high_risk is false, gated_paths is false, no no-auto-approve team match. No escalation triggers apply — falls through to row 9.