@synapsor/runner 0.1.0-alpha.9 → 0.1.0

package/README.md

@@ -7,24 +7,67 @@ Runner lets an MCP agent inspect scoped data and request database-backed
 business actions without receiving raw SQL, write credentials, approval tools,
 or commit tools.
 
-## Alpha Operational Notes
+## The Five-Line Model
 
-These are current alpha requirements, not hidden behavior:
+Your agent talks to Synapsor Runner, not directly to your database.
+It can look: scoped reads through reviewed tools.
+It can suggest: saved proposals with evidence and exact diffs.
+It cannot commit: approval and writeback happen outside the model-facing tool.
+After writeback, Runner keeps receipts and replay so you can inspect what happened.
 
-- Writeback with `--config ./synapsor.runner.json` reads the trusted writer
-  connection from the source `write_url_env`, for example
-  `SYNAPSOR_DATABASE_WRITE_URL`. `SYNAPSOR_DATABASE_URL` is only the legacy
-  fallback when you run direct worker/apply flows without a local config.
-- `synapsor-runner mcp serve-http` is a small authenticated JSON-RPC endpoint
-  for `tools/list`, `tools/call`, and `resources/read`. It is not full MCP
-  Streamable HTTP and does not implement the `initialize`/SSE handshake. Use
-  stdio MCP for standard local MCP clients, or wrap the HTTP endpoint like the
-  OpenAI HTTP example.
-- Direct SQL writeback creates or writes `synapsor_writeback_receipts` for
-  idempotency and replay. The trusted writer needs permission for that table,
-  or an administrator must pre-create it and grant access. Use an app-owned
-  `http_handler` or `command_handler` if Runner should not create receipt
-  tables in your application schema.
+## Four Terms
+
+- Capability: a tool you define in config, such as `billing.inspect_invoice`
+  or `billing.propose_late_fee_waiver`. The agent only sees capabilities.
+- Proposal: the agent's suggested database-backed change. It is saved, not
+  applied.
+- Writeback: the moment an approved proposal actually changes the database.
+- Executor: your app's writeback handler for anything richer than a guarded
+  one-row update.
+
+You install only `@synapsor/runner`. There is no separate handler package to
+install. A handler is your app's endpoint or script for rich approved writes;
+Runner includes templates and examples to help you build one.
+
+## Who Does What
+
+You write the config: sources, trusted context, capabilities, visible fields,
+proposal fields, and guards. For rich writes, you also write a small handler.
+
+Synapsor Runner serves the MCP tools, stores evidence/proposals/receipts,
+enforces tenant, column, version, and idempotency guards, routes writeback, and
+keeps the replay log. You do not rebuild the safety loop yourself.
+
+## The Writeback Rule
+
+One-row update to an existing row: Runner can do guarded direct writeback.
+Anything else, such as inserting a row, touching two tables, or emitting an
+event: your app-owned executor does it after approval.
+
+## How An External Handler Works
+
+Some changes are too rich for Runner's one-row writeback: insert a credit row,
+touch two tables, or emit an event. For those, you run a small endpoint. The
+flow is:
+
+```text
+agent proposes
+-> human approves outside MCP
+-> Runner POSTs the approved change to your endpoint
+-> your code writes it in its own transaction and returns a receipt
+```
+
+The model never touches this code. You are the last line of defense: Runner
+hands you the tenant, expected row version, and idempotency key, and your
+handler must re-check all three. Skipping those checks reintroduces
+cross-tenant writes, lost updates, or duplicate writes. Start from
+`synapsor-runner handler template ...` instead of hand-rolling the safety checks.
+
+## Deliberate Limits
+
+Runner does not expose raw SQL, write credentials, approval tools, or commit
+tools to the model. Direct Runner writeback does not do generic `INSERT`,
+`DELETE`, `UPSERT`, DDL, or multi-row SQL. Those are app-owned executor jobs.
 
 ```text
 AI agent or MCP client
@@ -70,7 +113,7 @@ Run the guided quick demo first. It does not require Docker, a database, a
 config file, an MCP client, or a Synapsor Cloud account.
 
 ```bash
