peaks-loop 4.1.2 → 4.1.3

package/dist/cli/commands/job-commands.d.ts

@@ -1,67 +1,7 @@
 import { Command } from 'commander';
 import { type ProgramIO } from '../cli-helpers.js';
-export declare function asJson(opts: JobJsonOpts): boolean;
-/**
- * D6: every job subcommand resolves a job root, so every one of them must be
- * able to name the session that holds the job. Same precedence as the rest of
- * the CLI (`peaks sub-agent dispatch`, `peaks web *`, `peaks share *`), except
- * that job state has no "unknown-sid" location to land in — an unresolvable
- * session is an error, not a silent fallback.
- */
-export declare const SESSION_ID_HELP = "session id (default: resolve from .peaks/_runtime/session.json; falls back to PEAKS_SESSION_ID env var; final fallback: NO_ACTIVE_SESSION error)";
-/**
- * Resolves the on-disk root for Job state files.
- *
- * Per spec §3.3 + §4.5 (2.7.1 single-scope-axis layout), Job state lives at:
- *   `<projectRoot>/.peaks/_runtime/<sessionId>/job/<jobId>/state.json`
- *
- * The `JobStateStore` itself only knows its `rootDir` + `jobId` and joins them. We
- * compute the canonical root here (per-call) so the store can stay layout-agnostic.
- *
- * Resolution order (D6 — a job must stay addressable while the single per-project
- * `.peaks/_runtime/session.json` binding points at another session):
- * 1. `--session-id` flag (explicit override)
- * 2. `PEAKS_SESSION_ID` env var
- * 3. `getCurrentSessionId(project)` — this caller's session binding, falling back
- *    to `.peaks/_runtime/session.json` when no caller binding is resolvable
- * 4. Error (NO_ACTIVE_SESSION) — must never silently fall back to a random uuid
- *
- * When `jobId` is passed and it is absent from the resolved session, the thrown
- * error names the session that does hold it (if any), instead of leaving the
- * caller with a bare "no state for <job> at <other-sid>" path.
- */
-export declare function resolveJobStateRoot(opts: JobRootOpts, jobId?: string): {
-    rootDir: string;
-    sessionId: string;
-    projectRoot: string;
-};
-/**
- * S10 (2026-09-20) — the option shapes the `job` subcommands read.
- *
- * WHY. Commander types an action's `opts` as `any`, so every `opts.<field>`
- * access in this file was an `any` access: 109 `no-unsafe-*` findings, the
- * largest single TS root in the S10 census. The root is the *entrance* — the
- * untyped `opts` parameter — not the 109 sites, so the fix is to declare it.
- *
- * Each interface names exactly the options its own command READS, plus `--json`
- * (added by `addJsonOption`). So a field absent here is a field that command
- * does not read, and reading it is now a compile error instead of an `any`
- * access. (A command may declare more than it reads — `job status` declares
- * `--show-cost` and never looks at it; that option is deliberately not listed.)
- * `readonly` is honest: these are read-only inputs; Commander owns the object.
- *
- * The four helpers above (`asJson`, `failResult`, `projectRoot`,
- * `resolveJobStateRoot`) take the narrowest structural type each one actually
- * reads, so all eleven action callbacks remain assignable to them.
- */
-export interface JobJsonOpts {
-    readonly json?: boolean;
-}
-interface JobProjectOpts {
-    readonly project?: string;
-}
-export interface JobRootOpts extends JobProjectOpts {
-    readonly sessionId?: string;
-}
+import { asJson } from './job-command-shared.js';
+import { SESSION_ID_HELP, resolveJobStateRoot } from './job-state-root.js';
+export { asJson, SESSION_ID_HELP, resolveJobStateRoot };
+export type { JobJsonOpts, JobRootOpts, JobProjectOpts } from './job-command-shared.js';
 export declare function registerJobCommands(program: Command, io?: ProgramIO): void;
-export {};