Pure aggregation of the Tier 1 closed verify loop (BOU-101).
The shell runs the steps that need I/O — generate/write (scaffolder), kondo, FC/IS, run the affected tests — and hands the raw per-step results here. This namespace turns them into the single structured report the agent reads to self-correct: a flat list of issues (file, line, BND code, kind, expected/actual) plus an overall verdict. No I/O, no side effects.
The loop the report describes: generate → write → kondo → Malli/FC-IS → run affected core tests → report
Issue :severity drives the verdict:
:error — kondo error, FC/IS (BND-806) or convention (BND-807) violation,
or a failing test. Blocks (:status :fail) unless soft and
overridden.
:warning — kondo warning; never blocks.
FC/IS (BND-806) and convention (BND-807) issues are soft guardrails: an
audited {:allow true} override turns a would-be :fail into :overridden
("guardrail, not straitjacket", ADR-032). kondo errors and test failures
are hard — they are never overridable, because they mean the generated code
does not compile or does not pass.
Pure aggregation of the Tier 1 closed verify loop (BOU-101).
The shell runs the steps that need I/O — generate/write (scaffolder), kondo,
FC/IS, run the affected tests — and hands the raw per-step results here.
This namespace turns them into the single structured report the agent reads
to self-correct: a flat list of issues (file, line, BND code, kind,
expected/actual) plus an overall verdict. No I/O, no side effects.
The loop the report describes:
generate → write → kondo → Malli/FC-IS → run affected core tests → report
Issue `:severity` drives the verdict:
:error — kondo error, FC/IS (BND-806) or convention (BND-807) violation,
or a failing test. Blocks (`:status :fail`) unless soft and
overridden.
:warning — kondo warning; never blocks.
FC/IS (BND-806) and convention (BND-807) issues are *soft* guardrails: an
audited `{:allow true}` override turns a would-be `:fail` into `:overridden`
("guardrail, not straitjacket", ADR-032). kondo errors and test failures
are *hard* — they are never overridable, because they mean the generated code
does not compile or does not pass.(build-report steps)(build-report {:keys [generate kondo fcis tests]} {:keys [overridden?]})Assemble the structured verify report from raw per-step results.
steps keys (all optional — a step the shell skipped is simply absent):
:generate {:success bool :files [{:path :action}] [:errors]}
:kondo {:findings [clj-kondo finding ...]}
:fcis {:violations [check-fcis violation ...]}
:tests {:status :passed|:failed|:error|:unavailable
[:passed n] [:failed n] [:failures [...]] [:note ...]}
opts:
:overridden? — caller passed an audited {:allow true}; soft issues then
yield :overridden instead of :fail.
Returns: {:status :pass | :fail | :overridden :complete? bool ;; false when a step couldn't run :issues [ ... flat, ordered kondo→fcis→tests ... ] :counts {:errors n :warnings n} :steps {<step> <summary>} ;; compact per-step status [:overridable? bool]} ;; present when soft issues blocked
:complete? is false when the affected tests did not actually run (the
runner errored, or none was configured): then :status :pass means "passed
what ran", not "fully verified". An errored test step also adds a
:verify-incomplete warning issue (never blocks); the expected
no-runner-configured case (:unavailable) only lowers :complete?.
Assemble the structured verify report from raw per-step results.
`steps` keys (all optional — a step the shell skipped is simply absent):
:generate {:success bool :files [{:path :action}] [:errors]}
:kondo {:findings [clj-kondo finding ...]}
:fcis {:violations [check-fcis violation ...]}
:tests {:status :passed|:failed|:error|:unavailable
[:passed n] [:failed n] [:failures [...]] [:note ...]}
`opts`:
:overridden? — caller passed an audited `{:allow true}`; soft issues then
yield `:overridden` instead of `:fail`.
Returns:
{:status :pass | :fail | :overridden
:complete? bool ;; false when a step couldn't run
:issues [ ... flat, ordered kondo→fcis→tests ... ]
:counts {:errors n :warnings n}
:steps {<step> <summary>} ;; compact per-step status
[:overridable? bool]} ;; present when soft issues blocked
`:complete?` is false when the affected tests did not actually run (the
runner errored, or none was configured): then `:status :pass` means "passed
what ran", not "fully verified". An errored test step also adds a
`:verify-incomplete` *warning* issue (never blocks); the expected
no-runner-configured case (`:unavailable`) only lowers `:complete?`.(passed? report)Did the verify loop pass (no blocking issues, or all blocking issues were soft and overridden)?
Did the verify loop pass (no blocking issues, or all blocking issues were soft and overridden)?
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |