kici-admin: runs, execution & events

Guide

runs — execution run inspection

kici-admin runs list [--status <csv>] [--workflow-name <name>] [--repo <ownerRepo>] [--since <iso>] [--count] [--limit <n>] [--offset <n>] [--json]
kici-admin runs show <runId> [--json]
kici-admin runs structured <runId> [--json]
kici-admin runs jobs <runId> [--include-steps] [--json]
kici-admin runs ephemeral-key <runId> [--json]
kici-admin runs secret-outputs <runId> [--output-key <k>] [--reveal] [--json]
kici-admin runs logs <runId> --job <jobId> [--step <n>] [--limit <n>] [--cursor <c>] [--json]

Inspects execution runs, jobs, ephemeral keys, and secret outputs. Every <runId> takes a full run id or its first characters (at least 4), like a git short SHA: kici-admin runs show 709c899a finds the one run whose id starts with 709c899a. A prefix that matches several runs fails and lists them, so type more characters. A prefix that matches none, or text that cannot start a run id, fails and says so. An orchestrator older than kici-admin cannot look up a prefix, so kici-admin asks for the full run id. runs list shows full run ids. The admin API answers a run id that is not a full UUID with a 400 that names it. It filters the run list by prefix with ?runIdPrefix=. Useful for investigating run status and failures — and, with secret-outputs --reveal, for recovering a job’s output values during incident response — without direct database access.

Shows run header (status, repo, ref, SHA, provider, timing, context, trust tier), jobs table, and steps per job. Internally composes two admin API calls: GET /admin/runs/:runId (run header) + GET /admin/runs/:runId/jobs?includeSteps=true.

The header shows the run’s org on an Org: line, after Provider:. The run uses the contexts, secrets and trust policy of that org. After the jobs table, a ! <job>: <warning> line names a job that runs without some of its environment. An example is a bound context that does not exist in the run’s org while another org on the orchestrator has it. See which org a source belongs to. --json carries the same values as run.orgId and each job’s envWarning. An older orchestrator sends neither, and the lines do not show.

For an organization-wide workflow — one defined in another repository and fired by an event from this one — the header also shows where the workflow comes from. Defined in: names the repository that defines the workflow, Workflow SHA: the commit of that repository the run dispatched, and Workflow branch: its registered branch. A run of a repository’s own workflow shows none of these lines. --json carries the same values as workflowRepoIdentifier, workflowSha, and workflowBranch, each null on a run of a repository’s own workflow.

A run can span several workflows. kici run remote <fixture> gives each matched workflow its own run, but a kici older than 0.21.0 gets one shared run for all of them, when their job names cannot collide. Such a run shows a Workflows: line with every workflow name in place of the Workflow: line. The jobs table has a workflow column, and each step heading and the failure summary name the job as <workflow> / <job>, because two workflows can each define a job of the same name. runs list shows the run’s first workflow and a count of the others (hello-world +3), and --workflow-name matches a run that spans the named workflow. In --json, the run carries workflowNames (every workflow, the first one first) next to workflowName (the first one), and each job carries workflowName. A job row written by an earlier orchestrator version records no workflow. It shows - on a fixture run, and the run’s workflow on any other run.

Steps are listed in the order they ran. A job’s image build comes first, then its init commands, then its steps. The # column shows a step’s index, and an init command as init[<n>], where <n> is its position in the job’s init list. runs jobs --include-steps and runs structured list steps the same way. In the --json output of runs show, runs jobs --include-steps and runs structured, stepIndex is the stored index, which for an init command is a large internal number. Each step also carries phase (setup, init or steps), and an init command carries initIndex, its position in the list. An older orchestrator does not send phase and initIndex in runs structured.

An older orchestrator recorded init commands with no step type. Those steps are listed, labeled and reported the same way, from their stored index and their init:<n> step name. In --json, their stepType stays step.

Shows the machine-first, provenance-tagged structured run result — the same shape an automation agent reads over the admin API (GET /admin/runs/:runId/structured). Trusted fields (run/job/step ids, enum statuses, exit codes, durations, hashes, the derived failure category) are plain; untrusted fields (workflow / repo / job / step names, refs, error text, job output values) are wrapped in an { untrusted: true, value } envelope so a consumer can keep user-controlled content out of an instruction channel. Secret output values are never returned — only their key names. The human view unwraps envelopes for display; --json is lossless. See Agent run-result API for the full contract.

