@aitne-sh/aitne 0.1.7 → 0.1.9

package/agent-assets/templates/README.md

@@ -1,9 +1,11 @@
 # agent-assets/templates/
 
 Source templates used by the daemon at **fresh install** time to populate
-`~/.personal-agent/context/` with the B-007 vault layout. The daemon copies
-system / pass-through assets from here directly. User-facing scaffolds that
-must follow `primary_language` are seeded by the `setup.initial` agent flow.
+`~/.personal-agent/context/` with the CONTEXT_VAULT_REDESIGN six-class
+layout (`identity/`, `state/`, `plans/`, `journal/`, `knowledge/`,
+`policies/`). The daemon copies system / pass-through assets from here
+directly. User-facing scaffolds that must follow `primary_language` are
+seeded by the `setup.initial` agent flow.
 
 **Language policy (B-007 §3 P6, unified through
 `docs/design/appendices/output-language-policy.md`)** — template source
@@ -11,12 +13,13 @@ lives here in English. The runtime rule is now carried by the
 `<output_language_policy>` block emitted by ContextBuilder, so every
 flow that writes a scaffold or refreshes one of these files follows one
 shared policy reference instead of restating language wording per flow.
-System prose templates (`rules/redaction.md`, `context-index.md`,
-`agent/journal.md`, `.base` files) stay English regardless of locale
-(Policy A). User-facing scaffolds (`today.md`, `roadmap.md`,
-`_index.md`, `routines/*.md`, `rules/journal-format.md`,
-`rules/journal-export.md`, `user/profile.md`) keep the template H2/H3
-headers (skeleton, Policy B) and their body is filled in
+System prose templates (`policies/redaction.md`, `journal/agent.md`,
+`.base` files, and the reconciler-block portion of `_index.md`) stay
+English regardless of locale (Policy A). User-facing scaffolds
+(`state/today.md`, `plans/roadmap.md`, `_index.md`,
+`policies/routines/*.md`, `policies/journal-format.md`,
+`policies/journal-export.md`, `identity/profile.md`) keep the template
+H2/H3 headers (skeleton, Policy B) and their body is filled in
 `primary_language` by the setup conversation before `save-rules`
 finalizes setup.
 
@@ -30,10 +33,10 @@ Two rendering paths:
 Files prefixed `_` (e.g. `_active.base`) are Obsidian sidebar-sort
 conventions — the leading underscore floats them to the top.
 
-**`today.md` and `roadmap.md`** are shape-canary templates. They are
-copied verbatim by `skeleton.ts:ensureSkeletonFiles` when the templates
-tree is reachable; when the tree is unreachable, `skeleton.ts` falls
-back to an inline literal in `FALLBACK_PLACEHOLDERS` that is kept
+**`state/today.md` and `plans/roadmap.md`** are shape-canary templates.
+They are copied verbatim by `skeleton.ts:ensureSkeletonFiles` when the
+templates tree is reachable; when the tree is unreachable, `skeleton.ts`
+falls back to an inline literal in `FALLBACK_PLACEHOLDERS` that is kept
 byte-equal to these template files. A unit test
 (`packages/daemon/src/core/skeleton.test.ts:"shape canary ..."`)
 asserts this equality on every CI run, so a PR that updates one path
@@ -49,7 +52,7 @@ inventory lives at `_manifest.json` (auto-generated) alongside the
 templates. When a template's format changes:
 
 1. **Bump `template_version` in the template file's frontmatter** (e.g.
-   1 → 2 when `rules/management.md` gains a new required section).
+   1 → 2 when `policies/management.md` gains a new required section).
 2. **Regenerate `_manifest.json`** so the `version` entry matches. A
    unit test (`template-versions.test.ts:"shipped manifest consistency"`)
    fails the build if the two disagree.
@@ -75,9 +78,10 @@ templates. When a template's format changes:
 
 ### Files excluded from versioning
 
-- `today.md`, `roadmap.md`, `projects/_active.base` — no frontmatter to
-  carry the marker. These files are shape canaries / Obsidian view
-  configs that evolve through schema validation, not template diff.
+- `state/today.md`, `plans/roadmap.md`, `plans/projects/_active.base` —
+  no frontmatter to carry the marker. These files are shape canaries /
+  Obsidian view configs that evolve through schema validation, not
+  template diff.
 - `README.md` (this file) — documentation, not a template.
 
 Bump `manifestVersion` in `_manifest.json` only when the manifest
