Session Flow
Cadastre o cliente uma vez e a agenda do mês se monta sozinha, com o valor de cada sessão. Veja quem já pagou, quanto falta receber e cobre pelo WhatsApp.
翻译准备中
尚未检测到更新。GitHub 发布版本后会显示在这里。
个人 GitHub 账号下公开仓库的所有者可以登录并验证所有权,自行管理介绍,无需管理员批准。
登录并生成验证文件,在 30 分钟内将其提交到此仓库的默认分支。其他分支或分叉仓库中的文件无效。然后在下方检查文件,即可无需管理员批准直接管理项目。请保留文件以维持管理权限。
如需登录,将前往登录页面。登录后请回到此处,再次点击所选的验证按钮。
在项目文件夹中运行 /nomorevibe verify,即可验证所有权并自行管理介绍。
一分钟完成验证制作者的介绍仅有上面的一句话。 更多详情请阅读仓库 README。 仓库 README ↗
正在加载完整 README。
查看完整 README ↗Operations app for PHO & CO restaurants (Eastcote, Sydenham) and the Wembley central production kitchen. Built for shared Android phones and tablets on site: staff pick their name, enter a PIN and work through the day's checklists. Owners see every site, resolve alerts and control accounts; operations managers do most of that for the sites they run.
Site tablets only: staff names and the name + PIN sign-in appear only on tablets registered to a site with a one-time set-up code from an owner or operations manager. Any other device shows no names, just a pairing box and a staff ID + PIN sign-in (the full app for owners and operations managers, My shifts for everyone else). Removing a tablet signs out everyone on it.
Sign in with name + 4-digit PIN. 5 wrong PINs (at sign-in, sign-off or PIN change) locks the account for 15 minutes.
Staff management (owners, and operations managers for staff and managers at their sites): add people, sites, roles, sections; temporary PINs that must be changed on first use; reset PIN; mark as left.
Roles, set per site: staff, manager (manager tools for their site), operations manager and owner.
Today screen: the site's checklists for each section (FOH, BOH, Production) with due times, overdue flags, open alerts and handover items.
Checklists: tick items, temperature readings, numbers, text, photo placeholders. Readings are checked against the approved limits:
Sign-off requires the PIN again. Signed records are locked; corrections are added as new entries.
Handover notes between shifts. "Needs action" items stay open until someone closes them.
Owner control (the overview; operations managers see their own sites, without closing them):
Rota and reminders: each site's rota Google Sheet sends its Export, week status (Settings) and Staff tabs every hour through a small Apps Script (Owner → Rota sheets → Connect sheet). Only Published weeks are shown or messaged. Staff sign in on their own phone with staff ID + PIN to a limited My shifts view and turn on notifications: a list when a week is published, a message when a published shift changes, and a reminder at 18:00 the evening before. Nothing is sent 22:00–08:00, except urgent messages (kit not working, P1 tasks), which still go out until midnight, and shift reminders (below). A Supabase schedule (pg_cron) calls /api/cron/tick every 10 minutes.
Shift reminders and replies: every published shift gets one reminder 2 hours before it starts (not before 05:00 unless the shift starts earlier), whatever the hour. It carries what's waiting from handover at the site: action notes (staff notes never; customer complaints only as a count, since they can name a customer) and prep still to do. The owner's Send reminders now button (top of the Owner screen) sends them straight away to everyone starting later today who hasn't had theirs, and shows today's team at every site, who has notifications on, and each reply. Staff answer under the shift on My shifts: On my way, Running late (15, 30 or 45 min) or Can't make it (they're also asked to phone). Late and can't-make-it replies go to the site's managers and owners straight away (if the shift starts within 3 hours, even at night) and show at the top of Today for managers. Replies are append-only: a new one replaces the last.
Handover tab (prep and notes in one place): everything outstanding for the shift on one list, prep items from the last handover and notes together, each ticked Done (who and when are kept; undo within 10 minutes). Notes can be added at any time and show straight away: Needs action notes stay until ticked, For info notes show for that shift and the next, then drop off. Food-safety notes go to the top. At Eastcote the closing shift also does the prep handover from the same tab: one master list in two parts, To do and To prep, in groups (managers edit it under Manage → Handover list; the owner and operations managers can take items off and put them back), tap only what's needed (saved as a shared draft), Next shift / Tomorrow morning / Tomorrow evening, then "everything else is stocked". Anything not done carries into the next handover once, and the manager gets an alert.
Ready to open (Today and the Owner screen): each site has a ready time (Eastcote 12:00, Wembley 08:00, in sites.ready_by). On a day the site has published shifts (and once it has started recording checklists in the app) it shows a light. Green: the opening checks (those due by the ready time) are signed and nothing is in the way. Amber: still getting ready, or kit not working, a warning alert, or someone late or not coming. Red: opening checks unsigned at the ready time, food-safety kit not working, or a critical alert. Red at the ready time messages the site's managers and owners once, with why.
Gas off at close: from 15 minutes before the last published shift at a site ends, the tablet and the closing team's phones show All gas is off. The first tap counts (who, when, and whether on the tablet or a phone; it can't be changed). If nobody has tapped 30 minutes after close, the site's managers and owners are told, whatever the hour, and hear when it's done. Only on days with published shifts, so a site whose rota isn't in the app yet (Wembley today) is never chased.
Yesterday at a glance: at 08:00 owners (all sites) and managers (their sites) get one message covering checks signed and missed, temperatures out of range, alerts, kit, people late or not coming, handover notes, overdue tasks, and whether the gas check was done. Sites that weren't in use that day are left out.
Shift cover: under any upcoming published shift on My shifts, Ask for cover (with an optional reason, which only managers see). Colleagues at the same site in the same section who aren't working (or already covering) then and aren't off are asked; the site's managers and owners are told. Colleagues see it under Shifts you could cover and tap I can cover (or take it back). A manager approves one offer (Manage → Shift cover) or declines with a note, and can cancel an approval later; everyone involved is told. The app never changes the rota sheet: the page tells the manager to move the shift in the sheet, and once the next import shows it moved, the request shows as covered. If the sheet changes the shift first, an open request closes. Requests can be withdrawn while open; nothing is deleted.
Team rota (Rota tab, and "Team rota" on My shifts): the site's week laid out like the Schedule tab in the rota sheet, a grid on a computer and day by day on a phone. Everyone at the site can see published weeks; owners and managers also see paid hours, daily and weekly totals, and draft weeks (marked Draft). Paid hours come from the sheet's Export tab with each hourly sync.
Manager tools (Manage tab for managers; tiles at the top of the overview for owners and operations managers). Managers use them on the shop tablet; staff phones stay limited to My shifts and the team rota.
SOP library (Library tab; "SOPs" on My shifts): PHO & CO's standard operating procedures as numbered steps, each with an optional red warning and a photo (taken or chosen on the tablet, made smaller there before upload, and stored in the database so only signed-in people see it). Managers, operations managers and the owner write drafts; the owner or an operations manager approves and publishes, or sends it back with a note. Nobody approves a version they wrote, changed or sent (the owner may, so they're never stuck), and an operations manager only approves, retires or takes back SOPs for sites they run: the rest go to the owner. Approving publishes exactly the version on screen: if it changed meanwhile, the approver is shown the latest first, and two people saving the same draft can't overwrite each other. Changes not yet saved are kept on the device and offered back if the writer leaves the page or is signed out. Only published versions reach staff. Each SOP has a code that never changes (SOP-BOH-001: one section, or SOP-GEN- for several or everyone), says who must read it (Front of house, Back of house, Production, or everyone), and has a review date (12 months by default). Everyone it's for sees it under SOPs to read on Today and My shifts until they tap "I've read and understood it", once per version: a new version (marked minor update or major change) asks them again. A Step by step view shows one step per screen in big text and keeps the screen on. Managers see who has read each version at their sites. A published version is never changed (the database refuses): editing makes a new draft, and the old version stays readable. SOPs are retired, never deleted, and can be brought back. For privacy, the owner can erase a photo (say it shows someone): it shows as "Photo removed" in every version (and in any other recipe using the same ingredient picture), and the reason is recorded. Photos no SOP uses are cleared away after a week.
Recipe handbook (Library → Recipes, on the shop tablet): prep recipes (a batch: what it makes, ingredients, method, storage and shelf life) and dish specs (what goes in a portion and how it's built), written and versioned like SOPs. Only the owner approves, sends back, retires or brings back a recipe or dish (operations managers and managers write drafts and send them). Each recipe shows as one card that fits the tablet screen, either way round, laid out like PHO & CO's printed recipe cards: a prep recipe has its ingredients as picture tiles, the method as numbered picture steps (past 12 steps, a second panel), then the final result, important notes (one per line, shown as ticks), storage and allergens; a dish has its photo with labels pinned to it ("Protein (generous)"), the serving standard as checks ("NOT over-burnt"), what's in a portion and how it's built, and its allergens. A version that isn't the one in use (waiting for approval, replaced or retired) says so on the card. Print A4 prints the card on one page (a recipe too long for one goes over two, never cut off). Amounts are numbers with units, so the size picker in the card's header makes ½, 2 or 3 batches, any number of portions, or scales to what's to hand ("18 kg of bones"). Writers add a picture per ingredient; a picture taken once for an ingredient is offered again wherever that ingredient appears (by name). A dish's components can link to the prep recipes they use. Every recipe marks all 14 allergens (and E120): contains, can be left out on request (dishes), or free from. A dish can be published with just its allergens, so the matrix can go live before every dish's build is written. Recipes are for kitchen staff and managers only, never on staff phones.
Allergen matrix (Library → Allergens, for everyone, on the tablet or their phone): every published dish, by menu section, with its kitchen notes and dietary tags; "A guest avoids…" shows which dishes are fine, fine only if the kitchen leaves something out, or not for them; it prints. When a dish's allergens change, everyone at its sites sees it on Today or My shifts and confirms they've seen what changed; managers see who has.
Training Academy (Library → Training on the tablet or their own phone; Manage → Training for managers): each section has a pathway of skills in order (front of house, back of house, production), under headings like Operations or Service. A skill can link SOPs and recipes to read (staff only see published ones), a video to watch (a link that opens in a new tab) and a short quiz. A knowledge skill is done when its quiz is passed (or, with no quiz, when they mark it done; not while its quiz is still being written). A hands-on skill is done when a manager watches them do it and confirms it (after the quiz, if it has one): the manager of that section at their site (a head chef for kitchen skills), an operations manager or the owner, never themselves. Quizzes are shuffled every time and marked on the server, so the right answers never reach the phone; people can try again as often as they like, and every attempt is kept with what was asked and answered. Each pathway has deadlines from the day someone starts in that section, or for everyone already working, the day training goes live (induction skills within 7 days and everything within 42, by default); coming back (from leaving or a site closure) starts the clock again for whatever isn't done. A skill can have a refresher (every 12 months, say): it's due by that date, people are told 30 days before, and they can do it again from then. A skill also has to be done again within 14 days when an SOP or recipe it links to has a major change, or when a manager asks for it again with a reason, which the person sees. Tightening a skill later never makes anyone due sooner than is fair, nor clears what's already overdue: shorter pathway deadlines or making a skill part of induction give the new days from the change (but no longer than before), a new or shorter refresher two weeks (but no longer than the old one), a skill moved to another pathway or brought back the pathway's usual days, a first quiz for someone who'd said they were ready two weeks, and linking an SOP accepts it as it is (only a major change after that counts). Overdue skills and ones to do again show on Today and My shifts, and at 9am people get a message when a refresher is 30 days away or due, or a skill is to be done again. Someone waiting for a manager's check is never shown as overdue. Managers see each person's skills passport, a matrix of who has done what at each site, and a Waiting for your check list. The owner and operations managers set the skills, quizzes and deadlines; questions drafted for them aren't asked until one of them approves them. Owners and operations managers have no training of their own. Nothing is deleted: skills and questions are retired (a retired skill can't be changed until it's brought back), and the training record is append-only.
Equipment and maintenance: each site's register of kit (fridges, freezers, fryers, probes and so on) with where it is, who services it and how often. Anyone working at the site reports a problem from the tablet, their own phone, or by scanning the QR label on the kit (Manage → Equipment → Print QR labels); managers are told straight away. "Not working" kit shows at the top of Today and on the Handover tab until someone marks it fixed and says what was done. Managers log services; reminders go two weeks before a service is due and when it's overdue. The weekly report counts problems and hours out of service. The history is append-only and kit is retired, never deleted.
Shift Mode (the Shift tab, and where everyone but owners lands after sign-in): your role + your shift = your screen. The app looks up your shift on today's published rota and shows only that shift's things in time order: the check due now, prep for you or your section, handover notes for you, allergen changes to confirm, training due, the gas check at close if you're a closer, with On my way / Running late / Can't make it under the header. Kitchen (BOH), Front of house (FOH) and Production (PROD) each see their own lane. Not on today's rota? Pick a lane and it shows what's waiting there. Managers see every lane with people on, side by side, and can switch to their own shift; the Owner screen opens with four numbers (urgent, ready to open, prep to do, on shift) and a link to the lanes. The old Today screen stays as "Everything at the site".
Not built yet: Wembley batch codes, labels, dispatch and receiving, and the remaining MVP features. See the PRD.
With no database configured the app runs in demo mode on sample data held in memory. Restarting the server resets the data. Demo mode skips the site-tablet check.
npm install
npm run dev # http://localhost:3000
Demo PINs: owner 4826, everyone else 1357. The demo people are clearly labelled "(demo)". No real staff data is in this repo.
The app uses the database when the server has a DATABASE_URL (Supabase project phoco-ops-hub, London).
DATABASE_URL. For local use, put it in .env.local, which git ignores.DATABASE_URL=... npm run person:add -- --code 001 --name "First name" --access "EAS:owner:FOH,BOH;WEM:owner:PROD;SYD:owner"
Access is SITE:role:SECTIONS, separated by ;. Roles are owner, ops (operations manager), manager and staff. Sections are FOH, BOH and PROD.
| Command | What it does |
|---|---|
npm run dev | Development server |
npm run build / npm start | Production build / serve |
npm test | Unit tests for the rules (temperatures, sign-off, access, rota, PINs, prep, records, reports, notices, time off, certificates, equipment, tasks, shift reminders and replies, the SOP library, recipes, training) and the reminder scheduler on demo data |
npm run typecheck | TypeScript check |
npm run lint | ESLint |
npm run person:add | Create or update a person, their site access and PIN (see above) |
node scripts/build-seed.mjs | Regenerates supabase/seed.sql from data/checklist-library.json |
params, searchParams, cookies() and headers() are asynchronous: always await them.src/lib/domain/ holds the business rules as plain functions with no database. This is the part the tests cover.src/lib/data/ has a Store interface with two implementations: DemoStore (in memory) and SqlStore (Postgres/Supabase). The app uses SqlStore whenever DATABASE_URL is set.supabase/migrations/ holds the database schema, one numbered file per change (0001_core.sql first). Row Level Security is on for every table with no policies, so the public Supabase API can read nothing; only the app server, connecting with the database connection string, can read or write. Checklist answers, corrective actions and the audit log are append-only: a database trigger refuses edits and deletes..env files, staff names, phone numbers or PINs. Real staff data lives only in the database.temp_rules are placeholders until the owner confirms them against the approved HACCP plan.