Anatomy of a comment

The comment is where most people meet Garboard. Here is every part of it, from the actual template the composer emits.

**garboard** reviewed in 48s · 3 findings

> **Blast radius** — touches `modules/vpc` · consumed by 4 units across 2 envs (prod: 3)

**[critical]** RDS instance is not encrypted at rest
storage_encrypted is absent or false. Every database in this repo is encrypted
with a per-service KMS key. Evidence: `envs/prod/payments.tf:12` · seen in 6/7 resources
[Fix with Garboard]

**[warn]** Resource name is not snake_case
paymentsDb does not match the repo's naming convention. Evidence: `envs/prod/payments.tf:2`

**[info]** Prod database has no deletion protection
deletion_protection is unset on a production database. Evidence: `envs/prod/payments.tf:9`

rcd v7 @ a1b2c3d · dismiss a finding · docs

The header

**garboard** reviewed in 48s · 3 findings

The elapsed time is there on purpose. A review that took 48 seconds is a review that ran; one that says 0s did not do what you think it did.

The count is the number shown, which is at most three. If more were found, the stored review has all of them — the cap belongs to the comment, not to the record.

Context blockquotes

> **Blast radius** — touches modules/vpc · consumed by 4 units across 2 envs (prod: 3)

Context carries no severity and never occupies one of the three finding slots. It is a blockquote so that it reads as a note rather than a verdict. There are exactly two kinds: blast radius, and cost. Both are described in when Garboard says nothing, because both are also the only reasons an otherwise-clean pull request gets a comment at all.

A finding

Four parts, always in this order:

Severity — [critical], [warn] or [info].

A one-line title. Says what is wrong, not what to do.

A body of at most two sentences. The first states the fact. The second, where there is one, says what this repo normally does — “Every database in this repo is encrypted with a per-service KMS key”. That sentence is what makes it a convention finding rather than a lint rule: it is your standard, quoted back to you.

Evidence, as a link. envs/prod/payments.tf:12, linked at the commit the review ran against — not at main, which may have moved. A finding without evidence never appears: the ranker drops it. See findings and severities.

Some findings carry · seen in 6/7 resources. That is the convention’s support: six of your seven do this, and this is the seventh.

The Fix link

[Fix with Garboard] appears on findings Garboard can propose a correction for. It opens the proposed diff. Accepting it commits to your pull request’s head branch, and the fix goes through the same checks your pull request did — see fixes.

The footer

rcd v7 @ a1b2c3d · dismiss a finding · docs

rcd v7 @ a1b2c3d is the exact convention document this review used, and the commit it was derived from. If you think a finding is wrong, this tells you which version of your repo’s conventions produced it. It is rendered from the review, never a constant — a client that hard-codes it is broken.

Attribution

A finding from an adopted catalog rule is marked with the upstream check it mirrors, for example · catalog rule CKV_AWS_21. A finding from one of your own custom rules is identifiable by its custom.* rule id. Built-in rules are attributed by their id namespace — secops.*, reliability.* — rather than by a redundant label.

One comment, edited in place

Push again and the comment is upserted: edited, not added to. A pull request with nine pushes has one Garboard comment showing the current state.