QA Scribe is a local-first testing notepad
for people who turn exploratory testing into
reusable Testware. It captures the raw work
of a testing Session, then helps shape
that material into Findings and Drafts. The
important boundary is local control: storage is
local SQLite, attachments are local files, and
AI runs through local command-line tools. The
user flow starts with a tester writing
notes during a focused Session. Those notes
can include context, observations, logs, API responses
screenshots, and follow-up thoughts. When the tester
is ready, the same material can become
editable Testware or a structured Finding. The
app keeps those records linked back to
the testing evidence. The runtime has three
layers. The React renderer owns the desktop
interaction model. The Tauri bridge exposes typed
commands to the renderer. The Rust core
owns storage, validation, managed files, generation prompts
and response persistence. SQLite and the attachment
directory sit behind the core service layer
Provider CLIs sit outside the app and
are only called after explicit user action
Session capture moves through a narrow path
The editor calls a frontend action factory
The action calls a typed Tauri command
The command locks the app state and
calls SessionService. SessionService validates ownership and writes
the SQLite rows. That path keeps the
UI simple and keeps data rules in
Rust. The domain model is intentionally small
A Session scopes the work. An Entry
stores raw testing material. A Finding records
a structured conclusion. A Draft stores editable
Testware. Evidence connects conclusions back to Entries
and managed attachments. An AI Run records
each generation request and its outcome. Attachments
are managed instead of being loose file
references. When an image is pasted or
uploaded, the backend sanitizes the path, writes
it under the Session attachment folder, hashes
the bytes, and stores metadata in SQLite
Preview reads verify the hash before returning
a data URL. Rich editor images use
a QA Scribe attachment protocol instead of
arbitrary local file paths. AI generation is
explicit. The frontend opens a preflight step
where the user chooses an action, provider
model, and reasoning effort. The backend prepares
a Generation Context and a running AI
Run. Then a local Claude, Codex, or
Copilot CLI receives the prompt on standard
input. Streaming events update the UI until
the final Draft, Finding, or summary is
persisted. Provider readiness is a separate system
QA Scribe checks whether each local CLI
is installed and authenticated. It detects model
choices where the CLI exposes them, caches
readiness briefly, and never stores provider API
keys. This keeps authentication with the provider
tool that already owns it. On the
frontend, one controller coordinates most app state
useAppController owns the active Session, note body
Drafts, Findings, provider state, generation jobs, busy
flags, and notices. AppShell lays out the
desktop frame. Views render Notes, Testware, Findings
and Settings. The editor and workflow modules
handle rich text, preflight, copy, and deletion
flows. The codebase is compact but broad
There are eighty-two Rust files, fifty-six TypeScript
and TSX files, and a release pipeline
that builds desktop artifacts and Linux package
repository metadata. Recent churn concentrates around provider
process execution, generated bindings, frontend controller tests
and release automation. Those are the areas
to test carefully after changes. You can
remember the repository by its seams. Change
domain rules in qa-scribe core. Change desktop
commands in src-tauri. Change user workflows in
frontend source. Change packaging in scripts and
GitHub workflows. The design goal is steady
capture testing evidence locally, keep it traceable
and turn it into useful Testware without
taking control away from the tester. For
a new contributor, the safest starting point
is the workflow seam closest to the
change. If the behavior is about saved
data, start in the Rust service tests
If it is about how a tester
moves through the app, start in the
React action factories and view tests. If
it is about generation reliability, start with
the job runner, stream executor, and provider
detection tests. That split makes the repository
easier to reason about than its desktop
shape first suggests. That is the tour
a small desktop app, a clear core
service boundary, and a testing workflow that
preserves the tester's evidence. The useful mental
model is capture first, structure second, and
generate only when the user asks for
it.