Overview

Accepted direction · decided 2 October 2026 · nothing is implemented

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. None of it is built.

One application, two roles. 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, not built
Mobile app	The same application packaged for iOS and Android with Capacitor.	Accepted for now, not built
API	Holds stores, teams, rules, schedules and change requests; everything the application shows comes from it. Built with NestJS.	Accepted direction, not built
Scheduling agent and solver	Turn what people ask for into constraints, build the schedule and explain the result.	Hypothesis; the solver for the first version is chosen — see Agent and solver
Employee assistant	Takes a change request in plain language, checks the rules and prepares one decision for the manager.	Proposal — 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
      └───────────────┬───────────────┘
                      │
      ┌───────────────┴───────────────┐
      │  API (NestJS)                 │
      └───────┬───────────────┬───────┘
              │               │
     scheduling agent    employee assistant
        and solver

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. There is no data model, no list of endpoints and no screen yet.

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 a prototype. Agent and solver describes what the solver is, the tools the agent would get, and why the solver is a service rather than an MCP server.

Not decided

• The database and where it is hosted — and with it, where employee data lives, which has to be settled before any pilot.
• Which language model, and where the agent runs — inside our API or on an external platform. The solver for the first version is chosen (YALPS); see Agent and solver.
• 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.
• Sign-in, and how an employee is invited to a store.
• 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.
• A separate admin panel and a public website. Neither is designed.

Where to go next

• User flow: what the manager and the employee would do in the application.
• Agent and solver: what counts the schedule, and how the agent would use it.
• 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.