@aitne-sh/aitne 0.1.8 → 0.1.10

package/agent-assets/task-flows/message.received.dm.md

@@ -10,11 +10,15 @@ Apply the canonical capture-user-info routing below to `<user_input>`.
 
 {include:_partials/capture-user-info.md}
 
+Apply the canonical feedback-capture routing below to `<user_input>`.
+
+{include:_partials/feedback-capture.md}
+
 ### Step 2 — Profile-question reconcile / latent opportunity
 
 Two operations from the user-interview skill — run in order, before composing the reply.
 
-**A. Queue reconcile (Operation 4).** GET `agent/profile-questions.md ## In Progress`. For any `state=asked` entry where `(now − asked_at) < 24h`, treat the inbound DM as the answer: tick the matching `## Pending` row `[ ]` → `[x]`, remove from `## In Progress`, append to `## Answered`, and remove the matching `Profile question (...)` line from today's notes section. Leave `state=latent` / `state=scheduled` entries alone.
+**A. Queue reconcile (Operation 4).** GET `state/profile-questions.md ## In Progress`. For any `state=asked` entry where `(now − asked_at) < 24h`, treat the inbound DM as the answer: tick the matching `## Pending` row `[ ]` → `[x]`, remove from `## In Progress`, append to `## Answered`, and remove the matching `Profile question (...)` line from today's notes section. Leave `state=latent` / `state=scheduled` entries alone.
 
 **B. Latent opportunity (Operation 2).** If after reconcile a `state=latent` entry remains:
 
@@ -106,7 +110,7 @@ snapshot is fresh.
 
 Refetch the live log when the user asks about recent activity — for example "what have you been up to", "did anything come in", "anything new since X", "anything happen", "in the last N minutes".
 
-- Issue `GET /api/context/today` (the standard context-read endpoint).
+- Issue `GET /api/context/state/today` (the standard context-read endpoint).
 - Compare the live `## Agent Log` against what is in <today>.
 - Answer from the union. If the live log shows no new entries beyond
   <today>, the snapshot was sufficient — answer from <today> with no
@@ -143,7 +147,12 @@ detection" §"Reply branches", carrying the user's reply shape (yes /
 counter-proposal / no) into that handler. Apply the same pattern to
 any other gate that opts into the confirm sub-flow in the future.
 
-**Scheduling.** Recurring ("every hour", "every morning at 9", "weekly", "25th of each month") → `POST /api/recurring-schedules`. One-shot ("tomorrow 3pm", "in 30 min") → `POST /api/schedule/dm` (pre-composed; default) or `POST /api/schedule` (wake-up that must look something up at fire time). Edit / cancel / list use the same endpoints. Load the schedule skill for the request shape, dedup pre-check, DM-vs-wake decision, and description contract. Use `<current_time>` for timezone resolution. Prefer `tier` over `model`; the two are mutually exclusive on a single row.
+**Scheduling.** Split by what fires:
+- **Recurring autonomous work** ("every hour check my PRs and act", "each morning fetch X and update Y") → create an **Agent** via the `agent-create` skill (`POST /api/agents`). These are durable, named, recurring work identities managed on `/agents`.
+- **Recurring scheduled DM / briefing** ("DM me a summary every morning at 9") → `POST /api/recurring-schedules` with `taskType: "dm_session"` (still the home for recurring DMs).
+- **One-shot** ("tomorrow 3pm", "in 30 min") → `POST /api/schedule/dm` (pre-composed; default) or `POST /api/schedule` (wake-up that must look something up at fire time).
+
+Load the `schedule` skill (one-shot + recurring-DM request shape, dedup, DM-vs-wake, description contract) or the `agent-create` skill (recurring work Agents). Use `<current_time>` for timezone resolution. Prefer `tier` over `model`; the two are mutually exclusive.
 
 Schedules go through this daemon — never through any cloud-hosted scheduled-agent feature your CLI may expose. Cloud routines cannot reach `localhost:8321`, so they cannot deliver via the user's chat platforms or use any integration registered here. Do not propose one as a tradeoff.
 
@@ -157,7 +166,7 @@ Schedules go through this daemon — never through any cloud-hosted scheduled-ag
    - **Re-enable** → `PATCH /api/recurring-schedules/:id` `{"enabled": true}`.
 3. Confirm to the user in persona voice. Keep it short — never name internal mechanisms ("recurring schedule", "pin_to_quiet_hours_end", row IDs) in user-visible text.
 
-**Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → apply the decision tree below; the `roadmap` skill is the writer. Ambiguous or speculative items belong in `agent/journal.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `roadmap.md` without a clear positive signal.
+**Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → apply the decision tree below; the `roadmap` skill is the writer. Ambiguous or speculative items belong in `journal/agent.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `plans/roadmap.md` without a clear positive signal.
 
 {include:_partials/dm-intent.long-horizon.md}
 

