@remixmate/cli 0.9.71 → 0.9.73

package/dist/progress.d.ts

@@ -1,23 +0,0 @@
-/**
- * Progress reporting — emits __progress__ JSON lines that ab-agent's
- * executor parses (see apps/ab-agent/src/skills/executor.ts).
- *
- * Always writes to stdout because the consumer reads stdout line-by-line.
- * Each event is a single JSON object on its own line, with the marker
- * field `__progress__: true` so non-progress stdout content is ignored.
- *
- * The consumer flattens the entire parsed JSON into `extra`, so any
- * additional context (model id, generationId, ...) can be passed as
- * top-level keys and will reach the SSE client unchanged.
- */
-export interface ProgressEvent {
-    /** Pipeline phase, e.g. `gen-image:request`. */
-    phase?: string;
-    /** 0..1 progress fraction. */
-    progress?: number;
-    etaSeconds?: number | null;
-    elapsedSeconds?: number | null;
-    /** Free-form context — flattened into the parsed JSON line. */
-    [key: string]: unknown;
-}
-export declare function emitProgress(ev: ProgressEvent): void;

package/dist/project/commands.d.ts

@@ -1,19 +0,0 @@
-/**
- * `remixmate project ...` and `remixmate host probe`.
- *
- * `project use` is the low-friction way to keep CLI output out of 「未分类」:
- * say it once per repo (or once globally) instead of passing --project on every
- * call — an agent won't pass a flag it wasn't told about.
- *
- * `host probe` exists so onboarding an unknown agent shell is a minute's work
- * rather than a reverse-engineering session: run it inside the new host, read
- * off the session variable, add one row to HOST_PROVIDERS.
- */
-export declare const PROJECT_VERB = "project";
-export declare const HOST_VERB = "host";
-export declare function runProjectCommand(argv: string[]): Promise<number>;
-/**
- * Report what the CLI can see about its host. Prints variable NAMES only —
- * an environment dump is a routine way to leak tokens into a chat transcript.
- */
-export declare function runHostCommand(argv: string[]): Promise<number>;

package/dist/project/host.d.ts