Lists the execution jobs for a single run. Cheaper than runs show when you only need job-level state (e.g., for polling). Each job row carries its resolved upstream dependency edges in needs (an array of { upstreamName, runOn }, where runOn is the per-edge set of upstream terminal statuses that satisfy the edge, or null when the job has no upstreams) — the same dependency structure the dashboard run-detail graph view renders.

Answers the security-relevant question “did the per-run ephemeral key get scrubbed?” without psql. Returns { exists, createdAt }; the key material itself is never exposed on the wire, regardless of role.

Lists the secret outputs produced by a run’s jobs. Values are masked by default — the row set shows jobId, outputKey, createdAt, and nothing that could reconstruct the secret. --reveal is the break-glass path for incident response only: it is always audited, requires the stricter secret.reveal permission, and fails with HTTP 503 if the orchestrator was started without a master key (e.g., no KICI_SECRET_KEY).

Prints a page of one step’s log lines. It reads the orchestrator admin route rather than the dashboard plane, and that is what lets it serve the pre-run evaluation round of an organization-wide workflow: such a round writes no execution run of its own, so neither the dashboard nor kici runs logs can address it, and this command is the only path to its output — including anything the workflow’s filter printed. --step defaults to 0, which is the evaluation itself. --limit defaults to 500 and the server caps it at 2000; a truncated page returns a cursor to pass back as --cursor.

An evaluation round has no run entry, so its two ids come from the dispatch queue instead:

# 1. The round's workflow name is `__globaleval__<owner>/<repo>` of the repo the
#    workflow was authored in. In the JSON rows, `id` is the job id and `run_id`
#    is the run id — use `--json`, because the plain table abbreviates both to
#    their first eight characters.
kici-admin queue list --workflow-name '__globaleval__myorg/ci-pipelines' --limit 5 --json

# 2. Step 0 is the evaluation itself.
kici-admin runs logs <run_id> --job <id>

Run this recipe with an owner or admin token — an auditor token cannot complete it. The two steps sit on different permissions: step 1 reads the dispatch queue, which requires secret.read, so an auditor is refused with a 403 and never reaches step 2. Only step 2 falls under the run.read grant described next. (An operator with database access can take step 1 offline instead, via kici-admin queue list --database-url <url>, which bypasses the admin API and its role check entirely.)

--step 'init[<n>]' prints the log of the init command that runs show labels init[<n>]. Quote the value, because some shells (zsh) read the brackets as a file pattern.

--step=-1 prints a job’s setup log. It holds the clone, the .kici/ dependency install, and the workflow module load, plus a container job’s host-side checkout and dependency install.

When a step has no lines, a note on stderr says which case applies. For --step=-1 the note reads (no setup log recorded for this job) or (the setup log for this job is empty); any other step gets the same pair, naming its index. Standard output stays empty, so it remains pipeable. --json prints the response as-is, and its recorded field carries the same answer.

RBAC tokens for these commands: run.read is enough for list, show, jobs, ephemeral-key, logs, and masked secret-outputs (all three roles — owner, admin, auditor — carry it). secret-outputs --reveal additionally requires secret.reveal, which only owner + admin roles hold — auditor tokens get 403. Successful reveals land in secret_audit_log with action = secret-outputs.reveal, run_id, user_id, role, and a metadata JSON object summarising the revealed / failed output keys.

execution — execution read + maintenance

kici-admin execution list [--routing-key <k>] [--status <s>] [--workflow-name <n>] [--limit <n>] [--database-url <url>] [--json]
kici-admin execution show <runId> [--database-url <url>] [--json]
kici-admin execution purge-stale --routing-key <key> --confirm
kici-admin execution purge-stale --routing-key <key> --confirm --database-url $URL

