@theholocron/astromech 5.0.0-alpha.17 → 5.0.0-alpha.171

package/dist/index.d.mts

@@ -1,34 +1,223 @@
-import { r as TasksConfig } from "./schema-D01VYg43.mjs";
-//#region src/run.d.ts
+import { r as TasksConfig } from "./schema.type-BJmfOafW.mjs";
+//#region src/generators/codecov/codecov.type.d.ts
+interface WorkspacePackage$1 {
+  slug: string;
+  name: string;
+  /** Which workspace root the package was discovered under. Defaults to `"packages"`. */
+  dir?: "packages" | "apps" | "plugins";
+}
+//#endregion
+//#region src/generators/codecov/codecov.d.ts
+declare function codecovComponentBlock(packages: WorkspacePackage$1[]): string;
 /**
- * `holocron run <task> [job] [-- <passthrough>]` — run a registry task (or one
- * of its sub-jobs) locally.
+ * Ensure every codecov status default carries `if_not_found: success`, so an
+ * infra-only PR (dep bump, config, lockfile — no coverable change) passes
+ * instead of hanging forever on a required check codecov never posts.
  *
- * A `job` argument only applies to tasks that declare `jobs`; for any other
- * task it is folded back into the passthrough (`holocron run delivery.build
- * src/`).
+ * Injects the key on the line after each `target:` that sits inside a status
+ * block (`coverage.status.*.default` or a `statuses:` list item — indent ≥ 8,
+ * or ≥ 8 for a `- type:` list entry), when the immediate sibling lines do not
+ * already declare it.
+ */
+declare function ensureIfNotFound(yaml: string): string;
+declare function mergeCodecovComponents(existing: string, packages: WorkspacePackage$1[]): string;
+/**
+ * Every public `packages/*`, `apps/*`, and `plugins/*` workspace, sorted by
+ * slug. `[]` when none of the three directories exist. Monorepo templates
+ * (Next.js, React, …) ship user-facing code under `apps/` alongside library
+ * code under `packages/`; `holocron` itself splits vendor plugin packages
+ * into their own `plugins/*` root — every recognized root needs a codecov
+ * component so `codecov/patch/<slug>` actually posts for each.
+ */
+declare function readWorkspacePackages(repoRoot: string): WorkspacePackage$1[];
+/** A brand-new `codecov.yml` — the scaffold header + the base template + this repo's component list. */
+declare function createCodecovConfig(packages: WorkspacePackage$1[]): string;
+/**
+ * The full pipeline `holocron repo setup` needs: read this repo's public
+ * `packages/*`, then either merge them into an `existing` `codecov.yml` or
+ * scaffold a new one.
+ */
+declare function codecovConfig(repoRoot: string, existing: string | null): string;
+//#endregion
+//#region src/generators/github-action-reusable-workflows/github-action-reusable-workflows.d.ts
+/**
+ * The **reusable** GitHub Actions surface pushed to `theholocron/.github` by
+ * `holocron sync github` — the `workflow_call` implementations and composite
+ * actions that every repo's thin callers delegate to.
  *
- * Resolution:
+ * `theholocron/.github` is a **pure sync target**: `.github/workflows/*`,
+ * `.github/actions/*` and `workflow-templates/*` there are generated from the
+ * `.yml` files in `src/templates/reusable/` and pushed verbatim (with a
+ * "do not edit" header). Never hand-edit them in `.github`.
  *
- *   J. job given                              → TASKS[task].jobs[job].local (unknown job → exit 1)
- *   1. turbo.json defines the task            → `turbo run <task>`
- *   2. package.json has a `<task>` script     → `<pm> run <task>`
- *      (unless it's the `holocron run …` thin caller — that recurses)
- *   3. TASKS[task].local resolves             → `<tool> <args> <org-flags> <passthrough>`
- *   3b. TASKS[task].linterGroup               → run each resolved linter natively (see below)
- *   4. TASKS[task].jobs has entries           → run each job in declared order
- *   5. TASKS[task].local === null             → "enforced in CI" (skip, even with --required)
- *   5b. known task, nothing resolved          → "no <task> task" (exit 0, or 1 with --required)
- *   6. unknown task                           → "unknown task" (exit 1)
+ * Not to be confused with `WORKFLOW_TEMPLATES` in `github-action-thin-callers.ts` — those are
+ * the *thin-caller bases* written into each consumer repo's `.github/workflows/`.
+ */
+/** `workflow_call` implementations → `.github/workflows/<name>.yml`. */
+declare const REUSABLE_WORKFLOWS: Record<string, string>;
+/** Composite actions → `.github/actions/<name>/action.yml` (key includes `/action`). */
+declare const REUSABLE_ACTIONS: Record<string, string>;
+/** GitHub starter-workflow metadata → `workflow-templates/<name>.properties.json`. */
+declare const WORKFLOW_TEMPLATE_PROPERTIES: Record<string, string>;
+/**
+ * The complete file batch `holocron sync github` pushes to `theholocron/.github`:
+ * path → content. YAML gets the "do not edit" header; the starter-workflow
+ * `.properties.json` files are left bare (native JSON, not a commented file).
+ */
+declare function reusableTemplates(): Map<string, string>;
+//#endregion
+//#region src/generators/github-action-thin-callers/github-action-thin-callers.type.d.ts
+interface PreviewConfig {
+  /** Cloudflare Pages project name shared across all repos for previews. */
+  project: string;
+  /**
+   * Base domain for preview URLs (e.g. `"preview.theholocron.dev"`).
+   * When set, `holocron repo setup` automatically provisions:
+   * - Cloudflare Pages custom domain `*.<domain>` on the project
+   * - DNS wildcard CNAME `*.<domain>` → `<project>.pages.dev`
+   *
+   * Preview URLs resolve as `<repo>-pr-<n>.<domain>`.
+   */
+  domain?: string;
+}
+/** Org-level context used to derive preview defaults from `preview: true`. */
+interface OrgContext {
+  /** GitHub org name — becomes the prefix of the default project: `<org>-preview`. */
+  org?: string;
+  /** Org canonical domain — becomes `preview.<domain>` for the default preview domain. */
+  domain?: string;
+  /** Project name — injected as the `name` input to the deploy reusable when `docs: true`. */
+  repoName?: string;
+}
+//#endregion
+//#region src/generators/github-action-thin-callers/github-action-thin-callers.d.ts
+declare const WORKFLOW_TEMPLATES: Record<string, string>;
+declare const KNOWN_WORKFLOWS: Set<string>;
+/**
+ * The GitHub status-check context a `required` task contributes to branch
+ * protection. Format: `"{workflow name} / {job name}"`.
  *
- * A `linterGroup` task (`sourceQuality.staticAnalysis`, etc.) runs its fixed
- * set of `linters.ts` entries, each still gated by that linter's own
- * `detect`/`always` rule — every entry runs its `localBin` natively when
- * found on PATH. Missing tools are flagged; the exit code is the worst of
- * the lot. Unlike the old single `lint` task, this check runs *after*
- * turbo/`package.json` resolution (step 3b, not step 0) — a `linterGroup`
- * task is a normal turbo-delegatable task like any other.
+ * Most of these are single-job workflows now (D3's decomposition split what
+ * used to be multi-job `lint`/`audit` into one task per concern) — the
+ * context names that job directly, no `Conclusion` aggregator needed; a
+ * single job's own conclusion already *is* the workflow's conclusion.
+ * `Conclusion` fan-in jobs are kept only where a task genuinely has several
+ * conditionally-run jobs feeding one required check:
+ * `verification.unitTests` (unit / Storybook / Chromatic / interaction /
+ * user-flow, each gated by its own `run-*` input) and
+ * `platform.repoValidation` (its three script jobs all must pass). Only
+ * merge-gating workflows are listed. `astromech.requiredChecks()` reads this
+ * for every `required` task.
  */