@@ -1,91 +0,0 @@
-/**
- * Host detection — which agent shell is this CLI running inside, and what is
- * its conversation id?
- *
- * The id is used as the *grouping key* for takes: every render fired from the
- * same host conversation lands in one VideoProject as successive takes. The
- * creative loop ("generate → watch → shorten the intro → re-render") spans
- * multiple skill invocations and multiple render jobs, so the conversation —
- * not the render job — is its natural boundary.
- *
- * Everything here reads the **child process environment only**. We deliberately
- * do not speak any host's private IPC (Codex exposes its thread id through an
- * App Server JSON-RPC channel, and finding "the current thread" there means
- * matching on cwd + status + recency — a heuristic, not an identity lookup,
- * which would silently group takes wrong). A host that hands us nothing simply
- * degrades one rung; see resolveTakeKey().
- *
- * See docs/product/cli/cli-project-binding-design.md §5.1 and appendix A.
- */
-export interface HostSessionProvider {
-    /** Host identifier; becomes the namespace of the grouping key. */
-    host: string;
-    /** First provider whose detect() passes wins — ORDER MATTERS, see below. */
-    detect: (env: NodeJS.ProcessEnv) => boolean;
-    /** Session-level id candidates, most-preferred first. */
-    sessionVars: string[];
-}
-/**
- * Adding a host is a data-only change: append a row, touch nothing else.
- * Run `remixmate host probe` inside the new host to discover its variable names.
- *
- * ⚠️ ORDER IS LOAD-BEARING. CodeBuddy also sets `CLAUDE_SESSION_ID` (same value
- * as its own id), while real Claude Code uses the longer `CLAUDE_CODE_*` prefix.
- * Detecting Claude Code first — or matching on a bare `CLAUDE_` prefix — would
- * mislabel every CodeBuddy session.
- *
- * ⚠️ Prefer the ROOT session over a child/sub-agent one. Claude Code exposes
- * both (`CLAUDE_CODE_HOST_SESSION_ID` alongside a per-subagent
- * `CLAUDE_CODE_SESSION_ID`); grouping must follow the root so a render fired
- * from a subagent still joins the main take.
- */
-export declare const HOST_PROVIDERS: HostSessionProvider[];
-export interface HostSession {
-    host: string;
-    sessionId: string;
-}
-/** Identify the host and its root session id, or null when unrecognised. */
-export declare function detectHostSession(env?: NodeJS.ProcessEnv): HostSession | null;
-/**
- * Normalise a declared host label.
- *
- * `video_project.client_host` is `varchar(32)`, and the value is rendered as a
- * badge, so free-form input gets slugified rather than trusted: lowercase,
- * non-alphanumerics collapsed to `-`, capped at 32. Anything that normalises to
- * empty is treated as absent — an unusable label should degrade to "no badge",
- * never to a garbage one.
- */
-export declare function normaliseHostLabel(raw: string | undefined): string;
-/**
- * Host label for provenance, even when no session id could be read.
- *
- * Declaration wins over detection: the declaring party knows, the table guesses.
- */
-export declare function detectHostLabel(env?: NodeJS.ProcessEnv): string;
-export interface TakeKey {
-    /** `<host>:<sessionId>`, or '' when nothing groups this invocation. */
-    key: string;
-    host: string;
-    /** Which rung produced the key — surfaced by `doctor` / `host probe`. */
-    source: 'host' | 'env-override' | 'render-job' | 'none';
-}
-/**
- * Resolve the take grouping key.
- *
- *   1. a recognised host's root session id      → "<host>:<id>"
- *   2. REMIXMATE_TAKE_KEY                       → "custom:<value>"
- *   3. the render job id                        → "job:<id>"
- *
- * Rung 2 is the escape hatch that matters: an unsupported host (or a user on
- * Codex) can export one variable and get correct grouping without waiting for a
- * CLI release. Rung 3 keeps the feature working everywhere, at the cost of
- * splitting one video's iterations across takes — acceptable as a floor, not as
- * a default.
- */
-export declare function resolveTakeKey(jobId: number | undefined, env?: NodeJS.ProcessEnv): TakeKey;
-/**
- * Environment variable names that look like a session/thread identifier.
- * Used by `remixmate host probe` to onboard an unknown host in a minute.
- * Returns NAMES ONLY — values may carry tokens and are never printed.
- */
-export declare function probeSessionVarNames(env?: NodeJS.ProcessEnv): string[];

package/dist/project/resolve.d.ts

@@ -1,43 +0,0 @@
-/**
- * Project resolution ladder — which Project does this invocation's output
- * belong to? First rung that matches wins.
- *
- *   0. CONVERSATION_ID already set  → do nothing at all (cloud ab-agent path)
- *   1. --project prj_xxx            → explicit flag
- *   2. REMIXMATE_PROJECT_ID         → explicit env
- *   3. ~/.config/remixmate/projects.json → `project use` binding (byPath → default)
- *   4. the default project 「未分类」 → lazily created server-side
- *
- * Only "explicit" and "fallback" — there is deliberately no inference step in
- * between. Deriving a project from the git remote reads well until you notice
- * it *creates* one on every unfamiliar repo (`/project/create` is an upsert),
- * and that its rules have to keep growing for private remotes, non-GitHub
- * remotes, monorepos and repos with no origin — each misfire silently filing
- * output under a project the user never made.
- *
- * See docs/product/cli/cli-project-binding-design.md §3.
- */
-import { type HttpContext } from '../http.js';
-export interface ResolvedProject {
-    projectId: string;
-    source: 'flag' | 'env' | 'binding-path' | 'binding-default' | 'default-project';
-}
-/** Minimal shape of ab-api's ProjectVO — only what the ladder needs. */
-export interface ProjectSummary {
-    id: string;
-    displayName?: string;
-    fullName?: string;
-    sourceUrl?: string;
-    isDefault?: boolean;
-}
-/** POST /project/default — get-or-lazily-create 「未分类」. */
-export declare function fetchDefaultProject(ctx: HttpContext): Promise<ProjectSummary>;
-/** POST /project/list — for `remixmate project list`. */
-export declare function listProjects(ctx: HttpContext): Promise<ProjectSummary[]>;
-export declare function resolveProject(ctx: HttpContext, opts?: {
-    flagProjectId?: string;
-    env?: NodeJS.ProcessEnv;
-    cwd?: string;
-}): Promise<ResolvedProject>;
-/** Human-readable label for `doctor` / `project show`. */
-export declare function describeProjectSource(source: ResolvedProject['source']): string;

