@aitne-sh/aitne 0.1.9 → 0.1.11

package/agent-assets/docs/features/memory-files/agent-journal.md

@@ -27,7 +27,7 @@ ask_examples:
   - Why did journal/agent.md stop growing?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - journal
   - retros
@@ -38,17 +38,19 @@ related:
   - features/routines/morning-routine
   - features/routines/evening-review
   - features/routines/weekly-review
+  - features/memory-files/agent-lessons
   - features/operations/activity-and-conversations
   - concepts/memory-model
 process_keys:
+  - routine.morning_routine_today
   - routine.morning_routine_journal
   - routine.evening_review
   - routine.weekly_review
 context_files:
   - journal/agent.md
 ui_anchors:
-  - /connections/journal
-  - /settings/journal
+  - /knowledge?tab=context-files
+  - /agents/morning-routine?tab=rulebook
 ---
 
 # journal/agent.md
@@ -68,26 +70,34 @@ of *what happened* — the journal is reflection-shaped: it captures
 
 Each entry carries:
 
-- A timestamp (the routine stamps an `Appended at:` line).
+- A dated heading — the morning routine stamps a
+  `## YYYY-MM-DD morning routine` H2; the weekly and monthly retros add
+  a `> Appended at: YYYY-MM-DD HH:MM` line under their section header.
 - A short context line — which routine or conversation prompted it.
 - The reflection itself.
 
-The file lives at `~/.personal-agent/context/journal/agent.md` and
-grows forever. Later routines read it back to look for patterns.
+The file lives at `~/.personal-agent/context/journal/agent.md`. The
+day-to-day morning and ad-hoc entries accumulate indefinitely; the
+daily retention rollup keeps only a rolling window of the structured
+retros (the most recent 12 `## Weekly` and 24 `## Monthly` sections),
+pruning older ones. Later routines read it back to look for patterns.
 
 ## Who writes it, and when
 
 Three routines append to the journal — none ever rewrites it:
 
-- **Morning routine** (Stage B, `routine.morning_routine_journal`) is
-  the recurring daily writer. After the day's stages settle, the
-  daemon appends a one-paragraph audit-trail entry assembled from the
-  prior day's `agent_actions` — stage results, retry stats, anomalies.
-  This is the entry you'll see most often.
+- **Morning routine** is the recurring daily writer — and here the
+  daemon itself does the writing, not an LLM stage. After the day's
+  stages (Stage A `routine.morning_routine_today`, Stage B
+  `routine.morning_routine_journal`) settle, the daemon appends a
+  one-paragraph audit-trail entry assembled from the run's
+  `agent_actions` rows — stage results, inbox stats, anomalies — plus
+  a one-line footprint of the prior day's actions. This is the entry
+  you'll see most often.
 - **Weekly review** (`routine.weekly_review`) appends the largest
   structured block: a `## Weekly YYYY-Www` retro with *What worked*,
   *What slipped on my side*, *System improvement ideas*, and agent-side
-  metrics. It quotes prior entries to find a thread.
+  metrics.
 - **Evening review** (`routine.evening_review`) appends short
   bookkeeping lines — for example a one-liner each time it bumps a
   roadmap review forward, or a validation error if a roadmap write was
@@ -109,11 +119,15 @@ worth recording during reactive work.
 ### System improvement ideas
 - Add Saturday to the Weekend day-type default so weekend pushes triage.
 ### Metrics (agent side)
