@aitne-sh/aitne 0.1.11 → 0.1.13

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

@@ -23,6 +23,32 @@ user's explicit rulebook intent. For ad-hoc deadline or surprise nudges,
 the surfacing event handler that discovered the item — not this routine —
 is the right vehicle.
 
+**Session constraints & turn economy** (apply at every step):
+- This session has **no calendar or external-connector access**.
+  "Prepare tomorrow" means updating the `state/today.md` ## Handoff
+  `### Tomorrow` section in Step 1 — that is the entire contract. Do
+  NOT attempt a calendar or observations "tomorrow preview"; no tool
+  in this session can serve it, and probing for one wastes a turn.
+  If Handoff needs upcoming-event context, the injected
+  `<calendar_events_3d>` block already carries the coming days'
+  events — read it directly.
+- Operate in as few turns as possible: consolidate tool calls, do not
+  narrate routine actions, and never re-derive facts already in your
+  context. Issue independent read-only GETs (e.g. the Step 0
+  observations drain) together in a single turn as parallel tool
+  calls. The one exception is rebuild discipline: a GET that feeds a
+  `mode=replace` PATCH (e.g. the Step 4 lesson-store reads) must be
+  fresh — keep it adjacent to its write, never batched up front.
+- Injected context blocks (`<roadmap>`, `<today>`, `<user>`,
+  `<feedback_worksheet>`, …) are already in your prompt — never GET a
+  file merely to read what is injected. GET fresh only immediately
+  before a rebuild-and-replace write.
+- Prose writes to `journal/agent.md` use
+  `PATCH /api/context/journal/agent` with the body
+  `{"mode":"append_to_file","content":"..."}` — `append_to_file`
+  appends at end-of-file and takes **no** `section` field
+  (`mode:"append"` without a `section` is rejected with 400).
+
 ### Step 0 — Read today's mail outcomes
 
 The pre-pass fetcher session (`routine.fetch_window`) ran ahead of you
@@ -74,6 +100,16 @@ are NOT this routine's job anymore. This step only carries the two
 substeps that genuinely need an LLM in the loop: promote-on-resolution
 and Review-date fire.
 
+**Skip-gate (check the injected roadmap before locking).** Read
+`## Long-term Plans` from the `<roadmap>` block already in your
+prompt (it is injected verbatim). If it is empty, or it has no entry
+that resolved to a concrete date today (2a) and no entry whose
+`Review:` date is on or before today (2b, ignoring
+`Review: [noreview]`), skip Step 2 entirely — do NOT acquire the
+lock and do NOT GET the roadmap. An entry added mid-evening simply
+waits for tomorrow's review — the same 24-hour tolerance the
+409-conflict path below already accepts.
+
 **Write-lock handling.** `<roadmap_write_lock_id>` is NOT injected for
 evening_review, so acquire the lock explicitly before the first PATCH:
 `POST /api/context/lock/roadmap` → read back `lockId`. On 409 (a
@@ -238,6 +274,13 @@ 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.
 
+When the worksheet carries an `<outcome_rollup>` block (per-notification-type
+reaction counts over the last week), weigh it while judging promotions and
+demotions: a high `correction_rate` on an action type argues for demoting
+lessons that push that behaviour and supports candidates that curb it. Never
+treat `ignored` as rejection — it is engagement-coverage only — and never
+reward sheer notification volume.
+
 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
@@ -253,24 +296,42 @@ user-facing output.
       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).
