Architecture and data flow
The boundaries between local execution, stored data, target services, and AI
reopt QA combines a desktop app, a local execution engine, and a bundled browser runtime. Tests and results are managed on your computer. Target services and AI providers may require external connections.
Desktop UI
↕ HTTP / WebSocket on the same computer
Local execution engine
├─ Browser runtime → target service
├─ Execution records → local storage
└─ AI tasks → configured model provider
External MCP client
↕ stdio
reopt-qa mcp → local execution engineLocal components
The directly distributed app includes a Tauri shell, React UI, Rust execution engine, and Node/Playwright runtime. The engine manages queues, browser work, result storage, and queries.
The UI and engine communicate over loopback. The desktop engine receives a port at startup; its address must not be assumed to match the development server's fixed port.
When data moves
| Task | Connection and data |
|---|---|
| Read stored results | Query locally stored records through the engine |
| Explore or test a service | Browser communicates with the target and performs authentication and test actions |
| AI generation, investigation, fixes, and classification | Required code, page content, and failure records may be sent to the configured provider |
| Conditional fix approval evaluation | Supporting evidence may be sent to a separate model provider |
| Read results through MCP | Local bridge returns data to the external AI client; subsequent handling follows that client's configuration |
| Export and share reports | Exported content becomes available to its recipients |
A local connection between the MCP bridge and the app does not mean the external AI client avoids external transmission. Manual fix approval controls file application; it does not block AI requests from sending data.
Separate records from runtime files
The directly distributed app stores user data in agent-data under the application data directory. The separate runtime contains replaceable execution components. Reports, logs, screenshots, and traces depend on execution and collection settings; not every run produces every artifact.
To share verification criteria, manage test code, metadata, and required environment conditions together. Keep passwords and authentication sessions out of test code and shared reports. Installing the app does not automatically synchronize team accounts or test data.
From observation to verification
Use the Service map to organize observed structure, then define intended behavior through scenarios. Review results, make improvements, and check again under the same conditions. Managing the gap between observed and intended behavior with evidence is the working approach behind Post Architecture.
Product structure and improvement records
Features store expected behavior and linked pages and tests. User flows store ordered steps, source, and user confirmation. Improvements retain observations, evidence references, decision notes, and retest evidence. These records belong to individual projects; map collections and test runs remain separate records.
AI chat can include the selected feature, flow, or improvement as context. Review or exclude it in the panel before sending. External MCP's get_product_context also reads project features, flows, and improvements. Consider both read permissions and transmission through the external AI client.