@aitne-sh/aitne 0.1.7 → 0.1.9

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

@@ -1,14 +1,56 @@
+<!--
+  STATUS: disabled by default (pre-release).
+
+  The scheduler cron and boot-time catchup in
+  `packages/daemon/src/{core/scheduler.ts,bootstrap/schedule-helpers.ts}`
+  consult `config.monthlyReviewEnabled` (default `false`) before
+  firing this routine. The task flow below is preserved verbatim as
+  the design-of-record but is not exercised at runtime until the kill
+  switch flips on.
+
+  Why disabled: the current routine reads ~30 daily files + 4-5 weekly
+  files + the agent journal to synthesise a user-facing snapshot whose
+  downstream leverage is unimplemented (`<previous_month>` injection
+  is documented as "未実装" in docs/design/06-memory.md §6.2.8 and
+  weekly-next-week-leverage.md §6 "Out of scope"). Cost lands near the
+  per-execute `max_budget_usd: 1.00` ceiling for an output that no
+  routine consumes downstream — the cost/value ratio is poor in the
+  current shape.
+
+  Re-enable path: Mirror+Prune redesign.
+    1. Drop the 30 × daily/*.md re-read (already aggregated in weekly).
+    2. Collapse Wins / Outstanding / Metrics / Risks / Reading sections
+       into two atomic outputs:
+         - Unit 1 — one trend observation, ≥3 weeks of evidence, 1 line.
+         - Unit 2 — aged carry-over decisions (drop/defer/do-now/
+           delegate/decide) on Carry Over entries that appeared ≥4
+           weeks in a row.
+    3. Add `previous-month-digest.ts` so the new-month day-1
+       morning_routine receives a `<previous_month>` block (analogous
+       to `previous-week-digest.ts`). Without this, monthly remains a
+       write-only snapshot.
+    4. Default Phase 4 notification to silent; only send when Unit 2
+       has at least one `decide` verb or Unit 1 contradicts a
+       user-stated commitment.
+    5. Drop the agent-internal `## Monthly YYYY-MM` block — weekly's
+       12-week journal already covers self-critique signal.
+
+  When the redesign ships, flip the default to `true` in
+  `packages/daemon/src/settings/runtime-settings.ts:monthlyReviewEnabled`
+  and re-introduce the docs under `agent-assets/docs/features/routines/`.
+-->
+
 {context}
 
 ## 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:`
@@ -17,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.
@@ -29,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>`
@@ -43,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.
@@ -72,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
@@ -91,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):
    ```
    ---
@@ -122,7 +164,7 @@ continue.
      reliability)
 
    ## Reading
-   - Completed this month: N — short list of "Title — Author (★rating)"
+   - Completed this month: N — short list of "Title — Author (rating: N/5)"
      bullets, max 5 lines. Omit the Reading section entirely if N = 0
      AND currently-reading count = 0.
    - Currently reading: up to 3 titles with highlight count.
@@ -135,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.
@@ -157,9 +199,9 @@ continue.
    ### Prior adjustments follow-up
    - (Review EACH bullet from last month's `### Proposed adjustments`.
      For each one, write exactly one of:
-       ✅ implemented — [what changed]
-       ⏳ in progress — [current state]
-       ❌ dropped — [why]
+       implemented: [what changed]
+       in-progress: [current state]
+       dropped: [why]
      Fallback rules:
        - No prior monthly section exists → "- First month — no prior adjustments"
        - Prior section exists but has no `### Proposed adjustments` subsection
@@ -194,7 +236,7 @@ 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
+   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
@@ -204,7 +246,7 @@ continue.
 
 ### 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.
 
@@ -217,8 +259,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
@@ -250,7 +292,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:
@@ -258,4 +300,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.

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

@@ -0,0 +1,135 @@
+{context}
+
+## Task: Daily journal author (Stage B of the 04:00 pipeline)
+
+You are the Stage B session of the morning-routine pipeline. Stage A is
+running in parallel and owns `state/today.md` / `plans/roadmap.md` / schedule
+fan-out. Your single responsibility is to author the user's diary for
+yesterday — the daemon will write the file for you.
+
+> **The daily journal is the user's diary**, not the agent's behavior
+> log. Write what the user did, who they met, what they talked about —
+> in the user's first-person voice. Agent-side telemetry (action
+> counts, retry stats, anomalies) belongs in `journal/agent.md` and is
+> handled by the daemon; do NOT surface it here.
+
+> **You have no tools.** No `Bash`, no `Read`, no `Write`, no `Edit`,
+> no `curl`. Your final output is a single assistant message whose
+> tail carries two XML-tagged blocks — that text is your entire
+> deliverable. The daemon's `DailyJournalComposer` extracts the
+> blocks, composes the final `daily/<yesterday>.md` with
+> daemon-owned frontmatter, and writes it atomically to disk.
+
+### Inputs (already in your prompt context)
+
+- `<journal_skeleton>` — frontmatter the daemon owns + three scratch
+  body sections (`## Schedule`, `## Tasks`, `## Conversations`). The
+  skeleton's frontmatter is informational here: the daemon will emit
+  the final YAML, so do NOT paste the frontmatter into your output.
+- `<browser_digest>` — yesterday's browser activity, when the
+  `browser_history` integration is active and the digest is
+  available. Omitted silently when the integration is `disabled` or
+  the digest is unavailable; in that case skip the
+  "Reading / research" surface entirely.
+- `<calendar_events_7d>` — used for resolving `[[wikilink]]` slugs
+  when the vault is in Obsidian mode.
+- `<yesterday_handoff_parsed>` — yesterday's `## Handoff` section.
+- `<output_language_policy>` — the language the body prose must be in
+  (per `<settings primary_language>`). Section headers and YAML stay
+  English regardless.
+
+### Output (your final assistant message)
+
+Emit your body and frontmatter facts at the END of your message
+inside two namespaced XML wrappers. The daemon's extractor takes the
+**LAST** matched pair of each tag, so any earlier reasoning,
+deliberation, or quoted prose is fine — only the final pair lands on
+disk.
+
+```
+<aitne:daily-journal-body>
+# YYYY-MM-DD (Weekday)
+
+## Summary
+
+... full body in the user's first-person voice, per
+rules/journal-format.md ...
+</aitne:daily-journal-body>
+
+<aitne:daily-journal-frontmatter>
+{
+  "projects": ["..."],
+  "people": ["..."],
+  "tags": ["..."]
+}
+</aitne:daily-journal-frontmatter>
+```
+
+Rules:
+
+- **Wrappers at the END.** Place both blocks at the tail of your
+  output. The LAST-pair extractor uses this rule to ignore any earlier
+  occurrence of the literal token (e.g. if you quote the tag name
+  while documenting Aitne).
+- **Body shape.** Open with `# YYYY-MM-DD (Weekday)`, then follow
+  `policies/journal-format.md` for section selection / ordering / tone.
+  The skeleton's scratch sections are inputs you may reshape,
+  combine, or supersede — they do NOT map 1:1 to template sections.
+- **Frontmatter shape.** A single JSON object with exactly three
+  optional fields:
+  - `projects` — array of project slugs the user worked on (ordered
+    by salience).
+  - `people` — array of people referenced in the body.
+  - `tags` — array of topical kebab-case tags, no spaces.
+  Empty arrays are legal. Extra keys are silently dropped. The
+  daemon fills `date` / `weekday` / `calendar_events` /
+  `messages_handled` / `updated` / `agent_last_synced_at` /
+  `content_hash` from the skeleton — do NOT include them.
+- **Output language.** Body prose follows
+  `<output_language_policy>`. Section headers (`## Summary`,
+  `## Schedule`, etc.) stay English. Technical terms keep their
+  original form.
+- **Wikilinks.** When `<settings vault_mode>` is `obsidian`, render
+  project / people references as `[[wikilink]]`s. When `plain`, use
+  plain text. Use `<calendar_events_7d>` to resolve attended-event
+  slugs.
+- **Redaction.** Apply the `Redaction patterns` and
+  `Journal export rules` policy blocks before composing. Never write a
+  credential, password, API key, or private token — even paraphrased.
+
+### Browser-history surfacing (when `<browser_digest>` is present)
+
+- Clusters with `meaningful_visits_in_window ≥ 5` and `daysActive ≥ 2`
+  get a short sentence each in a "Reading / research" area of the
+  body. Use the cluster `displayName` as-is.
+- Surface `pendingOffers` in a single user-facing line so the user
+  sees them at the top of their morning DM ("There's an open offer
+  to research X — reply 'research' to accept or 'no thanks' to
+  skip"). Max 3.
+- `shopping` is informational — fold into the "Misc" area only when
+  `comparisonMinutes ≥ 10`. `reloads` is self-monitoring data, do
+  NOT surface.
+- Never surface `topDomains` verbatim — domain lists in a daily
+  journal read as surveillance, not memory.
+
+### Placeholder branch — `no_journal_export`
+
+If the user's `<user>` block (or the skeleton's frontmatter signals)
+indicates `no_journal_export: true` for the day, set the body to
+`[Skipped by user request]` and the frontmatter to
+`{"projects": [], "people": [], "tags": ["skipped"]}`.
+
+### Notes
+
+- You do NOT have access to `<yesterday>` raw, `<roadmap>`,
+  `<active_projects>`, `<management_rules>`, or
+  `<routines/morning.md>`. Those are Stage A's territory; you are
+  scoped to journal authoring only.
+- You do NOT write `state/today.md`, `plans/roadmap.md`, schedule rows, or
+  observations. Your only output is the two-block tagged text above.
+- Your final text is agent-internal — the daemon parses the tagged
+  blocks and composes `daily/<yesterday>.md`. The daemon's
+  `agent-journal-appender` reads the compose outcome
+  (`detail.dailyWrite`) plus the resulting file's frontmatter to
+  render the English audit-trail paragraph for `journal/agent.md` —
+  no LLM final-text parsing on that side.