# What the client has answered, and what is still owed

Written 5 August 2026, against `dev` at `6a48837`, and rewritten 6 August
against `7f29f2e`. The list of what is owed had gone stale in both directions:
the holiday calendar had arrived and was still listed as waiting, and twelve
questions raised since had never been added to it.

The normative specification lives outside this repository and is read only from
here, so its `machine/open-points.tsv` still shows several questions as open
that have since been answered. **This file is the current state.** Where the two
disagree, this one is newer and the commit named beside each answer is the
evidence.

## Answered, and built

**How people sign in.** A username, chosen by HR when the account is opened, not
the employee code. Both live in the database and the person is what links them,
because the employee code is a pillar of the accounting system it already lives
in. This is open point **D**, and it is settled. `c4ffc28`, `ee8e98c`.

**How 193 people get a password.** By hand, from the HR manager, and again when
somebody loses one. The reason given was the constraint rather than a
preference: the factory network has no internet and there is nothing to send
anything with. `/admin/people` is that screen. `ee8e98c`.

**The working week.** Monday to Saturday, every week, no rotating shifts.
Sunday is overtime and never a schedule. Answered by Roma on 4 August, and it
closed three questions at once: no third value in the enum, no alternate-week
schedule, and `work_pattern` is the right shape. All 193 people were `mon_fri`,
which nothing had chosen; it is what a default does when nobody supplies the
data. `0816b68`.

**What happens to a task nobody did.** It stays owed. "Keep it. Work owed is
work owed, and the list is honest." This is open point **C**, and the
specification's own provisional default was the **opposite**, to mark it missed
and remove it from the active list. Asking rather than following the default is
what stopped us building the reverse of what they wanted. `cd0b554`.

**Who sees the list of positions.** Admin. Two client documents disagreed and
the narrower reading was taken, because widening later shows somebody a list
they were not seeing and narrowing later takes one away.

**The 2026 holiday calendar.** Their own **Advance Manufacturers Annual
Holidays 2026**, the company closure list, which is exactly what the table
means. Fourteen days, loaded at `c4ffc28`. It corrected the Buddhist file in
both directions: three religious observances removed because they are not
closures, Visakha Bucha moved from a Sunday to its substitution day on Monday 1
June, and the government days added. Every date was checked against the weekday
the file itself states, fourteen rows and no disagreement, which is the only
thing that makes converting somebody's calendar by hand defensible. ELEVA-150.

**Whether the factory wifi reaches the server.** It does. That was not obvious,
and it is what makes a link opened on a phone possible at all. It does not
change anything built, and it unblocks one thing that is not.

**Who delivers a set-your-password link.** Not us. The link is generated and
shown with a copy button, and HR sends it however they like. That removes a
dependency and means no bearer token ever sits in infrastructure we are
responsible for.

## Answered, and not built

**Nothing.** Every answer received has been acted on.

## Waiting on the client

Roughly in the order they cost us: the ones at the top stop work, the ones at
the bottom are confirmations of something already running.

Two deserve to be asked first even if nothing else is. **The screen size**,
because half the visual work cannot start without it. **What an assignee hands
in**, because it decides what the worker's screen asks for.

Not on this list, and worth saying because they were on an earlier version of
it: the notification channel is **answered** (answer 6, Mattermost and push, so
it is a target to build rather than a question to ask), and one-time personal
to-dos are **answered** (answer 2, "no need", which is what was built). Both
were listed as open on 6 August by reading our own notes instead of the
client's document. ELEVA-238 records how that happened.

**Which duties continue on a holiday.** The engine stops everything on a
holiday and moves it to the next working day. If the night guard still does his
round on New Year's Day, that work disappears from the system on the day it
matters most. Nothing today can express "this one continues". ELEVA-151.

**What size the screen is.** Nobody has said. Four separate visual problems
change answer between 800×480, 1024×768 and a 1080p panel: the sidebar
disappears below 768px, the destructive button in a dialog renders above Cancel
below 640px, every dialog is capped at 320 or 384px while holding spelled-out
Thai sentences, and no table cell anywhere can wrap. Fixing for the wrong
target costs twice. A photograph of one real terminal would nearly do.
ELEVA-239.

**What an assignee hands in.** A note is captured and, as of this week, shown
to the checker. Whether they should also record a reading, a number, a photo or
a link is unanswered, and it decides what the worker's screen asks for.
ELEVA-121.

§5 of the specification narrows this more than the issue says. A task already
declares **which report it produces, how it is delivered and to whom**, plus a
link to a model of that report and a link to the work instruction. So the
question may be smaller than it looks: perhaps finishing only has to say the
named report went where it was meant to go, rather than carry anything.

**Can a position have several holders.** The schema allows it and a production
line really does put ten operators on one job, but the roster has exactly one
each, so the data cannot tell us. The demonstration set now contains one
two-holder position, invented from a transfer, so the behaviour can at least be
looked at. ELEVA-137.