• list / show are read-only inspection verbs over execution_runs / execution_jobs (dual-mode). Over the admin API, show takes a run id prefix like runs show. With --database-url it needs the full run id.
• purge-stale deletes execution_runs + execution_jobs whose routing_key differs from the current cluster (or is NULL). Used by redeploy workflows that move a cluster to a new routing_key — leftover rows from the previous key would otherwise violate FK constraints on restart.

check-run — check-run tracking reads

kici-admin check-run list --sha <sha> [--check-name <name>] [--limit <n>] [--database-url <url>] [--json]

• Read-only. Answers “did we post that check run?” for a commit, without reaching into the database by hand.
• Each row is one check run the orchestrator recorded for the commit, and each column answers a different half of the question:
  • CHECK_RUN_ID — the id the provider returned at create time, when the check run was still queued. It answers “did we create it?” and nothing more.
  • CREATE_STATE — pending from just before the create call until it returns. Nothing resets it on failure, so a row left on pending means the create never returned an id: still in flight, or permanently failed. It distinguishes an in-flight create from a missing one; it does not prove the create succeeded.
  • TERMINAL_SENT — when the terminal completed update was accepted by the provider. This is the column that answers “did we complete it?”.
  • IN_PROGRESS_SENT_AT — written only for per-job check names (kici/<workflow>/job/<job>). The workflow-level kici/<workflow> row always shows an em dash here.
• Every write on this table is best-effort, so an em dash (—) means “no record”, never proof that the call failed. If the database is unreachable the orchestrator falls back to an in-memory copy and keeps reporting to the provider, so a check run can exist at the provider with nothing recorded here.
• Direct-DB only — pass --database-url or set KICI_DATABASE_URL. There is no HTTP form of this command.

# Did we post the workflow-level check run for this commit?
kici-admin check-run list --sha 4f2c1ab --check-name kici/e2e-test --database-url $URL

A check run that GitHub still shows as queued reads as: TERMINAL_SENT set means we sent the terminal update and the provider is lagging or dropped it; TERMINAL_SENT empty with the run itself finished means the terminal update never left the orchestrator.

queue — dispatch queue read + maintenance

kici-admin queue list [--status <s>] [--status-not-in <csv>] [--job-name <name>] [--job-name-prefix <p>] [--job-name-not-like <pattern>] [--workflow-name <n>] [--created-after <iso>] [--limit <n>] [--database-url <url>] [--json]
kici-admin queue show <id> [--database-url <url>] [--json]
kici-admin queue clear --confirm [--yes]                       # TRUNCATE dispatch_queue
kici-admin queue clear --confirm --database-url $URL --yes     # Offline mode (orchestrator down)

• list / show are read-only inspection verbs (dual-mode: HTTP or direct DB via --database-url). Handy for investigating stuck dispatch state without psql.
• clear truncates dispatch_queue — stale pending jobs can linger after a crash or upgrade, and clear wipes the table so the next boot starts clean. HTTP mode is preferred when the orchestrator is up; direct-DB mode (via --database-url) is the legitimate path for warm-start cleanup before restart.

registration — workflow registration management

kici-admin registration list [--org <id>] [--routing-key <k>] [--repo <ident>] [--trigger-type <type>] [--limit <n>] [--database-url <url>] [--json]
kici-admin registration show <id> [--database-url <url>] [--json]
kici-admin registration disable <id> [--json]
kici-admin registration enable <id> [--json]
kici-admin registration delete <id> [--yes] [--json]

Reads and changes rows in workflow_registrations. Distinct from workflow list (which inspects workflow-code) — registration is the registered-workflow-instance row. list and show are dual-mode (HTTP via /api/v1/admin/registrations or direct DB).

• list returns { registrations, registryVersion }; filter by customer, routing key, repo identifier, or trigger type.
• show <id> prints the single row plus its registry_version.
• disable <id> keeps the registration but stops its triggers from dispatching. enable <id> turns it back on. Both call PATCH /api/v1/admin/registrations/:id/disable with { "disabled": true | false }.
• delete <id> removes the registration. It asks for confirmation unless --yes is passed.
• disable, enable and delete are HTTP only, and are the operator path for the dashboard’s registration.disable and registration.delete writes in the dashboard-write policy. Each one bumps the registry version, so every peer reloads its registrations, and prints the new registry_version. A token scoped to one routing key can act only on registrations under that key. An unknown id exits non-zero with HTTP 404.