@@ -85,8 +89,11 @@ schema itself changes (e.g. a new per-entry field). Individual
 template-version bumps leave `manifestVersion` alone.
 
 See `docs/design/06-memory.md` and `docs/design/12-configuration.md` for the
-fresh-install flow and vault layout. The `rules/management.md` template
+fresh-install flow and vault layout. The `policies/management.md` template
 follows the structured `schema_version: 3` registry specified in
 `docs/design/21-management-registry-and-entities.md` (A. SoT bindings,
-B. Managed tasks, C. Active-Policies stub) — the v2 "Default Schedules"
-section has been retired (§21 §8.10); do not reintroduce it.
+B. Managed tasks, C. Active-Policies stub). `Default Schedules` is not a
+static template section: the daemon's default-schedules reconciler appends
+a read-only `## Default Schedules` mirror of `recurring_schedules` at
+runtime (§21 §8.10), so it is intentionally absent from this seed — do
+not add it here.

package/agent-assets/templates/_index.md

@@ -1,39 +1,55 @@
 ---
 type: index
 owner: shared
-updated: 2026-04-22
-template_version: 1
+updated: 2026-05-25
+template_version: 2
 ---
 # Aitne Vault
 
-This directory is shared by the agent and me. The agent writes most of it;
-I can edit any file and my edits are preserved (see `rules/management.md`
-for conflict handling).
+This directory is shared by the agent and me. Six top-level folders sit
+under this root; each carries a single authority/lifecycle contract so I
+(and the agent) can always tell which kind of file lives where. The
+agent writes most of it; I can edit any file and my edits are preserved
+(see `policies/management.md` for conflict handling).
 
 ## Where things live
 
