@aitne-sh/aitne 0.1.7 → 0.1.9

package/agent-assets/agents/morning-routine/agent.md

@@ -0,0 +1,78 @@
+---
+# ── Identity ─────────────────────────────────────────────────────────────────
+slug: morning-routine
+name: Morning Routine
+description: "Regenerates state/today.md, creates the daily journal entry, and delivers the morning DM digest at the day boundary."
+kind: builtin
+version: 1
+enabled: true
+tags: [routine, daily, journal]
+
+# ── Schedule ─────────────────────────────────────────────────────────────────
+# `{dayBoundaryHour}` is substituted with the live config value at load
+# (default 4 → "0 4 * * *"). The registry (§5.5) is the authoritative cron
+# source; the loader emits a non-fatal drift warning on mismatch.
+# `timezone` is intentionally omitted — the loader fills it from
+# `config.timezone` (US-targeted product; no baked single-zone default).
+schedule:
+  kind: cron
+  expression: "0 {dayBoundaryHour} * * *"
+
+# ── Backend / routing ────────────────────────────────────────────────────────
+# `tier`/`model` are null: built-ins defer their routing to
+# `process_backend_config` (the seed authority). Operators override per-agent
+# from the dashboard (§6.4.1), not here.
+backend:
+  process_key: routine.morning_routine
+  tier: null
+  model: null
+
+# ── Limits (per execution) ───────────────────────────────────────────────────
+limits:
+  max_turns: 30
+  max_budget_usd: 0.50
+  timeout_minutes: 15
+
+# ── Expected outputs (informational; drive the dashboard + criteria intent) ──
+outputs:
+  - state/today.md
+  - journal/daily/{date}.md
+  - journal/agent.md
+
+# ── Semantic success checks (best-effort, evaluated post-execute) ────────────
+# today.md is regenerated wholesale every morning, so a section-count floor is
+# a real check (it fails on a degenerate/empty regen). The daily journal is
+# written for the *previous* agent-day (`daily/<yesterday>.md`), which the
+# `{date}`-only evaluator cannot target, and the DM digest is conditional —
+# both are listed under `outputs` rather than asserted as criteria.
+success_criteria:
+  - id: today_md_populated
+    kind: file_section_count
+    target: state/today.md
+    heading_level: 2
+    min: 3
+
+# ── Error handling ───────────────────────────────────────────────────────────
+on_error:
+  retries: 1
+  retry_delay_seconds: 60
+  notify_owner: true
+
+# ── Stop warning (byte-identical to BUILTIN_AGENT_REGISTRY, §12.1) ──────────
+stop_warning:
+  level: critical
+  services_lost:
+    - "Daily state/today.md regeneration"
+    - "Daily journal entry creation"
+    - "Morning DM digest delivery"
+  dependent_agents:
+    - evening-review
+    - weekly-review
+  reactivation_hint: "Re-enable from /agents/morning-routine. The next firing catches up with a broader observation window."
+---
+
+# Morning Routine
+
+Built-in routine — the execution prompt lives in the task-flow, not here.
+See `agent-assets/task-flows/routine.morning_routine_today.md` (Stage A — today.md synthesis)
+and `agent-assets/task-flows/routine.morning_routine_journal.md` (Stage B — daily journal).

package/agent-assets/agents/roadmap-maintenance/agent.md

@@ -0,0 +1,52 @@
+---
+# ── Identity ─────────────────────────────────────────────────────────────────
+slug: roadmap-maintenance
+name: Roadmap Maintenance
+description: "Mechanical (no-LLM) roadmap.md upkeep — stale-item pruning and section reconciliation — before the evening review."
+kind: builtin
+version: 1
+enabled: true
+tags: [routine, daily, roadmap, no-llm]
+
+# ── Schedule (17:45 — releases the roadmap write-lock before Evening Review) ─
+schedule:
+  kind: cron
+  expression: "45 17 * * *"
+
+# ── Backend / routing ────────────────────────────────────────────────────────
+# `process_key: null` — this is a no-LLM in-process pass with no backend-routing
+# key (§5.5.1). Reserved for built-ins; the schema rejects a null key for user
+# Agents.
+backend:
+  process_key: null
+  tier: null
+  model: null
+
+# ── Limits (no LLM turn — zero budget; `max_turns` must be ≥ 1 per schema) ──
+limits:
+  max_turns: 1
+  max_budget_usd: 0
+  timeout_minutes: 5
+
+# ── Expected outputs ─────────────────────────────────────────────────────────
+outputs:
+  - plans/roadmap.md
+
+success_criteria: []
+
+# ── Stop warning (byte-identical to BUILTIN_AGENT_REGISTRY, §12.1) ──────────
+stop_warning:
+  level: high
+  services_lost:
+    - "Mechanical roadmap.md maintenance (stale-item pruning, section reconciliation)"
+  dependent_agents:
+    - evening-review
+  reactivation_hint: "Re-enable from /agents/roadmap-maintenance. Runs daily at 17:45, before Evening Review."
+---
+
+# Roadmap Maintenance
+
+No-LLM in-process pass — there is no task-flow. Implemented by the daemon
+callback `onRoadmapMaintenance` registered in `scheduler.ts` (mechanical
+`roadmap.md` stale-item pruning and section reconciliation). It runs at 17:45
+and releases the roadmap write-lock before Evening Review's 18:00 promotion.

