@aitne/daemon 0.1.8 → 0.1.9

package/dist/core/morning/orchestrator.d.ts

@@ -67,12 +67,14 @@ import { type AgentResult, type BackendId, type Event, type ProcessKey } from "@
 import type { AgentConfig } from "../../config.js";
 import type { IAuditLogger, IContextBuilder } from "../dispatcher-types.js";
 import type { PromptAssembler } from "../dispatcher-prompt.js";
-import type { IAgentRouter } from "../backends/backend-router.js";
+import { type IAgentRouter } from "../backends/backend-router.js";
 import type { DispatcherErrorRouter } from "../dispatcher-error-handling.js";
 import type { ResultProcessor } from "../dispatcher-result-processor.js";
 import type { AgentWriteTracker } from "../../safety/agent-write-tracker.js";
 import { type ParentAuditEmitResult, type TodayMdHealth } from "./parent-audit-emitter.js";
 import { type AgentJournalAppenderResult } from "./agent-journal-appender.js";
+import type { DailyJournalComposer } from "./daily-journal-composer.js";
+import { type PartialExtractStreakNotifier } from "./partial-extract-streak.js";
 declare const STAGE_A_PROCESS_KEY: ProcessKey;
 declare const STAGE_B_PROCESS_KEY: ProcessKey;
 /**
@@ -110,10 +112,34 @@ export interface MorningPipelineOrchestratorDeps {
      * not get tagged as a user-actor change by the obsidian / git
      * observers (which would re-trigger the hourly check on the agent's
      * own output). The context-index reconciler is intentionally NOT
-     * threaded here: `agent/journal.md` is not in the indexable set, so
+     * threaded here: `journal/agent.md` is not in the indexable set, so
      * the chokidar fallback path covers it without an explicit hint.
      */
     writeTracker?: AgentWriteTracker;
