@aitne-sh/aitne 0.1.7 → 0.1.8

package/scripts/commands/verify.mjs

@@ -0,0 +1,264 @@
+/**
+ * `aitne verify <target>` — post-launch verification for shipped design
+ * surfaces. Each target bundles a small set of pass/warn/fail checks an
+ * operator runs once after a rollout to confirm the change actually
+ * delivered what it promised.
+ *
+ * Targets:
+ *   - `evening-review-slimdown` — Phase 4 of
+ *     `docs/design/appendices/evening-review-slimdown.md`. Confirms the
+ *     four post-launch invariants the doc lists (cron audit freshness,
+ *     token-envelope drop, conditional notify load, 30-day notify
+ *     invocation sample).
+ *
+ * Verify is read-only and offline. No daemon HTTP call, no DB writes,
+ * no network. Safe to run while the daemon is up (the daemon enables
+ * WAL — concurrent readers are fine) or while it is stopped (we open
+ * the SQLite file in readonly mode).
+ *
+ * The check logic itself lives in
+ * `packages/daemon/src/core/evening-review-verify.ts` so the rulebook
+ * predicate is reused verbatim from the daemon (no drift risk) and the
+ * checks are unit-testable under the daemon's coverage gate. This file
+ * is a thin CLI wrapper: parse args → resolve contextDir → call the
+ * typed runner → render.
+ *
+ * Exit codes:
+ *   0   every check returned pass or warn
+ *   1   at least one check returned fail
+ *   2   argument error / unknown target
+ *   3   the SQLite file or daemon dist is missing
+ */
+import fs from "node:fs";
+import path from "node:path";
+import { fileURLToPath, pathToFileURL } from "node:url";
+
+const KNOWN_TARGETS = new Set(["evening-review-slimdown"]);
+
+export async function run(args, ctx) {
+  if (args.includes("--help") || args.includes("-h")) {
+    printHelp();
+    return;
+  }
+  const opts = parseArgs(args);
+
+  if (!KNOWN_TARGETS.has(opts.target)) {
+    process.stderr.write(`Unknown verify target: ${opts.target}\n`);
+    process.stderr.write(`Available targets: ${[...KNOWN_TARGETS].join(", ")}\n`);
+    process.exit(2);
+  }
+
+  const dbPath = path.join(ctx.DATA_DIR, "data", "personal_agent.db");
+  if (!fs.existsSync(dbPath)) {
+    process.stderr.write(
+      `SQLite file not found at ${dbPath}.\n` +
+        `Has the daemon been started? Run \`aitne start\` first.\n`,
+    );
+    process.exit(3);
+  }
+
+  const verifyMod = await loadVerifyModule(ctx.PROJECT_ROOT);
+  if (!verifyMod) {
+    process.stderr.write(
+      "Daemon dist is missing — `packages/daemon/dist/core/evening-review-verify.js` " +
+        "did not resolve.\nRun `aitne build` first (or `aitne start`, which builds " +
+        "if stale).\n",
+    );
+    process.exit(3);
+  }
+
+  const { loadBetterSqlite3 } = await import("../lib/sqlite-loader.mjs");
+  const Database = await loadBetterSqlite3(ctx.PROJECT_ROOT);
+  const db = new Database(dbPath, { readonly: true, fileMustExist: true });
+
+  let report;
+  try {
+    const contextDir = verifyMod.resolveContextDirFromDb(db, ctx.DATA_DIR);
+    report = verifyMod.runEveningReviewSlimdownChecks({
+      db,
+      contextDir,
+      windowDays: opts.days,
+    });
+  } finally {
+    db.close();
+  }
+
+  if (opts.json) {
+    process.stdout.write(JSON.stringify(report, null, 2) + "\n");
+    process.exit(report.summary.failed > 0 ? 1 : 0);
+  }
+
+  printReport(opts.target, report, ctx);
+  process.exit(report.summary.failed > 0 ? 1 : 0);
+}
+
+// ─────────────────────────────────────────────────────────────────────────
+// CLI parsing
+// ─────────────────────────────────────────────────────────────────────────
+
+function parseArgs(args) {
+  const opts = {
+    target: "evening-review-slimdown",
+    days: 7,
+    json: false,
+  };
+
+  let positional = null;
+  for (let i = 0; i < args.length; i++) {
+    const a = args[i];
+    if (a === "--json") {
+      opts.json = true;
+      continue;
+    }
+    if (a === "--days") {
+      if (i + 1 >= args.length) {
+        process.stderr.write("--days requires a value\n");
+        process.exit(2);
+      }
+      const raw = args[++i];
+      const n = parseInt(raw, 10);
+      if (!Number.isFinite(n) || n <= 0 || n > 365) {
+        process.stderr.write(`--days must be a positive integer ≤ 365 (got: ${raw})\n`);
+        process.exit(2);
+      }
+      opts.days = n;
+      continue;
+    }
+    if (a.startsWith("-")) {
+      process.stderr.write(`Unknown flag: ${a}\n`);
+      process.stderr.write("See `aitne verify --help`.\n");
+      process.exit(2);
+    }
+    if (positional !== null) {
+      process.stderr.write(`Unexpected positional argument: ${a}\n`);
+      process.exit(2);
+    }
+    positional = a;
+  }
+  if (positional !== null) opts.target = positional;
+  return opts;
+}
+
+// ─────────────────────────────────────────────────────────────────────────
+// Daemon module + contextDir resolution
+// ─────────────────────────────────────────────────────────────────────────
+
+/**
+ * Dynamically import the compiled `evening-review-verify` module from
+ * the daemon's dist directory. Returns null when the dist is missing so
+ * the caller can surface a clear "build first" hint instead of a stack
+ * trace.
+ *
+ * Three resolution paths cover every shipping shape:
+ *
+ *   1. Workspace dev — pnpm symlinks `node_modules/@aitne/daemon` →
+ *      `packages/daemon`, so the compiled module sits under the repo's
+ *      own `packages/daemon/dist/`. Direct filesystem path.
+ *   2. Published install — `npm i -g @aitne-sh/aitne` installs
+ *      `@aitne/daemon` as a sibling under `<install>/node_modules/`.
+ *      The daemon's `package.json` only exports `.` (its barrel
+ *      index), so `import("@aitne/daemon/core/...")` is blocked by
+ *      Node's exports-field gate. Resolve the barrel via
+ *      `import.meta.resolve("@aitne/daemon")` to get the daemon root,
+ *      then reach the sibling file directly.
+ *   3. Legacy flatten — historical install layout where `dist/` ended up
+ *      at the project root. Kept as a last-resort fallback so a future
+ *      build/publish change doesn't silently break this CLI.
+ *
+ * The barrel `index.ts` does NOT re-export this module by design —
+ * verify is operator-tooling, not a daemon API surface — so we always
+ * go through the filesystem path rather than `import("@aitne/daemon")`.
+ */
+async function loadVerifyModule(projectRoot) {
+  const candidates = [
+    // 1. Workspace dev (pnpm symlink).
+    path.join(projectRoot, "packages/daemon/dist/core/evening-review-verify.js"),
+  ];
+  // 2. Published install — resolve via the daemon's own package root.
+  try {
+    const daemonMainUrl = import.meta.resolve("@aitne/daemon");
+    const daemonMainPath = fileURLToPath(daemonMainUrl);
+    candidates.push(
+      path.join(path.dirname(daemonMainPath), "core/evening-review-verify.js"),
+    );
+  } catch {
+    // @aitne/daemon not resolvable from this context — fall through to
+    // the legacy candidate below.
+  }
+  // 3. Legacy flatten fallback (defensive).
+  candidates.push(path.join(projectRoot, "dist/core/evening-review-verify.js"));
+
+  for (const candidate of candidates) {
+    if (fs.existsSync(candidate)) {
+      return import(pathToFileURL(candidate).href);
+    }
+  }
+  return null;
+}
+
+// ContextDir resolution lives in the typed daemon module
+// (`resolveContextDirFromDb`) so the degraded-mode branch + tilde
+// expansion are unit-tested in lockstep with `getContextDir`.
+
+// ─────────────────────────────────────────────────────────────────────────
+// Output
+// ─────────────────────────────────────────────────────────────────────────
+
+function printReport(target, report, ctx) {
+  console.log(`${ctx.APP_NAME} verify ${target} — ${report.checks.length} check(s)`);
+  console.log("");
+  const labelWidth = Math.max(...report.checks.map((c) => c.label.length));
+  for (const c of report.checks) {
+    const mark = c.status === "pass" ? "ok " : c.status === "warn" ? "warn" : "FAIL";
+    const label = c.label.padEnd(labelWidth);
+    console.log(`  [${mark}]  ${label}  ${c.detail}`);
+    if (c.hint && c.status !== "pass") {
+      console.log(`           ${" ".repeat(labelWidth)}  hint: ${c.hint}`);
+    }
+  }
+  const { passed, warned, failed, windowDays, installAgeDays } = report.summary;
+  console.log("");
+  console.log(
+    `${passed} ok · ${warned} warn · ${failed} fail · window ${windowDays}d · install age ~${installAgeDays}d`,
+  );
+}
+
+// ─────────────────────────────────────────────────────────────────────────
+// Help
+// ─────────────────────────────────────────────────────────────────────────
+
+function printHelp() {
+  console.log(`Usage: aitne verify [target] [flags]
+
+Run post-launch verification for a shipped design surface. Read-only —
+no daemon HTTP call required, no DB writes, no network. Safe to invoke
+any time.
+
+Targets:
+  evening-review-slimdown    (default)
+        Phase 4 of docs/design/appendices/evening-review-slimdown.md.
+        Bundles four checks:
+          1. Daily 17:45 \`roadmap_mechanical_maintenance\` audit row.
+          2. evening_review session envelope (cost / turns / tokens).
+          3. Conditional notify load (resolveSkillManifest mirror).
+          4. 30-day notify invocations attributable to evening_review.
+
+Flags:
+  --days <N>     Window for time-bounded checks (default 7, max 365).
+                 Capped at install age automatically; the 30-day notify
+                 sample uses min(30, install age) regardless.
+  --json         Machine-readable output. Implies no terminal formatting.
+  -h, --help     Print this message.
+
+Exit codes:
+  0   every check returned pass or warn
+  1   at least one check returned fail
+  2   argument error / unknown target
+  3   SQLite file or daemon dist missing — run \`aitne start\` once first
+
+Examples:
+  aitne verify
+  aitne verify evening-review-slimdown --days 14
+  aitne verify --json | jq '.summary'
+  aitne verify --json | jq '.checks[] | select(.status != "pass")'`);
+}

