blogwright 0.3.2 → 0.4.0-beta.0

package/dist/graph.d.ts

@@ -1,20 +1,31 @@
-import type { OpsContext } from './context.js';
-/** A node in the infrastructure dependency graph. */
-export interface ResourceNode {
-    id: string;
-    dependsOn: string[];
-    /** Human label for logging. */
-    title: string;
-    /** Does the resource already exist? (Also hydrates outputs into ctx.state.) */
-    read(ctx: OpsContext): Promise<boolean>;
-    create(ctx: OpsContext): Promise<void>;
-    /** Reconcile an existing resource (optional). */
-    update?(ctx: OpsContext): Promise<void>;
-    delete(ctx: OpsContext): Promise<void>;
+import type { ResourceNode, ResourceOutputs } from 'blogwright-core';
+/**
+ * The structural minimum the engine below (`topoSort`, `applyGraph`,
+ * `destroyGraph`) actually reads off a node's context: a logger it calls
+ * `step`/`ok`/`warn` on, a way to persist state, and the state's resources
+ * map (`destroyGraph` deletes an entry from it). Exported so a caller
+ * running this engine over a different context - `OpsContext` (`context.ts`)
+ * and core's `PluginContext` (`blogwright-core`) both do already - knows
+ * exactly what that context must supply, without this module depending on
+ * either one. Neither `OpsContext` nor `PluginContext` is named here on
+ * purpose: this is the structural minimum both happen to satisfy, not a
+ * fixed supertype of them (see the doc comment on core's `ResourceNode` for
+ * why no such supertype is worth naming).
+ */
+export interface GraphContext {
+    logger: {
+        step(msg: string): void;
+        ok(msg: string): void;
+        warn(msg: string): void;
+    };
+    state: {
+        resources: Record<string, ResourceOutputs>;
+    };
+    save(): Promise<void>;
 }
 /** Topologically order nodes so dependencies come before dependents (Kahn's algorithm). */
-export declare function topoSort(nodes: ResourceNode[]): ResourceNode[];
+export declare function topoSort<Ctx>(nodes: ResourceNode<Ctx>[]): ResourceNode<Ctx>[];
 /** Reconcile the graph in dependency order (create missing, update existing). */
-export declare function applyGraph(nodes: ResourceNode[], ctx: OpsContext): Promise<void>;
+export declare function applyGraph<Ctx extends GraphContext>(nodes: ResourceNode<Ctx>[], ctx: Ctx): Promise<void>;
 /** Tear down the graph in reverse dependency order. */
-export declare function destroyGraph(nodes: ResourceNode[], ctx: OpsContext): Promise<void>;
+export declare function destroyGraph<Ctx extends GraphContext>(nodes: ResourceNode<Ctx>[], ctx: Ctx): Promise<void>;

package/dist/graph.js

@@ -77,9 +77,8 @@ export async function destroyGraph(nodes, ctx) {
         await node.delete(ctx);
         delete ctx.state.resources[node.id];
         // The state lives in the bucket that is itself being deleted, so persisting it may
-        // fail (NoSuchBucket) once the bucket node is gone — never let that abort teardown.
+        // fail (NoSuchBucket) once the bucket node is gone - never let that abort teardown.
         await ctx.save().catch(() => undefined);
         ctx.logger.ok(`deleted ${node.title}`);
     }
 }
-//# sourceMappingURL=graph.js.map

package/dist/init.d.ts

@@ -1,4 +1,38 @@
-import { type FileSystem, type Terminal } from 'blogwright-core';
+import { type FileSystem, type Plugin, type Terminal } from 'blogwright-core';
 import type { Logger } from './logger.js';
