@aitne/daemon 0.1.8 → 0.1.10

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

@@ -1,34 +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;
@@ -87,6 +60,21 @@ interface SessionPromptBundleParams {
      * 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
@@ -159,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
@@ -187,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[];
@@ -381,290 +369,4 @@ export declare class SkillsCompiler {
     private materializeFetchWindowCliSession;
     private materializeCliSession;
 }
-export declare const EMPTY_MAIL_ACCOUNTS_MD: string;
-export declare function renderMailAccountsMd(accounts: readonly MailAccount[]): string;
-/**
- * docs/design/appendices/opencode-backend.md §10 D6 — opencode 1.14.50 documents
- * `[a-z0-9-]{1,64}` as the legal skill-slug pattern. Aitne's existing
- * built-ins all conform; this helper is the predicate the build-time
- * validator (`validateBuiltinSkillSourceTree`) and the user-skill PUT
- * endpoint both gate on.
- *
- * docs/design/appendices/skills-unification.md Phase 1 §R5 / item 6 — promoted from a
- * runtime warn to a build-time throw at SkillsCompiler construction so
- * a malformed source tree refuses to boot the daemon.
- *
- * Exported for unit testing (`skills-compiler.test.ts` regression).
- */
-export declare function isValidSkillSlug(slug: string): boolean;
-/**
- * docs/design/appendices/skills-unification.md Phase 1 §R5 / item 6 — build-time invariant
- * pass over `agent-assets/skills/`. Throws on:
- *   - Any built-in slug that doesn't match `[a-z0-9-]{1,64}`.
- *   - Any SKILL.md (incl. variants like `SKILL.delegated.<backend>.md`)
- *     whose `description` exceeds `SKILL_DESCRIPTION_MAX_LENGTH`.
- *   - Any SKILL.md missing `name` or `description`.
- *
- * No-op when the source tree is absent (test workspaces / partial-clone
- * scenarios). Memoised per workspace dir + skill-tree fingerprint so
- * repeated SkillsCompiler constructions in the same process don't pay
- * the walk cost twice; tests that mutate source between constructions
- * get fresh validation because the fingerprint shifts.
- *
- * Exported for tests that exercise the failure paths in isolation.
- */
-export declare function validateBuiltinSkillSourceTree(skillsRoot: string): void;
-/**
- * Return the backend-specific dotfile namespace name for a given backend's
- * skill directory, **without** the trailing `skills` segment — callers
- * join `skills` themselves. Returns `null` only for Claude (which is
- * dispatched through `materializeClaudeSession` and writes
- * `<sessionDir>/.claude/skills/` directly).
- *
- * docs/design/appendices/skills-unification.md Phase 1 — every non-Claude backend now writes
- * to its own brand-aligned namespace:
- *   - `codex`    → `.codex`
- *   - `gemini`   → `.gemini`
- *   - `opencode` → `.opencode` (V2 path (c); flipped from prior `.claude/`
- *                  redundancy-avoiding alias).
- */
-export declare function cliSkillsDirName(backendId: BackendId): string | null;
-/**
- * Return the CLI instruction-file name for a given backend. Codex and
- * OpenCode both auto-discover `AGENTS.md` from cwd; Gemini reads
- * `GEMINI.md`. Throws for `claude` — the Claude SDK consumes a per-cwd
- * `CLAUDE.md` written by `materializeClaudeSession`, not an instruction
- * file from this helper.
- *
- * Single helper so the choice is consistent between the wide
- * `materializeCliSession` and the slim `materializeFetchWindowCliSession`
- * paths (docs/design/appendices/fetch-window-cost-reduction.md §4.5.7).
- */
-export declare function cliInstructionFileName(backendId: Exclude<BackendId, "claude">): "AGENTS.md" | "GEMINI.md";
-/**
- * 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;
-/**
- * docs/design/appendices/skills-unification.md Phase 1 — parse the `name` and `description`
- * single-line YAML scalars out of a SKILL.md frontmatter block. Returns
- * `{ name: null, description: null }` when no frontmatter is present or
- * neither key is set. Multi-line block scalars (`description: |` /
- * `description: >`) are rejected at the regex level — the schema enforces
- * single-line scalars across all backends (R6).
- */
-export declare function parseSkillFrontmatter(content: string): {
-    name: string | null;
-    description: string | null;
-};
-/**
- * docs/design/appendices/skills-unification.md Phase 1 §R5 — hard upper bound on a
- * SKILL.md `description` scalar. Enforced at SkillsCompiler construction
- * for built-in skills (refuses to boot on violation) and at
- * `PUT /api/skills/<slug>` for user-authored skills (HTTP 400). Sized to
- * fit the model's selection decision without pinning enough prose to
- * encode body content.
- */
-export declare const SKILL_DESCRIPTION_MAX_LENGTH = 280;
-/**
- * docs/design/appendices/skills-unification.md Phase 1 §"Codex read-sensitive banner
- * inheritance" — endpoints flagged `RiskTier.ReadSensitive` by
- * `safety/risk-classifier.ts` that a Codex session cannot satisfy (no
- * read-sensitive token). Any SKILL.md whose body references one of these
- * prefixes triggers a one-line banner prepend on the Codex copy. Listed
- * literally (not derived from `API_RISK` at module-load time) so the
- * core/skills-compiler module stays independent of safety/risk-classifier
- * — a circular import would invert the bootstrap order.
- *
- * Drift guard: `skills-compiler.test.ts` pins this list against the
- * RiskTier.ReadSensitive GET-prefix set in `risk-classifier.ts` so a new
- * read-sensitive endpoint added to API_RISK surfaces here at test time
- * instead of as silent 401 retries in a future Codex session.
- *
- * Exported for the drift-guard regression test only — production code
- * MUST use {@link skillBodyTouchesReadSensitive} to keep the
- * "literal prefix" decision encapsulated.
- */
-export declare const READ_SENSITIVE_API_PREFIXES: readonly ["/api/apple-calendar", "/api/books", "/api/calendar", "/api/context", "/api/entities", "/api/mail", "/api/mcp/servers", "/api/notion", "/api/observations", "/api/obsidian", "/api/receipts", "/api/travel-bookings"];
-export declare function renderSkillIndexBlock(destSkillsRootAbs: string, destSkillsRootRelative: string): string;
-/**
- * docs/design/appendices/skills-unification.md Phase 1 — re-render the `<skill-index>` block
- * inside an existing instruction file. Called by the workdir layer AFTER
- * `syncAllUserSkills` so user-authored slugs land in the index alongside
- * the built-ins (`renderSkillIndexBlock` reads the dest dir on disk, so a
- * post-sync re-render naturally picks them up).
- *
- * No-op when:
- *  - The backend is Claude (no instruction file with `<skill-index>`).
- *  - The instruction file is missing (the session has not been
- *    materialised yet).
- *  - The instruction file carries no `<skill-index>` block (slim
- *    fetch_window sessions, or future backends that opt out).
- *
- * Idempotent — re-running with the same dest contents produces an
- * identical instruction file.
- */
-export declare function refreshSkillIndexBlock(sessionDir: string, backendId: BackendId): void;
-/**
- * docs/design/appendices/skills-unification.md Phase 1 §R6 — `adaptSkillForCli` (which used
- * to retain only `name`/`description`/`when_to_use` and strip
- * `allowed-tools` from CLI-bound copies) is deleted. The source
- * SKILL.md frontmatter is byte-identical across all backends post-
- * materialisation. Codex / Gemini tolerate unknown YAML keys; OpenCode's
- * permissive frontmatter parser does too (verified against
- * `docs/design/appendices/opencode-backend.md` §5.5). The `when_to_use:` field has been
- * dropped from every built-in SKILL.md (Phase 0.1 of the sister doc) so
- * there is no per-backend fork to maintain.
- */
-/**
- * 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/exec` task-mode
- * chokepoint (DELEGATED-MODE-V2-DESIGN.md §4.3.2; the legacy `/invoke`
- * RPC was retired 2026-05-01). 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