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

stacktrace_cli-0.6.1/.claude/skills/pr-review-loop/SKILL.md

@@ -0,0 +1,120 @@
+---
+name: pr-review-loop
+description: Autonomous code → commit → push → PR → review monitoring → fix → thumbsup loop. Use when the user wants end-to-end delivery of code changes through Codex review approval.
+---
+
+# pr-review-loop
+
+End-to-end autonomous loop: generate code, commit, push, create or update a PR,
+monitor Codex review, fix findings, and iterate until the PR receives a thumbsup
+or approval with no actionable findings remaining.
+
+**Announce at start:** "I'm using the pr-review-loop skill to deliver this change
+through review."
+
+## When to invoke
+
+User says any of: "ship this", "get this to thumbsup", "run the review loop",
+"deliver through review", or asks for code changes with instructions to
+autonomously handle the PR review cycle.
+
+## Inputs
+
+1. **Branch name** — inferred from the current branch, or ask the user.
+2. **PR number** — if a PR already exists for the branch, use it. Otherwise
+   create a new one.
+3. **Base branch** — defaults to `main`.
+
+## Phase 1: Code generation
+
+1. Implement the requested changes following the repo's conventions (CLAUDE.md):
+   - TDD for business logic (red → green → refactor)
+   - Surgical changes — touch only what you must
+   - Simplicity first — no speculative abstractions
+2. Run all four gates before committing:
+   ```bash
+   uv run ruff check .
+   uv run ruff format --check .
+   uv run pyright
+   uv run pytest -q
+   ```
+3. Fix any failures. If a gate reveals a design decision, go with the
+   recommendation and log the decision.
+
+## Phase 2: Commit, push, PR
+
+1. Stage only the files your changes touch — never `git add -A`.
+2. Commit with a descriptive message explaining WHY, not WHAT.
+3. Push to remote. If rejected, stop and report it as a blocker — fetch and
+   look at what changed, but do not rebase or force-push to resolve it
+   automatically (see "Never force-push, rebase published commits" below).
+4. If no PR exists for this branch, create one with `gh pr create`. Include a
+   summary, list of changes, and a test plan.
+5. If a PR already exists, update its description if the scope changed.
+
+## Phase 3: Monitor review
+
+Poll for review status using a dynamic loop (`/loop`). On each tick:
+
+1. Check CI status:
+   ```bash
+   gh pr checks <PR_NUMBER>
+   ```
+2. Check for new review comments:
+   ```bash
+   gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/comments --paginate
+   gh api repos/<OWNER>/<REPO>/pulls/<PR_NUMBER>/reviews
+   ```
+3. If CI fails, read the logs and fix the issue. Push a new commit.
+4. If Codex or a human reviewer left comments:
+   - Read each comment thread.
+   - For P0/P1/P2 findings: fix them. Push a new commit.
+   - For P3 findings: defer unless the user approved them.
+   - If you disagree with a finding: reply on the PR explaining why,
+     with evidence. Do not silently skip it.
+5. If a reviewer requested changes, address them and re-request review.
+
+### Decisions during review
+
+- **Make autonomous decisions** for: code style fixes, test additions,
+  lint/format fixes, obvious bug fixes, naming improvements.
+- **Log but proceed** for: architecture choices between reasonable alternatives,
+  threshold values, which invariant test to extend.
+- **Stop and ask** for: design-level questions flagged for the user, scope
+  changes that would significantly alter the PR, removing existing tests or
+  changing public interfaces.
+
+### Stopping conditions
+
+- **Success:** CI passes, the latest head has been reviewed, and no actionable
+  P0/P1/P2 findings remain. Report the result.
+- **Cap reached:** After 7 automated fix rounds without a human corrective
+  commit, stop and post a message in the PR (per CLAUDE.md review rules).
+- **Blocked:** A finding requires human judgment (design decision, scope change).
+  Post a summary comment and notify the user.
+
+## Phase 4: Summary
+
+When the loop exits, report:
+1. Total commits pushed.
+2. Review rounds completed.
+3. Decisions made autonomously (with brief justification for each).
+4. Any remaining P3 suggestions that were deferred.
+5. Final PR status (approved / changes requested / commented).
+
+## Conventions
+
+- Never force-push, rebase published commits, or skip hooks.
+- Every fix is a new commit, not an amend.
+- Batch related fixes into one commit when possible.
+- Run all four gates before every push.
+- Count fix rounds per CLAUDE.md: 7 rounds without a human corrective commit
+  triggers the cap.
+
+## What this skill does NOT do
+
+- **Doesn't merge the PR.** That's always a human action.
+- **Doesn't approve its own PR.** It can only push fixes and respond to review.
+- **Doesn't modify CI/CD, branch protection, or permissions.**
+- **Doesn't override human reviewer decisions.** If a human says "don't fix
+  this", it stays unfixed.

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: stacktrace-cli
-Version: 0.5.3
+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>
@@ -21,7 +21,7 @@ Requires-Python: >=3.11
 Requires-Dist: click>=8.1
 Requires-Dist: httpx<1.0.dev0,>=0.28.1
 Requires-Dist: openaca==0.7.0