-npx -y -p @synapsor/runner@alpha synapsor-runner demo --quick
+npx -y -p @synapsor/runner synapsor-runner demo --quick
 ```
 
 In a terminal, it walks through the safety model step by step. In CI, piped
@@ -82,7 +125,7 @@ It does not prove database connectivity. It shows the proposal, evidence, and
 replay flow without giving the runner a database URL.
 
 ```bash
-npx -y -p @synapsor/runner@alpha synapsor-runner demo inspect
+npx -y -p @synapsor/runner synapsor-runner demo inspect
 ```
 
 Human output is concise by default. Use `--details` for reviewer metadata or
@@ -100,14 +143,69 @@ synapsor-runner demo inspect --npx
 Then choose one path:
 
 ```text
-Full disposable proof  -> npx -y -p @synapsor/runner@alpha synapsor-runner demo
+Full disposable proof  -> npx -y -p @synapsor/runner synapsor-runner demo
 Your own staging DB    -> export DATABASE_URL=... then run the inspect command below
-MCP risk review        -> npx -y -p @synapsor/runner@alpha synapsor-runner audit --example dangerous-db-mcp
+MCP risk review        -> npx -y -p @synapsor/runner synapsor-runner audit --example dangerous-db-mcp
+```
+
+For your own database, do this before wiring Claude, Cursor, OpenAI Agents SDK,
+or another MCP client:
+
+```text
+1. Generate the config with start/init/onboard.
+2. Run tools preview to confirm no raw SQL or write credentials are exposed.
+3. Run smoke call against one generated inspect tool.
+4. Only then run up --serve or mcp serve.
 ```
 
 `synapsor-runner` is the public command for this OSS runner. `synapsor` is
 reserved for the Synapsor Cloud CLI.
 
+Authoring reference:
+
+- [Capability Authoring](docs/capability-authoring.md): read/proposal tools,
+  model-facing descriptions, result envelope v2, trusted context, and writeback
+  guards.
+- [Result Envelope v2](docs/result-envelope-v2.md): stable
+  `ok`/`summary`/`data`/`proposal`/`error` MCP tool results.
+- [JSON Schema](schemas/synapsor.runner.schema.json): editor validation for
+  `synapsor.runner.json`.
+
+## Current Alpha Details
+
+These are current alpha requirements, not hidden behavior:
+
+- Writeback with `--config ./synapsor.runner.json` reads the trusted writer
+  connection from the source `write_url_env`, for example
+  `SYNAPSOR_DATABASE_WRITE_URL`. `SYNAPSOR_DATABASE_URL` is only the legacy
+  fallback when you run direct worker/apply flows without a local config.
+- `synapsor-runner mcp serve` is standard stdio MCP for local clients that can
+  launch Runner.
+- `synapsor-runner mcp serve-streamable-http` is standard MCP Streamable HTTP
+  with `initialize` and in-memory session behavior for SDK/client HTTP MCP
+  integrations.
+- OpenAI Agents SDK rejects dotted function/tool names. Use
+  `--alias-mode openai` or `--openai-tool-aliases` for OpenAI-facing MCP
+  transports. Runner exposes aliases such as `billing__inspect_invoice` and
+  keeps the canonical Synapsor capability name in tool metadata.
+- `synapsor-runner mcp serve-http` is a small authenticated JSON-RPC bridge for
+  `tools/list`, `tools/call`, and `resources/read`. Use it only when you want a
+  simple app/server wrapper instead of full HTTP MCP.
+- Direct SQL writeback creates or writes `synapsor_writeback_receipts` for
+  idempotency and replay. The trusted writer needs permission for that table,
+  or an administrator must pre-create it and grant access. Use an app-owned
+  `http_handler` or `command_handler` if Runner should not create receipt
+  tables in your application schema.
+- Run `synapsor-runner doctor --config synapsor.runner.json --check-writeback`
+  after reviewing receipt-table DDL/grants to verify writer connectivity,
+  receipt-table permissions, and rollback-only target-table access. The probe
+  never mutates business rows, but it can create the receipt table if the
+  writer has permission.
+- For app-owned `http_handler` executors, configure `signing_secret_env` to
+  have Runner sign writeback requests with `X-Synapsor-Signature`. Run
+  `synapsor-runner doctor --config synapsor.runner.json --check-handlers` to
+  check handler env vars and network reachability without applying a proposal.
+
 ## Connect Your Own Staging Database
 
 Put a read-only connection string in the environment:
@@ -120,17 +218,160 @@ For disposable dev RDS fixtures only, use `sslmode=no-verify` if your local
 Node/Postgres TLS stack cannot verify the test certificate chain. For real
 staging or production-like databases, keep certificate verification enabled.
 
-Inspect metadata:
+Run the guided own-database path:
 
 ```bash
