Cards primitive for pa.gf.cx — lift to assets.gf.cx/cards (parked 2026-05-24)

DARE.CO.UK · PARKED SKETCH · 2026-05-24

Mirrored from ~/.claude/.../memory/parked_sketch_cards_primitive_2026-05-24.md. This is a design sketch parked for future build — read for context, not as a current deliverable.

pa.gf.cx is increasingly card-grid driven (New Hope landing, expense categories, vehicle records, status pages, contractor records). Each surface re-implements similar-but-different card CSS today. Time to lift to a single shared primitive at assets.gf.cx/cards/cards.css so Audrey-grade visual consistency holds across the whole portfolio. Triggered by Dan wanting to share pa.gf.cx with Audrey.


Dan 2026-05-24: “Lets schedule time to build ‘cards’ for pa.gf.cx, it’s handy sharing with audrey now that it’s taking shape.”

Why now

Five surfaces already use card-grid layouts with hand-rolled CSS that’s similar-but-not-identical:

Surface Card pattern Renderer
pa.gf.cx/ New Hope landing .system cards (13 cards, photo/emblem thumb + body) hand-written pa/index.html
pa.gf.cx/properties/new-hope/expenses/ .cell cards (60 category tiles) pa_harvest_render.py
pa.gf.cx/vehicles/*.html various sections — TCO stat cards, receipt grid tiles hand-written + Python inject
pa.gf.cx/amazon/_status/ .stat cards (6 stat tiles) pa_job_status_render.py
pa.gf.cx/contractors/*.html signal-axis cards hand-written

Plus future: vehicles index, expense year pages, claim cockpit, every per-substrate landing.

Recipe

  1. Create ~/Code/toolkit/web-assets/cards/cards.css — the canonical primitive
  2. Define three card variants: - .card--system — thumb + body (matches pa landing today) - .card--stat — label + big serif value + sub (matches status today) - .card--tile — square tile with title + meta (matches category landing today)
  3. Add layout primitive: .card-griddisplay:grid; grid-template-columns:repeat(auto-fill, minmax(220px, 1fr)); gap:18px
  4. Each surface imports via <link rel="stylesheet" href="https://assets.gf.cx/cards/cards.css">
  5. Replace hand-rolled CSS in each renderer with the shared classes
  6. Update web-assets/index.html to list the new primitive

Generic Amazon card (per Dan’s note)

For Amazon specifically — a single generic “Amazon section” card sits on the pa.gf.cx New Hope landing, links to /amazon/ (which is its own surface with subpages). Same shape as the existing system cards. No per-order card needed on the landing; the orders.html master table handles browsing.

“Easy programmatically for any page” — honest answer

Surface Programmatic?
Status pages, expense pages, per-order pages ✓ Yes (already rendered by Python scripts; just import the CSS + rename classes)
pa landing, vehicle records, contractor records ✗ Hand-written; each needs a manual edit pass

So lift-and-shift is mixed: programmatic renderers convert in ~10 min each; hand-written surfaces are case-by-case CSS migration.

Cost

Step Effort
Author cards.css + deploy assets.gf.cx 45 min
Migrate 4 programmatic renderers 40 min (10 each)
Migrate 4-6 hand-written surfaces 60-90 min
Document in web-assets/cards/README.md 15 min
Total ~3-4 hours

Build trigger

Build when ANY: - Dan dedicates a focused session - Audrey first looks at pa.gf.cx and asks “why does this card look different from that one?” - Card grid pattern gets reused on a 6th surface (forcing the migration) - Adding a new portfolio surface (would otherwise spawn yet another card CSS variant)

Cross-references

The aphorism

The portfolio earns its visual coherence when the cards aren’t trying — they just are.

Source: parked_sketch_cards_primitive_2026-05-24.md · Rendered 2026-05-24 06:31