Dogfood Example

The dogfood app in examples\dogfood exercises the current end-to-end loop:

1. Frontend console and error instrumentation.
2. Wrapped Tauri command calls.
3. Wrapped Tauri event emit/listen calls.
4. Backend Rust tracing logs and spans.
5. CLI and MCP reads from the same SQLite session.

Run the app

cd examples\dogfood
npm install
npm run build:api
npm run tauri dev

Click each button in the app. The failing-command button is intentionally useful for agents: it creates a frontend tauri.invoke failing_command span with ERROR status and a backend tracing error that contains Intentional dogfood backend failure.

The dogfood commands also opt into Auditaur’s Tauri IPC trace context bridge. The frontend invoke wrapper sends W3C traceparent through Tauri invoke request headers plus the reserved auditaurTraceContext compatibility argument, and the Rust commands use #[tauri_plugin_auditaur::auditaur_command] to attach backend spans to the frontend invoke trace without command-name or timestamp heuristics.

The dogfood frontend enables the Tauri-native drive bridge in its single main WebView. Agents can use it to exercise selector actions and targeted screenshots:

cargo run -p auditaur-cli -- drive --app auditaur-dogfood --active --json inspect
cargo run -p auditaur-cli -- drive --app auditaur-dogfood --active --json exists --selector "#successful-command" --visible-only
cargo run -p auditaur-cli -- drive --app auditaur-dogfood --active --json screenshot --selector ".card .actions" --output dogfood-actions.png

Selector screenshots should report screenshotBackend=tauri_native_webview_snapshot, screenshotScope=selector, and selectorRect when native WebView capture succeeds.

Run a confidence drill

Use drill run when you want Auditaur to own the dogfood app lifecycle and return a stable pass/fail result:

cargo run -p auditaur-cli -- drill run --app auditaur-dogfood --require-drive-bridge --selector "#output" --expect-text "Auditaur initialized" -- npm --prefix examples\dogfood run tauri dev

The drill waits for a fresh dogfood Auditaur session, checks the Tauri-native drive bridge, verifies the selector text, writes auditaur-drill-report.json, and cleans up the spawned app process tree. See Drill Confidence Runs for report, hook, and exit-code details.

Manual smoke path:

1. Emit console log.
2. Throw frontend error.
3. Emit/listen to frontend event.
4. Call successful command.
5. Call failing command.
6. Ask backend to emit event.

Inspect the data

Copy databasePath from the latest discovery file under:

Platform	Discovery directory
Windows	%LOCALAPPDATA%\auditaur\apps
macOS	~/Library/Application Support/auditaur/apps
Linux	~/.local/share/auditaur/apps

Then run:

cargo run -p auditaur-cli -- apps --json
cargo run -p auditaur-cli -- logs --json
cargo run -p auditaur-cli -- errors --json
cargo run -p auditaur-cli -- exceptions --json
cargo run -p auditaur-cli -- exceptions --markdown --output issue.md
cargo run -p auditaur-cli -- ipc --json
cargo run -p auditaur-cli -- events --json
cargo run -p auditaur-cli -- traces --json
cargo run -p auditaur-cli -- windows --json
cargo run -p auditaur-cli -- timeline --json
cargo run -p auditaur-cli -- explain

Or, for runs started with auditaur observe or auditaur start, pass the pinned session file:

cargo run -p auditaur-cli -- traces --session-file .auditaur\session.json --json
cargo run -p auditaur-cli -- logs --session-file .auditaur\session.json --json
cargo run -p auditaur-cli -- errors --session-file .auditaur\session.json --json
cargo run -p auditaur-cli -- exceptions --session-file .auditaur\session.json --json
cargo run -p auditaur-cli -- ipc --session-file .auditaur\session.json --json
cargo run -p auditaur-cli -- events --session-file .auditaur\session.json --json
cargo run -p auditaur-cli -- windows --session-file .auditaur\session.json --json

If multiple dogfood app instances are active, discovery intentionally refuses to guess which database to inspect. Use apps --json, copy the latest databasePath, and pass --db.

If the dogfood app restarts while you are editing Rust or Tauri sources, apps --json annotates stale sessions with supersededBySessionId, secondsUntilNextStart, and churnHint when a newer session for the same app appears. Treat that as session chronology evidence, not proof that Auditaur itself restarted the app.

windows returns the latest stored window rows per window. The plugin captures initial window state at startup and lifecycle rows for later window events. For event rows, attributes.tauri.window.event and related attributes.tauri.window.event.* fields describe the authoritative event payload; top-level fields such as focused, visible, width, and height are best-effort sampled state at capture time.

For MCP, start:

cargo run -p auditaur-cli -- mcp

Point your MCP client at that command and ask it to use get_health, list_traces, list_logs, list_errors, list_ipc_calls, list_events, list_windows, get_trace, get_related_telemetry, or the explain_* tools with the copied databasePath.

Last manual smoke result

The latest local manual smoke used the dogfood app on Windows with an isolated AUDITAUR_DATA_DIR and verified:

• auditaur apps --json discovered one active dogfood session with a readable SQLite database.
• auditaur logs --json returned frontend console logs plus backend tracing logs.
• auditaur errors --json returned the intentional frontend error.
• auditaur exceptions --json grouped captured frontend exceptions and failed IPC calls into issue-ready local reports.
• auditaur ipc --json returned successful_command, failing_command, and emit_backend_event rows.
• auditaur events --json returned frontend emit/receive and backend receive rows.
• auditaur traces --json returned frontend wrapper spans and backend Rust tracing spans.
• auditaur trace <traceId> --json returned trace detail for the failing command span and its IPC row.
• auditaur timeline --json returned a chronological view across spans, logs, errors, IPC calls, events, and window state.
• auditaur explain summarized the intentional failing command path.
• MCP get_health, list_logs, list_errors, list_ipc_calls, list_events, list_traces, get_trace, and related/explain tools returned real dogfood telemetry from the same SQLite DB.
• MCP list_windows returned stored startup and lifecycle window rows when window capture was available.

Exact caveats:

• If multiple dogfood instances are active, discovery refuses to choose a default DB. Pass --db.
• Window lifecycle rows include authoritative event attributes separately from best-effort sampled state fields.