stitchkit 0.103.13 → 0.104.1

package/llms/application.2.txt

@@ -122,49 +122,101 @@ deadline holds `stop()` — and so the resource's `force()` — for that one cal
 so give the transport a timeout. Superseding a key that is being sent right now
 does not recall it: the send completes, and only its receipt is not written.
 
-`createDirectoryInbox` is the receiving side for another program on the same
-host: it drops entries — a release transition, say — into a directory, and
-the application takes each one at least once. It is a managed resource of its
-own (`createDirectoryInbox({ id, directory, schema, handle })`, imported from
-`stitchkit/application/directory-inbox` because it touches files; its types
-and schemas are in `stitchkit/application`) and publishes a handle with
-`flush()` and `state()`. The producer writes each entry
-atomically as `<name>.json` — a temporary name, then a rename; names that start
-with a dot are never read. Entries are delivered in name order, and only after
-`activate`: none reaches the application before it is ready. `stopAdmission`
-stops taking new ones, `drain` waits for the one in flight, and `force` aborts
-the `signal` its handler was given.
-
-Taken and done are separate durable records. Before `handle` runs, the entry
-is claimed with a lease (`leaseMs`, default five minutes); after it returns,
-a receipt replaces the claim and only then is the file removed. A process that
-died mid-delivery leaves a claim, and the entry is taken again once the lease
-runs out — at least once, not exactly once, so a handler that sends somewhere
-should carry the entry's `key` as its idempotency key. A process that died
-after the receipt leaves only the file, which the next pass removes without
-delivering it again. A handler that throws is retried after a backoff from one
-second doubling to five minutes; an entry that fails `schema`, is over
-`maxEntryBytes` or was taken `maxAttempts` times (default 20 — the count
-survives restarts, so an entry whose handling kills the process is not taken
-forever) is moved to `rejected/` with its reason and reported to `onRejected`,
-and the entries after it keep flowing. The state lives in
-`<directory>/.inbox-state.json` under `createFileStateStore`'s inter-process
-lock unless a `store` is supplied.
-
-These primitives depend on the structural `StateStore`. On a server,
-`createFileStateStore` supplies the shared Zod-validated JSON adapter with an
-inter-process lock, unique temporary file, fsync and atomic rename. The lock
-is a file with a heartbeat: the holder refreshes its mtime every third of
-`staleLockMs` (default 3 s), a contender waits up to `lockTimeoutMs` (default
-10 s), and the stale bound must sit inside the timeout — otherwise a crashed
-holder blocks every update until the lock ages out, which the constructor
-refuses. A lock whose heartbeat is stale is reclaimed once its recorded pid is
-gone; a live or unverifiable pid (a reused number, another user's process)
-keeps it for ten stale bounds — and never fewer than thirty missed heartbeats,
-so a scheduler stall on a loaded host cannot pull a live lock from under its
-holder — after which the heartbeat wins and the lock is abandoned. Temporary files a crashed writer left beside the state are swept on
-the store's first update. Ledger corruption may be declared reconstructable;
-an outbox must fail closed rather than silently discard pending delivery.
+`createDirectoryInbox` receives entries from another program on the same host,
+or directly from a transport adapter. Import the resource from
+`stitchkit/application/directory-inbox`; its contracts live in
+`stitchkit/application`. Its published handle has `accept({ source, key, entry })`,
+`flush()` and `state()`:
+
+```ts
+const inbox = createDirectoryInbox({
+  id: 'updates',
+  directory: env.INBOX_DIRECTORY,
+  schema: UpdateSchema,
+  handle: ({ identity, entry, signal }) => processUpdate(identity, entry, signal),
+})
+const ingress = defineManagedResource({
+  id: 'ingress',
+  dependsOn: [inbox],
+  start(context) {
+    const intake = context.use(inbox)
+    return { value: (key: string, entry: Update) =>
+      intake.accept({ source: 'client-updates', key, entry }) }
+  },
+})
+```
+
+`accept` is available after the resource starts, including before activation.
+It validates the entry and full producer identity, writes a lossless JSON envelope,
+syncs its file and parent directory, then returns
+`{ status: 'accepted' | 'duplicate', filename }`. Automatic delivery starts at
+`activate`; an explicit `flush()` is available before activation. A producer
+should acknowledge its provider only after acceptance resolves. Failure after
+publication can mean the entry was accepted but its acknowledgement was lost:
+retry the same identity, and `duplicate` keeps the original payload.
+
+The identity is the pair `source` (1–128 characters) and `key` (1–1024 characters).
+A hash of the pair names the file; the full pair is retained inside its envelope
+and checked against existing files and records. Two sources may use the same key.
+The handler's legacy `key` remains the filename; programmatic entries additionally
+carry `identity`. No Telegram numeric update id or MTProto event shape is invented.
+
+The default `maxPendingEntries: 1000` refuses new programmatic entries when the
+pending directory is full, without publishing another file; duplicate acceptance
+still succeeds. `maxEntryBytes` defaults to 1 MiB and counts the complete UTF-8
+envelope. A completed identity is deduplicated while its receipt is retained
+(`retain`, default 1000); a rejected envelope also deduplicates while its file
+remains in `rejected/`. Choose the retention and rejected-file cleanup policy to
+match the provider's replay window. Provider cursors, identity extraction and
+external-effect idempotency remain application responsibilities.
+
+The original file-producer path also remains: atomically publish
+`<name>.json`, using a temporary name followed by a rename. Names starting with
+a dot are ignored; `intake-<64 hex characters>.json` is reserved for programmatic
+envelopes. Entries are delivered in filename order. The reader refuses unsafe
+leaf symlinks, multiple links and files changed during reading.
+`stopAdmission` stops new acceptance and delivery, `drain` waits for accepted
+storage operations and the handler in flight, and `force` aborts its handler
+signal. A handler ignoring that signal may still finish an external effect;
+the inbox leaves its entry unsettled rather than claiming it was cancelled.
+
+Taken and done are separate durable records. Before `handle`, the entry is
+claimed with a unique expiring lease (`leaseMs`, default five minutes). A
+long handler renews that lease; an expired or replaced lease cannot complete,
+reject, retry or remove the successor's file. Success first commits a receipt,
+then removes only that file generation under a new protected transaction.
+A crash after receipt commit is recovered by cleanup without redelivery. A crash
+before receipt commit may redeliver: the guarantee is at least once, so use the
+full producer identity as the external idempotency key.
+
+A throwing handler retries after a backoff from one second to five minutes.
+Schema failures, oversize files and `maxAttempts` exhaustion (default 20) are
+recorded before their files move to `rejected/`, with `onRejected` reporting the
+reason. The state defaults to `<directory>/.inbox-state.json`, or uses the supplied
+`store`. Manual file producers are responsible for atomic publication and capacity.
+
+These primitives share the structural `StateStore`. `update` owns one atomic
+read/modify/write transaction and passes a `StateStoreUpdateContext` as the
+transition's second argument. Its `await context.assertHeld()` checks that the
+transaction is still active and its exclusive generation is still owned. A custom
+store must implement both real serialization/atomic commit and this guard;
+a no-op guard does not satisfy the contract. Ordinary one-argument transition
+callbacks remain valid.
+
+On a server, `createFileStateStore` uses the same process-instance lock as
+`withExclusiveLock`, unique staging files and atomic directory-durable publication.
+`lockTimeoutMs` (default 10 s, zero means one attempt) bounds acquisition only.
+A live or unattributable owner is never replaced by age, including after an event
+loop stall or `SIGSTOP`; only a provably dead local process instance is reclaimed.
+Legacy readable pid/token records without a host are unknown owners and need
+operator recovery after the old writer is verified stopped.
+
+`staleLockMs` and `retryMs` are removed and are refused at runtime. The current
+write removes its own staging file; unknown historical temporary files are
+preserved, without an age sweep. Directory durability requires a filesystem
+supporting directory sync (Linux and macOS); Windows is refused explicitly.
+Ledger corruption may be declared reconstructable; an outbox must fail closed
+rather than discard pending delivery.
 
 ## Recovering change subscriptions
 
@@ -232,7 +284,7 @@ description: Executable patterns for moving database, poller, queue and operatio
 type: architecture
 status: active
 created: 2026-08-24
-updated: 2026-08-24
+updated: 2026-10-04 13:28 +07:00
 ---
 
 # Application migration recipes
@@ -266,6 +318,131 @@ The application still owns the client, ORM configuration, transactions,
 migrations and reconnect policy. The executable recipe deliberately fails after
 allocation and proves one rollback close.
 
+## Stateful clients, including MTProto
+
+An application-owned client is an ordinary managed resource. Keep SDK creation,
+credentials, authorization and reconnect policy in the application; no Telegram
+client SDK is required by Stitchkit. Create a fresh client inside each `start`,
+publish it after connection/readiness succeeds, and share one memoized destroy
+promise between partial-start cleanup, `close` and `force`:
+
+```ts
+let generation: { destroy(): Promise<void> } | undefined
+
+const client = defineManagedResource({
+  id: 'client',
+  async start({ signal }) {
+    const connection = createClient() // Your SDK and configuration.
+    let destruction: Promise<void> | undefined
+    const destroy = () => destruction ??= Promise.resolve()
+      .then(() => connection.destroy())
+    generation = { destroy }
+    let ready = false
+    let startFailure: unknown
+    let startFailed = false
+    let cleanupFailure: unknown
+    let cleanupFailed = false
+    try {
+      await connection.connect(signal)
+      await connection.assertReady()
+      signal.throwIfAborted()
+      ready = true
+    } catch (error) {
+      startFailure = error
+      startFailed = true
+    } finally {
+      if (!ready) {
+        try { await destroy() }
+        catch (cleanup) {
+          cleanupFailure = cleanup
+          cleanupFailed = true
+        }
+      }
+    }
+    if (startFailed) {
+      if (cleanupFailed) throw new AggregateError([startFailure, cleanupFailure],
+        'Client startup and cleanup failed', { cause: startFailure })
+      throw startFailure
+    }
+    return { value: connection }
+  },
+  close: () => generation?.destroy(),
+  force: () => generation?.destroy(),
+})
+
+const api = defineManagedResource({
+  id: 'api',
+  dependsOn: [client],
+  start(context) {
+    const connection = context.use(client)
+    return { value: async () => {
+      const lease = context.admission.acquire()
+      if (!lease) throw new ApplicationAdmissionError()
+      try { return await connection.invoke() }
+      finally { lease.release() }
+    } }
+  },
+})
+```
+
+`createClient` supplies a client whose `destroy` safely cleans partial connection
+setup; its adapter must honor cancellation or otherwise reconcile late SDK effects.
+The destroy cache belongs to one generation and is reset by the next `start`.
+Successful startup keeps the connection alive. Dependants start after readiness,
+requests acquire admission before invoking the client, and dependent HTTP resources
+close before the client. A subtree restart builds a new client and new dependants.
+
+The packed-consumer fixture
+[`managed-client-composition.mjs`](../../packages/core/scripts/consumer-lane/fixtures/minimal/src/managed-client-composition.mjs)
+proves readiness/admission, partial startup, close order, forced cleanup and restart
+with a fake client on Bun and Node. It does not claim a live provider acceptance test.
+
+## Custom StateStore transaction guards
+
+Transitions now receive `(current, context)`. Keep ordinary callbacks that only use
+`current`; update custom store implementations to pass a real protected context.
+For an in-memory test store, queue transactions and invalidate the context when
+the transaction finishes:
+
+```ts
+function memoryStore<T>(): StateStore<T> {
+  let state: T | null = null
+  let tail: Promise<unknown> = Promise.resolve()
+  return {
+    read: async () => state,
+    update(transition) {
+      const work = tail.then(async () => {
+        let active = true
+        const context: StateStoreUpdateContext = {
+          async assertHeld() {
+            if (!active) throw new Error('Transaction is no longer active')
+          },
+        }
+        try {
+          const next = await transition(state, context)
+          await context.assertHeld()
+          state = next.state
+          return next.result
+        } finally { active = false }
+      })
+      tail = work.catch(() => undefined)
+      return work
+    },
+  }
+}
+```
+
+This recipe is process-local and has no restart durability. A database store must
+guard its real transaction/generation and commit atomically; an escaped or lost
+guard must refuse. Filesystem mutations made inside inbox transactions call
+`assertHeld` immediately before publication or cleanup.
+
+For `createFileStateStore`, remove `staleLockMs` and `retryMs` from configuration.
+`lockTimeoutMs` remains the acquisition budget. Timestamp age no longer revokes
+a live or unknown writer. Stop and verify old writers before recovering a legacy
+pid-only lock; do not invent owner metadata. Historical temporary files are no
+longer deleted by age. See the [durable intake contract](application-kernel.md#durable-process-facts-and-owner-notifications).
+
 ## Long-running poller
 
 Return separate readiness and completion promises. Readiness says dependants may

package/llms/application.3.txt

@@ -36,7 +36,9 @@ cutovers are covered by the executable
 | `NotificationOutboxItem` / `NotificationOutboxReceipt` / `NotificationOutboxState` / `NotificationSend` / `NotificationFailureClassification` / `DroppedNotification` / `EnqueueNotification` | _type_ | versioned queue records, stable send identity and delivery decisions |
 | `notificationOutboxStateSchema` | function | strict persisted-state schema over an application payload schema |
 | `notificationOutboxResource` / `NotificationOutboxResource` / `NotificationOutboxResourceConfig` | function / _type_ | thin managed-resource scheduler over an outbox handle |
-| `createDirectoryInbox` (from `stitchkit/application/directory-inbox`) / `DirectoryInbox` / `DirectoryInboxConfig` / `DirectoryInboxDelivery` / `DirectoryInboxResource` | function / _type_ | managed resource delivering each `<name>.json` entry another program drops into a directory to the application at least once, after readiness; separate durable taken/done records, leases, bounded retry |
+| `createDirectoryInbox` (from `stitchkit/application/directory-inbox`) / `DirectoryInbox` / `DirectoryInboxConfig` / `DirectoryInboxDelivery` / `DirectoryInboxResource` | function / _type_ | one managed directory inbox for files or durable `accept({ source, key, entry })`; first payload wins, bounded capacity/bytes/receipts and renewable fenced leases; delivery begins after readiness and effects remain at least once |
+| `DirectoryInboxIdentitySchema` / `DirectoryInboxIdentity` / `DirectoryInboxAccept` / `DirectoryInboxAcceptResultSchema` / `DirectoryInboxAcceptResult` | schema / _type_ | validated source/key, typed entry and durable accepted/duplicate result with filename; duplicates do not replace the first payload |
+| `StateStoreUpdateContext` | _type_ | real active protected transaction: `assertHeld()` refuses after ownership loss or completion; custom adapters supply this context to their transition |
 | `DirectoryInboxStateSchema` / `DirectoryInboxState` / `DirectoryInboxRejection` / `DirectoryInboxRejectionReasonSchema` / `DirectoryInboxRejectionReason` | schema / _type_ | the inbox's claims, receipts and rejections (`invalid`, `too-large`, `attempt-limit`) |
 | `ApplicationHandle.restart` | method | replace one resource and everything that depends on it, leaving the rest of the graph running and the process epoch unchanged |
 | `ApplicationRestartInputSchema` / `ApplicationRestartInput` | schema / _type_ | the resource to replace, by id, and optionally `gracePeriodMs` / `forceTimeoutMs` for this restart — the application's own shutdown budget otherwise |

package/llms/application.txt

@@ -19,7 +19,7 @@ description: Compose process-local resources, schedules, readiness, drain and op
 type: architecture
 status: active
 created: 2026-08-23
-updated: 2026-09-30 17:41 +07:00
+updated: 2026-10-04 13:28 +07:00
 ---
 
 # Managed application kernel

package/llms/cli.2.txt

@@ -5,7 +5,146 @@
 
 Parts of this slice:
 - `llms/cli.txt`: Guide: CLI  (docs/guide/cli.md)
-- `llms/cli.2.txt`: API reference: `stitchkit/cli`  (docs/api/reference.md)
+- `llms/cli.2.txt`: Guide: CLI  (docs/guide/cli.md) · API reference: `stitchkit/cli`  (docs/api/reference.md)
+
+==============================================================================
+# Guide: CLI  (docs/guide/cli.md)  (continued)
+==============================================================================
+
+## Commands discovered from a running server
+
+A CLI compiled from contracts carries the surface of the build it was compiled
+from. One built from discovery carries the surface the server has *right now* —
+which matters, because a long-lived MCP client freezes schemas at connect time
+and then refuses the server's own newer fields:
+
+```ts
+const discovered = await mountConnections([
+  defineMcpClientConnection({
+    name: 'api',
+    transport: { url },
+    token: () => key,
+    transports: ['CLI'],   // the opt-in: this server's tools are commands
+    limits: {
+      discovery: { timeoutMs: 30_000, maxResponseBytes: 4 * 1024 * 1024 },
+      call: { timeoutMs: 120_000 },
+    },
+  }),
+])
+await createCli({ name: 'myapp', version, runtimeTools: discovered, commands: [...] })
+```
+
+`transports` is where the opt-in belongs: a whole server becomes a set of
+commands, and a connection without it still contributes nothing to the CLI —
+exposure stays explicit, as it is everywhere else in the framework.
+
+One unconvertible schema no longer takes the connection down with it. The tool
+is skipped and **named** (`onSkippedTool`, or a stderr line by default), so a
+surface of two hundred tools is not lost to one.
+
+MCP connection limits follow the operation phase. `initialize`, the initialized
+notification, `tools/list` and legacy endpoint discovery use `limits.discovery`;
+`tools/call` uses `limits.call`. A mounted call's handshake still uses discovery
+limits. Each logical operation has one deadline, including initial transport
+negotiation and response-body reading. Legacy endpoint readiness has a discovery
+deadline; the lifetime of an established SSE stream does not.
+
+Omitted phase fields inherit the existing connection-level `timeoutMs` and
+`maxResponseBytes`, whose defaults are 30 seconds and 1 MiB. Values must be positive
+safe integers; `timeoutMs` must also fit the runtime timer range. The byte ceiling
+counts raw UTF-8 body bytes, including SSE framing, regardless of `Content-Length`.
+Pending legacy calls also count comments and wrong-id frames. `budget.maxTools`
+and `budget.maxSchemaBytes` remain separate mount limits.
+
+Only the initial `initialize` can negotiate HTTP-to-legacy fallback on 400, 404
+or 405. A failed `tools/call` is not replayed. Caller cancellation preserves its
+original reason for in-process observers.
+
+Expected local failures produce safe tool errors: `CONNECTION_TIMEOUT` (exit 7),
+`CONNECTION_RESPONSE_TOO_LARGE` (exit 1), `UNAUTHORIZED` (exit 2), `FORBIDDEN`
+(exit 3) or `CONNECTION_REQUEST_FAILED` (exit 1). Deadline and response-limit
+failures include fixed `operation`/`phase`, the applicable bound and measured
+`observedReadBytes`. The public `ConnectionTimeoutError` and
+`ConnectionResponseTooLargeError` classes carry the same diagnostics. Raw URL,
+credential, body, identity and stack stay with the original in-process cause in
+`onToolError` / `afterToolCall`; tool errors produce no process console dump.
+Unknown throws remain `INTERNAL_SERVER_ERROR`. A timeout is not proof that a
+write did not happen: verify the remote outcome before repeating an operation.
+
+**A remote refusal keeps its code.** A failed `tools/call` used to become a
+one-sentence `Error` with the result discarded, which cost three things at once:
+the code (so `exitCodes` had nothing to map and every remote failure exited `1`),
+the message the operator needed, and the error's own class — a plain `Error` is
+an *unexpected* error to the runner, so it printed a code frame of the framework
+bundle before the JSON failure and was then scrubbed to `INTERNAL_SERVER_ERROR`.
+A structured `{ error, details }` body is now relayed as the contract error it
+is, on every transport; anything else fails as `UPSTREAM_TOOL_ERROR` carrying
+what the server did send. Not `INTERNAL_SERVER_ERROR`, because nothing of ours
+broke.
+
+**On the CLI a discovered command prints the answer, not the envelope.**
+`tools/call` returns `{ content: [...], structuredContent? }`, and an agent mount
+needs exactly that — the parts are what a model is shown. The CLI is different in
+kind, because the handler's value is what gets printed, piped and aggregated:
+handed the envelope, `--count-by status` groups the *content parts* and answers
+`no record carries the field "status" — available: text, type`. So the CLI
+transport unwraps, and only it: `structuredContent` when the server sent one, a
+lone text part when it parses as JSON, its text when it does not, and `null` when
+there are no parts at all — a tool without an output contract answers that way,
+and the `_meta` beside an empty `content` is protocol metadata, never the answer.
+Several parts, an image or audio pass through whole — picking one of many would
+be inventing an answer.
+
+## Auth parity
+
+A scoped command is guarded by the same `createAuthHook` your HTTP server uses —
+pass it as `lifecycle`, and inject the identity through `context` so
+`resolveFromContext` can read it:
+
+```ts
+const authHook = createAuthHook({ /* resolve, resolveFromContext, rules */ })
+
+await createCli({
+  name: 'myapp',
+  version: '1.0.0',
+  resolveAuth: () => resolveIdentityFromToken(process.env.MYAPP_TOKEN),
+  context: (identity) => ({ user: identity }),   // resolveFromContext reads this
+  lifecycle: { beforeHandle: authHook },          // same policy; HTTP wires it as authorize
+  services,
+})
+```
+
+Without `lifecycle`, a scoped command runs **unguarded** — the scope check lives
+entirely inside the `createAuthHook` result, so with no hook wired in there is
+nothing to enforce a method's `scope`. This matches the MCP / agent surfaces
+exactly ([ADR 0014](../decisions/0014-tool-http-parity.md)): on every tool
+transport the auth gate is opt-in, so a contract with scoped methods **must** be
+given a `lifecycle` (and `context` identity) to be protected. The gate only
+*fails closed* once the hook **is** present but `resolveFromContext` is missing —
+then a scoped call has no identity and is rejected.
+
+## Typed context
+
+Use `createToolkit<AppContext>()` to type the injected `context` against your
+app's context shape — the tool-side mirror of `createImplement`
+([ADR 0017](../decisions/0017-typed-tool-context.md)):
+
+```ts
+const tools = createToolkit<{ user: User }>()
+await tools.createCli({
+  name: 'myapp',
+  version: '1.0.0',
+  services,
+  context: (identity) => ({ user: identity }),   // checked against { user: User }
+})
+```
+
+## Remaining boundary
+
+File-upload (`multipart`) contract endpoints remain CLI-invisible, the same as
+on MCP/Agent: their wire body is not a JSON tool form. Model file-oriented
+application behavior as a managed pathless command, or binary-only behavior as
+a native command. Streaming (SSE) output is not yet piped to stdout.
 
 ==============================================================================
 # API reference: `stitchkit/cli`  (docs/api/reference.md)
@@ -33,6 +172,7 @@ SDK nor the `ai` peer.
 | `checkCliUpdate` | function | bounded, interval-limited, never-throwing check for a newer published build |
 | `applyCliUpdate` | function | download, verify the decompressed digest and replace the binary by rename |
 | `assertCliPublishable` | function | refuse republishing one version from a different commit — takes one manifest or every manifest already published, because the promise a version makes does not stop at a channel boundary |
+| `publishCli` / `CliPublicationOptions` / `CliPublicationPhase` / `CliPublicationResult` | function / _type_ | optional bounded builder/admission over one immutable name/version/commit stamp; commit verified assets before the manifest pointer, recover exact completed versions, retain verified history; existing signatures/installer/updater own the wire contract |
 | `rollbackCliUpdate` / `CliRollbackConfig` / `RolledBackCliUpdate` | function / _types_ | put the kept previous build back, digest-checked first and written by the same atomic rename the update uses |
 | `signCliManifest` / `verifyCliManifest` / `cliManifestSigningPayload` | function | Ed25519 over `{name, version, commit, builtAt, assets[]}` — every asset's digest included, so the chain closes on the file that executes |
 | `cliSignatureAccepted` / `CliSignatureVerdict` | function / _type_ | `valid` \| `unenforced` \| `missing` \| `unknown-key` \| `invalid`; `unenforced` keeps an unpinned build updating while making the absence of a check visible |
@@ -64,6 +204,9 @@ SDK nor the `ai` peer.
 | `CliConfig` | _type_ | config for `createCli`; `defaultCommand`, `globalOptions`, `optionAliases` and `positionals` define the shared command presentation policy |
 | `CliPresentationPolicyConfig` | _type_ | shared command presentation-policy subset of `CliConfig` |
 | `CliSurfaceSource` | _type_ | static service/runtime array or identity-dependent factory |
+| `RuntimeToolExecution` | _type_ | neutral heterogeneous runtime-tool registration; handlers execute through the schema-validating managed runner |
+| `RuntimeToolExecutionWithOutput` | _type_ | strict neutral managed definition with schema-derived handler input/output; construct before adding to CLI `runtimeTools` |
+| `RuntimeToolDefinitionWithoutOutput` | _type_ | strict neutral managed void definition without an output contract or transport presenters |
 | `CliCommandDefinition` | _type_ | native command definition union |
 | `CliCommandDefinitionBase` | _type_ | native command name, description and input schema |
 | `CliCommandDefinitionWithOutput` | _type_ | native command with validated declared output and typed optional `present` / successful `exitCode` callbacks |