-- **About me** → `user/` (profile, people, work, expertise, personal, goals)
-- **Today / Roadmap** → root-level `today.md` and `roadmap.md`
-- **Yesterday snapshot** → yesterday.md appears after the first morning
-  rotation and is replaced by the next one
-- **Projects** → `projects/`; project notes use the projects/<slug>.md
-  naming pattern. See `projects/_index.md` or open `projects/_active.base`
-  in Obsidian
-- **Daily archives** → `daily/` files named by date (synthesized journal)
-- **Weekly / Monthly reviews** → `weekly/`, `monthly/`
-- **Agent self-reflection** → `agent/journal.md` (internal; never pushed
-  as a notification)
-- **Rules & policies** → `rules/` (how the agent should behave — edited by
-  either of us)
-- **Routines** → `routines/` (per-cadence check-list rulebooks)
-- **Dump bucket** → `inbox/` (paste anything here; I'll triage on next
-  morning routine)
+- **About me** → `identity/` (profile, people, work, expertise, personal, goals)
+- **Today / Yesterday** → `state/today.md`, `state/yesterday.md`
+- **Roadmap & projects** → `plans/roadmap.md`, `plans/projects/<slug>.md`
+  (open `plans/projects/_active.base` in Obsidian for the active list)
+- **Inbox dumps** → `state/inbox/` (paste anything here; I'll triage on
+  the next morning routine)
+- **Agent scratch** → `state/scratch/` (48h-TTL working area; not
+  durable)
+- **Activity views** → `state/activity/` (90-day reconciler outputs)
+- **Profile-question queue** → `state/profile-questions.md`
+- **Daily / Weekly / Monthly journals** → `journal/daily/`,
+  `journal/weekly/`, `journal/monthly/` (date-named, append-only)
+- **Per-repo journals** → `journal/repos/<slug>/<date>.md`
+- **Agent self-reflection** → `journal/agent.md` (decision log,
+  append-only, never DM'd)
+- **Wiki workspaces** → `knowledge/wiki/<workspace>/` (internal vaults
+  live here; external Obsidian vaults stay external)
+- **Per-repo overviews** → `knowledge/repos/<slug>/overview.md`
+- **Dossiers** → `knowledge/dossiers/` (accumulated agent research)
+- **Management-registry entities** → `knowledge/entities/<domain>/<type>/<slug>.md`
+- **Rules & policies** → `policies/` (`management.md`, `mcp.md`,
+  `redaction.md`, `journal-format.md`, `journal-export.md`,
+  `integrations.md`)
+- **Routines** → `policies/routines/` (per-cadence rulebooks)
+- **User skills** → `policies/skills/<slug>/SKILL.md`
+- **Policy captures** → `policies/management-captures/`
 
 ## How the agent reads/writes this
 
-All writes go through the context API (locked + snapshotted). Read: direct.
-`Edit`/`Write` tools are not available to the agent — the API is the only
-chokepoint.
+All writes go through the context API (locked + snapshotted). Read:
+direct. `Edit`/`Write` tools are not available to the agent — the API
+is the only chokepoint.
 
-This file is human-readable navigation. The agent's canonical file catalog
-is `context-index.md`, maintained from the filesystem.
+The block below is maintained by the daemon reconciler. Edits inside
+the `<!-- reconciler-section -->` markers are overwritten on the next
+run. Anything outside the markers is yours and is preserved.
+
+<!-- reconciler-section -->
+<!-- /reconciler-section -->

package/agent-assets/templates/_manifest.json

@@ -1,103 +1,38 @@
 {
-  "manifestVersion": 1,
-  "generatedAt": "2026-04-23",
-  "notes": "Auto-generated inventory of versioned templates. Each entry's 'version' must equal the `template_version:` field in the corresponding template file's frontmatter. Bump both in the same PR. A unit test asserts this consistency.",
+  "manifestVersion": 2,
+  "generatedAt": "2026-05-25",
+  "notes": "Auto-generated inventory of versioned templates. Each entry's 'version' must equal the `template_version:` field in the corresponding template file's frontmatter. Bump both in the same PR. A unit test asserts this consistency. Layout rebased onto the CONTEXT_VAULT_REDESIGN six-class structure (identity/, state/, plans/, journal/, knowledge/, policies/).",
   "templates": {
-    "_index.md": {
-      "version": 1
-    },
-    "agent/journal.md": {
-      "version": 1
-    },
-    "agent/profile-questions.md": {
-      "version": 1
-    },
-    "context-index.md": {
-      "version": 1
-    },
-    "dossiers/_index.md": {
-      "version": 1
-    },
-    "dossiers/evening.md": {
-      "version": 1
-    },
-    "dossiers/hourly.md": {
-      "version": 1
-    },
-    "dossiers/monthly.md": {
-      "version": 1
-    },
-    "dossiers/morning.md": {
-      "version": 1
-    },
-    "dossiers/roadmap.md": {
-      "version": 1
-    },
-    "dossiers/weekly.md": {
-      "version": 1
-    },
-    "projects/_index.md": {
-      "version": 1
-    },
-    "routines/_index.md": {
-      "version": 1
-    },
-    "routines/evening.md": {
-      "version": 1
-    },
-    "routines/hourly.md": {
-      "version": 1
-    },
-    "routines/monthly.md": {
-      "version": 1
-    },
-    "routines/morning.md": {
-      "version": 1
-    },
-    "routines/weekly.md": {
-      "version": 1
-    },
-    "rules/_index.md": {
-      "version": 2
-    },
-    "rules/journal-export.md": {
-      "version": 1
-    },
-    "rules/journal-format.md": {
-      "version": 1
-    },
-    "rules/management.md": {
-      "version": 2
-    },
-    "rules/mcp.md": {
-      "version": 1
-    },
-    "rules/policies/_index.md": {
-      "version": 2
-    },
-    "rules/redaction.md": {
-      "version": 1
-    },
-    "user/_index.md": {
-      "version": 1
-    },
-    "user/expertise.md": {
-      "version": 1
-    },
-    "user/goals.md": {
-      "version": 1
-    },
-    "user/people.md": {
-      "version": 1
-    },
-    "user/personal.md": {
-      "version": 1
-    },
-    "user/profile.md": {
-      "version": 2
-    },
-    "user/work.md": {
-      "version": 1
-    }
+    "_index.md": { "version": 2 },
+    "identity/_index.md": { "version": 1 },
+    "identity/expertise.md": { "version": 2 },
+    "identity/goals.md": { "version": 2 },
+    "identity/people.md": { "version": 2 },
+    "identity/personal.md": { "version": 2 },
+    "identity/profile.md": { "version": 2 },
+    "identity/work.md": { "version": 2 },
+    "journal/agent.md": { "version": 1 },
+    "knowledge/dossiers/_index.md": { "version": 1 },
+    "knowledge/dossiers/evening.md": { "version": 1 },
+    "knowledge/dossiers/hourly.md": { "version": 1 },
+    "knowledge/dossiers/monthly.md": { "version": 1 },
+    "knowledge/dossiers/morning.md": { "version": 1 },
+    "knowledge/dossiers/roadmap.md": { "version": 1 },
+    "knowledge/dossiers/weekly.md": { "version": 1 },
+    "plans/projects/_index.md": { "version": 1 },
+    "policies/_index.md": { "version": 2 },
+    "policies/journal-export.md": { "version": 1 },
+    "policies/journal-format.md": { "version": 3 },
+    "policies/management-captures/_index.md": { "version": 2 },
+    "policies/management.md": { "version": 2 },
+    "policies/mcp.md": { "version": 1 },
+    "policies/redaction.md": { "version": 1 },
+    "policies/routines/_index.md": { "version": 1 },
+    "policies/routines/evening.md": { "version": 1 },
+    "policies/routines/hourly.md": { "version": 1 },
+    "policies/routines/monthly.md": { "version": 1 },
+    "policies/routines/morning.md": { "version": 1 },
+    "policies/routines/weekly.md": { "version": 1 },
+    "state/profile-questions.md": { "version": 1 }
   }
 }

package/agent-assets/templates/{user → identity}/_index.md

@@ -13,4 +13,4 @@ template_version: 1
 | `work.md` | Workplace, team, tech stack |
 | `expertise.md` | Domains, tools, skills |
 | `personal.md` | Hobbies, health, habits |
-| `goals.md` | Developmental goals (distinct from `../roadmap.md` project milestones) |
+| `goals.md` | Developmental goals (distinct from `../plans/roadmap.md` project milestones) |

package/agent-assets/templates/identity/expertise.md

@@ -0,0 +1,9 @@
+---
+type: user
+owner: shared
+updated: 2026-05-18
+template_version: 2
+---
+# Expertise
+
+## Tools

package/agent-assets/templates/identity/goals.md

@@ -0,0 +1,9 @@
+---
+type: user
+owner: shared
+updated: 2026-05-18
+template_version: 2
+---
+# Goals
+
+## Learning

package/agent-assets/templates/identity/people.md

@@ -0,0 +1,13 @@
+---
+type: user
+owner: shared
+updated: 2026-05-18
+template_version: 2
+---
+# People
+
+## Family
+
+## Colleagues
+
+## Friends

package/agent-assets/templates/identity/personal.md

@@ -0,0 +1,9 @@
+---
+type: user
+owner: shared
+updated: 2026-05-18
+template_version: 2
+---
+# Personal
+
+## Habits

package/agent-assets/templates/{user → identity}/profile.md

@@ -9,8 +9,8 @@ template_version: 2
 # User
 
 > Primary profile injected into every session. Keep this file concise.
-> Detailed profile lives under `user/`.
-> Fetch index: `curl -s http://localhost:8321/api/context/user/_index`
+> Detailed profile lives under `identity/`.
+> Fetch index: `curl -s http://localhost:8321/api/context/identity/_index`
 
 ## Identity
 (To be filled during setup)

package/agent-assets/templates/identity/work.md

@@ -0,0 +1,9 @@
+---
+type: user
+owner: shared
+updated: 2026-05-18
+template_version: 2
+---
+# Work
+
+## Stack

package/agent-assets/templates/{dossiers → knowledge/dossiers}/_index.md

@@ -15,8 +15,8 @@ Injected into prompts through the root-level context-index.md catalog.
 | File | Process key |
 |---|---|
 | `hourly.md` | `routine.hourly_check` |
-| `morning.md` | `routine.morning_routine`, `routine.morning_routine_initial` |
+| `morning.md` | `routine.morning_routine`, `routine.morning_routine_today` |
 | `evening.md` | `routine.evening_review` |
 | `weekly.md` | `routine.weekly_review` |
 | `monthly.md` | `routine.monthly_review` |
-| `roadmap.md` | `routine.roadmap_refresh` |
+| `plans/roadmap.md` | `routine.roadmap_refresh` |

package/agent-assets/templates/{projects → plans/projects}/_active.base

@@ -1,6 +1,6 @@
 filters:
   and:
-    - file.inFolder("projects")
+    - file.inFolder("plans/projects")
     - state != "archived"
 views:
   - type: table

package/agent-assets/templates/policies/_index.md

@@ -0,0 +1,21 @@
+---
+type: index
+owner: shared
+updated: 2026-04-24
+template_version: 2
+---
+# Policies
+
+Natural-language policy files the agent reads to decide HOW to act. Each
+is user-editable; changes take effect at the next task-flow assembly.
+
+| File | Purpose |
+|---|---|
+| `policies/management.md` | Source-of-truth bindings (where each category lives) |
+| `policies/management-captures/_index.md` | Active management policies captured from conversation |
+| `policies/mcp.md` | MCP usage rules (B-003) |
+| `policies/journal-format.md` | Format spec for the daily synthesized journal |
+| `policies/journal-export.md` | User-defined redaction / inclusion rules for B-005 |
+| `policies/redaction.md` | Built-in secret patterns (English, informational) |
+| `policies/routines/` | Per-cadence routine definitions read by the scheduler |
+| `policies/integrations.md` | Integration mode snapshot (renderer keeps this in sync) |

package/agent-assets/templates/{rules → policies}/journal-export.md

@@ -9,7 +9,7 @@ template_version: 1
 
 Edit this file to control what's included when the agent mirrors your
 synthesized `daily/*.md` entries to an external backend (B-005). These
-rules run *on top of* the built-in `rules/redaction.md` patterns.
+rules run *on top of* the built-in `policies/redaction.md` patterns.
 
 ## Inclusion defaults
 

package/agent-assets/templates/policies/journal-format.md

@@ -0,0 +1,168 @@
+---
+type: rule
+slug: journal-format
+owner: user
+updated: 2026-05-16
+template_version: 3
+---
+# Daily journal — format template
+
+This file controls how the agent writes `daily/YYYY-MM-DD.md` during the
+04:00 morning routine. Edit this file to change the format. The agent
+reads it as a **format spec** (body structure, required/optional sections,
+voice) — it does NOT follow this as code; natural-language guidance is
+fine.
+
+## Framing — this is the user's diary
+
+`daily/<date>.md` is the **user's diary**, not the agent's behavior
+log. It records the user's day: what the user did, what the user
+talked about, what was on their schedule. The agent is the author
+because the human user doesn't journal by hand — but the perspective,
+voice, and content all belong to the user.
+
+Agent-side bookkeeping (action counts, internal anomalies, audit
+trail) lives in `journal/agent.md` — not here. If you find yourself
+about to log "the agent ran N tools today" or "the hourly check
+fired M times", that belongs in the agent-side log instead. Filter
+it out.
+
+The daemon's `journal-skeleton-builder`
+(`docs/design/appendices/morning-routine-optimization.md` §"Daemon-side
+modules to add" — Phase 2 daemon primitive) emits scratch data
+(`## Schedule`, `## Tasks`, `## Conversations`) read from SQLite +
+yesterday.md. Stage B **authors the entire body** per the section
+list below, using the scratch sections as input data — the skeleton
+sections are NOT preserved verbatim. Only the skeleton-owned
+frontmatter MUST be preserved byte-for-byte; the daemon's daily-write
+chokepoint validates frontmatter drift with
+`context.skeleton_field_drift` and rejects the PUT with 422. Body
+content (section names, ordering, prose) is Stage B's responsibility
+and not validated for drift.
+
+## Required frontmatter fields
+
+Skeleton-owned (preserved byte-for-byte by Stage B):
+- `date`, `weekday`, `type: daily`, `owner: agent`, `agent_generated: true`
+- `calendar_events: <count>` — total calendar events filtered to the
+  agent-day window
+- `messages_handled: <count>` — **incoming user messages only**
+  (`messages.role='user'` rows within the agent-day window). Agent
+  replies and internal `system` rows are excluded so the value
+  matches "how many messages did the user send today" rather than
+  total conversation turns. (Field name kept for backward
+  compatibility with already-written daily journals; a future rename
+  to `messages_received` is deferred.)
+- `updated: <YYYY-MM-DD>` — today's agent-day, stamped by the daemon
+  at skeleton-build time. The generic context-frontmatter validator
+  requires this field on every `daily/*.md` PUT; emitting it from the
+  daemon (instead of leaving it as a Stage-B placeholder) eliminates
+  the 422 failure mode where Stage B forgot to fill the slot.
+
+Stage B-owned (filled from the narrative Stage B authors):
+- `agent_last_synced_at` (ISO 8601), `content_hash` (`sha256:<hex>`)
+- `projects: [...]`, `people: [...]`, `tags: [...]`
+
+## Required body sections (Stage B output order)
+
+Stage B authors each section below. Annotations describe the scratch
+data Stage B reads from the daemon-emitted skeleton; the skeleton
+section names happen to match the output section names, but Stage B
+remains free to reshape data, add bullets, drop a section on a sparse
+day, etc.
+
+1. `# YYYY-MM-DD (Weekday)` — title. Stage B emits verbatim from the
+   skeleton's title line.
+2. `## Summary` — **one paragraph, 3–5 sentences, first-person voice
+   from the user's perspective**. Authored entirely by Stage B (no
+   skeleton placeholder). Placed first so the reader's eye lands on
+   the narrative synthesis before the raw-fact sections that follow
+   (TL;DR-at-top reading order matching the pre-rev2 daily journal
+   corpus the user has accumulated). The voice is **the user's**, not
+   the agent's — "I shipped X", "I met with Y", "I felt rushed about
+   Z". Don't write about what the agent did ("the agent triaged 4
+   inbox items") — that's footprint, not diary content.
+3. `## Schedule` — yesterday's events the user attended (or had
+   planned). Each line is `- HH:MM — <title>` for timed events, `-
+   <title>` for all-day. `- (none)` when the day carried no events.
+   Stage B reads the skeleton's `## Schedule` scratch section as
+   input; may add `(attended)` / `(skipped)` flags from yesterday
+   context.
+4. `## Tasks` — yesterday's `## User Tasks` carried forward, checkbox
+   markers stripped, `(none)` placeholder filtered. These are the
+   things the user was meant to do — keep them user-side (not
+   agent-side schedule rows). `- (none)` when yesterday had no User
+   Tasks. Stage B reads the skeleton's `## Tasks` scratch section as
+   input.
+5. `## Conversations` — **what the user talked about that day**, as
+   topic-level bullets. Stage B reads the skeleton's
+   `## Conversations` scratch section (rolling DM summaries with
+   HH:MM + message counts) and synthesises **2–5 topic bullets** in
+   the user's voice, e.g. `- Discussed Q2 roadmap with the agent —
+   agreed to defer feature X`. The HH:MM and `(n=N)` markers from
+   the scratch input are NOT preserved verbatim; they're inputs for
+   topic synthesis, not output structure. `- (none)` when no DM
+   activity. Skip mechanical per-thread enumeration — collapse to
+   topics.
+
+**Sections deliberately NOT in the daily journal:**
+
+- ❌ Agent action counts (`agent_actions` breakdown by type). Lives
+  in `journal/agent.md` instead — the audit-trail footprint.
+- ❌ Internal stage status, retry counts, anomalies. Same as above.
+- ❌ "The agent did X for the user" framing. The user's diary uses
+  user voice; agent meta-narration belongs in the agent-side log.
+
+## Voice (`## Summary` and `## Conversations`)
+
+- First-person **from the user's perspective** ("I shipped...", "I
+  met with...", "I asked the agent about..."), concise, factual
+- Written in `settings.primary_language`; keep technical terms in their
+  original form if that's how the user writes them
+- Refers to the entities Stage B surfaces in the body sections that
+  follow (the meetings under `## Schedule`, the tasks under
+  `## Tasks`, the topics under `## Conversations`) so the narrative
+  reads as a synthesis of those facts, not a separate stream of
+  consciousness
+
+## Wikilink rendering
+
+- When `settings.vault_mode` is `obsidian`, Stage B renders project /
+  people references throughout the body as `[[wikilinks]]` targeting
+  `projects/<slug>.md` or `identity/people.md#<person>` (basename resolves
+  automatically). The `## Summary` paragraph is the primary surface,
+  but data sections may also receive wikilinks where a project / person
+  name appears (e.g. a meeting title containing a person's name).
+- When `vault_mode` is `plain`, Stage B writes plain text only — no
+  double brackets, no link markup.
+- The skeleton's scratch sections do not embed wikilinks; Stage B
+  applies them as it authors the final body.
+
+## Redaction
+
+- Apply `policies/redaction.md` patterns to the entire body Stage B
+  authors (Summary + data sections both — Stage B owns the body, so
+  redaction applies wherever sensitive content might surface).
+- Apply `policies/journal-export.md` user rules to the entire body.
+- If yesterday.md frontmatter had `no_journal_export: true`, write
+  `[Skipped by user request]` as the body of `## Summary` and omit
+  the data sections (they would echo information the export rule is
+  trying to suppress).
+
+The skeleton's scratch sections carry data sourced from upstream
+writers (calendar observer, yesterday.md `## User Tasks`, the
+`dm_conversation_log` rolling-summary writer). Stage B SHOULD apply
+redaction during authoring; but the *primary* defence belongs
+**upstream** — if a credit-card number is appearing in
+`dm_conversation_log` summaries, fix the rolling-summary writer
+rather than relying on Stage B as the last line of defence. Stage
+B's redaction is a backstop, not a safety net.
+
+## Conflict behavior
+
+Follow B-006 content-hash protection: if the user edited the previous
+day's `daily/<date>.md`, append `## Agent revision — <ISO timestamp>`
+rather than overwrite. The Agent revision section may carry a fresh
+Summary + any updated data sections. The original body the user
+edited is preserved verbatim above the Agent revision boundary;
+Stage B does NOT rewrite sections the user touched.

package/agent-assets/templates/{rules/policies → policies/management-captures}/_index.md

@@ -8,8 +8,8 @@ template_version: 2
 
 Auto-maintained by the daemon's policy-index reconciler. Direct edits
 are overwritten on the next reconcile pass — to add or modify a policy,
-edit its `rules/policies/<slug>.md` file (or use the `management-policy`
-skill).
+edit its `policies/management-captures/<slug>.md` file (or use the
+`management-policy` skill).
 
 ## Active
 

package/agent-assets/templates/{rules → policies}/management.md

@@ -32,15 +32,15 @@ or the dashboard's Settings → Management page._
 ## C. Active Policies
 
 Auto-maintained by the daemon (do not edit). Source files live under
-`rules/policies/<slug>.md`; capture new policies via the
-`management-policy` skill. Full index: [[rules/policies/_index.md]]
+`policies/management-captures/<slug>.md`; capture new policies via the
+`management-policy` skill. Full index: [[policies/management-captures/_index.md]]
 
 _No active policies yet._
 
 ## Notes
 
 - The agent cannot use `Edit` / `Write` tools on this file — writes go
-  through `/api/context/rules/management` (locked + snapshotted) or the
+  through `/api/context/policies/management` (locked + snapshotted) or the
   managed-tasks / sot-bindings API surfaces.
 - This file is injected into every flow via `policy-files.ts`. Keep it
   concise so prompt assembly stays cheap.

package/agent-assets/templates/{rules → policies}/mcp.md

@@ -16,7 +16,7 @@ This file governs how the agent uses attached Model Context Protocol
   the target with me via DM when the change is visible to others (a new
   issue, a posted message, an edited doc).
 - Failures are loggable events. On repeated MCP call failures, the agent
-  appends to `agent/journal.md` and surfaces the pattern at the next
+  appends to `journal/agent.md` and surfaces the pattern at the next
   hourly check.
 - Scope to the active task. MCP calls unrelated to the current flow's
   stated goal are skipped.