wingfoil 0.2.1

package/dist/cli/registrar.js

@@ -0,0 +1,82 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.buildCliCommands = buildCliCommands;
+exports.listRegisteredCliCommands = listRegisteredCliCommands;
+const registry_1 = require("../core/registry");
+const exit_code_1 = require("../core/exit-code");
+const error_1 = require("./error");
+const exit_1 = require("./exit");
+const output_1 = require("./output");
+/**
+ * Derive one `CliCommand` per operation in `modules`, in `enumerateOperations`'s deterministic
+ * order (REQ-SYS-07). The verb is derived via `deriveVerb` (spec-006 §5).
+ */
+function buildCliCommands(modules, options) {
+    return (0, registry_1.enumerateOperations)(modules).map(({ module, operation }) => {
+        const verb = (0, registry_1.deriveVerb)(module.name, operation.name);
+        return {
+            noun: module.name,
+            verb,
+            mutates: operation.mutates,
+            flags: operation.flags,
+            options: operation.options,
+            run: async (formatValue, positionals, flags, optionValues) => {
+                if (!(0, output_1.isValidFormat)(formatValue)) {
+                    (0, exit_1.exitWith)(2, `error: invalid --format value "${formatValue}", expected one of: console, json, yaml`);
+                    return;
+                }
+                const format = formatValue;
+                let result;
+                try {
+                    // `resolveRoot()` / `buildParams()` run INSIDE the try so an ambient failure — e.g. a
+                    // `StorageError` from resolving the git root outside a WingFoil project — is rendered
+                    // through the spec-005 §1 single-exit path (emitError + exitWith), never escaping as an
+                    // uncaught throw that a top-level handler would stack-dump (bug-002-cli-error-stack-dump).
+                    const params = options.buildParams({
+                        moduleName: module.name,
+                        operationName: operation.name,
+                        root: options.resolveRoot(),
+                        // `positional` stays the first positional (single-positional read ops read it); `positionals`
+                        // is the full list a multi-input op (`dnaSet`) reads (task-025-implement-dna-set).
+                        positional: positionals?.[0],
+                        positionals,
+                        flags,
+                        // Value-bearing `--{name} <value>` options a data-mutating op reads (task-020's `memoryAdd`
+                        // reads `type`/`title`/`tags`). Undefined for every op declaring none.
+                        options: optionValues,
+                    });
+                    result = await operation.fn(params);
+                }
+                catch (error) {
+                    // Core owns exit-code selection for a thrown error too (spec-008 Consequences): a UsageError
+                    // (a malformed argument, e.g. `dna set`'s invalid key path) surfaces as exit 2, everything
+                    // else as 1 — never a bare crash (bug-002-cli-error-stack-dump). task-025-implement-dna-set.
+                    const { reason, exitCode } = (0, exit_code_1.exitCodeForThrow)(error);
+                    (0, error_1.emitError)(reason, { format });
+                    (0, exit_1.exitWith)(exitCode);
+                    return;
+                }
+                // Render the outcome, then terminate through the single exit function with the code core
+                // selects for this result (`0` success / `1` logic error) — the CLI does not re-decide the
+                // `0`/`1` mapping (task-012, spec-005 §1). `2` (usage error) is handled above, pre-core.
+                if (result.ok) {
+                    process.stdout.write((0, output_1.renderSuccess)(result.value, format));
+                }
+                else {
+                    (0, error_1.emitError)(result.error.message, { format });
+                }
+                (0, exit_1.exitWith)((0, exit_code_1.exitCodeForResult)(result));
+            },
+        };
+    });
+}
+/**
+ * Every `"{noun} {verb}"` command derived from `commands`, sorted (REQ-SYS-07) — the CLI-side
+ * enumeration the REQ-SYS-05 parity test (`test/core/parity.test.ts`) diffs against the MCP Tool
+ * list. A flat, no-verb command (`verb === ''`, task-028-implement-paths-category) renders as the
+ * bare noun (`"paths"`), not `"paths "` with a trailing space.
+ */
+function listRegisteredCliCommands(commands) {
+    return commands.map((command) => (command.verb ? `${command.noun} ${command.verb}` : command.noun)).sort();
+}
+//# sourceMappingURL=registrar.js.map

package/dist/cli/registrar.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"registrar.js","sourceRoot":"","sources":["../../src/cli/registrar.ts"],"names":[],"mappings":";;AA2EA,4CA+DC;AAQD,8DAEC;AAlID,+CAAmE;AAEnE,iDAAwE;AAExE,mCAAoC;AACpC,iCAAkC;AAClC,qCAAwD;AA+CxD;;;GAGG;AACH,SAAgB,gBAAgB,CAAC,OAA8B,EAAE,OAA6B;IAC5F,OAAO,IAAA,8BAAmB,EAAC,OAAO,CAAC,CAAC,GAAG,CAAC,CAAC,EAAE,MAAM,EAAE,SAAS,EAAE,EAAE,EAAE;QAChE,MAAM,IAAI,GAAG,IAAA,qBAAU,EAAC,MAAM,CAAC,IAAI,EAAE,SAAS,CAAC,IAAI,CAAC,CAAC;QACrD,OAAO;YACL,IAAI,EAAE,MAAM,CAAC,IAAI;YACjB,IAAI;YACJ,OAAO,EAAE,SAAS,CAAC,OAAO;YAC1B,KAAK,EAAE,SAAS,CAAC,KAAK;YACtB,OAAO,EAAE,SAAS,CAAC,OAAO;YAC1B,GAAG,EAAE,KAAK,EACR,WAAmB,EACnB,WAA+B,EAC/B,KAAyC,EACzC,YAA+C,EAC/C,EAAE;gBACF,IAAI,CAAC,IAAA,sBAAa,EAAC,WAAW,CAAC,EAAE,CAAC;oBAChC,IAAA,eAAQ,EAAC,CAAC,EAAE,kCAAkC,WAAW,yCAAyC,CAAC,CAAC;oBACpG,OAAO;gBACT,CAAC;gBACD,MAAM,MAAM,GAAG,WAAW,CAAC;gBAE3B,IAAI,MAA2B,CAAC;gBAChC,IAAI,CAAC;oBACH,sFAAsF;oBACtF,sFAAsF;oBACtF,wFAAwF;oBACxF,2FAA2F;oBAC3F,MAAM,MAAM,GAAG,OAAO,CAAC,WAAW,CAAC;wBACjC,UAAU,EAAE,MAAM,CAAC,IAAI;wBACvB,aAAa,EAAE,SAAS,CAAC,IAAI;wBAC7B,IAAI,EAAE,OAAO,CAAC,WAAW,EAAE;wBAC3B,8FAA8F;wBAC9F,mFAAmF;wBACnF,UAAU,EAAE,WAAW,EAAE,CAAC,CAAC,CAAC;wBAC5B,WAAW;wBACX,KAAK;wBACL,4FAA4F;wBAC5F,uEAAuE;wBACvE,OAAO,EAAE,YAAY;qBACtB,CAAC,CAAC;oBACH,MAAM,GAAG,MAAM,SAAS,CAAC,EAAE,CAAC,MAAM,CAAC,CAAC;gBACtC,CAAC;gBAAC,OAAO,KAAK,EAAE,CAAC;oBACf,6FAA6F;oBAC7F,2FAA2F;oBAC3F,6FAA6F;oBAC7F,MAAM,EAAE,MAAM,EAAE,QAAQ,EAAE,GAAG,IAAA,4BAAgB,EAAC,KAAK,CAAC,CAAC;oBACrD,IAAA,iBAAS,EAAC,MAAM,EAAE,EAAE,MAAM,EAAE,CAAC,CAAC;oBAC9B,IAAA,eAAQ,EAAC,QAAQ,CAAC,CAAC;oBACnB,OAAO;gBACT,CAAC;gBAED,yFAAyF;gBACzF,2FAA2F;gBAC3F,yFAAyF;gBACzF,IAAI,MAAM,CAAC,EAAE,EAAE,CAAC;oBACd,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,IAAA,sBAAa,EAAC,MAAM,CAAC,KAAK,EAAE,MAAM,CAAC,CAAC,CAAC;gBAC5D,CAAC;qBAAM,CAAC;oBACN,IAAA,iBAAS,EAAC,MAAM,CAAC,KAAK,CAAC,OAAO,EAAE,EAAE,MAAM,EAAE,CAAC,CAAC;gBAC9C,CAAC;gBACD,IAAA,eAAQ,EAAC,IAAA,6BAAiB,EAAC,MAAM,CAAC,CAAC,CAAC;YACtC,CAAC;SACF,CAAC;IACJ,CAAC,CAAC,CAAC;AACL,CAAC;AAED;;;;;GAKG;AACH,SAAgB,yBAAyB,CAAC,QAA+B;IACvE,OAAO,QAAQ,CAAC,GAAG,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,GAAG,OAAO,CAAC,IAAI,IAAI,OAAO,CAAC,IAAI,EAAE,CAAC,CAAC,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;AAC7G,CAAC"}

