No updates detected yet. GitHub releases will appear here.
Loading the full README. The saved excerpt is shown below.
Real implementation of the Covered hospitality staffing marketplace, built
per reference/docs/covered-technical-spec.md. See ../CLAUDE.md (in the
parent Downloads folder) for the full build brief and phasing rationale.
This is a fresh codebase — reference/prototypes/*.html are the click-through
UI/UX mockups that informed the design; they are not extended in place.Read the full README ↗Real implementation of the Covered hospitality staffing marketplace, built
per reference/docs/covered-technical-spec.md. See ../CLAUDE.md (in the
parent Downloads folder) for the full build brief and phasing rationale.
This is a fresh codebase — reference/prototypes/*.html are the click-through
UI/UX mockups that informed the design; they are not extended in place.
Per spec §8.1: Phase 0 (foundations), Phase 1 (core booking loop),
Phase 2 (Reliability Score / Venue Trust Score), Phase 3 (Stripe Connect
payments), Phase 4 (ID/right-to-work/DBS verification), Phase 5
(dispute queue + admin panel), and Phase 6 (permanent-hire flow,
analytics, demand forecast, quick actions) are all built. Phase 3 is
verified live against real Stripe test-mode API calls: a full
shift (create → offer → accept → complete) walked Payment.status
through charging → charged → paid_out, with a real PaymentIntent
and Transfer on both ends. Phase 4's Persona piece is code-complete
but not live-tested — it needs a real external account only you can
create (see "Persona setup" below, and SETUP.md for the consolidated
list). Everything else — Phases 0, 1, 2, 5, and 6 in full — is
verified live against the database in the browser, not just
typechecked. Phase 6
highlights: the permanent-hire flow was walked through end to end
(propose → worker accepts → fee calculated correctly at £4,800 for a
£24,000 salary and 2 completed shifts → worker confirmed excluded from
that venue's search but still visible to a second venue, per spec
§3.3); the prototype's exact three quick-action presets
(covered.html's applyQuickAction) were matched and verified,
including weekend-availability filtering and kitchen-role grouping.
See src/lib/scoring.ts and src/lib/venue-trust.ts for interpretation
notes on two Phase 2 spec ambiguities (venue_confirmation_rate vs.
attendance_rate_weighted sharing one underlying field, and the
"late cancellation" tier vs. §3.1's binary 4-hour rule).
This is the beginning of the README. Read the rest at the original. Read the full README ↗