Two weeks to a demo
Plan · written 4 October 2026 · targets, not commitments · nothing has started
The goal is a web-only MVP that can be shown on 18 October 2026: the proposed demo would take one made-up store from a draft schedule to an employee's day off, with the manager approving the change.
Two weeks should answer whether the whole journey is worth pursuing: a schedule people can understand, and a change they can agree on.
The owner has settled the goal and boundaries: one application, two roles, and the manager approves every change. The first solver is YALPS; the stack is a NestJS API and a Nuxt app organised by CleanSlice. These are accepted directions, not implementations. This demo is web only: Capacitor is a later step, and messengers are outside this plan. Everything else below is a proposal; dates are targets.
What “showable” means
The proposed demo would run in a browser on a laptop, with one illustrative store already filled in and a role switch instead of sign-in. The proposed script, in order:
- The manager would open the store and see its team, rules and hourly traffic already filled in.
- They would ask for next week's schedule. A draft would appear with hourly coverage against traffic, visible gaps and overtime, and a short explanation such as “Ben starts at 10:00 because the lunch peak needs three people”.
- They would change one thing in words — “give Chloe fewer closing shifts” — and see the draft change. Stretch: the first thing to cut if time runs out.
- They would publish the schedule.
- The demonstrator would switch to an employee, see their shifts and ask the assistant: “Can I get Saturday off?”
- The assistant would find who could cover without breaking rest, hours or availability, propose the least disruptive option and ask that colleague.
- The demonstrator would switch to the colleague and accept, then switch to the manager, who would see one ready change and approve it in one step.
- The published schedule would update for everyone.
Every person and number in this demo would be made up; there is no real store. Any illustrative email addresses would use example.com, such as [email protected]. The quoted conversation is illustrative, not output from a system.
In and out of scope
Proposed in scope: the eight steps above, with step 3 as stretch; seed data for one store with about a dozen people, one week, hourly traffic and four templates for sliding shifts. The input rules would cover availability, absences, minimum rest, maximum weekly hours and shift length. The demo would also enforce one shift a day and at least one key holder whenever the store is open, and show the required people per hour. A list of “things waiting for you” inside the app would replace notifications.
Out of this plan: Capacitor and anything mobile; messengers; sign-up, invitations and accounts (the role switch would take their place); real labour law for any country; spreadsheet import (seed data instead, with import only as stretch); point-of-sale or footfall integrations; more than one store; an admin panel; a public website; product hosting and deployment. The proposed demo would run locally with make dev. Nothing would be approved automatically.
The work, in order
The plan assumes one developer working with agents in Orca working copies, one task per copy. If that assumption is wrong, the dates move. The proposed packages below depend on the preceding foundations; they are not promises of daily throughput.
Week 1 — a schedule exists: 6–10 October
| Work package | Depends on | Proposed result |
|---|---|---|
| Day 1: decisions and skeleton | Confirming the choices below | Set up the API and app alongside the docs in this repository, using the registry's reserved root ports: 4182 for the API and 4180 for the app. Extend make dev and the working-copy scripts to start both, with each working copy's own assigned ports. A blank page would talk to a blank API. |
| The store in data | Day 1 choices and skeleton | Describe the store, roles, employees, availability, absences, rules, hourly traffic, shift templates, schedule, shifts and change requests; seed them for the illustrative store. |
| The solver | Seed data and agreed rules | Put YALPS behind the four tools on Agent and solver: build a schedule, check a change, find cover, explain a refusal. Report uncovered hours rather than hide them: allow a visible coverage shortfall, penalised when comparing drafts, while keeping hard rules intact. First prove that a week for a dozen people solves at all; the solver page names this as the prototype's first risk. |
| The manager's screens | Store data, then the solver for generation | Show store, team, rules and traffic with simple edits; generate a draft, compare coverage hour by hour and publish it. |
Week 2 — people talk to it: 13–17 October
| Work package | Depends on | Proposed result |
|---|---|---|
| Explanations | Solver results and refusal details | The agent would turn results into the short explanations from step 2, and refusals into “which hours, which rule, what would fix it”. |
| The employee's screens and the assistant | A published schedule and the solver's check-and-cover tools | My shifts, chat, and the path from a request to proposed cover to asking the colleague. |
| Approval | Proposed cover and the employee screens | The colleague could accept; the manager could decide in one step; the schedule would update. Both roles would have the “waiting for you” list. |
| Changes in words for the manager — stretch | Working generation, explanations and rule checks | Step 3: revise the draft from a request in words. |
| Demo data, script and rehearsal — 16–17 October | The connected flow above | Run through the eight steps twice, fix what breaks and record what was cut. If step 3 is cut, mark it as omitted in both rehearsals. |
| Docs | Evidence of what actually runs | Update Architecture, DevOps and product-page status badges to “implemented, not verified end to end” only for what actually runs. Nothing else changes status. |
18 October 2026 is the target showing. No work package has started.
Proposed choices to confirm on day 1
Every row is proposed; to confirm on day 1. None settles the broader product's open questions.
| Choice | Proposal | Why | What it would cost to change later |
|---|---|---|---|
| Database | PostgreSQL through Prisma, as in our other products; reserve a database port in the registry before use. | Follow a familiar way to store the demo's data. | Rewrite data access, move existing data and revisit the local setup. |
| Language model | Claude API for understanding requests and writing explanations only. It would never build or approve a schedule. Keep templated explanations as a fallback. | Try the conversation while letting the demo survive without a network. | Adapt the request and explanation interface and recheck the demo conversations. |
| Schedule modelling | Four shift templates per day, as on the problem page, instead of free start and end times; one week at a time. | Keep the first experiment small given the size risk described on the solver page. | Rework the scheduling model, seed data and coverage checks. |
| Consent and approval | Colleague consent and manager approval inside the app, demonstrated by switching roles; nothing sent anywhere. | Show the complete agreement without accounts or external delivery. | Adding real identities and delivery would require access checks and a new consent flow. |
Risks and what gets cut first
- YALPS cannot solve a realistic store in acceptable time. Try a coarser model, then a smaller store, then highs-js, the fallback named on the solver page. We have measured no solve time.
- The language model is unreliable on demo day. Use templated explanations and a scripted assistant path for the one demo request; identify the fallback when showing it.
- Time runs out. Cut in this order: the manager's changes in words; preferences and fairness as soft rules; spreadsheet import (if added as stretch); traffic edits; anything cosmetic. Hard rules and manager approval stay.
- The demo convinces nobody. That would be a finding, not a failure. Record it in Open questions.
Definition of done for 18 October
The target is for the eight steps to run end to end on the seeded store from make dev, twice in a row, by someone other than the person who built it; make check must be green and the docs must say what exists. If stretch step 3 is cut, the demo script must say so explicitly; the remaining steps must still pass twice. This is a target, not a claim that anything works today.
Where to go next
- Architecture: the accepted application and API direction beyond this demo.
- Agent and solver: the four tools and the first solver risk to test.
- User flow: the proposed manager and employee journey.
- Open questions: what still needs a decision or evidence.