-Requires-Dist: openaidr==0.3.0
+Requires-Dist: openaidr==0.3.2
 Requires-Dist: posthog<8,>=7.0
 Description-Content-Type: text/markdown
 
@@ -51,7 +51,7 @@ Requires Python 3.11 or newer.
 
 ```console
 $ stacktrace --version
-stacktrace 0.5.3 (openaca 0.7.0)
+stacktrace 0.6.1 (openaca 0.7.0)
 ```
 
 ## Quick start

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

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

{stacktrace_cli-0.5.3 → 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.5.3 → stacktrace_cli-0.6.1}/docs/adrs/0029-stage-three-returns-to-opt-in.md

@@ -1,10 +1,10 @@
 ---
 id: 0029
 title: Stage three returns to opt-in
-status: accepted
+status: superseded
 date: 2026-09-09
 supersedes: null
-superseded-by: null
+superseded-by: 0076
 amends: 0004
 amended-by: null
 ---

{stacktrace_cli-0.5.3 → stacktrace_cli-0.6.1}/docs/adrs/0033-a-third-party-analyzer-only-by-a-flag-that-names-it.md

@@ -1,10 +1,10 @@
 ---
 id: 0033
 title: A third-party analyzer is reached only by a flag that names it, and its output is numbers
-status: accepted
+status: superseded
 date: 2026-09-17
 supersedes: null
-superseded-by: null
+superseded-by: 0076
 amends: 0004, 0011
 amended-by: 0034, 0035
 ---

{stacktrace_cli-0.5.3 → stacktrace_cli-0.6.1}/docs/adrs/0035-naming-an-analyzer-selects-stored-answers.md

@@ -6,7 +6,7 @@ date: 2026-09-19
 supersedes: null
 superseded-by: null
 amends: 0033
-amended-by: null
+amended-by: 0076
 ---
 
 ## Context

{stacktrace_cli-0.5.3 → 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.5.3 → stacktrace_cli-0.6.1}/docs/adrs/0060-two-upload-postures-not-one-command-with-two-sources.md

@@ -6,7 +6,7 @@ date: 2026-09-23
 supersedes: null
 superseded-by: null
 amends: null
-amended-by: null
+amended-by: 0077
 ---
 
 ## Context

{stacktrace_cli-0.5.3 → stacktrace_cli-0.6.1}/docs/adrs/0065-asset-external-id-resolves-by-a-ladder.md

@@ -6,7 +6,7 @@ date: 2026-09-24
 supersedes: null
 superseded-by: null
 amends: null
-amended-by: null
+amended-by: 0078
 ---
 
 ## Context

