tga audit

The gaps are printed, not filled in

A due-diligence report is read by someone deciding whether to buy the thing it describes. The failure that matters there is not a missing number. It is a number nobody measured, printed as though somebody had.

tga audit has no PERFORMANCE dimension and no COST dimension — nothing in the pipeline measures either one. So the report declares both as gaps rather than scoring them off a proxy.

Failure works the same way. Point the sweep at a config with no JIRA project key and the jira sync stage fails. That failure becomes a named line in Gaps & Caveats. The alternative — a zero in a cell — is indistinguishable from a project that genuinely had no JIRA activity, and the reader has no way to tell which one they are looking at.

Every report-quality bug fixed in the last milestone was that same shape: a partial signal rendered as an authoritative statement.

no JIRA project scope: pass --project <KEY> or set jira.project_key in config.yaml

Point it at a repository set

tga audit audits local checkouts that a config file names. It does not discover or clone anything, so this step is the one that decides what gets audited. tga install is an interactive wizard that writes the config for you; a hand-written one can be as small as a list of repository paths, because every other section has a default.

-c, --config <FILE> is global on tga, so it goes before the subcommand. A missing config logs a warning and runs on defaults rather than failing — which is worth knowing, because an audit of nothing is a report of nothing.

Running it

Six flags, all optional, nothing interactive. Once it starts it never prompts, confirms, or waits for input — start it and walk away.

tga audit

Bare, it reads ./config.yaml and writes ./audit-output. That is the whole minimal invocation.

tga --config config.yaml audit \
  --org acme --client "Acme Holdings" --analyst "J. Reviewer" \
  --weeks 26 --output ./acme-dd

Where the report comes out

Everything lands in the output directory — ./audit-output unless --output says otherwise. The run ends by printing the paths it wrote under Report artifacts, so the last lines on your terminal are the deliverable. The Markdown file is the report; open it first.

If the sweep stopped at the render — the renderer was not installed, or the model call failed — the manifest survived it, because it is written before the renderer is called. Fix the cause and run the last stage by hand; this is exactly what the sweep would have run:

trusty-review report \
  --manifest ./audit-output/manifest.toml \
  --analyze --synthesize --out ./audit-output

Eight stages, in the order the data flows

The numbering is real: each stage writes what the next one reads, which is why they run in this order and not another. A stage that fails is recorded and named in Gaps & Caveats, and the run continues.

1. 1 collect — walks the configured repositories into commits via git2.
2. 2 classify — runs the four-tier classification cascade over those commits.
3. 3 jira sync — ingests JIRA transitions and comments.
4. 4 deployments collect — deploy events into fact_deployments.
5. 5 incidents collect — incidents into fact_incidents.
6. 6 dora — reduces those two fact tables to the four DORA keys.
7. 7 pr-metrics — per-engineer pull-request metrics; writes pr-metrics.csv.
8. 8 report — renders tga's own CSV, JSON and Markdown.

What lands in the output directory

Up to 18 files, from three producers.

The report, section by section

Eight sections, in this order. A model writes the executive summary, the top-risk rationale, and the RED/AMBER finding prose, working only from what the sweep collected — every figure it cites is checked against that data and the sentence is dropped if the figure is not there. Section 2 falls back to a roll-up composed from the report's own counts whenever that check rejects the written one.

Red, amber, green — and what routes a finding there

The colours are the report's own convention, and the mapping is mechanical: the diagnostic's own severity decides, nothing else.

What the last fix actually changed

Measured on one run, over the ripgrep repository, before and after the report stage was corrected.

The 20 pre-fix RED entries were all "Extract method" refactor suggestions misrouted into RED. The two non-code components were CHANGELOG.md and FAQ.md, scored as if they were applications. The complexity buckets summed to a round 1,000 instead of the 4,328 units actually counted.

All three are the same defect wearing different clothes: output that looked like a measurement and was not one.

What this does not do

The buyer's alternative is a tool that would have guessed at all six of these. Read this section as part of the pitch, not as a disclaimer at the bottom.