file viewer, docs, ws: add image/media preview path, projects doc, ws wiring

Show file gains image and video display for capable agents. Docs add
projects.md and update index. Wire ws file-watch in project-board.
Minor fs tool and CLAUDE.md updates.

CLAUDE.md

@@ -89,7 +89,7 @@ Two rules keep the boundary real, and both are enforced by the compiler:
 | `crates/skald-core/src/approval/` | Approval rules engine |
 | `crates/skald-core/src/clarification/` | `ClarificationManager`: background-session question/answer |
 | `crates/skald-core/src/elicitation/` | `ElicitationManager` + bridge: MCP server-initiated input (`elicitation/create`), surfaced in the Inbox; secrets never logged/persisted |
-| `crates/skald-core/src/inbox.rs` | `Inbox`: unified façade for pending approvals + clarifications + elicitations (wraps ApprovalManager, ClarificationManager, ElicitationManager) |
+| `crates/skald-core/src/inbox.rs` | `Inbox`: unified façade for pending approvals + clarifications + elicitations (wraps ApprovalManager, ClarificationManager, ElicitationManager). The managers already emit the `*Requested`/`*Resolved` lifecycle events on the per-user bus; `ws.rs` forwards them to every connected client of that user regardless of `source`, so the web UI updates live (see `sidebar.js` row) |
 | `crates/skald-core/src/llm/` | LLM client abstraction (OpenAI-compat, Anthropic, Ollama…). OpenAI-compatible provider *types* are runtime data, not code: `providers/declared.rs` loads `providers.yaml` at boot (see Config); only non-OpenAI-compatible or bespoke providers (anthropic, ollama, openai, openrouter) stay native. **Retriability** (`llm_call.rs::is_retriable_llm_error`) keys on the real HTTP status via `llm_client::http_status` (a structured `LlmError { status }` from the client, else a `reqwest::Error` in the chain), **not** a substring of the message — a model id/token count containing "404"/"401" no longer mis-classifies; 401/403/404/422 don't retry, 400/429/5xx/network do |
 | `crates/skald-core/src/transcribe/` | Transcription providers |
 | `crates/skald-core/src/image_generate/` | Image generation providers |
@@ -105,14 +105,14 @@ Two rules keep the boundary real, and both are enforced by the compiler:
 
 The schema is split into two buckets (§5.1), and the split is the point:
 