+declare const WORKFLOW_CHECK_CONTEXTS: Partial<Record<string, string>>;
+/**
+ * Generate the thin caller content for a workflow, optionally injecting or
+ * merging `with:` overrides into the jobs block.
+ *
+ * Two strategies are used depending on the template:
+ * - Templates that already have a `with:` block (e.g. lint):
+ *   the override entries are merged in, replacing existing keys and appending
+ *   new ones.
+ * - Templates that end with `    secrets: inherit`: a new `with:` block is
+ *   injected immediately before `secrets: inherit`.
+ * If neither pattern matches the template, a warning is emitted and the
+ * base template is returned unchanged.
+ */
+declare function generateThinCallerContent(name: string, withOverrides?: Record<string, unknown>, additionalPaths?: string[],
+/** Optional sink for the "could not inject `with:`" warning. */
+logger?: {
+  warn(obj: Record<string, unknown>, msg: string): void;
+},
+/**
+ * `with:` key → a `# comment` line rendered immediately above that entry.
+ * Only honored when injecting a fresh `with:` block (no template today
+ * ships one), which is the path `lint` takes.
+ */
+comments?: Record<string, string>): string;
+/**
+ * Extract the Cloudflare Pages preview config from a deploy workflow's `with:` object.
+ *
+ * Accepts three forms:
+ * - `preview: true` — derive both project and domain from org context
+ * - `preview: { project: "..." }` — explicit project; domain derived from context if omitted
+ * - `preview: { project: "...", domain: "..." }` — fully explicit
+ *
+ * Returns null when `preview:` is absent, false, or can't be resolved.
+ */
+declare function extractPreviewConfig(raw: Record<string, unknown>, ctx?: OrgContext): PreviewConfig | null;
+/**
+ * Generate the full thin-caller YAML for a `deploy.yml` that handles both
+ * production (push to main → GitHub Pages) and preview (pull_request →
+ * Cloudflare Pages) in a single file.
+ *
+ * Both jobs receive the same docs/storybook `with:` inputs. If the per-repo
+ * config supplies `cloudflare-project` it is forwarded; otherwise the reusable
+ * falls back to the `CLOUDFLARE_PAGES_PROJECT` org variable — set that once and
+ * all repos with a `deploy` workflow get previews without per-repo config.
+ */
+declare function generateCombinedDeployContent(deployWith: Record<string, unknown>, paths: string[], preview: Pick<PreviewConfig, "project">): string;
+/**
+ * Expand structured with-values to flat GitHub Actions inputs before
+ * generating the thin caller. Handles:
+ *   - deploy shorthand: docs/storybook → type + storybook-projects
+ *   - preview: stripped (handled separately via extractPreviewConfig)
+ *   - chromatic-projects entries' untraced array → newline-joined string
+ *   - plain arrays → JSON-stringified for YAML scalar quoting
+ *
+ * Used by both `holocron repo setup` and `sync-workflow-templates`.
+ */
+declare function normalizeWorkflowWith(raw: Record<string, unknown>): Record<string, unknown>;
+/**
+ * Derive on.push.paths entries from the deploy with: shorthand.
+ * Used by both `holocron repo setup` and `sync-workflow-templates`.
+ */
+declare function deriveDeployPaths(raw: Record<string, unknown>): string[];
+//#endregion
+//#region src/generators/required-checks/required-checks.d.ts
+/** Ordered (task contexts in {@link CI_ORDER}, then extras), de-duplicated. */
+declare function requiredChecks(config: TasksConfig): string[];
+//#endregion
+//#region src/generators/tsconfig/tsconfig.type.d.ts
+interface TsconfigOptions {
+  /** Human-readable name for the `display` field — the package's own name is the usual choice. */
+  display: string;
+  /**
+   * `@theholocron/tsconfig` variant. Defaults to `"node-lts"` — every
+   * checked package uses it; the other three (`astro`, `nextjs`, `react`)
+   * exist for a template repo's app-shaped packages, not the plain
+   * Node.js library packages this org's currently-migrated repos ship.
+   */
+  variant?: "astro" | "nextjs" | "node-lts" | "react";
+  /**
+   * Add a `@/*` → `./src/*` path alias. A real per-package choice, not a
+   * default — roughly 40% of packages checked use one, the rest don't.
+   */
+  paths?: boolean;
+}
+//#endregion
+//#region src/generators/tsconfig/tsconfig.d.ts
+/**
+ * A package-level `tsconfig.json` — the uniform shape confirmed across
+ * every package checked, parameterized only by the two fields that
+ * genuinely vary (`display`, `paths`). No scaffold/workflow header (matches
+ * `.alexrc.json`'s existing precedent for a strict-JSON Bucket B file —
+ * JSON has no comment syntax to carry one, and TypeScript's own tolerance
+ * for JSONC comments in `tsconfig.json` isn't worth relying on for a file
+ * this thin).
+ */
+declare function createTsconfig(options: TsconfigOptions): string;
+//#endregion
+//#region src/generators/turbo/turbo.type.d.ts
+interface EnsureRootWorkspaceMemberResult {
+  content: string;
+  changed: boolean;
+}
+interface EnsureTurboDependencyResult {
+  content: string;
+  changed: boolean;
+}
+//#endregion
+//#region src/tasks/run/run.type.d.ts
 /** Minimal structural logger — `@theholocron/observability`'s `Logger` satisfies it. */
 interface RunLogger {
   debug(obj: Record<string, unknown>, msg?: string): void;
@@ -80,9 +269,11 @@ interface RunTaskReport {
   command?: string;
   message?: string;
 }
+//#endregion
+//#region src/tasks/run/run.d.ts
 declare function runTask(input: RunTaskInput): RunTaskReport;
 //#endregion
-//#region src/ci.d.ts
+//#region src/tasks/ci/ci.type.d.ts
 interface CiOptions {
   /** Print the plan without running anything. */
   dryRun?: boolean;
@@ -107,127 +298,178 @@ interface CiInput extends RunDeps, CiOptions {
   cwd: string;
   config: TasksConfig;
 }
+//#endregion
+//#region src/tasks/ci/ci.d.ts
 declare function runCi(input: CiInput): CiReport;
 //#endregion
-//#region src/thin-callers.d.ts
-/**
- * Workflow templates + thin-caller generation.
- *
- * `WORKFLOW_TEMPLATES` holds each reusable `.github/workflows/<name>.yml`
- * (synced to `theholocron/.github`); `generateThinCallerContent` wraps one
- * into the thin caller `holocron setup` / `holocron sync` write locally.
- */
-declare const WORKFLOW_TEMPLATES: Record<string, string>;
-declare const KNOWN_WORKFLOWS: Set<string>;
-/**
- * The GitHub status-check context a `required` task contributes to branch
- * protection. Format: `"{workflow name} / {job name}"`.
- *
- * Most of these are single-job workflows now (D3's decomposition split what
- * used to be multi-job `lint`/`audit` into one task per concern) — the
- * context names that job directly, no `Conclusion` aggregator needed; a
- * single job's own conclusion already *is* the workflow's conclusion.
- * `Conclusion` fan-in jobs are kept only where a task genuinely has several
- * conditionally-run jobs feeding one required check:
- * `verification.unitTests` (unit / Storybook / Chromatic / interaction /
- * user-flow, each gated by its own `run-*` input) and
- * `platform.repoValidation` (its three script jobs all must pass). Only
- * merge-gating workflows are listed. `astromech.requiredChecks()` reads this
- * for every `required` task.
- */
-declare const WORKFLOW_CHECK_CONTEXTS: Partial<Record<string, string>>;
-/**
- * Generate the thin caller content for a workflow, optionally injecting or
- * merging `with:` overrides into the jobs block.
- *
- * Two strategies are used depending on the template:
- * - Templates that already have a `with:` block (e.g. lint):
- *   the override entries are merged in, replacing existing keys and appending
- *   new ones.
- * - Templates that end with `    secrets: inherit`: a new `with:` block is
- *   injected immediately before `secrets: inherit`.
- * If neither pattern matches the template, a warning is emitted and the
- * base template is returned unchanged.
- */
-declare function generateThinCallerContent(name: string, withOverrides?: Record<string, unknown>, additionalPaths?: string[],
-/** Optional sink for the "could not inject `with:`" warning. */
-logger?: {
-  warn(obj: Record<string, unknown>, msg: string): void;
-},
-/**
- * `with:` key → a `# comment` line rendered immediately above that entry.
- * Only honored when injecting a fresh `with:` block (no template today
- * ships one), which is the path `lint` takes.
- */
-comments?: Record<string, string>): string;
-interface PreviewConfig {
-  /** Cloudflare Pages project name shared across all repos for previews. */
-  project: string;
+//#region src/utils/create-header/create-header.type.d.ts
+/** Comment style produced by workflowHeader. */
+type WorkflowHeaderFormat = "yaml" | "cjs" | "shebang";
+interface CreateHeaderOptions {
+  /** Path within theholocron/holocron that owns the file being generated. */
+  source: string;
+  /** CLI command that produces the file. Defaults to "holocron repo setup". */
+  tool?: string;
+  /** Set true only when writing to theholocron/.github itself. */
+  forPrimary?: boolean;
+}
+interface HeaderFunctions {
   /**
-   * Base domain for preview URLs (e.g. `"preview.theholocron.dev"`).
-   * When set, `holocron setup` automatically provisions:
-   * - Cloudflare Pages custom domain `*.<domain>` on the project
-   * - DNS wildcard CNAME `*.<domain>` → `<project>.pages.dev`
+   * "AUTO-GENERATED — do not edit" header for files managed on every run.
    *
-   * Preview URLs resolve as `<repo>-pr-<n>.<domain>`.
+   * format:
+   *   "yaml"    — `# …` comment lines (YAML, text, ignore files)
+   *   "cjs"     — `/* … *\/` block comment (CommonJS modules)
+   *   "shebang" — `#!/bin/sh` on line 1, then yaml header (shell scripts)
    */
-  domain?: string;
-}
-/** Org-level context used to derive preview defaults from `preview: true`. */
-interface OrgContext {
-  /** GitHub org name — becomes the prefix of the default project: `<org>-preview`. */
-  org?: string;
-  /** Org canonical domain — becomes `preview.<domain>` for the default preview domain. */
-  domain?: string;
-  /** Project name — injected as the `name` input to the deploy reusable when `docs: true`. */
-  repoName?: string;
+  workflowHeader(format?: WorkflowHeaderFormat): string;
+  /**
+   * "Scaffolded — edit this file freely" header for one-time generated files
+   * that the user is expected to take over (e.g. codecov.yml).
+   */
+  scaffoldHeader(): string;
 }
+//#endregion
+//#region src/utils/create-header/create-header.d.ts
 /**
- * Extract the Cloudflare Pages preview config from a deploy workflow's `with:` object.
+ * Factory that binds `source` and `tool` once and returns all header
+ * constructors for auto-generated files. Prefer this over passing source
+ * as a positional argument at every call site.
  *
- * Accepts three forms:
- * - `preview: true` — derive both project and domain from org context
- * - `preview: { project: "..." }` — explicit project; domain derived from context if omitted
- * - `preview: { project: "...", domain: "..." }` — fully explicit
+ * @example
+ * const { workflowHeader, scaffoldHeader } = createHeader({
+ *   source: "packages/astromech/src/templates/configs/editorconfig/create-config.ts",
+ * });
  *
- * Returns null when `preview:` is absent, false, or can't be resolved.
- */
-declare function extractPreviewConfig(raw: Record<string, unknown>, ctx?: OrgContext): PreviewConfig | null;
-/**
- * Generate the full thin-caller YAML for a `deploy.yml` that handles both
- * production (push to main → GitHub Pages) and preview (pull_request →
- * Cloudflare Pages) in a single file.
+ * export function createConfig(): string {
+ *   return `${workflowHeader()}${body}`;
+ * }
  *
- * Both jobs receive the same docs/storybook `with:` inputs. If the per-repo
- * config supplies `cloudflare-project` it is forwarded; otherwise the reusable
- * falls back to the `CLOUDFLARE_PAGES_PROJECT` org variable — set that once and
- * all repos with a `deploy` workflow get previews without per-repo config.
+ * ## Which header to use
+ *
+ * | Function          | When to use                                        | User can edit? |
+ * |-------------------|----------------------------------------------------|----------------|
+ * | `workflowHeader`  | Files overwritten on every setup / sync-github run | No — "AUTO-GENERATED — do not edit" |
+ * | `scaffoldHeader`  | Files written once; user takes ownership after     | Yes — "Scaffolded — edit this file freely" |
+ *
+ * ## `workflowHeader` formats
+ *
+ * | Format              | Comment style          | Used for                                              |
+ * |---------------------|------------------------|-------------------------------------------------------|
+ * | `"yaml"` (default)  | `# …` lines            | YAML workflows, ignore files, `.editorconfig`, labeler|
+ * | `"cjs"`             | `/* … *\/` block       | CommonJS config files (`.cjs`)                        |
+ * | `"shebang"`         | `#!/bin/sh` + `# …`    | Shell scripts (`prepare-commit-msg`, hooks)           |
  */
-declare function generateCombinedDeployContent(deployWith: Record<string, unknown>, paths: string[], preview: Pick<PreviewConfig, "project">): string;
+declare function createHeader(options: CreateHeaderOptions): HeaderFunctions;
+//#endregion
+//#region src/utils/default-list-dirs/default-list-dirs.d.ts
+declare const defaultListDirs: (path: string) => string[];
+//#endregion
+//#region src/utils/default-read-json/default-read-json.d.ts
+declare const defaultReadJson: (path: string) => unknown;
+//#endregion
+//#region src/utils/default-run/default-run.type.d.ts
+interface SpawnResult {
+  status: number | null;
+  stdout: string;
+  stderr: string;
+}
+type Run = (command: string, args: string[], options: Record<string, unknown>) => SpawnResult;
+//#endregion
+//#region src/tasks/deploy-on-release/workspace-packages/workspace-packages.type.d.ts
+/** A workspace package: absolute folder, and what its `package.json` says. */
+interface WorkspacePackage {
+  name: string;
+  dir: string;
+  version: string | undefined;
+  dependencies: Record<string, string>;
+}
+interface Tree {
+  readJson: (path: string) => unknown;
+  listDirs: (path: string) => string[];
+}
+//#endregion
+//#region src/tasks/deploy-on-release/workspace-packages/workspace-packages.d.ts
 /**
- * Expand structured with-values to flat GitHub Actions inputs before
- * generating the thin caller. Handles:
- *   - deploy shorthand: docs/storybook → type + storybook-projects
- *   - preview: stripped (handled separately via extractPreviewConfig)
- *   - run-chromatic object → run-chromatic: true + chromatic-projects
- *   - plain arrays → JSON-stringified for YAML scalar quoting
- *
- * Used by both `holocron setup` and `sync-workflow-templates`.
+ * Every package under `<repoRoot>/packages/*`, `<repoRoot>/apps/*` and
+ * `<repoRoot>/plugins/*` with a readable, named `package.json` — `holocron`'s
+ * own layout splits vendor plugin packages into `plugins/*` and deployable
+ * apps into `apps/*`, siblings to `packages/*`.
  */
-declare function normalizeWorkflowWith(raw: Record<string, unknown>): Record<string, unknown>;
+declare function workspacePackages(repoRoot: string, { readJson, listDirs }: Tree): WorkspacePackage[];
+//#endregion
+//#region src/tasks/deploy-on-release/deploy-on-release.type.d.ts
+interface DeployOnReleaseOptions {
+  cwd: string;
+  /** The release's channel: its prerelease identifier (`alpha`); empty or `main` for a stable release. */
+  channel: string;
+  /** The previous release's commit; omitted when there is none, so every deploying channel match deploys. */
+  from?: string;
+  /** The release commit. Default `HEAD`. */
+  to?: string;
+  /** Where progress lines go (stdout in the CLI). */
+  print: (line: string) => void;
+  dryRun?: boolean;
+}
+interface DeployOnReleaseDeps extends Partial<Tree> {
+  run?: Run;
+  sleep?: (ms: number) => Promise<void>;
+  now?: () => number;
+  /** Reads a package folder's task manifest; `loadTasksConfig` by default. */
+  loadTasks?: (dir: string) => Promise<TasksConfig>;
+}
+interface DeployOnReleaseResult {
+  pkg: string;
+  status: "ok" | "fail" | "skip" | "dry-run";
+  message: string;
+}
+interface DeployOnReleaseReport {
+  /** `fail` if any package's deploy failed; `skip` if none applied to this release; else `ok`. */
+  status: "ok" | "fail" | "skip";
+  results: DeployOnReleaseResult[];
+}
+//#endregion
+//#region src/tasks/deploy-on-release/deploy-on-release.d.ts
 /**
- * Derive on.push.paths entries from the deploy with: shorthand.
- * Used by both `holocron setup` and `sync-workflow-templates`.
+ * Deploys every package whose manifest declares a release-time deploy that
+ * applies to this release. Never throws for a deploy problem: each package's
+ * outcome is in the report, and `status: "fail"` is the caller's exit code.
  */
-declare function deriveDeployPaths(raw: Record<string, unknown>): string[];
+declare function deployOnRelease(options: DeployOnReleaseOptions, { run, readJson, listDirs, sleep, now, loadTasks }?: DeployOnReleaseDeps): Promise<DeployOnReleaseReport>;
 //#endregion
-//#region src/turbo.d.ts
-interface EnsureRootWorkspaceMemberResult {
-  content: string;
-  changed: boolean;
+//#region src/tasks/group/group.type.d.ts
+interface GroupOptions {
+  /** Print the resolved commands without running anything. */
+  dryRun?: boolean;
+  /** `turbo --filter=<pkg>` passthrough (monorepo). */
+  filter?: string;
+}
+interface GroupJobReport {
+  task: string;
+  status: "ok" | "fail" | "skip" | "dry-run";
+  command?: string;
+  message?: string;
+}
+interface GroupReport {
+  /** `"unknown"` when the namespace matches zero configured tasks. */
+  status: "ok" | "fail" | "dry-run" | "unknown";
+  jobs: GroupJobReport[];
+}
+interface GroupInput extends RunDeps, GroupOptions {
+  cwd: string;
+  config: TasksConfig;
+  /** The bare namespace, e.g. `"sourceQuality"` — matched against `"sourceQuality."`-prefixed task names. */
+  namespace: string;
 }
 //#endregion
-//#region src/astromech.d.ts
+//#region src/tasks/group/group.d.ts
+declare function runGroup(input: GroupInput): GroupReport;
+//#endregion
+//#region src/tasks/match-namespace/match-namespace.d.ts
+/** Every configured task whose name starts with `"<namespace>."`, in manifest declaration order. */
+declare function matchNamespace(config: TasksConfig, namespace: string): string[];
+//#endregion
+//#region src/astromech.type.d.ts
 interface AstromechOptions {
   /** Repo root. */
   cwd: string;
@@ -272,8 +514,15 @@ interface RunOptions {
   filter?: string;
 }
 interface Astromech {
-  /** Run one task — or one of its sub-jobs (`opts.job`) — locally. */
-  run(task: string, opts?: RunOptions): RunTaskReport;
+  /**
+   * Run one task — or one of its sub-jobs (`opts.job`) — locally. When
+   * `task` isn't an exact registry task but matches the prefix of one or
+   * more configured tasks (`"sourceQuality"` against `sourceQuality.*`),
+   * runs every matching task in sequence instead ({@link GroupReport}) —
+   * `opts.job` is ignored for a namespace match, since a job belongs to
+   * one task, not a namespace.
+   */
+  run(task: string, opts?: RunOptions): RunTaskReport | GroupReport;
   /**
    * Run the merge-gating checks locally, in CI order — "will CI pass?".
    * Default scope: `required: true` tasks (falls back to every `ci: true`
@@ -288,7 +537,7 @@ interface Astromech {
    */
   thinCallers(): Map<string, string>;
   /**
-   * The complete reusable-workflow batch `holocron sync-github` pushes to
+   * The complete reusable-workflow batch `holocron sync github` pushes to
    * `theholocron/.github` — repo-relative path → content, "do not edit" header
    * already applied to the YAML. Config-independent (the same for every repo).
    */
@@ -301,10 +550,19 @@ interface Astromech {
    * when there is no config or `syncScripts: false`.
    */
   packageScripts(): Record<string, string>;
+  /**
+   * Task names this repo's manifest can actually run locally — the same
+   * filter {@link packageScripts} applies (skips `local: false` and tasks
+   * with no local runner at all), but independent of `syncScripts`: a repo
+   * that opts out of generated `package.json` scripts still has real
+   * runnable tasks. Empty when there is no config. Backs `holocron`'s own
+   * interactive task picker (`run` with no task given).
+   */
+  runnableTasks(): string[];
   /**
    * The branch-protection required-status-check contexts for this repo —
    * every `required: true` task's check context plus `extraRequiredChecks`,
-   * ordered and de-duplicated. `holocron setup` prepends `"DCO"` and applies
+   * ordered and de-duplicated. `holocron repo setup` prepends `"DCO"` and applies
    * the list; this method is policy-free (manifest only).
    */
   requiredChecks(): string[];
@@ -312,7 +570,7 @@ interface Astromech {
    * This repo's `codecov.yml` — component `paths` derived from `packages/*`.
    * Pass the current file's content (`null` if none exists yet) to either
    * merge the component list in or scaffold a fresh file. Policy-free same
-   * as {@link requiredChecks} — `holocron setup` owns writing the result.
+   * as {@link requiredChecks} — `holocron repo setup` owns writing the result.
    */
   codecovConfig(existing: string | null): string;
   /**
@@ -328,151 +586,30 @@ interface Astromech {
    * (not just an orchestrator) silently vanishes from `turbo run <task>`.
    * Pass `pnpm-workspace.yaml`'s current content (or `""` if none exists —
    * a no-op either way, since no `packages:` key means single-package mode
-   * already) and root `package.json`'s own `scripts` keys. `changed: false`
-   * means don't write anything — the file is already correct.
+   * already) and root `package.json`'s own `scripts` object — values and
+   * all, not just keys, so a task-name-matching script that's already the
+   * generated `holocron run <task> --` wrapper (predating this call, not
+   * written by it) is correctly excluded rather than treated as proof root
+   * is directly buildable (#846). `changed: false` means don't write
+   * anything — the file is already correct.
    */
-  ensureRootWorkspaceMember(workspaceYaml: string, rootScripts: readonly string[]): EnsureRootWorkspaceMemberResult;
-}
-declare function createAstromech(options: AstromechOptions): Astromech;
-//#endregion
-//#region src/codecov.d.ts
-/**
- * `codecov.yml` generation — a manifest-derived artifact (component `paths`
- * come from workspace packages; the status targets track the `test` task's
- * coverage setup), the same category as the reusable `test.yml` this package
- * also generates. Moved out of `@theholocron/cli` (theholocron/holocron#650)
- * — `holocron setup`'s codecov step now calls {@link codecovConfig} instead
- * of importing this logic directly.
- */
-interface WorkspacePackage {
-  slug: string;
-  name: string;
-  /** Which workspace root the package was discovered under. Defaults to `"packages"`. */
-  dir?: "packages" | "apps";
-}
-declare function codecovComponentBlock(packages: WorkspacePackage[]): string;
-/**
- * Ensure every codecov status default carries `if_not_found: success`, so an
- * infra-only PR (dep bump, config, lockfile — no coverable change) passes
- * instead of hanging forever on a required check codecov never posts.
- *
- * Injects the key on the line after each `target:` that sits inside a status
- * block (`coverage.status.*.default` or a `statuses:` list item — indent ≥ 8,
- * or ≥ 8 for a `- type:` list entry), when the immediate sibling lines do not
- * already declare it.
- */
-declare function ensureIfNotFound(yaml: string): string;
-declare function mergeCodecovComponents(existing: string, packages: WorkspacePackage[]): string;
-/**
- * Every public `packages/*` and `apps/*` workspace, sorted by slug. `[]`
- * when neither directory exists. Monorepo templates (Next.js, React, …)
- * ship user-facing code under `apps/` alongside library code under
- * `packages/` — both need a codecov component so `codecov/patch/<slug>`
- * actually posts for each.
- */
-declare function readWorkspacePackages(repoRoot: string): WorkspacePackage[];
-/** A brand-new `codecov.yml` — the scaffold header + the base template + this repo's component list. */
-declare function createCodecovConfig(packages: WorkspacePackage[]): string;
-/**
- * The full pipeline `holocron setup` needs: read this repo's public
- * `packages/*`, then either merge them into an `existing` `codecov.yml` or
- * scaffold a new one.
- */
-declare function codecovConfig(repoRoot: string, existing: string | null): string;
-//#endregion
-//#region src/linters.d.ts
-/**
- * The linter registry — one list of linter names (from `config.tasks`'
- * `{ name: "lint", linters: [...] }`, or auto-detected) maps to both the
- * CI super-linter `VALIDATE_*` env and the native local run. This table is
- * the single source of truth for that mapping; {@link superLinterConfig}
- * (CI) and the `holocron run lint` aggregate (local) both read it.
- *
- * Spec: `docs/wiki/specifications/tech-astromech-task-runner.spec.md` "Lint parity".
- */
-interface LinterDef {
+  ensureRootWorkspaceMember(workspaceYaml: string, rootScripts: Readonly<Record<string, string>>): EnsureRootWorkspaceMemberResult;
   /**
-   * super-linter `VALIDATE_*` keys this linter turns on. Setting any
-   * `VALIDATE_*` puts super-linter in allow-list mode, so emitting only the
-   * enabled keys makes it run exactly this set.
+   * `turboConfig()` writes a `turbo.json` but never touches `package.json`
+   * — a repo with no local `turbo` devDependency falls back to whatever
+   * (if anything) is globally on `PATH`, per `run.ts`'s `resolveBin()`.
+   * Pass root `package.json`'s raw content and `pnpm-workspace.yaml`'s
+   * current content (checked for an existing `turbo` catalog entry, which
+   * takes precedence over the hardcoded fallback version). `changed: false`
+   * means don't write anything — `devDependencies.turbo` already exists.
    */
-  validate: string[];
-  /** super-linter `FIX_*` keys (auto-commit / `--write` parity). */
-  fix?: string[];
-  /**
-   * Local binary, resolved from `node_modules/.bin` then `PATH`. Absent →
-   * the linter has no meaningful local run (`holocron run lint` prints
-   * "CI only"); CI still enforces it.
-   */
-  localBin?: string;
-  /** Args for `localBin` in CHECK mode — never `--write` / `--fix`. */
-  localArgs?: string[];
-  /**
-   * Shown by `holocron run lint` when `localBin` is set but not found on
-   * PATH — the "you're missing a tool the repo needs" nudge.
-   */
-  installHint?: string;
-  /**
-   * Repo-root filenames that auto-enable this linter when the `lint` task
-   * has no explicit `linters` list. Ignored when {@link always} is set.
-   */
-  detect?: string[];
-  /** Enabled regardless of detection (the org baseline). */
-  always?: boolean;
-  /** Reusable-workflow config-file input this linter honors, if any. */
-  configInput?: "eslint-config" | "prettier-config" | "yaml-config";
+  ensureTurboDependency(packageJson: string, workspaceYaml: string): EnsureTurboDependencyResult;
 }
-/**
- * Known linters, in execution order. `always` entries are the current
- * hard-coded super-linter baseline; `prettier` is always-on because the org
- * applies it universally (super-linter only lints files that exist).
- */
-declare const LINTERS: Record<string, LinterDef>;
-/** Every linter name the registry knows. */
-declare const LINTER_NAMES: ReadonlySet<string>;
-/**
- * Resolve the linter set for a repo. An `explicit` list (from `config.tasks`)
- * picks the candidate set; otherwise the candidates are every `always` linter
- * plus every `detect`-gated linter whose filenames are present at the repo
- * root. Either way, a `detect`-gated linter (eslint, markdownlint) only makes
- * the final set when its config file is actually present — a repo can't run
- * eslint without an `eslint.config.*`, and super-linter FATALs if you ask it
- * to (theholocron/holocron#654). `always` linters are unconditional. Result
- * is ordered by {@link LINTERS} declaration order.
- *
- * @throws when an `explicit` name is not in the registry — a typo is a
- * config bug, not a linter to silently skip.
- */
-declare function resolveLinters(opts: {
-  explicit?: string[];
-  rootFiles: string[];
-}): Array<{
-  name: string;
-  def: LinterDef;
-}>;
 //#endregion
-//#region src/registry.d.ts
-/**
- * The task registry — how each task runs *locally*, without GitHub
- * Actions. `holocron run <task>` and `holocron ci` resolve against this;
- * adding a task here gives every repo that task.
- *
- * Keyed identically to the workflow templates — a task IS a workflow. This
- * is the canonical vocabulary table (epic #672, D11): every other artifact
- * (`KNOWN_TASKS`, `thin-callers.ts`'s `KNOWN_WORKFLOWS`/`WORKFLOW_CHECK_CONTEXTS`,
- * `CI_ORDER`) derives from these keys rather than hand-duplicating them —
- * including the future GitHub App (#679), which imports this same table for
- * config-schema validation instead of reimplementing its own copy.
- *
- * Task names are an intent-facing vocabulary (`verification.*`,
- * `sourceQuality.*`, `security.*`, `delivery.*`, `platform.*`,
- * `knowledge.*`), not tool names — `eslint`/`vitest`/`tsdown`/… stay
- * internal to this file and `theholocron/configs`. See
- * `.notes/tech-vocabulary-rename.spec.md` (#675) for the full mapping and
- * the reasoning behind each namespace and decomposition.
- *
- * Spec: `docs/wiki/specifications/tech-astromech-task-runner.spec.md` (epic #581).
- */
+//#region src/astromech.d.ts
+declare function createAstromech(options: AstromechOptions): Astromech;
+//#endregion
+//#region src/registry/registry.type.d.ts
 /** How to run one task (or job) locally. */
 interface LocalRunner {
   /** Binary to invoke — resolved from `node_modules/.bin` then PATH. */
@@ -511,7 +648,7 @@ interface JobDef {
   /**
    * The CI status-check context this job reports as (e.g.
    * `platform.repoValidation / Validate registry consistency`) — every sub-job is a CI job.
-   * `holocron run <task>` and `holocron ci` label each job line with it;
+   * `holocron run <task>` and `holocron run ci` label each job line with it;
    * the task-level `… / Conclusion` context (only for tasks with several
    * jobs) lives in `WORKFLOW_CHECK_CONTEXTS`.
    */
@@ -522,7 +659,7 @@ interface TaskDef {
    * `null` — the registry has no built-in runner (CodeQL, deploys, the
    * bundle-size job). An explicit turbo task or `package.json` script still
    * runs (resolution steps 1–2); with neither, `holocron run` does nothing
-   * and `holocron ci` skips it — never a failure, even when the task is
+   * and `holocron run ci` skips it — never a failure, even when the task is
    * `required` (a CI-only check isn't a local one).
    */
   local: LocalRunner | null;
@@ -548,155 +685,124 @@ interface TaskDef {
   /** Turborepo fan-out config for this task — see {@link TurboTaskConfig}. Omitted for whole-repo, non-fan-out tasks. */
   turbo?: TurboTaskConfig;
 }
+//#endregion
+//#region src/registry/registry.d.ts
+/**
+ * The task registry — how each task runs *locally*, without GitHub
+ * Actions. `holocron run <task>` and `holocron run ci` resolve against this;
+ * adding a task here gives every repo that task.
+ *
+ * Keyed identically to the workflow templates — a task IS a workflow. This
+ * is the canonical vocabulary table (epic #672, D11): every other artifact
+ * (`KNOWN_TASKS`, `thin-callers.ts`'s `KNOWN_WORKFLOWS`/`WORKFLOW_CHECK_CONTEXTS`,
+ * `CI_ORDER`) derives from these keys rather than hand-duplicating them —
+ * including the future GitHub App (#679), which imports this same table for
+ * config-schema validation instead of reimplementing its own copy.
+ *
+ * Task names are an intent-facing vocabulary (`verification.*`,
+ * `sourceQuality.*`, `security.*`, `delivery.*`, `platform.*`,
+ * `knowledge.*`), not tool names — `eslint`/`vitest`/`tsdown`/… stay
+ * internal to this file and `theholocron/configs`. See
+ * `docs/wiki/specifications/tech-vocabulary-rename.spec.md` (#675) for the full mapping and
+ * the reasoning behind each namespace and decomposition.
+ *
+ * Spec: `docs/wiki/specifications/tech-astromech-task-runner.spec.md` (epic #581).
+ */
 declare const TASKS: Record<string, TaskDef>;
 /** Every task name the registry knows. */
 declare const KNOWN_TASKS: Set<string>;
 /**
- * The order `holocron ci` runs tasks in — cheapest / fastest signal first, so
+ * The order `holocron run ci` runs tasks in — cheapest / fastest signal first, so
  * an agent or a `pre-push` hook fails early. Tasks not listed here run last, in
  * manifest order. (The generated thin callers carry no `needs:` — cross-workflow
- * ordering lives in `theholocron/.github` — so `holocron ci` declares its own.)
+ * ordering lives in `theholocron/.github` — so `holocron run ci` declares its own.)
  */
 declare const CI_ORDER: string[];
 //#endregion
-//#region src/required-checks.d.ts
-/** Ordered (task contexts in {@link CI_ORDER}, then extras), de-duplicated. */
-declare function requiredChecks(config: TasksConfig): string[];
-//#endregion
-//#region src/resolver.d.ts
+//#region src/tasks/deploy-on-release/default-paths/default-paths.d.ts
 /**
- * Resolves the absolute path to a Bucket A tool's shared `@theholocron/*-config`
- * entry point, installed in the consuming repo's own `node_modules` — and the
- * CLI flag(s) to hand it via (`--config`, `--extends`, …). `run.ts` splices the
- * result into the command it builds for a tool/detect runner or a linter-group
- * entry, right after the tool's own args.
- *
- * Every mapped package's resolved entry point already carries a ready-to-use
- * default export (a plain re-export for `prettier`/`commitlint`; an invoked,
- * zero-arg preset for `eslint`/`vitest`/`tsdown` — verified end-to-end against
- * each tool's real `--config`/`--extends` loader, not just the file's shape).
- * A repo doesn't need this package installed at all — every lookup degrades to
- * `[]` (no flag added, the tool falls back to its own auto-discovery of a
- * local file, unchanged from today) rather than throwing, so this is additive
- * and safe to run unconditionally.
+ * The paths a release must touch to redeploy `pkg` when its manifest doesn't
+ * list them: its own folder plus the folder of every
+ * {@link workspaceDependencies} entry. Derived rather than listed so a new or
+ * dropped workspace dependency needs no second edit.
  *
- * `semantic-release`, `devmoji`, `editorconfig-checker`, and `knip` are
- * deliberately absent — `semantic-release-config`'s `defineConfig()` needs
- * real per-repo data (branches, npm options) a static `--extends <path>` can't
- * carry; `devmoji` runs through a git hook template, not `holocron run
- * <task>`; `editorconfig-checker` has no shared-config package yet; `knip` is
- * repo-specific by nature, never a shared-config candidate. See
- * `.notes/tech-config-resolution.spec.md` (#676).
- */
-interface ResolverDeps {
-  readFile: (path: string) => string;
-  fileExists: (path: string) => boolean;
-}
-/** Every tool name the resolver knows how to point at a shared config. */
-declare const RESOLVABLE_TOOLS: ReadonlySet<string>;
-/**
- * `<flag> <absolute path>` for `tool`, resolved against `cwd`'s
- * `node_modules` — or `[]` when the tool isn't mapped, the package isn't
- * installed, its `package.json` doesn't declare the export subpath this
- * needs, or the resolved file doesn't actually exist on disk (a stale
- * install, or a package version that predates the export existing).
+ * @returns Repo-relative prefixes, each ending in `/`.
  */
-declare function resolveToolConfig(tool: string, cwd: string, deps: ResolverDeps): string[];
+declare function defaultPaths(repoRoot: string, pkg: WorkspacePackage, all: WorkspacePackage[]): string[];
 //#endregion
-//#region src/reusable.d.ts
+//#region src/templates/configs/alexjs/create-config.d.ts
+declare function createRcConfig(): string;
+declare function createIgnoreConfig(): string;
+//#endregion
+//#region src/templates/configs/commit-msg/create-config.d.ts
 /**
- * The **reusable** GitHub Actions surface pushed to `theholocron/.github` by
- * `holocron sync-github` — the `workflow_call` implementations and composite
- * actions that every repo's thin callers delegate to.
+ * `.husky/commit-msg` — lints the commit message via `holocron run lint
+ * commit-msg` (holocron#789), the real programmatic replacement for
+ * shelling out to `commitlint --edit`. Installed by `holocron repo setup` when
+ * hooks are enabled. Same `__HOLOCRON_SCRIPT__` substitution as `pre-push`.
  *
- * `theholocron/.github` is a **pure sync target**: `.github/workflows/*`,
- * `.github/actions/*` and `workflow-templates/*` there are generated from the
- * `.yml` files in `src/templates/reusable/` and pushed verbatim (with a
- * "do not edit" header). Never hand-edit them in `.github`.
- *
- * Not to be confused with `WORKFLOW_TEMPLATES` in `thin-callers.ts` — those are
- * the *thin-caller bases* written into each consumer repo's `.github/workflows/`.
+ * @param holocronScript - the command that invokes the CLI. Defaults to
+ *   `pnpm exec holocron`; the source repo passes `node packages/cli/dist/cli.mjs`.
  */
-/** `workflow_call` implementations → `.github/workflows/<name>.yml`. */
-declare const REUSABLE_WORKFLOWS: Record<string, string>;
-/** Composite actions → `.github/actions/<name>/action.yml` (key includes `/action`). */
-declare const REUSABLE_ACTIONS: Record<string, string>;
-/** GitHub starter-workflow metadata → `workflow-templates/<name>.properties.json`. */
-declare const WORKFLOW_TEMPLATE_PROPERTIES: Record<string, string>;
+declare function createConfig(holocronScript?: string): string;
+//#endregion
+//#region src/templates/configs/dependabot/create-config.d.ts
+declare function createConfig$1(): string;
+//#endregion
+//#region src/templates/configs/devmoji/create-config.d.ts
+declare function createConfig$2(): string;
+//#endregion
+//#region src/templates/configs/editorconfig/create-config.d.ts
+declare function createConfig$3(): string;
+//#endregion
+//#region src/templates/configs/editorconfig-checker/create-config.d.ts
 /**
- * The complete file batch `holocron sync-github` pushes to `theholocron/.github`:
- * path → content. YAML gets the "do not edit" header; the starter-workflow
- * `.properties.json` files are left bare (native JSON, not a commented file).
+ * The generated `.editorconfig-checker.json`.
+ *
+ * Deliberately carries no `"Version"` key: editorconfig-checker treats it as a
+ * hard gate and exits non-zero the moment the running binary's version differs
+ * — which it does the instant a contributor's local install (Homebrew tracks
+ * latest) drifts from the version super-linter bundles in CI, breaking
+ * `holocron run lint` / the pre-push hook for everyone (#618). The config
+ * options here (`Exclude`, `Disable`) are stable across releases, so pinning
+ * buys nothing.
  */
-declare function reusableTemplates(): Map<string, string>;
+declare function createConfig$4(): string;
 //#endregion
-//#region src/tsconfig.d.ts
+//#region src/templates/configs/labeler/create-config.d.ts
+declare function createConfig$5(): string;
+//#endregion
+//#region src/templates/configs/pre-commit/create-config.d.ts
 /**
- * `tsconfig.json` generation — Bucket B (config-resolution workstream, #676):
- * the file must stay committed (the TypeScript language server discovers it
- * directly from disk, no `--config` override mechanism to hand it a path
- * instead), but its content is fully derivable, so it's generated rather
- * than hand-authored — the same category as `.editorconfig`
- * ({@link "./templates/configs/editorconfig/create-config.js" createConfig})
- * and {@link codecovConfig}.
- *
- * Surveyed every package-level `tsconfig.json` across the org (`holocron`,
- * `clients`, `utils` — 20+ packages). `extends: "@theholocron/tsconfig/
- * node-lts"`, `compilerOptions.baseUrl: "./"`, `compilerOptions.outDir:
- * "./dist"`, `include: ["src/**\/*.ts"]`, and `exclude: ["node_modules",
- * "dist"]` are uniform in every one — safe defaults here. `paths` (a `@/*`
- * → `./src/*` import alias) is a real per-package choice, present in
- * roughly 40% of packages checked — an opt-in parameter, not a default.
- *
- * Two fields checked and deliberately *not* absorbed as defaults, unlike
- * `eslint-config`'s `tsconfigRootDir`/`settings.node` (which turned out
- * redundant with the shared package's own behavior, `configs`#461):
- * `compilerOptions.module`/`moduleResolution` (only `@theholocron/cli`
- * overrides these, to `esnext`/`bundler` — a genuine deviation from the
- * shared `node-lts` preset's `nodenext`/`nodenext`, needed for its bundler
- * tooling, not something every package should inherit) and
- * `compilerOptions.rootDir` (present in exactly two packages, always the
- * same value `./src` that `include` already implies — an unnecessary
- * override wherever it appears, not a pattern worth generalizing).
+ * `.husky/pre-commit` — runs GitLeaks (scoped to staged changes) and
+ * lint-staged before every commit. Installed by `holocron repo setup` when hooks
+ * are enabled (default for `protection: "strict"`). `git commit --no-verify`
+ * bypasses it.
  *
- * Monorepo *root* `tsconfig.json` (a TS project-references "solution
- * file" — `holocron`'s own root is `{ files: [], references: [...] }`,
- * listing which packages to build) is a structurally different, genuinely
- * per-repo document — out of scope here, same as Bucket C content.
- *
- * Not yet wired into `holocron setup`'s per-package write loop (every
- * other Bucket B file there is a single repo-root file, safely
- * overwritten every run — `tsconfig.json` is per-package, and most
- * packages' files still carry real hand-authored content today, not yet
- * migrated to a fully-generated state). That per-package iteration +
- * safe-migration design is `#680`'s job, not duplicated here — this is
- * the generator itself, ready for it to call.
+ * `gitleaks protect --staged` (not `gitleaks git`) is deliberate: the latter
+ * scans the entire commit history on every invocation, so once any false
+ * positive lands in a past commit — a fake test token, an example key in a
+ * doc — every future commit is permanently blocked, regardless of what's
+ * actually staged.
  */
-interface TsconfigOptions {
-  /** Human-readable name for the `display` field — the package's own name is the usual choice. */
-  display: string;
-  /**
-   * `@theholocron/tsconfig` variant. Defaults to `"node-lts"` — every
-   * checked package uses it; the other three (`astro`, `nextjs`, `react`)
-   * exist for a template repo's app-shaped packages, not the plain
-   * Node.js library packages this org's currently-migrated repos ship.
-   */
-  variant?: "astro" | "nextjs" | "node-lts" | "react";
-  /**
-   * Add a `@/*` → `./src/*` path alias. A real per-package choice, not a
-   * default — roughly 40% of packages checked use one, the rest don't.
-   */
-  paths?: boolean;
-}
+declare function createConfig$6(): string;
+//#endregion
+//#region src/templates/configs/pre-push/create-config.d.ts
 /**
- * A package-level `tsconfig.json` — the uniform shape confirmed across
- * every package checked, parameterized only by the two fields that
- * genuinely vary (`display`, `paths`). No scaffold/workflow header (matches
- * `.alexrc.json`'s existing precedent for a strict-JSON Bucket B file —
- * JSON has no comment syntax to carry one, and TypeScript's own tolerance
- * for JSONC comments in `tsconfig.json` isn't worth relying on for a file
- * this thin).
+ * `.husky/pre-push` — runs `holocron run ci` (the merge-gating checks, in CI order)
+ * before every push. Installed by `holocron repo setup` when hooks are enabled
+ * (default for `protection: "strict"`). `git push --no-verify` bypasses it.
+ *
+ * @param holocronScript - the command that invokes the CLI. Defaults to
+ *   `pnpm exec holocron`; the source repo passes `node packages/cli/dist/cli.mjs`.
  */
-declare function createTsconfig(options: TsconfigOptions): string;
+declare function createConfig$7(holocronScript?: string): string;
+//#endregion
+//#region src/templates/configs/prepare-commit-msg/create-config.d.ts
+declare function createConfig$8(): string;
+//#endregion
+//#region src/templates/configs/yamllint/create-config.d.ts
+declare function createConfig$9(): string;
+declare function createIgnoreConfig$1(): string;
 //#endregion
-export { type Astromech, type AstromechOptions, CI_ORDER, type CiJobReport, type CiOptions, type CiReport, type ExecFn, type JobDef, KNOWN_TASKS, KNOWN_WORKFLOWS, LINTERS, LINTER_NAMES, type LinterDef, type LocalRunner, type OrgContext, type PreviewConfig, RESOLVABLE_TOOLS, REUSABLE_ACTIONS, REUSABLE_WORKFLOWS, type ResolverDeps, type RunLogger, type RunOptions, type RunTaskInput, type RunTaskReport, TASKS, type TaskDef, type TsconfigOptions, WORKFLOW_CHECK_CONTEXTS, WORKFLOW_TEMPLATES, WORKFLOW_TEMPLATE_PROPERTIES, type WorkspacePackage, codecovComponentBlock, codecovConfig, createAstromech, createCodecovConfig, createTsconfig, deriveDeployPaths, ensureIfNotFound, extractPreviewConfig, generateCombinedDeployContent, generateThinCallerContent, mergeCodecovComponents, normalizeWorkflowWith, readWorkspacePackages, requiredChecks, resolveLinters, resolveToolConfig, reusableTemplates, runCi, runTask };
+export { type Astromech, type AstromechOptions, CI_ORDER, type CiJobReport, type CiOptions, type CiReport, type CreateHeaderOptions, type DeployOnReleaseOptions, type DeployOnReleaseReport, type DeployOnReleaseResult, type WorkspacePackage as DeployWorkspacePackage, type ExecFn, type GroupJobReport, type GroupOptions, type GroupReport, type HeaderFunctions, type JobDef, KNOWN_TASKS, KNOWN_WORKFLOWS, type LocalRunner, type OrgContext, type PreviewConfig, REUSABLE_ACTIONS, REUSABLE_WORKFLOWS, type RunLogger, type RunOptions, type RunTaskInput, type RunTaskReport, TASKS, type TaskDef, type TsconfigOptions, WORKFLOW_CHECK_CONTEXTS, WORKFLOW_TEMPLATES, WORKFLOW_TEMPLATE_PROPERTIES, type WorkflowHeaderFormat, type WorkspacePackage$1 as WorkspacePackage, codecovComponentBlock, codecovConfig, createIgnoreConfig as createAlexignore, createRcConfig as createAlexrc, createAstromech, createCodecovConfig, createConfig as createCommitMsg, createConfig$1 as createDependabot, createConfig$2 as createDevmoji, createConfig$3 as createEditorconfig, createConfig$4 as createEditorconfigChecker, createHeader, createConfig$5 as createLabeler, createConfig$6 as createPreCommit, createConfig$7 as createPrePush, createConfig$8 as createPrepareCommitMsg, createTsconfig, createIgnoreConfig$1 as createYamlignore, createConfig$9 as createYamllint, defaultListDirs, defaultPaths, defaultReadJson, deployOnRelease, deriveDeployPaths, ensureIfNotFound, extractPreviewConfig, generateCombinedDeployContent, generateThinCallerContent, matchNamespace, mergeCodecovComponents, normalizeWorkflowWith, readWorkspacePackages, requiredChecks, reusableTemplates, runCi, runGroup, runTask, workspacePackages };