loki-mode 11.10.1 → 11.15.0

package/completions/_loki

@@ -286,7 +286,7 @@ function _loki_commands {
         'crash:Crash report management'
         'otel:OpenTelemetry management'
         'wiki:Wiki commands'
-        'answer:Resume a BLOCKED run with an answer'
+        'answer:Start a follow-up run from a BLOCKED run with your answer'
         'verify-pr:Verify a PR against its linked issue in a sandbox'
         'queue:Overnight issue queue with a morning digest'
         'issues:Run every open issue in a repo and open PRs'

package/completions/loki.bash

@@ -59,7 +59,7 @@ _loki_completion() {
         memory)
             local memory_cmds="list show search stats export clear dedupe index timeline consolidate economics retrieve lessons learn forget episode pattern skill vectors brief help"
             if [[ "$cur" == -* ]]; then
-                COMPREPLY=( $(compgen -W "--task --help" -- "$cur") )
+                COMPREPLY=( $(compgen -W "--task --recent --repo --help" -- "$cur") )
                 return 0
             fi
             COMPREPLY=( $(compgen -W "${memory_cmds}" -- "$cur") )
@@ -226,6 +226,13 @@ _loki_completion() {
             fi
             ;;
 
+        quickstart)
+            if [[ "$cur" == -* ]]; then
+                COMPREPLY=( $(compgen -W "--dry-run --explain-match --from-preview --verify-preview --json --list-templates --template --yes --help" -- "$cur") )
+                return 0
+            fi
+            ;;
+
         plan)
             if [[ "$cur" == -* ]]; then
                 COMPREPLY=( $(compgen -W "--json --verbose --spec --requirements --help" -- "$cur") )
@@ -242,6 +249,14 @@ _loki_completion() {
             COMPREPLY=( $(compgen -W "${issue_cmds}" -- "$cur") )
             ;;
 
+        modernize)
+            if [[ "$cur" == -* ]]; then
+                COMPREPLY=( $(compgen -W "--repo --ref --unit --mid --target --help" -- "$cur") )
+                return 0
+            fi
+            COMPREPLY=( $(compgen -W "heal migrate unit" -- "$cur") )
+            ;;
+
         onboard)
             if [[ "$cur" == -* ]]; then
                 COMPREPLY=( $(compgen -W "--depth --format --output --stdout --update --help" -- "$cur") )

package/dashboard/__init__.py