-npx -y -p @synapsor/runner@alpha synapsor-runner inspect \
-  --engine auto \
+npx -y -p @synapsor/runner synapsor-runner start \
   --from-env DATABASE_URL \
   --schema public
 ```
 
-Generate a reviewed read-only config first. The wizard creates this local
-flow:
+`start --from-env` is the low-friction alias for `onboard db --from-env`. That
+path inspects metadata, helps you choose one table/view, creates trusted
+context bindings, generates semantic MCP tools, validates the tool boundary,
+and prints the exact MCP/UI next commands. It does not require hand-authored
+JSON. If you provide an optional real object id during the wizard, it also
+writes `./.synapsor/smoke-input.json` so the first tool call can use an actual
+row instead of guessed sample data. When the read URL env var and trusted
+tenant/principal env vars are already set, onboarding also attempts that smoke
+call immediately and stores the evidence/query audit in the local ledger. If
+those env vars are missing, it prints the exact command to run after you set
+them from `.env.example`.
+
+The end-to-end shape is:
+
+```text
+1. Put your read-only DB URL in DATABASE_URL.
+2. Run start --from-env DATABASE_URL.
+3. Choose one table/view and the safe fields agents may see.
+4. Preview the generated capabilities.
+5. Serve them over MCP to Claude, Cursor, OpenAI Agents SDK, or your app.
+6. For writes, approve a proposal outside MCP before writeback.
+```
+
+The generated config is just the safety contract. A small reviewed version
+looks like this:
+
+Bring the generated review-mode workspace up with one command:
+
+```bash
+npx -y -p @synapsor/runner synapsor-runner up \
+  --serve \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+```
+
+`up` validates the config/store, summarizes model-facing tools, shows whether
+proposal tools use direct SQL writeback or app-owned executors, checks active
+store leases, and prints the next smoke, approve, apply, replay, UI, and doctor
+commands. By default, `up` is guidance-only. Use `up --serve` to start the
+standard Streamable HTTP MCP server after the checklist; use `--dry-run` to
+rehearse without starting it. For app-owned executor configs, add
+`--with-handler` to run the handler doctor before serving.
+
+For CI, shell scripts, or an LLM driving the setup, use the prompt-free path:
+
+```bash
+npx -y -p @synapsor/runner synapsor-runner onboard db \
+  --from-env DATABASE_URL \
+  --schema public \
+  --table invoices \
+  --mode review \
+  --tenant-column tenant_id \
+  --primary-key id \
+  --conflict-column updated_at \
+  --namespace billing \
+  --object-name invoice \
+  --id-arg invoice_id \
+  --visible-columns id,tenant_id,late_fee_cents,waiver_reason,updated_at \
+  --patch late_fee_cents=fixed:0,waiver_reason=arg:reason \
+  --patch-bounds late_fee_cents=0:5500 \
+  --write-url-env SYNAPSOR_DATABASE_WRITE_URL \
+  --yes
+```
+
+If `--namespace` is omitted, Runner derives a namespace from the table name
+instead of creating `source.*` tools. Use `--read-tool` and `--proposal-tool`
+when you need exact model-facing names.
+
+For app-owned writeback, replace `--write-url-env ...` with
+`--writeback http_handler --handler-url-env APP_WRITEBACK_URL --emit-handler`.
+Runner marks that source as read-only unless you explicitly pass a writer env,
+so `config validate` does not warn that direct SQL writeback is disabled.
+You can also pass `--answers ./answers.json --yes` for a fully declarative
+setup file.
+
+```json
+{
+  "version": 1,
+  "mode": "review",
+  "result_format": 2,
+  "sources": {
+    "app_postgres": {
+      "engine": "postgres",
+      "read_url_env": "DATABASE_URL",
+      "write_url_env": "SYNAPSOR_DATABASE_WRITE_URL"
+    }
+  },
+  "trusted_context": {
+    "provider": "environment",
+    "values": {
+      "tenant_id_env": "SYNAPSOR_TENANT_ID",
+      "principal_env": "SYNAPSOR_PRINCIPAL"
+    }
+  },
+  "capabilities": [
+    {
+      "name": "billing.inspect_invoice",
+      "kind": "read",
+      "source": "app_postgres",
+      "target": {
+        "schema": "public",
+        "table": "invoices",
+        "primary_key": "id",
+        "tenant_key": "tenant_id"
+      },
+      "args": {
+        "invoice_id": { "type": "string", "required": true }
+      },
+      "lookup": { "id_from_arg": "invoice_id" },
+      "visible_columns": ["id", "status", "late_fee_cents", "updated_at"],
+      "evidence": "required",
+      "max_rows": 1
+    },
+    {
+      "name": "billing.propose_late_fee_waiver",
+      "kind": "proposal",
+      "source": "app_postgres",
+      "target": {
+        "schema": "public",
+        "table": "invoices",
+        "primary_key": "id",
+        "tenant_key": "tenant_id"
+      },
+      "args": {
+        "invoice_id": { "type": "string", "required": true },
+        "reason": { "type": "string", "required": true }
+      },
+      "lookup": { "id_from_arg": "invoice_id" },
+      "visible_columns": ["id", "status", "late_fee_cents", "updated_at"],
+      "patch": {
+        "late_fee_cents": { "fixed": 0 },
+        "waiver_reason": { "from_arg": "reason" }
+      },
+      "allowed_columns": ["late_fee_cents", "waiver_reason"],
+      "conflict_guard": { "column": "updated_at" },
+      "approval": { "mode": "human", "required_role": "billing_lead" }
+    }
+  ]
+}
+```
+
+The agent sees `billing.inspect_invoice` and
+`billing.propose_late_fee_waiver`. It does not see the database URL, writer
+credential, raw SQL, approval command, or commit command.
+
+The wizard creates this local flow:
 
 ```text
 trusted context -> capability -> MCP tool
