Overview

Accepted direction · decided 2 October 2026, extended 5, 6 and 11 October 2026 · sign-in, roles, stores, people and invitations built 6 and 11 October 2026, the new look, the schedule screens, change requests and a scripted demo of the assistant's screen 11 October 2026, the Assistant tab showing "In development" instead from 14 October 2026, the assistant turned back on — the live chat with the store's agent where the API says it is available, the scripted demo removed, the store's assistant on the store pages — 19 October 2026, checked against a local Agentfy only, the API's shared core (teams, sessions, invitations and password resets by email, API keys) 15 October 2026, a schedule's day view and month sheet 16 October 2026, an admin app of its own for Settings 18 October 2026, a manager's rights in their own store 19 October 2026, owners joining only after a platform administrator approves them 23 October 2026, nothing else implemented, nothing deployed · a manager optional for an employee 23 October 2026, not deployed · the owner's list of positions 30 October 2026, not deployed · the local demo written only by make seed 30 October 2026

The agreed design is one application for both managers and employees — in the browser and, for now, on phones through Capacitor — with a single API behind it. Of all of it, only signing in, the three roles (owner, manager, employee), stores, people, invitations, schedules and change requests are built — in the API, and in the application the owner's stores and people, each role's menu, the schedules each role may see, deciding requests and following them, and the assistant's chat with each store's agent on Agentfy, checked against a local Agentfy only — and nothing is deployed.

One application, three roles. The owner, the manager and the employee open the same app and see different parts of it.

The pieces

Piece	What it would do	Status
Application	Where the manager describes the store, reviews and publishes the schedule, and where the employee sees shifts and asks for changes. One codebase, built with Nuxt.	Accepted direction; sign-in, owner sign-up, the owner's stores and people screens, each role's menu, the schedule screens and the request screens built (11 October 2026), not deployed — see What is built
Mobile app	The same application packaged for iOS and Android with Capacitor.	Accepted for now, not built
Admin app	Where Shiffty's own platform administrators — not an owner, a manager or an employee — keep the platform's Settings (the Agentfy connection and its keys) and, since 23 October 2026, answer owners' requests to join. A separate Nuxt application next to the API and the app, as in our other products; it lets no one else in.	Built (18 October 2026, SHIF-36), not deployed — see What is built
API	Holds stores, teams, rules, schedules and change requests; everything the application shows comes from it. Built with NestJS, on the same core as our other products.	Accepted direction; accounts, sign-in, roles, stores, people, invitations, schedules and change requests built (6 and 11 October 2026), the shared core (15 October 2026), not deployed — see What is built
Store agent	The agent a store’s manager and employees talk to. It runs on the Agentfy platform, one agent per store; the chat itself is drawn inside the application.	Accepted direction (5 October 2026); setting up a store's agent and the chat built (13 and 19 October 2026), checked against a local Agentfy only, no hosted Agentfy connected, not deployed — see Agentfy integration
Tool server (MCP)	Run by Shiffty next to the API: the one door through which the store agent reaches Shiffty’s tools, with the identity of the person it is talking to.	Accepted direction (5 October 2026); built in the API with seven tools, checked against a local Agentfy only, not deployed — see Agentfy integration
Scheduling agent and solver	Turn what people ask for into constraints, build the schedule and explain the result.	Hypothesis; the first solver is built in the API (19 October 2026), its tools in the agent's catalog, not deployed — see Agent and solver
Employee assistant	Takes a change request in plain language, checks the rules and prepares one decision for the manager.	Proposal; a scripted demo of its screen built 11 October 2026, hidden from 14 October and removed 19 October 2026; the live chat with the store's agent built 19 October 2026, checked against a local Agentfy only, not deployed — see Employee assistant

How the pieces would connect — a target design, not a running system:

        Manager                 Employee
            \                     /
      ┌───────────────────────────────┐
      │  Application (Nuxt)           │   browser · iOS and Android
      │  one codebase, two roles      │   through Capacitor
      └───────────────┬───────────────┘
                      │
      ┌───────────────┴───────────────┐   messages   ┌─────────────────────┐
      │  API (NestJS)                 │ ───────────▸ │  Store agent        │
      │  tool server (MCP) · solver   │ ◂─────────── │  on Agentfy         │
      └───────────────────────────────┘  tool calls  └─────────────────────┘

One app on phones, through Capacitor — for now

The mobile app is not a second product. It is the same application the manager can open in a browser, packaged for iOS and Android with Capacitor instead of being written twice as native apps.

What that means for the people using it:

