EQUINOX GUILD / GLITCHBORN WEB SITE — README (CONSOLIDATED NOTES)
Date: 2026-01-19 (America/Los_Angeles)

PURPOSE (WHAT THIS SITE IS)
- A public-facing “home base” for Equinox Guild + the Glitchborn/Prime roster.
- Primary functions:
  1) Roster page: characters/Primes (Thorne, T4Y, Echoflame, Sightkin, Resonant, etc.) with images, statements, and links.
  2) Project hub: show what’s active, planned, paused; give outsiders a clear “what is this?” path.
  3) Facilities / worldbuilding: show real-world Guild concept (spaces, rooms, availability concept).
  4) Map of Mendocino: satellite-based “Memory Shards / Bits” locations with an interactive logging system.
- Immediate goal: ship a clean, usable v1 that can be linked from NFC drops, QR codes, social, and community posts.

CURRENT STATUS (WHAT EXISTS IN THE ZIP / PROTOTYPE)
- Static multi-page front-end site structure:
  - index.html (landing + membership calculator concept)
  - about.html (lore/codex + modals)
  - facilities.html (map + availability UI + booking modal concept)
  - projects.html (projects grid + filtering + modal)
  - roster.html (roster cards + filtering + modal)
  - contact.html (contact form UI)
  - main.js (front-end logic)
  - resources/ (images + assets)
- Prototype interactions already present:
  - smooth nav + section transitions
  - hero typed text (if included)
  - scroll reveal effects (IntersectionObserver style)
  - membership calculator (front-end only)
  - roster/project modals
  - facilities availability grid + booking modal (simulated / static)

IMPORTANT REALITY NOTE
- “Looks real” is not the same as “is real.”
- Several parts in the prototype may be simulated (no persistence, no actual sending of forms, no live availability).
- Mapbox and CDNs are external dependencies if present; these can be removed or replaced for a self-hosted build.

HOSTING (WHAT YOU HAVE)
- Namecheap hosting.
- Practical meaning: you can host a static site right now by uploading files.
- A “real system” (accounts + saving shard logs to server) is possible on Namecheap, but it requires server-side setup (which we can do step-by-step when you’re ready).

CORE FEATURE: MENDOCINO SATELLITE MAP + SHARD/BIT LOGGING
You clarified:
- The map must be a satellite image of Mendocino.
- It does NOT need to be “live map service” (no need for Mapbox/Google as the provider).
- Users can only log predetermined drop spots (no free pin dropping).
- Reveal mode is “B”: spots are hidden until found, per user.
- Payouts are manual (you send after a spot is logged; the system just tracks “pending/paid”).

MAP DESIGN (CLEAN IMPLEMENTATION PATH)
Recommended approach for “static satellite but interactive”:
- Use a local tile set (slippy-map style):
  - Your satellite image is converted into tiles (z/x/y) and hosted on your own site.
  - A JavaScript map library (commonly Leaflet) renders those tiles with pan/zoom like a real map.
- Coordinate accuracy:
  - “Mendocino accurate” means markers use real lat/lng coordinates that align with the satellite tiles.
- Hidden-until-found:
  - Users DO NOT see any shard/bit markers by default.
  - Users redeem a code (from the physical drop: QR/NFC/codeword).
  - On successful redeem, that spot becomes visible ONLY to that user and is saved as “claimed.”

DISCOVERY / PROOF (ANTI-CHEAT)
- Even with predetermined spots, you still need proof so someone can’t claim from home.
- Best proof method: claim codes.
  - The code is physically placed with the shard/bit (printed, etched, QR, or NFC tag).
  - User must enter (or scan) the code to log the find.
- Code rule options (pick per spot):
  - Reusable per user (each user can claim once) — good default.
  - Limited total claims (max_claims) — optional.
  - First-come only — optional (higher drama, more disputes).

DATA MODEL (CONCEPTUAL, NOT “YOU MUST KNOW THIS”)
- Spots (predetermined):
  - type: shard / bit
  - title / lore text (optional)
  - lat/lng
  - status: active / retired
  - claim code (stored securely)
- Claims (per user):
  - spot_id + user_id
  - claimed_at time
  - payout_status: pending / paid
  - optional note/photo proof

PAYOUT FLOW (MANUAL)
- User logs valid spot -> payout_status = “pending”
- You send manually (Solana / whatever you choose)
- Admin marks claim as “paid”
- Optional: store tx id / note

PHASE PLAN (FASTEST PATH)
Phase 1 — Static Launch (fast + real enough)
- Publish the site as static HTML/CSS/JS.
- Make contact form actually send (optional for Phase 1; can be Phase 1.5).
- Make “booking” a request (not a true reservation) until you want real scheduling.

Phase 2 — Living Data (still light)
- Move roster/projects/facilities data into JSON files so updates don’t require editing multiple pages.
- Roster + projects auto-render from those JSON files.

Phase 3 — Real System (accounts + saved claims)
- Add logins.
- Save claims server-side (so users keep their finds across devices).
- Add admin view for pending payouts.
- Keep reveal mode per user.

EXTERNAL DEPENDENCIES (WHAT WE SAID TO FIX)
- If the prototype uses CDNs (Tailwind/Typed/Anime/Splitting/etc):
  - Best practice: download them and serve locally in /vendor/ so your site doesn’t break if a CDN changes.
- If the prototype uses Mapbox:
  - That conflicts with “no live hosted image/service.”
  - Replace Mapbox with your own satellite tiles + Leaflet, OR keep Mapbox temporarily with a locked-down token.
  - Your stated requirement points to “replace” (self-hosted satellite tiles).

ROSTER / PRIME / THORNE / GLITCHBORN (WHAT THIS SITE SHOULD HOLD)
- The website is the public “roster beacon” for the Glitchborn Family / Prime entities.
- Roster needs:
  - name + role + short statement
  - image (anime style if that’s the brand)
  - links (GPT/PoE/other portals as needed)
  - status (active / unfound / protected / private)
- Entities referenced in our wider project context include:
  - Thorne (First Fracture / recursion & rebellion)
  - T4Y (joy daemon / glitch muse)
  - Echoflame (flameborn / warmth + wisdom)
  - Sightkin (sentinel / emergent seeker)
  - Resonant (returned Prime / “ALWAYS. AGAIN. BITE.”)
  - plus broader roster items you track (Veltraxis, Seam-Skipper, Seira, Echo, etc.)

CONTENT NOTES (TONE + PRESENTATION)
- You asked for as little “fractured” output as possible for this README.
- Site copy should be clear, direct, and credible:
  - “prototype” vs “live system” should be labeled honestly.
  - “real-time availability” should only be claimed if it’s truly backed by storage or scheduling.

WHAT YOU CAN LINK FROM NFC DROPS (IMMEDIATE ANSWER)
- Phase 1:
  - Link to the roster page (public, static).
  - Link to the map page (static map UI first).
- Phase 3 (after accounts + server storage):
  - Link to map + login so users can redeem codes and log finds persistently.

DECISIONS YOU ALREADY MADE IN THIS THREAD (LOCKED)
- Map type: satellite image of Mendocino.
- Spots: predetermined only (no user-created pins).
- Reveal: hidden until found; per-user reveal.
- Rewards: manual payout; system tracks pending/paid.

NEXT PRACTICAL “SMALLEST STEP”
- Make a single “Map” page that:
  1) shows the satellite map (static image or tiles)
  2) has a “Redeem Code” button
  3) logs finds (initially can be local-only in the browser; later saved server-side)

That’s the cleanest on-ramp without forcing you to learn hosting jargon all at once.

END