@usenaive-sdk/cli 0.15.1 → 1.0.1

package/dist/commands/up.d.ts

@@ -1,551 +0,0 @@
-import { Command } from "commander";
-import { type NextStep } from "../output.js";
-/** What the API reports back per declared `runtime.durable` team. */
-export interface DurableTeamResult {
-    team: string;
-    /**
-     * The tenant this team routes as, `(companyId, tenantUserId)`.
-     *
-     * PRINTED, because the two-step flow is unusable without it. A durable team is
-     * refused until the runtime already holds it, and registering it there needs
-     * the tenant_user_id — which nothing else on this side shows. The refusal used
-     * to say "supply the credential the runtime issued for this tenant" without
-     * ever naming the tenant.
-     */
-    subject?: {
-        company_id: string;
-        tenant_user_id: string;
-    };
-    agents?: Array<{
-        role: string;
-        provision_status: string;
-        loop?: AppliedLoop;
-    }>;
-    archived?: string[];
-    /**
-     * Job ids this apply CANCELLED on the runtime because the config stopped
-     * declaring them. Printed, because a timer that was stopped is real work the
-     * apply did and the alternative — silence — is what makes "I deleted the loop
-     * and it kept firing" indistinguishable from "I deleted the loop and it
-     * stopped".
-     */
-    loops_unscheduled?: string[];
-    placement?: {
-        status: string;
-        code?: string;
-        message?: string;
-        details?: Record<string, unknown>;
-    };
-    /**
-     * WHAT MANIFEST DELIVERY DID, which is a DIFFERENT fact from `placement`.
-     *
-     * `placement` answers "does this tenant route to the durable runtime". This
-     * answers "does the runtime enforce what the config declared". A placed team
-     * whose manifest was refused is exactly the state that must not read as
-     * success: it routes, it accepts requests, and it dispatches nothing —
-     * `deliverTeamManifest` (packages/api/src/services/system-staffing.ts) PUTs
-     * the record and then applies the digest, and a team whose bind was refused
-     * ticks with no bound manifest.
-     *
-     * This field was ALREADY on the wire and this interface was the entire loss.
-     * Traced end to end: `deliverTeamManifest` returns `ManifestDelivery`, the
-     * materializer carries it on `DurableTeamApply.manifest`, `applyDeployment`
-     * returns that object whole, and the route `res.json(result)`s it (sync) or
-     * stores it as the job result (async) — which this command reads back
-     * verbatim as `job.result`. Nothing in between dropped it; only this
-     * interface failed to name it, so the CLI decoded a refusal into nothing.
-     *
-     * `status` is typed `string`, not the API's union
-     * (`applied | noop | delivered_not_applied | refused | unreachable |
-     * skipped`), matching how `placement.status` is already typed one line up:
-     * the CLI decodes untrusted wire JSON and the API owns the union. A server
-     * that grows a seventh status must not make this decoder throw.
-     */
-    manifest?: {
-        status: string;
-        digest?: string;
-        code?: string;
-        error?: string;
-    };
-    /**
-     * What apply did with each `team({ on })` trigger — ONE ENTRY PER KEY.
-     *
-     * Never a count, for the reason the per-loop lines exist: a registered timer
-     * and a refused one are different facts, and a summary is exactly where they
-     * get confused. `registerTeamTriggers`
-     * (packages/api/src/services/system-staffing.ts) reports per trigger and this
-     * interface is the only thing between that report and the operator.
-     */
-    triggers?: AppliedTrigger[];
-    /** Trigger job ids this apply CANCELLED because the config stopped declaring them. */
-    triggers_unscheduled?: string[];
-    /**
-     * Standing runtime schedules this config did NOT author. Named, never
-     * cancelled — see `registerTeamTriggers` for why the marker is a job-id
-     * namespace rather than the `config_source` stamp apply uses everywhere else.
-     *
-     * PRINTED, because the decision is made correctly in the service and is
-     * invisible without this: apply deliberately leaves somebody else's timer
-     * standing, and an operator who is never told cannot act on it. Same shape as
-     * the brains `retained` sentence, deliberately — one vocabulary for "this
-     * exists, this config did not declare it, remove it yourself".
-     */
-    schedules_retained?: string[];
-    /**
-     * Capabilities the CONTROL PLANE added to this team's manifest that the config
-     * did not declare — `"<role>: <capability>"`. See `DurableTeamApply
-     * .manifest_grants` on the API for what it is and why it had to be named.
-     *
-     * PRINTED for the same reason `schedules_retained` is: the decision is made
-     * correctly on the other side and is invisible without this. `naive up`, the
-     * `/plan` report and `/roster` all show the DECLARED `can:`, and the digest an
-     * operator reviews and binds contained one more capability than any of them
-     * listed.
-     */
-    manifest_grants?: string[];
-}
-/**
- * What apply did with one declared trigger — see `AppliedTrigger` on the API.
- *
- * `status` carries a FOURTH state the loop lane does not have. A loop against an
- * unbound manifest is reported `queued`, which is honest for a loop: the next
- * `naive up` registers it. A trigger says `blocked_unbound` because the operator
- * ACTION is different and a shared word hides it — `queued` reads as "the
- * runtime was busy, wait", and the real state is "the runtime refuses to
- * schedule against a manifest it has not bound, and `naive teams apply` is the
- * repair", which is a thing a human must go and do.
- */
-interface AppliedTrigger {
-    key: string;
-    cron: string;
-    name: string;
-    status: "registered" | "queued" | "unschedulable" | "blocked_unbound";
-    /** WHY, in the words of whatever decided it — a runtime sentence, verbatim. */
-    reason?: string;
-}
-/** What the API reports about the brains `company.brains` declared. */
-interface BrainsResult {
-    declared_in?: string | null;
-    created?: Array<{
-        name: string;
-    }>;
-    converged?: Array<{
-        name: string;
-    }>;
-    default?: {
-        name?: string | null;
-        changed?: boolean;
-    };
-    retained_undeclared?: string[];
-    /**
-     * Declared brain policy with no column to land in, per brain.
-     * `brain_knowledge_bases` has columns for name, is_default, scope, status and
-     * provider ids and nothing else, so `retention`, `partitions`, `writes`,
-     * `recall`, `lanes`, `visibility` and `bounds` are accepted and not stored.
-     */
-    unpersisted?: Record<string, string[]>;
-    /** The server's own prose for the same, plus the retained-undeclared note. */
-    notes?: string[];
-}
-/**
- * The brain half of the report, or undefined when the config declared none.
- *
- * Exported for the same reason it exists: `naive up` printed `applied: true` and
- * said NOTHING about brains, so a config that declared two of them looked
- * identical to a config that declared none. `--plan` showed them (it prints the
- * whole plan); apply did not. A provisioned thing that is not reported is the
- * same silence as an unprovisioned one, one level up.
- *
- * 🔴 AND `unpersisted` IS PART OF THE REPORT, NOT AN EXTRA. The apply path
- * computed the accept-and-drop list and this projection threw it away, so
- * `naive up --plan` told the user which declared brain keys have no column and
- * plain `naive up` — the command people actually run — did not. That is the same
- * defect one level down: `packages/api/src/services/deployment-brains.ts`'s own
- * header calls accept-and-drop "the exact defect this file exists to remove", and
- * a report only the dry run prints is a report most operators never see.
- */
-export declare function brainReport(brains: BrainsResult | undefined): {
-    declared_in: string | null;
-    created: string[];
-    converged: string[];
-    default: string | null;
-    retained: string[];
-    unpersisted?: Record<string, string[]>;
-    notes?: string[];
-} | undefined;
-/** What the frozen runtime reports per hermes team. */
-interface HermesTeamResult {
-    system: string;
-    agents?: Array<{
-        role: string;
-        provision_status: string;
-        loop?: AppliedLoop;
-    }>;
-    archived?: string[];
-}
-/** What apply did with one agent's declared `loop` — see AppliedLoop on the API. */
-interface AppliedLoop {
-    name: string;
-    /** The calendar arm. Absent on an interval loop — see {@link loopCadence}. */
-    cron?: string;
-    /** The interval arm, in seconds. Durable lane only; absent on a cron loop. */
-    everySeconds?: number;
-    status: "registered" | "queued" | "unschedulable";
-    /**
-     * WHY, in the words of whatever decided it. Set on the durable lane only — a
-     * runtime refusal quoted verbatim, or "already registered; unchanged" for a
-     * re-apply that converged. Optional because the hermes lane's `queued` has one
-     * meaning and repeating it every line would be noise.
-     */
-    reason?: string;
-}
-/** One printed loop line: the role that declared it, plus what apply did with it. */
-export type PrintedLoop = AppliedLoop & {
-    role: string;
-};
-/**
- * How a loop's cadence PRINTS — the one place that decides, so the four lines
- * below cannot disagree about it.
- *
- * An interval is spelled `every 3600s` rather than as a bare number: `(3600)`
- * next to a name reads as an id, and the whole point of this line is that an
- * operator can tell at a glance what is about to spend on a timer.
- *
- * The empty fallback is reachable only for an {@link AppliedLoop} carrying
- * neither arm, which the fold refuses (`loop_cadence_invalid`) — so it exists to
- * keep the report printable rather than to describe anything real.
- */
-export declare function loopCadence(l: {
-    cron?: string;
-    everySeconds?: number;
-}): string;
-/**
- * Every loop this apply touched on a team, BOTH LANES FOLDED.
- *
- * A registered loop is real, recurring work the apply just scheduled, and
- * reporting nothing about it made a firing schedule invisible — the reason this
- * projection exists at all. It read `hermes?.agents` only, which was correct
- * exactly as long as the durable lane registered nothing: a durable role's
- * `loop` came back in `unconsumed` and there was no timer to print. Now that
- * `registerDurableTeamLoops` (packages/api/src/services/system-staffing.ts)
- * registers it against the runtime's own alarm, reading one lane would make a
- * schedule the apply had just created invisible on the OTHER runtime — the same
- * silence, moved.
- *
- * Folded rather than `durable ?? hermes` for the reason `agents` is: a MIXED
- * team is reported by both materializers and preferring one drops the other's
- * half.
- */
-export declare function projectLoops(hermes: HermesTeamResult | undefined, durable: DurableTeamResult | undefined): PrintedLoop[];
-/** The shape `loopHints` reads — a printed team, narrowed to what it needs. */
-export interface LoopBearingTeam {
-    name: string;
-    runtime: string;
-    role_runtimes?: Record<string, string>;
-    loops?: PrintedLoop[];
-    loops_unscheduled?: string[];
-}
-/**
- * One hint line per loop, plus one per loop this apply cancelled.
- *
- * 🔴 THE LIST COMMAND IS LANE-DEPENDENT AND NAMING THE WRONG ONE IS WORSE THAN
- * NAMING NONE. `naive cron list` reads `cron_jobs`, which has no row for a
- * durable tenant — an operator who followed it after a durable loop registered
- * would find nothing and conclude the line above it had lied. A mixed team has
- * both lanes at once, so the lookup is per ROLE and falls back to the team's.
- */
-export declare function loopHints(t: LoopBearingTeam): string[];
-/** The shape {@link grantHints} reads — a printed team, narrowed to what it needs. */
-export interface GrantBearingTeam {
-    name: string;
-    manifest_grants?: string[];
-    manifest?: {
-        status: string;
-        digest?: string;
-    };
-}
-/**
- * 🔴 WHAT THE CONTROL PLANE PUT IN THE DIGEST THAT THE CONFIG DID NOT.
- *
- * `projectTeamRecord` grants a durable team's LEAD the built-in `delegate` when
- * the lane has more than one member. The grant is narrow and argued for at
- * length where it is made, and it was reported NOWHERE: `naive up` prints the
- * declared `can:`, and so do `/plan` and `/roster`, so the authority surface an
- * operator reviews before running `naive teams apply … --expected-digest …`
- * contained one capability more than anything on naive listed. A digest that
- * moves for a reason no surface names is the same silence the manifest report
- * itself exists to end, one field deeper.
- *
- * SAID PER TEAM AND ONLY WHEN THERE IS SOMETHING TO SAY. A one-member durable
- * team gets no grant and no line.
- */
-export declare function grantHints(t: GrantBearingTeam): string[];
-/** The shape `triggerHints` reads — a printed team, narrowed to what it needs. */
-export interface TriggerBearingTeam {
-    name: string;
-    triggers?: AppliedTrigger[];
-    triggers_unscheduled?: string[];
-    schedules_retained?: string[];
-}
-/**
- * One hint line per declared trigger, one per trigger this apply cancelled, and
- * ONE RETAINED LINE for standing schedules this config did not author.
- *
- * A sibling of {@link loopHints} rather than a branch inside it, printed
- * immediately after it, and the split is not cosmetic: a trigger has no ROLE.
- * `agent({ loop })` reserves every firing to the member that declared it and
- * every loop line says `team/role`; `team({ on })` fires UNRESERVED and the
- * board hands the card to whoever is next. A line that named a role would name
- * one that does not exist.
- *
- * 🔴 THE RETAINED LINE IS THE HALF THAT WOULD OTHERWISE BE INVISIBLE, and it is
- * the reason this function exists at all. `registerTeamTriggers` refuses to
- * cancel a schedule it cannot prove it wrote — the one destructive failure that
- * cannot be undone by re-running anything — and then says nothing about it. A
- * correct decision nobody is told about is the same defect one level up: the
- * operator still has a timer spending on a cadence no config declares, and now
- * also has no evidence it exists. The sentence is copied in shape from the
- * brains one this file already prints, down to "remove one deliberately", so an
- * operator meets one vocabulary for drift rather than two.
- *
- * 🔴 AND WHERE A FIRING WILL NOT SHOW UP, said once per team that declares any.
- * A durable schedule's firing reaches NEITHER existing observability surface:
- * `GET /v1/triggers/ledger` reads the `events` table, whose sources are
- * `email|objective|cron|task|approval|company_channel` and which a durable alarm
- * never writes, and `routeEvent` writes `trigger_deliveries` over a disjoint
- * vocabulary it also never writes. The board is the only place the work appears.
- * Naming that here is the cheap mitigation; reconciling the two ledgers is its
- * own piece of work.
- */
-export declare function triggerHints(t: TriggerBearingTeam): string[];
-/** What the plan reports per declared team, whichever runtime it asked for. */
-interface TeamPlanEntry {
-    name: string;
-    runtime: string;
-    roles?: string[];
-    lead_role?: string;
-    /** Role → runtime, present only for a MIXED team. See `role_runtimes` on the API. */
-    role_runtimes?: Record<string, string>;
-    placement?: {
-        status: string;
-        code?: string;
-        message?: string;
-    };
-    /** Keys this team declared that NOTHING on the control plane reads. */
-    unconsumed?: string[];
-}
-/**
- * The per-team accept-and-drop warning, one line per team that declared any.
- *
- * The data has been on the wire the whole time (`plan.teams[].unconsumed`,
- * computed by `unconsumedTeamKeys` in packages/api) and `naive up` printed none
- * of it — `team({ governance: {…} })` applied green and enforced nothing, with
- * nothing anywhere for the author to notice. Printed on the PLAN and on the
- * APPLY, because a report only the dry run shows is a report most operators
- * never see.
- */
-export declare function unconsumedWarnings(teams: readonly TeamPlanEntry[]): string[];
-/**
- * ONE deprecation line when the config still uses the legacy ECS surface —
- * `runtime.pool()` declarations, an agent-level `runtime: "<pool>"` string, or
- * `systems:`. All three keep working indefinitely; the line names what was
- * found and where new configs should author instead.
- */
-export declare function legacyDeprecationNotice(config: Record<string, unknown>): string | null;
-/**
- * ONE rename line when the config declares `agents:`. Separate from the legacy
- * line above on purpose: `runtime.pool()` / `systems:` are a deprecated
- * SURFACE, while `agents:` is a deprecated SPELLING — the block compiles to
- * byte-for-byte what `kits:` compiles to, so the honest notice is "rename",
- * not "migrate". A notice, never a refusal, on both entrypoints.
- */
-export declare function agentsRenameNotice(config: Record<string, unknown>): string | null;
-/**
- * The operator credential the DURABLE RUNTIME issued, read from the ENVIRONMENT.
- *
- * Never from `naive.config.ts`, and that is the whole point rather than a style
- * choice. The config is committed, so a credential in it is a credential in git —
- * and, more importantly, the config is the one thing that must not by itself be
- * able to change where a tenant runs. Pointing a tenant at the durable runtime
- * overwrites its `sidecar_url` and `container_auth_token` and nulls its
- * `instance_id`, none of which is stashed anywhere. Requiring a second, separate
- * act means an edit alone can never do it.
- *
- * `NAIVE_DURABLE_CREDENTIAL_<TEAM>` names one team; `NAIVE_DURABLE_CREDENTIAL`
- * covers them all. Neither is ever printed, and the API never echoes it back.
- */
-export declare function durableCredentialEnvVar(team: string): string;
-/**
- * The recovery for ONE refused team — a command that EXISTS, or none.
- *
- * 🔴 `naive runtime migrate` IS NOT A COMMAND, AND THIS USED TO PRINT IT.
- * Every refusal here used to emit
- * `naive runtime migrate --tenant … --to durable --credential-from <file>`.
- * Measured on the built CLI: `naive runtime migrate --tenant <id> --to hermes`
- * answers
- * `{"code":"cli_outdated","message":"Unknown command 'runtime'. Your naive CLI
- * is v0.12.4; this command may exist in a newer version."}` — and it exists in
- * NO version: `packages/cli/src/index.ts` registers no `runtime` group at all.
- * So an operator whose apply was refused was handed a command that tells them to
- * upgrade, forever. A next_step that cannot be run is worse than none, because it
- * ends the search.
- *
- * The two cases are genuinely different and are answered differently:
- *
- *   · `runtime_credential_required` — there IS a procedure, it works today, and
- *     it is the one this command already implements: put the operator credential
- *     the durable runtime issued in the environment and re-run. Never in
- *     `naive.config.ts`, which is committed.
- *   · everything else (`runtime_migration_requires_explicit_opt_in`,
- *     `runtime_claim_in_flight`, `runtime_placement_lost_race`,
- *     `runtime_not_configured`, `runtime_state_unknown`) — there is NO self-serve
- *     command on this build. Moving an existing tenant between runtimes
- *     overwrites `sidecar_url` and `container_auth_token` and nulls `instance_id`
- *     with nothing stashed, so the control plane refuses it and no client can do
- *     it either. Say that, and print the server's own message, rather than
- *     inventing a command to carry the blame.
- *
- * The API writes the same vapour into `details.migrate_command`
- * (packages/api/src/services/placement.ts MIGRATE_COMMAND). That string is not
- * this package's to change and is reported as a follow-up; this function is why
- * `naive up` no longer repeats it.
- */
-export declare function refusalNextStep(t: {
-    name: string;
-    placement?: {
-        code?: string;
-    };
-}): NextStep | null;
-/**
- * The `manifest` half of one team's report line, from the API's own team row.
- *
- * A SIBLING OF `placement`, NEVER NESTED INSIDE IT. The API's comment on the
- * field this reads is explicit about why: "the tenant routes to the durable
- * runtime" and "the runtime enforces what the config declared" are different
- * facts, and a placed team with a refused manifest is exactly the state that
- * must not read as success. Nesting one inside the other would collapse a
- * distinction the API deliberately kept, and would make the refusal look like a
- * detail of a successful placement.
- *
- * Absent when the API reported nothing — a hermes team has no manifest at all,
- * and an older server does not send the field. An empty object rather than
- * `{ manifest: undefined }`, so the printed envelope has no key for a fact
- * nobody stated.
- */
-export declare function projectManifest(durable?: Pick<DurableTeamResult, "manifest">): {
-    manifest?: {
-        status: string;
-        digest?: string;
-        code?: string;
-        error?: string;
-    };
-};
-/** One line of `naive up`'s team report, as far as the manifest half cares. */
-interface TeamManifestLine {
-    name: string;
-    /** The team's OWN tenant subject. Not the caller's — see `manifestReport`. */
-    subject?: {
-        tenant_user_id?: string;
-    };
-    manifest?: {
-        status: string;
-        digest?: string;
-        code?: string;
-        error?: string;
-    };
-}
-/**
- * WHAT `naive up` SAYS ABOUT MANIFEST DELIVERY, AND WHETHER IT MAY STILL EXIT 0.
- *
- * Extracted for the same reason `brainReport` is: the claim — "a refused
- * manifest is reported in the runtime's own words and the apply exits
- * non-zero" — is otherwise only assertable against a live API.
- *
- * Delivering the manifest is the step that turns a placed tenant into a working
- * one. Before this existed the CLI decoded the placement and dropped the
- * delivery, so a team that routed correctly and enforced NOTHING printed
- * exactly like one that worked: `placement: { status: "placed" }`, `applied:
- * true`, exit 0.
- *
- * 🔴 A `next_step` IS NOW OFFERED FOR `delivered_not_applied`, AND FOR NOTHING
- * ELSE. This block previously offered none at all, under this reasoning:
- *
- *     The obvious candidate is `naive teams apply <team> --expected-digest
- *     <digest>` and it is wrong TWICE on this build: `teamsCmd` registers no
- *     `apply` subcommand, and the control plane routes `POST …/apply` through
- *     `REFUSED_WRITES` to a 501.
- *
- * Both halves are now false, and the FIRST ONE WAS NEVER TRUE. `teams.ts`
- * declares no subcommands at all — it walks `lib/teams-catalog.ts` — and that
- * catalog has carried an `apply` row, with a REQUIRED `--expected-digest` that
- * defaults to nothing, since before this branch was written. Verified by
- * running the built CLI rather than by reading for it:
- *
- *     $ naive teams --help
- *       apply [options] <team>   Record that an operator applied this exact
- *                                manifest digest. Refuses a stale one
- *
- * The second half is false as of this change: `POST …/apply` is a
- * `DURABLE_WRITES` row and reaches the runtime's own `apply` verb. So the
- * command exists, the route exists, and the digest is already in hand — which
- * is exactly the condition {@link refusalNextStep} sets for emitting one.
- *
- * `--tenant` IS SPELLED OUT, AND IT IS NOT OPTIONAL. `naive teams` requires it
- * on every subcommand and has NO default, deliberately: "a command that guesses
- * the tenant is a command that acts on the wrong tenant exactly once". A durable
- * team's subject is its OWN — `ensureTeamSubject` mints one per declared team —
- * so `--tenant @self` would address the operator's subject and bind a digest on
- * a tenant that is not this team. The apply response carries the right id on
- * `subject.tenant_user_id` and that is what is printed. If it is somehow absent
- * the next_step is WITHHELD rather than emitted with a placeholder, because a
- * command an operator has to guess a field in is the same dead end as a command
- * that 501s.
- *
- * STILL NO next_step FOR `refused` OR `unreachable`, and the distinction is the
- * point. `delivered_not_applied` means the record IS stored and only the bind
- * failed — a retryable act with a known digest. `refused` means the runtime
- * would not take the record at all, so there is nothing to apply and the fix is
- * in the config; `unreachable` means nothing was attempted. Offering an apply
- * for either would send an operator to run a command that cannot succeed.
- */
-export declare function manifestReport(teams: ReadonlyArray<TeamManifestLine>): {
-    unbound: TeamManifestLine[];
-    hints: string[];
-    nextSteps: NextStep[];
-};
-/**
- * THE ONE PARAGRAPH SAID ABOUT UNBOUND MANIFESTS AS A GROUP, RATHER THAN PER
- * TEAM — and it is emitted only for the teams {@link manifestReport} could NOT
- * hand a repair command to.
- *
- * 🔴 IT USED TO CONTRADICT THE NEXT_STEP PRINTED THREE LINES ABOVE IT. Written
- * inline in the command's action closure by parity 0, it read:
- *
- *     No `naive` command binds a manifest on this build: `naive teams`
- *     registers no `apply` subcommand, and the control plane answers
- *     `POST /v1/teams/.../apply` with 501.
- *
- * Both halves are false at HEAD and the first was never true — the full
- * accounting is in {@link manifestReport}'s own comment, which emits
- * `naive teams apply <team> --tenant … --expected-digest …` for
- * `delivered_not_applied`. That is the SAME status that put a team in
- * `unbound`, so an operator was handed a command and then told, one line later,
- * that no such command exists. It survived because it was a string inside a
- * 500-line closure that nothing imports and nothing could call.
- *
- * So it is a function now, for the reason `manifestReport` is one: a claim that
- * cannot be called cannot be tested, and this one was wrong for two commits.
- *
- * WHAT IT SAYS NOW is the fact that is actually true of the teams it fires for:
- * `naive teams apply` binds a digest the runtime has ALREADY STORED, so it can
- * repair `delivered_not_applied` and nothing else. `refused` means the record
- * was never taken; `unreachable` means it was never delivered. For both, the
- * runtime's own sentence is printed above and re-running `naive up` re-delivers.
- *
- * The condition is "an unbound team that got no next_step", not "any unbound
- * team": a team whose repair is printed does not need to be told there is none.
- */
-export declare function unbindableNote(report: Pick<ReturnType<typeof manifestReport>, "unbound" | "nextSteps">): string[];
-export declare const upCmd: Command;
-export declare const downCmd: Command;
-export {};