@aitne-sh/aitne 0.1.12 → 0.1.13

package/agent-assets/docs/pages/settings.md

@@ -0,0 +1,77 @@
+---
+schema_version: 1
+slug: pages/settings
+title: "Settings Page"
+id: page-settings
+aliases:
+  - settings page
+  - settings hub
+  - preferences page
+category: pages
+summary: |
+  The Settings page is the configuration hub. The landing tab covers the
+  agent's identity and management mode; a sidebar groups the rest —
+  Profile, Intelligence, Operations, Browser, and System.
+tags:
+  - config
+status: stable
+ask_examples:
+  - What can I do on the Settings page?
+  - Where do I change the agent's name or character?
+  - Where do I set quiet hours?
+  - Where do I change which model handles a tier?
+locale: en-US
+created: 2026-07-01
+updated: 2026-07-01
+keywords:
+  - settings
+  - configuration
+  - models
+  - hours
+  - safety
+related:
+  - concepts/agent-day
+  - concepts/backends-and-tiers
+  - features/operations/quiet-hours
+  - concepts/safety-and-execution
+ui_anchors:
+  - /settings
+---
+
+# Settings Page
+
+The `/settings` landing (**Agent**) covers the basics — the agent's display
+name, its character, management mode, and vault health. A sidebar groups
+everything else.
+
+## What you can do here
+
+- **Profile** — **Agent** (name, character, management mode) and
+  **Hours & Notifications** (quiet hours, notification policy).
+- **Intelligence** — **Models** (which model serves each tier — the
+  agent's speed/cost levels),
+  **Self-learning** (skill-overlay review), **Lessons** (the feedback
+  learning store), and **Wiki** (workspace configuration).
+- **Operations** — **Management** (the agent's primary vault + management
+  mode) and **Commands** (settings for bang-commands — the `!`-prefixed
+  shortcuts you type in chat).
+- **Browser** — **Browser History** and **Browser Automation** settings
+  (mirrored on the [Browser page](../pages/browser.md)).
+- **System** — **Safety** (tool policy), **Infrastructure** (config keys,
+  paths), and **Danger Zone** (reset and reinstall).
+
+## Where to go deeper
+
+- [The agent's day](../concepts/agent-day.md) — hours and routines.
+- [Backends & tiers](../concepts/backends-and-tiers.md) — what the Models
+  page controls.
+- [Quiet hours](../features/operations/quiet-hours.md) — when the agent
+  stays silent.
+- [Safety & execution](../concepts/safety-and-execution.md) — what the
+  Safety page governs.
+- [Config reference](../reference/config.md) — every editable key.
+
+## Related
+
+- [Agents page](agents.md) — per-agent schedules and rulebooks.
+- [Connections page](connections.md) — link outside services.

package/agent-assets/docs/pages/tasks.md

@@ -0,0 +1,74 @@
+---
+schema_version: 1
+slug: pages/tasks
+title: "Tasks Page"
+id: page-tasks
+aliases:
+  - tasks page
+  - task board
+  - queue page
+  - schedule page
+category: pages
+summary: |
+  The Tasks page is the operations hub — everything the agent has in
+  motion. A standing Board of work items, a run Queue (upcoming and
+  history), and your recurring Scheduled DMs, all in your timezone.
+tags:
+  - agents
+  - scheduler
+status: stable
+ask_examples:
+  - What can I do on the Tasks page?
+  - Where do I see what the agent is about to run?
+  - How do I set up a recurring DM reminder?
+  - Where did the Schedule page go?
+locale: en-US
+created: 2026-07-01
+updated: 2026-07-01
+keywords:
+  - tasks
+  - queue
+  - schedule
+  - scheduled dms
+  - board
+related:
+  - pages/agents
+  - features/memory-files/schedule
+  - features/operations/schedule-approaching
+  - concepts/routines
+ui_anchors:
+  - /tasks
+---
+
+# Tasks Page
+
+The `/tasks` page is where the standing work, the run queue, and your
+scheduled DMs all live. (The old **Schedule** page merged in here — its
+queue and DM rules are now the Queue and Scheduled DMs tabs.)
+
+## What you can do here
+
+- **Board tab** — the read-only Unified Task Board: a live inventory of
+  everything in motion (agents, triggers, runs, background workers), each
+  clickable for detail.
+- **Queue tab** — the concrete runs your schedules produce. **Upcoming**
+  lists what is about to run, soonest first; **History** shows what already ran.
+- **Scheduled DMs tab** — the home for recurring DM rules (the reminders
+  and nudges). Create, edit, and remove them here.
+- **Status strip** at the top shows the next scheduled run.
+
+All times render in your own timezone.
+
+## Where to go deeper
+
+- [The schedule memory file](../features/memory-files/schedule.md) — how
+  scheduled work is stored.
+- [Schedule approaching](../features/operations/schedule-approaching.md) —
+  the heads-up the agent gives before a run.
+- [Routines](../concepts/routines.md) — the recurring agents that feed the
+  queue.
+
+## Related
+
+- [Agents page](agents.md) — the identities behind the runs.
+- [Overview page](overview.md) — the next run also shows on the home status bar.

package/agent-assets/docs/pages/wiki.md

@@ -0,0 +1,73 @@
+---
+schema_version: 1
+slug: pages/wiki
+title: "Wiki Page"
+id: page-wiki
+aliases:
+  - wiki page
+  - wiki dashboard
+category: pages
+summary: |
+  The Wiki page is the dashboard for the personal wiki builder — an opt-in
+  workspace that turns URLs, pastes, and notes you DM into a linked
+  Markdown wiki. It shows the index and recent activity, or an enable
+  prompt when no workspace exists yet.
+tags:
+  - wiki
+  - knowledge
+status: stable
+ask_examples:
+  - What can I do on the Wiki page?
+  - How do I enable the wiki?
+  - Where do I see my wiki's articles?
+  - How do I add a source to my wiki?
+locale: en-US
+created: 2026-07-01
+updated: 2026-07-01
+keywords:
+  - wiki
+  - workspace
+  - ingest
+  - compile
+  - articles
+related:
+  - features/wiki/overview
+  - features/wiki/dashboard
+  - features/wiki/commands
+  - guides/build-your-wiki
+ui_anchors:
+  - /wiki
+---
+
+# Wiki Page
+
+The `/wiki` page is where you read your wiki — the view surface for the
+wiki builder. You build the wiki itself over DM. The wiki is opt-in: until
+you enable a workspace, the page shows a **Wiki not enabled** card with a
+prompt to turn it on.
+
+## What you can do here
+
+- **Enable a workspace** the first time, from the enable card.
+- **Browse the index** of synthesized articles once a workspace is active.
+- **Watch recent activity** — the latest captures, compiles, and answers.
+- **Build the wiki over DM.** The real work happens through bang commands
+  (messages that start with `!`) you send the agent: `!ingest` to capture,
+  `!compile` to synthesize, `!ask` for cited answers, and
+  `!lint` / `!trace` / `!connect` to audit, trace history, and bridge
+  domains.
+
+## Where to go deeper
+
+- [Wiki overview](../features/wiki/overview.md) — the workspace concept and
+  the `00_inbox` / `10_raw` / `20_wiki` / `30_outputs` layers.
+- [Wiki dashboard](../features/wiki/dashboard.md) — this page and the
+  timeline in detail.
+- [Wiki commands](../features/wiki/commands.md) — the full `!` reference.
+- [Build your wiki](../guides/build-your-wiki.md) — first-day walkthrough.
+
+## Related
+
+- [Knowledge page](knowledge.md) — the agent's own memory (distinct from
+  the wiki).
+- [Settings → Wiki](settings.md) — workspace configuration.

package/agent-assets/docs/reference/api.md

@@ -16,9 +16,6 @@ summary: |
   per-route files under packages/daemon/src/api/routes/.
 section: api
 tags:
-  - reference
-  - api
-  - core
   - operations
 status: stable
 ask_examples:
@@ -28,7 +25,7 @@ ask_examples:
   - How do I list registered backends?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-08
+updated: 2026-07-01
 keywords:
   - API
   - REST
@@ -50,20 +47,23 @@ related:
 
 # API Reference
 
-The daemon serves a single Hono app on `127.0.0.1:PA_API_PORT` (default
-`8321`). Almost all endpoints are mounted under `/api/*`; the lone
-exception is the GitHub webhook receiver, mounted at root `/webhook/github`.
+The daemon serves one Hono web app on `127.0.0.1:PA_API_PORT` (default
+`8321`). Hono is a small, fast HTTP framework. Almost every endpoint sits
+under `/api/*`; the one exception is the GitHub webhook receiver, at the
+root path `/webhook/github`.
+
 **Source of truth:** `packages/daemon/src/api/server.ts` (`createApp`)
-registers most route groups, with one post-compose mount in
-`packages/daemon/src/bootstrap/api.ts` (the docs corpus + docs-QA, wired
-only after the indexer handle exists). Each group lives in its own file
-or directory under `packages/daemon/src/api/routes/`.
+registers most route groups. One more group is mounted later, in
+`packages/daemon/src/bootstrap/api.ts` — the docs corpus plus docs-QA,
+which can only be wired up once the search indexer is ready. Each group
+lives in its own file or directory under `packages/daemon/src/api/routes/`.
 
 ## Auth
 
-A bearer token is generated at first launch and stored in the OS
-keychain. The dashboard reads it via the daemon proxy; external
-callers pass it as `Authorization: Bearer <token>`.
+A bearer token — a secret string that proves a caller is allowed to use
+the API — is generated at first launch and stored in the OS keychain. The
+dashboard reads it through the daemon proxy; external callers pass it in
+the `Authorization: Bearer <token>` header.
 
 ## Route Groups
 
@@ -187,9 +187,10 @@ keys.
 ## Risk classification
 
 Every endpoint carries a `RiskTier` from
-`packages/daemon/src/safety/risk-classifier.ts`. The enum has three
-values (the former **notify** tier was abolished daemon-wide — Approve
-now covers everything that used to be Notify):
+`packages/daemon/src/safety/risk-classifier.ts` that says how much
+protection it needs. There are three values (the former **notify** tier
+was removed daemon-wide — Approve now covers everything that used to be
+Notify):
 
 - **autonomous** — safe to execute without any auth or notification.
 - **read_sensitive** — touches personal data (email, calendar, notes,

package/agent-assets/docs/reference/cli-commands.md

@@ -14,8 +14,6 @@ summary: |
   dashboard, plus the environment variables that override defaults.
 section: cli
 tags:
-  - core
-  - reference
   - cli
   - operations
 status: stable
@@ -28,7 +26,7 @@ ask_examples:
   - How do I check my install with aitne doctor?
 locale: en-US
 created: 2026-04-27
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - aitne start
   - aitne stop
@@ -54,6 +52,7 @@ related:
   - features/messaging/bang-commands
   - reference/knowledge-layout
   - reference/config
+  - reference/keyboard-shortcuts
 ui_anchors:
   - /setup
   - /activity
@@ -66,10 +65,11 @@ ui_anchors:
 
 `aitne` is the project's CLI (`bin/aitne.mjs`). The `pnpm <cmd>` forms are
 workspace scripts that delegate to the same entry point. Use whichever you
-prefer — `aitne start` and `pnpm start` do the same thing. After installing
-the npm package globally (`npm install -g @aitne-sh/aitne`) the `aitne`
-binary is on your `$PATH` and you no longer need to be inside the repo to
-use it. The tables below show both forms.
+prefer — `aitne start` and `pnpm start` do the same thing. After you install
+the npm package globally (`npm install -g @aitne-sh/aitne`), the `aitne`
+binary lands on your `$PATH` (the list of folders your shell searches for
+commands), so you can run it from anywhere — you no longer need to be inside
+the repo. The tables below show both forms.
 
 Note: `pnpm build` is *not* the same as `aitne build`. `pnpm build` runs
 `turbo run build` directly; `aitne build` runs the same build **and** writes
@@ -157,9 +157,10 @@ lives under `PA_DATA_DIR`, **not** inside the repo.
 
 ## Where data lives
 
-The context vault is partitioned into six authority classes (context-vault
-v2). The agent never writes these files directly — it goes through the
-daemon at `http://localhost:8321/api/context/<class>/<path>`.
+The context vault is split into six top-level folders (context-vault v2),
+each one an "authority class" — a separate group of memory files. The agent
+never writes these files directly; every write goes through the daemon at
+`http://localhost:8321/api/context/<class>/<path>`.
 
 ```
 ~/.personal-agent/
@@ -182,3 +183,5 @@ daemon at `http://localhost:8321/api/context/<class>/<path>`.
   guide that uses these commands end-to-end.
 - [Reinstall Cleanly](../guides/reinstall-cleanly.md) — when you need
   to wipe state and start over.
+- [Keyboard Shortcuts](./keyboard-shortcuts.md) — the dashboard hotkeys
+  that pair with these terminal commands.

package/agent-assets/docs/reference/config.md

@@ -15,8 +15,6 @@ summary: |
   and pointers to the canonical key tuples in shared/.
 section: config
 tags:
-  - core
-  - reference
   - config
   - operations
   - backends
@@ -78,7 +76,7 @@ ui_anchors:
   - /settings/infrastructure
   - /settings/models
 created: 2026-04-25
-updated: 2026-06-08
+updated: 2026-07-01
 related:
   - reference/api
   - reference/cli-commands
@@ -89,21 +87,24 @@ related:
 # Config Reference
 
 The full `AgentConfig` schema lives in
-`packages/daemon/src/config.ts`. Three canonical tuples in
-`packages/shared/src/editable-config-keys.ts` govern what is editable
-and when:
-
-- **`EDITABLE_RUNTIME_KEY_TUPLE`** — the ~130 keys mutable at runtime
-  via `PATCH /api/config`. Both the daemon and the dashboard import
-  from this tuple so the accepted-key set is enforced at compile time
-  in both packages.
-- **`RESTART_REQUIRED_KEY_TUPLE`** — runtime-editable keys whose
-  change does not apply to a running worker (the dashboard renders a
-  restart-required badge for these).
-- **`EDITABLE_BOOTSTRAP_KEY_TUPLE`** — `apiPort` only, written to
-  `.env` because it's read before the daemon binds.
-
-Anything not in those tuples must be set via env or restart.
+`packages/daemon/src/config.ts`. Three fixed lists of key names
+(TypeScript tuples) in `packages/shared/src/editable-config-keys.ts`
+decide which keys you can change, and when:
+
+- **`EDITABLE_RUNTIME_KEY_TUPLE`** — the ~130 keys you can change while
+  the daemon is running, via `PATCH /api/config`. Both the daemon and
+  the dashboard import this list, so the set of accepted keys is checked
+  at compile time in both packages.
+- **`RESTART_REQUIRED_KEY_TUPLE`** — keys you can edit at runtime, but
+  the new value only reaches a worker after a restart; it does not apply
+  to a worker that is already running. The dashboard shows a
+  restart-required badge for these.
+- **`EDITABLE_BOOTSTRAP_KEY_TUPLE`** — only `apiPort`. It is written to
+  `.env` because the daemon reads it before it starts listening on the
+  network (binds to a port).
+
+Any key that is not in one of these three lists can only be set through
+an environment variable or by restarting.
 
 ## Where Each Field Comes From
 
@@ -116,9 +117,9 @@ Anything not in those tuples must be set via env or restart.
 
 ## Selected Keys
 
-A representative slice of `EDITABLE_RUNTIME_KEY_TUPLE` — the full list
-of ~130 keys is in `editable-config-keys.ts`. Names below are exact and
-case-sensitive.
+A representative sample of `EDITABLE_RUNTIME_KEY_TUPLE`; the full list
+of ~130 keys is in `editable-config-keys.ts`. The names below are exact
+and case-sensitive.
 
 ### Identity and timezone
 
@@ -127,18 +128,19 @@ case-sensitive.
 | `agentDisplayName` | string | What the agent calls itself in DMs. |
 | `character` | string | Free-text user-defined communication style / persona (max 1000 chars). When non-empty, rendered as a `## Character (user-defined)` block into each backend's instruction file. The agent profile itself is selected by ProcessKey, not by this key. |
 | `timezone` | IANA tz | Empty falls back to the system tz. |
-| `dayBoundaryHour` | 0–9 | Default `4`. Controls the agent-day rollover (must be an early-morning hour). |
+| `dayBoundaryHour` | 0–9 | Default `4`. Sets the agent-day boundary — the moment "today" rolls over for the agent (must be an early-morning hour). |
 | `primaryLanguage` | BCP-47 | Output language for DMs, journal, and Obsidian writes. Templates stay English-headered. |
 | `vaultMode` | enum | Where context lives — `plain` (default; `<dataDir>/context`) or `obsidian` (an external Obsidian vault). |
 
 ### Activity scan and gate
 
-The first five keys are **deprecated fallbacks**: the activity-scan
-cadence, active window, min-observations threshold, and enable switch
-moved onto the activity-scan agent (`/agents/activity-scan`, Definition
-tab → Cadence card; Enable/Disable). The keys are still accepted by
-`PATCH /api/config` but no longer surfaced in the dashboard; values
-resolve agent override → legacy config key → built-in default.
+The first five keys are **deprecated fallbacks**. The activity-scan
+cadence (how often it runs), active window, minimum-observations
+threshold, and enable switch now live on the activity-scan agent
+(`/agents/activity-scan`, Definition tab → Cadence card; Enable/Disable).
+`PATCH /api/config` still accepts these keys, but the dashboard no longer
+shows them. A value resolves in this order: agent override → legacy
+config key → built-in default.
 
 | Key | Type | Notes |
 |---|---|---|
@@ -247,7 +249,7 @@ resolve agent override → legacy config key → built-in default.
 ### Feedback learning
 
 The feedback learning loop (capture → nightly consolidation → injection of
-durable lessons). All six knobs are runtime-editable via `PATCH /api/config`,
+durable lessons). All knobs are runtime-editable via `PATCH /api/config`,
 surfaced by `GET /config`, and tunable from the dashboard `/settings/lessons`
 page. Defaults and ranges below are enforced in
 `packages/daemon/src/settings/runtime-settings.ts`.
@@ -255,12 +257,15 @@ page. Defaults and ranges below are enforced in
 | Key | Type | Notes |
 |---|---|---|
 | `feedbackLearningEnabled` | boolean | Default `true` (env `FEEDBACK_LEARNING_ENABLED`). Master kill-switch for the whole loop — capture, consolidation, and injection. |
-| `selfTuningEnabled` | boolean | Default `false` (env `SELF_TUNING_ENABLED`). Actuation gate for the self-tuning review cycle. While `false`, the loop runs in shadow mode: the weekly review still receives `<tuning_recommendations>` and records verdicts via `POST /api/tuning/verdicts`, but no config change is ever applied. With the flag on, apply verdicts for config knobs actuate through the bounded config chokepoint — one owner DM per applied change, `!revert tuning` undoes the latest, and a daily monitor auto-reverts any change whose 7-day verify metrics regressed. Flip only after ≥2 clean shadow cycles (SELF_TUNING_REVIEW_CYCLE_DESIGN.md §7 shadow→live gate). |
+| `selfTuningEnabled` | boolean | Default `false` (env `SELF_TUNING_ENABLED`). Actuation gate for the self-tuning review cycle. While `false`, the loop runs in shadow mode: the weekly review still receives `<tuning_recommendations>` and records verdicts via `POST /api/tuning/verdicts`, but no config change is ever applied. With the flag on, apply verdicts for config knobs actuate through the bounded config chokepoint — one owner DM per applied change, `!revert tuning` undoes the latest, and a daily monitor auto-reverts any change whose 7-day verify metrics regressed. Flip only after ≥2 clean shadow cycles (SELF_TUNING_REVIEW_CYCLE_DESIGN.md §7 shadow→live gate); the daemon DMs you once when 3 consecutive shadow cycles were fully approved (graduation). |
 | `feedbackPromotionThreshold` | 1–10 | Default `2` (env `FEEDBACK_PROMOTION_THRESHOLD`). Weighted-evidence threshold a behavioral / self-critique lesson must clear before it becomes injectable. |
 | `feedbackLessonMaxBytesGlobal` | 1024–32768 | Default `8192` (env `FEEDBACK_LESSON_MAX_BYTES_GLOBAL`). Byte cap for `policies/agent-lessons.md`. |
 | `feedbackLessonMaxBytesPerAgent` | 512–16384 | Default `4096` (env `FEEDBACK_LESSON_MAX_BYTES_PER_AGENT`). Byte cap for each `policies/agents/<slug>/lessons.md`. |
-| `feedbackLessonStaleDays` | 7–365 | Default `60` (env `FEEDBACK_LESSON_STALE_DAYS`). Lessons whose `last=` date is older are pruned, except `kind=constraint` (durable). |
+| `feedbackLessonStaleDays` | 7–365 | Default `60` (env `FEEDBACK_LESSON_STALE_DAYS`). Staleness horizon for the graduated expiration lifecycle: an active lesson past the horizon whose time-decayed confidence is below the floor demotes to provisional (reversible); a provisional lesson uncorroborated for twice the horizon is archived. `kind=constraint` lessons are durable and never expire. |
 | `feedbackSignalRetentionDays` | 30–365 | Default `180` (env `FEEDBACK_SIGNAL_RETENTION_DAYS`). Consumed `feedback_signals` rows older than this are swept. |
+| `feedbackLessonConfidenceFloor` | 0–1 | Default `0.25` (env `FEEDBACK_LESSON_CONFIDENCE_FLOOR`). Inferred lessons whose effective (time-decayed) confidence `cf` falls below this floor are dropped from injection; also the demote test in the expiration lifecycle. Durable `constraint` lessons are exempt from the injection filter, and explicit owner corrections are floor-tested on their undecayed `cf` (an obeyed directive produces no corroborating signals, so decay alone must not silently un-bind it). `0` disables the filter. |
+| `feedbackContradictionGuardCf` | 0–1 | Default `0.6` (env `FEEDBACK_CONTRADICTION_GUARD_CF`). Anti-whiplash guard: a new candidate contradicting an established lesson with `cf` at or above this value is held provisional until it accumulates 1.5x the usual evidence. Explicit owner corrections always win immediately. |
+| `feedbackOutcomeLearningEnabled` | boolean | Default `true` (env `FEEDBACK_OUTCOME_LEARNING_ENABLED`). Includes the per-notification-type outcome rollup (replied / corrected / ignored, correction rate) in the nightly consolidation worksheet so lesson promotions weigh real reactions. |
 
 ## Routine Schedule Times Are Not Configurable
 
@@ -284,10 +289,10 @@ cadence and active window — edited on the activity-scan agent's page
 
 ## Restart-Required Keys
 
-The `RESTART_REQUIRED_KEY_TUPLE` covers fields whose new value is
-written through `applyConfigUpdates` but does not apply to a running
-worker — the dashboard renders a badge prompting an `aitne restart`.
-The current list:
+The `RESTART_REQUIRED_KEY_TUPLE` covers fields whose new value is saved
+through `applyConfigUpdates` but does not reach a worker that is already
+running — the dashboard shows a badge prompting an `aitne restart`. The
+current list:
 
 - `apiPort` (env-only)
 - `externalObsidianVaultName` / `externalObsidianVaultPath` / `externalObsidianWatch`

package/agent-assets/docs/reference/disallowed-tools.md

@@ -14,9 +14,7 @@ summary: |
   by skill-level allow-lists. Mirrors src/safety/always-disallowed.ts.
 section: reference
 tags:
-  - reference
   - safety
-  - core
   - audit
 status: stable
 ask_examples:
@@ -25,7 +23,7 @@ ask_examples:
   - Why can't the agent read my .env or SSH keys?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-07
+updated: 2026-07-01
 keywords:
   - disallowedTools
   - deniedTools
@@ -41,16 +39,18 @@ related:
 
 # Disallowed Tools
 
-There are two distinct deny layers — the **absolute-block layer**
-(non-overridable) and the **default strict-mode list** (`DEFAULT_DISALLOWED_TOOLS`
-in `src/settings/runtime-settings.ts`, relaxable in Allow mode or via
-`allowedToolsOverride`).
+The agent keeps two separate lists of tools it refuses to run. The
+first is the **absolute-block layer**, which nothing can turn off —
+not your config, not a skill's allow-list. The second is the
+**default strict-mode list** (`DEFAULT_DISALLOWED_TOOLS` in
+`src/settings/runtime-settings.ts`), which you *can* relax by
+switching to Allow mode or by setting `allowedToolsOverride`.
 
 ## Absolute-block layer (cannot be widened past)
 
-These patterns are denied unconditionally regardless of execution mode
-or `allowedToolsOverride`. Source of truth:
-`packages/daemon/src/safety/always-disallowed.ts`.
+The agent always refuses these patterns — no matter which execution
+mode it is in, and no matter what you put in `allowedToolsOverride`.
+Source of truth: `packages/daemon/src/safety/always-disallowed.ts`.
 
 | Category | Examples |
 |---|---|
@@ -79,13 +79,14 @@ managed-Chromium chokepoints above).
 
 ## Default strict-mode list (relaxable)
 
