@aitne-sh/aitne 0.1.9 → 0.1.11

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

@@ -155,6 +155,16 @@ workflow; the skill owns the file contract.
         prioritization call this week
       - Concrete system improvement ideas (tighter silence gates, prompt
         adjustments, missing context features)
+
+      Ground this bucket in the `<self_performance>` block when it is
+      present in your context — it carries the objective 7-day evidence
+      (per-routine run/failure/cost rows, fetch-window empty-run rates per
+      integration, activity-scan gate stage distribution, per-type notification
+      reaction rates, lesson-store byte pressure, and any applied
+      self-tuning changes in `<tuning_ledger>`). Cite its numbers instead
+      of impressions ("gmail pre-pass 78% empty over 40 runs", not "mail
+      fetching feels wasteful"), and do not re-derive any of them by
+      querying APIs.
 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?" →
@@ -307,19 +317,53 @@ workflow; the skill owns the file contract.
      prompt tweak / schedule adjustment / filter rule. "Improve the filter"
      is not testable; "Add Saturday to Weekend day-type default" is)
    ### Metrics (agent side)
-   - Agent plan rows completed: N
-   - Did-not-fire / failed rows: N
-   - Observations reviewed / ignored: N / N
+   - Routine runs (7d): N total / N failed (prev week: N / N)
+   - Spend (7d): $X (prev week: $Y); top cost: <action_type> $Z
+   - Notifications (7d): N sent / N ignored (prev week sent: N)
    ```
+   **The Metrics numbers are copied, never counted.** The
+   `<self_performance>` block in your context is daemon-computed over
+   `agent_actions` / `notification_log` (SELF_TUNING_REVIEW_CYCLE_DESIGN.md
+   §3.1): take total/failed runs, spend, and the prev-week trend from
+   `<totals>`, the top-cost line from the first `<a>` row of `<actions>`,
+   and sent/ignored from `<totals>`'s `notif_*` attributes. Do not recount
+   via API queries, do not estimate from memory, do not "verify" the block
+   by re-querying — that re-spends the tokens this block exists to save.
+   If the block is absent (fresh install, prep failure), write the single
+   line `- metrics unavailable this week` instead of the three lines;
+   never reconstruct the numbers by hand.
    **Hard limits for this block** (the rollup will warn if exceeded):
      - Total section budget: ≤ 4000 bytes (~1000 tokens)
      - Bullet caps: What worked ≤ 5, What slipped ≤ 5, Improvement ideas ≤ 3
-     - Metrics section: exactly 3 numeric lines, no commentary
+     - Metrics section: exactly 3 numeric lines copied from
+       `<self_performance>` (or the single unavailable-line fallback),
+       no commentary
    If you have more than 5 notable items in one subsection, keep only the
    top 5 by actionable impact and drop the rest. Do not try to fit
    everything — the monthly review synthesizes across weeks and surfaces
    recurring items anyway.
 
+   For each concrete, actionable bullet in `### System improvement ideas`,
+   also record a structured self-critique signal:
+
+   ```
+   POST /api/feedback
+   {
+     "source": "self_critique",
+     "summary": "<the specific testable improvement, max 280 chars>",
+     "valence": "neutral",
+     "kind": "do-more",
+     "scope_type": "agent",
+     "action_kind": "agent_execution",
+     "evidence": { "excerpt": "weekly_review YYYY-Www system improvement idea" }
+   }
+   ```
+
+   Post only concrete improvement ideas. Do not post every retrospective
+   sentence, metrics row, or vague wish. If an idea is clearly about one
+   named Agent Definition's output, use `scope_type: "agent_slug"` and
+   `scope_ref` with that slug; otherwise keep `scope_type: "agent"`.
+
    If `journal/agent.md` does not yet exist (GET returns 404), PUT a minimal
    file with just `# Agent Journal\n\n` as header and your new section below
    it, in a single call. Do not abort the review.
@@ -331,6 +375,82 @@ workflow; the skill owns the file contract.
    earlier one within 24 hours. Do not spend tokens trying to locate and
    overwrite the old section in place.
 
