Run this repo's integration tests against a Veris dependency sandbox.
The sandbox is a set of stateful, contract-accurate twins of the services this
code depends on. The code under test is
never modified and never told: it
keeps its production hostnames, credentials, and client stack, and
reroutes its outbound HTTP(S) into the sandbox from outside the
process. Your job is to stand that pipeline up, prove it actually intercepted,
and only then trust any test result.
Core framing: green means nothing without proof of interception
Everything in this skill exists to make one sentence true: a passing test
proves the integration works against the sandbox. Two rules follow.
- Never modify the code under test to point it at Veris. No base-URL
overrides, no injected config, no test doubles. If the code path you test is
not the code path that ships, the green is fiction. The proxy is the whole
mechanism.
- Never report tests as passing without evidence the sandbox received the
traffic. A suite that quietly stopped calling its dependency, a runtime
that ignored the interception, and a working run all print the same test
output. The proxy prints a receipt — what the sandbox actually received,
per service — after every run, and an run whose receipt is
empty exits 3 on its own: the environment already names the services, so
"the suite reached the sandbox at all" is asserted for you. When the tests
must touch a specific service, sharpen with
--require-service <name>[:count]
Do not declare the task done until the tests are green and the receipt
shows the sandbox received the traffic the tests were supposed to send.
The mode: container, always
Everything runs through
veris-proxy run --image ...
. The proxy runs in
its own container and your image runs in a second one sharing its network
namespace; an
redirect moves the traffic in the kernel, below
every library. Nothing in the process under test has to cooperate, so the
routing covers
every runtime: Java, static Go binaries, Apache
HttpClient, aiohttp. (
Trust is still decided in-process, and an SDK that
ships its own CA bundle decides it alone — see
phases/troubleshooting.md.)
Your image needs no capability, no iptables, no entrypoint change, and no
particular base — distroless and scratch work. All requirements sit on the
proxy's own container.
(The binary also has a host tier —
without
, environment
variables only. Do not use it in this skill: it covers only libraries that
honour proxy variables, and its gaps are silent. If the work truly cannot
run in a container, stop and tell the user rather than falling back.)
There is no committed proxy config to maintain. The run names an
and the whole routing — which production hostnames map to
which sandbox services — is derived from the control plane plus a routing
table measured against the real vendors and embedded in the binary. Never
write hosts files by hand.
The phases
Work the skill as two phases plus a failure manual, each in its own file.
Read the file fully at the point named — the details there are
load-bearing, not optional:
- phases/preflight.md — Phase 0, once per
environment: seven check-first gates (API key, MCP server, testing guide,
proxy binary, docker, a runnable test image, service manuals + the default
world). Run through it before the first run against any environment, and
whenever a prerequisite might have changed.
- phases/running.md — Phase 1, every run: the one
run command and its flags, receipts and assertions, exec
sessions for iterative work, webhooks via , seeding and fault
injection, teardown. Autonomous once preflight holds.
- phases/troubleshooting.md — the moment
anything fails or confuses: the evidence-first diagnosis order (receipt,
then , then theories), empty-receipt causes, exit codes,
and TLS trust failures from SDKs that bundle their own CA. Read it
before forming a theory, not after one collapses.
Reporting back
Keep a running record of anything about the sandbox that confused or
blocked you: gaps in its documentation, behavior that contradicted the docs,
responses that differ from the real vendor, failures you could not attribute.
Include request/response evidence. Give that list to the user verbatim at the
end — it goes back to Veris, and it is how the twins improve.
Ask before
- installing veris-proxy
- registering the MCP server (the user runs this — it needs a restart)
- anything that sends repo code or data to a new external destination
Sandbox lifecycle operations (
,
,
,
) are routine and yours to perform freely.