package/dist/project/store.d.ts

@@ -1,31 +0,0 @@
-/**
- * Persistent project binding — which Project should this machine's CLI output
- * belong to?
- *
- * Stored at ~/.config/remixmate/projects.json, NOT in credentials.json: that
- * file is a 0600 secret store keyed by API base URL, with different lifetime
- * and different blast radius on corruption.
- *
- * Two layers, because host cwd semantics are not uniform:
- *   - `byPath`  — keyed by absolute cwd. Hosts that run inside the user's real
- *                 repo (Codex, Claude Code) get per-repo bindings.
- *   - `default` — a single fallback. Hosts that spawn a throwaway working
- *                 directory per conversation (WorkBuddy uses
- *                 ~/WorkBuddy/<timestamp>) would never hit a byPath entry, so a
- *                 cwd-only design silently degrades to nothing for them.
- *
- * See docs/product/cli/cli-project-binding-design.md §3.
- */
-export declare const CONFIG_DIR: string;
-export declare const PROJECTS_FILE: string;
-export interface StoredBinding {
-    projectId: string;
-    /** Which layer matched — surfaced by `project show` / `doctor`. */
-    scope: 'path' | 'default';
-}
-/** Look up the binding for a cwd: exact byPath match first, then the default. */
-export declare function readBinding(apiBaseUrl: string, cwd?: string): Promise<StoredBinding | null>;
-/** Bind a project to this cwd (`scope: 'path'`) or as the fallback (`'default'`). */
-export declare function writeBinding(apiBaseUrl: string, projectId: string, scope: 'path' | 'default', cwd?: string): Promise<void>;
-/** Drop a binding. Returns true when something was actually removed. */
-export declare function clearBinding(apiBaseUrl: string, scope: 'path' | 'default', cwd?: string): Promise<boolean>;

package/dist/project/take.d.ts

@@ -1,50 +0,0 @@
-/**
- * Take creation — turn a render invocation into a VideoProject the web app can
- * show, and hand its conversation id down to the skill.
- *
- * Why this exists at all: ab-web derives a video's project from
- * `file.conversation_id → media_video_project → media_project`. A render whose
- * upload carries no conversation id is stored correctly but belongs to nothing,
- * so it shows up only in the raw asset list. The cloud agent injects
- * CONVERSATION_ID for its own runs; locally, nobody did — that is the bug this
- * module fixes.
- *
- * Idempotency lives on the server (`/video-project/ensure` is get-or-create on
- * `(user_id, client_session_key)`), not in a local state file: a pipeline is N
- * separate CLI processes, sometimes concurrent, and a local cache would have to
- * solve staleness and write races that a unique index solves for free.
- *
- * See docs/product/cli/cli-project-binding-design.md §5.
- */
-import { type HttpContext } from '../http.js';
-export interface EnsuredTake {
-    conversationId: string;
-    videoProjectId: string;
-    projectId: string;
-    created: boolean;
-    attempt: number;
-    /** The grouping key this take was resolved under — reused as the trace's session id. */
-    sessionKey: string;
-    /** Provenance label of the host we're running inside ('' when unknown). */
-    host: string;
-}
-/**
- * Look up the take for the current grouping key without creating anything.
- *
- * Used by pipeline skills that should attach to a take when one exists but must
- * never bring one into being: someone running `remixmate gen-image` on its own
- * isn't making a video, and an empty VideoProject is worse clutter than an
- * unattributed image.
- *
- * Deliberately does NOT resolve a project — resolveProject()'s last rung
- * lazily *creates* 「未分类」, which a read-only lookup has no business doing.
- */
-export declare function findTake(ctx: HttpContext): Promise<EnsuredTake | null>;
-/**
- * Resolve project + grouping key, then get-or-create the take.
- * Returns null when this invocation shouldn't own a take.
- */
-export declare function ensureTake(ctx: HttpContext, opts: {
-    jobId?: number;
-    flagProjectId?: string;
-}): Promise<EnsuredTake | null>;