• A manager and an employee install the same app. The role on the account decides what each of them sees.
• The manager can also work in a browser. It is the same application, not a separate admin tool.
• “For now” is part of the decision. Capacitor is the starting choice, not a permanent one. What would make us replace it, and with what, is not decided.

Still open: how the app is distributed, how people are notified about a new schedule or a pending decision, and whether anything works without a connection. Whether employees can also write from a messenger they already use (Telegram, Viber, WhatsApp) is an open question.

How the code would be organised

NestJS for the API and Nuxt for the application, organised by CleanSlice — the convention our other products are built with, where code is grouped by feature rather than by technical layer.

This is a choice of tools, not a design of the features. A first outline of what would be kept and what people would see is on Data structure and Screens.

What is built

The repository holds the first working part of the application and the API — and only this. It was rebuilt on 11 October 2026 around the owner's decision on who works for whom; the list of companies, the company pages and the employee records of 6 October are gone.

• An owner asks to join with a name, the name of their business, an email and a password, and, if they like, a phone number and how many stores they have; the business is their team (a company until 15 October 2026). Only owners sign up on their own. Since 23 October 2026 (the owner's decision) signing up is a request: the owner cannot sign in until a platform administrator approves it on Requests in the admin app. Signing in before that says the request is being reviewed; after a decline it says the request was declined, with the administrator's reason when one was given. The applicant gets an email when the request arrives and when it is answered; every platform administrator gets one saying only that a new request arrived and from whom (name, business, email). A declined applicant may ask again with the same email; the declined request stays as history. A platform administrator can switch an approved company inactive and back: while it is inactive, its owner and all its people cannot sign in and are told why, their sessions end, and API keys and the assistant stop working; nothing is deleted, and switching it back on restores access. Approving makes the company active and, when Shiffty is connected to Agentfy, connects the company's assistant (Agentfy integration). Owners who signed up before count as approved. Checked by the API's automated tests and once in a working copy; not deployed.
• Everyone signs in with an email and a password and lands in their role's part of the app: the owner on /owner, a manager on /manager, an employee on /me. Each has the prototype's menu — the owner Assistant, Stores, People, Schedules and Requests; a manager Assistant, Schedules, People (since 19 October 2026) and Requests; an employee Assistant, My shifts, My requests and Waiting for you — and an account menu with their name, role and Sign out. What the Assistant tab shows is below; a person lands on it when the assistant is available to them, and otherwise on Schedules (the owner, a manager) or My shifts (an employee) (19 October 2026).
• The owner sees their stores as cards — address, opening hours, how many managers and employees, who the managers are — opens a store to see its managers and its employees, each employee with the manager they report to, and creates a store with a name, address, opening hours and time zone.
• The owner sees everyone on People, filtered by role and store, with each person's store, manager and status.
• The owner's list of positions (30 October 2026, the owner's request): on People → Positions the owner adds the business's positions — "Cashier", "Stock handler", "Deputy manager" — each with a name and a description for the assistant, renames them and archives them. One list for all the stores. A person's position is picked from it in the invitation and in the person's dialog, never typed; a manager picks one for their own people and cannot change the list. An archived position stays with those who hold it and is not offered to anyone new. The titles typed before were turned into positions, nothing lost (Data structure).
• The owner invites a manager or an employee to one of their stores, from People or from a store's page. An employee reports to a manager of that store chosen in the form, or to no manager (optional since 23 October 2026, owner's decision); a manager's own invitation makes the employee report to them unless they choose another manager — only the owner leaves an employee without one. Since 15 October 2026 the link is sent to the person by email; the dialog also shows it once, to copy and hand over if the email does not arrive. People lists the invitations still open; the owner can withdraw one that is pending or has expired.
• A manager's rights in their own store (19 October 2026, the owner's decision): within their store, and only for its employees — never another manager, never themselves — a manager deactivates and reactivates a person, gives them another manager of the same store, invites employees and withdraws those invitations, and changes the store's opening hours and description. Before, all of this was the owner's; the owner keeps every right. The manager has a People tab with their store's people (inactive ones listed last, to make active again) and its open invitations, an Invite employee dialog fixed to their store, Reports to and Status in a person's dialog, and Edit on their store page — hours and description only; the name, address, time zone and status stay the owner's. New hours are refused while shifts would fall outside them, as for the owner. Each of these changes, the owner's too, is recorded with who made it, what kind of change it was and which fields changed — never the values. Checked by the API's automated tests; not deployed.
• The invited person opens the link, sees the store, the role and whom they will report to, chooses a password and lands on their role's page. A link works once and for seven days; an expired, used or withdrawn link says which of the three it is.
• A forgotten password (15 October 2026): the sign-in page links to a form that emails a one-time link, valid for an hour; it opens a page to choose a new password, which signs the person out everywhere.
• The API's shared core (15 October 2026, SHIF-25): the same foundation as our other products, so they read and fail alike. Every route is under /api; every answer is { success, data } and every refusal names a stable code, a message and a request id; lists come in pages. Signing in opens a session that can be ended from the server, and stealing an old refresh token ends it. The company became a team with roles — owner, admin, member — with API keys for programs and an ownership transfer, and a platform admin role opens Settings — in the admin app since 18 October 2026 (below). Mail goes through Resend in production and a local mailbox on a developer's machine. The application talks to the API through a client generated from the API's own description. Of this, only invitations by email and the password pages are visible to people; teams, roles beyond the owner, API keys and ownership transfers exist in the API only. See Data structure.
• Settings in an admin app of their own (18 October 2026, SHIF-36): the platform's Settings left the application for a separate admin app, the way our other products keep theirs. It has its own sign-in against the same accounts; anyone who is not a platform administrator is refused there with a plain message, and in the application nobody has a Settings tab any more. The Settings themselves did not change — the same fields, buttons and API. Checked on a developer's machine only (signing in as the administrator and saving a change, and being refused as the owner of the demo company); not deployed. Since 23 October 2026 the admin app also has Requests: owners' requests to join, by status (pending, approved, declined), each with its details, Approve, and Decline with an optional reason, and for an approved company Deactivate and Reactivate; the admin app opens on Requests.
• Schedules in the API: every store has a time zone, and each store's weeks can be read — a draft or published, live or past — as a grid of shifts with hours and overtime, together with each person's own shifts and "this week's" hours. Shifts change by hand (below) or when a change request is approved. See Data structure.
• Schedules on screen (11 October 2026): the owner sees the weeks of any store as one grid of who works when with each person's hours — managers first, then employees, with a filter by role, manager, person and area (14 October 2026; until then the team and the managers were two tabs); a manager sees every week of their store — draft, published, live or past, with shifts, hours and overtime — and opens one as the same grid; an employee sees their own shifts this week and next, from published weeks only, and their next shift. Each view says which time zone its times are in. The assistant cannot draft or change a schedule — it has no tool for that — so no button asks it to (19 October 2026); schedules are made and edited by hand (below). A manager's week has "Ask the assistant" while the assistant is available to them, which asks about that week's team schedule. Change requests are drawn on the grids and on My shifts. Since 16 October 2026 the owner and the managers can also look at one day as an hour timeline, with the store's usual receipts, the tills they need and the people on the checkouts and in the store hour by hour, and at a month as one read-only sheet to print; a shift's break can say when it starts. See Screens.
• Change requests (11 October 2026): an employee's request goes to their own manager (or any manager of the store while theirs has not joined yet), a manager's to the owner, and since 23 October 2026 so does the request of an employee with no manager; a manager who is deactivated hands the requests waiting for them to the owner. A manager decides on Requests, the owner decides the managers' requests on theirs; approving changes the shifts in one step after checking them again, declining changes nothing, and a decision can be undone while its week is not over. A colleague asked to cover or swap answers on Waiting for you; people follow their requests on My requests. The badges on Requests and Waiting for you, and "N waiting" on the owner's store cards, follow each decision. Requests are made with the request form (below), in the assistant's chat when it is available — only after the person confirms the proposed change — or through the API; what is checked is either the demo data's prototype text or the API's fixed checks, the same for every request, and the list says "Checked against the store's rules" (until 19 October 2026 "Checked by the assistant"). See Data structure and Screens.
• The assistant, on again (19 October 2026, the owner's decision, for good): whether it is shown is the API's answer, read when a person signs in and when they open the tab — available when Shiffty is connected to Agentfy, chat is on and the person's store agent is ready — for the owner, since 20 October 2026, their own agent for the whole company (the owner's assistant). Available, a manager's or an employee's Assistant tab is the live chat with their store's agent (Agentfy integration) and the links into it are shown: "Ask the assistant" on a manager's week, "Need a change? Ask the assistant" on My shifts, "Or ask the assistant" on My requests, and "Something is wrong" on Waiting for you opens it with that question. Not available, the tab says why in plain words and who can fix it, and the links are hidden. The owner's tab says the assistant serves store teams for now, with a link to Stores. A store's page — the owner's, and the manager's Store profile — shows the store's agent and has Connect assistant or Retry (Screens). The scripted demo is removed from the code, and there is no scripted fallback. Checked by the app's unit tests and the API's automated tests against an in-memory stand-in for Agentfy, and in a browser against a real Agentfy on a developer's machine; not deployed, and no hosted Agentfy is connected.
• The Assistant tab: "In development" (14 to 19 October 2026, the owner's decision of 14 October): each role's Assistant tab showed the title, "In development" and one sentence: until it is ready, everything is done by hand in the other tabs. The buttons and links elsewhere that would open the assistant were hidden, and "Something is wrong" on Waiting for you only marked the week. Replaced by the entry above.
• The assistant, as a scripted demo (11 October 2026; not shown from 14 October 2026, removed from the code 19 October 2026): each role's Assistant tab had the prototype's chat — a greeting, what is waiting for the person, suggested questions, a thread, the composer — with no agent behind it. A few fixed questions get scripted answers filled with real data from the API (drafts, hours, requests, the person's own shifts); anything else gets "I'm a demo and can't understand free text yet". It changes nothing by itself: the only things it does are the ones a person confirms in the chat — approving or declining a request, or sending an employee's request — and it says one was done only after the API accepted it. To propose a colleague the API answers, read-only, who could take one of the person's shifts under the same fixed checks as a request. The buttons elsewhere that point to the assistant open it with their question. The conversation lasts until the page is reloaded. See Screens.
• By hand, until the assistant does it (11 October 2026, the owner's direction that every action must also be possible without the assistant): the owner edits any store's schedules, a manager their store's team; weeks are created empty or copied, edited and published; shifts are added, changed and deleted within the store's rules, with rest and contract hours as warnings; a shift with an open request is locked. Employees and managers make requests from a form and withdraw them while they wait; managers have My requests and Waiting for you inside their Requests. The owner edits a store (new hours that shifts would fall outside are refused) and a person's title (a position from the owner's list since 30 October 2026), weekly hours, manager and status; a manager their own people's title and weekly hours, and since 19 October 2026 the manager and status of any employee of their store and the store's hours and description. See Data structure.
• Shift tools (14 October 2026): a shift has a break, and every count of hours uses the hours worked (length minus break); each store has up to ten shift templates that the shift dialog and an empty day of the grid offer, managed by the owner and the store's managers; and the API returns, with each week, the days on which no manager is on duty for part of the opening hours — shown above the grid and in the confirmation before publishing, which it does not block — and warns in a request's checks when approving would open such a gap. See Data structure and Screens.
• Store and person profiles (14 October 2026): a store has a description and an hourly load — the usual till receipts per hour, Monday to Sunday — and a person a description, all typed in by hand as context for the assistant later. The owner writes the store's description (and since 19 October 2026 the store's managers too); the owner and the store's managers edit the hourly load; the owner describes anyone, a manager the employees of their store. A person never sees their own description. Nothing reads any of it yet, the assistant included. See Data structure.
• The schedule solver (19 October 2026): for a store's week it proposes the team's shifts from the shift templates, the shapes people already work — and, since 26 October 2026, hours it sets itself where none of those fits — contract hours and the hourly load, says what stays short and why, and writes a confirmed plan into a draft week, never publishing; it weighs a change request and names the cover it would need. HiGHS inside the API since 10 November 2026 (WebAssembly; YALPS before that, and kept as a fallback). Its three tools are in the agent's catalog: a week and a manager's decision are cards the manager confirms. See Agent and solver.
• Time zones in the screens: every store has a time zone, and schedules are shown in the store's zone, never the viewer's (the owner's decision of 11 October 2026). The new-store form asks for the zone, the store cards and a store's page show it, and an invitation's expiry is shown in its store's zone. This week's hours on a store card and on People come from the API's schedules.

Who sees what is one rule in the API: the owner sees everything in their team; a manager sees their store and everyone in it, with their own people marked; an employee sees themselves and their store. Anything else answers as if it did not exist. A person whose place was made inactive can still sign in but sees nothing.

A local demo company — the one in the prototypes, Morgan Retail with four stores (the prototypes' three and Central Station, a railway-station kiosk with a commuter flow of customers of its own), seven managers, thirty-three employees and one pending invitation, all made up, five weeks of schedules per store around the current week, and the prototypes' change requests on top — is written on a developer's machine by make seed, which empties that machine's database first. Since 30 October 2026 (the owner's decision) starting the servers never empties a database: until then a start rewrote the demo whenever the seed code or the week had changed, and so wiped businesses made by hand in the app. A new working copy's empty database is the one thing a start still fills; see local/README.md in the repository. The seed refuses any database that is not on that machine. When the machine also runs a local Agentfy, the stores' assistants are connected to it once the local API answers, also after a reset (since 19 October 2026; not when their profile changed in between — see Agentfy integration).

It was checked on 11 October 2026 by the API's automated tests and by signing in as the owner, a manager and an employee and accepting an invitation in a browser, on a developer's machine; the owner's screens and the three menus the same way, at a desktop width and a phone width; the schedule screens the same way, with the browser set to three different time zones (Europe/London, Asia/Tokyo and Pacific/Auckland), checking that the days, "today" and the times match what the API says for each store; the requests by approving, declining and undoing as the owner and a manager and answering a colleague's ask as an employee, at both widths, with the browser in Europe/London and Asia/Tokyo; the assistant demo by the app's unit tests and by approving a manager's request from the owner's chat and sending a Saturday swap from an employee's, at both widths, with the browser in Europe/London, Asia/Tokyo and Pacific/Auckland; editing by hand by creating, editing and publishing a week as a manager, editing the managers' schedule, a store's hours and a person's hours as the owner, and making and withdrawing requests as an employee and a manager, at both widths, with the browser in Europe/London and Asia/Tokyo. The shift tools were checked on 14 October 2026 by the API's automated tests and the app's unit tests, and in a browser on a developer's machine: a week with breaks and its gap warnings, adding a shift from an empty day's template menu, the publish confirmation, the shift dialog with templates and a break, and the templates section as the owner and as a manager, at a desktop width and, for a manager's week, a phone width, with the browser in its own time zone only. Nothing of it is deployed, so no store can use it.

Since 11 October 2026 the application is being redrawn to follow three clickable prototypes — one each for the owner, the manager and the employee — kept in the repository under design/prototypes/, outside this site. The look is in place — colours, fonts and the shared pieces (header, tab bar, buttons, cards, dialogs, chat) — and so are the owner's Stores, store and People screens, each role's menu, the schedule screens with the requests drawn on them, the request screens and the assistant's chat (a scripted demo from 11 October, hidden from 14 October, the live chat with the store's agent since 19 October 2026); the forms for doing by hand what the assistant will do are not in the prototypes and were kept small in the same style. The prototypes' other screens are not built, and their people and numbers are invented.

Not built: a hosted assistant — the chat works only against a local Agentfy, and no hosted Agentfy is connected — and an assistant that undoes decisions or publishes schedules on its own: undoing stays a person's action, and only the owner's assistant prepares publishing, as a card the owner confirms (20 October 2026); requests and edits are also made by hand. Also not built: the manager's and employee's other screens, the profile, notifications, screens for teams, admins, API keys and ownership transfers, and changing a person's role or store. The status of a store (active or inactive) is still our assumption, not the owner's choice; nothing can be deleted. A store's agent is set up from its page with Connect assistant (19 October 2026); see Agentfy integration.

Agent and solver

Assigning people to shifts under hard rules is an optimisation problem, and dedicated solvers are good at it. Our working assumption is that the language-model agent does not do that arithmetic: it understands the request, turns it into constraints, calls a solver and explains the result. This is a hypothesis that needs managers to try it. A first solver is built (19 October 2026); Agent and solver describes what it does, its limits, and why it is a part of the API rather than an MCP server.

Not decided

• Where employee data lives and who sees it — this has to be settled before any pilot. The engine itself is PostgreSQL on Neon through Prisma; see Data structure.
• Which language model. Where the agent runs is settled — on Agentfy, see Agentfy integration — and so is the solver for the first version (YALPS); the model behind the agent is not.
• Hosting for the application and the API. Today only this documentation site is deployed; see DevOps. The one stated intention is that a later solver service would run in Kubernetes next to the API.
• Whether an invitation reaches people other than by email. Since 15 October 2026 it is sent by email (SHIF-25), with the link also shown to hand over; a messenger or text message is not decided.
• Notifications.
• A messenger as a second channel for employees.
• Integrations with point-of-sale or footfall systems. Spreadsheets are the likely first entry point; see Input data.
• What else the admin app holds, and a public website. The admin app has Settings (18 October 2026) and Requests (23 October 2026); nothing else in it is designed, and neither is a public website.

Where to go next

• User flow: what the manager and the employee would do in the application.
• Screens: every proposed screen for both roles.
• Agent and solver: what counts the schedule, and how the agent would use it.
• Data structure: what the system would keep, and how it is grouped.
• Agentfy integration: where the agent runs and what has to be proven first.
• DevOps: what is deployed today.
• Open questions: what is decided and what is not.
• Two weeks to a demo: the web-only plan for 18 October; Capacitor comes later.