workflow — workflow registration inspection

kici-admin workflow list [--org <orgId>] [--routing-key <key>] [--repo <ownerRepo>] [--trigger-type <type>] [--event <eventName>] [--json]
kici-admin workflow register-manual --lock-file <path> --repo <ident> --routing-key <key> --org <id> [--provider-context <json>] [--commit-sha <sha>] [--database-url <url>] [--json]

list inspects workflow registrations from the workflow_registrations table. All filters are optional and combinable. The schema column shows the compile schema each lock declares, marked (stale) when the agents of the orchestrator’s release implement another one. When any row is stale, a Warning: line follows the table. With --json, each row carries compileSchemaVersion (the lock’s) and agentCompileSchemaVersion (the agents’). See compile schema mismatch.

register-manual seeds workflow_registrations rows straight from a compiled lock file — used by local-only / non-Git deployments and by test setups that can’t rely on a webhook-driven compile-and-register flow. Dual-mode (HTTP via admin API, or direct DB via --database-url). Both modes upsert: the command adds or updates the workflows the lock file names and never removes another registration of the repository. To remove one, use kici-admin registration delete <id>. For each registered workflow whose lock declares a compile schema the agents do not implement, the command prints a Warning: line on stderr, and --json output carries a warnings array. In direct-DB mode the CLI compares with the compile schema of its own release.

event — internal events

kici-admin event emit <name> --payload-file <path> [--source-routing-key <k>] [--source-repo <r>] [--database-url <url>] [--json]
kici-admin event list [--name <eventName>] [--outcome <outcome>] [--since <iso>] [--before <cursor>] [--limit <n>] [--json]
kici-admin event show <eventId> [--json]

Inserts a row into kici_events and fires pg_notify('kici_event_channel', <id>) so the orchestrator’s EventRouter picks it up immediately. It does what an agent’s ctx.emit() does from within a step execution. Dual-mode: HTTP (POST /api/v1/admin/events/emit) or direct DB via emitKiciEventDirect from @kici-dev/shared.

• <name> is the event name (e.g. deploy.completed).
• --payload-file is required and must contain a JSON object (not an array).
• --source-routing-key / --source-repo are optional hints for cross-repo event matching.

list shows internal events newest first, with each event’s dispatch state (pending, leased, retrying, processed or dlq) and its match outcome: matched, or the reason no workflow ran (no-registration, no-target-repo, trust-blocked, no-trigger-match, buffered). show adds the runs the event dispatched and, for a role holding event_log.read_payload, the payload. It replaces the claimCode of an event-scaler scale-up with [redacted]. Both commands are HTTP-only and need the event_dlq.read permission. A token scoped to one routing key sees only the events emitted under that key. The event scaler’s kici.scaler.* events have no source routing key, so a scoped token does not see them.

event-dlq — event dead-letter queue triage

kici-admin event-dlq list [--limit <n>] [--before <iso>] [--json]
kici-admin event-dlq count
kici-admin event-dlq retry <id>
kici-admin event-dlq discard <id>

Operator triage surface for at-least-once event delivery. When an event lands in the DLQ it usually means a workflow handler is consistently failing and should be fixed at its root cause; this CLI is the path to inspect last_error, retry once a fix is deployed, or discard if the event is no longer relevant.

• list shows DLQ events most-recent-first with id, event name, reason, attempts, source repo / routing key, and a truncated last_error. --before <iso> paginates via the dlq_at cursor (echoed as Next page: --before "<ts>"); --limit caps rows (default 50, max 200). With --json, each row carries the event payload for a role holding event_log.read_payload (for the auditor role it is null). The claimCode of an event-scaler scale-up is replaced with [redacted], here and in the dashboard.
• count prints the total number of events currently in the DLQ — handy for monitoring / alerting.
• retry <id> clears the DLQ flag, resets the attempts counter, and pg_notifys the EventRouter to schedule the event for immediate retry.
• discard <id> permanently deletes the row.

Reference

kici-admin check-run

Check-run tracking reads (read-only)

