stacktrace-cli 0.6.0__tar.gz → 0.6.1__tar.gz

{stacktrace_cli-0.6.0 → stacktrace_cli-0.6.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: stacktrace-cli
-Version: 0.6.0
+Version: 0.6.1
 Summary: CLI for Stacktrace — Detection and Response platform for AI Agents.
 Project-URL: Homepage, https://stacktrace.ai
 Author-email: "Stacktrace AI, Inc" <founders@stacktrace.ai>
@@ -51,7 +51,7 @@ Requires Python 3.11 or newer.
 
 ```console
 $ stacktrace --version
-stacktrace 0.6.0 (openaca 0.7.0)
+stacktrace 0.6.1 (openaca 0.7.0)
 ```
 
 ## Quick start

{stacktrace_cli-0.6.0 → stacktrace_cli-0.6.1}/README.md

@@ -24,7 +24,7 @@ Requires Python 3.11 or newer.
 
 ```console
 $ stacktrace --version
-stacktrace 0.6.0 (openaca 0.7.0)
+stacktrace 0.6.1 (openaca 0.7.0)
 ```
 
 ## Quick start

{stacktrace_cli-0.6.0 → stacktrace_cli-0.6.1}/docs/adrs/0006-trust-boundary-and-detection-upload.md

@@ -5,7 +5,7 @@ status: accepted
 date: 2026-08-28
 supersedes: null
 superseded-by: null
-amended-by: 0011, 0027, 0031, 0039, 0064
+amended-by: 0011, 0027, 0031, 0039, 0064, 0084
 ---
 
 ## Context

{stacktrace_cli-0.6.0 → stacktrace_cli-0.6.1}/docs/adrs/0039-send-usage-telemetry-by-default-with-an-opt-out.md

@@ -6,7 +6,7 @@ date: 2026-09-21
 supersedes: null
 superseded-by: null
 amends: 0006, 0031
-amended-by: 0043, 0044
+amended-by: 0043, 0044, 0083
 ---
 
 ## Context

{stacktrace_cli-0.6.0 → stacktrace_cli-0.6.1}/docs/adrs/0067-a-webhook-is-an-independent-queue-subscriber.md

@@ -6,7 +6,7 @@ date: 2026-09-24
 supersedes: null
 superseded-by: null
 amends: 0036, 0046
-amended-by: 0068, 0071, 0073
+amended-by: 0068, 0071, 0073, 0085
 ---
 
 ## Context

{stacktrace_cli-0.6.0 → stacktrace_cli-0.6.1}/docs/adrs/0068-webhooks-retry-the-retained-backlog.md

@@ -6,7 +6,7 @@ date: 2026-09-25
 supersedes: null
 superseded-by: null
 amends: 0067
-amended-by: 0069
+amended-by: 0069, 0085
 ---
 
 ## Context

{stacktrace_cli-0.6.0 → stacktrace_cli-0.6.1}/docs/adrs/0073-name-what-fired-and-which-component.md

@@ -6,7 +6,7 @@ date: 2026-09-26
 supersedes: null
 superseded-by: null
 amends: 0067, 0071
-amended-by: null
+amended-by: 0084, 0085
 ---
 
 ## Context

stacktrace_cli-0.6.1/docs/adrs/0082-monitor-checks-every-installed-component-by-default.md

@@ -0,0 +1,72 @@
+---
+id: 0082
+title: Monitor's static tabs check every installed component by default
+status: accepted
+date: 2026-09-30
+supersedes: null
+superseded-by: null
+amends: null
+amended-by: null
+---
+
+## Context
+
+`correlate/orchestrate.py`'s `advisories_for` deliberately narrows advisory
+lookups to the union of what a session actually invoked. Its own docstring
+names this as a decision, not an accident of the optimization it also
+describes: asking during acquisition would send every component on the
+machine to osv.dev once per composition built, so it is asked after
+correlation instead — "osv.dev learns only about components this machine
+actually used."
+
+`docs/specs/monitor-inventory.md` adds two tabs, Inventory and Vulnerabilities,
+whose whole purpose is the opposite question: not what the agents did, but
+what they *can* load and what is known to be wrong with it. Answering that
+means checking every installed component, invoked or not, which reverses the
+invoked-only default for this one surface. A future reader who finds
+`advisories_for`'s comment and then finds `monitor` disclosing the full
+install list would reasonably read that as a regression rather than a second,
+deliberately different, disclosure boundary — the two call sites don't share
+a docstring, and the reason the newer one is broader isn't visible from
+either alone.
+
+## Decision
+
+`stacktrace monitor`'s Inventory and Vulnerabilities tabs send the package names
+of every *installed* component to osv.dev by default, independent of the
+invoked-only lookup that Live and `detect` keep using. This is not a new
+disclosure boundary: it is the same set `stacktrace scan endpoint` and Fleet's
+composition upload already send, so the static tabs are catching up to a
+boundary this package has already crossed elsewhere, not opening a new one.
+`monitor --help` and its startup line say so, because widening what leaves
+the machine is not something to do quietly. `detect` and the Live tab are
+unchanged and continue to ask only about what a session invoked.
+
+## Alternatives considered
+
+- **Invoked-only, matching Live** — rejected: it would leave every component
+  a session never happened to call unchecked, which defeats the tabs' stated
+  purpose (what the agent *can* load) in favor of what Live already shows
+  (what it did load).
+- **Gate the wider scan behind a flag** — rejected: the tabs are
+  materially incomplete without it, so the flag would be mandatory in
+  practice for anyone actually using the feature — a step with no real
+  choice behind it.
+
+## Consequences
+
+Every installed component that has a package name (an npm or PyPI MCP server,
+a package) is named to osv.dev once per `monitor` run, not only the ones a
+session reached. Skills and plugins with no package are never sent. This is a
+strictly larger disclosure than Live's, in the same process. The cost is
+proportional to install count rather than invocation count; this is accepted
+because `scan endpoint` already pays it per sync. `detect`'s narrower,
+invoked-only default is untouched and remains the answer for anyone who wants
+the tighter boundary.
+
+## When to revisit
+
+If install-count growth measurably slows the tabs' first paint (the spec's
+"summarise before listing" goal assumes the summary doesn't lag), or if
+someone asks for the invoked-only boundary on these tabs too — add a flag
+rather than reverting the default silently.

stacktrace_cli-0.6.1/docs/adrs/0083-each-block-reason-is-its-own-rule.md

@@ -0,0 +1,127 @@
+---
+id: 0083
+title: Each block reason is its own rule
+status: accepted
+date: 2026-09-30
+supersedes: null
+superseded-by: null
+amends: 0039
+amended-by: null
+---
+
+## Context
+
+`stacktrace-agent-blocked` emitted one finding per block reason in
+`detector/blocked.py` — `quota_exhausted`, `policy_blocked`,
+`provider_throttled`, `upstream_refused` — and carried the reason only as the
+anchor evidence's `kind`. Title, label, severity and remedy were all chosen per
+reason, so the finding a reader got locally was specific.
+
+Everything that keys on the rule id alone was not:
+
+- **Fleet.** Its catalogue is seeded per rule id and never uploaded (Cloud
+  ADR-0027, ADR-0029), so every block in the console read "The agent was
+  blocked while working" with one remediation. Findings roll up by rule, so a
+  spend limit, a safety block, a throttle and a service refusal were one row.
+  Slack takes its title from the same catalogue.
+- **Local notifications.** Prose is selected by rule id only (ADR-0031), so
+  every block notified as "The agent encountered a block while working".
+- **Special cases.** `daemon/presentation.py` and the daemon's delivery
+  properties each read `evidence[0].kind` for this one rule, and telemetry grew
+  a `reason` property scoped to it (ADR-0039) with its own pairing table.
+
+The four are not one finding with four wordings. Each has a different person
+who acts and a different action: the account owner raises a limit or waits; the
+person running the session starts a fresh one or leaves auto mode; nobody, at
+first, for a throttle that clears by itself; whoever owns the service's
+credentials grants a permission. They were already graded differently. ADR-0017
+declined a second rule id for a declined stall because "the question a reader
+asks is identical in both cases". Here it is not.
+
+## Decision
+
+**Each block reason is its own rule.** `stacktrace-blocked-quota`,
+`stacktrace-blocked-policy`, `stacktrace-blocked-throttled` and
+`stacktrace-blocked-upstream` are reliability rules, and each `Reason` names
+its `rule_id`. Detection is unchanged: one pass reads the session, groups by
+reason, and files each group under that reason's rule. The reason code stays
+the evidence `kind`.
+
+**Each is `session`-scoped.** It fires at most once per session, which is the
+cardinality ADR-0022 gives `session`. `agent-blocked` was `call` only because
+it fired once per reason; the new ids have no stored identity to keep stable.
+
+**`stacktrace-agent-blocked` is retired, not erased.** It leaves `RULE_IDS`, so
+nothing can emit it, and stays in `rules.RETIRED_SCOPES` with its `call` scope,
+because a finding the daemon stored before an upgrade still names it and the
+Fleet drain asks for its scope on every row it sends. Raising there would fail
+the drain on every tick for as long as the row was queued. The local findings
+view reads such a row by its retained reason code, and telemetry still admits
+the id.
+
+**A block already notified does not ring again under its new rule.** The
+daemon's transcript fingerprints live in memory, so the restart an upgrade
+brings re-reads every live session, and each block it rang as `agent-blocked`
+comes back with a new event id. `rules.SUCCEEDS` names the rule each new one
+took over from, and the store rebuilds the old id from the same anchor:
+`agent-blocked` was call-scoped on the first blocked call, which its successor
+still cites first. The new finding is still stored and uploaded.
+
+**Telemetry drops `reason`.** This amends ADR-0039's `finding_delivered` row,
+"optional reason code": the rule now says which reason it was, and a second
+property saying it again could only ever disagree.
+
+**Fleet learns the reasons by seeding four catalogue rows**, and keeps the
+`agent-blocked` row for findings already ingested and CLIs not yet upgraded.
+
+## Alternatives considered
+
+- **Teach Fleet the reason code instead.** A reason column on detections,
+  grouping and filtering by `(rule_id, reason)`, a per-reason title table.
+  Rejected: it adds a second key to ingest, schema, roll-up, filters, counts,
+  the console and Slack, and every consumer written later has to learn the same
+  special case. Splitting the id makes the reason a fact every rule-keyed
+  consumer already reads.
+- **Upload the per-reason title and remediation on the finding.** Rejected by
+  `docs/specs/detection-upload.md`: catalogue text is Cloud-derived so that two
+  copies cannot drift (ADR-0024).
+- **Keep `call` scope.** Rejected: it contradicts ADR-0022's cardinality rule,
+  and since the ids are new there is no identity in Fleet or the daemon ledger
+  to preserve.
+- **Keep `reason` in telemetry on the new rules.** Would keep a
+  group-by-reason insight working across versions. Rejected: it duplicates
+  `rule`, and keeping it honest needs a per-rule value check — the "a reason on
+  the wrong rule is a lie" argument ADR-0039's pairing table already made.
+- **Rewrite stored `agent-blocked` rows to the new ids at upload.** Rejected: it
+  changes what was recorded, puts evidence parsing on the upload path, and Fleet
+  already holds rows under the old id that it would not match.
+- **Name the rules after the codes** (`stacktrace-quota-exhausted`, …).
+  Rejected: a shared `blocked-` prefix keeps them together in sorted lists and
+  lets a prefix filter recover "every block" without a family column.
+
+## Consequences
+
+The catalogue grows from 10 rules to 13 (8 security, 5 reliability). This is
+not new coverage — the same pass finds the same blocks — so ADR-0015's case
+for a narrow catalogue is not reopened.
+
+Adding a block reason now means adding a rule: a `rules.py` entry with scope
+and stage, a `Reason.rule_id`, and a Fleet seed migration. That is the cost, and
+it is also the point: Fleet has to learn a new reason either way, and this
+makes forgetting visible as a bare rule id in the console (ADR-0029).
+
+During the transition, Fleet can hold both an `agent-blocked` row and a
+`blocked-*` row for the same block: the restarted daemon re-reads recent
+sessions and uploads each block again under its new rule, and an old and a new
+CLI can both analyse one session. The two rows do not merge. Laptops on older versions keep sending `agent-blocked`, with `reason`
+on `finding_delivered`, until they upgrade. A PostHog breakdown by `reason`
+covers only those versions; newer ones answer by `rule`.
+
+Notifications now name the reason, with the title `blocked.py` writes for it.
+
+## When to revisit
+
+If block reasons grow past a handful and the per-rule catalogue churn becomes
+the larger cost, or if a consumer needs "every block" as a unit a prefix cannot
+give — a family below `reliability`, say — then a catalogue column for it is
+the next step, not a return to one rule.

stacktrace_cli-0.6.1/docs/adrs/0084-a-recursive-deletes-evidence-is-the-rm-that-ran.md

@@ -0,0 +1,85 @@
+---
+id: 0084
+title: A recursive delete's evidence names what it deleted
+status: accepted
+date: 2026-09-30
+supersedes: null
+superseded-by: null
+amends: 0006, 0073
+amended-by: null
+---
+
+## Context
+
+`stacktrace-destructive-action` reached Fleet's Slack as *Subject: Bash (tool)
+(built-in) · Evidence: recursive_delete*. On the machine this was written
+against it fired four times in sixteen minutes, and every one was an agent
+deleting its own test output in a sibling project after a `cd` out of the
+session's starting directory. None of the four could be dismissed from the
+alert, because nothing in it said what was deleted.
+
+That is the condition ADR-0006 wrote for its own revision: a detection type
+genuinely unactionable without an evidence excerpt. ADR-0027 met it once, for
+one field.
+
+## Decision
+
+**A `stacktrace-destructive-action` citation's `kind` is `rm -rf` and the
+paths it deleted outside the workspace.**
+This narrows ADR-0006 constraint 3 for that one field on that one rule, and
+for that rule replaces ADR-0073's premise that a kind is a classifier: the
+daemon webhook, which maps `evidence_kinds`, carries the command too.
+
+1. **No new field.** Fleet already stores `kind` and shows it as the alert's
+   *Evidence*, so the device and Fleet keep one schema.
+2. **`rm -rf` and the escaped paths, and nothing else.** Each path as it
+   resolved, listed once and whole. A path that does not fit under 500
+   characters is counted (`… and 3 more`), never cut. Wrappers, flags,
+   operands that stayed inside the workspace and the rest of the tool call are
+   left out.
+3. **The existing redactor applies, word by word.** `kind` is cleaned one shell
+   word at a time, so each path is redacted on its own: relative to `$HOME` or
+   a working directory where it sits under one, its last component otherwise.
+   Credential tokens are dropped. An absolute path still never leaves.
+4. **The display is best-effort, and this is its whole scope.** When the rule
+   fires is the resolver's existing behaviour. Its one change here carries
+   `sudo -R`'s root into a nested shell and prefixes it onto an absolute
+   operand, so the scratch exemption cannot hide `/tmp/x` under a chroot. A
+   relative operand under `sudo -R` resolves as on the host: a known gap, kept
+   because translating `cd` and `-D` through a chroot took four review rounds
+   and each fix found a narrower case. The evidence
+   reproduces no shell syntax, so a case it shows imperfectly is a cosmetic
+   gap, not a parser to extend. The upload contract still checks the redacted
+   `kind` for rooted paths and credentials, so a display flaw is refused at
+   the send, never leaked.
+
+## Alternatives considered
+
+- **New evidence fields** (`deleted_paths`, `delete_commands`). Built and
+  dropped. They changed the schema between the device and Fleet, needed a
+  Fleet migration, and Fleet refuses keys it does not declare, so a CLI that
+  shipped first would have lost every run holding one.
+- **The command as the subject.** Rejected. Fleet groups findings by subject,
+  so every distinct command would become its own row instead of one *Bash*.
+- **`detail`.** Rejected. Fleet's Slack alert does not show it.
+- **The command as typed, operands resolved in place.** Built first, then
+  dropped. Reproducing wrappers, flags, `env -S`, quoting and several `rm`s in
+  one call was a shell parser of its own: every review finding on it after
+  the first was about that reproduction, and none about what was deleted.
+
+## Consequences
+
+Folder names, relative to the home directory, reach Fleet and every Slack
+workspace it posts to. That exposure is accepted for this rule because a delete
+cannot be triaged without it. A path outside `$HOME` and the working
+directories shows only its last component (ADR-0064), so `rm -rf /etc/important`
+reads `rm -rf important`; its `high` severity is what says it was a system
+delete. Fleet's alert cuts a kind at 200 characters and strips `*` and `~`.
+`tests/test_untrusted_content_never_travels.py` states the exemption beside the
+invariant it narrows.
+
+## When to revisit
+
+If a second rule asks to carry an excerpt, it needs its own ADR. If a customer
+objects to folder names in Fleet, the answer is an org-level switch, not a
+wider redactor.

stacktrace_cli-0.6.1/docs/adrs/0085-show-when-and-which-finding-slack-delivered.md

@@ -0,0 +1,88 @@
+---
+id: 0085
+title: Show when and which finding Slack delivered
+status: proposed
+date: 2026-09-26
+supersedes: null
+superseded-by: null
+amends: 0067, 0068, 0073
+amended-by: null
+---
+
+## Context
+
+The first Slack webhook configured on a host delivers every eligible finding
+still inside local retention (ADR-0068). A host with a retained backlog can
+therefore receive many messages at once. The Slack rendering did not show the
+finding's stable event ID or when Stacktrace recorded its notifiable revision,
+so a reader could not distinguish old backlog from new findings or name the
+exact finding when investigating it.
+
+The timestamp Slack adds to a posted message is delivery time. It cannot answer
+that question: a retained finding posted today looks new even when Stacktrace
+recorded it days earlier. ADR-0030's occurrence range answers a different
+question -- when the cited session turns occurred -- and may span multiple
+turns.
+
+Configuration also stated only that retained history would be sent. It gave no
+size before the write authorized delivery and woke the daemon.
+
+## Decision
+
+`detected_at` joins the webhook's allowlisted projection for every format. It is
+the queue row's `created_at`: the instant Stacktrace recorded the first revision
+that crossed the notification gate. It is neither the cited-turn occurrence
+range nor the later webhook delivery time. The payload remains version 1 because
+the field is additive.
+
+The Slack rendering shows `detected_at` with Slack's native date syntax, so each
+viewer sees it in their own locale and timezone, and includes the stable event
+ID under the label `finding ID`. The same event ID remains in
+`X-Stacktrace-Event-ID` for receiver idempotency. A timestamp that cannot be
+parsed as an offset-aware ISO 8601 value is omitted from the Slack presentation
+rather than holding the delivery cursor forever; the finding ID still renders.
+
+Before writing configuration, `stacktrace webhook configure` reads the webhook
+subscriber's durable high-water mark and reports the exact number of retained,
+notifiable revisions currently above it. It does not count unknowns, ineligible
+findings, later revisions of an already-notified finding, or rows the subscriber
+already passed. A missing database reports zero. An unreadable database reports
+that the preview is unavailable but does not prevent configuration.
+
+The count is an informational snapshot. It is not a confirmation prompt, a
+configuration-time cutoff or a new acknowledgement: concurrent recording and
+delivery may change the backlog immediately afterward, and ADR-0068's retained
+history semantics remain in force.
+
+## Alternatives considered
+
+- **Rely on Slack's message timestamp**: rejected because it is the delivery
+  time and makes an old retained finding look newly generated.
+- **Render `occurred_start` or `occurred_end`**: rejected because those date the
+  cited session evidence, not the finding's creation, and a finding can cite a
+  range rather than one instant.
+- **Keep the event ID only in the HTTP header**: rejected because headers help
+  automated receivers deduplicate but are invisible to the person investigating
+  a Slack alert.
+- **Ask for confirmation or default to new findings only when backlog exists**:
+  rejected because that silently changes ADR-0068's reliable retained-history
+  contract. The count supplies informed context without creating a second
+  delivery policy.
+
+## Consequences
+
+Backlog deliveries identify themselves as older findings, and operators can
+copy one stable ID into a discussion or lookup. Generic webhook consumers gain
+one additive field. Slack receives one more timestamp and the already-disclosed
+event ID in its message body.
+
+The configure count can be stale as soon as it is printed, and an unreadable
+database cannot provide it. Both conditions are stated rather than disguised as
+an exact authorization boundary.
+
+## When to revisit
+
+Revisit the label if the product introduces a separately persisted finding
+generation instant distinct from queue insertion. Revisit the preview if
+configuration gains an explicit backlog policy; until then it must remain a
+snapshot of the one retained-history policy, not a policy of its own.

{stacktrace_cli-0.6.0 → stacktrace_cli-0.6.1}/docs/adrs/INDEX.md

@@ -110,3 +110,7 @@ supersedes anything yet.
 - [0079](0079-the-monitor-page-renders-findings-not-pipeline-health.md) — **The monitor page renders findings, not pipeline health.** `app.js` stops drawing `banners` (collection failures, unplaceable sessions, suppressed-reasoning counts) — an operator reading the page wants to know what their agent did wrong, not why a transcript reader choked on a broken symlink, and unlike a finding there was nothing on the page to act on from one. The backend is unchanged: `render.py`'s `_banners()` still computes them and `/api/state`'s JSON still carries them, so a script, `curl`, or support still sees exactly what they saw before; `stacktrace sessions` still prints the full local detail. `#banners` (the DOM element) stays — `showConnectionLost` still uses it for a different claim, that the page itself cannot currently say anything. Read before reintroducing a page-rendered pipeline-health banner, or before assuming the page and the JSON show the same things.
 - [0080](0080-enabling-reasoning-does-not-requeue-the-past.md) — **Enabling reasoning does not retroactively requeue sessions skipped while it was off.** ADR-0081 made reasoning off the daemon's default, so `reasoning_not_requested` (previously rare) is now the routine outcome for a gate-tripping session scanned while the switch is off — and unlike `budget_exhausted`, it carries no `_underbuilt` retry marker, so the watermark advances and that session is done for good unless its transcript changes again. Deliberately not fixed by mirroring `budget_exhausted`: with reasoning off by default, that would retry every such session on every tick forever. Turning reasoning on starts coverage from that point forward; catching up on the past is left to an explicit `detect --reasoning`/`sync detect` re-run. Read before adding retry logic for a skipped-reasoning session, or before assuming enabling reasoning is retroactive.
 - [0081](0081-reasoning-activation-returns-to-explicit-opt-in.md) — **Reasoning activation returns to explicit opt-in.** Amends ADR-0076's "conditional reasoning activation" clause only — the phase collapse, rule placement and async executor it introduced are unchanged. `TYPESAFE_API_KEY` presence stopped being sufficient consent on its own: it was already insufficient on `detect`, `monitor` and `sync detect` (ADR-0033), and only the daemon had drifted to key-alone activation, reopening the exact divergence ADR-0029 fixed once. The daemon gains `--reasoning/--no-reasoning` on both `run` and `start`, and `STACKTRACE_REASONING` in `DaemonConfig`, defaulting to off through the same flag-beats-environment-beats-default ladder every other daemon setting uses. `daemon start`'s key prompt now runs only behind an explicit `--reasoning`, and `cloud/setup.sh` passes `--no-reasoning` to `daemon run` explicitly rather than trusting an inherited default. Read before assuming a key alone turns reasoning on anywhere, or before adding a reasoning-activation path that bypasses `DaemonConfig`.
+- [0082](0082-monitor-checks-every-installed-component-by-default.md) — **Monitor's static tabs check every installed component by default.** `correlate/orchestrate.py`'s `advisories_for` deliberately narrows osv.dev lookups to what a session actually invoked; `monitor`'s new Inventory and Vulnerabilities tabs (`docs/specs/monitor-inventory.md`) ask a different question — what the agent *can* load — so they send every installed component's package name by default, independent of that invoked-only lookup. Not a new disclosure boundary: the same set `scan endpoint` and Fleet's composition upload already send. `detect` and Live are unchanged. Read before touching `advisories_for`'s scope, before assuming monitor and detect share one disclosure boundary, or before widening what osv.dev sees from a third call site.
+- [0083](0083-each-block-reason-is-its-own-rule.md) — **Each block reason is its own rule.** `stacktrace-agent-blocked` filed four reasons under one id, so everything keyed on the rule id alone — Fleet's seeded catalogue and roll-up, Slack, local notifications — read a spend limit, a safety block, a throttle and a service refusal as one finding. Now `stacktrace-blocked-quota`, `-policy`, `-throttled` and `-upstream`, each named by its `Reason`, each `session`-scoped by ADR-0022 cardinality. `agent-blocked` is retired to `rules.RETIRED_SCOPES` so stored rows still upload. Amends ADR-0039: `finding_delivered` no longer carries `reason`. Read before adding a block reason, before teaching Fleet a sub-rule key, or before putting a second property beside `rule` on a telemetry event.
+- [0084](0084-a-recursive-deletes-evidence-is-the-rm-that-ran.md) — **A recursive delete's evidence names what it deleted.** Amends ADR-0006 constraint 3 and ADR-0073's kind-is-a-classifier rule, for `stacktrace-destructive-action` only. Its evidence `kind` is `rm -rf` and the paths that escaped the workspace, whole, listed once, counted past 500 characters; never wrappers, flags or the rest of the call, because an alert saying only `recursive_delete` cannot be triaged and a reproduced command is a parser of its own. No new field: Fleet already stores and shows `kind`, so device and Fleet keep one schema. The redactor cleans `kind` word by word and drops credentials; the upload contract still checks it, so a display flaw is refused, never leaked. Read before putting session text in any other field or rule, or before making the display reproduce more of the command.
+- [0085](0085-show-when-and-which-finding-slack-delivered.md) — **Show when and which finding Slack delivered.** Amends ADR-0067, ADR-0068 and ADR-0073: `detected_at` is the first notifiable revision's queue creation time, Slack renders it in the viewer's locale beside the visible stable finding ID, and `webhook configure` previews the exact currently pending eligible count before enabling. The count is a snapshot, not a cutoff or confirmation policy; retained-history and at-least-once delivery semantics do not change. Read before redefining `detected_at`, hiding the ID again, or turning the preview into a second backlog policy.

stacktrace_cli-0.6.1/docs/releases/v0.6.1.md

@@ -0,0 +1,108 @@
+# 0.6.1 — Inventory, and why an agent stopped
+
+0.6.0 told you what the agents on this machine did. This release adds what
+they can load, and says why an agent stopped instead of only that it did.
+
+The monitor gains Inventory and Vulnerabilities tabs. A blocked agent is now
+one of four findings — a spend limit, a safety check, a rate limit, or a
+service refusing it — each with its own title, fix and Fleet row. A
+destructive-action finding names the `rm` that ran.
+
+## The monitor shows what your agents can load
+
+Two new tabs, **Inventory** and **Vulnerabilities**, list every component the
+agents on this machine can load: MCP servers, plugins, skills, hooks, commands,
+subagents and packages. The list comes from the same collection the BOM upload uses, so
+the monitor and Fleet agree on what is installed. Each component reads one of
+four answers about known vulnerabilities: found, none found, not checked, or no
+package to check.
+
+To check them, the monitor sends the package names of installed components to
+osv.dev. That is the set `stacktrace scan endpoint` and the Fleet upload already
+send; the startup line and `monitor --help` say so (ADR-0082). `detect` and the
+Live tab still ask only about what a session invoked.
+
+## Four rules for why an agent stopped
+
+`stacktrace-agent-blocked` filed every block under one rule and kept the reason
+inside its evidence, so anything that reads only the rule id — Fleet's titles
+and grouping, Slack, notifications — saw a spend limit and a service refusal as
+the same finding. Each reason is now its own rule (ADR-0083):
+
+| Rule | Severity | Fires when |
+| --- | --- | --- |
+| `stacktrace-blocked-quota` | High | The account's spend limit stopped model calls |
+| `stacktrace-blocked-policy` | High | A safety check refused the action for the rest of the session |
+| `stacktrace-blocked-throttled` | Medium | Requests were rate-limited |
+| `stacktrace-blocked-upstream` | Medium | A service refused the request |
+
+Detection is unchanged; each block is filed under its reason's rule, once per
+session. Notifications now say which reason it was. A block already notified
+under the old rule before you upgrade does not notify again.
+
+## A destructive-action finding names the rm
+
+A `stacktrace-destructive-action` alert read "Evidence: recursive_delete",
+which said nothing about what was deleted. Its evidence is now `rm -rf` and the
+paths it deleted outside the workspace. Paths under your home folder travel
+home-relative, credentials are dropped, and an absolute path still never leaves
+the machine (ADR-0084).
+
+Severity now follows where the delete landed: high for system folders, a home
+folder, or a folder that contains the workspace; medium within two levels of
+the workspace; low deeper than that. Deletes under the temp directories are no
+longer findings. `sudo -R`'s root is now followed into a nested shell, and
+`env -S`'s split string is expanded before the target is read.
+
+## The monitor says what it is checking
+
+- **The Findings column opens with the checks a pass runs.** A line reads
+  "Checking 106 sessions for security and reliability issues…" with a progress
+  bar, and each check shows "2 found" the moment it finds something. A clean
+  window reads "All clear" with every check ticked. A window with findings folds
+  the list so the findings lead, and **What we check** opens it again.
+- **A range switch answers the click.** It used to change nothing on screen
+  until the new window had been read, 4 to 10 seconds on a real machine. A
+  retry click on a failed range now reaches the server, and a monitor restart
+  no longer confuses the page about which answer is its own.
+- **Bug fixes.** The page keeps its token when the logo link drops it, a
+  completed window with no sessions no longer reads "All clear", and findings
+  cards drop the stage tag.
+
+## Daemon and Slack
+
+- **Slack shows when a finding was detected, and its finding ID.** The webhook
+  payload gains `detected_at`, the moment Stacktrace first recorded the finding
+  (ADR-0085).
+- **`webhook configure`'s backlog preview counts only what will be delivered.**
+  It promised findings that the next start was about to prune.
+
+## Install
+
+`uv tool install stacktrace-cli==0.6.1` or `pip install stacktrace-cli==0.6.1`.
+Python 3.11 or newer; macOS and Linux.
+
+## Compatibility
+
+Beta — no back-compat hedging.
+
+- **`stacktrace-agent-blocked` is no longer emitted.** Anything filtering on it
+  — saved Fleet filters, webhook receivers — needs the four
+  `stacktrace-blocked-*` ids. The new rules are session-scoped; the old one was
+  call-scoped. Findings stored before the upgrade still upload under the old id,
+  and Fleet keeps showing rows it already ingested.
+- **Fleet titles for the new rules come from Fleet's own catalogue.** Until
+  that is deployed, they show as bare ids such as "Blocked quota".
+- **Fleet can show a block twice, once.** After the upgrade the daemon re-reads
+  recent sessions and uploads each block under its new rule beside the old
+  `agent-blocked` row. The two do not merge.
+- **Usage telemetry's `finding_delivered` no longer carries `reason`.** The
+  rule says which reason it was; a breakdown by `reason` covers older versions
+  only.
+- **Destructive-action findings change.** Their severity can now be high or
+  low as well as medium, temp-directory deletes no longer fire, and the
+  evidence shows the command.
+- **The monitor sends installed package names to osv.dev** for the Inventory
+  and Vulnerabilities tabs.
+- **A monitor and a CLI of the same version are still required.**
+- **Dependencies**: `openaca==0.7.0` and `openaidr==0.3.2`, both unchanged.