Two pipelines, one workspace, one place to look.

1. The summary comment

Every push that opens or updates an MR triggers the products you have enabled for that repo. When each finishes, the bot drops a single comment with the verdict, the top findings/remarks, and a link to the full report. Re-reviews update the existing comment in place — they never spam the discussion tab.

If both products run on the same MR, you get two summary comments — one per pipeline — so you can read «security said this, review said that» at a glance instead of disentangling them by hand.

2. Inline notes on the diff

Security scans — critical and high-severity findings get an inline note anchored to the exact line. When the AI is confident in the fix, the note carries a native suggestion block: one click in GitLab and the change is committed.

Code review — every remark is its own discussion thread on the changed line. No top-level wall of text, no "scroll to find what I'm being asked about". Each thread carries a "Suppress" chip; click it once and CodeGuards posts the closing reply and resolves the thread in GitLab.

3. The buttons in the comment

• Suppress — silences this finding/remark on this repo. Use it when the bot is wrong; we won't bother you with the same one again. Per-repo, per-fingerprint, with a category-path fallback so a rephrased AI output still hits the same rule.
• Apply suggested fix (Security scans only) — pushes the AI's patch to a side-branch codeguard/fix/.... Open a follow-up MR if you want to ship it.
• Open full report — the per-run dashboard with timeline, AI cost, suppression history, and (for review) the rulebook that fired.

Repository memory improves over time

Accepted suppressions remain scoped to that repository. Architecture expectations accumulate in the rulebook and in what the team has already accepted. Historical decisions persist in the audit trail — who marked what, when, and why.

Repository context reduces repeated discussions: the same "we do this here because…" explanation is recorded once, not rehashed on every merge request.

4. Talking back to the reviewer

Reply in any CodeGuards thread with a question and the reviewer reads the surrounding diff plus the original finding/remark and writes a focused answer. Slash commands work too:

• /codeguards suppress — same as the button. Works for both scan findings and review remarks.
• /codeguards fix — same as Apply suggested fix.
• /codeguards explain — make the bot expand the recommendation in plain English.
• /codeguards help — list every command.

Each thread has a cap on how many AI replies we'll send so we never get into a "are you sure?" loop with an impatient reviewer.

5. Tuning the bot per repo

Open Integrations, find your repo, and tune each product independently:

• Security scans — review style (chill / balanced / strict), minimum severity floor, tone (professional / friendly / blunt).
• Code review — per-repo rulebook controlling which categories are loud (style, naming, tests, error handling, architecture-boundary bypasses) and which are silenced. Defaults match the language/framework we detect.
• Per-repo enablement — toggle each product per repository. Run scans on the public-facing API repo, reviews on the design system, both on your monolith.

Changes apply to the next run — no redeploy, no migration, no run to re-trigger by hand.

6. Architecture boundaries the bot remembers

The Code review pipeline holds a per-repo rulebook that includes your team's architecture decisions — bounded contexts, layered dependencies, "the controller never talks to the model directly" rules. When a diff bypasses one, the reviewer flags it as a remark on the offending line, with a one-line citation of the rule. Suppress once if the bypass is intentional; the team's actual policy stays in version-controlled config, not in a Confluence page nobody reads.

7. Zero-config setup

Connect GitLab (cloud or self-hosted) or GitHub once on the Integrations page. CodeGuards registers the webhook for you, seeds a baseline ruleset for your stack on both products, and starts reviewing the very next push. There is nothing to add to .gitlab-ci.yml or .github/workflows — both pipelines are purely event-driven. CI mode (POST /api/scans/ci, POST /api/reviews/ci) is available if you want to trigger explicitly from a pipeline step instead.

FAQ

Will it spam my MR?

No. One summary comment per product per review, plus inline notes per anchored finding/remark. Re-runs update the existing notes in place. Soft caps prevent runaway threads.

Does it ever push code to my MR branch?

Never. Auto-applied fixes always go to a fresh codeguard/fix/... branch — you decide whether to merge them.

Can I run only one product on a repo?

Yes. Per-repo toggle. You can also start with Security scans on every repo and roll out Code review gradually as you tune the rulebook.

GitLab + GitHub?

Both. GitLab cloud and self-hosted; GitHub cloud. Same product surface on both — inline comments, summary verdict, suppression buttons. The one capability gap: only GitLab supports auto-resolving threads (GitHub's REST API doesn't expose it).