package/dist/project/trace.d.ts

@@ -1,98 +0,0 @@
-/**
- * Execution-trace self-reporting — tell the backend what this invocation
- * actually did, so a locally-run pipeline is not a blind spot.
- *
- * Why this exists: the cloud agent records every tool call, its arguments AND
- * its result into `media_chat_turn_trace` (ab-agent/src/trace-persist.ts). The
- * local path records nothing — a take created from codex / claude code has an
- * empty conversation, zero tool calls and zero credits in the analytics tables,
- * so every session-level metric silently excludes it.
- *
- * What we can honestly report and what we cannot: the CLI is a child process
- * spawned once per skill call. It never sees the user's prompt or the host's
- * reply — those live in the host's own transcript. So this module reports the
- * one thing it genuinely observes: the invocation itself.
- *
- * See docs/product/cli/cli-session-record-design.md §5.
- */
-import { type HttpContext } from '../http.js';
-import type { ParsedArgs } from '../argv.js';
-import type { EnsuredTake } from './take.js';
-export interface TraceOptions {
-    skillName: string;
-    args: ParsedArgs;
-    take: EnsuredTake;
-    ctx: HttpContext;
-}
-/**
- * Whether this invocation should report at all.
- *
- * The rule is deliberately narrow: report only when THIS process resolved the
- * take. Everything else is already covered by someone else —
- *   - under the cloud agent, CONVERSATION_ID arrives pre-set and ab-agent's own
- *     TurnTracer already recorded the very same call;
- *   - a nested `gen-image` spawned by prepare-video-assets inherits its
- *     parent's CONVERSATION_ID, and the parent's row already covers it.
- * Since runner.ts only builds a tracer after resolving a take itself, this
- * function just honours the kill switch.
- */
-export declare function tracingEnabled(env?: NodeJS.ProcessEnv): boolean;
-/**
- * Collects one invocation's evidence and posts it as a single turn.
- *
- * Lifecycle (runner.ts): `begin()` → output flows through the tap → `finish()`
- * in a finally block. Every failure mode ends in a warning on stderr: a lost
- * trace row must never cost the user a render they already paid for.
- */
-export declare class InvocationTrace {
-    private readonly opts;
-    private chunks;
-    private restore;
-    private flushed;
-    private constructor();
-    /** Returns null when tracing is off — callers can then skip output capture entirely. */
-    static begin(opts: TraceOptions): InvocationTrace | null;
-    /**
-     * Tap both output streams.
-     *
-     * One tap covers both dispatch paths: in-process handlers write here
-     * directly, and the Python child's piped output is re-emitted through the
-     * same `write` (see runner.ts). Restored in finish().
-     */
-    installCapture(): void;
-    /** Feed captured output. Keeps a bounded tail — the decisive line is the last one. */
-    absorb(chunk: unknown): void;
-    /**
-     * Emit the turn. Idempotent; never throws.
-     *
-     * `error` is the dispatcher's caught exception when there is one — a Python
-     * child that exits non-zero gives us no exception, only its output, which is
-     * exactly why the tail buffer exists.
-     */
-    finish(exitCode: number, durationMs: number, error?: unknown): Promise<void>;
-}
-/**
- * Flags → a trace-safe object.
- *
- * Credentials are dropped outright; long strings are cut to their opening
- * because an argument like `--prompt` is *content*, and this table is evidence,
- * not an archive of what the user wrote.
- */
-export declare function sanitiseArgs(args: ParsedArgs): Record<string, unknown>;
-/**
- * Captured output → the tail we store.
- *
- * Two transformations before truncating, both about spending the 16KB on
- * things a human would read:
- *   - progress lines are the machine protocol — one fat JSON object per phase,
- *     marked by a `__progress__` field (progress.ts, and the same shape from the
- *     Python skills). Their payload is noise here, but WHICH PHASE a failed run
- *     reached is the single most useful fact about it, so the line collapses to
- *     its phase name instead of being dropped.
- *   - `__diagnostic_v1__` lines are our own structured log of this very run;
- *     keeping them would store the same verdict twice.
- *
- * Then keeps the TAIL, unlike ab-agent's head-first cleanText: a command's
- * verdict — the error, or the URL it produced — is its last line.
- */
-export declare function condense(raw: string): string;

