Shopify Lane Closeout Verification — Step 0 (2026-08-27)

Status of this report: COMPLETE — all 6 verification tracks finished. Two findings surfaced and both are now FIXED (Items 2 and 7 below): a missing source-literal test on the PIXEL_EVENTS_ENABLED activation flag (added), and a stale claim-discipline defect in docs/product/FEATURE_COVERAGE_MATRIX_v1.md describing the built ghost-bid module as "design only, not shipped" (corrected to PARTIAL (DARK)). Everything else verifies clean. See each item's section for the fix detail, and the Bottom Line for the consolidated post-fix state.

Scope note on authority order given in the prompt vs. this repo's actual precedence: the prompt specified WIRING.md > OFFERING_MAP v2.2 > .claude/rules/03-canonical-architecture.md > DEL_AUTHORIZATION_FUNCTION.md > plan of record. This repo's own CLAUDE.md §1 places the constitution set (CONSTITUTION.md, AGENTS.md, OPERATING_SYSTEM.md, GOVERNANCE.md, TRUTH.md) above all of those. Where this report cites the constitution (e.g. cell count, Article VI), that is the higher authority per the repo's own rules, not a deviation from the prompt.

Verified against: origin/main tip d77c56e6 (local branch fast-forwarded from b2f4b309 before any checks ran; 8 commits, git merge --ff-only, no conflicts). Working tree clean; local-only, nothing committed or pushed by this verification pass. An unrelated locked worktree (/sessions/eloquent-stoic-knuth/wt-shopify-arm, branch claude/shopify-oauth-arming, tip d25badc7) is active on a different Shopify OAuth-arming lane — not touched or investigated by this pass.

Doc naming discrepancy: the master prompt names SIGNAL_SHOPIFY_MASTER_v4_FINAL.md. No such filename exists; the canonical file is docs/product/SIGNAL_SHOPIFY_MASTER_v4.md (no _FINAL suffix), matching the canon pointer in docs/reports/SIGNAL_SHOPIFY_LANE_STATUS_2026-08-12_R3.md line 4 and .claude/rules/03-canonical-architecture.md. Treated as the intended target.

Item 1 — C1–C5 + B5 present on main

VERIFIED — all present, matching the R3 report's descriptions.

Note: there is also an unrelated, differently-scoped services/service-action-runner/execution_adapters/reconciliation.py — do not conflate it with the C2 measurement-rails reconciliation harness.

C2 tighten-only ceilings — test-asserted, confirmed. services/measurement-rails/reconciliation.py: - Line 38 (doc): "Tolerances may be **tightened, never loosened**". - Line 59 (doc): "# Tolerance CEILINGS — tighten-only". - Line 82 (refusal message): "the ceiling {MAX_REVENUE_REL_TOLERANCE} — tolerances tighten, never loosen".

test_reconciliation.py: - test_loosening_beyond_either_ceiling_is_refused (line 128) — Tolerances(revenue_rel_tolerance=0.002) and Tolerances(revenue_abs_tolerance=0.05) each raise ReconciliationInputError. - test_tightening_is_legal_and_bites (line 136) — Tolerances(revenue_rel_tolerance=0.0, revenue_abs_tolerance=0.0) succeeds and measurably tightens behavior (trailing_clean_days == 0). - test_ceilings_are_source_literals (line 142) — ast.parse-pins MAX_REVENUE_REL_TOLERANCE=0.001 and MAX_REVENUE_ABS_TOLERANCE=0.01 as literals (source-literal assertion, not a runtime check).

C3 E[NCM]-only, raw revenue inexpressible — test-asserted, confirmed. services/measurement-rails/test_ncm_feed_wiring.py: - test_meta_events_carry_margin_never_raw_revenue (line 289) - test_google_adjustments_carry_margin_never_raw_revenue (line 312)

self.assertEqual(first["custom_data"], {"currency": "USD", "value": EXPECTED_MARGIN})
dumped = json.dumps(built)
self.assertIn("84.75", dumped)
self.assertNotIn("250.0", dumped)   # raw net revenue absent
self.assertNotIn("230.0", dumped)   # contribution sum absent too

