AdorWorks website + backend

Four parts now:

• The public site (this folder's root) — plain static HTML/CSS/JS, no build step, no framework, installable as a PWA (manifest + service worker) and tuned for mobile-first use, since ~90% of the target market is on smartphones. Still concierge-flavoured: curated shortlists, staff-reviewed verification, intake forms rather than self-service search — the front door for people who haven't signed up yet.
• platform/ — the self-service marketplace app (Next.js): accounts, login, onboarding, opportunity search and applications, offers, contracts, milestones, messaging, disputes, timesheets, and a fully simulated payment flow (invoices, receipts, mobile-money/card checkout). This is where the "prove the model, then open self-service" sequencing from the blueprint actually lands — see platform/README.md.
• backend/ — Supabase (Postgres + Auth + Storage + Row Level Security) plus a small Node/Express API for staff-only operations. Implements the full self-service-marketplace data model from the AdorWorks Startup & Website Blueprint §7.9 and is what both the public site's intake forms and platform/ write into.
• staff/ — the internal console staff use to triage, verify, moderate and oversee everything above.

This is a separate product from Adormedia and is meant to be deployed as its own Cloudflare Pages site — see "Deploy" below; platform/ deploys separately (see its own README) since it's a Next.js app, not a static site.

What's here vs. what isn't

Built:

• Public marketing/info pages for the full sitemap in Blueprint §7.4, installable as a PWA (manifest.webmanifest, sw.js, offline.html, an install-prompt banner) and audited for mobile touch targets, iOS safe-areas, and the sticky-header/anchor-scroll bug that's easy to miss (see css/styles.css's scroll-padding-top).
• Six public forms (employer brief, talent application, shortlist request, service request, general contact, insights-launch subscribe) that submit to Supabase directly with the anon key once js/supabase-config.js is filled in (see backend/supabase/README.md) — already the case in production. A Netlify Forms fallback still exists in the code for completeness but is unreachable now that Netlify itself is retired (see "Deploy" below).
• The full backend schema + RLS (backend/supabase/) and a staff-console API (backend/api/) for verification, shortlisting, engagement tracking and manual finance records — see backend/README.md.
• The finalised AdorWorks brand (violet/teal/coral, Midnight, Manrope) — see css/themes.css and img/.
• Honest empty states instead of invented content: jobs-projects.html and impact-stories.html both say plainly that there's nothing to show yet, per the blueprint's evidence standards (§9.4) — no fake listings, no fabricated testimonials or stats.
• A staff console (staff/) for everything the API supports: triaging intake submissions and converting them into real accounts, verifying talent and organisations, building each opportunity's shortlist, overseeing contracts and finance records, and resolving disputes. See staff/README.md.
• A talent/employer account UI (platform/): login, dashboard, self-service opportunity search and applications, offers and contract lifecycle (milestones, deliverables, revisions), in-platform messaging with attachments, timesheets, disputes, verified work history, and two-sided reviews. See platform/README.md for the full feature list and its "Security notes" section for how the authorization model works.
• A fully simulated payment flow inside platform/: invoices raised automatically on milestone approval, a swappable payment-provider interface (mock m-Gurush, MTN MoMo and card implementations), receipts, and staff-side reconciliation — see backend/README.md's "What's deliberately NOT here" section for what this is and isn't.
• A test suite (platform/e2e/, platform/src/**/*.test.ts, backend/api/src/**/*.test.js) and a CI workflow (.github/workflows/ci.yml) that runs lint, unit tests and a production build on every push.

Not built yet:

