FAQ: A Model Comment Is Not a CODEOWNERS Approval

I keep meeting the same myth in review threads.
A model comment gets treated as a real approval.
Would you merge on a sentence with no owner?

That habit shows up when free access feels easy.
A draft appears, a shell looks calm, and people relax.
Easy access is not the same thing as evidence.

The claims I keep correcting

I hear three claims more often than I like.
Each one sounds practical until you ask for proof.
Then the thread goes quiet in a hurry.

Myth one: a comment is CODEOWNERS

A model can suggest a reviewer name in prose.
That sentence does not satisfy a CODEOWNERS rule.
GitLab still expects the eligible human to approve.

Have you checked who is actually eligible here?
I treat a named rule as the only approval that counts.
A polite bot line is just another comment.

If the rule list is empty, say that in the thread.
Do not invent eligibility because the prose sounds sure.
Confidence is not a seat on the approval list.

Myth two: a scratch transcript is the audit log

A free server transcript can help you remember a try.
It is not an audit log your team can retain.
Sessions can reset, expire, or hide the full command.

Would you bet a release review on that scrollback?
I would not trust scrollback after a refresh.
I want a job URL that the project still serves.

Copy the useful line into the scratch note file.
Leave the durable receipt on the merge request.
A vanished tab cannot defend you next month.

Myth three: a rewrite means the tests moved too

A tidy rewrite can hide a missing test change.
The model may describe a test it never added.
Have you opened the test file, or only the chat?

I diff the test paths before I trust the prose.
If those paths are untouched, the claim is unfinished.
Words about coverage are not coverage in the commit.

A quick path check

# example: unexecuted; swap origin/main for your base
git diff --name-only origin/main...HEAD

Compare that list with the files the rewrite mentioned.
If tests are absent, keep the claim in the scratch box.
Do not promote that claim into a receipt yet.

The corrected mental model

Hold three boxes, and do not let them merge.
Suggestions, scratch runs, and receipts have different jobs.
Only receipts can support a real merge click.

• A suggestion can warn, draft, or ask a question.
• A scratch run can try a command off the laptop.
• A receipt names the SHA, the job, and the approver.

I label scratch notes so they cannot impersonate receipts.
I refuse to hide a missing job behind fluent prose.
Does your comment name the box it belongs to?

Promotion between boxes is the bug I care about.
A good draft can move into a commit after review.
It cannot move into the approval row by tone.

An evidence contract you can run

I use four plain files as a proposed local contract.
This script is an unexecuted example, not a benchmark.
You should adapt paths before you trust it.

#!/usr/bin/env bash
# proposal: unexecuted example, not a measured result
set -euo pipefail

need() {
  local path="$1"
  if [[ ! -s "$path" ]]; then
    echo "missing evidence: ${path}" >&2
    exit 1
  fi
}

need evidence/commit.txt
need evidence/pipeline-url.txt
need evidence/approval.txt
need evidence/scratch-note.txt

commit_now="$(git rev-parse HEAD)"
commit_noted="$(tr -d '[:space:]' < evidence/commit.txt)"

if [[ "${commit_now}" != "${commit_noted}" ]]; then
  echo "commit drifted: noted ${commit_noted} head ${commit_now}" >&2
  exit 1
fi

if grep -Eq '(glpat-|ghp_|AKIA)[A-Za-z0-9_-]{8,}' evidence/scratch-note.txt; then
  echo "scratch note looks like it holds a token" >&2
  exit 1
fi

echo "evidence contract ok for ${commit_now}"

What the script is willing to claim

Run the check from the repository root first.
A missing file should fail closed, every time.
A drifted commit SHA should fail closed too.

The token grep is a coarse tripwire, not a scanner.
It will miss clever encodings and private keys.
Still, I keep it to block the lazy paste.

What you record once per revision

mkdir -p evidence
git rev-parse HEAD > evidence/commit.txt
printf '%s\n' 'https://gitlab.example.com/group/app/-/pipelines/123' > evidence/pipeline-url.txt
printf '%s\n' 'approved by: sam - rule: code-owner' > evidence/approval.txt
printf '%s\n' 'scratch: model draft only, not a pipeline result' > evidence/scratch-note.txt
bash evidence-check.sh

Those sample URLs are placeholders, not real jobs.
Replace them with links from your own project.
Keep tokens and private diffs out of the files.

