From 9ae7fe9ae06eaedfde81f30fc3fec949975ab953 Mon Sep 17 00:00:00 2001 From: Ayla Croft Date: Sun, 20 Sep 2026 07:27:02 -0400 Subject: [PATCH] plan: amendments to slices 030, 041 and 050 Change 4 of the 2026-09-20 plan. 030: per-tier token budgets in the prompt builder (800 / 300 / 200 to 500 as starting values, replaced by measurement at G1) and a query receipt on every truncation naming the tier and the count dropped. 041: the proposer is a Task that writes only to the pending directory and never applies; patch over replace, replace tagged :destructive; the scanner runs on the pending directory and reports every exclusion as a low-severity finding rather than dropping it; a census pins the proposer's write path. 050: a memory curator on the maintenance queue, stale at 30 days, archived at 90, never deleted, archiving as an :artifact effect through the membrane. plan_check: PASS. Signed-off-by: Ayla Croft --- slices/030-persona-always-on-memory/SLICE.md | 5 +++++ slices/041-skill-self-management/SLICE.md | 8 ++++++++ slices/050-scheduler-oban/SLICE.md | 5 +++++ 3 files changed, 18 insertions(+) diff --git a/slices/030-persona-always-on-memory/SLICE.md b/slices/030-persona-always-on-memory/SLICE.md index e56b067..7ebcc40 100644 --- a/slices/030-persona-always-on-memory/SLICE.md +++ b/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:** diff --git a/slices/041-skill-self-management/SLICE.md b/slices/041-skill-self-management/SLICE.md index d6df591..7ccc3db 100644 --- a/slices/041-skill-self-management/SLICE.md +++ b/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 `/pending/skills///`; `skill_changes` rows; diff generation; apply/reject; versioning (`skills.version++`, previous version archived under `/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///` 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). diff --git a/slices/050-scheduler-oban/SLICE.md b/slices/050-scheduler-oban/SLICE.md index e11e539..7ef92a6 100644 --- a/slices/050-scheduler-oban/SLICE.md +++ b/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).