← Back to Oven Command
FUDR-HARLEYS-DEEPSCAN-2026-10-22.md

# FUDR × Harley’s — Product, UX & Integration Deep-Scan

**ASK-25 · 22 October 2026 · Owner review required**

Read-only evidence captured from approximately 14:19 IST; publication prepared 14:26 IST. Scan scope and gaps are stated below.

**Verdict: useful customer-commerce foundation, with configuration defects to resolve before launch sign-off. Integration readiness and end-to-end customer journeys are not yet proven.** This readout delivers authenticated HTTP, application-source, catalogue and outlet-API evidence. It is not a completed visual or transactional acceptance test.

The strongest confirmed findings are an invalid configured base outlet, a Bangalore/Mumbai city mapping collision, copied First Coffee configuration, inconsistent rewards eligibility wording, and large promotional assets. Fix and verify those before treating the demo as operationally ready. Keep the existing Central ODS hold and require a supported FUDR integration contract before building synchronization.

## 1. Scope, access and evidence limits

- Target: [Harley’s FUDR storefront](https://harleys.fudr.in/). Supplied account: `harley_demo`; password redacted as `fudr@***`.
- The root returned HTTP 401 with `WWW-Authenticate: Basic realm="Client Area"`. The supplied credentials successfully returned HTTP 200. This is a site-access gate, not evidence of merchant privileges or customer login.
- Requests were restricted to application pages, referenced static assets and source-defined read endpoints. No orders, carts, menu items, settings, customer records, OTPs, payments, coupons or stock states were created or changed. No offensive tests, fuzzing or vulnerability scan occurred.
- Four requested entry paths (`/login`, `/admin`, `/merchant`, `/dashboard`) returned the same application shell structure and boot configuration. HTTP 200 on these paths does **not** establish that an admin console exists there.
- A browser launch failed in the local runtime. Computer Use then rejected access to Google Chrome for Testing with “Computer Use was not approved to use Google Chrome for Testing.” No live 390px or 1440px screenshots, rendered tap measurements, browser network trace, LCP, CLS or INP were obtained. Asset images were inspected separately; they are not page screenshots.
- Customer OTP login, checkout, order tracking against an actual order, merchant permissions and write behavior remain unverified. The demo credentials must not be described as customer or merchant authentication.
- Evidence classes throughout: **Observed** = HTTP response or inspected asset; **Source/config** = delivered code or configuration, not proof of execution; **Local requirement** = project document; **Proposed** = recommendation; **Unverified** = unavailable evidence.

## 2. Prioritized findings and closure evidence

Priority is proposed: P1 before release/integration sign-off; P2 planned improvement. Owners are proposed roles, not assigned people.

| ID / priority | Evidence and finding | Business consequence | Proposed owner / next action | Required closure evidence |
|---|---|---|---|---|
| F01 · P1 | Config `baseOutletId` ends `…94b43fd6`. Its source-defined restaurant-detail read returns 400 `Invalid restaurant id`, including with the correct `depth=all`. JP Nagar returns 200 as a control. [E02/E04] | Default menu/outlet resolution may fail or fall back incorrectly; actual UI path remains unverified. | FUDR implementation lead: resolve the intended default outlet and reference lifecycle. | Valid referenced outlet plus fresh-session homepage/menu evidence on desktop and mobile. |
| F02 · P1 | `brandCities` assigns the Mumbai city ID to both Mumbai.png and Bangalore.png. The cities API supplies a different Bangalore ID. [E02/E03] | Missing/wrong imagery or city association; click routing impact depends on component logic and is not claimed as observed. | Digital catalogue owner: use one canonical city ID per city. | Unique IDs; each tile label, image and destination verified against six returned cities. |
| F03 · P1 | Resource copy says “Choose Your FC Spot”; generic `appLinks` target First Coffee; onboarding and footer assets reference First Coffee, with additional shared assets under another brand. Download nudges are configured false, so visibility is not established. [E02] | Brand confusion and potential misdirection if those components are enabled. Shared generic icons alone are not proof of a defect. | Brand/digital owner with FUDR: audit every reachable content variant and link. | Harley’s-specific copy and destinations in active flows; no unrelated brand promotion; retained shared assets explicitly accepted. |
| F04 · P1 | Rewards configuration uses membership minimum net order value 999; FAQ says ₹1,000 or more. [E02] | Eligibility disputes and staff explanations that disagree with the rule. | Loyalty commercial owner: choose the exact threshold and amount basis, update copy. | Approved boundary cases at ₹998/₹999/₹1,000, discounts and tax handling in a vendor sandbox; identical customer/staff wording. |
| F05 · P1 verification | Top-level `onlineOrder=false`, `appOrder=true`; brand `activeModules` includes `onlineOrder`. 17 outlets are ordering-listed, yet Udyod Vihar and Palladium Mall have config `mode=READ`. [E02/E03] | Multiple state layers can mislead release decisions. This may be intentional, not a proven ordering bug. | FUDR product owner: document effective web/app/outlet/service-state precedence. | An outlet×channel×service truth table, showing browse-only, orderable, closed, paused and stopped states in the UI. |
| F06 · P1 integration gate | Local T3-0 is held; no inspected artifact proves FUDR–Rista/ODS/OneOps synchronization. NPL and People contracts inspected are drafts. [E07–E09] | Overselling, missed launches or duplicate revenue reporting if assumed integrated. | HOP architect + FUDR vendor owner: sign identifiers, API semantics and reconciliation ownership. | Vendor-supported sandbox contract and the acceptance pack in §8. |
| F07 · P2 | Primary hero: 3,480,654 bytes; mobile secondary PNG: 1,279,672 bytes; secondary desktop SVG: 1,210,424 bytes. [E05] | Avoidable download cost and likely mobile performance pressure; no measured LCP regression is claimed. | Web performance owner: responsive formats, right-sized images, loading priority. | Proposed ≤250 KB mobile hero budget where quality permits, and measured field/pilot performance after optimization. |
| F08 · P1 accessibility verification | Delivered viewport disables zoom; scripts suppress iOS gestures. About-page CSS specifies `#aaa9a9` text on white (~2.34:1 by calculation). [E01/E02] | Low-vision users may struggle to read; actual device override behavior remains untested. | UX/frontend owner: allow zoom and darken body text. | 200% zoom without lost controls; proposed ≥4.5:1 body contrast; keyboard and mobile checks. |

## 3. Application architecture and authentication

| Layer | Evidence-backed assessment | Limit |
|---|---|---|
| Edge and delivery | Cloudflare response headers, HTTPS/HSTS, no-store HTML. Separate `assets.fudr.in` media host. | Origin hosting, backend language, database, deployment topology and uptime not established. |
| Frontend | React/ReactDOM 16.14.0 strings in delivered vendor code; Webpack JSONP and lazy chunks; Redux-style state and Axios interceptors in code. | Version strings describe delivered libraries; no security assessment was performed. |
| Bootstrap | Empty root shell plus `window.__FUDR_BOOT__` brand/modules/resources; web surface; `pageGraph` null in root bootstrap; site chunk supplies route/config machinery. | Not evidence of fully server-rendered product content. |
| API | Runtime `API_URL=https://api.fudr.in`; common client base `/restaurant-service`; source-defined REST reads with JSON/HAL responses. | HAL response format does not prove Spring or any specific backend framework. |
| Tenant/outlet model | Subdomain → brand `harleys`; brand UUID, city UUID, restaurant UUID and restaurant/scan codes; outlet config and service types. | These identifiers are not Rista `branch_code` or OneOps outlet IDs. A crosswalk is required. |
| Site gate | HTTP Basic challenge; successful supplied login. | No merchant-role assertion. Keep separate from customer auth. |
| Customer auth | Source includes phone/OTP flow, Bearer authorization, token refresh and localStorage `AuthData`/`GuestLoginData`. Config allows guest browsing and `protected-only` access. | No OTP sent, guest created or token session exercised. Retention, permission boundaries and refresh reliability were not tested. |
| Payments | HTML loads Cashfree SDK; runtime also contains payment-provider configuration. JP Nagar config is prepayment. | SDK inclusion is not a successful integration or settlement proof. No payment initiated. |
| App/PWA | Service-worker registration, manifest handling and React Native WebView bridge exist in delivered source. | Offline correctness, installability and native-app parity unverified. |
| Merchant backend | Client copy references `business.fudr.in`; supplied root-path checks exposed the web shell. | Merchant login, roles, menu authoring, availability controls, refunds, reports and audit trails require a verified portal/read-only account. Not inferred from client feature flags. |

### API evidence: executed reads versus references

Base URL for the following paths is `https://api.fudr.in/restaurant-service`. No demo Basic credential was forwarded to this separate API host.

| Endpoint | Scan treatment | Meaning |
|---|---|---|
| `GET /brands/cities/harleys` | Executed, 200 | Six cities. |
| `GET /brands/harleys/outletDetails?page=1&size=100&appOrderingStatus=ACTIVE` | Executed, 200; one page, totalElements=17 | Ordering-listed outlet metadata. |
| `GET /restaurants/{id}?depth=all` | Executed for configured base and one valid outlet | Base invalid; JP Nagar metadata, service types and hours available. |
| `GET /restaurants/scan/{selfPickupScanCode}?includeMenu=true&subDomain=harleys` | Executed for JP Nagar, 200 | Read-only pickup catalogue sample. |
| `GET/POST /appStartup` | Source reference; root bootstrap inspected | Tenant initialization, not a mutation workflow. No POST needed by this scan. |
| `POST /orders/cart`, `/orders/cart/v2` | Source reference only; not called | Cart has server API involvement; do not assume Add is local-only. |
| `/customizations/groups`, `/menus/variations` | Groups: source only. Variations: one JP Nagar cake read executed, 200. | Size, price and promotional add-ons sampled; no selection/cart mutation. |
| `/orders/current/counts`, order/account routes | Source references only | Tracking/history capability; no customer orders queried. |
| `/brandGuests/refreshToken`, `/guests/refreshToken` | Source references only | Refresh mechanism; no customer session exercised. |

This is a source/API map, not an intercepted browser waterfall. Production webhook support, quotas, write permissions and POS handoff contracts were not available.

## 4. Module-by-module inventory

| Module | Evidence-backed inventory | Completion boundary |
|---|---|---|
| Storefront / brand pages | Configured hero banners, selected-outlet bar, category grid and city tiles; source routes for About, Stores, Franchise, Enquiry and Work With Us. Mint `#97DDDE`, cream and serif brand styling. | Content/config observed; route rendering and forms not exercised. No enquiry submitted. |
| Digital menu / catalogue | JP Nagar pickup menu obtained from a source-defined read endpoint. Category and item summary follows below. Versioned menu/category/item components and modifier endpoints exist in source. | One outlet/service sample; not a whole-estate SKU master, POS stock audit or menu write test. |
| Ordering / cart | Config displays delivery (`DL`) and pickup (`SP`), while applicable modes also contain dine-in (`DI`). JP Nagar detail returns pickup service and a Self Pick-up scan code. Header points to `/order/cart`. | Delivery reach, taxes, fees, allergens, customization validity and final price reconciliation require rendered/sandbox checks. No cart request or order created. |
| Rewards | Active reward program with Victorian, Royal and Majesty tiers, configured earn values 5/10/20 with percentage unit and redeem caps 50/75/100. | These are configuration values, not validated entitlement, profitability or settlement outcomes. Threshold mismatch is F04. |
| Wallet | Top-level wallet module inactive; generic wallet copy/routes remain in source. | Do not count wallet as enabled merely because code exists. Balance/recharge untested. |
| Coupons / offers | Coupon, offer, reward and deal routes, terms templates and offer lookup functions exist. Config says coupons are not categorically excluded from ordering. | Eligibility, stacking, expiry and redemption untested; no coupon claimed. |
| Outlets / branches | 17 ordering-listed records across six cities, with UUIDs, display names, city IDs, order status and config. | Not a claim about total operational outlets, opening readiness or actual live service availability. |
| Hours / availability | JP Nagar has seven workhour records, each 08:00–00:00, and pickup `isPaused=false`, `isStopped=false`. | Local-time/midnight semantics, holiday overrides and observed customer state unverified. Other outlets’ hours were not audited. |
| Tracking / history | Source includes order lifecycle/status handling and order/history routes. Account navigation labels Order History but links to `view=point-history`. | Verify whether the destination mixes points and orders; label alone is not proof of wrong behavior. No real customer record accessed. |
| Admin / merchant | No authenticated merchant console established. | Inventory outstanding: multi-outlet permissions, catalogue publication, sold-out toggles, reconciliation reports, audit history and role separation. |

### JP Nagar pickup catalogue — observed sample

The read endpoint returned **118 distinct menu item IDs across 57 sections: 18 nonempty and 39 empty**. There are 108 enabled and 10 disabled items; none are hidden in this response. All three Fresh Breads items are disabled. Section enable flags are true even for empty sections; whether the UI suppresses them is unverified.

| Nonempty section (API label) | Item records |
|---|---:|
| Harley's Festive Specials | 15 |
| Sweet Assortments | 8 |
| Favourite Combinations | 6 |
| Signature Medovik | 13 |
| Chessecake Pastries | 6 |
| Celebration Medovik Cakes | 13 |
| Celebration Cheesecakes | 6 |
| French Macarons | 10 |
| Mexican Tres Leches | 6 |
| Chef's Table | 1 |
| Bar Cakes & Muffins | 6 |
| Fresh Breads | 3 |
| Classic Croissants | 1 |
| Cake Shake Indulgence | 5 |
| Chocolate Frappes | 5 |
| Hot Chocolate | 3 |
| Iced Coffee | 5 |
| Hot Coffee | 6 |

117 of 118 items have media and 111 have descriptions. Choco Mocha Cold Coffee has no media entry. The section label “Chessecake Pastries” needs copy correction. These are catalogue-quality findings; the actual fallback image and rendered navigation remain unverified.

Nineteen customizable items use default variations. Their absent top-level price is **not a missing-price defect**: each has `defaultVariation.price`. Across top-level/default prices the sample spans ₹80–₹1,450, before checkout taxes/charges; this is not the full size-variant range. A separately retrieved London Viral Whipped Caramel Medovik Cake has 600 gm at ₹1,275 and 1 kg at ₹2,100, vegetarian metadata and two zero-price promotional add-ons. Do not assume free-add-on eligibility from price alone.

`ownerParentId` references exist (for example `harleys-diwalisplgifthamper-01`), but no verified Rista SKU crosswalk was supplied. An enabled item flag is not physical stock quantity or evidence of OneOps synchronization. Catalogue acceptance should check images/descriptions, spelling, per-size price/tax disclosure, allergen/ingredient presentation and correct disabled/empty behavior across selected pilot outlets.

### Ordering-listed outlet footprint

| City | Returned count | Display names |
|---|---:|---|
| Bangalore | 4 | JP Nagar; Kalyan Nagar; Mall of Asia; Prestige Tech Park |
| Hyderabad | 6 | Kapil Towers; Nanakramguda; Sainikpuri; TSPA Junction; AMB Mall; Odeon Mall |
| Mumbai | 3 | BSE; Jio World; Palladium Mall |
| Pune | 2 | Balewadi; MOM |
| Gurugram | 1 | Udyod Vihar (API spelling) |
| Vijayawada | 1 | Sentini Mall |

## 5. UI/UX review: source and asset evidence, with visual gaps

The sampled product photography and mint packaging convey a coherent premium bakery identity. The first banner embeds its caption in the image. The secondary mobile artwork asks users to “Tap to open the box”; that is an engagement cue, not an explicit purchasing action. Retain the brand treatment while making outlet, fulfillment mode, product price and the next ordering action clear in live layouts.

| Dimension | 390px mobile assessment | 1440px desktop assessment | Required verification |
|---|---|---|---|
| Visual hierarchy | Source orders primary marketing before selected outlet/category content. Risk: browse/order context sits below promotion. Actual fold unknown. | Brand imagery is strong; ordering prominence relative to the hero is unknown. | Capture initial fold, selected outlet and primary CTA at both exact widths. |
| Navigation | Configured Home, Cart and Account with profile/rewards/support sublinks; guest browsing is supported in config. | Account dropdown and category subnavigation are defined. | Back navigation, selected-city persistence, drawer/modal focus and route consistency. |
| Images | Mobile secondary source is 2987×1920 PNG at 1.28 MB; visible source text may become small when scaled. | Primary source is 2000×1000 PNG at 3.48 MB; white text over a light photograph needs rendered contrast review. | Responsive source choice, crop, alt text, lazy loading and layout stability. |
| Tap targets | Not measured. “Tap to open” text is baked into artwork; actual clickable element and accessible name unknown. | Keyboard focus and pointer target behavior not measured. | Proposed 44px primary touch target budget; keyboard activation and visible focus. |
| Readability | Zoom restriction is confirmed in delivered HTML/scripts; About body CSS has low calculated contrast. | Same source concern; fixed negative margins in About CSS create a layout risk, not a measured overflow defect. | 200% zoom, text reflow and no horizontal overflow at both widths. |
| Empty/error states | Source has unavailable-item copy and generic empty-state assets. Base-outlet error creates a concrete case to test. | Same requirement. | No-outlets, no-results, sold-out, off-hours, invalid outlet and timeout states with a useful recovery action. |
| Customer friction | Signup config requests name, email and DOB; no evidence these are all required before guest browsing. | Same source config. | Keep optional profile enrichment distinguishable from checkout necessities; validate actual consent and form sequence. |
| Staff journey | Merchant access unavailable. | Merchant access unavailable. | Walk one outlet manager through observing order status and availability, without saving changes; record role scope and audit visibility. |

## 6. Performance measurements and what they mean

Single-environment, single-pass HTTP observations on 22 October 2026; no throttling or browser execution. These are elapsed request times, not TTFB, render times, field percentiles or SLA measurements. OS/network/CDN cache effects are uncontrolled.

| Resource | Observed result | Interpretation |
|---|---|---|
| Unauthenticated root | 401; curl total ~0.364 s | Gate behavior. |
| Authenticated root | 200; ~0.360 s; 115,434 decoded bytes | Fast shell response in this sample; root is not rendered content. |
| Vendor JS + main JS | 1,038,636 + 556,037 decoded bytes, before lazy chunks | At least ~1.59 MB of these two script bodies; compressed wire bytes and execution cost not measured. |
| Cities / outlet listing | 200; ~0.319 / ~0.172 s | Point samples only. |
| Primary hero PNG | 200; 3,480,654 bytes; ~0.781 s in this run | Large asset; prioritize format/size improvement. |
| Mobile secondary PNG | 200; 1,279,672 bytes; ~0.099 s | Fast local fetch does not remove mobile bandwidth cost. |
| Desktop secondary SVG | 200; 1,210,424 bytes; ~0.063 s | SVG extension does not guarantee a small payload. |

Proposed performance acceptance: repeat at 390px and 1440px with cold/warm cache, explicit mobile network/CPU settings and three runs per condition; capture LCP/CLS/INP where applicable, total transferred bytes, errors and time to usable menu. Proposed pilot targets: LCP ≤2.5 s, CLS ≤0.1, INP ≤200 ms at p75 after sufficient real-user samples. These are proposed targets, not achieved metrics.

## 7. Integration architecture: current evidence and proposed design

**Current verified relationship:** FUDR web client reads FUDR API and asset hosts. No inspected response or local contract proves a live FUDR connection to Rista, Central ODS, OneOps or HOP. Absence of evidence is not proof that no vendor-side POS integration exists.

**Local requirements:** T3-0 explicitly says HOLD BUILD; Central ODS owns Rista/Odoo ingestion, retries, archives and normalization. OneOps/HOP consume its canonical read views and must not duplicate direct Rista polling. The documented outlet-status feed names Swiggy, Zomato and Ownly, not FUDR. Vendor 403/field-shape gaps are reported by the intake document, not freshly retested here.

| Flow | Proposed source of truth and contract | Failure handling / audit | Management evidence |
|---|---|---|---|
| Rista → Central ODS → HOP/OneOps | Preserve planned ingestion ownership; `branch_code` and canonical SKU keys. | Source event IDs, ingestion timestamps, replay/deduplication, quarantined unknown mappings. | Reconciled counts/totals and freshness by outlet, source and business date. |
| FUDR ↔ canonical identity | Versioned map of brand, restaurant UUID/code, city, scan/service context and item/variant IDs to branch/SKU. | Unique mapping constraints, effective dates, steward and unresolved queue. | Pilot coverage 100%; no orphan outlet/SKU publication. |
| OneOps sold-out intent → supported FUDR adapter | Separate command authority from ODS observation. Agree who can change stock availability, scope, reason and expiry. | Desired vs observed state, source/version, correlation ID, idempotency, retry/backoff, acknowledgement and rollback. Never call undocumented client endpoints a supported integration. | Unacknowledged changes, stale states, oversell exceptions and reconciliation lag. |
| NPL T1-10 → approved menu publication | Approved SKU, recipe/compliance, price/media, outlet scope, crew/cold-chain readiness and publish/withdraw windows. | Preview, versioned release, effective time, acknowledgement and controlled rollback. Failed outlet publication remains open. | Launch readiness versus actual customer-visible availability; margin, sell-through and waste from labelled sources. |
| Outlet master → public hours | Explicit timezone, weekly trading calendar, holidays, temporary closures and channel overrides. | Manager-owned exceptions and audit trail; distinguish closed, paused, stockout and stale. | Hours mismatch and unresolved closure exceptions. |
| T1-11 staff presence → readiness signal | Staff rostering/presence can inform a readiness warning. It is not authoritative public opening hours. | No automatic public closure solely because a staff check-in is missing. | Staffing gap and accountable outlet response. |
| FUDR order facts → ODS | Agree order ID and POS linkage, status lifecycle, tax/discount/refund fields and channel attribution. | Prevent double counting a FUDR order also recorded in Rista; handle delayed refunds and reordered events. | Gross/net sales, refunds, settlements and unresolved differences by outlet/day. |

Proposed logical paths:

```text
Rista / Odoo ──> Central ODS (planned; HOLD) ──> HOP / OneOps views
FUDR order facts ──> approved ingestion + POS deduplication ──> ODS
NPL approvals / OneOps availability intent
  └──> separately approved vendor adapter ──> FUDR
         └── acknowledgement + observed-state reconciliation ──> HOP exceptions
Outlet master trading hours ──> approved publication adapter
T1-11 staff presence ──> readiness warnings (not direct public-hours authority)
```

A 15-minute analytical ingestion design must not silently become the operational stockout SLA. Decide whether customer availability needs a separate supported event/command path. The NPL and Presence contracts also expose a BIGINT outlet ID versus text `branch_code` mismatch; resolve identity before synchronization.

## 8. Delivery plan and measurable acceptance

These are proposals for owner discussion, not authorization to modify FUDR.

| Sequence | Work / proposed accountable role | Acceptance evidence |
|---|---|---|
| 1 — Configuration cleanup | Digital product owner + FUDR implementation lead; F01–F05 | Valid default outlet, unique city map, clean brand content, agreed rewards rule and documented effective availability states. |
| 2 — Complete read-only review | UX lead + merchant operations owner | 390px/1440px screenshots, rendered navigation/error/tap/focus checks and merchant read-only role walkthrough. No customer mutation required. |
| 3 — Integration contract | HOP architect + ODS owner + vendor owner | Signed ID crosswalk, documented API/webhook support, rate limits, authentication, ownership, data retention and event semantics; preserve T3-0 hold until released through its own gate. |
| 4 — Controlled sandbox pilot | Integration owner + selected outlet manager | Duplicate/reordered events safe; one stockout/restore acknowledged and observed; LTO appears/disappears at correct outlet/time; timeout enters an owned queue; hours exceptions reconcile. These write tests were not performed here. |
| 5 — Commercial verification | Finance + digital commerce owner | No duplicate FUDR/Rista revenue; sampled taxes/discounts/refunds/settlements reconcile; conversion, repeat rate, contribution margin and waste tracked with source labels. |
| 6 — Scale gate | Owner + operations/technology leads | Expand only after agreed service/exception performance and training evidence. The saved 1,000+ outlet ambition is a target for the two years from 8 October 2026, not a forecast or this demo’s verified capacity. |

Do not declare success from an HTTP acknowledgement alone. Every operational control needs an accountable owner, desired state, observed result, timestamp, exception path and closure evidence. Avoid rebuilding FUDR’s commerce engine in HOP unless a measured capability/cost gap justifies it; first assess a supported integration with clear authority.

## 9. Owner review — decisions pending, not signed off

Suggested 15-minute review: five minutes on F01–F05 and their business impact; five on the commerce/ODS/OneOps authority boundary; five on the evidence needed to close the remaining scan.

- [ ] Confirm FUDR’s intended role: customer commerce, digital menu, loyalty, merchant operations, and which channels are in scope.
- [ ] Name the vendor and internal owners for menu/pricing, stock availability, rewards and trading hours.
- [ ] Accept or change the proposed configuration-first priority; authorize fixes separately through normal controls.
- [ ] Obtain the actual merchant portal/read-only role and a permitted browser session to finish visual review.
- [ ] Agree operational stockout latency and supported integration direction; preserve the ODS hold until its own acceptance gate is satisfied.
- [ ] Approve the sandbox pilot specification before any controlled write tests.

**Owner review status: PENDING.** This readout does not record owner acceptance, a production release approval or integration-build sign-off.

## 10. Evidence register and reproducibility

Captured locally during this dispatch. Private raw API/source evidence stays in `runtime/agy-eval/fudr-deepscan/evidence/`; it is not included in the public/staging readout bundle. `manifest.json` records filenames, sizes and SHA-256 hashes. The readout contains only the findings needed for owner review.

| Evidence ID | Source / local record | Supports |
|---|---|---|
| E01 | Root HTML and headers from `https://harleys.fudr.in/`; authenticated response hash recorded in `sanitized-config-evidence.json` | HTTP Basic gate, bootstrap, viewport, SDK and shell. |
| E02 | `sanitized-config-evidence.json`; delivered `window.__FUDR_BOOT__` examined | Flags, resource copy, city collision, base outlet, rewards boundary. |
| E03 | `cities.json`, `outlets.json`, `http-results.json` | Six cities, 17 ordering-listed records, page metadata and modes. |
| E04 | `base-outlet-all.json`, `jp-outlet.json` | Invalid base reference versus valid outlet control; sample hours/service metadata. |
| E05 | `asset-metrics.json`, `primary-hero.png`, `mobile-secondary.png`, `desktop-secondary.svg` | Download sizes, source image inspection, not rendered page screenshots. |
| E06 | `main-pretty.js`, `site-pretty.js`, referenced JS chunks, `jp-pickup-menu.json`, `jp-menu-inventory-summary.json`, `jp-example-variations.json` | Source architecture, routes, API signatures, catalogue sample. |
| E07 | [Rista Central ODS intake](/admin/oven-command?doc=OUT/INTAKE-RISTA-CENTRAL-ODS-2026-10-22.md), lines 5, 13–19, 33–39, 50, 63 | Build hold, ownership, branch key, planned feeds and reported vendor gaps. |
| E08 | [NPL contract](/admin/oven-command?doc=OUT/CONTRACT-T1-10-NEW-PRODUCT-LAUNCH-MODULE.md), lines 5–7, 29–43, 202–217, 247 | Draft status, launch readiness and deferred ODS metrics. |
| E09 | [People & Presence contract](/admin/oven-command?doc=OUT/CONTRACT-T1-11-CAFE-PEOPLE-PRESENCE-MODULE.md), lines 1–10, 523, 597–606 | Staff-presence scope, ID mismatch and draft status. |

Verification is self-authored for the product scan; a parallel agent inspected local integration contracts and derived catalogue evidence. Neither constitutes independent owner sign-off. Reproduce only the listed reads; do not follow write functions while using this read-only scope.

## 11. Publication and remaining gaps

Markdown and Lagoon HTML are the deliverables for this scan. ASK-25 remains **READOUT DELIVERED — VISUAL/MERCHANT VALIDATION AND OWNER REVIEW PENDING**, rather than an unqualified product acceptance. The requested `sync-oven-command-staging.sh` completed successfully. Both readout files were verified by matching SHA-256 on the staging host and inside its API container. Final publication updates are synchronized again after this record.

The preferred [HOP readout](https://test.hop.harleys.com/admin/oven-command?doc=FUDR-HARLEYS-DEEPSCAN-2026-10-22.html) could not be reached because DNS resolution failed from this environment. The [fallback staging readout](https://skateboard.13.205.205.185.sslip.io/admin/oven-command?doc=FUDR-HARLEYS-DEEPSCAN-2026-10-22.html) returned HTTP 303 to the login page with the document destination preserved. Authenticated owner viewing was not tested. OneOps returned the expected 302 to HOP.

Validation passed for credential redaction in both reports, sticky Lagoon back navigation, HTML parsing, unique anchors, table-of-contents targets and the ASK-25 dashboard/ledger links. Rendered visual QA of the readout itself was unavailable under the same browser limitation. Staging publication followed the explicitly requested sync script; the FUDR application remained read-only.