• A native mobile app — the PWA (installable from the browser, works offline for pages already visited) is the mobile-app answer for now; see backend/README.md's note on when a native app would earn its cost. platform/ itself is deliberately online-only (not offline-first) — every core action there has to reach the server to mean anything, so a full offline sync layer isn't the right trade for a marketplace app the way it is for the mostly-static public site.
• Update, 2026-09-19 (S13-04–S13-08): privacy.html, terms.html, community-standards.html and cancellation-refunds.html are now real, dated, versioned policy documents (not placeholders) — see docs/governance/decision-log.md's Stage 13 entry. What's still genuinely Content pending: a real phone/WhatsApp number, and trust-safety.html's dedicated safeguarding reporting channel — both deliberately left unpublished until there's someone to actually staff and monitor them, not an oversight.
• Real payments — the simulated flow above never sets is_simulated to false anywhere in the codebase; no payment gateway is integrated, per the blueprint's compliance-first rule pending a licensed local payment partner.

Before this goes live

• Working name. The blueprint flags "AdorWorks" as a working name pending company-name, trademark, domain and social-handle clearance (see its "Document status and how to use it" section). That's noted in an HTML comment in about.html and in the footer copyright line on every page — remove both once clearance is confirmed.
• Domain. robots.txt, sitemap.xml, canonical/OG/Twitter tags and the JSON-LD on index.html now point at the real live domain, adorworks.pages.dev (moved from adorworks.netlify.app after Netlify's free-tier usage limit took the site down — see "Deploy" below) — update all of these again once a custom domain is cleared and live.
• Compliance. Do not accept real client funds or run full-time/ cross-border placements through this site before the recruitment-agency licensing, contracts, tax and payment-partner questions in Blueprint Part 5.8 and 11 are resolved with qualified counsel.
• Contact details. privacy.html/terms.html/community-standards.html/ cancellation-refunds.html are done (see above) — what's left is contact.html's and trust-safety.html's WhatsApp/phone number and the dedicated Trust & Safety reporting channel, both still marked Content pending until there's someone to actually staff and monitor them.

Deploy

Cloudflare Pages (current):

1. Cloudflare dashboard → Workers & Pages → Create → Pages → Import an existing Git repository → the AdorWorks repo.
2. Build settings: Framework preset None, Build command node build-cf-pages.mjs, Build output directory _site, Root directory blank (repo root).
3. build-cf-pages.mjs copies only the files this site needs to serve (every top-level *.html, css/, js/, img/, staff/, manifest.webmanifest, sw.js, robots.txt, sitemap.xml, _headers, _redirects) into _site/ — the actual deploy output — so backend/, platform/, docs/, .github/ and repo-management files are never uploaded as deployable assets at all. This isn't optional cleanliness: a Cloudflare Pages redirect does not reliably override a request whose path matches a real uploaded file (confirmed live, not just from docs), so relying on _redirects alone to block those paths after the fact was found not to work.
4. No environment variables needed — js/supabase-config.js already has the public URL/key committed. Forms submit directly to Supabase client-side; there's no server-side form handling to configure.

Netlify (retired): the site was originally deployed there, but its free-tier usage limit took the whole site down for real visitors — every page returned Netlify's own "usage_exceeded" 503 — which is what prompted the move to Cloudflare Pages above. netlify.toml is gone; _headers/_redirects are what its [[headers]]/[[redirects]] were translated from, and are now the only copy. The six forms still carry data-netlify="true" markup (harmless no-op on Cloudflare) and js/main.js still has a submitToNetlify fallback for completeness, but that path is dead code in production — Supabase is configured, so submitToSupabase is what actually runs.

Local preview

npx serve .
# or
python -m http.server 8080

Structure

index.html            Home
services.html          Services (packaged deliverables + service request)
jobs-projects.html     Jobs & Projects (honest "no listings yet" state)
for-employers.html     For Employers (categories, hiring modes, verification, brief form — the one real employer-intake pipeline)
for-talent.html         For Talent (verification tiers + application form)
how-it-works.html      How It Works (both journeys, step by step)
trust-safety.html      Trust & Safety (verification, payments, disputes)
pricing.html            Pricing (fee model; talent side is always free)
impact-stories.html    Impact & Stories (case-study method, empty for now)
about.html              About (mission, Adormedia relationship, values)
insights.html            Insights (coming-soon + notify-me form)
contact.html             Contact (general enquiries)
css/themes.css          AdorWorks brand palette as CSS custom properties
css/styles.css          Shared layout, components, utilities
js/main.js               Nav toggle, analytics hooks, PWA install prompt, form submit
js/supabase-config.js    Public Supabase URL + anon key (fill in; not secret)
img/                      Logo SVGs + generated PWA icons (img/icons/)
manifest.webmanifest      PWA manifest
sw.js                     Service worker (offline shell caching)
offline.html              Shown when a page isn't cached and there's no connection
404.html
robots.txt, sitemap.xml
_headers, _redirects     Cloudflare Pages security headers + redirects
backend/supabase/         Database schema, RLS policies, storage buckets (see backend/README.md)
backend/api/               Staff-console Node/Express API
staff/                     Staff console web UI (see staff/README.md) — noindex'd, login-gated
render.yaml                 Render Blueprint for deploying backend/api

PWA / mobile

• Install: Chrome/Edge/Android show an in-page "Install AdorWorks" banner once the browser decides the site is installable (handled in js/main.js's beforeinstallprompt listener). iOS Safari has no such event — install there is manual, via the Share sheet → "Add to Home Screen"; there's no code path to trigger it programmatically.
• Offline: sw.js precaches every page plus the CSS/JS/icon shell on first visit, so previously-viewed pages keep working with no connection; offline.html is the fallback for anything not cached. Form submissions are never intercepted by the service worker (only GET requests are) — no connection means no submission, by design, rather than a silently-queued write that might never actually send.
• Bump CACHE_VERSION in sw.js whenever you change a cached file (any CSS/JS/HTML in SHELL_URLS) — otherwise visitors with the site already installed keep serving the old cached copy indefinitely.
• Regenerating icons: img/icons/*.png were rasterized from img/adorworks-mark.svg (a one-off Node + sharp script, not checked in) — regenerate at the same sizes (192/512 "any", 192/512 "maskable" with ~52% icon-to-canvas ratio for safe-zone padding, 180 apple-touch) if the mark ever changes.

Backend

Full setup instructions live in backend/README.md. Short version:

1. Create a Supabase project and run the four migrations in backend/supabase/migrations/ (paste into the SQL Editor, in order).
2. Fill in js/supabase-config.js with your project's URL and anon key — the six public forms then write straight into intake_submissions.
3. cd backend/api && npm install, fill in .env from .env.example (this one needs the secret service_role key), npm start — this is what a future staff console would call to review submissions, verify people/organisations, build shortlists and track engagements.

Brand

Single palette (no per-page theme switching, unlike the Adormedia site): Midnight #182230 (primary/text), Opportunity Teal #00A88F (primary action colour), Talent Violet #5B4BDB (secondary accent), Energy Coral #FF6B4A (sparing highlight only), Cloud #F4F7FB (background), Slate #596274 (muted text). Headings and the wordmark use Manrope (loaded from Google Fonts), matching the delivered logo files in img/.

Analytics

js/main.js pushes events to window.dataLayer for every form submission (event name adorworks_event, action form_submit with a form_id). js/analytics.js (Stage 9) turns these into real Google Analytics 4 events, consent-gated: every page defaults Google's Consent Mode to fully denied, shows a cookie banner on first visit, and only loads gtag.js — and only after a visitor actively accepts — if a Measurement ID is configured.

To turn analytics on: create a GA4 property (analytics.google.com -> Admin -> Data Streams -> your web stream), copy its Measurement ID (G-XXXXXXXXXX), and set window.ADORWORKS_GA_MEASUREMENT_ID in js/analytics-config.js. Leaving it blank (the default) keeps analytics fully inert regardless of what anyone clicks in the cookie banner — same "no ID, no live calls" pattern as the payment-provider scaffolding in platform/.