4 Commits

Include renames

Author	SHA1	Message	Date
dguiducci	78cdcf4cc7	feat: let one source carry several chats, and open them with a + ... A source had exactly one live conversation, so the copilot could only ever replace a chat, never add one: the trash button reset the source and the old conversation was left orphaned. Working on two things at once meant losing one. The tab bar now holds two kinds of tab. A primary tab is a source — it shows whatever `web` or `project-7` currently points at, which is where background delivery lands (notify, a finished async task, an inbound Telegram message) and what a reset moves to a fresh row. A secondary tab, opened with `+`, is one specific conversation: its source points elsewhere, so it is unreachable by source name and is addressed by id throughout — REST, WebSocket, event filtering. `POST /api/sessions/new` creates one without touching `sources`, which is the whole difference from a reset; its agent and run-context still come from the source, so an extra project tab is the coordinator with the project's context. Project "Open chat" is untouched and still resumes the project's own. The load-bearing half is in ChatHub: the input queue and the model pin are now keyed by session, not by source. Two tabs on one source would otherwise serialize into a single queue and a single turn, and share a `/model` pin — the odd one out, since the security group was already per-session and persisted. The source-taking methods survive as one-line resolvers, so Telegram, mobile and cron are untouched. Because queues now grow with conversations rather than with the handful of sources, a reset retires the queue it replaces instead of leaving a consumer task parked forever. Events are filtered per conversation, so anything a chat must see has to carry a session id: `show_file_to_user`'s OpenFile and the security-group revalidation were emitting untagged and would have reached nobody. A primary connection additionally follows NewSession for its source, so a second window does not keep talking to a conversation another window just reset. Tabs can be renamed by double-click — `chat_sessions.title` existed and was dead until now. An empty name stores NULL, so the box is also the undo.	2026-08-04 22:15:20 +01:00
dguiducci	8f5c5382c8	feat: keep the chat tabs you left open, and keep them with you ... Reopening the app closed every project tab: the copilot's tab bar lived in RAM, so a reload dropped it and each conversation had to be found again from its project board. The set of open tabs is now a column on the session row, `chat_sessions.is_open` (additive, `ensure_column`), restored by `GET /api/sessions/open` and written by `PUT /api/sessions/{id}/open`. Not localStorage: that store is per-origin, so on a shared laptop one member's tabs would greet the next, whereas the owner table sits in their own encrypted file and follows them to another device. Which tab is *selected* stays in sessionStorage — that one is genuinely per window, and a shared value would have two windows fighting over it. `is_open` defaults to 0 and `chat_sessions::create` never sets it: every `/new` leaves its predecessor behind and every system-agent pass mints a row, so the opposite default would restore a bar full of conversations nobody opened. Only the copilot writes the column, at the moment it opens the tab. A reset moves the flag rather than copying it — `POST /api/sessions` now returns the new id and `new_session` carries it, and the old row is closed as the new one opens, or the source would restore twice and a later close would clear the stale row. Closing a tab clears the flag and nothing else: the conversation is kept and comes back with its history when the project is reopened.	2026-08-04 21:50:10 +01:00
dguiducci	046f060fcd	rename the TIC system agent to event triage ... TIC said nothing about what the agent does, and named the wrong thing: the tick belongs to the scheduler, which is generic and lives outside it. The agent's only decision is whether an incoming event deserves an interruption — it sorts, it never acts — so it is now event-triage, matching the functional naming of the two memory lints. - agents/tic/ -> agents/event-triage/, module tic/ -> event_triage/, TicManager -> EventTriageManager, TicConfig -> EventTriageConfig - agent id and chat source: "tic" -> "event-triage" - config keys: tic.* -> event_triage.*, and the config.yml section tic: -> event_triage: (greenfield: previously set values fall back to defaults) - i18n en/it/fr: Event triage / Triage eventi / Tri des evenements; dropped the stale "TIC sessions" mention from the debug-pages description - docs/system-agents.md, docs/index.md, docs/settings.md, CLAUDE.md, SKALD.md	2026-07-28 21:59:37 +01:00
dguiducci	178a38357e	feat(users): UserManager with per-user SQLCipher, and extract skald-core crate ... Two changes developed together in one session; they share the same module structure (db/mod.rs, the core lib root) and only compile together, so they land as one commit. ## UserManager + per-user encryption (§9/§11) New `users::UserManager`: owns the system.db pool plus a map `userid -> SqlitePool` of unlocked databases. The pool *is* the unlock token — its connect options carry the DEK as SQLCipher's raw key, so an open pool means the key is in RAM until restart and dropping it re-locks (§9). Knows nothing about cookies. New `crypto` module: envelope encryption. A random 256-bit DEK encrypts `{userid}.db`; `users.database_password` holds it sealed with AES-256-GCM under `Argon2id(password, salt)`. The AEAD tag is the password verifier — one derivation both authenticates and yields the key, so encrypted users store no second hash. Cleartext users store the Argon2id output directly, compared in constant time. Argon2 runs in spawn_blocking behind a 2-permit semaphore (256 MiB per derivation). - SQLCipher via `libsqlite3-sys` `bundled-sqlcipher-vendored-openssl`, pinned <0.38 so it unifies with the one sqlx-sqlite links (a newer copy would apply the feature to a SQLite sqlx never uses). OpenSSL is vendored and static, so the binary stays self-contained. - Schema split into `create_registry_tables` (instance-wide, no user key) and `create_owner_tables` (one owner's content, identical in every file). No FK in the owner bucket may reach the registry — enforced by a standalone test. Dropped `chat_history.model_db_id` (write-only, and the only registry-crossing key); moved `projects`/`project_tickets` into the owner bucket. - Provisioning invariant: the file is written before the row, deleted after it, so a crash leaves an orphan file, never a user without a database. `open_db` never creates: a missing file is an error, not a silent empty database. Not consumed yet: no login, call sites still use the shared system.db pool. ## Extract crates/skald-core The headless core moves out of `src/` into its own crate; `skald` (server) and the coming `skald-setup` are shells around it. Two dependencies on the shell were inverted rather than dragged along, so the core names neither Tauri nor any concrete plugin: - `Plugin::tools(self: Arc<Self>)` — plugins contribute tools through this hook (sibling of `http_router`), so the core no longer downcasts to `MobileConnectorPlugin`. - `tools::restart::set_restart_handler` — the desktop shell installs its teardown-and-respawn; the core defaults to the supervisor exit code. The core loses its `desktop` feature. - `boot`'s stdout formatter moves to the binary (`src/boot_format.rs`); the core only emits tracing events. All 79 core tests pass; the binary boots and serves in a clean directory, and the mobile-connector tools still register through the new hook.	2026-07-10 16:48:51 +01:00