package/dist/cli.d.ts

@@ -0,0 +1,3 @@
+#!/usr/bin/env node
+export {};
+//# sourceMappingURL=cli.d.ts.map

package/dist/cli.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":""}

package/dist/cli.js

@@ -0,0 +1,45 @@
+#!/usr/bin/env node
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+/**
+ * The `wingfoil` CLI executable — task-007-npm-distribution (REQ-SYS-09). This is the `bin`
+ * entrypoint `package.json`'s `"bin"` field maps to (compiled to `dist/cli.js`); `npm install -g
+ * wingfoil` places a shim on `PATH` that runs this file directly (npm chmods it executable at link
+ * time — the `#!/usr/bin/env node` shebang above is what makes the shim itself runnable).
+ *
+ * It wires the real `commander` program built by `./cli/program.ts` (`buildProgram`, task-006) onto
+ * a real process invocation, exactly like `test/cli/fixtures/cli-harness.cjs` drives it against a
+ * fixture root in tests — the difference here is `resolveRoot` resolves the *real* project root via
+ * git-root detection (`./storage/git-root.ts`, spec-011-storage-layout) instead of a fixed fixture
+ * path, and the real `process.argv` is parsed instead of a synthetic one.
+ *
+ * `resolveRoot` is only invoked lazily, once per dispatched command (see `./cli/registrar.ts`'s
+ * `run`) — `--help` (Commander built-in) and `--version` (registered by `buildProgram` via
+ * `.version()`, see `./cli/program.ts` — bug-001-cli-version-flag) are both handled by `commander`
+ * before any command handler runs, so `wingfoil --help` / `wingfoil --version` exit `0`
+ * (spec-005-cli-command-contract §1, spec-008-cli-grammar §1) even outside a git repository; only an
+ * actual `<noun> <verb>` invocation needs a resolvable git root.
+ */
+const program_1 = require("./cli/program");
+const core_1 = require("./core");
+const git_root_1 = require("./storage/git-root");
+(0, program_1.buildProgram)(core_1.CORE_MODULES, {
+    resolveRoot: () => (0, git_root_1.resolveProjectRoot)(process.cwd()),
+    // task-026's single bare `positional` (`ctx.positional`, read by `dnaShowFn`/`pathsFn` as
+    // section/category), task-025's full `positionals` list (read by `dnaSetFn` as `<key> <value>`),
+    // task-028's additive `flags` spread (e.g. `paths`'s `--list` -> `list: true`), plus task-020's
+    // value-bearing `options` record (read by `memoryAddFn` as `type`/`title`/`tags`). A command with no
+    // positional/flags/options is unaffected.
+    buildParams: (ctx) => ({ root: ctx.root, positional: ctx.positional, positionals: ctx.positionals, options: ctx.options, ...(ctx.flags ?? {}) }),
+})
+    .then((program) => program.parseAsync(process.argv))
+    .catch((error) => {
+    // Last-resort handler for anything that escapes the per-command spec-005 exit path. Emit only the
+    // message as a single `error:` line — never `error.stack`, which would leak a stack trace and
+    // absolute internal paths from a published CLI (bug-002-cli-error-stack-dump). The normal
+    // no-git-root path is already handled cleanly inside the registrar; this guards the unexpected.
+    const message = error instanceof Error ? error.message : String(error);
+    process.stderr.write(`error: ${message}\n`);
+    process.exit(1);
+});
+//# sourceMappingURL=cli.js.map

package/dist/cli.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"cli.js","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";;;AACA;;;;;;;;;;;;;;;;;;GAkBG;AACH,2CAA6C;AAC7C,iCAAsC;AACtC,iDAAwD;AAExD,IAAA,sBAAY,EAAC,mBAAY,EAAE;IACzB,WAAW,EAAE,GAAG,EAAE,CAAC,IAAA,6BAAkB,EAAC,OAAO,CAAC,GAAG,EAAE,CAAC;IACpD,0FAA0F;IAC1F,iGAAiG;IACjG,gGAAgG;IAChG,qGAAqG;IACrG,0CAA0C;IAC1C,WAAW,EAAE,CAAC,GAAG,EAAE,EAAE,CAAC,CAAC,EAAE,IAAI,EAAE,GAAG,CAAC,IAAI,EAAE,UAAU,EAAE,GAAG,CAAC,UAAU,EAAE,WAAW,EAAE,GAAG,CAAC,WAAW,EAAE,OAAO,EAAE,GAAG,CAAC,OAAO,EAAE,GAAG,CAAC,GAAG,CAAC,KAAK,IAAI,EAAE,CAAC,EAAE,CAAC;CACjJ,CAAC;KACC,IAAI,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,CAAC,UAAU,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC;KACnD,KAAK,CAAC,CAAC,KAAc,EAAE,EAAE;IACxB,kGAAkG;IAClG,8FAA8F;IAC9F,0FAA0F;IAC1F,gGAAgG;IAChG,MAAM,OAAO,GAAG,KAAK,YAAY,KAAK,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC;IACvE,OAAO,CAAC,MAAM,CAAC,KAAK,CAAC,UAAU,OAAO,IAAI,CAAC,CAAC;IAC5C,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAClB,CAAC,CAAC,CAAC"}