-/** Run the wizard. Returns a process exit code; never throws for expected refusals. */
-export declare function initSite(fs: FileSystem, terminal: Terminal, logger: Logger, root?: string): Promise<number>;
+/**
+ * One question, and how to ask it: shown text, a prefilled default, whether
+ * an empty answer must re-prompt, and an optional validator. Exported - and
+ * `ask` below along with it - because `plugin-commands.ts`'s `io.ask` (the
+ * surface an `init?(io)` contributor asks its own questions through) reuses
+ * this exact prompt/validate/retry loop rather than writing a second one; no
+ * plugin path may reach `node:readline` itself. Structurally the same shape
+ * as core's `PluginQuestion` (`blogwright-core`'s `plugin.ts`), so a
+ * contributor's question passes straight through with no conversion.
+ */
+export interface Question {
+    prompt: string;
+    defaultValue?: string | undefined;
+    required?: boolean | undefined;
+    validate?: ((answer: string) => string | undefined) | undefined;
+}
+/**
+ * Ask `q.prompt` over `terminal`, retrying up to `MAX_ATTEMPTS` times on a
+ * required-but-empty answer or a `validate` failure, and resolving with
+ * `undefined` for an unanswered optional question. Throws once every attempt
+ * is spent. The one prompt/validate/retry loop every wizard-shaped question -
+ * `blogwright init`'s own four and any plugin's `init?(io)` contributor -
+ * asks through.
+ */
+export declare function ask(terminal: Terminal, logger: Logger, q: Question): Promise<string | undefined>;
+/**
+ * Run the wizard. Returns a process exit code; never throws for expected
+ * refusals (non-interactive, an existing config file). `plugins` is every
+ * plugin the caller has ALREADY discovered (`cli.ts`, over
+ * `DiscoveryPortsFactory`) - this function asks their questions and writes
+ * their blocks but never runs discovery itself. A plugin's `init(io)`
+ * contributor throwing propagates unchanged, rejecting this call before the
+ * single `fs.writeText` below ever runs, so the config file stays exactly
+ * what it was - absent, on this path - rather than a partial write.
+ */
+export declare function initSite(fs: FileSystem, terminal: Terminal, logger: Logger, plugins: readonly Plugin[], root?: string): Promise<number>;

package/dist/init.js

@@ -1,14 +1,28 @@
 /*
- * `blogwright init` — the first-run wizard. Asks the four questions a new site
- * needs, writes a commented config/production.jsonc, and prints the path to a
- * live site. Runs before any context exists (there is no config to load yet),
- * so it takes its ports directly.
+ * `blogwright init` - the first-run wizard. Asks the four core questions a
+ * new site needs, then each already-discovered plugin's own `init(io)`
+ * questions (in deterministic, name-sorted order), and writes ONE commented
+ * config/production.jsonc carrying every answered block. Runs before any
+ * context exists (there is no config to load yet), so it takes its ports
+ * directly. Plugin discovery itself is the composition root's job
+ * (`cli.ts`), never this module's: `initSite` takes the already-discovered
+ * plugins as a plain array, never a `ModuleLoader`, so this stays a domain
+ * module.
  */
-import { colors, findRepoRoot } from 'blogwright-core';
+import { colors, findRepoRoot, parseConfig, } from 'blogwright-core';
+import { renderConfigBlock } from './config-block.js';
 const SITE_NAME_PATTERN = /^[a-z0-9-]+$/;
 const GITHUB_REPO_PATTERN = /^[\w.-]+\/[\w.-]+$/;
 const MAX_ATTEMPTS = 3;