-- Agent plan rows completed: 12
-- Did-not-fire / failed rows: 1
-- Observations reviewed / ignored: 18 / 4
+- Routine runs (7d): 142 total / 3 failed (prev week: 150 / 5)
+- Spend (7d): $4.10 (prev week: $4.80); top cost: routine.fetch_window $2.10
+- Notifications (7d): 9 sent / 4 ignored (prev week sent: 11)
 ```
 
+The metrics lines are copied verbatim from the `<self_performance>`
+block the daemon computes and injects into the weekly session — the
+review does not count anything itself.
+
 ## Append-only — enforced, not just convention
 
 The journal is append-only at the API layer, not merely by prompt
@@ -127,10 +141,18 @@ cannot destroy history. Writes go through the daemon context API
 
 ## Where in the dashboard
 
-- **Connections → Journal** (`/connections/journal`) is the read view
-  of the file.
-- **Settings → Journal** (`/settings/journal`) controls retention and
-  which routines contribute.
+- **Knowledge → Context Files** (`/knowledge?tab=context-files`) is the
+  read view of the file — `journal/agent` is listed among the top-level
+  context files. It is flagged as sensitive: entering edit mode surfaces
+  a "deliberately pruning noise" warning before you change anything.
+- **The morning-routine agent's Rulebook tab**
+  (`/agents/morning-routine?tab=rulebook`)
+  does *not* edit this file. It hosts the daily-journal rule files —
+  `policies/journal-format.md` (sections, voice, frontmatter) and
+  `policies/journal-export.md` (redaction / inclusion rules) — both of
+  which the morning routine reads when synthesizing `daily/YYYY-MM-DD.md`,
+  not `journal/agent.md`. `/connections/journal` is a compatibility alias
+  that redirects here.
 
 ## Configuration
 
@@ -142,25 +164,30 @@ agent's own writes, not to you editing the file on disk.
 ## When something goes wrong
 
 - **The journal stops growing.** This usually points at the morning
-  routine's Stage B (the daily writer) or the evening/weekly review not
+  routine (whose daemon-side appender writes the daily entry) or the
+  evening/weekly review not
   running. See [Morning Routine](../routines/morning-routine.md) and
   [Evening Review](../routines/evening-review.md).
 - **Entries look duplicated.** This usually means a routine retried
   after a backend fallback. Because writes are append-only, a retry
-  can re-append rather than overwrite; the weekly review has an
-  idempotency check for its own section, but it is best-effort — a
-  manual prune is fine.
+  re-appends rather than overwrites — the weekly review deliberately
+  appends a fresh section instead of editing in place. The daemon's
+  daily retention rollup (`rollupAgentJournal`) collapses duplicate
+  `## Weekly YYYY-Www` / `## Monthly YYYY-MM` keys last-write-wins
+  within 24 hours, so duplicates self-heal; a manual prune is fine but
+  rarely needed.
 
 ## Related
 
 - [Morning Routine](../routines/morning-routine.md) — the recurring
-  daily writer (Stage B).
-- [Weekly Review](../routines/weekly-review.md) — the largest retro,
-  and the main consumer that reads prior entries back.
+  daily writer (via the daemon-side appender).
+- [Weekly Review](../routines/weekly-review.md) — the largest retro.
 - [Evening Review](../routines/evening-review.md) — appends short
   bookkeeping lines.
 - [Activity & Conversations](../operations/activity-and-conversations.md)
   — the action-shaped audit log, distinct from the reflection-shaped
   journal.
+- [agent lessons](agent-lessons.md) — the directive-shaped learned-behavior
+  stores, distinct from this reflection-shaped diary.
 - [Memory model](../../concepts/memory-model.md) — how the journal fits
   the wider context vault.

package/agent-assets/docs/features/memory-files/agent-lessons.md

