@aitne/daemon 0.1.7 → 0.1.9

package/dist/core/skills-compiler.d.ts

@@ -1,33 +1,7 @@
+import type DatabaseNs from "better-sqlite3";
 import { type BackendId, type IntegrationKey, type IntegrationState, type ProcessKey } from "@aitne/shared";
 import type { MailAccount } from "../services/mail/provider.js";
-export declare const logger: import("pino").Logger<never, boolean>;
-interface SkillCompilerFile {
-    path: string;
-    content: string;
-    updatedAt: string | null;
-}
-interface WikiWorkspaceTokens {
-    vault_path: string;
-    language: string;
-    workspace_name: string;
-    schema_version: string;
-}
-export declare function setWikiWorkspaceTokenResolver(resolver: ((processKey: string, workspaceName?: string) => WikiWorkspaceTokens | null) | null): void;
-export declare function missingDelegatedVariants(workspaceDir: string, integrationKey: IntegrationKey, delegatedBackend: BackendId): {
-    skills: string[];
-    taskFlows: string[];
-};
-/**
- * INTEGRATION_NATIVE_MODE_DESIGN.md §7.4 / §8.5 — symmetric to
- * {@link missingDelegatedVariants} for the new `native` mode. Used by
- * the PATCH route's pre-commit hard reject and (Phase B2 onwards) by
- * `skills-manifest.test.ts` to assert variant existence on every
- * supported `(integration, native backend)` pair before a release.
- */
-export declare function missingNativeVariants(workspaceDir: string, integrationKey: IntegrationKey, nativeBackend: BackendId): {
-    skills: string[];
-    taskFlows: string[];
-};
+import { type SkillCompilerFile } from "./skills-compiler-tree.js";
 interface SessionPromptBundleParams {
     backendId: BackendId;
     sessionDir: string;
@@ -61,6 +35,46 @@ interface SessionPromptBundleParams {
         skillSlugs: readonly string[] | null;
         profileBody: string | null;
     };
+    /**
+     * `evening-review-slimdown.md` §2.1 — runtime context root used by
+     * `resolveSkillManifest` to apply per-event predicates (today: the
+     * evening rulebook gate that decides whether `notify` is loaded for
+     * `routine.evening_review`).
+     *
+     * Optional and default-`undefined` — events without a predicate ignore
+     * this field entirely, so non-evening call sites do not need to plumb
+     * it through. When omitted on an evening session, the gate evaluates to
+     * "rulebook inactive" and the conservative `notify`-dropped manifest
+     * wins. Production call sites always pass `getContextDir(config)`.
+     */
+    contextDir?: string;
+    /**
+     * docs/design/appendices/skills-improvement.md §9-§11 + §14 — DB handle threaded into
+     * `gmailLifestyleActive` / `managedTasksActive`. Undefined →
+     * predicates return the conservative include branch.
+     */
+    db?: DatabaseNs.Database | null;
+    /**
+     * docs/design/appendices/skills-improvement.md §9-§11 + §14 — inbound DM message text
+     * for the `*ForDm` trigger-phrase fallback. Undefined / null for
+     * routine and scheduled events that have no user-typed text.
+     */
+    messageText?: string | null;
+    /**
+     * AGENT_DEFINITIONS_DESIGN.md §4.2 — an Agent definition's `tools.skills`.
+     * Composed onto the process-key default bundle via `composeSkillSet`
+     * (union, or replace when `skillsReplace` is set). Empty / undefined is a
+     * no-op, so non-Agent materialisation sites are unaffected. The dispatcher
+     * resolves this from the firing Agent's effective definition and threads it
+     * through `AgentExecuteParams.extraSkills`.
+     *
+     * Ignored when a bang-command `override.skillSlugs` is present — that
+     * surface already replaces the manifest verbatim and never co-occurs with
+     * an Agent firing.
+     */
+    extraSkills?: readonly string[];
+    /** AGENT_DEFINITIONS_DESIGN.md §4.2 — `tools.skills_replace`. See `extraSkills`. */
+    skillsReplace?: boolean;
 }
 /**
  * Materializes backend-specific instruction files for session workdirs
@@ -133,7 +147,7 @@ export declare class SkillsCompiler {
     /**
      * P22 — skill-curation overlay context. When set, the materializer runs an
      * extra pass that resolves `<!-- CURATION:<kind> id="<id>" -->` anchors in
-     * each skill's SKILL.md against `<dataDir>/skills/overlays/<slug>/<id>.json`
+     * each skill's SKILL.md against `<dataDir>/skill-curation-overlays/<slug>/<id>.json`
      * (overlay) or `agent-assets/skills/<slug>/seeds/<id>.seed.json` (seed).
      *
      * Optional and default-OFF — daemon code is expected to call
@@ -161,10 +175,10 @@ export declare class SkillsCompiler {
      * §4.7 "Missing-variant policy": if any paths come back, the caller
      * should refuse to enter delegated mode or at least log a loud warning.
      * The per-integration variant for the hypothetical PATCH path lives in
-     * the standalone `missingDelegatedVariants` helper below; this method
-     * aggregates across every currently-delegated integration using its
-     * declared `delegatedBackend` (not the session backend — see the helper
-     * docstring for the rationale).
+     * `missingDelegatedVariants` in `./skills-compiler-variants.js`; this
+     * method aggregates across every currently-delegated integration using
+     * its declared `delegatedBackend` (not the session backend — see the
+     * helper docstring for the rationale).
      */
     validateDelegatedVariants(): {
         skills: string[];
@@ -224,6 +238,93 @@ export declare class SkillsCompiler {
      */
     private composeClaudeProfileFromBody;
     private materializeClaudeSession;
+    /**
+     * docs/design/appendices/skills-unification.md Phase 1 — per-backend skill-dir writer.
+     *
+     * Writes `<sessionDir>/<destSkillsRootRelative>/<slug>/SKILL.md` for each
+     * slug, applying the full per-skill transformation pipeline:
+     * variant resolution → brand tokens → partial / reference inlining →
+     * service strip → mode filter → deny filter → curation splice → mail
+     * `accounts.md`. The destination directory is the only thing that varies
+     * across backends:
+     *
+     *   - Claude  → `.claude/skills`
+     *   - OpenCode → `.opencode/skills`
+     *   - Codex   → `.codex/skills`
+     *   - Gemini  → `.gemini/skills`
+     *
+     * For Codex sessions, this method ALSO prepends a one-line read-sensitive
+     * banner to each materialised SKILL.md whose body references a read-
+     * sensitive `/api/*` endpoint (those endpoints 401 on Codex because the
+     * Codex backend does not hold the read-sensitive token). The banner
+     * points the agent at the `## Read-sensitive endpoints are UNAVAILABLE`
+     * section already rendered into `AGENTS.md`.
+     *
+     * Returns the list of slugs that ended up on disk (slugs whose variant
+     * resolved to `null` for same-backend native MCP and slugs whose source
+     * SKILL.md was missing are excluded). Callers use this list to render
+     * the `<skill-index>` block from a stable, post-materialisation source.
+     */
+    private writeSkillsDir;
+    /**
+     * docs/design/appendices/opencode-backend.md §6.5 / Phase 4 — opencode-specific
+     * materialisation.
+     *
+     * Three on-disk artefacts are written per session:
+     *   1. `AGENTS.md` (cwd-auto-discovered by opencode per V1) — same
+     *      shape as `materializeCliSession` produces for Codex EXCEPT
+     *      skill bodies are NOT inlined (skills auto-discover from
+     *      `.claude/skills/` via opencode's `skill` tool — V2). Includes
+     *      safety, character, behavioral rules, daemon-API, integration
+     *      routing tables, and the runtime profile body.
+     *   2. `.opencode/agent/<profile-slug>.md` (singular `agent/` per V5)
+     *      — the per-process agent persona with V5-correct frontmatter
+     *      (`mode: primary`, `permission` block keyed only on
+     *      `edit/bash/webfetch/doom_loop/external_directory` — NO `read`
+     *      key per V5 contract). Body is the profile body; opencode
+     *      invokes this via `session.prompt({ body: { agent: <slug> } })`
+     *      so the per-agent permission overrides the server-level
+     *      defaults.
+     *   3. `.opencode/skills/<slug>/` via `writeSkillsDir` — every
+     *      manifest skill becomes a discoverable SKILL.md tree opencode
+     *      reads on `skill` tool activation. `.claude/skills/` is
+     *      intentionally NOT written: docs/design/appendices/skills-unification.md Phase 1
+     *      flipped opencode from V2 path (b) (`.claude/skills/`
+     *      redundancy-avoiding alias) to V2 path (c) (`.opencode/skills/`)
+     *      so each backend lives under its own brand-aligned namespace.
+     *
+     * The dispatcher passes `agent: <slug>` (where `<slug>` matches the
+     * profile filename without `.md`) on every `session.prompt` call so
+     * the right agent file is selected.
+     */
+    private materializeOpencodeSession;
+    /**
+     * docs/design/appendices/opencode-backend.md §6.5 / V5 — write the per-process agent
+     * profile to `.opencode/agent/<slug>.md` (singular `agent/`; the
+     * plural form does NOT register per V5).
+     *
+     * Frontmatter shape (V5-correct keys only):
+     *   - `mode: primary` — opencode's primary-agent mode; subagent is
+     *     reserved for the disabled `task` tool path.
+     *   - NO `permission` block here — the server-level
+     *     `OpencodeRuntimeConfig.permission` is the per-session truth and
+     *     is stricter for narrow agents (delegated runs use a separate
+     *     `delegated-<callId>` agent file with its own tight permission).
+     *     Emitting `permission: {}` here would NOT widen anything (the
+     *     server-level deny still wins), but the absence keeps the
+     *     frontmatter a manifest and avoids drift between two seats.
+     *   - NO `model` field — opencode falls back to `OPENCODE_CONFIG_CONTENT.model`
+     *     (set per-session by `OpencodeCore`'s runtime-config builder),
+     *     and the dispatcher additionally overrides per `session.prompt`
+     *     body. Pinning here would either drift from the per-call value
+     *     or duplicate it.
+     *
+     * Body composition mirrors AGENTS.md (safety + character + profile)
+     * so an `agent: <slug>` invocation that REPLACES opencode's default
+     * cwd context still gets safety/character rules — V5 confirmed the
+     * agent body becomes the system prompt for that turn.
+     */
+    private writeOpencodeAgentFile;
     /**
      * P22 §1.5 — splice CURATION anchors in a single skill's materialized
      * SKILL.md against overlay/seed JSON. Pure file I/O — overlay store
@@ -231,190 +332,41 @@ export declare class SkillsCompiler {
      * no curation context is configured or when the skill has no anchors.
      */
     private spliceCurationAnchorsInSkill;
+    /**
+     * docs/design/appendices/skills-unification.md Phase 1 item 15 — the slim path does NOT
+     * emit a `<skill-index>` block or the skill-discovery preamble. The
+     * fetch_window system prompt is a self-contained operational contract
+     * (one-window-one-curl, no sub-tasks, exactly-one JSON-on-stdout) and
+     * the only skill copied (`observations`) is referenced inline by the
+     * runner-emitted user prompt. Adding the index would mis-signal the
+     * fetcher to scan for skills before executing the acquisition plan.
+     *
+     * docs/design/appendices/fetch-window-cost-reduction.md Phase 1.5 — slim instruction-file
+     * materializer for `routine.fetch_window` on Codex / Gemini CLI.
+     *
+     * Mirrors the Claude SDK's Phase 1 systemPrompt swap (the same
+     * `agent-assets/system-prompts/routine-fetch-window.md` template is the
+     * single source of truth): write the slim body verbatim as AGENTS.md /
+     * GEMINI.md and copy only the `observations` skill — the
+     * `/api/observations/batch` POST contract is the fetcher's sole
+     * structural assertion. The integration partial inlined by the runner
+     * (`routine-fetch-window-runner.ts:reassemblePrompt`) covers the
+     * per-attempt call shape, so `mail` / `notion` / `external-services` /
+     * `attach` skill bodies are deliberately omitted.
+     *
+     * No safety preamble / character / behavioral-rules / daemon-API
+     * sections — the slim template restates the only rules the fetcher
+     * needs (localhost-only curl, no sub-tasks, no context writes, no
+     * notify, JSON-on-stdout-and-exit). The destructive-action policy layer
+     * (absolute-block list, Codex sandbox, Gemini admin TOML) still applies
+     * unchanged at runtime.
+     *
+     * The `<mcp-servers>` section is appended downstream by
+     * `services/mcp/session-materializer.ts:appendMcpSection` exactly as on
+     * the wide path — Phase 3's allowlist filter, when it lands, will scope
+     * that section without further changes here.
+     */
+    private materializeFetchWindowCliSession;
     private materializeCliSession;
 }
-export declare const EMPTY_MAIL_ACCOUNTS_MD: string;
-export declare function renderMailAccountsMd(accounts: readonly MailAccount[]): string;
-/**
- * Return the backend-specific skills directory name for a given backend.
- * Returns null for Claude (which uses `.claude/skills/` managed separately).
- */
-export declare function cliSkillsDirName(backendId: BackendId): string | null;
-/**
- * Rewrite the `## Character (user-defined)` block inside every backend
- * instruction file that currently lives in `workdir`. Used by the
- * `PATCH /api/config` live-overwrite path (§15.6.1) so an owner editing
- * character on the dashboard doesn't have to wait for the next session
- * spawn for the change to land.
- *
- * Multi-backend aware: a workdir that has seen a Claude→Codex fallback
- * contains both CLAUDE.md and AGENTS.md, and both must end up byte-
- * identical in their character block. Each write is atomic (tmp +
- * rename, both on the same filesystem so rename stays cheap) and
- * per-file errors are logged without failing the whole call.
- *
- * Returns a summary of how many files were rewritten. Useful for
- * instrumentation and for the dashboard PATCH handler to log.
- *
- * The helper is an FS wrapper: its pure parse/compose half lives in
- * `character-block.ts` and is covered 100% there. This side is excluded
- * from coverage along with the rest of `skills-compiler.ts`.
- */
-export declare function rewriteCharacterBlock(workdir: string, character: string): {
-    rewritten: number;
-    skipped: number;
-    failed: number;
-};
-/**
- * Strip service sections from external-services/SKILL.md that correspond to
- * unconfigured integrations. Sections are delimited by HTML comments:
- *   <!-- service:calendar --> ... <!-- /service:calendar -->
- * When `configuredServices` is empty the content is returned unchanged — the
- * "no services configured yet" case keeps every section so the agent can see
- * the full menu. Only strips once the user has configured at least one
- * service (and therefore expressed an intent to narrow the surface).
- */
-export declare function stripUnconfiguredServices(content: string, configuredServices: ReadonlySet<string>): string;
-/**
- * Adapt a SKILL.md for CLI backends (Codex / Gemini): retain only `name`,
- * `description`, and `when_to_use` frontmatter fields, stripping
- * Claude-specific fields like `allowed-tools`. The body content is
- * preserved unchanged.
- *
- * `when_to_use` is the secondary trigger-shape clarification documented
- * in `SKILLS-PHASE-2-PLAN.md` §3.2 / §5; the Claude Agent SDK reads it
- * verbatim from `q.when_to_use` (verified against
- * `claude-agent-sdk@0.2.98/cli.js`). Preserving it on the CLI side keeps
- * the per-backend skill frontmatter aligned even though Codex / Gemini
- * do not currently consume the field — drift would surface as a missing
- * activation hint when they eventually do.
- *
- * Assumes `name`, `description`, and `when_to_use` are each single-line
- * YAML scalars (no `|` / `>` block forms). A multi-line `when_to_use:`
- * is matched only by its first line — the `.+` regex stops at the
- * newline — but since YAML block scalars start with the line that
- * contains only `|` or `>`, the captured value would be the empty
- * indicator and the inlined value would be useless. Phase 2 v1 keeps
- * this conservative: callers must use single-line scalars (NG5).
- */
-export declare function adaptSkillForCli(content: string): string;
-/**
- * Resolve `{{> base }}` include directives in a skill/task-flow variant file.
- * Reads `SKILL.base.md` (or `<key>.base.md` for task flows) from `basePath`
- * and replaces every occurrence of `{{> base }}` with the base file's content
- * (frontmatter stripped). A missing or empty base file is silently ignored.
- *
- * Only `{{> base }}` is supported — this is intentionally minimal (§4.7
- * design note: "~40 lines of pure TS").
- *
- * @deprecated DELEGATED-PROXY-API-DESIGN.md §11 — after Phase D no in-tree
- * skill uses `{{> base }}`: mail / external-services unified their bodies
- * during Phase D, and the lone surviving `notion/SKILL.base.md` was
- * removed in Phase 9 (its hourly-check read-only constraint moved to
- * `routine.hourly_check.md` task-flow where the rule applies in every
- * integration mode, including same-backend delegated where the skill
- * body is dropped). The helper is retained for future composition needs;
- * remove the call sites in `materializeClaudeSession` /
- * `materializeCliSession` when no consumer reappears.
- */
-export declare function renderPartialIncludes(content: string, basePath: string): string;
-/**
- * Resolve `{{> ref:<name> }}` directives in a skill body by inlining
- * `references/<name>.md` (frontmatter stripped) from the skill's source dir.
- *
- * Mirrors `renderPartialIncludes` but is intra-skill, not cross-skill: each
- * skill carries its own `references/` dir. Used by progressive-disclosure
- * skills (planned for `mail`, `roadmap`, `reading`, `user-interview` after
- * Phase 2-B) so heavy reference tables can live next to the skill body
- * without bloating the navigation overview.
- *
- * Behaviour:
- *  - Missing `references/<name>.md` → directive replaced with empty string;
- *    logged at WARN. (Mirrors the deprecated helper's missing-base behaviour.)
- *  - The directive matches `{{> ref:<name> }}` with the strict-kebab name
- *    pattern `[a-z][a-z0-9-]*`. Path-traversal (`../`, leading underscore,
- *    uppercase) is rejected at the regex level — `existsSync` is never
- *    consulted for invalid names.
- *  - Multiple occurrences each inline the same file's content (re-read per
- *    occurrence — pinned by the unit tests so a later caching refactor must
- *    surface as a deliberate change).
- *  - Frontmatter on the reference file (if present) is stripped before
- *    inline, so reference files can carry `---\nkind: reference\n---`
- *    headers for tooling without leaking YAML into skill bodies.
- *  - The resolver is NOT fence-aware; a directive inside a triple-backtick
- *    fence is still expanded. This matches `renderPartialIncludes` and is
- *    deliberate for v1 — fence-aware resolution would be a separate refactor.
- *
- * Phase 2-A ships compiler-only; no in-tree skill carries a directive yet
- * (`skills-manifest.test.ts` pins `0` as the lockstep count). Phase 2-B
- * starts emitting them per the migration map in `SKILLS-PHASE-2-PLAN.md`.
- */
-export declare function renderReferenceIncludes(content: string, skillSrcDir: string): string;
-/**
- * §7.7 — apply the per-integration tool-deny policy to a delegated skill
- * body. Two enforcement modes:
- *
- *  - **Claude (hard enforcement):** parse the YAML frontmatter and remove
- *    every `allowed-tools` entry whose unsuffixed name (after the
- *    descriptor's `toolNamespace`) is in `deniedTools`. The Claude Agent
- *    SDK refuses to invoke any tool not present in `allowed-tools`, so
- *    this is hard enforcement at the SDK boundary.
- *
- *  - **Codex / Gemini (soft enforcement):** append a "Denied tools (do
- *    not invoke)" prose block at the end of the skill body listing the
- *    full namespaced tool names. The CLI surfaces have no per-tool deny
- *    mechanism comparable to Claude's `allowed-tools`; the prose is the
- *    only guard. Documented soft-enforcement gap.
- *
- * Stale entries (a deniedTools name that doesn't match any tool in the
- * active backend's `capabilityTools`) are silently ignored — the API
- * already rejects them at PATCH time, but a delegatedBackend swap can
- * leave Claude-namespaced names in a list now active for Codex.
- *
- * Run AFTER `renderPartialIncludes` and `stripUnconfiguredServices` so
- * partial includes and service-section gating land first.
- */
-export declare function applyDeniedTools(content: string, integrationKey: IntegrationKey, backendId: BackendId, deniedTools: readonly string[]): string;
-/**
- * DELEGATED-MODE-V2-DESIGN.md §4.3.3-§4.3.4 — render a top-level prose
- * deny block listing every same-backend integration tool the user has
- * denied. Returns `null` when no integration is in same-backend mode for
- * this backend or the deny lists are empty.
- *
- * Codex (γ outcome): this prose is the ONLY enforcement surface — the
- * Codex CLI's connector apps have no admin-policy or per-tool deny config.
- * The agent profile (`AGENTS.md`) inlines this block above the behavioral
- * rules so it is impossible to miss.
- *
- * Gemini: duplicate intent — admin-policy already hard-denies these tools
- * (§4.3.3 hard enforcement), but echoing the deny in prose saves tokens
- * the model would otherwise spend drafting a doomed call.
- */
-export declare function buildSameBackendDenyBlock(integrations: Partial<Record<IntegrationKey, IntegrationState>>, sessionBackend: BackendId): string | null;
-/**
- * Apply the deny pass for every integration whose `skillsTouched` OR
- * `deniedToolsAppliesToSkills` includes the given skill slug. A skill that
- * touches no integration leaves content unchanged. Touching multiple
- * integrations runs the pass once per integration so each contributes its
- * own deny list.
- *
- * Hard enforcement of the same deny list for cross-backend delegated
- * calls lives at the `POST /api/integrations/:key/invoke` chokepoint
- * (DELEGATED-MODE-V2-DESIGN.md §4.3.2). For same-backend native MCP it
- * is enforced via SDK `disallowedTools` (Claude) / admin policy
- * (Gemini); see `collectSessionDeniedTools` (§4.3.3).
- */
-export declare function applyAllDeniedToolsForSkill(content: string, skillSlug: string, backendId: BackendId, integrations: Partial<Record<IntegrationKey, IntegrationState>>): string;
-/**
- * Remove any built-in skill directory under `destRoot` whose slug is not
- * in `keep`. Recognises a directory as a built-in by its presence under
- * the source `agent-assets/skills/` tree — anything else (user-authored
- * skill, accounts.md, etc.) is left alone, since `syncAllUserSkills` is
- * the canonical writer for those.
- *
- * Idempotent and side-effect-free when there is nothing to prune.
- * Exported for unit testing only.
- */
-export declare function pruneStaleBuiltinSkillDirs(destRoot: string, sourceSkillsRoot: string, keep: readonly string[]): void;
 export {};
-//# sourceMappingURL=skills-compiler.d.ts.map