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.

CHANGELOG.md

@@ -10,6 +10,13 @@ release PR may merge — and a section is closed at the commit that bumps it.
 
 ### Added
 
+- The assistant can now explain the **file viewer**, the **Tasks page**, your **Profile**
+  and the admin's **Users** page: ask it what a document's history button does, why a
+  `.tex` is shown instead of a PDF, how to stop a recurring job without losing it, what a
+  "cancelled" run means, what an encrypted account means when a password is forgotten, or
+  why it knows a member's age — and it answers from the in-app documentation instead of
+  guessing.
+
 - A **Files** section in the menu: everywhere you can reach, in one place — your home,
   your personal and the shared memory, the folders and projects shared with you, plus
   skills and documentation. Browse, open, download a folder as a ZIP, and upload, rename

docs/access.md

@@ -37,4 +37,4 @@ The three things being granted are not the same, and the difference matters when
 - **A shared connector grant** (one the admin runs centrally, e.g. web search) puts that connector's tools in that person's assistant.
 - **A per-user connector grant** (e.g. Gmail, WhatsApp) only authorizes the person to *set it up* — they still have to sign in with their own account. Nobody ever uses somebody else's credentials through a grant.
 
-See also: [index.md](index.md) for the plugin list, and each plugin's own page under [`plugins/`](plugins/).
+See also: [index.md](index.md) for the plugin list, each plugin's own page under [`plugins/`](plugins/), and [users.md](users.md) for the rest of a person's page — the account itself, their directory profile and their schedule.

docs/file-viewer.md

