Plan: amendments to slices 030, 041 and 050

slices/030-persona-always-on-memory/SLICE.md

@@ -21,6 +21,11 @@ Vision goal 3, first half. A small always-on tier with a budget that consolidate
 - `Trinity.Memory` context (always-on part): `memories` table (`tier`, `scope`, `key`, `body`); `Trinity.Memory.AlwaysOn.snapshot/1` renders a deterministic block for the prompt (sorted, sized).
 - `memory` tool: `add(tier, key, body)`, `replace(key, body)`, `remove(key)`, `list()`: risk `:write` with a persona-level default rule "allow" (memory writes are low risk but auditable); every change logged.
 - Budget: per persona (default 8 KB total for profile + always_on). When exceeded, `Trinity.Memory.Consolidator` asks the LLM to merge/condense entries into a proposal; the proposal is applied automatically if under budget, else queued for user review (UI list).
+- **Per-tier token budgets, added 2026-09-20.** The prompt builder holds a token budget per tier, starting at
+  800 for the stable tier, 300 for the context tier and 200 to 500 for the volatile tier; these are starting
+  values to be replaced by measurement at G1 and recorded in NOTES.md with the command. Every truncation the
+  builder performs writes a query receipt naming the tier and the count of tokens dropped, so a silent clip is
+  impossible and the receipt stream shows where the budget binds. Starting values are configuration, not code.
 - Prompt builder ordering: stable (SOUL, tool guidance) → context (skills index placeholder) → volatile (memory snapshot, time, session facts), mirroring the caching-friendly tiering.
 - UI: persona editor (SOUL markdown), memory panel (profile / always-on lists with inline edit and delete), consolidation review.
 **Out:**

slices/041-skill-self-management/SLICE.md

@@ -20,7 +20,15 @@ Vision goal 4: "grows safely". A self-improving skills library is only safe if t
 **In:**
 - `skill_manage` tool with actions and args validated; risk `:write`; always routed through staging regardless of permission rules (design decision: skills are code-adjacent).
 - `Trinity.Skills.Staging`: writes proposals to `<data_dir>/pending/skills/<name>/<change_id>/`; `skill_changes` rows; diff generation; apply/reject; versioning (`skills.version++`, previous version archived under `<data_dir>/skills/.history/`).
+- **The proposer is a Task that only writes to the pending directory, added 2026-09-20.** It produces a diff
+  and a rationale into `pending/skills/<name>/<change_id>/` and never applies anything; applying is the gated
+  promotion below. A patch is preferred over a whole-file replace; a replace is tagged `:destructive` in the
+  `skill_changes` row and the approval card says so. A census asserts the proposer has no write path outside
+  the pending directory (planted write goes red).
 - `Trinity.Skills.Scanner`: heuristics (shell commands, network calls, credential patterns, "ignore previous instructions", external URLs, base64 blobs) → findings with severity; high severity blocks auto-approval even if a rule would allow.
+  The scanner runs on the pending directory, before promotion, never on the live registry alone. Any content a
+  heuristic excludes from further scanning (binary, oversized, unparseable) is reported as a low-severity finding
+  naming what was excluded and why; there is no silent drop (added 2026-09-20).
 - Approval UI: pending skill changes list, side-by-side diff, scanner findings, approve/reject with comment; reuses `Trinity.Permissions.Gate` topics so gateways (070) can approve too.
 - `/learn` command (UI + tool `learn(source)`): fetch/parse source (URL via Web.Fetch, local file via FS.Read, pasted text) → LLM distils into a lean SKILL.md + reference files → staged like any other change.
 - Auto-approve option per persona for low-severity changes (default off).

slices/050-scheduler-oban/SLICE.md

@@ -23,6 +23,11 @@ Scheduled work as durable, retried, observable jobs rather than entries in a con
 - `Trinity.Scheduler.Workers.RunTask`: creates/uses a session with `origin: "cron"`, runs one turn with the prompt (+ skill hints), waits for completion via PubSub with timeout, records summary, delivers via `Trinity.Scheduler.Delivery` behaviour (`Desktop` impl now: notification list in UI; gateways add impls in 070).
 - Natural-language schedule helper: `Trinity.Scheduler.Parse.human("every weekday at 9am")` → cron (LLM-assisted with `generate_object`, validated by a cron parser).
 - Memory observer (032) becomes an Oban worker on `memory` queue; retry policy defined. *If 032 is not yet approved when this slice runs, skip this item here and do it in 032 (note in NOTES.md); AC6 is then waived.*
+- **Memory curator on the `maintenance` queue, added 2026-09-20.** A memory entry untouched for 30 days is
+  marked stale; one untouched for 90 days is archived; nothing is ever deleted by the curator. Archiving is an
+  `:artifact` effect that crosses the membrane like any other write and is receipted; the thresholds are
+  configuration with those defaults. Marking stale is a query receipt. If slice 024 is not yet approved when
+  this slice runs, the curator marks stale only and archiving waits for the membrane (note in NOTES.md).
 - UI: `/tasks` list, create/edit form, run history with links to the sessions.
 **Out:**
 - Oban Pro; multi-step workflows (modelled later via chained jobs if needed).