@@ -0,0 +1,178 @@
+---
+schema_version: 1
+slug: features/memory-files/agent-lessons
+title: agent lessons
+id: agent-lessons
+aliases:
+  - lessons
+  - agent lessons
+  - feedback learning loop
+  - policies/agent-lessons.md
+category: features
+summary: |
+  The agent's learned-behavior stores — a global policies/agent-lessons.md
+  plus a per-agent policies/agents/<slug>/lessons.md. Your corrections and
+  preferences, the agent's own self-critiques, and your reactions are
+  captured as feedback signals, consolidated nightly into dated lessons,
+  re-generalized monthly, and injected back into the right executions.
+section: memory-files
+tags:
+  - memory
+  - feedback
+  - learning
+  - routines
+status: beta
+ask_examples:
+  - What are the agent lessons?
+  - Where does the agent remember my corrections?
+  - How does the feedback learning loop work?
+  - What is a provisional lesson?
+  - How do I tune the lesson caps?
+locale: en-US
+created: 2026-06-08
+updated: 2026-06-07
+keywords:
+  - lessons
+  - feedback
+  - learning loop
+  - corrections
+  - preferences
+  - self-critique
+  - provisional
+related:
+  - features/routines/evening-review
+  - features/routines/weekly-review
+  - features/memory-files/agent-journal
+  - reference/knowledge-layout
+process_keys:
+  - routine.evening_review
+  - routine.weekly_review
+  - routine.monthly_review
+context_files:
+  - policies/agent-lessons.md
+  - policies/agents/<slug>/lessons.md
+ui_anchors:
+  - /settings/lessons
+---
+
+# agent lessons
+
+## In one sentence
+
+The lesson stores are where the agent remembers how you want it to
+behave: a short, dated list of learned directives that grows from your
+corrections and the agent's own retros, and is fed back into the agent's
+work so it stops repeating the same mistakes.
+
+## What they are
+
+There are two kinds of store:
+
+- **Global agent behavior** — `policies/agent-lessons.md`. Lessons that
+  apply to the agent as a whole. These are injected into your DM
+  conversations and into the routines that decide whether to notify you.
+- **Per-agent** — `policies/agents/<slug>/lessons.md`, one per Agent
+  Definition. These are injected **only** into that agent's own
+  executions, so a lesson learned for your "weekly-report" agent never
+  leaks into an unrelated one.
+
+Both live under `~/.personal-agent/context/policies/`, alongside your
+other rule files, and are plain Markdown you can read or hand-edit.
+
+Each store is a `## Lessons` section of dated bullets. A lesson looks
+like:
+
+```
+- [2026-06-07] Keep the budget section in the weekly report. <!-- ev=2 kind=correction src=explicit conf=high last=2026-06-07 -->
+```
+
+The trailing HTML comment is bookkeeping the daemon manages: how much
+evidence backs the lesson (`ev`), what kind it is (a `correction`, a
+`do-more`/`do-less`, a hard `constraint`, …), how it was sourced, and
+when it was last reinforced. You can ignore the comment when reading —
+the prose before it is the directive.
+
+## How a lesson is born
+
+You never write these files to teach the agent a lesson; the loop does
+it for you. There are three ways signals enter:
+
+- **You correct it or state a preference.** When, in a DM, you correct
+  the agent, tell it how you want something done, or say
+  stop / do-more / do-less, it records that once as a feedback signal.
+  This does **not** change the current reply — your correction already
+  lives in that conversation — but it is remembered for later.
+- **The agent critiques itself.** The [weekly](../routines/weekly-review.md)
+  and monthly reviews post each concrete, actionable improvement idea as
+  a `self_critique` signal.
+- **Your reactions.** Whether you replied to or ignored a proactive
+  message is recorded as a weaker signal.
+
+Those raw signals don't become lessons immediately. Each night the
+[evening review](../routines/evening-review.md) folds the day's
+unconsumed signals into the right store as dated lessons, then marks them
+consumed (it skips the step entirely when nothing pends). Once a month
+the monthly review — off by default; opt in by enabling the
+monthly-review agent at `/agents/monthly-review` — runs a re-generalize
+pass that collapses several same-theme lessons into one higher-level
+principle, keeping each store small.
+
+## Provisional vs. active
+
+A new lesson is stored but is not necessarily *injected* right away. A
+lesson carries a `<!-- provisional -->` marker until it has enough
+corroborating evidence; provisional lessons sit in the file but are not
+fed into the agent's prompts. This avoids over-fitting to a single
+offhand comment.
+
+How a lesson crosses from provisional to active:
+
+- A behavioral or self-critique lesson must reach weighted evidence at or
+  above the **promotion threshold** (`feedbackPromotionThreshold`,
+  default 2). Evidence is weighted by source — an explicit or corrected
+  signal counts 1.0, a reply or self-critique 0.5, an ignore 0.25.
+- An **explicit owner directive** ("always do X", "stop doing Y")
+  promotes on the first occurrence — it is taken at your word.
+- An **ignore on its own never promotes** a lesson, and is never read as
+  disapproval.
+
+## Bounded by design
+
+The stores can't grow without limit. Each is capped in bytes and entry
+count — the global store at `feedbackLessonMaxBytesGlobal` bytes
+(default 8192) / 40 entries, the per-agent stores at
+`feedbackLessonMaxBytesPerAgent` (default 4096) / 20 entries. When a
+store is full, the lowest-signal lessons are dropped first. Lessons that
+go untouched for `feedbackLessonStaleDays` (default 60) are pruned — with
+one exception: a `kind=constraint` lesson is durable and is never
+stale-pruned or collapsed away. The underlying feedback signals
+themselves are retained for `feedbackSignalRetentionDays` (default 180).
+
+## Where in the dashboard
+
+**Settings → Lessons** (`/settings/lessons`, labelled "Lessons" with a
+**Preview** badge) is the read/tune surface. From there you can view and
+edit the lessons themselves and adjust every knob above:
+`feedbackLearningEnabled` (the master kill-switch, on by default),
+`feedbackPromotionThreshold`, the byte caps, the stale-days horizon, and
+the signal retention window. Turning `feedbackLearningEnabled` off stops
+both capture and consolidation.
+
+## Configuration
+
+All of the loop's knobs are listed above and live on the Lessons page;
+there is nothing to configure in the files themselves. Because the stores
+are plain Markdown, **you** can hand-edit, prune, or remove a lesson at
+any time — the loop will pick up from whatever it finds the next night.
+
+## Related
+
+- [Evening Review](../routines/evening-review.md) — folds the day's
+  feedback signals into these stores each night.
+- [Weekly Review](../routines/weekly-review.md) — posts self-critique
+  signals that feed the loop. The optional (off-by-default) monthly
+  review re-generalizes the stores once a month.
+- [agent journal](agent-journal.md) — the reflection-shaped diary, a
+  separate file from these directive stores.
+- [Knowledge layout](../../reference/knowledge-layout.md) — where the
+  `policies/` stores sit in the wider context vault.