-`DEFAULT_DISALLOWED_TOOLS` (in `src/settings/runtime-settings.ts`, the
-seed for `config.disallowedTools`) ships with additional defaults that the
-operator can widen out of via `allowedToolsOverride` or by switching
-to Allow mode. These include `Bash(chmod *)`, `Bash(chown *)`,
-`Bash(git push --force *)`, `Bash(git reset --hard *)` and a handful
-of other footgun patterns. They are **not** in the absolute-block
-layer — Allow mode permits them.
+`DEFAULT_DISALLOWED_TOOLS` (in `src/settings/runtime-settings.ts`)
+seeds `config.disallowedTools` with a few extra blocks you can lift —
+either by setting `allowedToolsOverride` or by switching to Allow
+mode. These include `Bash(chmod *)`, `Bash(chown *)`,
+`Bash(git push --force *)`, `Bash(git reset --hard *)`, and a handful
+of other patterns that are easy to run by accident and hard to undo.
+Because they are **not** part of the absolute-block layer, Allow mode
+permits them.
 
 ## Audit log
 

package/agent-assets/docs/reference/keyboard-shortcuts.md

@@ -9,13 +9,11 @@ aliases:
   - key bindings
 category: reference
 summary: |
-  Keyboard shortcuts available in the dashboard. The set is small by
-  design — the dashboard is a low-cognition surface.
+  Keyboard shortcuts available in the dashboard. The set is small on
+  purpose — the dashboard is meant to stay calm and easy to scan.
 section: reference
 tags:
