Change control — Friday 21 August

The largest change in this release takes 407,302 part pages that carry nothing — no price, no photo, no catalogue data — and makes them answer not-found instead of rendering an empty page. That is the intent and it is worth doing. But the rule has two lists in it, and only one of them checks whether the page has anything on it. 7,803 pages that do have something — 4,828 of them a real price, $3,888,976.50 of list value between them — are withdrawn as well.

This was found on Thursday by opening one of them: a New Holland Construction part that production serves today at $42.42 / each, with a fitment list, eight diagram links and a “Contact our parts desk” button. On the candidate the same address answers not-found.

What is true on the other side of it None of the 407,302 has taken an order in twenty-four months. None is offered to Google. None is findable in the store's own search. And the parts diagram already stops linking to them, so the promote creates no dead link and no broken buy path inside the store. What a customer loses is a page with a price and a phone number on it, not a way to buy anything.

The choice Ship it as it stands and accept that 4,828 priced pages stop existing — or move one word between two lists before Friday, which keeps 98.1% of the result and leaves those 7,803 pages rendering. The change was named in the pull request itself as the trade-off worth a second look; it has simply never been decided out loud.

One thing this does not answer: nobody has measured how many people actually open those 4,828 pages. That needs the search-console pull, and the cloud login for it had expired on Thursday — a missing measurement, not a zero.

Production today — a person sees thisThe candidate

I could not read a single Cloud Run revision name, traffic split, env var, or service-level scaling value this session. The token is expired; per the standing rule an expired token is a false negative, never evidence of absence. What that leaves missing from the rollback surface: the currently-serving search-api revision name (the actual --to-revisions rollback target), whether latestReady == latestCreated on search-api today, whether any stale traffic tag is parked (billable, and it has happened twice), search-api's env vars (the image swap preserves env, so a var the new image requires and prod lacks = crash-loop), and every parts-services service's deployed image tag. Two facts I do have, from ops/docs/evidence/2026-08-20-search-promote-before.json captured at 07:35:01Z today while gcloud still worked: prod search-api runs image search-nest:2da1a51e3d98ffc37b4656a0f00bd6c44930cdab with scalingMode MANUAL / manualInstanceCount 2; search-api-dev runs crop-search:b92268a1a3551b8c7485ce9cf88995edce7231ed with maxInstanceCount 2. That is an image tag, not a revision name — a revision name cannot be derived from it.

What to doVova, after gcloud auth login, run exactly these and paste the output onto the change-control page: (1) gcloud run services describe search-api --region=us-east1 --format='value(status.latestReadyRevisionName,status.latestCreatedRevisionName)' (2) gcloud run services describe search-api --region=us-east1 --flatten='status.traffic[]' --format='csv[no-heading](status.traffic.revisionName,status.traffic.percent,status.traffic.tag)' — this names the rollback revision AND exposes any stale tag (3) gcloud run revisions list --service=search-api --region=us-east1 --format='table(name,active,creationTimestamp,spec.containers[0].image)' (4) gcloud run services describe search-api --region=us-east1 --format='yaml(spec.template.spec.containers[0].env)' — confirm IS_PUBLISHABLE_FILTER_ENABLED and every var the new config module requires (5) curl -s -H "Authorization: Bearer $(gcloud auth print-access-token)" https://run.googleapis.com/v2/projects/noted-bliss-466410-q6/locations/us-east1/services/search-api — the v2 REST call, because describe reports spec.scaling as null and HIDES the service-level instance cap (this is why ops/scripts/search-promote-check.ts uses REST) (6) gcloud run services list --region=us-east1 --format='table(metadata.name,status.latestReadyRevisionName,spec.template.spec.containers[0].image)' for the parts-services image tags (7) bun run ops/scripts/search-promote-check.ts to refresh the before/after instrument once auth is back.

The Artifact Registry path was renamed on 2026-08-19, mid-week, between the last promote and this one. Lineage from the #916 diff, which I read directly: search-hono-nest -> search-nest -> crop-search, all under us-east1-docker.pkg.dev/noted-bliss-466410-q6/cloud-run-source-deploy/. So the promote pushes crop-search:<dev sha> while the thing you roll back TO is search-nest:2da1a51e3d98ffc37b4656a0f00bd6c44930cdab — a different repository name, confirmed independently by this morning's evidence JSON. #916's own workflow comment says it: 'A rollback must use the path that SHA was built under, not this one.' The delivery-flow runbook repeats it. The trap is that swapping the tag on the crop-search path to 2da1a51e resolves to nothing and Cloud Build fails, at the exact moment you are trying to undo a bad promote. The safe rollback does not touch images at all: gcloud run services update-traffic search-api --to-revisions=<prev-revision>=100 --region=us-east1, because every revision stays routable by name until deleted. That needs the revision name, which is UNAVAILABLE (see the gcloud item).

What to doVova: before the swap, capture the currently-serving revision name and write BOTH the revision name and the full old image URI (us-east1-docker.pkg.dev/noted-bliss-466410-q6/cloud-run-source-deploy/search-nest:2da1a51e3d98ffc37b4656a0f00bd6c44930cdab) on the change-control page. Roll back by revision, not by image.

Measured by me at ~12:54-13:05Z today, crawler UA, never-before-used query strings. Prod search-api /health — the cheapest endpoint there is, a DB ping with no federated fan-out — answered: timeout at 40s, timeout at 40s, then 200 in 38.77s. Dev search-api /health answered 200 in 0.62s with a healthy vocabulary cache. That is not the #895/#896 fan-out shape; /health does not do the fan-out. More important, the CONTROL path from #924 has failed over: https://crop.clintontractor.net/parts?page=10 returned 500 three times out of three (20.08s, 5.39s, 2.56s) where at 01:15Z it was 200 in 0.78-0.96s and was cited in #924 as proof that 'listing is healthy, only search fails'. It no longer is. Also measured: / = 200 in 5.53s, /parts (bare) = 200 in 4.61s, PDP /parts/CT-NHL-100074 = 200 in 19.11s. So per the brief's rule I am saying it plainly: I cannot separate 'the promote surface' from 'the live outage' today, because the outage now reaches the plain catalogue listing. Whatever before/after you take on Friday will be measured against a moving, degrading baseline — and the before/after window dies at the promote.

What to doVova: re-run bun run ops/scripts/search-promote-check.ts immediately before the promote to refresh the BEFORE, and treat the 07:35Z evidence JSON as stale. If /health is still 38s+ at promote time, decide explicitly whether the candidate gate can even be trusted to pass — a 40s /health will not survive smoke-candidate.sh.

The front weekly promote is merge stage -> main per docs/runbooks/delivery-flow.md. stage HEAD is e6b2f0f99, dated 2026-08-14T06:14:24Z, message 'chore(stage): re-cut release train 2026-08-13 from dev [preview]'. compare/main...stage = 2 ahead, 93 behind, 0 files changed; compare/stage...dev = 89 ahead. So stage carries last week's train and nothing from this week. Today is Thursday 2026-08-20, which is the cut day, and as of 13:00Z the cut has not happened. Everything downstream of the cut is therefore also not done: no QA pass on stage, and CROP-change-control holds only 2026-08-07.html and 2026-08-14.html — there is no page for this train, and that page is the material for John's five-minute retro.

What to doVova: cut stage from the frozen dev SHA today, or decide now that Friday is a search-only promote and say so — the front half cannot be validated on a stage that is 89 commits behind dev.

