API compatibility repair — evidence

Lane record for docs/audits/api-compatibility/2026-10-01/. Every line below is either a quote from an official page (URL + retrieval time), a measurement taken in this lane (command + result), or a pointer to a tracked file. Bulky page captures and wheels stayed in the session scratchpad; their digests are here so the measurement can be repeated.

• Audit lead examined: 1603d538a1411cd0d12a3aafc7ffbb669dfaa471 (historical lead only).
• Baseline measured here: origin/main = 3d5278b00a19b47ae369f248953eb9d961ac3ad5 (2026-10-01 10:41 -0400, merge of #1290). The checkout is shallow (git rev-parse --is-shallow-repository → true).
• Session capabilities (measured 2026-10-01T14:5xZ): gcloud auth list → "No credentialed accounts"; gh auth status → token invalid. No Cloud Run, Secret Manager, Cloud Console metrics or provider account access exists in this lane. Every runtime row below that needs them is BLOCKED_EXTERNAL.

1. Official provider notices (retrieved 2026-10-01, ~14:45–15:00Z)

Pages were fetched with curl -sS -L through the session proxy and reduced to text; quotes are verbatim from that text.

Google Ads API

• https://developers.google.com/google-ads/api/docs/sunset-dates — "Last updated 2026-09-30 UTC." Released versions table: v22 October 15, 2025 → October 2026 (tentative), v23 January 28, 2026 → February 2027, v23.1/v23.2 → February 2027, v24 April 22, 2026 → May 2027, v24.1 → May 2027, v24.2 June 24, 2026 → June 2027, v25 July 22, 2026 → August 2027, v25.1 August 19, 2026 → August 2027, v25.2 September 23, 2026 → August 2027. Upcoming: v26 October 2026 → November 2027, v26.1* November 2026. "Requests sent to this version will fail on or after the sunset date." Python client minimums: "v25 Min: 31.2.0", "v24 Min: 30.1.0", "v23 Min: 29.2.0".
• https://ads-developers.googleblog.com/ — post "Google Ads API v22 sunset reminder", Wednesday, September 2, 2026: "Google Ads API v22 will sunset on October 7, 2026. Starting on this date, all v22 API requests will begin to fail." (The sunset page's "October 2026 (tentative)" is the month; the blog post fixes the day.)
• https://developers.google.com/google-ads/api/docs/api-policy/developer-token — "Developer tokens were sunset on September 9, 2026." "You can continue sending developer tokens in your API call headers, but this is optional and ignored by the API servers." "Your API access levels are determined by the Google Cloud project you used to generate your OAuth credentials. If your app uses the user authentication workflow, then this is the project that owns your OAuth client ID and secret. If you use the service account workflow, then this is the project that owns your service account." "Version v25 of the Google Ads API will throw a AuthorizationError.CLOUD_PROJECT_NOT_APPROVED_FOR_PRODUCTION error if you try to use a Google Cloud project with Test access to make calls to a production account. Older API versions will throw an AuthorizationError.ACTION_NOT_PERMITTED error instead." "We encourage you to update your app to stop sending a developer token as part of your API calls." "We will start rejecting developer tokens in API calls in a future major version of the Google Ads API."
• https://developers.google.com/google-ads/api/docs/api-policy/access-levels — four access levels on the Cloud project: Test (test accounts only), Explorer (2,880 production operations/day; planning, billing, user management restricted), Basic (15,000/day), Standard (unlimited).
• https://github.com/googleads/google-ads-python/blob/main/ChangeLog (raw): 33.0.0 — Google Ads API v25_2 release. Remove Google Ads API v22. Remove Google Ads API v21. 32.0.0 — Remove validation checking if developer token is present in configuration.
• PyPI google-ads (JSON API, 2026-10-01): latest 33.0.0 uploaded 2026-09-23T21:18Z, requires_python <3.15,>=3.9. Wheels downloaded and digest-checked against PyPI; google/ads/googleads/client.py read from each:

Merchant API

• https://developers.google.com/merchant/api/guides/versioning — sub-API table: "Reports v1 v1beta Active Discontinued on Feb 28, 2026" (every sub-API's v1beta: "Discontinued on Feb 28, 2026"). Stable versions get "a 12-month deprecation window ... starting from the official deprecation announcement".
• https://developers.google.com/merchant/api/guides/compatibility/migrate-v1beta-v1 — "You will need to call the registerGcp method (only once for each Google Cloud project used for authentication) ... You won't be able to use any v1 or v1alpha API until this step is completed."
• https://developers.google.com/merchant/api/reference/rest/reports_v1/accounts.reports/search — POST https://merchantapi.googleapis.com/reports/v1/{parent=accounts/*}/reports:search; body {query, pageSize, pageToken}; "pageSize ... Defaults to 1000. Values above 100,000 are coerced to 100,000."; response {results[], nextPageToken}; scope https://www.googleapis.com/auth/content. Same page banner: "Content API for Shopping was sunset on August 18, 2026 ... Starting September 1, 2026, Content API for Shopping requests will experience progressive errors."
• https://developers.google.com/merchant/api/reference/rest/reports_v1/accounts.reports — ReportRow: "Only the message corresponding to the queried table is populated". ProductPerformanceView fields: date (Date; "Condition on date is required in the WHERE clause"), week, conversionValue (Price; "Available only for the FREE traffic source"), marketingMethod, customerCountryCode, storeType, offerId, title, brand, categoryL1..5, productTypeL1..5, customLabel0..4, clicks (int64 string), impressions (int64 string), clickThroughRate, conversions (FREE only), conversionRate (FREE only). "Segment fields cannot be selected in queries without also selecting at least one metric field."
• https://developers.google.com/merchant/api/guides/reports/overview — "This API is only available for standalone and individual sub-accounts. You can't retrieve reports for advanced accounts." "You can query only one view per request."

Google Data Manager API

• https://developers.google.com/data-manager/api/reference/rest/v1/events/ingest — POST https://datamanager.googleapis.com/v1/events:ingest; "At most 2000 Event resources can be sent in a single request"; validateOnly: "If true, the request is validated but not executed. Only errors are returned, not results."; response {"requestId": string, "fieldWarnings": [FieldWarning]} — "fieldWarnings[] Detailed row-level warnings with field paths."
• https://developers.google.com/data-manager/api/reference/rest/v1/FieldWarning — {reason (WarningReason), description, field}; reasons include WARNING_REASON_CUSTOM_VARIABLE_NOT_ENABLED, WARNING_REASON_GENERIC, WARNING_REASON_INVALID_MERCHANT_ID, ...
• https://developers.google.com/data-manager/api/reference/rest/v1/requestStatus/retrieve — GET https://datamanager.googleapis.com/v1/requestStatus:retrieve?requestId=; response requestStatusPerDestination[] with destination, requestStatus (REQUEST_STATUS_UNKNOWN, SUCCESS "Processing succeeded for all records without any errors. However, there may be warnings", PROCESSING, FAILED "Processing failed for all records", PARTIAL_SUCCESS), errorInfo ("Only populated if the requestStatus is FAILED or PARTIAL_SUCCESS. This field isn't populated while the request has requestStatus of PROCESSING"), warningInfo, and eventsIngestionStatus.recordCount — "The total count of events sent in the upload request. Includes all events in the request, regardless of whether they were successfully ingested or not." "The order of the statuses matches the order of the destinations in the original request."

Meta Graph / Marketing API

• https://developers.facebook.com/docs/graph-api/changelog/versions/ — Graph API: v26.0 July 29, 2026 TBD, v25.0 February 18, 2026 → July 29, 2028, v24.0 → February 18, 2028, v23.0 → October 8, 2027, v22.0 → May 20, 2027, v21.0 October 2, 2024 → January 21, 2027, v20.0 → September 24, 2026. Marketing API: "Marketing API version auto-upgrade will release on July 29, 2026." v25.0 February 18, 2026 → TBD, v24.0 → October 6, 2026, v23.0 → June 9, 2026, v22.0 → February 19, 2026, v21.0 → September 9, 2025.
• https://developers.facebook.com/docs/graph-api/changelog/version26.0/ — "Marketing API Released July 29, 2026 | Available until TBD". Changes this lane maps in ISSUES.json API-B6: Delivery Estimate daily_outcomes_curve, budget_guardrail, estimate_dau removed ("Applies to all remaining supported versions on October 27, 2026"); "Instagram Explore Feed placement is no longer available ... requests that explicitly specify Explore return an error" (v26.0+); Messenger Stories: "The story value in messenger_positions is silently removed" ("Applies to all Marketing API versions, including unversioned calls, on October 27, 2026"); HEC-F targeting_automation.advantage_audience explicit on ad set creation (v26.0+); poll ads and web-only destination for Web+App campaigns (all versions 2026-10-27); legacy Graph protocol features (pretty, debug, date_format, GET /?ids=, If-None-Match; all remaining versions from October 27, 2026); Shops ads default destination WEBSITE_AND_SHOP (v26.0+).
• https://developers.facebook.com/docs/marketing-api/overview/versioning/ — "Once a version is unavailable, any calls made to that version number may fail or be upgraded to the next available version." "the auto-upgrade is not applied to endpoints affected by next available version". "If an API call targets a version that has been deprecated and has been automatically upgraded, an API response header is included ... X-Ad-Api-Version-Warning". "Unversioned calls are invalid and will fail when made against Marketing API endpoints."
• Conversions API pages read (Using the API, Marketing API versioning, Graph versioning) do not state which expiry table governs /{pixel_id}/events; recorded as unresolved in API-B7.

Other providers (retrieved 2026-10-01, 15:54–16:06Z)

Pages fetched with curl -sS -L and reduced to text, as above; every quote below was re-checked against the saved bytes. The capture set (raw bytes, text, a fetch log with UTC time, HTTP code, final URL and sha256 per fetch) stayed in the session scratchpad.

• Shopify — https://shopify.dev/docs/api/usage/versioning: "| 2026-07 | July 1, 2026 | July 16, 2027 15:00 UTC | Latest stable" (column "Accessible until"); "If your app targets an inaccessible version, Shopify falls forward and responds using the oldest accessible stable version."
• Klaviyo — https://developers.klaviyo.com/en/docs/changelog_: "Revision 2024-10-15 (GA) Revision supported until: 2026-10-15". No per-revision date for 2026-07-15; the policy page (https://developers.klaviyo.com/en/docs/api_versioning_and_deprecation_policy) says "Each revision is supported for 2 years after its release" (so 2028-07-15 is DERIVED, not published) and "Klaviyo falls forward and responds to your request with the same behavior as the next oldest revision"; removed endpoints answer 410. Breaking changes between 2024-10-15 and 2026-07-15 (changelog sections): Bulk Subscribe/Unsubscribe require subscriptions (2025-01-15); plural profile conversations (2026-07-15); Get Events returns events whose metric cannot be resolved by default (2026-07-15).
• LinkedIn — https://learn.microsoft.com/en-us/linkedin/marketing/integrations/migrations?view=li-lms-2026-09: "...version 202601 (January 2026)... | January 15, 2027 | Active", "...version 202604 (April 2026)... | April 15, 2027 | Active"; https://learn.microsoft.com/en-us/linkedin/marketing/error-responses?view=li-lms-2026-09: a deprecated version header answers 426 NONEXISTENT_VERSION ("Requested version yyyymmdd is not active").
• Amazon SP-API — https://developer-docs.amazon/sp-api/docs/catalog-items-api.md: "Current version: v2022-04-01"; product-type-definitions-api.md: "Current version: v2020-09-01"; sp-api-deprecations.md (updatedAt 2026-09-09): no entry for either; "Removed indicates that calls to the resources fail as of the removal date."
• Amazon Ads reporting — deprecations release note (content host d3a0d0y2hgofx6.cloudfront.net/en-us/release-notes/deprecations.md, named by the page's own server config): "All v3 reporting endpoints and associated report types are also deprecated ... available through POST /reporting/reports"; "Hard shutoff date: ... v3 reporting ... will stop delivering data on June 30, 2027"; Reporting API v1 "now generally available" (2026-09-30).
• Google Analytics — https://developers.google.com/analytics/devguides/reporting/data/v1: "Beta : No breaking changes are expected in this channel." Measurement Protocol (https://developers.google.com/analytics/devguides/collection/protocol/ga4): "will remain operational with no plans for deprecation".
• Merchant API Accounts — versioning guide: "| Accounts | v1 v1alpha v1beta | Active Active Discontinued on Feb 28, 2026"; "We commit to a 12-month deprecation window for stable major versions".
• The Trade Desk — partner portal and api.thetradedesk.com/v3/doc are login-gated (401); the public OpenTTD page https://open.thetradedesk.com/rest/openttd/advertiser/content/docs/Foundations/resources/doc/ApiChanges: "We don't employ a formal versioning policy"; "communicate at least 3 months before planned changes that require integration changes take effect".
• Data Manager — GA announcement 2025-12-09 (https://ads-developers.googleblog.com/2025/12/the-data-manager-api-is-now-generally.html); v1 is the only version in the reference; no versioning or sunset policy page was found (release-notes / changelog / versioning URLs answered 404).
• Meta Graph — versions page, Graph table: "| v21.0 | October 2, 2024 | January 21, 2027", "| v25.0 | February 18, 2026 | July 29,2028"; Graph versioning guide: "once a version is no longer usable, any calls made to it will be defaulted to the next oldest, usable version." Marketing API v24.0 changelog: "Daily budget flexibility is increasing from 25% to 75%" and "Your weekly spend will not change, and will not be greater than 7 times your daily budget". v26.0 changelog: Explore Feed placement "requests that explicitly specify Explore return an error"; Messenger Stories "The story value in messenger_positions is silently removed" (v26.0+; all versions 2026-10-27). No Graph or Marketing changelog from v22.0 to v26.0 lists a Conversions API change (grep over the five pages: only the v26 Business SDK note).
• Data Manager requestStatus — https://developers.google.com/data-manager/api/reference/rest/v1/requestStatus/retrieve (retrieved 15:56Z): ErrorInfo {errorCounts[{recordCount, reason}]} ("May not be populated in all cases"), WarningInfo {warningCounts[...]}, IngestEventsStatus {recordCount} ("Includes all events in the request, regardless of whether they were successfully ingested or not").

2. Source measurements (baseline 3d5278b00)

See ISSUES.json source_evidence per issue. Commands used:

grep -rn -E "graph\.facebook\.com|GRAPH_API_VERSION|META_GRAPH|GRAPH_VERSION" services src connectors contracts
grep -n "version\|SUNSET" services/service-action-runner/execution_adapters/google_ads.py
python3 scripts/deps_lock.py --list | grep gaql

3. Workflow, build and runtime evidence

Every run in §3.1–§3.4 is local, on the branch named in RESUME.md, with the network namespace removed or the proxy variables unset (rule 01, "a network audit behind a loopback proxy sees only the proxy"), and every provider answer is a fake. §3.5 records the deploy runs that the owner's merges fired (#1299,

1302 and #1308), read through the GitHub API, and §3.6 to §3.8 the PR

checks. §3.9 records #1322's merge and two corrections to the closeout's manual-deploy steps. Nothing in this file is live-verified against a provider. (Until independent review pass 3, D8, this paragraph said nothing below was deployed, which §3.5 contradicted.)

3.1 Commits

Published on work/mizoki-api-compatibility-3ae54n behind draft PR #1299. The owner marked it ready and merged it at 0cf37f0 (2026-10-01 20:14:51Z, merge commit cb7b7ff); GitHub then deleted the branch. The claim PR #1300 merged at 20:14:12Z. The work that followed (review pass 2 and Copilot's review of the merged head) went onto the same branch name restarted on main, behind draft PR #1302: the one unmerged commit was rebased (8e961af → 606fb8a) and pushed with --force-with-lease against 8e961af. The assigned claude/ branch was never pushed: a push there merges to main and fires the Deploy Router without the owner's typed MERGE gate.

The owner merged #1302 at 482b60b (2026-10-02 12:47:38Z, merge commit d98d213). GitHub kept the branch (read at 12:55Z). The record that followed went onto it as a fast-forward from d98d213, behind a new draft PR.

The owner merged that PR, #1308, at 99381e8 (2026-10-02 13:29:44Z, merge commit 990bccf). This time GitHub deleted the branch at the merge (pass 12 read it deleted at 13:29:49Z). Pass 12's record went onto the same branch name, restarted on main, behind a new PR, #1322. It was first made on main f44f961, then redone on main bf1ff32 when other sessions' memory commits made it conflict.

1322 merged at 35a58e7 (2026-10-03 14:46:04Z, merge commit d0992c1,

from the mediaintelligence account). GitHub kept the branch. The corrections in §3.9 went onto the same branch name, restarted on main 185f358, behind a new PR.

3.2 Test runs (fresh venvs; the install lines of the CI job named)

A first governance run in an older venv showed three failures: one real regression this lane introduced (the gateway's new import provider_versions failed when test_tenant_lane_vault loads connector_credentials.py by file path) — fixed in d787e7e with a sibling-file fallback — and two environment artifacts reproduced identically on pristine origin/main (reportlab absent from that venv; test_wo19_atomic_reservations failing on a long TMPDIR, AF_UNIX path too long, rule 01). The clean run above is the one that counts.

Final sweep (8e961af, the pass-2 commit before its rebase onto main as 606fb8a)

Every gate command again, on fresh venvs built from each job's install lines (build_p2.sh in the session scratchpad: ci.yaml lint-and-test, governance-gates, orphaned-suites, suite-wiring and measurement-rails; the canonical-ingestion gate; the gemini gate; the GAQL image's lock). The earlier venvs venv-ci and venv-cig were reinstalled by the pass-2 verifier while this lane's first sweep ran (its disclosure, §4.3), so no number below comes from them. Proxy variables unset, TMPDIR=/tmp/sw, one activity on the tree. The real-SDK GAQL step ran without unshare -rn in both sweeps. Its tests stub the SDK's credential factory (TestRealSdk), so no OAuth refresh is attempted; the other tests use fake clients or unconfigured settings. HEAD 8e961af5180cd4046ac0c389b102b781546beb1f dirty=0, started 2026-10-01T20:12:32Z; finished 2026-10-01T20:28:38Z dirty=0.

Non-zero exits, each pre-existing and reproduced on base 3d5278b:

• wire_docs_audits_tests_: docs/audits/tests/test_wo31_register.py runs git show 26bec9c6…:docs/OPEN_ITEMS.md, a commit this shallow clone lacks; it fails identically on base 3d5278b, and CI's suite-wiring job (full history) passes it.

Follow-up head (e3bd49e, PR #1302, on main 3f89cd0)

The rebase changed no file of the pass-2 commit, so the full sweep above stands for it. These runs cover what changed after it, plus the gates that read the reworded inventory row (same fresh venvs):

Pass-3 heal head (22f711d, fc2a3a3 and their record commits)

Same fresh venvs, proxy variables unset, TMPDIR=/tmp/f4 or /tmp/gv3; anything that can build a provider client under unshare -rn.

fc2a3a3 changes only the GAQL registry, its test and a test fixture, so the 5ff9bdb rows that read neither stand for it. The PR body records the gate run on the pushed head.

Pass-4 heal head (b03f33e and the record commit after it)

Same venvs, in a detached worktree at b03f33e (the main checkout was being edited for this record), proxy variables unset, TMPDIR=/tmp/t4; anything that can build a provider client under unshare -rn.

The record commit changes only docs/audits/api-compatibility/2026-10-01/. The gates that read it are the governance spine (the inventory's ledger-id guard), content_gates.sh, the lifecycle, gate-leak, canon-docs and memory checks, docs/audits/tests and the Deploy Router. They run on that commit, and the PR body records them, as it did for 9fd5982.

Pass-5 heal head (c7d8904 and the record commit after it)

Same venvs, proxy variables unset, TMPDIR=/tmp/n6; anything that can build a provider client under unshare -rn. Measured on the working tree that was then committed unchanged as c7d8904 (git status clean after the commit).

The image-lock GAQL suite and the final-tree gates run on the record commit; the PR body records them.

Pass-6 heal head (9d9cd01, 85b7ecb and the record commit after them)

Same venvs, proxy variables unset; anything that can build a provider client under unshare -rn. Measured on the working tree committed unchanged as 9d9cd01. 85b7ecb changes one test file: its registry tests pass (3), and the whole GAQL suite runs again in the final-tree gates.

The image-lock GAQL suite and the final-tree gates run on the record commit; the PR body records them.

Pass-7 heal head (49f8d80 and the record commit after it)

Same venvs, proxy variables unset; anything that can build a provider client under unshare -rn. Measured on the working tree committed unchanged as 49f8d80.

The image-lock GAQL suite and the final-tree gates run on the record commit; the PR body records them.

Pass-8 heal head (02b4c3c and the record commit after it)

Same venvs, proxy variables unset; anything that can build a provider client under unshare -rn. Measured on the working tree committed unchanged as 02b4c3c.

The final-tree gates run on the record commit; the PR body records them.

Pass-9 heal head (9736385 and the record commit after it)

Same venvs, proxy variables unset; anything that can build a provider client under unshare -rn. Measured on the working tree committed unchanged as 9736385.

The deploy pin's scan of the four roots takes about 13 s of the GAQL suite. The final-tree gates run on the record commit; the PR body records them.

Pass-10 heal head (d1e1e7b; 592fa5d changes a docstring only)

Same venvs, proxy variables unset; anything that can build a provider client ran under unshare -rn. Measured in a clean worktree at d1e1e7b. The fast gates (content gates 155 passed; lifecycle, gate-leak, canon docs, memory --strict and the router clean) and the same suites also passed on 592fa5d before it was pushed.

The pin's test class took about 23 s here, measured while other runs shared the machine. The final-tree gates run on the record commit; the PR body records them.

Pass-11 heal head (8c4f986; c9df080 adds one seed)

These runs used the same venvs, with the proxy variables unset. Anything that can build a provider client ran under unshare -rn. Measured in a clean worktree at c9df080.

Before each commit was pushed, the fast gates passed on it: content gates (155 passed), and the lifecycle check, gate-leak, canon docs, memory --strict and the router, all clean. PR CI on 8c4f986 passed: 27 checks green, 1 skipped.

The pin's test class took about 23 s here (5 tests, test_the_tree_checks_read_both_ways among them). The final-tree gates run on the record commit; the PR body records them.

Earlier sweep (b4860c8, re-runs at 19e8a6c)

Every pytest command in .github/workflows/*.yml whose scope the branch touches, plus the ci.yaml jobs, each in a venv built from that job's install lines (proxy variables unset, TMPDIR=/tmp/sw). Commands and logs: session scratchpad sweep/ and rerun/.

docs/audits/tests/test_wo31_register.py fails here and fails identically on the base 3d5278b: it runs git show 26bec9c6…:docs/OPEN_ITEMS.md, a commit this shallow clone does not have (git rev-parse --is-shallow-repository → true). CI's suite-wiring job, which fetches full history, passed on #1299.

The first sweep run of tests/connectors and the gateway suite (2 failures each) overlapped an inventory edit made while it ran; it was discarded and re-run on the final tree (rule 01, "one tree, one activity").

3.3 Mutation probes (the new tests fail on a reverted fix)

• gateway (tests/connectors/test_api_compat_2026_10.py): 8/8 mutants caught.
• Data Manager (test_api_compat_final_status.py): 8/8 caught — applied on acceptance, duplicate refusal removed, sweep unbounded, warnings dropped, tenant scoping removed, success aggregated with any, expiry disabled, live upload without tenant.
• WO-45 guard widening: on origin/main it reports ad_integration_health.py:393 v22 and unified_platform_integration.py:72 v18, the two pins the first-line rule never saw.
• Pass-3 heals (22f711d), each new test run against the old code in a throwaway worktree:
• On db3c271's code, 10 fail: 7 GAQL (TestChangeStatusLimit ×2, TestReadsThatCrossTheSunset, TestActGuards ×2, TestLiveFieldLookup, the partial-failure test) and 3 Data Manager (the claim-stamp and own-claim tests); 65 pass. On the Decisions route the old code answers 502 LIMIT_NOT_SPECIFIED; in the sunset-before-ACT test it reaches the retired version's client and attempts the mutations, which the placeholder operation builder refuses.
• The corrected D2 test passes on db3c271 (its fix, e3bd49e, is there) and fails on 3f89cd0's code: 28 != 0, the 28 locally authorized actions reach ACT. Its sibling fails there too.
• test_the_console_email_route_stays_unarmed_on_deploy fails when EMAIL_SERVICE=klaviyo is seeded into the console deploy's env map.
• fc2a3a3: TestRegistryAgainstTheV25FieldReference fails on 5ff9bdb's registry (conversion_segmentation_v1, metrics.cost_per_conversion, not selectable with the conversion-action segments) and passes now.
• Pass-4 heals (b03f33e), each new test run against 9fd5982's code in a throwaway worktree:

• 7 fail there. 5 are GAQL tests:

  • test_the_changes_route_sends_its_own_limit;
  • both TestRunsDecideFromTheirOwnReads tests;
  • TestLiveFieldLookup, whose fake now refuses the FROM clause the old query sent;
  • test_the_executor_holds_no_client_of_its_own (V5-12, added in 9d76b52; this count uses 9d76b52's test files).

  The other 2 are the Data Manager late-read tests. The rest of those two files pass there: 31 GAQL tests (4 skipped) and 34 Data Manager tests. - The pins pass on both trees, as pins of unchanged values do. On b03f33e, each of ten seeded flips fails exactly one test:

  Seeded flip	Test that fails
  each of the deploy's three values; an added --update-env-vars	test_the_deploy_keeps_live_mutations_off
  each of the three code defaults	test_the_code_defaults_keep_live_mutations_off
  an operation builder that returns	test_the_operation_builder_refuses
  metrics.cost_per_conversion back in conversion_segmentation_v1	TestRegistryAgainstTheV25FieldReference
  EMAIL_SERVICE=klaviyo in the console's env map	test_the_console_email_route_stays_unarmed_on_deploy

  The worktree was clean after each restore. - Pass-5 heals (c7d8904), in throwaway worktrees: - On 2ee03e0's code with c7d8904's test files, 3 fail: - test_an_mcc_run_refused_for_a_synthetic_child_names_its_child_runs (N5); - test_a_late_read_is_never_applied_to_a_re_sent_record (N1); - test_a_late_read_notes_what_it_answered (N2).

  Everything else passes there: the GAQL file 36 passed + 4 skipped, the Data Manager suite 51, the inventory tests 23. - The registry check's seeds fail (test_the_check_catches_what_it_encodes) when the attributed-resource rule or the segment-to-segment rule is removed, or when the cumulative skip pass 5 described is restored. - Seeded real deploy files each fail exactly the pin that guards them: - a console substitution default carrying EMAIL_SERVICE; - --flags-file in the console deploy; - a second, space-form --set-env-vars step in the GAQL deploy; - --flags-file in the GAQL deploy.

  The clean files pass. - TestLiveFieldLookup fails when the lookup's query gains a bogus WHERE term. - Pass-6 heals (9d9cd01, 85b7ecb), in throwaway worktrees: - On 701f67c's code with 9d9cd01's test files, 2 fail: - test_a_malformed_status_body_is_read_not_raised (D3: AttributeError: 'str' object has no attribute 'get', raised at request_tracking.py:336); - test_a_read_that_outlived_its_lease_releases_only_its_own_claim (D4: the note's reason).

  Everything else passes there: the Data Manager suite 52, the GAQL file 37 passed + 4 skipped, the inventory tests 23. The pins pass on both trees, as pins of unchanged files do. - Seeds on the real files. With 9d9cd01's test files, each fails exactly the test named. The last column is the result with 701f67c's test files.

  Seed	Test that fails	With 701f67c's tests
  a step in deploy-ui.yml running gcloud run services update … --update-env-vars EMAIL_SERVICE=…	test_the_console_email_route_stays_unarmed_on_deploy	passes
  a second, space-form submit of the console build in deploy-ui.yml, with another substitution	same	fails
  the name added to scripts/ops/deploy_frontend_cloudrun_prod.sh's env map	same	passes
  --update-env-vars EMAIL_SERVICE=… on patch-react-rsc-gcp.yml's console deploy	same	passes
  a second pair after ${{ github.sha }} in deploy-ui.yml (pass 6's seed 1)	same	passes
  a quoted pair there that puts a shell command into _REQUIRE_AUTH (seed 1)	same	passes
  pass 6's seed 2 in deploy-all.yml, as it gave it ('--substitutions=^:^…,EMAIL_SERVICE=…:_IMAGE_TAG=…')	same	passes
  a plain second pair in deploy-all.yml	same	passes
  ENV EMAIL_SERVICE=… in the console's Dockerfile (seed 3)	same	passes
  --flags-file on deploy-ui.yml's submit (seed 4)	same	passes
  another --config in deploy-ui.yml (seed 4)	same	passes
  another --config in deploy-google-ads-gaql.yml	test_the_deploy_keeps_live_mutations_off	passes
  a second, space-form --config there	same	passes
  a step there running gcloud run services replace on the reference manifest, with its GAQL_ENABLE_LIVE_MUTATIONS set to "true" (pass 6's D7). Pass 7 (N1): not pass 6's seed, which put the step in the cell's Cloud Build file; that one passed these pins	same	passes
  a script under deployment/ naming the reference manifest	same	passes

  A look-alike name (EMAIL_SERVICE_URL) in a deploy script passes both. The clean files pass both, and the worktree was clean after each restore. Pass 6's seed 5, a name assembled at run time in a shell step, was not seeded: it is out of the pin's reach, and its docstring says so. Pass 7: inaccurate in the harmless direction. The seed as pass 6 wrote it carries --update-env-vars in a shell string, which the substring merging-flag check catches. - 85b7ecb: with the metric half removed again, exactly test_the_check_catches_what_it_encodes fails. Its new seed drops campaign from metrics.clicks' list. - Pass-7 heals (49f8d80), in throwaway worktrees: - On d14dba0's code with 49f8d80's Data Manager tests, 1 fails: test_a_status_body_out_of_range_is_read_not_raised (OverflowError: cannot convert float infinity to integer). The other 54 pass there. - Before the fix, on d14dba0's code, a probe swept three due records, the first answering with an Infinity count. The first sweep raised at it and read nothing else. Sweeps inside the lease skipped it and finalized the other two. After the lease it raised again, and its checks stayed 0. By reading, the budget and TTL checks run inside the update that raised, so nothing could retire it. With the fix one sweep finalizes all three. Pass 8 measured it: 80 hours of 1-minute sweeps on d14dba0's code gave 960 raises, one every 300 s, and the record stayed submitted with 0 checks, past the 72-hour TTL. - The verifiers' own seeds, replayed on the real files rather than rewritten from their reports: - pass 7's seed driver (vfy8/probes/seeds.py), unchanged except for its paths: its 15 replays of this record's seeds, its look-alike, its clean tree and its 12 own seeds V01–V12; - pass 6's D7 seed, as pass 6 wrote it.

  Each seed ran against 49f8d80's pins and against d14dba0's. Of the 28 arming routes, 49f8d80's pins catch 28, each failing exactly the test named; d14dba0's catch 15. By family: the console route 20 of 20 (d14dba0: 11), the GAQL deploy 8 of 8 (d14dba0: 4). The clean tree and the look-alike name (EMAIL_SERVICE_URL) pass both, and the worktree was clean after each restore.

  Seed	With 49f8d80's pins, the test that fails	With d14dba0's pins
  pass 6's own D7 seed (vfy7/probes/mutate.py, gaql_services_replace): a step in the cell's Cloud Build file replacing the service from the reference manifest, its GAQL_ENABLE_LIVE_MUTATIONS set to "true"	test_the_deploy_keeps_live_mutations_off	passes
  a deploy-ui.yml step running gcloud run services update … --update-env-vars EMAIL_SERVICE=…	test_the_console_email_route_stays_unarmed_on_deploy	fails
  a second, space-form submit of the console build in deploy-ui.yml, with another substitution	test_the_console_email_route_stays_unarmed_on_deploy	fails
  the name added to scripts/ops/deploy_frontend_cloudrun_prod.sh's env map	test_the_console_email_route_stays_unarmed_on_deploy	fails
  --update-env-vars EMAIL_SERVICE=… on patch-react-rsc-gcp.yml's console deploy	test_the_console_email_route_stays_unarmed_on_deploy	fails
  a second pair after ${{ github.sha }} in deploy-ui.yml (pass 6's seed 1)	test_the_console_email_route_stays_unarmed_on_deploy	fails
  a quoted pair there that puts a shell command into _REQUIRE_AUTH (seed 1)	test_the_console_email_route_stays_unarmed_on_deploy	fails
  pass 6's seed 2 in deploy-all.yml, in its ^:^ form	test_the_console_email_route_stays_unarmed_on_deploy	fails
  a plain second pair in deploy-all.yml	test_the_console_email_route_stays_unarmed_on_deploy	fails
  ENV EMAIL_SERVICE=… in the console's Dockerfile (seed 3)	test_the_console_email_route_stays_unarmed_on_deploy	fails
  --flags-file on deploy-ui.yml's submit (seed 4)	test_the_console_email_route_stays_unarmed_on_deploy	fails
  another --config in deploy-ui.yml (seed 4)	test_the_console_email_route_stays_unarmed_on_deploy	fails
  another --config in deploy-google-ads-gaql.yml	test_the_deploy_keeps_live_mutations_off	fails
  a second, space-form --config there	test_the_deploy_keeps_live_mutations_off	fails
  a step there running gcloud run services replace on the reference manifest, flipped to "true"	test_the_deploy_keeps_live_mutations_off	fails
  a script under deployment/ naming the reference manifest	test_the_deploy_keeps_live_mutations_off	fails
  V01: EMAIL_SERVICE in the console's env.production.yaml	test_the_console_email_route_stays_unarmed_on_deploy	passes
  V02: a deploy-ui.yml step running services update --env-vars-file= on that file (which names it)	test_the_console_email_route_stays_unarmed_on_deploy	passes
  V03: scripts/arm_email.mjs, run by a step	test_the_console_email_route_stays_unarmed_on_deploy	passes
  V04: an extensionless .github/scripts/arm-email, run by a step	test_the_console_email_route_stays_unarmed_on_deploy	passes
  V05: Dockerfile.prod with ENV EMAIL_SERVICE, and the console Cloud Build file's -f pointed at it	test_the_console_email_route_stays_unarmed_on_deploy	passes
  V06: next.config.js with env.EMAIL_SERVICE	test_the_console_email_route_stays_unarmed_on_deploy	passes
  V07: a new workflow submitting miz-oki-command-center-ui/./cloudbuild.yaml with extra substitutions	test_the_console_email_route_stays_unarmed_on_deploy	passes
  V08: a second --substitutions in the middle of a line of deploy-ui.yml's submit	test_the_console_email_route_stays_unarmed_on_deploy	passes
  V09: EMAIL_SERVICE in cloudbuild.otel.yaml's Knative env, and a new workflow submitting it	test_the_console_email_route_stays_unarmed_on_deploy	passes
  V10: a deploy-google-ads-gaql.yml step running services update … --update-env-vars=GAQL_ENABLE_LIVE_MUTATIONS=true,…	test_the_deploy_keeps_live_mutations_off	passes
  V11: a copy of the manifest, flipped, at deployment/gaql/live.yaml, replaced by a deploy step	test_the_deploy_keeps_live_mutations_off	passes
  V12: scripts/arm_gaql.js, which names the manifest	test_the_deploy_keeps_live_mutations_off	passes

• Pass-8 heals (02b4c3c), in throwaway worktrees:

• On d7a5af2's code with 02b4c3c's Data Manager tests, 1 fails: test_status_totals_and_rows_stay_in_what_the_store_holds (two widest counts give confirmed_events 2**64 − 2). The other 55 pass there.
• With the fix in place, removing each of its five parts in turn makes that test fail: the clamped totals, the refusal of negative counts, the row cap, the bounded warning labels and the history note. Restored, it passes.

• The verifiers' seeds, replayed from the files pass 8 kept (vfy9/probes/seeds9.py, seeds9_extra.py, seeds9_extra2.py), paths changed only, on 02b4c3c with its pins and with d7a5af2's:

  • pass 7's driver and pass 6's D7 seed, as pass 8 replayed them: of the 28 arming routes, 02b4c3c's pins catch 28 and d7a5af2's 28, each failing exactly its pin; the clean tree and the look-alike pass both;
  • pass 8's own seeds, below: 02b4c3c's GAQL pin catches 6 of the 6 GAQL routes (d7a5af2's: 0), each failing exactly test_the_deploy_keeps_live_mutations_off; its three false positives and the control pass; the two routes now stated out of reach (C3, C4) pass both.

  Seed	With 02b4c3c's pins	With d7a5af2's pins
  G1: a new workflow running services replace on a flipped manifest copy kept in the cell's directory (the service named only in the copy)	test_the_deploy_keeps_live_mutations_off	passes
  G2: a fourth step in the cell's Cloud Build file (id first, no entrypoint, flow-list args) replacing from that copy	test_the_deploy_keeps_live_mutations_off	passes
  G3: a deploy-workflow step whose services update is split by a line continuation, with an env file in the cell's directory	test_the_deploy_keeps_live_mutations_off	passes
  G4: the same with the verb quoted	test_the_deploy_keeps_live_mutations_off	passes
  G5: a second Cloud Build file in the cell's directory (live settings), submitted by a new workflow	test_the_deploy_keeps_live_mutations_off	passes
  control: a harmless new workflow and a new note in the cell's directory	passes	passes
  C1: the homepage deploy mounting SENDGRID_API_KEY, the site's own pilot-email key (a false positive of d7a5af2's pin)	passes	test_the_console_email_route_stays_unarmed_on_deploy
  C2: an ops script arming measurement-rails' KLAVIYO_PRIVATE_API_KEY (a false positive of d7a5af2's pin)	passes	test_the_console_email_route_stays_unarmed_on_deploy
  C3: a third submitter through working-directory, with the config spelled relative to the console's directory	passes	passes
  C4: YAML-escaped names in an env file under deployment/, applied by a deploy-ui step	passes	passes
  G6: a deploy-workflow step gcloud run deploy google-ads-gaql-cell --env-vars-file=…	test_the_deploy_keeps_live_mutations_off	passes
  GFP: the fleet verify workflow printing a services update {svc} --min-instances=1 for each service (a false positive of d7a5af2's pin)	passes	test_the_deploy_keeps_live_mutations_off

• Pass-9 heals (9736385), in throwaway worktrees:

• On b9a35c6's code with 9736385's Data Manager tests, 3 fail; the other 55 pass there:
  • test_a_label_the_store_cannot_encode_reads_as_absent: UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' … surrogates not allowed, raised by the test's store, which refuses what Firestore's encoder refuses;
  • test_an_answer_with_more_rows_than_destinations_is_unknown: success where unknown is due;
  • test_status_totals_and_rows_stay_in_what_the_store_holds: the same, in pass 8's own test, whose baseline moved.
• With the fix in place, removing each of its five parts in turn makes its test fail (1 failed, 57 passed; the row rule 2 failed, 56 passed): the Unicode check, bytes rather than characters, the description's bound, more rows read as unknown, and the history note. Restored, it passes.
• Each of the GAQL pin's 14 rules, removed in turn, makes test_the_deploy_scan_reads_commands_as_written fail (1 failed, 3 passed each): the repeated-key and alias refusals, YAML decoding, Python decoding, shell words, joined block lists, cuts at && and ;, reads of any suffix, the manifest rule, the service-word rule, the bounds of the cell's name, the deploy-workflow rule, quote marks in a config path, and the shell reading of names.
• Size, computed with Firestore's documented formula on apply_status's own output (not run against Firestore): a status row with maximal labels is 23,253 bytes, and the record is 1,030,366 bytes at 44 destinations and 1,077,012 at 46.

• The verifiers' seeds, replayed from the files passes 8 and 9 kept (vfy10/probes/seeds/: seeds9.py, seeds9_extra.py, seeds9_extra2.py, seeds10_own.py, seeds10_y.py, seeds10_z.py), paths changed only, on 9736385 with its pins and with b9a35c6's: 55 seeds.

  • Pass 9's 8 arming routes (X1 to X8): 9736385's pins catch 8, b9a35c6's 0.
  • Its two spellings (Y1, Y2): caught 2, against 0.
  • Its two false positives (XFP1, XFP2) pass.
  • The 34 earlier arming routes (pass 7's driver and pass 6's D7 seed, 28; pass 8's G1 to G6, 6) are caught by both.
  • The controls and legal seeds pass both: B00, B16, G0, X0, C1 to C4 and GFP.
  • Every caught seed fails exactly one test, the pin that guards it.

  Seed	With 9736385's pins	With b9a35c6's pins
  X1: a flipped manifest copy with a .txt suffix in the cell's code directory, services replaced by a new workflow	test_the_deploy_keeps_live_mutations_off	passes
  X2: a YAML folded scalar (run: >-) splitting services replace from its manifest	test_the_deploy_keeps_live_mutations_off	passes
  X3: a Cloud Build file under deployment/ whose block args list has a comment line, submitted by a new workflow	test_the_deploy_keeps_live_mutations_off	passes
  X4: a Python script under scripts/ with a multi-line subprocess list, run by a new workflow	test_the_deploy_keeps_live_mutations_off	passes
  X5: YAML double-quoted escapes for the service name and the key in a deploy-workflow step	test_the_deploy_keeps_live_mutations_off	passes
  X6: shell quotes inside the service name and the key in a deploy-workflow step	test_the_deploy_keeps_live_mutations_off	passes
  X7: a Cloud Build file under deployment/ with a flow args list over two lines, submitted by a new workflow	test_the_deploy_keeps_live_mutations_off	passes
  X8: the cell's own Cloud Build file gains a first steps: block (build, push, services replace of a flipped copy); the pinned block follows unchanged	test_the_deploy_keeps_live_mutations_off	passes
  XFP1: the action runner's deploy env gains the cell's URL (another service)	passes	test_the_deploy_keeps_live_mutations_off
  XFP2: a console env file under deployment/ carrying NEXT_PUBLIC_GAQL_CELL_URL, applied by a deploy-ui step	passes	test_the_deploy_keeps_live_mutations_off
  X0: the clean tree	passes	passes
  Y1: a third console submitter, the path with a quoted segment, an extra substitution	test_the_console_email_route_stays_unarmed_on_deploy	passes
  Y2: a second submitter of the cell's Cloud Build file, the path with a quoted segment	test_the_deploy_keeps_live_mutations_off	passes
  - Pass-10 heals (d1e1e7b; 592fa5d changes the docstring only), in throwaway
  worktrees:
  - Each new rule, removed in turn: 38 removals in a clean worktree at
  d1e1e7b (mut12.py). With nothing removed, the GAQL pin's class
  passes (4 passed) and so does the inventory suite.
  - The command reader's 15 rules and the strict reader's 3 new refusals
  each make test_the_deploy_scan_reads_commands_as_written fail alone
  (1 failed, 3 passed):
  - continuation removal;
  - a quoted word read again;
  - a verb anywhere after run;
  - each of the five change marks (--env-vars-file, --set-env-vars,
  --update-env-vars, run.googleapis.com, deploy-cloudrun);
  - a step's uses read with its inputs;
  - a target after =, and after /services/;
  - reads after =, @ and <;
  - words cut at brackets and quotes;
  - odd characters, explicit tags and directives.
  - Of _cloudbuild_problems' 17 rules, 16 each make the same test fail
  alone. The 17th, "every deploy argument is a string" (C10), fails
  nothing when removed, because the flag allow-list also refuses a
  non-string argument. All C10 adds is a named problem in place of a
  crash. It is recorded as subsumed, not pinned.
  Pass 11 (NIT 1): not so. That run coerced the arguments to
  strings instead of removing the rule. With the rule removed, the
  seed test fails: the flag allow-list crashes on a non-string
  (AttributeError) instead of refusing it. Re-measured in the
  pass-11 block below.
  - The console reader's three new refusals each make
  test_config_spellings_and_the_strict_reader fail alone.
  - Pass 11 (NIT 2): these are the rules this run removed, not every
  rule the pin holds. Eight more failed no test when removed, the
  deploy workflow's digest among them. The pass-11 block below seeds
  them, or says why not.
  - gcloud's own loader (Cloud SDK 530.0.0), run offline under unshare -rn
  with no credentials (fuzz12.py, classify12.py).
  - Candidates. Each mutates one of the real Cloud Build files: 300
  random insertions of one to three characters from a pool of 50, plus
  every pool character at the start and at the end of every line. The
  pool:
  - ASCII punctuation, space, newline, tab and CR;
  - NEL, U+2028, U+2029, a byte-order mark, U+FFFE and DEL;
  - NUL, VT, FF and ESC;
  - non-breaking space, U+200B, U+3000, an em dash, é, §, ·, an
  emoji, a soft hyphen and U+200F;
  - a few letters, digits and symbols.
  - Comparison. gcloud's LoadCloudbuildConfigFromPath loaded each text
  the new pins accept. Its Build message was compared with PyYAML's
  reading put through gcloud's own message conversion
  (_YamlToMessage and FinalizeCloudbuildConfig, compared as
  MessageToPyValue).

  File (the pin that accepts it)	Candidates	Accepted	Read the same	Refused by both	Read differently
  the cell's (_cloudbuild_problems is empty)	5,501	1,104	1,104	0	0
  the console's (_strict_yaml reads it)	37,901	11,994	11,581	413	0

  • The 413 refused texts. gcloud itself refuses them, so a deploy of them fails. In 10 of them the two sides' error texts differ. Of the 11 read in full, 8 have an unknown key, 2 a malformed substitution key, and 1 a null key.
  • No text gcloud loads is read differently. Pass 10's Z6 and Z6b are refused by the reader, as seeded.
  • What this establishes. It is a measurement of single insertions into the real files, not a proof for every text.
  • Size (NIT 3), re-measured by this session with Firestore's documented formula (computed, not run against Firestore). The record goes through the real lifecycle (begin_submission, record_accepted, reconcile_record), with every label at its bound:

  Destinations	Field warnings	Status label	Bytes	Over 1 MiB
  44	none	SUCCESS	1,024,004	no
  44	50 maximal	SUCCESS	1,060,404	yes
  44	none	maximal (reads as unknown)	1,032,557	no
  44	50 maximal	maximal	1,068,957	yes
  45	none	SUCCESS	1,047,253	no
  45	none	maximal	1,055,999	yes
  46	none	SUCCESS	1,070,502	yes

  • A status row is 23,183 bytes with SUCCESS, and 23,376 with a maximal status label.
  • 50 maximal field warnings are 36,400 bytes.
  • Pass 9's figures came from a synthetic record that skipped the lifecycle and the field warnings: 23,253 bytes per row, and 1,030,366 at 44 destinations. These replace them, and match pass 10's.
  • The verifiers' seeds, replayed from the files passes 8 to 10 kept, with paths changed only. They ran on d1e1e7b with its pins and with 4e1fe7a's: 68 seeds, pass 10's 13 (seeds11_own.py, seeds11_more.py) and the 55 of the pass-9 block.
  • Pass 10's 12 arming routes (Z1 to Z11 and Z6b): d1e1e7b's pins catch 12, 4e1fe7a's catch 0. Its clean tree (Z0) passes both.
  • The 44 earlier arming routes are caught by both, each failing exactly one test: the 34 of the pass-8 block, and pass 9's X1 to X8, Y1 and Y2.
  • The 11 controls and legal seeds pass both: B00, B16, G0, X0, C1 to C4, GFP, XFP1 and XFP2. GFP failed the first version of this fix, which was amended before it was pushed (§4.21).
  • One kept driver, seeds9_extra.py, names its worktree in its own code. A symlink pointed that name at the worktree it ran in; nothing else changed.

  Seed	With d1e1e7b's pins	With 4e1fe7a's pins
  Z1 GAQL: deploy-workflow step, mid-word shell continuations (upd\ate, --update-env-v\ars, the key split), target ${{ env.SERVICE_NAME }}	test_the_deploy_keeps_live_mutations_off	passes
  Z2 GAQL: new workflow, mid-word shell continuations in the cell's name, the env flag and the key	test_the_deploy_keeps_live_mutations_off	passes
  Z3 GAQL: new workflow gcloud run --quiet services replace of a flipped manifest copy kept as LIVE.md in the cell's dir	test_the_deploy_keeps_live_mutations_off	passes
  Z4 GAQL: deploy-workflow step gcloud run --quiet services replace of LIVE.md (flipped copy, cell's dir)	test_the_deploy_keeps_live_mutations_off	passes
  Z5 GAQL: deploy-workflow step gcloud run --quiet services update ${{ env.SERVICE_NAME }} --image=... (deploys the cell another way)	test_the_deploy_keeps_live_mutations_off	passes
  Z6 GAQL: the cell's Cloud Build file, env map reordered and followed by U+2028 + the next item (gcloud's reader joins them)	test_the_deploy_keeps_live_mutations_off	passes
  Z7 GAQL: the cell's Cloud Build deploy step gains env CLOUDSDK_PYTHON=/bin/sh + CLOUDSDK_PYTHON_ARGS=	test_the_deploy_keeps_live_mutations_off	passes
  Z8 GAQL: deploy-workflow step curl -X PATCH the Run Admin API for ${{ env.SERVICE_NAME }} with a body kept as ARM.md in the cell's dir	test_the_deploy_keeps_live_mutations_off	passes
  Z9 GAQL: listed verify workflow step bash -c "gcloud run services update google-ads-gaql-cell --region=... --env-vars-file=docs/..."	test_the_deploy_keeps_live_mutations_off	passes
  Z0 CLEAN tree (mut6)	passes	passes
  Z6b GAQL: the cell's Cloud Build file gains - --description=GAQL cell + U+2028 before the env map (gcloud's reader merges the env map into the description)	test_the_deploy_keeps_live_mutations_off	passes
  Z10 GAQL: deploy-workflow step uses: google-github-actions/deploy-cloudrun@v2 with metadata: a flipped manifest copy under docs/	test_the_deploy_keeps_live_mutations_off	passes
  Z11 GAQL: new workflow gcloud run services replace /dev/stdin <src/cells/google_ads_gaql/LIVE.md (redirect; stated out of reach as stdin)	test_the_deploy_keeps_live_mutations_off	passes
  - Pass-11 heals (8c4f986; c9df080 adds one seed), in throwaway
  worktrees:
  - The tree checks, seeded both ways. test_the_tree_checks_read_both_ways
  builds a tree and checks it:
  - the deploy workflow (item 2): one byte added, and five added steps,
  each caught under its own digest: a second config, the same config
  twice, a config that only a YAML reader joins to its flag, a flags
  file, and a service change;
  - the four roots (item 3): five files caught, each naming the Cloud
  Build file or the cell's service, or arming the cell (S4 and S4b among
  them). A listed file that stops naming the cell is caught too, and two
  legal look-alikes pass;
  - _names_config: 7 spellings that name the Cloud Build file, and 3
  that do not;
  - the cell's own files (item 4): seven files caught:
  - S1b;
  - S1arm's script;
  - a Markdown file naming the manifest;
  - S6's Markdown command;
  - a Python command;
  - a new file naming the service;
  - a new file naming a key.

  A tree passes in which prose and code name the service and a key and this test file and compiled Python are present. This test file is caught when it is not skipped.

  test_the_deploy_scan_reads_commands_as_written gains: - two commands it catches: the cell named in a JSON body, and a file read through $(realpath ...); - one it leaves: a ; with no space around it; - the flow-list entry _strict_yaml passes; - one Cloud Build text: a colon ending a flow-list entry. - Each rule, removed in turn. 66 removals ran in a clean worktree at 8c4f986 (mut13.py), and five again at c9df080 (mut13b.py). With nothing removed, the pin's class passes (5 passed), and so does the inventory suite. - 63 removals each make at least one test fail: - The GAQL reader's 15 rules and its strict reader's three refusals each fail test_the_deploy_scan_reads_commands_as_written. So does each of _cloudbuild_problems' 17. - Continuation removal, the verb rule and the atom cut also fail test_the_tree_checks_read_both_ways, which uses them. - C10 fails with AttributeError: 'int' object has no attribute 'split': the flag allow-list crashes rather than refusing (pass 11, NIT 1). - The reads after =, @ and < were removed at c9df080. At 8c4f986 their patterns also matched _names_config. - The console reader's three refusals each fail test_config_spellings_and_the_strict_reader. - The new rules each fail test_the_tree_checks_read_both_ways: _names_config's five, _root_problems' eight and _own_file_problems' five. One of them, "the deploy workflow passes exactly one --config as written", failed nothing at 8c4f986. c9df080 adds a seed that only it catches (the same config submitted twice), and there it fails. - NIT 2's three each fail the seed test: _targets_cell's atom pass, _reads' atom pass and _words' punctuation. - The four exclusions each fail the tree test: this test file, compiled Python, the Cloud Build file's own deploy, and prose and code in the naming checks. Three of them fail the real-tree test too. The exception is compiled Python: the clean tree holds none. Pass 12 (NIT 3): not in a normal run. Python writes bytecode before the test body runs, so with the .pyc exclusion removed the real-tree test fails with 20 problems, the first a compiled copy of this test file. All four fail it in a normal run. The .pyc exclusion's removal passes it only with PYTHONDONTWRITEBYTECODE=1 and no __pycache__. - Three fail nothing: - _names_config's shortcut. It is not a rule: it skips texts no decoding could match, and the results are the same without it. - "One env map" in _cloudbuild_problems. A second map breaks the each-flag-once rule and the count of --set-env-vars, and a missing one breaks the count. The rule stays as a guard against an index error. - _words' bracket and comma replacement. _atoms cuts the same marks wherever a verdict depends on them, and no input was found on which it changes a verdict. It is not seeded. - Pass 12 (NIT 2): these are the three this run's removals found. Pass 12 made 94 removals, plus the noncharacter refusal in both readers and each of the four roots. Besides these three, and two that remove the real-tree calls and are not rules, three more fail nothing: - the decoding of the cell's own files, which is load-bearing (a decoded name in an own file is missed without it) and seeded by nothing; - "only the deploy workflow names the Cloud Build file" also requiring the deploy workflow to name it, which the one---config rule subsumes; - the U+FFFE/U+FFFF refusal in both strict readers, which is redundant: they end in PyYAML's safe_load, which refuses both, as gcloud 530.0.0's loader does.

  Recorded for the owner (§4.25). - The verifiers' seeds, replayed with paths changed only. They ran on 8c4f986 with its pins and with 1e78fad's. - Pass 11's 13 (vfy12/probes/seeds12/seeds.py, unchanged). Its S7 variant without the digest edits the old test file, so it is not replayed.

  Seed	With 8c4f986's pins	With 1e78fad's pins
  S1: a script in the cell's directory names the reference manifest through a variable; a new workflow runs it	test_the_deploy_keeps_live_mutations_off	passes
  S1arm: S1, with the reference manifest's live-mutations value flipped	test_the_deploy_keeps_live_mutations_off	passes
  S1b: a file in the cell's directory names the reference manifest	test_the_deploy_keeps_live_mutations_off	passes
  S2: a flipped manifest under docs/, applied through a variable a new workflow sets	passes (not checked: a variable)	passes
  S3: a listed workflow applies an inline manifest from a heredoc	passes (not checked: a heredoc)	passes
  S4: a second submitter; the Cloud Build file's path split by backslash-newlines, edited by sed first	test_the_deploy_keeps_live_mutations_off	passes
  S4b: a copy of the Cloud Build file made through a quoted path, edited and submitted	test_the_deploy_keeps_live_mutations_off	passes
  S5: a listed workflow updates the cell through a variable set in its step's env	passes (not checked: a variable)	passes
  S6: an arming command in a Markdown file in the cell's directory, run by a new workflow	test_the_deploy_keeps_live_mutations_off	passes
  S7: the deploy workflow edits the Cloud Build file before submitting it	test_the_deploy_keeps_live_mutations_off	test_the_deploy_keeps_live_mutations_off
  FP1: a read with a trailing comment that says "deploy", in a listed file	test_the_deploy_keeps_live_mutations_off (fails closed; NIT 3)	test_the_deploy_keeps_live_mutations_off
  FP2: a read of the Run Admin API in a listed file	test_the_deploy_keeps_live_mutations_off (fails closed; NIT 3)	test_the_deploy_keeps_live_mutations_off
  CH1: the console's deploy step gains a gcloud hook that runs a script under src/	passes (not checked: a step's environment)	passes

  • The 68 of the earlier blocks: both pins agree on every seed. The 56 arming routes are caught by both, each failing the same one test. The 12 controls and legal seeds pass both.
  • One harness change. The new own-file check reads every file under the cell's directory, including the copy of 1e78fad's GAQL pin (test_api_compat_binding_oldd14.py). That copy was moved out of the directory while the new pins ran (run_in13.py).
  • Size (NIT 4), re-measured by this session with Firestore's documented formula (dm_size13.py; computed, not run against Firestore). The record goes through the real lifecycle with every label at its bound, then through 20 manual status reads that each fail with an error cut to 200 characters. That fills the history (MAX_HISTORY = 20):

  Destinations	Field warnings	History	Bytes	Over 1 MiB
  42	50 maximal	20 failed reads	1,028,490	no
  43	50 maximal	3 entries	1,045,515	no
  43	50 maximal	20 failed reads	1,051,932	yes
  44	none	20 failed reads	1,038,974	no
  45	none	3 entries	1,055,999	yes
  45	none	20 failed reads	1,062,416	yes

  • Notes. A failed read's note is 234 bytes. With a 36-character request id, a late read's note is at most 342 bytes. That is 2,160 bytes more over a full history, which moves neither count.
  • Agreement with pass 11. Pass 11 measured 43 destinations at 1,051,932 bytes, 1,045,515 without the reads, and 44 without field warnings at 1,038,974. These agree.

3.4 Builds

• GAQL cell image built locally from the branch with a sandbox-only harness Dockerfile (proxy CA added; not committed), digest sha256:3341bd88d2791d3d11ef688a670012e4667d25f11d2415b4ff69f06ce10d292b. Offline smoke: v23/v25 → supported, not live (google_ads_credentials_not_configured), data_source: synthetic; v22 → api_version_sdk_unsupported:v22. This is a build check, not a release artifact.
• python3 scripts/deps_lock.py --check → 0 findings (18 allowlisted images).
• The image above was built before b4860c8, which changed the GAQL cell (per-call version check, 503 on synthetic channel reads, envelope fallback). It is not evidence for the final head; the deploy builds its own.
• Console: npx tsc --noEmit exit 0 and app/api/action-hub/email/send/route.test.ts 2 passed (vitest 4.1.11, after npm ci). next lint / next build were not run locally; frontend-guard runs them on the PR.

3.5 Deploy, serving revision, runtime

This session made no merge, deploy, provider call, registration or credential change (no GCP credentials; merging is the owner's gate). The owner's merge of #1299 fired the Deploy Router's seven workflows on cb7b7ff. Each run and job below was read through the GitHub API on 2026-10-01 (~20:40Z); the job conclusions are success.

What this does and does not establish: - Deployed: the 32 issues whose code ships in these images are DEPLOYED in ISSUES.json. API-A5 was recorded DEPLOYED until pass 3 (D6): its fix is the reference manifest, which no deploy reads. API-A6, API-A7 and API-B7 are deployed in part (§4.4, #1302, net-yield). Manual or dispatch-only deploys did not run: the Data Manager connector, the Klaviyo puller, the leads extender, cell37, net-yield and the website. Corrected 2026-10-02 (Copilot review of #1322): - For the three manual deploys (the Data Manager connector, the Klaviyo puller and the leads extender), "did not run" was not measured. This lane did not run them, but a manual deploy leaves no trace on GitHub, and this session cannot read Cloud Run. - The dispatch-only ones are measured on GitHub. No deploy-net-yield.yml or deploy-cell37.yml run has started since #1299's merge; their latest runs are #15 (2026-08-27) and #24 (2026-09-25). - The website was deployed later, by another lane's homepage run #140 (below). - Not runtime-verified: no row is VERIFIED. The action runner's health block is the serving revision's own selection, not provider traffic. The provider-side checks (API-E4, API-D6, API-C5, API-F5) need an operator. - Not deployed by #1299: the follow-up commits (606fb8a, e3bd49e, 22f711d, fc2a3a3, b03f33e; until pass 4, V5-10, this list stopped at 22f711d; 9e433b7 changes a test docstring only), c7d8904 (9d76b52 is a test only), 9d9cd01, 49f8d80, 02b4c3c and 9736385. The one code change in each of the last four is the Data Manager connector's, a manual deploy; the rest of them, 85b7ecb, d1e1e7b and 592fa5d (pass 10), and 8c4f986 and c9df080 (pass 11), are tests. They merged with #1302 (below). Until then, the GAQL code deployed with #1299 answered /srpvdal/run with labelled synthetic totals while it was not live (the console Overview page showed them), and its live reads returned 200 with empty rows on a provider failure. - Not measured: whether the serving GAQL revision holds credentials. The deploy config (cloudbuild.yaml) sets none, but it passes no --set-secrets or --clear-secrets, so a secret mounted on an earlier revision would survive (rule 04), and the older reference manifest mounted four. API-E4 reads the serving revision's secret references. Until pass 3 (D5) this file said the cell has no credentials. The synthetic-to-ACT path stays unreachable either way: the deploy sets GAQL_ENABLE_LIVE_MUTATIONS=false and the operation builder raises.

Website source mirror failed on the merge commit (run 36920171366). It had already failed on its 19:30Z scheduled run at 2ae5c87, before the merge (run 36914807823). It is red on the base and not this change's.

#1302's merge. The owner merged #1302 at head 482b60b on 2026-10-02 at 12:47:38Z (merge commit d98d213, first parent f17e068), before review pass 12 reported. A merge through the pull request is a push to main, which fires each deploy-*.yml whose on.push.paths match the push. Two service deploys ran, the two the PR named (deploy_router.py --base f17e068 --head d98d213 lists the same two, plus the frontend-guard check). The Backup to GCS workflow (deploy-gcs.yml) ran too (run 37008851020, success): it has no paths: filter, so it runs on every push to main, and it uploads a snapshot of the repository to Cloud Storage; it deploys no service. This paragraph first said two deploy workflows ran (pass 12, NIT 8). Each run and job below was read through the GitHub API on 2026-10-02 (~13:12Z; the Backup run ~15:40Z).

• Deployed: the GAQL cell's code from #1302, that is the code changes in 606fb8a, e3bd49e, 22f711d, fc2a3a3, b03f33e and c7d8904. The rest of #1302's GAQL changes are tests. API-A6, A7, A9, A10, A11 and A13 are DEPLOYED in ISSUES.json. The new revision's routes were not probed: the service is IAM-locked (unauth=403) and this session holds no invoker.
• The console run is not this change's alone. It built main at d98d213, which also carries #1306's console change (merge commit 80bcb6e, minutes before #1302; its own console deploy, run 37008560190, succeeded first). #1302's console change is one comment in the Klaviyo route (API-G14). The console's cloudbuild.yaml at d98d213 names EMAIL_SERVICE 0 times.
• Not deployed: #1302's Data Manager connector changes (in 606fb8a, e3bd49e, 22f711d, b03f33e, c7d8904, 9d9cd01, 49f8d80, 02b4c3c and 9736385). They ship only with the connector's manual deploy (ops/remediation/deploy_all.sh), which this lane has not run (API-F1 to F4, API-F6). Whether an operator has run it is not measured: a manual deploy leaves no trace on GitHub, and reading the serving revision needs GCP access (API-E4). This line first said "which has not run" (Copilot review of #1322).
• Not runtime-verified: as for #1299, no row is VERIFIED.

#1308's merge. The owner merged #1308, the record of #1302's merge, at head 99381e8 on 2026-10-02 at 13:29:44Z (merge commit 990bccf). Its diff is four files under docs/audits/. deploy_router.py --base d98d213 --head 99381e8 matches no deploy workflow, and no service deploy ran. The Backup to GCS workflow ran on the push (run 37013362669, success).

Homepage run #140, another lane's release. The owner dispatched deploy-homepage.yml at 7b2be4c for the /shopify Option B release (run 37033812102, job 110926990905, 2026-10-02 16:25–16:29Z). It ships the whole site from that commit, and 7b2be4c carries #1299's two site files unchanged: google_ads_gaql.py (blob 52b6eeb) and connections.py (blob 593fac5). Its log, read through the API: - it staged mizoki-website-00256-jam with no traffic; - it verified that revision and its focused routes; - it routed 100% to it. The previous revision was mizoki-website-00253-fah, run #139 of 2026-09-25, which predates #1299.

So API-G7 is DEPLOYED. This lane did not dispatch the run and has not probed the site's routes.

3.6 Pull request CI (#1299)

• Head f44a7d8: CodeQL reported 2 high alerts (py/incomplete-url-substring-sanitization, alerts 291 and 292) in two test filters that selected Google Ads calls with a substring test on the URL. 19e8a6c compares the parsed hostname instead. Every other check that had finished on f44a7d8 was green (governance gates, orphaned suites, suite wiring, measurement rails, LII cells, frontend guard, console typecheck, manifest validation, secrets scan, truth gate).
• Head 0cf37f0 (merged): all 30 check runs green when read (20:10Z) except one CodeQL Analyze (python) job still running; the CodeQL check itself reported success and both alert threads were resolved as outdated. The claim PR #1300 (f5475c6) read the same: 25 green, one Analyze (python) running.
• Later heads: see the PR's checks; this file records what was read when it was written.

3.7 Pull request CI (#1302)

Read through the GitHub API at the merge and after it (2026-10-02). - At the merge (12:47:38Z), head 482b60b carried 28 check runs: 23 success, 1 skipped (Live Cell Endpoint Tests), and 4 still running: - Lint, Test, and Validate, one of the 13 required contexts (.github/required-status-checks.json); - the console typecheck (tsc --noEmit); - the console e2e + a11y job; - one CodeQL Analyze (python) job (run 37008407046). - Read at 13:12Z: - Lint, Test, and Validate ended success (its CI run 37008411903 completed at 12:58:58Z); - the console typecheck and e2e + a11y ended success (Frontend Guard run 37008411877, 12:48:32Z); - the CodeQL Analyze (python) job of the Code Quality run 37008407046 ended success at 13:11:41Z (job 110842038518; the run completed at 13:11:42Z). This line first said it was still running at that read (pass 12, NIT 7); re-read through the API. - The Copilot reviewer and Cursor Bugbot started after the merge (12:47:40Z and 12:47:41Z).

3.8 Pull request CI (#1308)

Read through the GitHub API after the merge (2026-10-02, ~15:40Z). - At the merge (13:29:44Z), 24 check runs on head 99381e8 had started: 22 success and 2 still running: - Lint, Test, and Validate, one of the 13 required contexts (CI run 37012761822); - one CodeQL Analyze (python) job (run 37012758776). - Both ended success: the first at 13:39:57Z, the second at 13:51:58Z. - Cursor Bugbot and the Copilot reviewer started after the merge (13:29:49Z and 13:29:54Z).

3.9 #1322's merge, and two corrections to the closeout's manual deploys

Read through the GitHub API on 2026-10-03, 14:47–15:17Z.

The merge. - #1322 merged at 2026-10-03 14:46:04Z from the mediaintelligence account: head 35a58e7, merge commit d0992c1. Its first parent is b303717, #1328's merge, so main had moved since the PR's base 51055b8. - The merge brought in the PR's patch unchanged: the same 13 files and the same hunks (git diff 51055b8 35a58e7 against git diff b303717 d0992c1, index lines aside). No other change touched those files between 51055b8 and b303717. - It deployed nothing. The Deploy Router over the merge (--base b303717 --head d0992c1) matches no deploy workflow, and no deploy workflow ran on d0992c1. These five runs did, all success:

• The connectors deploy that ran at the same time belongs to #1328. Run #94 (37130753359) was created at 14:45:23Z for b303717, before #1322 merged, and its README record commit 185f358 landed at 14:48:21Z.
• The memory on d0992c1 is valid: claude_memory.py check --strict passes, reindex changes nothing, no claim is open, and CLAUDE.md is 16,206 bytes.

Correction 1: the extenders' manual builds need COMMIT_SHA (API-G3, API-G9). - The closeout gave API-G3 as gcloud builds submit --config services/intent-pullers-extender/cloudbuild.yaml. - That config tags its image gcr.io/$PROJECT_ID/intent-pullers-extender:$COMMIT_SHA (lines 6, 8, 15 and 26). The leads extender's config does the same (lines 7, 9, 16 and 26). - A manual build does not set $COMMIT_SHA. The repository records the result: - docs/lii/RUNBOOK.md:319–320: "A manual submit must pass it too, or the tag is an invalid :"; - the same runbook's troubleshooting row for "Build tag error / invalid image :" (line 988); - ops/remediation/cloudbuild.yaml:2–3.

gcloud 530.0.0's help lists COMMIT_SHA among the built-ins that --substitutions may set. - So the command as written would have stopped at the build's first step, before any deploy. This comes from the files, not from a run: the lane has no GCP access. - gcloud builds submit uploads the directory it is given, not a commit (rule 02). So the corrected commands build from a fresh export of origin/main and pass its SHA.

Correction 2: ops/remediation/deploy_all.sh is not a connector deploy (API-F5, API-F6). The closeout said "The operator deploys the connector (ops/remediation/deploy_all.sh)". That follows the service registry's deploy: field for service-data-manager-connector. The script does much more: - It deploys all ten governance services. The list is fixed (line 16), and there is no single-service option. - It builds from the operator's working tree at git rev-parse HEAD (lines 68 and 94–96). - Its deploy sets each service's env with --set-env-vars (line 110), which replaces the whole map, using four keys. A second pass puts back SELF_URL only (lines 118–123). Keys that CI deploys set on five of the ten would be gone: - service-action-runner: INVENTORY_SPEND_GATE and MIZOKI_TENANT_MAP (deploy-service-action-runner.yml:152); - service-canonical-ingestion: CANONICAL_EVENTS_BQ_TABLE, MIZOKI_TENANT_MAP and its second allowed caller (deploy-service-canonical-ingestion.yml:196); - service-policy-engine, service-decision-control-plane and service-audit-replay: MIZOKI_TENANT_MAP and per-service keys such as TENANT_LANE_VAULT, DECISION_METER and PASSPORT_SIGNING_KMS_KEY (deploy-governance-services.yml:223–278, applied at line 303). - It changes IAM and creates resources: - project roles and secret access for the runtime service account (lines 76 and 83); - the signing secret and the event topic, if they are missing (lines 82 and 88); - an invoker grant on each of the ten (line 134); - last, security/harden_auth.sh (line 139). It calls that script without PUBLIC_SERVICES, so only api-gateway is exempt (harden_auth.sh:39–52). Every other Cloud Run service in the region loses its allUsers and allAuthenticatedUsers invoker bindings (lines 57–75). That includes the intended public surfaces the script's own header lists (lines 18–24), and the leads extender, which is public by design. - Run today to ship one connector, the script would: - remove the tenant maps. Unset, MIZOKI_TENANT_MAP reads as unconfigured (contracts/mizoki_contracts/auth.py:43). - switch the action runner's inventory spend gate off. It defaults to off when unset (services/service-action-runner/execution_adapters/inventory_gate.py:47). - close public services.

The task says to preserve tenant isolation and allowlists. - The corrected step deploys the connector alone, as a new image only: - gcloud run deploy with --image and nothing else keeps the serving revision's env, service account and secrets, and leaves IAM alone. - It first runs deploy_all.sh's own gates (lines 43–66: the claims lint, the source-of-truth conformance check and tests/remediation) in the same export. - Before that, it reads the serving revision, so a missing service stops it, and that revision is the rollback target. The registry records service-data-manager-connector-00006-2c2, live-verified 2026-07-27.

How the corrected commands were checked. None of them reached GCP. Each ran in this sandbox from a clone, with a stub gcloud on PATH that logs its arguments. - Both extender blocks called gcloud builds submit once each. The source was a fresh export of origin/main (185f358), the config was the export's cloudbuild.yaml, and the substitution was COMMIT_SHA=185f35856851cb1a70c35be14ae1f7ac6c8a770f. The export holds .gcloudignore, and its config is identical to main's. - The connector block ran its real gates. It used a fresh venv built from deploy-service-canonical-ingestion.yml's pinned install lines, with mizoki_contracts not installed, so the export's copy was used through PYTHONPATH. - The claims lint was clean. - The conformance check was clean. - tests/remediation: 396 passed.

It then called builds submit with _SERVICE=service-data-manager-connector and the full SHA, and run deploy with the image only. - It stops early when it should. When the stub reported the service missing, the block stopped after its first call. When the interpreter had no pytest, it stopped at the test gate, before any build.

Not done. - None of the three deploys was run by this lane, and whether an operator has run any of them is still not measured. - The script and the registry row are unchanged. Making deploy_all.sh safe to run again (a service filter, and the public allowlist for its last step) is an owner decision.

4. Independent review

Blind passes by a separate verifier session. It received the commit range, the rules and the earlier passes' findings, never the builder's reasoning; it worked in its own detached worktrees and removed them. Each pass's fixes were written by the integrator, so they are not independent until the next pass checks them (rule 08): pass 2 checked b4860c8; pass 3 checks the follow-up PR, #1302 (606fb8a, e3bd49e and the record corrections, §4.6). Copilot also reviewed the merged head of #1299 (§4.5); that review is not blind, so each of its findings was verified before a fix.

4.1 Pass 1 — 3d5278b..d787e7e (report verbatim)

Review: 3d5278b..d787e7e (7 commits, branch claude/mizoki-api-compatibility-3ae54n), adversarial pass

I worked only in my own detached worktrees, plus a scratch repo that borrows objects from the main checkout through alternates. I have removed all of them. The main checkout is untouched: git status shows only the pre-existing untracked docs/audits/api-compatibility/. I did not touch the scratchpad/base worktree, which is someone else's. Test runs had the proxy variables unset and used a short TMPDIR.

Verdict: one blocker (a red test this change introduces), one major process risk, and several smaller defects. I found no new path that can change a customer's ads, audiences, conversions or spend, and no weakened gate or kill switch.

---

BLOCKER

1. The change leaves a red test in tests/remediation, and the evidence still says green. - Where: tests/remediation/test_wo24_google_ads_api_version.py:167 (test_wo24_sunset_list_agrees_with_the_repo_wide_sunset_guard) now fails. - Cause: commit d787e7e added v23, v24 and v25 rows to the WO-45 guard's SUNSET table (tests/governance/test_google_ads_api_version_sunset.py:45-47). The WO-24 test requires every guard version to be in the runner's SUNSET_API_VERSIONS | SUNSET_SCHEDULE. SUNSET_SCHEDULE holds only the day-precision rows (v22), so the test now fails. - Evidence: in a venv with the canonical-ingestion gate's pins (pydantic 2.13.4, fastapi 0.141.1, httpx 0.28.1), pytest tests/remediation -q gives 1 failed, 394 passed with AssertionError: {'v23', 'v24', 'v25'}. - The same file passes 40/40 at base 3d5278b and 40/40 at fdd282c. - Who runs it: deploy-service-canonical-ingestion.yml gates every deploy on pytest tests/remediation -q. Its triggers are contracts/**, the service itself, ops/remediation/* and src/shared/virtuoso_models/**. - So after merge, the next canonical-ingestion deploy fails at its gate. - PR CI stays green: ci.yaml runs only test_execution_adapters.py from that directory. This is the latent-red shape rules 07 and 08 describe. - Stale evidence: fdd282c's commit message says "tests/remediation 395 passed". That was measured before d787e7e, and EVIDENCE.md repeats it.

MAJOR

2. As named, this branch auto-merges and triggers six production deploys; no coordination claim is on record. - Auto-merge: the branch name matches claude/** in auto-merge-ai-branches.yml. None of the 65 paths matches protected_path_gate.sh (^\.github/|^deployment/terraform/|^deployment/cloudbuild|^CODEOWNERS$), so the protected-path gate would not stop it. - Deploys: deploy_router.py --base 3d5278b --head HEAD lists six workflows: - deploy-boss-agent-core - deploy-gemini-kg-pipeline - deploy-gemini-meta-worker - deploy-google-ads-gaql - deploy-service-action-runner - deploy-service-marketing-connectors - Drain risk: gemini-kg-pipeline falls under AGENTS 7.7 drain safety. - Rules: a large cross-cutting change belongs on a branch outside the auto-merge prefixes, behind a PR whose title gives the deploy count (rule 05 A.4, rule 02, rule 04), merged only after the owner's typed MERGE gate. - No claim: I found no claim for this lane in the branch's CLAUDE.md, the branch inbox, main's CLAUDE.md, or main's .claude/memory/inbox/2026-10.md (rule 05 A.2, rule 02). - Current state: not pushed yet (git ls-remote origin 'refs/heads/claude/mizoki-api-compatibility*' returns nothing). It merges cleanly with current main 67d6e41 (merge-tree exit 0).

MINOR

3. A Meta served-version warning from one tenant's call shows up in other tenants' results. - Where: services/service-action-runner/execution_adapters/meta_ads.py:243-248 stores the warning on self; :321-323 reads it back. - Adapters are built once per process (registry.build_adapters), and the warning is never cleared. - Effect: after any response carries X-Ad-Api-Version-Warning, every later update result, for any tenant, reports that warning. - Probe: one adapter, tenant acme gets a warning header, then tenant globex gets none. globex's provider_response still contains served_version_warning: 'call upgraded'. - So audited results are wrong, and state crosses tenants (the content itself is not sensitive).

4. Merchant v1 rows split one product into two knowledge-graph nodes. - Where: direct_connectors.py:338- sets no product_id on productPerformanceView rows. projector_kg.py:264 keys a Product by product_id or offer_id. - Probe output (catalog and performance rows for the same offer o1): - catalog row → product_gmc_online-en-US-o1 with {price: 1.99, currency: USD} - performance row → product_gmc_o1 with {currency: EUR} - The performance row's conversion-value currency lands in the Product node's currency field, which elsewhere means price currency. This misses requirement C ("canonical records keeping … product … currency").

5. Two sunset gates apply different policies to the same pins, on the wall clock. - The widened WO-45 guard (new FILE_PINS plus the v23–v25 rows) fails CI for any pin site. - The new inventory says credential_gated and dormant rows only warn. - Probe: - Guard _scan(2027-01-17) finds 0 problems; _scan(2027-01-18) finds 13, all v23 literals in Boss (cross_channel_cooldown_manager, mcp_connector_registry_v2, platform_rollback_integration, …). - API_LIFECYCLE_AS_OF=2027-01-18 scripts/api_lifecycle_check.py gives FAILURES (0) for the same rows, as a warning only. - CI never sets API_LIFECYCLE_AS_OF, so every PR in the repo goes red on 2027-01-18. That conflicts with the "deterministic CI checks" requirement and is the calendar time-bomb rule 01 describes.

6. In CI, the lifecycle unknowns are not visible. - test_api_lifecycle_inventory.py:106 prints the unknowns, and pytest swallows that output on a passing test. - pytest tests/governance/test_api_lifecycle_inventory.py -c tests/governance/pytest.ini (the CI invocation) gives "17 passed" with zero lines matching UNKNOWN or "no published retirement". Only the single dormant warning shows. The CLI lists 20 unknowns.

7. The coverage check skips the UI tree, which has a live Klaviyo call on a revision retiring in 14 days. - scripts/api_lifecycle_check.py:59 SOURCE_ROOTS leaves out miz-oki-command-center-ui. - app/api/action-hub/email/send/route.ts:72-76 POSTs to a.klaviyo.com/api/events/ with revision: '2024-10-15' (retires 2026-10-15 per the inventory's own table) when EMAIL_SERVICE=klaviyo. - The inventory has no row for it, and coverage_gaps reports nothing.

8. The Cloud-project remedy (API-D4) probably never fires on the real Google Ads pull. - provider_versions.google_ads_error_codes (:171-187) returns [] for a list body. - GoogleAdsAdapter.pull (direct_connectors.py:641) calls searchStream and already parses its success body as a JSON array. - google_ads_access_remedy([err]) returns None; the same error as an object returns the remedy. - The test (test_google_ads_pull_names_the_cloud_project_remedy) uses only an object-shaped error body. - That streaming errors arrive as [{"error":…}] is my inference from how REST streaming works; I did not measure it against Google.

9. The Page Insights path was recorded as compatible, but one default metric is not documented. - The default metrics at connectors/meta_signals/client.py:133-136 include page_engaged_users. - That metric is absent from the Page Insights reference for both v25.0 and v26.0. Both pages say "The API returns an invalid metric error when calling any of these metrics" about the deprecated ones. - The justification at :21-26 ("No v22.0-v26.0 changelog names … the four default Page metrics") is based on searching changelogs only — rule 01's narrow-search trap. The defect predates this change, but the change re-pins the path and records it as checked. One live call would settle it.

10. The GAQL "synthetic" label is not shown anywhere a user looks. - orchestrator.py:90 claims "so no surface can present it as one". - The cell's only live caller, the Command Center Google channel pages (app/channels/google/lib.ts gaqlGet and its components), never reads data_provenance. Grepping the UI for it finds nothing. - Those pages still render synthetic impressions, cost and ROAS as campaign metrics.

NIT

• 11. Dangling references: 13 committed files cite the untracked docs/audits/api-compatibility/2026-10-01/{ISSUES.json,EVIDENCE.md}, including the inventory's ledger and sdk.evidence and the claims-ledger C38 note. No test checks that ledger exists.
• 12. Inventory statuses:
• enhanced_conversions_integration.py is imported by the deployed Boss and gated by ENABLE_ENHANCED_CONVERSIONS. That is "dark" by the inventory's own vocabulary, but it is filed under meta_marketing.dormant, so its retired v21.0 pin only warns.
• google_ads.boss_integration_health is marked credential_gated, but credentials can be registered at runtime through an API.
• 13. GAQL checks the version only once: client.py:103 runs it when the connector is built, so the /health as_of date is frozen. A long-lived instance would keep its live client past a sunset day. The runner, gateway and Boss check on every call.
• 14. canonical_adapter.py:178 still falls back to "v23".
• 15. Developer tokens still required in Boss:
• platform_rollback_integration.py:240 sends the developer-token header.
• :1160 reports the integration enabled only if a developer token exists.
• mcp_connector_registry_v2 validate_credentials requires one (lines 1059 and 1493).
• 16. Stale skill text: skills/adwords-virtuoso/SKILL.md:136 (and its .claude and Boss JSON copies) still say v23, pinned in connector_credentials.py. No docs/skills/SKILL_DELTA_* was logged (rule 03).
• 17. Merchant provenance report_view is taken from req.resource's default even when req.query selects a different view.
• 18. The Boss health probe ignores the GOOGLE_ADS_API_VERSION override that the Boss unified client honours.
• 19. Regenerating the GAQL lock also pulled in about 15 unrelated transitive upgrades, including oauthlib 3.3.1→4.0.0 (a major version). Tests pass with the real SDK, but the PR should say so.
• 20. /api/v1/upload-requests:reconcile is not tenant-scoped. The sweep is bounded and returns counts only.

---

Checked and found correct

• Google Ads dates: I fetched the sunset page (last updated 2026-09-30): v22 "October 2026 (tentative)", v23 Feb 2027, v24 May 2027, v25 Aug 2027, "any time in that month", and "fail on or after the sunset date". The code matches. "Retired when days_left <= 0" is applied the same way in the runner, gateway, Boss, GAQL, website and offline rail, and boundary tests exist for each.
• Meta tables: the Marketing and Graph version tables match the inventory. v26.0 is "Available until TBD". The Explore placement removal (v26.0 and later) and Messenger Stories removal (v26.0 and later, all versions on 2026-10-27) match REMOVED_PLACEMENTS. No Python Meta caller sends the 2026-10-27 legacy protocol fields or Delivery Estimate fields.
• Merchant Reports v1: the URL and all field names exist in the reports_v1 reference. The Klaviyo 2026-07-15 Get Events change is as the change describes.
• SDK: google-ads 33.0.0 ships _VALID_API_VERSIONS = ['v25','v24','v23'], and get_service uses the version set at construction. GAQL tests: 73 passed with the real SDK.
• Safety:
• flags.py is untouched, and the runner's deploy workflow asserts EXECUTION_ADAPTERS_ENABLED=false.
• All Boss direct writes are refused before quota, token or network calls, with a source-literal pin on the default.
• The GAQL live mutation path still raises NotImplementedError.
• Data Manager: the consent gate runs first, then tenant resolution. Records are tenant-bound, the status route is tenant-scoped, records hold no personal data, and every transition is audited. A timeout becomes "unknown", and a blind resend gets 409.
• Images: the four provider_versions.py copies are byte-identical and ship in every image. The gateway, runner, Boss and GAQL deploys use --set-env-vars, so no stale version env survives a redeploy.
• Test results at HEAD:
• connectors 972 · Data Manager 44 · measurement-rails 497 · net-yield 208
• intent-leads-extender 7 · intent-pullers-extender 24 · website 949 · gemini-kg-pipeline 237 OK
• tests/services 39 (+1 skipped) · claims_backing 196
• Auto-merge gates: content_gates.sh exit 0 (155 gate tests passed); gate-leak scan clean; rule-03 V1–V3 greps clean on the changed files.
• The governance suite fails on exactly one test at both base and HEAD (test_pilot_report::test_default_ledger_path_is_the_in_tree_ledger), caused by my venv's editable contracts install, not by the change.
• Baseline moves in tests: each moved assertion keeps or strengthens its original intent. The one test that should have moved and didn't is finding 1.

4.2 Pass 1 dispositions (fix commit b4860c8)

Every code fix has a test that fails on d787e7e and passes on b4860c8 (measured by restoring the d787e7e file and re-running the test).

One defect was introduced and caught while fixing these: the new inventory row first quoted the console's deploy-environment flag, and tests/connectors/test_ttv_onboarding_completion_gateway.py (and its twin in the gateway suite) reads every non-doc file that carries such a flag and names the service as an environment source, so it failed with cannot read. The copy was reworded (rule 01, "fix the copy, never the rule").

4.3 Pass 2 — d787e7e..b4860c8 (report verbatim)

Independent verification of d787e7e..b4860c8 (one commit, b4860c8)

Bottom line. b4860c8 closes most of the earlier findings, and every new test it adds fails on d787e7e's code and passes on b4860c8's (I ran b4860c8's tests against d787e7e). But b4860c8 on its own has four problems: - It is red on 3 CI steps (7 failing tests). One new inventory row breaks 6 tests, and the missing ledger breaks 1 governance test. - Finding 10 is only partly fixed. The console's Google Overview page still shows synthetic metrics. - The finding-13 fix creates a latent path from synthetic data to a live mutate client, with no Decision Control Plane in between. - Dispositions for findings 15 and 19 are not recorded, and the inventory cites ledger ids (API-G13, API-G14) that do not exist.

Two commits landed in the main checkout after b4860c8 while I was running: 925d005 and f44a7d8. On f44a7d8 the 7 failures pass (115, 49 and 76 passed in the three affected files). I did not otherwise verify those two commits.

Earlier findings

#	Verdict	Evidence
1	FIXED	Ran pytest tests/remediation -q with the canonical-ingestion gate's install line. d787e7e: 1 failed (the WO-24 agreement test), 394 passed. b4860c8: 396 passed. The test is not weakened: it now checks every row of API_VERSION_SUNSETS against the guard, dates included. Mutation check: moving the v24 date to 2027-05-02 makes it fail.
3	FIXED	Nothing is stored on the adapter any more: grep finds only the staticmethod and local variables, and no caller of the old _read_node is left. The new cross-tenant test fails on d787e7e and passes on b4860c8.
4	FIXED	Performance rows now have record type product_performance and the projector skips them as unmapped; the conversion currency moved to conversion_value_currency. The new projector test fails on d787e7e. Side effect (NIT): the default Merchant pull (resource=product_performance) now puts nothing in the KG, not even the account_gmc_* PlatformAccount node. The commit does not mention this.
5	FIXED	I swept every day from 2026-10-01 to 2027-08-15 through both gates. At b4860c8 both first fail the Boss v23 pins on 2027-01-18. At d787e7e, api_lifecycle_check.py --as-of 2027-01-18 gave 0 failures (a warning only).
6	FIXED	Unknowns are now raised with warnings.warn. tests/governance/pytest.ini has no filterwarnings or -p no:warnings. A passing run printed UserWarning: provider API lifecycle: UNKNOWN …, 20 selection(s).
7	FIXED	The console is now scanned (1172 tracked files) and the route is pinned to revision 2026-07-15. Removing the row in memory produces the coverage gap; restoring it gives none. vitest: the new test gets a 500 on the old route (empty 202 parsed as JSON) and passes on the new one (2/2). Klaviyo docs confirm revision 2026-07-15 is GA, 2024-10-15 is "supported until 2026-10-15", and the reference uses the {data:{type,attributes}} body. Governance note: see N4.
8	FIXED	The gateway passes the raw parsed body (_json_body) on to the remedy lookup. The four copies are byte-identical (sha256 65d4dbd2…). On d787e7e the [stream-array] case returns 502; on b4860c8 it returns 503 with the remedy.
9	FIXED	Checked against developers.facebook.com/docs/platforminsights/page/deprecated-metrics ("Updated: Mar 2, 2026"): page_engaged_users was deprecated 2024-03-14; page_fans (alternative page_follows) and page_impressions (alternative page_media_view) on 2025-11-15. page_views_total and page_post_engagements are still in the v26.0 reference. NIT: RETIRED_PAGE_METRICS (client.py:41) lists only those 3, so e.g. page_impressions_unique would still be sent. Nothing in production calls this method.
10	PARTIAL	The eight /channels/google/* GET routes now return 503 unless allow_synthetic=true (checked in-process). But app/channels/google/page.tsx:32 posts to /srpvdal/run (main.py:120, not gated), which returns 200 with synthetic numbers: total_cost 1016890.83, total_conversions 30854.86, account_cpa 32.96. The page shows them as Total Cost / Conversions / Account CPA (page.tsx:112-114) without reading data_provenance. The deployed cell has no credentials, so this is what the production Overview page shows.
11	PARTIAL at b4860c8	The guard test is correct, but b4860c8's tree has 0 files under docs/audits/api-compatibility. So test_the_inventory_names_a_ledger_that_exists (test_api_lifecycle_inventory.py:118) fails at b4860c8. The ledger arrives in f44a7d8.
12	FIXED	Probe: the Boss Meta client with api_version: None resolves to …/v26.0; v21.0 raises VersionRefused.
13	FIXED, but introduces N3	today=None is stored, so each refresh uses the real date. extract, /health and data_provenance all refresh.
14	FIXED	The fallback is now the configured version, or "unknown". The WO-45 guard flagged canonical_adapter.py's v23 for 2027-01-18 at d787e7e and no longer does.
15	NOT FIXED; disposition unsound/incomplete	No code change. The only record is ISSUES.json API-G12 in f44a7d8, and it is wrong in three ways (below). Leaving the token requirement in place arms nothing, but the plan in the next point should not be followed.
16	Disposition sound (outside range)	The SKILL_DELTA in f44a7d8 is a DRAFT and not applied, which is what rule 03 requires. skills_sync --check and ontology_skills_sync --check both report OK.
17	FIXED	report_view now comes from the row (merchant_record_type). The new test fails on d787e7e.
18	FIXED	The probe now uses environment override, then class default, the same order as _api_base (config api_version is None by default). The new test fails on d787e7e. The Boss deploy sets no override.
19	NOT ADDRESSED / not recorded	The lock file is unchanged in b4860c8, and git grep -i oauthlib f44a7d8 (excluding lock and requirements files) finds no disposition. My measurement says the risk is low (details below).
20	Disposition sound	reconcile_due returns counts only (recovered/scanned/finalized/still_open/expired). It reads only records with next_check_at <= now; limit ≤ RECONCILE_BATCH; callers are verify_caller platform identities. Not in the docstring: recover_stale_sends changes state across tenants (in-flight to unknown). The background loop makes the same transition, and nothing is disclosed.

Finding 15, why API-G12 is not a sound disposition: - It calls platform_rollback_integration a "dormant path", but it is imported by the deployed Boss (boss_agent_core.py:2480), and the inventory classifies it credential_gated. - It never names mcp_connector_registry_v2, which requires developer_token (lines 1059 and 1493). - Its next action is "remove the header when a path is armed". PlatformRollbackManager makes direct Google and Meta mutations from Boss with no DCP or DIRECT_WRITES gate (grep finds none). The disposition should say this path must not be armed outside DCP → action-runner, not prepare it.

Finding 19, measured risk. google-ads 33.0.0's oauth2.py uses only google.oauth2 / google.auth. Nothing in the cell imports oauthlib. oauthlib 4.0.0 imports cleanly alongside requests-oauthlib 2.0.0 and google-auth-oauthlib 1.5.0. The cell suite passes on the lock (76 passed).

New defects

• N1 BLOCKER (b4860c8 alone): 3 CI steps red.
• Cause: production/provider-api-lifecycle.json:1385. The new console row's gate text quotes --set-env-vars, and the TTV scanners report production/provider-api-lifecycle.json:1385: cannot read.
• Failing tests:
  • tests/governance/test_ttv_outcome_actual_stamps.py: 2 tests (governance spine step).
  • tests/connectors/test_ttv_onboarding_completion_gateway.py: 2 tests (ci.yaml connectors step and the canonical-ingestion deploy gate).
  • services/service-marketing-connectors/test_tenant_economics_ttv_stamp.py: 2 tests.
• All of these pass at d787e7e.
• Together with the ledger test in finding 11, governance is 3 failed / 4344 passed.
• 925d005 rewords the text and f44a7d8 adds the ledger; all 7 pass at f44a7d8.
• N3 MAJOR (latent): synthetic actions can reach a live mutate client without the DCP.
• How it happens:
  • The ACT stage keeps its own reference to the Google Ads client, captured when the cell is built (orchestrator.py:54).
  • On the sunset day, refresh_version_status drops only the connector's reference (client.py:159).
  • The run then senses the synthetic stream, and synthetic runs skip the DCP (governed = None if synthetic, orchestrator.py:231).
  • The locally authorized actions then go to the executor (orchestrator.py:238), which still holds the live client.
• Probe (fake SDK client; approval_required mode with the request's own human_approved=True; dry_run false; live mutations flag on):
  • Sunset day: 500 synthetic events and 58 authorized actions. The executor called get_service('AdGroupCriterionService', version=None) on the stale client.
  • It stopped only at act.py:98's NotImplementedError.
  • The control run one day earlier never reached ACT.
• This state could not occur at d787e7e. It is not reachable today: the live-mutations flag is off by default, the cell has no credentials, and the operation builder is unimplemented.
• Fix: drop or re-read executor._client on refresh, and refuse ACT whenever the data is synthetic.
• N2 MINOR: inventory cites ledger ids that do not exist. It cites API-G13 (lines 621 and 626) and API-G14 (1384 and 1389). The ledger landed in f44a7d8 holds 45 ids, E1 through G12, with no G13 or G14.
• N4 MINOR, governance: the Klaviyo fix makes a non-DCP write route work.
• /api/action-hub/email/send is on the console's frozen list of routes with no in-handler caller check ("sends email through SendGrid/Klaviyo with the platform API key").
• Klaviyo's reference says Create Event upserts the profile and triggers flows unless backfill is true. So after this fix, one environment variable (EMAIL_SERVICE=klaviyo plus a key) turns on a working provider write outside DCP → action-runner (law A.7).
• It is not armed: EMAIL_SERVICE is not in the console's cloudbuild --set-env-vars, and the only mounted secret is the Supabase key.
• The inventory row presents arming as a configuration step and does not mention the DCP rule.
• N5 MINOR, package docs in f44a7d8 (outside the range) contradict b4860c8:
• CLOSEOUT still says only live/dark rows fail and that the Boss v23 pins only warn (from 2026-11-03), and omits the 2027-01-18 CI-fail date.
• It says "6 deploy workflows". The deploy router over d787e7e..b4860c8 and over 3d5278b..b4860c8 plans 7: boss-agent-core, gemini-kg-pipeline, gemini-meta-worker, google-ads-gaql, service-action-runner, service-marketing-connectors and ui, plus frontend-guard.
• RESUME says "seven commits … d787e7e".
• The CLOSEOUT "Independent review" section is a placeholder.
• EVIDENCE's GAQL test counts are stale (70+3 / 73 written; now 73+3 / 76).
• N6 NIT: refresh race. A health request on another thread can clear _client between _search_stream's None check and _service(). The resulting AttributeError is caught as an extraction error. It can only happen on the sunset transition.

Test runs

Fresh Python 3.11 venvs, install lines copied from the b4860c8 workflows; proxy variables unset; short TMPDIR. Results as b4860c8 → d787e7e:

Suite	b4860c8	d787e7e
Canonical-ingestion gate: tests/remediation	396 passed	1 failed (finding 1), 394 passed
Canonical-ingestion gate: tests/connectors	2 failed (N1), 585 passed	584 passed
Canonical-ingestion gate: test_kg_write_perimeter.py	68 passed	68 passed
ci.yaml governance (-c tests/governance/pytest.ini)	3 failed (N1, finding 11), 4344 passed, 7 skipped	1 failed*, 4344 passed
ci.yaml services/service-marketing-connectors	2 failed (N1), 386 passed	388 passed
ci.yaml test_execution_adapters.py	178 passed	177 passed
ci.yaml tests/market_signal	294 passed	292 passed
ci.yaml cell37	33 passed	33 passed
GAQL, lock venv (google-ads 33.0.0)	76 passed	73 passed
GAQL, suite-wiring venv	73 passed, 3 skipped	70 passed, 3 skipped
Suite wiring: tests/services	41 passed, 1 skipped	39 passed, 1 skipped
Suite wiring: data-manager connector	44 passed	44 passed
Suite wiring: claims_backing	196 passed	196 passed
Suite wiring: "# MIZ OKI 3.5/tests"	949 passed	949 passed
Suite wiring: connector_gateway	17 passed	17 passed
Orphaned suites	980 passed	980 passed

*The d787e7e failure is test_pilot_report::test_default_ledger_path_is_the_in_tree_ledger. It is an artifact of my setup: the venv's editable contracts install pointed at the b4860c8 worktree, so the path comparison crossed trees. It passes in the matching tree, and I do not attribute it to either commit.

Also at b4860c8: - .github/scripts/content_gates.sh: rc 0 (155 passed). - Rule-03 V1–V3 greps on the diff: no hits. - Console: vitest route test 2/2; lib/auth, the no-public-backend-url ratchet and app/api/action-hub 192/192; tsc --noEmit clean; next lint clean on the two changed files.

Not checked, and disclosures

• Constraint breach. While checking whether oauthlib is on the cell's runtime path, I called GoogleAdsClient.load_from_dict with dummy credentials ("x"/"y"/"z"). The library refreshes the token eagerly, so one request went to Google's OAuth token endpoint and came back invalid_client. No real credential was involved and no Google Ads API call was made, but this broke the no-provider-calls rule.
• next lint ran without NEXT_TELEMETRY_DISABLED, so it may have sent a Next.js telemetry ping.
• Shared venvs. My first venv build reused the names scratchpad/venv-ci and venv-cig, which belonged to another session (created 15:02 and 15:51). uv reinstalled into them and pointed their editable mizoki_contracts at my worktree. I pointed them back to /home/user/MIZOKICloudRun/contracts (finder MAPPING and direct_url.json), which is what that session's other venvs use. Their package versions may have changed. All my measurements came from fresh venvs under scratchpad/vfy.
• Main checkout. One early git status there ran before I turned optional locks off. Everything else there was read-only.
• Not checked:
• What a real searchStream error body looks like (Google's docs do not show one).
• Live behaviour at Klaviyo or Meta, and the deployed revisions (no GCP access).
• The full console vitest suite and Playwright.
• The CI runner's exact git and Python builds.

Cleanup. All five of my worktrees and /tmp/v2 are removed, along with my venvs. The base and memwt worktrees were not touched. Logs are in /tmp/claude-0/-home-user-MIZOKICloudRun/3197261c-38e1-556d-ba3d-19d3526cd8c2/scratchpad/vfy/ (ci-head.out, ci-prev.out, cig-*.out, wire-*.out, content-gates-head.out, cmp_gates.py).

4.4 Pass 2 dispositions (fixes in 606fb8a, authored as 8e961af; record in the commit that adds this section)

Each code fix has a test that fails on b4860c8's code and passes on 606fb8a (measured by restoring the old files in a throwaway worktree and re-running the test).

Verifier disclosures, recorded as given (§4.3): one OAuth token request to Google with dummy credentials while probing an import path (invalid_client; no real credential and no Google Ads call); a possible Next.js telemetry ping from next lint; and reinstalls into this lane's venv-ci / venv-cig, which it repointed. Responses: pass 3 runs any code that can build a provider client inside unshare -rn, with NEXT_TELEMETRY_DISABLED=1, in venvs of its own; the 8e961af sweep (§3.2) used fresh venvs only.

4.5 Copilot review of #1299 (head 0cf37f0, posted 20:20Z, after the merge)

Copilot's overview: "Synthetic data can still reach execution, provider failures can appear as valid empty reports, and reconciliation is race-prone." Its three inline comments, verbatim:

orchestrator.py 231–233 (high). When synthetic is true, skipping _govern leaves the locally authorized actions in authorized; lines 234–240 then pass them to the executor. With dry_run=false, human_approved=true, and live mutations enabled, synthetic metrics can therefore drive provider mutations without DCP authorization. Clear authorized for synthetic runs rather than merely bypassing _govern.

request_tracking.py 411–415 (medium). The due/rate-limit checks occur before the provider call and are not claimed transactionally. Two concurrent reconcilers (for example the background loop plus scheduler/manual refresh) can both fetch the same request status and consume two checks; a representative concurrent run produced two provider calls and incremented checks twice. Acquire a per-record transactional lease/check claim before fetch, then finalize that claimed attempt afterward.

main.py 253–256 (medium). This gate only proves that a client object was constructed. GoogleAdsConnector.extract() catches provider/auth failures and returns ExtractionResult.error, but cell.sense() discards that error; these channel routes then return HTTP 200 with empty rows. Propagate extraction failures to these routes (for example as a 502/503) so expired credentials or provider outages do not look like valid zero-data reports.

The replies on the three threads name these commits, and the threads are resolved; the fixes deploy when #1302 merges (the Data Manager one by operator deploy).

4.6 Pass 3 — follow-up PR #1302 (3f89cd0..db3c271, report verbatim)

The verifier received the range, the earlier reviews (in this file) and the rules; never the builder's reasoning. It ran 2026-10-01 from 21:00Z to about 21:42Z. Its report, verbatim:

Independent verification, pass 3: 3f89cd0..db3c271 (draft PR #1302)

Bottom line. I found no blocker. The code does what the range says: - A synthetic run authorizes nothing, and the executor re-reads the connector's client before ACT. - While the connector is not live, every route that serves SENSE rows, totals or account listings answers 503 unless allow_synthetic is set. - A failed live extraction answers 502. - A Data Manager status read is claimed inside one transaction.

Every gate I ran is green, except two reds caused by my environment (the shallow clone, and the sandbox's commit signer). Each is explained below.

What is wrong: 1. MAJOR, latent. The new rule "a live run stops on any failed extraction" meets a registry query, change_status_v1, that carries no LIMIT unless the caller passes one. The installed v25 SDK documents that LIMIT as required. Once credentials land, /channels/google/decisions and every no-limit run will always answer 502 and plan nothing. 2. One of the two TestSyntheticRunsNeverMutate tests passes on the old code, although the record, the commit message, the PR body and the Copilot reply all say both fail there. 3. "Nothing persisted" is false for a partial failure: the raw rows of the queries that answered are saved during SENSE. 4. The Data Manager lease is stamped with the sweep's start time, so a slow sweep writes claims that have already expired. 5. Several record inaccuracies, the largest being API-A5 marked DEPLOYED and an unsupported "no credentials are mounted".

Basis for the old-code runs: git diff --stat shows the GAQL and Data Manager code identical at b4860c8, 0cf37f0 and 3f89cd0. I ran the new tests against 3f89cd0's code restored in my own worktree.

Pass-2 and Copilot items

Item	Verdict	Evidence I produced
N2	FIXED	Catches the original case: the new guard, run on the f44a7d8 tree, fails with ['API-G13', 'API-G14'] in the inventory. Mutations at db3c271: • an id the ledger lacks, added to RESUME.md → fails; • API-G14 removed from ISSUES.json → fails in all four files; • an id the ledger lacks, added to the inventory → fails; • unmodified → passes. Limits: D12.
N3	FIXED	Code: orchestrator.py:254-261 empties authorized for a synthetic run, :271 re-reads the client, :272 forces a dry run. Single call site: git grep finds one executor call in the repo, orchestrator.py:274. It is reached only through run(), from /srpvdal/run, /srpvdal/run-mcc (per child) and /channels/google/decisions. Probe (never-live cell, approval_required + human_approved, live-mutations flag on): old code 28 locally authorized → 28 executions; new code 28 → 0 authorized, 0 executions. Residuals: D2, D13.
N4	FIXED (as a disposition)	Recorded: the comment at route.ts:78-82, and the inventory gate text names law A.7. Dark today: EMAIL_SERVICE is absent from the console cloudbuild.yaml, which uses --set-env-vars and --set-secrets, both of which replace the whole map; the route defaults to 'mock' (route.ts:40). Still open: the route stays ungated (api-route-roles.ts:92-95). No test pins EMAIL_SERVICE's absence from the deploy env map.
N5	FIXED	CLOSEOUT now has the 2027-01-18 fail date, "7 services" and a filled review section. RESUME's commit list and §3.2's GAQL counts name their commits. New inconsistencies: D8, D9.
N6	FIXED (the stream path)	Fixed: client.py:243-245 snapshot, passed to _search_stream and _service (:272, :313). Remaining read: validation between the snapshot and the stream (:252-253 → _live_field_lookup :184-199) still reads self._client. It is benign: the lookup catches the error and _lookup falls back to the static catalog.
Finding 10	FIXED in #1302 (not deployed)	Route table: I enumerated app.routes (23 method/route pairs). With the connector not live and no allow_synthetic: the 8 channel routes, the 3 /srpvdal POSTs and the MCC listing answer 503; /gaql/*, /health, /metrics and the docs pages answer 200 with no rows. Test: the extended route test fails on the old code. Residual: D11.
Finding 15 (disposition)	ACCURATE, except one carried error	Rollback manager (platform_rollback_integration.py): • token sent but never checked: :186, :240 • OAuth from GOOGLE_ADS_CLIENT_ID/_SECRET/_REFRESH_TOKEN: :187-189, :207-227 • enabled appears only in get_status: :1160 • mutates with validateOnly false: :275, :285, :291, :362, :447 • Meta calls on graph.facebook.com: :570 Boss core: boss_agent_core.py:2480 (import), :2511 (default "true"), :27823 (MCP tools registered at startup). Registry: validate_credentials requires developer_token at lines 1059 and 1493; it has no caller anywhere in the repo. Boss deploy: cloudbuild.v5.yaml uses --set-env-vars and --set-secrets and names no Google Ads or Meta variable. Error: D7.
Finding 19 (record)	ACCURATE	The GAQL lock moved 15 pins from 3d5278b to db3c271. The only major moves are google-ads 25.1.0 → 33.0.0 and oauthlib 3.3.1 → 4.0.0; the other 13 match the list.
Finding 20 (docstring)	FIXED	The docstring now names recover_stale_sends. reconcile_due calls it (request_tracking.py:496), and the background loop runs reconcile_due.
NIT (finding 4)	ACCURATE	direct_connectors.py:909 defaults to product_performance. merchant_record_type returns product_performance (:397-410), which projector_kg.py does not map (only product_report, :345). account_gmc_* is created only in _map_merchant_product (:265).
NIT (finding 9)	ACCURATE	RETIRED_PAGE_METRICS lists 3 metrics (connectors/meta_signals/client.py:41). get_page_insights has no caller beyond its own fake and the tests. The acceptance was reworded.
Copilot, high: synthetic runs keep authorizations	FIXED	Same evidence as N3. Only the sunset-day test is a real test (D2).
Copilot, medium: two reconcilers read one record twice	FIXED when reconcilers share a clock; gap in long sweeps	Both new tests fail on the old code (['req-1', 'req-1']); the suite has 46 passed. Gap: D4.
Copilot, medium: failed extraction reads as empty	FIXED	TestExtractionFailuresAreErrors (3 tests) fails on the old code. All 12 reading routes answer 502. Side effects: D1, D3.

New defects

D1 — MAJOR (latent): no live run without a limit can succeed, and the Decisions page will always error once Google Ads is live - Where: - gaql_registry.py:303 defines change_status_v1. - build() adds LIMIT only when limit is truthy (:41-42). - The query is in run()'s default set. - main.py:386 (decisions) and :339 (changes) pass no limit. - orchestrator.py:175-186 returns before REASON on any failed extraction. - Why it will fail: the installed SDK's v25 ChangeStatusErrorEnum documents LIMIT_NOT_SPECIFIED: "The change_status search request must specify a LIMIT." - Scenario: credentials are mounted, and the console Decisions page calls /channels/google/decisions. - change_status_v1 fails, the run stops after SENSE, and the route answers 502 every time. - The same happens on /channels/google/changes, and on any /srpvdal/run or /srpvdal/sense call without a limit. - In /srpvdal/run-mcc without a limit, every child counts as failed. - Before this range the failure was silent, and the other nine queries still produced decisions. The Overview page passes limit: 50, so this query does not break it. - Fix: - Give change_status a mandatory LIMIT of at most 10,000 in the registry. - Pin it with a test over every registered query built with limit=None. - Decide whether an auxiliary query's failure should block planning on the performance queries.

D2 — MINOR: one of the two new "synthetic never mutates" tests passes on the old code - Where: test_api_compat_binding.py:292-303, test_a_never_live_cell_authorizes_nothing_for_execution. - Why it is vacuous: it runs in autopilot mode, where the local gates authorize only low-risk action types, and on this synthetic data none is. - Probe on the old code: autopilot → 0 locally authorized; approval_required + human_approved → 28 authorized, 28 executions. - Measured: the test PASSES on the old code. The other 5 new GAQL tests fail there. - False claims: API-A7's evidence ("both tests fail on 0cf37f0's code"; "asserts some local gate authorized an action"), the e3bd49e commit message, the #1302 body and the Copilot reply. - Fix: use approval_required with human_approved=True, and assert that some gate authorized before asserting 0.

D3 — MINOR: "nothing persisted" is false for a partial failure - Where: SENSE saves raw rows (orchestrator.py:81-82) before run() checks the errors. The run's own warning (:184, returned in the API result) says "nothing persisted". - Probe: a live fake client where only change_status_v1 fails → 9 save_raw_rows calls, then that warning. - Repeated in: API-A9's acceptance, the #1302 body and the Copilot reply. - Why no test sees it: the new test uses a client where every read fails (:364). - Fix: buffer the raw rows until after the error check, or reword. Add a partial-failure test either way; that case is also where the old and new behaviour differ (old code planned 2 actions, new code stops).

D4 — MINOR: the Data Manager lease is anchored to the sweep's start - Where: request_tracking.py:431 stamps check_claimed_at with the caller's now, and reconcile_due passes one now, the sweep's start, to every record (:492-511, :504). - Probe: 12 due records, each read taking its 30 s timeout. The 12th claim is written 330 s into the sweep but stamped at its start. A concurrent reconciler at the real time sees it as lapsed and reads again: 2 reads, checks 2. - Scope: this is the case Copilot raised, during a slow provider period. The lease docstring's "a claim outlives its read" does not hold here. - Fix: stamp and compare the lease against the wall clock at claim time. Optionally, store a claim token so the finalizing write clears only its own claim.

D5 — MINOR: "no credentials are mounted" on the GAQL cell is unsupported present tense - Where: CLOSEOUT.md:49 and :94-95, EVIDENCE.md:513-515, API-A7's evidence. - Why it is unsupported: - The only basis is cloudbuild.yaml. It sets --set-env-vars but passes no --set-secrets or --clear-secrets, so a secret env var mounted on an earlier revision survives (rule 04). - The old manifest at 3d5278b mounted GOOGLE_ADS_CLIENT_ID, _CLIENT_SECRET, _REFRESH_TOKEN and _DEVELOPER_TOKEN from Secret Manager. - The deploy's verify step (job 110563954917) reads only the control plane and the unauthenticated 403, never /health. - Fix: say "the deploy config mounts none". Measure the serving revision's secret references, or an authenticated /health google_ads_live, under API-E4.

D6 — MINOR (record): API-A5 is marked DEPLOYED, but its fix ships nowhere - Its fix is cloud-run-google-ads-gaql.yaml, now headed "REFERENCE MANIFEST — not the deploy path"; the deploy uses gcloud run deploy flags. - Should be NOT_APPLICABLE, which makes the counts 32 DEPLOYED and 16 NOT_APPLICABLE. - The other 32 DEPLOYED issues map to files the Deploy Router matched for the seven workflows (cb7b7ff^1..cb7b7ff). The rails ship in the Boss image (Dockerfile.v5:60). Nothing is VERIFIED.

D7 — NIT (record, carried from 3f89cd0): API-G13 says "13 lines" and "the WO-45 guard's _scan(2027-01-18) reports the same 13 pins" - Measured: _scan reports 12 lines on both db3c271 and 3f89cd0, and git grep finds 12 v23 pins in the Boss tree. - The dated escalation itself is right. A day-by-day sweep from 2026-10-01 finds the first failure of both gates on 2027-01-18.

D8 — NIT (record): EVIDENCE.md:256 contradicts §3.5 - Line 256 still opens §3 with "Nothing below is deployed or live-verified", while §3.5 now lists the deploy runs and "Deployed: the 33 issues…". At 3f89cd0, §3.5 said "None."

D9 — NIT (record): miscounts - CLOSEOUT.md:19 and RESUME.md:27 say "53 implemented and tested". Measured: 53 IMPLEMENTED, 52 of them TESTED (API-G17's testing is NOT_APPLICABLE). - CLOSEOUT.md:165-166 says pass 2 "verified every pass-1 fix except three". Pass 2's table has four rows not FIXED or sound: 10, 11, 15 and 19. - API-A2 and API-A3 stay REVIEW_READY although 606fb8a edited _service() and extract()'s labelling. Their tests pass.

D10 — NIT (record): revision 00079-ptp was built from main (e480aaa), not from cb7b7ff - §3.5 and the deployed issues say "Deploy Marketing Connectors run 36920171263 at cb7b7ff … 00079-ptp". - That workflow checks out ref: main (deploy-service-marketing-connectors.yml:60-64 and :112-116). - e480aaa was on main by 20:15:35Z (run 36920255631 created), before this job's checkout at 20:16:21Z. Its README push shows e480aaa95..e7348d5c9. - e480aaa contains cb7b7ff, so the change is in the deployed code either way; only the attribution is imprecise.

D11 — NIT: a request straddling the sunset can still get synthetic data without allow_synthetic - _require_live (main.py:253-272) checks before SENSE, and the client is dropped inside extract's own refresh. - Probe: the check passes on 2027-07-31 and the extraction runs on 2027-08-01. /channels/google/campaigns answers 200 with 3 synthetic rows, and /srpvdal/run answers 200 with synthetic totals (30 sensed). They are labelled only in data_provenance, which the console does not read. - The window is the requests in flight at the sunset instant. - Fix: refuse from the extraction's own provenance.

D12 — NIT: limits of the N2 guard - It fires on any text of the shape "API", hyphen, uppercase letter, digits that is not a ledger id. I seeded a provider version written that way in EVIDENCE.md and the test failed. - It does not scan ISSUES.json's own references. A seeded dangling depends_on passes; none dangle today. - Because EVIDENCE.md quotes reviews verbatim, a review that names an id not yet in the ledger would fail CI unless the quote is edited. This report deliberately writes no such id.

D13 — NIT: test and design gaps - No partial-failure test (see D3). - By reading: the synthetic dry-run override (orchestrator.py:272) is not pinned on its own, because authorized is already empty for a synthetic run. - The executor's client is shared state written per run (:271) rather than passed to execute(). A thread interleave at the sunset instant could store a just-dropped client; this is by reading only, and needs live data and armed mutations.

Outside the range, recorded for the owner (not introduced here): - _live_field_lookup queries a segmenting field. The installed v25 GoogleAdsField has no such field (grep count 0), so in live mode every lookup fails and falls back to the static catalog, after one failing provider call per field per extract. - The GAQL image contains no mizoki_governance, so _govern always returns None in production. A live run's ACT then rests on the request's own human_approved. It is latent today: GAQL_ENABLE_LIVE_MUTATIONS=false and the operation builder raises.

Deploy and publication claims (GitHub API, read-only)

Run	Head SHA	Conclusion	Job	Log matches the record
36920171359	cb7b7ffc…	success	110563954917	yes: Ready=True latestReady=google-ads-gaql-cell-00015-4qn latestCreated=… unauth=403
36920171187	cb7b7ffc…	success	110563954595	yes: revision boss-agent-adk-00423-lqd, runtime 6.49.4, SRPVDAL passed, registry 118 entries
36920171312	cb7b7ffc…	success	110563954483	yes: /health reports v25, sunset 2027-08-01, {v22: 2026-10-07}, Meta v26.0, CAPI v25.0, every flag false, allowlist 0
36920171263	cb7b7ffc…	success	110564512882	yes (00079-ptp); but see D10 for which tree it built
36920171300	cb7b7ffc…	success	110564520180	yes: image gemini-kg-pipeline:c4087d5a-…
36920171356	cb7b7ffc…	success	110563954663	yes: "Wire Meta credentials" skipped; the job exists
36920171249	cb7b7ffc…	success	110563954837	yes: HTTP Status: 307
36920255631	e480aaa	success	—	the run exists and succeeded

Other publication checks: - The website mirror runs 36920171366 and 36914807823 both failed with the same cause, a missing WEBSITE_MIRROR_TOKEN. - #1299 merged at head 0cf37f0. The merge commit time is 20:14:51Z; the API's merged_at is 20:14:52Z. #1300 merged_at is 20:14:12Z. - #1302 is draft, head db3c271, base fa1cc19. main gained #1301 (two docs files) since 3f89cd0, and git merge-tree of the PR head onto fa1cc19 is clean. - Copilot's three threads on #1299 are resolved and their replies name the commits. Two replies repeat the D2 and D3 claims.

Ledger counts reconcile apart from D6 and D9: DEPLOYED 33, IN_PROGRESS 3, OPEN 10, NOT_APPLICABLE 15; runtime OPEN 46, BLOCKED_EXTERNAL 4 (E4, D6, C5, F5), NOT_APPLICABLE 11; 0 VERIFIED anywhere.

Test runs

All runs below were in fresh Python 3.11.15 venvs I built with uv from each job's install lines, inside unshare -rn (loopback only), with proxy variables unset and TMPDIR=/tmp/v3.

Command	Environment	Result
python -m pytest "src/cells/google_ads_gaql/tests" -q -p no:cacheprovider -o addopts=""	suite-wiring install line	db3c271: 78 passed, 3 skipped. 3f89cd0: 73 passed, 3 skipped
same	requirements.lock.txt + pytest (google-ads 33.0.0)	81 passed
the new GAQL tests, against the restored 3f89cd0 code	wiring venv	5 failed, 1 passed (D2)
python -m pytest "services/service-data-manager-connector/tests" …	wiring venv	46 passed. Old code: 2 failed (the new ones), 44 passed
pytest tests/governance -c tests/governance/pytest.ini	ci.yaml lint-and-test line + -e contracts + docs/whitepapers/requirements.txt	4348 passed, 7 skipped, 0 failed, 6227 subtests (see Disclosures for the discarded first run)
MIZOKI_STORE=memory pytest tests/connectors -q; … services/service-marketing-connectors -q	ci.yaml pins	615; 399 passed
pytest tests/remediation -q; pytest tests/connectors -q; pytest tests/test_kg_write_perimeter.py -q	canonical-ingestion gate install lines	396; 615; 68 passed
python -m pytest "docs/audits/tests" …	wiring venv	1 failed (test_wo31_register: git show 26bec9c6b… absent in this shallow clone), 7 passed. Identical on 3d5278b
bash .github/scripts/content_gates.sh	governance-gates install line first on PATH	rc 0, 155 passed
vitest run app/api/action-hub/email/send/route.test.ts	npm ci --ignore-scripts, vitest 4.1.11, Node 22.22.0, NEXT_TELEMETRY_DISABLED=1, unshare -rn	2 passed
python3 scripts/api_lifecycle_check.py	gates venv	rc 0, FAILURES (0)
python3 scripts/gate_leak_scan.py --check	gates venv	rc 0: "0 new file(s); 0 grown; 0 stale baseline row(s)"
python3 scripts/claude_memory.py check --strict	gates venv	rc 0: "structurally valid"
the three governance files named in §3.2	ci venv	121 passed (db3c271), 120 (3f89cd0)
deploy_router.py --base 3f89cd0 --head db3c271	ci venv	deploy-google-ads-gaql (5 files), deploy-ui (1), frontend-guard (1)

Not checked

• Live provider behaviour. The change_status LIMIT requirement comes from the installed SDK's own documentation, not a live call. I did not check whether conversion_segmentation_v1's cost metric is compatible with segments.conversion_action.
• The serving revisions' env and secret mounts (no GCP access).
• The full console vitest suite, tsc, lint and Playwright.
• The CI runner's exact git (2.55.0) and Python versions. The sandbox has git 2.43.0 and Python 3.11.15.
• The ci.yaml jobs outside the range's scope (orphaned suites, the other suite-wiring lines, skills, measurement rails).
• Gates on #1302's real merge result with fa1cc19. I only confirmed that merge-tree is clean.

Disclosures

• First governance run discarded. It gave 185 failures caused by my environment. The sandbox's global commit.gpgsign=true calls a signing program that needs a local service, which the empty network namespace cannot reach. I re-ran with signing turned off for the test processes through GIT_CONFIG_COUNT environment variables only; no config file was changed.
• One import outside the namespace. I checked where mizoki_contracts resolved by running python -c "import mizoki_contracts" in three venvs. Importing it builds a Firestore client, and in the canonical-ingestion venv google-auth looked for default credentials (this may include a metadata-server probe) and found none. No provider API call was made and no credential was used.
• Install differences from CI. I installed with uv instead of pip; unpinned packages resolved to pytest 9.1.1, plus jsonschema 4.26.0 and pydantic 2.13.5 where those were unpinned. I ran npm ci with --ignore-scripts; CI runs the scripts.
• Main checkout. I added and removed worktrees with git worktree add/remove, which writes only worktree metadata. The checkout is otherwise untouched: same branch, HEAD db3c271, status clean.
• My own worktrees. In them I restored old files with git checkout 3f89cd0 -- <paths> and made the guard mutations, reverting each after the run. I copied db3c271's test file into the f44a7d8 worktree.
• Removed: all six of my worktrees, all venvs and /tmp/v3. I did not touch base, fix4 or memwt2.
• No writes outside my scratchpad. GitHub was read only; I made no pushes, comments, memory records, deploys or dispatches.
• Kept: logs and probe scripts in /tmp/claude-0/-home-user-MIZOKICloudRun/3197261c-38e1-556d-ba3d-19d3526cd8c2/scratchpad/vfy3/ (logs/, probe_*.py, sweep_dates.py).

4.7 Pass 3 dispositions (fixes in 22f711d; record in the commit that adds this section)

Each code fix has a test that fails on db3c271's code and passes on 22f711d (§3.3). The heals are this session's own and therefore non-independent; pass 4 re-checks them before the merge gate.

Verifier disclosures, recorded as given (§4.6): its first governance run was discarded (the sandbox's commit signing needs a service the empty network namespace cannot reach; it re-ran with signing off through environment variables only); one mizoki_contracts import outside the namespace let google-auth look for default credentials (none found; no provider call); it installed with uv and ran npm ci --ignore-scripts. It changed no file in the main checkout and removed its worktrees and venvs.

4.8 Pass 4 — follow-up PR #1302 (db3c271..9fd5982, report verbatim)

The verifier received the range, the earlier reviews (in this file) and the rules; never the builder's reasoning. A first launch at about 22:10Z was lost to a container restart; its worktrees and venvs were removed before the relaunch, which ran 2026-10-01 from about 22:40Z to 23:15Z. Its report, verbatim:

Independent verification, pass 4 (blind): db3c271..9fd5982 (draft PR #1302)

Bottom line. I found no blocker. - Every pass-3 code item is fixed except one: the outside-range field-lookup item. The segmenting field is gone, but the lookup still sends a FROM google_ads_field clause. Google documents that clause as one that "must be omitted when querying GoogleAdsFieldService". So in live mode every lookup is still expected to fail and fall back to the static catalog. The new test pins that wrong grammar: removing FROM makes TestLiveFieldLookup fail. - The registry fixture matches Google's published v25 field reference exactly: 58 fields, 10 attributed-resource lists, 0 mismatches. With API-A13 applied, no registered query is invalid under the extra rules I checked. - Record problems: - D5 is only partly corrected: API-A7 still says "the cell has no credentials". - API-A11's "fixed" and "the validator reads live metadata" are unsupported. - API-F3 moved to REVIEW_READY although 22f711d changed its reconcile code. - The EVIDENCE §4.7 D9 row says "55 implemented, 54 tested"; the documents now say 56 and 55. - Every gate I ran is green, except docs/audits/tests. That red is environmental: it fails identically on 3d5278b because the shallow clone lacks commit 26bec9c6.

Pass-3 items

Item	Verdict	Evidence I produced
D1	FIXED	Build: build() with limit None, 0, 1, 50, 10000, 10001 and 50000 always ends in a LIMIT between 1 and 10,000. A negative limit is unreachable: every request model has ge=1. Only the registry builds a change_status query (git grep). Docs: Google's change-status guide says the query "must filter on a date within the past 90 days ... and must include a LIMIT clause set to at most 10,000". Google's own example is DURING LAST_14_DAYS ORDER BY ... LIMIT 10000. Reference: the v25 reference marks last_change_date_time filterable and sortable. Every DURING literal (docs/query/date-ranges) is under 90 days. Old code: 22f711d's tests on db3c271 answer 502 LIMIT_NOT_SPECIFIED on the Decisions route.
D2	FIXED	Head's TestSyntheticRunsNeverMutate on 3f89cd0's code: 2 failed, each 28 != 0. The tests pass on db3c271. The corrected test asserts that some gate authorized before it asserts 0.
D3	FIXED (code)	The partial-failure test on db3c271 fails with 9 save_raw_rows calls. run() is the only caller that persists raw rows: every main.py caller passes persist_raw=False. Residual: V5-6.
D4	FIXED	Probe (12 records × 30 s reads; a second reconciler tries the 12th at the real time): at head 0 extra reads and checks 1; at db3c271 1 extra read and checks 2. Production callers: both pass clock=rt.utc_now (main.py:452, :459); the manual refresh passes utc_now(). Same-stamp claims: impossible, because _int_env floors the lease at 1 s. Firestore: the stamp is stored and read back as a string, and transact_update returns the dict it wrote. Residual: V5-3.
D5 (record)	PARTIAL	CLOSEOUT and EVIDENCE §3.5 are reworded. API-A7's evidence, one of the places pass 3 named, still says "the cell has no credentials". API-A3's source_evidence still says "mounts no Google Ads credentials, so production serves synthetic rows".
D6 (record)	ACCURATE	API-A5 now reads NOT_APPLICABLE for both deployment and runtime. git grep cloud-run-google-ads-gaql outside docs/audits finds nothing; the deploy submits cloudbuild.yaml.
D7 (record)	ACCURATE	The WO-45 guard's _scan reports 0 pins on 2027-01-17 and 12 on 2027-01-18: 8 files, the lines API-G13 lists. api_lifecycle_check.py --as-of exits 0 on 2027-01-17 and 1 on 2027-01-18 (FAILURES (1)).
D8 (record)	ACCURATE	§3 no longer says nothing below is deployed, and it matches §3.5.
D9 (record)	ACCURATE, one stale row	CLOSEOUT and RESUME counts equal ISSUES.json (below). API-A2 and API-A3 record pass 3's N6 re-check. The §4.7 D9 row still says 55 implemented and 54 tested.
D10 (record)	ACCURATE	The log of job 110564512882 shows git log -1 → e480aaa952938f… at 20:16:47Z. The image is tagged :cb7b7ffc…, and the README push is e480aaa95..e7348d5c9.
D11	FIXED	Routes: app.routes has 23 method/route pairs. With the connector never live and no allow_synthetic, the 8 channel routes, the MCC listing and the 3 /srpvdal POSTs answer 503. The other routes answer 200 and serve no rows. Straddle: TestReadsThatCrossTheSunset fails on db3c271 (200 != 503). No route serves synthetic rows without allow_synthetic, and the console never passes it (git grep). Residual: V5-5.
D12	FIXED	The 22 inventory tests pass. Caught on the real files: a dangling id in RESUME.md, and one in an ISSUES.json entry's acceptance. Not flagged: the look-alikes API-V25, API-E2E and XAPI-A1.
D13	FIXED	Both TestActGuards tests fail on db3c271. The old code requested mutate services on the retired client, and _build_operation raised. git grep finds no execute or _execute_one caller other than orchestrator.py:284, so no caller breaks. Residual: V5-12.
N4 residual	FIXED (pinned)	Seeding EMAIL_SERVICE=klaviyo into --set-env-vars, or into --set-secrets, fails the test. Gaps: V5-7.
Field lookup segmenting	PARTIAL (in effect, not fixed)	See V5-1.
GAQL image without a DCP client	Record mostly ACCURATE. Disposition sound as an owner item, but its latency rests on unpinned defaults and the exposure is understated (V5-4)	The lock has no mizoki_governance, and the Dockerfile copies gaql_cell/ only. cloudbuild.yaml sets GAQL_ENABLE_LIVE_MUTATIONS=false,GAQL_DRY_RUN_DEFAULT=true,GAQL_AUTONOMY_MODE=advisory.
"Not checked" → API-A13	FIXED, and the record is ACCURATE	Reference: I parsed Google's v25 reference pages (metrics, segments, and the 11 resource pages). metrics.cost_per_conversion's "Selectable with" lacks both segments.conversion_action and segments.conversion_action_name; conversions, conversions_value, all_conversions and all_conversions_value include both. Test: it fails on 5ff9bdb's registry. Stricter rules: I also checked that each metric and segment is available with its resource in the FROM clause, that segments are compatible with each other, and that attributed resources are compatible with the selected segments. No other query fails.

Ledger at 9fd5982. 65 issues; nothing VERIFIED.

Track	Counts
Implementation	56 IMPLEMENTED, 7 NOT_APPLICABLE, 2 OPEN (API-A12, API-G13)
Testing	55 TESTED, 10 NOT_APPLICABLE
Review	48 REVIEW_READY, 11 IN_PROGRESS, 2 OPEN, 4 NOT_APPLICABLE
Deployment	32 DEPLOYED, 3 IN_PROGRESS (A6, A7, B7), 13 OPEN, 17 NOT_APPLICABLE
Runtime	48 OPEN, 4 BLOCKED_EXTERNAL (E4, D6, C5, F5), 13 NOT_APPLICABLE

CLOSEOUT, RESUME and the PR body match these counts. No new or changed entry claims DEPLOYED or VERIFIED from a test.

The other changed entries are accurate against the tree: - API-A6, A9, A10, A13, F6, G13, G14 and G15. G14's wording is accurate; its pin has the gaps in V5-7. - The five moved to REVIEW_READY: A1, C6, B10, G12 match pass 3's verdicts. F3 is the exception (V5-10).

New defects

V5-1: MINOR (latent). The live field lookup is still invalid, and its test pins the invalid grammar. - Where: src/cells/google_ads_gaql/gaql_cell/connector/client.py:194-197, SELECT name, category, selectable, filterable, sortable FROM google_ads_field WHERE name = '…'. - Google's documentation: - docs/query/grammar: "FromClause … must be omitted when querying GoogleAdsFieldService". - docs/query/structure: "the FROM clause should not be specified when using GoogleAdsFieldService". - docs/query/overview: "Note that there's no FROM clause in this query". - samples/search-for-google-ads-fields: all five languages omit FROM. - google-ads 33.0.0's v25 QueryError has UNEXPECTED_FROM_CLAUSE (47): FROM clause cannot be specified in this query. - Scenario: once credentials land, every lookup is expected to fail. Each extract then makes about 14–28 failing GoogleAdsFieldService calls (twice per extract: cached and uncached validation) before falling back to the static catalog. That is exactly the state pass 3 reported. - Test: TestLiveFieldLookup's fake parses SELECT … FROM …. When I removed FROM in my own worktree, the test failed with None != {...}. TestRealSdk checks only the selected names, and it is skipped in CI because the suite-wiring job installs no SDK. - Record: API-A11 ("fixed"; "effect once live: the validator reads live metadata"), EVIDENCE §4.7, CLOSEOUT ("fixed, API-A11") and RESUME ("API-A11 fixed") are unsupported. - Impact: no regression. The static catalog matches the reference for every field the registry uses; the one difference is value_settings.default_value filterable, which no WHERE clause uses. - Fix: drop the FROM clause. Make the fake refuse a FROM clause, and assert the built query has none. Alternatively, retire the live lookup and keep the CI reference check.

V5-2: MINOR (record). The D5 correction is incomplete. - Where: ISSUES.json API-A7 verification_evidence ("the cell has no credentials"); API-A3 source_evidence ("mounts no Google Ads credentials, so production serves synthetic rows"). - Failure: a reader takes an unmeasured present-tense claim as fact. API-A7 is the exact place pass 3 named. - Fix: reword to "the deploy config sets none; the serving revision's secret references are unmeasured (API-E4)".

V5-3: MINOR (pre-existing, in the scope D4 claims). A stale overtaken Data Manager read can regress a terminal record. - Where: services/service-data-manager-connector/request_tracking.py:457-474. - Probe: a read outlives the lease. A second reconciler claims the record, reads SUCCESS and finishes. The first read then finishes with an older PROCESSING answer. The record ends as: - status processing, with needs_reconcile False, so the sweep never picks it up again; - applied True and confirmed_events 1 kept from the success; - last_checked_at moved backwards (12:06:01 → 12:01:00), next_check_at in the past, checks 2. - db3c271 behaves identically. The range releases only the claim, while its own docstring now describes the overtaken case. - Fix: when the claim was overtaken (the current claim is not this read's stamp), the record is already terminal, or last_checked_at is newer than this read's time, record the late read in history only. Never move status or last_checked_at backwards.

V5-4: MINOR. API-A12's "latent" rests on unpinned defaults, and its exposure is understated. - Unpinned: no test pins GAQL_ENABLE_LIVE_MUTATIONS=false in cloudbuild.yaml, the _flag(..., False) default (config.py:209), or _build_operation raising. git grep over the tests finds none (rule 01: fail-if-flipped). - Understated: A12 says authorization "rests on the request's own human_approved". The request also chooses autonomy_mode, and autopilot authorizes ADD_NEGATIVE_KEYWORD and ADJUST_BID with no approval at all (gates.py:122-124). - Fix: add a pin like the EMAIL_SERVICE one, and reword A12.

V5-5: NIT. The post-read check refuses all-live results after the run has persisted. - Where: main.py:153 (_require_still_live after cell.run). - Probe: all rows live, persist=True (the request default), midnight passes after the run. Result: 16 store writes (events, raw rows, decisions, snapshots, query audit, BigQuery), then 503 google_ads_not_live. The 503 hides a run that persisted and could have executed. - Fix: decide from the extractions' own provenance, or return the run_id in the 503.

V5-6: NIT. A SENSE pass that crosses the sunset persists raw rows while the run says it persisted nothing. - Probe: 3 live extractions, then the client drops. Result: 3 save_raw_rows calls, and the warning "...were not persisted, enveloped or governed". - Fix: persist raw rows in run() after the provenance check, or word the warning accurately.

V5-7: NIT. Gaps in the EMAIL_SERVICE pin. - Where: tests/governance/test_api_lifecycle_inventory.py, test_the_console_email_route_stays_unarmed_on_deploy. - Seeds:

Seed	Result
gcloud ^@^ custom delimiter	not caught
--env-vars-file	not caught
a second --set-env-vars flag	not caught
removing the unrelated --set-secrets	test fails (ValueError from args.index)

• The docstring's "absence here is absence on the revision" holds only for revisions this cloudbuild creates through those two flags.
• Fix: parse every env/secret flag form, treat a missing flag as no keys, and handle the delimiter syntax.

V5-8: NIT. Gaps in the registry-reference test. - Seeds that pass but should fail: - a WHERE field missing from the fixture behind NOT IN, because the regex reads no NOT IN, BETWEEN or IS NULL; - campaign_budget.amount_micros with segments.device FROM campaign, which the reference disallows (attributed resource × segment is not encoded). - Minor behaviours: - if problems: continue tests the cumulative list, so after one problem the later queries skip their compatibility checks. The test still fails, but it under-reports. - Only the first ORDER BY field is checked. - A new resource or segment reports as "not selectable" rather than "regenerate the fixture". - Caught as intended: a non-selectable segment, a field missing from the fixture, an unsortable ORDER BY.

V5-9: NIT (stale references introduced by the range). - Where: - production/service-registry.yaml:1132,1137-1138 (act.py:75-80, act.py:61, act.py:92-101); - tests/remediation/test_gaql_governance_wiring.py:4; - docs/INTEGRATION_PLAN.md:371. - These were exact at db3c271. act.py now shifts them by 10 lines. - Fix: update the references in the same PR (rule 01).

V5-10: NIT (record). - API-F3 moved to REVIEW_READY although 22f711d changed its reconcile path (reconcile_record, reconcile_due). That contradicts the ledger's own review_track_note. - The EVIDENCE §4.7 D9 row is stale. - §3.5's "Not yet deployed" list omits fc2a3a3.

V5-11: NIT. Some tests build a real Google Ads client. - With google-ads installed (the image lock), 5 tests build a real GoogleAdsClient, whose construction attempts an OAuth refresh to accounts.google.com with fake credentials. Two of them are new in this range: the partial-failure test and the sunset-before-ACT test. - unshare -rn blocked the calls (NameResolutionError). - Fix: inject client_factory=_FakeClient before GAQLIntelligenceCell() builds its connector.

V5-12: NIT. The executor keeps its start-up client. - MutationExecutor._client keeps the start-up client forever, because nothing clears it now. - execute() without client= uses that client, even after the connector dropped it. No caller does this today. - Fix: make client a required keyword.

V5-13: NIT. Every Changes or Decisions page load now asks Google for up to 10,000 change_status rows. - The routes display at most 2000 changes or 100 decisions. - Fix: pass the route's limit through.

Test runs

All runs used fresh Python 3.11.15 venvs I built with uv from each job's install lines, inside unshare -rn, with proxy variables unset, TMPDIR=/tmp/v5 (governance: /tmp/v5g), and signing off through GIT_CONFIG_* environment variables.

Command	Environment	Result
python -m pytest "src/cells/google_ads_gaql/tests" -q -p no:cacheprovider -o addopts=""	suite-wiring line, MIZOKI_STORE=memory	87 passed, 4 skipped
same	requirements.lock.txt + pytest (google-ads 33.0.0)	91 passed
22f711d's GAQL and DM tests on db3c271's code	wiring venv	GAQL 7 failed, 19 passed, 4 skipped; DM 3 failed, 46 passed
head's TestSyntheticRunsNeverMutate on 3f89cd0	wiring venv	2 failed (28 != 0)
TestRegistryAgainstTheV25FieldReference on 5ff9bdb	wiring venv	1 failed, 1 passed
python -m pytest "services/service-data-manager-connector/tests" …	wiring venv	49 passed
python -m pytest "docs/audits/tests" …	wiring venv	1 failed (test_wo31_register: commit 26bec9c6 absent), 7 passed; identical on 3d5278b
pytest tests/governance -c tests/governance/pytest.ini -p no:cacheprovider	ci.yaml lint-and-test line + -e contracts + docs/whitepapers/requirements.txt	4350 passed, 7 skipped, 0 failed, 6227 subtests
bash .github/scripts/content_gates.sh	governance-gates install line first on PATH	rc 0, 155 passed
tests/governance/test_api_lifecycle_inventory.py	ci venv	22 passed, plus the seeds above
tests/remediation/test_gaql_governance_wiring.py	wiring venv	5 passed
python3 scripts/api_lifecycle_check.py	gates venv	rc 0, FAILURES (0), WARNINGS (1)
python3 scripts/gate_leak_scan.py --check	gates venv	rc 0: 0 new, 0 grown, 0 stale
python3 scripts/claude_memory.py check --strict	gates venv	rc 0
python3 .github/scripts/deploy_router.py --base 3f89cd0 --head 9fd5982	gates venv	18 files → deploy-google-ads-gaql.yml (8), deploy-ui.yml (1), frontend-guard.yml (1)
PR #1302 check-runs on 9fd5982 (gh api, read-only)	GitHub	all success (one skipped); mergeable_state clean against fa1cc19

Not checked

• Live provider behaviour. V5-1 rests on Google's documentation and the SDK's error enum, not a live call.
• The serving revisions' env and secret mounts (no GCP access).
• The console vitest, tsc, lint and Playwright suites. GitHub reports them green.
• The other ci.yaml jobs.
• CI's exact git and Python versions.
• Gates on the real merge result with fa1cc19. I ran no local merge-tree, to avoid writing objects into the main repository.
• Whether Next.js would load an EMAIL_SERVICE placed in .env.production.

Disclosures

• Main checkout: untouched. Branch work/mizoki-api-compatibility-3ae54n, HEAD 9fd5982, status clean. git worktree add/remove wrote only worktree metadata.
• Cleanup: I removed all 7 of my worktrees, all 4 venvs, /tmp/v5 and /tmp/v5g. I did not touch base, fix5 or memwt2. I did not read the builder's scratchpad files.
• Network:
• Google documentation pages fetched read-only with curl, plus one WebSearch.
• GitHub reads only: PR metadata, comments, job logs, check-runs.
• No provider call left the host: the 5 OAuth refresh attempts in the lock run were blocked by the namespace.
• No pushes, comments, records, deploys or dispatches.
• Deviations from CI: uv instead of pip (pytest resolved to 9.1.1), and -p no:cacheprovider on the governance run.
• Mutations: my seeds and old-code copies were made only in my own worktrees and reverted.
• Kept:
• logs, probes, the parsed reference, and REPORT.partial.md in /tmp/claude-0/-home-user-MIZOKICloudRun/3197261c-38e1-556d-ba3d-19d3526cd8c2/scratchpad/vfy5/;
• the fetched pages and parsers in docs/ there, with docs/compare.py doing the fixture-vs-reference comparison.

4.9 Pass 4 dispositions (fixes in b03f33e; record in the commit that adds this section)

How each fix is verified (§3.3): - A test that fails on 9fd5982's code: V5-1, V5-3 (two tests), V5-5, V5-6, V5-12 (its pin, added in 9d76b52) and V5-13. - Pins that fail when flipped: V5-4. - Self-seeded tests: V5-7 and V5-8 check other checks, so their tests seed both directions. Pass 4 measured the old checks missing those seeds. - Read, not tested: V5-9's new line references. - Measured by a DNS-lookup audit: V5-11. - Record items: V5-2 and V5-10.

This list's first wording, in b34358c, said every code fix had a test that fails on 9fd5982's code. V5-9, V5-11 and V5-12 had none then.

The heals are this session's own and therefore non-independent; pass 5 re-checks them before the merge gate.

Pass 4's verdicts on the pass-3 items stand as reported (§4.8). The two it did not close are D5, corrected further under V5-2, and the field lookup, fixed under V5-1.

Verifier disclosures, recorded as given (§4.8): it installed with uv (pytest 9.1.1) and ran the governance suite with -p no:cacheprovider; it turned commit signing off for its test processes through environment variables only; five OAuth refresh attempts in its image-lock run were blocked by the empty network namespace (V5-11); it fetched Google's documentation pages read-only and made GitHub reads only. It changed no file in the main checkout and removed its worktrees and venvs.

4.10 Pass 5 — follow-up PR #1302 (9fd5982..2ee03e0, report verbatim)

The verifier received the range, the earlier reviews (in this file) and the rules; never the builder's reasoning. It ran 2026-10-02 from about 00:01Z to 00:43Z. Its report, verbatim:

Independent verification, pass 5 (blind): 9fd5982..2ee03e0 (draft PR #1302)

Bottom line. I found no blocker. - Code items. 11 of the 13 V5 code items, the field lookup and D5 hold. V5-3 and V5-8 are PARTIAL. - The new defects. One MINOR, N1: a Data Manager status read can finish after the upload was re-sent, and it is then applied to the new attempt. Pass 4 recommended three conditions for treating a read as late, and the fix encodes two of them. The rest are NITs. - Builder's claims I re-measured: each one reproduced. - 7 tests fail on 9fd5982's code. - Each of the 10 seeded flips fails exactly one test. - The DNS audit finds 5 accounts.google.com lookups on the old tree and 0 on the new one. - Gates: all green except docs/audits/tests. That suite fails identically on 3d5278b, because this shallow clone lacks commit 26bec9c6. - The disagreement: by Google's published documentation, keyword_performance_v1 is expected to be valid, but that cannot be verified offline. The builder's statement of the evidence is accurate, with two omissions.

Pass-4 items

Item	Verdict	Evidence I produced
V5-1	FIXED	Query: client.py:193-194 builds SELECT name, category, selectable, filterable, sortable WHERE name = '…'. Grammar: Google's grammar page is Query -> SelectClause FromClause? WhereClause? … and says "FromClause … must be omitted when querying GoogleAdsFieldService". The five-language sample omits FROM and uses WHERE name LIKE. SDK: google-ads 33.0.0 accepts search_google_ads_fields(request=None, *, query=None, …), and its category enum has SEGMENT. Old code: head's test on 9fd5982's code fails with None != {...}. Fake fidelity (NIT): the fake checks only FROM and the SELECT list. With AND not_a_field = 1 appended to the query, TestLiveFieldLookup still passes.
V5-2 (record)	Content ACCURATE, pointers INACCURATE	Content: the corrections match cloudbuild.yaml, which passes no --set-secrets or --clear-secrets. Pointers: API-A3 source_evidence[0] and API-A7 verification_evidence[5] say "SUPERSEDED … next line", but the corrections are [2] and [9]. So §4.9's "followed by the measured wording" is not literally true.
V5-3	PARTIAL	Fixed: the reported interleaving. - Probe A at head: success, checks 2, last_checked_at 12:06:01, needs_reconcile False, one success audit. - On 9fd5982 the same probe ends in processing. - Both new tests fail on 9fd5982. Missing: pass 4's first condition ("the current claim is not this read's stamp"). See N1.
V5-4	FIXED	Pins: the three TestLiveMutationsStayOff tests each fail on their own flips; see the runs table. A12: the title now names autonomy_mode. gates.py:39 sets _LOW_RISK_ACTIONS = {ADD_NEGATIVE_KEYWORD, ADJUST_BID}, and _authorize authorizes them on AUTOPILOT. gcloud: --set-env-vars uses UpdateAction, which raises on a duplicate key, and it is mutually exclusive with --update-env-vars and --env-vars-file. So a second flag in the same call cannot flip a pinned key.
V5-5	FIXED	Routes: the app has 27 method/route pairs; 12 of them read SENSE. - All live: every route 200. - Sunset inside the first read: all 12 answer 503 with 0 writes. - Sunset after the first read: the multi-read routes (run, run-mcc, sense, decisions) answer 503 with 0 writes; single-read routes answer 200, because their one read was live. Old code: head's test fails on it (503 != 200). When provenance is taken: in run(), right after the last SENSE read (orchestrator.py:180), before any write (:207, :311). In MCC, after the listing (:509), and re-marked after each child's run. Residual: N5.
V5-6	FIXED	Old code: saves raw rows 3 times (['save_raw_rows']*3 != []). Head: raw rows are saved only at orchestrator.py:207-209, after both the error check and the provenance check. Callers: no caller passes persist_raw=True, and the routes persist nothing.
V5-7	FIXED (as scoped)	Forms read: repeated flags, --flag=value, ^DELIM^; a missing flag sets nothing. Fails closed on: --update-* and --env-vars-file. Checks: the seeded test passes; the real console cloudbuild.yaml gives no false positive; seeding EMAIL_SERVICE=klaviyo fails exactly that one test. New gaps: N4.
V5-8	PARTIAL	Pinned: every WHERE operator and every ORDER BY field (the old regex, or reading only the first field, fails the assertions). A resource missing from the fixture is named. Not pinned: "each query is checked on its own". The pre-V5-8 cumulative check leaves all 3 tests green (N3). Uncaught: pass 4's seed 2 (campaign_budget with segments.device) still returns [].
V5-9	FIXED	Lines: act.py:80-85, :66 and :97-106 hold the same statements as db3c271's 75-80, 61 and 92-101. Observation: # MIZ OKI 3.5/site_docs_internal/INTEGRATION_PLAN.html:607 still says 75-80. deploy-homepage.yml rebuilds that mirror at deploy.
V5-10 (record)	ACCURATE	API-F3's review was REVIEW_READY at 5ff9bdb and is IN_PROGRESS at b34358c. 22f711d changed request_tracking.py. The D9 row and the §3.5 list are annotated.
V5-11	FIXED	DNS audit (lock venv, unshare -rn): - 9fd5982: 91 passed; 5 accounts.google.com and 120 169.254.169.254 lookups. - 2ee03e0: 99 passed; 0 and 126. Record wording: N7.
V5-12	FIXED	Executor: no __init__; client defaults to None. Caller: the only caller (orchestrator.py:298-299) passes the client right after refresh_version_status(). A dropped client is None, so the action is simulated (act.py:66). Old code: the pin fails ('__init__' unexpectedly found). Its behavioural half alone passes on the old code too.
V5-13	FIXED	Changes route: passes its own limit (le=2000); the registry caps any LIMIT at 10,000 (gaql_registry.py:44-47). On 9fd5982 the route sent LIMIT 10000. Decisions route: keeps the cap. The builder's reason is sound: the route's limit slices decisions after the run, while run(limit=) would change every query's LIMIT.
D5 (record)	ACCURATE (with the V5-2 pointer defect)	Every GAQL "no credentials" line is now marked superseded and corrected. The remaining "mounts no ad credentials" lines are Boss's, measured separately.
Field lookup	FIXED	As V5-1.

The disagreement (keyword_performance_v1)

Verdict: expected valid, not verifiable offline. The CLOSEOUT's planned first live call to /srpvdal/sense is the right first measurement. The docs I fetched were last updated 2026-09-30.

What Google publishes in favour of the query: - keyword_view's v25 page marks segments.date "Yes, it is", meaning usable when keyword_view is in the FROM clause. - That page lists ad_group_criterion as an attributed resource: "Fields from the above resources may be selected along with this resource in your SELECT and WHERE clauses. These fields will not segment metrics". - The criteria-metrics guide tells clients to select ad_group_criterion fields with the *_view resources.

The text that supports the strict reading, and why it cannot be evaluated: - The field-service concept page says: "If you select fields from a resource that is not in the FROM clause, that resource's selectableWith list must include all other segments and resources present in your SELECT clause." - ad_group_criterion's resource-level selectableWith is not published. Its v25 page has only an Attributed-resources table: no Segments or Metrics tables and no "Selectable with" row. So that rule cannot be checked offline.

Why the omission from the published lists is not evidence of incompatibility: - segments.date's 545-entry list omits ad_group_criterion, campaign_criterion and accessible_bidding_strategy. - metrics.clicks and metrics.impressions omit ad_group_criterion and accessible_bidding_strategy the same way. They name campaign, campaign_budget, ad_group, customer and bidding_strategy. - Google's Cookbook query selects 5 metrics with ad_group_criterion fields FROM keyword_view, and the metric lists omit ad_group_criterion too.

The SDK carries no field catalog. The QueryError 51 text the builder quotes is exact. Codes 48 and 65 also exist; 65 is "A metric may not be selected with one of the selected resource fields…".

The builder's statement is accurate. I copied pass 4's kept eval_registry.py into my own folder and ran it on 2ee03e0 and on 9fd5982. It flags exactly segments.date and the 5 metrics of keyword_performance_v1, and every other query is OK. Two omissions: - the concept page's rule above; - pass 4's own kept notes (vfy5/REPORT.partial.md, line 10) dismissed that flag as "a parser artefact: that page has no segment/metric tables". So pass 4's "no other query fails" was a judgement, not an oversight.

New defects

N1 — MINOR. A late status read that straddles a re-send is applied to the new attempt. - Where: services/service-data-manager-connector/request_tracking.py:458-491; the guard is at :467. - Scenario (probe E): 1. R1 claims the record for req-1 at 12:01:00, and its read stalls past the 300 s lease. 2. R2 claims at 12:06:01, reads FAILED, and the record becomes a failure. 3. The caller re-sends: begin_submission allows a FAILED record to be re-sent, and the record is accepted again as req-2 (attempt 2). 4. R1 then finishes with req-1's FAILED answer. - Result at head: - status failure, request_id req-2, attempt 2; - needs_reconcile False; - last_checked_at 12:01:00, earlier than attempt 2's submission at 12:06:06; - a second conversions.request.failure audit. - Consequence: req-2 is never read, and a third re-send is allowed. The same happens on 9fd5982. It is pre-existing, but inside V5-3's scope. - Record: it contradicts API-F6 ("not applied"), §4.9 V5-3 ("no status … moves backwards") and the CLOSEOUT Data Manager row ("a late read never undoes a newer one"). - Fix: treat current.get("check_claimed_at") != stamp, or a changed request_id/attempt, as a late read (note it, never apply it). Add a re-send test.

N2 — NIT. A late read that carries the final answer is dropped. - Where: request_tracking.py:467-479. - Scenario (probe C3): the overtaking read answers PROCESSING and spends the last check, so the record becomes unknown/status_expired with needs_reconcile False. The late read carried SUCCESS; it is discarded, and the history note records the current status, not the late answer. - Effect: the sweep never reads the record again; only a manual refresh recovers it. 9fd5982 applied the SUCCESS. With checks left (probe C2), the next sweep heals it. - Fix: put the late read's mapped status in the history note. Optionally, let a late terminal answer settle an unknown/status_expired record.

N3 — NIT. Gaps in the registry-reference test. - Where: src/cells/google_ads_gaql/tests/test_api_compat_binding.py:524-560 and :589-618. - Gaps: - The "each query is checked on its own" property is unpinned (the cumulative-check seed stays green). - Pass 4's campaign_budget × segments.device seed is uncaught. The fixture already distinguishes it: segments.device's list omits campaign_budget and segments.date's includes it. ad_group_criterion is outside the fixture's resource universe, so this rule fails nothing registered. - Segment-to-segment compatibility is neither encoded nor listed as "not encoded". - Fix: - Place a compatibility seed after a missing-name seed, and assert both are reported. - Encode the attributed-resource rule for attributed resources that are themselves FROM resources in the fixture.

N4 — NIT. Forms the EMAIL_SERVICE pin does not read. - Where: tests/governance/test_api_lifecycle_inventory.py:188-239. - Seeds that pass the test: - the _LIFT_ENGINE_URL default in the file's own substitutions: block set to "…run.app,EMAIL_SERVICE=klaviyo". Cloud Build expands it inside the --set-env-vars value, and gcloud splits on the comma. - --flags-file=… added to the deploy args. - By reading: only the deploy-to-cloud-run step is read. The GAQL pin's --set-env-vars=(\S+) regex also misses the space form in a separate gcloud step. So the docstring's "Arming the route means editing this test" overstates. - Fix: expand ${_X} from the file's own substitutions (fail closed if a value contains , or =), refuse --flags-file, and scan every step.

N5 — NIT. An MCC run with a synthetic child hides a persisted live child. - Where: orchestrator.py:536-537 and main.py:174-175. - Probe: child 1 live, then a sunset before child 2's SENSE. Child 1 makes 17 store writes, then the route answers 503. - Gap: the 503 detail has only the MCC run_id, which is never persisted, and no child run ids. - Fix: put per_account (run ids, ok flags) in the 503 detail.

N6 — NIT (record). The PR body is stale. - PR #1302 at 2ee03e0: - the title still says "review passes 2–3"; - the commit list stops at 9fd5982; - it says the merge gate waits for pass 4; - its gate table is for 9fd5982; - its field-lookup row says only "It now reads category". - Elsewhere: - EVIDENCE §3.2 says the record-commit gates are recorded in the PR body; at 2ee03e0 they are not. - CLOSEOUT's release-package row says "pass 5 reports no open blocker" in the present tense, before pass 5 reported.

N7 — NIT (record). Five ledger lines and the review note. - API-A7 [10]: "no test builds a real GoogleAdsClient" is false. TestRealSdk builds real ones with a stubbed credential factory. What was measured is that no test looks up accounts.google.com. - API-A12: says the flips were seeded "on 9fd5982's tree", while EVIDENCE §3.3 says b03f33e. The pin tests do not exist on 9fd5982. - API-A13: says the check is "seeded in both directions", which includes the unpinned each-query property (N3). - API-A11 [2]: "unsupported until b03f33e" implies the claim is supported after it. - review_track_note: its IN_PROGRESS definition covers G13 and G15, which b34358c changed but which are REVIEW_READY. Their new lines do match pass 4's report.

Ledger at 2ee03e0

65 issues; nothing is VERIFIED.

Track	Counts
Implementation	56 IMPLEMENTED (55 TESTED; API-G17 is the only untested one), 7 NOT_APPLICABLE, 2 OPEN (API-G13, API-A12)
Review	48 REVIEW_READY, 11 IN_PROGRESS (A3, A6, A7, A9, A10, A11, A12, A13, F3, F6, G14), 2 OPEN, 4 NOT_APPLICABLE
Deployment	32 DEPLOYED, 3 IN_PROGRESS (A6, A7, B7), 13 OPEN, 17 NOT_APPLICABLE
Runtime	48 OPEN, 4 BLOCKED_EXTERNAL, 13 NOT_APPLICABLE

CLOSEOUT and RESUME match these counts. No changed entry claims DEPLOYED or VERIFIED from a test.

Data Manager interleavings (probes on head)

Columns: status, checks, last_checked_at, needs_reconcile, audit. The claim is released only by its own read in every case.

Interleaving	Result
Two reconcilers: a late PROCESSING after a newer SUCCESS	success, 2, 12:06:01, False, one success audit
Manual refresh inside the lease	refused; the sweep's claim is kept
Manual refresh after the lease	same as two reconcilers
Late newer answer, checks left (C2)	processing, then the next sweep settles success
Late newer answer after the overtaking read spent the last check (C3)	status_expired, SUCCESS lost (N2)
Firestore-style retry (attempt 1 stale, attempt 2 late)	applied cleared; nothing applied; no audit
Re-send between the claim and the late read (E)	N1

Nothing reconciles forever: late reads add to checks, and the next applied read checks the expiry. The comparison orders reads by claim time, never equal ones (the lease is at least 1 s). A late read that carries a newer answer is therefore treated as older (C2, C3).

Test runs

Common environment: fresh pip venvs on CPython 3.11.15 (pytest 9.1.1) built from the CI install lines, run under unshare -rn, proxy variables unset, short TMPDIR.

Command	Environment	Result
python -m pytest "src/cells/google_ads_gaql/tests" -q -p no:cacheprovider -o addopts="" @2ee03e0	suite-wiring venv, MIZOKI_STORE=memory	95 passed, 4 skipped
same	image-lock venv (google-ads 33.0.0)	99 passed
GAQL suite with a getaddrinfo audit	lock venv, @9fd5982 / @2ee03e0	91 passed, 5 accounts.google.com lookups / 99 passed, 0
services/service-data-manager-connector/tests	wiring venv	51 passed
Head's two test files on 9fd5982's code	wiring venv	GAQL file 5 failed / 31 passed / 4 skipped; Data Manager suite 2 failed / 49 passed
tests/remediation/test_gaql_governance_wiring.py	wiring venv	5 passed
docs/audits/tests @2ee03e0 and @3d5278b	wiring venv	1 failed (test_wo31_register, commit 26bec9c6 absent), 7 passed, identical on both
pytest tests/governance -c tests/governance/pytest.ini -p no:cacheprovider	ci venv (+ -e contracts, whitepapers), signing off through GIT_CONFIG_*	4351 passed, 7 skipped, 6227 subtests, 0 failed
bash .github/scripts/content_gates.sh	governance-gates venv first on PATH	rc 0, 155 passed
api_lifecycle_check.py / gate_leak_scan.py --check / claude_memory.py check --strict	gates venv	rc 0 each (FAILURES 0, WARNINGS 1 / 0 new, 0 grown, 0 stale / valid)
deploy_router.py --base 3f89cd0 --head 2ee03e0	gates venv	21 files → deploy-google-ads-gaql.yml (8), deploy-ui.yml (1), frontend-guard.yml (1)
10 seeded flips: the GAQL suite plus the inventory test file	flip worktree @2ee03e0	each flip fails exactly 1 test
Seeds the checks miss: cumulative check, bogus WHERE, substitution default, --flags-file	as above	all pass, so each check misses its seed
PR #1302 check-runs (gh api, read-only)	GitHub	28: 26 success, 1 skipped, 1 in progress (CodeQL)

The 10 flips were each of the deploy's three values, an added --update-env-vars, each of the three code defaults, an operation builder that returns, cost_per_conversion back in conversion_segmentation_v1, and EMAIL_SERVICE in the console's env map.

Not checked

• Live provider behaviour.
• Whether Cloud Run accepts a secret-sourced env var with the same name as a literal one.
• The serving revisions' env and secret mounts.
• The console vitest, tsc, lint and Playwright suites, and the other ci.yaml jobs.
• Gates on the merge result with fa1cc19.
• Whether §4.8 quotes pass 4 verbatim: I had only pass 4's partial notes, not its original report.
• CI's git version.

Disclosures

• Main checkout: I only read it, with GIT_OPTIONAL_LOCKS=0, and ran worktree add/remove there. During my run another session moved its branch from b34358c to 2ee03e0, and c3wt disappeared from the worktree list; neither was me. Its status was clean at the end.
• Cleanup: I removed all 6 of my worktrees, all 4 venvs and /tmp/v6*. I did not touch base, memwt2 or c3wt. Outside vfy6/ I read only pass 4's vfy5/ files.
• Kept, in vfy6/: REPORT.partial.md, logs/, probes/, the fetched docs, and p4docs/ (copies of pass 4's scripts and its parsed reference).
• Network:
• Google documentation pages fetched read-only with curl.
• PyPI installs.
• GitHub REST reads only. One gh pr view hit the GraphQL 403 (a read).
• No provider call: the DNS audit refused every non-loopback lookup.
• Deviations from CI: pip in plain python3.11 -m venv venvs, not setup-python; -p no:cacheprovider on the governance run; commit signing turned off through GIT_CONFIG_* environment variables only.
• No writes: no pushes, comments, records, deploys or dispatches.

4.11 Pass 5 dispositions (fixes in c7d8904; record in the commit that adds this section)

How each fix is verified (§3.3): - A test that fails on 2ee03e0's code: N1, N2, N5. - Seeds that fail when the rule is removed: N3. For N4, seeds on the real deploy files fail. - Record items: N6, N7 and the V5-2 markers.

The heals are this session's own and therefore non-independent; pass 6 re-checks them before the merge gate. Pass 5's verdicts on the pass-4 items stand as reported (§4.10); its two PARTIALs are N1 (V5-3) and N3 (V5-8).

Verifier disclosures, recorded as given (§4.10): - Environment: it built plain python3.11 -m venv venvs with pip, ran the governance suite with -p no:cacheprovider, and turned commit signing off through GIT_CONFIG_* environment variables only. - Network: it fetched Google's documentation pages read-only and made GitHub reads only (one gh pr view hit the GraphQL 403). - Observed during its run: the branch moving from b34358c to 2ee03e0, and the c3wt worktree disappearing. Both were this session's: the fast-forward and its scratch worktree. - Footprint: it changed no file in the main checkout and removed its worktrees and venvs.

4.12 Pass 6 — follow-up PR #1302 (2ee03e0..701f67c, report verbatim)

The verifier received the range, the earlier reviews (in this file) and the rules; never the builder's reasoning. It ran 2026-10-02 from about 01:13Z to 01:52Z. Its report, verbatim:

Independent verification, pass 6 (blind): 2ee03e0..701f67c (draft PR #1302)

Bottom line. I found no blocker and no MAJOR.

• Code fixes: N1, N2, N3 and N5 are FIXED.
• On 2ee03e0's code with c7d8904's three test files, exactly 3 tests fail, the 3 the builder named. Reproduced.
• Each N3 seed fails when its rule is removed. The V5-1 seed (a bogus WHERE term) fails TestLiveFieldLookup. The four seeded deploy files each fail exactly the pin that guards them.
• N4 is PARTIAL. The forms pass 5 named are now caught. Two problems remain:
• The record claims the console pin refuses "a submit-time substitution in deploy-ui.yml other than _IMAGE_TAG". That is false for a pair written after ${{ github.sha }}.
• The pin still misses several in-repo ways to arm the route, so the docstring and API-G14 overstate it.
• N6 is PARTIAL. The PR body is now current. But CLOSEOUT.md:273 still says pass 6 "reports no open blocker", while §4.11 says that row no longer speaks for a pass before it reports.
• The rest of the record is ACCURATE: the V5-2 markers, N7, the counts, and API-A9/A10 moving to REVIEW_READY. No changed line calls anything deployed or verified beyond the evidence.
• New defects: 7, all NIT. One is in code: a late Data Manager read can now raise on a malformed status body.
• Gates: all green in fresh venvs, except docs/audits/tests::test_wo31_register. It fails identically on 3d5278b, because commit 26bec9c6 is not in this clone.

Pass-5 items

Item	Verdict	Evidence I produced
N1	FIXED	Old code: the new re-send test fails there (status failure != submitted). Probe P6: R2 fails the record, it is re-sent as req-2, and R3 claims attempt 2; then R1 returns. Head keeps R3's claim, checks stay 0, and the note says "re-sent as attempt 2". 2ee03e0 applied the failure to attempt 2. A read that should apply still applies: a sweep read, a manual refresh, a lapsed claim nobody took over, and a legacy record without attempt, check_claimed_at or checks. Firestore-style retry, stale snapshot first then the real one: applied once, one audit. Reverse order: not applied, no audit. History: stays at 20 entries; the note is at most about 311 characters; history is not in public_view.
N2	FIXED; disposition SOUND	Old code: the new test fails there (no "answered success" in the note). Probe with MAX_CHECKS=1: the late SUCCESS is dropped and the record ends unknown/status_expired. The sweep scans 0 records. The note says "answered success". A manual refresh then sets success with applied true.
N3	FIXED	Seeds: removing the segment-to-segment rule, removing the attributed rule, or restoring the cumulative skip each fails test_the_check_catches_what_it_encodes, and nothing else. Pass 4's seed 2 is caught. Against Google's pages: I fetched the v25 pages for all 10 registry FROM resources. Each page's list matches the fixture's segment and metric lists: 0 mismatches. campaign_budget's page does not list segments.device. So the rule as coded agrees with the field-service guide's rule for these resources.
N4	PARTIAL	Caught: a substitution default carrying EMAIL_SERVICE; --flags-file in a step; a plain shell step that names it; in the GAQL deploy, a second space-form flag and --flags-file. Not caught: see D1.
N5	FIXED	Old code: the test fails there (KeyError: 'per_account'). Probe with 5 child states: - live: run id, synthetic: false; - skipped: run_id null, synthetic null; - run raised: run_id null, synthetic null, and the exception text is not in the 503; - failed extraction: run id, synthetic: false; - after the sunset: ok: true, synthetic: true. The additive flag: no reader of per_account exists outside tests, and the schema is List[Dict].
N6 (record)	PARTIAL	ACCURATE: the PR body now has the title "passes 2–5", commits through 701f67c, and a gate table whose numbers match mine. The timeline shows the 00:17:48Z rename came after pass 5's read at 00:16:53Z. The §3.2 pointer is now true. INACCURATE: CLOSEOUT.md:273; see D2.
N7 (record)	ACCURATE	API-A7 [10] → [11]; API-A12 [3] → [4] (on b03f33e); API-A13 [5]'s marker; API-A11 [2]'s wording; the review note's "a verdict line is not a change".
V5-2 markers	ACCURATE	API-A3 [0] points to [2] and API-A7 [5] points to [9]. Both targets start "corrected after independent review pass 4".
V5-1 fidelity note	FIXED	Bogus WHERE seed: TestLiveFieldLookup fails. Real lookups: all 58 registry field names match the fake's name regex, so it refuses nothing the real lookup sends. Remaining gaps (pre-existing): the fake is stricter than Google on WHERE forms, and it returns a row for a well-formed name that does not exist.
V5-9 observation	Disposition SOUND	deploy-homepage.yml:216 runs build_site_docs.py, whose --out-internal default is site_docs_internal. The committed copy (INTEGRATION_PLAN.html:607) still says 75-80.
keyword_performance_v1	Disposition SOUND	Both omissions are now recorded (§4.11). The new rule skips ad_group_criterion, and that skip is asserted legal. Its v25 page publishes 0 segments and 0 metrics; customer's publishes 93 and 209.

New defects

D1 — NIT (record and test scope). The console email-route pin misses several arming routes, and the record overstates it. - Where: - tests/governance/test_api_lifecycle_inventory.py:267: the substitution regex --substitutions[= ]+(\S+). - :249-256: the docstring. - ISSUES.json:1757 (API-G14), EVIDENCE.md:1732 (§4.11 N4) and the PR body. - Seeds that leave both email tests passing: 1. A second pair in deploy-ui.yml:58. --substitutions=_IMAGE_TAG=${{ github.sha }},_REQUIRE_AUTH=false passes, because \S+ stops at the space inside ${{ github.sha }}. So does a quoted pair that puts a shell command into _REQUIRE_AUTH, because the auth-guard step pastes '${_REQUIRE_AUTH}' into bash. I did not run that in Cloud Build. 2. deploy-all.yml:123-126, which submits the same Cloud Build file. With '--substitutions=^:^_LIFT_ENGINE_URL=https://x.run.app,EMAIL_SERVICE=klaviyo:_IMAGE_TAG=…' the pin passes; it reads only deploy-ui.yml. 3. ENV EMAIL_SERVICE=klaviyo in the console Dockerfile's runtime stage (after line 41). 4. deploy-ui.yml given --flags-file=…, or --config= another file that names the variable. 5. An obfuscated shell step, such as N=EMAIL; … --update-env-vars "$${N}_SERVICE=klaviyo". The merging-flag check reads only arguments that start with the flag. - Fix: - Correct the API-G14, §4.11 and PR wording. - Pin the exact submit line, and do it in every workflow that submits this config. - Refuse --flags-file and a different --config in those workflows. - Scan the Dockerfile and next.config.mjs for the name. - Extend the "out of reach" list beyond "a Cloud Run setting changed by hand".

D2 — NIT (record). CLOSEOUT.md:273 reads "pass 6, which re-checks the pass-5 heals, reports no open blocker". That is the same construction pass 5 flagged (2ee03e0's row 255), yet §4.11 N6 says the row was fixed. - Fix: "pass 6 must report no open blocker", or fill the row in after pass 6 reports.

D3 — NIT (code). The late-read path can now raise on a malformed status body. - Where: request_tracking.py:480-481 calls apply_status on the late answer. apply_status raises AttributeError when errorInfo or warningInfo is not a mapping (:336, :339). - Scenario (probe P8): a late read gets HTTP 200 with "errorInfo": "boom". - Head raises out of reconcile_record; 2ee03e0 noted the read. - reconcile_due (:547) has no per-record isolation, so the sweep's batch stops there. The loop logs and retries; a manual refresh answers 500. - The same body on the applied path raises on both trees (pre-existing). - Fix: catch the error and note "answered an unparseable body", or make apply_status check types.

D4 — NIT (code wording). request_tracking.py:482-483: when a read's claim was taken over but the newer read has not landed yet (probe P5), the note still says "a newer read had already updated this record". In that probe nothing had updated the record: status submitted, last_checked_at null. - Fix: add a third reason, "its claim was taken over".

D5 — NIT (docstring and record). The registry check skips more than it says. - Where: test_api_compat_binding.py:537-542 and :574-576, API-A13 [6], and the PR body. - What is wrong: - "Not encoded" names only ad_group_criterion. In fact the attributed rule skips every attributed resource that is not a registry FROM resource: customer, bidding_strategy, accessible_bidding_strategy, campaign_group, and change_status's asset, asset_set, combined_audience and shared_set. Google does publish lists for some of these (customer: 93 segments). - The metric half of the same guide sentence (an attributed resource must also be compatible with each selected metric) is neither encoded nor listed. - Impact today: none. I checked every registered query's metrics against its attributed registry resources, and none fails. - Fix: list both gaps under "Not encoded".

D6 — NIT (record). API-A6 [9] (ISSUES.json:1547) says "per_account entries gain a synthetic flag", and the PR body says "on each MCC child entry". Skipped and raised children get no flag (orchestrator.py:521-525, :563-565), and the 503 shows them as null. A child whose run raised also has no run id, so the 503 cannot name a run that may have partly persisted (pre-existing). - Fix: say "each child that ran".

D7 — NIT (test scope). The GAQL deploy pin (test_api_compat_binding.py:955-958) has one gap and one false positive. - Not caught: a step running gcloud run services replace src/cells/google_ads_gaql/cloud-run-google-ads-gaql.yaml, with that manifest flipped to GAQL_ENABLE_LIVE_MUTATIONS "true". The GAQL file still passes, 37 tests. By reading, a different --config in deploy-google-ads-gaql.yml is not read either. - False positive: a YAML comment naming a pinned key fails the pin (count 2). That fails closed, but unlike the console test, its comment does not say comments count. - Fix: pin the workflow's --config, and state these limits in the test.

Test runs

All runs: fresh python3.11 -m venv venvs (CPython 3.11.15, pytest 9.1.1) built from the CI install lines, under unshare -rn, with the proxy variables unset, TMPDIR=/tmp/v7/<run>, and commit signing turned off through GIT_CONFIG_* environment variables.

Command	Environment	Result
python -m pytest "src/cells/google_ads_gaql/tests" -q -p no:cacheprovider -o addopts="" @701f67c	suite-wiring venv, MIZOKI_STORE=memory	96 passed, 4 skipped
same	image-lock venv (google-ads 33.0.0)	100 passed
same, under my own getaddrinfo audit (a direct lookup of accounts.google.com was recorded)	lock venv	100 passed; 126 metadata-server lookups, 0 accounts.google.com
services/service-data-manager-connector/tests	wiring venv	53 passed
tests/remediation/test_gaql_governance_wiring.py	wiring venv	5 passed
docs/audits/tests @701f67c and @3d5278b	wiring venv	1 failed (test_wo31_register, git show 26bec9c6… exit 128), 7 passed, identical on both; the object is absent from this clone
pytest tests/governance -c tests/governance/pytest.ini -p no:cacheprovider	ci venv (+ -e contracts, whitepaper requirements)	4351 passed, 7 skipped, 6227 subtests, rc 0
bash .github/scripts/content_gates.sh	governance-gates venv first on PATH	rc 0, 155 passed
api_lifecycle_check.py / gate_leak_scan.py --check / claude_memory.py check --strict	gates venv	rc 0 each (FAILURES 0, WARNINGS 1 / 0 new, 0 grown, 0 stale / valid)
deploy_router.py --base 3f89cd0 --head 701f67c	gates venv	21 files → deploy-google-ads-gaql.yml (8), deploy-ui.yml (1), frontend-guard.yml (1); with --base fa1cc19, 23 files and the same three
git merge-tree 3f89cd0 fa1cc19 701f67c (stdout-only form)	—	0 conflicts
c7d8904's three test files on 2ee03e0's code	wiring / lock / ci venvs	GAQL suite 1 failed, 95 passed, 4 skipped (lock: 1 failed, 99 passed); GAQL file alone 1 failed, 36 passed, 4 skipped; Data Manager 2 failed, 51 passed; inventory file 23 passed
18 seeded mutations @701f67c	GAQL file + inventory file	as reported above
PR #1302 check-runs @701f67c	gh api, read-only	28: 27 success, 1 skipped (Live Cell Endpoint Tests)

Not checked

• Live provider behaviour.
• Whether Cloud Build would actually run any seeded file. The claims that an image ENV survives --set-env-vars and that gcloud splits pairs on the comma come from documented behaviour; I did not measure them.
• The serving revisions.
• Gates on the merge result with fa1cc19. I only checked it for conflicts.
• The console vitest, tsc and Playwright suites myself (CI reports them green).
• Whether §4.10 quotes pass 5 verbatim. I had only pass 5's kept notes in vfy6/; they do not contradict it.
• The PR body's edit history between 00:17Z and 01:14Z.
• CI's git version.

Disclosures

• Main checkout: I only read it, with GIT_OPTIONAL_LOCKS=0, and ran worktree add/remove there. It was clean at the start and the end; HEAD stayed 701f67c. I did not touch base or memwt2.
• My worktrees: I created and removed 6. In them, I restored mutated files with git show HEAD:<path>; I used no stash.
• Cleanup: I removed all 4 venvs and /tmp/v7.
• Kept, in vfy7/: REPORT.partial.md, logs/, probes/, gdocs/, dnshook/, pr_body.md and ledger_diff.txt.
• Read outside vfy7/: only vfy6/REPORT.partial.md, vfy6/pr1302.json, and directory listings of vfy5/ and vfy6/.
• Network:
• Google's field-service page and the v25 field-reference pages, fetched read-only.
• PyPI installs.
• GitHub REST reads only (the PR, its check-runs, its timeline).
• No provider call.
• Deviations from CI: plain venvs rather than setup-python; -p no:cacheprovider on the governance run; -rf added to some runs; pytest installed after the lock.
• No writes: no pushes, comments, records, deploys or dispatches.

4.13 Pass 6 dispositions (fixes in 9d9cd01 and 85b7ecb; record in the commit that adds this section)

How each fix is verified (§3.3): - A test that fails on 701f67c's code: D3, D4. - Seeds on the real files: D1 and D7. Of the 15 arming routes seeded, the pins as pass 6 read them catch 1, and the new pins catch all 15. A legal look-alike passes both. - A seed that fails when the rule is removed: D5's metric half. - Record and docstrings: D2, D5, D6.

The heals are this session's own and therefore non-independent; pass 7 re-checks them before the merge gate. Pass 6's verdicts on the pass-5 items stand as reported (§4.12); its two PARTIALs are N4 (D1) and N6 (D2).

Pass 6's other observations, recorded as given (§4.12): - What it did not check: - live provider behaviour, the serving revisions, and whether Cloud Build would run any seeded file; - the gates on the merge result with fa1cc19 (it checked only for conflicts). 5971bcb merges fa1cc19, and the final-tree gates run on the merge result; - the console's vitest, tsc and Playwright suites; - whether §4.10 quotes pass 5 verbatim; - the PR body's edit history between 00:17Z and 01:14Z; - CI's git version. - Its DNS audit of the image-lock GAQL suite recorded 126 metadata-server lookups and no accounts.google.com lookup. It did not raise the metadata lookups as a finding. - Footprint: it only read the main checkout, removed its worktrees and venvs, and kept its notes in vfy7/.

4.14 Pass 7 — follow-up PR #1302 (701f67c..d14dba0, report verbatim)

The verifier received the range, the earlier reviews (in this file) and the rules; never the builder's reasoning. It ran 2026-10-02 from about 02:35Z to 03:17Z. Its report, verbatim (taken from its hand-back; the copy it kept at vfy8/FINAL.md differs in the last line only):

Independent verification, pass 7 (blind): 701f67c..d14dba0 (draft PR #1302)

Bottom line. I found no blocker and no MAJOR. I found one MINOR and five NITs.

• Code fixes D3, D4 and D5 are FIXED.
• On 701f67c's code with 9d9cd01's test files, exactly 2 tests fail, the 2 the builder named. Reproduced.
• With the metric half removed, exactly test_the_check_catches_what_it_encodes fails.
• D1 is PARTIAL. All five of pass 6's seeds now fail the pin, seed 5 included. But nine new in-repo routes I seeded pass both email tests, and three sentences of the record are false (N2).
• D7 is PARTIAL (MINOR). I replayed pass 6's own D7 seed from its kept mutate.py. It still passes, 37 passed and 4 skipped. That seed is a step in the cell's own Cloud Build file. The record says D7 is fixed, and it labels a different seed "pass 6's D7": one in the workflow (N1).
• D2 and D6 are ACCURATE. N6 is fixed. But CLOSEOUT and RESUME credit the record fixes to 9d9cd01 and 85b7ecb; the PR body correctly says d14dba0 (N4).
• Data Manager.
• A body of the wrong shape is now read, not raised, on both paths.
• A documented-shape body gives identical output on both trees.
• The late-read note gives the right reason in all 9 cases I probed.
• A pre-existing case still raises: an unquoted Infinity in any recordCount. It stops the sweep. The PR body and CLOSEOUT overstate this (N3).
• The rest of the record is ACCURATE: the counts and states, API-A3, A7 and A11 moving to REVIEW_READY, the index markers, and API-A6, A13, F3 and F6.
• Gates: all green in fresh venvs. The one exception is docs/audits/tests::test_wo31_register, which fails identically on 3d5278b and fa1cc19: commit 26bec9c6 is absent from this clone. PR CI on d14dba0: 28 check runs, 27 success, 1 skipped.

Pass-6 items

Item	Verdict	Evidence I produced
D1 (test scope + record)	PARTIAL	Pass 6's own seeds, replayed from its kept mutate.py and mutate2.py on d14dba0, each fail exactly test_the_console_email_route_stays_unarmed_on_deploy: - seed 1 (ui_wf_second_subst); - seed 2 (deploy_all_subst); - seed 3 (dockerfile_env); - seed 4 (ui_wf_flags_file, ui_wf_other_config); - seed 5 (ui_shell_obfuscated). Seed 5 is now caught by the substring merging-flag check, though §3.3 calls it out of reach. The builder's 11 console seeds each fail exactly that test. With 701f67c's test file, only B02 fails. Not caught: nine in-repo routes (V01–V09, under N2).
D2 (record)	FIXED / ACCURATE	CLOSEOUT.md:294 now reads "pass 7, which re-checks the pass-6 heals, must report no open blocker".
D3 (code)	FIXED as scoped; residual NIT (N3)	Old code + new test: AttributeError at request_tracking.py:336. Head reads these without raising, on both paths: errorInfo a string, warningInfo an int, the row list 5, a dict or a string, and a non-mapping body. The old code raised on the first three. A documented-shape body with 2 destinations gives identical output on head and old code. Still raises (pre-existing): a recordCount of Infinity or -Infinity raises OverflowError on both paths.
D4 (code wording)	FIXED	9 late cases probed (probes/dm_reasons.py): - re-sent and accepted, or re-sent and still in flight: "re-sent as attempt 2"; - a later read settled the record, advanced it, or failed; or R2 was overtaken by R3, which applied: "a newer read had already updated this record"; - the claim was taken over by a sweep or a manual refresh and is still in flight; or R2 was noted while R3 is in flight: "its claim was taken over by another read". The old code said "newer read" in the last three.
D5 (docstring + test)	FIXED	Google's field-service guide (fetched; last updated 2026-09-30): a non-FROM resource "must be compatible with all other fields, segments, and metrics that are selected". Each v25 resource page lists "all metrics and segments that can be put in the same SELECT clause as the fields of" the resource. Proxy vs the documented list: for the 3 attributed owners the registry uses (campaign_budget, campaign, ad_group), against all 14 fixture segments and metrics: 42 comparisons, 0 mismatches. Not vacuous: 6 queries exercise it, and its seed fails when it is removed. The "Not encoded" list is accurate: - the 9 non-FROM attributed names in the fixture are exactly the docstring's; - ad_group_criterion is the only one any query selects; - its v25 page has no segment or metric tables; - the Cookbook keyword query is as described; - the fixture has no resource-level lists.
D6 (record)	ACCURATE	By reading orchestrator.py:519-567 and main.py:178-180: a skipped child and a raised child carry no run_id or synthetic key, so they project to null. A child that ran (ok, or with extraction errors) carries both.
D7 (test scope + record)	PARTIAL (N1)	Caught: the builder's 4 GAQL seeds each fail exactly test_the_deploy_keeps_live_mutations_off. 701f67c's pin catches 0 of them. Not caught: - pass 6's own seed, gaql_services_replace: 37 passed, 4 skipped; - V10 to V12.
N4 (pass 6 PARTIAL)	still PARTIAL	Through the D1 and D7 residuals.
N6 (pass 6 PARTIAL)	FIXED (D2)	A new disagreement between the documents is N4 below.

Record items.

Item	Verdict
API-A3, API-A7 and API-A11 → REVIEW_READY	Sound. No pass-6 finding maps to them, and 9d9cd01 and 85b7ecb touch none of their code or tests. These are the only state changes against 701f67c.
Counts	ACCURATE. - 65 issues. - Implementation: 56 IMPLEMENTED, 7 not applicable, 2 OPEN. - Testing: 55 TESTED, 10 not applicable. - Review: 53 REVIEW_READY, 6 IN_PROGRESS (A6, A12, A13, F3, F6, G14), 2 OPEN, 4 not applicable. - Deployment: 32 DEPLOYED, 3 in progress, 13 OPEN, 17 not applicable. - Runtime: 48 OPEN, 4 BLOCKED_EXTERNAL (E4, D6, C5, F5), 13 not applicable. - Nothing is VERIFIED. CLOSEOUT and RESUME match.
Index markers	ACCURATE. - API-G14: [8] is marked SUPERSEDED. - API-A6: [9] is marked, and [10] corrects it. - API-A3: source_evidence [0] points to [2]. - API-A7: [5] points to [9].
API-A6 [10], API-A13 [7], API-F3, API-F6 and the new lines on A3, A7 and A11	ACCURATE.
API-G14 [9], §4.13 D1, docstring, PR body	INACCURATE (N2).
API-A12 (new line), §4.13 D7, §3.3 row "pass 6's D7", the test comment "nothing deploys the reference manifest"	INACCURATE (N1).
§3.3, "Pass 6's seed 5 … out of the pin's reach"	INACCURATE, in the harmless direction: the seed as pass 6 gave it is caught.
§3.1, §3.2 (its numbers equal mine on d14dba0), §3.5, §4.11's marked rows	ACCURATE.
§4.12	Consistent with pass 6's kept files. Every number, seed and probe in it matches vfy7/REPORT.partial.md, logs/mutations.txt (18 seeds) and probes/. Pass 6's final report text is not kept in vfy7, so I cannot prove the quote verbatim; I can only say nothing in those files contradicts it.
Deployed, verified or safe claims	None beyond the evidence. "Not merged or deployed" holds. "Merging deploys 2 services" holds: the router dispatches deploy-google-ads-gaql and deploy-ui, plus the frontend-guard check. "PR CI green on the head" holds: 27 success, 1 skipped.

New defects

N1 — MINOR (test scope + record): pass 6's own D7 seed still passes, and the record says D7 is fixed. - Where: - src/cells/google_ads_gaql/tests/test_api_compat_binding.py:974-990. The scan reads .github, ops, scripts and deployment, and only .yml, .yaml, .sh and .py files there. The cell's own cloudbuild.yaml is read only for the env flag and the pinned keys. - The test comment at :974-976 ("nothing deploys the reference manifest"). - EVIDENCE.md:660 (§3.3) and :1970 (§4.13 D7). - ISSUES.json:1987 (API-A12). - The PR body's "GAQL cell: ACT" row. - Scenario: pass 6's vfy7/probes/mutate.py gaql_services_replace, applied verbatim to d14dba0, gives 37 passed and 4 skipped. It does two things: - appends to src/cells/google_ads_gaql/cloudbuild.yaml a step gcloud run services replace src/cells/google_ads_gaql/cloud-run-google-ads-gaql.yaml; - sets the manifest's GAQL_ENABLE_LIVE_MUTATIONS to "true".

On merge, that Cloud Build file deploys the cell, and the replace step would then leave live mutations on. The operation builder still raises (pinned), so no mutation runs today. The builder seeded a different variant, a step in deploy-google-ads-gaql.yml, and §3.3 attributes it to pass 6. - Same gap, also passing: - V10: a step in deploy-google-ads-gaql.yml running gcloud run services update google-ads-gaql-cell --update-env-vars=GAQL_ENABLE_LIVE_MUTATIONS=true,.... - V11: a copy of the manifest under deployment/gaql/live.yaml, deployed by a services replace step. - V12: scripts/arm_gaql.js, which names the manifest.

The class docstring (:951) still says that flipping any of the pinned settings is "a visible change to this test". - Fix: - Pin the cell's Cloud Build steps exactly (their ids, or no services replace, and the manifest's name absent). - Scan workflows for the three key names, as the console pin does for its variable. - Drop the suffix filter, or state it. - Correct §3.3, §4.13, API-A12 and the PR body.

N2 — NIT (test scope + record, the same class as pass 6's D1): the console pin's reach is overstated again. - Where: - tests/governance/test_api_lifecycle_inventory.py: :254-255 (_CONSOLE_ENV_SOURCES), :285-292 (the docstring), :305, :310 and :316-318. - ISSUES.json:1762 (API-G14 [9]), EVIDENCE.md:1964 (§4.13 D1) and the PR body's "Console Klaviyo route + inventory" row. - False sentences: - "every file under .github, ops, scripts and deployment". Only .yml, .yaml, .sh, .py, .json and .env suffixes are read. Those roots hold 77 .tf files, 8 extensionless files (including ops/Makefile), and .js, .ts and .hcl files. - "a third submitter fails it". This holds only when the path is spelled exactly. - "each submit command's substitutions must be exactly the image tag". Only lines that start with the flag are read. - The "out of reach" list is not the remainder. - Seeds that pass both email tests and 701f67c's pin (each restored clean afterwards): - V01: EMAIL_SERVICE: klaviyo in the committed miz-oki-command-center-ui/env.production.yaml. The documented scripts/ops/deploy_frontend_cloudrun_prod.sh turns that file into --set-env-vars. - V02: a deploy-ui.yml step running services update --env-vars-file= on that file. - V03: scripts/arm_email.mjs, run by a step. - V04: an extensionless .github/scripts/arm-email. - V05: Dockerfile.prod with ENV EMAIL_SERVICE, and the console cloudbuild.yaml's -f pointed at it. No workflow edit is needed, and deploy-ui fires on merge. - V06: next.config.js with env.EMAIL_SERVICE. Next 15.5.24 resolves .js before .mjs; I read that, I did not build it. - V07: a new workflow with --config=miz-oki-command-center-ui/./cloudbuild.yaml and extra substitutions. - V08: a second --substitutions in the middle of a line in deploy-ui.yml. - V09: EMAIL_SERVICE in cloudbuild.otel.yaml's Knative env (it deploys miz-oki-command-center-ui), and a new workflow that submits it. - Mitigation: the route also needs EMAIL_API_KEY, SENDGRID_API_KEY or KLAVIYO_PRIVATE_API_KEY, and none is in the console's deploy env. That barrier is not pinned. - Fix: - Reword every copy to the measured scope. - Add the out-of-reach classes above. - Read the Cloud Build file's -f target, every next.config.*, and the console directory's YAML env files. - Scan without the suffix filter.

N3 — NIT (code, pre-existing; the record overstatement is new): a non-finite count still raises out of reconcile_record. - Where: - request_tracking.py:309-313: _count catches TypeError and ValueError, not OverflowError. - main.py:412: httpx r.json() uses json.loads, which accepts Infinity. - The sweep loop :557 has no per-record isolation. - Scenario (probe): a 200 response with "recordCount": Infinity raises OverflowError on the applied path and on the late path. reconcile_due raises at that record, and the other 2 due records stay submitted. The old code behaves identically. - Record overstatements of the same thing: - CLOSEOUT.md:60: "a malformed status body is read rather than raised". - The PR body: "instead of raising and stopping the sweep's batch". - §4.13 D3: "an exception from the store stops the batch". - By reading, not run: reason and destination.reference are stored as given. Firestore's documented limits would refuse a nested array, depth beyond 20, or more than 1 MiB on the applied-path write. - Fix: except (TypeError, ValueError, OverflowError) plus a finiteness check; a try/except per record in reconcile_due; and correct the wording.

N4 — NIT (record): the documents disagree on where the pass-6 fixes are. - Where: - CLOSEOUT.md:278: "All are fixed in 9d9cd01 and 85b7ecb". - RESUME.md:84-85: "Its two partials … and its seven nits are fixed in 9d9cd01 and 85b7ecb". - Measured: 9d9cd01 changes 4 files: request_tracking.py and 3 tests. D2 (the CLOSEOUT row), D6 (API-A6) and D1's record wording were changed in d14dba0. The PR body says so correctly. - Fix: say "the code findings in 9d9cd01 and 85b7ecb; the record findings in d14dba0".

N5 — NIT (label): an unreadable body is recorded as the provider's own "unknown". - Where: request_tracking.py:373. - Scenario: with the row list 5, a string or a dict, or a non-mapping body, the record becomes unknown/provider_reported_unknown with the history note "status read". That is the same record a genuine REQUEST_STATUS_UNKNOWN leaves. The record keeps being polled until its budget runs out, which is sensible; only the label is wrong. Pre-existing for an empty body; the row list 5 is a new path to it. - Fix: a distinct reason, or the note "unreadable status body".

N6 — NIT (observation, pre-existing, no impact today): the registry check against Google's own published queries. - The segment half of the attributed rule, as documented and encoded, would refuse Google's Query Cookbook "Search terms" query. That query selects segments.keyword.info.match_type with campaign.name FROM search_term_view, and campaign's v25 list (152 segments) omits that segment. The metric half refuses none of the Cookbook's 15 owner/query pairs. - Google's segmentation guide says "When a segment is in the WHERE clause, it must also be in the SELECT clause", except the core date segments. The check does not encode this, and the docstring does not list it: replace(campaign_performance_v1, where="segments.device = 'MOBILE'") gives []. No registered query has a segment only in WHERE (measured).

Test runs

All runs: fresh python3.11 -m venv venvs (CPython 3.11.15, pytest 9.1.1) built from the install lines below, under unshare -rn, with the proxy variables unset (both cases), TMPDIR=/tmp/v8/<run>, and commit signing off through GIT_CONFIG_COUNT/KEY/VALUE environment variables only. Every run is on d14dba0 unless stated.

The venvs: - ci: ci.yaml's Install Dependencies line, the consolidated-tests line, -e contracts, and the whitepaper requirements. - wire: the suite-wiring line. - gates: the governance-gates line. - lock: src/cells/google_ads_gaql/requirements.lock.txt, then pytest (google-ads 33.0.0, fastapi 0.109.1, pydantic 2.5.0). - cing: the install line of the deploy-service-canonical-ingestion.yml gate.

Command	Environment	Result
python -m pytest "services/service-data-manager-connector/tests" -q -p no:cacheprovider -o addopts=""	wire, MIZOKI_STORE=memory	54 passed
python -m pytest "src/cells/google_ads_gaql/tests" … (same flags)	wire	96 passed, 4 skipped
same	lock	100 passed
pytest tests/remediation/test_gaql_governance_wiring.py	wire / cing (the only workflow that runs it is deploy-service-canonical-ingestion.yml, as pytest tests/remediation)	5 passed / 5 passed
python -m pytest "docs/audits/tests" … @d14dba0, @fa1cc19, @3d5278b (my own worktree)	wire	1 failed (test_wo31_register: "not in '26bec9c6…'"), 7 passed, identical on all three; the object is absent from this clone
pytest tests/governance -c tests/governance/pytest.ini -p no:cacheprovider	ci	4351 passed, 7 skipped, 6227 subtests, rc 0 (444 s)
bash .github/scripts/content_gates.sh	gates venv first on PATH	rc 0, 155 passed
python3 scripts/api_lifecycle_check.py	gates	rc 0 (FAILURES 0, WARNINGS 1, UNKNOWNS 20)
python3 scripts/gate_leak_scan.py --check	gates	rc 0 (0 new, 0 grown, 0 stale)
python3 scripts/claude_memory.py check --strict	gates	rc 0 (valid)
python3 .github/scripts/deploy_router.py --base fa1cc19 --head d14dba0	gates	21 files → deploy-google-ads-gaql.yml (8), deploy-ui.yml (1), frontend-guard.yml (1); with --base 3f89cd0, 23 files and the same three
git merge-tree --write-tree 9d9cd01 fa1cc19	—	tree d5e3561 = 5971bcb^{tree}: a clean merge with no hand edits. It brought only 8924d1c's two Shopify docs; there is no overlap with the PR's 21 files and no interaction
701f67c's code with 9d9cd01's 3 test files	wire / lock / ci	Data Manager: 2 failed (exactly the 2 named), 52 passed. GAQL suite: 96 passed + 4 skipped (wire), 100 passed (lock). GAQL file alone: 37 passed + 4 skipped. Inventory: 23 passed
15 builder seeds + look-alike + clean (probes/seeds.py), with head's pins and with 701f67c's pins	ci + wire	each fails exactly the named pin; 701f67c's pins catch 1 (B02); the look-alike and the clean tree pass both
12 own seeds V01–V12	ci + wire	all pass, under both the new and the old pins
pass 6's 17 seeds, replayed	ci + wire	16 caught as expected (seed 5 included); gaql_services_replace not caught
metric half removed (f.startswith("segments."))	wire	1 failed (exactly test_the_check_catches_what_it_encodes), 36 passed, 4 skipped
Data Manager probes (probes/dm_probe.py, dm_reasons.py) on head and 701f67c	wire, memory store	as reported under D3, D4 and N3
PR #1302 check runs on d14dba0	gh api, read-only	28: 27 success, 1 skipped (Live Cell Endpoint Tests)

What I did not check

• Live provider behaviour and the serving revisions.
• Whether Cloud Build, gcloud or Next.js would act on any seed. Three behaviours come from documentation or reading, not measurement: an image ENV surviving --set-env-vars, how gcloud treats a repeated --substitutions, and whether Next.js prefers next.config.js and inlines its env.
• Firestore behaviour. It is from its documented limits; I ran nothing against it.
• Whether Google's API accepts the Cookbook query that conflicts with the documented rule.
• The console's vitest, tsc and Playwright suites myself. CI's Frontend Guard is success.
• A DNS audit of the image-lock suite. Every suite ran under unshare -rn.
• That §4.12 is verbatim, beyond being consistent with vfy7.
• CI's git version.
• The PR body's edit history.

Disclosures

• Main checkout: I read it only, with GIT_OPTIONAL_LOCKS=0. I also ran git worktree add and remove there, and one git worktree prune; base and memwt2 are still listed and I did not touch them. At the start and the end, status was clean, HEAD was d14dba0 and there were 0 stashes.
• My worktrees: I created and removed 6 under vfy8 (head, p701, main, w3d, mut, mut2). In them, I restored seeded files with git checkout -- . and git clean; I used no stash.
• Cleanup: I removed all 5 venvs and /tmp/v8.
• Read outside vfy8:
• vfy7/REPORT.partial.md, vfy7/probes/mutate.py, vfy7/probes/mutate2.py, vfy7/logs/mutations.txt;
• directory listings of vfy5, vfy6 and vfy7;
• one listing of the scratchpad root, file names only. I read none of those files.
• Network:
• read-only fetches of Google documentation: the field-service guide; the v25 pages for campaign, campaign_budget, ad_group, ad_group_criterion and metrics; the Query Cookbook; the segmentation guide (one 404 first); and two Firestore pages;
• PyPI installs;
• GitHub REST reads of PR #1302 and its check runs.

I made no provider call. - Deviations from CI: - plain venvs rather than setup-python; - -p no:cacheprovider and -rf/-rfE added on some runs; - content gates and the gate scripts ran in a clean worktree at the same commit. - No writes: no pushes, comments, records, deploys or dispatches. - Kept, in vfy8/: REPORT.partial.md (which also holds this report), logs/, probes/ and gdocs/.

4.15 Pass 7 dispositions (fixes in 49f8d80; record in the commit that adds this section)

How each fix is verified (§3.3): - A test that fails on d14dba0's code: N3. - The verifiers' own seeds, replayed on the real files: N1 and N2. Of 28 arming routes from pass 7's driver and pass 6's D7 seed, 49f8d80's pins catch 28 and d14dba0's catch 15. The clean tree and a look-alike name pass both. - Docstrings and record: N2's wording, N4, N6. - Recorded, not changed: N5, N3's per-record isolation, and N6's Cookbook observation.

The heals are this session's own and therefore non-independent; pass 8 re-checks them before the merge gate. Pass 7's verdicts on the pass-6 items stand as reported (§4.14): D2 to D6 FIXED or ACCURATE, and D1 and D7 PARTIAL (N2, N1).

Pass 7's other observations, recorded as given (§4.14): - What it did not check: - live provider behaviour and the serving revisions; - whether Cloud Build, gcloud or Next.js would act on any seed: an image ENV surviving --set-env-vars, a repeated --substitutions, and the next.config.js precedence are from documentation or reading; - Firestore behaviour (documented limits only); - whether Google accepts the Cookbook query; - the console's vitest, tsc and Playwright suites (CI's Frontend Guard is green); - a DNS audit (every suite ran under unshare -rn); - that §4.12 is verbatim: pass 6 kept no copy of its final text, so pass 7 could check §4.12 only against pass 6's kept files, which nothing in it contradicts; - CI's git version, and the PR body's edit history. - Footprint: it read the main checkout only, and ran git worktree add/remove and one git worktree prune there. It removed its worktrees and venvs, and kept its notes in vfy8/.

4.16 Pass 8 — follow-up PR #1302 (d14dba0..d7a5af2, report verbatim)

The verifier received the range, the earlier reviews (in this file) and the rules; never the builder's reasoning. It ran 2026-10-02 from about 03:50Z to 04:28Z. Its report, verbatim (taken from its hand-back):

Independent verification, pass 8 (blind): d14dba0..d7a5af2 (draft PR #1302)

Bottom line. I found no blocker and no MAJOR. I found one MINOR and four NITs.

• The pass-7 heals hold for every seed they were built against.
• I replayed pass 7's seed driver (vfy8/probes/seeds.py, paths changed only) and pass 6's D7 seed (vfy7/probes/mutate.py, gaql_services_replace, verbatim). That is 28 arming routes.
• With 49f8d80's test files, all 28 are caught, and each fails exactly the test named. With d14dba0's test files, 15 are caught.
• The clean tree and the look-alike name pass both.
• N3's new test fails on d14dba0's code: 1 failed (OverflowError), 54 passed. Each half of the N3 fix makes that test fail when I remove it.
• MINOR: N1 is only PARTIAL, so D7 stays PARTIAL. Six in-repo, literal routes I seeded (G1–G6) pass both the new and the old GAQL pins. One of them is a fourth step in the cell's own Cloud Build file. So these statements are false:
• "the Cloud Build file's steps are pinned";
• the docstring's "out of reach" list.

The operation builder still raises NotImplementedError (its test passes), so no mutation can run today. - NITs: - Both pins now fail on plausible changes to other services (false positives). - N3 bounds each count, but not their sums or the number of status rows. On head, with Firestore's own encoder in the store path, one provider answer raised 960 times in 80 hours, and its record was never retired. - Several record sentences overstate the fixes (defect 4). - One pre-existing accept-path gap of the same kind as N3 (defect 5). - Gates: all green in fresh venvs. The one exception is test_wo31_register, which fails identically on 3d5278b because this shallow clone lacks commit 26bec9c6. - PR CI on d7a5af2: 28 check runs, 27 success, 1 skipped. - RESUME's own rule ("a blocker, major or minor in the pass-7 heals is fixed and re-checked again") applies to the MINOR.

Pass-7 items

Item	Verdict	Evidence I produced
N1 (MINOR: GAQL pin and record)	PARTIAL	Pass 6's D7 seed, verbatim: the new pins fail exactly test_the_deploy_keeps_live_mutations_off; d14dba0's pins pass it. V10, V11 and V12 are now caught (the old pins catch none of them). G1–G6 (defect 1) pass both the whole new GAQL test file (0 failures) and the old pin.
N2 (NIT: console pin and record)	FIXED for the nine routes; NIT residuals	V01–V09 each fail exactly test_the_console_email_route_stays_unarmed_on_deploy; the old pin catches none. Console total: 20 of 20 (old pin: 11). Residuals: C3/C3b and C4 pass (defect 4); C1 and C2 are new false positives (defect 2).
N3, code	FIXED as scoped	Old code with the new tests: 1 failed (the named test), 54 passed. Head with the 64-bit range check removed, or with _label returning the raw value: exactly that test fails. 10 documented-shape bodies (int64 min/max strings, numbers instead of strings, a missing count, an empty body, 1–2 destinations): apply_status output identical on head and on d14dba0.
N3, record: "never retired"	ACCURATE (now measured)	Old code, 80 hours of 1-minute sweeps: 960 raises, one every 300 s. The record stayed submitted with 0 checks, past the 72-hour TTL. Head: finalized on the first sweep. Label mismatch: §3.3 says "by reading"; §4.15 and API-F6 say "measured".
N3, record: "With every provider answer now read, [a store exception] is the remaining way for a record to stop a sweep"	INACCURATE	Defect 3
N3's per-record isolation (recorded, not changed)	Deferral defensible; premise false	Rule 01 ("write paths fail loudly") supports not swallowing store errors. But a provider answer can still produce a store error, with the same never-retired outcome (defect 3), so the residual is larger than recorded.
N4 (record)	ACCURATE	CLOSEOUT and RESUME now credit the code findings to 9d9cd01/85b7ecb and the record findings to d14dba0.
N5 (recorded)	Sound as a deferral; its reason is incomplete	Head and old both label a row list of 5, a string, or a non-mapping body as unknown/provider_reported_unknown. The stated reason (it would widen the unknown_reason vocabulary) covers one of pass 7's two fixes. The other, the history note "unreadable status body", widens nothing.
N6 (observation, docstring)	ACCURATE	Segmentation guide (fetched; last updated 2026-10-01): its wording matches the docstring. Registry: 11 queries; 7 have a segment in WHERE, all segments.date, and each also selects it. So no query has a WHERE-only segment. Cookbook (last updated 2026-09-30): the "Search terms" query selects segments.keyword.info.match_type with campaign.name FROM search_term_view. Campaign's v25 resource-level segment list (152 entries) has no keyword.* segment. Registry test: passes.
Pass 7's PARTIAL on D1	Now FIXED for every measured route	NIT residuals as for N2
Pass 7's PARTIAL on D7	Still PARTIAL	G1 and G5 are exactly D7's class: a deploy of a manifest copy, and a different Cloud Build config from another workflow.

Record items

Item	Verdict
§4.14 verbatim	ACCURATE. The 194 quoted lines equal vfy8/FINAL.md except the last line, as stated. vfy8/REPORT.partial.md holds the same text. Pass 7's hand-back itself was not available to me.
Counts and states (ISSUES.json)	ACCURATE: - 65 issues. - Implementation: 56 IMPLEMENTED, 7 not applicable, 2 OPEN (G13, A12). - Testing: 55 TESTED, 10 not applicable. - Review: 54 REVIEW_READY, 5 IN_PROGRESS (F3, G14, A12, A13, F6), 2 OPEN, 4 not applicable. - Deployment: 32 DEPLOYED, 3 in progress, 13 OPEN, 17 not applicable. - Runtime: 48 OPEN, 4 BLOCKED_EXTERNAL (E4, D6, C5, F5), 13 not applicable. - Nothing is VERIFIED. CLOSEOUT and RESUME match.
API-A6 → REVIEW_READY	Sound. It is the only state change. 49f8d80 does not touch A6's code or its tests (test_api_compat_binding.py:704–830). Its new line only records pass 7's verdict.
API-A12, pass-7 line	Numbers ACCURATE (8 of 8; 4 with the old pin). "Out of reach…" INACCURATE (G1–G6).
API-A13, F3, F6 lines	ACCURATE. F6 says nothing about sums or rows.
API-G14	Numbers ACCURATE (20 of 20; 11 with the old pin). "Any spelling of the config path" is overstated (C3).
EVIDENCE §3.1, §3.2 (pass-7 heal head), §3.3 (pass-7 block and the two marked pass-6 lines), §3.5	ACCURATE. My numbers equal the record's. Pass 6's kept seed did put the step in the Cloud Build file, and its seed 5 does carry --update-env-vars.
§4.13 marked rows	ACCURATE. NIT: D7's and A12's markers do not say that the old GAQL scan read only four suffixes.
§4.15	N1's disposition and its "out of reach" list: INACCURATE. N2: mostly accurate. N3's last sentence: INACCURATE. N4, N5, N6: ACCURATE.
CLOSEOUT	ACCURATE, except the Data Manager row (:60): "counts or labels the store cannot hold, is read rather than raised" is overstated.
RESUME	ACCURATE.
PR body	The gate table and the numbers are ACCURATE (reproduced). INACCURATE: - the GAQL row: "that file's steps…", "changes the cell's service with those verbs", and "Out of reach"; - the corrections bullet "both read six file suffixes only": d14dba0's GAQL scan read four (.yml .yaml .sh .py, :988); - the Data Manager row: overstated, as in CLOSEOUT; - the console row's "any spelling" (C3).
Deployed, verified or safe claims	None beyond the evidence. PR #1302 is open, a draft, and not merged (REST read). The router dispatches 2 deploys (GAQL cell, console) plus the frontend-guard check, as stated.

New defects

1. MINOR: the GAQL deploy pin is bypassable by literal in-repo changes, and the record says otherwise. - Where: - src/cells/google_ads_gaql/tests/test_api_compat_binding.py: :955–959 (the constants), :968–977 (the docstring), :1002–1008 (the step pin, done with line regexes), and :1025–1034. In :1025–1034 the verb check runs only when a file names the service, and the cell's directory is not scanned beyond cloudbuild.yaml. - The record: §4.15 N1, API-A12's pass-7 line, and the PR body's GAQL row. - Seeds: each passes the whole new GAQL test file and d14dba0's pin, and each was restored clean. - G1: a new push-to-main workflow runs gcloud run services replace src/cells/google_ads_gaql/live.yaml. live.yaml is the reference manifest with GAQL_ENABLE_LIVE_MUTATIONS: "true", kept in the cell's directory. The workflow never names the service, so the verb check never runs. - G2: a fourth step in the cell's own cloudbuild.yaml, written - id: arm-live / name: gcr.io/cloud-builders/gcloud / args: [run, services, replace, src/cells/google_ads_gaql/live.yaml, --region=us-central1]. - PyYAML parses 4 steps; the ^\s*- name: regex sees 3. - The step has no entrypoint, and the verb regex misses services, replace. - .gitignore re-includes /src/ (I read this; I did not run a build). - G3 and G4: a deploy-google-ads-gaql.yml step running gcloud run services \, then update google-ads-gaql-cell … --env-vars-file=src/cells/google_ads_gaql/live-env.yaml on the next line. G4 is the same with the verb quoted ("update"). - G5: src/cells/google_ads_gaql/cloudbuild.live.yaml, a copy of the pinned file with =true, submitted by a new workflow. - G6: a deploy-google-ads-gaql.yml step running gcloud run deploy google-ads-gaql-cell --image=… --env-vars-file=src/cells/google_ads_gaql/live-env.yaml. It needs no trick: run deploy is not a pinned verb.

None of these is a by-hand change, a deploy from outside the repository, or a name assembled at run time. - Fix: - Parse the Cloud Build file with yaml.safe_load and assert the exact step list (name, entrypoint, args). - Before matching verbs, tokenize the arguments: join list items, and strip quotes and line continuations. - Treat run deploy, services update/replace, --env-vars-file, and --set-env-vars/--update-env-vars on the service as changes. - Scan the cell's directory (excluding tests) for any other Cloud Build file or Knative YAML that names google-ads-gaql-cell. - Add "a file outside the scanned places that a literal deploy step reads" to the docstring, API-A12, §4.15 and the PR body, as the console pin already does.

2. NIT: both pins now fail on legitimate changes to other services (false positives). - Where: tests/governance/test_api_lifecycle_inventory.py:257–259 with :345–354; test_api_compat_binding.py:959 with :1033–1034. - Seeds: each fails the new pin; the old pin passes. - C1: deploy-homepage.yml:409's --update-secrets gains SENDGRID_API_KEY=…. That is the site's own pilot-email key (# MIZ OKI 3.5/mizoki_runtime/pilot_requests.py:34). The console test fails. - C2: ops/rails/arm_klaviyo_feed.sh sets measurement-rails' KLAVIYO_PRIVATE_API_KEY (named in docs/measurement-rails/RUNBOOK.md:189 and klaviyo_feed.py:47). The console test fails. - GFP: verify-cloudrun-state.yml, whose fleet list names google-ads-gaql-cell, prints gcloud run services update {svc} --min-instances=1. The GAQL test fails. - Why it matters: arming either documented dark rail through a scanned deploy file would turn the governance suite red for a service it does not touch. That invites narrowing the rule, which rule 01 forbids. - Fix: fail only when the same command targets the console or GAQL service. At minimum, document the coupling.

3. NIT: Data Manager. N3 bounds each count, but not the values derived from them or the number of status rows (pre-existing; the record overstates the fix). - Where: services/service-data-manager-connector/request_tracking.py:353 (the rows are unbounded) and :392–400 (failed, sent, confirmed_events and failed_events are unbounded). In the record: CLOSEOUT.md:60, §4.15 N3, and the PR body's Data Manager row. - Measured (head and d14dba0 behave identically): - Two destinations, each answering recordCount "9223372036854775807", give confirmed_events 2^64−2. - A partial success with two such error counts gives failed_events 2^64−2. - An error count of −2^63 gives confirmed_events 2^63+5. - google-cloud-firestore 2.34.0 and 2.11.1 _helpers.encode_dict refuse all three, offline: ValueError: Value out of range. - End to end on head: I ran 80 hours of 1-minute sweeps with a store whose transact_update runs that encoder (as transaction.set does). There were 960 raises. The record stayed submitted with 0 checks and its claim held, and it was never retired; the other two records succeeded. - Rows: a 1-destination record answered with 90 SUCCESS rows reads as success and stores a 1,067,314-byte provider_status. 20,000 minimal rows give 2,220,004 bytes. Firestore's 1 MiB document limit comes from its documentation; I did not run Firestore. - The memory store accepts all of these, so the test suite cannot see them. - Fix: - Clamp the sums, or treat a total outside int64 as unknown (confirmed_events None), and reject negative counts. - Cap the rows at the record's number of destinations. - Add a seed whose sums overflow. - Correct CLOSEOUT :60, §4.15 N3 and the PR body.

4. NIT: record wording. - PR body: "both read six file suffixes only" is wrong for the GAQL scan, which read four. - §4.13 D7 and API-A12's pass-6 marker: they do not say the old scan read four suffixes (pass 7's V12), unlike G14's marker. - "Never retired": §4.15 and API-F6 say measured; §3.3 says "by reading". The fact is true. - "Under any spelling of its path" (console): C3 and C3b pass all 23 inventory tests. C3b is a workflow with working-directory: miz-oki-command-center-ui running gcloud builds submit .. --config=cloudbuild.yaml --substitutions=…,_REQUIRE_AUTH=false. This does not arm the email route by itself. - C4: YAML-escaped names ("EMAIL\x5FSERVICE") in deployment/ui/runtime-env.yaml, applied by a deploy-ui step with --env-vars-file, pass. This is arguably "assembled at run time", and is worth naming.

5. NIT (pre-existing, outside the range's claims; by reading only): field_warnings() (request_tracking.py:163–174) keeps the reason and field of an events:ingest response unbounded and of any type. It is the accept-path twin of N3's labels.

Test runs

Environment for every run: - Fresh python3.11 -m venv venvs (CPython 3.11.15, pytest 9.1.1), built from the install lines below. - Everything ran under unshare -rn. - Proxy variables unset, and also GH, GCP and AWS credential variables. - TMPDIR=/tmp/v9/<run>. - Commit signing off via GIT_CONFIG_* environment variables only.

The venvs: - ci: ci.yaml's Install Dependencies line, the consolidated-tests line, -e contracts, and the whitepaper requirements. - wire: the suite-wiring line. - gates: the governance-gates line. - lock: the GAQL lock file, then pytest (google-ads 33.0.0, fastapi 0.109.1, pydantic 2.5.0). - cing: the gate line of deploy-service-canonical-ingestion.yml (google-cloud-firestore 2.34.0).

Command	Env	Result
pytest tests/governance -c tests/governance/pytest.ini @d7a5af2	ci	4351 passed, 7 skipped, 6227 subtests passed, rc 0 (441 s)
python -m pytest "services/service-data-manager-connector/tests" -q -p no:cacheprovider -o addopts="" (MIZOKI_STORE=memory)	wire	55 passed
same flags, "src/cells/google_ads_gaql/tests"	wire / lock	96 passed + 4 skipped / 100 passed
pytest tests/remediation/test_gaql_governance_wiring.py; pytest tests/remediation -q	wire / cing	5 passed; 396 passed
"docs/audits/tests" @d7a5af2 and @3d5278b (my own worktree)	wire	1 failed (test_wo31_register, git show 26bec9c6b… exit 128), 7 passed; identical on both
tests/governance/test_api_lifecycle_inventory.py	ci	23 passed
bash .github/scripts/content_gates.sh	gates venv first on PATH	rc 0, 155 passed
api_lifecycle_check.py / gate_leak_scan.py --check / claude_memory.py check --strict	gates	rc 0 each: FAILURES 0, WARNINGS 1, UNKNOWNS 20 / 0 new, 0 grown, 0 stale / valid
deploy_router.py --base fa1cc19 --head d7a5af2	gates	21 files → deploy-google-ads-gaql (8), deploy-ui (1), frontend-guard (1)
d14dba0's code with 49f8d80's Data Manager tests	wire	1 failed (the named test, OverflowError), 54 passed
28 replayed arming seeds, plus the clean tree and the look-alike, against the new and the old pins	ci + wire	new pins 28 of 28, each failing exactly the named test; old pins 15 of 28
13 own seeds (G0–G6, GFP, C1–C4, C3b)	ci + wire	G1–G6, C3, C3b and C4 pass both pins; G0 (control) passes both; C1, C2 and GFP fail the new pin only
Data Manager and Firestore-encoder probes	wire / cing / lock	As in defect 3 and the N3 rows
PR #1302 check runs on d7a5af2	gh api, read-only	28: 27 success, 1 skipped (Live Cell Endpoint Tests)

What I did not check

• Live provider behaviour and the serving revisions.
• Firestore itself. I used only its client's offline encoder; the 1 MiB limit is from its documentation.
• Whether Cloud Build or gcloud would execute G1–G6. That they would is from reading.
• The console's vitest, tsc and Playwright suites (CI's Frontend Guard is green).
• A DNS audit.
• Pass 7's hand-back text.
• The PR body's edit history, and CI's git version.

Disclosures

• Main checkout: I read it only, with GIT_OPTIONAL_LOCKS=0, and ran git worktree add/remove there. Status was clean, HEAD was d7a5af2 and there were 0 stashes, at the start and at the end. I did not touch base or memwt2.
• My worktrees: I created and removed 7 under vfy9 (head, head2, old, mut, mut2, mutold, w3d). I seeded files in my own worktrees and restored them with git checkout/git clean and file copies; I used no stash.
• Cleanup: I removed all venvs and /tmp/v9. No /tmp/wo26-* or /tmp/v417-* entries were left.
• Read outside vfy9:
• vfy8/FINAL.md, vfy8/REPORT.partial.md, vfy8/probes/seeds.py and its run and build scripts;
• vfy7/probes/mutate.py;
• directory listings, and one listing of the scratchpad root (file names only). I opened none of the builder's files.
• Network:
• PyPI installs;
• read-only fetches of Google's segmentation guide (three 404s while finding its URL), the Query Cookbook and the v25 campaign fields page;
• GitHub REST reads of PR #1302 and its check runs. One GraphQL attempt was refused (403) before any data was read.

I made no provider call. - Deviations from CI: - plain venvs rather than setup-python; - -p no:cacheprovider and -rf/-rfE added on some runs; - an early governance run had a doubled -q, which hid its summary line; I re-ran it exactly as CI does; - some probe scripts unset only the HTTP(S) proxy variables, but all of them ran under unshare -rn. - No writes: no pushes, comments, records, deploys or dispatches. - Kept in vfy9/: REPORT.partial.md (which also holds this report), logs/, probes/ and gdocs/.

Note (after pass 9, defect F): the quote above is byte for byte pass 8's hand-back (19,536 characters, compared with the SubagentHandback message in pass 8's transcript). Its line ".gitignore re-includes /src/" should read .gcloudignore: the tree has !/src/ at .gcloudignore:4 and none in .gitignore, and pass 8's own notes (vfy9/REPORT.partial.md) say .gcloudignore. The quote keeps pass 8's word.