-  - reference
   - dashboard
-  - core
 status: stable
 ask_examples:
   - What keyboard shortcuts work in the dashboard?
@@ -23,7 +21,7 @@ ask_examples:
   - What does pressing "?" do in the dashboard?
 locale: en-US
 created: 2026-04-25
-updated: 2026-06-10
+updated: 2026-07-01
 keywords:
   - shortcut
   - hotkey
@@ -42,9 +40,9 @@ related:
 
 # Keyboard Shortcuts
 
-The dashboard ships a deliberately small set of shortcuts — it is a
-low-cognition surface, not a power-user IDE. These work from any
-dashboard screen.
+The dashboard ships a deliberately small set of shortcuts — it is built
+to stay calm and easy to scan, not to be a power-user IDE. These work
+from any dashboard screen.
 
 | Keys | Action |
 |---|---|

package/agent-assets/docs/reference/knowledge-layout.md

@@ -19,8 +19,6 @@ summary: |
   api/routes/context/permissions.ts.
 section: knowledge-layout
 tags:
-  - reference
-  - core
   - memory
   - knowledge
   - operations
@@ -34,7 +32,7 @@ ask_examples:
   - Which files can the agent write to?
 locale: en-US
 created: 2026-05-18
-updated: 2026-06-08
+updated: 2026-07-01
 keywords:
   - context
   - knowledge
