Screens

Proposal · accepted direction for the structure, nothing designed · 5 October 2026 · roles decided 11 October 2026 · owner sign-up, sign-in by role, accepting an invitation, the owner's stores and people, each role's menu, schedules, requests and Waiting for you built 11 October 2026 · the assistant as a scripted demo built 11 October 2026, replaced by an "In development" tab 14 October 2026 · the assistant turned back on — the live chat with the store's agent where the API says it is available, otherwise a panel that says why — the scripted demo removed and an Assistant section on the store pages, built 19 October 2026, checked against a local Agentfy only · editing schedules, stores and people by hand, the request form and withdrawing a request built 11 October 2026, until the assistant does them · store and person descriptions and a store's hourly load built 14 October 2026 · shift breaks, shift templates and the manager-on-duty warning built 14 October 2026 · several shifts a day for one person (split shifts) built 14 October 2026 · one schedule grid for everyone, with a filter, built 14 October 2026 · a reason with every decline, and who approved a change, built 14 October 2026 · break start times, a day view with receipts, tills and people per hour, a month sheet and printing built 16 October 2026 · the manager's People and store editing built 19 October 2026 · the owner's own assistant on their Assistant tab and the Company assistant section on Stores built 20 October 2026, checked against a local Agentfy only · sign-up as a request to join, approved in the admin app, built 23 October 2026 · "No manager" in the invite and person forms and the owner deciding such an employee's requests built 23 October 2026, not deployed · the company's assistant with Retry on the owner's Assistant tab (a short line when it failed) and why it failed on an approved company's card in the admin app, built 28 October 2026, not deployed · stretching a shift's hours on the day view with the mouse, a finger or the keys built 28 October 2026, not deployed · the owner's list of positions (People → Positions), and a person's position picked from it instead of a typed title, built 30 October 2026, not deployed · the week grid's totals under each day and its people grouped by position built 30 October 2026, not deployed · the printed week as the grid on screen, and A4 landscape for every view, built 30 October 2026, not deployed · a red dot on a position whose people leave some opening hours uncovered built 4 November 2026, not deployed · the week beside the assistant's chat, with a schedule card's changes on it, built 4 November 2026, checked with a fixture card in a browser, not deployed · the assistant asks for missing descriptions before it builds a week, built 5 November 2026, tested against an in-memory Agentfy, not checked with a live agent, not deployed · adding a position from the person's dialog and the invitation form built 5 November 2026, checked in a browser, not deployed · an arrow on a shift in the week that opens its day with the shift outlined, built 5 November 2026, checked in a browser on a working copy, not deployed · the day view grouped by position like the week, with the day's red dots, built 5 November 2026, checked in a browser on a working copy, not deployed

The proposed application has twenty screens: five for signing in and the account, nine for the manager and six for the employee — a list of what each would show and allow, not a design.

One application, two roles; the role decides which screens a person sees.

How to read this

Each screen says who it is for, what it shows, what the person can do there, the states it has, and when it is needed: in the demo planned for 18 October or after it. The numbers are stable, so other pages can refer to "screen 11".

• Every screen would have a loading state and an error state that says in plain words what failed and offers to try again. They are listed below only where they differ.
• “Demo plan” means the screen is part of the plan for 18 October, where one made-up store is already filled in and a role switch stands in for sign-in. Whether the demo keeps the role switch is still the plan's choice to confirm; the screens here are the target, and the plan's scope is unchanged.
• “After the demo” means the plan leaves it out on purpose.
• Steps refer to the loop on the user-flow overview. Behaviour is described on the product pages and only placed on a screen here. Where no page describes the behaviour, the screen says so and points to Not designed yet.

All people, shifts and conversations below are made up.

Sign-in and account

All five come after the demo. Sign-in is Shiffty's own — email and password kept by Shiffty's API, as in our other products, not Neon Auth; decided on 6 October 2026, see Open questions.

Since 11 October 2026 there are three roles — the owner, who has the business and its stores; managers, each in one store; and employees, each reporting to one manager (decided that day). The screens below were written for two roles; the owner's screens are not on this list yet.

Built so far (11 October 2026), not deployed: a plain version of screen 1 (an owner, their business name, email and password), screen 2 (sign-in that lands each person in their role's part of the app) and screen 4 (accepting an invitation); for the owner, the list of stores with a page per store (screen 6) and the list of people with inviting and withdrawing (part of screen 8). Each role has its menu — the owner Assistant, Stores, People, Schedules and Requests; a manager Assistant, Schedules and Requests; an employee Assistant, My shifts, My requests and Waiting for you — and since 19 October 2026 a manager's or an employee's Assistant tab is the live chat with their store's agent when the API says the assistant is available to them, and otherwise a panel that says why; the owner's says there is no assistant for the owner yet (screens 13 and 16, and the owner's; from 11 October it was a scripted demo with no agent behind it, and from 14 to 19 October each tab said "In development"). Schedules are on screen 11 for the owner and the manager, and screen 15 for the employee. Requests are decided on screen 12 — by a manager for their employees and by the owner for the managers — and people follow their own on screens 17 and 19; in the assistant's chat (13, 16) a proposed change becomes a request only when the person confirms its card, and it still needs a decision. Everything the assistant does or would do can also be done by hand (the owner's direction of 11 October 2026): weeks and shifts on screen 11, a store on screen 6, a person on screen 8, a request from screens 15 and 17. Who may edit what is on Data structure. Screen 3 (password reset) is built in a plain form since 15 October 2026; screen 5 and the manager's and employee's other screens are not built. See What is built.

1. Sign up