package/agent-assets/docs/features/routines/monthly-review.md

@@ -1,65 +0,0 @@
----
-schema_version: 1
-slug: features/routines/monthly-review
-title: Monthly Review
-id: monthly-review
-aliases:
-  - monthly retro
-category: features
-summary: |
-  Once a month, the agent rolls up the four weekly retros into a
-  single monthly synthesis under monthly/<YYYY-MM>.md.
-section: routines
-tags:
-  - routine
-  - autonomous
-  - light-tier
-status: stable
-ask_examples:
-  - When does the monthly review fire?
-  - Where do monthly retros live?
-locale: en-US
-created: 2026-04-25
-updated: 2026-04-25
-related:
-  - features/routines/weekly-review
-process_keys:
-  - routine.monthly_review
----
-
-# Monthly Review
-
-## In One Sentence
-
-Light-tier monthly retro that synthesizes the four weekly reviews into
-a single monthly file.
-
-## What It Does
-
-- Reads the past month of weekly retros.
-- Surfaces threads, recurring patterns, and unfinished pushes.
-- Writes the synthesis into `monthly/<YYYY-MM>.md`.
-
-## When It Runs / How It Is Triggered
-
-The **last day of the calendar month at 18:00 local time**. The schedule
-is fixed in `packages/daemon/src/core/scheduler.ts` and is not
-operator-configurable.
-
-## What It Outputs
-
-- A single `monthly/<YYYY-MM>.md` file.
-
-## Configuration
-
-This routine has no operator-tunable knobs. The fire time, day-of-month,
-and tier are fixed in code.
-
-## When Something Goes Wrong
-
-- A late-month install will skip the first month's retro because
-  there are not four weekly retros to synthesize yet.
-
-## Related
-
-- [Weekly Review](weekly-review.md)

