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.8 KiB
source, audience, title
| source | audience | title |
|---|---|---|
| policy_docs | role:admin, role:employer | Right to Work and Certification Checks |
Before a first shift
No worker starts a first shift without a completed right-to-work check. This is not a paperwork step that can follow the shift: the obligation is on the business, the penalty falls on the business, and a shift worked before the check cannot be undone by completing it afterwards.
The check is a sight of the original document, or a share code verified against the online service, recorded with the date and the name of whoever checked it. A photograph sent by message is not a check.
Documents that expire
Where a document carries an expiry date, the worker's record carries the same date and they stop being offered shifts seven days before it. Seven days rather than on the day, because a licence renewed on the morning of a shift is a licence that was not in place when the rota was published.
Role-specific certification
| Role | Required before first shift | Renewal |
|---|---|---|
| Security officer | SIA licence, valid and in date | Three years |
| Bar staff serving alcohol | Personal licence where required by venue | Venue-specific |
| Kitchen and food handling | Level 2 Food Safety | Three years |
| Supervisors | First aid at work | Three years |
A worker whose certification lapses is not removed from the pool. They stop being offered shifts for roles that require it and remain eligible for roles that do not, which is usually the difference between losing a good worker and losing three weeks of their availability.
Recording a check
Checks are recorded against the worker profile, not against the shift. A check done for one venue is valid across the organisation — asking a worker to prove the same thing at each site is how a pool of willing people becomes a pool of people who work somewhere else.