package/dist/registry.d.ts

@@ -1,30 +0,0 @@
-/**
- * Skill registry — scan skills/ and load skill.json definitions.
- *
- * Validation and entry-normalization live in `skill-schema.ts` (shared with
- * the build-time manifest generator and smoke test). A record that fails
- * validation is skipped with a warning rather than crashing the whole CLI.
- */
-import { type SkillAuthMode, type SkillEntry } from './skill-schema.js';
-export declare const SKILLS_DIR: string;
-export type { SkillEntry, SkillAuthMode } from './skill-schema.js';
-export interface SkillDef {
-    name: string;
-    toolName: string;
-    description: string;
-    parameters: Record<string, unknown>;
-    entry: SkillEntry;
-    /** Authorization requirement enforced by the dispatcher before invocation. */
-    auth: SkillAuthMode;
-    /** Ensure a take (VideoProject + conversation) before running — see skill-schema.ts. */
-    createsTake: boolean;
-    /** Attach to an existing take, never create one — see skill-schema.ts. */
-    joinsTake: boolean;
-    /** Argv keys that downgrade createsTake to joinsTake — see skill-schema.ts. */
-    createsTakeUnless: string[];
-    skillDir: string;
-    /** Absolute path to the python entry script (only when entry.type === 'python'). */
-    scriptAbsolutePath?: string;
-}
-export declare function loadSkills(baseDir?: string): SkillDef[];
-export declare function findSkill(name: string, baseDir?: string): SkillDef | null;

package/dist/runner.d.ts

@@ -1,39 +0,0 @@
-/**
- * Skill dispatcher — routes a parsed invocation to either:
- *   - spawn `python3 <scriptAbsolutePath> --flag value ...` (entry.type === 'python')
- *   - call a TS handler from handlers/ (entry.type === 'http' | 'builtin')
- *
- * Authorization happens HERE, once, before either path — see auth/ensure.ts for
- * why. Python children receive the resolved credential through their environment
- * and never read the credential store themselves.
- *
- * Resolves to the child process's exit code so cli.ts can propagate it.
- */
-import { type SkillDef } from './registry.js';
-import type { ParsedArgs } from './argv.js';
-export interface RunOptions {
-    /** Override the skills directory (defaults to the package's bundled skills/). */
-    baseDir?: string;
-    /** Raw argv slice after the skill name (passed verbatim for python; parsed for handlers). */
-    rawArgs: string[];
-    /** Parsed argv (for handlers). */
-    parsedArgs: ParsedArgs;
-}
-export declare function runSkill(skillName: string, opts: RunOptions): Promise<number>;
-/** What this invocation is allowed to do about attribution. */
-export type TakeMode = 'create' | 'join' | 'none';
-/**
- * Decide the take mode from the skill's declaration *and* what this particular
- * invocation was asked to do.
- *
- * The manifest flags alone are not enough, because they describe the skill, not
- * the call: `render-video --help` prints usage and exits, and
- * `render-video --resolve-only` stops after asset resolution. Both used to run
- * the full createsTake path, so a help query was enough to mint an empty take
- * and lazily create 「未分类」 — the exact clutter project/take.ts sets out to
- * avoid ("an empty VideoProject is worse clutter than an unattributed image").
- *
- * Note that a downgraded run still *joins*: when its own pipeline already
- * started a take under the same grouping key, assets it generates stay attached.
- */
-export declare function resolveTakeMode(skill: Pick<SkillDef, 'createsTake' | 'joinsTake' | 'createsTakeUnless'>, args: ParsedArgs): TakeMode;

