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. 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.

3. Application architecture and authentication

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.

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

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.

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

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.

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.

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.

Proposed logical paths:

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.

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.

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 Formatted 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 could not be reached because DNS resolution failed from this environment. The fallback staging readout 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 Harley's 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.