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
2.2 KiB
source, audience, title
| source | audience | title |
|---|---|---|
| policy_docs | tenant | Shift Cover and Cancellation |
Filling an open shift
A shift is open from the moment it is published without a name against it. Open shifts are offered in this order, and the order is not a preference — skipping a step is what produces a rota nobody trusts:
- Staff already rostered at that venue who are under their weekly hours.
- Staff at other venues in the same region with the required certification.
- The wider talent pool, filtered to those whose availability covers the window.
An offer stands for four hours during the working day, or until 9am the next morning if it is sent after 6pm. After that it lapses and moves to the next group. Do not hold an offer open longer in the hope of a better answer — the person who would have taken it has usually accepted something else by then.
Late cover
A shift falling open inside 24 hours of its start is late cover. Late cover may be offered to all three groups at once rather than in order, because the cost of an unfilled shift now exceeds the cost of an imperfect match.
Late cover attracts a premium of one and a half times the base rate for the whole shift, not only the hours inside the 24-hour window.
Cancelling a shift
Cancelling a worker's confirmed shift with less than 48 hours' notice obliges the venue to pay four hours at the base rate, whether or not the worker is re-deployed elsewhere. Inside 12 hours it is the full scheduled length.
This applies to cancellations the venue initiates. A shift cancelled because the event itself was called off by the client is still a venue cancellation — the client's decision does not transfer the cost to the worker.
When a worker cancels
A worker withdrawing from a confirmed shift should do so as early as possible through the app. Withdrawals inside 12 hours are recorded against the worker's reliability, and three in a rolling quarter trigger a conversation with the venue manager before further shifts are offered.
A withdrawal for a reason covered by the sickness or emergency provisions in the staff handbook is not recorded against reliability. The manager records the reason at the time; a reason supplied a week later cannot be verified and will not be applied retrospectively.