The Friday promote image-swaps whatever artifact the DEV gate blessed. It did not bless dev HEAD. Run 32347365459 (Deploy search-api-dev, dev sha 678b7af2 = #925, 08:08Z today): 'Build image' success, 'Deploy candidate revision (no traffic)' success, 'Smoke + warm + contract gate vs candidate' FAILURE, 'Promote candidate to 100% traffic' SKIPPED, 'Delete un-promoted candidate on gate failure' success. The run before it (f5518b6b, 07:38Z) succeeded. So search-api-dev today serves the f5518b6b image — it has #920 (cache the three hottest assemblies routes) and #922 (Kuhn part_count) but NOT #925 (CNH assemblies fence). A third run (24b775a4, 07:38Z) also failed. This is the exact silent-staleness failure #910 documented: the workflow behaves as designed, nothing alerts, and the old revision keeps serving. ops/docs/2026-08-20-merchant-feed-promote.md adds the second half: smoke-candidate.sh runs against dev-crop-db, which IS prod PG, so a gate run inside a ~100% CPU window fails on plain browse and a rerun inside the same window is wasted. Friday 05:00 NY = 09:00 UTC read 97.9% max on 08-17 and 94.0% on 08-18.

What to doVova: before the swap, pull prod PG CPU for the preceding 30 minutes; if it is pegged, wait rather than rerun. Then re-run the dev deploy on dev HEAD and confirm gate -> promote -> terminal-page parity all green and latestReady == latestCreated. Only then swap. Decide explicitly whether you swap dev HEAD (needs a green gate) or the f5518b6b image (green, but without #925).

Measured 2026-08-20 ~13:00Z with never-before-used query strings. Prod /api/search: first probe no response at 45s, second 200 in 32.4s. search-api-dev on the SAME database: 200 in 5.67s and 4.00s. Prod /health itself took 39.6s; dev /health 0.60s. Storefront /parts?q=<fresh> 500 in 16.8s. New, and not in #924: /parts?page=2 500 in 3.1s and /parts?page=10 500 in 2.9s and 5.3s, while /parts page 1 is 200 in 4.7s and the home page is 200. #924 records 'Listing is healthy, /parts?page=10 200 in 0.81s' — that is no longer true, so the customer-visible surface is bigger than the issue says. Page 1 is CDN-cached; anything uncached fails. This also means a prod 500 on almost any catalogue path today is this outage, not a new regression — I could not separate the two on any uncached route.

What to doVova: the swap is the fix. Add /parts?page=2 to the acceptance in search#924 (it currently only covers ?q=) and re-measure it immediately after the swap. If page 2 does not recover, the outage has a second cause and Friday's other promotes should stop.

#3653 states the constraint in its own body: 'the two brand-hold lines must be on main BEFORE PDP_INDEXING_MODE=strict is set on prod — flipping the env first would open four unsigned-off brands (Kuhn / Ferris / McHale / Marcrest, 358 registry-eligible parts). Cherry-pick then env, in that order, on the 2026-08-21 train.' #3244 merged a day later and flips the DEFAULT to strict in lib/seo-config.ts, so once it is on main there is no env step left to hold back — strict arrives with the deploy. #3244 also kills legacyBrandHold (gated on mode !== strict) and says so. #3244's justification is 'PDP_INDEXING_MODE=strict is already set on prod, so prod behaviour is unchanged'. That claim does not survive measurement: prod /sitemap/1.xml carries 2,378 locs and 2,378 of them are CT-NHL-, zero FER/KUH/MCH/MAR; prod /parts/CT-FER-1608395 answers 200 with noindex, follow. By #3625's own strict-mode detector ('any non-CNH branded loc means the hold is off'), the hold is ON in production today. I could not read the Vercel env value to settle which of the two PRs is right — env values are not readable from here.

What to doVova: read the real PDP_INDEXING_MODE value in Vercel Production before the train (vercel env ls production, or the dashboard). Then either cherry-pick #3653 and #3244 as one changeset, or hold #3244 back entirely. #3244 alone opens four brands John has not signed off.

#615 adds validateCheckout to POST /payment-intent — the Apple Pay / Google Pay / Link path — which issues one GET /api/parts/:id per cart line against the search service and fails CLOSED. Prod search answers cold in 32s today; payment-service's fetchPartPrice has a 5s timeout. The hosted checkout page already fails exactly this way: ops/docs/2026-08-20-checkout-blocked-by-pg-saturation.md records crop-checkout-probe (a real POST /api/checkout/session against production every 30 min) failing three scheduled executions on 08-19 with 'Could not verify price for CROP-SYNTHETIC-PROBE (search API timeout)', p0 policy, alert fired five times, nobody came. Express Checkout is currently the one payment path that still works, precisely because it does not call the catalogue. Promoting #615 first removes that.

What to doVova: search-api image swap first, verified green on a fresh cold query, then ps#615. The sequence is not negotiable. If the swap slips, ps#615 slips with it.

ops/docs/2026-08-20-merchant-feed-promote.md lists as a hard gate: 'Denis's explicit QA sign-off on stage — hard gate. No sign-off, no promote, the train waits a week.' Denis departed 2026-08-20. Seven of this week's dev merges carry Driver: @denistka, including two customer-visible availability changes (front#3565, search#891) and two revenue-path changes (ps#615, ps#624). Nobody is named to sign off on stage on Friday, and a gate that passes by default is worse than no gate.

What to doVova: before Friday, either name yourself as the stage sign-off and do the pass, or delete the gate from delivery-flow.md and record what replaces it. Do not let the train roll with the box unticked and unnoticed.

front#3653 (merge 65e71f00c7, 08-18) made the brand hold mode-independent; front#3244 (merge fa60043144, 08-19) flipped PDP_INDEXING_MODE's default from legacy to strict. They are separate commits and the house rule is individual cherry-pick PRs, so they can land apart. Verified on origin/main today: lib/seo-config.ts still returns "legacy" by default, lib/seo/pdp-index-hold.ts starts with if (PDP_INDEXING_MODE === "strict") return false;, and app/parts/[id]/page.tsx:223 gates legacyBrandHold on PDP_INDEXING_MODE !== "strict". On origin/dev both exemptions are gone and isBrandHeldSku is unconditional. So cherry-picking #3244 alone = Kuhn/Ferris/McHale/Marcrest PDPs plus both sitemap surfaces go index,follow — #3653 puts that at 358 registry-eligible parts John has not signed off. The two PR bodies argue opposite conclusions: #3244 calls the hold going dead "intentional and correct", #3653 calls it four unsigned-off brands. A reviewer reading only #3244 would approve it standalone. Second trap: #3653's runbook line "cherry-pick then env, in that order" is now half-stale — #3244 absorbed PDP_INDEXING_MODE=strict into code, so the pick itself is the flip and there is no env gate left on that half. The env step that genuinely remains is ENABLE_EQUIPMENT_TREE_NOINDEX=true (still === "true", default off, verified on dev). No open issue carries this coupling; #2912 and #3594 are both closed.

What to doVova: assemble the 08-21 front train so lib/seo-config.ts, lib/seo/pdp-index-hold.ts and app/parts/[id]/page.tsx land in ONE cherry-pick PR, and correct the ordering line in docs/seo/index-open-runbook.md before anyone follows it. After promote, curl -A crop-audit a KUH/FER/MCH/MAR PDP and confirm noindex, follow.

Measured today with -A crop-audit against production: /robots.txt 200 in 0.66s, /sitemap/1.xml 200 in 0.34s advertising 2,378 PDP locs, / 200 in 6.4s — but /parts?q=<never-used-string> returned 500 in 20.2s, /parts/CT-NHL-219758 gave no response inside 40s, and /parts/CT-NHL-100016 (taken straight from that sitemap) took 19.0s to answer 200. A Ferris PN returned 500 at 63s on one probe. So the entire indexable surface we submit is currently answering slowly or erroring to a crawler. Separately, front dev HEAD (ce2513b7) has build, lint-and-build and crawl-preview all failing: run 32348291522 job build at 08:33Z shows /api/brand/{mchale,marcrest,new-holland-agriculture,ferris,kuhn,kress,landoll}/equipment-types each returning errorStatus 429, retry-exhausted, adaptive-backoff healthy -> recovering. That is the same prod-search dependency front#3707 is filed for. Consequence nobody has written down: no cherry-pick PR to main can go green while dev CI is red on this, so the front train is downstream of the image swap, not parallel to it. ops/scripts/search-promote-check.ts exists and its before-window is already captured (ops 1960680).

What to doVova: do the search#924 image swap first, verify with bun run ops/scripts/search-promote-check.ts (status before latency; novel query string), then re-run front CI on dev and only then assemble the train.

Route A, the runbook's weekly train: merge stage -> main, which after a fresh cut carries compare/main...dev = 88 commits / 300 files. That is the whole week — the SEO train (#3653, #3700, #3661), the merchant feed widening (#3655, #3650, #3690), the availability and PDP work, the CI restructuring. Route B, what is actually open against main right now: five cherry-pick PRs, #3680, #3679, #3675, #3662, #3638 — every one of them a CI or gate fix (sitemap-seo-gate cold start, scheduled-lane reds, stage-target preflight, brand-hold subtraction, Vercel automation bypass). Not one of them touches customer-facing code. Worth noting explicitly: none of the front fixes for the current outage — #3712 (answer a transient search failure like an outage, not a 500), #3684 (a search outage must not read as a discontinued catalogue), #3628 (degraded listing reaches a crawler as 503, not 500) — has a cherry-pick PR open. They are dev-only. So the storefront's own resilience to a search outage does not reach production on Route B.

What to doVova: state which route Friday is, out loud, before the call. If it is Route B, say plainly that the storefront keeps 500-ing on a search failure because #3712/#3684/#3628 are not in it.

Answer to question 3, first genuine item. #3700 turns 407,302 part pages into an edge 404 in lib/proxy/supersession-redirect.ts. I grepped its full diff for a gate — process.env appears exactly once, as deps.baseUrl ?? process.env.SEARCH_SERVICE_URL. There is no feature flag: this ships on promote. The outward-state part is Google's crawl: URLs crawled and served 404 during the live window are a signal already sent, and a code rollback does not recall it. Two things bound the damage, both measured in the PRs themselves rather than assumed. First, all 407,302 are already is_publishable=false and already noindex per #3700's body, so the indexed set barely moves — this is crawl-budget work, not de-indexing of ranking pages. Second, #3710 deliberately caps the edge TTL at s-maxage=300 (it would otherwise inherit /parts-not-found's s-maxage=3600 + 24h stale-while-revalidate), so a rollback restores 200s within five minutes instead of a day. The 13,626 dont_list rows that carry a price or an image stay 200.

What to doVova: accept or hold this one explicitly on Friday. If accepted, note on the change-control page that rollback is code-plus-five-minutes at the edge, not instant, and that #3710 is what makes that true — it must ship in the same promote as #3700, never after it.

compare/main...dev = 8 commits ahead, 56 files. main HEAD be865716b dates from 2026-08-14T07:07:30Z (#616, the 08-13 train); dev HEAD 38352042f from 08-18. Two of the eight touch money. #615 (3323f61c7) re-prices the express-checkout cart against the catalogue before charging — it changes services/payment/src/routes/payment-intent.ts, i.e. what a customer is charged; #624 (38352042f) stops a UPS reply with no charge block being quoted as free shipping. Neither is one-way by itself (no outward write is added; per standing rule our code never calls Stripe for refunds), but both alter what a customer is told and charged, so a rollback after real orders leaves those orders priced by the version that was live. #620 is the Bun 1.3.9 -> 1.3.14 bump that is the cure for the TLS leak OOMing four services — arguably the one you most want in prod. Separately, four promote PRs to main have been queued since 08-11/08-12 and have not moved: #600 (Mongo idle-connection churn / OOM), #596 (/rates cache-write P0), #595 (the backfill script), #594 (photo-upload brand_code). Note the runbook's own warning: git log origin/main..origin/dev over-reports here — it says 8, git cherry -v by patch-id says 6.

What to doVova: decide whether parts-services rides Friday at all. If yes, they are individual cherry-picks from the frozen train SHA, never a dev->main merge, and #620 goes first since it is the OOM cure. If no, say so — #596 and #600 have been queued for nine days and that should be a decision, not a drift.

docs/runbooks/delivery-flow.md names three gates before a promote: Denis's explicit QA sign-off on stage (hard — no sign-off, no promote, the train waits a week); zero open release-blocker issues; and no prod deploy during working hours. I checked the second one: gh issue list --label release-blocker --state open across CROP-front, CROP-search and CROP-parts-services returns nothing — that gate is clear. Two open sale-blocker issues exist in CROP-search: #924 (which IS this promote) and #146 (the BOM description fitment bug, John-classed, unrelated). The first gate is the problem — the QA lane is unowned, and there is no stage build to sign off on anyway (see the stage item). The last promote already went out of the working-hours window on Vova's call and was logged in ops/docs/change-control/emergency-log.md.

What to doVova: decide who signs off, or decide explicitly to waive the gate for a search-only promote and log the waiver in emergency-log.md the way the 08-14 out-of-window promote was logged. An unowned hard gate that everyone quietly steps over is worse than a waived one.

search#924 states the trade in its own words: 'An image swap is all-or-nothing: promoting carries all 27 commits, not just #896/#897. SEO-train work, the merchant-feed change (#904) and the availability depot-axis change (#891) ride along. That is the decision to weigh; it is not a reason to leave a 16.5s search in production.' There is no way to take the latency fix alone. Prod search-api currently runs search-nest:2da1a51e (per the 07:35Z baseline in ops/docs/evidence/2026-08-20-search-promote-before.json).

What to doVova: accept the bundle or don't swap. If you accept it, items 7, 10 and 15 below are the three riders that actually change what customers see, and they should be named at the meeting rather than discovered afterwards.

#891 stops the parts diagram resolving stock from the retired cnh_orderability axis and reads the depot signal through the catalogue tile's own resolveRowAvailability. Known cohort: 127,404 publishable rows flip from a green In Stock chip to Out of Stock on the diagram (that number comes from the #708 work, not from this PR). The PR is explicit that the change is WIDER than that: any BOM row with no depot reading and Material Status GREEN previously read in_stock and now reads unclear — 'it is a second population, it is not 127,404, and nobody has counted it'. The body ends '@appdev-v — please run those [two SQL counts] before merging.' It merged 2026-08-16 without them. front#3562 adds the storefront-side guard so the Add-all-in-stock CTA cannot re-open it, and needs no separate decision.

What to doVova or Alex: run the two counts in the #891 body against prod PG before the swap. The second number (green chip -> 'we don't know') is the one John should hear, and it is the one nobody has.

These two only work together. #3700 edge-404s all no_cnh_data plus the price-less, image-less dont_list rows: 407,302 URLs go from 200 / 286 KB / 11.2s to 404 / ~104 KB / under a second. Deliberate but not free: 7,804 of the 75,048 no_cnh_data rows DO carry content (4,829 priced, 3,841 imaged) and 404 anyway — the PR flags this itself as 'the one number here that isn't obviously free', and making it content-conditional is a one-line change to WITHDRAWN_STATUSES. publish_status is recomputed NIGHTLY, so a URL can legitimately move 404 -> 200 -> 404 across nights. #3710 caps the CDN TTL at s-maxage=300; without it the 404 inherits s-maxage=3600 + stale-while-revalidate=86400 (measured on dev: x-vercel-cache HIT, age 84), so a part that becomes sellable overnight keeps answering 404 for up to 25 hours.

What to doVova: decide whether the 7,804 content-bearing no_cnh_data rows 404. Then ship #3700 and #3710 in the same changeset or neither. After the promote, watch pdp.unpublishable_404 for a step change, not drift.

Gated behind PDP_INDEXING_MODE=strict and the new ENABLE_EQUIPMENT_TREE_NOINDEX (default off, registered in .env.example + lib/seo-config.ts, NOT lib/env.ts — the Vercel value is part of the train). Nothing changes on merge; both switches are off/legacy today. Measured on prod now: the sitemap advertises 18,657 URLs — shard 0 = 16,279 locs of which 16,250 are /equipment*, shard 1 = 2,378 PDPs. After the flip it drops to ~2,407 (2,378 PDP + 16 brand listings + 2 brand hubs + 11 static), and 352,201 PDPs + 8,126 equipment pages + 8,124 diagram hubs move from index,follow to noindex,follow. Every one of those pages still answers 200 and is still findable by on-site search. Rollback is env-only with no deploy: PDP_INDEXING_MODE=legacy, ENABLE_EQUIPMENT_TREE_NOINDEX=false, restore DIAGRAM_NOINDEX_PILOT_FAMILIES, redeploy the current build.

What to doVova: set both vars in Vercel Production AFTER the code lands, not before. Tell John the sitemap number moves 18,657 -> ~2,407 before he sees it in GSC, and that the prepared list grows back toward ~11,800 with no further code change.

search#904 repoints the feed source from indexable_parts_v1 + merchant_eligible (which requires clinton_on_hand > 0, hence the 2,684 ceiling) to part_indexing_candidates_v1 + image/offer/commerce gates: 97,578 rows, shard width 5,000 -> 25,000. front#3655 rewrites the route against it: 4 shards of 25,000, canonical-SKU ids, >=500x500 gallery images, mapped Google categories, g:shipping dropped. ops/docs/2026-08-20-merchant-feed-promote.md: 'search-api first, front second. The front's batchSize tripwire 503s the feed if the front arrives before the backend it calls.' Measured on prod now: /feed/google/0.xml = 2,632 items served in 0.28s, /feed/google/1.xml = 503, /feed/google/inventory/0.xml = 404 — neither half is live. front#3690 fixes five more empty-string/encoding defects that #3655 itself introduced and must ride with it. If a hotfix cherry-pick is used instead of the stage->main train, the closure is three commits IN ORDER — b90bac5ae first (it adds canonicalSkuPath, which main lacks; without it the other two cherry-pick clean and then fail to compile) then a97fb36a4 then 4c5f8456f, plus #3690.

What to doVova: backend swap, verified, then front. Run bun run scripts/merchant-feed-audit.ts against prod immediately after. Note the Merchant Center account has never been created (console-only, yours) — the feed can be perfect and reach nobody until it exists.

#3655 states it plainly: the price load is a one-time April import, average age ~95 days, and 15,345 sellable parts are priced BELOW live CNH (ops/docs/evidence/2026-07-20-nh-price-correctness.md). Going from 2,635 to 97,578 items does not create the problem but multiplies the exposure by 37x. Tracked with Alex as hub#305, unresolved. Separately, 1,584 of the 97,578 are federated brands whose PDPs return 200 with noindex, follow — 353 of them are already in today's feed, so they stay in, but the reason codes want checking at the first Diagnostics read.

What to doVova: decide whether the feed goes live before hub#305 closes. If yes, say the number out loud at the meeting — 15,345 parts priced under live CNH — so it is an accepted risk and not a discovery.

Googlebot is taken off Next's blocking bot render and onto the CDN path. Measured on prod: Googlebot got x-vercel-cache BYPASS at 0.87-4.52s against a browser HIT at 0.20-1.40s, with byte-identical head and body — so the blocking render bought nothing and capped crawl rate. The htmlLimitedBots override and its drift-check workflow are deleted. This is a sitewide crawler-behaviour change that lands the moment the code deploys; there is no env switch. Two subtrees keep the old blocking render on purpose (/parts-diagrams/<brand>/<model> and /brand/<slug>) because their 404 exists ONLY because of the bot render — #3621 moves both to the edge and is also on dev, which is what lets the exception eventually go. Audit UAs including crop-audit come off the blocking path too, so probe timings before and after are not comparable.

What to doVova: accept it as part of the SEO batch or hold the whole SEO batch. If it ships, book the saving from a full billing day of production bot-vs-human latency after the promote, not from a preview — #3568 says so itself.

front#3712 merged to dev at 08:08Z today and makes /parts/[id] render ServiceUnavailable on a transient 429/5xx/timeout, which the edge re-labels 503 + Retry-After: 300 for crawlers instead of a hard 500. Its own evidence block records three prod probes at 07:35Z: 500/34.9s, no-response/45s, 500/27.1s on CT-NHL-100016. front#3693 is CLOSED (08-20). My probes four hours later still show 500s and 19-40s waits on prod, so the behaviour #3693 described is still what Google is getting — the fix exists only on dev and its tracking issue is shut. I cannot separate how much of today's 500 rate is the search outage versus anything else: both surfaces fail on the same upstream, and the storefront 500s on exactly the queries the search API refuses.

What to doVova: decide Friday whether #3712 rides the train. Note it is defence-in-depth — the search#924 swap removes the trigger — but it is the only thing that stops a future 429 burst from re-teaching Google that indexed PDPs return 500.

Both issues closed on their dev merges. #3244's body: "the sitemap/PDP count convergence measurement is a verify-phase activity post-promote". #3653's body: "The after-numbers are gated on the env flip, so they land with the Friday train, not here." The claim being verified is real and specific — 352,201 PDPs answering index,follow against a sitemap advertising 2,378, converging to ~2,407 indexable URLs — and I confirmed prod's sitemap/1.xml still carries exactly the 2,378 pre-change locs. Epic #2370 is open but names none of this. So the promote-and-verify step for the largest SEO change in the train belongs to no ticket, and #3653's four-step curl verification block will be the only place it is written down once the PR scrolls out of view.

What to doVova: before the train, file one issue (or reopen #3594) carrying #3653's four verification curls plus the sitemap loc count, assigned to yourself with a post-promote date.

parts-services main HEAD is still be865716 (08-14, train 2026-08-13). ps#600 (cherry-pick of #597, the maxIdleTimeMS half of the leak) has been open since 08-12 and did not go on 08-14; its own body says the alert has been open since 08-12T09:56Z and user-service is OOM-killed roughly daily. ps#620 (Bun 1.3.9 -> 1.3.14, the residual TLS leak) merged to dev 08-17 with measured leak rates of 2.87-4.43 MiB/h across user/delivery/payment/catalog and OOM kills on 08-15 and 08-16; its stated pass check is not a test but a dev soak — watch run.googleapis.com/container/memory/utilizations on the *-dev services and compare the slope against that baseline. Whether that soak has been read is UNAVAILABLE: gcloud is not authenticated in this session (expired token), and I am reporting that as unmeasured, not as zero. Also queued since 08-11: #594 (photo-upload 500ing since 06-10), #595 (documents still on Mongo), #596 (rate quote held behind a cache write). ps#589 is open, so the leak itself is tracked; what is untracked is who reads the soak and by when. ps#600 also warns: keep revision recycling armed for user/payment/delivery/catalog until the Bun bump lands.

What to doVova: gcloud auth login and read the *-dev memory slope against the 2.87-4.43 MiB/h baseline before Friday. If flat, promote #600 and the Bun bump together and stand down the recycling; decide the same day whether #594/#595/#596 ride or get dropped from the queue.

Before — production todayHTTP 500 after ~17s, 57,091-byte body carrying no listing. No Retry-After and no X-Robots-Tag header. Reproduced on six page numbers, five of them never requested before: page 500 (500, 17.01s), 641 (500, 17.02s and 17.43s), 733 (500, 16.95s), 852 (500, 17.14s), 904 (500), 1000 (500, 18.63s).

After — the candidate todayHTTP 200 after ~9-11s, 54,416-byte body also carrying no listing (a page that works, ?page=1, is 483,454 bytes). Still no Retry-After and no X-Robots-Tag. So the customer stops getting an error page, but front#3628's stated outcome — 503 + Retry-After: 300 + X-Robots-Tag: noindex for a crawler — does NOT reproduce against crop-dev.app. That claim was verified against the PR's own preview deployment, not against dev. Worth a decision before the promote: for a person a quiet 200 is better than a 500, for Google a 200 on an empty page is a soft-404 and is worse than the 503 the PR promised.

Before — production todayHTTP 503 in 5.44s, retry-after: 1, cache-control: no-store, server-timing: total;dur=5003, body {"error":"Service temporarily unavailable","message":"Search is briefly degraded — please retry.","code":"SEARCH_DEGRADED"}

After — the candidate todayByte-for-byte the same: HTTP 503 in 5.49s, retry-after: 1, total;dur=5002, same SEARCH_DEGRADED body. Unchanged by design. Both environments receive an identical, well-formed refusal from the backend — so the 500-versus-200 difference in the row above is entirely the storefront's handling of it, and nothing here is the CROP-search#874 prod outage.

Before — production todayThree cold runs (fresh cache key each, x-cache: MISS on every one): server-timing total;dur = 3,995ms / 1,503ms / 2,597ms; wall clock 5.09s / 2.51s / 3.21s.

After — the candidate todaySame three runs against dev: total;dur = 58ms / 43ms / 32ms; wall clock 1.11s / 1.08s / 1.05s. Roughly 60x less database time on the median. The answer is identical — all six responses are 217,121 bytes with md5 20eac2b35201af17324ce24b2f6d6ade — so nothing about what the customer sees changed, only how long they wait.

Before — production todayNo x-cache header exists on these routes at all, and every call reaches PostgreSQL. Chapters: db;dur=33 then db;dur=39 on two identical back-to-back calls (re-checked later: 41 then 54). Model assemblies: db;dur=304 then db;dur=263.

After — the candidate todayChapters: first call db;dur=90 with x-cache: MISS, second identical call cache;dur=0 with x-cache: HIT. Model assemblies: first call db;dur=725 MISS, second cache;dur=0 HIT. The database is not touched on the repeat. Payloads are byte-identical between the two environments (3,807 bytes for chapters, 19,635 for assemblies), so this is purely load taken off the database that also serves checkout.

Before — production todayHTTP 200 in 4.02s, server-timing search_facets;dur=3360, x-cache: MISS. The 15-second hang ending in a 500 that the PR recorded (15,082 / 16,114 / 14,360ms on this exact model key) did not happen — the database is not saturated at 12:47Z today.

After — the candidate todayHTTP 200 in 5.48s, search_facets;dur=4762, x-cache: MISS. The new 8,000ms cap did not fire on either side because neither side got near it. The change that matters — a fast 503 with Retry-After replacing a 15s 500, and replacing a silently empty filter list — only shows itself while PostgreSQL is overloaded, and I could not create that condition without deliberately loading the production database, which I did not do. Both sides answer 200 today.

Before — production todaySix probes between 12:44Z and 12:57Z: HTTP 200 every time, 2.93s / 3.64s / 3.97s / 4.12s / 4.43s / 6.86s, 559,047 bytes. The 500s the PR captured on this exact URL at 07:35Z (500 in 34.9s, no response in 45.0s, 500 in 27.1s) are NOT reproducible now — production search recovered during the morning.

After — the candidate todayDev answers 200 in 3.23s and 3.82s, 557,270 bytes. Both sides healthy, so the actual change — a transient upstream failure reaching the customer as a hard 500 versus as the 'temporarily unavailable, retry shortly' page — cannot be observed on demand right now. Making it observable would mean loading an already-degraded production service, which both PRs say is exactly the wrong thing to do, so I did not. This is the one row where the before is a morning measurement in the PR rather than something the meeting can re-run.

Before — production todayHTTP 307 redirect to /sign-in?redirect_url=%2Faccount%2Fsaved-parts. The page is behind Clerk sign-in, so an anonymous probe never reaches the behaviour. (/garage and /saved-parts are both 404 — /account/saved-parts is the real surface.)

After — the candidate todayCould not be measured. Showing the difference needs three things at once: a signed-in customer, saved parts already in their account, and a failing search backend. The first two need a real session, and the third cannot be created safely on production. The change is real and unit-tested (3 of 7 tests red before the fix, 7 green after) but it is not probe-observable from outside, so treat it as untested end-to-end going into the promote.

This pair could not be observed today — the reason is in the two lines above, and no number has been invented to fill the gap.

Before — production todayNot applicable — production runs the pre-promote image, which does not contain this change.

After — the candidate todayNot running on dev either. dev HEAD is 678b7af2 (search#925), but its Deploy search-api-dev run failed at 08:29Z with 'Gate failed — candidate tag removed'. The last successful deploy was f5518b6b (search#922) at 07:38Z, and search-api-dev is still serving revision search-api-dev-00015-yej. So search#925 is merged, is inside tomorrow's promote candidate, and has never served a single request in any environment. Everything measured in the rows above comes from #913 + #920 + #922 only; none of it includes #925.

Before — production today7 never-before-used query strings against production. Server-reported total: 2,137 / 15,051 / 15,173 / 15,199 / 15,272 / 15,285 / 15,454 ms — six of the seven pinned flat at the 15-second database timeout, whatever the query was. Wall clock 4.7-17.4s. Production's timing header has no federated_equipment segment at all, so the 15 seconds shows up as an unexplained gap.

After — the candidate today7 fresh strings against dev: 1,312 / 1,347 / 1,680 / 1,747 / 2,138 / 2,571 / 5,140 ms. Wall clock 1.8-5.7s. Nothing sits on the 15s wall. Every dev response carries federated_equipment;dur=0 — the leg now has its own segment (#896) and costs zero because the failed brand snapshot is remembered for five minutes instead of retried (#897).

Before — production today7 fresh queries on production: 6 returned HTTP 500 after 16.7-17.2 seconds, 1 returned 200 after 6.2s. This is the live customer symptom behind CROP-search#924.

After — the candidate today7 fresh queries on dev: 7 of 7 returned HTTP 200, in 4.4-8.6 seconds. Caveat stated plainly: dev also runs newer storefront code, so this row is the whole path, not the search API alone — row 1 is the isolated API measurement.

Before — production todayProduction emits no x-cache header at all on these three routes, and db;dur= on every single call including an immediate repeat of the identical URL: model assemblies 124 then 139 ms, chapters 40 then 80 ms, assembly detail 13 then 14 ms. Every request reaches Postgres. (Production does send x-cache on /api/search and the brand routes, so the header is not being stripped — these routes were simply never wired.)

After — the candidate todayDev returns x-cache: MISS with db;dur= on the first call and x-cache: HIT with cache;dur=0 on the second, for all three routes. The deliberate exclusion holds: /api/assembly-search on dev still has no x-cache and still ran the query twice (db;dur=970 then 409 ms).

Before — production todayProduction, server-reported total, cache deliberately bypassed with a fresh nonce, 3-4 samples per model: model 2273 = 1,252 / 1,305 / 1,315 / 1,379 ms; model 15661 = 1,222 / 1,229 / 1,266 ms; model 10363 = 1,250 / 1,257 / 2,427 ms; model 159 = 135 / 144 / 210 ms.

After — the candidate todayDev, same models, same method: model 2273 = 29 / 34 / 38 / 50 ms; model 15661 = 85 / 99 / 100 ms; model 10363 = 29 / 35 / 41 ms; model 159 = 21 / 23 / 69 ms. Roughly 30x faster on the three big models. The answer is unchanged: model 2273's full 916-row payload is byte-identical between production and dev once the timing field is excluded.

Before — production today14 cold production calls on the pathological leg: 1,135 / 2,025 / 2,388 / 2,483 / 2,546 / 2,793 / 2,901 / 3,052 / 3,245 / 3,820 / 6,596 / 7,777 / 11,095 ms. All answered 200. There is no ceiling — the 11.1-second call is production simply waiting, and past 15s it becomes a 500 or a silently empty sidebar.

After — the candidate today16 cold dev calls, same leg: 1,497 through 7,628 ms answered 200, and one call that reached the new 8-second budget returned HTTP 503 with Retry-After: 1 at total;dur=8061. Caught live, paired against a production call in the same second that was still waiting at 7,777 ms with no limit. The cap fires exactly where the PR says it does.

Before — production todayThe defect is real and reproducible today. Three identical requests for page 1 of model ABC3335398's diagram list returned three different pages on the dev backend — 16 and 19 of the 50 rows changed position, and the sets were not even the same rows. Production happened to answer the same three calls identically during the probe, because its query plan is currently stable; neither side has the fix, so neither side is safe from it.

After — the candidate todayCannot be observed. The change merged to dev at 08:08Z today, its dev deploy ran, the candidate revision was built and deployed with no traffic, the contract gate failed, the promote step was skipped and the candidate revision was deleted. Dev is serving the previous commit. So search#925 is running on neither service, and unless a fresh dev deploy passes its gate before tomorrow it will not be in the Friday image swap either.

This pair could not be observed today — the reason is in the two lines above, and no number has been invented to fill the gap.

Before — production todayAddress bar becomes /parts?view=counter&pageSize=100&sortBy=name_asc&hasImage=true&categoryId=FASTENERS — every parameter that was already there rides along

After — the candidate todayAddress bar becomes /parts?categoryId=FASTENERS — driven through the real page on crop-dev.app today, not from the PR body

Before — production todayThe merged URL answers <meta name="robots" content="noindex, follow"> and carries NO canonical tag at all. The clean /parts?categoryId=FASTENERS answers "index, follow" with a self-canonical. So on production every category click spent its link value on a page we told Google to drop.

After — the candidate todayOn dev the same merged URL now emits a canonical pointing at the clean /parts?categoryId=FASTENERS. The robots value cannot be compared on dev — dev is "noindex, nofollow" site-wide by design — so the customer-facing half of this is the row above: the click no longer mints the noindex URL.

Before — production today1 — the pill strip under the search bar is on the page alongside the sidebar's Part Category list, ranked differently and able to show a different set of categories

After — the candidate today0 — the pill strip is gone; the sidebar is the only category control

Before — production today{"total":8,"toggleCounts":null} — production has no such field, so the page has no way to know a filter would empty the grid

After — the candidate today{"total":8,"toggleCounts":{"shipsSameDay":0,"hasImage":3}} — dev measures it: of the 8 Versatile brake parts, none ship same day

Before — production todayCheckbox is enabled; clicking it goes to ...&shipsSameDay=true and the page reads "No results match your filters"

After — the candidate todayUnchanged on dev: the checkbox is still enabled and still lands on "No results match your filters", even though dev's own /api/filters reports shipsSameDay: 0 for exactly this combination. The backend half landed; the sidebar is not acting on it for this case. This dead end is NOT closed by the promote.

Before — production today52 parts on the Battery diagram: 49 say in_stock, 2 call_us, 1 unclear. Part 48126818 says in_stock although its depot reading is RED, and the catalogue page for that same part says out of stock. "Add all in-stock" would add all 49.

After — the candidate todaySame 52 parts: 34 say in_stock, 18 call_us, 0 unclear. Part 48126818 now says call_us. 15 rows leave the "Add all in-stock" button, and the diagram agrees with the catalogue.

Before — production todayProduction already reads correctly for the closest live case I could find: CT-AGC-302047 (no online price, 50 on our shelf) shows "Out of Stock" and "Ask for a price", with zero occurrences of "In Stock" and zero of "usually ships same day".

After — the candidate todayDev renders the same. I could not find any live part in the state the fix is aimed at: every priced-but-not-purchasable publishable part in the serving database already reads out_of_stock, and none of them carries shelf stock. So this ships as a guard against a state that has no population today, not as a visible correction — please do not describe it to John as a live lie we removed unless someone finds the part.

Before — production todayNothing asserted the button's own composition end to end; breaking the snapshot mapping failed only one unrelated assertion.

After — the candidate todayCannot be observed from outside — this is a test-only change with no rendered surface. Not run in this session either: there is no CROP-front worktree here and the shared checkout is parked on a stale branch, so running it would have measured the wrong code.

This pair could not be observed today — the reason is in the two lines above, and no number has been invented to fill the gap.

Before — production todayDead end. /parts/069526 makes one 308 hop to /parts/CT-NHL-069526, and that address answers 404. Identical on all three construction parts sampled (069526, A14858, 1014009C1) — 3 of 3 dead-end, final code 404.

After — the candidate todayWorks. One 308 hop to /parts/CT-NHC-069526, which answers 200. 3 of 3 reach a live page in a single hop. Sampled parts are all publish_status='sellable' so nothing else suppresses them.

Production todayThe candidate

Before — production today404 immediately, with no redirect at all (hops=0). Same for CT-NHL-A14858 and CT-NHL-1014009C1. Every one of these addresses is already in Google's index from earlier crawls, and each is a hard dead end.

After — the candidate today308 forward to /parts/CT-NHC-069526, which answers 200 (hops=1). All three already-crawled addresses heal onto the working page instead of dying.

Production todayThe candidate

Before — production todayThe page emits 6 diagram links, 6 of 6 in the old raw-code form (e.g. .../parts-diagrams/5FC8CAAF-B8BF-E111-9FCE-005056875BD6?highlight=21). Followed, that link is a 308 to .../parts-diagrams/75-200-10-spike-tooth-harrow before it reaches 200 — every diagram link costs a wasted round trip.

After — the candidate todaySame 6 links, 6 of 6 already in the readable form (e.g. .../parts-diagrams/75-200-10-spike-tooth-harrow?highlight=21). Followed, it answers 200 with hops=0 — no bounce.

Before — production today6 diagrams returned, the field assemblySlug appears 0 times. The site had nothing but the raw code to build a link from, which is why row 3's before-state exists at all.

After — the candidate todaySame 6 diagrams, assemblySlug appears 6 times (e.g. "assemblySlug":"75-200-10-spike-tooth-harrow"), and the separate "slug" field still carries the model slug, unchanged. This is the enabling half — confirmed live on search-api-dev, so front#3658 has real data to read.

Before — production todayThe page itself loads (200), but the address it declares as its official one is https://crop.clintontractor.net/parts/CT-NHL-ESH6/L3/48 — the slash left raw, splitting one part number into three path pieces. Probed directly, that declared address answers 404. So the page tells Google its real home is a dead link.

After — the candidate todayThe same page declares https://crop-dev.app/parts/CT-NHL-ESH6%2FL3%2F48 — the slash encoded, pointing at itself. Real part number from prod PG (ESH6/L3/48, sellable, $192.91), not a made-up example.

Before — production todayTwo of the three POWERSTAR-90 variants serve a byte-identical title: 'New Holland POWERSTAR-90 ...4 B (na) - 20 chapters | CROP' for both the Mechanical and the Power Shuttle page. The words that tell them apart were cut off; only the shared tail survived.

After — the candidate todayAll three distinct: '...POWERSTAR-90 Mechanical... - 20 chapters', '...POWERSTAR-90 Power... - 20 chapters', '...POWERSTAR-90 Dual... - 20 chapters'. 3 of 3 unique on the same command.

Before — production todayBoth variant pages show the same heading: 'New Holland POWERSTAR-90'. A customer landing on either one cannot tell from the heading which version's diagrams they are looking at.

After — the candidate today'New Holland POWERSTAR-90 Mechanical Tractor - Tier 4 B (na)' and 'New Holland POWERSTAR-90 Power Shuttle Tractor - Tier 4 B (na)'. The heading now carries what used to sit only in the paragraph underneath.

Before — production todayAll three answer 200. CT-NHL-01111895 (no price, no image): 200, 288,341 B, 2.19 s. CT-NHL-0145155 (no CNH data): 200, 338,531 B, 2.93 s. CT-NHL-100074 (the control, a withdrawn part that does have an image): 200, 289,938 B, 2.34 s. Prod PG, queried directly today: 75,048 rows carry no CNH data and 332,254 more are withdrawn with neither a price nor an image — 407,302 URLs of this shape.

After — the candidate todayThe two dead ones answer 404 in 101,413 B and 0.51 s each — a third of a second instead of two and a half, and a third of the bytes. The control is untouched at 200, 285,347 B: the 13,626 withdrawn parts that still carry a price or an image keep their page.

Production todayThe candidate

Before — production todayProd's 404 carries cdn-cache-control: public, s-maxage=3600, stale-while-revalidate=86400 and cache-control: s-maxage=31536000 — one hour fresh, then served stale for another twenty-four. Whether a part is buyable is recomputed nightly, so a part that came back could keep answering 404 for up to twenty-five hours.

After — the candidate todayDev's 404 carries cdn-cache-control: public, s-maxage=300 with no stale-while-revalidate, and cache-control: public, max-age=0, must-revalidate. Confirmed on a real withdrawn part too: /parts/CT-NHL-20348S answers 404 on dev with s-maxage=300 and x-vercel-cache: HIT at age 184.

Before — production todayAll three dead URLs answer 200 to a browser and 404 to Googlebot on production. /brand/zzz-not-a-brand, /parts-diagrams/new-holland/ZZZ-NOT-A-MODEL and /parts-diagrams/mchale/ZZZ-NOT-A-MODEL/ZZZ-NOT-AN-ASM: chrome=200, googlebot=404 on every one. The live control /brand/new-holland-agriculture answers 200 to both.

After — the candidate todayAll three answer 404 to both, on dev. The live control still answers 200 to both. The status no longer depends on who is asking.

Production todayThe candidate

Before — production todayOn production, Googlebot gets x-vercel-cache: BYPASS on /parts/CT-NHL-100016 — twice in a row, 2.67 s and 4.68 s. A browser asking for the identical URL in the same minute gets x-vercel-cache: HIT. Every crawl was paying for a fresh render nobody stored.

After — the candidate todayOn dev, Googlebot gets x-vercel-cache: HIT — the same cache state a browser gets, on the same URL. Not measurable as a time saving here: dev is a different, colder deployment, so the seconds are noise. The cache state is the fact.

Before — production todayProduction emits three crawlable links that carry the display options forward: /parts?view=counter&pageSize=100&page=2, &page=3 and &page=1000. Separately, /parts?view=grid serves index, follow with a canonical pointing at /parts, while /parts?pageSize=100 — the same kind of option on the same page — serves noindex, follow with no canonical.

After — the candidate todayDev emits /parts?page=2, /parts?page=3 and /parts?page=1000 — the display options are gone from the links. The robots-tag half of this change cannot be separated on dev: dev serves noindex, nofollow on every page by environment, and it emits a canonical even on /parts?pageSize=100 where production's rule drops one. Only the links are cleanly measurable before Friday.

Before — production todayOn production, /parts/brand/new-holland-agriculture/type/balers?page=7 answers index, follow and names https://crop.clintontractor.net/parts/brand/new-holland-agriculture/type/balers as its canonical — page one, which shares none of page seven's parts. /parts/brand/new-holland-agriculture?page=7 answers index, follow with the title New Holland Parts | Clinton Tractor — Page 7.

After — the candidate todayOn dev the balers page names itself as its canonical: .../type/balers?page=7. The brand title reads New Holland Parts — Page 7 | Clinton Tractor, page number before the publisher, matching /parts. The third half of this change — deep brand pages answering noindex past page five — cannot be read on dev, because dev answers noindex on every page regardless.

Production todayThe candidate

Before — production todayMeasured on production today. The sitemap advertises 18,657 URLs (16,279 + 2,378), and 16,250 of those — 87 percent — are the per-model equipment tree and its diagram hubs. Only 2,378 are product pages. Meanwhile /parts/CT-NHL-219758, which is not in the sitemap at all, answers 200 with index, follow, and so does /equipment/attachments-rotary-broom-aad86496ef and its /parts-diagrams hub. Prod PG holds 579,518 part rows flagged publishable against those 2,378 advertised — the robots tag and the sitemap are running on two different rules.

After — the candidate todayCannot be observed on dev, and would not be visible there even if it could. Three separate reasons, each checked: dev's robots.txt is User-Agent: * / Disallow: / and every page answers noindex, nofollow by environment, so no robots tag can be told apart; /sitemap.xml, /sitemap-index.xml, /sitemap/0.xml, /sitemap/1.xml and /sitemap-images/0.xml all answer 404 on dev, so there is no sitemap to count; and both switches this PR adds ship off by design, so the change is inert until the environment values are set in production after the promote. The 2,407-URL figure in the PR is the projection, not a reading.

This pair could not be observed today — the reason is in the two lines above, and no number has been invented to fill the gap.

Before — production todayProduction answers 500 on both, with no Retry-After and no noindex header: /parts?page=500 in 17.0 s and /parts/brand/new-holland-agriculture?page=300 in 19.3 s. Repeated 500s are what tell Google to crawl the site less.

After — the candidate todayCannot be observed on dev. Dev answers 200 on both of those URLs — 11.6 s and 14.9 s — an empty listing with zero product links, because dev's search backend does not refuse the deep page the way production's does. The change only relabels a page that failed, and on dev nothing fails, so nothing relabels. Production search is also degraded today (CROP-search#924, the queued promote), which means I cannot separate a by-design refusal of a deep page from that outage even on the production side.

This pair could not be observed today — the reason is in the two lines above, and no number has been invented to fill the gap.

Before — production today{"total":2681,"batchSize":5000,"boundaries":[]} — 2,681 products eligible for the feed, in one file. The binding gate was clinton_on_hand > 0, so only parts physically on Clinton's own shelf could be advertised.

After — the candidate today{"total":97619,"batchSize":25000,"boundaries":["NHL|47886103","NHL|84071622","NHL|87419908"]} — 97,619 products across 4 files of 25,000. 36x the population, and 4 Merchant Center data sources instead of 20.

Before — production todayProd emits the photo URL without the parts/ bucket prefix — https://media.clintontractor.net/ct/bns/1650347SM/gallery/1650347SM-1.jpg. 405 of the 2,681 prod rows have that shape, and 10 of 10 sampled return 404.

After — the candidate todayDev emits https://media.clintontractor.net/parts/ct/bns/1650347SM/gallery/1650347SM-1.jpg, and 10 of 10 sampled return 200. Same photo, same part: the prod URL 404s and the dev URL 200s side by side.

Before — production todayThe live feed advertises the CNH catalogue thumbnail on 2,278 of 2,632 items (86%). 12 of 12 sampled measure exactly 510x287 — 0 of 12 clear Merchant Center's 500x500 floor, so those items would be size-rejected. The ops audit scored the same thing 4 of 24.

After — the candidate todayThe merchant rows the new feed reads carry the gallery photo instead: 12 of 12 sampled are >=500x500 (1024x1024 typical, one 1612x1209), and 25,000 of 25,000 rows carry a photo at all. Honest caveat: this is measured on the source the new feed reads, not on the feed file, because /feed/google/*.xml returns 404 outside production. The feed's own g:image_link can only be measured after Friday's promote.

Before — production todayMeasured on prod today: 1 shard, 2,632 items (shards 1-3 return 404). Audit criterion 1 FAILS — 0 of 2,632 g:id carry the canonical CT-VENDOR-PN SKU; they are bare part numbers like 1650347SM, so Merchant Center would key its product statistics to an id we are about to change. g:google_product_category is 888 (the bare Vehicles & Parts root) on all 2,632 items; g:product_type on 0 items; g:shipping on 2,256 (85%), a flat 9.00 USD that contradicts the free-over-$75 rule; g:description byte-identical to the title on 2,306 (87%). Criteria 2 and 4 pass today: links 40/40 return 200 with no redirect, parity 20/20 feed == PDP JSON-LD.

After — the candidate todayCOULD NOT BE MEASURED. /feed/google/0.xml through 3.xml all return 404 on crop-dev.app: the route fail-closes outside production on IS_INDEXING_ENABLED, by design, so a 404 there is correct behaviour and not a fault. The audit run against --base https://crop-dev.app reports 0 shards / 0 items for that reason, not because the feed is empty. The 404 is a genuine 404 and not the Vercel login wall — the same bypass header on /parts/CT-FER-1608395 returns 200 with the effective URL still crop-dev.app. The first observable after is this same audit command re-run against prod once Friday's promote lands.

This pair could not be observed today — the reason is in the two lines above, and no number has been invented to fill the gap.

Before — production todayProd. Across 12 sampled part pages, 9 state stock to Google and 3 omit availability from the Offer entirely — CT-AGC-000-1158, CT-AGC-000-1182, CT-FER-1608395. CT-AGC-000-1158 renders the badge "Out of Stock" in its own server HTML while telling Google nothing at all. On CT-FER-1608395: name = "Spring-Extn 1.040ODX 04.000LG .105WIRE D... 1608395" (a literal ellipsis from a 70-character clamp, with the part number appended); description = "Genuine Ferris spring-extn, part 1608395. $13.99 at Clinton Tractor." (the price sits inside the product description, so it goes stale); category = "Ferris", which is the brand, not a category; itemCondition sits on Product; seller is an anonymous Organization; no @id on either node.

After — the candidate todayDev. 12 of 12 sampled pages state availability. The three prod omitted read OutOfStock / OutOfStock / InStock, and on CT-AGC-000-1158 the JSON-LD and the server-rendered badge now say the same thing — both Out of Stock. On CT-FER-1608395: name = "Spring-Extn 1.040ODX 04.000LG .105WIRE D" (no ellipsis, no appended part number); description = "Genuine Ferris spring-extn, part 1608395." with the price gone; category absent rather than wrong; itemCondition moved onto the Offer; seller carries @id .../#org and the Product carries @id .../#product, so Google resolves one seller entity instead of an anonymous one.

Before — production todayprod {"numberOfItems":40,"entries":40,"priced":40,"pricesVisibleInHtml":18,"entriesWithImage":0} — Google is told 40 prices and can find only 18 of them anywhere in the page's own HTML (18 is exactly the eager-render budget; the other 22 cards ship a price-less placeholder). Not one of the 40 entries carries an image. Marked-up content that is not visible on the page is a Google structured-data policy violation, and it is enforced across a whole site at once, not per URL.

After — the candidate todaydev {"numberOfItems":40,"entries":40,"priced":40,"pricesVisibleInHtml":40,"entriesWithImage":40} — all 40 marked-up prices appear in the page's non-script HTML, and all 40 entries carry an image.

Before — production todayprod: 516,737 bytes, 64 /parts/ links for 16 distinct parts — every part's link sent four times, because the whole bill-of-materials subtree was rendered twice (once per breakpoint) and each row stacked a second copy of its part-number link.

After — the candidate todaydev: 360,590 bytes (-30.2%), 16 /parts/ links for the same 16 distinct parts. The unique link count is identical on both sides, so no link was lost — only the duplicates. The win scales with how many rows the diagram has; this is a 16-row page.

Before — production todayorigin/main (what production is built from) answers: REJECT: International addresses are not supported. We currently ship to US only. A US street named after a country fails the same way — '456 Mexico St, Springfield, IL 62701' is also rejected. Typing 'NM' works; pasting the full address does not.

After — the candidate todayorigin/dev answers: OK state=NM. '456 Mexico St, Springfield, IL 62701' -> OK state=IL. A genuine international address is still refused: 'Calle Reforma 100, Mexico City, DF 01000' -> REJECT: International addresses are not supported.

Before — production todayProduction's shipped bundle: replace(/\s+/g," ");if(t=s,[/\b(?:canada|uk|united — the country test is the FIRST statement of the address parser, so it fires before any parsing runs and 'New Mexico' matches on the word 'mexico'.

After — the candidate todayDev's shipped bundle: ngs:s})}(t,i,a);return l?l:[/\b(?:canada|uk|united — the same country test now runs only after the parsing strategies returned nothing. Checked that the dev fetch stayed on crop-dev.app (url_effective=https://crop-dev.app/checkout/shipping, http=200), not a Vercel login page.

Before — production todayorigin/main: 0 — the Express Checkout route makes no price check at all. The live payment-service was last deployed 2026-08-14 from main@be865716, so that is what production runs today: the browser's own unitPrice goes to Stripe unchecked, while the hosted checkout page refuses the identical cart.

After — the candidate todayorigin/dev: 2 references, the same guard the hosted page uses. The dev payment-service was deployed 2026-08-18 from dev@d626f353, which contains the fix (verified with git merge-base --is-ancestor). NOT probed at runtime on purpose: reproducing the before would mean writing a tampered cart and calling POST /payment-intent, which on production creates a real live-mode PaymentIntent. Deliberately not done.

Before — production todayorigin/main: 0. No test anywhere in the payment service reads what orderRepo.create is called with — every webhook suite asserted only that it was called. Tax, shipping, discount, total, currency and per-line unit prices could all be rewritten on every paid order with the build staying green.

After — the candidate todayorigin/dev: 1 suite, 7 cases, 17 literal expect( in the file (the PR reports 21 assertion calls when bun runs it), covering both order-writing paths — the hosted Checkout page and Express Checkout. I did not execute the suite in this pass; it needs a fresh worktree and a full bun install, so this row measures the code that is there, not a green run.

Before — production todayorigin/main line 188: cost: Number.parseFloat(total.MonetaryValue ?? '0') — an unpriced lane becomes exactly 0.00 and is offered to the customer as a real, selectable free option, with the carrier's actual bill left with us. Production's delivery-service was deployed 2026-08-14 from main@be865716, so this is live today.

After — the candidate todayorigin/dev line 178: Number.parseFloat(total.MonetaryValue ?? '') and a drop-with-warning when the value is not a finite number above zero; if every lane drops, the quote fails instead of going free. The dev delivery-service was deployed 2026-08-18 from dev@38352042, which IS the #624 merge commit. The symptom itself cannot be provoked from outside — only UPS decides when it answers without a charge block — so the before was not reproduced live, and 9 new tests (6 of them red before the fix) are what the guarantee rests on.

Before — production todayProduction returns 5 options in 1.1s: Clinton Tractor In-Store Pickup $0, Clinton Tractor FREE shipping $0, UPS Ground $14.02, UPS 2nd Day Air $33.57, UPS Next Day Air $53.93.

After — the candidate todayDev returns the identical 5 options at identical prices in 1.5s. This is the guard against over-correction: our own two intentional $0.00 lanes (pickup and free shipping) survive untouched, because the new check lives inside the UPS provider only, and every UPS lane still comes back priced.

Before — production todayProduction answers ready=true gitSha=be865716b8f668d3245e4595b82d3377cd1e5133 — it names its own build, and that commit is origin/main HEAD, dated 2026-08-14.

After — the candidate todayDev answers ready=true gitSha=unknown. The dev deploy workflow never passes the GIT_SHA build argument (only delivery-deploy.yml does, at line 103), so the dev service cannot identify itself and its build identity has to be taken from the GitHub Actions deploy record instead. Worth fixing: a promote-day check against dev cannot self-verify what it just tested.