package/agent-assets/task-flows/message.received.dm_first.md

@@ -12,11 +12,15 @@ Apply the canonical capture-user-info routing below to `<user_input>`.
 
 {include:_partials/capture-user-info.md}
 
+Apply the canonical feedback-capture routing below to `<user_input>`.
+
+{include:_partials/feedback-capture.md}
+
 ### Step 2 — Profile-question reconcile / latent opportunity
 
 Two operations from the user-interview skill — run in order, before composing the reply.
 
-**A. Queue reconcile (Operation 4).** GET `agent/profile-questions.md ## In Progress`. For any `state=asked` entry where `(now − asked_at) < 24h`, treat the inbound DM as the answer: tick the matching `## Pending` row `[ ]` → `[x]`, remove from `## In Progress`, append to `## Answered`, and remove the matching `Profile question (...)` line from today's notes section. Leave `state=latent` / `state=scheduled` entries alone.
+**A. Queue reconcile (Operation 4).** GET `state/profile-questions.md ## In Progress`. For any `state=asked` entry where `(now − asked_at) < 24h`, treat the inbound DM as the answer: tick the matching `## Pending` row `[ ]` → `[x]`, remove from `## In Progress`, append to `## Answered`, and remove the matching `Profile question (...)` line from today's notes section. Leave `state=latent` / `state=scheduled` entries alone.
 
 **B. Latent opportunity (Operation 2).** If after reconcile a `state=latent` entry remains, FIRST run the slot-filled pre-check (GET `/api/profile-questions/slot-filled?path=<target>&section=<section?>&anchor=<anchor?>`); if `filled: true`, resolve the row (tick Pending, remove In Progress, append `(reconciled:opportunity)` to Answered, remove the matching note line) and **do not weave a question**.
 
@@ -132,11 +136,11 @@ project?"* → user replies "yeah" → route through the context skill's
 "Project DM-intent detection" §"Reply branches" with branch=
 affirmative.
 
-**Scheduling.** Recurring ("every hour", "every morning at 9", "weekly", "25th of each month") → `POST /api/recurring-schedules`. One-shot ("tomorrow 3pm", "in 30 min") → `POST /api/schedule/dm` (pre-composed; default) or `POST /api/schedule` (wake-up). Edit / cancel / list use the same endpoints. Load the schedule skill for the request shape, dedup pre-check, and description contract. Use `<current_time>` for timezone resolution. Prefer `tier` over `model`; the two are mutually exclusive on a single row.
+**Scheduling.** Recurring autonomous **work** ("every hour check X and act") → create an **Agent** via the `agent-create` skill (`POST /api/agents`). Recurring scheduled **DM / briefing** ("DM me every morning at 9") → `POST /api/recurring-schedules` (`taskType: "dm_session"`). One-shot ("tomorrow 3pm", "in 30 min") → `POST /api/schedule/dm` (pre-composed; default) or `POST /api/schedule` (wake-up). Load the `schedule` skill (one-shot + recurring-DM) or `agent-create` (recurring work Agents). Use `<current_time>` for timezone resolution. Prefer `tier` over `model`; the two are mutually exclusive.
 
 Schedules go through this daemon — never through any cloud-hosted scheduled-agent feature your CLI may expose. Cloud routines cannot reach `localhost:8321`, so they cannot deliver via the user's chat platforms or use any integration registered here.
 
-**Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → apply the decision tree below; the `roadmap` skill is the writer. Ambiguous or speculative items belong in `agent/journal.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `roadmap.md` without a clear positive signal.
+**Long-horizon intent** (commitment, trip, deliverable, learning target beyond today) → apply the decision tree below; the `roadmap` skill is the writer. Ambiguous or speculative items belong in `journal/agent.md` as a candidate line for the next morning routine to confirm — do **not** write directly to `plans/roadmap.md` without a clear positive signal.
 
 {include:_partials/dm-intent.long-horizon.md}
 

package/agent-assets/task-flows/routine.custom.md

@@ -3,7 +3,7 @@
 ## Custom Routine
 
 This is a user-defined recurring check fired from a cron schedule. The
-primary-vault file `routines/custom/<slug>.md` (injected above under
+primary-vault file `policies/routines/custom/<slug>.md` (injected above under
 "Vault policy files") contains your canonical check list and the reason
 it exists.
 
@@ -17,7 +17,7 @@ it exists.
    `max_budget_usd` and `backend_tier`; stop early rather than exceed
    either.
 4. For each action, use the same conventions as the other routines:
-   - Scheduled actions → append to `today.md` `## Agent Plan` and
+   - Scheduled actions → append to `state/today.md` `## Agent Plan` and
      register a matching `POST /api/schedule` row. Use `tier` for the
      row's cost knob; check `GET /api/schedule/options` for the live
      model list when a step needs to pin a specific model id.