Synopsis: kici-admin check-run

kici-admin check-run list

List the check runs the orchestrator recorded for a commit

Synopsis: kici-admin check-run list [options]

Options

Option	Default	Description
--sha <sha>		Commit SHA to look up
--check-name <name>		Filter by check name (e.g. kici/e2e-test)
--limit <n>		Max rows to return (default 50, max 1000)
--database-url <url>		Orchestrator DB URL (else KICI_DATABASE_URL)
--json		Emit JSON output

kici-admin event

Internal events (kici_events): emit, list, show

Synopsis: kici-admin event

kici-admin event emit

INSERT a row into kici_events and fire pg_notify — manually emit an internal event (mirrors agent ctx.emit())

Synopsis: kici-admin event emit <name> [options]

Arguments

Argument	Required	Variadic	Description
name	yes	no

Options

Option	Default	Description
--payload-file <path>		Path to JSON file whose contents become the event payload
--source-routing-key <k>		Source routing key for cross-repo event matching (default: empty)
--source-repo <r>		Source repo identifier for cross-repo matching (default: empty)
--database-url <url>		Use direct DB access instead of HTTP (offline mode)
--json	false	Emit JSON output { eventId } on stdout

kici-admin event list

List internal events, newest first, with each event’s state and match outcome (admin API: /api/v1/admin/events)

Synopsis: kici-admin event list [options]

Options

Option	Default	Description
--name <eventName>		Filter by event name (e.g. kici.scaler.scale-up)
--outcome <outcome>		Filter by match outcome (matched|buffered|no-registration|no-target-repo|trust-blocked|no-trigger-match)
--since <iso>		Only events created at or after this ISO timestamp
--before <cursor>		Only events after this cursor: the next-page cursor (an event id) or an ISO timestamp
--limit <n>		Max results (default 50, max 200)
--json		Emit raw JSON instead of a table

kici-admin event show

Show one internal event: its state, match outcome, payload (claim codes redacted) and the runs it dispatched

Synopsis: kici-admin event show <eventId> [options]

Arguments

Argument	Required	Variadic	Description
eventId	yes	no

Options

Option	Default	Description
--json		Emit raw JSON instead of formatted output

kici-admin event-dlq

Inspect / retry / discard events in the DLQ (at-least-once delivery)

Synopsis: kici-admin event-dlq

kici-admin event-dlq count

Print the total number of events in the DLQ

Synopsis: kici-admin event-dlq count

kici-admin event-dlq discard

Permanently delete an event from the DLQ

Synopsis: kici-admin event-dlq discard <id>

Arguments

Argument	Required	Variadic	Description
id	yes	no

kici-admin event-dlq list

List events currently in the DLQ (most recent first)

Synopsis: kici-admin event-dlq list [options]

Options

Option	Default	Description
--limit <n>	50	Max rows (max 200)
--before <iso>		Cursor: list events with dlq_at < this ISO timestamp
--json	false	Print raw JSON instead of a formatted table

kici-admin event-dlq retry

Clear the DLQ flag, reset attempts, and schedule the event for immediate retry

Synopsis: kici-admin event-dlq retry <id>

Arguments

Argument	Required	Variadic	Description
id	yes	no

kici-admin execution

Execution data maintenance

Synopsis: kici-admin execution

kici-admin execution list

List execution_runs (read-only)

Synopsis: kici-admin execution list [options]

Options

Option	Default	Description
--routing-key <k>		Filter by routing_key
--status <s>		Filter by status
--workflow-name <n>		Filter by workflow_name
--limit <n>		Max rows to return (default 100, max 1000)
--database-url <url>		Use direct DB access instead of HTTP (offline mode)
--json		Emit JSON output

kici-admin execution purge-stale

DELETE execution_runs/jobs whose routing_key differs from the current cluster

Synopsis: kici-admin execution purge-stale [options]

Options

Option	Default	Description
--database-url <url>		Use direct DB access instead of HTTP (offline mode)
--routing-key <key>		Current routing key to preserve
--confirm		Explicit confirmation flag

kici-admin execution show

Show one run + its jobs (by run_id, or its first 4+ characters)