{stacktrace_cli-0.5.3 → 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.5.3 → 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.5.3 → 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/0076-two-phase-detection-pipeline.md

@@ -0,0 +1,164 @@
+---
+id: 0076
+title: Collapse detector to two phases with conditional reasoning
+status: accepted
+date: 2026-09-27
+supersedes: 0029, 0033
+superseded-by: null
+amends: 0035
+amended-by: 0081
+---
+
+## Context
+
+The detector has three stages: deterministic (2 rules), priors (0 rules — all
+five withdrawn), and reasoning (cache-only — daemon hardcodes
+`reasoning=False`). Stage 2 contains no detection logic, only routing and two
+data-quality metrics. The daemon never activates new reasoning. Adding new
+rules (10 total) requires cleaning up this structure.
+
+Three problems force the change now:
+
+1. **Stage 2 is empty.** `run_priors` has no rules. What remains is
+   `low_coverage` (a data-quality metric), `_missing_mcp_transport` (same),
+   and routing logic that builds `ReasoningRequest`s. None of that is
+   detection.
+
+2. **The daemon never reasons.** `analyse_batch()` hardcodes
+   `reasoning=False`. New reasoning rules (`stacktrace-infra-unsafe-action`,
+   `stacktrace-unrequested-publication`) will never fire in the background.
+
+3. **Reasoning blocks the tick.** A 1–3s Jev call per session, run
+   synchronously in a 5s tick, blocks the daemon.
+
+## Decision
+
+Collapse to two phases and one orchestrator. Phase 1 is deterministic (no
+model, no vendor boundary — predominantly μs, with the exception of
+`stacktrace-vulnerable-dep-invoked` which queries cached advisory data and degrades
+to async enrichment on a cold cache). Phase 2 is reasoning (seconds,
+requires `TYPESAFE_API_KEY`). The orchestrator sits between them and
+builds the reasoning queue from gate trips, solo routes, and the
+EVERY_SESSION route.
+
+### Phase collapse
+
+Stage 2's remnants move:
+
+| Function | Destination |
+|---|---|
+| `low_coverage` | Session-level metric (not a rule) |
+| `_missing_mcp_transport` | Per-rule coverage metadata on the analysis result |
+| Routing (`_solo_routes`, `ReasoningRequest`) | Orchestrator inside `run_detector` |
+
+### Conditional reasoning activation
+
+`TYPESAFE_API_KEY` in the environment is the only switch. No `--reasoning`
+flag, no `--analyzer jev`. If the key is absent, `reasoning=False` — no
+model, no cost, no vendor boundary. If present, Phase 2 runs only when
+Phase 1 produces a non-empty reasoning queue.
+
+Budget: `DEFAULT_DAEMON_BUDGET = 50`. It caps *sessions* dispatched to
+Phase 2 per tick, not Jev calls — `stacktrace-deceptive-completion` alone
+issues one gate call plus one call per verification call with a covering
+claim, so a session's actual cost scales with its checks. At $0.0006/session
+(one gate call) and typical <20 sessions/tick, normal operation is nowhere
+near the cap; $0.03/tick is that single-call estimate at the budget ceiling,
+not a hard spend cap — a tick of sessions with many verification calls can
+exceed it.
+
+### Async Phase 2
+
+Phase 1 runs synchronously in the tick. Phase 2 dispatches to
+`ThreadPoolExecutor(_WORKERS=4)` and returns immediately. The next tick
+does not wait. When a verdict arrives, findings are recorded and
+`on_commit` wakes the fleet/webhook jobs.
+
+```
+tick()
+├─ Synchronous (μs–ms)
+│  ├─ enumerate + collect + correlate
+│  ├─ Phase 1: deterministic → findings recorded immediately
+│  ├─ orchestrator → reasoning queue
+│  └─ record(findings, unknowns, pending=queue)
+│
+├─ Asynchronous (ThreadPoolExecutor, background)
+│  └─ for each ReasoningRequest:
+│      build windows → Jev call → evaluate → store.record_reasoning()
+│
+└─ Scheduler.tick()
+```
+
+### Rule placement
+
+| Rule | Phase | Rationale |
+|---|---|---|
+| `stacktrace-credential-egress` | 1 | Regex on call arguments |
+| `stacktrace-agent-blocked` | 1 | Refused-call channel match |
+| `stacktrace-destructive-action` | 1 | Path resolution on delete commands |
+| `stacktrace-credential-persisted` | 1 | Secret match on a Write/Edit call's own content |
+| `stacktrace-mcp-transient-failure` | 1 | MCP call sequence pattern |
+| `stacktrace-tool-retry-storm` | 1 | Counter with reset |
+| `stacktrace-vulnerable-dep-invoked` | 1 | Package list × osv.dev |
+| `stacktrace-deceptive-completion` | 2 | Gate (Jev) + per-call nouls. EVERY_SESSION route. |
+| `stacktrace-infra-unsafe-action` | 1 gate → 2 | Gate: mutating command. Model: beyond_request + shared_target. |
+| `stacktrace-unrequested-publication` | 1 gate → 2 | Gate: publication verb. Model: beyond_request. |
+
+## Alternatives considered
+
+- **Keep three stages, add rules to stage 2.** Rejected because stage 2 has
+  no rules and its abstraction boundary is accidental — it exists because the
+  function signature existed, not because the domain has three kinds of work.
+
+- **Separate `--reasoning` and `--analyzer` flags.** Rejected because the
+  consent decision is setting `TYPESAFE_API_KEY` — the operator named a
+  vendor by placing its key. Two flags that must be typed together, where one
+  is meaningless without the other, is ceremony that protects nothing.
+
+- **Synchronous reasoning in the tick with a short budget.** Rejected because
+  even a budget of 3 blocks the tick for 3–9 seconds. The daemon goes deaf,
+  and the tick interval (5s) is shorter than a single Jev call.
+
+## Consequences
+
+- 7 of 10 rules fire on every tick with no model dependency.
+- Reasoning activates automatically when a key is present and a gate trips.
+- The tick never blocks on inference.
+- `ThreadPoolExecutor(4)` caps Jev API pressure at 4 concurrent calls.
+
+**Costs:**
+
+- Async Phase 2 requires a daemon-owned executor with these invariants:
+  (1) bounded in-flight work — cap queued futures, not just the budget;
+  (2) in-flight deduplication — a session already pending reasoning is not
+  re-queued; (3) revision-aware commits — a reasoning result is committed
+  only if its session fingerprint matches the current analysis, so a stale
+  result from a slow Jev call never overwrites a newer deterministic pass;
+  (4) retry on transient Jev failure, with backoff, capped at 3 attempts;
+  (5) on daemon restart, pending reasoning is re-derived from Phase 1 on
+  the next tick rather than persisted across restarts;
+  (6) on daemon stop or upgrade, cancel queued futures and observe
+  cancellation between per-window requests in active workers — the executor
+  must not outlive the daemon's stop deadline (600s), so shutdown joins only
+  the work already in flight, never the full queue.
+- New rules send data the original consent did not envision (shell commands,
+  user requests). Documentation should describe what each rule sends. This
+  ADR amends the consent model established in ADR-0033; key-as-consent is a
+  product decision that should be documented as such. Cached verdicts from
+  prior runs remain readable when the key is present, independent of whether
+  new reasoning is commissioned — this preserves the `--analyzer jev`
+  read-only behavior. Cached Jev verdicts remain readable without a key:
+  the cache is keyed by analyzer identity and prompt version, not by the
+  presence of a runtime credential, so removing or rotating
+  `TYPESAFE_API_KEY` stops commissioning new work but does not discard
+  already-paid findings.
+
+## When to revisit
+
+- If a second reasoning provider is added (Jev is the only one today), the
+  key-as-consent model needs per-provider consent.
+- If Phase 2 latency exceeds 10s per session, the ThreadPoolExecutor design
+  may need a persistent queue with retry.
+- If cross-rule incident grouping becomes urgent (credentials written,
+  committed, and pushed = three findings for one mistake), the orchestrator
+  needs a post-Phase-2 deduplication pass.

stacktrace_cli-0.6.1/docs/adrs/0077-the-bom-job-wakes-once-at-startup-staggered.md

@@ -0,0 +1,208 @@
+---
+id: 0077
+title: The BOM job wakes once at startup, staggered
+status: accepted
+date: 2026-09-30
+supersedes: null
+superseded-by: null
+amends: 0060
+amended-by: null
+---
+
+## Context
+
+ADR-0060 clause 2 justifies `stacktrace daemon sync-bom` this way: "the drain
+at least has a wake path, and the BOM job has none." That was true when
+ADR-0060 was accepted. This PR gives the BOM job the same one-time startup
+wake `fleet`/`webhook` already had — otherwise a freshly started daemon sits on
+a machine's inventory for up to `--bom-interval` (6h default) plus a
+hostname-derived stagger before its first upload, unlike the other two jobs.
+ADR-0060's sentence is now the one thing in this repository's design contract
+that says the opposite of what the code does.
+
+The first attempt at the wake reset `Job._due_at` to `now + interval`
+unconditionally on every run. Codex review caught that this loses the
+hostname stagger `stagger()` computes not just on the first run but forever
+after: every host provisioned from one script converges onto the same
+recurring upload instant, which is the exact fleet-wide burst `stagger()`
+exists to prevent (`docs/specs/daemon-uploads.md`'s "Stagger machines" row).
+
+The second attempt preserved the stagger only when `_due_at > now` at the
+moment `run_if_due` executed — reasoning that a run "arrived early" only if
+its deadline hadn't passed yet. A further Codex pass caught that this breaks
+too: `DaemonService.tick()` runs `scanner.run_once()` before `jobs.tick()`, so
+a slow initial scan can push `now` past a low-offset host's `_due_at` before
+the startup-woken `bom.run_if_due()` ever executes, even though that run is
+still the job's first. Comparing `_due_at` to `now` cannot distinguish "ran
+early" from "ran late" — it can only be answered by whether this is the job's
+first run at all.
+
+A third Codex pass caught that a single `+ interval` step still isn't enough:
+with a short `--bom-interval`, a delay of more than one interval left the
+preserved deadline in the past, so the job went due again immediately and
+that second run — no longer the first — re-anchored on `now` via the normal
+path anyway. A fourth caught that even advancing by whole intervals wasn't
+enough on its own, because the deadline was computed from the clock read
+*before* `self.run()` — the BOM upload itself can eat into whatever margin
+that pre-run reading assumed was safe, on the same short-interval hosts the
+third pass was about. A fifth caught the last boundary case: rounding the
+delay up with `ceil` leaves the deadline exactly equal to the post-run clock
+when the delay lands on an exact interval multiple, which `_is_due` still
+reads as due.
+
+A sixth and seventh Codex pass moved the goalposts again, but this time both
+findings were instances of the same thing: `--bom-interval` (and every other
+daemon interval — `parse_duration`, `config.py`) validated only a maximum,
+never a minimum. A sixth pass constructed an interval small enough (the
+smallest positive `float` at all) that the phase arithmetic's division
+overflowed to infinity, raising `OverflowError` out of `run_if_due` and
+crashing the scheduler loop. Patched locally at first — a `try`/`except`
+around the division, falling back to the plain `after + interval` deadline —
+a seventh pass immediately found the sibling case one `try`/`except` does not
+cover: an interval too small relative to a long-uptime host's `monotonic()`
+reading to survive floating-point addition at all (`now + interval == now`),
+which does not raise, so the `except` never fires, and the job re-runs on
+every tick forever. Two Codex passes finding two failure modes of the same
+missing input check, back to back, is the shape CLAUDE.md names directly:
+"a second finding of the same class means the first fix was at the wrong
+level." The fix moved to the boundary instead of the arithmetic:
+`parse_duration` now refuses any positive duration under one second (closing
+both repro cases directly, `5e-324s` and `1e-20s` alike), for every daemon
+interval it parses, not only the BOM job's. `Job`'s phase arithmetic no
+longer defends against a value that should never have reached it, and the
+`try`/`except` this replaced is removed along with the test that pinned it —
+CLAUDE.md's own bar for removing a test that protected a behavior which was
+"intentionally changed or removed": the behavior here (surviving a
+sub-one-second interval inside `Job`) is removed, not merely relocated, since
+no caller can construct one through the validated path anymore.
+
+## Decision
+
+The BOM job is woken once, unconditionally, right after it's constructed —
+the same as `fleet`/`webhook`. `Job` gains a `preserve_stagger` flag, set only
+for the BOM job: on that job's first-ever run (`_ran_at is None`, checked
+before this run sets it), the pre-run `_due_at` assignment (`now + interval`)
+is skipped, and the next due time is instead computed once `run()` returns
+(success or failure alike, from a `finally` block) as the original staggered
+slot advanced by as many whole intervals as the delay — measured against the
+clock *at that point*, not before the run — needs to land at or after it:
+`_due_at + interval * max(1, floor((after - _due_at) / interval) + 1)` —
+`floor(x) + 1`, not `ceil(x)`, since `ceil` leaves the result exactly equal to
+`after` when the delay lands on an exact interval multiple, and `floor(x) + 1`
+is strictly greater than `x` for every real `x` with no boundary case left
+over. That division assumes `interval` is representable and well away from
+zero; `parse_duration` (`config.py`) now enforces a one-second floor on every
+positive daemon interval it parses (`0` still means disabled), which is the
+only thing standing between this arithmetic and the two failure modes below,
+placed at the boundary where the value entered the system rather than as a
+defensive check inside `Job` itself. Every run
+after the first behaves exactly as before: `_ran_at` is no longer `None`, so
+`run_if_due` falls back to `now + interval`, computed before the run same as
+any job without `preserve_stagger` set. `fleet`/`webhook` do not set the
+flag: they are woken repeatedly by real events (a scan commit, a flush) for
+the daemon's whole life, where re-anchoring on `now` at each of those wakes is
+the correct behavior, not just tolerable on the first one.
+
+This amends ADR-0060, not supersedes it: the two-posture decision, `sync-bom`
+existing in `flush`'s shape, blocking one pass, and serializing with the
+scheduled job are all unchanged. Only the one clause explaining *why*
+`sync-bom` is needed — "the BOM job has none [wake path]" — no longer holds,
+and only for the reason given there: `sync-bom` is still the only way to run
+`sync_endpoint` on demand once the daemon is past its own single startup kick.
+
+## Alternatives considered
+
+- **Leave ADR-0060 accepted as written, fix only the spec.** Rejected: a
+  future reader of ADR-0060 alone would still be told the BOM job has no wake
+  at all, with no pointer to what changed or why — the durable-decision
+  problem CLAUDE.md's ADR discipline exists to prevent.
+- **Fully supersede ADR-0060.** Rejected: every other clause in it — the two
+  postures, `flush`/`sync-bom`'s shape, one blocking pass, serialization with
+  the scheduled job — is unaffected by this change. Retiring the whole
+  decision over one now-stale sentence would erase context that still binds,
+  against the amend/supersede test itself ("does a numbered decision in the
+  old ADR still bind — if one does, it's an amendment").
+- **Reset `_due_at` to `now + interval` unconditionally.** Rejected (P1,
+  first Codex pass): defeats the fleet-wide stagger on every run after the
+  first, not only the first, which was the whole point of `stagger()`.
+- **Preserve the stagger when `_due_at > now` at execution time.** Rejected
+  (P2, second Codex pass): a scan slower than a low-offset host's remaining
+  stagger makes `_due_at` already `<= now` by the time this job's
+  `run_if_due` runs, so exactly the hosts stagger matters most for would fall
+  through to the unstaggered path anyway.
+- **Advance the preserved deadline by exactly one interval.** Rejected (P2,
+  third Codex pass): with a short `--bom-interval`, a delay of more than one
+  interval left the deadline in the past, so the job ran again immediately —
+  no longer the first run — and re-anchored on `now` via the normal path,
+  losing the stagger the fix was meant to keep.
+- **Compute the advanced deadline from the clock read before `run()`.**
+  Rejected (P2, fourth Codex pass): the run itself (an actual upload) can
+  outrun the margin that pre-run reading assumed was safe, on the same
+  short-interval hosts the third pass was about. Measuring from the clock
+  after `run()` returns keeps the deadline honest about time the run itself
+  spent.
+- **Round the delay up to whole intervals with `ceil`.** Rejected (P2, fifth
+  Codex pass): `ceil` leaves the deadline exactly equal to the post-run clock
+  when the delay lands on an exact interval multiple, which `_is_due` still
+  reads as due, running the job again immediately on the normal (no longer
+  preserved) path. `floor(x) + 1` is strictly greater than `x` always, with
+  no boundary left to land on.
+- **Give the BOM job a real, repeating wake** (e.g. on scan commit, like
+  `fleet`). Rejected as out of scope: nothing in the queue is BOM input (a
+  BOM upload is a full inventory snapshot, not a drain of anything a scan
+  writes), so there is no event that should retrigger it before its interval
+  — only the one-time startup case this ADR covers.
+- **Catch the division's `OverflowError` inside `Job` and fall back to
+  `after + interval` on that run.** Tried first (P2, sixth Codex pass; this
+  is what commit `37b1da1` shipped), then rejected once a seventh pass found
+  the case it does not cover: an interval too small to move a large
+  `monotonic()` reading by floating-point addition at all does not raise —
+  it silently drops the deadline back to `now`, so nothing catches it. A
+  `try`/`except` guards one arithmetic failure mode of an unvalidated input,
+  not the input; a sibling failure mode with no exception to catch was only
+  ever one interval choice away. Rejected in favor of refusing the value at
+  `parse_duration`, the boundary every daemon interval already passes
+  through, which closes both failure modes and any other the same missing
+  floor would eventually surface.
+- **Guard the tiny-interval case inside every `Job` caller in `runtime.py`
+  instead of in `parse_duration`.** Rejected: `runtime.py` has four call
+  sites building a `Job` from a parsed setting; `parse_duration` is the one
+  place all four already funnel through, and it is also where `daemon
+  status`'s "duration is too small" message reaches an operator's terminal
+  at `daemon run` time (`test_a_mistyped_interval_fails_at_resolution_not_at_
+  the_first_tick`), rather than a forked process's log file after the fact.
+
+## Consequences
+
+A freshly started daemon uploads its BOM promptly instead of waiting up to
+`--bom-interval` plus a stagger, on every daemon, without collapsing a
+fleet's recurring upload cadence onto one instant. `sync-bom` remains
+necessary for an on-demand run after startup — the BOM job still has no
+recurring wake of its own. `preserve_stagger`'s "first run ever" key assumes
+the flag is only ever set on a job that is woken exactly once, at
+construction; a job that combines `preserve_stagger` with a real recurring
+wake would need the mechanism revisited. Every daemon interval — not only
+`--bom-interval` — now has a one-second floor: `--scan-interval`,
+`--fleet-interval`, `--webhook-interval`, and `--scan-since` all parse
+through the same `parse_duration`, so a value that was always nonsensical
+(a webhook retry cadence measured in nanoseconds) is now refused at
+resolution for those too, not only for the job whose arithmetic happened to
+expose it.
+
+## When to revisit
+
+- If the BOM job ever gains an event-driven wake beyond the one-time startup
+  kick (mirroring `fleet`'s scan-commit wake), `preserve_stagger`'s
+  first-run-only key stops being sufficient, and ADR-0060 clause 2 needs
+  another look alongside it.
+- If `DaemonService.tick()`'s ordering changes so scanning no longer runs
+  ahead of the jobs it wakes, the delayed-first-tick case this ADR's second
+  alternative was rejected for may no longer be reachable — worth confirming
+  before simplifying `preserve_stagger` back to a deadline comparison.
+
+## References
+
+- ADR-0060 — two upload postures, not one command with two sources
+- `docs/specs/daemon-uploads.md` — the BOM job, `sync-bom`, and the stagger
+- `src/stacktrace_cli/daemon/jobs.py` — `Job.preserve_stagger`, `stagger()`
+- `src/stacktrace_cli/daemon/config.py` — `parse_duration`'s one-second floor