package/dist/skill-schema.d.ts

@@ -1,138 +0,0 @@
-/**
- * Single source of truth for skill.json shape + validation.
- *
- * Imported directly by `registry.ts` (runtime loader) and — via the compiled
- * `dist/skill-schema.js` — by `scripts/build-manifest.mjs` and `scripts/smoke.mjs`.
- * Previously each of those reimplemented `normalizeEntry` and its own subset of
- * field checks, so "valid at build" ≠ "loadable at runtime". Centralizing here
- * means one definition of a well-formed skill.
- *
- * Error policy is the caller's choice: `validateSkillJson` returns a list of
- * human-readable problems (empty = OK). The runtime loader skips + warns;
- * the build treats them as fatal.
- */
-export type SkillEntry = {
-    type: 'python';
-    scriptPath: string;
-} | {
-    type: 'http';
-    handler: string;
-} | {
-    type: 'builtin';
-    handler: string;
-};
-/**
- * Skill 类别 — 区分"创作期 / 消费期 / 元数据型" skill。
- *
- * - "authoring": 创建 / 编辑模板期间使用，例如 template-registry / gen-script /
- *                render-video（用于 try_render） / prepare-video-assets。
- * - "consuming": 消费已有模板生成媒体，例如 export-jianying / video-parser /
- *                web-screenshot / web-record（与"创建模板"无关，是消费侧场景）。
- * - "asset":     生成单一类型素材的原子 skill：gen-image / gen-voice /
- *                gen-video / gen-digital-human。authoring 也会用，但通过 stub
- *                方式占位；consuming 场景下是真调用。
- * - "meta":      元 skill（如未来加入 doc-only 的 template-creator）。
- *
- * 下游消费方（如 ab-template-studio）按 category 自动挑选白名单，避免每加一个
- * skill 就要改两侧 hardcode。
- */
-export type SkillCategory = 'authoring' | 'consuming' | 'asset' | 'meta';
-export declare const CATEGORY_VALUES: readonly ["authoring", "consuming", "asset", "meta"];
-/**
- * Authorization requirement — consumed by the dispatcher's auth preflight.
- * Semantics are documented on `AuthMode` in src/auth/ensure.ts (kept there so
- * the runtime behavior and its description live together); this file only owns
- * the literal values and their validation.
- */
-export type SkillAuthMode = 'required' | 'optional' | 'none';
-export declare const AUTH_VALUES: readonly ["required", "optional", "none"];
-/**
- * 参数的**展示分级** —— 给人填表用的，不影响调度。
- *
- * `parameters` 是给 agent 的完整契约（十几个字段很正常）；把它整份渲染成表单
- * 就是把门槛从"不知道说什么"换成"不知道填什么"。所以每个 skill 自己声明哪些
- * 字段该直出、哪些折叠、哪些**根本不该给人看见**（`json_output` / `seed` 这类
- * 是给调用方的开关，不是给人的选项）。
- *
- * 它和 schema 同住 skill.json，是刻意的：跨仓库的第二份名单必然漂移——
- * ab-web 曾经用硬编码的 `ARCHETYPES` 常量对着后端字典表，最后两边对不上。
- *
- * 未声明的字段自动落进 `advanced`（见 build-manifest 的 resolveUiHints）：
- * 新加一个参数时，最坏情况是它多显示了一层，而不是静默消失。
- */
-export interface SkillUiHints {
-    /** 表单展开即可见 */
-    primary?: string[];
-    /** 折叠在「高级」里 */
-    advanced?: string[];
-    /** 不渲染给人类 */
-    hidden?: string[];
-}
-export interface RawSkillJson {
-    name: string;
-    toolName: string;
-    description: string;
-    title?: string;
-    tier?: string;
-    category?: SkillCategory;
-    auth?: SkillAuthMode;
-    parameters?: Record<string, unknown>;
-    /** 参数的展示分级；缺省时按 required → primary、其余 → advanced 推导。 */
-    ui?: SkillUiHints;
-    scriptPath?: string;
-    entry?: SkillEntry;
-    envVars?: string[];
-    /**
-     * Declares that this skill produces a finished video, so the dispatcher should
-     * ensure a "take" (VideoProject + conversation) before running it and inject the
-     * resulting CONVERSATION_ID. Declarative rather than a hardcoded skill name in
-     * runner.ts, so the pipeline's shape stays visible in the skill's own manifest.
-     */
-    createsTake?: boolean;
-    /**
-     * Declares that this skill contributes to a video but must never *start* one:
-     * attach to an existing take if there is one, otherwise carry on unattributed.
-     * A standalone `gen-image` run isn't a video, and an empty VideoProject is
-     * worse clutter than an unattributed asset.
-     */
-    joinsTake?: boolean;
-    /**
-     * Parsed-argv keys (snake_case, as produced by argv.ts) whose presence means
-     * *this* invocation won't finish a video — `render-video --resolve-only`
-     * resolves assets and stops. Such a run degrades from createsTake to
-     * joinsTake: it still attaches to a take its own pipeline already started,
-     * but never brings one — nor the lazily created 「未分类」 — into being for a
-     * pass that may end in a contract error and no video at all.
-     */
-    createsTakeUnless?: string[];
-}
-/**
- * Resolve a skill's auth mode, defaulting for records that predate the field.
- *
- * The default is derived from `envVars` rather than hardcoded to `'required'`:
- * a skill that never declared PRIV_TOKEN cannot possibly need a credential, and
- * defaulting it to `required` would make a purely local skill (web-screenshot)
- * pop a browser. Every skill shipped in this package declares `auth` explicitly,
- * so this only covers externally supplied skill dirs (SKILL_BASE_DIR).
- */
-export declare function resolveAuthMode(raw: Pick<RawSkillJson, 'auth' | 'envVars'>): SkillAuthMode;
-export declare const TIER_VALUES: readonly ["atomic", "orchestration", "tool"];
-export declare const REQUIRED_SKILL_JSON_FIELDS: readonly ["name", "tier", "title", "description"];
-/**
- * Resolve the dispatcher entry. A missing `entry` falls back to the legacy
- * top-level `scriptPath`, treated as `{ type: 'python', scriptPath }` so older
- * skills keep working untouched. Returns null when neither is present.
- */
-export declare function normalizeEntry(raw: Pick<RawSkillJson, 'entry' | 'scriptPath'>): SkillEntry | null;
-/**
- * 把 `ui` 声明补全成三个互斥的完整分桶。没声明 `ui` 时按 required 推导。
- *
- * **未提及的字段一律落进 advanced**：新增参数时最坏是多折一层，而不是消失。
- * 返回 null 表示这个 skill 没有可填的参数（不该弹表单）。
- */
-export declare function resolveUiHints(raw: Pick<RawSkillJson, 'parameters' | 'ui'>): Required<SkillUiHints> | null;
-/**
- * Validate a parsed skill.json against the directory it lives in. Returns an
- * array of problem strings; an empty array means the record is well-formed.
- */
-export declare function validateSkillJson(raw: RawSkillJson, skillId: string): string[];

