dguiducci
434e27d7c2
Nightly Build / build (push) Successful in 7m14s
Memory is kept as a maintained wiki, and a wiki nobody prunes rots. This adds
the scheduled maintenance pass, and generalises the machinery TIC had grown so
that a background agent is a trait impl rather than a loop of its own.
Two lint agents, not one. The private pass runs per user over `user-memory/`
and reports to them; the shared pass runs once over `shared-memory/`, where the
interesting defect is different — a note failing the table rule, i.e. private
business written where every member can read it. It names the note and the
category without repeating the content, since restating it spreads the very
thing being flagged. Both share `agents/common/memory-lint.md`.
Both are read-only, and that is enforced twice: the prompt says report-never-
repair, and `shared-memory/*` writes are already `@fs_write require`, so an
agent that tried to fix something would raise an approval card from an
unattended pass, which is auto-denied. Read-only is the only design that works
here, not merely the safe one.
One scheduler for cadences three orders of magnitude apart. TIC runs every few
minutes, a lint weekly — the case that tempts a second loop. It stays one
because the wake-up decides nothing: `base_tick` picks only how often to look,
and whether an agent runs for a user is `is_due` against persisted state.
Due-ness moves out of the run log into a new owner table, `system_agent_state`.
The two answer different questions: the run log skips idle ticks so it stays a
history rather than a heartbeat, while scheduling needs every attempt. Reading
due-ness off the log would re-run an idle agent on every tick and never bring a
weekly one due once its last productive run aged out. Persisting it is also
what makes a long interval survive a restart — an in-memory deadline is fine at
TIC's scale, but a weekly agent on a box rebooted every few days would have it
re-armed before it ever fired.
The shared store belongs to nobody, so `AgentScope::Instance` runs that pass as
the first unlocked admin. An ownerless run would write its trace into system.db,
which the runs endpoint shows to nobody by design, and its notify() would have
no recipient; attributing it to a user keeps the whole per-user surface working
unchanged.
Settings move to where the run log is. `ConfigSet` gains `owner`, so placement
is data on the set rather than a page that knows set names; the System agents
page grows one tab per agent holding its description, its settings (admin only)
and its runs — "why did this do nothing last night?" is half a schedule
question and half a log question. The form is shared with the Config page, and
writes still go through PUT /api/config/{key}.
Fixes an authorization gap found on the way: neither /api/config handler took
the caller into account, so any authenticated session could read and write
instance-wide config. The sidebar hiding the page is presentation, not access
control. Both are now admin-gated.
3.7 KiB
3.7 KiB
Documentation index
This folder is written for you, the assistant, not for the human directly. It is mounted read-only at ~/docs/ in your workspace. Read it when a user asks how the software itself works, wants help configuring something, or asks what's possible — then explain it in your own words, adapted to that person (their technical level, their language, their actual goal). Don't just paste these files back at them.
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 memory, projects, system agents and plugins; more sections (agents, connectors, security groups, shared folders…) will be added later.
Features
| Document | What it covers |
|---|---|
| memory.md | Private and shared memory: what goes where, the indexes and history log, why some shared facts can't be changed on request |
| projects.md | Projects: shared folders with their own assistant chat, a live file explorer, and member sharing |
| system-agents.md | Background agents that run on a schedule (TIC, the two memory lints): what they watch, why they only ever report, why a run can be skipped, and their settings |
| settings.md | The admin's Config page: interface language, the compaction model picker, debug mode |
Plugins
Plugins are optional add-ons an admin can enable and configure — extra voices, extra ways to reach the assistant (Telegram, a phone app), image generation, long-term memory, remote access, and so on. Each has its own document in plugins/:
| Document | What it adds |
|---|---|
| plugins/comfyui.md | Local image generation via a self-hosted ComfyUI server |
| plugins/elevenlabs.md | Cloud text-to-speech and transcription (ElevenLabs) |
| plugins/whisper_local.md | Local, private speech-to-text (no cloud, no API key) |
| plugins/kokoro_tts.md | Local, lightweight text-to-speech (CPU-only, no API key) |
| plugins/orpheus_tts_3b.md | Local, expressive text-to-speech with emotion tags (needs a GPU) |
| plugins/honcho.md | Long-term cross-session memory via an external Honcho server (opt-in per user) |
| plugins/telegram.md | Chat with the assistant from Telegram |
| plugins/mobile-connector.md | Companion mobile app: Inbox notifications + remote access, end-to-end encrypted |
| plugins/remote_connectivity.md | Reach the web app remotely over a Tailscale mesh network |
General plugin mechanics that apply to all of them:
- An admin enables/disables and configures each plugin from the Plugins page (sidebar → Plugins, admin-only): one card per plugin, an enable toggle, and a Configure button opening its settings form.
- A plugin only becomes visible to a given user once the admin grants them access — being enabled instance-wide isn't enough by itself (Mobile Connector is the one exception: access there is the device-pairing itself, not a grant list).
- A plugin with per-user settings (e.g. Telegram's pairing code, Honcho's memory opt-in) gives each granted user its own dedicated sidebar page to manage them — separate from the admin's instance-wide config.
- A plugin can add tools the assistant calls directly (e.g.
set_secret,telegram_pairing), a dedicated sidebar page, or both.