jfeelgoodofficial/minicuration

1. Project type

- This is a static marketing/catalog site for limited-edition trading card art prints.

- There is no application backend or database; the live site is composed of prebuilt HTML pages, images, and SEO files.

2. Primary user-facing surfaces

- index.html is the main landing page.

- shop.html is the product listing/catalog view.

- about.html provides brand or artist context.

- artists/jfeelgood.html is an artist-focused page.

- Individual product pages live under shop/*.html for each print.

3. Content organization

- The repository is structured around static pages per product rather than dynamic rendering.

- Each print has its own dedicated HTML page, which makes the catalog easy to index and straightforward to share.

- This design also supports SEO-friendly, crawlable detail pages.

4. Media and visual assets

- Images are stored in image/, with a dedicated image/spin/ area for the 3D card-flip/preview visuals described in the README.

- The site appears image-heavy, so the asset pipeline is a first-class part of the architecture.

- The README’s “hover to flip” behavior implies the front end uses visual states and image assets to simulate the card front/back interaction.

5. Client-side interaction model

- The core UX features are:

- card flip on hover/click,

- filter controls for availability,

- modal detail views,

- responsive mobile layout.

- These are all delivered on the client side, likely via JavaScript embedded in or associated with the HTML pages, with no server round trips for interaction.

6. SEO and indexing layer

- robots.txt, sitemap.xml, and _redirects show that search visibility and clean routing are intentional parts of the architecture.

- llms.txt suggests additional machine-readable site guidance for LLM-oriented crawlers or tooling.

- tests/seo.check.ts and scripts/check-seo-files.js reinforce that SEO files are treated as build-critical artifacts.

7. Asset maintenance pipeline

- The scripts/ directory is a maintenance toolchain for image and HTML hygiene:

- image optimization,

- conversion to WebP,

- updating image references in HTML,

- fixing image attributes and spacing,

- verifying generated output.

- This indicates a workflow where static content is edited, then normalized/optimized before deployment.

8. Quality and validation boundaries

- The repo includes multiple validation layers:

- ESLint for JavaScript/TypeScript,

- Prettier for formatting,

- Stylelint for CSS,

- HTML validation via htmlvalidate,

- Playwright for browser-level checks,

- Lighthouse configuration for performance/SEO audits.

- This is a static-site architecture with strong content QA rather than runtime observability.

9. End-to-end test coverage

- tests/home.e2e.ts, tests/shop.e2e.ts, tests/product.e2e.ts, and tests/seo.check.ts cover the critical user flows:

- landing page,

- catalog page,

- product detail pages,

- SEO integrity.

- The test suite reflects the main architectural boundaries: home, browse, detail, and discoverability.

10. Deployment model

- The presence of _redirects, static HTML pages, and GitHub workflow files strongly suggests deployment as a static site, likely via GitHub Pages or a similar static host.

- There is no evidence of server-side rendering or API dependencies in the runtime path.

11. Technology profile

- Tooling is centered on Node-based maintenance and testing (package.json, Playwright, Lighthouse, CI workflow) with at least one Python verification/cleanup script.

- The runtime experience for visitors remains purely static; the build/test toolchain is what adds structure and quality.

12. Architecture summary for a diagram

- A good diagram would show:

- source content/pages at the center,

- image pipeline scripts feeding optimized assets into the site,

- validation/test tooling wrapping the site,

- static hosting/redirects/SEO files as the delivery layer,

- and no backend services in the request path.