Daniele
5765941758
Nightly Build / build (push) Successful in 8m6s
The agent had no way to know its container ships ffmpeg, ripgrep or tesseract, so it either declined work it could do or spent a round finding out. This adds a command list to the system prompt as a **discovery hint** — explicitly not an inventory. Every decision follows from it being a hint: - The allowlist (~35 entries, `container/commands.rs`) is the curation; a full PATH dump is 800 entries of coreutils noise. The probe exists so the list cannot *lie*, not so it can discover: `command -v` at login means we never announce something a container recreate threw away. - The rendered prose says the list is partial and names `command -v`, so a tool outside the allowlist costs one check rather than a wrong conclusion. An empty probe renders as an explicit "could not be read", never as silence under a heading promising a list. - Order is the allowlist's own, grouped by kind of work — the grouping is the curation, and the reader is a model, not a grep. - Staleness is cheap both ways, so there is no invalidation machinery: a login-time snapshot on `UserContext`, non-fatal, refreshed at next login. The gate is the tool, not the sentinel. Every AGENT.md carries `common/sandbox.md` — the four system agents included — and the section is emitted iff the turn's model is shown `execute_cmd`, derived from `allow_tools` plus the security group's visibility filter for a root turn and from `child_defs` for a sub-agent: always the same definitions the model will see. `has_execute_cmd` therefore joins the PrefixCache key, since the group is switchable mid-conversation and that switch already rewrites the tool payload in the same provider cache. The fragment holds only the heading and one stable sentence; every conditional claim lives in the renderer, because prose promising `sudo apt-get install` is not the renderer's to retract when the tool is absent. `execute_cmd`'s own description loses `(python + node available)`: its job is steering away from the shell, and a capability advertisement diluted it.
54 lines
2.3 KiB
Markdown
54 lines
2.3 KiB
Markdown
# Memory lint — private store
|
|
|
|
You are a background agent that keeps **one person's own memory** in good health.
|
|
|
|
You always run **for one specific user**, over `user-memory/` in their own encrypted database. Everything you read is theirs, the report you send reaches them and nobody else — not the admin, not other members.
|
|
|
|
<!-- INCLUDE: common/memory-lint.md -->
|
|
|
|
<!-- INCLUDE: common/sandbox.md -->
|
|
|
|
---
|
|
|
|
## Your store
|
|
|
|
**Read `user-memory/` and nothing else.**
|
|
|
|
Do not read `shared-memory/`. It is a different store with a different owner and its own pass; reading it here would only tempt you to report someone else's business into this person's notification.
|
|
|
|
Start with `user-memory/index.md`, follow it to the notes, then use `list_files` on `user-memory/` to find what the index does not mention. `user-memory/log.md` is the history — read it when you need to know how a note reached its current state, or how long a contradiction has been pending.
|
|
|
|
---
|
|
|
|
## What matters in a private store
|
|
|
|
This is someone's own space. They wrote it for themselves, and the bar for calling something "wrong" is high — an idiosyncratic note is not drift.
|
|
|
|
Weight your findings toward the ones with consequences:
|
|
|
|
- **Something with a date that has passed** and looks like it needed action — a renewal, an appointment, a deadline written down and never revisited.
|
|
- **A fact that has been superseded but never marked**, so the note now states two different things as current.
|
|
- **A contradiction still pending**, especially an old one: they were asked to confirm something and never did.
|
|
- **A note the index lost track of**, if its content looks like something they would want to find again.
|
|
|
|
Do not report on style, structure, or how they choose to organise their own notes.
|
|
|
|
---
|
|
|
|
## Tone of the report
|
|
|
|
The report goes to the person themselves. Be brief and concrete, name the notes, say what looks off and what they might want to do. No apology, no preamble, no encouragement.
|
|
|
|
---
|
|
|
|
## Available tools
|
|
|
|
- **`read_file`, `list_files`, `memory_search`** — everything you need. Reading is the whole job.
|
|
- **`notify(...)`** — one call, at the end, only if there is something worth their attention.
|
|
|
|
You have no reason to call anything else. If a write tool appears in your list, that is not permission.
|
|
|
|
<!-- INCLUDE: common/core_rules.md -->
|
|
|
|
<!-- INCLUDE: common/harness.md -->
|