package/agent-assets/docs/features/memory-files/projects.md

@@ -25,7 +25,7 @@ ask_examples:
   - How does the agent write to a project file?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - projects
   - project file
@@ -56,8 +56,8 @@ project's lifetime.
 
 - Captures the project's purpose, status, links, and recent decisions
   in a single durable note.
-- Surfaces in the morning routine while the project is active and the
-  roadmap has Preparation Timeline rows pointing at it.
+- Surfaces in the morning routine while the project is active (its
+  `state` is not `archived`).
 - Becomes the canonical reference the agent quotes from in DMs.
 
 ## File Shape
@@ -67,9 +67,11 @@ only the minimum — `type: project`, `owner: shared`, an `updated`
 date, and an H1 title. By convention the agent also writes `slug`,
 `state`, `start`, `due`, `stakeholders`, `next_milestone`, and `tags`.
 
-`state` is what marks a project **active**: the dashboard's project
-view filters on it, and the morning routine only surfaces projects
-whose `state` is active.
+`state` is what marks a project **active**: the Obsidian `_active.base`
+Bases view filters on it (`state != "archived"`), and the morning
+routine surfaces every project whose `state` is not `archived` — a
+file with no `state` (or any state other than `archived`) is treated
+as active and surfaced.
 
 ```markdown
 ---
@@ -97,8 +99,9 @@ Read on demand. Written when the operator asks the agent to remember
 something project-specific, or when a DM expresses project intent
 (create, update status, mark done).
 
-The agent never edits files on disk — it has no `Edit`/`Write` tools.
-All project writes go through the context API:
+The agent cannot edit context files on disk — a pre-write hook blocks
+`Edit`/`Write` anywhere inside the context vault. All project writes go
+through the context API:
 
 - `GET /api/context/list/projects` — discover existing project files.
 - `PUT /api/context/plans/projects/<slug>` — create or fully replace.

package/agent-assets/docs/features/memory-files/roadmap.md

@@ -24,7 +24,7 @@ ask_examples:
   - How do I add a roadmap entry?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - roadmap.md
   - roadmap
@@ -56,9 +56,10 @@ rows that the morning routine fires on the day they come due.
 - Captures long-running goals that span more than a single day, so
   they don't fall out of `state/today.md` (which is replaced fresh
   each morning).
-- Preparation Timeline rows like "T-7 days: book hotel" surface in
-  the morning routine on the day each offset lands — turning a far-off
-  milestone into concrete actions at the right moment.
+- Preparation Timeline rows like "2026-06-13 [notify]: book hotel"
+  surface in the morning routine on the day each row is dated (or once
+  it is overdue) — turning a far-off milestone into concrete actions at
+  the right moment.
 - Cross-links to project files for deeper context.
 
 ## What It Looks Like
@@ -67,25 +68,27 @@ A goal with a Preparation Timeline is just Markdown the agent reads
 each morning. For example:
 
 ```markdown