Synopsis: kici-admin execution show <runId> [options]

Arguments

Argument	Required	Variadic	Description
runId	yes	no

Options

Option	Default	Description
--database-url <url>		Use direct DB access instead of HTTP (offline mode)
--json		Emit JSON output

kici-admin queue

Dispatch queue maintenance

Synopsis: kici-admin queue

kici-admin queue clear

TRUNCATE the dispatch_queue table (destructive)

Synopsis: kici-admin queue clear [options]

Options

Option	Default	Description
--database-url <url>		Use direct DB access instead of HTTP (offline mode)
--confirm		Explicit confirmation flag
--yes		Skip interactive confirmation prompt (for scripted use)

kici-admin queue list

List dispatch_queue entries (read-only)

Synopsis: kici-admin queue list [options]

Options

Option	Default	Description
--status <s>		Filter by exact status (pending|dispatched|…)
--status-not-in <csv>		Filter status NOT IN (CSV; e.g. “completed,failed,expired”)
--job-name-prefix <p>		Filter by job_name prefix
--job-name <name>		Filter by exact job_name match
--job-name-not-like <pattern>		Exclude job_name LIKE pattern (e.g. “build%“)
--workflow-name <n>		Filter by exact workflow_name
--created-after <iso>		Filter created_at >
--limit <n>		Max rows to return (default 100, max 1000)
--database-url <url>		Use direct DB access instead of HTTP (offline mode)
--json		Emit JSON output

kici-admin queue show

Show a single dispatch_queue row by id

Synopsis: kici-admin queue show <id> [options]

Arguments

Argument	Required	Variadic	Description
id	yes	no

Options

Option	Default	Description
--database-url <url>		Use direct DB access instead of HTTP (offline mode)
--json		Emit JSON output

kici-admin registration

Registered workflow instances (workflow_registrations table)

Synopsis: kici-admin registration

kici-admin registration delete

Delete a workflow registration by id

Synopsis: kici-admin registration delete <id> [options]

Arguments

Argument	Required	Variadic	Description
id	yes	no

Options

Option	Default	Description
--yes		Skip confirmation prompt
--json		Emit JSON output

kici-admin registration disable

Disable a workflow registration: it stays registered, but its triggers stop dispatching

Synopsis: kici-admin registration disable <id> [options]

Arguments

Argument	Required	Variadic	Description
id	yes	no

Options

Option	Default	Description
--json		Emit JSON output

kici-admin registration enable

Re-enable a disabled workflow registration

Synopsis: kici-admin registration enable <id> [options]

Arguments

Argument	Required	Variadic	Description
id	yes	no

Options

Option	Default	Description
--json		Emit JSON output

kici-admin registration list

List workflow_registrations rows (also returns registry_version)

Synopsis: kici-admin registration list [options]

Options

Option	Default	Description
--org <id>		Filter by customer_id
--routing-key <k>		Filter by routing_key
--repo <ident>		Filter by repo_identifier
--trigger-type <type>		Filter by trigger type (in trigger_types[])
--limit <n>		Max rows (default 100, max 1000)
--database-url <url>		Use direct DB access instead of HTTP (offline mode)
--json		Emit JSON output

kici-admin registration show

Show a single workflow_registrations row by id

Synopsis: kici-admin registration show <id> [options]

Arguments

Argument	Required	Variadic	Description
id	yes	no

Options

Option	Default	Description
--database-url <url>		Use direct DB access instead of HTTP (offline mode)
--json		Emit JSON output

kici-admin runs

Inspect execution runs, jobs, and steps

Synopsis: kici-admin runs

kici-admin runs ephemeral-key

Show whether the run-ephemeral key has been scrubbed yet

Synopsis: kici-admin runs ephemeral-key <runId> [options]

Arguments

Argument	Required	Variadic	Description
runId	yes	no	Run id, or its first 4 or more characters

Options

Option	Default	Description
--json		Emit raw JSON instead of plain text

kici-admin runs jobs

List jobs for a run (admin API: /api/v1/admin/runs/:runId/jobs)

Synopsis: kici-admin runs jobs <runId> [options]

Arguments