• Who: an owner starting a company. Employees never sign up on their own — see screen 4.
• Shows: a form for the person and their business (the company); the first store would follow.
• Can do: create the account and the company in one go — built in this form. Since 23 October 2026 (the owner's decision) this sends a request to join: the form adds an optional phone number and number of stores, and ends on "Request sent"; a platform administrator approves or declines it on Requests in the admin app, and the owner gets an email either way. Creating a store as part of signing up, and with it the store's agent, is not built; see Agentfy integration.
• States: the email is already in use (after a declined request the same email may ask again); the request is sent and waits for approval; the store was created but its agent is not ready yet — the owner can go on, and the assistant screens say so.
• When: after the demo.

2. Sign in

• Who: everyone.
• Shows: email and password.
• Can do: sign in; go to password reset. An owner whose request to join is not approved yet is told it is being reviewed, and one whose request was declined is told so, with the administrator's reason; everyone of a company a platform administrator switched off is told that (built 23 October 2026). The owner lands on the list of stores (6); a manager on the store home (7); an employee on My shifts (15). What is built lands each on their role's Assistant tab when the assistant is available to them, and otherwise on Schedules (the owner, a manager) or My shifts (an employee); the owner, who has no assistant, always lands on Schedules (19 October 2026; from 14 to 19 October each landed on an Assistant tab that said "In development").
• States: wrong email or password; the account exists but has no active place in any store.
• When: after the demo. The demo plan uses a role switch instead. Built in a plain form (11 October 2026); the link to password reset since 15 October 2026.

3. Password reset

• Who: everyone.
• Shows: a field for the email, then a field for a new password.
• Can do: ask for a reset link, set a new password.
• States: link sent — said the same whether or not the email has an account; link used or expired.
• When: after the demo. Built in a plain form on 15 October 2026: the link comes by email, works once for an hour, and setting the password signs the person out everywhere.

4. Accept an invitation

• Who: a manager or an employee the owner invited to a store.
• Shows: the store's name, the company, the role they are invited to, whom they will report to, and a field for a password.
• Can do: open the link the owner passed on, set a password and land on their role's page. There is no self-service sign-up for managers or employees: an invitation is the only way in.
• States: the invitation has expired or was withdrawn; it was already used; the link is not valid. An email that already belongs to someone cannot be invited — each person has one place.
• When: after the demo. Built in a plain form on 11 October 2026; since 15 October 2026 the link is sent by email, and the owner can still copy it once from their page to hand it over.

5. Profile

• Who: everyone; the employee's entry to it is screen 20.
• Shows: name, language, password.
• Can do: change them; sign out.
• States: saved; not saved, with the reason.
• When: after the demo.

Manager

Desk width first: the schedule is a wide table, and the manager can also work in a browser. Every screen still has to be usable on a phone.

6. Stores

• Who: the owner. A manager has one store (11 October 2026) and never sees this list.

• Shows: the company's stores, each with this week's state: published or not, how many decisions are waiting.

• Can do: open a store; add one — name, address, opening and closing time and the store's time zone.

• States: no store yet.

• When: after the demo; the plan has one store. Built for the owner on 11 October 2026: a card per store with its address, hours, time zone, how many managers and employees it has, this week's scheduled hours (the week of the store's own zone) and who its managers are, and a page per store listing its managers and its employees, each employee with the manager they report to. Since the requests were built, a card also says how many managers' requests wait for the owner ("1 waiting"); whether the week is published is not shown yet. By hand (11 October 2026), until the assistant does it: a new store goes to the end of the list; a store's page has Edit store — name, address, opening hours, time zone and status. New hours that live or upcoming shifts would fall outside are refused and those shifts are named; a new time zone says that shifts keep their times. A store's page also lists people who were made inactive, dimmed, so the owner can make them active again. Since 14 October 2026 Edit store also has a Description — plain text, up to 4,000 characters, context for the assistant later — and the store's page shows it, with the store's Hourly load beside it (screen 10). A manager reaches the same two sections, the description read only, from Store profile on their Schedules. Since 19 October 2026 the store's page and the manager's Store profile also have an Assistant section: the store's agent and Connect assistant (screen 14).

• Built 20 October 2026, not deployed: the Company assistant. At the top of the owner's Stores list a Company assistant section shows the owner's own agent — Not connected, Setting up, Ready or Failed with the reason — with Connect assistant or Retry, the same way a store's page shows the store's (screen 14). A store's assistant has to be connected first; until then connecting is refused with that reason. Checked against a local Agentfy only.

7. Store home

• Who: the manager.
• Shows: this week's coverage at a glance — which days are fully covered and which have a gap or overtime — and the list of decisions waiting.
• Can do: go to the schedule (11) or straight to a waiting request (12).
• States: no schedule for this week yet, with one action: go and build a draft; nothing to decide; the store is not described yet, with a pointer to screens 8–10.
• When: demo plan, in a simple form. Steps 3 and 7 of the loop.

8. Team