-- **`create_registry_tables`** — instance-wide, readable without any user key: `users`, `roles`, `llm_providers`, `llm_models`, `transcribe_models`, `tts_models`, `image_generate_models`, `plugins`, `plugin_access` + `plugin_user_configs`, `approval_rules`, `tool_permission_groups`, `config`, `known_tools`, `llm_requests`, `mcp_catalog`, `mcp_global_servers` + `mcp_global_access`, `oauth_providers`, `role_capabilities`, `shared_folders` + `shared_folder_members`. The MCP tables back the Connectors model (§7/§14/§15 — see its own section); `oauth_providers` (accessor `db/oauth_providers.rs`) holds one row per identity provider (Google…) — endpoints + `client_id`/`client_secret` + `redirect_uri`, admin-owned household secrets (§4/§15b), never a per-user token. The last two (accessor `db/shared_folders.rs`) are the **membership** of the on-disk shared folders (§6): a junction table so a member can be read-only (`can_write`) and so the container mount topology + the `shared/{X}` fs routing both query it. FK `shared_folder_members.user_id → users(id)` is registry→registry (same file), which is allowed — unlike an owner→registry key.
-- **`create_owner_tables`** — one owner's content, **identical schema in every file that has it**: `chat_sessions`, `chat_sessions_stack`, `chat_history`, `chat_llm_tools`, `chat_summaries`, `session_scratchpad`, `session_mcp_grants`, `stack_mcp_grants`, `scheduled_jobs`, `job_runs`, `mcp_user_servers`, `mcp_events`, `sources`, `secrets`, `projects`, `project_tickets`, `llm_request_payloads`, `memory_docs` (+ FTS5 `memory_docs_fts`). `mcp_user_servers` (a user's activated per-user connectors) carries `catalog_name` as a **bare `TEXT` snapshot** of `mcp_catalog.name`, never a FK — an owner→registry key would fail every INSERT; for an OAuth connector it also snapshots `oauth_provider` + `deliver_json`, and its `api_key` column holds the refresh token (in the SQLCipher-encrypted file, so no column crypto). Because `memory_docs` is an owner table, one definition backs **private** memory in each `{userid}.db` and **shared** memory in `system.db` (the household owner) — see the memory namespace note below.
+- **`create_registry_tables`** — instance-wide, readable without any user key: `users`, `roles`, `llm_providers`, `llm_models`, `transcribe_models`, `tts_models`, `image_generate_models`, `plugins`, `plugin_access` + `plugin_user_configs`, `approval_rules`, `tool_permission_groups`, `config`, `known_tools`, `llm_requests`, `mcp_catalog`, `mcp_global_servers` + `mcp_global_access`, `oauth_providers`, `role_capabilities`, `shared_folders` + `shared_folder_members`, `projects` + `project_members`. The MCP tables back the Connectors model (§7/§14/§15 — see its own section); `oauth_providers` (accessor `db/oauth_providers.rs`) holds one row per identity provider (Google…) — endpoints + `client_id`/`client_secret` + `redirect_uri`, admin-owned household secrets (§4/§15b), never a per-user token. The last two pairs are junction-backed membership: `shared_folder_members` (accessor `db/shared_folders.rs`) for the on-disk shared folders (§6), `project_members` (accessor `db/project_members.rs`) for projects (see the Projects section) — both let a member be read-only (`can_write`) and both drive the container mount topology + the fs routing. Their FKs are registry→registry (same file), which is allowed — unlike an owner→registry key.
+- **`create_owner_tables`** — one owner's content, **identical schema in every file that has it**: `chat_sessions`, `chat_sessions_stack`, `chat_history`, `chat_llm_tools`, `chat_summaries`, `session_scratchpad`, `session_mcp_grants`, `stack_mcp_grants`, `scheduled_jobs`, `job_runs`, `mcp_user_servers`, `mcp_events`, `sources`, `secrets`, `llm_request_payloads`, `memory_docs` (+ FTS5 `memory_docs_fts`). `mcp_user_servers` (a user's activated per-user connectors) carries `catalog_name` as a **bare `TEXT` snapshot** of `mcp_catalog.name`, never a FK — an owner→registry key would fail every INSERT; for an OAuth connector it also snapshots `oauth_provider` + `deliver_json`, and its `api_key` column holds the refresh token (in the SQLCipher-encrypted file, so no column crypto). Because `memory_docs` is an owner table, one definition backs **private** memory in each `{userid}.db` and **shared** memory in `system.db` (the household owner) — see the memory namespace note below. (`projects`/`project_tickets` were owner tables in the single-user past: projects are shareable now, so `projects` + `project_members` are registry tables and `project_tickets` is gone.)
 
 Schema is greenfield (no migrations, §0), but a purely **additive** column lands on an existing DB in place: `db::ensure_column` runs `ALTER TABLE … ADD COLUMN` and swallows the "duplicate column" error, a no-op on a fresh DB where the `CREATE TABLE` already has the column. Used for the OAuth columns on `mcp_catalog` / `mcp_user_servers` so a dev box need not be wiped for an additive change (a full recreate is still valid).
 
-**No foreign key in the owner bucket may point at a registry table.** SQLite cannot enforce a key across files, not even through `ATTACH`, and sqlx turns on `PRAGMA foreign_keys`: the `CREATE TABLE` succeeds and every `INSERT` fails. `db::tests::owner_tables_stand_alone_with_foreign_keys_on` enforces this by running the owner schema against a database holding nothing else, then inserting a row into each table. Two keys crossed and were fixed: `chat_history.model_db_id` (dropped — write-only, and `llm_requests.model_name` already records the model) and `project_tickets.job_id` (fixed by moving `projects`/`project_tickets` into the owner bucket).
+**No foreign key in the owner bucket may point at a registry table.** SQLite cannot enforce a key across files, not even through `ATTACH`, and sqlx turns on `PRAGMA foreign_keys`: the `CREATE TABLE` succeeds and every `INSERT` fails. `db::tests::owner_tables_stand_alone_with_foreign_keys_on` enforces this by running the owner schema against a database holding nothing else, then inserting a row into each table. One key crossed and was fixed: `chat_history.model_db_id` (dropped — write-only, and `llm_requests.model_name` already records the model).
 