C4 shopify_install.py B0–B6 — confirmed present, defined in docs/architecture/SHOPIFY_OAUTH_INSTALL_DESIGN.md:380-389, referenced by test_shopify_install.py (SHA d2965c1b69d99522ab54c8fe899c5e6da3a279f7): - B0 = shop registry + schema-2 token custody - B1 = OAuth install/callback routes (flag-gated) - B2 = webhook tenant resolution + DEFAULT_TENANT_ID shim - B3 = sync per-tenant credentials + resolve_tenant - B4 = app/uninstalled + GDPR compliance jobs - B5 = Web Pixel activation at install completion - B6 = doc corrections riding with B2

Sequencing note in the design doc: "B0→B1→B2→B3→B4 strictly ordered; B5 after B2; B6 with B2."

C5 fulfillments mapping — G1 (HIGH, consent-gate leak of ship-to) fix confirmed live in code. webhook_hardening.py:212-219:

_PERSON_KEY_JOINED = {
    ...
    # Shopify person-address CONTAINERS whose subkeys evade the token walk
    # (`name` = full name, `address1`, lat/long): `destination` is the
    # fulfillment / fulfillment-order ship-to block, `addresses` the customer
    # address book — dropped subtree-and-all exactly like shipping_address
    # (C5 review G1, docs/reports/FULFILLMENTS_MAPPING_REVIEW_2026-08-12.md).
}

G2 (order linkage) was fixed separately and later, via PR #664 (Item 3, below) — broader than the review doc's original one-line proposal.

B5 activate_web_pixel + INTENT_TENANT_MAP — confirmed installed-rows-only, allowlist-gated, idempotent, fail-closed. shopify_install.py:692 (doc comment): "installed rows only (§8 row B5): activation cannot precede §2.2" — gated on status=installed, consent settings honored, no activation before §2.2 step-5 completion. services/intent-shopify-extender/main.py:423-431 — INTENT_TENANT_MAP fail-closed:

if TENANT_MAP_INVALID:
    _count("tenant_map_invalid")
    raise HTTPException(status_code=503,
        detail={"reason": "tenant_map_invalid",
                "detail": "INTENT_TENANT_MAP is set but is not a JSON object of shop_domain→tenant_id strings"})

Docstring: "Set-but-unparseable is a MISCONFIGURATION, not a fallback: ... the webhook surface fails closed (503)."

Item 2 — Flag-off asserts + test suite counts vs. R3 baselines

MOSTLY VERIFIED — one gap found: not every activation surface has a source-literal test.

Caveat on the test runs below (rule 01): run with the pre-existing system python3 (3.14.6) / pytest 9.1.1 already on PATH. No fresh virtualenv was built for this check, despite the repo having venv//venv_314/ available. Per .claude/rules/01-verification-discipline.md ("build fresh environments — a reused venv is how a suite lies"), treat the pass/fail counts below as probably accurate but not fully rigorous — a clean re-run in a fresh venv is recommended before treating this as the final gate for W1–W6.

SHOPIFY_OAUTH_ENABLED=False — exactly 2 AST-assertion locations, confirmed. Defined at services/service-marketing-connectors/shopify_install.py:44 as a bare False literal.

• Location 1 — services/service-marketing-connectors/test_shopify_install.py:105-120 (FlagLiteralTests.test_default_off_as_source_literal): python src = MODULE_PATH.read_text() tree = ast.parse(src) literals = [ node.value.value for node in ast.walk(tree) if isinstance(node, ast.Assign) for t in node.targets if isinstance(t, ast.Name) and t.id == "SHOPIFY_OAUTH_ENABLED" and isinstance(node.value, ast.Constant) ] self.assertEqual(literals, [False]) self.assertFalse(si.SHOPIFY_OAUTH_ENABLED)
• Location 2 — tests/connectors/test_shopify_oauth_gateway.py:246-262 (TestFlagGate.test_flag_default_is_off_source_literal) — the same AST walk, run against the gateway's own read of the module, with an explicit comment that it deliberately duplicates location 1 to pin what the gateway sees, not just what the module declares.

Activation-surface flag inventory — GAP FOUND.

Webhook processing itself (/shopify/webhook, /pubsub/shopify-webhooks) is correctly not flag-gated — it's protected by HMAC/OIDC caller auth per .claude/rules/marketing-commerce-connectors.md, so it isn't a counterexample to the claim, just outside this category by design.

