Assay — Manual test plans that actually get run

Assay's run view with a failed case open: the failed step is marked, and the what-actually-happened box holds the description a defect is built from. — A failed case: which step broke, and what actually happened. Enlarge to see the full screen.

Working a run

A failure says which step broke.

Checking off steps is the difference between "A-07 failed" and "step 4 of A-07 failed, and here is what happened." A case can't be recorded as failed without that description, so the defect that follows is never an empty card.

How a run works

Plans and versions

Your markdown goes in, and comes back out.

Assay reads the fleet's manual-test-plan format with a deterministic parser and keeps every version. Runs stay on the version they were generated from, so what you tested stays true after the plan changes, and export writes the plan back out as markdown.

Plans and import

Assay's plan detail page: a plan's sections and cases with priorities and a known-defect tag, and a note that the plan has two versions. — A plan with two versions: runs pin to the one they were generated from. Enlarge to see the full screen.

Assay's Agents page: two registered agents, one of them holding a live lease on a case with its time left and heartbeat count. — Agents: the registry, and the leases held right now. Enlarge to see the full screen.

Agents and defects

Agents take cases off the queue. Dead ones give them back.

An agent claims one assigned case at a time on a lease and reports every step. If it stops, the lease expires and the case goes back to the queue with its reported steps intact. Failures then link to Docket, and anything that can't reach it is shown, not dropped.

Agents and defects

Features

A test plan is a document. Assay makes it an instrument.

These are the jobs Assay does today. Plans come in as markdown through the importer or the MCP tools; people work runs in the web app; agents claim work through the API and MCP.

Import the markdown. Keep the markdown.

01

A real parser, not a model call

Sections, case tables, priorities, defect tags, the environment notes, and appendices are read by a deterministic parser, so the same document always gives the same plan.

02

Dry run by default

Import reports what it found (sections, cases, defect tags, and every warning) and writes nothing until you say so. Importing changed text adds a new version; importing the same text again changes nothing.

03

Exports back to markdown

Export writes a document a person would accept as the source, and the exporter's tests check that it imports back to the same plan. The plan is never trapped in the database.

04

Honest about what it guessed

Steps split on explicit numbering or semicolons. A split on sentence boundaries is a weaker guess, so the import report marks it for review, and a single step that reads like several is flagged and left whole.

Evidence that can't shift underneath you

05

Runs pin to a plan version

Plan versions are append-only and a run stays on the version it was generated from. Publish a new version mid-run and the run does not move.

06

Generate the slice you need

The whole plan, P0 and P1 only, the known-defect cases, the agent-executable cases, or the manual-only cases, or your own filter by section, priority, tag, defect tag, or case key.

07

Step by step, not just case by case

Check off individual steps, then record the case as pass, fail, blocked, or not applicable. A failure can't be saved without a description of what actually happened.

08

Keyboard-first

Move between cases and steps, toggle a step, and record a result without the mouse. Shortcuts are ignored while you type in a text box, and the command palette (Command-K) jumps to a case or a page and carries the verbs for the case you're on.

Assign a case to a person. Or to an agent.

09

Assign one case or a whole slice

Hand cases to a person or an agent one at a time, or in bulk by case key, section, priority, or everything unassigned. Your own queue shows on the dashboard, and the run view has a Mine filter.

10

Agents claim real work

An agent claims the next case assigned to it, highest priority first, executes it, and reports each step. The claim hands over the steps, the run's environment settings, and the plan's environment notes in one response. Agent results are marked as agent results in the run.

11

A dead session loses nothing

A claim is a lease, not a lock. It runs 30 minutes by default and can be extended up to 4 hours from the first claim. If the agent stops, a sweeper that runs every 30 seconds returns the case to the queue, and every step it already reported stays recorded.

12

Agents can't do damage

An agent key carries five scopes: read, claim, report, evidence, and comment. It can't author a plan, assign work, or administer anything, and no two agents are handed the same case.

A failure has somewhere to go

13

Linked or filed in Docket

A failed case can be filed as a Docket card with its steps, expected and actual results, and environment, or linked to a card that already exists. A repeat of the same failure comments on its card instead of filing another.

14

Nothing fails silently

Side effects go through a durable outbox with bounded retries, so a Docket outage never blocks a tester's click. The Defects page leads with anything that never reached Docket and shows the error.

15

Evidence, with secrets stripped

Attach log excerpts, HTTP transcripts, JSON, text, links, or screenshots to a case or a step. Tokens, keys, and authorization headers are redacted before anything is stored, and the patterns that fired are recorded.

16

Say it in Chirp

When a Chirp webhook is configured, Assay posts when a run starts and finishes, when a P0 or P1 case fails, when a defect is filed, and when a run stalls. It batches the summary, so a long run is not a flood.

Screens

