Build Handoff Archive
TatCare — archival handoff document for all past build sessions.
TatCare — Build Handoff Archive
Professional archival handoff document for all past build sessions. Generated 2026-07-31.
Project / Feature Name
TatCare — Tattoo Healing Management & Touch-up Tracking Platform
Document Purpose
Archive all past build sessions into a clean, durable handoff document for future retrieval.
Build Sessions
| Session ID | Date | Duration | What Changed | Status | Notes |
|---|---|---|---|---|---|
| BS-001 | Not verified | Not verified | Mandatory 5-step onboarding flow (greet, role selection, tutorial, NDA consent, profile creation) with auth gate as first step; root (/) path set to Onboarding; conditional role-based routing to Dashboard after completion. | Complete | NDA consent is client-side only (bypassable). Onboarding enforced via AppLayout redirect. |
| BS-002 | Not verified | Not verified | Applied Row-Level Security (RLS) to all 9 core entities (Appointment, ArtistAvailability, BookingRequest, CheckIn, Client, PortfolioItem, Reminder, TattooSession, User) with role/ownership-based rules. | Complete | ArtistAvailability and PortfolioItem read = null (public). Review create = created_by_id. |
| BS-003 | Not verified | Not verified | Public booking system: booking_token as public lookup key; getPublicArtistProfile and getPublicSlots backend functions; PublicArtistProfile and PublicBooking pages; server-side service-role access for anonymous submissions. | Complete | PublicPortfolio token parsing includes extraneous query strings (known issue). No strict rate-limiting on public functions. |
| BS-004 | Not verified | Not verified | Review entity for client testimonials on public profiles with artist moderation gate (is_approved). | Complete | Read = null (public once approved). Update/delete restricted to artist role. |
| BS-005 | Not verified | Not verified | Free session entitlement: FreeSessionRedemption entity; checkFreeSessionEligibility function returning minimal {eligible, reason}; submitBookingRequest with email normalization, claim-then-check race-condition protection, and wrapped email notifications. | Complete | All free session logic is server-side (admin-only entity) to prevent client-side data leaks. |
| BS-006 | Not verified | Not verified | Healing Intelligence Beta entitlement: HealingIntelligenceBeta entity; checkHealingIntelligenceEligibility and joinHealingIntelligenceBeta backend functions with server-side RLS enforcement; JoinHealingIntelligenceBeta UI component on PublicArtistProfile. | Complete | Beta access controlled by admin allowlist. Eligibility UI is conditional on server response. |
| BS-007 | Not verified | Not verified | HealingIntelligenceAdmin page for internal beta allowlist management (add/remove client emails, toggle active state, scope by artist token); wired /admin/healing-intelligence route. | Complete | Page enforces admin role check; redirects non-admins. Entity RLS is admin-only across all operations. |
| BS-008 | 2026-07-31 | Not verified | Added admin role to User entity role enum (admin, artist, client) to enable platform-level admin assignment for the app owner. | Complete | Admin role is NOT selectable during onboarding. Assigned via platform Settings → Users. |
Start/end times not preserved in available records — marked "Not verified". Entries in chronological build order.
Overview
TatCare is a professional tattoo healing management and touch-up tracking platform for studios. It enforces a role-specific workflow for artists and clients, including secure healing tracking, booking, portfolio management, and a beta entitlement system for advanced Healing Intelligence features. The app is onboarding-first, with mandatory onboarding before Dashboard access.
What Was Built
A full onboarding flow with auth gate and NDA consent; row-level security across all core entities; a public booking system with token-based artist profiles and server-side submission; client testimonials; a one-time free session entitlement with race-condition protection; and a managed beta entitlement system (Healing Intelligence) with an admin allowlist and server-side enrollment.
What Is Complete
Onboarding flow (5 steps + auth gate). RLS on all 9 core entities. Public booking (profile, slots, submission, free session redemption). Reviews. Healing Intelligence Beta (entity, eligibility check, enrollment, admin allowlist page, public UI). Admin role added to User entity enum.
What Is Intentionally Unchanged
Onboarding role selection remains artist + client only (admin is not self-selectable). No payment/billing integration wired (Stripe packages installed but unused). No scheduled reminder automation. No offline support. No multi-artist support beyond single-artist booking tokens.
Key Implementation Details
booking_token is treated as a public lookup key for artist profiles; sensitive data is protected by RLS and server-side auth. Anonymous booking submission uses service-role backend functions. Email normalization (lowercased, trimmed) is applied consistently for client lookups. Free session redemption uses a claim-then-check pattern to prevent race conditions. Booking submission wraps email notifications so the booking succeeds even if notification delivery fails (surfacing a warning). Beta enrollment is fully server-side with admin-controlled allowlist.
Security / Privacy Notes
All 9 core entities have RLS. Public backend functions (getPublicArtistProfile, getPublicSlots, submitBookingRequest, checkFreeSessionEligibility, checkHealingIntelligenceEligibility, joinHealingIntelligenceBeta) use service-role access. Known gaps: public functions lack strict rate-limiting; NDA consent is client-side only and bypassable; submitBookingRequest lacks date/time availability validation; no payment/billing integration. Photos submitted are used solely for healing assessment. Client data is not sold to third parties.
Open Questions / Future Follow-Ups
Add server-side rate-limiting to public functions. Move NDA consent to server-side enforcement. Add date/time availability validation in submitBookingRequest. Fix PublicPortfolio token parsing (extraneous query strings). Wire payment/billing for deposits. Implement scheduled reminder automation. Consider multi-artist support beyond single booking tokens.
Files, Entities, Functions, or UI Components Affected
Entities: User (role enum + admin), Appointment, ArtistAvailability, BookingRequest, CheckIn, Client, PortfolioItem, Reminder, TattooSession, Review, FreeSessionRedemption, HealingIntelligenceBeta. Backend functions: getPublicArtistProfile, getPublicSlots, getAvailableSlots, submitBookingRequest, checkFreeSessionEligibility, checkHealingIntelligenceEligibility, joinHealingIntelligenceBeta, appointmentClientAction, appointmentGetByToken, appointmentNotify, sendDepositRequest. Pages: Onboarding, Dashboard, PublicArtistProfile, PublicBooking, PublicPortfolio, AppointmentConfirm, ArtistReview, ClientDashboard, ClientHealing, HealingIntelligenceAdmin, Settings, and others. Components: JoinHealingIntelligenceBeta, AppLayout, AuthContext.
Testing Status
Not yet verified. No automated test suite observed. Manual testing via app preview. Backend functions have not been systematically test-invoked in this archive window. Mark testing status as pending follow-up.
Archive Notes
This document was generated from project context snapshots and compacted conversation history. Exact session dates, start/end times, and durations were not preserved in available records and are marked "Not verified". Content reflects the state as of 2026-07-31. Entries are in chronological build order. This archive is durable and intended for long-term retrieval.
Handoff ready for archive.
