Screenshots
See It in Action
The run view — every case on the left, every step on the right, entirely keyboard-driven
Features
A Test Plan Is a Document. Assay Makes It an Instrument.
A manual test plan written in markdown is an excellent document and a terrible instrument. You cannot check off a step. You cannot tell who has run what. A failure has to be hand-copied into a tracker. And a plan that took hours to write gets executed once, then rots — because nobody can see its coverage decaying. Assay keeps the document and adds the instrument: import the markdown, generate a run, work it case by case, and let every failure file itself.
Plans
Import the Markdown. Keep the Markdown.
Deterministic Markdown Import
A real parser, not a model call — sections, case tables, priorities, defect tags, appendices, and Mermaid diagrams all survive. Import is reproducible, so the same document always yields the same plan.
Dry Run by Default
Import reports what it found — counts per section, priority breakdown, and every warning — before writing anything. An exploratory parse can never surprise you with a new version.
Round-Trips Back to Markdown
Export produces a document a human would accept as the source, and re-imports to identical content. Assay never traps your plan in a database; edit it here or there, as you like.
Honest About What It Guessed
Source plans cram several steps into one prose cell. Assay splits only on a real signal — explicit numbering or semicolons — and reports anything it had to guess. A bogus step boundary makes a checklist lie; an over-large step does not.
Runs
Evidence That Cannot Shift Underneath You
Runs Pin to a Plan Version
Plan content is append-only, and a run is bound to the exact version it was generated from. Publish a new version mid-run and the run does not move. A record of what was tested has to stay true after the plan changes.
Generate Exactly the Slice You Need
Whole plan, P0 and P1 only, one section, the known-defect regression suite, or just the cases an agent can run. Presets are stored filters, so any of them can be tuned.
Step-by-Step, Not Case-by-Case
Check off individual steps with per-step notes. When a case fails, the record shows which step broke — the difference between a useful defect report and “it didn't work.”
Keyboard-First
Move between cases and steps, toggle, resolve, and jump to any case key without touching the mouse. ⌘K carries verbs as well as links, so the palette can resolve the case you are already looking at.
People and Agents
Assign a Case to a Person. Or to Claude.
Multi-User by Construction
Assign cases individually or in bulk by section, priority, or “everything unassigned.” Every result records who produced it and when.
Claude Agents Claim Real Work
Assign cases to a registered agent and a Claude session claims them off a leased queue, executes them against the real system, and reports each step. Agent results are attributed as agent results, everywhere.
A Dead Session Loses Nothing
Claims are leases, not locks. If an agent stops, its work returns to the queue automatically — but every step it already reported stays recorded. Losing the lease never loses the results.
Agents Cannot Do Damage
An agent key grants exactly five things: claim, report, attach evidence, comment, read. It cannot author a plan, assign work, or manage users. Cases are agent-runnable only when an author says so.
No Two Agents Get the Same Case
The claim protocol hands each case to exactly one caller, under contention, using the database's own row-locking. Two Claude sessions working the same run never duplicate a result or contradict each other.
Failures
A Failure Files Itself
Failing a Case Requires Saying Why
A fail cannot be recorded without a description of what actually happened. The defect card is generated from that text, and an optional field guarantees empty cards.
Auto-Filed Docket Defects
A failure becomes a Docket card carrying the repro steps with per-step outcomes, expected versus actual, environment, priority, and a link back to the case — enough that the fixer never has to ask what happened.
Deduplicated, Not Duplicated
The same failure recurring across runs comments on the existing card instead of filing a twelfth copy. A genuinely different failure of the same case still files separately.
Nothing Fails Silently
Every side effect goes through a durable queue. If Docket is unreachable, the result still commits, the problem is visible on the case, and the card files on retry. A dropped defect is not an acceptable outcome.
Integration
MCP Server — 33 Tools
Author Plans from Claude
Create plans, sections, cases and steps, publish versions, diff two versions, and export back to markdown — a whole plan can be written in a conversation.
Generate and Work Runs
Generate a run with any preset or filter, list and inspect cases, report step and case results, and pull progress — the same surface the web app uses.
The Agent Lane
Claim the next assignment, heartbeat the lease, release it, and report results. The claim returns everything needed to execute in one call — including the plan's environment notes, so an agent is never testing blind.
Accessibility
Built for Everyone
WCAG 2.1 AA Compliance
4.5:1 contrast for body text, 3:1 for large text and UI components, in both light and dark themes.
Keyboard Navigation
Every interaction reachable via keyboard. Logical tab order, visible focus indicators, Escape-to-dismiss for modals.
Screen Reader Support
VoiceOver, NVDA, and JAWS tested. Semantic HTML, ARIA labels, live regions for dynamic updates.
Reduced Motion
Respects
prefers-reduced-motion. Usable at 200% zoom. Touch targets meet 44x44 minimum.
How It Works
Import, Generate, Work, File
Step 1: Import
Point Assay at an existing markdown test plan. It parses sections, cases, steps, priorities and defect tags, and reports exactly what it found before writing anything.
Step 2: Generate
Create a run against an environment — the whole plan, or just the P0s, or just one section. The run pins to that plan version and cannot drift.
Step 3: Work
Check off steps, resolve cases, attach evidence. Assign whatever you like to teammates, or to a Claude agent that claims and executes it for you.
Step 4: File
Every failure becomes a deduplicated Docket card with the steps, the expected result, what actually happened, and a link straight back to the case.
Technical Specifications
Under the Hood
Backend
- FastAPI (Python 3.12), SQLAlchemy 2.0 async
- PostgreSQL — append-only plan versions, runs pinned to a version
- Leased claim protocol on
SELECT … FOR UPDATE SKIP LOCKED - Durable outbox for every external side effect
Frontend
- React 19, TypeScript, Vite 8
- @avian/design-system, canonical AppShell and ⌘K palette
- Full keyboard map with an input-focus guard
- Light and dark mode, mobile-safe down to 375px
Execution
- Scoped agent API keys — execution scopes only, never authoring
- Leases with heartbeat, hard cap, and an attempt limit
- Supervised sweeper returns abandoned work to the queue
- Server-side redaction on all captured evidence
Integrations
- MCP server — 33 tools (Streamable HTTP + stdio bridge)
- Auto-filed, deduplicated Docket defects
- renkara-auth single sign-on
- Registered fleet-wide through Roost as
assay
Development
100% Built by Claude
Every tool in the Renkara fleet was built by Claude (Anthropic) working alongside a single human supervisor. Every line of code, every test, every deployment: AI-authored with human direction. The leverage factor across the fleet runs in the 20x–50x range, with individual sessions regularly exceeding 100x.
See the daily leverage records for per-task numbers across the full build history.