Regulatory Compliance Checklist

vercel/commerce

Generated by Inkwell Forge — automated codebase documentation analysis. Based on analysis of 5 screens. Subject matter expert review is recommended before distribution.

May 5, 2026

Regulatory Compliance Checklist

Application: Commerce (Shopify/Next.js Storefront) Document Title: Regulatory Compliance Checklist Date: May 2026 Prepared By: Inkwell Forge — Automated Codebase Documentation Analysis Frameworks Assessed: GDPR · CCPA/CPRA · SOC 2 Type II · PCI-DSS v4.0 · WCAG 2.1 Level AA Control Mapping: ISO/IEC 27001:2022 Annex A · NIST Cybersecurity Framework v2.0

2. Executive Summary

Generated by Inkwell Forge — automated codebase documentation analysis. Subject matter expert review is recommended before distribution.

This checklist assesses five documented screens of the Commerce application — a Next.js 15 / React 19 storefront backed by the Shopify Storefront API — against GDPR, CCPA/CPRA, SOC 2 Type II, PCI-DSS v4.0, and WCAG 2.1 Level AA. The application is a publicly accessible e-commerce storefront presenting product catalog data, collection browsing, search, and static informational pages. No authentication, payment processing, or user account management screens were included in the assessed documentation; those workflows are outside the scope of this document.

The application's strongest compliance posture is in PCI-DSS, where the documented screens contain no payment card data handling, no stored cardholder data, and no direct payment form elements — the architecture delegates payment processing entirely to Shopify, which is itself a PCI-DSS Level 1 certified service provider. The application also demonstrates reasonable foundational security hygiene through its React Server Component architecture, which prevents server-side secrets from leaking to the client bundle. WCAG 2.1 AA posture is Partially Compliant: the root layout correctly sets lang="en" on the <html> element, and several semantic HTML patterns are documented, but multiple accessibility gaps are explicitly acknowledged in the screen documentation, including missing <time> elements, absent landmark labels, and unconfirmed carousel keyboard navigation.

The three highest-risk compliance gaps identified are: (1) Absence of any documented consent management, privacy notice, or cookie banner mechanism — a gap that simultaneously affects GDPR (Articles 6, 7, 13), CCPA/CPRA (§1798.100(b), §1798.120), and SOC 2 (P1.1), making it the single highest-priority cross-framework remediation item; (2) No documented security event monitoring, error tracking, or audit logging at the application layer — the screen documentation explicitly notes the absence of Sentry, Datadog, or equivalent instrumentation calls in every assessed screen, which affects SOC 2 (CC7.1, CC7.2) and GDPR (Art. 32); and (3) An unguarded featuredImage.url access in the Product Detail screen's JSON-LD block that can cause a runtime crash for products without a featured image, representing a documented availability and integrity risk.

GDPR and CCPA/CPRA postures are Partially Compliant at best, with several requirements that Cannot be Assessed from the available documentation (organizational controls, data retention policies, DPA agreements) and others that are clearly not addressed in the documented screens (consent capture, data subject rights mechanisms). SOC 2 posture is Partially Compliant — foundational technical controls are present but monitoring, incident response, and organizational controls are outside the documentation scope. Readers are directed to the framework-specific checklists in Sections 5–9 for the authoritative per-requirement status distributions.

Assessment limitation: This document is based exclusively on per-screen codebase documentation for five screens. It does not reflect live compliance testing, organizational policy review, infrastructure configuration outside the provided PROJECT CONFIG and ROOT LAYOUT blocks, or screens and workflows not included in the assessed documentation. Findings should be validated by qualified legal, security, and accessibility professionals before use in formal audit submissions.

3. Assessment Methodology

Approach: Documentation-based technical control assessment against regulatory requirements. Each requirement is evaluated against evidence present in the provided screen documentation, PROJECT MANIFEST (package.json), PROJECT CONFIG (next.config.ts, postcss.config.mjs, tsconfig.json), ROOT LAYOUT (app/layout.tsx), and MIDDLEWARE (not provided for this assessment).

Frameworks: GDPR (EU) 2016/679 · CCPA Cal. Civ. Code §1798.100 et seq. / CPRA · SOC 2 Type II (AICPA Trust Services Criteria 2017) · PCI-DSS v4.0 · WCAG 2.1 Level AA

Control Mapping: ISO/IEC 27001:2022 Annex A controls for security compliance structure; NIST Cybersecurity Framework v2.0 for control mapping.

Scope: This checklist covers 5 screen(s) of the Commerce application:

Screen Route
Home /
Item Detail /[page]
Product Detail /product/[handle]
Search /search
Search Detail /search/[collection]

Screens, features, and components not included in the assessed documentation are outside the scope of this document. This explicitly excludes: checkout flow, cart management, user account/authentication screens, admin interfaces, and any server-side infrastructure configuration not present in the provided PROJECT CONFIG block.

MIDDLEWARE block: Not provided. Findings that depend on middleware-level controls (authentication enforcement, rate limiting, CORS, security headers) are scoped to "not visible in the per-screen bundle" rather than "absent from the application."

Compliance status definitions:

Status Definition Symbol
Compliant Documented controls fully satisfy the requirement ✅
Partially Compliant Some controls present but gaps exist ⚠️
Non-Compliant Required controls not documented or clearly missing ❌
Not Applicable Requirement does not apply to this application N/A
Cannot Assess Insufficient documentation to determine compliance ❓

4. Applicability Matrix

Framework Applicable Rationale
GDPR Yes The application is a public-facing e-commerce storefront. Even without explicit EU user targeting, the Shopify Storefront API integration processes browsing behavior data; product pages set Open Graph metadata and JSON-LD structured data; and the /[page] route is documented as serving Privacy Policy and Terms of Service pages, indicating the operator is aware of data protection obligations. If the store ships to or targets EU residents, GDPR applies.
CCPA/CPRA Yes The application is a public-facing commercial storefront. If the operator meets any CCPA threshold (annual gross revenue >$25M, data on >100,000 consumers, or >50% revenue from selling personal information) and serves California residents, CCPA/CPRA applies. The presence of a Privacy Policy page route (/privacy-policy via /[page]) suggests the operator acknowledges consumer privacy obligations.
SOC 2 Yes The application is a SaaS-pattern web application handling customer browsing data, integrated with Shopify (a third-party data processor). If the operator provides the storefront as a service or handles customer data on behalf of merchants, SOC 2 Type II is relevant for demonstrating security, availability, and confidentiality controls to business partners.
PCI-DSS Likely The documented screens contain no payment card data handling. However, the application is an e-commerce storefront that presumably leads to a checkout flow. If any screen in the undocumented checkout flow touches cardholder data — even indirectly — PCI-DSS applies. The Shopify integration (cdn.shopify.com image patterns, Storefront API) is consistent with a Shopify-hosted checkout, which would place the operator in SAQ A scope at minimum.
WCAG 2.1 AA Yes The application is a public-facing web application. WCAG 2.1 AA compliance is a legal requirement in many jurisdictions (ADA Title III in the US, EN 301 549 in the EU, AODA in Canada) and is a baseline accessibility standard for commercial web properties.