FINDING (FIXED): PIXEL_EVENTS_ENABLED in the intent-shopify-extender lacked a source-literal test. Added PixelEventsFlagLiteralTests.test_off_default_is_a_source_literal to services/intent-shopify-extender/test_pixel_events.py, AST-parsing the module's own os.environ.get("PIXEL_EVENTS_ENABLED", ...) call and asserting the default argument is the empty-string literal — mirroring shopify_install.py's AST pattern rather than test_pixel_collect.py's regex one, since the assignment here is a boolean membership expression, not a bare constant. Verified the test both passes on current source (11/11 green, python3 -m pytest services/intent-shopify-extender/test_pixel_events.py -v) and fails when the literal is flipped (sanity-checked by patching the source in-memory and re-running the AST walk before committing the test). Every activation surface now has an OFF-default test pinned at the source literal.

Test suite counts vs. R3 baselines (rails 396; gateway+connectors 220; extender 20) — all suites GREEN, all at or above baseline; baselines are stale/superseded by lane growth, not violated.

• rails (services/measurement-rails/): python3 -m pytest services/measurement-rails -q → 397 passed, 2 warnings, 7 subtests (baseline 396; +1, zero failures).
• gateway+connectors (tests/connectors/ + services/service-marketing-connectors/): python3 -m pytest tests/connectors -q → 340 passed; python3 -m pytest services/service-marketing-connectors -q → 159 passed. Combined 499 passed vs. the R3-era baseline of 220 — substantially larger, consistent with lane growth since 2026-08-12 (B6 OAuth flow, Cell 37 wiring, pixel/collect, tenant-onboarding-intake tests all postdate R3). Zero failures in either half.
• extender (services/intent-shopify-extender/): python3 -m pytest services/intent-shopify-extender -q → 40 passed, 2 warnings (baseline 20; roughly doubled, driven by test_pixel_events.py added after R3).

Conclusion: zero test failures across all three suites; every count meets-or-exceeds its R3 baseline. Treat "396/220/20" as a floor the lane has grown past, not a target it currently matches — restating those exact numbers as "current" in future reports would itself be a stale-baseline defect per rule 01.

Item 3 — PR #664 (fulfillments backfill/webhook join parity) reconciled on main

VERIFIED — merged and present on main.

gh pr view 664: title "fix(connectors): C5a fulfillments backfill could never join its webhook twin", state MERGED, merged 2026-08-12T14:38:20Z, base main, +98/-7. Merge commit 312d81aac52836220b33d639c5a7732224785f88 is present on current main (git log --all --grep="664" also surfaces fe065491 mem: PR 664 merged (Shopify backfill/webhook join parity); zero open PRs).

Content check: Admin GraphQL gids vs. webhook numeric IDs mismatched, so the backfill sync path and the live webhook path for the same fulfillment never shared an identifier. Fix selects legacyResourceId on both fulfillment and order and emits both ID forms. This corresponds to — and is broader than — the review doc's G2 gap (missing order linkage in entity_ids); PR #664 fixes join-parity between backfill and webhook generally, landing after the review doc's 2026-08-12 timestamp as a follow-on.

Item 4 — Operator remainder still outstanding (nothing in code substitutes)