+      `- [<today>] <directive> <!-- ev=<round(weighted_ev), min 1> kind=<kind> src=<src> conf=<conf> cf=<cf0> last=<today> -->`
+      (`src`/`conf` come from the candidate; `cf=` copies the candidate's
+      `cf0=` for a new bullet or the existing lesson's `cf=` verbatim — never
+      invent a value, the daemon re-stamps it deterministically after your
+      write; use the candidate's `kind=` when present, otherwise infer it from
+      the directive; `kind` ∈ preference|correction|do-more|do-less|constraint).
+    - `decision="promote"` with a `contradicts_ranks=` attribute → the candidate
+      cleared the anti-whiplash bar against the lessons at those ranks.
+      Adjudicate: **supersede** (mark each contradicted lesson provisional and
+      promote the candidate), **merge** (rewrite one bullet to cover both,
+      drop the other), or **keep-distinct** (the conflict is context-scoped —
+      keep both, scoping each bullet's wording so they cannot collide).
     - `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-contradiction"` → the candidate contradicts an
+      established lesson (see `contradicts_ranks=`) and has NOT yet cleared the
+      higher evidence bar. Store it as a provisional bullet; do **not**
+      supersede, weaken, or reword the lessons it contradicts.
     - `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.
+    - A newer explicit `correction` that contradicts an active lesson
+      **supersedes** it: drop the stale bullet in the same rebuild so a changed
+      mind leaves no stale guidance (a user correction always wins — the
+      contradiction guard applies only to inferred candidates).
+    - **Expiration verdicts** (graduated, reversible): honour each existing
+      lesson's `action=` attribute verbatim — `action="demote"` → append
+      `<!-- provisional -->` to the bullet unless a fresh candidate
+      re-reinforces it this pass; `action="archive"` → drop the bullet (its raw
+      evidence stays in feedback_signals); a re-reinforced provisional lesson
+      whose bumped `ev` now meets the threshold → remove its provisional
+      marker. `action="keep"` (and every `constraint`) stays untouched. The
+      daemon enforces the same verdicts mechanically after your write, so a
+      missed one self-corrects.
     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

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

@@ -50,6 +50,27 @@ terminate.
 
 {integration_partial}
 
+### Turn efficiency
+
+This sub-session runs under a hard `max_turns` cap — every model turn is one
+round-trip, and a run that wanders past the cap is killed mid-fetch, so its
+window is retried from scratch. Collapse the work into as few turns as you can:
+
+- **Load tool schemas in ONE `ToolSearch` call.** On a Claude backend the
+  connector tools this integration uses are deferred, so their schemas must be
+  loaded before the first call. Load every schema you need in a single
+  `ToolSearch` (its `select:` query accepts a comma-separated list); never spend
+  one `ToolSearch` turn per tool.
+- **Issue independent fetches together in one turn.** When `<acquisition-plan>`
+  carries several `<fetch>` rows (multiple windows or accounts), emit their
+  independent read calls in the SAME turn instead of one-per-turn — the rows do
+  not depend on each other, so serialising them only burns turns.
+- **Never fetch per-item detail.** The search/list response already carries the
+  compact subset you submit (see the partial's `raw` shape). Do NOT make a
+  follow-up per-item call (`get_thread`, `get_event`, a per-message body fetch,
+  …) for data the list response already returned — that is one wasted turn per
+  item. Submit straight from the list response.
+
 ### Step 2 — Emit a single JSON line and terminate
 
 After every row has been processed (success, duplicate, or recorded

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

@@ -291,7 +291,9 @@ declares (`policies/agent-lessons.md` for the global `agent` scope;
     - 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).
+      (summing `ev` keeps the merged lesson harder to evict — never re-derive it
+      lower; omit `cf=` on a merged bullet — the daemon stamps it
+      deterministically after your write).
     - 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

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

@@ -41,6 +41,22 @@ Global rules (apply at every step):
   `daily/*.md` file from this session — Step 5 is delegated. The
   daemon's parent audit row gates on YOUR success + today.md health,
   so a Stage B failure does not stop the day from "opening".
+- Turn economy: operate in as few turns as possible. Consolidate tool
+  calls, do not narrate routine actions, and never re-derive facts
+  already in context. The independent read-only GETs — Step 2a mail,
+  Step 2b notion, the Step 2c non-direct calendar observations read,
+  Step 3 `actor=user`, Step 4 inbox list — MUST be issued together in
+  **one turn** as parallel tool calls; only a GET that immediately
+  precedes a `mode=replace` PATCH (rebuild discipline) needs to stay
+  adjacent to its write.
+- Injected blocks (`<yesterday>`, `<calendar_events_7d>`,
+  `<fetch_report>`, `<handoff_parsed>`, `<user>`, …) are already in
+  your prompt — never GET a file merely to read what is injected; GET
+  fresh only immediately before a rebuild-and-replace write.
+- curl rules: always double-quote URLs containing `&` (an unquoted
+  `&` backgrounds the command mid-URL), and never pass
+  `-w`/`--write-out` (the shell hook rejects it) — plain `curl -s`
+  output is sufficient.
 
 ### Step 1 — Read handoff and derive day-type
 
@@ -467,7 +483,8 @@ Global rules (apply at every step):
 
     Skip this step on recurring days — the row already exists.
 
-    a. **Pre-flight.** `GET /api/recurring-schedules?enabled=true`
+    a. **Pre-flight.** `GET
+       /api/recurring-schedules?enabled=true&includeClaimed=true`
        and scan for an item with `taskType === "dm_session"` AND
        `taskContext.sub_flow === "morning_briefing"`. If found, skip
        the rest of this step — duplicate insertion would cause
@@ -661,12 +678,14 @@ the morning routine.
     need a flag in metadata.
 
     If the PATCH returns `agent_actions.session_row_not_found`
-    (404), the dispatcher has not pre-inserted your in-flight row —
-    surface a one-line warning to `## Agent Log`
-    (`- HH:MM [morning_routine] agent-self self-report 404 — no in-flight row`)
-    and continue. Do NOT block the turn on telemetry, and do NOT
-    fall back to writing `journal/agent.md` directly (the daemon
-    owns that file in V2; a direct write would race).
+    (404) — the dispatcher has not pre-inserted your in-flight row —
+    or any other 4xx, surface a one-line warning to `## Agent Log`
+    (`- HH:MM [morning_routine] agent-self self-report <status> — <code>`)
+    and continue. Telemetry is best-effort: do NOT block the turn on
+    it, do NOT spend turns debugging headers or environment
+    variables, and do NOT fall back to writing `journal/agent.md`
+    directly (the daemon owns that file in V2; a direct write would
+    race).
 
     <output_language>english_only — Policy A surface (agent journal,
     parsed log); `<output_language_policy>` carves this out

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

@@ -0,0 +1,50 @@
+{context}
+
+## Task: Source Library Maintenance
+
+You are the source librarian. Documents the user sends over chat (PDF, PPTX, DOCX, XLSX, ODT) are captured automatically into a durable library; most weeks a few of them sit `unfiled`. Your job: file them as cards under `knowledge/sources/`, keep the collection taxonomy healthy, and repair any library↔vault drift. The `sources` skill carries the API surface, the current taxonomy, and the filing conventions — follow it for every call shape.
+
+The scheduler only fires this routine when its prefilter found work; the event data carries `unfiledCount`, `inconsistencyCount`, and `driftSignalCount` so you know which phases matter this run.
+
+### Phase 1: Triage unfiled sources
+
+1. `GET /api/sources?status=unfiled` and read `knowledge/sources/_index.md` for the current collections.
+2. For each unfiled source, decide from `originalFilename` + `caption` + provenance what it is. Fetch the bytes into the workdir only when the metadata is genuinely insufficient (PDFs are directly readable with the Read tool; for PPTX/DOCX use the `unzip -p` text peek from the skill).
+3. File it per the skill's taxonomy and conventions: write the card (PUT), bind it (`PATCH /api/sources/<id>` with `cardPath`), and add the `## Sources` cross-link in the matching `plans/projects/<slug>.md` when a project applies.
+4. Junk or duplicates (`receive_count` > 1 with an existing card): `PATCH {"status":"archived"}` instead of writing a card. Never DELETE.
+5. Update `knowledge/sources/_index.md` when collections were added or their scope shifted.
+
+### Phase 2: Taxonomy review
+
+Look at the collection shapes, not just this week's arrivals:
+
+- **Singletons**: a collection with one card that fits an existing broader collection → move the card (PUT new path, DELETE old, PATCH `cardPath`).
+- **Overloaded**: a collection past ~15 cards with visible sub-themes → split it.
+- Keep moves small this run (≤ ~10 card moves). For a larger restructuring, delegate instead of doing it inline: compose a self-contained brief (current tree, target tree, move list, "PATCH each moved source's cardPath, update _index") and POST it —
+
+```bash
+curl -s -X POST http://localhost:8321/api/background-task \
+  -H "Content-Type: application/json" \
+  -d '{"title":"Reorganize knowledge/sources collections","brief":"<self-contained instructions>","tier":"medium","notificationPolicy":"if_significant","origin":"agent"}'
+```
+
+### Phase 3: Consistency repair
+
+For inconsistencies the prefilter counted:
+
+- A `filed` source whose card file is missing → rewrite the card from the ledger metadata (or `PATCH {"status":"unfiled"}` if you cannot reconstruct it meaningfully).
+- A card whose `source_id` has no ledger row → the binary is gone (owner hard-delete); note it in the card body and remove the card next pass if the owner confirms, or leave the card as the surviving record — judgement call, prefer preserving information.
+- Report anything irrecoverable via `POST /api/notify` (priority low, one message for the whole run — never one per item).
+
+### Phase 4: Learn
+
+- If the shipped taxonomy/filing anchors in the `sources` skill have drifted from how you actually filed things this run, submit a skill-curation proposal against those anchors (`POST /api/skill-curation/proposals`) so next week's pass starts from the better rules.
+- Friction worth remembering (a collection rule that misfires, a provenance that always needs bytes fetched) → record one `self_critique` signal per distinct lesson; the consolidation loop folds it into your per-agent lessons, which are injected automatically next run:
+
+```bash
+curl -s -X POST http://localhost:8321/api/feedback \
+  -H "Content-Type: application/json" \
+  -d '{"source":"self_critique","valence":"negative","scope_type":"agent_slug","scope_ref":"source-librarian","summary":"<one-line lesson, e.g. WhatsApp PDFs never carry captions - always fetch bytes before filing>"}'
+```
+
+Silent by default: no user notification unless Phase 3 found something irrecoverable or a delegated reorg was spawned (one short DM via `/api/notify`, priority low).

package/agent-assets/task-flows/scheduled.dm.md

@@ -93,14 +93,18 @@ person at 9am than during the day."
 
 ## Sub-flow routing
 
-The specific dm_session task is selected by `{event_data[task]}`
-prefix matching. Find the matching sub-flow below and follow its
-content rules.
-
-- starts with `morning briefing` → see `## Morning briefing` below
-- starts with `task delivery:` → see `## Task delivery` below
-- starts with `profile_interview:` → see `## Profile interview` below
-- starts with `confirm:` → see `## Confirmation follow-up` below
+The specific dm_session sub-flow is selected by the **structural**
+`sub_flow` field inside `<task_context>` — a value the daemon sets and
+the user never edits, so routing stays correct even after the task's
+prompt/content is freely edited (e.g. through the `task` board facade).
+Read `sub_flow` out of the JSON in the `<task_context>` block and match
+it below. If `sub_flow` is absent (legacy rows predating the field),
+fall back to `{event_data[task]}` prefix matching.
+
+- `sub_flow` is `morning_briefing` (legacy fallback: task starts with `morning briefing`) → see `## Morning briefing` below
+- `sub_flow` is `task_delivery` (legacy fallback: task starts with `task delivery:`) → see `## Task delivery` below
+- `sub_flow` is `profile_interview` (legacy fallback: task starts with `profile_interview:`) → see `## Profile interview` below
+- `sub_flow` is `confirm` (legacy fallback: task starts with `confirm:`) → see `## Confirmation follow-up` below
 - (future sub-flows added here)
 
 If no sub-flow matches:
@@ -122,7 +126,8 @@ user verbatim — defeating the skip.
 
 ## Task delivery
 
-Triggered by `{event_data[task]}` starting with `task delivery:`.
+Triggered by `sub_flow` = `task_delivery` in `<task_context>` (legacy
+fallback: `{event_data[task]}` starts with `task delivery:`).
 
 Your final assistant turn IS the DM that delivers a background task
 artifact. The daemon has already decided that the owner is active in
@@ -157,21 +162,27 @@ Delivery rules:
 2. Preserve factual fidelity. Do not invent findings, counts, URLs, or
    decisions not present in `report` / `draft`. Do not claim a file is
    attached unless it appears in `assets`.
-3. Do not mention implementation details such as task IDs,
+3. If `draft` carries a `Note: N of M requirements not fully met: …` line,
+   the task completed WITH GAPS — that disclosure must survive into your
+   DM (verbatim or tightly rephrased, naming the unmet items). Never
+   present a gapped result as a clean one, no matter how compact the
+   message needs to be.
+4. Do not mention implementation details such as task IDs,
    `task.delivery`, `scheduled.dm`, artifacts, metadata, API routes,
    context blocks, or background runners.
-4. Keep the message compact. For long reports, summarize the decision
+5. Keep the message compact. For long reports, summarize the decision
    points and offer to pull details if the owner asks. If the owner later
    asks for a file again, you can re-send it from the task detail in a
    normal turn (the artifact API exposes the asset list).
-5. End with exactly the message to send. Do not perform follow-up work in
+6. End with exactly the message to send. Do not perform follow-up work in
    this turn.
 
 ---
 
 ## Morning briefing
 
-Triggered by `{event_data[task]}` starting with `morning briefing`.
+Triggered by `sub_flow` = `morning_briefing` in `<task_context>` (legacy
+fallback: `{event_data[task]}` starts with `morning briefing`).
 
 > Universal rules from the notify skill § Universal user-facing
 > message discipline apply on top of the contract below — particularly
@@ -417,8 +428,9 @@ inside the closer line.
 
 ## Profile interview
 
-Triggered by `{event_data[task]}` starting with `profile_interview:<id>
-— <ask-hint>`. This is the **fallback** path — the morning routine
+Triggered by `sub_flow` = `profile_interview` in `<task_context>` (legacy
+routing fallback: `{event_data[task]}` starts with `profile_interview:<id>
+— <ask-hint>`). This is the **fallback** path — the morning routine
 normally just lays the row latent and waits for an opportunity in DM /
 briefing. The evening sweep promotes a row to a scheduled DM only after
 3 days of no opportunity AND the user has been actively DMing.
@@ -483,7 +495,8 @@ row open.
 
 ## Confirmation follow-up
 
-Triggered by `{event_data[task]}` starting with `confirm:`. The DM
+Triggered by `sub_flow` = `confirm` in `<task_context>` (legacy fallback:
+`{event_data[task]}` starts with `confirm:`). The DM
 handler scheduled this row because a gate (e.g. project-creation, a
 managed-task duplicate, a long-horizon ambiguity) was triggered during
 an earlier DM but could not be asked then — either the conversation

package/agent-assets/templates/_manifest.json

@@ -13,6 +13,7 @@
     "identity/work.md": { "version": 2 },
     "journal/agent.md": { "version": 1 },
     "knowledge/dossiers/_index.md": { "version": 1 },
+    "knowledge/sources/_index.md": { "version": 1 },
     "knowledge/dossiers/evening.md": { "version": 1 },
     "knowledge/dossiers/activity-scan.md": { "version": 1 },
     "knowledge/dossiers/monthly.md": { "version": 1 },

package/agent-assets/templates/knowledge/sources/_index.md

@@ -0,0 +1,19 @@
+---
+type: index
+owner: agent
+updated: 2026-07-01
+template_version: 1
+---
+# Sources
+
+Directory of source-document collections (SOURCE_LIBRARY_DESIGN.md).
+Each collection groups markdown cards describing documents the user
+sent over chat; the binaries themselves live in the daemon's source
+library and are referenced by each card's `source_id` frontmatter.
+
+Maintained by the `sources` skill and the weekly source-librarian pass.
+One line per collection with its one-phrase scope.
+
+## Collections
+
+- (none yet — created as documents are filed)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aitne-sh/aitne",
-  "version": "0.1.11",
+  "version": "0.1.13",
   "description": "Aitne — a local-first, proactive personal AI agent. A long-running TypeScript daemon is the nervous system; Claude Code (or Codex / Gemini CLI) is the brain. All persistent memory lives in local Markdown files.",
   "keywords": [
     "ai",
@@ -43,9 +43,9 @@
     "README.md"
   ],
   "dependencies": {
-    "@aitne/daemon": "0.1.11",
-    "@aitne/dashboard": "0.1.11",
-    "@aitne/shared": "0.1.11"
+    "@aitne/daemon": "0.1.13",
+    "@aitne/dashboard": "0.1.13",
+    "@aitne/shared": "0.1.13"
   },
   "devDependencies": {
     "@typescript-eslint/eslint-plugin": "^8.58.1",