package/dist/core/approval-authority.d.ts

@@ -0,0 +1,83 @@
+/**
+ * Role-based approval authority (REQ-SEC-03, adr-006-git-identity-role-based-authz —
+ * task-040-role-based-approval-authority).
+ *
+ * adr-006's second point fixes approval authority as role-based, never bound to a named person: a
+ * `.wingfoil/dna.yaml` `team.members[]` entry holds one or more `roles` from the canonical
+ * `team.roles` catalogue (`src/dna/schema.ts`'s `Team`), and only a member holding the `approver`
+ * role may approve a Memory document — uniformly across every type. There is no per-type approver
+ * role anywhere in `memory.yaml`/`dna.yaml`: every `approval: { by_role: ... }` step across
+ * `.wingfoil/workflows/custom/*.yaml` already gates on the single `approver` role, so this module
+ * does the same rather than inventing a per-type mapping no spec defines.
+ *
+ * "Who is asking" is resolved the same way `requireGitIdentity` (REQ-SEC-01) already establishes
+ * attribution: the live git identity configured at the project root (`readGitIdentity`,
+ * `./git-identity.ts`) — git identity is WingFoil's sole attribution mechanism (adr-001/adr-006), so
+ * authority is checked against the exact same "who" the resulting approval commit will record. This
+ * is why `team.agents` is deliberately NOT consulted here: an AI agent has no git identity of its own
+ * distinct from whichever human account runs the command, so there is no code-level signal this
+ * git-identity-keyed check could use to single an agent out. Structurally preventing agents from
+ * holding approval authority is instead a `dna.yaml` fact (`team.agents[].approval_authority: false`)
+ * enforced by process/governance (CLAUDE.md §4/§8: "AI agents ... never hold approval authority"), not
+ * by this predicate.
+ *
+ * **"Who is authorized" is read from the COMMITTED `dna.yaml`, never from the working tree**
+ * (task-090, `bug-079-uncommitted-dna-yaml-grants-approval-authority`). The two halves of the check
+ * therefore take deliberately different baselines, and each takes the only one it can:
+ *
+ * - *who is asking* — the live git config, which is a local setting git never commits, and which is
+ *   also exactly what the resulting commit will record as its author;
+ * - *who may approve* — `HEAD`'s `.wingfoil/dna.yaml`, because an approval is evidence and evidence
+ *   is worth what an independent reader can re-derive from the artefact of record. An uncommitted
+ *   grant used to be enough to put `Approver: … (approver)` into a permanent commit that the
+ *   repository's own record, at that very commit, contradicted.
+ */
+import type { DnaYaml } from '../dna/schema';
+import { type CoreResult } from './types';
+/** The one role that carries approval authority, uniformly across every Memory type (adr-006). */
+export declare const APPROVER_ROLE: "approver";
+/**
+ * The roles held by the `dna.yaml` `team.members[]` entry whose `email` matches `email`
+ * (case-insensitively — git identities are free-form and casing is not semantically meaningful),
+ * or `[]` when `email` is empty or matches no member. Pure lookup — no git/filesystem access; callers
+ * needing the live git identity go through {@link requireApprovalAuthority} or `readGitIdentity`
+ * (`./git-identity.ts`) themselves.
+ */
+export declare function resolveMemberRoles(dna: DnaYaml, email: string): readonly string[];
+/** Whether the `dna.yaml` team member matching `email` holds the {@link APPROVER_ROLE}. */
+export declare function hasApproverRole(dna: DnaYaml, email: string): boolean;
+/**
+ * Verify the principal identified by the live git identity at `root` holds the `approver` role — **as
+ * the committed `.wingfoil/dna.yaml` records it** — before an approval (`memory.approve`, P1.7) or a
+ * rejection (`memory.reject`, P1.8) proceeds. Returns a `CoreResult.error` (code `VALIDATION` — a
+ * failed authorization precondition, mapped to exit `1` by `exitCodeForError`, mirroring
+ * `requireGitIdentity`'s own precondition shape; `spec-005` §1 reserves `2` for a malformed
+ * *invocation*, which none of these refusals is) carrying the exact REQ-SEC-03 fit-criterion message
+ * `user not authorized to approve type '<type>'` when the git-configured email holds no `approver`
+ * role at `HEAD` (including when it is unset, or matches no `team.members` entry at all); otherwise
+ * `ok`. `typeName` is the Memory element type being approved (e.g. `task`, `adr`) — interpolated into
+ * the refusal message only, it plays no role in the authority check itself (§ module doc comment: the
+ * `approver` role is uniform across types).
+ *
+ * Three refusals, all fail-closed, all before anything is written:
+ *
+ * 1. **No authority at `HEAD`** — REQ-SEC-03's message verbatim. When the *working tree* would have
+ *    granted it, a second sentence names the baseline, so a user whose editor shows them as an
+ *    approver is told why the tool disagrees instead of being left to argue with the file on their
+ *    screen. That diagnostic is the half of option (b) — refusing while `dna.yaml` is modified —
+ *    worth keeping; the refusal itself remains a statement about the repository.
+ * 2. **No committed `dna.yaml` at all** — an untracked file, or a repository with no commits: there
+ *    is no record to read, so no authority can be established.
+ * 3. **A committed `dna.yaml` that does not parse or validate** — the baseline is unreadable, which
+ *    is not the same as "grants nothing", but leads to the same refusal.
+ *
+ * This function takes `root`, not a `DnaYaml`: a caller cannot hand it a parsed working-tree
+ * configuration even by accident, which is what makes the committed baseline a property of the read
+ * itself rather than of a precondition someone must remember to run (task-090, AC2).
+ *
+ * Callers run this AFTER `requireGitIdentity` (REQ-SEC-01) in the same mutating-op pre-flight
+ * sequence `dnaSetFn`/`memoryAddFn` (`src/core/index.ts`) establish — an unconfigured identity should
+ * surface as REQ-SEC-01's own message, not this one.
+ */
+export declare function requireApprovalAuthority(root: string, typeName: string): CoreResult<void>;
+//# sourceMappingURL=approval-authority.d.ts.map