Argument	Required	Variadic	Description
runId	yes	no	Run id, or its first 4 or more characters

Options

Option	Default	Description
--include-steps		Embed step list inside each job (default false)
--json		Emit raw JSON instead of a table

kici-admin runs list

List execution runs (admin API: /api/v1/admin/runs)

Synopsis: kici-admin runs list [options]

Options

Option	Default	Description
--status <statuses>		Filter by run status. Accepts a single value or a comma-separated list (e.g. success,failed)
--workflow-name <name>		Filter by workflow name. A run that spans several workflows matches any of them
--repo <ownerRepo>		Filter by repo identifier (owner/repo)
--since <iso8601>		Only include runs with created_at strictly later than this ISO-8601 timestamp
--count		Return only the count of matching runs, skipping the row listing
--limit <n>	20	Max results (max 100)
--offset <n>	0	Skip first N results
--json		Emit raw JSON instead of a table

kici-admin runs logs

Print a page of a step log (admin API: /api/v1/admin/runs/:runId/jobs/:jobId/steps/:i/logs)

Synopsis: kici-admin runs logs <runId> [options]

Arguments

Argument	Required	Variadic	Description
runId	yes	no	Run id, or its first 4 or more characters

Options

Option	Default	Description
--job <jobId>		Job id (the dispatch_queue row id for an eval round)
--step <n>	0	Step index (-1 is the job setup log), or an init step as init[]
--limit <n>	500	Max lines to return (server caps at 2000)
--cursor <c>		Line-offset cursor from a previous page
--json		Emit raw JSON instead of plain lines

kici-admin runs secret-outputs

List per-job secret outputs (masked by default; —reveal decrypts and audits)

Synopsis: kici-admin runs secret-outputs <runId> [options]

Arguments

Argument	Required	Variadic	Description
runId	yes	no	Run id, or its first 4 or more characters

Options

Option	Default	Description
--output-key <key>		Filter to a single output_key
--reveal		Decrypt and print plaintext values. Audited with actor=secret-outputs.reveal; requires secret.reveal permission
--json		Emit raw JSON instead of a table

kici-admin runs show

Show run detail with jobs and steps

Synopsis: kici-admin runs show <runId> [options]

Arguments

Argument	Required	Variadic	Description
runId	yes	no	Run id, or its first 4 or more characters

Options

Option	Default	Description
--json		Emit raw JSON instead of formatted output

kici-admin runs structured

Show the provenance-tagged structured run result (agent read path; /structured)

Synopsis: kici-admin runs structured <runId> [options]

Arguments

Argument	Required	Variadic	Description
runId	yes	no	Run id, or its first 4 or more characters

Options

Option	Default	Description
--json		Emit the raw AgentRunResult (untrusted envelopes preserved)

kici-admin workflow

Inspect workflow registrations

Synopsis: kici-admin workflow

kici-admin workflow list

List workflow registrations (admin API: /api/v1/admin/registrations)

Synopsis: kici-admin workflow list [options]

Options

Option	Default	Description
--org <orgId>		Filter by customer/org id (server param: customerId)
--routing-key <key>		Filter by routing key, e.g. github:42
--repo <ownerRepo>		Filter by repo identifier (owner/repo)
--trigger-type <type>		Filter by trigger type, e.g. webhook, push, schedule
--event <eventName>		Filter by webhook event name (scans lock_entry.triggers)
--json		Emit raw JSON instead of a table

kici-admin workflow register-manual

Upsert workflow_registrations rows from a lock file and bump registry_versions. Transactional. Never removes a registration the lock file does not name (use registration delete). Seeds workflow registrations without a real push event.

Synopsis: kici-admin workflow register-manual [options]

Options

Option	Default	Description
--lock-file <path>		Path to a kici.lock.json file
--repo <ident>		repo_identifier value (e.g. “owner/repo”)
--routing-key <key>		Routing key for the source (e.g. “github:42”)
--org <id>		Org id to attribute rows to
--provider-context <json>	{}	Provider-specific context as a JSON object
--commit-sha <sha>		Optional commit SHA stamped on each row
--database-url <url>		Use direct DB access instead of HTTP (offline mode)
--json		Emit JSON output