package/dist/template/args.d.ts

@@ -1,25 +0,0 @@
-/**
- * Strict argv parser for `remixmate template <sub>`.
- *
- * Unlike src/argv.ts (which is permissive because skill flags are forwarded to
- * Python), these subcommands own their whole surface, so an unknown flag or a
- * stray positional is a usage error (exit 2) rather than something silently
- * ignored — `publish --nmae X` must not publish under the default name.
- */
-import { SkillError } from '../errors.js';
-export type FlagKind = 'bool' | 'string';
-export type FlagSpec = Record<string, FlagKind>;
-export interface ParsedTemplateArgs {
-    positionals: string[];
-    /** Keyed by the flag name without dashes, kebab-case preserved (`props-json`). */
-    flags: Record<string, string | boolean>;
-}
-/** Flags every subcommand accepts. */
-export declare const COMMON_FLAGS: FlagSpec;
-export declare function usageError(message: string): SkillError;
-export declare function parseTemplateArgs(argv: string[], spec: FlagSpec, opts: {
-    maxPositionals: number;
-}): ParsedTemplateArgs;
-export declare function flagString(flags: ParsedTemplateArgs['flags'], name: string): string | undefined;
-/** Parse a positive number flag; usage error on anything else. */
-export declare function flagNumber(flags: ParsedTemplateArgs['flags'], name: string): number | undefined;

