# Debugging

Debugging usually starts by identifying the layer: renderer state, Tauri command bridge, core storage/service logic, managed files, or provider process execution.

## Renderer and state

`frontend/src/app/useAppController.ts` centralizes boot, active Session state, autosave, busy state, provider status, generation jobs, and notices. If a view shows stale data, inspect the action factory for that workflow: `frontend/src/app/sessionActions.ts`, `frontend/src/app/recordActions.ts`, `frontend/src/app/generationActions.ts`, `frontend/src/app/attachmentActions.ts`, or `frontend/src/app/copyActions.ts`.

## Tauri commands

Command errors are normalized in `src-tauri/src/commands/error.rs`. A validation or not-found error should normally originate in `crates/qa-scribe-core/src/services/session_service`, while an internal error may come from storage, file IO, provider execution, or response parsing.

## Storage and files

SQLite schema and migration logic live in `crates/qa-scribe-core/src/storage/mod.rs`. Attachment import, preview, hash checking, path sanitization, and reconciliation live in `crates/qa-scribe-core/src/attachments/mod.rs`.

## Provider jobs

Provider debugging starts in `src-tauri/src/commands/ai/job_runner.rs` and `src-tauri/src/jobs.rs`. Process execution details live in `src-tauri/src/commands/ai/streaming_exec.rs`, with executable resolution in `src-tauri/src/provider_command.rs` and provider readiness under `src-tauri/src/commands/providers`.

See [Provider detection](systems--provider-detection.md) and [Generation jobs](systems--generation-jobs.md) for deeper maps.