• Who: the manager.
• Shows: the list of employees and pending invitations. An employee card holds what Input data lists: roles and skills, contracted hours, availability, absences and preferences.
• Can do: add or edit a person; invite them; withdraw an invitation; record an absence. Since 11 October 2026 inviting is the owner's, and a manager sees which people report to them; since 19 October 2026 (the owner's decision) a manager also invites employees to their own store.
• States: an empty team; an invitation sent, accepted or expired.
• When: the list and the card are in the demo plan, filled in beforehand, with simple edits. Invitations come after the demo. Built on 11 October 2026 for the owner, as the People screen: everyone in the company with their role, store, manager, this week's shifts and hours, and status, filtered by role and store, the invitations still open, and inviting from there or from a store's page. The link is shown once, to copy; it can be copied again only in the same browser tab, because the API keeps no copy of it. The manager's People (19 October 2026): their store's managers and employees with role, manager, this week and status — inactive people last, dimmed — and the store's open invitations below; Invite employee opens the invitation form with the role and the store fixed. Opening an employee changes whom they report to and their status (deactivate, reactivate), as well as the description, and for their own people the title and weekly hours; a manager's row and their own open read only for those fields. A manager withdraws an employee's invitation, not a manager's. By hand (11 October 2026): the owner opens a person on People or on a store's page and changes their title, weekly hours, whom they report to and status; making someone inactive with shifts after today first lists those shifts, and "Remove N shifts and deactivate" confirms. A manager opens one of their own people from their name in the week's grid and changes the title and weekly hours. Role and store are not changed by hand. Since 14 October 2026 the person's dialog and the invitation form have a Description — strengths, skills, limits, as context for the assistant later. The owner writes it for anyone; a manager opens any employee of their store from the grid and writes theirs (the title and weekly hours stay their own manager's); nobody writes or reads their own. Step 1 of the loop. Positions (30 October 2026, the owner's request): a person's title is no longer typed. The owner keeps the business's list on People → Positions (the People tab stays lit): each position with its name, how many people hold it and its description — context for the assistant — with Add position, Edit, Archive and Restore, and no delete. One list for every store. The invitation form and the person's dialog have a Position select of the active ones, or "No position"; someone who holds an archived one sees it marked archived and keeps it. With an empty list the field says where positions come from — for the owner a link to Positions. Since 5 November 2026 (the owner's request) the owner does not have to leave the form for a missing position: New position beside the field opens the same small form as on Positions — a name and an optional description — over the person's dialog or the invitation; once it is added it is in the list and chosen, and what was already typed in the form stays. Cancel leaves the field as it was; a name the business already has is refused in that small form with the reason. A manager picks a position for their own people and cannot change the list, so they do not see New position. The week grid, the day view, the month sheet, the store's page and the account menu show the position's name where they showed the title.
• Not designed: how an absence the manager hears about first — a sick call in the morning — changes a published schedule. See Not designed yet.

9. Rules, opening hours and shift templates

• Who: the manager.
• Shows: opening hours, the store's rules — rest, maximum hours, shift length, breaks, minimum staff per role — and the shift templates the schedule is built from. The fields are on Input data.
• Can do: edit them. The store states its own rules; no legal rule set is supplied.
• States: nothing entered yet. What happens to an already published schedule when a rule changes is not designed.
• When: demo plan, filled in beforehand, with simple edits. Step 1.
• Built (14 October 2026), shift templates only, not deployed: a "Shift templates" section — on a store's page for the owner, under the weeks on Schedules for a manager — lists the store's templates, each with its name and "09:00–18:00 · 1 h break · Sales floor"; Add template (name, start, end, break in minutes, area or none), edit, ↑ ↓ to reorder and delete (a second click confirms). Up to ten. A template that the store's opening hours no longer fit is marked "Outside opening hours" and is not offered. Since 16 October 2026 a template may say when its break starts ("09:00–18:00 · 1 h break 13:00–14:00"), copied into the shifts made from it. The store's rules are not built.

10. Traffic by hour

• Who: the manager.
• Shows: how busy the store is by hour and day, and where the numbers came from: a footfall counter, till receipts or the manager's own estimate.
• Can do: view and edit the numbers.
• States: no traffic yet — without it a draft cannot follow the busy hours.
• When: viewing is in the demo plan; editing is among the first things the plan would cut. Step 1. How traffic becomes a number of people per hour is open. Built on 14 October 2026 in a simple form, as the Hourly load section of a store's page: the usual till receipts for every hour the store is open, Monday to Sunday, typed in by hand; empty is unknown; Copy Monday to all days. The owner and the store's managers edit it. Hours outside the opening hours are kept and not shown. Only till receipts, no other source. Since 16 October 2026 the section also holds Receipts per cashier per hour (80 unless changed, edited with the load), and the schedule's day view reads both (Schedule).

11. Schedule

• Who: the manager.
• Shows: a period picker; whether the manager is looking at the draft or the published schedule; who works when; coverage hour by hour against traffic, with gaps and overtime visible; next to the draft, its explanations in plain words (“Ben starts at 10:00 because the lunch peak needs three people”).
• Can do: build a draft for the period — a button, not a request to the assistant; edit shifts directly; publish. Every direct edit would be checked against the same rules as the draft.
• States: no draft for the period yet; a draft being built; no valid schedule exists — the screen says which hours are uncovered, which rule is in the way and what would fix it, and the manager decides; a draft that differs from the published schedule; published.
• When: demo plan. Steps 2 and 3. Read Schedule generation.
• Built (11 October 2026), read only, not deployed: the manager's list of their store's weeks — draft, published, live or past, with the shifts, hours and overtime (of the team or of the managers until 14 October 2026; of the whole store since) — and one week as a grid of who works when; the owner sees the weeks of any store the same way. Times are in the store's time zone, and the screen names it. Requests show on the grid: a change waiting (peach, with a note such as "Swap → Chloe"), the shift a colleague would take (striped, "Covers Maya") and an approved change (mint, "Swapped in", "Time off"), with who approved it — "Approved by Daniel Okafor", or "Approved automatically" when no person did (14 October 2026); the shift's dialog says the same ("Hours changed · Approved by Daniel Okafor"). A waiting change is shown only to the people it concerns — whoever decides it, made it or was asked — and an approved one to everyone who sees the schedule. The manager's week has a "2 changes waiting" button to Requests, and the list of weeks notes "2 changes waiting for you" or, for a past week, "1 change approved". The coverage by hour and the explanations are not built.
• Built by hand (11 October 2026), until the assistant does it: "New week" makes a week empty or as a copy of the week before (a manager's copy brings the employees' shifts only), and the week opens as a draft with what was copied. In the grid a day is a button: a shift opens it, an empty day adds one. A small dialog holds the start, the end (within the store's hours, shown with its zone) and the area; as they change it shows the rule that would refuse them, or the warnings that do not block — less than 11 hours' rest, more hours than the contract — and an existing shift can be deleted. On a phone a day's row opens its shift and "Add a shift" picks the person. A shift with an open request carries a lock and cannot be changed. "Publish" (until 14 October 2026 "Publish to team") publishes a draft, for everyone in the week. The owner steps through a store's weeks with ‹ › and edits every row; a manager edits the employees' rows, and the screen says "The managers' schedule is the owner's" over the managers' rows. Past weeks say they are read only.
• Built (14 October 2026), not deployed: a shift has a break: the dialog has "Break, minutes", a cell shows it on its small line ("1 h break"), and hours everywhere are the hours worked. The dialog offers the store's shift templates on top; picking one fills the times, break and area, which stay editable. An empty day opens a menu of the templates — one click adds that shift — and "Other times…" for the dialog. Above the grid one line says on how many days no manager is on duty for part of the opening hours; it opens to the days ("Tue: no manager on duty 06:00–08:00, 20:00–22:00"). "Publish" now asks first and lists those days, then publishes anyway: the warning does not block.
• Built (14 October 2026), not deployed: split shifts. A person may work up to three shifts a day, such as 12:00–14:00 and 18:00–20:00 — one regulation the owner studied uses 4 h morning and 4 h evening part-time shifts. A day in the grid lists its shifts one under another by start time, each with its own small line and each opening its own dialog; a day with room for another showed a small "+" on hover (always on a touch screen), with the templates menu as on an empty day — until 5 November 2026, when an arrow to the day view replaced it and another shift is added in the day view (below). The dialog lists the person's other shifts that day, and a new shift starts where the last one ends. A shift that overlaps another of that person's shifts that day is refused ("This overlaps another shift of this person that day. Shifts on one day may meet (one ends at 14:00, the next starts at 14:00) but not overlap."), and so is a fourth ("This person already has 3 shifts that day, the most one day can hold."). On a phone a day's row lists every shift, each opening its own, and "Add a shift" offers anyone with room for another that day. The demo data has one: Sara Lind, Riverside's draft week, Monday 12:00–14:00 and 18:00–20:00 on the checkouts.
• Built (14 October 2026), not deployed: one grid for everyone, with a filter. The owner decided that a week is one table: the store's managers first, under a light "Managers" label, then its employees under "Employees", each with their hours; the Team and Managers tabs are gone. Over the grid, next to the week, a filter chooses whose rows are shown: Role (All · Managers · Employees), Reports to (a manager, with the people who report to them), People (several, searched by name) and Area (people with at least one shift there that week). The parts combine; "3 of 10 people" counts what is shown, "Clear" brings everyone back, and a filter that leaves nobody says "No one matches the filter." While someone is hidden, a line says that hours, totals and the manager-on-duty warning are still the whole store's — they are never counted for the filtered rows only; the totals under each day of the week grid, since 30 October 2026, are the one exception (below). The filter is in the page's address, so a filtered view can be shared, survives a reload and stays when the week changes; an old link to the managers' tab opens with Managers chosen. A manager gets the same filter on their week, over the same people they saw before: the managers' rows are read only. On a phone the day's list carries the same two labels. There is one "Publish" for the whole week. "Ask assistant to adjust" was hidden from 14 October 2026 and is gone since 19 October 2026, as are the owner's "Ask assistant" and the manager's "New schedule": the assistant has no tool to draft or change a schedule, so weeks are made and edited by hand ("New week"). Since 19 October 2026 a manager's week has Ask the assistant while the assistant is available to them, which opens the Assistant tab asking about that week's team schedule (screen 13).
• Built (16 October 2026), not deployed: Week | Day | Month, and Print. A switch over the grid chooses the view; it is in the page's address with the day or the month, like the filter. Day shows one day of the week shown, picked from its seven days, as the chain's day sheet the owner showed us: people down, the store's opening hours across, one column an hour ("06:00", "07:00", …), and each shift a bar drawn to the minute — a shift from 09:30 fills half the 09:00 column; a split day is two or three bars on one row. A break with a known start is a hatched part of its bar; one without is noted in the Break column ("30 min · time not set"), not drawn. Each row has the person's name (since 5 November 2026 under their position's subheading, below), and on the right the day's worked hours, first start, last end and break. Above the people, four rows for the whole store whatever the filter hides (a line says so when someone is hidden): Receipts per hour from the hourly load ("—" when unknown), Tills needed, On checkout and On shift (all), in person-hours with one decimal (2.5); an hour with fewer on checkout than tills needed is peach. How they are counted is on Data structure. Editing is as in the week: a bar opens its shift, an empty hour offers the store's templates or "New shift from 10:00…", a manager's view keeps the managers' rows read only, and past weeks are read only. On a phone the timeline scrolls inside its card and the names stay in place. Print prints the view shown — week, day or month — on A4 landscape, without the app's menus. Since 30 October 2026 (the owner asked for it) the printed week is the grid on the screen at any page width, never the phone's one-day list: the store, the week's dates and status on top; the day headers with their totals repeated on every page; a person's row never split across two pages; the table scaled down to fit a page narrower than it (portrait chosen in the print dialog, or a browser that ignores the page size).
• Built (28 October 2026), not deployed: stretching a shift on the day view. Where the person viewing may edit a bar — the owner every row, a manager their store's employees, not in a past week and not on a shift with an open request — each end of the bar is a handle (the cursor turns into ↔): dragging the left end moves the start, the right end the end, in steps of 15 minutes; with a mouse or pen, dragging the middle of the bar moves the whole shift and keeps its length (a finger on the middle scrolls the timeline instead). While dragging, the bar and its time, Total, From and To, and the On checkout and On shift (all) rows follow; Esc puts the bar back. A handle can also be focused: ← and → move it by 15 minutes, Enter saves, Esc or leaving it cancels. The drag stops at the store's opening and closing times and at the person's other shifts that day — a bar may meet the next one (14:00 and 14:00) but is never dragged into it (owner, 28 October 2026) — and a shift keeps at least 15 minutes; every other rule is the same as in the shift form, checked by the API on release: the new times are saved at once (only the times — the break stays as it is), the line above the timeline says what was saved and any warnings (rest, weekly hours), and a refusal — a break that no longer lies inside the shift, say — is shown under the row in the API's words, with the bar back where it was. Employees see no handles.
• Built (16 October 2026), not deployed: the month sheet. Month shows ‹ October 2026 › with the same filter over the rows: every Monday-to-Sunday week that touches the month, up to six, its days grouped under the week's dates and status (Published, Draft, No schedule); days of the months before and after are dimmed. A cell writes the day's shifts as the printed sheet does ("09–18", split shifts one under another), with a dot for an approved change; empty is a day off, and a week without a schedule is shaded. On the right, for the calendar month only: shifts, hours, days off and the contract (weekly hours × days ÷ 7, see Data structure). It is read only: a cell of a week with a schedule opens that week's day view on that day. Printed, it fits one landscape page in small type, for the staff-room wall. Creating or publishing several weeks at once is not part of it.
• Built (30 October 2026), not deployed: totals under each day, people grouped by position. The owner asked for both. Under each day's header in the week grid — "Mon 26" — a small line says how many people work that day and their worked hours, "6 people · 46 h" (shift lengths minus breaks, as in the Hours column), or "No one"; under Hours, the week's. Unlike the title's hours they count only the rows the filter shows — the owner's choice — and a line under the filter says so while someone is hidden. A person counts on a day with at least one shift; the shift a colleague would take and "Off" are not shifts and count for nothing. Inside Managers and inside Employees, people are grouped under a small subheading per position (the owner's list of positions), positions by name — the list has no order of its own — and "No position" last; inside a position the order is as before. An archived position stays a group under its name while someone holds it. On a phone the chosen day's line carries the same total ("Friday, Oct 30 · 6 people · 46 h" on a manager's week) and the day's list the same subheadings; printed, a subheading stays with the first person under it. The month view keeps its order and shows the position under each name, as before; the day view is grouped the same way since 5 November 2026 (below). Like the rest of the app, the labels are in English.
• Built (4 November 2026), not deployed: a red dot on a position that leaves hours uncovered. The owner asked for it. In the week grid a position's subheading ("Loader") ends in a small red dot when, on some day of the week, part of the store's opening hours — however short — has none of that position's people on a shift. Hovering or focusing the dot says on how many days: "Not every hour is covered on 2 days"; nothing more. Everyone who holds the position counts, managers and employees alike, in any area, so two people's shifts add up and a position under both Managers and Employees shows the same dot; breaks do not open a gap, as in the manager-on-duty warning. It counts the whole week whatever the filter shows, in a draft and a published week alike; "No position" has no dot. Opening hours are the store's, the same every day, as the store's page sets them; the store has no closed days to leave out yet. The dot prints with the grid, the words do not. It is on the grid from tablet width up, not on the phone's one-day list. It is guidance: it blocks nothing.
• Built (5 November 2026), not deployed: from a shift in the week to its day. The owner asked for it. In the week grid, hovering or focusing a shift shows a small round arrow → on its corner, where the "+" used to be (always shown on a touch screen); it is there on every shift of the Schedules screens, the owner's and the manager's, in a draft, a published and a past week alike, including rows the viewer may not edit. Clicking the arrow opens the Day view of that date in the same store and week, with that shift's bar outlined in ink with a thin white gap; if the bar is below the bottom of the screen the page scrolls down to it, and if the day's timeline is wider than the screen it scrolls across to it. The outline stays until the next click anywhere, or Esc. The page's address carries the shift ("…?view=day&day=2026-11-07&shift=…"), so a reload shows the outline again and Back returns to the week; choosing another day or view drops it. Clicking the shift itself still opens its dialog. The "+" that added another shift to a day that already has one is gone from the grid: a second or third shift is added in the Day view, from an empty hour of the person's row (the templates menu or "New shift from 08:00…"); an empty day keeps "+ Add", and on a phone "Add a shift" stays. Not shown: on the phone's one-day list (it has no "+" either), in print, and in the week beside the assistant's chat, which is a read-only preview of a card. A shift the filter hides is not outlined. Checked in a browser on a working copy with the demo data, the owner's and a manager's week; not deployed.
• Built (5 November 2026), not deployed: the day view grouped by position. The owner asked for it: "the same split by position on the day screen as on the week screen". Under the four store rows the day's people are listed exactly as in the week grid: a Managers and an Employees label row, inside each a small subheading per position, positions by name and "No position" last, and inside a position the same order as in the week — so a person is found in the same place in both views. Everyone the filter shows is listed, with or without a shift that day; people are not reordered by start time. The position no longer stands above each name, since the subheading says it. A subheading ends in the week's red dot when, on this day, part of the store's opening hours has none of that position's people on a shift — the same rule as the week's dot, for one day, counted over the whole store whatever the filter shows; hovering or focusing it says "Not every opening hour is covered this day". The labels stay at the left edge when the timeline scrolls across on a phone, and the dot is shown there too (in the week it is not on the phone's list). Printed, the groups print with the day, a subheading stays with the first person under it, and the dot prints without its words. A shift opened from the week's arrow is still outlined and scrolled to. Checked in a browser on a working copy with the demo data, as the owner and as a manager; not deployed.
• Built (16 October 2026), not deployed: when a break starts. The shift dialog has "Break starts" next to "Break, minutes" — optional, and the whole break has to lie inside the shift — and a shift reads "1 h break 13:00–14:00" where the time is known.

12. Requests

• Who: the manager.
• Shows: the queue of change requests. Each one arrives as a single ready-made change with the facts behind it: the shift, who would take it and that they agreed, which rules were checked, what it would cost — overtime or a gap. A request nobody can cover arrives with who was checked and why each option failed.
• Can do: approve or reject in one step. Approving updates the published schedule.
• States: nothing to decide; waiting for a decision; decided; a request that stopped being valid because the schedule changed in the meantime — it is checked again, not approved blindly.
• When: demo plan. Steps 7 and 8. Read Employee assistant.
• Not designed: what the employee is offered after a rejection, and what the manager can do with a request nobody can cover beyond rejecting it. See Not designed yet.
• Built (11 October 2026), not deployed: for a manager, the requests of the employees they decide for; for the owner, the managers' requests and, since 23 October 2026, those of employees with no manager ("Managers’ requests, and those of employees with no manager. Other employees’ go to their manager."; until then "Employee requests go to their store manager"). An employee with no manager reads "The owner decides." on My requests and in the request form; the owner's invite and person forms offer "No manager" in Reports to (a manager's do not: only the owner leaves an employee without a manager). Waiting · N and Decided · N; a card per request with its chip; the open request with the requester's own words, Now and If approved, what was checked (✓ or !), and Approve or Decline — afterwards a line with Undo while the week is not over. Approving checks the shifts again and changes them in one step; if the schedule changed since, it says so and changes nothing. The check lines are the demo's prototype texts or the API's fixed checks, not the assistant's. Since 19 October 2026 the list says "Checked against the store's rules. You decide." (until then "Checked by the assistant. You decide.") and the open request's checks are headed "Checks" (until then "What the assistant checked"): they are the API's own rules, the same for every request. The counts on the Requests tab update after each decision. A manager's Requests has three parts (11 October 2026) — To decide, My requests and Waiting for you — because the prototypes' menu stays Assistant · Schedules · Requests; the tab's badge counts what they decide and what waits for their answer. A withdrawn request leaves the list. Since 14 October 2026 a request that would leave part of a day without a manager on duty says so among its checks, worked out when it was made. Since 14 October 2026 a decline always says why: Decline opens a small dialog with a required Reason (3 to 500 characters; "Maya will see this."), and its Decline button stays off until the reason is long enough. A declined request shows that reason on its card under Decided and under the decision line, where Undo clears it. Every decided request also says who decided it — "Approved by Daniel Okafor", "Declined by Alex Morgan", or "Approved automatically" (14 October 2026).

13. Assistant, the manager's side

• Who: the manager.
• Shows: a chat with the store's agent — the same agent the employees talk to, answering with the manager's rights.
• Can do: ask about the schedule in words; ask for a change to the draft (“give Chloe fewer closing shifts”).
• States: an empty conversation with a few example questions; the assistant is unavailable — the schedule and the requests keep working without it, because they live in Shiffty.
• When: changes in words are the stretch item of the demo plan, the first thing to cut. Step 3.
• Built 19 October 2026 (the owner's decision: the assistant is on again, for good), checked against a local Agentfy only, not deployed: whether the assistant is shown is the API's answer, not a switch in the app. When the API says it is available — Shiffty is connected to Agentfy, chat is on and this store's agent is ready — the manager's Assistant tab is the live chat with the store's agent: suggested questions, a thread kept between visits, and the composer. It can read the manager's own shifts and their store's week, check a change, find who could cover, explain a refusal, submit the manager's own change request and say where their requests stand (the tools). A proposed change is a card; it becomes a request only when the manager presses Send request, and it still has to be decided — the owner decides a manager's. It cannot draft or change a schedule. When it is not available the tab says why, in plain words: Shiffty is not connected or chat is off — a platform administrator turns it on in the admin app's Settings; or this store's assistant is not ready — with a link to Store profile to connect it or retry (screen 14). Then every "Ask the assistant" link is hidden. The owner's Assistant tab (since 20 October 2026, the owner's decision) is the live chat with the owner's own agent when it is available — the same chat, named after the company, with suggestions such as "What is short next week across stores?"; its cards lead to the store they are about. Until then (19–20 October 2026) it said that the assistant served store teams only. When the owner's assistant is not ready the tab says so and, since 28 October 2026, shows the Company assistant section itself — its status, a short line when a setup failed ("could not be set up … press Retry later", without codes; the full reason is in the admin app), and Connect assistant or Retry; until then it linked to Stores (screen 6, the owner's assistant).
• The week beside the chat (the owner's request of 4 November 2026; built that day, checked in a browser with a recorded solve_week card rather than a live agent, not deployed). When the assistant proposes a change to a week — a new week, a change to shifts or the solver's plan — the chat moves to the left and that week opens on the right, as the same grid as Schedules: day totals, managers and employees grouped by position. On it, before anything is confirmed, the card's changes are drawn on top of the week: a new shift outlined green and marked “New”, a changed one outlined with what it was (“was 08:00–16:00”), a removed one struck through and faded, with a legend; the totals are the week as it would be. A week that does not exist yet shows as it would be created. The week shown is not guessed in the app: Shiffty tries the card's own confirmation, with every rule, and throws the result away, so the week is exactly what confirming would write; if confirming would now be refused, the week says “Out of date” and why. A newer card replaces the week on the right; Show week on any card shows its week; the week closes with ✕ and the card opens it again. After the card is confirmed the week reloads as saved, without the marks; after No, the week as it is. The week is read only — Open in Schedules leads to it for editing — and shows only what the person may see: a manager their store's week. On a phone the week covers the chat, with Back to chat. The same on the owner's Assistant tab, for the store the card is about.
• Descriptions first (the owner's request of 5 November 2026; built that day, tested against an in-memory Agentfy, not checked with a live agent, not deployed). Asked to build a week, the assistant first looks at the descriptions — the store's, the positions' and the people's. If one is missing it builds nothing and says so plainly (“the store has no description”, “no description for: Viktor, Sergey”), and asks for what a week needs: how many people on the checkout and on the floor and when, a position's usual shifts and working days, a person's days off and hours. It asks the same when a description is there but leaves that out. The answer becomes a card that adds the manager's words to the description, and the week is built after the card is confirmed. A position's description is the owner's: the assistant says so, and the owner's assistant writes it. Only when the manager says to build without it does the assistant build, and then the answer and the card say which descriptions were missing (the quoted lines are what the assistant is told to say, not a recorded answer). The same on the owner's Assistant tab.
• From 14 to 19 October 2026 (the owner's decision of 14 October): the manager's Assistant tab, like the owner's, showed only the title, "In development" and one sentence: until it is ready, everything is done by hand in the other tabs. "New schedule" and "Ask assistant to adjust" were hidden; a manager's empty Schedules offered "New week" instead, as it still does.
• Built (11 October 2026) as a scripted demo, not deployed, not shown from 14 October 2026, removed from the code 19 October 2026: there is no agent and no free text. A few fixed questions — the four suggestions, or the same words typed — get scripted answers filled with the store's real data: the draft for the week after next (shifts, hours, overtime) with a link to it; the oldest request waiting for the manager, with Approve, Decline and Details that decide it for real — Decline asks for a reason in the same dialog as Requests (14 October 2026), and the card then shows it; the manager's own request to the owner and where it stands; who works the evening checkout on the next Thursday and who is off that day and still within their weekly hours; a list of the requests waiting. Anything else gets "I'm a demo and can't understand free text yet" and the suggestions. The assistant drafts nothing, asks nobody and changes nothing by itself, and a line under the chat says so. The empty screen shows how many requests wait for the manager, with a link to Requests. The owner's Assistant tab is the same kind of demo: the manager drafts of every store for the week after next, each store's scheduled hours next week against its people's contract hours, the invite form filled in for a manager, and the oldest manager request to decide. The buttons "New schedule" and "Ask assistant to adjust" open this tab with their question. The conversation lasts until the page is reloaded.

14. Settings

• Who: an owner or a manager.
• Shows: the company, the store, and the state of the store's agent: being created, ready, or failed.
• Can do: rename the company or the store; try again if the agent could not be created.
• States: the agent is not ready — the reason is shown in plain words.
• When: after the demo.
• Built 19 October 2026, not deployed: the store's assistant. Not a Settings screen: an Assistant section on the owner's store page and on the manager's Store profile shows the store's agent — Not connected, Setting up, Ready or Failed with Agentfy's reason in words that are safe to show, and a note when the agent still runs on an older setup because updating it failed. The owner and that store's managers have Connect assistant, or Retry after a failure. Setting up moves on only when the page asks again, so while it says "Setting up" the page asks every 3 seconds, at most 20 times (about a minute), and stops when the agent is ready or failed or the page is left; after that it says "Still setting up" with Check again. When Shiffty itself is not connected to Agentfy, the section says that a platform administrator connects it in the admin app's Settings, and shows no button. Renaming the company or the store here is not built.

Employee

Phone width first: an employee would mostly open the application on a phone.

15. My shifts

• Who: the employee.
• Shows: their shifts in the published schedule, a week at a time.
• Can do: move between weeks; start a request from a shift, which opens the assistant (16).
• States: no published schedule for this week yet; no shifts this week.
• When: demo plan. Step 4.
• Built (11 October 2026), not deployed: this week and next, one card per day with the time, the area and the hours or "Off", today marked, and the next shift; days and times in the store's time zone. A day with one of the person's requests waiting shows "Swap pending" (or "Time off pending", "Change pending"); an approved change shows as the new shifts, in mint, with what changed and who approved it ("Swapped in · Approved by Daniel Okafor"; a day it took a shift from reads "Time off · Approved by …", 14 October 2026). A shift with a break reads "09:00–17:00 · 1 h break", with the hours worked (14 October 2026). A day with several shifts shows each, with its own "Request a change" (14 October 2026). By hand (11 October 2026), until the assistant takes requests in words: a shift from today on with nothing waiting has "Request a change", which opens the request form with that shift chosen. "Need a change? Ask the assistant" opens the assistant's tab (16) while the assistant is available to the person (19 October 2026); it was hidden from 14 to 19 October 2026 and is hidden whenever the assistant is not available.

16. Assistant

• Who: the employee.
• Shows: a chat with the store's agent. The employee asks in plain language — “Can I get Saturday off?” — and sees the affected shift, the proposed cover and what it would cost, then the colleague's answer and the manager's decision as they arrive.
• Can do: ask when they work; ask for a day off, a swap or a later start; confirm that the proposal goes to the colleague and then to the manager.
• States: an empty conversation with example questions; waiting for the colleague; waiting for the manager; nobody can cover — the assistant says so and passes the request to the manager with the facts; the assistant is unavailable — shifts and requests stay visible.
• When: demo plan. Steps 5 and 6. Read Employee assistant.
• Not designed: what happens after a colleague says no. See Not designed yet.
• Built 19 October 2026 (the owner's decision), checked against a local Agentfy only, not deployed: when the API says the assistant is available, the employee's Assistant tab is the live chat with their store's agent — the same agent as their manager's, with an employee's rights. It answers about their own shifts, checks a day off, a swap, a cover or different hours, finds who could cover, explains a refusal and says where their requests stand. A proposed change is a card; nothing is sent until the person presses Send request, and the request then goes to the colleague and to whoever decides, as one from the form would — it does not change the schedule. The thread is kept between visits; a reply cut off by a broken connection can be recovered. When it is not available the tab says why — the store's assistant is not ready and their manager or the owner connects it, or a platform administrator has to turn the assistant on — and points to My shifts, My requests and Waiting for you, where everything is also done by hand. There is no scripted fallback: when the API answers that Agentfy is not configured, the app asks the API again and shows that panel.
• From 14 to 19 October 2026 (the owner's decision of 14 October): the employee's Assistant tab showed only the title, "In development" and one sentence: until it is ready, everything is done by hand in the other tabs (My shifts, My requests and Waiting for you).
• Built (11 October 2026) as a scripted demo, not deployed, not shown from 14 October 2026, removed from the code 19 October 2026: there is no agent and no free text; a line under the chat says the replies are scripted and that it changes nothing by itself. The four suggestions (or the same words typed) get answers from the person's real shifts: next week's shifts; "Can I swap my Saturday?" or "Can I get Saturday off?" shows the next Saturday shift and a proposal — a colleague who could cover it within their weekly hours, or, when nobody can, a colleague to swap with so both keep their hours, or else time off for the manager to decide. The API finds the colleague with the same fixed checks it applies to a request. Nothing is sent until the person presses "Send to … and manager"; only after the API has accepted the request does the chat say "Sent" and show its status, which is read again when the tab is opened again. "No" sends nothing. A shift that already has a request waiting shows that request's status instead. The same for Thursday, without the swap. A day with several shifts names them all ("Your Saturday shifts are 12:00–14:00 and 18:00–20:00."), and the proposal — a cover or time off — takes every one of them; a swap is not offered for such a day, since it would move one shift only (14 October 2026). A later start is explained, with a link to My requests, since there is no form for it. Anything else gets "I'm a demo and can't understand free text yet" and the suggestions. The empty screen shows how many items wait on Waiting for you. The unavailable state exists only as a switch for testing (?assistant=offline); nothing detects an outage. The conversation lasts until the page is reloaded.

The employee sees who could cover a shift, never a colleague's personal reasons or pay.

17. My requests

• Who: the employee.
• Shows: every request they made and where it stands: with a colleague, with the manager, approved, rejected.
• Can do: open a request to see its history; withdraw it while it waits (built 11 October 2026, not designed beyond that).
• States: no requests yet.
• When: not named in the demo plan; after the demo.
• Built (11 October 2026), not deployed: every request the person made, newest first: what they asked for ("Sat, Oct 10 off"), the chip — Waiting for Chloe, Waiting for manager, Approved or Declined — a line under it, and when they asked, in the store's time zone. A request still on its way shows its steps (sent, the colleague's answer, the decision); decided ones are dimmed. A decided request says who decided it ("Approved by Daniel Okafor", also in its steps), and one the manager or the owner declined shows why, in their words (14 October 2026); a colleague's no has no reason. By hand (11 October 2026), until the assistant does it: "New request" opens a form — one of their shifts this week or next, what they need (Time off, Cover by a colleague, Swap, Different hours), the colleague or the colleague's shift, the new hours, and an optional reason kept as their own words; colleagues whose shifts that day overlap the asker's cannot be chosen to cover — someone working that day at other times can (14 October 2026). On a day with several shifts, Time off and Cover by a colleague take every one of them, and the form says so ("Time off takes both shifts that day: 12:00–14:00, 18:00–20:00."); a swap and different hours change the chosen shift only. A waiting request has Withdraw (a second click confirms); it then reads Withdrawn, with "You withdrew it" in its steps. Managers have the same screen inside their Requests, where the owner decides. "Or ask the assistant" leads to the assistant's tab while the assistant is available to the person (19 October 2026); it was hidden from 14 to 19 October 2026 and is hidden whenever the assistant is not available.

18. My availability and preferences

• Who: the employee.
• Shows: when they can and cannot work, recurring and one-off, and what they prefer.
• Can do: propose a change. Whether an employee's change takes effect at once or needs the manager is not designed.
• States: nothing entered yet.
• When: after the demo; in the plan this data is filled in beforehand.

19. Waiting for you

• Who: everyone; for the employee it is the place where a colleague's request to cover arrives and where a decision comes back.
• Shows: the things that need an answer or were just decided, newest first.
• Can do: agree or decline to cover — a colleague can say no without explaining why; open a decision.
• States: nothing waiting.
• When: demo plan; it stands in for notifications.
• Not designed: how a person learns that something is waiting when the application is closed. See Not designed yet.
• Built (11 October 2026) for employees, not deployed: a colleague's ask to cover or swap, with what it does to the person's week and who decides next — "I can cover" sends it on, "No" ends it — and "Confirm your shifts for Oct 12–18" with Confirm or "Something is wrong", which marks it; until 14 October 2026 it also opened the assistant's tab, where the demo said it cannot change shifts, and since then its done line reads "Marked as something wrong · tell your manager what to change" — since 23 October 2026 "… tell your manager or the owner what to change", or "… tell the owner what to change" for an employee with no manager and for a manager. Since 19 October 2026, while the assistant is available to the person, it also opens the Assistant tab with "Something is wrong with my shifts". Answered items keep a done line for a week. The tab carries the number still open. Decisions do not arrive here yet; the employee sees them in My requests. Managers have the same list inside their Requests (11 October 2026), for another manager's ask to cover. A request withdrawn while its ask was open takes the ask away.

20. Profile

The employee's entry to screen 5, plus the store they belong to. After the demo.

Three wireframes

Wireframes, not a design: they show what sits on a screen and roughly where. Names, shifts and numbers are made up.

Schedule (screen 11) — wireframe, not a design:

┌─ Schedule ───────────────────────────────────────────────────────────┐
│ ◂ 12–17 Oct ▸        [ Draft ]  Published          ( Build a draft ) │
├─────────┬─────────┬─────────┬─────────┬─────────┬─────────┬──────────┤
│         │ Mon     │ Tue     │ Wed     │ Thu     │ Fri     │ Sat      │
│ Anna    │ 08–14   │ 08–14   │ —       │ 08–14   │ 08–14   │ 08–16    │
│ Ben     │ 10–18   │ —       │ 10–18   │ 10–18   │ —       │ 12–20    │
│ Chloe   │ 14–22   │ 14–22   │ 14–22   │ —       │ 14–22   │ —        │
│ Dan     │ —       │ 10–18   │ 08–14   │ 14–22   │ 10–18   │ 14–22    │
│ … 8 more                                                             │
├─────────┴─────────┴─────────┴─────────┴─────────┴─────────┴──────────┤
│ Saturday    08 09 10 11 12 13 14 15 16 17 18 19 20 21                │
│ needed       1  1  1  1  3  3  2  2  2  2  2  2  1  1                │
│ planned      1  1  1  1  2  2  3  3  2  2  2  2  1  1                │
│                          ▲  ▲  gap: one person short 12:00–14:00     │
├──────────────────────────────────────────────────────────────────────┤
│ Why   “Ben starts at 10:00 because the lunch peak needs three”       │
│ Gaps: 1 · Overtime: none                                 ( Publish ) │
└──────────────────────────────────────────────────────────────────────┘

Assistant (screen 16) — wireframe, not a design:

┌─ Assistant ──────────────────┐
│                              │
│      Can I get Saturday off? │
│         My sister’s wedding. │
│                              │
│ Your Saturday shift is       │
│ 12:00–20:00. Chloe would     │
│ cover it without overtime.   │
│ ┌──────────────────────────┐ │
│ │ Sat 17 Oct · 12:00–20:00 │ │
│ │ You → Chloe              │ │
│ │ no overtime · no gap     │ │
│ │        ( Send to Chloe ) │ │
│ └──────────────────────────┘ │
│                              │
│ ● Waiting for Chloe          │
│                              │
│ ┌────────────────────┐       │
│ │ Write a message…   │  (↑)  │
│ └────────────────────┘       │
│ Shifts · Assistant · Waiting │
└──────────────────────────────┘

Requests (screen 12) — wireframe, not a design:

┌─ Requests ────────────────────────────────────────────────┐
│ [ Waiting for you · 2 ]   Decided                         │
├───────────────────────────────────────────────────────────┤
│ Ben · day off · Sat 17 Oct, 12:00–20:00                   │
│ Proposed: Chloe takes the shift — she agreed              │
│ Checked: rest ✓   weekly hours ✓   availability ✓         │
│ Cost: no overtime, no gap                                 │
│                                 ( Reject )    ( Approve ) │
├───────────────────────────────────────────────────────────┤
│ Dan · later start · Tue 13 Oct, 11:00 instead of 10:00    │
│ Nobody can cover 10:00–11:00                              │
│ Checked: Anna — absent · Chloe — rest too short           │
│ Cost: one person short 10:00–11:00                        │
│                                                  ( Open ) │
└───────────────────────────────────────────────────────────┘

Design notes

The screens would follow “Portrait”, the project's style reference, which is light only. What it means here, by its token names:

• A white canvas and one ink. The page is --color-white-canvas; text, lines and outlined actions are --color-portrait-ink. No second brand colour.
• Pastel washes for small surfaces only — a status pill, a marked cell, never a whole section. The proposed reading: --color-mint-wash for approved and covered, --color-sky-wash for waiting and draft, --color-peach-wash for a gap, overtime or anything that needs a look. The mapping is a proposal.
• The rainbow accent at most once per view, as the outline of the primary action (--gradient-rainbow-spectrum): “Publish” on the schedule, “Approve” on a request, “Send” in the chat. Everything else is a quiet text button.
• Generous rounding and calm density: --radius-cards for cards, --radius-buttons for buttons, --radius-tags for status pills; shadows barely there.
• Coverage is a table or bars in ink and washes. No charts in brand colours: a gap is a peach cell with a number, not a red line.
• Phone width first for the employee's screens, desk width first for the manager's schedule.

Nothing here is drawn yet. The sketches on the overview are an earlier exploration of five employee screens, not this list.

Where to go next

• User flow: the loop these screens serve.
• Schedule generation and Employee assistant: the behaviour behind screens 11, 12 and 16.
• Data structure: what the system would keep behind these screens.
• Agentfy integration: how the assistant on screens 13 and 16 would work.
• Open questions: everything still undecided.