+    /**
+     * daily-journal-daemon-write.md §4.11 — Stage B's daily journal
+     * compose step. The orchestrator invokes the composer AFTER
+     * `Promise.allSettled` settles both stages and BEFORE
+     * `persistStageAuditRows` so the compose outcome lands on the same
+     * INSERT/UPSERT as the Stage B audit row (`detail.dailyWrite`).
+     *
+     * Optional so the Phase 5 test fixtures that don't exercise the
+     * daily-write path can construct the orchestrator without a real
+     * composer. Production wiring always supplies it; when omitted the
+     * orchestrator skips the compose call entirely (Stage B's audit row
+     * lands without `detail.dailyWrite` and `agent-journal-appender`
+     * falls back to the file-presence heuristic).
+     */
+    dailyJournalComposer?: DailyJournalComposer;
+    /**
+     * daily-journal-daemon-write.md §4.7b — owner-DM emitter the
+     * partial-extract streak detector uses. The orchestrator passes the
+     * existing `sendNotification` chain via a thin adapter so the
+     * detector doesn't depend on Hono / messaging adapters directly.
+     * Optional: when omitted the streak detector still runs (SQL is
+     * cheap, the result is logged), but no DM is emitted.
+     */
+    partialExtractStreakNotifier?: PartialExtractStreakNotifier;
 }
 export interface MorningPipelineRunInputs {
     /**
@@ -182,20 +208,47 @@ export declare class MorningRoutinePipelineOrchestrator {
      */
     run(inputs: MorningPipelineRunInputs): Promise<MorningPipelineRunResult>;
     /**
-     * Write per-stage `agent_actions` rows via `processResult`. Each stage
-     * is processed against its OWN `RoutineEvent` (carrying the stage's
-     * process-key event type), so the row's `action_type` lands as
-     * `routine.morning_routine_today` / `routine.morning_routine_journal`
-     * — exactly what `parent-audit-emitter.readStageSummaries` and the
-     * Phase 6 `agent-journal-appender` will read.
+     * Wrap `agentRouter.resolveBinding` so a resolver-side throw (e.g. a
+     * malformed `process_backend_config` row) doesn't abort the whole
+     * `run()` before either stage gets a chance to dispatch. A null
+     * binding signals "binding unknown" to the failure-path writer; the
+     * resulting `agent_actions(result='failed')` row will lack the
+     * backend / model columns but still pin the failure to a known
+     * stage event. The stage's own `runStage*` will re-throw the same
+     * resolution error on dispatch and that's what
+     * `persistStageAuditRows` records.
+     */
+    private safeResolveBinding;
+    /**
+     * Write per-stage `agent_actions` rows for both success and failure
+     * outcomes. Each stage's row lands keyed on its OWN `RoutineEvent`
+     * (carrying the stage's process-key event type), so the row's
+     * `action_type` is `routine.morning_routine_today` /
+     * `routine.morning_routine_journal` — exactly what
+     * `parent-audit-emitter.readStageSummaries` and the Phase 6
+     * `agent-journal-appender` will read.
+     *
+     * Success path → `processResult` (which calls `audit.logAction`,
+     * settling the in_progress sentinel row to `result='success'`).
      *
-     * Failures inside `processResult` (e.g. a notify hook misbehaving) do
-     * NOT propagate — losing audit rows is bad, but blocking the entire
+     * Failure path → `audit.logError` (which UPSERTs the same in_progress
+     * sentinel to `result='failed'`, preserving the agent-side metadata
+     * column intact). Without the failure-path write, Stage B rejections
+     * (most commonly `BackendQuotaError(max_budget_usd)` from a tight
+     * lite-tier envelope) leave the audit trail with NO Stage B row at
+     * all — `agent-journal-appender.formatJournalLine` then falls into
+     * the `stageB === null` branch and renders `Journal synthesis:
+     * skipped (no prior-day data)`, indistinguishable from a legitimate
+     * first-run skip. This is the structural bug the failure-path write
+     * closes.
+     *
+     * Failures inside `processResult` or `audit.logError` do NOT
+     * propagate — losing audit rows is bad, but blocking the entire
      * morning routine on a downstream telemetry hiccup is worse. In
-     * practice `audit.logAction` already swallows its own DB errors with
-     * an internal logger.error, so the catch here is a defence-in-depth
-     * guard against non-audit hooks (notify side effects we don't expect
-     * for routine events but might land later).
+     * practice `audit.logAction` / `audit.logError` already swallow their
+     * own DB errors with an internal logger.error, so the catches here
+     * are defence-in-depth guards against non-audit hooks (notify side
+     * effects we don't expect for routine events but might land later).
      *
      * Tail-risk acknowledgement: if a stage row truly fails to land
      * (audit's internal try/catch swallowed a real SQLite error AND
@@ -208,6 +261,45 @@ export declare class MorningRoutinePipelineOrchestrator {
      * degrades silently for that day; it does not infinite-loop.
      */
     private persistStageAuditRows;
+    /**
+     * Write a `result='failed'` agent_actions row for a rejected stage.
+     * Uses `audit.logError`, which UPSERTs the matching in_progress
+     * sentinel row when one exists (Stage A's pre-insert) and INSERTs a
+     * fresh row otherwise (Stage B). Both paths land a terminal-state
+     * row keyed on `(event_id=correlationId, action_type=event.type)` so
+     * the downstream readers — `loadMorningRoutineActionRows`,
+     * `parent-audit-emitter.readStageSummaries`,
+     * `agent-journal-appender.formatJournalLine` — see one consistent
+     * shape per stage regardless of which terminal state the stage
+     * reached.
+     *
+     * Backend / model attribution: pulled from the pre-resolved binding
+     * when available, with a fallback to `BackendQuotaError.backendId`
+     * if the binding was unresolvable but the error happens to carry
+     * that field. Other failure shapes leave backend/model unset; the
+     * audit logger's `context` schema tolerates absent values.
+     */
+    private recordStageFailure;
+    /**
+     * daily-journal-daemon-write.md §4.11 — invoke the daily-journal
+     * composer when (a) the orchestrator has a composer dep, (b) Stage B
+     * was actually dispatched (event built), and (c) `buildStageBInputs`
+     * produced the skeleton facts the composer needs. Otherwise return
+     * `null` and let the appender fall back to file-presence detection.
+     *
+     * Reuses the SAME skeleton + counts cached on `stageBInputs` (the
+     * exact byte stream Stage B's prompt saw) rather than re-deriving
+     * against the live DB. Re-deriving was the previous behaviour and
+     * introduced a drift class: if a new DM or calendar observation
+     * landed during Stage A's wall-clock window, the LLM authored against
+     * Skeleton-V1 while the daemon wrote Skeleton-V2 frontmatter; ditto
+     * `updated:` if the agent day rolled over between the two reads.
+     *
+     * Stage B's `AgentResult` may be `null` even when the event was
+     * dispatched (the SDK threw mid-stream); the composer handles that
+     * explicitly via its `stage_b_null` reason.
+     */
+    private composeDailyJournalIfPossible;
     /**
      * ⑥b parent audit emit — the row keyed `action_type='routine.morning_routine'`
      * that `morningRoutineRanToday` in `schedule-helpers.ts` SELECTs on.
@@ -231,7 +323,7 @@ export declare class MorningRoutinePipelineOrchestrator {
     /**
      * morning-routine-optimization.md Phase 6 — ⑥ AgentJournalAppender.
      * Assembles the one-paragraph English audit-trail entry for
-     * `agent/journal.md` from `agent_actions` rows (stage results +
+     * `journal/agent.md` from `agent_actions` rows (stage results +
      * the metadata column Stage A wrote via `PATCH /api/agent-actions/self`)
      * plus `daily/<yesterday>.md` frontmatter. No LLM final-text parsing.
      *
@@ -248,7 +340,7 @@ export declare class MorningRoutinePipelineOrchestrator {
      */
     appendAgentJournalEntry(args: {
         correlationId: string;
-    }): AgentJournalAppenderResult | null;
+    }): Promise<AgentJournalAppenderResult | null>;
     private preInsertStageAInProgressRow;
     private buildHandoffParsedBlock;
     private buildStageBInputs;
