`verification/REVIEW.md`

48 lines

> Deployment update (September 9, 2026): Steve approved the rollout; all three production repositories now contain the verified fixes. The live canary passed. See [executed outcome](rollout/RESULT.md). The historical pre-approval review below is retained for provenance.

# TK-11314 — DW activation repair review

The code fixes are verified in isolated branches. They are **not deployed**. No product was activated or edited, no canonical database was changed, and no Gemini generation call or billing change was made.

## Verified findings and changes

- The 08:25–08:31 PDT run examined 1,860 drafts: 1,591 failed product checks and 269 passed product checks but encountered image-review HTTP 429.
- A fresh read of all 1,860 products confirms 45 false width flags and 251 false legal-description flags. The width adapter now recognizes explicit `dwc.width` / `specs.width` fields and the Carnegie-specific namespace only for Carnegie. Package dimensions and descriptions cannot supply inferred widths.
- The description validator narrowly exempts the exact material claim “without Prop 65 Phthalates”; actual disclaimers, empty/placeholder copy, missing images, missing samples, missing widths and internal-product guards remain enforced.
- Twelve products have more than 20 variants and four have more than 80 metafields. The runtime now reads remaining pages before checking them. Failed or looping pagination leaves the product unverified.
- The image client retains sanitized error details and retry information, uses header authentication, bounds request time, and opens a fail-closed cooldown after configured keys receive 429. An unavailable image service returns HELD. It does not establish that the design is prohibited, and it never permits activation.
- Shopify must explicitly return ACTIVE for the requested product before the activation count/ledger increases. HTTP errors and incomplete GraphQL replies cannot count as successful activations.
- Each run produces `out/current-readiness-repairs.json`, with one record per product/repair type, timestamps, source, reasons and `apply_authorized:false`. This is a review report, **not an automatic catalog updater**.
- The old variant repair worker keyed completion by SKU alone. Completion is now keyed by Shopify product ID and repair type. The 20,034-row snapshot has 17,445 matching completed results and 2,589 unmatched entries. **All 2,589 have blank DW SKUs**; they are identity problems, not publish-ready products. Forty-one overlap the current activation cohort, and none of those 41 currently lack a sample. The existing no-resolvable-SKU guard stays intact.

The canonical/price/sample replay improves from 343 to 637 passing products. These are **not activation predictions**: manufacturer provenance, private-label, showroom/internal, reintroduction, settlement, publication and live-state checks still apply. The 43 Carnegie products whose widths were corrected still have the separately observed manufacturer-placeholder block.

## Verification

- 34 activation tests, four canonical validator tests, seven repair-progress/executor tests: **45 passed**.
- All 1,860 products fetched using read-only Shopify queries, with no missing or truncated snapshots.
- Exact patched runtime batch query + real pagination verified against 50 live DRAFT products: 17 requests, 12 variant pagination cases and four metafield pagination cases; maximum requested query cost 27. Real Designtex/Carnegie fixtures pass the corrected checks; incomplete Fischbacher remains blocked.
- Repair progress reconciled against the actual database worklist and persisted audit. Dry executor-flow tests leave the audit unchanged and never request a live budget.
- Reintroduction, duplicate/age and never-activate vendor guard script passed unchanged.
- Source rollback was rehearsed on isolated temporary copies of all runtime files: reverse patches restored the exact base bytes, and forward patches restored the reviewed bytes. Production was untouched. See `rollback-rehearsal.json`.
- DTD: Codex CLI and Qwen selected A (2/2 valid votes; 2/6 available), mandatory adversarial review KEEP. Claude disabled by zero-cost policy; Grok/Kimi/Muse unavailable. This technical decision does not authorize publishing.

Evidence: `e2e-proof.json`, `live-boundary.json`, `readiness-replay.json`; retained untracked snapshots `live-products-20260909.json` and `readiness-repairs-20260909.json`. Repair-worker evidence is in `~/Projects/dw-repair-debug-TK11314/verification/e2e-proof.json`.

## Image service remains unresolved

The configured primary key successfully reads Gemini 2.5 Flash model metadata (HTTP 200). Its project lookup returns HTTP 403 with both saved working Google logins. The saved `info@designerwallcoverings.com` gcloud login needs reauthentication. The optional `GEMINI_API_KEY_WALLCO` fallback is absent from the master environment. No key was copied, rotated, or restored.

Old activation logs discarded the error body, so the exact generation limit cannot be established from those logs. The new diagnostics will distinguish quota metrics and retry delays when a permitted generation request runs. A model-metadata read does not prove generation is available. Google documents 429 handling and retry guidance in its [Gemini troubleshooting guide](https://ai.google.dev/gemini-api/docs/troubleshooting).

## Proposed production rollout — approval required

1. Verify original source files have not drifted from the base versions; preserve unrelated runtime data, dirty submodules and concurrent changes.
2. Acquire the existing rotation and field-repair `.drain.lock` locks only when the real workers are idle. Do not clear another worker's lock or alter any launchd schedule.
3. Save exact before-file snapshots and apply only the reviewed runtime/test changes from the three branches. Deploy the canonical validator and dependent activation modules as one coordinated release.
4. Re-run syntax, regression and reintroduction guards against the installed files; confirm the observed candidates remain DRAFT until the explicitly approved canary.
5. Run a one-product canary only with publish approval and successful existing settlement checks. Verify Shopify ACTIVE, intended channel publication, exclusions and ledger delta against independent live reads. A provider error remains HELD. No source values may be invented to force a pass.
6. Release the locks to the existing 21-per-hour / 500-per-day activation schedule after the canary passes. Monitor activation, hold and repair reports. Existing pricing, sample, manufacturer, internal/showroom, private-label and settlement requirements remain in force.

Rollback: retain the locks, restore only the saved source files, run syntax/guard checks, and release the locks. Restoring source does **not** undo an already published product; any canary product rollback requires its separately recorded before-state and explicit authorization. No force reset, broad checkout, database restoration, credential change or billing increase is part of this rollout.