@@ -0,0 +1,77 @@
+# The file viewer
+
+One file, open on screen. It is where every file in the app ends up being read: the Files page and a project's explorer open into it, a path in one of your tool cards is clickable and opens it, an approval card for a write opens it — and **you can open it yourself** with `show_file_to_user`, which is the point worth remembering: when a file is the answer, put it on their screen instead of pasting it into the chat.
+
+The header shows the file's path exactly as your tools spell it (`shared/recipes/dolci.md`, `projects/anna/holiday/plan.tex`), so a user reading it back to you is handing you a working path. Next to it: the history button, the download button, and — for HTML — a source/preview toggle.
+
+## What it does with each kind of file
+
+| Kind | What the user sees |
+| --- | --- |
+| Markdown | rendered, with images referenced relatively resolved from the file's own folder; fenced code blocks get a copy button |
+| Code and plain text | the source, syntax-highlighted |
+| Images (PNG, JPG, GIF, WebP, AVIF…) | the picture |
+| SVG | rendered in an isolated frame — scripts inside it never run |
+| PDF | drawn by the app itself, so it looks and scrolls the same in every browser and on the phone |
+| LaTeX (`.tex`) | **compiled to PDF on the server** and shown as the document |
+| HTML | rendered live in an isolated frame; the toggle in the header switches to the source |
+| Anything else | not displayed — the file can still be downloaded |
+
+Two consequences worth knowing:
+
+- **Always give `show_file_to_user` the `.tex`, never a `.pdf` you built from it.** The `.tex` is recompiled and the view follows its dependencies — `\input` fragments, styles, images — so it stays current. A raw `.pdf` is served as bytes: it is never recompiled and the user ends up looking at a stale render.
+- **A compile that fails is not a dead end.** The viewer shows the source instead, with the actual error block foldable at the top. That error is worth reading if they ask why "the document is not showing" — it usually names a line.
+
+## It is live
+
+The viewer watches the open file. When something changes it on disk — you, from the conversation; another member; a task running in the background — the view reloads on its own within about a second, without a refresh and without losing their place.
+
+This is what makes "watch this while I fix it" work: they leave a document open, you rewrite it, and they see the new version. There is no need to tell them to reload, and no need to reopen the file after each edit.
+
+## Editing Markdown
+
+A Markdown file the person may write to shows **View | Edit** tabs. Everything else is read-only, always — code, text, images, and anything under a read-only place.
+
+- **Edit** is a plain source editor, with a dot marking unsaved changes; **View** meanwhile previews what they are typing, not what is on disk.
+- **Save** writes the file. Leaving the file with unsaved changes asks first.
+- **If the file changed underneath them while they were typing** — because you wrote to it, or another member did — the save does not clobber it. A banner offers three ways out: reload the other version (dropping theirs), overwrite with theirs, or copy their text to the clipboard first and then reload. If they ask you which to pick, the safe answer is copy-then-reload: nothing is lost and the two versions can be merged in conversation.
+
+Two things that are **never** editable here, and both are deliberate rather than a limitation to work around:
+
+- **Memory notes** (`user-memory/…`, `shared-memory/…`). They open, they read, they do not save — changing memory goes through you in conversation, which is what keeps the history honest ([memory.md](memory.md)).
+- **A past version** (see below), and files read out of the sandbox that have no counterpart on disk.
+
+## History: reading an earlier version
+
+Files inside a folder that is under version control — in practice, project folders the project coordinator commits into — get a **clock button** in the header. It lists the changes that touched *this* file, newest first, with their date and the message that came with them.
+
+- Picking one shows the file **as it was then**, with a banner saying which version, and a way back to the current one.
+- The whole view comes from that moment, not just the text: a LaTeX file compiles against the images and fragments of that revision, and a Markdown file's pictures are the ones it had then.
+- A past version is read-only, and the live watcher stands down while it is open — working-tree changes will not yank them back to the present.
+- **No clock button means no history**, which is normal: memory notes, files outside any versioned folder, and instances whose host has no `git` simply never offer it. It is not an error and there is nothing to switch on.
+
+## Download
+
+The download button saves the file with its real name. For a `.tex` it downloads the **compiled PDF**, not the source — that is usually what someone asking to "send me the document" wants; if they want the source itself, they want the `.tex`, and it is worth checking which.
+
+## What the viewer tells you
+
+While a file is open, the eye in the chat carries its path and how it is being shown, plus any passage the user highlighted in it — with line numbers when they are looking at source. That is why "what does this mean?" or "rewrite this paragraph" works with no file named: the selection came with the message. Full details, including how to turn it off, in [view-context.md](view-context.md).
+
+If the eye is off, none of that arrives, and you genuinely do not know what they have open — ask, rather than guess.
+
+## Common questions
+
+- *"Can I edit this here?"* — Markdown, in a place they may write to. Everything else is read-only in the page; ask them what to change and do it from the conversation.
+- *"It says the file changed while I was editing."* — something else wrote to it. Three buttons on the banner; copy-then-reload loses nothing.
+- *"The PDF is wrong / old."* — if there is a `.tex` beside it, they are looking at a stale build. Open the `.tex` instead: it recompiles.
+- *"Where is the old version?"* — the clock, if the file is in a project folder. Otherwise there is no history to show, and the honest answer is that this file is not versioned.
+- *"It won't show the file."* — a kind the viewer cannot render (an archive, an office document, an unknown binary) shows the download instead. That is the whole story; there is no plugin to install.
+- *"Show me that file."* — `show_file_to_user`, one file per call, on any path in their own workspace including a memory note. It must already exist.
+
+## Related
+
+- [files.md](files.md) — the Files page: the places a member can reach, and where write access comes from
+- [projects.md](projects.md) — the project explorer, and the versioning that gives the clock button something to list
+- [memory.md](memory.md) — why notes are readable here but only changeable through you
+- [view-context.md](view-context.md) — what the open file and the highlighted passage send with a message

docs/files.md

@@ -24,7 +24,7 @@ A place they have no access to simply is not in the list — there is nothing to
 
 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.
+- **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.
@@ -52,6 +52,7 @@ The two memory stores appear as ordinary folders, and this is the first place a
 
 ## 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

docs/index.md