-**Memory namespace (blueprint §5).** `memory_docs` (accessor `db/memory_docs.rs` — `get`/`upsert`/`list`/`search`(FTS)/`delete`) backs a virtual note store surfaced through the fs-tools, **not** the disk. Two sibling roots (not the blueprint's nested `memory/{userid}` + `memory/shared`): `user-memory/…` routes to the caller's own pool (`ToolContext::pool`), `shared-memory/…` to the system pool (a singleton captured in `fs::register_all`). `tools/fs/classify_memory()` decides on the raw first path component (a `..` in the tail clamps inside the store, never escapes to disk); `read_file`/`write_file`/`list_files`/`edit_file`/`insert_at_line`/`replace_lines`/`search_file` override `run_with` to route memory paths (each extracting a pure transform shared with its on-disk `execute`) and leave every other path on disk. Approval (seeded in `seed_fs_path_rules`): `user-memory/*` is `@fs_any allow` (private, frictionless); `shared-memory/*` is `@fs_read allow` + `@fs_write require` — reads free, **writes need approval** so the agent can't silently push one person's data into shared memory. `grep_files` stays disk-only (regex-across-tree ≠ FTS); ranked full-text recall over notes is a separate tool, `memory_search` (`tools/fs/memory_search.rs`), over the `memory_docs` FTS index — allowed by a path-less rule (it takes `query`, not `path`).
+**Memory namespace (blueprint §5).** `memory_docs` (accessor `db/memory_docs.rs` — `get`/`upsert`/`list`/`search`(FTS)/`delete`) backs a virtual note store surfaced through the fs-tools, **not** the disk. Two sibling roots (not the blueprint's nested `memory/{userid}` + `memory/shared`): `user-memory/…` routes to the caller's own pool (`ToolContext::pool`), `shared-memory/…` to the system pool (a singleton captured in `fs::register_all`). `tools/fs/classify_memory()` decides on the raw first path component (a `..` in the tail clamps inside the store, never escapes to disk); `read_file`/`write_file`/`list_files`/`edit_file`/`insert_at_line`/`replace_lines`/`search_file` override `run_with` to route memory paths (each extracting a pure transform shared with its on-disk `execute`) and leave every other path on disk. The HTTP surface routes them the same way: `GET /api/file` classifies **before** `resolve_view_path` and serves the note from `memory_docs` (caller's pool / system pool), so the file viewer opens `user-memory/…` and `shared-memory/…` like any file, and `show_file_to_user` accepts memory paths too (existence-checked on the right pool). Approval (seeded in `seed_fs_path_rules`): `user-memory/*` is `@fs_any allow` (private, frictionless); `shared-memory/*` is `@fs_read allow` + `@fs_write require` — reads free, **writes need approval** so the agent can't silently push one person's data into shared memory. `grep_files` stays disk-only (regex-across-tree ≠ FTS); ranked full-text recall over notes is a separate tool, `memory_search` (`tools/fs/memory_search.rs`), over the `memory_docs` FTS index — allowed by a path-less rule (it takes `query`, not `path`).
 
 **Memory injection into the prompt**: `MessageBuilder::load_inject_memory` routes each `meta.inject_memory` entry — `user-memory/…` → owner pool, `shared-memory/…` → the shared (`system.db`) pool, both via `memory_docs::get`; anything else (`data/…`, `$WD/…`) is a disk read. The shared pool is threaded `ChatSessionManager` → handler → `MessageBuilder`. `assistant` and `project-coordinator` inject `user-memory/index.md` + `shared-memory/index.md`.
 
@@ -133,6 +133,7 @@ The agent sees **one namespace**, routed on the first path component. The choke
 | `user-memory/…` | SQLite `ctx.pool` (`{userid}.db`) | `classify_memory` → `memory_docs` |
 | `shared-memory/…` | SQLite `system.db` | `classify_memory` → `memory_docs` |
 | `shared/{X}/…` | host `{WD}/shared/{X}` (if a member) | `UserFs::host_base_and_tail` |
+| `projects/{O}/{S}/…` | host `{WD}/projects/{owner_userid}/{S}` (if a member) | `UserFs::host_base_and_tail` |
 | `~/…`, relative | host `{WD}/homes/{userid}` | `UserFs::host_base_and_tail` |
 
 Two views, **one storage**: the fs-tools run **host-side** in the Skald process on `{WD}/homes/{userid}` + `{WD}/shared/{X}`; `execute_cmd` runs **inside the container** (`docker exec -w <container-path> skald-{userid} sh -c …`, via `ExecuteCmd::run_with`) on the same paths bind-mounted (`homes/{userid}`→`/root`, `shared/{X}`→`/root/shared/{X}`, read-only when `can_write=0`). A file written in the container appears to the host fs-tools and vice versa.
@@ -141,6 +142,16 @@ Two views, **one storage**: the fs-tools run **host-side** in the Skald process
 
 The threading: `UserContext.fs` (built by `container::build_user_fs` at login, snapshotting shared memberships) → `ChatSessionManager` → `ChatSessionHandler.fs` → `ToolContext.fs`. **Admin CRUD is wired** (`src/frontend/api/shared_folders.rs` — `GET/POST /api/shared-folders`, `PATCH/DELETE /api/shared-folders/{id}`, `POST`/`DELETE .../members[/{user_id}]`; UI `shared-folders.js`): a create/describe/delete + per-member `can_write` surface, and each mutation calls a best-effort `remount(user)` that rebuilds the affected user's fs + container mounts **in place** — so a membership change lands without a re-login (blueprint §6's "admin CRUD" + "membership refresh without re-login" TODOs, now closed; it still settles at next login/boot if the live remount fails). `execute_cmd` /stop is robust: the command runs under `setsid -w` in its own process-group (leader pid recorded in a container pidfile), and a `KillReaper` drop-guard reaps that group on /stop **or** timeout via a detached `docker exec` that walks `/proc` and kills members by **positive pid** (the container's dash mishandles `kill -<pgid>`); the pidfile is passed positionally (`$1`), and the container's `--init` (tini) reaps the killed processes so no zombies accumulate. **Per-user MCP connectors now run inside this container** (§7) — the container infra enabled it; see the MCP connectors section.
 
+## Projects
+
+A **project** is a shareable, self-service workspace: a folder at `{WD}/projects/{owner_userid}/{slug}` plus membership in the registry. `projects` (accessor `db/projects.rs` — slug is immutable, `UNIQUE(owner_user_id, slug)`) + `project_members` (junction with `can_write`; the owner is always a write-member, so a private project = one member). Sharing is **not** admin-gated: the owner and any write-member can add/remove/re-grant members and edit metadata; only the owner can delete. Each membership mutation remounts the affected users' containers in place (`Skald::refresh_user_mounts`). The mount appears in the agent namespace as `projects/{owner_username}/{slug}` (host keys on the stable userid, agent path on the username) — read-only members get a read-only bind mount in the container.
+
+**API** (`src/frontend/api/projects.rs`): `GET/POST /api/projects`, `GET/PUT/DELETE /api/projects/{id}`, `POST /api/projects/{id}/members`, `DELETE .../members/{user_id}`, `POST /api/projects/{id}/session`. `ProjectDetail` carries `root_path` — the agent path of the folder, computed server-side (owner username ≠ `owner_name`, which may be a display name) — the explorer's root. A `project-{id}` chat source provisions the `project-coordinator` agent with a project `RunContext` (`provisioning_for_source` → `skald_core::projects::build_project_run_context`: `project_root` + a system block with name/description/folder/members); every member keeps their **own private** `project-{id}` session — only the folder is shared.
+
+**UI** (`web/components/projects/`): `index.js` (`<projects-page>` host — hash-routed: `#projects`, `#projects/{id}`, `#projects/{id}/sharing`, back/forward-aware), `project-list.js` (card grid + create/edit/delete modal), `project-board.js` (`<project-board-section>` — the detail page: header with **Open chat**, then a **Files / Sharing** tab bar using the `.project-tab-bar` styles in `css/projects/board.css`), `project-files.js` (`<project-files-panel>` — the explorer). The mobile app has its own read-only `shared/projects-page.js` (list → open project chat).
+
+**The explorer** (`project-files.js`): one directory at a time via `GET /api/files/dir?path=…` (new endpoint in `src/frontend/api/files.rs`: immediate children with `name/path/is_dir/size/created_at/modified_at`, dirs-first; same `resolve_view_path` scoping as `/api/file`). Breadcrumb rooted at the project (`/` = `root_path`); file click → `window.openFile` (existing viewer); folder click → navigate. **Live**: it subscribes the open directory on the existing `/api/file/watch` socket (`web/lib/file-watcher.js` singleton — `notify` NonRecursive on a dir reports its direct children) and reloads debounced 300 ms, so files created by other members or by the agent in-container appear without a refresh. Write actions (new folder, upload incl. drag&drop, rename, delete) are shown only to `can_write` members and ride the existing `/api/file` endpoints — `POST` gained `dir:true` (mkdir), `DELETE` handles directories (`remove_dir_all`), and binary upload is the new `POST /api/file/upload?path=…` (raw body, 256 MiB `DefaultBodyLimit`). **Server-side write gate**: all `/api/file` write handlers now call `UserFs::can_write_to(agent_path)` (core-api) — home → true, `shared/`/`projects/` → the membership's `can_write`, `docs/` → false — closing the host-side bypass of the read-only bind mount (the container mount only gates in-container writes).
+
 ## MCP connectors (blueprint §7/§14/§15)
 
 MCP servers are surfaced to users as **"Connectors"** (UI naming; `mcp`/schema stays neutral, §0.1). The old single owner table `mcp_servers`, the agent-facing `register_mcp`/`delete_mcp` tools, and the `mcp` kinds of `list_items`/`toggle_item` are **gone**. Connectors are now admin-curated and user-activated through the Connectors UI/API — never written by the agent, which closes the §14 RCE vector (prompt-injection → agent writes+registers a local script → arbitrary code on the box).
@@ -257,7 +268,7 @@ Create `agents/<id>/meta.json` and `agents/<id>/AGENT.md`. The agent is discover
 
 ## Documentation
 
-`docs/` is **not developer documentation** — it's written for the in-app LLM, not for a human reading the repo, and is mounted read-only into every user's container at `~/docs/` (see the Filesystem & containers section: `docs_host` on `UserFs`, `DOCS_DIR` in `container/mod.rs`). It explains the software's UX (plugins, and eventually agents/connectors/memory/roles/…) in plain terms, in English, so the assistant can help a non-technical user configure things instead of guessing. `docs/index.md` is the entry point; `docs/plugins/<plugin id>.md` covers each built-in plugin. The three `type: chat` agents (`assistant`, `kid`, `project-coordinator`) are told in their `AGENT.md` to read `docs/index.md` when a user asks how the software works. Keep it in sync when plugins or major UX-facing behavior change — it goes stale like any other doc.
+`docs/` is **not developer documentation** — it's written for the in-app LLM, not for a human reading the repo, and is mounted read-only into every user's container at `~/docs/` (see the Filesystem & containers section: `docs_host` on `UserFs`, `DOCS_DIR` in `container/mod.rs`). It explains the software's UX (plugins, and eventually agents/connectors/memory/roles/…) in plain terms, in English, so the assistant can help a non-technical user configure things instead of guessing. `docs/index.md` is the entry point (general index of feature pages); `docs/plugins/<plugin id>.md` covers each built-in plugin. The three `type: chat` agents (`assistant`, `kid`, `project-coordinator`) are told in their `AGENT.md` to read `docs/index.md` when a user asks how the software works. **Standing rule: every change that impacts the UX must update `docs/` in the same change** — a new/renamed feature page plus the `docs/index.md` index entry. It goes stale like any other doc, except users actually see this one.
 
 ## Config
 
@@ -294,7 +305,7 @@ All extend `LightElement` from `web/lib/base.js` (Lit). `ChatSession` (`web/lib/
 | `copilot.js` | `<app-copilot>` | The chat surface (`_wsSource='web'`): full/dock roving layout, welcome hero empty state, privacy chip, composer with model pill, slash-command autocomplete |
 | `shared/chat-page.js` | `<chat-page>` | Mobile chat (`_wsSource='mobile'`) |
 | `copilot-render.js` | (helpers) | `renderMsg`, `renderTool`, `renderDiff`, etc. — shared by copilot and chat-page |
-| `sidebar.js` | `<app-sidebar>` | Nav sidebar; role-driven (`ui_mode`); polls `/api/inbox` every 10 s for badge |
+| `sidebar.js` | `<app-sidebar>` | Nav sidebar; role-driven (`ui_mode`); inbox badge is **live** — the chat WS forwards the inbox lifecycle events (`approval_requested/resolved`, `clarification_*`, `elicitation_*`) regardless of `source`, `chat-session.js` re-dispatches them as the `inbox-changed` window event, and the sidebar (+ `agent-inbox.js`) refreshes on it; a 60 s poll remains as fallback |
 | `topbar.js` | `<app-topbar>` | Top nav bar; per-user avatar color hashed from the username |
 | `dashboard-page.js` | `<dashboard-page>` | `#dashboard` — status hero, LLM stats charts, pending inbox, quick guide |
 | `shared/file-viewer-base.js` | `FileViewerBase` (base) | Shared file-viewer engine (fetch, kind detection, markdown/PDF/SVG/LaTeX, watcher, `_renderBody`); driven by `_show`/`_hide`. Extended by desktop + mobile |
@@ -310,6 +321,7 @@ All extend `LightElement` from `web/lib/base.js` (Lit). `ChatSession` (`web/lib/
 | `plugin-detail.js` | `<plugin-detail>` | `#plugin-detail?id=<id>` — one plugin's admin page: instance-config form (`config_schema`) + per-user access checklist (plugin twin of `connector-detail.js`) |
 | `plugin-page-host.js` | `<plugin-page-host>` | Host for plugin-contributed pages (`#plugin/<plugin_id>/<page_id>`): dynamic-imports the fragment module, registers its element, mounts it with `plugin-id` |
 | `shared-folders.js` | `<shared-folders-page>` | `#shared-folders` — admin-only CRUD for on-disk shared folders (§6): create/describe/delete + per-member read-only/read-write grants; description feeds the assistant's `__SHARED_FOLDERS__` context |
+| `projects/` | `<projects-page>` | `#projects` — host + list + board; the board is tabbed (**Files** explorer with live watcher + write actions, **Sharing** members), deep-linked `#projects/{id}[/sharing]`. See the Projects section |
 | `connector-detail.js` | `<connector-detail-page>` | A connector's own page (`#connector?name=X`): env/secret form + Test, the **OAuth login panel** (sign in → paste code → complete, §15), global enable + per-user access grants |
 | `shared/connector-common.js` | (helpers) | Shared Connectors vocabulary: `statusOf` (incl. `needs_login` for a pending OAuth row), `STATUS_LABEL`, schema normalization, `jf` fetch |
 | `llm-providers.js` | `<llm-providers-page>` | LLM provider management |

crates/skald-core/src/tools/fs/mod.rs

@@ -52,7 +52,7 @@ pub const USER_MEMORY_ROOT: &str = "user-memory";
 pub const SHARED_MEMORY_ROOT: &str = "shared-memory";
 
 /// Which memory store a path resolves to.
-pub(crate) enum MemScope {
+pub enum MemScope {
     /// `user-memory/…` → the caller's own pool (`ToolContext::pool`).
     User,
     /// `shared-memory/…` → the shared system pool.
@@ -61,7 +61,7 @@ pub(crate) enum MemScope {
 
 /// A path that falls inside the virtual memory namespace: the store it belongs to
 /// and the note key **relative to that store's root** (the root prefix stripped).
-pub(crate) struct MemRef {
+pub struct MemRef {
     pub scope: MemScope,
     pub rel:   String,
 }
@@ -75,7 +75,7 @@ pub(crate) struct MemRef {
 /// disk path. The tail is then normalized (resolving `.`/`..`) and clamped at the
 /// store root, so a memory path stays within its store and an absolute path is
 /// always disk.
-pub(crate) fn classify_memory(user_path: &str) -> Option<MemRef> {
+pub fn classify_memory(user_path: &str) -> Option<MemRef> {
     let mut parts = user_path.trim_start_matches("./").splitn(2, ['/', '\\']);
     let scope = match parts.next()? {
         USER_MEMORY_ROOT   => MemScope::User,

crates/skald-core/src/tools/show_file.rs

@@ -1,17 +1,20 @@
 use std::sync::Arc;
 
 use serde_json::{Value, json};
+use sqlx::SqlitePool;
 
 use core_api::user_fs::SharedFs;
 
 use crate::chat_hub::ChatHub;
+use crate::db::memory_docs;
 use crate::events::{GlobalEvent, ServerEvent};
 use crate::session::handler::{InterfaceTool, ToolFuture};
 use crate::tools::fs;
 use crate::tools::tool_names::SHOW_FILE_TO_USER;
 
-/// Build a `show_file_to_user` InterfaceTool bound to a `ChatHub`, a source and the
-/// caller's [`SharedFs`] (their per-user filesystem view).
+/// Build a `show_file_to_user` InterfaceTool bound to a `ChatHub`, a source, the
+/// caller's [`SharedFs`] (their per-user filesystem view) and the two memory
+/// pools (the caller's own + the shared system one).
 ///
 /// Injected only for SPA clients (web copilot + mobile) at the WebSocket entry
 /// point, so Telegram — which has its own `send_attachment` — never sees it.
@@ -19,11 +22,20 @@ use crate::tools::tool_names::SHOW_FILE_TO_USER;
 /// The path is resolved through the caller's own workspace (`resolve_view_path`):
 /// `~/…`, `shared/{X}/…`, `projects/{O}/{S}/…`, a bare relative path, or a
 /// container-absolute `/root/…` — anything outside the container view is refused.
+/// A path under a memory root (`user-memory/…`, `shared-memory/…`) is a virtual
+/// note instead: it is looked up in `memory_docs` on the matching pool — the
+/// viewer's `GET /api/file` applies the same routing, so it round-trips.
 /// It then emits a `ServerEvent::OpenFile` carrying the **canonical agent path**, so
-/// the file-viewer page fetches the same file back through `/api/file` (which applies
-/// the identical per-user resolution). The frontend renders every kind in the viewer
-/// (HTML live in an origin-isolated iframe; LaTeX compiled to PDF server-side).
-pub fn make_tool(hub: Arc<ChatHub>, source: String, fs: SharedFs) -> InterfaceTool {
+/// the file-viewer page fetches the same file back through `/api/file`. The
+/// frontend renders every kind in the viewer (HTML live in an origin-isolated
+/// iframe; LaTeX compiled to PDF server-side).
+pub fn make_tool(
+    hub: Arc<ChatHub>,
+    source: String,
+    fs: SharedFs,
+    user_pool: SqlitePool,
+    shared_pool: SqlitePool,
+) -> InterfaceTool {
     let definition = json!({
         "type": "function",
         "function": {
@@ -34,7 +46,8 @@ pub fn make_tool(hub: Arc<ChatHub>, source: String, fs: SharedFs) -> InterfaceTo
                              to PDF automatically on the server). HTML files open in a \
                              new browser tab. Use this to surface a file you created or \
                              found so the user can look at it directly. One file per call. \
-                             The file must already exist on disk. \
+                             The file must already exist on disk — or as a memory note \
+                             (`user-memory/…`, `shared-memory/…`). \
                              IMPORTANT for LaTeX: always pass the `.tex` source, never a \
                              pre-built `.pdf` of a document you have the `.tex` for. The \
                              `.tex` is compiled on the server and the view live-reloads \
@@ -49,8 +62,9 @@ pub fn make_tool(hub: Arc<ChatHub>, source: String, fs: SharedFs) -> InterfaceTo
                         "type": "string",
                         "description": "Path of the file to show, in your own workspace: relative to your \
                                          home (e.g. `report.md` or `~/report.md`), a `shared/<folder>/…` or \
-                                         `projects/<owner>/<slug>/…` path, or an absolute container path \
-                                         (`/root/…`). Paths outside your workspace are refused."
+                                         `projects/<owner>/<slug>/…` path, a memory note \
+                                         (`user-memory/…`, `shared-memory/…`), or an absolute container \
+                                         path (`/root/…`). Paths outside your workspace are refused."
                     }
                 },
                 "required": ["path"]
@@ -59,14 +73,42 @@ pub fn make_tool(hub: Arc<ChatHub>, source: String, fs: SharedFs) -> InterfaceTo
     });
 
     let handler = Arc::new(move |args: Value| -> ToolFuture {
-        let hub    = Arc::clone(&hub);
-        let source = source.clone();
-        let fs     = fs.clone();
+        let hub         = Arc::clone(&hub);
+        let source      = source.clone();
+        let fs          = fs.clone();
+        let user_pool   = user_pool.clone();
+        let shared_pool = shared_pool.clone();
         Box::pin(async move {
             let path = args["path"]
                 .as_str()
                 .ok_or_else(|| anyhow::anyhow!("show_file_to_user: missing required parameter 'path'"))?;
 
+            // Virtual memory namespace → a `memory_docs` note, not a disk file.
+            // The viewer serves it through the same routing (see GET /api/file),
+            // so confirming existence is all that's needed here.
+            if let Some(mem) = fs::classify_memory(path) {
+                if mem.rel.is_empty() {
+                    anyhow::bail!("show_file_to_user: '{path}' is a memory folder, not a file");
+                }
+                let (pool, root) = match mem.scope {
+                    fs::MemScope::User   => (&user_pool, fs::USER_MEMORY_ROOT),
+                    fs::MemScope::Shared => (&shared_pool, fs::SHARED_MEMORY_ROOT),
+                };
+                let exists = memory_docs::get(pool, &mem.rel).await
+                    .map_err(|e| anyhow::anyhow!("show_file_to_user: {e}"))?
+                    .is_some();
+                if !exists {
+                    anyhow::bail!("show_file_to_user: file not found: {path}");
+                }
+                let display = format!("{root}/{}", mem.rel);
+                hub.emit(GlobalEvent {
+                    source:     Some(source),
+                    session_id: None,
+                    event:      ServerEvent::OpenFile { path: display.clone() },
+                });
+                return Ok(format!("Opened {display} in the user's viewer."));
+            }
+
             // Resolve against the caller's workspace snapshot: gives the host path to
             // stat and the canonical agent path the viewer will fetch back.
             let user_fs = fs.load();

docs/index.md

@@ -4,7 +4,13 @@ This folder is written for **you, the assistant**, not for the human directly. I
 
 Keep answers grounded in what's actually enabled and configured for this instance — check with the relevant tool (e.g. list installed/enabled plugins) rather than assuming everything described here is turned on. A feature documented here may not be enabled on this particular instance.
 
-This index will grow over time. Right now it covers plugins; more sections (agents, connectors, memory, security groups, shared folders, projects…) will be added later.
+This index will grow over time. Right now it covers projects and plugins; more sections (agents, connectors, memory, security groups, shared folders…) will be added later.
+
+## Features
+
+| Document | What it covers |
+| --- | --- |
+| [projects.md](projects.md) | Projects: shared folders with their own assistant chat, a live file explorer, and member sharing |
 
 ## Plugins
 

docs/projects.md

@@ -0,0 +1,54 @@
+# Projects
+
+A **project** is a shared workspace: a folder on the server plus its own chat with the assistant. Members of the group can work on the same files — directly, or by asking the assistant in the project chat — without giving anyone access to their private home folder.
+
+Examples: a household budget, a holiday plan, a shared recipe collection, a small work document base.
+
+## Creating a project
+
+1. Open **Projects** in the sidebar.
+2. Click **New Project**, give it a name and an optional description, save.
+
+You become the project's owner. Only you can delete the project; everything else (editing the description, sharing) can also be done by members you grant read & write access.
+
+## The project page
+
+Opening a project shows its page, with two tabs (the current tab is part of the address, so you can bookmark or share the link):
+
+- **Files** — the project's file explorer (see below).
+- **Sharing** — who can access the project.
+
+The header also has an **Open chat** button: it opens the project's conversation with the assistant. The assistant already knows the project folder and works directly inside it — creating documents, searching, summarizing. Each member has their **own private** conversation about the project; only the files are shared.
+
+## The Files tab
+
+A file explorer rooted at the project folder:
+
+- The **breadcrumb** on top shows where you are, relative to the project root (`/`, then `/folder`, `/folder/subfolder`). Click any segment to jump back.
+- Files and folders are listed as a table: icon, name, creation date, last-modified date, size.
+- Click a **file** to open it in the file viewer (Markdown rendered, images, PDFs, text…).
+- Click a **folder** to navigate into it.
+- The listing **updates by itself**: if another member or the assistant creates, renames or deletes a file while you're looking at a folder, the change appears within a second — no refresh needed.
+
+If you have write access you can also, from the toolbar or each row:
+
+- **New folder** — create a subfolder in the current location.
+- **Upload** — send files from your device into the current folder (or just drag & drop them onto the list).
+- **Rename** and **Delete** — from the icons on each row. Deleting a folder removes everything inside it, after a confirmation.
+
+Read-only members see the same explorer and can open every file, but the write actions are hidden (and refused by the server anyway).
+
+## The Sharing tab
+
+Lists every member with their access level. The owner and any read & write member can:
+
+- **Add a member** — pick a person and their access: *Read* (browse and open files only) or *Read & write* (can also create, edit, delete and share).
+- **Change access** or **remove** a member (the owner can't be removed).
+
+Access changes apply immediately — no need for the other person to log out.
+
+## Notes
+
+- A private project is simply a project with one member (you). Share it later whenever you want.
+- Renaming a project does not move its folder, so links and the assistant's context keep working.
+- Deleting a project removes its folder for everyone — there is no undo.

src/frontend/api/files.rs

@@ -11,6 +11,7 @@ use serde::{Deserialize, Serialize};
 
 use std::sync::Arc;
 use core_api::user_fs::UserFs;
+use skald_core::db::memory_docs;
 use skald_core::skald::Skald;
 use skald_core::latex::CompileError;
 use skald_core::tools::fs as fs_tools;
@@ -141,6 +142,12 @@ pub struct FileQuery {
 /// `application/pdf`. Compilation failures yield `422 Unprocessable Entity`
 /// with the textual `latexmk` log in the body, so the caller can fall back to
 /// showing the raw source.
+///
+/// A path under a virtual memory root (`user-memory/…`, `shared-memory/…`) is
+/// served from the `memory_docs` table — the caller's own pool for the private
+/// root, the system pool for the shared one — exactly like the fs-tools route
+/// them (see [`fs_tools::classify_memory`]). Raw content only: no LaTeX
+/// compilation (notes are not on disk).
 pub async fn get_file(
     State(state):    State<Arc<Skald>>,
     Extension(auth): Extension<AuthUser>,
@@ -150,6 +157,30 @@ pub async fn get_file(
         Ok(c)  => c,
         Err(e) => return e.into_response(),
     };
+
+    // Virtual memory namespace → SQLite, not disk.
+    if let Some(mem) = fs_tools::classify_memory(&q.path) {
+        let pool = match mem.scope {
+            fs_tools::MemScope::User   => Arc::clone(&ctx.pool),
+            fs_tools::MemScope::Shared => state.db().clone(),
+        };
+        return match memory_docs::get(&pool, &mem.rel).await {
+            Ok(Some(doc)) => {
+                let mut response = doc.content.into_response();
+                response.headers_mut().insert(
+                    header::CONTENT_TYPE,
+                    HeaderValue::from_static(content_type_for(&q.path)),
+                );
+                if q.force_download {
+                    set_attachment(&mut response, &basename(&q.path));
+                }
+                response
+            }
+            Ok(None)  => (StatusCode::NOT_FOUND, format!("File not found: {}", q.path)).into_response(),
+            Err(e)    => (StatusCode::INTERNAL_SERVER_ERROR, e.to_string()).into_response(),
+        };
+    }
+
     let user_fs = ctx.fs.load();
     let abs = match fs_tools::resolve_view_path(user_fs.as_ref(), &q.path) {
         Ok((abs, _)) => abs,

src/frontend/api/ws.rs

@@ -412,6 +412,8 @@ async fn handle_socket(mut socket: WebSocket, skald: Arc<Skald>, source: String,
                             Arc::clone(&chat_hub),
                             source.clone(),
                             ctx.fs.clone(),
+                            ctx.pool.as_ref().clone(),
+                            skald.db().as_ref().clone(),
                         ),
                     ],
                     ..Default::default()

web/components/projects/project-board.js

@@ -222,17 +222,16 @@ export class ProjectBoardSection extends LightElement {
 
   _renderTabs() {
     const tab = (id, icon, label) => html`
-      <li class="nav-item">
-        <button class="nav-link ${this._tab === id ? 'active' : ''}" @click=${() => this._selectTab(id)}>
-          <i class="bi ${icon} me-1"></i>${label}
-        </button>
-      </li>
+      <button class="project-tab ${this._tab === id ? 'project-tab--active' : ''}"
+        @click=${() => this._selectTab(id)}>
+        <i class="bi ${icon}"></i>${label}
+      </button>
     `;
     return html`
-      <ul class="nav nav-tabs px-3">
+      <div class="project-tab-bar">
         ${tab('files', 'bi-folder2-open', t('projects.tabs.files'))}
         ${tab('sharing', 'bi-people', t('projects.tabs.sharing'))}
-      </ul>
+      </div>
     `;
   }