@@ -7,6 +7,6 @@ Modules:
     control: Session control helpers (status, atomic writes, origin check)
 """
 
-__version__ = "11.10.1"
+__version__ = "11.15.0"
 
 __all__ = ["__version__"]

package/docs/CLI-REFERENCE.md

@@ -1,13 +1,13 @@
 # CLI reference
 
-Generated from `loki-ts/src/cli/registry.ts` by `scripts/generate-stale-zero.sh` for v11.10.1. Do not edit by hand.
+Generated from `loki-ts/src/cli/registry.ts` by `scripts/generate-stale-zero.sh` for v11.15.0. Do not edit by hand.
 Hidden and legacy-only commands are omitted; see `docs/v10/CLI-MODERN.md` for the full inventory.
 
 | Command | Description |
 | --- | --- |
 | `loki version` | Show version |
 | `loki status` | Show current run status |
-| `loki doctor` | System prerequisites health check |
+| `loki doctor` | System prerequisites health check; --json, --fix, --requirements, --repo (repo profile with a 0-100 readiness score and fixes) |
 | `loki provider` | Show, list or set the AI provider |
 | `loki provider show` | Show current provider |
 | `loki provider list` | List providers and install status |
@@ -44,6 +44,8 @@ Hidden and legacy-only commands are omitted; see `docs/v10/CLI-MODERN.md` for th
 | `loki control backfill` | Ship DIR/.loki/runs to the control plane |
 | `loki control prune` | Delete matching runs |
 | `loki control status` | Show control plane reachability |
+| `loki intent` | Show a past run's intent card |
+| `loki intent show` | Print the intent card and answer |
 | `loki kpis` | KPI snapshot (alias of report kpis) |
 | `loki report` | Reporting: kpis, session, metrics, cost, export, share, dogfood |
 | `loki report kpis` | Canonical KPI snapshot |
@@ -57,7 +59,7 @@ Hidden and legacy-only commands are omitted; see `docs/v10/CLI-MODERN.md` for th
 | `loki trust detail` | Trust metrics detail |
 | `loki crash` | Inspect or submit scrubbed crash reports |
 | `loki contract` | Print the spec delivery contract |
-| `loki start` | Run the autonomous build |
+| `loki start` | Run the autonomous build (a `jira:KEY` or `linear:KEY` ref also writes the outcome back to that ticket, see docs/trackers.md) |
 | `loki slack` | Slack inbound handler |
 | `loki slack serve` | Serve the Slack handler |
 | `loki queue` | Overnight issue queue with a morning digest |
@@ -68,7 +70,8 @@ Hidden and legacy-only commands are omitted; see `docs/v10/CLI-MODERN.md` for th
 | `loki issues run` | Triage and run open issues; split too-large ones into stacked PRs |
 | `loki undo` | Plan or apply an undo of a run |
 | `loki verify-pr` | Verify a PR against its linked issue in a sandbox |
-| `loki answer` | Resume a BLOCKED run with an answer |
+| `loki verify-pr respond` | Fix open review comments on the PR branch, one commit each, reply with the sha |
+| `loki answer` | Start a follow-up run from a BLOCKED run with your answer |
 | `loki engine10` | v10 engine router |
 | `loki engine10 run` | Run the v10 engine |
 | `loki engine10 status` | v10 status |

package/docs/DEPLOYMENT.md

@@ -238,18 +238,25 @@ is the better option if you inject secrets as files rather than env vars.
 
 ---
 
+## Issue comment steering and author gate
+
+The `issue_comment` event steers a live run. A newly created comment on an issue
+that has a live Loki run (matched by `owner/repo#N`) is written to that run with
+`loki steer`, only when the comment's `author_association` is OWNER, MEMBER or
+COLLABORATOR. Bot comments, edits and deletions are ignored, the body is cut to
+one line of at most 1000 characters, and an unauthorized comment or an issue with
+no live run is skipped with nothing written. Subscribe the webhook to "Issue
+comments" to use it. The `issues` `opened` trigger applies the same author gate;
+set `LOKI_TRIGGER_ALLOW_ANY_ISSUE_AUTHOR=1` to let any author start a build.
+
 ## Triggers that do not exist yet
 
 Documented so you do not go looking for them:
 
 - **Issue labelled** (add a `loki` label to start a build). Not implemented.
   The `issues` handler acts on `opened` only.
-- **Issue comment commands** (`/loki build`). Not implemented. The receiver has
-  no `issue_comment` handler; GitHub will deliver the event and get back
-  `unsupported event: issue_comment`.
 
-Both are reasonable and neither exists in this release. Path 2 covers the same
-ground manually today.
+Not implemented in this release. Path 2 covers the same ground manually today.
 
 ---
 

package/docs/EVALUATING.md

@@ -217,6 +217,19 @@ Not measured: human effort, recovery success, review quality. Output: `--out-dir
 
 ---
 
+## Outcome analytics
+
+One set of definitions for the effort and honesty numbers, used by the bench report (`benchmarks/bench/attribution.py`) and by real-run reports (`loki trust`, `.loki/state/interventions.json`, HANDOFF.md). It answers the Factory comparison gate "metrics include failures and measure user effort" (FACTORY_VS_LOKI section 8, P2). Failures are counted, never dropped.
+
+- Term accepted outcome: bench, a run whose held-out acceptance check passed. Real runs, a proof with verdict VERIFIED that was not later contradicted by a FAILED outcome.
+- Term misleading completion: Loki or the agent claimed done and was wrong. Bench name `false_completion` = (reported success and not accepted) / reported success. `loki trust` name `false_verified` = VERIFIED claims later FAILED / VERIFIED claims. Same idea, same denominator (claims of success). Null when nothing claimed success.
+- Term cost per accepted: total spend across ALL attempts, failures included, divided by accepted. Null when nothing was accepted, and null when any run's cost is unmeasured (a partial sum is not a total; the bench also reports a lower bound). Never zero for an unknown.
+- Interventions by type: counts of blocking pauses that waited on a person, split into `steer`, `input`, `authorization` and `repair` (a fixed enum, no free text). Written to `.loki/state/interventions.json` at the pause site; shown in `loki trust`, HANDOFF.md and the proof as `interventions_detail`. Absent means not recorded, not zero.
+- Waited versus active minutes: only `waited_s` is measured, the wall-clock seconds a run sat blocked on a person. It is an upper bound on human attention. Active minutes (time a person actually spent working) are NOT measured and are never reported. `loki trust` labels the figure "waited, upper bound".
+- Retries: iterations to completion, taken from the proof `iterations.count` (`loki trust` iterations axis). A retry is not an intervention.
+
+---
+
 ## What we do not have
 
 Stating this plainly, because you will find it out anyway and it is cheaper for

package/docs/INSTALLATION.md

@@ -2,7 +2,7 @@
 
 Loki Mode, by [Autonomi](https://www.autonomi.dev/), turns a spec or an issue into a verified pull request with a receipt you can check. This page covers installing it, a first run, and the options around it.
 
-**Version:** v11.10.1
+**Version:** v11.15.0
 
 **Engine note:** `loki start` is the primary command. `loki start`, `loki "<task>"`, `loki owner/repo#N` and `loki quick` all run the Loki 10 engine, whatever the flag order or input form (PRD file, issue ref, task or one-word brief). The previous loop runs only on `--engine legacy`, `LOKI_ENGINE=legacy`, or for one call when a flag Loki 10 cannot honor is present. See the [user guide](v10/GUIDE.md) and the [5-minute quickstart](QUICKSTART.md).
 
@@ -57,7 +57,7 @@ Required (`loki doctor` fails without them):
 
 | Tool | Minimum |
 |------|---------|
-| Node.js | 18 (20+ recommended, 22 LTS is the CI target) |
+| Node.js | 20+ (22 LTS is the CI target) |
 | Python 3 | 3.8 |
 | git | any recent version |
 | jq | any |

package/docs/SIGNED-RECEIPTS.md

@@ -39,6 +39,13 @@ it", not an independent build. A receipt signed by a key the gate does not hold
 UNCHECKED and refuses; it is never reported as TAMPERED. Keep retired public
 keys listed after a rotation so old receipts stay VERIFIED.
 
+The signed `loki.deploy/1` record also carries the post-deploy facts:
+`health_status`, `health_http_code`, and, when `--auto-rollback` ran, whether the
+rolled-back service answered again (`post_rollback_health`: `healthy`,
+`FAILED_HEALTH` or `unchecked`). A rollback that leaves the service down exits 5.
+With `--health-match STR` the probe body must contain STR, and the record stores
+`health_match` and the deployed `tree_sha`.
+
 ## Honest limits
 
 - A signature proves **provenance and integrity**, not correctness. The

package/docs/WORKSPACES.md

@@ -36,7 +36,7 @@ loki workspace status <run-id>
 - A failing repo does not stop the others (continue and report). The command exits 0 only when every repo succeeded and the integration step did not fail. It exits 3 when the only non-ok outcomes are budget stops (a child exited 3, or a dependent was skipped behind one), and 1 for any other failure. Ctrl-C (SIGINT) stops the recorded child process groups like SIGTERM.
 - The repo that owns the issue ref gets the ref; other repos get a task text naming the ref and the sibling worktree paths as read-only context.
 - After all repos finish, the `integration` command runs once from the run directory with `LOKI_WS_DIR_<OWNER>_<REPO>` pointing at each worktree. A timeout counts as failed. With no integration configured the status is `not_configured`.
-- Evidence is written to `.loki/workspaces/<name>/<run-id>/integration.json`: head SHA per repo, exit code, log sha256. When every repo succeeded, integration did not fail and every child sealed a receipt, the run also seals a signed `composite.json` that binds integration.json and every child receipt (see "Verify a workspace run").
+- Evidence is written to `.loki/workspaces/<name>/<run-id>/integration.json`: head SHA per repo, exit code, log sha256. When every repo succeeded, integration did not fail and every child sealed a receipt, the run also seals a signed `composite.json` that binds integration.json (its status, exit code and log hash), `integration.log`, every repo head SHA and every child receipt (see "Verify a workspace run"). Sealing refuses a failed or interrupted integration run, a nonzero exit code, a missing integrated head and a log that does not match its recorded hash.
 - `loki workspace infer <name>` prints suggested `after:` edges read from package.json, go.mod and pyproject.toml dependencies on other listed repos. It also suggests an edge from (1) a source import (TS/JS import or require, Python import, Go import path) of a sibling's package or module name even when the manifest does not declare it, scanning at most 400 source files per repo, and (2) a client generator config (openapitools.json, openapi-generator*.yaml, orval.config.*) whose input spec path lies inside a sibling checkout. Each inferred edge prints its evidence as `file:line`. It is print-only and cycle-checked; it never edits loki.yaml.
 - `plan: true` (or `LOKI_WORKSPACE_PLAN=1`) makes one provider call that decomposes the brief per repo into `<run-dir>/plan.json`. A valid plan gives each listed repo its own task; an invalid one falls back to the generic text and prints the reason.
 - `integration: {per_stage: true}` also runs the integration command after each topological layer. A failing stage SKIPs every later layer, so a broken contract stops before downstream repos build on it.
@@ -55,7 +55,7 @@ After `loki workspace run <name> <ref>` finishes, check the evidence rather than
 3. `.loki/workspaces/<name>/<run-id>/integration.json` holds `status`, the head SHA per repo and `timing`.
 4. `python3 autonomy/lib/workspace_metrics.py <run-dir> --attention-min <minutes>` prints `prs`, `prs_per_hour` and `prs_per_attention_minute`; any value it cannot measure prints `unmeasured`.
 5. Each repo PR for the run branch carries exactly one integration comment.
-6. `loki verify <run-dir>/composite.json` re-checks the composite offline (add `--pubkey FILE` on another machine). It recomputes the composite hash, re-verifies every child receipt from disk and checks the signature. A tampered, swapped or stale-head child makes it TAMPERED or UNCHECKED; an unsigned child under a signed composite is UNCHECKED. Exit codes are the single-receipt ones: 0 VERIFIED, 1 TAMPERED, 2 UNCHECKED, 3 UNSIGNED. The composite never reads higher than its weakest child: one PARTIAL child caps it at PARTIAL.
+6. `loki verify <run-dir>/composite.json` re-checks the composite offline (add `--pubkey FILE` on another machine). It recomputes the composite hash, re-verifies every child receipt from disk and checks the signature. It prints the integration result and every repo head SHA it attests. It is TAMPERED for a tampered or swapped child, a child head that is not the integrated head, a failed or interrupted integration status or nonzero exit code, an edited integration section, or an `integration.log` that no longer matches its recorded hash. It is UNCHECKED for an unsigned child under a signed composite, and for a legacy composite that predates the integration section and has no integrated head to compare. Deployed-SHA binding is not implemented: the composite attests what was integrated and tested, not what is running anywhere. Exit codes are the single-receipt ones: 0 VERIFIED, 1 TAMPERED, 2 UNCHECKED, 3 UNSIGNED. The composite never reads higher than its weakest child: one PARTIAL child caps it at PARTIAL.
 7. A run that could not seal prints `composite not sealed: <reason>` (for example a repo with no receipt). Seal by hand with `loki verify --seal-composite <run-dir>`; it refuses unless every child has a receipt.
 
 Not measured: no scale test exists for large repo counts. Claim only what you have run.

package/docs/cost-controls.md

@@ -225,3 +225,29 @@ One table in `loki-ts/src/providers/provider_guard.ts` (`CAPABILITIES`) records
 | cline | engine10 | estimated | post-iteration | yes | none | yes | no | post-iteration | none |
 | aider | engine10 | estimated | post-iteration | yes | --no-auto-commits | yes | no | post-iteration | none |
 | opencode | engine10 | none | none | yes | none | yes | no | post-iteration | none |
+
+### Parallel units and groups
+
+A decomposed run (`loki backlog --dag`, or a spec that splits into a unit group) shares one
+total. The resolved cap is exported to every unit as `LOKI_BUDGET_LIMIT`, and the backlog
+runner stops launching pending units with `BUDGET_STOP` once the summed measured cost of
+finished units reaches that cap. Units already running when the cap is crossed finish, so
+the total can overshoot by at most the in-flight units. `budgets.per_run` is accepted as an
+alias of `budgets.per_run_usd` in `loki.yaml`.
+
+## A budget stop survives a rerun
+
+When the Bun engine stops a run on its dollar cap it writes
+`.loki/runs/<id>/budget.json` with the cap, the amount spent, where the cap
+came from, and the outcome `budget_stopped`. `loki status` shows the latest
+stop, and the run summary's next step reads "raise with --max-cost, then rerun
+the same task".
+
+Rerunning the same task does not reset the meter. The supervisor finds the
+newest budget stop for that exact task text and hands its spend to the worker
+as `LOKI_E10_SPENT_USD`, so the cap counts the earlier spend too. To continue,
+raise the cap with `--max-cost`.
+
+When a dollar cap is set but the provider reports no cost, the start output
+adds a warning: the cap cannot be enforced, because unmeasured sessions never
+count toward it.

package/docs/merge-queue.md

@@ -11,3 +11,22 @@ polled (LOKI_MERGE_POLL_S, default 20s; LOKI_MERGE_MAX_POLLS, default 90). After
 each merge the next PR is rebased onto the new base and must pass checks again.
 PRs that are red, time out, or fail to rebase stay in the queue; the command
 exits nonzero. Nothing is force-pushed and no check is bypassed.
+
+    loki merge pr <pr|branch> [--require-verified] [--delete-branch]
+
+One PR through the same gate. It is refused (PR left open) when it is a draft,
+when `gh pr checks` is not green after polling, or, with --require-verified,
+when the run verdict is not VERIFIED. The refusal names the gate. `loki start
+--ship` auto-merge uses this command, so it cannot bypass red, pending or draft
+PRs or a non-VERIFIED run.
+
+    loki merge watch <pr|branch> [--require-verified] [--delete-branch]
+
+CI repair loop. Waits for checks; when they are red it passes the failed-run log
+tail to a bounded repair session on the PR branch (LOKI_PR_REPAIR_CMD, default a
+`loki start` of a generated brief; it gets the evidence file path as its last
+argument), pushes, and re-checks, up to LOKI_PR_REPAIR_MAX attempts (default 2).
+Green goes through the same merge gate as `loki merge pr`. When attempts run out
+the PR is returned to draft, nothing merges, and the last failure log is printed.
+`loki start --ship` calls this after it opens the PR; `/merge watch <pr>` runs it
+from `loki chat`.

package/docs/sentry-intake.md

@@ -20,6 +20,8 @@ The token is sent only to the Sentry host through a curl config on stdin, never
 2. Start the server: `python3 autonomy/trigger-server.py --port 8080` and point the Sentry alert webhook at `/sentry`.
 3. A valid alert is normalized with `normalize_sentry_json` and enqueues `loki start "<brief>" --pr --detach`. A bad signature gets 401.
 
+The brief also carries the event's release and environment, the newest `.loki/deploys` record (`last deploy <sha7> <finished_at> health=<status>`) and, when the culprit file resolves inside the project, its last `git log -1` author. All of it is sanitized to one line and capped; it adds no authority.
+
 The output is a receipt-gated PR only, never a deploy. Whether the PR opens is still decided by the policy file (`autonomy`).
 
 
@@ -55,6 +57,8 @@ Teams (`POST /teams`):
 2. `Authorization: HMAC <base64>` is the base64 HMAC-SHA256 of the raw body keyed by the base64-decoded token. Bad signature: 401. The activity `timestamp` must be within 300s; a stale or missing one is refused with 401.
 3. The message text (with `<at>` mentions and tags removed) is the brief and runs as `loki start --brief "<brief>" --pr --detach`. Teams gets a synchronous reply whose text starts with "Queued" and ends with the job id. A repeated activity id is not queued twice.
 
+Jira completion comments: set `JIRA_BASE_URL` (https only), `JIRA_EMAIL` and `JIRA_API_TOKEN`; the result is then posted as a comment on the issue that triggered the run. Without all three nothing is posted, and `JIRA_API_TOKEN` never reaches the `loki start` child environment.
+
 Jira and Teams runs are receipt-gated PR runs only: the server always passes `--pr` and never a deploy argument, so shipping stays a separate gated step. `--brief` forces brief mode, so text that ends in `.md` or contains an issue URL is never reclassified, and `loki start --brief ... --pr/--worktree/--detach` runs in an isolated worktree, detached, and opens a PR carrying the Evidence Receipt (the same machinery as `loki start <issue>`). Sentry alerts use the same form. Neither secret reaches the `loki start` child environment, and both must differ from every other credential. A missing secret answers 503 naming the variable.
 
 Reply targets are stored server side keyed by job id, captured only after verification. Notifier errors are logged and never fail the job. Poll status with `GET /jobs/<id>`.

package/docs/slack.md

@@ -16,12 +16,13 @@ Point the Slack Events API request URL at this server through a tunnel or revers
 
 - `@loki <issue ref or task text>` in a channel starts a Loki 10 run (it launches `bin/loki "<task>"`; the text must be at least two words and must not start with `-`, otherwise the bot replies asking you to describe the task, so a lone word like `reset` can never reach a legacy subcommand) and replies in the thread with the run id.
 - When the run ends BLOCKED, the question is posted in the same thread. A reply in that thread starts a follow-up run with your answer added to the original task (v10 has no in-place resume, BLOCKED is terminal).
+- The CLI `loki answer` has the same semantics: it starts a fresh follow-up run that carries the original task plus your answer, it does not resume the BLOCKED run.
 - Runs are launched through the repo `bin/loki` with the two Slack secrets removed from the child environment and `LOKI_NO_BROWSER=1` set. A failed Slack post logs one redacted line to stderr.
 - Every request is verified with the Slack signature (HMAC sha256 over `v0:timestamp:body`, constant-time compare, timestamps older than 5 minutes are rejected). Retried events are deduplicated.
 
 ## Who can start a run
 
-Set `LOKI_SLACK_ALLOWED_USERS` to a comma-separated list of Slack user IDs (for example `U012ABC,U034DEF`). A mention or a BLOCKED-thread answer from any other user is rejected with a short thread reply and nothing is spawned. When it is unset, anyone who can mention the bot can start a run, and `loki slack serve` prints one startup line saying so.
+Set `LOKI_SLACK_ALLOWED_USERS` to a comma-separated list of Slack user IDs (for example `U012ABC,U034DEF`). A mention or a BLOCKED-thread answer from any other user is rejected with a short thread reply and nothing is spawned. When it is unset or blank, every mention is rejected (fail closed) and `loki slack serve` prints one startup line saying so. Set it to `*` to explicitly allow anyone in the workspace. The trigger server `/slack` slash command applies the same variable to the form `user_id`.
 
 Limits: task text over 64 KB is rejected with "task too long" and no run starts. If a run cannot be launched, the thread gets a generic message and the detail (which may include local paths) is logged to stderr only. `--port` must be a whole number (an empty value exits 2).
 

package/docs/trackers.md

@@ -1,6 +1,6 @@
 # Jira and Linear intake
 
-Loki 10 can start a run from a Jira or Linear issue. This is intake only: the issue is fetched once, before any model runs, and normalized into the same `issue.json` GitHub intake writes (with a `source` field of `jira` or `linear`). Loki does not write back to the tracker or sync status.
+Loki 10 can start a run from a Jira or Linear issue. The issue is fetched once, before any model runs, and normalized into the same `issue.json` GitHub intake writes (with a `source` field of `jira` or `linear`). Loki can also write the outcome back to the ticket (see Writeback below); it never syncs status beyond that.
 
 ```bash
 loki jira:PROJ-123
@@ -14,6 +14,17 @@ loki linear:ENG-42
 
 A missing variable stops the run with an error that names it. A Linear HTTP 401, or a GraphQL response with errors and no data, also names `LINEAR_API_KEY`.
 
+## Writeback
+
+When the run starts from a `jira:` or `linear:` ref, `loki start` exports `LOKI_WRITEBACK_ISSUE` with the issue key, and the same credentials used for intake enable writeback. With no ref, writeback stays off unless the legacy `LOKI_JIRA_URL`, `LOKI_JIRA_TOKEN`, `LOKI_JIRA_EMAIL` or `LOKI_LINEAR_TOKEN` variables are set. With nothing configured, no network call is made.
+
+- done: a comment with the verdict, the PR URL and the receipt sha256.
+- blocked: a comment that the run needs input, with the reason.
+- failed: a comment that the run ended without a PR, with the reason.
+- started: supported by the contract, with its own comment text; the engine does not emit it today.
+
+Optional status moves happen only on done: `LOKI_JIRA_DONE_TRANSITION` (a Jira transition id) and `LOKI_LINEAR_DONE_STATE` (a Linear workflow state id). Failures warn on stderr and never change a verdict or exit code. Tokens are never logged.
+
 ## Self-hosted Jira
 
 `<JIRA_BASE_URL>/browse/KEY` is accepted as a ref only when its origin equals the origin of `JIRA_BASE_URL`. A browse URL on any other host is not treated as a tracker ref.