The database moved to a container of our own; the platform is gone.
This takes out what was left of it — and, where the leftovers were load
bearing, moves rather than deletes.
Moved, not deleted:
supabase/migrations/ -> db/migrations/ the schema's source of truth
supabase/build-org.ts -> scripts/build-org.ts
lib/supabase/types.ts -> lib/types.ts 52 import sites repointed
The bookkeeping needed care. It lived in `supabase_migrations.schema_migrations`,
and simply renaming the schema would have left the runner facing an empty
table: it would have called all 67 migrations pending and replayed them
against a database that is long since current. So the runner now creates
`migrationen.schema_migrations` and, once, copies the old rows across —
guarded so a second run does nothing and a fresh database skips it entirely.
Only then does migration 20260907100000 drop the old schema.
Deleted: the CLI config, the seed, the historical schema/function dumps
(nothing read them), scripts/umzug-von-supabase.sh (the move is done), and
both Supabase packages plus the CLI. Nothing in the application imported
them — the build now succeeds with no environment variables at all, which
is the proof.
Integration tests: six of them signed in through Supabase Auth and asserted
against the anon key and the service role. That model is gone, so the tests
were not portable — they are deleted. session-context and
employee-status-filter already ran on pg and are untouched; om-reporting is
ported to a direct connection because it guards a real risk (the reporting
line rule exists twice, once in SQL and once in TypeScript).
CI: the integration job started a Supabase stack. It now runs a postgres
service, applies deploy/db-init and every migration to an empty database —
that was the valuable part, and it still holds — then checks that a second
run is a no-op, which is what proves the bookkeeping works.
Docs: security-review.md audited a service-role key, a cookie adapter and
auth.users, none of which exist. Restating findings about removed components
would suggest today's system had been reviewed; it has not. It now records
what was removed and says a fresh review is due. data-model.md was already
marked obsolete and described the pre-OM schema; azure-migration.md was a
plan for a route not taken. Both deleted.
Verified: npm ci, typecheck, lint, 445 tests, build — all clean without the
packages. Integration tests skip cleanly with no database. Migration SQL and
the runner are reviewed but NOT executed: no Docker here, and the old
instance no longer resolves.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The offboarding list was a checkbox fieldset inside the exit panel — four
items, never sent anywhere. Nothing in terminateEmployee's payload
carried them; ticking a box there recorded exactly nothing.
It's replaced with the same kind of list the entries got: its own tab,
appearing the moment an exit is recorded, with one item per row, a
comment on each, and — unlike the fieldset — a record of who touched it
and when.
The eleven items come from the same printed sheet as the entry list.
Nine are plain checkboxes. Two are text fields under "Vermerke":
remaining vacation and the balance transferred for payout — the sheet
names "Überleitung Salden für Auszahlung" twice, once as a task to do
and once as the actual figure, and those are genuinely two different
questions, kept as two items. Where the sheet still says "GKK" rather
than today's "ÖGK", it's left as written — that's the name the process
runs under internally, not a typo.
No Show gets no list. Never having worked a single day, there's no IT
access to revoke, no GKK registration to undo, no Dienstzettel to
collect — an empty checklist there would be a label with nothing behind
it. Both the tab and the auto-creation on exit check for this
specifically, not just the "Ausgetreten" status that No Show shares with
a real exit. Rehiring the same person hides the tab again — the data
stays, since it happened, but a checklist for someone currently working
has nothing to point at.
The engine (what counts as done, how progress is computed) moved into
lib/checklist.ts so onboarding and offboarding can't drift into two
different ideas of "done" the way two independent copies eventually do;
lib/onboarding.ts and lib/offboarding.ts bind it to their own item list,
and the tab UI is a single ChecklistPanel bound the same way.
Checked against the real database: a real exit creates all eleven items
in the same transaction as the exit itself; a No Show creates none;
rehiring flips the tab off while the old answers stay queryable. One
false alarm during that check turned out to be the user's own clicks on
a real employee's onboarding list, made in the browser while trying the
earlier feature — left untouched, not test debris.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Works council members, expectant mothers, parents on leave, registered
disabled employees, apprentices — each has its own rules that come
before a dismissal. The tool does not judge whether one is lawful, but
it must not stay quiet about it either, and looking it up on the
contract tab is exactly the step that gets skipped under time pressure.
So: a checkbox, an optional end date, and a red warning at the top of
the termination panel naming the date — or saying plainly that no end
was recorded. It shows for a no-show too; the protection runs from the
start of the contract, not the first day worked.
The date is optional on purpose. A works council mandate has a known
end, a pregnancy does not, and a mandatory field would force an invented
number. A constraint says only what cannot be: an end date without the
flag, which would be a leftover nobody could interpret.
The field goes the whole way through — hire, data change, contract
sheet, export, report criteria (as a yes/no and as a date range), and
the import. A field that exists in one screen and not the next is how
people stop trusting the numbers.
Terminating is now offered for planned entries as well, labelled "Nicht
angetreten", with No Show preselected. Without it a person who never
turned up stayed a planned entry forever, since nothing else can end
one.
One finding worth recording: tsc has been reporting success on a broken
program. A generated file under .next got corrupted when a build ran
against a live dev server, and its syntax errors suppressed semantic
checking everywhere else — two genuine type errors in this change went
unreported until I typechecked with .next excluded. The file is removed
and the ordinary typecheck is meaningful again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Someone hired who then does not start needs an exit reason of its own,
and until now the case could not be recorded at all. Terminating on the
entry date failed on chk_assignment_range: the assignment was closed
with valid_to = valid_from, and an empty interval is forbidden there.
Moving the exit to the next day would have claimed a day of employment
that never happened — headcount, tenure, every as-of report.
"No Show" is now an exit reason, and it behaves differently in three
ways.
The exit date is always the entry date, whatever the caller passed. That
is what makes "never active" true rather than asserted: a person counts
as employed when their exit date is *after* the reporting date, and here
it never is. The status derivation needed no change at all — it already
says Geplant before the entry date and Ausgetreten from it on.
The position assignment is deleted rather than closed. The post was
never filled, it goes back to being open, and nothing records a holder
who never held it.
The status column goes to Ausgetreten immediately, even for an entry
still in the future. Otherwise it would read Geplant forever — nothing
runs later to correct it.
A constraint holds the first of those regardless of the path in,
including the import: exit_reason is distinct from 'No Show' or
exit_date = entry_date. "is distinct from" rather than "<>" so an empty
reason does not evaluate to null and slip through — the same three-
valued trap that let an earlier check pass the case it was written to
stop.
The dialog locks the date field when No Show is picked and says why, so
nobody types a date that would then be silently overridden. The
offboarding checklist is hidden: nothing was ever handed out.
Rehearsed against real data — a planned entry with a 2099 date passed
in, which came back as the entry date; derived status across three
reporting dates never Aktiv; a direct write with a mismatched date
refused; and an ordinary termination unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Employee names now read "Winkler, Hannah" wherever a person appears in a
list, a table, a heading or a tree node. That is the order a personnel
list is kept in, it is the order people are looked up in, and it finally
matches the sorting — the employee list has always been ordered by
surname, which made an alphabetical page look unsorted.
The name was being assembled inline in about twenty places. A rename
that catches half of them is worse than none, so it now goes through
fmtName in lib/format.ts and every display site calls it.
Sentences keep the natural order: "Hannah Winkler wurde versetzt" reads
like German, "Winkler, Hannah wurde versetzt" reads like a form. So the
toasts are unchanged and only labels moved.
Two things the change would have quietly broken:
The org chart's own filter matched against "first last". It now matches
either order, with or without the comma, so typing what you see works
and so does typing what you remember.
The print model sorted by the last word of the composed name, which
happened to be the surname and is now the first name — every printed
unit would have come out sorted by first name. It sorts on the surname
field itself now, which is what it meant all along.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Accessibility work on the UI layer, all of it rooted in one structural gap:
there were no form primitives, so every field was hand-assembled and every
field got the same details wrong.
Form primitives
- components/ui/Field.tsx (Field/TextField/SelectField/TextareaField) and
Button.tsx. Field generates the control id with useId and derives htmlFor
from it, which is what makes the association impossible to omit rather
than merely conventional.
- 92 labels existed, 4 used htmlFor, and no input carried an id at all: a
screen reader announced an unnamed edit box and clicking a label focused
nothing. Now every label resolves to its control (0 unassociated), and the
input class chain that appeared verbatim 85 times appears zero times.
- Field also takes a render prop, so Lookup, CountryPicker and Picklist get
the same wiring instead of a second, partial solution.
- SearchInput replaces three hand-rolled copies of the icon-in-a-box search
whose input had only a placeholder — not a label — and killed its own
focus ring with outline-none and nothing in its place.
- Toggle groups (workdays, reorg change type) became fieldsets with
aria-pressed; colour alone was carrying the selected state.
Comboboxes
- Lookup and CountryPicker were text inputs with a div of clickable buttons
underneath: typeable, but no keyboard path to a result and nothing telling
a screen reader a list had appeared. Both now carry role=combobox,
aria-expanded/controls/activedescendant and listbox semantics, with arrow
keys, Enter and Escape. Escape stops propagation, or it would close the
surrounding dialog along with the dropdown.
Dialogs
- useDialogFocus centralises what Modal and SlideOver each owed the
keyboard and neither provided beyond Escape: focus into the dialog on
open, Tab and Shift+Tab cycling within it, focus restored to the trigger
on close.
- SlideOver stays mounted for its transition, and aria-hidden does not
remove anything from the tab order — so every closed panel was leaving
invisible tab stops at the end of the page. `inert` fixes that.
Route states
- loading.tsx, error.tsx, not-found.tsx and global-error.tsx. Every page in
the (app) group is server-rendered per request, so without loading.tsx a
navigation showed nothing at all until the server answered, and a render
error dropped the user on Next's own screen with no way back.
Tests
- 22 component tests (vitest jsdom project). Two of them found limits of the
environment rather than of the code: jsdom implements neither `inert` nor
scrollIntoView, so the inert test asserts the attribute and the missing
scrollIntoView — which was taking the whole render down from inside an
effect — is stubbed in the setup file.
Reworks the app from a two-role (hr_admin/manager) model to a single
HR-only role gated by profiles.is_active, fixes transfer/promote/karenz/
reorg RPCs to actually defer future-dated changes via a new
pending_org_changes table instead of writing them immediately (applied
by a daily Vercel Cron route), makes reorg undo append-only instead of
deleting history, adds Karenz-return and history-date integrity guards,
deprecates the salary column, and adds explicit schema grants + perf
indexes needed to run against a fresh (non-hosted) Postgres instance.
Adds vitest unit + integration test suites (the latter against a real
local Supabase instance) covering all of the above, plus lint/typecheck/
build wiring (`npm run check`).
- supabase/functions.sql, functions_2.sql: Postgres RPCs for every
employee/position/reorg mutation (hire, terminate, transfer, promote,
start/adjust/return karenz, change data, rehire, create position, staff
internally, apply/undo reorg). Each resolves manager_id server-side,
writes history + audit atomically, and enforces hr_admin via
require_hr_admin() (backed by the existing RLS policy).
- actions/employees.ts, positions.ts, reorg.ts: Server Actions wrapping
the RPCs, returning success/error for client-side toast handling.
- Employees list (search/filter/pagination) and detail (4 tabs: Stammdaten,
Vertrag & Gehalt, Organisation, Historie) reading from employees_directory.
- 6 action slide-over panels: Transfer, Promote, Karenz (start/adjust/
return), Daten aendern (person+contract diffing), Terminate (with direct-
report reparenting warning + offboarding checklist), Rehire.
- lib/org.ts: shared division/department/team/location lookups.
Verified live: promote mutation updates salary, writes history/audit, and
the detail page reflects it after refresh, no console errors.
Note: the spec's Karenz-verwalten panel only covers employees already on
Karenz; added a start-Karenz mode (Karenzbeginn/geplante Rueckkehr) to
cover the Aktiv-employee case implied by the header button but not
specified in the panel list.
