chore: prepare v0.9.3 release

backlog/tasks/task-236 - Gate-Jimaku-and-SubSync-modal-actions-when-setup-is-missing.md

@@ -0,0 +1,29 @@
+---
+id: TASK-236
+title: Gate Jimaku and SubSync modal actions when setup is missing
+status: To Do
+assignee: []
+created_date: '2026-03-26 05:48'
+labels:
+  - ui
+  - setup-validation
+dependencies: []
+---
+
+## Description
+
+<!-- SECTION:DESCRIPTION:BEGIN -->
+Add safeguards in the Jimaku and SubSync modals so users cannot proceed with unsupported flows when required setup is missing. SubSync should clearly block use when alass/ffsubsync detection fails. Jimaku should surface a visible warning when no API key is configured and prevent proceeding with actions that require it.
+<!-- SECTION:DESCRIPTION:END -->
+
+## Acceptance Criteria
+<!-- AC:BEGIN -->
+- [ ] #1 SubSync modal detects availability of alass and ffsubsync before enabling related action option
+- [ ] #2 When only one of alass/ffsubsync is available, only the available path is selectable and clearly labeled; unavailable options are visually disabled
+- [ ] #3 When neither alass nor ffsubsync are available, the unsupported action option is disabled and/or hidden, and cannot navigate to next step
+- [ ] #4 If a user tries to proceed while detection says unavailable, submission is blocked with explanatory inline feedback
+- [ ] #5 Jimaku modal detects missing API key (or invalid/missing key) and shows an immediate warning on search results or related UI area
+- [ ] #6 When Jimaku API key is absent, actions that require key-based operations are disabled or blocked and cannot be submitted
+- [ ] #7 All new/updated UX states include clear copy explaining what to fix (e.g., install binary, add API key, restart if needed)
+- [ ] #8 Add or update tests for setup detection and blocked-state behavior in relevant modal/components
+<!-- AC:END -->

backlog/tasks/task-237 - Improve-config-validation-error-reporting-and-logging.md

@@ -0,0 +1,34 @@
+---
+id: TASK-237
+title: Improve config validation error reporting and logging
+status: To Do
+assignee: []
+created_date: '2026-03-26 05:51'
+labels:
+  - errors
+  - config
+  - validation
+  - ux
+dependencies: []
+references:
+  - /docs/README.md
+  - /docs/workflow/verification.md
+---
+
+## Description
+
+<!-- SECTION:DESCRIPTION:BEGIN -->
+Replace raw error body system notifications during config validation with clearer, user-friendly summaries while retaining full technical detail in logs. The flow should surface what is wrong, where, and how to fix it without overloading the user with raw stack traces, and write structured details to console/file logs.
+<!-- SECTION:DESCRIPTION:END -->
+
+## Acceptance Criteria
+<!-- AC:BEGIN -->
+- [ ] #1 When config validation fails, show a user-facing notification with cleaned, human-readable summary instead of dumping raw error text directly
+- [ ] #2 Notification content includes actionable context (what field/setting failed, expected format/type, and next steps where possible)
+- [ ] #3 Raw technical error details are preserved in console logs in a consistently formatted, presentable way
+- [ ] #4 Config validation failures also write to persistent log file output in the same presentable format
+- [ ] #5 When validation fails repeatedly or with multiple errors, aggregate and group errors for easier reading instead of showing one opaque blob
+- [ ] #6 Warning/error notification should map to the specific invalid config section so users can jump to/identify what to fix
+- [ ] #7 Add/update tests (unit/integration) that assert notification formatting and logging behavior for at least one malformed config case
+- [ ] #8 No sensitive data (API keys/secrets) is written to logs/notifications when sanitizing errors
+<!-- AC:END -->