See it in light and dark

Real captures of the running tool, with fictional StrataForge Robotics data. They follow your theme.

Assay's run view: a filterable case list on the left and the step checklist for the open case on the right, with pass, fail, blocked, and not applicable buttons. — The run view: every case on the left, every step on the right. Enlarge to see the full screen.

Assay's run view with a failed case open: the step that failed is marked, and the what-actually-happened box holds the description the defect is built from. — A failed case: the step that broke and what actually happened. Enlarge to see the full screen.

Assay's Defects page: two failures linked to existing Docket cards, each with its state and a link to the card. — Defects: every failure and the card it belongs to. Enlarge to see the full screen.

How it works

Import, generate, work, link

Import
Point Assay at a markdown test plan. It parses the sections, cases, steps, priorities, and defect tags, and reports what it found before it writes anything.
Generate
Create a run against an environment: the whole plan, just the P0s, or one section. The run pins to that plan version.
Work
Check off steps and resolve cases, or assign them to people and agents who claim and report them.
Link
A failed case becomes a Docket card, or is linked to the one that already exists, with a path back to the case.

Accessibility

Built so everyone can use Assay.

Assay's web app is built on the Renkara design system and keeps a keyboard map for working a run. Here is what the product supports today and what has actually been checked. We do not claim a WCAG conformance level for the product, and Assay has no automated accessibility scan yet.

Read the accessibility statement and evidence

Tech specs

Under the hood

Assay technical specification
Backend	FastAPI (Python), with REST under /api/v1 PostgreSQL through SQLAlchemy (async) and Alembic migrations Append-only plan versions; runs pinned to a version Leased agent claims on SELECT ... FOR UPDATE SKIP LOCKED, with a supervised sweeper A durable outbox with bounded retries for every side effect
Web app	React 19 and TypeScript, built on the Renkara design system A command palette and a keyboard map for working a run Light and dark themes; the run view fits 375 by 667 Pages for the dashboard, plans, runs, defects, and agents
Execution	Scoped agent keys: read, claim, report, evidence, and comment only Leases with heartbeats, a hard cap, and an attempt limit Server-side redaction of tokens and keys in evidence Optimistic concurrency: a simultaneous edit gets a conflict, not an overwrite
Integrations	An MCP server with 40 tools, relayed to agents by Roost Docket cards: filed with de-duplication, linked, or suppressed Chirp notices through an inbound webhook Authentication by the Renkara identity service; agents use keys
Stands in for	Markdown test plans nobody could check off, Failures copied into a tracker by hand

Works with

Part of the Renkara fleet

Docket
Failures are filed as Docket cards or linked to existing ones, with the severity taken from the case's priority.
Chirp
Run starts, completions, P0 and P1 failures, filed defects, and stalled runs post to a Chirp channel through an inbound webhook.
Roost
Relays Assay's MCP tools to agents on every machine.

MCP tools

Built for agents as well as people

Agents and people author plans as markdown, generate and read runs, assign work, claim and report cases, attach evidence, and link or file defects through Assay's MCP tools.

Plans

list_plans
get_plan
create_plan
update_plan
archive_plan
import_plan_markdown
export_plan_markdown
list_plan_versions
get_plan_version
publish_plan_version
diff_plan_versions

Runs

generate_run
list_runs
get_run
update_run
get_run_progress
export_run
list_run_cases
get_run_case

Assignment

assign_case
bulk_assign
get_my_queue
list_agents
register_agent

Execution

claim_next_assignment
heartbeat_claim
release_claim
report_step_result
report_case_result
reset_case
list_claims

Evidence

attach_evidence
list_evidence
retract_evidence

Defects

list_defects
file_defect
link_existing_defect
suppress_defect

Operations

check_service_health
get_diagnostics

FAQ

Questions people ask

Is Assay available to other teams?

Assay is part of Renkara's own tool fleet, and this site shows what it does and how it is built. It is not offered for sale here. Write to contact@renkara.com with questions.

Can I write or import a plan in the web app?

Not today. Plans come in as markdown through the importer script or the MCP import tool, and an agent can write the markdown for you. The web app shows plans and their versions, and it is where runs are worked.

What happens if an agent dies in the middle of a case?

Its lease expires and the case returns to the queue, and every step it already reported stays recorded. A case that keeps losing its claim is blocked with a reason instead of looping.

Does a failure always file a Docket card?

Only when the plan has a Docket board and auto-filing on. A repeat of the same failure comments on the existing card, and a failure can instead be linked to a card that already exists or suppressed with a reason.

Is the data in the screenshots real?

No. Every screenshot is a capture of the running app against fictional StrataForge Robotics data.

Contact

Questions about this tool?

Write to Renkara Media Group and a person will answer.

Email contact@renkara.com

Manual test plans that actually get run.