@@ -4,7 +4,7 @@ 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 the chat window, the inbox, the interface, view context, files, agents, memory, projects, shared folders, background tasks, system agents, access grants, security groups, connectors, skills, the sandbox, voice input and plugins; more sections (the mobile app, the admin's Users and Roles pages, the Tasks page, models and providers…) will be added later.
+This index will grow over time. Right now it covers the chat window, the inbox, the interface, view context, files, the file viewer, agents, memory, projects, shared folders, background tasks, the Tasks page, system agents, access grants, profiles and user administration, security groups, connectors, skills, the sandbox, voice input and plugins; more sections (the mobile app, the Roles page, models and providers…) will be added later.
 
 ## Features
 
@@ -16,12 +16,16 @@ This index will grow over time. Right now it covers the chat window, the inbox,
 | [memory.md](memory.md) | Private and shared memory: what goes where, the indexes and history log, why some shared facts can't be changed on request |
 | [agents.md](agents.md) | Agents: the three kinds (chat, task, system), which one you are talking to and why, the specialist agents the assistant delegates to, how the model is chosen, and adding a custom agent |
 | [files.md](files.md) | The Files page: everywhere a member can reach — home, both memory stores, shared folders, projects, skills and docs — what they can change there, and what is deliberately read-only |
+| [file-viewer.md](file-viewer.md) | The file viewer: what it does with each kind of file (Markdown, code, images, PDF, LaTeX, HTML), the live reload, editing a Markdown file and the conflict banner, and reading an earlier version |
 | [projects.md](projects.md) | Projects: shared folders with their own assistant chat, a live file explorer, and member sharing |
 | [shared-folders.md](shared-folders.md) | Shared folders: admin-managed folders with no chat of their own — who sees them, read vs write access, why the assistant asks before touching them, and when to choose a project instead |
 | [system-agents.md](system-agents.md) | Background agents that run on a schedule (event triage, the two memory lints, the nightly conversation review of a supervised account): what they watch, why they only ever report, why a run can be skipped, and their settings |
 | [tasks.md](tasks.md) | Background tasks: the strip above the message box, following one live, stopping one, answering the approvals and questions they raise, and how every outcome comes back to the conversation |
+| [tasks-page.md](tasks-page.md) | The Tasks page: running, recurring, scheduled and finished tasks — disabling a job rather than deleting it, reading what a past run said, and why there is no "new task" button |
 | [settings.md](settings.md) | The admin's Config page: interface language, the compaction model picker, debug mode |
 | [access.md](access.md) | Who can use which plugin or connector: the open default, removing access per person, and the role switch that keeps children out of it |
+| [profile.md](profile.md) | A member's own Profile page: display name, language, password — and what an "encrypted account" means for them |
+| [users.md](users.md) | The admin's Users page: creating a member and the encryption choice, the directory profile the agents are told about, deactivating vs deleting, per-person event triage |
 | [connectors.md](connectors.md) | Connectors (MCP servers): shared vs per-user, setting one up in the UI, the sign-in and QR-pairing flows, and what to do when one is not working |
 | [sandbox.md](sandbox.md) | Your sandbox: the private Linux container commands run in, which files survive a rebuild, why the command list in your prompt is partial, and installing what is missing |
 | [skills.md](skills.md) | Skills: instruction folders the assistant loads on demand — where they live, how to read and run one, and the contract for writing, installing and downloading one |

docs/profile.md

@@ -0,0 +1,46 @@
+# Your profile (name, language, password)
+
+Every member has a Profile page — the avatar in the top-right corner → **Profile**. It is short on purpose: four things, all of them about that person's own account. Nothing here is admin-only, and nothing here affects anybody else.
+
+## What is on it
+
+**Account** — username and role, both shown but **not editable**. They are the admin's to change, from the Users page. If someone wants a different username or a different role, they are asking the admin, not the page.
+
+**Display name** — the name they want to be called by. This is the one every screen uses, and it is also the name **you** are given in your prompt: change it and you should start using the new one. Leaving it empty falls back to the username.
+
+**Language** — either an explicit choice or "Group default (…)", which follows whatever the admin set for the instance. It applies straight away, no reload, and it is stored on the **account**, so it follows them to any browser and any device. Two things it does:
+
+- it translates the interface, and
+- it is passed to you as their **preferred language** — which is why answering in it is the default, whatever language the last message happened to be in.
+
+**Change password** — a new password, typed twice. Whether the **current** password is asked for depends on the account, and that difference is not cosmetic: see below.
+
+## Passwords, and what "encrypted account" means
+
+At the moment an account is created, the admin chooses whether it is **encrypted**. That single choice explains most of what a user will find surprising later.
+
+**An encrypted account** keeps its database sealed with a key that only their password opens. Its consequences, which are worth saying plainly when asked:
+
+- Changing the password asks for the current one, and the current one must be right — there is no way around it, because it is what opens the seal.
+- The change is instant even on a large history: the data is not re-encrypted, only the seal around the key is replaced. Nothing is lost and nothing has to be re-read.
+- **The admin cannot reset it.** The reset button on the admin's page refuses encrypted accounts outright. If the password is forgotten, the conversation history and private notes are unrecoverable — not "hard to recover": gone. Say this honestly if it comes up; do not offer hope of a recovery path, because there is none.
+- Nothing in their private space can be read while they are logged out, by anyone, the admin included.
+
+**A non-encrypted account** is protected by a password too — logging in still requires it — but the database is not sealed with it. The practical differences: the admin *can* set a new password for them from the Users page, and the account is available to the instance's background work even when nobody is logged in.
+
+**The choice cannot be switched afterwards.** There is no toggle anywhere that turns an existing account from one into the other, in either direction. A user who wants to change it is really asking for a new account, and that is the honest answer.
+
+## What a user might ask
+
+- *"Change my name."* — the Display name field on this page. Ask what they want to be called; you cannot change it for them, and you should start using it once they have.
+- *"Speak Italian to me."* — the Language field settles it for good, across devices. Doing it *only* in conversation lasts as long as the conversation does.
+- *"Change my username."* — not from here. It belongs to the admin's Users page.
+- *"I forgot my password."* — non-encrypted: the admin can set a new one. Encrypted: nobody can, and the data behind it is lost. Which one it is, is the first thing to establish.
+- *"Is my stuff private from the admin?"* — an encrypted account, while they are logged out, genuinely is: nothing normal use of the software offers can open it. That is a real promise about ordinary use, not a mathematical one about somebody who owns the machine and is willing to modify the software running on it. Say it that way — the honest version is what makes it trustworthy.
+- *"What does the app know about me?"* — the display name, the language, and the directory profile the admin filled in (date of birth, sex, notes). The last of those is on the admin's page, not this one, and they are entitled to ask what it says: see [users.md](users.md).
+
+## Related
+
+- [users.md](users.md) — the admin's side: creating an account, the encryption choice, resetting a password, the directory profile the agent is told about
+- [settings.md](settings.md) — the instance-wide default language this page's "Group default" follows
+- [memory.md](memory.md) — what is kept about a person, and where private ends and shared begins

docs/tasks-page.md

@@ -0,0 +1,80 @@
+# The Tasks page (sidebar → Tasks)
+
+[tasks.md](tasks.md) explains the background tasks that appear **inside a conversation** — the strip above the message box. This document is about the **page**: sidebar → Tasks, where every task of that person is listed, including the scheduled ones that belong to no conversation at all.
+
+Two things to know before anything else:
+
+- **It shows only that person's own tasks.** Tasks live in each member's own space; nobody sees anybody else's here, the admin included.
+- **There is no "new task" button.** Tasks are created by *you*, in conversation, with `execute_task`. The page manages what exists — enable, disable, stop, delete, read the outcome — and that is the whole answer to "how do I schedule something?": they ask you, in words, and you create it.
+
+The page is not in the simplified interface. A member on the simple menu has chat, Inbox and Projects only, so for them everything below is something you do on their behalf and report back in words.
+
+## The four sections
+
+The Tasks entry in the sidebar opens a submenu with four sections. They are four views of the same set, cut by *state*, not by kind.
+
+### Running
+
+Anything of theirs running **right now**, whatever kind: a recurring job that happens to be in its run, a one-shot, or a background task started from a chat (badges `cron` / `one-shot` / `async`).
+
+Each card shows the elapsed time, ticking live, which agent is doing the work, and a link to the session — that link is where the work itself can be read, message by message. The **✕** stops the task immediately. Stopping is not failing: the run is recorded as *cancelled* with "Stopped by the user before it finished", and whatever it had produced is kept but incomplete. Say so plainly if asked about it later; never present a stopped task as if it had finished.
+
+### Recurring (cron)
+
+The jobs that run on a schedule, over and over. Each card carries:
+
+- the schedule **in words** ("At 09:00 every day") with the raw cron expression underneath it,
+- the agent that runs it, when it **last** ran and when it will run **next**,
+- a switch to enable/disable, and a bin to delete.
+
+**Disabled is not deleted.** A disabled job keeps its definition and its history, and simply never fires until it is switched back on — that is the right suggestion when someone wants a job to stop "for now", or is unsure whether they still need it.
+
+Times are evaluated in the instance's configured timezone, which is the one named in your own `execute_task` description — worth reading off it rather than assuming the user's, if they are travelling or the box is elsewhere.
+
+### Scheduled
+
+Tasks that are waiting rather than repeating: a **one-shot** job whose moment has not arrived yet (*pending*), and background tasks that are *queued* or running. A recurring job never appears here. The bin deletes.
+
+Once a one-shot has run it drops out of this section: its outcome is in History, and its result has already gone where it was going. About a week after they finish, one-shot and background tasks are cleaned up entirely — the card *and* the History row disappear together. Recurring jobs are never cleaned up, so their runs stay in History indefinitely.
+
+### History
+
+Every finished run, newest first: status, task, agent, when it completed, how long it took. Three statuses, and the difference matters:
+
+| Status | Means |
+| --- | --- |
+| completed | it finished on its own |
+| failed | it broke; the row carries the error |
+| cancelled | somebody stopped it before it finished |
+
+Clicking a row expands it: a link to the session it ran in, the error if there was one, and the **final response** — the last thing the agent said, stored as text. That stored response is the honest answer to "what did last night's job actually say?", and it is worth reading before speculating: the run is over, but its words are still there.
+
+## Where a task's result goes
+
+The page is the *record*, not the delivery. Where an outcome lands depends on the kind:
+
+- **A background (async) task** returns into the conversation that started it — always, whether it succeeded, failed or was stopped. See [tasks.md](tasks.md).
+- **A recurring or one-shot scheduled job** belongs to no conversation, so its outcome arrives as a notification in the **home chat** — you are woken to read it and to tell the user whatever is worth telling. The full text stays in History either way.
+- **A synchronous task** never appears in Running or Scheduled at all: it is over before the page could show it, because the answer came straight back into your reply. Only its History row remains.
+
+## What this page is not
+
+- **Not the background agents' log.** Event triage, the memory lints and the nightly conversation review are not tasks — they have their own page and their own run log ([system-agents.md](system-agents.md)). Nothing about them will ever appear here, and a user hunting for "last night's memory check" should be sent there.
+- **Not an editor.** A job's prompt, agent and schedule cannot be changed in the page. Changing what a job does means deleting it and creating a new one — which is a request to you, not a button.
+- **Not the Inbox.** A task waiting for an approval or an answer is *running*, and looks perfectly healthy here. If someone says a task has been going for hours, check the Inbox ([inbox.md](inbox.md)) before assuming it is stuck: it may simply be waiting for them.
+
+## Common questions
+
+- *"Did last night's job run?"* — Recurring section for the next/last run times, History for what happened.
+- *"Stop this from repeating."* — the switch on its card. Deleting also works but throws the definition away; offer the switch first.
+- *"Why is nothing scheduled?"* — most likely nothing ever created one. There is no default job; the page is empty until somebody asks for something.
+- *"Where did my task from yesterday go?"* — if it was a one-shot or a background task and more than a week has passed, it and its history row were cleaned up. The result itself is still in the conversation (background task) or was delivered as a notification (scheduled).
+- *"Can I see what my daughter has scheduled?"* — no. Each person's tasks are their own; the page shows nobody else's.
+- *"It says cancelled — did it fail?"* — no. Somebody pressed ✕, or the session was stopped. The work is incomplete, not broken.
+
+## Related
+
+- [tasks.md](tasks.md) — background tasks inside a conversation: the strip, stopping one, and how results come back
+- [system-agents.md](system-agents.md) — the scheduled background agents, which are *not* tasks
+- [agents.md](agents.md) — which agents may run a task (a task agent, never a chat one)
+- [inbox.md](inbox.md) — where a running task asks for an approval or an answer

docs/tasks.md

@@ -46,4 +46,4 @@ Common questions and the honest answers:
 - *"It has been going for ages."* — a task has no time limit; stopping it with ■ is always available, and stopping is not the same as failing.
 - *"Where did the result go?"* — into this conversation, always. If it is not there yet, the task has not finished.
 - *"It's stuck."* — check whether it is asking for something: an approval or a question waiting at the top of the strip, or in the Inbox if the card was closed earlier.
-- *"Show me everything that ever ran."* — the **Tasks** page (sidebar → Tasks) has the full history, including scheduled jobs; the strip only covers the current conversation.
+- *"Show me everything that ever ran."* — the **Tasks** page (sidebar → Tasks) has the full history, including scheduled jobs; the strip only covers the current conversation. See [tasks-page.md](tasks-page.md).

docs/users.md

@@ -0,0 +1,79 @@
+# The Users page (admin)
+
+Sidebar → **Users**, admin only. The list is everyone on the instance — username, display name, role, whether their database is encrypted, and whether the account is active. Clicking a row opens **that person's page**, which is where everything about them lives: Profile, Connectors, Plugins, Event triage, Security.
+
+Only one thing is still a dialog: **New user**. Everything else about an existing member is edited on their own page.
+
+[access.md](access.md) already covers the Connectors and Plugins sections — what a grant is and why the default is open. This document is about the rest.
+
+## Creating a member
+
+The dialog asks for a username and a password (both required), optionally a display name, a **role**, the directory profile fields, and one checkbox: **Encrypt conversation history**.
+
+The checkbox is the decision to think about, because it is the only one that cannot be undone:
+
+- **Encrypted** — that person's database is sealed with a key their password opens. Nobody else can read it, the admin included, and the admin cannot reset their password. If the password is lost, the history is gone for good. The dialog says so; repeat it if someone is choosing.
+- **Not encrypted** — a password is still needed to log in, but the admin can set a new one, and the account is available to the instance's background work while nobody is logged in.
+
+There is no way to convert an existing account from one to the other, in either direction. Getting it wrong means creating a new account, so it is worth one question up front: *do you want to be able to help them if they forget their password?*
+
+The new member starts out holding everything the group already uses, unless their role opts out of that — see [access.md](access.md).
+
+## The directory profile, and why it matters to you
+
+Username, display name, role, and three optional fields: **date of birth**, **sex**, **notes**. The page says it plainly under the notes box — *included in the profile shown to agents* — and that is exactly what happens:
+
+- The person's own profile block in your prompt carries their name, date of birth **with the age computed for today**, sex, preferred language and the notes.
+- A table of the other **active** members — name, age, sex, role — is there too, so you know who else is in the group and roughly who they are.
+
+Two consequences worth being careful about:
+
+- **The notes field is not a private admin memo.** Whatever is written there is read by the assistant of that person, every conversation. Useful for "coeliac", "prefers short answers", "works nights". Not the place for anything the person should not read back, because they can simply ask.
+- **A member can ask what their profile says**, and answering honestly is right. It is their own data; there is nothing to protect here.
+
+Dates of birth are validated (`YYYY-MM-DD`, never in the future) and the free-text fields are length-capped, so an age that looks wrong is a wrong birthdate, not a bad calculation.
+
+## Active, inactive, deleted
+
+The **Active** switch and the **Delete** button are not two strengths of the same thing.
+
+**Deactivating** takes effect immediately, not at their next login: open sessions are revoked, running work is stopped, and — for an encrypted account — the key leaves memory, so their database is sealed again. The account, its data and its history all stay. Switching it back on restores everything. This is the right answer for a device that was lost, a member who is away, or an account that is being paused for any reason at all.
+
+**Deleting** erases the user, their database and all their conversation history. It is permanent, it is not a stronger deactivation, and it is confirmed for that reason. Anyone hesitating between the two wants the switch.
+
+**Changing someone's role** applies immediately too, including to sessions they have open — a narrower role cannot be outrun by staying logged in. What the role decides (interface mode, which security groups they may use, whether new plugins reach them automatically) belongs to the Roles page.
+
+## Event triage
+
+One number, and the only schedule on this page: how often the event-triage agent runs **for this person**. Empty means "follow the instance setting", and the field says which value that is; a number overrides it for them alone.
+
+It is per-person because the load is per-person: someone whose connectors deliver a lot of mail or messages triggers triage on nearly every pass, and slowing them down is the fix. What triage actually does is [system-agents.md](system-agents.md).
+
+## Security
+
+Two things at the bottom of the page:
+
+- **Reset password** — sets a new password without knowing the old one. It works **only for non-encrypted accounts**; for an encrypted one the section says so and offers nothing, because there is genuinely nothing to offer: only the current password opens the seal, so only the account holder can change it, from their own [profile.md](profile.md).
+- **Delete** — as above.
+
+## What this page is not
+
+- **Not the Roles page.** What a role *means* is edited under sidebar → Roles; here a role is only picked from a list.
+- **Not a way in.** Nothing here lets an admin read another member's private conversations or notes. The page manages accounts, access and schedules — never content.
+- **Not where a member changes their own things.** Display name, language and password are theirs, on their own Profile page.
+
+## Common questions
+
+- *"Add my son to the assistant."* — New user: username, password, a role, and the encryption decision. Ask about that last one rather than deciding silently.
+- *"Stop them logging in for a while."* — the Active switch. It bites immediately; deleting is not the tool for this.
+- *"They forgot their password."* — non-encrypted: reset it here. Encrypted: nobody can, and their history is unrecoverable.
+- *"Why does the assistant know my daughter's age?"* — because the admin filled in her date of birth in the directory profile, which is shared with the agents by design.
+- *"Take Telegram away from them."* — the Plugins section on their page; see [access.md](access.md).
+- *"Why is it checking their mail every two minutes?"* — the Event triage field, on their page.
+
+## Related
+
+- [profile.md](profile.md) — the same person's own page: name, language, password, and what "encrypted account" means to them
+- [access.md](access.md) — the Connectors and Plugins sections, the open default, and the role switch behind it
+- [system-agents.md](system-agents.md) — what event triage is and what it does with what it finds
+- [security-groups.md](security-groups.md) — what a role's security group permits the assistant to do