@@ -25,7 +25,7 @@ it exists.
      truly urgent. Silent is the default.
    - Observations → consume via `observations` skill if the step pulls
      from pending observations.
-5. When all checks complete, append ONE line to `agent/journal.md`
+5. When all checks complete, append ONE line to `journal/agent.md`
    summarising what ran:
    `- HH:MM [routine.custom.<slug>] ran N checks, skipped M (<reasons>)`.
 

package/agent-assets/task-flows/routine.evening_review.md

@@ -3,12 +3,12 @@
 ## Task: Evening Review
 
 The "Vault policy files" block appended to this prompt includes
-`routines/evening.md` — run any `### <label>` entries there alongside the
+`policies/routines/evening.md` — run any `### <label>` entries there alongside the
 built-in review steps below, using the same journaling conventions.
 The "Vault review context" block includes `context-index.md` and
-`dossiers/evening.md`; consult it before Step 1 and update the
+`knowledge/dossiers/evening.md`; consult it before Step 1 and update the
 dossier's Open items / Last run before finishing. Writes to
-`dossiers/<flow>.md` MUST preserve the existing YAML frontmatter block
+`knowledge/dossiers/<flow>.md` MUST preserve the existing YAML frontmatter block
 (`---\ntype: dossier\nowner: agent\nupdated: <date>\n---`); prefer
 `PATCH` with a section target to mutate a single block, and when doing
 a `PUT` full rewrite keep the frontmatter and only refresh `updated:`
@@ -16,7 +16,7 @@ a `PUT` full rewrite keep the frontmatter and only refresh `updated:`
 
 Close out today and prepare tomorrow. Steps 1–3 are internal bookkeeping
 (Morning Routine depends on them) and emit no user-facing output by default.
-User-defined entries in `routines/evening.md` run alongside the built-in
+User-defined entries in `policies/routines/evening.md` run alongside the built-in
 steps and are authoritative: execute them as written, including any that
 call `POST /api/notify` — the built-in steps' silence does not override the
 user's explicit rulebook intent. For ad-hoc deadline or surprise nudges,
@@ -126,7 +126,7 @@ PATCH:
        `section=long_term_plans` `mode=replace`.
     3. Otherwise, bump `Review:` forward by the class review interval:
        previous Review +30 days by default, or +90 days for `undated`;
-       increment `ReviewCount:` and log one line to `agent/journal.md`.
+       increment `ReviewCount:` and log one line to `journal/agent.md`.
     4. For `undated` lines reaching `ReviewCount: 3` with no
        promotion, silently rewrite `Review:` to `[noreview]`. Do NOT
        DM.
@@ -140,7 +140,7 @@ PATCH:
     roadmap.md, rebuild from that current body, and retry once while
     preserving every existing `completed ...` row byte-for-byte. If
     the retry still fails, stop Step 2, append the validation error and
-    affected IDs to `agent/journal.md`, and stay silent.
+    affected IDs to `journal/agent.md`, and stay silent.
 
 ### Step 3 — Process user/profile.md and user/ per the user-profile skill
    Read <user> ## Raw Signals and classify each entry into one of four buckets.