package/agent-assets/agents/skill-curation/agent.md

@@ -0,0 +1,52 @@
+---
+# ── Identity ─────────────────────────────────────────────────────────────────
+slug: skill-curation
+name: Skill Curation
+description: "Generates typed skill self-optimization proposals on the configured cadence (opt-in)."
+kind: builtin
+version: 1
+enabled: true
+tags: [routine, skills, self-learning, opt-in]
+
+# ── Schedule (03:00; scheduler reads the configured cadence at fire time) ────
+schedule:
+  kind: cron
+  expression: "0 3 * * *"
+
+# ── Backend / routing (tier/model deferred to process_backend_config) ───────
+backend:
+  process_key: routine.skill_curation
+  tier: null
+  model: null
+
+# ── Limits (per execution) ───────────────────────────────────────────────────
+limits:
+  max_turns: 25
+  max_budget_usd: 0.50
+  timeout_minutes: 15
+
+# ── Expected outputs ─────────────────────────────────────────────────────────
+# Output is typed curation submissions (proposals persisted via the
+# skill-curation API), not a deterministic vault file — documented here, no
+# post-execute criterion asserted in v1.
+outputs:
+  - "Typed skill self-optimization proposals (skill-curation submissions)"
+
+success_criteria: []
+
+# ── Stop warning (byte-identical to BUILTIN_AGENT_REGISTRY, §12.1) ──────────
+stop_warning:
+  level: normal
+  services_lost:
+    - "Skill self-optimization proposals (typed curation submissions)"
+  dependent_agents: []
+  reactivation_hint: "Skill curation is opt-in via /settings/self-learning. Re-enable from /agents/skill-curation."
+---
+
+# Skill Curation
+
+Built-in routine — opt-in via `/settings/self-learning`. The execution runs in
+the optimizer workdir (`dispatcher-scheduled-tasks.ts`, P22 §3.4) against the
+`/api/skill-curation/*` surface and the `agent-assets/optimizer-skills/skill-curation`
+assets; there is no `task-flows/routine.skill_curation.md`. The scheduler gates
+firing on `isSkillCurationEnabled(db)` and the configured cadence.

package/agent-assets/agents/user-profile-sweep-evening/agent.md

@@ -0,0 +1,48 @@
+---
+# ── Identity ─────────────────────────────────────────────────────────────────
+slug: user-profile-sweep-evening
+name: User Profile Sweep (Evening)
+description: "Refreshes identity/profile.md from the day's DM traffic shortly before the evening review."
+kind: builtin
+version: 1
+enabled: true
+tags: [routine, profile, sweep, evening]
+
+# ── Schedule (17:50 — 10 min before Evening Review at 18:00) ────────────────
+schedule:
+  kind: cron
+  expression: "50 17 * * *"
+
+# ── Backend / routing (tier/model deferred to process_backend_config) ───────
+backend:
+  process_key: routine.user_profile_sweep
+  tier: null
+  model: null
+
+# ── Limits (per execution; minimal-tools background pass) ───────────────────
+limits:
+  max_turns: 15
+  max_budget_usd: 0.20
+  timeout_minutes: 8
+
+# ── Expected outputs ─────────────────────────────────────────────────────────
+outputs:
+  - identity/profile.md
+  - "identity/<topic>.md"
+
+success_criteria: []
+
+# ── Stop warning (byte-identical to BUILTIN_AGENT_REGISTRY, §12.1) ──────────
+stop_warning:
+  level: normal
+  services_lost:
+    - "Pre-evening user/profile.md refresh from the day's DM traffic"
+  dependent_agents:
+    - evening-review
+  reactivation_hint: "Re-enable from /agents/user-profile-sweep-evening. Runs 10 min before Evening Review."
+---
+
+# User Profile Sweep (Evening)
+
+Built-in routine — the execution prompt lives in the task-flow, not here.
+See `agent-assets/task-flows/routine.user_profile_sweep.md` (phase: evening).