@@ -138,10 +379,11 @@ trusted context -> capability -> MCP tool
 
 It asks which table/view backs the context, which tenant/scope column and
 backend session env vars are trusted, which fields are visible, and what
-semantic capability name to expose.
+semantic capability name to expose. Before writing files, it shows a final
+preview and lets you revise visible fields or capability names.
 
 ```bash
-npx -y -p @synapsor/runner@alpha synapsor-runner init \
+npx -y -p @synapsor/runner synapsor-runner init \
   --wizard \
   --engine auto \
   --from-env DATABASE_URL \
@@ -152,15 +394,26 @@ npx -y -p @synapsor/runner@alpha synapsor-runner init \
 Preview and serve the semantic tools:
 
 ```bash
-npx -y -p @synapsor/runner@alpha synapsor-runner tools preview \
+npx -y -p @synapsor/runner synapsor-runner tools preview \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db
 
-npx -y -p @synapsor/runner@alpha synapsor-runner mcp serve \
+npx -y -p @synapsor/runner synapsor-runner smoke call \
+  <generated.inspect_tool_name> \
+  --input ./.synapsor/smoke-input.json \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db
+
+npx -y -p @synapsor/runner synapsor-runner mcp serve \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db
 ```
 
+`smoke call` uses the same runtime as MCP, records evidence/query audit or a
+proposal in the local store, and prints the evidence/proposal/replay commands
+to inspect what happened. If you skipped the optional smoke input in the
+wizard, pass `--json '{"<lookup_arg>":"<real_id>"}'` instead.
+
 ## Two Ways To Run MCP
 
 Use stdio when the MCP client runs locally and can launch Synapsor Runner. Use
@@ -175,26 +428,70 @@ synapsor-runner mcp serve \
   --store ./.synapsor/local.db
 ```
 
