Skip to content

Commit 9ae7fe9

Browse files
committed
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 <aylacroft@proton.me>
1 parent cce1ff9 commit 9ae7fe9

3 files changed

Lines changed: 18 additions & 0 deletions

File tree

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

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,6 +21,11 @@ Vision goal 3, first half. A small always-on tier with a budget that consolidate
2121
- `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).
2222
- `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.
2323
- 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).
24+
- **Per-tier token budgets, added 2026-09-20.** The prompt builder holds a token budget per tier, starting at
25+
800 for the stable tier, 300 for the context tier and 200 to 500 for the volatile tier; these are starting
26+
values to be replaced by measurement at G1 and recorded in NOTES.md with the command. Every truncation the
27+
builder performs writes a query receipt naming the tier and the count of tokens dropped, so a silent clip is
28+
impossible and the receipt stream shows where the budget binds. Starting values are configuration, not code.
2429
- Prompt builder ordering: stable (SOUL, tool guidance) → context (skills index placeholder) → volatile (memory snapshot, time, session facts), mirroring the caching-friendly tiering.
2530
- UI: persona editor (SOUL markdown), memory panel (profile / always-on lists with inline edit and delete), consolidation review.
2631
**Out:**

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

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,15 @@ Vision goal 4: "grows safely". A self-improving skills library is only safe if t
2020
**In:**
2121
- `skill_manage` tool with actions and args validated; risk `:write`; always routed through staging regardless of permission rules (design decision: skills are code-adjacent).
2222
- `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/`).
23+
- **The proposer is a Task that only writes to the pending directory, added 2026-09-20.** It produces a diff
24+
and a rationale into `pending/skills/<name>/<change_id>/` and never applies anything; applying is the gated
25+
promotion below. A patch is preferred over a whole-file replace; a replace is tagged `:destructive` in the
26+
`skill_changes` row and the approval card says so. A census asserts the proposer has no write path outside
27+
the pending directory (planted write goes red).
2328
- `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.
29+
The scanner runs on the pending directory, before promotion, never on the live registry alone. Any content a
30+
heuristic excludes from further scanning (binary, oversized, unparseable) is reported as a low-severity finding
31+
naming what was excluded and why; there is no silent drop (added 2026-09-20).
2432
- 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.
2533
- `/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.
2634
- Auto-approve option per persona for low-severity changes (default off).

‎slices/050-scheduler-oban/SLICE.md‎

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -23,6 +23,11 @@ Scheduled work as durable, retried, observable jobs rather than entries in a con
2323
- `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).
2424
- Natural-language schedule helper: `Trinity.Scheduler.Parse.human("every weekday at 9am")` → cron (LLM-assisted with `generate_object`, validated by a cron parser).
2525
- 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.*
26+
- **Memory curator on the `maintenance` queue, added 2026-09-20.** A memory entry untouched for 30 days is
27+
marked stale; one untouched for 90 days is archived; nothing is ever deleted by the curator. Archiving is an
28+
`:artifact` effect that crosses the membrane like any other write and is receipted; the thresholds are
29+
configuration with those defaults. Marking stale is a query receipt. If slice 024 is not yet approved when
30+
this slice runs, the curator marks stale only and archiving waits for the membrane (note in NOTES.md).
2631
- UI: `/tasks` list, create/edit form, run history with links to the sessions.
2732
**Out:**
2833
- Oban Pro; multi-step workflows (modelled later via chained jobs if needed).

0 commit comments

Comments
 (0)