Files
Daniele c14cbc3626
Nightly Build / build (push) Successful in 9s
docs: the file viewer, the Tasks page, profiles and user administration
Four gaps off the coverage map, written for the in-app assistant:

- file-viewer.md — what each kind renders to, the live reload, editing a
  Markdown file and the conflict banner, git history mode, and why a `.tex`
  must be shown instead of a PDF built from it.
- tasks-page.md — the four sections, disable-vs-delete, where each kind's
  result lands, and that there is no "new task" button because tasks are
  created in conversation.
- profile.md — display name, language, password, and what an encrypted
  account means when the password is forgotten.
- users.md — creating a member and the irreversible encryption choice, the
  directory profile that feeds the agents' prompt, deactivating vs deleting,
  and the per-person event-triage interval.

Indexed in docs/index.md, cross-linked from files.md, tasks.md and access.md.
2026-08-24 18:20:12 +01:00

60 lines
5.0 KiB
Markdown

# Files
The **Files** page (sidebar → Files) is where a member sees their own space: everything they can reach, in one list. Before it existed, files were reachable only through you — a user could ask "what's in the recipes folder?" but could not go and look. Now they can, and this document exists so you know what they are looking at when they mention it.
## What they see first
The page opens on a list of **places**, not files. This is deliberate: the things a person can reach are not folders inside one another, they are separate roots, and the list is the only level where they all appear together.
| Place | Path | Notes |
| --- | --- | --- |
| Home | `~` | Their own workspace. Always writable. |
| Personal memory | `user-memory/` | Their private notes — the ones you keep for them |
| Shared memory | `shared-memory/` | The group's common notes |
| Shared folders | `shared/{name}` | One entry per folder they are a member of |
| Projects | `projects/{owner}/{name}` | One entry per project they can reach |
| Skills | `skills/` | Installed skill folders. Read-only |
| Documentation | `docs/` | This documentation. Read-only |
A place they have no access to simply is not in the list — there is nothing to explain away.
**The paths shown are the paths you use.** Under each name the page prints the real path (`shared/recipes`, `projects/anna/holiday`), which is the same string you would pass to a file tool. That is worth pointing out to a user who asks how to tell you where to look: they can read the path off the page and say "the file in `shared/recipes/dolci`", and you will find it.
## Inside a place
Clicking a place opens a file explorer: one folder at a time, folders first, with size and dates. From there:
- **Clicking a file opens it** in the usual file viewer — Markdown rendered, images, PDFs, colored code, plain text. What it does with each kind, and where a Markdown file can be edited, is [file-viewer.md](file-viewer.md).
- **Clicking a folder goes into it**; the breadcrumb at the top walks back out, and the browser's back button works too. The address bar carries the folder, so a user can bookmark or paste a link to exactly where they are.
- **The listing is live.** A file you create from a conversation, or another member uploads, appears within a second without a refresh. If a user says "it's not there", ask them to check the folder rather than assuming the write failed — but the page updates on its own, so a truly missing file is missing.
- **ZIP download** — the button in the toolbar downloads the whole open folder as a single archive. Useful when someone wants "all the photos" rather than one file.
## What they can change, and where
Write buttons — new folder, upload (including drag & drop), rename, delete — appear **only where that person may write**. Everywhere else the page shows a **Read-only** badge and no buttons.
Read-only for everyone: **Skills**, **Documentation**, and both memory stores. Read-only for some people: a shared folder or project where they were given read access only.
This matters when a user asks you to do something they just failed to do in the page: if the badge said read-only, you cannot do it either — the same rule applies to your file tools, and asking you is not a way around it. Tell them who to ask (an admin for a shared folder, the owner for a project).
## Memory in the page
The two memory stores appear as ordinary folders, and this is the first place a person can read their notes themselves rather than asking you. Two things to explain if it comes up:
- **They are read-only here.** A user can open and read a note, but cannot edit or delete it from the page. Changing memory goes through you, in conversation — which is what keeps the history in `log.md` honest and, for shared memory, what keeps the confirmation step in place.
- **The folders are not on disk.** Notes live in the database, not as files, so they will not appear if someone goes looking in a terminal. The page shows them as folders because that is the useful way to read them, not because they are files.
## What is not there
- **Places outside their space.** Only what is in the list. A path inside the sandbox but not under any of those roots (`/tmp/…`, for example) is not browsable from the page, though you can still read it with your own tools.
- **Search.** There is no search box yet. Finding something by content is still a question for you — you can search notes and files far better than a folder-by-folder look.
- **The phone app.** The Files page is desktop-only for now.
## Related
- [file-viewer.md](file-viewer.md) — the page a file opens into: what is rendered, what is editable, and the version history
- [shared-folders.md](shared-folders.md) — who may see a shared folder, and read vs write access
- [projects.md](projects.md) — projects have their own explorer on the project page, the same one this page uses
- [memory.md](memory.md) — what goes in each memory store, and why shared memory asks for confirmation
- [skills.md](skills.md) — what the skill folders hold and why they can only be changed by installing