Feature inventory & QA
A canonical, always-current map of every feature in your product — and a browser-based QA loop that re-verifies the ones that matter as your code changes.
Two loops keep an honest picture of what your product does and whether it still works. Feature inventory maintains a single canonical list of every user-facing feature, read straight from the code. Story QA then drives the highest-stakes of those features in a real browser to confirm they behave as documented. Both run on their own daily cadence and depend on a connected GitHub repo.
Feature inventory — the canonical feature map
Every day the inventory loop clones your repo, reads the actual code, and reconciles a single source-of-truth list — the map of features a solo founder can't keep by hand. It's read-only: it never edits code, never opens a PR. The rows it persists are the deliverable.
For each distinct user-facing feature — a capability a user would actually feel or use, like "Google OAuth sign-in" or "SEO audit report", not internal plumbing — it records:
- A user story — who wants it and why.
- Expected behavior — what should happen when the feature is used. This becomes the oracle Story QA verifies against.
- A lifecycle status —
live,partial,planned, ordeprecated.
Because it reuses a stable key per feature, a re-scan updates rows in place instead of duplicating them: new features are added, changed ones updated, and ones that disappeared from the code are retired. The inventory lives on the Features tab.
Story QA — verify the features still work
Story QA is the verification arm of the inventory. It drives your product in a real browser (Playwright/Chromium) to check that one feature story behaves as its expectedBehavior claims — recording the whole check as a single video.
It judges two things, and only these two:
- Logical correctness — does the documented flow actually complete, with no errors or dead ends?
- Objective friction — measured, not felt: number of steps and clicks to reach the goal, console errors, error toasts, and rough timing.
It is not a persona and not a reviewer — no taste, no "I felt", no findability judgments (a scripted browser run navigates nothing like a human, so "how long it took to find X" is noise — that's Cast's job). Each verification ends in a verdict: passed, friction, or failed.
How a sweep works
A daily dispatcher decides which stories are worth re-checking and fans out one browser run per story — it doesn't drive the browser itself.
- Scan what changed in the repo since last time.
- Prioritize against a budget of about 10 verifications a day: high-stakes areas first (auth, billing, anything that can lose or corrupt data, the core actions the product is for), plus any story that previously failed. It de-prioritizes cosmetic, copy-only, and
deprecatedstories, and prefers breadth across areas over re-checking one area. - Fan out — each chosen story gets its own run that writes and runs a Playwright test, records a video, and saves a verdict.
QA runs against staging
Story QA drives a real browser that clicks, types, and submits for real. It points at a staging URL with a throwaway test account, so even destructive flows are safe to exercise. Set the staging target and login from the QA settings.
What you get
- Feature inventory: a reconciled list of every feature with its user story, expected behavior, and lifecycle status — on the Features tab. No PR; the rows are the output.
- Story QA: per-story verdicts with a recorded video. A run with an actionable result — a failure or notable friction — becomes an awaiting-review ticket with the recording attached, so only the runs worth your attention surface.
Notes & limits
- Inventory is read-only — it scans and records; it never changes code.
- QA verifies one story per run and keeps each check under a few minutes; a mismatch is recorded as a finding rather than aborting the run, so the video always finishes.
- A clean skip is valid. If nothing meaningful changed, the dispatcher skips the day with a one-line reason instead of re-running everything.
- Inventory feeds QA. Story QA verifies the
expectedBehaviorthe inventory recorded — keep the inventory current and QA stays meaningful.
Docs
Keeps your documentation complete and accurate against your code, one reviewable pull request at a time — and stands a docs site up from scratch when you don't have one yet.
Watchdog
A daily app-health monitor that drives your product in a real browser to probe the flows that matter, and files a draft ticket — with the recording — for every failure it reproduces on screen.