5. GDPR Compliance Checklist

GDPR posture: Partially Compliant — The application demonstrates some privacy-aware design (server-side rendering that avoids client-side data leakage, no unnecessary data collection on public pages, documented Privacy Policy page route). However, critical gaps exist in consent management, data subject rights mechanisms, and organizational controls that cannot be assessed from the available documentation.

5.1 Principles (Article 5)

# Principle Requirement Status Evidence Gap Remediation
GD-001 Lawfulness Processing has valid legal basis (Art. 6) ❓ The /[page] route is documented as serving a Privacy Policy page, suggesting the operator has considered legal basis. No consent mechanism, cookie banner, or legal basis documentation is present in any of the 5 assessed screens. The application makes Shopify Storefront API calls server-side on every page load. No documented legal basis for any data processing activity (browsing data, server-side API calls, CDN delivery via Vercel). [Not documented — WHO: DPO or legal counsel; WHAT: What is the documented legal basis (Art. 6(1)(a)–(f)) for each category of data processing performed by this application, including server-side Shopify API calls, Vercel CDN logging, and any analytics? WHERE: Insert in GD-001 Evidence column and cross-reference with GD-008.]
GD-002 Purpose Limitation Data used only for specified purposes ❓ All five screens are read-only product catalog pages. No user data is collected or stored by the documented screens. Server-side Shopify API calls are for product retrieval only. No documented purpose specification for any data processing. Vercel CDN and Shopify may log IP addresses and request metadata; purposes for this processing are not documented. [Not documented — WHO: DPO; WHAT: What purposes are specified in the privacy notice for each data processing activity, and are those purposes documented in a Records of Processing Activities (RoPA)?; WHERE: Insert in GD-002 Evidence column and GD-019.]
GD-003 Data Minimisation Only necessary data collected ⚠️ The five documented screens collect no user-supplied data. No forms, no authentication, no tracking scripts are present in the assessed screen files or ROOT LAYOUT. The package.json (PROJECT MANIFEST) contains no analytics, tracking, or consent-management libraries. Vercel CDN and Shopify Storefront API will process IP addresses and HTTP request headers as a technical necessity. Whether this is minimised to what is strictly necessary is not documented. The WelcomeToast component in ROOT LAYOUT and sonner (toast library) are present — their data handling is not documented. Confirm that no analytics, session recording, or behavioral tracking is added outside the documented screens. Document the minimum data processed by Vercel and Shopify for infrastructure purposes.
GD-004 Accuracy Data kept up to date ⚠️ The /[page] route (Item Detail) renders page.updatedAt from Shopify, indicating content accuracy is maintained via Shopify's admin. Product data on Product Detail and Search screens is fetched live from Shopify Storefront API. No user personal data is stored by the application itself in the documented screens, so accuracy obligations are limited. However, if user accounts or order data exist in undocumented screens, accuracy mechanisms are not assessed. Confirm that no user personal data is stored in application-layer databases outside the Shopify integration. If user accounts exist, document data correction mechanisms.
GD-005 Storage Limitation Data not kept longer than necessary ❓ No data storage by the application is documented in the 5 assessed screens. Next.js Full Route Cache and Vercel CDN caching are mentioned for performance. Cache retention periods for Vercel CDN, Next.js Full Route Cache, and Shopify API response caches are not documented. If server logs are retained by Vercel, retention periods are not specified. [Not documented — WHO: Infrastructure/DevOps lead; WHAT: What are the retention periods for Vercel access logs, Next.js cache entries, and any Shopify webhook or order data? WHERE: Insert in GD-005 Evidence column and GD-019.]
GD-006 Integrity & Confidentiality Appropriate security measures ⚠️ React Server Component architecture prevents server-side secrets (Shopify API tokens) from leaking to the client bundle — documented across all 5 screens. SHOPIFY_STOREFRONT_ACCESS_TOKEN and SHOPIFY_STORE_DOMAIN are documented as server-only environment variables. next.config.ts configures image delivery from cdn.shopify.com over HTTPS only (protocol: "https"). No CSP headers documented in next.config.ts (no headers() export present). No security event monitoring documented in any screen. No MIDDLEWARE block provided — cannot assess middleware-level security headers. Add Content Security Policy headers via next.config.ts headers() export or middleware. Implement application-level error tracking. Verify HTTPS enforcement at the Vercel platform level.
GD-007 Accountability Demonstrate compliance ❓ The /[page] route serves Privacy Policy and Terms of Service pages (documented in Item Detail screen overview). No DPA with Shopify documented. No RoPA documented. No DPIA documented. No data protection officer (DPO) appointment documented. These are organizational controls. (Organizational control — outside documentation scope) Ensure DPA with Shopify is executed, RoPA is maintained, and DPO appointment is assessed for applicability.

5.2 Data Subject Rights (Articles 12–22)