package/dist/core/approval-authority.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"approval-authority.d.ts","sourceRoot":"","sources":["../../src/core/approval-authority.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAiCG;AACH,OAAO,KAAK,EAAE,OAAO,EAAE,MAAM,eAAe,CAAC;AAK7C,OAAO,EAAmB,KAAK,UAAU,EAAE,MAAM,SAAS,CAAC;AAE3D,kGAAkG;AAClG,eAAO,MAAM,aAAa,EAAG,UAAmB,CAAC;AAEjD;;;;;;GAMG;AACH,wBAAgB,kBAAkB,CAAC,GAAG,EAAE,OAAO,EAAE,KAAK,EAAE,MAAM,GAAG,SAAS,MAAM,EAAE,CAKjF;AAED,2FAA2F;AAC3F,wBAAgB,eAAe,CAAC,GAAG,EAAE,OAAO,EAAE,KAAK,EAAE,MAAM,GAAG,OAAO,CAEpE;AAiBD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,wBAAgB,wBAAwB,CAAC,IAAI,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,GAAG,UAAU,CAAC,IAAI,CAAC,CAmCzF"}

package/dist/core/approval-authority.js

@@ -0,0 +1,112 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.APPROVER_ROLE = void 0;
+exports.resolveMemberRoles = resolveMemberRoles;
+exports.hasApproverRole = hasApproverRole;
+exports.requireApprovalAuthority = requireApprovalAuthority;
+const validation_1 = require("../validation");
+const git_identity_1 = require("./git-identity");
+const loaders_1 = require("./loaders");
+const types_1 = require("./types");
+/** The one role that carries approval authority, uniformly across every Memory type (adr-006). */
+exports.APPROVER_ROLE = 'approver';
+/**
+ * The roles held by the `dna.yaml` `team.members[]` entry whose `email` matches `email`
+ * (case-insensitively — git identities are free-form and casing is not semantically meaningful),
+ * or `[]` when `email` is empty or matches no member. Pure lookup — no git/filesystem access; callers
+ * needing the live git identity go through {@link requireApprovalAuthority} or `readGitIdentity`
+ * (`./git-identity.ts`) themselves.
+ */
+function resolveMemberRoles(dna, email) {
+    if (email.length === 0)
+        return [];
+    const normalized = email.toLowerCase();
+    const member = dna.team.members.find((candidate) => candidate.email?.toLowerCase() === normalized);
+    return member?.roles ?? [];
+}
+/** Whether the `dna.yaml` team member matching `email` holds the {@link APPROVER_ROLE}. */
+function hasApproverRole(dna, email) {
+    return resolveMemberRoles(dna, email).includes(exports.APPROVER_ROLE);
+}
+/**
+ * Whether the working tree's `dna.yaml` grants `email` the `approver` role — a **diagnostic only**,
+ * never a decision. It answers one question: is the user looking at a file that says something the
+ * repository has not recorded? Any failure to read or parse it is simply "no" (`false`): an
+ * unreadable working-tree file must never change the outcome of a check whose answer comes from
+ * `HEAD`.
+ */
+function workingTreeWouldGrant(root, email) {
+    try {
+        return hasApproverRole((0, loaders_1.loadDnaYaml)(root), email);
+    }
+    catch {
+        return false;
+    }
+}
+/**
+ * Verify the principal identified by the live git identity at `root` holds the `approver` role — **as
+ * the committed `.wingfoil/dna.yaml` records it** — before an approval (`memory.approve`, P1.7) or a
+ * rejection (`memory.reject`, P1.8) proceeds. Returns a `CoreResult.error` (code `VALIDATION` — a
+ * failed authorization precondition, mapped to exit `1` by `exitCodeForError`, mirroring
+ * `requireGitIdentity`'s own precondition shape; `spec-005` §1 reserves `2` for a malformed
+ * *invocation*, which none of these refusals is) carrying the exact REQ-SEC-03 fit-criterion message
+ * `user not authorized to approve type '<type>'` when the git-configured email holds no `approver`
+ * role at `HEAD` (including when it is unset, or matches no `team.members` entry at all); otherwise
+ * `ok`. `typeName` is the Memory element type being approved (e.g. `task`, `adr`) — interpolated into
+ * the refusal message only, it plays no role in the authority check itself (§ module doc comment: the
+ * `approver` role is uniform across types).
+ *
+ * Three refusals, all fail-closed, all before anything is written:
+ *
+ * 1. **No authority at `HEAD`** — REQ-SEC-03's message verbatim. When the *working tree* would have
+ *    granted it, a second sentence names the baseline, so a user whose editor shows them as an
+ *    approver is told why the tool disagrees instead of being left to argue with the file on their
+ *    screen. That diagnostic is the half of option (b) — refusing while `dna.yaml` is modified —
+ *    worth keeping; the refusal itself remains a statement about the repository.
+ * 2. **No committed `dna.yaml` at all** — an untracked file, or a repository with no commits: there
+ *    is no record to read, so no authority can be established.
+ * 3. **A committed `dna.yaml` that does not parse or validate** — the baseline is unreadable, which
+ *    is not the same as "grants nothing", but leads to the same refusal.
+ *
+ * This function takes `root`, not a `DnaYaml`: a caller cannot hand it a parsed working-tree
+ * configuration even by accident, which is what makes the committed baseline a property of the read
+ * itself rather than of a precondition someone must remember to run (task-090, AC2).
+ *
+ * Callers run this AFTER `requireGitIdentity` (REQ-SEC-01) in the same mutating-op pre-flight
+ * sequence `dnaSetFn`/`memoryAddFn` (`src/core/index.ts`) establish — an unconfigured identity should
+ * surface as REQ-SEC-01's own message, not this one.
+ */
+function requireApprovalAuthority(root, typeName) {
+    const { email } = (0, git_identity_1.readGitIdentity)(root);
+    let committed;
+    try {
+        committed = (0, loaders_1.loadDnaYamlAtHead)(root);
+    }
+    catch (error) {
+        if (!(error instanceof validation_1.ValidationError))
+            throw error;
+        return (0, types_1.coreErr)({
+            code: 'VALIDATION',
+            message: `cannot resolve approval authority: the committed '${loaders_1.DNA_YAML_PATH}' (at HEAD) is not readable as DNA: ` +
+                `${error.message}. Approval authority is read from the committed configuration, so the committed file ` +
+                'must be valid; fix it and commit the fix, then retry.',
+            details: { issues: error.issues },
+        });
+    }
+    if (committed === null) {
+        return (0, types_1.coreErr)({
+            code: 'VALIDATION',
+            message: `cannot resolve approval authority: '${loaders_1.DNA_YAML_PATH}' is not committed at HEAD. Approval authority is a ` +
+                'property of the repository, not of a working tree (adr-006), so an approval can only rest on roles some ' +
+                `commit records; commit '${loaders_1.DNA_YAML_PATH}' first, then retry.`,
+        });
+    }
+    if (hasApproverRole(committed, email))
+        return (0, types_1.coreOk)(undefined);
+    const uncommittedGrant = workingTreeWouldGrant(root, email)
+        ? ` — the working tree's '${loaders_1.DNA_YAML_PATH}' grants it, but that change is not committed, and approval authority ` +
+            `is read from the committed configuration (adr-006); commit '${loaders_1.DNA_YAML_PATH}' first, then retry`
+        : '';
+    return (0, types_1.coreErr)({ code: 'VALIDATION', message: `user not authorized to approve type '${typeName}'${uncommittedGrant}` });
+}
+//# sourceMappingURL=approval-authority.js.map