+For OpenAI Agents SDK over stdio, add OpenAI-safe aliases:
+
+```bash
+synapsor-runner mcp serve \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --alias-mode openai
+```
+
 App/server deployments:
 
 ```bash
 export SYNAPSOR_RUNNER_HTTP_TOKEN="dev-local-token"
 
+synapsor-runner mcp serve-streamable-http \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN \
+  --alias-mode openai
+```
+
+You can also start the same review-mode server through the safer startup
+checklist:
+
+```bash
+synapsor-runner up --serve \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN \
+  --alias-mode openai
+```
+
+Equivalent unified command:
+
+```bash
+synapsor-runner mcp serve \
+  --transport streamable-http \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN \
+  --alias-mode openai
+```
+
+Streamable HTTP defaults to `127.0.0.1:8766`, requires bearer auth by default,
+and should use private networking, TLS, and rate limits before being exposed
+beyond a local machine. With `--alias-mode openai`, tools are exposed to
+the model as OpenAI-safe aliases such as `billing__inspect_invoice`; `_meta`
+still includes `synapsor.canonical_tool_name = billing.inspect_invoice`, and
+Runner routes calls back to the canonical Synapsor capability. Use
+`--alias-mode both` during migrations if one client still expects canonical
+dotted names while another needs OpenAI-safe aliases.
+
+Bridge mode:
+
+```bash
 synapsor-runner mcp serve-http \
   --config ./synapsor.runner.json \
   --store ./.synapsor/local.db \
   --auth-token-env SYNAPSOR_RUNNER_HTTP_TOKEN
 ```
 
-HTTP defaults to `127.0.0.1:8765`, requires bearer auth by default, and should
-use private networking, TLS, and rate limits before being exposed beyond a
-local machine.
-
-HTTP alpha scope: `serve-http` is a JSON-RPC endpoint for `tools/list`,
-`tools/call`, and `resources/read`. It is not full MCP Streamable HTTP and does
-not implement `initialize`/SSE. If an SDK HTTP MCP client expects that
-handshake, use stdio mode or wrap the HTTP endpoint like the OpenAI HTTP
-example.
+Bridge HTTP defaults to `127.0.0.1:8765` and supports only JSON-RPC
+`tools/list`, `tools/call`, and `resources/read`. It does not implement MCP
+Streamable HTTP `initialize`/session behavior.
 
 OpenAI Agents SDK examples:
 
@@ -214,6 +511,15 @@ Before asking an agent to solve a real task, confirm it can call a Runner tool:
 synapsor-runner tools preview --config ./synapsor.runner.json --store ./.synapsor/local.db
 ```
 
+For OpenAI-facing clients:
+
+```bash
+synapsor-runner tools preview \
+  --config ./synapsor.runner.json \
+  --store ./.synapsor/local.db \
+  --alias-mode openai
+```
+
 Then ask the agent:
 
 ```text
@@ -236,12 +542,25 @@ The disposable reference app includes proposal-first write examples for:
 Each tool creates evidence, a before/after diff, and a proposal. The source
 database remains unchanged until approval outside MCP and guarded writeback.
 
-For a longer local session, you can install the alpha package explicitly:
+For a longer local session, you can install the package globally:
 
 ```bash
-npm install -g @synapsor/runner@alpha
+npm install -g @synapsor/runner
 ```
 