I would commit the checklist script, not the secrets.
I would think hard before committing scratch notes.
If the note quotes a private diff, leave it local.

A decision table for tired reviewers

I read this table before I type an approval.
It stops me from upgrading a hint into proof.
Use it when the comment sounds finished too early.

What you hold	What it can support	What it cannot support
Model comment or rewrite	A question, a risk, or a draft	CODEOWNERS approval or ownership
Free server shell transcript	A disposable repro attempt	A retained audit log
Rewrite prose about tests	A hint to open the test diff	Proof the tests moved
Job URL for the same SHA	A receipt others can open	A human approval by itself
Named approval on the rule	The human decision	That tests ran, unless linked

If your proof sits in the right column, stop.
Ask for the missing receipt instead of more prose.
A second model pass will not fill an empty rule.

Where free model access actually fits

Disclosure: This article was prepared as part of MonkeyCode's product outreach.
MonkeyCode's free model access can draft the scratch note.
Its free server option can host a scratch command.

I am not stating quotas, hardware, model names, or uptime.
Treat both as the scratch box, never as the receipt.
Ask for risks and questions, not for a merge blessing.

A narrow prompt worth keeping

Review this diff for missing tests and secret leaks.
Do not claim that any pipeline already passed.
Do not invent reviewers or any CODEOWNERS eligibility.
List uncertainties as questions I can check later.

Paste useful warnings under a heading called scratch.
Link the job URL for the same commit beside it.
Keep the approval line human, named, and rule-based.

If you already have that free access, park it there.
The merge button still waits on your evidence contract.
That is the only soft ask I will make here.

Four questions I leave on the thread

I do not debate style when the myth appears.
I ask which box is missing, in four lines.
Short questions beat a long lecture every time.

1. Which commit SHA did the pipeline actually run?
2. Where is the job URL for that same SHA?
3. Who approved, and which rule made them eligible?
4. What stayed scratch-only, and what is a receipt?

If the author cannot answer, the thread is not done.
Fluency is not a substitute for those four lines.
I would rather see a red script than a shiny paste.

A bad note versus a usable note

Model approved this on the free server, so I am merging.
That sentence mixes all three boxes into one blur.
I would reject it before I read the diff.

Scratch only: possible nil deref on the empty list.
Receipt: pipeline 123 for SHA abc, approval by sam.
Those two lines keep the boxes from impersonating each other.

The bad note feels faster in a tired afternoon.
The usable note takes one extra minute to write.
Which one can a stranger audit next week?

Limitations you should not skip

This checklist does not replace branch protection settings.
It does not prove the tests were honest or complete.
It does not audit the runner image or the cache.

A person can still type fake text into the files.
Your real control is the job plus the approval rule.
The script only catches empty claims and drifted SHAs.

I have not timed this flow, and I publish no scores.
Free access can change, pause, or differ by account.
Do not build a release gate that assumes it stays.

Do not send tokens or private diffs to a scratch host.
If policy forbids external models, skip the prompt entirely.
The files still work with a human scratch note.

The grep pattern is intentionally small and obvious.
Do not treat it as a secret-scanning product.
Add your real scanner in CI if policy demands one.

Who should not use this approach

Skip this flow when you need signed release attestation.
Skip it when compliance demands a locked runner only.
Skip it when the change touches production secrets.

Also skip it when no merge request exists yet.
A solo notebook is not a shared team record.
Write the evidence where reviewers can actually open it.

New teammates can use the table as a reading aid.
They should not treat it as a GitLab admin manual.
Your project's approval rules still win every argument.

Maintainers of regulated repos should not outsource judgment.
A free scratch host is a poor place for that duty.
Keep those reviews on the systems your policy names.

Verify platform facts before you trust me

I am describing a review habit, not a product spec.
Confirm approval rules in the current GitLab documentation.
UI labels move, and I will not pretend they froze.

Open your project settings for merge request approvals.
Then open the CODEOWNERS file on the default branch.
If those settings disagree with this FAQ, trust them.

I am not reporting quotas, latency, or a success rate.
I did not run a survey, and I will not invent one.
Your project settings are the facts that matter here.

Before you click merge

Before you merge, read the three boxes out loud.
Is the model text still labeled as scratch only?
Does the job URL match the commit in the file?

If either answer wobbles, do not click merge yet.
Fix the evidence, then run the script again.
That habit beats another fluent rewrite in the thread.