package/agent-assets/agents/user-profile-sweep-morning/agent.md

@@ -0,0 +1,53 @@
+---
+# ── Identity ─────────────────────────────────────────────────────────────────
+slug: user-profile-sweep-morning
+name: User Profile Sweep (Morning)
+description: "Refreshes identity/profile.md from the day's DM traffic shortly before the day boundary, ahead of the morning routine."
+kind: builtin
+version: 1
+enabled: true
+tags: [routine, profile, sweep, morning]
+
+# ── Schedule ─────────────────────────────────────────────────────────────────
+# `{dayBoundaryHour-1}` resolves to the hour before the day boundary
+# (default 4 → "50 3 * * *"), i.e. 10 min before Morning Routine at 04:00.
+schedule:
+  kind: cron
+  expression: "50 {dayBoundaryHour-1} * * *"
+
+# ── Backend / routing (tier/model deferred to process_backend_config) ───────
+backend:
+  process_key: routine.user_profile_sweep
+  tier: null
+  model: null
+
+# ── Limits (per execution; minimal-tools background pass) ───────────────────
+limits:
+  max_turns: 15
+  max_budget_usd: 0.20
+  timeout_minutes: 8
+
+# ── Expected outputs ─────────────────────────────────────────────────────────
+# Writes are silent and idempotent (no user-visible output, no /api/notify).
+# profile.md pre-exists and is appended/patched, so file presence is not a
+# meaningful per-run signal — documented here, no criterion asserted.
+outputs:
+  - identity/profile.md
+  - "identity/<topic>.md"
+
+success_criteria: []
+
+# ── Stop warning (byte-identical to BUILTIN_AGENT_REGISTRY, §12.1) ──────────
+stop_warning:
+  level: normal
+  services_lost:
+    - "Pre-morning user/profile.md refresh from the day's DM traffic"
+  dependent_agents:
+    - morning-routine
+  reactivation_hint: "Re-enable from /agents/user-profile-sweep-morning. Runs 10 min before the day boundary."
+---
+
+# User Profile Sweep (Morning)
+
+Built-in routine — the execution prompt lives in the task-flow, not here.
+See `agent-assets/task-flows/routine.user_profile_sweep.md` (phase: morning).

package/agent-assets/agents/weekly-review/agent.md

@@ -0,0 +1,51 @@
+---
+# ── Identity ─────────────────────────────────────────────────────────────────
+slug: weekly-review
+name: Weekly Review
+description: "Writes the weekly synthesis note and reviews the roadmap every Friday evening."
+kind: builtin
+version: 1
+enabled: true
+tags: [routine, weekly, journal]
+
+# ── Schedule (Friday 19:00) ──────────────────────────────────────────────────
+schedule:
+  kind: cron
+  expression: "0 19 * * 5"
+
+# ── Backend / routing (tier/model deferred to process_backend_config) ───────
+backend:
+  process_key: routine.weekly_review
+  tier: null
+  model: null
+
+# ── Limits (per execution) ───────────────────────────────────────────────────
+limits:
+  max_turns: 30
+  max_budget_usd: 0.50
+  timeout_minutes: 15
+
+# ── Expected outputs ─────────────────────────────────────────────────────────
+# The synthesis note is keyed on the ISO week (`journal/weekly/YYYY-Www.md`),
+# which the `{date}`-only success-criteria evaluator cannot target in v1, so it
+# is documented here rather than asserted as a criterion.
+outputs:
+  - "journal/weekly/{week}.md"
+  - plans/roadmap.md
+
+success_criteria: []
+
+# ── Stop warning (byte-identical to BUILTIN_AGENT_REGISTRY, §12.1) ──────────
+stop_warning:
+  level: high
+  services_lost:
+    - "Weekly synthesis note (journal/weekly/{week}.md)"
+    - "Weekly roadmap review"
+  dependent_agents: []
+  reactivation_hint: "Re-enable from /agents/weekly-review. Resumes on the next Friday 19:00 firing."
+---
+
+# Weekly Review
+
+Built-in routine — the execution prompt lives in the task-flow, not here.
+See `agent-assets/task-flows/routine.weekly_review.md`.

package/agent-assets/docs/concepts/agent-day.md

