@theholocron/cli 3.57.0 → 3.58.1

package/dist/index.d.mts

@@ -31,7 +31,7 @@ declare function createFeatureResolver(config: FeatureResolverConfig): (input?:
  * subcommands; consulted at position 4 in every plugin's auth
  * precedence chain (after --token / HOLOCRON_<X>_TOKEN / <native>_TOKEN).
  *
- * See `.notes/tech-auth-bootstrap.spec.md` for the design rationale.
+ * See `docs/wiki/specifications/tech-auth-bootstrap.spec.md` for the design rationale.
  *
  * Failure model: keyring access is best-effort. Platforms without a
  * supported credential store (some Linux CI images, sandboxed
@@ -66,13 +66,25 @@ declare function deleteToken(provider: string): boolean;
 declare function listStoredProviders(): string[];
 //#endregion
 //#region src/config/config.d.ts
-/** Structured-logging config — level only; credentials never live in config. */
+/** Structured-logging config. The Axiom **token** never lives here — only in
+ *  env vars or the OS keyring — but the non-secret dataset name may. */
 interface LogConfig {
   /**
    * Default log level. The lowest-priority level source: `--verbose` /
    * `--quiet` and `HOLOCRON_LOG_LEVEL` both outrank it.
    */
   level?: LogLevel;
+  /**
+   * Axiom log-shipping. Set `axiom.dataset` to opt local runs into Axiom
+   * without exporting `HOLOCRON_AXIOM_DATASET` — the CLI then pairs it with
+   * the token from `HOLOCRON_AXIOM_TOKEN` / `AXIOM_TOKEN` or the OS keyring
+   * (`holocron auth set axiom[.<org>] <TOKEN>`). Env vars still win. In CI,
+   * prefer the `HOLOCRON_AXIOM_DATASET` variable.
+   */
+  axiom?: {
+    /** Target Axiom dataset, e.g. `"holocron-local"`. */
+    dataset?: string;
+  };
 }
 type ProviderOptions = Record<string, unknown>;
 /**

package/dist/index.mjs

@@ -26,7 +26,7 @@ function makeEnv(source) {
 * subcommands; consulted at position 4 in every plugin's auth
 * precedence chain (after --token / HOLOCRON_<X>_TOKEN / <native>_TOKEN).
 *
-* See `.notes/tech-auth-bootstrap.spec.md` for the design rationale.
+* See `docs/wiki/specifications/tech-auth-bootstrap.spec.md` for the design rationale.
 *
 * Failure model: keyring access is best-effort. Platforms without a
 * supported credential store (some Linux CI images, sandboxed

package/dist/plugin/capabilities.d.mts

@@ -9,7 +9,7 @@ import { ProviderApiError } from "@theholocron/http-client";
  * `CardinalityFor<K>` so config resolution + command code can branch
  * statically.
  *
- * See `.notes/archive/tech-architecture.spec.md` for the design narrative
+ * See `docs/wiki/specifications/tech-architecture.spec.md` for the design narrative
  * (issue: #74).
  */
 type CapabilityKey = "source" | "ci" | "secrets" | "environments" | "issues" | "deployment" | "storage" | "auth" | "vault" | "dns" | "tooling" | "notifications" | "analytics" | "errors" | "logs" | "wiki" | "workers";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@theholocron/cli",
-  "version": "3.57.0",
+  "version": "3.58.1",
   "description": "The Holocron CLI — a pluggable, capability-based orchestrator for spinning up and operating software projects.",
   "keywords": [
     "cli",
@@ -52,7 +52,7 @@
     "ora": "^9.4.1",
     "tsx": "4.23.12",
     "yargs": "^18.1.0",
-    "@theholocron/logger": "3.57.0"
+    "@theholocron/logger": "3.58.1"
   },
   "devDependencies": {
     "@theholocron/eslint-config": "^7.32.1",
@@ -68,7 +68,7 @@
     "tsdown": "^0.22.14",
     "typescript": "^5.9.3",
     "vitest": "^4.1.11",
-    "@theholocron/rollup-plugin-transform-template": "3.57.0"
+    "@theholocron/rollup-plugin-transform-template": "3.58.1"
   },
   "engines": {
     "node": ">=22.0.0"