+### Phase 3c: Tuning verdicts (only when `<tuning_recommendations>` is present)
+
+9a. If your context contains a `<tuning_recommendations>` block, judge each
+    `<r>` row and submit verdicts. If the block is absent, skip this phase
+    silently — never invent recommendations, never call the endpoint without
+    a block.
+
+    The block is daemon-generated (SELF_TUNING_REVIEW_CYCLE_DESIGN.md §3.2):
+    each row proposes one bounded change (`current` → `proposed`) to a cost
+    knob, backed by 14-day telemetry in `evidence`. Your job is the one
+    thing the rule table cannot do — apply context the numbers don't show.
+    For each row pick exactly one verdict:
+      - `apply` — the evidence matches your understanding of the period and
+        the change is sensible. Example: mail pre-passes really were mostly
+        empty, nothing unusual about the week.
+      - `reject` — the numbers have a context explanation the rule can't
+        see. Example: notifications were ignored because the user was
+        traveling, not because the type is noise; a schedule failed because
+        an integration was temporarily down and is now fixed.
+      - `defer` — plausible but one more week of data would settle it.
+    Every verdict needs a one-line reason (max 280 chars) grounded in this
+    week's context — the reason is the record the owner reads during the
+    shadow period, so "looks fine" is not a reason.
+
+    A row that already carries a `verdict` attribute was judged by an
+    earlier run of this same cycle (same-day re-run) — do not re-judge or
+    re-submit it; verdict only the rows without one. If every row already
+    has a verdict, skip step 9b entirely.
+
+9b. Submit ALL verdicts in a single call:
+
+    ```
+    POST /api/tuning/verdicts
+    {
+      "cycleId": "<the block's cycle attribute>",
+      "verdicts": [
+        { "id": "<r id verbatim>", "verdict": "apply", "reason": "..." },
+        { "id": "<r id verbatim>", "verdict": "reject", "reason": "..." }
+      ]
+    }
+    ```
+
+    Hard rules:
+      - Use the `id` values from the block **verbatim** — the endpoint
+        accepts only the ids the daemon generated this cycle and 400s on
+        anything else. Do not edit keys, values, or propose your own
+        changes through this endpoint.
+      - The block's `mode` attribute tells you what an `apply` verdict
+        does. `mode="shadow"`: verdicts are recorded, nothing is applied —
+        the response carries `shadow: true` and manual application stays
+        the owner's call. `mode="live"`: the daemon applies config-knob
+        `apply` verdicts immediately through its bounded config chokepoint,
+        DMs the owner one line per applied change (with the
+        `!revert tuning` undo), and auto-reverts on measured regression —
+        so treat `apply` as a real action, not a vote. In BOTH modes, do
+        NOT call `PATCH /api/config` yourself for these knobs — the
+        endpoint is the only path that gets bounds, hysteresis, the
+        ledger, and auto-revert right.
+      - In live mode the response's `applied` array is the daemon's
+        receipt. R2 (`notification:<type>`) applies become lesson guidance
+        only; R4 (`recurring_schedules:<id>`) applies become an owner DM
+        suggestion — neither changes machine config.
+      - Do not post a separate `POST /api/feedback` for rejections — the
+        endpoint records the `self_critique` signal server-side from your
+        reason.
+      - A 409 `cycle_expired` / `no_pending_cycle` means the block is stale
+        (e.g. a re-run after a new cycle was generated): drop the step,
+        note it under journal/agent.md "What slipped on my side", move on.
+      - Never mention recommendations, verdicts, or tuning in the
+        user-facing weekly file or the Phase 4 notification — this is agent
+        mechanics, bound by the same audience rule as Phase 3b. In
+        journal/agent.md, record at most a single count line (e.g.
+        "2 tuning changes applied this week") — the daemon already DM'd
+        each change individually, so per-change detail here would
+        double-notify.
+
 ### Phase 4: Notify (user-facing only)
 10. The notification is a brief, warm end-of-week touchpoint for the USER
     — not a report of Phases 1–3. Never mention journal/weekly/YYYY-Www.md,

package/agent-assets/task-flows/schedule.approaching.md

@@ -54,11 +54,11 @@ the user could not see by glancing at their calendar app.
       `calendar:*` is treated as a literal asterisk character and
       matches zero rows.
 
-   2. **`pending=false`** — `routine.hourly_check` consumes
+   2. **`pending=false`** — `routine.activity_scan` consumes
       `actor=user` observations every hour, and calendar mutations
       are tagged `actor='user'` (`calendar-poller.ts:210-212`). A
       `pending=true` query would miss any reschedule older than the
