v1.2.1

- Generic AI integration (Admin > Integracje > "Integracja AI"), optional and
  off by default: an OpenAI-compatible /chat/completions client (Groq, OpenAI,
  or a self-hosted Ollama instance) configured by base URL, optional API key,
  model, and an SSL-verification toggle. Foundation for the two AI features
  below and anything else that wants an LLM call in the future.
- BookStack automatic content tagging (AI): "Otaguj nową treść"/"Otaguj
  wszystko ponownie" buttons plus `php artisan bookstack:tag-content`
  (--dry-run/--force/--limit=N) tag every book/chapter/page with matching
  helpdesk subcategory names, idempotent by default.
- BookStack search refinement: "Przeszukuj" is now three independent
  checkboxes (Książki/Strony/Rozdziały) instead of a single dropdown, plus a
  new "Szukaj po" setting (nazwa/tagi/oba) — tag matching uses the bare
  subcategory name, matching what auto-tagging writes.
- AI-driven ticket triage + summary (Admin > Integracje > "Automatyzacja AI
  dla zgłoszeń", via new scheduled ai:run-ticket-automation): five toggles
  auto-assign/correct category+subcategory, rewrite an unclear subject, and
  set priority from content, once per ticket in the background; every change
  is logged in the ticket's history. Separately, an AI summary + suggested
  action for every ticket, shown to operators only, with an admin-editable
  prompt.
- Operators can now reassign a ticket to any team, not just one they belong
  to.
- The auto-refresh countdown badges (ticket view, operator queue) are now
  clickable — fetch immediately and reset the countdown.
- All 7 "cyclical" intervals (3 browser refresh countdowns, the notification
  bell poll, and the 4 background scheduled commands) are now configurable
  from Admin > Konfiguracja instead of fixed in code.
- Fixed: an operator viewing a ticket that's deleted or moved outside their
  team scope mid-session is now redirected to the operator queue instead of
  hitting an error.
- Docs: README/ARCHITECTURE/CLAUDE/install/wiki updated for all of the above.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

CLAUDE.md

@@ -63,26 +63,43 @@ with no rebuild or restart:
 ## Scheduled commands need a host crontab entry
 
 The Docker image ships no cron/supervisor of its own (see [install.md](install.md)),
-so `tickets:check-sla-breaches`, `automation:run-rules`, and `emails:fetch-imap`
-(all registered in `routes/console.php` via `Schedule::command(...)`) only ever
-run if something outside the container calls `php artisan schedule:run` on a
-timer. **As of 2026-07-23 this is configured** — root's crontab on the host
-runs, every minute:
+so `tickets:check-sla-breaches`, `automation:run-rules`, `emails:fetch-imap`,
+and `ai:run-ticket-automation` (all registered in `routes/console.php` via
+`Schedule::command(...)`) only ever run if something outside the container
+calls `php artisan schedule:run` on a timer. **As of 2026-07-23 this is
+configured** — root's crontab on the host runs, every minute:
 
 ```cron
 * * * * * cd /mnt/rabbit-containers/servicedesk && docker compose exec -T servicedesk php artisan schedule:run >> /dev/null 2>&1
 ```
 
 (`sudo crontab -l -u root` to inspect/edit — it previously did not exist at all,
-which meant none of the three scheduled commands above had ever run
+which meant none of the four scheduled commands above had ever run
 automatically; ask before changing this again, since removing it silently
-breaks SLA checks, automation rules and IMAP fetching, and confusingly not the
-IMAP feature alone if you're only debugging that one.) IMAP-specific activity
-(connect attempts, per-message accept/reject decisions, created/replied ticket
-ids) is logged separately from the app's normal `LOG_LEVEL` to
-`storage/logs/imap-*.log` (see the `imap` channel in `config/logging.php`) —
-check there first when a mailbox isn't behaving as expected, before assuming
-the scheduler itself isn't firing.
+breaks SLA checks, automation rules, IMAP fetching and AI ticket automation,
+and confusingly not the IMAP feature alone if you're only debugging that one.)
+IMAP-specific activity (connect attempts, per-message accept/reject decisions,
+created/replied ticket ids) is logged separately from the app's normal
+`LOG_LEVEL` to `storage/logs/imap-*.log` (see the `imap` channel in
+`config/logging.php`) — check there first when a mailbox isn't behaving as
+expected, before assuming the scheduler itself isn't firing.
+
+All four commands' intervals are admin-configurable (Admin > Konfiguracja —
+`schedule_sla_check_minutes`/`schedule_automation_rules_minutes`/
+`schedule_imap_fetch_minutes`/`schedule_ai_automation_minutes`), which is why
+`routes/console.php` registers them as `->everyMinute()->when(fn () =>
+Settings::dueEveryMinutes(...))` instead of a plain `->everyFifteenMinutes()`/
+`->cron(...)` call — **never build a cron expression (or otherwise read
+`Settings`) at that file's top level**. `routes/console.php` is `require`'d on
+every artisan boot (`migrate`, `tinker`, `php artisan test`, not just
+`schedule:run` — it's wired in via `bootstrap/app.php`'s `commands:` key), so
+a top-level `Settings::get(...)` call runs before a fresh/test database
+necessarily has the `settings` table, and crashes every single artisan
+invocation, not just the scheduler. A `->when($closure)` guard is the fix —
+the closure is only ever evaluated later, when `schedule:run` processes due
+events. One visible side effect: `php artisan schedule:list` shows
+`* * * * *` for all four regardless of the actual configured interval, since
+that only exists inside the closure — expected, not a bug worth chasing.
 
 ## Apache `/icons/` alias trap