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
52 lines
2.2 KiB
Markdown
52 lines
2.2 KiB
Markdown
---
|
|
source: policy_docs
|
|
audience: tenant
|
|
title: 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:
|
|
|
|
1. Staff already rostered at that venue who are under their weekly hours.
|
|
2. Staff at other venues in the same region with the required certification.
|
|
3. 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.
|