package/dist/core/approval-authority.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"approval-authority.js","sourceRoot":"","sources":["../../src/core/approval-authority.ts"],"names":[],"mappings":";;;AAmDA,gDAKC;AAGD,0CAEC;AAkDD,4DAmCC;AA/GD,8CAAgD;AAEhD,iDAAiD;AACjD,uCAA0E;AAC1E,mCAA2D;AAE3D,kGAAkG;AACrF,QAAA,aAAa,GAAG,UAAmB,CAAC;AAEjD;;;;;;GAMG;AACH,SAAgB,kBAAkB,CAAC,GAAY,EAAE,KAAa;IAC5D,IAAI,KAAK,CAAC,MAAM,KAAK,CAAC;QAAE,OAAO,EAAE,CAAC;IAClC,MAAM,UAAU,GAAG,KAAK,CAAC,WAAW,EAAE,CAAC;IACvC,MAAM,MAAM,GAAG,GAAG,CAAC,IAAI,CAAC,OAAO,CAAC,IAAI,CAAC,CAAC,SAAS,EAAE,EAAE,CAAC,SAAS,CAAC,KAAK,EAAE,WAAW,EAAE,KAAK,UAAU,CAAC,CAAC;IACnG,OAAO,MAAM,EAAE,KAAK,IAAI,EAAE,CAAC;AAC7B,CAAC;AAED,2FAA2F;AAC3F,SAAgB,eAAe,CAAC,GAAY,EAAE,KAAa;IACzD,OAAO,kBAAkB,CAAC,GAAG,EAAE,KAAK,CAAC,CAAC,QAAQ,CAAC,qBAAa,CAAC,CAAC;AAChE,CAAC;AAED;;;;;;GAMG;AACH,SAAS,qBAAqB,CAAC,IAAY,EAAE,KAAa;IACxD,IAAI,CAAC;QACH,OAAO,eAAe,CAAC,IAAA,qBAAW,EAAC,IAAI,CAAC,EAAE,KAAK,CAAC,CAAC;IACnD,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,KAAK,CAAC;IACf,CAAC;AACH,CAAC;AAED;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,SAAgB,wBAAwB,CAAC,IAAY,EAAE,QAAgB;IACrE,MAAM,EAAE,KAAK,EAAE,GAAG,IAAA,8BAAe,EAAC,IAAI,CAAC,CAAC;IAExC,IAAI,SAAyB,CAAC;IAC9B,IAAI,CAAC;QACH,SAAS,GAAG,IAAA,2BAAiB,EAAC,IAAI,CAAC,CAAC;IACtC,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QACf,IAAI,CAAC,CAAC,KAAK,YAAY,4BAAe,CAAC;YAAE,MAAM,KAAK,CAAC;QACrD,OAAO,IAAA,eAAO,EAAC;YACb,IAAI,EAAE,YAAY;YAClB,OAAO,EACL,qDAAqD,uBAAa,sCAAsC;gBACxG,GAAG,KAAK,CAAC,OAAO,uFAAuF;gBACvG,uDAAuD;YACzD,OAAO,EAAE,EAAE,MAAM,EAAE,KAAK,CAAC,MAAM,EAAE;SAClC,CAAC,CAAC;IACL,CAAC;IAED,IAAI,SAAS,KAAK,IAAI,EAAE,CAAC;QACvB,OAAO,IAAA,eAAO,EAAC;YACb,IAAI,EAAE,YAAY;YAClB,OAAO,EACL,uCAAuC,uBAAa,sDAAsD;gBAC1G,0GAA0G;gBAC1G,2BAA2B,uBAAa,sBAAsB;SACjE,CAAC,CAAC;IACL,CAAC;IAED,IAAI,eAAe,CAAC,SAAS,EAAE,KAAK,CAAC;QAAE,OAAO,IAAA,cAAM,EAAO,SAAS,CAAC,CAAC;IAEtE,MAAM,gBAAgB,GAAG,qBAAqB,CAAC,IAAI,EAAE,KAAK,CAAC;QACzD,CAAC,CAAC,0BAA0B,uBAAa,wEAAwE;YAC/G,+DAA+D,uBAAa,qBAAqB;QACnG,CAAC,CAAC,EAAE,CAAC;IACP,OAAO,IAAA,eAAO,EAAC,EAAE,IAAI,EAAE,YAAY,EAAE,OAAO,EAAE,wCAAwC,QAAQ,IAAI,gBAAgB,EAAE,EAAE,CAAC,CAAC;AAC1H,CAAC"}

package/dist/core/builtin-asset.d.ts