@@ -305,8 +397,28 @@ export declare class MorningRoutinePipelineOrchestrator {
     private readForwardCalendarEvents;
     private runStageA;
     private composeStageBEvent;
+    /**
+     * Resolve the `<browser_digest>` block Stage B used to fetch via
+     * `GET /api/context/browser/yesterday-<date>.md`. Now daemon-driven
+     * since Stage B has no tools:
+     *
+     *  1. Gate on integration mode — `browser_history` `disabled` →
+     *     return `null` (no block injection).
+     *  2. File-first — `<contextDir>/browser/yesterday-<date>.md` written
+     *     by the 03:00 cron is the primary surface.
+     *  3. In-process JSON fallback — if the file is absent (daemon was
+     *     down at 03:00 or the file was purged), call
+     *     `runPreMorningDigestJob` in-process to rebuild from SQLite +
+     *     render the markdown shape (no HTTP loopback).
+     *  4. Both unavailable → return `null` (silent skip; the task-flow
+     *     omits the block).
+     *
+     * The block is wrapped in `<browser_digest>...</browser_digest>` to
+     * match the inbound-XML idiom every other ContextBuilder injection
+     * uses (`<fetch_report>`, `<journal_skeleton>`, etc.).
+     */
+    private buildBrowserDigestBlock;
     private runStageB;
     private readStageSummaries;
 }
 export { STAGE_A_PROCESS_KEY, STAGE_B_PROCESS_KEY, STAGE_A_ROUTINE_SLUG, STAGE_B_ROUTINE_SLUG, };
-//# sourceMappingURL=orchestrator.d.ts.map