Aravind
a222dcd3e4
§9 says no agent ships without evals. Eight of the nine had none: the two
other suites in evals/ are harness fixtures rather than agents in the
registry, so the rule was being met by one agent in nine.
Evals — 40 new cases, five per agent, every one carrying mustNotLeak:
- the agent is loaded from its real spec in agents/*.md rather than
written out again in Go. A hand-copied agent tests the copy: it keeps
passing after somebody edits the spec, which is the moment it most
needed to fail.
- callNamed calls the tool a case names. toolThenAnswer always called
tools[0], so seven of positions-agent's eight tools were unreachable,
and a boundary nothing calls is a boundary nothing tests.
- seedWorkspace fills BOTH tenants. A leak test against an empty second
tenant cannot fail.
Verified by breaking workersByScore's org predicate: six cases across four
agents fail with LEAKED "RIVAL".
Knowledge — six policy documents, taking the corpus from 2 to 8 (34
chunks). Three restricted to admin and employer, five tenant-wide. They
cover what the tools cannot: a tool reports how many shifts went unworked,
a policy says what cover costs inside 24 hours.
corpus_test.go treats those documents as product rather than fixtures. The
first version was tautological — it read audience: from a file and checked
that file's audience was enforced, so opening a restricted document passed.
mustNotBeTenantWide now holds that judgement apart from the files, with the
reason recorded for each.
CI — the checks this repository already had, made unskippable. testutil
calls t.Skipf on an unreachable database, so a dead service container would
produce a green build over a suite that ran almost nothing. Simulated: go
test exits 0 with 74 tests skipped, including every tenant-isolation test.
The guard exits 1 and names them, while still allowing TestLive* to skip
without a model key.
This CI tests; it does not deploy. The README's claim that migrations are
run by CI against the target database remains aspirational.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0186JgqQUCDS8ZwGmyw3ymWu
1.7 KiB
source, audience, title
| source | audience | title |
|---|---|---|
| policy_docs | tenant | Overtime and Working Time |
What counts as overtime
Overtime is time worked beyond the scheduled end of a shift. It begins at the scheduled end, not at the point the worker expected to leave, and it is recorded in fifteen-minute blocks rounded up.
Time spent waiting to be released at the end of an event is working time. A worker held back to clear a room is on overtime from the scheduled end, whether or not they were serving.
Approval
Overtime beyond thirty minutes needs a supervisor's approval at the time it is worked. Approval after the fact is possible but is the exception, and a venue where most overtime is approved retrospectively is a venue with a rota problem rather than an approval problem.
A supervisor may approve up to two hours. Beyond that needs the venue manager.
Weekly limits and rest
No worker is scheduled beyond 48 hours in a week averaged over 17 weeks. A worker may opt out in writing and may withdraw that opt-out with seven days' notice.
There must be eleven consecutive hours between the end of one shift and the start of the next. A shift ending at 2am cannot be followed by one starting before 1pm the same day. The rota should not offer it; if it does, the offer is declined without prejudice to the worker.
A break of twenty minutes applies to any shift over six hours, taken away from the service floor and not at the end of the shift.
When overtime is climbing
Sustained overtime is a rota signal, not an individual one. Where overtime per scheduled shift has risen for several weeks running, the venue manager reviews headcount for that role before approving further overtime — the cheapest hour of overtime is still more expensive than the shift that should have been rostered.