how to contribute debugging

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 and Generation jobs for deeper maps.