@@ -15,26 +15,32 @@ summary: |
 section: agent-day
 tags:
   - core
-  - timing
   - memory
+  - routines
+  - scheduler
 status: stable
 ask_examples:
   - When does the agent day actually roll over?
   - Why is my late-night work showing up under yesterday?
   - How do I change the day boundary?
+  - What is dayBoundaryHour?
 locale: en-US
 created: 2026-04-25
-updated: 2026-04-25
+updated: 2026-05-28
 keywords:
   - day boundary
   - 04:00
   - dayBoundaryHour
   - rollover
+  - agent day
+  - getAgentDayBoundsUtc
+  - getAgentDayDateStr
 related:
   - features/routines/morning-routine
   - features/memory-files/today
 ui_anchors:
   - /settings
+  - /settings/schedule
 config_keys:
   - dayBoundaryHour
 ---
@@ -45,7 +51,7 @@ config_keys:
 
 Aitne treats the "day" as starting at **04:00 local time**, not
 00:00. Anything you log between midnight and 4am is filed under the day
-that just ended, so a late commit at 02:30 lands in the same `today.md`
+that just ended, so a late commit at 02:30 lands in the same `state/today.md`
 that opened the previous morning.
 
 ## Why This Concept Exists
@@ -53,7 +59,7 @@ that opened the previous morning.
 Owner-as-user installations almost always have late-night work sessions
 that, mentally, belong to "today" even though the wall-clock has already
 ticked over. A day boundary at midnight would split a single coherent
-working session across two `today.md` files, and the morning routine
+working session across two `state/today.md` files, and the morning routine
 would open against an empty schedule because no agent activity had been
 logged for the new calendar day yet.
 
@@ -64,25 +70,26 @@ clean boundary before they start.
 ## Definitions
 
 - **Agent day**: the 24-hour window starting at the configured day-boundary hour and ending at the same hour the next calendar day.
-- **Day boundary**: the hour-of-day that starts the agent day. Configured via the `dayBoundaryHour` setting (default `4`).
-- **Day-stamped file**: any file whose name includes `YYYY-MM-DD` (e.g. `daily/2026-04-25.md`, `weekly/2026-04-20.md`). The date stamp uses the agent-day boundary, not the calendar day.
+- **Day boundary**: the hour-of-day that starts the agent day. Configured via the `dayBoundaryHour` setting (default `4`, valid range `0`–`9`). Values above 9 are rejected — the boundary is intended for the small hours, not mid-day.
+- **Day-stamped file**: any file whose name includes `YYYY-MM-DD` (e.g. `journal/daily/2026-04-25.md`, `journal/weekly/2026-04-20.md`). The date stamp uses the agent-day boundary, not the calendar day.
 
 ## Concrete Examples
 
 | Wall-clock time | Calendar date | Agent day |
 |---|---|---|
-| 2026-04-25 02:30 | April 25 | April 24 (late session) |
-| 2026-04-25 04:30 | April 25 | April 25 |
-| 2026-04-25 23:50 | April 25 | April 25 |
-| 2026-04-26 03:55 | April 26 | April 25 (still!) |
+| 2026-04-25 02:30 | April 25 | April 24 (before boundary) |
+| 2026-04-25 04:30 | April 25 | April 25 (after boundary) |
+| 2026-04-25 23:50 | April 25 | April 25 (normal) |
+| 2026-04-26 03:55 | April 26 | April 25 (before boundary) |
 
 ## Where You See It in the Dashboard
 
 - The Schedule view labels each day's column by **agent day**, so a 02:30 calendar entry appears under the previous day's header.
 - Activity → Conversations groups sessions by agent day for the same reason.
 - Cost analytics roll up by agent day so a late-night research binge does not split into two separate "days" of spend.
+- To change the boundary, open **Settings → Schedule** (`/settings/schedule`) and edit the day-boundary hour.
 
 ## Related
 
-- [Morning Routine](../features/routines/morning-routine.md) opens at the day boundary's morning-routine hour, not midnight.
+- [Morning Routine](../features/routines/morning-routine.md) opens shortly after the day boundary as part of the morning routine, not at midnight.
 - [today.md](../features/memory-files/today.md) is rebuilt once per agent day, anchored on the boundary.

package/agent-assets/docs/concepts/auth-health.md

@@ -7,6 +7,8 @@ aliases:
   - auth probe
   - auth recovery
   - credentials
+  - auth health monitor
+  - subscription auth warning
 category: concepts
 summary: |
   The auth-health monitor probes each backend's credentials at startup
