Namespace Kuestenlogik.Bowire.Reporting

Classes

BowireReportReader

Reads the artefacts Bowire writes and folds them into per-service rows (#587).

Deliberately parses the file formats rather than deserialising into the producing packages' types. A rollup exists to answer a question across services, so the reports come from other repositories, other machines and other Bowire versions — assuming the package that wrote a report is loaded in the process reading it would defeat the purpose. It also means a field added upstream doesn't break the reader.

Format detection goes by content, not by file name: CI jobs name these things whatever they like, and a results.json could be any of four shapes.

BowireReportSource

One artefact the rollup read, kept alongside the row it fed so a reader can trace a number back to the file it came from (#587).

BowireRollup

The assembled portfolio view (#587).

BowireRollupPayload

The canonical JSON shape of a rollup, shared by every surface that emits one (#587): GET /api/report/rollup, bowire report rollup --json and the bowire.report.rollup MCP tool.

It exists for the same reason #364 grew one: serialising the model directly let the CLI emit an enum ordinal where the endpoint emitted a string, so a script could not treat the surfaces alike. One projection, no drift.

BowireServiceReport

The rolled-up state of one service (#587) — what a platform team asks about a portfolio: is anything failing, how bad, and how fresh is the answer.

Every count is nullable on purpose: a service with no lint report at all is a different statement from one with zero findings, and flattening both to 0 would let a missing report read as a clean bill of health.

Enums

BowireReportKind

Kind of artefact a rollup row was fed by (#587).

BowireRollupSeverity

Severity ladder the rollup gate compares against (#587).