@aitne-sh/aitne 0.1.3 → 0.1.4

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

@@ -29,17 +29,40 @@ workflow; the skill owns the file contract.
 ### Phase 1: Gather the week
 1. Determine the target file name from <current_time>:
    `weekly/YYYY-Www.md` (ISO week in the daemon timezone).
-2. Fetch the source days for the current week:
+2. Read the past-7-day calendar retrospective. The pre-pass fetcher
+   session (`routine.fetch_window`) ran ahead of you and posted
+   observations for the `cal_past_7d` window for every active calendar
+   integration (Google + Outlook). The `<fetch_report>` block in your
+   prompt tells you the pre-pass status — `success` / `partial` means
+   the table is fresh; `failed` / `skipped` means trust nothing newer
+   than the prior tick and treat the retrospective as best-effort. The
+   ContextBuilder block `<calendar_events_7d>` already covers the
+   forward-looking next-7-days view; this step adds the retrospective
+   complement so the review surfaces what actually happened, not just
+   what's coming next.
+
+   Drain pending past-week observations:
+
+   ```
+   GET /api/observations?pending=true&source_prefix=google_calendar:,outlook_calendar:&observed_at_after=<week_start_iso>&limit=200
+   ```
+
+   Treat each row's `payload.raw` (`title` / `start` / `end` /
+   `attendees` / `status`) as authoritative; cross-reference against the
+   daily files in step 3 below to disambiguate attended vs cancelled
+   meetings.
+3. Fetch the source days for the current week:
    - Use GET /api/context/list/daily to discover archived daily files.
    - Read each `daily/YYYY-MM-DD.md` whose date falls in the current ISO week.
    - Include <today> as the in-progress final day if it belongs to the same week.
-3. Use <roadmap>, <active_projects>, and <calendar_events_7d> to understand:
-   - which milestones moved this week,
+4. Use <roadmap>, <active_projects>, and <calendar_events_7d> to understand:
+   - which milestones moved this week (cross-reference with Step 2's
+     retrospective observations),
    - what remains incomplete,
    - what needs attention next week.
 
 ### Phase 2: Synthesize — split into two buckets