+## Stable Compatibility Promise
+
+Starting with `0.1.0`, Synapsor Runner keeps the documented `synapsor-runner`
+binary, `synapsor.runner.json` schema version `1`, result envelope v2, stdio
+MCP, Streamable HTTP MCP, MCP client snippets, proposal/approval/writeback
+inspection commands, direct SQL writeback contract, and app-owned executor
+contract compatible through the `0.1.x` line unless a release note marks a
+deprecation first.
+
+Stable does not mean production SLA, hosted Cloud features, compliance
+certification, physical Postgres/MySQL branching, generic SQL writeback, or
+support for undocumented local SQLite internals.
+
 ## Runtime Flow
 
 The local runner keeps the model-facing tool call separate from approval and
@@ -326,6 +645,8 @@ relying on `latest`:
 
 ```bash
 synapsor-runner activity search --tenant acme --object invoice:INV-3001
+synapsor-runner events tail --store ./.synapsor/local.db
+synapsor-runner events webhook --url http://127.0.0.1:8788/synapsor/events --kind proposal_created --store ./.synapsor/local.db
 synapsor-runner proposals list --tenant acme --object invoice:INV-3001 --status approved
 synapsor-runner evidence show ev_...
 synapsor-runner query-audit list --evidence ev_...
@@ -351,16 +672,24 @@ Create a redacted local diagnostic report:
 
 ```bash
 synapsor-runner doctor --config synapsor.runner.json --report --redact --output synapsor-doctor.md
+synapsor-runner doctor --config synapsor.runner.json --check-writeback
 ```
 
 Inspect or compact the local ledger:
 
 ```bash
 synapsor-runner store stats --store ./.synapsor/local.db
+synapsor-runner events tail --store ./.synapsor/local.db --follow
+synapsor-runner events webhook --url-env SYNAPSOR_EVENT_WEBHOOK_URL --auth-token-env SYNAPSOR_EVENT_WEBHOOK_TOKEN --follow --store ./.synapsor/local.db
 synapsor-runner store vacuum --store ./.synapsor/local.db
 synapsor-runner store prune --store ./.synapsor/local.db --older-than 30d --dry-run