@@ -0,0 +1,71 @@
+/**
+ * Immutable built-in assets pre-flight check (REQ-SEC-07 — task-042-immutable-builtin-assets).
+ *
+ * **The rule is REQ-SEC-07's, the layout is spec-011's.** REQ-SEC-07 states that built-in directives
+ * and built-in workflow templates cannot be removed; `spec-011-storage-layout` supplies the structure
+ * that rule is expressed over — the `directives/{built-in,custom}/` and `workflows/{built-in,custom}/`
+ * split, where `built-in/` is "reserved for the official … templates shipped by the `wingfoil` npm
+ * package" (empty today, `.gitkeep` only) and `custom/` holds every asset that exists right now. Only
+ * the removability rule comes from REQ-SEC-07; spec-011 never speaks about removal or protection.
+ *
+ * Classification is **structural** (which subdirectory holds the file), not the directive
+ * frontmatter's `kind:` field — and that is the one point spec-011 does settle: the six P3.8 template
+ * stand-ins live under `custom/` while each is "authored with `kind: custom`, `ref: [P3.8]`", so
+ * `kind:` demonstrably does not track the subdirectory and cannot be the discriminator. Location is
+ * the only discriminator spec-011 defines.
+ *
+ * **This check is an ALLOW-LIST and fails CLOSED.** It returns "removable" only for a path it
+ * positively recognises as `{directives|workflows}/custom/…`; every other shape — a built-in path, an
+ * unknown shape, an empty string, a `.`/`..` traversal, an absolute path, a doubled separator, a
+ * different pillar's tree — is refused. A deny-list on the literal segment `built-in` was the
+ * first-pass defect: `src/core/loaders.ts` builds a directive's stored path with the **platform**
+ * separator (`join('directives', relativePath)`), so on Windows a built-in arrives as
+ * `directives\built-in\testing.md`, which a forward-slash-only split classifies as *not* built-in and
+ * would therefore have allowed `directive remove` to delete. Both separators are accepted as
+ * separators here for exactly that reason.
+ *
+ * `.`/`..` segments are **refused, not resolved**: resolving them textually is not equivalent to
+ * resolving them on a filesystem (a symlinked `custom/` aliasing `built-in/` defeats any string-level
+ * normalisation), so an ambiguous shape is rejected rather than guessed at. Callers pass the
+ * `.wingfoil`-relative path of an asset they already located; that path is never ambiguous.
+ *
+ * This lives in `src/core` (not `src/directives`/`src/workflow`) because REQ-SEC-07 crosscuts both
+ * pillars identically and both the CLI and MCP surfaces must enforce it the same way (REQ-SYS-05) —
+ * the same reasoning `requireGitIdentity` (REQ-SEC-01, task-014) already established for a
+ * cross-cutting mutating-op pre-flight. Neither `directive remove` nor `workflow remove` exists yet in
+ * `CORE_MODULES` (spec-006 §3 reserves both as future `mutates: true` operations); per the same
+ * precedent (task-014, task-016), this task delivers the shared, fully-tested primitive now and defers
+ * wiring it into the actual mutating op to the dependent task (task-052-directive-remove for
+ * `directive.remove`; a future task for `workflow.remove`).
+ *
+ * **Scope:** this module delivers REQ-SEC-07's *first* clause only. The second — "removal of a
+ * still-referenced custom asset is rejected naming the referrer" — is deliberately not implemented
+ * here; per `dl-030-req-sec-07-referenced-asset-ownership` (`ready`) the directive half belongs to
+ * `task-052-directive-remove` and the workflow half (P4.9) is carried to the next `release-planning`
+ * run. `requireCustomAsset` is therefore the FIRST of two checks a remove op runs, never the only one.
+ */
+import { type CoreResult } from './types';
+/** The two pillars REQ-SEC-07 protects — `built-in/` is immutable in both. */
+export type AssetKind = 'directive' | 'workflow';
+/**
+ * The allow-list: true only when `relativePath` is positively recognised as a removable `custom/`
+ * asset of this `kind` — e.g. `directives/custom/legacy-rule.md`, `workflows/custom/arch-review.yaml`,
+ * or a file nested deeper under `custom/`. Either separator is accepted (see the module doc-comment on
+ * `loaders.ts`'s platform `join`). A file merely *named* `built-in-notes.md` under `custom/` is
+ * removable — it is the `custom` **segment** that decides, never a substring. Everything else is
+ * false, including a `kind` mismatch: a workflow path handed to `'directive'` is not removable through
+ * the directive surface. Pure predicate — no filesystem access, no wall-clock/randomness (REQ-SYS-07).
+ */
+export declare function isRemovableCustomAssetPath(kind: AssetKind, relativePath: string): boolean;
+/**
+ * REQ-SEC-07 pre-flight: allow a removal only for a recognised `custom/` asset of `kind`. Mirrors
+ * `requireGitIdentity`'s shape exactly (`CoreResult<void>`, pure, safe to call before any read/write)
+ * — intended as the FIRST check `directiveRemove`/`workflowRemove` run, before any reference check,
+ * so a protected or unrecognised path is rejected on structure alone. Returns a `VALIDATION`
+ * `CoreResult.error` (a failed precondition, like the sibling pre-flights `requireGitIdentity` and
+ * `requireApprovalAuthority`; exit `1` via `exitCodeForError`) carrying REQ-SEC-07's exact fit-criterion
+ * wording for a declared built-in, or a generic `cannot remove '<path>': …` refusal — shaped after
+ * P3.3's own `cannot remove '<name>': …` message — for any other unrecognised shape; otherwise `ok`.
+ */
+export declare function requireCustomAsset(kind: AssetKind, relativePath: string): CoreResult<void>;
+//# sourceMappingURL=builtin-asset.d.ts.map

package/dist/core/builtin-asset.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"builtin-asset.d.ts","sourceRoot":"","sources":["../../src/core/builtin-asset.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6CG;AACH,OAAO,EAAmB,KAAK,UAAU,EAAE,MAAM,SAAS,CAAC;AAE3D,8EAA8E;AAC9E,MAAM,MAAM,SAAS,GAAG,WAAW,GAAG,UAAU,CAAC;AAiDjD;;;;;;;;GAQG;AACH,wBAAgB,0BAA0B,CAAC,IAAI,EAAE,SAAS,EAAE,YAAY,EAAE,MAAM,GAAG,OAAO,CAEzF;AAcD;;;;;;;;;GASG;AACH,wBAAgB,kBAAkB,CAAC,IAAI,EAAE,SAAS,EAAE,YAAY,EAAE,MAAM,GAAG,UAAU,CAAC,IAAI,CAAC,CAQ1F"}

package/dist/core/builtin-asset.js