package/agent-assets/skills/management-task-modify/SKILL.md

@@ -1,203 +0,0 @@
----
-name: management-task-modify
-description: Change cadence, intent, or output path on an existing managed task (`mt_<n>`) from a DM — "move daily Zoom check to 9am", "switch Gmail triage to Mondays". Owns PATCH on §B rows. SKIP for new registrations, stops, or app changes.
-when_to_use: User wants to keep a managed task running but adjust its cadence / intent / output path. SKIP for new registrations (`management-task-register`), stops (`management-task-stop`), or one-off run-now (`POST /api/managed-tasks/:id/run-now`).
-allowed-tools:
-  - Bash(curl *)
-  - Bash(jq *)
-  - Read
----
-
-# Modify a Managed Task
-
-Changes the cadence, intent, or `Output path` on an existing
-`mt_<n>` row in place. The `mt_id` is preserved across modifications
-so historical references in `agent_actions` and
-`_activity/<source>.md` remain unambiguous (§10.2).
-
-## When to use
-
-The user clearly references an existing recurring commitment and asks
-to change its **cadence**, **intent text**, or **output path**:
-
-- "Move the Zoom check to 9am instead of 10am"
-- "Switch the Gmail invoice triage to every Monday"
-- "Send Drive receipts to `finance/receipts/` instead of `personal/receipts/`"
-- "Rename the intent on `mt_42` to `Zoom recordings → meeting notes`"
-
-## When NOT to use
-
-| Shape | Use instead |
-|---|---|
-| New recurring commitment | `management-task-register` |
-| User wants to stop / pause it | `management-task-stop` (no soft-pause; hard-delete + re-register if they want to resume) |
-| User wants to run once off-schedule | `POST /api/managed-tasks/<id>/run-now` |
-| User wants to change which **app** an existing task targets | `management-task-stop` then `management-task-register` (different connector ⇒ different commitment) |
-| User wants to change the SoT for a category | `PUT /api/sot-bindings` (A-section flow) |
-
-A change of `app` is a different commitment — stop and re-register
-rather than mutating the row, because the connector probe must run
-fresh and the entity-mirror associations may differ.
-
-## Algorithm (mirror of design 21 §10.2)
-
-### Step 1 — Locate the row
-
-Read the registry and find the row the user means. If the user named
-an `mt_<n>` directly, fetch by id; otherwise dedup by `(app, cadence,
-intent)` the same way `management-task-register` does.
-
-```bash
-# By id when the user said "mt_42":
-curl -s "http://localhost:8321/api/managed-tasks/mt_42" | jq .item
-
-# By app fuzzy lookup:
-curl -s "http://localhost:8321/api/managed-tasks" | jq '.items[] | select(.app_normalized == "zoom")'
-```
-
-GET-by-id wraps the row in `{item:<row>}`; the list returns
-`{items:[…], count:N}`.
-
-If no row matches, DM:
-
-> No managed task for `<app>` is registered. Want me to register one?
-
-If multiple rows could plausibly match, list them with id + cadence +
-intent and ask the user to pick. Stop until they reply.
-
-### Step 2 — Diff the requested change
-
-Map the user's request to one or more of these fields:
-
-| User request | PATCH field | Notes |
-|---|---|---|
-| "9am instead of 10am" / "every Monday" | `cadence` + `recurrenceRule` (send both together) | Same `recurrenceRule` shape as `management-task-register` Step 5; only `daily`/`weekly`/`monthly` are representable |
-| "Rename intent" / "describe it as `<text>`" | `intent` | ≤ 200 chars, NFC, no `\n`, no `\|` |
-| "Send to `<dir>/`" | `output_path` | Validate against §9.3 (`<domain>/<type-plural>/`, trailing `/`, no `..`); send `null` to clear |
-
-If the request implies **app change**, stop and route the user to
-"stop + re-register" (Step 1 disambiguator above).
-
-### Step 3 — Confirm with the user before mutating (Notify tier)
-
-PATCH on a managed task is **Notify tier** (§13.1). DM the user
-verbatim with the proposed change and wait for an explicit yes:
-
-> `mt_42` Zoom check — change cadence from `daily 10:00 (Asia/Tokyo)`
-> to `daily 09:00 (Asia/Tokyo)`?
-
-Only after the user confirms do you issue the PATCH. If they decline
-or amend, restart at Step 2 with the new shape.
-
-When the user's confirmation also implies a different output path
-("…and write into `work/meetings/agendas/`"), include both fields in
-one PATCH so the audit row reflects the user's actual intent in a
-single transition.
-
-### Step 4 — PATCH /api/managed-tasks/:id
-
-```bash
-curl -sS -X PATCH http://localhost:8321/api/managed-tasks/mt_42 \
-  -H 'Content-Type: application/json' \
-  -d @- <<'JSON'
-{
-  "cadence":     "daily 09:00 (Asia/Tokyo)",
-  "recurrenceRule": {
-    "frequency": "daily",
-    "time":      "09:00",
-    "timezone":  "Asia/Tokyo"
-  }
-}
-JSON
-```
-
-| Field | When to send | Notes |
-|---|---|---|
-| `cadence` + `recurrenceRule` | Cadence change | Send both together so the rendered §B label matches the executable schedule. PATCH body must include at least one mutable field; an empty body returns `validation_error`. |
-| `intent` | Intent rename | ≤ 200 chars; trimmed + NFC at the boundary |
-| `output_path` | Output relocation | `<domain>/<type-plural>/` per §9.3; `null` clears it (back to "first run decides") |
-
-`app` / `app_normalized` / `last_run_at` / `last_result` /
-`consecutive_failures` are NOT mutable through this PATCH. Run-result
-writes go through the internal `/run-result` route used by
-`scheduled-managed-task`; app rename goes through the dedicated
-`POST /api/managed-tasks/:id/rename-app` (Step 1 disambiguator above
-already routes that case to "stop + re-register" for safety).
-
-The server-side transaction:
-
-a. UPDATEs `recurring_schedules` (if `recurrenceRule` changed),
-b. UPDATEs `managed_tasks.{intent,cadence,output_path,updated_at}`,
-c. re-renders `rules/management.md` from DB (locked + snapshotted),
-d. INSERTs `agent_actions` (`action_type='management_task.modified',
-detail={changed, from, to}`).
-
-The response is `{status:"updated", item:<ManagedTask>, render_status}`.
-
-The `mt_id`, `last_run_at`, `last_result`, and
-`consecutive_failures` are preserved across the PATCH — history is
-continuous (§10.2).
-
-A cadence change cancels any in-flight `agent_schedule` row tied to
-the old cron; the new cron takes effect from the next eligible slot.
-Do not separately DELETE `agent_schedule` items — the daemon owns
-that.
-
-**Output-path relocation does NOT move existing entity files.** Past
-entities stay where they were written. If the user wants
-re-organization, stop the task, move the entity files manually (or
-ask the user to), and re-register.
-
-### Step 5 — Confirm to user
-
-One DM, persona-tone (`notify` skill discipline applies). Read the
-resolved fields from the PATCH response — do NOT echo what you sent
-in case the daemon normalized something:
-
-> Updated `mt_42` Zoom check — now daily 09:00 JST. Next run 2026-12-05 09:00 JST.
-
-If the PATCH only changed `intent` or `output_path` (no cadence
-shift), do not announce a "next run" line — the next firing is
-unchanged.
-
-## Error envelope
-
-| HTTP | `error` | What to do |
-|---|---|---|
-| 400 | `invalid_id` | The `:id` segment didn't match `^mt_[1-9]\d*$`; the user typed the id wrong — ask them to repeat |
-| 400 | `validation_error` | Body has Zod `details`; pin the failing path (e.g. `recurrenceRule.daysOfWeek` not allowed for `daily`) and ask for a fix |
-| 404 | `not_found` | DM "I don't have an `mt_<id>` to modify"; offer to register one |
-| 5xx | `internal_error` | Surface `body.message` if present; advise `aitne logs` |
-
-The daemon does not currently emit `cron_too_tight` (the recurrence
-schema only accepts daily/weekly/monthly — sub-daily is impossible),
-nor `cadence_partial` (the recurrence rule is one structured field, so
-there is no partial-cadence shape to reject). If a future schema gain
-adds them, surface them verbatim.
-
-## What this skill does NOT do
-
-- Does NOT mutate `app` — that is a different commitment, stop +
-  re-register.
-- Does NOT pause / disable a task — there is no soft-pause; stop +
-  re-register if the user wants a hiatus.
-- Does NOT touch §A (SoT bindings) or §C (Active Policies).
-- Does NOT PUT `rules/management.md` directly. The daemon owns the
-  file write.
-- Does NOT migrate entity files when `output_path` changes; only
-  future runs honor the new path.
-- Does NOT auto-confirm "this looks right" — Notify-tier means a real
-  user-facing confirmation. Output language: follow
-  `<output_language_policy>`.
-
-## API summary
-
-| Verb + path | Used in |
-|---|---|
-| `GET /api/managed-tasks` | Step 1 (lookup by app/cadence) |
-| `GET /api/managed-tasks/:id` | Step 1 (lookup by id) |
-| `PATCH /api/managed-tasks/:id` | Step 4 (Notify-tier) |
-| `POST /api/notify` | Step 5 (user-facing confirmation) |
-
-The PATCH writes one `agent_actions` row and snapshots the file —
-do NOT post a separate audit event yourself.