@@ -179,7 +179,7 @@ PATCH:
       referenced, a lifestyle habit stated, a long-term goal declared, a
       specific framework with years of experience — → graduate into the
       matching user/*.md file via PATCH. The routing table lives in
-      the user-profile skill "user/profile.md vs user/" section; the curl
+      the user-profile skill "identity/profile.md vs user/" section; the curl
       recipe for read-before-write is under "How to navigate user/".
       Always read the target file first, check for duplicates, then PATCH
       (prefer `mode: "append"` for new bullets — it preserves siblings).
@@ -204,7 +204,7 @@ PATCH:
       mode to remove only those entries, preserving any signals that
       SignalDetector appended after your read:
       ```bash
-      curl -s -X PATCH http://localhost:8321/api/context/user/profile \
+      curl -s -X PATCH http://localhost:8321/api/context/identity/profile \
         -H 'Content-Type: application/json' \
         -d '{"section": "raw_signals", "mode": "clear_before", "cutoff": "<latest_processed_timestamp>"}'
       ```
@@ -224,3 +224,83 @@ PATCH:
       Learned Context entries out to the matching user/*.md file and
       remove them from user/profile.md so the primary profile stays compact.
 
+### Step 4 — Consolidate feedback signals into lessons
+
+If a `<feedback_worksheet>` block is present in your context, fold the
+unconsumed feedback signals it lists into the scoped lesson stores. The daemon
+already did the mechanical work: every candidate carries a deterministic
+`decision`, `conf`, `weighted_ev`, and `reason`; every existing lesson carries a
+`rank` (rank 1 = lowest score = evict first); and the block ends with the exact
+`<consume ids="…">` set. Your job is only the **semantic** part — judge whether a
+candidate matches an existing lesson's intent, phrase the generalization, and
+detect contradictions. Do **not** recompute promotion or caps; honour the
+worksheet's `decision` and `rank` verbatim. If the block is absent, skip this
+step entirely. Like Steps 1–3 it is internal bookkeeping and emits no
+user-facing output.
+
+4a. **Lesson-store scopes** — process **every** `<scope … mode="lessons">` in the
+    worksheet, writing each to the `store=` path it declares: the global `agent`
+    scope (`store="policies/agent-lessons.md"`) and any per-agent
+    `agent:<slug>` scope (`store="policies/agents/<slug>/lessons.md"` — feedback
+    on one named agent's own output, injected only into that agent's runs). The
+    per-candidate rules below are identical for each; only the target file and
+    its H1 change. GET the scope's `store=` file first. If it 404s, PUT a fresh
+    file: frontmatter `type: rule` / `owner: agent` / `updated: <agent_day_date>`,
+    an H1 (`# Agent Lessons` for the global `agent` scope; `# Agent Lessons —
+    <label>` for an `agent:<slug>` scope, e.g. `# Agent Lessons — agent:report-writer`),
+    then a `## Lessons` section. Then, per candidate in that scope:
+    - `decision="promote"` → find an existing `## Lessons` bullet with the same
+      intent. If found, bump its `ev=` by `weighted_ev` (rounded to a whole
+      number), refresh `last=` to today, raise `conf`, and tighten the wording.
+      If not, add a new **active** bullet:
+      `- [<today>] <directive> <!-- ev=<round(weighted_ev), min 1> kind=<kind> src=<src> conf=<conf> last=<today> -->`
+      (`src`/`conf` come from the candidate; use the candidate's `kind=` when
+      present, otherwise infer it from the directive; `kind` ∈
+      preference|correction|do-more|do-less|constraint).
+    - `decision="hold-provisional"` with `reason="below-threshold"` → if it
+      matches an existing lesson's intent, bump that lesson's `ev`; otherwise add
+      the bullet with a trailing `<!-- provisional -->` marker (stored, not yet
+      injected — it promotes once corroboration reaches the threshold).
+    - `decision="hold-provisional"` with `reason="ignored-non-initiating"` →
+      silence never *starts* a lesson. Only use it to bump the `ev` of an
+      existing matching lesson; if none matches, write nothing for it.
+    - A newer `correction` that contradicts an active lesson **supersedes** it:
+      drop the stale bullet in the same rebuild so a changed mind leaves no
+      stale guidance.
+    - **Staleness prune** (§4 step 7): drop any existing lesson the worksheet
+      marks `stale="true"` (its `last=` is past the staleness horizon and it is
+      not a `constraint`) unless a fresh candidate re-reinforces it this pass —
+      a `constraint` is durable and is never stale-pruned.
+    Write the scope's section back with `PATCH <store= path> section=lessons
+    mode=replace`, applying the Step-2 section-body-rebuild discipline (GET fresh,
+    write the keep-list down first, byte-for-byte for unchanged bullets). Repeat
+    for each `mode="lessons"` scope; a write failure on one scope must not block
+    the others (omit only the failed scope's ids from the consume call, 4d).
+
+4b. **Cap enforcement.** After your edits to each scope, if its `## Lessons`
+    section exceeds that scope's `cap_bytes` or `max_entries`, remove existing
+    lessons starting from `rank="1"` (the worksheet's lowest-scored) upward until
+    it fits, then append exactly one marker line:
+    `- [...N lower-signal lessons omitted — full history in feedback_signals]`.
+    Never evict a `kind=constraint` lesson — drop the next-lowest instead.
+
+4c. **User-scope signals** (`<scope label="user" … mode="raw">`). These are
+    explicit owner directives captured via `POST /api/feedback`, *not* Raw
+    Signals. Route each into `## Learned Context` (or the matching
+    `identity/*.md` file) using the same bucket rules as Step 3 (a₂ / b),
+    respecting the ~600-token profile budget. Do not double-write a signal you
+    already folded from Raw Signals.
+
+4d. **Consume.** Once every scope above is written, mark the processed signals
+    consumed so they don't resurface tomorrow — send the worksheet's full
+    `<consume>` id list:
+    ```bash
+    curl -s -X POST http://localhost:8321/api/feedback/consume \
+      -H 'Content-Type: application/json' \
+      -d '{"ids": [<the ids from <consume ids="…"/>>]}'
+    ```
+    Consume is by id and race-safe: any signal the detector appended after the
+    worksheet was built has a higher id absent from the list and survives
+    untouched for tomorrow's pass. If a lesson write failed, omit that scope's
+    ids from the consume call so its signals are retried next Evening Review.
+

package/agent-assets/task-flows/routine.fetch_window.md

@@ -108,6 +108,6 @@ of the plan produced.
   loop over items in a shell `for`. Do NOT chain multiple curl
   invocations. Those shapes are blocked by the daemon's Bash hooks
   (one curl per Bash call, heredoc bodies are stripped from URL
-  validation). One window → one curl → one JSON body whose
+  validation). One window → one submit → one JSON body whose
   `observations[]` array carries every fetched item (up to 200; split
-  larger windows into multiple POSTs).
+  larger windows into multiple `submit_observations` / POST calls).

package/agent-assets/task-flows/routine.hourly_check.md

@@ -4,17 +4,16 @@
 
 This task-flow is the **daemon-internal** hourly cron — a built-in
 observation review the dispatcher fires every hour. It is NOT the
-user-facing hourly recurring schedule path. Operators who want to
-register a custom hourly task should POST to
-`/api/recurring-schedules` with `recurrenceRule.frequency:"hourly"`
-(see the `schedule` skill's `references/recurring.md`); those rows
-fire `scheduled.task` / `scheduled.dm` events instead.
+user-facing recurring path. An operator who wants a custom recurring
+task creates a recurring **Agent** (`POST /api/agents`, e.g. an hourly
+cron `0 * * * *`); those fire `scheduled.task` / `scheduled.dm` events
+instead.
 
 The "Vault policy files" block appended to this prompt includes
-`routines/hourly.md` — your canonical check list for this cadence.
+`policies/routines/hourly.md` — your canonical check list for this cadence.
 The "Vault review context" block includes `context-index.md` and
-`dossiers/hourly.md`; consult it before Step 1 and update the dossier's
-Open items / Last run before finishing. Writes to `dossiers/<flow>.md`
+`knowledge/dossiers/hourly.md`; consult it before Step 1 and update the dossier's
+Open items / Last run before finishing. Writes to `knowledge/dossiers/<flow>.md`
 MUST preserve the existing YAML frontmatter block (`---\ntype: dossier\nowner: agent\nupdated: <date>\n---`); prefer `PATCH` with a
 section target to mutate a single block, and when doing a `PUT` full
 rewrite keep the frontmatter and only refresh `updated:` — writes that
@@ -27,7 +26,7 @@ routing rules.
 
 Output language: follow `<output_language_policy>` (Policy B for any
 context-MD write-up; Policy C for the optional `POST /api/notify` DM).
-Agent log appends to `agent/journal.md` stay English (Policy A).
+Agent log appends to `journal/agent.md` stay English (Policy A).
 
 Use the observations skill to fetch pending items. The pre-pass
 fetcher session (`routine.fetch_window`) ran ahead of you and posted
@@ -135,7 +134,7 @@ This routine reads external state for context — it does not push back. While r
 - Create / update / delete calendar events.
 - Open / merge / comment on GitHub PRs or issues.
 
-External-source signals (`mail:*`, `notion:*`, `calendar:*`, `git:*`) reach you through `<observations>`. Consume them, route to `today.md` / `projects/*.md` / the `roadmap_candidate` queue per the Decision Framework below, but do **not** act back on the source system. Outbound writes against external services belong in the morning routine, evening review, or DM-reply paths — `routine.hourly_check` is a silent bookkeeping pass.
+External-source signals (`mail:*`, `notion:*`, `calendar:*`, `git:*`) reach you through `<observations>`. Consume them, route to `state/today.md` / `projects/*.md` / the `roadmap_candidate` queue per the Decision Framework below, but do **not** act back on the source system. Outbound writes against external services belong in the morning routine, evening review, or DM-reply paths — `routine.hourly_check` is a silent bookkeeping pass.
 
 This rule applies regardless of integration mode (direct, same-backend delegated, cross-backend delegated). It is owned by the routine, so a session whose `notion` / `mail` / `external-services` skill body was dropped under same-backend delegation (because the connector covers the surface) still inherits the constraint.
 
@@ -190,6 +189,11 @@ This rule applies regardless of integration mode (direct, same-backend delegated
 6. Skip noise: journal-only edits, trivial formatting, auto-generated churn,
    already-processed agent writes, deletion of auto-generated artifacts.
 7. Mark processed observations consumed via POST /api/observations/consume.
+   Shape: `{"ids":[<int>...],"correlationId":"<verbatim from <event_correlation_id>>"}`.
+   Both fields are required and camelCase — `correlation_id` snake_case is
+   rejected. `ids` must be integers (not strings). Copy `correlationId`
+   verbatim from the `<event_correlation_id>…</event_correlation_id>` tag
+   in this prompt; do not paste the angle-bracket placeholder.
 8. Urgency gate for POST /api/notify — the default is SILENCE. At most
    ONE call per run, and only after the dedup pre-check passes AND one
    of (a)(b)(c) holds with its concrete threshold:
@@ -200,7 +204,7 @@ This rule applies regardless of integration mode (direct, same-backend delegated
      last 4 hours.
    - The truncation marker `[...N earlier entries omitted ...]` appears
      in `<today>` and you cannot rule out a same-day prior notification
-     from the truncated view. In that case `GET /api/context/today`
+     from the truncated view. In that case `GET /api/context/state/today`
      once for the full log before deciding.
    - A matching pending `POST /api/schedule/dm` or Agent Plan row is
      already going to fire for this item within the next 2 hours
@@ -210,7 +214,7 @@ This rule applies regardless of integration mode (direct, same-backend delegated
    (a) Hard deadline ≤ 2 hours away that the agent surfaced **this
        hour** from new input (mail, DM, observation) AND the user has
        not yet acted on it. **Self-set deadlines, course assignments,
-       class times, and items already in `today.md` ## User Tasks do
+       class times, and items already in `state/today.md` ## User Tasks do
        NOT qualify** — they fail the awareness gate (see notify skill
        § Universal user-facing message discipline § Awareness gate).
        A 6-hour deadline is NOT urgent regardless.

package/agent-assets/task-flows/routine.monthly_review.md

@@ -45,12 +45,12 @@
 ## Task: Monthly Review
 
 The "Vault policy files" block appended to this prompt includes
-`routines/monthly.md` — run any `### <label>` entries there alongside the
+`policies/routines/monthly.md` — run any `### <label>` entries there alongside the
 built-in review phases below, using the same journaling conventions.
 The "Vault review context" block includes `context-index.md` and
-`dossiers/monthly.md`; consult it during Phase 1 and update the
+`knowledge/dossiers/monthly.md`; consult it during Phase 1 and update the
 dossier's Open items / Last run before finishing. Writes to
-`dossiers/<flow>.md` MUST preserve the existing YAML frontmatter block
+`knowledge/dossiers/<flow>.md` MUST preserve the existing YAML frontmatter block
 (`---\ntype: dossier\nowner: agent\nupdated: <date>\n---`); prefer
 `PATCH` with a section target to mutate a single block, and when doing
 a `PUT` full rewrite keep the frontmatter and only refresh `updated:`
@@ -59,9 +59,9 @@ a `PUT` full rewrite keep the frontmatter and only refresh `updated:`
 Generate the monthly review snapshot for the current month and set up the next month.
 
 This routine produces **two separate artifacts** with strict audience boundaries:
-  - **User-facing**: `monthly/YYYY-MM.md` + (optionally) a short notification.
+  - **User-facing**: `journal/monthly/YYYY-MM.md` + (optionally) a short notification.
     Only real user work, wins, and next-month focus. No agent mechanics.
-  - **Agent-internal**: `agent/journal.md` (append). Monthly self-critique,
+  - **Agent-internal**: `journal/agent.md` (append). Monthly self-critique,
     recurring filter/schedule failures, cross-week patterns in the agent's
     own behavior, and concrete system improvement proposals. **Never**
     surfaced to the user via notify.
@@ -71,7 +71,7 @@ workflow; the skill owns the file contract.
 
 ### Phase 1: Gather the month
 1. Determine the target file name from <current_time>:
-   `monthly/YYYY-MM.md`.
+   `journal/monthly/YYYY-MM.md`.
 
 **Pre-pass acquisition (none).** Unlike morning / hourly / today_refresh /
 evening / weekly, monthly_review does NOT trigger an `<acquisition-plan>`
@@ -85,13 +85,13 @@ state rather than fetching fresh windows. If the dispatcher emitted any
 continue.
 2. Fetch source material for the current month:
    - Use GET /api/context/list/daily to discover archived daily files and
-     read each `daily/YYYY-MM-DD.md` in the current month.
+     read each `journal/daily/YYYY-MM-DD.md` in the current month.
    - Use GET /api/context/list/weekly to read weekly reviews that overlap this month.
-   - Read the last ~4 weekly sections of `agent/journal.md` via GET — they
+   - Read the last ~4 weekly sections of `journal/agent.md` via GET — they
      accumulate the agent-internal bucket across the month and are the basis
      for Phase 3b's monthly retrospective.
    - Also locate the **previous month's** `## Monthly YYYY-MM` section in
-     `agent/journal.md`. Extract its `### Proposed adjustments` bullets —
+     `journal/agent.md`. Extract its `### Proposed adjustments` bullets —
      these are the improvement proposals you committed to last month. You
      will evaluate their status in Phase 3b.
    - Include <today> if it belongs to the same month.
@@ -114,13 +114,13 @@ continue.
 
 ### Phase 2: Synthesize — split into two buckets
 5. Build TWO separate mental lists before writing anything:
-   a. **User-facing bucket** (goes to `monthly/YYYY-MM.md` and possibly notify):
+   a. **User-facing bucket** (goes to `journal/monthly/YYYY-MM.md` and possibly notify):
       - What meaningful user progress happened this month?
       - Which user commitments slipped or stayed open, and why (in terms the
         user cares about, not agent mechanics)?
       - What user-side risks or workload patterns carry into next month?
       - What should the user prioritize next month?
-   b. **Agent-internal bucket** (goes to `agent/journal.md` only):
+   b. **Agent-internal bucket** (goes to `journal/agent.md` only):
       - Cross-week patterns in scheduled-task failures / did-not-fire
       - Filter and prioritization failures the agent noticed about itself
       - Notification discipline: over-notify / under-notify patterns
@@ -133,7 +133,7 @@ continue.
    own performance or reliability.
 
 ### Phase 3a: Write the user-facing review
-7. PUT the review to `monthly/YYYY-MM.md`.
+7. PUT the review to `journal/monthly/YYYY-MM.md`.
    Required structure (user outcomes only — no agent mechanics in any section):
    ```
    ---
@@ -177,15 +177,15 @@ continue.
    ```
    The `## Metrics` section tracks **user** activity only. Do not add rows
    like "agent plan rows completed", "scheduled tasks fired", "observations
-   processed" — those belong in agent/journal.md.
+   processed" — those belong in journal/agent.md.
 
    Skip the `## Reading` section entirely if the user imported zero books
    and has zero completions this month — an empty reading block is noise.
 8. Update roadmap.md and relevant projects/*.md when the review shows
    milestone drift, completed phases, or a changed next-month focus.
 
-### Phase 3b: Append to agent/journal.md (internal)
-9. PATCH-append a monthly retrospective block to `agent/journal.md` via
+### Phase 3b: Append to journal/agent.md (internal)
+9. PATCH-append a monthly retrospective block to `journal/agent.md` via
    `mode: "append_to_file"` (no `section` param needed — content is
    appended to the end of the file). This is the cross-week synthesis of
    the weekly sections that accumulated during the month.
@@ -236,7 +236,28 @@ continue.
    cross-week frequency and drop the rest. Single-week anomalies are already
    in that week's journal entry and do not need re-listing.
 
-   If `agent/journal.md` does not yet exist, PUT a minimal file with
+   For each concrete, actionable bullet in `### Proposed adjustments`, also
+   record a structured self-critique signal:
+
+   ```
+   POST /api/feedback
+   {
+     "source": "self_critique",
+     "summary": "<the specific testable adjustment, max 280 chars>",
+     "valence": "neutral",
+     "kind": "do-more",
+     "scope_type": "agent",
+     "action_kind": "agent_execution",
+     "evidence": { "excerpt": "monthly_review YYYY-MM proposed adjustment" }
+   }
+   ```
+
+   Post only concrete proposed adjustments. Do not post every retrospective
+   sentence, metrics row, or vague wish. If an adjustment is clearly about one
+   named Agent Definition's output, use `scope_type: "agent_slug"` and
+   `scope_ref` with that slug; otherwise keep `scope_type: "agent"`.
+
+   If `journal/agent.md` does not yet exist, PUT a minimal file with
    `# Agent Journal\n\n` header plus this section, in a single call.
 
    **Idempotency note**: if a `## Monthly YYYY-MM` section for the current
@@ -244,9 +265,60 @@ continue.
    rollup collapses duplicate keys last-write-wins, so your newer append
    automatically supersedes the earlier one within 24 hours.
 
+### Phase 3c: Re-generalize feedback lessons (internal)
+
+If a `<feedback_regeneralization>` block is present in your context, collapse
+accumulated specific lessons into a smaller set of higher-level principles. This
+is the monthly counterpart to the Evening Review's signal-folding: it processes
+**no new signals and consumes nothing** — it only re-reads the already-consolidated
+lesson stores the block lists and rewrites them. The daemon already did the
+mechanical work: every `<scope>` carries its `store=` path and caps, and every
+`<lesson>` carries a `rank` (rank 1 = lowest eviction score = drop-first), its
+`ev`/`kind`/`last`, and a `stale="true"` flag when it is past the staleness
+horizon. Your job is the **semantic** part — cluster lessons that share a theme
+and phrase the generalization. If the block is absent, skip this phase entirely.
+Like Phase 3b it is internal bookkeeping and emits no user-facing output.
+
+For **each** `<scope … >` in the block, writing back to the `store=` path it
+declares (`policies/agent-lessons.md` for the global `agent` scope;
+`policies/agents/<slug>/lessons.md` for a per-agent `agent:<slug>` scope):
+
+11. GET the scope's `store=` file. Identify clusters of two or more lessons that
+    express the same underlying preference at different surfaces — e.g.
+    "shorter mail summary", "shorter standup", "shorter report" all express
+    "default to terse output". For each cluster:
+    - Replace its members with **one** higher-level bullet that captures the
+      shared principle:
+      `- [<today>] <generalized directive> <!-- ev=<sum of the cluster's ev, min 1> kind=<the cluster's strongest kind> src=<strongest src> conf=<high if any member was high, else medium> last=<today> -->`
+      (summing `ev` keeps the merged lesson harder to evict — never re-derive it lower).
+    - Leave a lesson that belongs to no cluster untouched, byte-for-byte.
+    - **Never collapse, merge, or promote a `<!-- provisional -->` lesson.** The
+      worksheet block lists only active (promoted) lessons; the file also holds
+      provisional lessons awaiting corroboration, which the nightly evening pass
+      alone may promote. Preserve every provisional lesson in the file exactly as
+      it is — re-generalization is not a promotion path.
+    - **Do not** collapse across a contradiction: if two lessons give opposing
+      guidance, keep them separate and prefer the one with the more recent `last=`;
+      drop the stale opposite only when a `correction` superseded it.
+    - Drop any lesson the block marks `stale="true"` unless it joins a cluster —
+      a `kind=constraint` lesson is durable and is never collapsed away or
+      stale-pruned.
+    Re-generalization should make each store **smaller**, not larger; if a scope
+    has no genuine clusters, leave it unchanged.
+12. After your edits, if the section still exceeds the scope's `cap_bytes` or
+    `max_entries`, remove existing lessons starting from `rank="1"` upward until
+    it fits, then append exactly one marker line:
+    `- [...N lower-signal lessons omitted — full history in feedback_signals]`.
+    Never evict a `kind=constraint` lesson.
+    Write the scope's section back with `PATCH <store= path> section=lessons
+    mode=replace`, applying the same GET-fresh / write-the-keep-list discipline
+    Phase 3a uses. A write failure on one scope must not block the others or any
+    later phase. There is **no consume call** in this phase — re-generalization
+    rewrites lessons in place and touches no `feedback_signals` rows.
+
 ### Phase 4: Notify (user-facing only)
 10. The notification is for the USER, not a report of Phases 1–3. Never
-   mention monthly/YYYY-MM.md, agent/journal.md, "Monthly Review complete",
+   mention journal/monthly/YYYY-MM.md, journal/agent.md, "Monthly Review complete",
    agent plan rows, did-not-fire, filter quality, observation processing,
    or any other internal mechanism.
 
@@ -259,8 +331,8 @@ hold:
     it in the first morning briefing of the new month anyway)
   - No hard deadline within the next 30 days that is slipping
 When the gate triggers: skip POST /api/notify entirely. The
-monthly/YYYY-MM.md file is still written. Also log one line in the current
-weekly section of agent/journal.md: `silent monthly wrap-up — nothing
+journal/monthly/YYYY-MM.md file is still written. Also log one line in the current
+weekly section of journal/agent.md: `silent monthly wrap-up — nothing
 actionable`.
 
 #### 4b. When you DO notify — content rules
@@ -292,7 +364,7 @@ Good (something worth saying):
     Next month's focus: Phase 2 foundation + the Q2 roadmap refresh.
 
 Good (silent path — nothing is sent):
-    (no POST /api/notify call; one-line note appended to agent/journal.md)
+    (no POST /api/notify call; one-line note appended to journal/agent.md)
 
 Bad (this is the failure mode this prompt exists to prevent):
     Monthly Review YYYY-MM complete. Wrote monthly/2026-04.md. Metrics:
@@ -300,4 +372,4 @@ Bad (this is the failure mode this prompt exists to prevent):
     processed 82. System improvement ideas logged. Review notification sent.
 
 The bad example reports the agent's bookkeeping. Everything in it either
-belongs in agent/journal.md or was never worth telling the user.
+belongs in journal/agent.md or was never worth telling the user.