Everything that runs PRC in one place: the systems, the flow, the 90-day schedule, where each cohort is up to, what to do when something breaks, and system health. Numbers below read live from the cohort data baked into this file.
A 90-day anonymous behavioural protocol delivered by daily email. Three pillars: Mapping (Day 1–30), Redesign (Day 31–60), Installation (Day 61–90), then a Day 91 exit. 74 emails, 14 weekly worksheets, a private phone-only log, and a numbers-only dashboard. The employer only ever sees aggregate data.
2770859 · 74 emails960580020075371296175prc-workforce.workers.devThe moving parts and how they connect. Everything routes through the enrolment page, Kit, and the Cloudflare Worker; the employer touches only the HR dashboard.
participant.html recognition page (employer distributes this) · enrol.html seat claim · /dashboard/ participant view · /score/ PRC Index entry · log.html phone-only private log · /hr/ employer aggregate view.
Static hosting. The pages call the Worker for anything dynamic.
Form PRC Participant Enrolment (9605800) collects personal email + company_code (field 1296175). Automation PRC Cohort Tagging (2007537) reads the code and applies the cohort:Name tag. Sequence PRC Workforce Protocol (2770859) delivers the 74 emails.
Write-once fields set by the Worker: dashboard_token, prc_protocol_start.
The brain. Endpoints: /api/enrol (the only sanctioned way to add a participant), /api/participant, /api/score, /api/weekly-score, /api/emails, /api/cohort, /api/hr, /api/day91, /api/go, /api/admin/add-client, /api/admin/sync-emails.
D1 tables: clients, emails (archive snapshot), weekly_scores. Secrets: KIT_API_KEY, ENROL_SECRET, admin key.
Priced per employee per year, site-wide, no seat cap. 12-month rolling, 90 days notice. No change to the employer's existing EAP or OH contracts.
Verify: the observed enrolment path (page → Worker + Kit) does not itself include a Stripe step — billing sits at the contract stage. Confirm where Stripe/Zapier are wired.
Watches the live system and sends a Telegram alert on faults, breakages, or the sequence firing incorrectly. See the System Health tab for status and how to feed it into this dashboard.
Its exact checks live in the Monitor Operating Guide / Reference Card PDFs, which are image-only and could not be read here — confirm the checklist so this can be made exact.
Employer sees seats, completion, and cohort-average PRC Index movement only — never names, emails, or who enrolled. Aggregate reporting is floored at n ≥ 5. The participant's written words live only in the phone-only log and are never uploaded.
From signing an employer to reporting back. Gold actions marked "Do" are the manual steps that need you.
Every one of the 74 emails in order, by pillar. Worksheets carry the weekly number; the PRC Index is taken on Days 1, 30, 60 and 90.
Worksheet weekly number PRC Index Days 1/30/60/90 Daily two-minute input
Each employer is a cohort, keyed by its company code. Current protocol day, pillar and next email are computed live from each cohort's start date and cadence. To make a change permanent, tell me and I will bake it into this file.
Adds to this session only — it will not survive a page reload. For a permanent cohort, send me the details and I will write it into the dashboard.
The known failure and support scenarios, with the exact response for each. Search to jump to one.
Live status of every moving part. The night watchman already sends you Telegram alerts; this panel is where that signal can also surface visually.
A saved HTML file cannot receive Telegram messages directly. To make the chips above go live, have the watchman also write its last result somewhere this page can read:
1. Add a /api/health route to the Worker (or a Cloudflare KV JSON) that returns the watchman's latest check.
2. Shape it as: { updated, systems:[{ name, status, message, last_check }] } where status is ok / warn / down.
3. Give me that URL and I set STATUS_URL in this file — the chips then refresh on load and every 60s.
Until then the panel runs in manual mode using the reference states below.
Proposed checklist, to confirm against your Monitor Operating Guide:
· Worker reachable (/api/participant returns 200 to a known seat)
· Kit API key valid (sequence read succeeds)
· Sequence step cadence correct (STEP_HOURS = intended value)
· D1 archive row count = 74 and in sync with Kit
· Enrolment path writes token + start and adds to sequence
· HR endpoint returns aggregate for a known cohort.
The Monitor PDFs are image-only and were not readable here — send the checklist and I will match this exactly.
Static log — tell me the date, system and what happened and I will add rows.