@@ -0,0 +1,137 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.isRemovableCustomAssetPath = isRemovableCustomAssetPath;
+exports.requireCustomAsset = requireCustomAsset;
+/**
+ * Immutable built-in assets pre-flight check (REQ-SEC-07 — task-042-immutable-builtin-assets).
+ *
+ * **The rule is REQ-SEC-07's, the layout is spec-011's.** REQ-SEC-07 states that built-in directives
+ * and built-in workflow templates cannot be removed; `spec-011-storage-layout` supplies the structure
+ * that rule is expressed over — the `directives/{built-in,custom}/` and `workflows/{built-in,custom}/`
+ * split, where `built-in/` is "reserved for the official … templates shipped by the `wingfoil` npm
+ * package" (empty today, `.gitkeep` only) and `custom/` holds every asset that exists right now. Only
+ * the removability rule comes from REQ-SEC-07; spec-011 never speaks about removal or protection.
+ *
+ * Classification is **structural** (which subdirectory holds the file), not the directive
+ * frontmatter's `kind:` field — and that is the one point spec-011 does settle: the six P3.8 template
+ * stand-ins live under `custom/` while each is "authored with `kind: custom`, `ref: [P3.8]`", so
+ * `kind:` demonstrably does not track the subdirectory and cannot be the discriminator. Location is
+ * the only discriminator spec-011 defines.
+ *
+ * **This check is an ALLOW-LIST and fails CLOSED.** It returns "removable" only for a path it
+ * positively recognises as `{directives|workflows}/custom/…`; every other shape — a built-in path, an
+ * unknown shape, an empty string, a `.`/`..` traversal, an absolute path, a doubled separator, a
+ * different pillar's tree — is refused. A deny-list on the literal segment `built-in` was the
+ * first-pass defect: `src/core/loaders.ts` builds a directive's stored path with the **platform**
+ * separator (`join('directives', relativePath)`), so on Windows a built-in arrives as
+ * `directives\built-in\testing.md`, which a forward-slash-only split classifies as *not* built-in and
+ * would therefore have allowed `directive remove` to delete. Both separators are accepted as
+ * separators here for exactly that reason.
+ *
+ * `.`/`..` segments are **refused, not resolved**: resolving them textually is not equivalent to
+ * resolving them on a filesystem (a symlinked `custom/` aliasing `built-in/` defeats any string-level
+ * normalisation), so an ambiguous shape is rejected rather than guessed at. Callers pass the
+ * `.wingfoil`-relative path of an asset they already located; that path is never ambiguous.
+ *
+ * This lives in `src/core` (not `src/directives`/`src/workflow`) because REQ-SEC-07 crosscuts both
+ * pillars identically and both the CLI and MCP surfaces must enforce it the same way (REQ-SYS-05) —
+ * the same reasoning `requireGitIdentity` (REQ-SEC-01, task-014) already established for a
+ * cross-cutting mutating-op pre-flight. Neither `directive remove` nor `workflow remove` exists yet in
+ * `CORE_MODULES` (spec-006 §3 reserves both as future `mutates: true` operations); per the same
+ * precedent (task-014, task-016), this task delivers the shared, fully-tested primitive now and defers
+ * wiring it into the actual mutating op to the dependent task (task-052-directive-remove for
+ * `directive.remove`; a future task for `workflow.remove`).
+ *
+ * **Scope:** this module delivers REQ-SEC-07's *first* clause only. The second — "removal of a
+ * still-referenced custom asset is rejected naming the referrer" — is deliberately not implemented
+ * here; per `dl-030-req-sec-07-referenced-asset-ownership` (`ready`) the directive half belongs to
+ * `task-052-directive-remove` and the workflow half (P4.9) is carried to the next `release-planning`
+ * run. `requireCustomAsset` is therefore the FIRST of two checks a remove op runs, never the only one.
+ */
+const types_1 = require("./types");
+/** The `.wingfoil/` top-level directory that holds each pillar's assets (spec-011 layout). */
+const ASSET_ROOT_SEGMENT = {
+    directive: 'directives',
+    workflow: 'workflows',
+};
+/** The spec-011 subdirectory holding removable assets — the ONE segment this allow-list accepts. */
+const CUSTOM_SEGMENT = 'custom';
+/** The spec-011 subdirectory reserved for official, npm-shipped templates. */
+const BUILT_IN_SEGMENT = 'built-in';
+/**
+ * Exact refusal wording required by REQ-SEC-07's fit criterion — **do not reword**: the BDD scenarios
+ * "Error - removing a built-in directive" (`p3-directives/P3.3-directive-remove.feature`) and
+ * "Error - removing a built-in workflow template" (`p4-workflow/P4.9-workflow-remove.feature`) assert
+ * these strings verbatim. Held in one named constant for the same reason `git-identity.ts` holds
+ * `IDENTITY_ERROR`: a fit-criterion string must be greppable against the `.feature` file that pins it,
+ * not reconstructed at each use site.
+ */
+const BUILT_IN_REMOVAL_ERROR = {
+    directive: 'built-in directives cannot be removed',
+    workflow: 'built-in workflows cannot be removed',
+};
+/**
+ * Split a stored asset path into segments on **either** separator, without collapsing runs — so a
+ * doubled separator yields an empty segment and an absolute path yields an empty leading segment,
+ * both of which the shape check below then rejects.
+ */
+function segmentsOf(relativePath) {
+    return relativePath.split(/[\\/]/);
+}
+/**
+ * True when `relativePath` is exactly the shape `{kind's root}/{subdirectory}/…/<file>`: at least
+ * three segments, no empty/`.`/`..` segment, the expected pillar root first and `subdirectory`
+ * second. Case-sensitive on purpose — a differently-cased segment is not recognised, and therefore
+ * (for the `custom` allow-list) refused rather than trusted on a case-insensitive filesystem.
+ */
+function isPillarAssetPath(kind, relativePath, subdirectory) {
+    const segments = segmentsOf(relativePath);
+    if (segments.length < 3)
+        return false;
+    if (!segments.every((segment) => segment !== '' && segment !== '.' && segment !== '..'))
+        return false;
+    return segments[0] === ASSET_ROOT_SEGMENT[kind] && segments[1] === subdirectory;
+}
+/**
+ * The allow-list: true only when `relativePath` is positively recognised as a removable `custom/`
+ * asset of this `kind` — e.g. `directives/custom/legacy-rule.md`, `workflows/custom/arch-review.yaml`,
+ * or a file nested deeper under `custom/`. Either separator is accepted (see the module doc-comment on
+ * `loaders.ts`'s platform `join`). A file merely *named* `built-in-notes.md` under `custom/` is
+ * removable — it is the `custom` **segment** that decides, never a substring. Everything else is
+ * false, including a `kind` mismatch: a workflow path handed to `'directive'` is not removable through
+ * the directive surface. Pure predicate — no filesystem access, no wall-clock/randomness (REQ-SYS-07).
+ */
+function isRemovableCustomAssetPath(kind, relativePath) {
+    return isPillarAssetPath(kind, relativePath, CUSTOM_SEGMENT);
+}
+/**
+ * True when `relativePath` positively declares itself a `built-in/` asset of this `kind`. Used
+ * **only** to choose the refusal wording, never to decide whether to refuse — that decision belongs
+ * entirely to {@link isRemovableCustomAssetPath}, so this predicate cannot reintroduce a fail-open
+ * path. A shape that is neither clearly `custom/` nor clearly `built-in/` (a traversal, an odd
+ * casing) is still refused; it just gets the generic wording instead of REQ-SEC-07's, because
+ * asserting "this is a built-in" about a path we did not recognise would be a claim we cannot make.
+ */
+function declaresBuiltInPath(kind, relativePath) {
+    return isPillarAssetPath(kind, relativePath, BUILT_IN_SEGMENT);
+}
+/**
+ * REQ-SEC-07 pre-flight: allow a removal only for a recognised `custom/` asset of `kind`. Mirrors
+ * `requireGitIdentity`'s shape exactly (`CoreResult<void>`, pure, safe to call before any read/write)
+ * — intended as the FIRST check `directiveRemove`/`workflowRemove` run, before any reference check,
+ * so a protected or unrecognised path is rejected on structure alone. Returns a `VALIDATION`
+ * `CoreResult.error` (a failed precondition, like the sibling pre-flights `requireGitIdentity` and
+ * `requireApprovalAuthority`; exit `1` via `exitCodeForError`) carrying REQ-SEC-07's exact fit-criterion
+ * wording for a declared built-in, or a generic `cannot remove '<path>': …` refusal — shaped after
+ * P3.3's own `cannot remove '<name>': …` message — for any other unrecognised shape; otherwise `ok`.
+ */
+function requireCustomAsset(kind, relativePath) {
+    if (isRemovableCustomAssetPath(kind, relativePath)) {
+        return (0, types_1.coreOk)(undefined);
+    }
+    const message = declaresBuiltInPath(kind, relativePath)
+        ? BUILT_IN_REMOVAL_ERROR[kind]
+        : `cannot remove '${relativePath}': not a ${kind} under '${ASSET_ROOT_SEGMENT[kind]}/${CUSTOM_SEGMENT}/'`;
+    return (0, types_1.coreErr)({ code: 'VALIDATION', message });
+}
+//# sourceMappingURL=builtin-asset.js.map