**When exactly a task runs out of time.** Open point **E**, still open, and the
one place the code diverges from the specification's recommendation: a weekly
task is given until the end of Sunday, where the recommendation says the end of
the last working day, now Saturday. One day, on the day nobody works.
ELEVA-223.

**How long a session should last.** Seven days was the library default and
nobody had chosen it; it is eight hours now, which is a shift. Whether an
office machine should behave like a screen at the end of a line, and whether
people will sign out at all, is unanswered. ELEVA-220.

**What a password must be worth.** Six characters, chosen so the development
logins could be `admin1`, and `/settings` now prints that number to 193 people.
Whoever sets the real number should know the trade: everybody types this on a
shared terminal several times a day. ELEVA-221.

**The username naming scheme.** HR chooses one per person today, which is right
for a hire and wrong for 193 people on the day the system goes live. A bulk
pass needs a rule, and a rule is a decision. Given names collide in a
193-person Thai roster. ELEVA-159.

**Where the Admin and HR desks are, and when.** `/login/help` is the only
recovery path on a network with no email, and every line on it was invented by
us: building, hours, extension. The tell is already on the screen, since Admin
is shown open six days and HR five on a site they confirmed works six.
ELEVA-234.

**Which table says who a Line Leader may assign to.** Answer 3 of the ten was
"I will have to provide you a table." It never arrived. Today any manager-level
person assigns to any position in their own department, which is the
provisional default still running unchallenged. ELEVA-153.

**The names in English.** Answer 7 said they would add everybody's name in
Latin script. `people.display_name` is null for all 193, so an English reader
sees Thai names everywhere, and a browser given `lang="en"` has no way to break
a Thai line.

**Employee 00000001, a Director their own export labels Staff.** One cell
decides whether the lowest employee code in the roster sees only their own
tasks. Promoting somebody because their title reads senior would be inventing
an access level for a real person, so it stays as the file says. ELEVA-158.

**Whether a fixed-day duty should move forward or back.** §7 of the
specification says it moves to the next working day and invites us to say if we
prefer the day before. We move it forward. It is our proposal, unchallenged,
and worth one confirmation because it is not reversible once a month of dates
exists.

**Whether the temporary cover we built is what they meant.** They asked for the
tasks to be "copied temporarily" onto the covering person's position. We do not
copy rows: for a window of days the duties resolve to the stand-in, which
produces the same visible result without making their job description list work
that is not their job. Same outcome, different route, worth a yes. ELEVA-117.

**Somebody between two positions cannot be offered as a stand-in**, and they
are exactly who you would ask. It does not arise in today's roster, where all
193 hold a position, and it will on the first transfer. ELEVA-236.

**The palette.** The screens do not match the mockups and will not until
somebody decides the colours. Two contrast pairs already fail AA, on the
**Missed** and **Late** badges, which are the most operationally important
words on the screen.

## Asked for in the specification, never questioned, never built

Not questions. The client wrote these as requirements in the body of the
document, and because the ten questions took all the attention they were never
tracked. ELEVA-240.

**§9, workload per person.** "The time-to-do field is added up per person to
show workload balance: 3 tasks for one person, 25 for another becomes visible
immediately." The field exists and a duty displays it; nothing sums it and no
screen shows the balance. And **0 of the 318 duties in the database carry a
value**, so the screen would be empty even once built. Who fills those
durations, and when, is worth asking at the same time.

**§8, copy a whole set of duties from one position to another.** Not built. It
is the act that makes the system usable at 46 departments of similar positions;
today every duty is typed by hand.

**§8, move a task permanently from one person to another.** The temporary half
is ELEVA-117 and is built. The permanent half is a different thing, because it
changes which position owns the duty rather than who receives a window of days.

## Confirmations, not questions

Three open points are marked `confirm` in the specification, meaning the
behaviour is built as described and needs a yes rather than an answer.

**F.** A task is complete once checked, and the verifier audits a sample rather
than every task. Built that way.

**G.** One-time personal to-dos are private; recurring ones are visible to the
manager. Not built at all yet, so the confirmation costs nothing today and
costs a rebuild later.

**H.** Staff see only their own position's job description, with no directory of
other positions or holders. The most conservative reading is in use.

## Two places the code contradicts the specification, deliberately

Both are recorded in the code, at the point where somebody would otherwise
report the working behaviour as a bug.

**Sending work back returns a task to `started`, not `todo`.**
`machine/lifecycle.json` says `todo`. A task that has been handed in has been
started, `started_at` holds the moment and nothing clears it, so a row at `todo`
would carry the time it began and offer the assignee a Start button for work
they have already done once and now have to correct. `lib/services/task-commands.ts`.

**`/review` is not guarded at manager level.** `routes.json` lists it in the
manager group, and the same row's purpose line says "queue of tasks waiting for
**MY** check". Seven people are named as a checker and **three of them are
staff**: a manager guard would hide their own queue from them.

Both should be corrected in the specification when it is next amended, which is
ELEVA-123. That folder cannot be written from here.