@@ -17,26 +19,43 @@ tags:
   - core
   - safety
   - backends
+  - operations
+  - health
 status: stable
 ask_examples:
   - Why is the dashboard showing a degraded backend?
   - How does the agent check that I'm still logged in to Claude?
   - What happens when my Codex token expires?
+  - What is the SubscriptionAuthWarning banner?
 locale: en-US
 created: 2026-04-25
-updated: 2026-05-04
+updated: 2026-05-28
 keywords:
   - auth
+  - authentication
   - credentials
   - probe
   - degraded
+  - auth health monitor
+  - auth recovery
+  - api-key-probe
+  - SubscriptionAuthWarning
 related:
   - concepts/backends-and-tiers
   - concepts/costs-and-quotas
   - troubleshooting/auth-failed
+ui_anchors:
+  - /settings/models
+  - /
 config_keys:
   - authProbeDisabled
   - authPreflightFreshnessMs
+api_endpoints:
+  - POST /api/backends/:backendId/check-auth
+  - POST /api/backends/:backendId/recovery/start
+  - GET /api/backends/:backendId/recovery/status
+  - POST /api/backends/:backendId/recovery/code
+  - POST /api/backends/:backendId/recovery/cancel
 ---
 
 # Auth Health
@@ -62,12 +81,21 @@ routine fails.
   is live. Without an API key, the probe checks whatever local CLI
   login Aitne fell back to (Claude credentials store, Codex token,
   Gemini ADC).
-- **Preflight freshness**: how long the daemon trusts a successful
-  probe before re-running.
-- **Recovery**: backend-specific repair. The recommended path is
-  re-pasting the API key on `/settings/models`; for the fallback
-  path, re-running the matching CLI login (`claude`,
-  `codex login`, `gemini auth`).
+- **Preflight freshness**: how long the daemon trusts a cached probe
+  result before the router consults the backend again. Controlled by
+  `authPreflightFreshnessMs` (default 600000 = 10 min). A cached
+  `expired`/`missing` status younger than this window makes the router
+  skip the main backend and route straight to fallback. Set to `0` to
+  disable the pre-flight check entirely.
+- **Recovery**: backend-specific repair. The recommended path is always
+  re-pasting a paid API key on `/settings/models`. If you run on CLI
+  subscription auth instead, you can recover the login from the same
+  page: `/settings/models` exposes a recovery dialog that drives the
+  backend's own interactive login subprocess —
+  `claude auth login --claudeai` (browser OAuth), `codex login
+  --device-auth` (device code), or Gemini's direct OAuth flow. As a
+  manual fallback you can always re-run the backend's CLI login in a
+  terminal yourself.
 
 ## Concrete Examples
 
@@ -77,7 +105,9 @@ routine fails.
 - Operator never registered an API key, ran on the subscription
   fallback, and the underlying `claude` CLI session expired → probe
   fails → card flips amber → recommended fix is to register an API
-  key on `/settings/models`; otherwise re-run the CLI login.
+  key on `/settings/models`. To keep using subscription auth instead,
+  open the recovery dialog on the same page and complete the browser
+  OAuth login it launches.
 
 Cloud-provider credentials (Bedrock / Vertex / Foundry / Azure
 OpenAI / Gemini-Vertex) are not probed against a `models` endpoint —
@@ -85,7 +115,23 @@ those providers trust the SDK's runtime auth chain, so the auth-
 health card stays neutral until the first execution either succeeds
 or surfaces a runtime auth error.
 
+## The "API key recommended" warning
+
+Separate from probe failures, `/settings/models` (and the setup
+wizard's AI Backends step) shows a standing **API-key-recommended**
+warning whenever a backend has no registered key. Skipping the key
+falls the daemon back to that backend's local CLI subscription login,
+which most providers do not officially support for automated agents —
+Anthropic in particular currently prohibits running the Claude Agent
+SDK on a Claude Pro / Max subscription. The warning is advisory, not a
+probe result: it stays visible while you are on the fallback so you can
+register a paid key and leave the gray area.
+
 ## Related
 
-- [Backends and Tiers](backends-and-tiers.md)
-- [Troubleshooting: Auth Failed](../troubleshooting/auth-failed.md)
+- [Backends and Tiers](backends-and-tiers.md) — tiers, models, and
+  fallback routing.
+- [Costs and Quotas](costs-and-quotas.md) — how API-key billing and
+  quota signals interact.
+- [Troubleshooting: Auth Failed](../troubleshooting/auth-failed.md) —
+  step-by-step recovery when a card goes red.