Correction (2026-09-30): items a and b below describe the CODE posture, which is unchanged — but the live secrets were already in place when this was written: shopify-app-client-secret (5 versions) and shopify-webhook-secret (2 versions) populated and mounted per SHOPIFY_SECRETS_STATUS_2026-08-25.md, OAuth armed 2026-08-21 (PR #768), app creation CLOSED (docs/OPEN_ITEMS.md S-4). The operator remainder is the first real store install; the shared-secret verifier in (b) is defect D1 of the 2026-09-30 lane plan, fixed by PR #1275.

VERIFIED — all four items remain genuinely operator-only; no code substitute exists; fail-closed/defer-loudly behavior confirmed live in current code.

a. Shopify app creation (client_id/secret). No real credential in code or terraform. deployment/terraform/shopify_app_secrets/variables.tf:29-32 — variable "shopify_client_id" { default = "" }; main.tf:104 only creates the secret version count = var.shopify_client_id != "" ? 1 : 0. Runtime: shopify_install.py:548-553 reads SHOPIFY_APP_CLIENT_ID/ SHOPIFY_APP_CLIENT_SECRET from env with no fallback; shopify_install.py:807 raises TokenRefreshError("oauth_client_unconfigured") when absent. (SHA 016ed9d, 3d3b332)

b. SHOPIFY_WEBHOOK_SECRET / provider creds — fail-closed, confirmed. services/service-marketing-connectors/main.py:551-553:

def _verify_shopify_hmac(raw_body, presented_hmac):
    if not SHOPIFY_WEBHOOK_SECRET or not presented_hmac:
        return False

Callers raise HTTPException(401, "invalid Shopify webhook HMAC") at lines 1392-1393 and 1688-1689. Unchanged in nature since 2026-08-12. (SHA aeb1538)

c. Pixel extension artifact / extender URL — still unset by default, defers loudly. Naming changed since the 08-12 report; posture identical. The env var was renamed SHOPIFY_PIXEL_COLLECT_URL (gateway collector edge); SHOPIFY_PIXEL_EXTENDER_URL is now legacy/plan-vintage naming per docs/reports/ORACLE_PRECONV_STEP0_2026-08-18.md:77. main.py:944-966:

collect = os.environ.get("SHOPIFY_PIXEL_COLLECT_URL", "").strip().rstrip("/")
if not collect:
    ...
    logger.warning("pixel activation deferred for %s: SHOPIFY_PIXEL_COLLECT_URL unset (browser collector edge not wired for OAuth installs yet)", shop_domain)
    return {"status": "deferred", "reason": "pixel_collect_url_unset"}

Plus an equivalent deferral for SHOPIFY_PIXEL_INGEST_SECRET unset (lines 967-975). (SHA aeb1538)

d. Reconciliation runner credentials — still stubbed/blocked. ops/reconciliation/run_reconciliation.py:3-6: claim_label: implemented — INERT today. No merchant credentials exist yet (open-work register item 6), so every real invocation refuses loudly at the credential/config gates below. Zero Pub/Sub subscribers on mizoki-events; no baked default BigQuery table (--events-table/RECONCILIATION_EVENTS_TABLE required, operator-supplied). (SHA 760c805)

Correction to the master-prompt's item framing: the prompt lists "app creation (direct/unlisted)" as item 1 of the operator remainder; this matches decision 1 in Item 6 below (direct/unlisted P1–P3, App Store at P4) — no conflict, just confirming the two prompts reference the same decision.

Item 5 — service-canonical-ingestion subject/erasure path

VERIFIED — the path exists, matching CLAUDE.md's "item 27 closed" claim.

Service dir: services/service-canonical-ingestion/ (main.py, projector_kg.py).

• Route: main.py:269-270 — @app.post("/api/v1/subjects/erase") / async def subjects_erase(req: SubjectEraseRequest, caller=Depends(verify_caller)): — redacts over events/events_outbox/events_dlq with a count→redact→recount receipt; returns 200 only if every recount confirms zero unredacted matches remain.
• BigQuery leg: main.py:290-308 — bq_table = _bigquery_erasure_table(); body["bigquery_leg_configured"] = bool(bq_table). Unset env → leg not run (disclosed in the response, not silently skipped); client/query failure → "status": "failed" merged into the receipt (fails closed, not silently).
• Salt mechanism: contracts/mizoki_contracts/erasure.py:64 — def default_salt_in_force():, surfaced via main.py:156 as "default_subject_salt_in_force": default_salt_in_force().
• Gateway canonical_eraser leg / CANONICAL_ERASER_URL: services/service-marketing-connectors/main.py:68 — CANONICAL_ERASER_URL = os.environ.get("CANONICAL_ERASER_URL", "").rstrip("/"); fail-closed at main.py:1568-1569: python if not CANONICAL_ERASER_URL: raise shopify_install.ComplianceLegFailed("canonical_eraser_unconfigured") Confirmed unset-in-prod matches the code (empty default, no fallback). Wired into /api/v1/shopify/compliance/run as leg 3 — "unset env fails the leg loudly."

SHAs: service-canonical-ingestion/main.py = 9afc286e65d416bf8a67f3446c9e43bed96c7a51; contracts/mizoki_contracts/erasure.py = b4191799da4304e7ee5ef3e573571b3234ed692a; service-marketing-connectors/main.py = aeb15387ad3fdcd140a6cd9a09946cc6ae0c2463; shopify_install.py = 3d3b332dd08e39b7c139d56415609b25052f5491.

Conclusion: no operator-only item has been silently substituted with code, and every fail-closed/defer-loudly behavior named in prior reports is present and matches on current main.

Item 6 — Open owner decisions (3, 9, 12, 13, 14, 15, 17, Article VI 36→37 patch)

VERIFIED — 7 of 8 remain genuinely OPEN; the Article VI item is RESOLVED but superseded (stale framing by 2026-08-27).

Searches run against CLAUDE.md, docs/reports/, docs/roadmap/, docs/product/, .claude/memory/active/, CONSTITUTION.md, docs/architecture/ for each decision's topic/number, cross-checked with git log/git show.

• 3 — Profit Truth Audit wedge go/no-go: OPEN. No resolution found anywhere. docs/roadmap/P1_BUILD_PLAN.md:147: "3 (Profit Truth Audit wedge go/no-go) stays open" — unchanged since 2026-08-12.
• 9 — citation sign-off: OPEN, closable-but-unclosed. docs/reports/CITATION_CHECK_2026-08-11.md confirmed 5/5 PASS — no canon corrections required; the report itself states decision 9 "can be closed for these five items on the strength of this report." That is the report's own framing, not an owner ruling. No later record shows the owner actually closing decision 9 — it remains formally open, merely unblocked.
• 12 — blueprint phase-name confirmation: OPEN. docs/roadmap/SIGNAL_SHOPIFY_PHASE_BINDING.md:25-34 (last touched 2026-08-16 by an unrelated cell34 commit, not this section): "the L5 Autonomous Media Architecture blueprint document itself was not located... The [Assumed — verify] flag therefore stands... owner to drop the blueprint on the board or confirm the five names, closing decision 12." No evidence the blueprint ever landed.
• 13 — 30-day plan wholesale vs. triaged: OPEN. Same file, line 42: "Owner decision 13 ... stays open." No later commit touches this.
• 14 — EU data-residency mechanism: OPEN. docs/architecture/FLEET_INTEGRITY.md:55-67 (last modified 2026-08-11): "The choice is owner decision 14 with counsel; engineering does not pre-empt it. No EU [merchant onboarded]..." docs/architecture/SHOPIFY_OAUTH_INSTALL_DESIGN.md:422 reaffirms: "decision 14 lands. No EU merchant is onboarded before that determination." No resolution found.
• 15 — holdout-share covenant floor by tier: OPEN. No resolving text found. docs/product/SIGNAL_SHOPIFY_MASTER_v4.md:158 still frames it as future design: "holdout share made a floor-bounded covenant parameter (decision 15)" — describes the mechanism, not a decided floor value.
• 17 — Stage 1–4 benchmarks (contractual SLA vs. internal target): OPEN. docs/roadmap/SIGNAL_SHOPIFY_PHASE_BINDING.md:84-86: "contractual SLAs or internal targets. Until decided, every stage benchmark above is an internal target and must not appear in merchant-facing contract language." Note: commit e223dda7 (2026-08-16) separately reused the numeral "17" for an unrelated fleet-register item (LII backtest AUC) — a different "17"; do not conflate the two.
• Constitution Article VI 36→37 cell patch: RESOLVED, then superseded — stale framing, not a pending amendment. CONSTITUTION.md:96-113 (Article VI procedural text is unchanged, carries no cell numbers itself). The count patch landed in two steps: commit 7aa504c0 (2026-08-13, "resolve the three parked decisions") applied 36→37, citing "owner ruling 2026-08-11"; commit 65b59906 (2026-08-16, "gov(article-vi): register cells 38-39 CRE Prospecting — 37→39, owner ruling 2026-08-16") then patched the preamble again to version 2.1.0. Current CONSTITUTION.md:13: "...39 registered cells total; docs/architecture/CELL_REGISTRY.md is the number authority, owner rulings 2026-08-11/2026-08-16..." docs/architecture/CELL_REGISTRY.md:5-6 confirms 39 registered cells and lists a standing correction: "'32-cell platform' is stale → 39 registered cells." This matches CLAUDE.md's current "39 registered cells" line. The R3-era "36→37" framing in the master prompt is stale by 2026-08-27 — the patch is fully applied at 39, not pending or stalled at 37.

Summary: 7 of 8 items (3, 9, 12, 13, 14, 15, 17) remain genuinely open with zero owner resolution in any post-08-12 record. (Superseded 2026-09-15: 3, 9, 12, 13, 15 and 17 are CLOSED by owner ruling — docs/OPEN_ITEMS.md §A, OWNER_RULINGS_2026-09-15_REGISTER_CLOSEOUT.md; 14 (EU residency) stays OPEN under counsel. Noted here 2026-09-30.) Decision 9 is unblocked (evidence exists) but not closed. Only the Article VI cell-count item is resolved — via two chained amendments — and is no longer a live open item at all; the "36→37" framing should be retired.

Item 7 — Ghost bids PROPOSED; writeback flags OFF with fail-if-flipped tests

CORRECTION (post-fix note, 2026-08-27): this section originally claimed "PROPOSED" was "a label that does not exist in this platform's claim vocabulary." That was imprecise — it conflated two distinct axes that this repo's own .claude/rules/03-canonical-architecture.md deliberately keeps separate: performance figures carry the closed TRUTH.md 5-label set (verified/benchmark/pilot/design target/illustrative), while capability statements carry a different axis, LIVE/PARTIAL/PROPOSED/RESEARCH (with DARK appended when built-but-flag-off). "PROPOSED" is a legitimate capability-axis label — the actual defect was narrower and has now been fixed: see below.

FIXED: docs/product/FEATURE_COVERAGE_MATRIX_v1.md rows 2.7 and G-03 described ghost bids as "design only, not shipped, not built" under status PROPOSED. That was stale — services/measurement-rails/ghost_bid.py is a real, complete module (shadow execution + auction logger), just shipped with its MEASUREMENT_RAIL_GHOST_BID flag off. Per rule 01 ("fix the claim and the row that authorizes it in the same commit"), both rows were corrected to PARTIAL (DARK) — matching this doc's own status-vocabulary convention (line 6/225: DARK is appended to a base status when a capability is built but flag-off by design) — with the artifact column now naming the actual code module, and the gap text corrected to "built shadow-only ... no live run against real ad spend yet." G-03's class also moved from build to operator, since the only remaining gap is the live run (GB-1), not further code.

The actual, current, correct claim label for ghost bids — services/measurement-rails/ghost_bid.py:3:

"""Ghost-bid shadow execution + auction logger — BUILD_DEBT GB-1.

claim_label: built, pre-benchmark.

— matches the platform status ceiling (src/shared/miz_oki_source_of_truth.py:370, PLATFORM_CLAIMS.status_label = "built, pre-benchmark").

Flag ships off, confirmed. services/measurement-rails/flags.py:45-49:

# GB-1. Ghost-bid execution is shadow-only by construction ...
"ghost_bid": "MEASUREMENT_RAIL_GHOST_BID"

comment: "Off, like every other rail."

Remaining work, per CLAUDE.md and COMPLIANCE_REPORT.md:456-457: "GB-1 ... live runs" against real ad spend is still outstanding — the code is BUILT (shadow-only, flag off) but not yet benchmarked against live spend. This matches CLAUDE.md register item 3 (GB-1, operator-only).

Corrected verdict to carry forward: ghost bids are "built, pre-benchmark; MEASUREMENT_RAIL_GHOST_BID flag off; GB-1 live run still owner-pending" — not "PROPOSED." Future prompts/reports referencing this lane should drop the "PROPOSED" label.

MEASUREMENT_WRITEBACK / NET_YIELD_WRITEBACK — VERIFIED hard-false at the source literal, with green fail-if-flipped tests.

Source literals: - services/measurement-rails/flags.py:31,35,83 — WRITEBACK_DEFAULT = False; MEASUREMENT_WRITEBACK_ENV = "MEASUREMENT_WRITEBACK"; return _env_bool(MEASUREMENT_WRITEBACK_ENV, WRITEBACK_DEFAULT). - services/net-yield/writeback/__init__.py:16,24 — NET_YIELD_WRITEBACK_ENV = "NET_YIELD_WRITEBACK"; return os.environ.get(NET_YIELD_WRITEBACK_ENV, "false").strip().lower() == "true".

Fail-if-flipped tests (source-literal + AST): - services/measurement-rails/test_flags.py:46-55 (TestDefaults.test_literal_defaults_pinned_in_code): python self.assertIs(flags.WRITEBACK_DEFAULT, False) source = inspect.getsource(flags) self.assertIn("WRITEBACK_DEFAULT = False", source) - services/net-yield/test_flags.py:35-40 (TestLiteralDefaultPinnedInCode.test_literal_default_pinned_in_code), plus an AST-level test_ast_default_argument_is_the_string_false that parses the os.environ.get(...) call and asserts the literal "false" constant.

Executed (same reused-interpreter caveat as Item 2 — no fresh venv):

python3 -m pytest services/measurement-rails/test_flags.py -k test_literal_defaults_pinned_in_code -v
  ...test_literal_defaults_pinned_in_code PASSED

python3 -m pytest services/net-yield/test_flags.py::TestLiteralDefaultPinnedInCode -v
  test_ast_default_argument_is_the_string_false PASSED
  test_dry_run_default_literal_pinned_in_both_senders PASSED
  test_literal_default_pinned_in_code PASSED

python3 -m pytest services/measurement-rails/test_flags.py -q   → 20 passed
python3 -m pytest services/net-yield/test_flags.py -q           → 13 passed

Note: the two test_flags.py files collide as pytest modules if collected together (neither directory has __init__.py), so each was run in its own process — a pytest collection quirk, not a test failure.

Verdict: both writeback flags are hard-false at the source literal, and every fail-if-flipped test is green, exactly as claimed.

Item 8 — Banned-content grep sweep across docs/

CLEAN — zero real violations found across all six categories. One unrelated, low-severity staleness noted for follow-up (not a violation of any tested pattern).

1. Airbnb KL figures (0.66 / 4.95 / 12.03) as MIZ OKI results — CLEAN. Tight grep (Airbnb/KL context): 8 hits, all legal — ban-notice/supersession tables (docs/product/history/SIGNAL_SHOPIFY_PRODUCT_DEFINITION_v2.1.md:48,181) and audit reports explicitly attributing the figures to Airbnb and confirming zero live occurrences (docs/completion-run/PHASE_V_VERIFIER_REPORT_2.md:39, A3_cross_reference_audit.md:60, A2_platform_machinery_audit.md:44, A1_site_content_audit.md:37; governance "KEEP banned" ruling text in docs/prompts/CLAUDE_CODE_MASTER_PROMPT_GROWTH_CONTROL_COMPLETION_v1.1.md:43 and ..._ACTIVATION_v2.1.md:269). Loose numeric checks for 0.66/4.95 surfaced only unrelated false positives (CSS alpha values, AUC/model stats, run IDs, hash fragments); 12.03 has zero hits repo-wide.

2. "Quokka Swarm" (any casing) — CLEAN. 16 hits, all legal: ban-list/canon rule definitions (MIZOKI_3.5_WHITEPAPER.md:214 + r3.5.1 twin, CLAUDE_CODE_COMPLIANCE_ALIGN_v1.0.md), audit reports confirming zero hits on served pages, or removal-record ledger entries documenting it was struck from earlier drafts (SIGNAL_SHOPIFY_MASTER_v4.md:130, SIGNAL_SHOPIFY_PRODUCT_DEFINITION_v2.1.md:49). No file presents it as an actual MIZ OKI method.

3. Audio/keystroke/gaze signals as collected/predicted — CLEAN. ~55 hits across ~35 files, all legal deny-list framing: permanently prohibited / schema-rejected under owner ruling O-1, with a named rejection tag DISALLOWED_KEYSTROKE_DYNAMICS, tested both directions (e.g. MIZOKI_3.5_WHITEPAPER.md:178-179, ORACLE_PRECONVERSION_INTENT_v1.1.md:38,55,173, INTENT_API_PLATFORM_BLUEPRINT.md:266, FEATURE_COVERAGE_MATRIX_v1.md:17, shopify-app-listing-copy.md:71,80, MIZOKI_SIGNAL_GROWTH_CONTROL_UNIFIED_SYSTEM_r2.0.md:77). None describe these as things the platform actually collects.

4. Mind-reading framing — CLEAN. ~35 hits across ~25 files, all explicit denials: canon language is uniformly "anticipatory intent with proof of causal lift — never 'mind-reading'" (OFFERING_MAP.md:37,416,547; ORACLE_PRECONVERSION_INTENT_v1.0/v1.1.md; whitepapers/MIZ_OKI_3.5_...Whitepaper.md:160,383; LII_ANTICIPATORY_INTENT_PLAN_v1.md:19,55,138). Site-content audits (V_verifier_report.md:16, A3_cross_reference_audit.md:126, PHASE_V_VERIFIER_REPORT_2.md:36) confirm the only live-site occurrences are negations. shopify-app-listing-copy.md:137 lists "AI reads your customers' minds" in a prohibited-phrase deny-list, not as a claim.

5. "32-cell" (stale cell count) — CLEAN (historical or self-corrected). ~90 hits, concentrated in docs/legacy/, docs/archive/, and older superseded verification reports. Current governance docs explicitly flag and correct it: OFFERING_MAP.md:45,88 ("32-cell fleet ... 39 registered cells"), docs/architecture/CELL_REGISTRY.md:125 ("'32-cell platform' is stale → 39 registered cells — this file is the number authority"), SIGNAL_OVERVIEW_v5.md:55,125, reports/CLOSE_OUT_RUN_2026-08-18.md:136-142, WHITEPAPER_TRUTH_RECONCILIATION_2026-08-13.md:24, STATE_RESUME_2026-08-20.md:102. No document asserts 32-cell as current live fact without a correction nearby. (Consistent with Item 6's finding that current cell count is 39, per CONSTITUTION.md and CELL_REGISTRY.md.)

6. Neo4j for Cell 35 — CLEAN, with one unrelated staleness flagged for follow-up. Tight Cell-35+Neo4j check: zero real violations — every hit states Cell 35 is Firestore-backed and Neo4j was retired by owner decision 2026-08-09 (MIZOKI_3.5_WHITEPAPER.md:12; INTENT_API_PLATFORM_BLUEPRINT.md:9-16,68,463,544; OFFERING_MAP.md:112; lii/ADR-LII-001.md:8-9,70; lii/RUNBOOK.md extensively; SIGNAL_SHOPIFY_MASTER_v4.md:6,41,71; ORACLE_PRECONVERSION_INTENT_v1.1.md:24,49,134,147). Broad Neo4j sweep (~90 files) spot-checked as legitimate substrate/retirement/corrected-canon references. Follow-up (not a violation of the tested pattern): docs/prompts/CLAUDE_CODE_COMPLIANCE_ALIGN_v1.0.md:33 (dated 2026-08-11, after the 2026-08-09 retirement ruling) still lists "Neo4j" plainly in a "Canonical stack" line with no retirement caveat and no Cell 35 mention — stale, but it names the general stack, not the specific banned "Neo4j-for-Cell-35" claim this sweep tests for.

Overall: zero real violations found in docs/ across all six banned-content categories.

Bottom line

• Items 1, 3, 4, 5, 8: verify clean against ground truth. Nothing in code substitutes for an operator-only step; every fail-closed/defer-loudly path named in prior reports is present and matches on current main; PR #664 is merged and reconciled; the canonical erasure path exists as claimed; the banned-content sweep is clean.
• Item 2 — FIXED: PIXEL_EVENTS_ENABLED (intent-shopify-extender) now has a source-literal test (test_pixel_events.py::PixelEventsFlagLiteralTests), matching its two sibling flags. Every activation surface has an OFF-default test-asserted at the source literal, as originally claimed. Test suites remain green and at-or-above R3 baselines, but were run without a fresh venv (caveat per rule 01) — re-run in a fresh venv before citing exact pass counts in a gating context.
• Item 6: 7 of 8 named owner decisions (3, 9, 12, 13, 14, 15, 17) are still open 15 days after the R3 report, with zero owner resolution in any later record — decision 9 is unblocked (5/5 citation PASS) but not formally closed. The Article VI cell-count item is resolved and superseded (39 cells, not 37) — the "36→37" framing is stale and should be retired from future prompts. Not code-fixable; needs an explicit owner ruling.
• Item 7 — FIXED: writeback flags verify hard-false with green fail-if-flipped tests (unchanged). The actual defect this item surfaced — docs/product/FEATURE_COVERAGE_MATRIX_v1.md describing the built ghost_bid.py module as "design only, not shipped" under status PROPOSED — is corrected to PARTIAL (DARK) with an accurate artifact reference and gap description. See Item 7's section for the correction to this report's own original (imprecise) framing of the finding.
• Remaining, not addressed in this pass: decisions 3/9/12/13/14/15/17 need an explicit owner ruling — this is outside agent scope (.claude/rules/00-memory-governance.md decision-rights boundary) and cannot be "fixed" by a commit.