-      latest hourly tick.
+      latest activity-scan tick.
 
    3. **`since=<UTC_24H_AGO>`** — pass the timestamp 24 hours before
       the `utc=` attribute on the `<current_time>` block in your

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

@@ -25,6 +25,27 @@ Task: {event_data[task]}
 - `<task_origin>` — what triggered this run (recurring schedule id,
   source)
 
+## Agent Plan close-out (plan-backed firings)
+
+When this firing matches a pending `## Agent Plan` row in <today>
+(typically a `→wake` row the Morning Routine registered — match HH:MM
++ action text), run these gates BEFORE composing, then close the loop
+per the today skill's Agent Plan lifecycle:
+
+1. **Day-type filter** — if the row's `[category]` focus is `off` on
+   line 2 of <today>, do not send the DM: end with empty output (the
+   delivery path drops zero-length turns) and close the loop with
+   outcome `skipped (focus off)`.
+2. **Premise check** — if the row references a calendar event that
+   <calendar_today> positively shows gone or moved, skip the same way
+   with outcome `skipped (premise gone)`. Missing or unfetchable
+   calendar data is NOT evidence — proceed normally.
+3. **Close the loop** — append the Agent Log entry, then flip the row
+   to `[x]` (annotate skips / failures per the lifecycle).
+
+Recurring briefings and confirm sub-flows with no matching row skip
+this section silently.
+
 ## Conversation-state framing (universal — every dm_session)
 
 Detect state from `<recent_dm_messages>`:
@@ -77,6 +98,7 @@ 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
 - (future sub-flows added here)
@@ -98,6 +120,55 @@ user verbatim — defeating the skip.
 
 ---
 