package/dist/template/check.d.ts

@@ -1,23 +0,0 @@
-/**
- * `remixmate template check [name] [--json] [--no-write]`
- *
- * Pure orchestration: the validation itself lives in the starter
- * (`.remixmate/check/index.mjs`, K3), synced from the same schema / security
- * policy sources the platform uses. The cli never carries its own copy — that
- * would be the drift requirement 5.2 exists to prevent.
- */
-import { type ProcOptions } from './proc.js';
-export interface CheckOptions {
-    name?: string;
-    json?: boolean;
-    noWrite?: boolean;
-    cwd?: string;
-    /**
-     * Where the check's stdout goes. Standalone `check` streams it straight
-     * through; preview/publish in --json mode route it to stderr so their own
-     * JSON stays the last stdout line.
-     */
-    stdio?: ProcOptions['stdio'];
-}
-/** Run the starter's check script; resolves to its exit code (0 ok / 1 issues / 2 usage). */
-export declare function runCheck(opts?: CheckOptions): Promise<number>;

package/dist/template/commands.d.ts

@@ -1,25 +0,0 @@
-/**
- * `remixmate template <init|check|preview|publish|list>` dispatcher.
- *
- * Exit codes follow the cli contract (errors.ts): 2 usage, 4 credentials,
- * 5 backend unreachable; `check` propagates the starter script's own code.
- * With --json a failure also ends stdout with `{"ok":false,...}` so hosts
- * parsing the last line always get an object.
- */
-import { type FlagSpec, type ParsedTemplateArgs } from './args.js';
-export declare const TEMPLATE_VERB = "template";
-export declare const TEMPLATE_SUBCOMMANDS: readonly ["init", "check", "preview", "publish", "list", "upgrade"];
-export type TemplateSubcommand = (typeof TEMPLATE_SUBCOMMANDS)[number];
-interface SubSpec {
-    flags: FlagSpec;
-    maxPositionals: number;
-    usage: string;
-}
-export declare const SUB_SPECS: Record<TemplateSubcommand, SubSpec>;
-export declare function templateUsage(): string;
-export declare function parseTemplateCommand(argv: string[]): {
-    sub: TemplateSubcommand | 'help';
-    args: ParsedTemplateArgs;
-};
-export declare function runTemplateCommand(argv: string[]): Promise<number>;
-export {};