+synapsor-runner store reset --store ./.synapsor/local.db --yes
 ```
 
+`events webhook` is a local/dev/staging convenience for review UIs, Slack
+bridges, or app-local notifications. It POSTs one redacted local event envelope
+per lifecycle event; it is not a hosted central ledger.
+
 This is local indexed search for local/dev/staging usage. It is not external
 database time travel, not cross-runner search, and not hosted compliance
 retention.
@@ -372,6 +701,24 @@ your application service already owns business writes, configure an
 `http_handler` or `command_handler` executor. Approval still happens outside
 MCP, and the handler returns an applied/conflict/failed receipt for replay.
 
+> **Important:** your app handler owns the final business write. Runner creates
+> the proposal and calls your handler only after approval, but your handler must
+> still enforce tenant/scope checks, expected-version or conflict guards,
+> idempotency keys, allowed business actions, transaction/rollback, and safe
+> error receipts. If you skip those checks, you can reintroduce cross-tenant
+> writes, lost updates, or duplicate writes. Keep handler credentials out of MCP.
+
+Starter handlers are included under `examples/app-owned-writeback`.
+The packaged app-owned billing example also includes a bundled
+`synapsor-handler.mjs` helper shim. There is no separate handler package to
+install.
+You can also generate a starter handler directly:
+
+```bash
+npx -y -p @synapsor/runner synapsor-runner handler template node-fastify \
+  --output ./synapsor-writeback-handler.mjs
+```
+
 For direct SQL writeback, set the writer env var named by the source
 `write_url_env`, for example `SYNAPSOR_DATABASE_WRITE_URL`. Runner also creates
 or writes `synapsor_writeback_receipts` for idempotency/replay, so the writer
@@ -391,4 +738,4 @@ Synapsor DBMS, not a physical branch engine for Postgres/MySQL, and not a
 general MCP security platform.
 
 See the full repository README and docs for Docker demos, MCP client setup,
-configuration recipes, and security boundaries.
+configuration recipes, security boundaries, and release notes.

package/dist/cli.d.ts

@@ -1,4 +1,5 @@
 #!/usr/bin/env node
+import { type DbRowReader } from "@synapsor-runner/mcp-server";
 import { type WritebackJob } from "@synapsor-runner/protocol";
 import { type SchemaInspection } from "@synapsor-runner/schema-inspector";
 export declare function main(argv: string[]): Promise<number>;
@@ -7,6 +8,7 @@ export declare function runInitWizard(args: string[], options?: {
     ask?: WizardAsk;
     env?: NodeJS.ProcessEnv;
     inspection?: SchemaInspection;
+    readRow?: DbRowReader;
     stdout?: Pick<NodeJS.WriteStream, "write">;
 }): Promise<number>;
 export declare function resolveSqlWriteDatabaseUrl(job: WritebackJob, configPath: string, env: NodeJS.ProcessEnv): Promise<string>;

package/dist/cli.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";AA8BA,OAAO,EAA6G,KAAK,YAAY,EAAwB,MAAM,2BAA2B,CAAC;AAC/L,OAAO,EAOL,KAAK,gBAAgB,EAEtB,MAAM,mCAAmC,CAAC;AA4H3C,wBAAsB,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,MAAM,CAAC,CA8C1D;AA0DD,KAAK,SAAS,GAAG,CAAC,QAAQ,EAAE,MAAM,EAAE,YAAY,CAAC,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC,CAAC;AAE9E,wBAAsB,aAAa,CACjC,IAAI,EAAE,MAAM,EAAE,EACd,OAAO,GAAE;IACP,GAAG,CAAC,EAAE,SAAS,CAAC;IAChB,GAAG,CAAC,EAAE,MAAM,CAAC,UAAU,CAAC;IACxB,UAAU,CAAC,EAAE,gBAAgB,CAAC;IAC9B,MAAM,CAAC,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;CACvC,GACL,OAAO,CAAC,MAAM,CAAC,CAiLjB;AAsyCD,wBAAsB,0BAA0B,CAAC,GAAG,EAAE,YAAY,EAAE,UAAU,EAAE,MAAM,EAAE,GAAG,EAAE,MAAM,CAAC,UAAU,GAAG,OAAO,CAAC,MAAM,CAAC,CAM/H"}
+{"version":3,"file":"cli.d.ts","sourceRoot":"","sources":["../src/cli.ts"],"names":[],"mappings":";AAYA,OAAO,EAAqG,KAAK,WAAW,EAA2F,MAAM,6BAA6B,CAAC;AAmB3P,OAAO,EAA6G,KAAK,YAAY,EAAwB,MAAM,2BAA2B,CAAC;AAC/L,OAAO,EAOL,KAAK,gBAAgB,EAEtB,MAAM,mCAAmC,CAAC;AA4U3C,wBAAsB,IAAI,CAAC,IAAI,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,MAAM,CAAC,CAmD1D;AA+DD,KAAK,SAAS,GAAG,CAAC,QAAQ,EAAE,MAAM,EAAE,YAAY,CAAC,EAAE,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC,CAAC;AAE9E,wBAAsB,aAAa,CACjC,IAAI,EAAE,MAAM,EAAE,EACd,OAAO,GAAE;IACP,GAAG,CAAC,EAAE,SAAS,CAAC;IAChB,GAAG,CAAC,EAAE,MAAM,CAAC,UAAU,CAAC;IACxB,UAAU,CAAC,EAAE,gBAAgB,CAAC;IAC9B,OAAO,CAAC,EAAE,WAAW,CAAC;IACtB,MAAM,CAAC,EAAE,IAAI,CAAC,MAAM,CAAC,WAAW,EAAE,OAAO,CAAC,CAAC;CACvC,GACL,OAAO,CAAC,MAAM,CAAC,CA2TjB;AAo7DD,wBAAsB,0BAA0B,CAAC,GAAG,EAAE,YAAY,EAAE,UAAU,EAAE,MAAM,EAAE,GAAG,EAAE,MAAM,CAAC,UAAU,GAAG,OAAO,CAAC,MAAM,CAAC,CAM/H"}