# Right Article Status Evidence Gap Remediation
GD-008 Transparent Information Art. 12–13 ⚠️ The /[page] route is documented as capable of serving a Privacy Policy page (handle privacy-policy). The Item Detail screen overview explicitly lists "Privacy Policy" as a use case. The Footer component (present in Home, Product Detail screens) is documented as containing "legal information." No privacy notice content is visible in the assessed documentation. No consent banner or layered notice mechanism is documented in any screen or ROOT LAYOUT. The ROOT LAYOUT contains no consent management provider. Implement a consent management platform (CMP) or cookie banner. Ensure the Privacy Policy page at /privacy-policy contains all Art. 13 required information. Verify Footer links to the Privacy Policy are present.
GD-009 Right of Access Art. 15 ❓ No user account or data access mechanism is present in the 5 documented screens. No documented mechanism for data subjects to request access to their personal data. This may exist in undocumented screens (e.g., account portal) or via Shopify's customer data tools. [Not documented — WHO: DPO or product owner; WHAT: Is there a documented mechanism (in-app portal, email process, or Shopify customer data export) for data subjects to exercise their Art. 15 right of access? WHERE: Insert in GD-009 Evidence column.] ⚠️ This workflow continues beyond the documented screens. Steps involving account management or customer service screens are not covered in this document. Verify the complete workflow with the development team before treating this as a comprehensive process description.
GD-010 Right to Rectification Art. 16 ❓ No user data editing interface is present in the 5 documented screens. No documented rectification mechanism. [Not documented — WHO: DPO or product owner; WHAT: Is there a mechanism for customers to correct their personal data (e.g., account profile edit, customer service process)? WHERE: Insert in GD-010 Evidence column.] ⚠️ This workflow continues beyond the documented screens.
GD-011 Right to Erasure Art. 17 ❓ No data deletion mechanism is present in the 5 documented screens. No documented erasure mechanism. Shopify provides merchant-facing customer data deletion tools, but application-layer implementation is not documented. [Not documented — WHO: DPO or product owner; WHAT: Is there a documented process for handling erasure requests, including deletion from Shopify customer records, Vercel logs, and any other data stores? WHERE: Insert in GD-011 Evidence column.]
GD-012 Right to Restriction Art. 18 ❓ Not present in the 5 documented screens. No documented restriction mechanism. (Organizational control — outside documentation scope) Document the process for handling restriction requests.
GD-013 Data Portability Art. 20 ❓ Not present in the 5 documented screens. No documented portability mechanism. [Not documented — WHO: DPO; WHAT: Is there a mechanism to export customer data in a machine-readable format (e.g., via Shopify's data export or a custom API endpoint)? WHERE: Insert in GD-013 Evidence column.]
GD-014 Right to Object Art. 21 ❓ Not present in the 5 documented screens. No analytics or profiling is documented. No documented objection mechanism. If no profiling or direct marketing is conducted, this right may have limited applicability. [Not documented — WHO: DPO; WHAT: Does the application conduct any profiling, behavioral analytics, or direct marketing that would trigger Art. 21 objection rights? WHERE: Insert in GD-014 Evidence column.]
GD-015 Automated Decision-Making Art. 22 N/A The 5 documented screens perform no automated decision-making with legal or similarly significant effects. Product recommendations (getProductRecommendations) are algorithmic but do not produce decisions affecting data subjects' legal rights. None identified in documented screens. No action required for documented screens. Reassess if personalization or credit/pricing algorithms are introduced.

5.3 Security & Breach (Articles 32–34)

# Requirement Article Status Evidence Gap Remediation
GD-016 Security of Processing Art. 32 ⚠️ Server Component architecture prevents secret leakage (documented in all 5 screens). HTTPS-only image delivery from cdn.shopify.com documented in next.config.ts. TypeScript strict mode enabled ("strict": true in tsconfig.json) reduces code-level vulnerabilities. dangerouslySetInnerHTML usage in Product Detail screen is documented with a known XSS risk for </script> sequences in JSON-LD. No CSP headers documented in next.config.ts. No MIDDLEWARE block provided — cannot assess middleware-level security controls. No error tracking or security monitoring documented in any of the 5 screen files. Missing: CSP headers, security event monitoring, documented encryption-at-rest policy, documented access control for infrastructure. The dangerouslySetInnerHTML JSON-LD risk is a documented known issue. Implement CSP headers. Replace JSON.stringify in JSON-LD with an HTML-safe serializer. Implement application-level error tracking (e.g., Sentry). Document infrastructure security controls.
GD-017 Breach Notification Art. 33–34 ❓ No breach notification procedure is documented in the assessed screens or configuration files. No documented incident response or breach notification procedure. (Organizational control — outside documentation scope) Establish and document a breach notification procedure meeting the 72-hour supervisory authority notification requirement of Art. 33.

5.4 Data Processing (Articles 25–30, 35)

# Requirement Article Status Evidence Gap Remediation
GD-018 Privacy by Design/Default Art. 25 ⚠️ Strong privacy-by-design signals: all 5 screens are React Server Components that process no user-supplied data; no client-side tracking libraries in package.json; server-side secrets never exposed to client bundle; no unnecessary data collection documented. next.config.ts restricts remote image patterns to cdn.shopify.com only, limiting third-party image loading. No consent-by-default mechanism documented. No documented data minimisation policy. The WelcomeToast component in ROOT LAYOUT has undocumented data handling. Document the privacy-by-design decisions already implemented. Add consent management. Audit WelcomeToast for any data collection.
GD-019 Records of Processing Art. 30 ❓ Not assessable from screen documentation. No RoPA is documented or referenced. (Organizational control — outside documentation scope) Maintain a RoPA covering all processing activities including Shopify Storefront API calls, Vercel CDN logging, and any third-party integrations.
GD-020 DPIA Art. 35 ❓ Not assessable from screen documentation. The application processes publicly available product data only in the documented screens. If the undocumented checkout or account screens process sensitive data at scale, a DPIA may be required. [Not documented — WHO: DPO; WHAT: Has a DPIA been conducted for the full application, including checkout, account management, and any profiling or analytics features? WHERE: Insert in GD-020 Evidence column.]

6. CCPA/CPRA Compliance Checklist

CCPA/CPRA posture: Partially Compliant — The application's documented screens collect no personal information directly. However, the absence of a documented privacy notice, opt-out mechanism, and data subject rights infrastructure represents significant gaps against CCPA/CPRA requirements.

# Requirement Section Status Evidence Gap Remediation
CC-001 Right to Know §1798.100 ⚠️ The /[page] route is documented as capable of serving a Privacy Policy page. No in-application mechanism for consumers to request disclosure of personal information categories, sources, purposes, or third parties is documented in the 5 assessed screens. No documented "Right to Know" request mechanism. No documented disclosure of what personal information is collected (even infrastructure-level data such as IP addresses via Vercel). Implement a consumer rights request mechanism (web form or email process). Ensure the Privacy Policy at /privacy-policy discloses all categories of personal information collected, including infrastructure-level data.
CC-002 Right to Delete §1798.105 ❓ No deletion mechanism is present in the 5 documented screens. No documented deletion request process. [Not documented — WHO: Privacy counsel or product owner; WHAT: Is there a documented process for handling consumer deletion requests, including deletion from Shopify customer records, Vercel logs, and any other data stores? WHERE: Insert in CC-002 Evidence column.]
CC-003 Right to Opt-Out of Sale/Sharing §1798.120 ❌ No "Do Not Sell or Share My Personal Information" link or mechanism is documented in any of the 5 screens, the ROOT LAYOUT, or the Footer component description. The package.json contains no consent management or opt-out library. No opt-out mechanism documented. If the application shares data with Shopify, Vercel, or any analytics provider in a manner that constitutes "sharing" under CPRA, a compliant opt-out mechanism is required. Implement a "Do Not Sell or Share My Personal Information" link in the site footer. Integrate a consent management platform. Assess whether Shopify/Vercel data sharing constitutes "sale" or "sharing" under CPRA.
CC-004 Right to Non-Discrimination §1798.125 ✅ The application is a public storefront with no authentication, tiered access, or pricing differentiation documented in the 5 assessed screens. All visitors receive identical access to product catalog data. None identified in documented screens. No action required for documented screens. Reassess if loyalty programs or personalized pricing are introduced.
CC-005 Right to Correct §1798.106 (CPRA) ❓ No data correction mechanism is present in the 5 documented screens. No documented correction mechanism. [Not documented — WHO: Privacy counsel or product owner; WHAT: Is there a mechanism for consumers to correct inaccurate personal information held by the business? WHERE: Insert in CC-005 Evidence column.] ⚠️ This workflow continues beyond the documented screens.
CC-006 Right to Limit Sensitive PI §1798.121 (CPRA) ❓ No sensitive personal information is collected or processed in the 5 documented screens. If undocumented screens (checkout, account) collect sensitive PI (payment data, precise geolocation, account credentials), a limitation mechanism is required. [Not documented — WHO: Privacy counsel; WHAT: Does the application collect any sensitive personal information as defined by CPRA §1798.121 (e.g., payment card data, precise geolocation, account login credentials)? WHERE: Insert in CC-006 Evidence column.]
CC-007 Privacy Notice §1798.100(b) ⚠️ The /[page] route is documented as serving a Privacy Policy page. The Footer component is documented as containing "legal information." No privacy notice content is visible in the assessed documentation. No "at or before collection" notice mechanism is documented. No consent banner or layered notice is present in ROOT LAYOUT. Ensure the Privacy Policy at /privacy-policy meets CCPA §1798.100(b) disclosure requirements. Implement a notice-at-collection mechanism for any data collected at checkout or account creation.
CC-008 Data Minimization §1798.100(c) (CPRA) ⚠️ The 5 documented screens collect no personal information beyond what is technically necessary for page delivery. No analytics, tracking, or behavioral data collection libraries are present in package.json. Infrastructure-level data (IP addresses, request logs via Vercel) is collected as a technical necessity but is not documented with a minimization rationale. Document the data minimization rationale for all infrastructure-level data collection. Confirm no analytics or tracking is added outside the documented screens.
CC-009 Reasonable Security §1798.150 ⚠️ React Server Component architecture prevents credential leakage. HTTPS-only image delivery documented. TypeScript strict mode reduces code vulnerabilities. No CSP headers documented. No security monitoring documented in screen files. The dangerouslySetInnerHTML JSON-LD risk is a documented known issue in Product Detail screen. No MIDDLEWARE block provided — cannot assess middleware-level security controls. Implement CSP headers. Fix the JSON-LD serialization vulnerability. Implement security monitoring. Conduct a security assessment of the full application.
CC-010 Service Provider Controls §1798.140(ag) ❓ Shopify and Vercel are identified as the primary service providers. Shopify processes product and (in undocumented screens) customer data. Vercel processes all HTTP requests. No documented Data Processing Agreements (DPAs) or service provider contracts with Shopify or Vercel that include CCPA-required contractual provisions. [Not documented — WHO: Legal counsel; WHAT: Are executed DPAs or service provider agreements in place with Shopify and Vercel that include CCPA §1798.140(ag) required provisions (prohibition on selling data, use limitation, etc.)? WHERE: Insert in CC-010 Evidence column.]

7. SOC 2 Compliance Checklist

SOC 2 posture: Partially Compliant — Technical controls visible in the documentation (server-side secret isolation, HTTPS delivery, TypeScript strict mode) support several Trust Services Criteria. However, monitoring, incident response, change management, and all organizational criteria cannot be assessed from screen documentation alone.

# Criterion Category Status Evidence Gap Remediation
SC-001 CC1.1 — Board Oversight Security ❓ Not assessable from screen documentation. Organizational governance controls are outside the scope of codebase documentation. (Organizational control — outside documentation scope) Demonstrate board-level oversight of security policies and risk management.
SC-002 CC5.1 — Logical Access Security ⚠️ All 5 documented screens are publicly accessible with no authentication. This is appropriate for a public storefront. No MIDDLEWARE block provided — cannot assess whether authenticated routes (checkout, account) enforce access controls. Shopify API credentials are documented as server-only environment variables across all 5 screens. Access controls for administrative interfaces, Shopify admin, and Vercel deployment pipeline are not documented. [Not documented — WHO: Security lead; WHAT: What access controls are in place for the Shopify admin, Vercel deployment pipeline, and any internal administrative interfaces? WHERE: Insert in SC-002 Evidence column.]
SC-003 CC5.2 — Authentication Security ❓ No authentication is implemented in the 5 documented screens (all public routes). No authentication library is present in package.json. Authentication mechanisms for any protected routes (checkout, account, admin) are not documented. No MFA, session management, or credential policy is documented. [Not documented — WHO: Security lead or engineering lead; WHAT: What authentication mechanism (e.g., NextAuth, Shopify customer accounts, Clerk) is used for protected routes, and does it enforce MFA for administrative access? WHERE: Insert in SC-003 Evidence column.]
SC-004 CC6.1 — Encryption Security ⚠️ next.config.ts enforces HTTPS-only for remote image patterns (protocol: "https" for cdn.shopify.com). Shopify Storefront API is accessed over HTTPS (inferred from standard Shopify API patterns — verify against lib/shopify implementation). Server-side environment variables (SHOPIFY_STOREFRONT_ACCESS_TOKEN) are documented as never exposed to the client bundle. Encryption at rest for any application-layer data stores is not documented. TLS version and cipher suite configuration are not visible in the provided PROJECT CONFIG. Verify TLS 1.2+ enforcement at the Vercel platform level. Document encryption-at-rest for any data stores.
SC-005 CC6.2 — Transmission Security Security ⚠️ HTTPS-only image delivery from cdn.shopify.com documented in next.config.ts. Shopify Storefront API calls are server-side and use HTTPS (inferred from Shopify API conventions — verify against lib/shopify). No HSTS header configuration documented. No MIDDLEWARE block provided — cannot assess whether HTTP-to-HTTPS redirect is enforced. Verify HSTS headers are configured at the Vercel platform level. Confirm HTTP-to-HTTPS redirect is enforced.
SC-006 CC6.3 — Change Management Security ❓ package.json includes prettier and prettier:check scripts, indicating code formatting standards are enforced. TypeScript strict mode is enabled. No CI/CD pipeline documentation, code review process, deployment approval workflow, or change management procedure is documented. (Organizational control — outside documentation scope) Document the change management process including code review requirements, CI/CD pipeline controls, and deployment approval gates.
SC-007 CC7.1 — Monitoring Security ❌ All 5 screen documentation files explicitly state: "No console.log, console.warn, console.error, error tracking service calls (Sentry, Datadog, etc.), or analytics event calls are present in this screen's component file." The ROOT LAYOUT contains no error tracking provider. The package.json contains no error tracking or monitoring library. No application-level security event monitoring, error tracking, or anomaly detection is documented anywhere in the assessed files. Infrastructure-level monitoring (Vercel analytics, Shopify analytics) may exist but is not documented. Integrate an error tracking service (e.g., Sentry). Implement application-level logging for security-relevant events. Note: the absence of monitoring calls in the 5 screen files does not confirm absence of infrastructure-level monitoring — verify via Vercel dashboard configuration and any instrumentation files not included in this assessment.
SC-008 CC7.2 — Incident Response Security ❓ Not assessable from screen documentation. No incident response plan, escalation procedure, or breach response process is documented. (Organizational control — outside documentation scope) Establish and document an incident response plan.
SC-009 CC8.1 — Risk Assessment Security ❓ Not assessable from screen documentation. The screen documentation does identify several technical risks (unguarded featuredImage.url, dangerouslySetInnerHTML JSON-LD, double getPage invocation) in Known Issues sections — this demonstrates some risk awareness at the development level. No formal risk assessment process is documented. (Organizational control — outside documentation scope) Conduct and document a formal risk assessment covering the full application.
SC-010 A1.1 — Processing Integrity Availability ⚠️ Next.js Full Route Cache and Vercel CDN caching are documented for the Home screen, providing availability resilience. notFound() is consistently implemented across Product Detail, Item Detail, and Search Detail screens for graceful 404 handling. No SLA, uptime commitment, or availability monitoring is documented. The unguarded featuredImage.url access in Product Detail is a documented availability risk (runtime crash). Fix the featuredImage.url null guard (documented Known Issue in Product Detail screen). Document availability SLAs and monitoring.
SC-011 A1.2 — Recovery Availability ❓ Not assessable from screen documentation. No backup, disaster recovery, or business continuity plan is documented. (Organizational control — outside documentation scope) Document recovery time objectives (RTO) and recovery point objectives (RPO), and test recovery procedures.
SC-012 PI1.1 — Data Quality Processing Integrity ⚠️ Product data is fetched live from Shopify Storefront API on each request, ensuring data currency. SEO metadata fallback chains are documented in Item Detail and Search Detail screens (e.g., seo.title → page.title). The updatedAt timestamp is displayed on Item Detail pages. The page.updatedAt malformed date edge case is documented as producing "Invalid Date" output (Item Detail Known Issues). No data validation layer is documented for Shopify API responses. Fix the updatedAt malformed date handling. Implement response validation for Shopify API data.
SC-013 C1.1 — Data Classification Confidentiality ❓ Shopify API credentials are documented as server-only environment variables. No other sensitive data is processed in the 5 documented screens. No formal data classification policy is documented. (Organizational control — outside documentation scope) Establish a data classification policy covering all data types processed by the application.
SC-014 C1.2 — Data Disposal Confidentiality ❓ Not assessable from screen documentation. No data storage is documented in the 5 assessed screens. No data disposal or retention policy is documented. (Organizational control — outside documentation scope) Document data retention and disposal procedures for all data stores, including Vercel logs and Shopify customer data.
SC-015 P1.1 — Privacy Notice Privacy ⚠️ The /[page] route serves a Privacy Policy page. The Footer component is documented as containing legal information links. No privacy notice content is visible. No consent management mechanism is documented. The ROOT LAYOUT contains no consent management provider. Ensure the Privacy Policy page is accessible from all pages via the Footer. Implement a consent management platform.

8. PCI-DSS Compliance Checklist

PCI-DSS posture: Partially Compliant — The 5 documented screens contain no payment card data handling. The architecture delegates payment processing to Shopify, which is a PCI-DSS Level 1 certified service provider. However, several requirements cannot be assessed from the available documentation, and the undocumented checkout flow is outside this assessment's scope.

Important scope note: PCI-DSS applicability for this application is primarily determined by the checkout flow, which is not included in the 5 documented screens. The findings below are limited to what is observable from the documented screens and configuration files. The checkout flow must be separately assessed.

# Requirement PCI-DSS Req Status Evidence Gap Remediation
PC-001 Network Segmentation Req 1 ❓ Not assessable from screen documentation. No network architecture documentation is provided. Network segmentation between the application tier and any cardholder data environment (CDE) is not documented. (Organizational control — outside documentation scope) Document network architecture and segmentation controls. If using Shopify-hosted checkout, confirm SAQ A scope with a QSA.
PC-002 Secure Configuration Req 2 ⚠️ TypeScript strict mode enabled (tsconfig.json). next.config.ts restricts remote image patterns to cdn.shopify.com only, reducing attack surface. No default credentials or unnecessary services are documented. No hardening baseline or secure configuration standard is documented for the application server or deployment environment. (Organizational control — outside documentation scope) Document the secure configuration baseline for the Vercel deployment environment.
PC-003 Protect Stored Data Req 3 N/A The 5 documented screens store no cardholder data. No payment card fields, card numbers, CVVs, or magnetic stripe data are present in any documented screen. The application delegates payment processing to Shopify. None for documented screens. If the undocumented checkout flow touches cardholder data, this requirement applies. Confirm with the development team that no cardholder data is stored in application-layer databases. Verify Shopify-hosted checkout is used for all payment processing.
PC-004 Encrypt Transmission Req 4 ⚠️ next.config.ts enforces HTTPS for cdn.shopify.com image delivery. Shopify Storefront API calls are server-side over HTTPS (inferred from Shopify API conventions — verify against lib/shopify implementation). TLS version and cipher suite configuration are not documented in the provided PROJECT CONFIG. No MIDDLEWARE block provided — cannot assess HTTP-to-HTTPS redirect enforcement. Verify TLS 1.2+ is enforced for all connections. Confirm HTTPS redirect is configured at the Vercel platform level.
PC-005 Anti-Malware Req 5 ❓ Not assessable from screen documentation. Anti-malware controls for the development and deployment environment are not documented. (Organizational control — outside documentation scope) Document anti-malware controls for all systems in scope.
PC-006 Secure Development Req 6 ⚠️ TypeScript strict mode and noUncheckedIndexedAccess reduce common vulnerability classes. prettier enforces code formatting standards. The dangerouslySetInnerHTML JSON-LD risk is documented as a Known Issue in the Product Detail screen — the development team has identified it, which demonstrates security awareness. URL parameters are passed to Shopify API without application-layer sanitization (documented in Item Detail and Search Detail screens), relying on Shopify's API layer for injection prevention. No documented SAST, DAST, dependency scanning, or penetration testing process. No documented secure coding standard beyond TypeScript strict mode. The dangerouslySetInnerHTML JSON-LD vulnerability is documented but not yet remediated. Fix the JSON-LD serialization vulnerability (use an HTML-safe JSON serializer). Implement dependency vulnerability scanning (e.g., npm audit, Snyk). Establish a secure development lifecycle (SDLC) policy.
PC-007 Access Control Req 7 ⚠️ All 5 documented screens are public routes with no access control — appropriate for a public storefront. Shopify API credentials are server-only environment variables, not exposed to the client. Access controls for Shopify admin, Vercel deployment pipeline, and any internal administrative interfaces are not documented. No MIDDLEWARE block provided — cannot assess access controls for protected routes. [Not documented — WHO: Security lead; WHAT: What role-based access controls are in place for the Shopify admin, Vercel dashboard, and any internal tools? WHERE: Insert in PC-007 Evidence column.]
PC-008 Authentication Req 8 ❓ No authentication is implemented in the 5 documented screens. No authentication library is present in package.json. Authentication mechanisms for administrative access (Shopify admin, Vercel) are not documented. MFA enforcement is not documented. (Organizational control — outside documentation scope) Document authentication controls for all administrative access, including MFA enforcement for Shopify admin and Vercel dashboard access.
PC-009 Physical Security Req 9 N/A The application is deployed on Vercel (cloud platform). Physical security is Vercel's responsibility as the infrastructure provider. None for cloud-hosted application. Obtain Vercel's physical security attestation (SOC 2 report or equivalent) as evidence.
PC-010 Logging & Monitoring Req 10 ❌ All 5 screen documentation files explicitly state the absence of error tracking, analytics, or logging calls. The ROOT LAYOUT contains no monitoring provider. The package.json contains no logging or monitoring library. No application-level logging or monitoring is documented. Infrastructure-level logging (Vercel) may exist but is not documented in the provided files. Implement application-level security event logging. Note: absence of logging calls in the 5 screen files does not confirm absence of infrastructure-level logging — verify via Vercel dashboard and any instrumentation files not included in this assessment.
PC-011 Security Testing Req 11 ❓ Not assessable from screen documentation. The package.json test script runs only prettier:check — no security testing tooling is documented. No penetration testing, vulnerability scanning, or security testing process is documented. (Organizational control — outside documentation scope) Establish regular penetration testing and vulnerability scanning. Implement dependency vulnerability scanning in the CI/CD pipeline.
PC-012 Security Policies Req 12 ❓ Not assessable from screen documentation. No information security policy is documented. (Organizational control — outside documentation scope) Establish and maintain a comprehensive information security policy.

9. WCAG 2.1 AA Compliance Checklist

WCAG 2.1 AA posture: Partially Compliant — The ROOT LAYOUT correctly sets lang="en" on the <html> element, and several screens use appropriate semantic HTML (e.g., <h1> for page titles, <ul>/<li> for product lists, <footer> landmark). However, multiple accessibility gaps are explicitly documented in the screen documentation, including missing <time> elements, absent landmark labels, unconfirmed carousel keyboard navigation, and missing <h1> on the Search Detail screen.

9.1 Summary by Principle

# Principle Criteria Count (AA) Compliant Partial Non-Compliant N/A Key Gaps
WC-001 1. Perceivable 13 5 5 2 1 Missing alt text verification for Carousel/ThreeItemGrid; missing <time> element; image-only content risk in product tiles
WC-002 2. Operable 10 4 4 1 1 Carousel keyboard navigation unconfirmed; missing visible focus rings on product tile links; no skip navigation link documented
WC-003 3. Understandable 8 5 2 1 0 Missing <h1> on Search Detail screen; <span> used instead of <strong> for search term emphasis
WC-004 4. Robust 3 2 1 0 0 Suspense fallback lacks aria-busy; JSON-LD <script> block uses dangerouslySetInnerHTML

9.2 Perceivable — Detailed Findings

1.1.1 Non-text Content (AA)

1.2.x Time-based Media (AA)

1.3.1 Info and Relationships (AA)

1.3.2 Meaningful Sequence (AA)

1.3.3 Sensory Characteristics (AA)

1.3.4 Orientation (AA)

1.3.5 Identify Input Purpose (AA)

1.4.1 Use of Color (AA)

1.4.2 Audio Control (AA)

1.4.3 Contrast (Minimum) (AA)

1.4.4 Resize Text (AA)

1.4.5 Images of Text (AA)

1.4.10 Reflow (AA)

1.4.11 Non-text Contrast (AA)

1.4.12 Text Spacing (AA)

1.4.13 Content on Hover or Focus (AA)

9.3 Operable — Detailed Findings

2.1.1 Keyboard (AA)

2.1.2 No Keyboard Trap (AA)

2.1.4 Character Key Shortcuts (AA)

2.2.1 Timing Adjustable (AA)

2.2.2 Pause, Stop, Hide (AA)

2.3.1 Three Flashes (AA)

2.4.1 Bypass Blocks (AA)

2.4.2 Page Titled (AA)

2.4.3 Focus Order (AA)

2.4.4 Link Purpose (AA)

2.4.5 Multiple Ways (AA)

2.4.6 Headings and Labels (AA)

2.4.7 Focus Visible (AA)

2.5.1 Pointer Gestures (AA)

2.5.3 Label in Name (AA)

9.4 Understandable — Detailed Findings

3.1.1 Language of Page (AA)

3.1.2 Language of Parts (AA)

3.2.1 On Focus (AA)

3.2.2 On Input (AA)

3.2.3 Consistent Navigation (AA)

3.2.4 Consistent Identification (AA)

3.3.1 Error Identification (AA)

3.3.2 Labels or Instructions (AA)

3.3.3 Error Suggestion (AA)

3.3.4 Error Prevention (AA)

3.2.6 Consistent Help (AA — WCAG 2.2)

9.5 Robust — Detailed Findings

4.1.1 Parsing (AA)

4.1.2 Name, Role, Value (AA)

4.1.3 Status Messages (AA)

10. Cross-Framework Gap Analysis

Gap Area GDPR CCPA SOC 2 PCI-DSS WCAG Impact Priority
Consent Management / Privacy Notice Art. 6, 7, 13 §1798.100(b), §1798.120 P1.1 — — High — legal exposure across two major privacy frameworks; no consent mechanism documented in any screen or ROOT LAYOUT High
Security Event Monitoring & Logging Art. 32 §1798.150 CC7.1, CC7.2 Req 10 — High — explicitly absent from all 5 screen files and ROOT LAYOUT; affects breach detection, incident response, and audit evidence High
Data Subject / Consumer Rights Mechanisms Art. 15–21 §1798.100, §1798.105, §1798.106, §1798.120 P1.1 — — High — no access, deletion, correction, or opt-out mechanisms documented in any assessed screen High
Content Security Policy (CSP) Headers Art. 32 §1798.150 CC6.1 Req 6 — High — no CSP headers documented in next.config.ts; mitigates XSS risk including the documented JSON-LD vulnerability High
JSON-LD dangerouslySetInnerHTML XSS Risk Art. 32 §1798.150 CC6.1, PI1.1 Req 6 4.1.1 Medium — documented Known Issue in Product Detail screen; JSON.stringify does not escape </script> sequences High
Service Provider / Data Processor Agreements Art. 28, 30 §1798.140(ag) CC5.1 Req 12 — High — Shopify and Vercel process data on behalf of the operator; no DPA documentation referenced High
Access Control & Authentication (Protected Routes) Art. 5(1)(f), 32 §1798.150 CC5.1, CC5.2 Req 7, 8 — High — no authentication library in package.json; protected routes (checkout, account) not documented Medium
Skip Navigation / Keyboard Accessibility — — — — 2.4.1, 2.1.1 Medium — no skip navigation link documented; carousel keyboard navigation unconfirmed Medium
Missing Page Heading (Search Detail) — — PI1.1 — 2.4.6, 1.3.1 Medium — documented Known Issue; affects both processing integrity and accessibility Medium
featuredImage.url Null Guard (Product Detail) Art. 32 — A1.1, PI1.1 Req 6 — Medium — documented Known Issue; causes runtime crash for products without a featured image Medium
Data Retention / Storage Limitation Art. 5(1)(e) §1798.100(c) C1.2 Req 3 — Medium — no retention periods documented for Vercel logs, Next.js cache, or Shopify data Medium
Carousel / Gallery Accessibility — — — — 2.1.1, 2.2.2, 2.4.3, 2.5.1 Medium — multiple WCAG criteria affected; implementation not visible from page-level documentation Medium
<time> Element for Dates (Item Detail) — — PI1.1 — 1.3.1 Low — documented Known Issue; semantic and machine-readability gap Low
Locale-Dependent Date Rendering (Item Detail) Art. 5(1)(d) — PI1.1 — 3.1.2 Low — documented Known Issue; server locale may differ from user locale Low

11. Remediation Roadmap

Phase 1: Immediate (0–30 days) — Non-Compliant Items with High Regulatory Risk

Phase 2: Short-Term (1–3 months) — Partially Compliant Items Needing Completion

Phase 3: Medium-Term (3–6 months) — Enhancement Items and Best Practices

Phase 4: Ongoing — Continuous Compliance Monitoring and Improvement

12. Glossary

Regulatory Frameworks and Acronyms

Term Definition
GDPR General Data Protection Regulation — EU Regulation 2016/679, effective May 2018. Governs the processing of personal data of individuals in the European Union.
CCPA California Consumer Privacy Act — California Civil Code §1798.100 et seq., effective January 2020. Grants California consumers rights over their personal information.
CPRA California Privacy Rights Act — Proposition 24 (2020), effective January 2023. Amends and expands CCPA, adding new rights (right to correct, right to limit sensitive PI) and creating the California Privacy Protection Agency (CPPA).
SOC 2 System and Organization Controls 2 — An auditing standard developed by the AICPA assessing service organizations' controls relevant to security, availability, processing integrity, confidentiality, and privacy (Trust Services Criteria).
SOC 2 Type II A SOC 2 audit that covers a period of time (typically 6–12 months), assessing both the design and operating effectiveness of controls.
PCI-DSS Payment Card Industry Data Security Standard — A set of security standards developed by the PCI Security Standards Council (Visa, Mastercard, Amex, Discover, JCB) to protect cardholder data. Version 4.0 is the current standard.
WCAG Web Content Accessibility Guidelines — Guidelines published by the W3C Web Accessibility Initiative (WAI) defining how to make web content accessible to people with disabilities. Version 2.1 Level AA is the most widely required standard.
DPA Data Processing Agreement — A contract between a data controller and a data processor (or between controllers) required by GDPR Art. 28, specifying the terms under which personal data is processed. Also used colloquially for "Data Protection Authority" (the supervisory authority in each EU member state).
DPIA Data Protection Impact Assessment — A process required by GDPR Art. 35 for processing activities likely to result in high risk to individuals' rights and freedoms.
DPO Data Protection Officer — A role required by GDPR Art. 37 for certain organizations, responsible for overseeing data protection strategy and compliance.
RoPA Records of Processing Activities — Documentation required by GDPR Art. 30 describing all data processing activities conducted by an organization.
CMP Consent Management Platform — A technology solution that manages user consent for data processing, typically implementing cookie banners and preference centers.
CSP Content Security Policy — An HTTP response header that instructs browsers to restrict the sources from which content (scripts, styles, images) can be loaded, mitigating XSS attacks.
PII Personally Identifiable Information — Information that can be used to identify a specific individual.
SAQ A Self-Assessment Questionnaire A — The simplest PCI-DSS compliance questionnaire, applicable to merchants that fully outsource all cardholder data functions to PCI-compliant third parties (e.g., Shopify-hosted checkout).
QSA Qualified Security Assessor — A company certified by the PCI Security Standards Council to conduct PCI-DSS assessments.
HSTS HTTP Strict Transport Security — An HTTP response header that instructs browsers to only connect to a site over HTTPS, preventing protocol downgrade attacks.
XSS Cross-Site Scripting — A web security vulnerability where an attacker injects malicious scripts into content served to other users.
CSRF Cross-Site Request Forgery — A web security vulnerability where an attacker tricks a user's browser into making an unintended request to a web application where the user is authenticated.
MFA Multi-Factor Authentication — An authentication method requiring two or more verification factors (e.g., password + OTP).
RTO Recovery Time Objective — The maximum acceptable time to restore a system after a disruption.
RPO Recovery Point Objective — The maximum acceptable amount of data loss measured in time (i.e., how far back in time recovery must reach).
SDLC Secure Development Lifecycle — A framework for integrating security practices into each phase of software development.
SAST Static Application Security Testing — Automated analysis of source code for security vulnerabilities without executing the program.
DAST Dynamic Application Security Testing — Automated security testing of a running application by simulating attacks.
ADA Americans with Disabilities Act — US federal law (Title III) that has been interpreted by courts to require accessible websites for places of public accommodation.
AODA Accessibility for Ontarians with Disabilities Act — Ontario, Canada legislation requiring accessible digital content.

GDPR Articles Referenced

Reference Name
Art. 5 Principles relating to processing of personal data
Art. 6 Lawfulness of processing
Art. 7 Conditions for consent
Art. 12–13 Transparent information and information to be provided
Art. 15 Right of access by the data subject
Art. 16 Right to rectification
Art. 17 Right to erasure ("right to be forgotten")
Art. 18 Right to restriction of processing
Art. 20 Right to data portability
Art. 21 Right to object
Art. 22 Automated individual decision-making, including profiling
Art. 25 Data protection by design and by default
Art. 28 Processor (data processing agreements)
Art. 30 Records of processing activities
Art. 32 Security of processing
Art. 33 Notification of a personal data breach to the supervisory authority
Art. 34 Communication of a personal data breach to the data subject
Art. 35 Data protection impact assessment
Art. 37 Designation of the data protection officer

CCPA/CPRA Sections Referenced

Reference Name
§1798.100 Right to know about personal information collected
§1798.100(b) Privacy notice requirement
§1798.100(c) Data minimization (CPRA)
§1798.105 Right to delete personal information
§1798.106 Right to correct inaccurate personal information (CPRA)
§1798.120 Right to opt-out of sale or sharing of personal information
§1798.121 Right to limit use and disclosure of sensitive personal information (CPRA)
§1798.125 Right to non-discrimination
§1798.140(ag) Definition of "service provider" and required contractual provisions
§1798.150 Private right of action for data breaches; reasonable security requirement

SOC 2 Trust Services Criteria Referenced

Criterion Name
CC1.1 Control Environment — Board oversight and organizational structure
CC5.1 Logical and Physical Access Controls — Logical access security
CC5.2 Logical and Physical Access Controls — Authentication
CC6.1 Logical and Physical Access Controls — Encryption
CC6.2 Logical and Physical Access Controls — Transmission security
CC6.3 Logical and Physical Access Controls — Change management
CC7.1 System Operations — Monitoring
CC7.2 System Operations — Incident response
CC8.1 Change Management — Risk assessment
A1.1 Availability — Processing integrity and availability
A1.2 Availability — Recovery
PI1.1 Processing Integrity — Data quality
C1.1 Confidentiality — Data classification
C1.2 Confidentiality — Data disposal
P1.1 Privacy — Privacy notice

PCI-DSS v4.0 Requirements Referenced

Requirement Name
Req 1 Install and maintain network security controls
Req 2 Apply secure configurations to all system components
Req 3 Protect stored account data
Req 4 Protect cardholder data with strong cryptography during transmission
Req 5 Protect all systems and networks from malicious software
Req 6 Develop and maintain secure systems and software
Req 7 Restrict access to system components and cardholder data by business need to know
Req 8 Identify users and authenticate access to system components
Req 9 Restrict physical access to cardholder data
Req 10 Log and monitor all access to system components and cardholder data
Req 11 Test security of systems and networks regularly
Req 12 Support information security with organizational policies and programs

WCAG 2.1 AA Success Criteria Referenced

Criterion Name
1.1.1 Non-text Content
1.3.1 Info and Relationships
1.3.2 Meaningful Sequence
1.3.3 Sensory Characteristics
1.3.4 Orientation
1.3.5 Identify Input Purpose
1.4.1 Use of Color
1.4.3 Contrast (Minimum)
1.4.4 Resize Text
1.4.5 Images of Text
1.4.10 Reflow
1.4.11 Non-text Contrast
1.4.12 Text Spacing
1.4.13 Content on Hover or Focus
2.1.1 Keyboard
2.1.2 No Keyboard Trap
2.2.1 Timing Adjustable
2.2.2 Pause, Stop, Hide
2.4.1 Bypass Blocks
2.4.2 Page Titled
2.4.3 Focus Order
2.4.4 Link Purpose (In Context)
2.4.5 Multiple Ways
2.4.6 Headings and Labels
2.4.7 Focus Visible
2.5.1 Pointer Gestures
2.5.3 Label in Name
3.1.1 Language of Page
3.1.2 Language of Parts
3.2.1 On Focus
3.2.2 On Input
3.2.3 Consistent Navigation
3.2.4 Consistent Identification
3.2.6 Consistent Help (WCAG 2.2)
3.3.1 Error Identification
3.3.2 Labels or Instructions
3.3.3 Error Suggestion
3.3.4 Error Prevention
4.1.1 Parsing
4.1.2 Name, Role, Value
4.1.3 Status Messages

Application and Technology Terms

Term Definition
React Server Component (RSC) A React component that renders exclusively on the server and ships zero JavaScript to the client. All 5 documented screens are RSCs.
Next.js App Router The Next.js 13+ routing system based on the app/ directory, where page.tsx files define route segments. Used throughout this application.
Full Route Cache A Next.js App Router caching layer that stores rendered HTML and RSC payloads at the CDN edge, enabling fast repeated page loads.
Shopify Storefront API Shopify's public-facing GraphQL API for building custom storefronts. Provides read access to products, collections, pages, and cart operations.
dangerouslySetInnerHTML A React prop that bypasses React's XSS protections by injecting raw HTML strings directly into the DOM. Used in Product Detail for JSON-LD structured data.
JSON-LD JavaScript Object Notation for Linked Data — a structured data format embedded in <script> tags that search engines use to understand page content and generate rich search results.
notFound() A Next.js App Router function that triggers the nearest not-found.tsx boundary, returning a 404 HTTP response.
generateMetadata A Next.js App Router export that generates <head> metadata (title, description, Open Graph, robots) for a page.
Vercel The cloud deployment platform and CDN used to host this Next.js application.
sonner A toast notification library used in ROOT LAYOUT via the <Toaster> component for displaying non-blocking user notifications.
HIDDEN_PRODUCT_TAG A Shopify product tag constant (from lib/constants) that marks a product as non-indexable by search engines while keeping it accessible by direct URL.
WelcomeToast A component rendered in ROOT LAYOUT that displays a welcome notification to new visitors using the sonner toast library.
Turbopack Next.js's Rust-based bundler used in development mode (next dev --turbopack), replacing Webpack for faster builds.
Geist A typeface by Vercel used as the primary font in this application, loaded via the geist npm package.
@headlessui/react A library of unstyled, accessible UI components (modals, dropdowns, etc.) included in package.json. Not directly referenced in the 5 documented screen files but available for use in child components.

End of Regulatory Compliance Checklist

Generated by Inkwell Forge — automated codebase documentation analysis. Subject matter expert review is recommended before distribution.