butschster/bridge

A runtime for driving other people's applications: giving synthetic staff accounts in a product, sending them to work in it all day, and keeping a trail of what each one was allowed to do, what it was told, what it did, and what it found.

Testing is the first kind of work it does, not the only one — a run that publishes an article is the same machinery with a different persona, a different grant and a different destination.

What it is for

Nobody tests a product the way its users break it. A test suite asserts what somebody thought of in advance; real users type fragments, misspell vendor names, ask the wrong specialist and give up quietly.

A complaint is not a finding. "The search returned nothing" is worth nothing until you know what the corpus held, whose rights the search ran under, what the person was told to do, and whether the target was even up. Half of this runtime is the trail that turns the first sentence into the second.

Three layers, and the line between them is secrets

| Layer | Where it lives | Why there | |---|---|---| | Integration | registry, ships as a module | the declaration: what the product is, how to work with it, what capabilities it has | | Project | a component | one use of it: address, credentials, actors, work | | Actor / job | components inside the project | who does what |

A credential cannot go in a registry entry — the entry travels into the image and into git. Everything else follows from that.

Capability by presence

An integration declares what it has and omits the rest; an absence is an answer, and a job that needs a conversation is refused when it is defined rather than halfway through a run.

target        who you are talking to, and whether it is up   (required)
actors        accounts and roles as the target knows them
credentials   a credential per run, and its revocation
tools         what an actor may do, as tools an agent is handed
conversation  the surface, when the thing under test IS the conversation
oracle        truth only the target knows
publish       work leaving here and landing there

output_kind on a kind of work decides where a result goes: finding into the project's journal, artifact into the publish capability, report into the run's own thread. The run itself knows nothing about QA.

The invariants

The tool list is the permission boundary. The platform's invoke merges the traits a caller passes over the agent's own and cannot be told an exclusive list, so a run reads the agent's own configuration, records what it brought, and refuses anything the project has not permitted in writing.

The credential is given back in every exit, including the exits nobody plans: a run has a process of its own and survives its caller; if that process is killed, the markers it wrote let a later sweep revoke what it held.

An event carries a reference, never content. The finding's text and the transcript stay in the history, behind a request.

The agent's own answers are never the oracle. What the corpus holds is asked of the product by deterministic code that never saw the reply — an expectation written before an episode cannot be reinterpreted after it.

What a run leaves behind

One record per run: who (actor, identity in the target, credential by reference, the exact grant, what the agent brought of its own, skills at their versions), conditions (the target's health at the start), how (the ordered steps with who did each, and the Flow that holds the transcript), the briefing verbatim, the errand and whether it was a fair test, and the outcome. Plus a handle — eight characters, resolvable on its own — so two people can talk about the same run out loud.