Skip to main content
← back to extensions

Swamp Triage

@sntxrr/swamp-triagev2026.08.04.4· 1d agoMODELSWORKFLOWS
01README

Investigate why any swamp model or workflow is failing, without knowing anything about the domain it automates. Every method and workflow run leaves a @swamp/method-summary or @swamp/workflow-summary report behind as versioned model data, written on failure as well as success — so the full history of a target is already on disk with nothing extra instrumented. investigate resolves a target by name at call time, walks that history back to the boundary where it stopped working, and classifies the error into auth / unreachable / timeout / tls / rate_limit / not_found / config, each with a concrete next step. The distinction it exists to make is auth vs unreachable: a remote answering 403 is healthy and rejecting your credential (go to the vault), while a remote that never answers is a network problem (go to the host) — the two read almost identically in a notification and lead opposite ways. Unrecognised errors are reported as unknown verbatim rather than filed under a plausible-looking category. Read-only: it reads what previous runs recorded and never invokes the failing target.

02Models1
@sntxrr/swamp-triage/investigationv2026.08.04.1swamp_triage.ts

Global Arguments

ArgumentTypeDescription
repoDir?stringRepository root to investigate. Defaults to the repo the model runs in.
fn investigate(target: string, kind: enum, maxVersions: number)
Investigate why a model or workflow is failing. Resolves the target
ArgumentTypeDescription
targetstringName of the model or workflow to investigate.
kindenumWhich definitions to search. 'auto' searches models then workflows.
maxVersionsnumberHow many recorded runs to walk back through when looking for the

Resources

investigation(infinite)— A classified finding for one investigated model or workflow.
03Workflows2
@sntxrr/investigate-apprise1d18f54e-b7f1-433d-a5e1-0d37c79de3fd

Investigate why any model or workflow in this repo is failing, and raise the finding through Apprise. Domain-agnostic: the target is named at run time, so this is the same workflow whether the thing that broke talks to a network controller, a DNS server, or an object store. swamp workflow run @sntxrr/investigate-apprise --input target=<name> Requires @sntxrr/apprise-notify and a model instance of it named `apprise`: swamp extension pull @sntxrr/apprise-notify swamp model create @sntxrr/

investigateRead the target's recorded history and classify the failure
1.collecttriage.investigate— Resolve the target by name, walk its summary-report versions back to the last success, and classify the recorded error. When the target is a workflow, this also follows the failing step into the model that step invoked -- a workflow summary names the step but not its error, so stopping at the workflow level would report `detect-drift failed` and omit the actual cause. Identifiable secret values are redacted from the error here, before the finding is written, so the notification below cannot carr
reportNotify through Apprise when the target is actually failing
1.notify-findingapprise.notify— Gated by a step `guard` rather than by the notifier's own arguments. A guard is a CEL predicate over step output, which `dependsOn` conditions cannot express -- those are status-based only. Truthy guard means SKIP, so this reads as "skip when notification is turned off, or when the target turned out to be healthy". Deliberately not the notifier's `when` argument, even though Apprise offers one: the guard keeps the gate identical in this workflow and in `investigate-ntfy`, whose notifier has no s
@sntxrr/investigate-ntfycd960c91-5a03-47f0-8823-b272a37cbbad

Investigate why any model or workflow in this repo is failing, and post the finding straight to ntfy. Domain-agnostic: the target is named at run time, so this is the same workflow whether the thing that broke talks to a network controller, a DNS server, or an object store. swamp workflow run @sntxrr/investigate-ntfy --input target=<name> Requires @mgreten/ntfy-notify and a model instance of it named `ntfy`: swamp extension pull @mgreten/ntfy-notify swamp model create @mgreten/ntfy-noti

investigateRead the target's recorded history and classify the failure
1.collecttriage.investigate— Resolve the target by name, walk its summary-report versions back to the last success, and classify the recorded error. When the target is a workflow, this also follows the failing step into the model that step invoked -- a workflow summary names the step but not its error, so stopping at the workflow level would report `detect-drift failed` and omit the actual cause. Identifiable secret values are redacted from the error here, before the finding is written, so the notification below cannot carr
reportPost to ntfy when the target is actually failing
1.notify-findingntfy.send— Gated by a step `guard` rather than by the notifier's own arguments. A guard is a CEL predicate over step output, which `dependsOn` conditions cannot express -- those are status-based only. Truthy guard means SKIP, so this reads as "skip when notification is turned off, or when the target turned out to be healthy". This notifier has no gating argument of its own -- `send` always sends -- so the guard is the only thing standing between a healthy target and a phone buzzing at 3am. It is the same g
04Previous Versions3
2026.08.04.3

Added 2 workflows

2026.08.04.2
2026.08.04.1
05Stats
A
100 / 100
Downloads
0
Archive size
31.4 KB
  • Has README or module doc2/2earned
  • README has a code example1/1earned
  • README is substantive1/1earned
  • Most symbols documented1/1earned
  • No slow types (deprecated)1/1earned
  • Dependencies pass trust audit2/2earned
  • Has description1/1earned
  • Platform support declared (or universal)2/2earned
  • License declared1/1earned
  • Verified public repository2/2earned
Repository
https://github.com/sntxrr/swamp-triage
06Platforms
07Labels
#triage#investigation#diagnostics#failure-analysis#incident#meta#swamp