-async function ask(terminal, logger, q) {
+/**
+ * Ask `q.prompt` over `terminal`, retrying up to `MAX_ATTEMPTS` times on a
+ * required-but-empty answer or a `validate` failure, and resolving with
+ * `undefined` for an unanswered optional question. Throws once every attempt
+ * is spent. The one prompt/validate/retry loop every wizard-shaped question -
+ * `blogwright init`'s own four and any plugin's `init?(io)` contributor -
+ * asks through.
+ */
+export async function ask(terminal, logger, q) {
     for (let attempt = 0; attempt < MAX_ATTEMPTS; attempt++) {
         const suffix = q.defaultValue ? ` [${q.defaultValue}]` : '';
         const answer = (await terminal.question(`${q.prompt}${suffix}: `)).trim() || q.defaultValue;
@@ -25,44 +39,140 @@ async function ask(terminal, logger, q) {
         }
         return answer;
     }
-    throw new Error(`no valid answer after ${MAX_ATTEMPTS} attempts — giving up`);
+    throw new Error(`no valid answer after ${MAX_ATTEMPTS} attempts - giving up`);
+}
+/**
+ * Build the `io` an `init?(io)` contributor asks its own questions through,
+ * entirely over the `ask` loop above - never a second prompt/validate/retry
+ * loop. Mirrors `plugin-commands.ts`'s own `buildInitIo` (the other path
+ * that reaches a plugin's contributor, `blogwright <plugin> init`) rather
+ * than importing it: that module already imports `ask` from here, so the
+ * reverse import would be a cycle between the two (see `known-commands.ts`'s
+ * module comment for what that class of cycle already broke once in this
+ * package). `ask` resolves `undefined` for an unanswered optional question;
+ * `PluginInitIo.ask` promises a `string` always, per the no-null rule, so
+ * the empty string stands in for "declined" here too.
+ */
+function buildInitIo(terminal, logger) {
+    return {
+        isInteractive: terminal.isInteractive,
+        logger,
+        ask: async (question) => (await ask(terminal, logger, question)) ?? '',
+    };
+}
+/**
+ * Ask one plugin's `init(io)` contributor its questions and render what it
+ * returns as a `"key": { ... }` block in `renderConfigBlock`'s style, or
+ * `undefined` when the operator answered nothing (an empty array). A
+ * contributor with no `configKey` to file its answers under is a
+ * plugin-authoring bug, not an operator refusal - raised naming the plugin,
+ * the same check `plugin-commands.ts`'s `runGenericInit` makes for the other
+ * path that reaches a contributor, so both refuse identically.
+ *
+ * This DOES abort the whole wizard - a misconfigured plugin among several
+ * stops every other plugin's block (and the core entries) from being
+ * written at all, unlike a candidate-level `plugins.ts` discovery failure,
+ * which is collected and never blocks an unrelated command. The
+ * inconsistency is deliberate, not overlooked: this is a plugin-authoring
+ * bug the operator cannot fix by re-running (unlike a transient discovery
+ * failure), `runGenericInit` - the sibling path - has no "continue past it"
+ * option either, since it operates on exactly one plugin, and this task's
+ * own contract is for the two paths to reach a contributor identically.
+ * Diverging here would need `plugin-commands.ts` to diverge too, which is
+ * outside this module's ownership.
+ */
+async function askPluginBlock(plugin, contributor, io) {
+    const configKey = plugin.configKey;
+    if (!configKey) {
+        throw new Error(`plugin "${plugin.name}" declares an init(io) contributor but no configKey - there is ` +
+            'nothing to file its answered block under');
+    }
+    const entries = await contributor(io);
+    if (entries.length === 0)
+        return undefined;
+    return renderConfigBlock(configKey, entries.map((entry) => ({ prop: entry.property, comment: entry.comment })));
 }
+/**
+ * Ask every plugin in `plugins` that declares an `init(io)` contributor, in
+ * deterministic order - sorted by `name`, never discovery or argument order
+ * - and return each answered block. A plugin declining (an empty array) or
+ * carrying no contributor at all contributes nothing: never a stray entry,
+ * never a stray comma once `renderConfig` composes the result.
+ */
+async function collectPluginBlocks(plugins, terminal, logger) {
+    const io = buildInitIo(terminal, logger);
+    const sorted = [...plugins].sort((a, b) => (a.name < b.name ? -1 : a.name > b.name ? 1 : 0));
+    const blocks = [];
+    for (const plugin of sorted) {
+        const contributor = plugin.init;
+        if (!contributor)
+            continue;
+        const block = await askPluginBlock(plugin, contributor, io);
+        if (block)
+            blocks.push(block);
+    }
+    return blocks;
+}
+/** Render one top-level item with its own trailing comma, or none when it is last. */
+function renderTopLevelItem(item, last) {
+    const comma = last ? '' : ',';
+    if ('block' in item)
+        return `${item.block}${comma}`;
+    return `  ${item.prop}${comma}${item.comment ? ` // ${item.comment}` : ''}`;
+}
+/**
+ * Render the whole `config/production.jsonc` body: the four core entries in
+ * their fixed, commented style, followed by every plugin block already
+ * rendered by `collectPluginBlocks` - each its own top-level property, comma
+ * discipline shared with the core entries via `renderTopLevelItem` so no
+ * block ever leaves (or follows) a stray comma. `pluginBlocks` empty
+ * reproduces exactly the entries-only output this wizard has always
+ * written - byte for byte, pinned by `init.test.ts`.
+ */
 function renderConfig(opts) {
-    const entries = [
+    const items = [
         { prop: `"region": "${opts.region}"` },
         {
             prop: `"siteName": "${opts.siteName}"`,
-            comment: 'stable slug in every AWS resource name — never change it',
+            comment: 'stable slug in every AWS resource name - never change it',
         },
     ];
     if (opts.domain)
-        entries.push({ prop: `"domain": "${opts.domain}"` });
+        items.push({ prop: `"domain": "${opts.domain}"` });
     if (opts.githubRepo) {
-        entries.push({
+        items.push({
             prop: `"githubRepo": "${opts.githubRepo}"`,
             comment: 'enables the GitHub OIDC deploy role',
         });
     }
-    const body = entries.map((e, i) => {
-        const comma = i < entries.length - 1 ? ',' : '';
-        return `  ${e.prop}${comma}${e.comment ? ` // ${e.comment}` : ''}`;
-    });
-    return ['// config/production.jsonc — created by `blogwright init`', '{', ...body, '}', ''].join('\n');
+    for (const block of opts.pluginBlocks)
+        items.push({ block });
+    const body = items.map((item, i) => renderTopLevelItem(item, i === items.length - 1));
+    return ['// config/production.jsonc - created by `blogwright init`', '{', ...body, '}', ''].join('\n');
 }
-/** Run the wizard. Returns a process exit code; never throws for expected refusals. */
-export async function initSite(fs, terminal, logger, root) {
+/**
+ * Run the wizard. Returns a process exit code; never throws for expected
+ * refusals (non-interactive, an existing config file). `plugins` is every
+ * plugin the caller has ALREADY discovered (`cli.ts`, over
+ * `DiscoveryPortsFactory`) - this function asks their questions and writes
+ * their blocks but never runs discovery itself. A plugin's `init(io)`
+ * contributor throwing propagates unchanged, rejecting this call before the
+ * single `fs.writeText` below ever runs, so the config file stays exactly
+ * what it was - absent, on this path - rather than a partial write.
+ */
+export async function initSite(fs, terminal, logger, plugins, root) {
     if (!terminal.isInteractive) {
         logger.error('init is an interactive wizard; in CI or plain mode create config/production.jsonc ' +
-            'by hand instead (see README — only "region" and "siteName" are required)');
+            'by hand instead (see README - only "region" and "siteName" are required)');
         return 1;
     }
     const repoRoot = root ?? (await findRepoRoot(fs).catch(() => process.cwd()));
     const configPath = `${repoRoot}/config/production.jsonc`;
     if (await fs.exists(configPath)) {
-        logger.error(`${configPath} already exists — edit it directly, or pass --config elsewhere`);
+        logger.error(`${configPath} already exists - edit it directly, or pass --config elsewhere`);
         return 1;
     }
-    logger.info(colors.bold('Welcome to blogwright — four questions and you are live.'));
+    logger.info(colors.bold('Welcome to blogwright - four questions and you are live.'));
     const siteName = await ask(terminal, logger, {
         prompt: 'site name (lowercase slug, names every AWS resource)',
         required: true,
@@ -80,7 +190,21 @@ export async function initSite(fs, terminal, logger, root) {
         prompt: 'GitHub repo for CI deploys, owner/repo (blank to skip)',
         validate: (v) => (GITHUB_REPO_PATTERN.test(v) ? undefined : 'expected owner/repo'),
     });
-    await fs.writeText(configPath, renderConfig({ region: region, siteName: siteName, domain, githubRepo }));
+    const pluginBlocks = await collectPluginBlocks(plugins, terminal, logger);
+    const rendered = renderConfig({
+        region: region,
+        siteName: siteName,
+        domain,
+        githubRepo,
+        pluginBlocks,
+    });
+    // Re-parsed before it is trusted onto disk, mirroring `plugin-commands.ts`'s
+    // `runGenericInit` (the sibling path composing a plugin's block into an
+    // existing file): a bug in this composition must never reach the operator
+    // as an unloadable config file, which is the one thing this whole feature
+    // promises never to do.
+    parseConfig(rendered);
+    await fs.writeText(configPath, rendered);
     logger.ok(`wrote ${configPath}`);
     logger.info('');
     logger.info(colors.bold('Next steps:'));
@@ -89,4 +213,3 @@ export async function initSite(fs, terminal, logger, root) {
     logger.info(colors.dim('   (bootstrap prints ACM validation CNAMEs when a domain is set)'));
     return 0;
 }
-//# sourceMappingURL=init.js.map

package/dist/known-commands.d.ts

@@ -0,0 +1,63 @@
+/**
+ * A LEAF. This module must never import anything.
+ *
+ * Task 09 moved `KNOWN_COMMANDS` and `RESERVED_COMMANDS` here out of `cli.ts`
+ * because `plugins.ts` needs the reserved set and `cli.ts` imports `plugins.ts`
+ * for dispatch - a cycle between the composition root and a domain module. It
+ * did not throw, because the set was only read inside a function body, but
+ * adding one ordinary top-level derivation to `plugins.ts` under that cycle
+ * produced `ReferenceError: Cannot access 'RESERVED_COMMANDS' before
+ * initialization` and killed every command including `--help`.
+ *
+ * A single import added here re-opens that fault, silently, for whichever
+ * module happens to be entered first. Keep it dependency-free.
+ */
+/**
+ * The CLI's command-name registries, isolated in their own leaf module with
+ * no imports of its own. Both `cli.ts` (the dispatcher - it pulls in every
+ * built-in command implementation, and since task 29 no plugin package by
+ * name: `blogwright-pds` reaches it only transitively, through the
+ * post-deploy sync `commands.ts` imports) and
+ * `plugins.ts` (a domain module that must stay inside the port boundary -
+ * see DEVELOPMENT.md §Hexagonal architecture) need to read the same set of
+ * reserved names, and neither may import the other: `plugins.ts` importing
+ * `cli.ts` for this alone becomes a real cycle the moment `cli.ts` imports
+ * `discover` from `plugins.ts` too (task 10 adds exactly that edge, to
+ * dispatch `blogwright plugin list`) - two modules each waiting on the
+ * other to finish initialising before either can run. This module gives
+ * both callers a shared, dependency-free home instead.
+ *
+ * `KNOWN_COMMANDS` is the eight names `cli.ts`'s `main` dispatches through
+ * its `switch`, after the `KNOWN_COMMANDS.has(command)` membership test:
+ * `bootstrap`, `deploy`, `rollback`, `delete`, `destroy`, `history`, `logs`,
+ * `status`.
+ *
+ * `RESERVED_COMMANDS` is every name a plugin may never claim as its own -
+ * see `discover`'s namespace-collision check in `plugins.ts`. It is
+ * deliberately NOT `KNOWN_COMMANDS` alone: `init` (dispatched in `cli.ts`
+ * ahead of the `KNOWN_COMMANDS` membership test) and `preview` (likewise)
+ * never enter that set, so deriving from it alone would under-reserve by
+ * two and let a plugin shadow either one. `plugin` is named explicitly for
+ * the same reason, one task early: `cli.ts` does not yet dispatch a
+ * `blogwright plugin` namespace (task 10 adds `'plugin'` to
+ * `KNOWN_COMMANDS`), but the name is reserved from the moment any plugin
+ * could collide with it, and the union keeps this set correct both before
+ * and after that command exists - no second edit required either way.
+ *
+ * `pds` is deliberately absent from `RESERVED_COMMANDS`, and adding it here
+ * would break `blogwright pds` outright. There is no built-in `pds` command:
+ * task 29 deleted `cli.ts`'s hardcoded `command === 'pds'` branch, and the
+ * namespace is now served by the bundled `blogwright-pds` package, which
+ * declares the plugin name `pds` and is discovered like any other plugin.
+ * Reserving the name would make `discover`'s reserved-name check
+ * (`plugins.ts`) reject that package - a load `failures` entry, never an
+ * installed plugin - so `blogwright pds <action>` would exit 1 with `no
+ * built-in command or installed plugin claims "pds"`, `--help` would list
+ * none of its six actions, and `blogwright plugin list` would blame a
+ * built-in command that does not exist. This is the one name in this file
+ * whose reservation would REMOVE a working command rather than protect one;
+ * it stays unreserved on purpose, pinned by a test in `plugins.test.ts` and
+ * `cli.test.ts`. See `plugins.ts`'s module comment for the full reasoning.
+ */
+export declare const KNOWN_COMMANDS: Set<string>;
+export declare const RESERVED_COMMANDS: ReadonlySet<string>;

package/dist/known-commands.js

@@ -0,0 +1,78 @@
+/**
+ * A LEAF. This module must never import anything.
+ *
+ * Task 09 moved `KNOWN_COMMANDS` and `RESERVED_COMMANDS` here out of `cli.ts`
+ * because `plugins.ts` needs the reserved set and `cli.ts` imports `plugins.ts`
+ * for dispatch - a cycle between the composition root and a domain module. It
+ * did not throw, because the set was only read inside a function body, but
+ * adding one ordinary top-level derivation to `plugins.ts` under that cycle
+ * produced `ReferenceError: Cannot access 'RESERVED_COMMANDS' before
+ * initialization` and killed every command including `--help`.
+ *
+ * A single import added here re-opens that fault, silently, for whichever
+ * module happens to be entered first. Keep it dependency-free.
+ */
+/**
+ * The CLI's command-name registries, isolated in their own leaf module with
+ * no imports of its own. Both `cli.ts` (the dispatcher - it pulls in every
+ * built-in command implementation, and since task 29 no plugin package by
+ * name: `blogwright-pds` reaches it only transitively, through the
+ * post-deploy sync `commands.ts` imports) and
+ * `plugins.ts` (a domain module that must stay inside the port boundary -
+ * see DEVELOPMENT.md §Hexagonal architecture) need to read the same set of
+ * reserved names, and neither may import the other: `plugins.ts` importing
+ * `cli.ts` for this alone becomes a real cycle the moment `cli.ts` imports
+ * `discover` from `plugins.ts` too (task 10 adds exactly that edge, to
+ * dispatch `blogwright plugin list`) - two modules each waiting on the
+ * other to finish initialising before either can run. This module gives
+ * both callers a shared, dependency-free home instead.
+ *
+ * `KNOWN_COMMANDS` is the eight names `cli.ts`'s `main` dispatches through
+ * its `switch`, after the `KNOWN_COMMANDS.has(command)` membership test:
+ * `bootstrap`, `deploy`, `rollback`, `delete`, `destroy`, `history`, `logs`,
+ * `status`.
+ *
+ * `RESERVED_COMMANDS` is every name a plugin may never claim as its own -
+ * see `discover`'s namespace-collision check in `plugins.ts`. It is
+ * deliberately NOT `KNOWN_COMMANDS` alone: `init` (dispatched in `cli.ts`
+ * ahead of the `KNOWN_COMMANDS` membership test) and `preview` (likewise)
+ * never enter that set, so deriving from it alone would under-reserve by
+ * two and let a plugin shadow either one. `plugin` is named explicitly for
+ * the same reason, one task early: `cli.ts` does not yet dispatch a
+ * `blogwright plugin` namespace (task 10 adds `'plugin'` to
+ * `KNOWN_COMMANDS`), but the name is reserved from the moment any plugin
+ * could collide with it, and the union keeps this set correct both before
+ * and after that command exists - no second edit required either way.
+ *
+ * `pds` is deliberately absent from `RESERVED_COMMANDS`, and adding it here
+ * would break `blogwright pds` outright. There is no built-in `pds` command:
+ * task 29 deleted `cli.ts`'s hardcoded `command === 'pds'` branch, and the
+ * namespace is now served by the bundled `blogwright-pds` package, which
+ * declares the plugin name `pds` and is discovered like any other plugin.
+ * Reserving the name would make `discover`'s reserved-name check
+ * (`plugins.ts`) reject that package - a load `failures` entry, never an
+ * installed plugin - so `blogwright pds <action>` would exit 1 with `no
+ * built-in command or installed plugin claims "pds"`, `--help` would list
+ * none of its six actions, and `blogwright plugin list` would blame a
+ * built-in command that does not exist. This is the one name in this file
+ * whose reservation would REMOVE a working command rather than protect one;
+ * it stays unreserved on purpose, pinned by a test in `plugins.test.ts` and
+ * `cli.test.ts`. See `plugins.ts`'s module comment for the full reasoning.
+ */
+export const KNOWN_COMMANDS = new Set([
+    'bootstrap',
+    'deploy',
+    'rollback',
+    'delete',
+    'destroy',
+    'history',
+    'logs',
+    'status',
+    'plugin',
+]);
+export const RESERVED_COMMANDS = new Set([
+    ...KNOWN_COMMANDS,
+    'init',
+    'preview',
+    'plugin',
+]);

package/dist/logger.js

@@ -31,4 +31,3 @@ export async function confirm(terminal, question, opts = {}) {
         return defaultYes;
     return answer === 'y' || answer === 'yes';
 }
-//# sourceMappingURL=logger.js.map

package/dist/microvms.d.ts

@@ -3,12 +3,12 @@ import type { OpsContext } from './context.js';
 /**
  * Active MicroVMs launched from *this* environment's builder image. Matches on the image
  * ARN recorded in state, falling back to the (env-scoped) image name so a stack whose
- * state predates the ARN still resolves — and a sibling env's VMs are never touched.
+ * state predates the ARN still resolves - and a sibling env's VMs are never touched.
  */
 export declare function runningStackMicrovms(ctx: OpsContext): Promise<Microvm[]>;
 /**
  * Guard a destroy/teardown against running builder MicroVMs (deleting the image 400s while
- * any are alive). Lists them, then interactively offers to terminate — default yes — or to
+ * any are alive). Lists them, then interactively offers to terminate - default yes - or to
  * wait, which cancels the destroy. Non-interactive callers get the default (terminate) so
  * automation isn't blocked. Returns true to proceed with the destroy, false to abort.
  */

package/dist/microvms.js

@@ -8,7 +8,7 @@ function isActive(vm) {
 /**
  * Active MicroVMs launched from *this* environment's builder image. Matches on the image
  * ARN recorded in state, falling back to the (env-scoped) image name so a stack whose
- * state predates the ARN still resolves — and a sibling env's VMs are never touched.
+ * state predates the ARN still resolves - and a sibling env's VMs are never touched.
  */
 export async function runningStackMicrovms(ctx) {
     const imageArn = ctx.state.resources['microvm-image']?.arn;
@@ -22,7 +22,7 @@ export async function runningStackMicrovms(ctx) {
 }
 /**
  * Guard a destroy/teardown against running builder MicroVMs (deleting the image 400s while
- * any are alive). Lists them, then interactively offers to terminate — default yes — or to
+ * any are alive). Lists them, then interactively offers to terminate - default yes - or to
  * wait, which cancels the destroy. Non-interactive callers get the default (terminate) so
  * automation isn't blocked. Returns true to proceed with the destroy, false to abort.
  */
@@ -37,7 +37,7 @@ export async function clearRunningMicrovms(ctx) {
         defaultYes: true,
     });
     if (!proceed) {
-        ctx.logger.info('Leaving MicroVMs running — destroy cancelled.');
+        ctx.logger.info('Leaving MicroVMs running - destroy cancelled.');
         return false;
     }
     for (const vm of running) {
@@ -53,4 +53,3 @@ export async function clearRunningMicrovms(ctx) {
     ctx.logger.ok('MicroVMs terminated');
     return true;
 }
-//# sourceMappingURL=microvms.js.map

package/dist/nodes.d.ts

@@ -1,5 +1,6 @@
+import { type ResourceNode as CoreResourceNode } from 'blogwright-core';
 import type { OpsContext } from './context.js';
-import type { ResourceNode } from './graph.js';
+type ResourceNode = CoreResourceNode<OpsContext>;
 export type BuilderImageAction = 'create' | 'update' | 'skip';
 /**
  * Decide what a builder-image reconcile should do: create when the image is missing or
@@ -17,14 +18,14 @@ export declare function builderImageAction(image: {
  * Create, rebuild, or leave the MicroVM builder image, depending on what's deployed:
  * create it if missing, rebuild it if the agent bundle (or its log group) changed or the
  * last build is unhealthy, otherwise no-op. Idempotent and cheap in the common case (a
- * single GetMicrovmImage + hash compare), so it's safe to run before every deploy — which
+ * single GetMicrovmImage + hash compare), so it's safe to run before every deploy - which
  * is how build-agent changes propagate through CI without a separate `bootstrap`.
  */
 export declare function reconcileBuilderImage(ctx: OpsContext): Promise<void>;
 /**
  * The workflow's OIDC subject claim, scoped per environment to match how each one
  * deploys: previews from any PR ref; staging from pushes to main; production from the
- * `production` GitHub Environment (release-gated — see production.yml), which lets
+ * `production` GitHub Environment (release-gated - see production.yml), which lets
  * deploys be gated behind environment protection rules.
  */
 export declare function oidcSubClaim(repo: string, env: string, preview: boolean): string;
@@ -32,3 +33,4 @@ export declare function oidcSubClaim(repo: string, env: string, preview: boolean
 export declare function oidcRolePolicyStatements(ctx: OpsContext): object[];
 /** Build the full node set for the current context (production or preview stack). */
 export declare function buildNodes(ctx: OpsContext): ResourceNode[];
+export {};