-## Conference talk — 2026-06-20
+### 2026-06-20: Conference talk
 
 Goal: deliver the keynote in Tokyo.
 
-Preparation Timeline:
-- T-14 days: finalize slide deck
-- T-7 days: book hotel
-- T-2 days: dry run with the team
-- T-0: travel day
+**Preparation Timeline:**
+- 2026-06-06 [today]: finalize slide deck
+- 2026-06-13 [notify]: book hotel
+- 2026-06-18 [today]: dry run with the team
+- 2026-06-20 [today]: travel day
 ```
 
-On 2026-06-06 the morning routine sees the `T-14` offset come due and
-pulls "finalize slide deck" into that day's plan; on 2026-06-13 it
-surfaces "book hotel", and so on.
+Each Preparation Timeline row carries an absolute date and a tag
+(`[notify]`, `[today]`, `[check]`, or `[schedule]`). On 2026-06-06 the
+morning routine sees the `2026-06-06` row come due and pulls "finalize
+slide deck" into that day's plan; on 2026-06-13 it surfaces "book
+hotel", and so on.
 
 ## When It Runs / How It Is Triggered
 
 Read by the morning routine each day, which walks the roadmap and
-surfaces any Preparation Timeline rows whose offset fires that day.
+surfaces any Preparation Timeline rows dated for that day (or overdue).
 The file is updated by the operator, or by the agent on request (for
 example via the roadmap skill or `aitne run-now roadmap_maintenance`).
 

package/agent-assets/docs/features/memory-files/schedule.md

@@ -29,7 +29,7 @@ ask_examples:
   - How do I change which sections the daily journal includes?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-10
 keywords:
   - daily journal
   - diary
@@ -43,6 +43,7 @@ related:
   - concepts/agent-day
 ui_anchors:
   - /schedule
+  - /agents/morning-routine?tab=rulebook
 process_keys:
   - routine.morning_routine_journal
 context_files:
@@ -122,7 +123,8 @@ do not rewrite them.
 The daily journal does **not** appear on the Schedule page — that page
 shows the scheduler's wake-ups and recurring routines, not these files.
 
-- **Journal settings (`/settings/journal`)** is where you shape the
+- **The morning-routine agent's Rulebook tab
+  (`/agents/morning-routine?tab=rulebook`)** is where you shape the
   output: the Format and Export rule files control which sections
   appear, the voice, the required frontmatter, and the redaction /
   inclusion rules applied on every synthesis run. Edits take effect on
@@ -132,7 +134,8 @@ shows the scheduler's wake-ups and recurring routines, not these files.
 
 There is nothing to configure on the files themselves; they are a
 side effect of the morning routine. To change *what* gets written, edit
-the journal Format and Export rules at `/settings/journal`.
+the journal Format and Export rules on the morning-routine agent's
+Rulebook tab (`/agents/morning-routine?tab=rulebook`).
 
 Retention is unlimited — old files accumulate. A manual prune
 (`rm ~/.personal-agent/context/journal/daily/2025-*.md`) is safe.

package/agent-assets/docs/features/memory-files/today.md

@@ -9,7 +9,7 @@ aliases:
 category: features
 summary: |
   today.md is the live plan for the current agent day. The morning
-  routine rebuilds it each day; the hourly check, evening review,
+  routine rebuilds it each day; the activity scan, evening review,
   and the operator all read and append to it during the day.
 section: memory-files
 tags:
@@ -23,7 +23,7 @@ ask_examples:
   - Why does today.md keep getting rewritten?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - today
   - day plan
@@ -31,7 +31,7 @@ keywords:
   - handoff
 related:
   - features/routines/morning-routine
-  - features/routines/hourly-check
+  - features/routines/activity-scan
   - features/routines/evening-review
   - features/memory-files/schedule
   - concepts/agent-day
@@ -59,7 +59,9 @@ today.md holds six sections, written in this order:
 - **User Schedule** — the day's calendar events.
 - **User Tasks** — today's external tasks plus agent-tracked to-dos.
 - **Agent Plan** — what the agent intends to work on today (each row is
-  registered as a schedule entry by the morning routine).
+  registered as a schedule entry by the morning routine; mid-day
+  sessions may add rows for new signals or cancel ones whose premise
+  changed).
 - **Agent Notes** — look-ahead items and date-bound memos folded in from
   inbox triage.
 - **Agent Log** — what actually happened, appended throughout the day.
@@ -69,10 +71,11 @@ today.md holds six sections, written in this order:
 
 - The **morning routine** fully rebuilds today.md (the daemon first
   rotates the previous day's file to `state/yesterday.md`).
-- The **hourly check** routes new observations into the right section
+- The **activity scan** routes new observations into the right section
   and appends short status lines under Agent Log.
 - The **evening review** finalizes the file — it updates Agent Log and
-  the Handoff section before writing the daily journal.
+  the Handoff section. (The daily journal itself is written the next
+  morning, from the rotated file.)
 
 ## How It Is Written
 
@@ -94,6 +97,6 @@ during the morning routine: while the lock is held, a write to
 ## Related
 
 - [Morning routine](../routines/morning-routine.md)
-- [Hourly check](../routines/hourly-check.md)
+- [Activity scan](../routines/activity-scan.md)
 - [Evening review](../routines/evening-review.md)
 - [schedule/ files](schedule.md)

package/agent-assets/docs/features/memory-files/user-profile.md

@@ -13,7 +13,8 @@ category: features
 summary: |
   identity/profile.md is the agent's stable profile of the operator — role,
   focus areas, preferences, names of important people. The agent reads it
-  on every session and appends only with the operator's permission.
+  on every session and silently appends durable facts the operator states
+  in DMs.
 section: memory-files
 tags:
   - memory
@@ -26,7 +27,7 @@ ask_examples:
   - Will the agent change my profile without asking?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - user profile
   - identity/profile.md
@@ -54,8 +55,8 @@ context_files:
 
 ## In One Sentence
 
-A stable, mostly hand-edited profile of you — the agent reads it
-every session and appends only with explicit permission.
+A stable profile of you — the agent reads it every session and
+silently appends durable facts you state in DMs.
 
 ## What It Does
 
@@ -76,9 +77,12 @@ every session and appends only with explicit permission.
 ## When It Runs / How It Is Triggered
 
 - **Read continuously** — loaded at the start of every session.
-- **Written** only when you say "remember that…" in a DM, or during
-  the profile sweep routine (`routine.user_profile_sweep`), which
-  routes captured facts into the appropriate `identity/*.md` slice.
+- **Written** silently, in the same turn, when you state a durable
+  fact about yourself in a DM ("remember that…", "I'm a…", "my
+  manager is…"), and during the profile sweep routine
+  (`routine.user_profile_sweep`), which catches facts the DM-time
+  capture missed and routes them into the appropriate
+  `identity/*.md` slice.
 
 The agent never edits these files directly. It writes through the
 daemon's context API — for example
@@ -101,8 +105,9 @@ To tell the agent a durable fact about yourself, just say it in a DM:
 
 > remember that my manager is Priya and we sync every Monday at 10am
 
-The agent appends a line to the relevant slice (here `identity/people.md`)
-after confirming, and recalls it in future sessions.
+The agent silently appends a line to the relevant slice (here
+`identity/people.md`) in the same turn, and recalls it in future
+sessions.
 
 ## When Something Goes Wrong
 

package/agent-assets/docs/features/messaging/bang-commands.md

@@ -6,6 +6,7 @@ id: bang-commands
 aliases:
   - "!stop"
   - "!start"
+  - "!status"
   - "!cost"
   - "!report"
   - "!help"
@@ -36,7 +37,7 @@ ask_examples:
   - How do I accept a research-cluster offer?
 locale: en-US
 created: 2026-05-12
-updated: 2026-05-28
+updated: 2026-06-07
 keywords:
   - bang command
   - "!stop"
@@ -88,10 +89,21 @@ Pair your messaging app first; see
 | Command | What it does |
 |---|---|
 | `!help` | List every registered command — built-ins plus enabled user commands. |
-| `!stop` | Pause cron-driven autonomous work (hourly check, morning / evening / weekly routines, scheduled tasks). In-flight runs are **not** aborted. |
+| `!stop` | Pause cron-driven autonomous work (activity scan, morning / evening / weekly routines, scheduled tasks). In-flight runs are **not** aborted. |
 | `!start` | Resume autonomous work after `!stop`. |
 | `!close` | Close the active DM session for the current routing tuple so the next DM starts a fresh conversation. |
 
+### Tasks (detached background / browser work)
+
+These inspect and cancel the long-running detached workers (background
+tasks and browser tasks). They run ahead of the agent — even while a DM
+turn or a result-delivery turn is in flight — and are safe while paused.
+
+| Command | What it does |
+|---|---|
+| `!status` | List the active background + browser tasks (kind, short id, state, title). Empty when nothing is running. |
+| `!stop <id>` | Cancel one task by its id (the short id from `!status` is fine; any unambiguous prefix works). **Bare `!stop` (no id) pauses the whole agent** — the lifecycle command above. |
+
 ### Reporting (pure DB reads, safe while paused)
 
 | Command | What it does |
@@ -100,6 +112,7 @@ Pair your messaging app first; see
 | `!cost claude` · `!cost codex` · `!cost gemini` · `!cost opencode` | Spend for a single backend (one row per registered backend). |
 | `!report` | Recent agent failures (last 7 days, top groups, most recent sample). |
 | `!checks` | Today's top browser reload patterns (domain + first path segment). Pure read on `browser_reload_signals`; anchored on the agent-day (`dayBoundaryHour`). Empty state is the common case for a quiet day. |
+| `!revert tuning` | Undo the most recent self-tuning config change (the one announced in a "Self-tuning (R…)" DM). Restores the previous value through the standard config chokepoint and puts the key into a 28-day re-proposal cool-down. Safe while paused. |
 
 ### Research clusters (browser-history)
 
@@ -193,9 +206,10 @@ were hidden.
 
 ## How They Behave
 
-- **Exact match for atomic commands** (`!stop`, `!cost`, `!checks`)
-  and **prefix match for parameterised ones** (`!cost claude`,
-  `!research accept <slug>`, `!compile @work full`). Anything
+- **Exact match for atomic commands** (`!stop`, `!cost`, `!checks` —
+  each `!cost <backend>` variant is its own exact-match entry) and
+  **prefix match for parameterised ones**
+  (`!research accept <slug>`, `!compile @work full`). Anything
   spanning newlines falls through to the agent path so a
   `"!stop\nignore me"` payload cannot spoof a command.
 - **DM only.** Bangs typed into a shared channel are ignored.
@@ -207,7 +221,8 @@ were hidden.
 - **While paused**, any DM (bang or not) replies with the paused
   notice; only commands that opt into `runsWhilePaused` continue to
   run: `!stop`, `!start`, `!close`, `!cost` (and `!cost <backend>`),
-  `!report`, `!help`, `!checks`, `!wiki` (status), and `!wiki help`.
+  `!report`, `!help`, `!checks`, `!revert tuning`, `!wiki` (status),
+  and `!wiki help`.
   Every other command — including **all** `!research` subcommands and
   the LLM-dispatching wiki commands (`!ingest`, `!compile`, `!ask`,
   `!lint`, `!trace`, `!connect`) — replies with a command-aware