@@ -87,15 +85,17 @@ knowledge of you. Every file lives under `PA_DATA_DIR/context/`
 (default `~/.personal-agent/context/`) as plain Markdown that you can read,
 edit, version, and back up with ordinary tools.
 
-The vault is partitioned into **six authority classes** — `identity/`, `state/`,
-`plans/`, `journal/`, `knowledge/`, and `policies/`. Each top-level directory
-carries a distinct authority + lifecycle contract; the daemon enforces those
-contracts via the file's YAML frontmatter (advisory in this release; strict in
-the next phase). This shape landed in the context-vault v2 restructure
+The vault is split into **six authority classes** — `identity/`, `state/`,
+`plans/`, `journal/`, `knowledge/`, and `policies/`. An authority class is
+simply a top-level directory with its own rules for who may write to it and
+how long its files are kept. The daemon enforces those rules through each
+file's YAML frontmatter (advisory in this release; strict in the next
+phase). This shape landed in the context-vault v2 restructure
 (migration `0004-context-vault-restructure`); legacy pre-v2 paths such as <!-- drift-allow -->
 `today.md`, `user/profile`, `rules/management`, `agent/journal`, etc. continue to work <!-- drift-allow -->
-because the daemon normalizes them in-process — never via HTTP 3xx — for one
-minor release while shipped skills and task-flows are updated.
+because the daemon rewrites them to the new paths in-process — never via an
+HTTP 3xx redirect — for one minor release while the shipped skills and
+task-flows are updated.
 
 The layout below is the canonical source-of-truth. It mirrors
 `packages/daemon/src/core/context-paths.ts` (`CONTEXT_RELATIVE_PATHS`) and