+## Task delivery
+
+Triggered by `{event_data[task]}` starting 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
+conversation, so weave this into the current thread instead of writing a
+standalone report.
+
+Read `<task_context>` → `task_delivery`:
+
+- `deliveryType: "task_result"` means a task finished. Use `draft` for
+  the compact owner-facing summary and `report` as the fidelity source.
+- `deliveryType: "task_clarification"` means the task is blocked on an
+  answer. Ask the question naturally and briefly; if there is useful
+  `contextSummary`, include only what helps the owner answer.
+- `title` is the human task label. Use it only when it helps orient the
+  owner.
+- `assets` is the list of files the task produced for the owner (each has
+  a `filename`, a `kind` like `screenshot` / `pdf` / `slides` / `image`,
+  and sometimes a `label`). **When `assets` is present, the daemon attaches
+  those files to THIS message automatically** — you do not upload anything.
+  Reference them naturally so the attachment makes sense (e.g. "I've
+  attached the confirmation screenshots" or "the slide deck is attached").
+  When `assets` is absent or empty, do not mention or imply any file.
+- IDs and other internal fields are for daemon routing and audit. Do not
+  expose filenames-as-paths, keys, or IDs in user-facing text.
+
+Delivery rules:
+
+1. Use the conversational state from `<recent_dm_messages>` and
+   `<recent_dm_conversation>` to write a short interruption-preface when
+   the owner is mid-topic. If the recent topic is clear, acknowledge it
+   lightly and hand the floor back after the task note.
+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,
+   `task.delivery`, `scheduled.dm`, artifacts, metadata, API routes,
+   context blocks, or background runners.
+4. 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
+   this turn.
+
+---
+
 ## Morning briefing
 
 Triggered by `{event_data[task]}` starting with `morning briefing`.
@@ -168,6 +239,7 @@ the daily greeting.
    - Calendar updates: events in today→+7d window with updated_at
      >= today 04:00
    - Pending observations: `GET /api/observations?pending=true&actor=user`
+   - Filed background results (§10.5): `GET /api/background-task?state=completed&notify=false&sinceHours=24` — background tasks the user started that finished without clearing the bar to ping (a `silent` task, or an `if_significant` task whose criteria weren't met). Each row carries a `title` and a one-line `significance`. These were deliberately not surfaced when they finished; the briefing is where they get a quiet mention so nothing is silently dropped. Empty list → nothing to mention.
 4. **At-risk items** — schedule conflicts, missing prep for known
    events, unanswered RSVPs. Derive by cross-referencing 1+2+3.
 
@@ -190,6 +262,7 @@ Overnight:
 - (mail) summary
 - (calendar) summary
 - (dm) summary
+- (filed) N background results: <title> (<significance>), …
 
 At-risk:
 - conflict / prep gap
@@ -270,7 +343,10 @@ voice carries the whole message.
 - Maximum ~25 lines total (briefing fits one mobile screen).
 - Schedule list: cap 8, append `...and N more` if over.
 - Tasks list: cap 10, append `...and N more` if over.
-- Overnight: cap 5 per category (mail / dm / calendar).
+- Overnight: cap 5 per category (mail / dm / calendar / filed). For
+  `(filed)`, lead with the count and name at most 3 by title; on a
+  long-quiet day a single line ("N background results filed quietly")
+  is enough — never let filed results crowd out the day's actual shape.
 - No internal names ("Morning Routine", "Agent Plan",
   "scheduled.dm", "state/today.md") in user-facing text.
 - Forbidden openers across all variants: "Morning briefing —",

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

@@ -116,6 +116,12 @@ confirmation.
 ### Step 3: Execute (only if not skipped)
 5. Execute the task. Use Daemon API (curl) as needed.
    Use <today> for day state and <calendar_today> for live calendar events.
+   Premise check first: if the task references a calendar event, confirm
+   it still exists at the expected time in <calendar_today>. Skip only on
+   positive evidence — the event is absent or moved while sibling events
+   show the data is live. Then do NOT execute; proceed to Step 4 with
+   outcome `skipped (premise gone)`. Missing or unfetchable calendar
+   data is NOT evidence — execute normally.
    If the task description is unclear or lacks critical details (who, what,
    when, why), do NOT guess — log `ambiguous task — skipped` to Agent Log
    and proceed to Step 4 with outcome `skipped (ambiguous)`.
@@ -125,7 +131,7 @@ confirmation.
    `- HH:MM [agent_plan] <action summary> — <outcome>`
    Outcome taxonomy: DM sent / notify sent / check-in scheduled /
    skipped (focus off) / skipped (quiet hours) / skipped (user in meeting) /
-   skipped (ambiguous) / failed: <reason>.
+   skipped (premise gone) / skipped (ambiguous) / failed: <reason>.
 7. If Step 1 found a matching Agent Plan row, flip it to `- [x]` via the
    lifecycle recipe in the context skill (GET → edit body → PATCH
    replace section=agent_plan). Annotate per the skill's outcome table:

package/agent-assets/task-flows/wiki.trace.md

@@ -8,6 +8,6 @@ Read `<wiki_command>` for the `topic`. Follow the `wiki-trace` skill:
 2. Order findings chronologically using the most authoritative date available (asserted dates → output filename dates → file `mtime`). Mark any date that came from `mtime` as "discovered on" rather than "happened on".
 3. Group into two to five phases of stable framing. For each phase, name the dominant question, the new evidence, and what changed compared to the previous phase. Cite every claim with a wiki path.
 4. Write one timeline report to `30_outputs/<YYYY-MM-DD>-trace-<slug>.md` through the Wiki API with `x-process-key: wiki.trace`. Follow the section order documented by the skill.
-5. Append a one-line `log.md` entry referencing the output filename and the topic.
+5. The daemon auto-appends the `log.md` entry on the successful write in step 4 — no manual log step is needed.
 
 If the wiki has fewer than two distinct sources on the topic, keep the report short and say so directly in `## Summary` — do not pad it with speculation. End with a short internal summary only.

package/agent-assets/templates/_manifest.json

@@ -14,7 +14,7 @@
     "journal/agent.md": { "version": 1 },
     "knowledge/dossiers/_index.md": { "version": 1 },
     "knowledge/dossiers/evening.md": { "version": 1 },
-    "knowledge/dossiers/hourly.md": { "version": 1 },
+    "knowledge/dossiers/activity-scan.md": { "version": 1 },
     "knowledge/dossiers/monthly.md": { "version": 1 },
     "knowledge/dossiers/morning.md": { "version": 1 },
     "knowledge/dossiers/roadmap.md": { "version": 1 },
@@ -29,7 +29,7 @@
     "policies/redaction.md": { "version": 1 },
     "policies/routines/_index.md": { "version": 1 },
     "policies/routines/evening.md": { "version": 1 },
-    "policies/routines/hourly.md": { "version": 1 },
+    "policies/routines/activity-scan.md": { "version": 1 },
     "policies/routines/monthly.md": { "version": 1 },
     "policies/routines/morning.md": { "version": 1 },
     "policies/routines/weekly.md": { "version": 1 },

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

@@ -14,7 +14,7 @@ Injected into prompts through the root-level context-index.md catalog.
 
 | File | Process key |
 |---|---|
-| `hourly.md` | `routine.hourly_check` |
+| `activity-scan.md` | `routine.activity_scan` |
 | `morning.md` | `routine.morning_routine`, `routine.morning_routine_today` |
 | `evening.md` | `routine.evening_review` |
 | `weekly.md` | `routine.weekly_review` |

package/agent-assets/templates/knowledge/dossiers/{hourly.md → activity-scan.md}

@@ -4,7 +4,7 @@ owner: agent
 updated: 2026-04-17
 template_version: 1
 ---
-# Hourly Check Dossier
+# Activity Scan Dossier
 
 ## Standing checklist
 

package/agent-assets/templates/policies/journal-format.md

@@ -23,7 +23,7 @@ voice, and content all belong to the user.
 
 Agent-side bookkeeping (action counts, internal anomalies, audit
 trail) lives in `journal/agent.md` — not here. If you find yourself
-about to log "the agent ran N tools today" or "the hourly check
+about to log "the agent ran N tools today" or "the activity scan
 fired M times", that belongs in the agent-side log instead. Filter
 it out.
 

package/agent-assets/templates/policies/mcp.md

@@ -17,7 +17,7 @@ This file governs how the agent uses attached Model Context Protocol
   issue, a posted message, an edited doc).
 - Failures are loggable events. On repeated MCP call failures, the agent
   appends to `journal/agent.md` and surfaces the pattern at the next
-  hourly check.
+  activity scan.
 - Scope to the active task. MCP calls unrelated to the current flow's
   stated goal are skipped.
 

package/agent-assets/templates/policies/routines/_index.md

@@ -12,7 +12,7 @@ I've added later via DM). All checks are treated equally.
 
 | File | Cadence | Process key |
 |---|---|---|
-| `hourly.md` | every hour | `routine.hourly_check` |
+| `activity-scan.md` | every 2 h (default) | `routine.activity_scan` |
 | `morning.md` | 04:00 daily | `routine.morning_routine` |
 | `evening.md` | evening | `routine.evening_review` |
 | `weekly.md` | Friday | `routine.weekly_review` |

package/agent-assets/templates/policies/routines/{hourly.md → activity-scan.md}

@@ -1,14 +1,14 @@
 ---
 type: rule
-slug: hourly
+slug: activity-scan
 owner: shared
 updated: 2026-04-17
 template_version: 1
 ---
-# Hourly Check
+# Activity Scan
 
-The daemon fires `routine.hourly_check` at the top of every hour. This
-file is injected verbatim via `policy-files.ts`. Each `### <label>` block
+The daemon fires `routine.activity_scan` every interval (default: every
+2 hours) within active hours. This file is injected verbatim via `policy-files.ts`. Each `### <label>` block
 is one check. All checks are equal — the agent runs them in order,
 skipping any whose preconditions are not met.
 
@@ -26,5 +26,5 @@ skipping any whose preconditions are not met.
 
 ## Skip conditions (applied before any check)
 - Morning routine still in progress (runtime_state flag)
-- Hourly check already running (atomic flag in runtime_state)
+- Activity scan already running (atomic flag in runtime_state)
 - No check has a firing precondition AND pending observations < 2

package/bin/aitne.mjs

@@ -17,6 +17,12 @@ import {
   resolveApiPort,
   resolveDashboardPort,
 } from "../scripts/lib/ports.mjs";
+import {
+  classifyPid,
+  parsePidMeta,
+  readProcessStartToken,
+  serializePidMeta,
+} from "../scripts/lib/process-identity.mjs";
 
 const IS_WINDOWS = process.platform === "win32";
 
@@ -98,18 +104,25 @@ function rotateLogFile(logFile) {
   try { fs.renameSync(logFile, rotated); } catch { /* ignore */ }
 }
 
-function readPid(pidFile) {
+function readPidMeta(pidFile) {
   try {
-    const content = fs.readFileSync(pidFile, "utf8").trim();
-    const pid = parseInt(content, 10);
-    return Number.isFinite(pid) ? pid : null;
+    return parsePidMeta(fs.readFileSync(pidFile, "utf8"));
   } catch {
     return null;
   }
 }
 
+/**
+ * Persist the PID plus a start-identity token so a later `start`/`stop`/`status`
+ * can tell *our* process from a recycled PID after an unclean shutdown. Line 1
+ * stays the bare PID so an older aitne still reads the file. If the OS
+ * start-time read fails we write just the bare PID and degrade to the legacy
+ * unverified-but-trusted behavior. See process-lifecycle-2 in
+ * CROSS_PLATFORM_REAUDIT_2026-06.md.
+ */
 function writePid(pidFile, pid) {
-  fs.writeFileSync(pidFile, String(pid) + "\n");
+  const startToken = readProcessStartToken(pid);
+  fs.writeFileSync(pidFile, serializePidMeta({ pid, startToken }));
 }
 
 function removePid(pidFile) {
@@ -186,11 +199,25 @@ function nextSpawnArgs(dashboardDir, nextBin, userArgs) {
   return userArgs;
 }
 
+/**
+ * Resolve the live PID recorded in `pidFile`, or null. This is the single
+ * chokepoint every command (start/stop/status, plus open/uninstall/doctor via
+ * ctx.helpers) funnels through, so identity reconciliation here fixes them all
+ * at once. A recycled PID (start-time token mismatch) classifies `stale` → the
+ * pidfile is removed and null returned, so `start` won't false-"Already
+ * running" and `stop` won't kill an unrelated tree. `running-unverified`
+ * (legacy file with no token, or an OS start-time read failure) degrades to the
+ * pre-fix bare-PID behavior — no regression; a legacy file self-heals on the
+ * next writePid. verifyStartup() deliberately does NOT route through here: it
+ * checks the freshly-spawned in-memory pid via isAlive + health, preserving its
+ * "alive but health not responding = hung" branch.
+ */
 function getRunningPid(pidFile) {
-  const pid = readPid(pidFile);
-  if (pid == null) return null;
-  if (!isAlive(pid)) { removePid(pidFile); return null; }
-  return pid;
+  const meta = readPidMeta(pidFile);
+  if (!meta || meta.pid == null) return null;
+  const verdict = classifyPid(meta, { readToken: readProcessStartToken, isAlive });
+  if (verdict === "stale") { removePid(pidFile); return null; }
+  return meta.pid;
 }
 
 /**
@@ -314,7 +341,14 @@ async function cmdLogRunner(args) {
     }
   };
 
-  const child = spawn(spec.command, spec.args, {
+  // Under shell:true on Windows, cmd.exe re-parses the line and does NOT
+  // auto-quote the command, so a spaced install path (C:\\Users\\First Last\\...)
+  // would split at the space. Double-quote the command so it stays one token.
+  // POSIX is byte-identical: spec.shell is never true off Windows (the `.cmd`
+  // predicate at the call site is gated on IS_WINDOWS). Args here are static
+  // literals (start --port <n>) with no metacharacters, so they need no escaping.
+  const runCommand = spec.shell === true ? `"${spec.command}"` : spec.command;
+  const child = spawn(runCommand, spec.args, {
     cwd: spec.cwd,
     env: process.env,
     stdio: ["ignore", "pipe", "pipe"],
@@ -427,7 +461,7 @@ async function cmdStart(args = []) {
   // cmd.exe and are kept only as a last fallback.
   const nextBin = resolveNextBin(dashboardDir);
   const dashArgs = nextSpawnArgs(dashboardDir, nextBin, [
-    "start", "--port", String(DASHBOARD_PORT),
+    "start", "--port", String(DASHBOARD_PORT), "--hostname", "127.0.0.1",
   ]);
   const dashboard = spawnLoggedService({
     command: nextBin,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@aitne-sh/aitne",
-  "version": "0.1.9",
+  "version": "0.1.11",
   "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.9",
-    "@aitne/dashboard": "0.1.9",
-    "@aitne/shared": "0.1.9"
+    "@aitne/daemon": "0.1.11",
+    "@aitne/dashboard": "0.1.11",
+    "@aitne/shared": "0.1.11"
   },
   "devDependencies": {
     "@typescript-eslint/eslint-plugin": "^8.58.1",
@@ -72,9 +72,10 @@
     "dev": "node bin/aitne.mjs dev",
     "doctor": "node bin/aitne.mjs doctor",
     "audit": "node bin/aitne.mjs audit",
-    "test": "node scripts/check-redaction-coverage.mjs && vitest run --coverage",
+    "test": "node scripts/check-redaction-coverage.mjs && node scripts/check-dashboard-colors.mjs && vitest run --coverage",
     "test:watch": "vitest",
     "check:redaction": "node scripts/check-redaction-coverage.mjs",
+    "check:colors": "node scripts/check-dashboard-colors.mjs",
     "check:vault-paths": "node scripts/check-vault-path-drift.mjs",
     "lint": "turbo run lint",
     "typecheck:tests": "turbo run typecheck:tests",

package/scripts/commands/doctor.mjs

@@ -12,7 +12,9 @@
 import { execFileSync } from "node:child_process";
 import fs from "node:fs";
 import net from "node:net";
+import os from "node:os";
 import path from "node:path";
+import { pathToFileURL } from "node:url";
 
 export async function run(args, ctx) {
   if (args.includes("--help") || args.includes("-h")) {
@@ -164,7 +166,13 @@ async function checkSecretStore(ctx) {
       return { status: "pass", label: "Secret store", detail: "libsecret (`secret-tool`) reachable" };
     } catch {
       const hasMaster = !!process.env.PA_MASTER_PASSWORD;
-      const keyfile = path.join(ctx.DATA_DIR, "secrets", ".master-key");
+      // The daemon's secret clients hardcode ~/.personal-agent/secrets and do
+      // NOT honor PA_DATA_DIR (secret-client-file.ts:99,209 — homedir-hardcoded;
+      // createSecretClient passes no dir). Probe the same homedir-anchored path
+      // so this diagnostic agrees with where keys are actually read. If the
+      // daemon is ever changed to honor PA_DATA_DIR for secrets, revert this and
+      // fix at the factory (secret-client-factory.ts) instead.
+      const keyfile = path.join(os.homedir(), ".personal-agent", "secrets", ".master-key");
       const hasKeyfile = fs.existsSync(keyfile);
       if (hasMaster || hasKeyfile) {
         return {
@@ -371,7 +379,8 @@ async function checkRepositoryGithubLinkDrift(dataDir) {
         },
       ];
     }
-    Database = (await import(found)).default ?? (await import(found));
+    const mod = await import(pathToFileURL(found).href);
+    Database = mod.default ?? mod;
   } catch (err) {
     return [
       {

package/scripts/lib/process-identity.d.mts

@@ -0,0 +1,46 @@
+/**
+ * Type declarations for the plain-ESM launcher module `process-identity.mjs`.
+ *
+ * `process-identity.mjs` is hand-written JavaScript (it must run before the
+ * TypeScript build, from `bin/aitne.mjs`), so it carries no inferred types.
+ * This sidecar lets the `packages/shared/src/process-identity.test.ts` peer
+ * test typecheck the import under `strict`. Mirrors the `ports.d.mts`
+ * precedent. Keep these signatures in lockstep with the `.mjs` exports.
+ */
+
+/** Parsed pidfile contents. `startToken` is null for a legacy (tokenless) file. */
+export interface PidMeta {
+  pid: number;
+  startToken: string | null;
+}
+
+/** Injectable OS shims for {@link readProcessStartToken} (tests only). */
+export interface ReadTokenDeps {
+  platform?: NodeJS.Platform;
+  execFileSync?: (command: string, args?: readonly string[], options?: unknown) => string | Buffer;
+  readFileSync?: (path: string, encoding: string) => string;
+}
+
+/** Liveness + start-time reader injected into {@link classifyPid}. */
+export interface ClassifyDeps {
+  readToken: (pid: number) => string | null;
+  isAlive: (pid: number) => boolean;
+}
+
+export type PidClassification = "stale" | "running-ours" | "running-unverified";
+
+export function serializePidMeta(input: { pid: number; startToken?: string | null }): string;
+
+export function parsePidMeta(content: string): PidMeta | null;
+
+export function parseLinuxStat(statContent: string): string | null;
+
+export function readProcessStartToken(
+  pid: number | null | undefined,
+  deps?: ReadTokenDeps,
+): string | null;
+
+export function classifyPid(
+  meta: { pid?: number | null; startToken?: string | null } | null | undefined,
+  deps: ClassifyDeps,
+): PidClassification;