package/dist/core/builtin-asset.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"builtin-asset.js","sourceRoot":"","sources":["../../src/core/builtin-asset.ts"],"names":[],"mappings":";;AA2GA,gEAEC;AAwBD,gDAQC;AA7ID;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6CG;AACH,mCAA2D;AAK3D,8FAA8F;AAC9F,MAAM,kBAAkB,GAA8B;IACpD,SAAS,EAAE,YAAY;IACvB,QAAQ,EAAE,WAAW;CACtB,CAAC;AAEF,oGAAoG;AACpG,MAAM,cAAc,GAAG,QAAQ,CAAC;AAEhC,8EAA8E;AAC9E,MAAM,gBAAgB,GAAG,UAAU,CAAC;AAEpC;;;;;;;GAOG;AACH,MAAM,sBAAsB,GAA8B;IACxD,SAAS,EAAE,uCAAuC;IAClD,QAAQ,EAAE,sCAAsC;CACjD,CAAC;AAEF;;;;GAIG;AACH,SAAS,UAAU,CAAC,YAAoB;IACtC,OAAO,YAAY,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC;AACrC,CAAC;AAED;;;;;GAKG;AACH,SAAS,iBAAiB,CAAC,IAAe,EAAE,YAAoB,EAAE,YAAoB;IACpF,MAAM,QAAQ,GAAG,UAAU,CAAC,YAAY,CAAC,CAAC;IAC1C,IAAI,QAAQ,CAAC,MAAM,GAAG,CAAC;QAAE,OAAO,KAAK,CAAC;IACtC,IAAI,CAAC,QAAQ,CAAC,KAAK,CAAC,CAAC,OAAO,EAAE,EAAE,CAAC,OAAO,KAAK,EAAE,IAAI,OAAO,KAAK,GAAG,IAAI,OAAO,KAAK,IAAI,CAAC;QAAE,OAAO,KAAK,CAAC;IACtG,OAAO,QAAQ,CAAC,CAAC,CAAC,KAAK,kBAAkB,CAAC,IAAI,CAAC,IAAI,QAAQ,CAAC,CAAC,CAAC,KAAK,YAAY,CAAC;AAClF,CAAC;AAED;;;;;;;;GAQG;AACH,SAAgB,0BAA0B,CAAC,IAAe,EAAE,YAAoB;IAC9E,OAAO,iBAAiB,CAAC,IAAI,EAAE,YAAY,EAAE,cAAc,CAAC,CAAC;AAC/D,CAAC;AAED;;;;;;;GAOG;AACH,SAAS,mBAAmB,CAAC,IAAe,EAAE,YAAoB;IAChE,OAAO,iBAAiB,CAAC,IAAI,EAAE,YAAY,EAAE,gBAAgB,CAAC,CAAC;AACjE,CAAC;AAED;;;;;;;;;GASG;AACH,SAAgB,kBAAkB,CAAC,IAAe,EAAE,YAAoB;IACtE,IAAI,0BAA0B,CAAC,IAAI,EAAE,YAAY,CAAC,EAAE,CAAC;QACnD,OAAO,IAAA,cAAM,EAAO,SAAS,CAAC,CAAC;IACjC,CAAC;IACD,MAAM,OAAO,GAAG,mBAAmB,CAAC,IAAI,EAAE,YAAY,CAAC;QACrD,CAAC,CAAC,sBAAsB,CAAC,IAAI,CAAC;QAC9B,CAAC,CAAC,kBAAkB,YAAY,YAAY,IAAI,WAAW,kBAAkB,CAAC,IAAI,CAAC,IAAI,cAAc,IAAI,CAAC;IAC5G,OAAO,IAAA,eAAO,EAAC,EAAE,IAAI,EAAE,YAAY,EAAE,OAAO,EAAE,CAAC,CAAC;AAClD,CAAC"}

package/dist/core/builtin-integrity.d.ts

@@ -0,0 +1,32 @@
+import { type BuiltinTemplateKind, type BuiltinTemplateSource } from '../storage';
+export type { BuiltinTemplateKind, BuiltinTemplateSource } from '../storage';
+/**
+ * The first built-in template source {@link verifyBuiltinTemplates} found invalid: its `name`/`kind`
+ * (identifying which source failed) plus the exact, already-formatted abort `message` — either the
+ * P3.8 directive wording or the P4.17 workflow wording, per REQ-SEC-10's fit criterion.
+ */
+export interface BuiltinIntegrityFailure {
+    readonly name: string;
+    readonly kind: BuiltinTemplateKind;
+    readonly message: string;
+}
+/**
+ * Schema-check every `sources` entry, in list order (REQ-SYS-07: deterministic, no unordered
+ * iteration), and return the FIRST one that fails — or `null` when every source is valid (including
+ * the trivial, always-passing case of an empty list, which is what `src/storage/templates.ts`'s
+ * `builtinTemplateSources` derives from the P1.1 minimal skeleton, whose built-in directory holds only
+ * a `.gitkeep`; `templateScaffold` yields the six P3.8 built-in directives since
+ * `task-057-builtin-directive-templates`).
+ *
+ * FAILS CLOSED on an unrecognized `kind`: a source whose kind has no {@link INTEGRITY_POLICY} entry is
+ * reported as a failure ({@link unknownKindMessage}) rather than skipped or thrown on — it cannot be
+ * checked, so it must not be installed.
+ *
+ * Callers — `initWingfoilProject` AND `initWingfoilStorage`, both in `src/core/init.ts`; every
+ * `initStorage` write path there is one — MUST run this before writing any file: REQ-SEC-10's fit
+ * criterion requires the abort to happen "before writing partial assets". This function itself never
+ * writes or reads from disk, so calling it before the scaffold write is sufficient to satisfy that
+ * ordering.
+ */
+export declare function verifyBuiltinTemplates(sources: readonly BuiltinTemplateSource[]): BuiltinIntegrityFailure | null;
+//# sourceMappingURL=builtin-integrity.d.ts.map

package/dist/core/builtin-integrity.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"builtin-integrity.d.ts","sourceRoot":"","sources":["../../src/core/builtin-integrity.ts"],"names":[],"mappings":"AA8BA,OAAO,EAAsB,KAAK,mBAAmB,EAAE,KAAK,qBAAqB,EAAE,MAAM,YAAY,CAAC;AAItG,YAAY,EAAE,mBAAmB,EAAE,qBAAqB,EAAE,MAAM,YAAY,CAAC;AAE7E;;;;GAIG;AACH,MAAM,WAAW,uBAAuB;IACtC,QAAQ,CAAC,IAAI,EAAE,MAAM,CAAC;IACtB,QAAQ,CAAC,IAAI,EAAE,mBAAmB,CAAC;IACnC,QAAQ,CAAC,OAAO,EAAE,MAAM,CAAC;CAC1B;AAuFD;;;;;;;;;;;;;;;;;GAiBG;AACH,wBAAgB,sBAAsB,CACpC,OAAO,EAAE,SAAS,qBAAqB,EAAE,GACxC,uBAAuB,GAAG,IAAI,CAehC"}