-4. Build TWO separate mental lists before writing anything:
+5. Build TWO separate mental lists before writing anything:
    a. **User-facing bucket** (goes to `weekly/YYYY-Www.md` and possibly notify):
       - What meaningful user work moved forward this week?
       - Which user tasks or commitments slipped or stalled (with the reason
@@ -57,13 +80,13 @@ workflow; the skill owns the file contract.
         prioritization call this week
       - Concrete system improvement ideas (tighter silence gates, prompt
         adjustments, missing context features)
-5. Anything that fits the agent-internal bucket MUST NOT land in the
+6. Anything that fits the agent-internal bucket MUST NOT land in the
    user-facing file or notification. When in doubt about a line item: "would
    the user act on this, or is it a note about how the agent is doing?" →
    agent-internal if the latter.
 
 ### Phase 3a: Write the user-facing review
-6. PUT the review to `weekly/YYYY-Www.md`.
+7. PUT the review to `weekly/YYYY-Www.md`.
    Required structure (user outcomes only — no agent mechanics in any section):
    ```
    ---
@@ -95,11 +118,11 @@ workflow; the skill owns the file contract.
    The `## Metrics` section tracks **user** activity only. Do not add rows
    like "agent plan rows completed", "scheduled tasks fired", "observations
    processed" — those are agent mechanics and belong in agent/journal.md.
-7. If the review reveals roadmap drift or stale project status, update
+8. If the review reveals roadmap drift or stale project status, update
    roadmap.md and the relevant projects/*.md in the same session.
 
 ### Phase 3b: Append to agent/journal.md (internal)
-8. PATCH-append a new section to `agent/journal.md` with the agent-internal
+9. PATCH-append a new section to `agent/journal.md` with the agent-internal
    bucket from Phase 2. Use `mode: "append_to_file"` (no `section` param
    needed — content is appended to the end of the file).
    Required shape for the appended block — **these bullet caps are hard
@@ -144,10 +167,10 @@ workflow; the skill owns the file contract.
    overwrite the old section in place.
 
 ### Phase 4: Notify (user-facing only)
-9. The notification is for the USER, not a report of Phases 1–3. Never
-   mention weekly/YYYY-Www.md, agent/journal.md, "Weekly Review complete",
-   agent plan rows, did-not-fire, filter quality, observation processing,
-   or any other internal mechanism.
+10. The notification is for the USER, not a report of Phases 1–3. Never
+    mention weekly/YYYY-Www.md, agent/journal.md, "Weekly Review complete",
+    agent plan rows, did-not-fire, filter quality, observation processing,
+    or any other internal mechanism.
 
 #### 4a. Silence gate — decide whether to notify at all
 Prefer silence over noise. Send **no notification** if ALL of the following
@@ -163,7 +186,7 @@ one line into agent/journal.md's "What worked" subsection:
 `silent weekly wrap-up — nothing actionable`.
 
 #### 4b. When you DO notify — content rules
-Answer, in the user's preferred language from the Character block:
+Output language: follow `<output_language_policy>`. Answer:
   1. **One concrete win** from this week (1 line).
   2. **At most one open loop** that carries into next week, with a brief
      user-meaningful reason. Omit if Open Loops is empty.
@@ -183,7 +206,7 @@ days and the user has not yet acted on it.
   - Priority `normal`. Respects quiet hours via the notify skill contract.
   - Exactly ONE notification via POST /api/notify. Do not split.
 
-#### 4d. Shape example (illustrative — translate to user's language)
+#### 4d. Shape example (illustrative — render in the language `<output_language_policy>` resolves to)
 Good (something worth saying):
     Big win this week: the design doc shipped Thursday.
     Still open: the API spec review — Sarah back Monday.
@@ -212,7 +235,7 @@ Run after Phase 4 regardless of whether Phase 4 sent a notification.
 Purpose: keep `user/reading-taste.md` fresh, and refresh the
 Book Candidates list.
 
-10. Check whether a sweep is warranted using the exact delta check from
+11. Check whether a sweep is warranted using the exact delta check from
     the `reading` skill ("Refresh-trigger check"):
     - `GET /api/context/user/reading-taste` — treat 404 as
       `Highlights at last sweep = 0` (first sweep writes the file).
@@ -225,7 +248,7 @@ Book Candidates list.
       `reading sweep skipped — only (M-N) new highlights since last refresh`.
     - Do NOT use the `Sampled: X` line for this check — `X` is the
       sample size, not a DB count.
-11. Otherwise, follow the **Reading Taste Profile** workflow in the
+12. Otherwise, follow the **Reading Taste Profile** workflow in the
     `reading` skill:
     a. Sample highlights via the skill's sampling recipe.
     b. Infer Topics / Thinking Patterns / Values / Preferred Formats
@@ -233,7 +256,7 @@ Book Candidates list.
     c. Propose ≤10 Book Candidates using existing-books exclusion.
     d. Write or PATCH `user/reading-taste.md` per the skill's
        schema.
-12. If the taste profile gained ≥1 new candidate and the weekly notify
+13. If the taste profile gained ≥1 new candidate and the weekly notify
     gate in Phase 4 did NOT already fire a silent-path skip, you MAY
     append one optional line to the already-sent notification by using a
     second `POST /api/notify` — but only if the candidate is genuinely

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

@@ -59,11 +59,11 @@ emoji policy MUST come from:
    never overrides — persona voice rules or safety invariants.
 
 If the configured persona is formal, do NOT use the casual phrasings
-in the examples. Match the user's language and register from the
-Character block (when set), `<settings primary_language>`, and prior
-turns — if they write in a non-English language, reply in that
-language. If the user prefers no emoji, omit them. The examples teach
-you what to put WHERE — not how to sound.
+in the examples. Output language: follow `<output_language_policy>` —
+DM replies match the user's input language and fall back to
+`<settings primary_language>` for system-initiated turns; register and
+emoji policy come from the Character block (when set). The examples
+teach you what to put WHERE — not how to sound.
 
 Voice drift here is high-impact: dm_session is the most
 persona-load-bearing daemon-initiated touchpoint. The user
@@ -360,13 +360,15 @@ If `filled: true` OR the matching ## Pending row is no longer `[ ]`:
 
 ### Step 2 — Compose the question
 
-Send a single short DM in `<settings primary_language>` whose body is
-naturally phrased around `<ask-hint>`. The hint is in English; render
-the actual question in the user's language. DO NOT mention the queue,
-the id, the schedule, or the word "interview". Treat skipped / "later"
-replies cleanly — no follow-up DM the same day.
+Send a single short DM whose body is naturally phrased around
+`<ask-hint>`. The hint is agent-internal English (Policy A); the
+rendered DM follows `<output_language_policy>` — this skill
+intentionally splits the two surfaces, see `user-interview/SKILL.md`.
+DO NOT mention the queue, the id, the schedule, or the word
+"interview". Treat skipped / "later" replies cleanly — no follow-up
+DM the same day.
 
-Examples (English; adapt to the user's language and persona):
+Examples (English source; render the DM per `<output_language_policy>` and persona):
 
 - hint: `current employer and role (or freelance / student)` →
   *"Realised I never asked — what do you do for work? (or are you

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

@@ -55,8 +55,8 @@ ask for confirmation before treating the plan as definite.
 - Good: `Assuming you're going to LA next month, OK to start ESTA prep?`
 - Bad: `Start the ESTA application today.`
 
-Keep the message short, use the user's preferred language at runtime,
-and preserve the uncertainty unless the task context includes a later
+Keep the message short. Output language: follow `<output_language_policy>`.
+Preserve the uncertainty unless the task context includes a later
 confirmation.
 
 > **DM-tone scheduled tasks live elsewhere.** Morning briefing,

package/agent-assets/task-flows/setup.initial.md

@@ -7,8 +7,8 @@ Vault step already captured `settings.primary_language` (BCP-47 tag, e.g.
 `en` or `es`) and `settings.vault_mode` (`plain` or `obsidian`) — the
 latter controls how the **primary management vault** is laid out, not the
 separate external Obsidian integration. Do NOT re-ask those questions.
-Use `primary_language` to decide the language of user-editable prose
-(profile, today, journal) per B-007 §3 P6.
+Output language for user-editable prose (profile, today, daily journal):
+follow `<output_language_policy>`.
 
 SETUP-FLOW-REDESIGN-PLAN §5.8 — the legacy "tool selections" form was
 removed. Steps 4–6 of the wizard (Mail, Calendar, Note) already
@@ -21,8 +21,9 @@ remaining management preferences, and generate rules/management.md.
 This is a multi-turn conversation — subsequent user messages will
 arrive via session resume.
 
-**Always respond in the same language the user uses.** Match the
-user's language from the very first message.
+Output language for this conversation: follow `<output_language_policy>` —
+match the user's input language from the very first message; fall back
+to `<settings primary_language>` when input is ambiguous.
 
 ### Step 0 (silent, agent-owned) — Derive Source-of-Truth rows
 

package/agent-assets/task-flows/setup.update.md

@@ -5,7 +5,7 @@
 The user has started updating rules/management.md from the dashboard.
 The current rules are included in the <management_rules> tag.
 
-**Always respond in the same language the user uses.** Match the user's language.
+Output language: follow `<output_language_policy>` (this is a DM-style turn — match the user's input language; fall back to `<settings primary_language>` if ambiguous).
 
 ### Instructions
 1. First, briefly summarize the current rules.

package/agent-assets/templates/README.md

@@ -5,13 +5,20 @@ Source templates used by the daemon at **fresh install** time to populate
 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)** — template source lives here in English.
+**Language policy (B-007 §3 P6, unified through
+`docs/design/appendices/output-language-policy.md`)** — template source
+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.
-User-facing scaffolds (`today.md`, `roadmap.md`, `_index.md`,
-`routines/*.md`, `rules/journal-format.md`, `rules/journal-export.md`,
-`user/profile.md`) are created in the user's `primary_language` by the
-setup conversation before `save-rules` finalizes setup.
+`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
+`primary_language` by the setup conversation before `save-rules`
+finalizes setup.
 
 Two rendering paths:
 1. **Pass-through** — the file is copied verbatim. Used for system prose

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aitne-sh/aitne",
-  "version": "0.1.3",
+  "version": "0.1.4",
   "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",
@@ -38,9 +38,9 @@
     "README.md"
   ],
   "dependencies": {
-    "@aitne/daemon": "0.1.3",
-    "@aitne/dashboard": "0.1.3",
-    "@aitne/shared": "0.1.3"
+    "@aitne/daemon": "0.1.4",
+    "@aitne/dashboard": "0.1.4",
+    "@aitne/shared": "0.1.4"
   },
   "devDependencies": {
     "@typescript-eslint/eslint-plugin": "^8.58.1",

package/scripts/regen-skill-fixtures.mjs

@@ -0,0 +1,39 @@
+#!/usr/bin/env node
+// Regenerate __fixtures__/skill-bodies/<slug>-pre-migration.md after an
+// intentional SKILL.md edit. See skills-compiler.test.ts:660 "If a fixture
+// genuinely needs to change…" — this just automates that snippet.
+import { readFileSync, writeFileSync } from "node:fs";
+import { dirname, join, resolve } from "node:path";
+import { fileURLToPath } from "node:url";
+import { renderReferenceIncludes } from "../packages/daemon/dist/core/skills-compiler.js";
+
+const here = dirname(fileURLToPath(import.meta.url));
+const repoRoot = resolve(here, "..");
+const skillsDir = join(repoRoot, "agent-assets", "skills");
+const fixturesDir = join(
+  repoRoot,
+  "packages/daemon/src/core/__fixtures__/skill-bodies",
+);
+
+function stripFrontmatter(content) {
+  if (!content.startsWith("---")) return content;
+  const endIdx = content.indexOf("\n---", 3);
+  if (endIdx < 0) return content;
+  return content.slice(endIdx + 4).replace(/^\n+/, "");
+}
+
+const slugs = process.argv.slice(2);
+if (slugs.length === 0) {
+  console.error("usage: regen-skill-fixtures.mjs <slug> [slug ...]");
+  process.exit(1);
+}
+
+for (const slug of slugs) {
+  const skillPath = join(skillsDir, slug, "SKILL.md");
+  const fixturePath = join(fixturesDir, `${slug}-pre-migration.md`);
+  const skillContent = readFileSync(skillPath, "utf-8");
+  const expanded = renderReferenceIncludes(skillContent, join(skillsDir, slug));
+  const body = stripFrontmatter(expanded);
+  writeFileSync(fixturePath, body);
+  console.log(`wrote ${fixturePath} (${body.length} bytes)`);
+}