DEV Community: Jordan Huang

FAQ: A Free Model Lease Is Not a Server Lease

Jordan Huang — Tue, 13 Oct 2026 14:03:27 +0000

Your free model just said the patch landed cleanly. Did the free server actually accept that same patch? I keep seeing this leap in review threads.

A cheap answer turns into a deploy story fast. Then that box still serves yesterday's old binary. Who actually owns that gap in your story?

Why does this myth keep winning?

People still love one receipt for two separate gifts. A free model session feels like real compute. A free server option feels like real hosting.

I keep hearing them merged into one stack. That quiet merger is the actual bug here. Those two leases can fail on their own.

MonkeyCode offers free model access and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I treat those lines as availability claims only.

I do not treat them as a quota sheet. I will not invent model names in this note. I will not invent hardware or duration either.

If a console shows numbers, those numbers win. A screenshot from last month is not a contract. Write the date next to any number you paste.

Which claims keep showing up?

These lines show up after a green chat. Each one sounds practical at first quick glance. Each one quietly skips a real host receipt.

"The model wrote the file, so the server has it."
"The free box is up, so the model saw my repo."
"One retry covers both the chat and the host."
"Free access means this path is a release path."
"A health URL alone proves the patch bytes."

Do you want a cleaner mental model now? I split this world into two separate ledgers. A model ledger records only the model calls.

A server ledger records files and live processes. Neither ledger inherits the other side's lease. You store both lines before you claim a win.

Myth 1: Is the reply the diff?

The model can describe a file almost perfectly. That text still lives only in the transcript. It is still not an inode on the host.

I ask one blunt question every single time. Where is the content hash from that host? If you cannot paste it, you do not have a diff.

Corrected model: generation is not the same as placement. Placement still needs a write on that host. Then you hash the exact path you named.

Myth 2: Did a live box see the repo?

A free server can boot with an empty home. Your repo may sit only on your laptop. Uptime alone does not mount your git remote.

I check three facts before I trust a read. Which user account is actually running that process? Which directory is the real current working directory?

Which git remote URL is actually configured there? I write those three answers in the note. I do not accept a shrug as an answer.

Corrected model: reachability is not the same as context. Real context means a cwd plus working credentials. Without those facts, the model is only guessing.

Myth 3: Can one retry heal both sides?

A model retry only spends another model call. A server retry restarts a process or job. Those clocks are not the same clock.

People mash one shared button for both failures. The chat pane retries all on its own. The host still keeps the old process running.

Which failure did you actually mean to hit? Name it in the note before you click again. A second click without a name is noise.

Corrected model: name the failing ledger before you retry. You then retry only that one failing ledger. Record the new id beside the old id.

Myth 4: Does free mean release-ready?

Free access only answers a narrow cost question. It does not answer a real promotion question. A real release needs owners, logs, and rollback.

I would not ship customer traffic this way. A small demo can still live here safely. A production pager should not depend on this.

Corrected model: price and promotion are different gates. You should pass the cheap gate first here. Then you pass the release gate on purpose.

Myth 5: Does health prove the bytes?

A 200 from /health means the process answered. It does not mean your patch is on disk. It does not mean the model read that disk.

I want a content hash, not a smile code. You compare the content hash you actually expected. Then compare the hash the host actually prints.

Corrected model: liveness is not the same as integrity. Integrity is a digest over the named path. Liveness is only a short timeout story here.

What is the corrected picture?

Hold two leases in your head at once. A model lease buys only fresh text generation. A server lease buys a place to run.

A lease does not copy files by sympathy. A lease does not share retries with the other. You reconcile them with hashes and call ids.

A two-ledger decision table

Use this table before you start the argument. Pick the row that actually matches the evidence. Do not pick the row that matches the vibe.

Evidence you hold	Model ledger	Server ledger	What you may claim
Transcript only	Call happened	Unknown	The model spoke
Host hash only	Unknown	File exists now	The box has bytes
Both ids and same hash	Call happened	Write matches	Placement matched this call
Health 200 only	Unknown	Process answered	The process is up
Retry of chat only	New call id	Old state likely	You did not retry the host

Read that last column out loud before you post. If it feels smaller than your Slack message, shrink the message. I do this small check before I reply.

An unexecuted check you can copy

This script is a proposal, not a lab report. I have not executed it against your host. Please label it that way in your notes.

It assumes a local shell on the server. It assumes curl and sha256sum both exist there. It does not assume any vendor product name.

#!/usr/bin/env bash
set -euo pipefail

# UNEXECUTED EXAMPLE. Fill paths from your own session.
MODEL_ID_FILE="${MODEL_ID_FILE:-./model_call_id.txt}"
EXPECT_HASH_FILE="${EXPECT_HASH_FILE:-./expected.sha256}"
TARGET="${TARGET:-./app.py}"
HEALTH_URL="${HEALTH_URL:-http://127.0.0.1:8080/health}"

echo "ledger,key,value"

if [[ -f "$MODEL_ID_FILE" ]]; then
  model_id="$(tr -d '[:space:]' < "$MODEL_ID_FILE")"
  echo "model,call_id,${model_id}"
else
  echo "model,call_id,MISSING"
fi

if [[ -f "$TARGET" ]]; then
  host_hash="$(sha256sum "$TARGET" | awk '{print $1}')"
  echo "server,path,${TARGET}"
  echo "server,sha256,${host_hash}"
else
  echo "server,path,MISSING"
  host_hash=""
fi

if [[ -f "$EXPECT_HASH_FILE" ]]; then
  expect="$(awk '{print $1}' "$EXPECT_HASH_FILE")"
  echo "compare,expected,${expect}"
  if [[ -n "$host_hash" && "$host_hash" == "$expect" ]]; then
    echo "compare,match,yes"
  else
    echo "compare,match,no"
  fi
else
  echo "compare,expected,MISSING"
fi

health_code="$(curl -s -o /dev/null -w '%{http_code}' --max-time 3 "$HEALTH_URL" || echo curl_fail)"
echo "server,health_http,${health_code}"
echo "server,user,$(id -un)"
echo "server,cwd,$(pwd)"

Keep paths free of commas or the row splits. sha256sum is a coreutils command, not a shell builtin. If it is missing, use shasum -a 256 instead.

Run it on the server, not on your laptop. Save that stdout right next to the transcript. That saved pair is your only real artifact.

bash two_ledger_check.sh | tee receipts.tsv

Then I ask these three plain questions next. Does that saved model call id look real? Does the compare match field actually say yes?

Does the server health field say 200 now? A missing call id means you never left the story. A match of no means the bytes differ.

A curl_fail means you checked the wrong port. A timeout is not a hash match in disguise. I record the raw line before I interpret it.

Commands I paste beside the chat

I do not trust a paragraph without a command. I paste these commands right after the script. Each one answers one broken table cell only.

id -un && pwd && git rev-parse --show-toplevel
git status --short && git rev-parse HEAD
stat -c '%U %Y %n' ./app.py
sha256sum ./app.py
ss -ltnp | awk 'NR==1 || /:8080/'

The id line tells me the user and cwd. The git line tells me whether a repo exists. The stat line tells me owner and mtime.

The hash line is the server ledger entry. The socket line shows who holds the port. If git rev-parse fails, stop claiming a repo read.

That failure is evidence, not a tool bug. A dirty work tree is not a successful write. An empty git status is not a model confession.

The stat flag in that snippet is GNU specific. On macOS, switch to stat -f before you run it. ss may hide process names without extra rights.

Treat a blank process field as unknown, not proof. A hidden process name is not a clean bill. I would rather see unknown than invent an owner.

How I read a mismatch

Start with the smallest broken cell you see. Please do not restart the whole world yet. I want one cause, not a new myth.

Missing model id: save the call id before you edit.
Missing path: you targeted the wrong cwd or user.
Hash mismatch: the write went elsewhere or never ran.
Health fail: the process is down or bound elsewhere.
Health pass plus hash miss: liveness lied about bytes.

Each bullet is a next command, not a vibe. I paste the command output under the bullet. Then the whole review thread gets much quieter.

What this check does not prove

A matching hash is still a narrow win. It only says this path matched this digest. It does not say your tests already passed.

It does not say the free option lasts. Availability can still change without a blog post. Check the console on the day you care.

It does not name a model for you. It does not set a quota for you. Those fields belong to the vendor page you can see.

I am not claiming any benchmark in this note. I am not claiming any customer result here. If I lack a number, I leave the cell blank.

Who should skip this check?

Skip this flow if you need a signed release. Skip it if your policy forbids free hosts. Skip it if secrets would land in a transcript.

Skip it if you cannot open a shell on the box. The check script needs that shell to be open. A screenshot of chat cannot replace that shell.

Skip it if two teams share one free box. You will not know who wrote the file. Get a private path on that box first.

A short close

I still like free model access for drafts. I still like a free server for a sandbox read. I do not let either receipt sign the other.

If you want that pair, try MonkeyCode and keep both receipts. The current docs should beat any sentence I wrote. Your own console should beat both of them.

Myth FAQ: Three Papers a Green Badge Cannot Sign

Jordan Huang — Tue, 13 Oct 2026 10:38:28 +0000

Did your free server paint the job green?
People still call that badge a signed contract.
I do not buy that story at all.

A green badge answers only one small question.
Something ran once, on some machine, under rules you may not share.
Which repeated claims still hide inside that badge?

I keep four of them in this FAQ.
Each one gets a claim, a check, and a cleaner model.
None of those claims gets a free pass from me.

What I mean by a receipt

I want three papers before I trust a change.
The chat note only counts as paper one.
The job log only counts as paper two.

The runner contract only counts as paper three.
Paper one can be fluent and still wrong.
Paper two can be green and still narrow.

Paper three holds registration, tags, and protection flags.
Can one free minute really replace all three?
No, one minute cannot replace the other papers.

It can only fill paper two, and only for that run.
Ask yourself which paper you are actually holding.
If you cannot name it, you are still guessing.

Myth 1: A free job shares production tags

The claim

Here is the claim I want to retire first.
The project is the same, so the runner class matches.
That leap quietly skips the runner registration step.

The check

Shared capacity and your group runner still differ.
They can share a YAML file and still diverge.
A script match is not a machine match.

What can you actually read after the run?
Look for CI_RUNNER_ID inside the saved job log.
Look for CI_RUNNER_TAGS in that same job log.
Look for CI_RUNNER_DESCRIPTION when the instance prints it.

Empty tags are not some hidden allow-list.
Missing tags are not your real production tags.
A different id means a different contract today.

The corrected model

So what is the corrected mental model here?
Tags are an allow-list, not a friendly vibe.
Name the tag when a private registry is required.

If the free server lacks that tag, stop.
That green run never walked the private path.
Do not promote the result into a release note.

Myth 2: Protected variables ride every free job

The claim

Here is another claim I want retired next.
The variable lives on the project, so every job gets it.
Storage on the settings page is not runtime exposure.

The check

GitLab has long limited protected variables by ref.
They show up on protected branches and protected tags.
They stay hidden on ordinary feature-branch pipelines.

Confirm that exposure rule on the docs you trust.
The flag CI_COMMIT_REF_PROTECTED is what I read first.
The string true and the string false differ.

Those two strings mark two different security worlds.
A feature-branch job often prints false right there.
That job cannot prove your deploy token works.

A missing value is the expected result, not a puzzle.
Did someone paste the raw value into chat?
Stop before the model even answers that prompt.

The corrected model

A useful receipt never needs the secret itself.
Keep the variable name and the protection flag.
Record whether this job could see the name.

What model should replace that casual claim now?
Storage, exposure, and proof are three separate steps.
Free compute does not promote your feature branch.

Free model access does not widen variable scope.
A chat replay of a secret is not a test.
It is a leak with extra steps attached.

Myth 3: Fluent prose validated your YAML

The claim

A softer claim shows up after a late edit.
The model rewrote the job, so the rules are safe.
Reading text is not the same as scheduling work.

The check

I already file a chat draft as an unread diff.
This myth still sneaks past that careful habit.
Local consistency can still fail on your runner.

An image name can exist in prose and fail.
A service alias can look tidy and stay unreachable.
A needs edge can be valid text and still wait.

What do I ask the model to produce instead?
I ask for an assumption list I can check.
Which image tag did you assume is present?

Which runner tag did you assume is registered?
Which ref protection state did you assume holds?
Which files does this job actually execute today?

The corrected model

Then I check those lines against the job page.
I do not ask the model to bless the pipeline.
I ask it to expose every quiet guess.

What is the cleaner model I keep nearby?
A suggestion is a diff that carries footnotes.
The footnotes are the useful part of the reply.

The confident closing sentence is just optional noise.
If a footnote has no log line, park it.
Come back only when paper two already exists.

Myth 4: One green run freezes tomorrow

The claim

This claim shows up when a demo felt smooth.
It passed on the free server, so tomorrow will match.
Tags float, caches drift, and mirrors move overnight.

The check

The tag alpine:3.20 is a label, not a digest.
A retag can change bytes without touching your YAML.
A cleared cache can turn one job into another.

I pin by digest when the job gates a release.
I treat cache keys as speed, not as correctness.
I store the job URL beside the commit SHA.

The corrected model

Does a free server make pinning less urgent?
It makes image pinning more urgent for me.
You control that host less than a private runner.

What should you remember after the sample passes?
A pass is one sample, not a freeze-frame.
Store the sample id where you can reopen it.

Do not store a vibe about the environment.
Tomorrow's queue can land on another host.
Your YAML did not freeze that host for you.

A receipt script you can review first

I have not executed this script on your runner.
Treat the file as a proposal, then review it.
It prints facts a normal job already holds.

It does not print secret values on purpose.
Why do I use unset instead of a filler word?
The dash form keeps an empty value empty.

The colon form would hide that difference.
Empty tags and unset tags are different facts.
You can rehearse those branches on a laptop.

This stand-in does not contact GitLab at all.
No token belongs in this local practice command.
The tag line should be empty, not the word missing.

Print the file if your grep behaves differently.
Do not fix the script until you can explain it.
A short job can publish that text file.

Use artifact when always if failed jobs still matter.
Never echo variables that hold tokens or keys.
RECEIPT_IMAGE_HINT is only a label you chose.

GitLab will not invent an image digest for you.
Resolve the digest in a step you already trust.
Then write that digest into the receipt yourself.

#!/bin/sh
# Proposal only. Review before you add it.
set -eu
out="${1:-ci-receipt.txt}"
{
  echo "job_id=${CI_JOB_ID-unset}"
  echo "pipeline_id=${CI_PIPELINE_ID-unset}"
  echo "job_url=${CI_JOB_URL-unset}"
  echo "sha=${CI_COMMIT_SHA-unset}"
  echo "ref=${CI_COMMIT_REF_NAME-unset}"
  echo "ref_protected=${CI_COMMIT_REF_PROTECTED-unset}"
  echo "runner_id=${CI_RUNNER_ID-unset}"
  echo "runner_desc=${CI_RUNNER_DESCRIPTION-unset}"
  echo "runner_tags=${CI_RUNNER_TAGS-unset}"
  echo "image_hint=${RECEIPT_IMAGE_HINT-unset}"
} > "$out"

# Local stand-in. This does not contact GitLab.
export CI_JOB_ID=1001
export CI_PIPELINE_ID=55
export CI_JOB_URL=https://gitlab.example/jobs/1001
export CI_COMMIT_SHA=abc123def456
export CI_COMMIT_REF_NAME=feature/demo
export CI_COMMIT_REF_PROTECTED=false
export CI_RUNNER_ID=9
export CI_RUNNER_DESCRIPTION=shared
export CI_RUNNER_TAGS=
export RECEIPT_IMAGE_HINT=alpine:3.20
sh ci-receipt.sh /tmp/ci-receipt.txt
grep -q 'ref_protected=false' /tmp/ci-receipt.txt

receipt:
  stage: test
  image: alpine:3.20
  variables:
    RECEIPT_IMAGE_HINT: alpine:3.20
  script:
    - sh ci-receipt.sh ci-receipt.txt
  artifacts:
    when: always
    paths:
      - ci-receipt.txt

A digest check can live beside the receipt file.
I have not run this against your registry.
Point it at the image you actually ship.

# Proposal. Point this at the image you ship.
docker buildx imagetools inspect alpine:3.20

The decision table I keep open

I keep a small table beside the log.
Each row splits real proof from wishful reading.
I read each row from left to right.

If the right cell blocks my claim, I stop.
I go and collect the missing paper instead.
Wishing harder does not fill that empty cell.

Field	What it proves	What it never proves
CI_JOB_URL	Where to reopen that run	That a later run matches it
CI_COMMIT_SHA	Which commit was checked out	That default-branch YAML matches
CI_COMMIT_REF_PROTECTED	Whether this ref is protected	That every variable was exposed
CI_RUNNER_ID	Which runner accepted the job	That registration survives tomorrow
CI_RUNNER_TAGS	Tags reported for this job	That production tags were implied
Image hint	The label you claimed to run	The bytes, unless you pinned a digest

Where a free model and a free server fit

I still want a first pass on the assumption list.
I still want one real job log I can archive.
MonkeyCode offers free model access and a free server option for that narrow drill.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Those two options are availability claims I was given.
I am not naming a model or quoting a quota.
I am not describing hardware, duration, or a benchmark.

I am not claiming the offer stays open forever.
How do I keep that help inside a narrow lane?
I paste redacted logs, never raw secret values.

I ask for assumption lists, never a pipeline blessing.
I run the receipt script on the free server once.
I compare runner id and tags with the contract.

I refuse to treat a chat summary as paper three.
Why is the free server still worth one trial?
It can fail in a log you can archive.

A missing tag shows up as a skip or an error.
A protected ref flag shows up as plain text.
Why is a free model still worth that first pass?

It stays patient with those boring rules diffs.
It will list branches I skip when I am tired.
It cannot see runner registration unless you provide it.

Want a low-stakes place to practice this split?
Run the receipt once on that free server option.
Then keep only the job URL you can reopen.

Limits I will not talk past

This script trusts predefined variables in the job.
A compromised runner can still lie inside a log.
A green file from a hostile host is not notarized.

I am not offering a security certification here.
I am offering a habit that catches common mix-ups.
Your compliance team may still require a private runner.

Image digests need a resolver you already trust.
The hint variable does not compute those digests.
Copying a tag into the file is a label, not a pin.

Local stand-ins use fake ids on purpose.
They prove how the script branches on empty values.
They prove nothing about your current GitLab version.

Check the variable list for the instance you run.
Shared capacity can be queued or simply unavailable.
A failed start is not proof your YAML is invalid.

Read the job page before you rewrite the config.
A queue delay is not a logic bug in your rules.
Separate capacity pain from a real contract miss.

Who should skip this approach

Skip this when the job handles production secrets.
A free server is the wrong rehearsal room for that.
Use a protected runner and a protected ref instead.

Skip this when you need a stable performance number.
One free job is a single sample, not a benchmark.
I will not pretend that sample is a percentile.

Skip this when your policy forbids external runners.
Availability on a page is not permission to use it.
Your security review outranks a convenient job log.

Skip this when a model asks you to paste a token.
No check in this FAQ needs a live secret.
Redact the log, then ask the question again.

What I do on the next red job

I open the job URL before I read the chat.
I copy the runner id, the tags, and the ref flag.
I ignore the model's first paragraph until those exist.

Then I ask one narrow question of the draft.
Which assumption here contradicts these three logged lines?
That question keeps the chat inside its lane.

Does the green badge still matter after all that?
Yes, it still matters as paper two only.
It never gets to sign paper three for me.

FAQ: Which Myths Die When the Job Id Changes?

Jordan Huang — Tue, 13 Oct 2026 05:00:26 +0000

Did your last retry orphan the log you just pasted?
I treat that move as a review risk now.

Someone fails a job, hits retry, then asks a model.
The written answer sounds sharp while the cited job sits stale.

A fluent paragraph is not a fresh job trace.
I want a mental model I can check before I reply.
Have you closed a thread on a job you already left?

Why this keeps wasting review time

I look at pipeline pages more often than chat panes.
A later green attempt can sit beside an older red one.
People still quote the older red one in the thread.

So I collect the claims that survive a retry click.
They sound practical until you compare two job ids.
Have you trusted a note after that id already changed?

Five claims I still hear

People claim a retry keeps the same job evidence.
People claim a free server reran the project runner.
People claim the model already saw the newer trace.
People claim quick agreement means the cause is found.
People claim free model access replaces runner minutes.

Each claim fails a different field check on the job.
I walk them in that order on purpose.
The id check comes before any story about the cause.

Myth 1: A retry keeps the same evidence

People say a retry is the same job, only cleaned.
I do not treat that sentence as API truth.
A job retry creates a new job record in GitLab.

The older job remains visible in the pipeline history.
Its trace stays attached to the older job id.
Your new buttons point at a different job id.

Corrected model: a retry is a new attempt.
The same stage name does not mean the same evidence.
I match ids before I trust any explanatory sentence.

Confirm this on your own instance docs before you script it.
The Jobs API is the source I trust for those fields.
A blog memory is not a substitute for that page.

Myth 2: A free server reran your runner

This myth appears when a laptop feels too slow.
Someone starts a free server and pastes the failing script.
The script exits zero, so they call the pipeline fixed.

MonkeyCode is an open source project I use for that desk.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I use its free model access to draft one hypothesis.
I use its free server option only as a scratch desk.
I do not treat that desk as the project runner.

A free server has your shell, not the runner tags.
It does not hold the project's protected variables.
It does not mint the job token your script expects.

Corrected model: that box can rehearse a snippet you own.
The runner is still the only place the job ran.
If the desk and the runner disagree, I believe the runner.

Myth 3: The model saw the newer trace

A model answers from the text you chose to paste.
If you pasted the first failure, that text is the world.
A later retry does not reach the model by magic.

I watch for line numbers that exist only in the old log.
The newer job log often does not contain those lines.
That mismatch is a citation bug, not a deep insight.

Did you upload the newer trace, or the comforting one?
Corrected model: context is a snapshot you selected.
No new snapshot means no claim about the latest attempt.

Myth 4: Quick agreement means the cause is found

A confident paragraph can feel like a closed root cause.
I treat that tone as a guess with clean grammar.
A model that agrees quickly is not a witness.

Two causes can share one error string in the log.
A cache miss and a bad lockfile can look alike.
Only the newer job can split those two stories.

Corrected model: verbal agreement is not real attribution.
I want a prediction I can falsify on the next run.
If that prediction stays vague, I do not merge it.

Myth 5: Free model access replaces runner minutes

People talk as if a token pool were a CI budget.
I have not verified any cap, duration, or hardware size.
I will not quote a number I cannot source today.

Read the current product page before you plan a week.
Caps and clocks move, and docs should beat memory.
My working rule is smaller than any hallway rumor.

Corrected model: model access buys drafting time only.
Runner minutes buy the evidence a reviewer can open.
Those meters are different, so I do not swap them.

Faster notes, same-age evidence

The model can answer faster than I can scroll a log.
The job evidence does not get younger while I read.
Speed in the chat does not refresh a finished_at stamp.

That is the gap I care about on a review day.
A smoother paragraph can still cite a dead attempt.
I would rather be slow and attached to the current id.

The check I keep beside the thread

I do not need a new platform to spot a stale note.
I download two job JSON payloads from the Jobs API.
Then I compare the fields a retry is supposed to change.

Keep the token outside the chat window and the prompt.
I use a personal access token limited to read_api.
I never paste that token into a model conversation.

curl --silent --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  "${GITLAB_URL}/api/v4/projects/${PROJECT_ID}/jobs/${OLD_JOB_ID}" \
  -o old_job.json

curl --silent --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  "${GITLAB_URL}/api/v4/projects/${PROJECT_ID}/jobs/${NEW_JOB_ID}" \
  -o new_job.json

Fetch the trace only after the id check passes.
The trace endpoint is a separate download from the job JSON.
I still refuse to drop either file into a shared prompt.

curl --silent --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  "${GITLAB_URL}/api/v4/projects/${PROJECT_ID}/jobs/${NEW_JOB_ID}/trace" \
  -o new_trace.log

This script is a proposal, not a benchmark I already ran.
Run it only on JSON you downloaded from your instance.
Do not send private traces where your policy forbids that.

#!/usr/bin/env python3
"""Flag a model note that still cites a pre-retry job."""

import json
import sys
from datetime import datetime

def load(path):
    with open(path, encoding='utf-8') as handle:
        return json.load(handle)

def stamp(value):
    if not value:
        return None
    return datetime.fromisoformat(value.replace('Z', '+00:00'))

def main():
    cited = load(sys.argv[1])
    current = load(sys.argv[2])
    notes = []
    stale = cited.get('id') != current.get('id')
    if not stale:
        notes.append('ids match; this pair is not a retry split')
    cited_sha = (cited.get('commit') or {}).get('id')
    current_sha = (current.get('commit') or {}).get('id')
    if cited_sha != current_sha:
        notes.append('commit sha differs; do not share one story')
    cited_pipe = (cited.get('pipeline') or {}).get('id')
    current_pipe = (current.get('pipeline') or {}).get('id')
    if cited_pipe != current_pipe:
        notes.append('pipeline id differs; widen the search')
    finished = {'success', 'failed', 'canceled'}
    if current.get('status') not in finished:
        notes.append('current job is not finished')
    cited_done = stamp(cited.get('finished_at'))
    current_done = stamp(current.get('finished_at'))
    if cited_done and current_done and cited_done >= current_done:
        notes.append('cited finish is not older than current finish')
    print('stale_citation=%s' % str(stale).lower())
    print('cited_job=%s' % cited.get('id'))
    print('current_job=%s' % current.get('id'))
    for note in notes:
        print('note=%s' % note)
    return 2 if stale else 0

if __name__ == '__main__':
    sys.exit(main())

python3 check_retry_citation.py old_job.json new_job.json
echo "exit=$?"

I want a true stale flag before I discard the older note.
If that flag is false, I still read the trace myself.
Matching ids means I have not moved attempts yet.

Those sample ids are placeholders, not jobs from a real project.
I include them only so the print shape is obvious.
Do not treat the numbers as evidence from any pipeline.

stale_citation=true
cited_job=111
current_job=222
note=cited finish is not older than current finish

The clicks I make after the flag

Fetch the cited job JSON with a read-only token.
Fetch the current job JSON from the same project.
Run the citation check before you answer the thread.
Paste a newer trace only after the flag says you left.
Write one falsifiable prediction, then retry a single job.

When the citation flag is true

The model note cites a job you have already left.
I keep the note as a hypothesis, not as a verdict.
I open the newer job URL before I answer the thread.

When the commit sha also changed

Now I have two builds, not one confusing failure.
A retry on a new commit is a different tree.
I stop mixing those logs inside one review sentence.

When the newer job is still running

There is no finished trace worth a confident explanation.
I wait, or I read the live log with my own eyes.
A model cannot finish a job that is still queued.

A table I use before I comment

Claim I hear	Field I check	What I do next
Retry kept the same log	job `id`	Fetch the newer job before commenting
Free server proved the fix	job `runner`	Re-run on the real runner tag
Model saw the latest failure	trace you pasted	Paste the newer trace or stop
Confident cause is enough	one testable prediction	Write it, then retry once
Token pool covers CI	nothing in the job JSON	Keep runner minutes as a separate budget

I use that table in review, not in a slide deck.
One matching row should change my next click.
If no row changes a click, I am collecting trivia.

Limits I refuse to sand away

This script only sees JSON you have already fetched.
It does not open or diff the trace body itself.
Two jobs can share a sha and still fail differently.

The finished_at field can be null while a job is running.
I treat a null finish as not evidence yet.
Laptop clocks can also drift away from GitLab time.

Protected logs may arrive redacted on your instance.
A redacted trace can hide the line that matters.
I do not ask a model to invent those missing bytes.

Self-managed GitLab can lag the docs I happen to remember.
Confirm the Jobs API on your instance before you automate it.
I am describing a local check, not certifying your server.

Free model access can be limited or withdrawn later.
The free server option is not an uptime promise.
I did not benchmark either option for this draft.

Who should skip this habit

Skip this if policy forbids external model tools entirely.
A security review is not a scratch-desk exercise.
Do not upload secrets, token-bearing traces, or customer data.

Skip this if you need a signed release attestation.
A chat note will not satisfy a careful auditor.
Your release job still has to run inside the real project.

Skip this if you cannot name the job id yet.
Without an id, you are debating a mood.
I would rather wait for the pipeline page to load.

What I do on the next red job

I copy the newer job id into the issue first.
I write one prediction in a single plain sentence.
Then I retry, and I let the newer trace judge it.

If I want help wording that prediction, I use a free model session.
I run the id check on the free server, away from the runner.
Then I return to GitLab and read the job that finished.

When I need that scratch desk, I open MonkeyCode first.
Then I leave it and read the job that actually finished.
That sequence is the whole habit I trust.

Older logs can teach you, but they cannot close a retry.
Which job id is your comment still citing right now?

Myth FAQ: A Clone Does Not Register the Runner

Jordan Huang — Tue, 13 Oct 2026 03:59:51 +0000

Did your open shell just register a runner for you? I keep seeing that leap in pipeline review notes. The files look familiar, so the leap feels easy.

A copied tree is not a runner process on GitLab. A prompt that can edit YAML is not registration. I want both distinctions taped above the editor.

Why this myth keeps returning

You open a remote shell and clone the project. A model then drafts a register sketch beside you. Someone still asks why the jobs sit queued.

I ask this whenever the only evidence is a transcript. Have you watched that same gap in your own reviews? The missing step is almost never more YAML prose.

What I will not pretend to know

I do not have a lab log for your project. I will not invent quotas, hardware, or uptime numbers. I will not name models I cannot verify here.

The operator notes I was given say two things only. MonkeyCode has free model access and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Those notes do not turn a shell into CI. They only name a place where a draft can live. The proof still has to come from GitLab itself.

Claim one: a clone is not registration

Developers repeat this right after a clone succeeds. The shell has the tree, so they expect jobs next. GitLab does not schedule work from a clone alone.

A runner must be registered before it can poll. That step writes local config after an admin action. Your clone uses your credentials, not that config path.

What I accept as evidence

GitLab documents registration as its own runner step. I link public docs later so you can recheck them. I am not quoting a private admin screen here.

Claim two: YAML tags do not grab a desk

People paste docker tags into the CI file and relax. They think the word docker binds their open shell. Tags match registered runners, not the mood of a prompt.

Your job waits until some runner advertises that tag. An interactive box does not advertise tags by existing. Have you checked the runner list in the project UI?

Claim three: a drafted command has not run

Free model access can draft a command that looks finished. Drafting is not execution on the host you mean. Execution on that host is still not successful registration.

I want three artifacts before I believe a runner exists. I want a transcript that hides every secret value. I want verify output plus a job log with a runner id.

If any artifact is missing, I still have only a story. Stories do not pick up jobs that remain queued. Do you still approve the merge on the story alone?

Claim four: a free desk is not shared capacity

A free server option can give you an interactive host. That host is a desk, not a fleet membership card. I will not claim how long that desk stays available.

Shared runners are configured by an admin on the instance. Your open shell stays absent until someone registers it. Should a coding desk inherit production job traffic at all?

I would not send protected jobs to an unowned desk. Protected variables follow separate rules from a plain shell. Read the current variable docs before you assume any exposure.

Claim five: docker on the host is not an executor

This claim shows up when the desk can run containers. People see a docker binary and assume the executor type. Executor type is config, not a package that happens to exist.

What the config decides

A shell executor can live on a machine that also has docker. The image key applies only to executors that honor images. Does your config name shell, docker, or something you never checked?

Claim six: job tokens do not follow the repo

A job token exists inside a running job only. It does not follow you into a random SSH session. If the probe prints absent, you are outside that job.

People paste tokens into chat so a model can finish. Please do not hand registration secrets to any transcript. A registration secret stays secret, even inside a helpful draft.

Token field names also change across GitLab versions. I will not freeze one register flag set in this FAQ. Check the registration page that matches your instance version.

A corrected mental model

Hold three objects apart when a pipeline claim arrives. The editor host is the place where you type commands. The runner process is what polls GitLab for new work.

The job process is what exports the predefined CI variables. Free model access sits with the editor, not with the runner. It can propose YAML, a probe, or a register sketch.

Prose cannot mint a runner id on the GitLab side. A free server option remains that editor host until registration. Remove the product name and this same split still holds.

You still have a host, a runner, and a job process.
Those three doors still need three different keys today.
Mixing those keys is how this myth survives a review.

Probe you can copy

The next script is a proposal, not a result I collected. Run it yourself on the host you actually control. Do not print secret values into shared output.

#!/usr/bin/env bash
# Proposed identity probe. Not an executed lab result.
set -u

echo "section=identity"

if [[ -n "${CI_JOB_ID:-}" ]]; then
  echo "ci_job_id=present"
else
  echo "ci_job_id=absent"
fi

if [[ -n "${CI_RUNNER_ID:-}" ]]; then
  echo "ci_runner_id=present"
else
  echo "ci_runner_id=absent"
fi

if [[ -n "${CI_PIPELINE_ID:-}" ]]; then
  echo "ci_pipeline_id=present"
else
  echo "ci_pipeline_id=absent"
fi

if [[ -n "${CI_JOB_TOKEN:-}" ]]; then
  echo "ci_job_token=present"
else
  echo "ci_job_token=absent"
fi

if command -v gitlab-runner >/dev/null 2>&1; then
  echo "gitlab_runner_binary=present"
else
  echo "gitlab_runner_binary=absent"
fi

if command -v docker >/dev/null 2>&1; then
  echo "docker_binary=present"
else
  echo "docker_binary=absent"
fi

if [[ -r /etc/gitlab-runner/config.toml ]]; then
  echo "runner_config_readable=yes"
else
  echo "runner_config_readable=no"
fi

How I read the bundle

Read those printed lines as one bundle, not isolated wins. Absent job variables mean you are standing outside a job. A missing binary means that host is not polling yet.

A missing config means registration has not landed there. It can also mean you cannot read the config path. Either reading blocks the claim that this runner is live.

Docker present beside runner absent is a useful split. The package can exist while no executor is configured. Do not let the container tool close that gap for you.

Decision table before I trust a desk

I use this table before I trust an open coding desk. The right column is the gate I refuse to skip. The left column is how the myth usually enters chat.

Claim in chat	Smallest honest check	Still not enough
The shell cloned the repo	`git rev-parse --short HEAD`	No runner id
Tags appear in the YAML	Runner UI shows those tags	No online match
A model wrote a register sketch	Diff of that sketch only	No verify output
A runner binary exists	`command -v gitlab-runner`	No readable config
Docker exists on the host	`command -v docker`	Executor still unknown
Verify names a configured runner	Redacted verify output	No picked-up job log
A job log shows a runner id	`CI_RUNNER_ID` present in that log	Not proof for other tags

The middle column is only the smallest honest check. Pass that check, then still demand the right-hand column. A partial row is not a registered runner yet.

Commands that separate a story from a runner

Ask the host what it is before you grant it trust. These commands are examples for a shell you control. Skip any path your security policy forbids outright.

command -v gitlab-runner || echo "binary_absent"
gitlab-runner --version || true
gitlab-runner verify || true
gitlab-runner list || true

List and verify only read local runner configuration. They do not create a runner by themselves. If those commands fail, the myth remains only a myth.

Inside a real job, print presence instead of token text. The snippet below is an example, not a pipeline I ran. It proves nothing until some registered runner picks it up.

probe_runner_identity:
  stage: test
  script:
    - test -n "$CI_JOB_ID" && echo "ci_job_id=present"
    - test -n "$CI_RUNNER_ID" && echo "ci_runner_id=present"
    - test -n "$CI_RUNNER_TAGS" && echo "ci_runner_tags=present"
    - test -n "$CI_RUNNER_EXECUTABLE_ARCH" && echo "runner_arch=present"
  rules:
    - if: $CI_PIPELINE_SOURCE == "web"

A queued pipeline is a waiting state, not a passing job. Did your last success come from this job or a typed shell? I want that answer written beside the two transcripts.

The web source rule keeps this sample off ordinary pushes. Older instances may omit some of those runner variables. Compare the predefined variable list for the version you run.

What those free options can honestly do

Use free model access to draft the probe and the snippet. Use a free server option as the interactive host only. Stop once the draft exists and identity is still unproven.

The model should not receive registration secrets or job tokens. Do not describe that server as shared runner capacity. I have no basis for capacity, region, lifetime, or speed claims.

If a generated command includes a raw secret, delete that draft. Rotate the secret if it already left your password manager. A helpful completion can still be a credential leak.

Who should not use this desk pattern

Skip this pattern when you need audited production runners. Skip it on protected release branches and compliance gates. Skip it whenever policy forbids hosts you do not administer.

Also skip it if you came looking for a speed benchmark. This FAQ covers runner identity, not model latency numbers. I am not publishing timings, hardware notes, or quota math.

Admins who already operate a fleet can ignore this myth list. They need their current config review, not another coding desk. I am writing for people who confuse a desk with that fleet.

Limits of this probe

The probe cannot read group runner settings it cannot access. It cannot prove tag policy stored only on the GitLab side. It cannot prove that a paused runner will accept work later.

Your config file may live on a different install path. A readable file is not the same thing as a healthy runner. Verify can fail because the stored credential already expired.

Documentation pages move, so recheck the runner guide first. I am describing stable roles, not a dated changelog entry. If your instance is old, compare that version's admin docs too.

Questions I ask before I close the review

I ask these questions before I close this kind of review. A missing answer means the desk is still only a desk. Can you answer each one without pasting a secret?

Where is that runner registered: project, group, or instance?
Which tags does that runner advertise in the UI today?
Does the job log show a runner id, or only a prompt?
Who can read the runner config file on that host?
Did any secret enter a model transcript during this change?

If you cannot answer those five, do not call it registered. Ask for the missing artifact instead of another YAML rewrite. A short refusal is cheaper than a release left queued.

One comparison worth keeping

If you already have MonkeyCode's free server option, start on that host. Run the shell probe there before you trust the generated sketch. Then place that output next to a log from a runner you registered.

Keep both transcripts inside the same review comment. That comparison is the only next step I want here. I am not offering uptime numbers, queue times, or extra certainty.

Sources to recheck before a ticket

I am linking public GitLab pages for the roles named above. Open each page before you paste a conclusion into a ticket. If a page has moved, follow the current registration guide.

These links point at public documentation, not at your instance version. Self-managed menus can lag or rename a token field. Treat the live admin docs as the final word on flags.

FAQ: A Free Shell Cannot Borrow Your Runner Tag

Jordan Huang — Mon, 12 Oct 2026 19:46:27 +0000

I keep hearing one claim in GitLab review threads.
A free server cloned the repo, so it counts as a runner.
Is a shell with git really a runner?
I do not think that claim holds up.

A runner is a process GitLab already knows.
It has an id, tags, and a job history.
A side shell has a checkout and a prompt.
Those two objects are not the same thing.

Why this FAQ exists

I am not posting a speed benchmark here.
I am not naming a chip, a quota, or a timer.
I want a corrected mental model you can test.

You run the checks on your own project.
Then you keep the job trace, not my opinion.
Five claims show up when someone demos a side server.

Each claim sounds practical until you ask for ids.
I answer each one with a check, not a vibe.
Confirm the linked docs on the day you try them.

Myth 1: A clone is registration

People say the repo is on the box, so it is a runner.
GitLab lists runners only after you create one.
A git clone never adds a row to that list.

The runner process must register and stay reachable.
The checkout is just files on a disk.
Open Settings, then CI/CD, then the Runners page.

If that host is missing, it is not your runner.
Docker on the box does not close this gap.
An executor binary is not a registration record.

Read the runner guide before you trust a demo.
The current page is GitLab runners.
Use your version's create-runner flow, not an old snippet.

You can also ask the API with your own read token.
Use it only on a project you maintain.
Do not paste that token into a chat log.

# Proposal: read-only. Run on your machine. I did not run this for you.
test -n "${GITLAB_TOKEN}" && test -n "${PROJECT_ID}" && test -n "${GITLAB_URL}"
curl --silent --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
  "${GITLAB_URL}/api/v4/projects/${PROJECT_ID}/runners"
command -v gitlab-runner || printf 'gitlab-runner binary absent\n'

An empty array means no project runner is registered.
A free shell hostname appears only after registration.
That missing row is the myth in one check.

Myth 2: YAML tags grab any host

People say YAML tags bind whatever host they SSH into.
Tags match a job to runners you already registered.
An unknown host is not in that match set.

GitLab leaves the job pending when nothing fits.
Job tags select registered runners, not random servers.
A shared shell prompt is not a tag match.

Here is a probe job I would put on a branch.
It is a proposal, not a pipeline result.
I have not executed it for this article.

# Proposal only. Commit it on a throwaway branch if you choose.
runner_identity_probe:
  stage: test
  tags:
    - probe-only
  script:
    - test -n "${CI_RUNNER_ID}"
    - test -n "${CI_JOB_ID}"
    - test -n "${CI_JOB_URL}"
    - printf 'runner=%s job=%s\n' "${CI_RUNNER_ID}" "${CI_JOB_ID}"
    - printf 'trace=%s\n' "${CI_JOB_URL}"

If no runner has the tag, the job stays pending.
A free server can still run those lines by hand.
That manual run never creates a job id.

A pending job in GitLab is the honest signal.
Read the tags reference before you loosen rules.
Untagged runners are a project choice, not a default gift.

Myth 3: Exported names mint a job

People export CI=true and expect a job token.
The job token is injected into a running job.
The job id and runner id arrive the same way.

A hand export can print names without issuing secrets.
Job identity is issued by GitLab for that run.
You cannot type a trace into the environment.

Run the loop on the side shell before you trust it.
Expect those job fields to be absent there.
Do not print secret values into tickets or chat.

# Proposal: side-shell identity probe. Absent means this is not a job.
for name in CI_JOB_ID CI_JOB_URL CI_JOB_TOKEN CI_RUNNER_ID CI_RUNNER_TAGS CI_PIPELINE_ID; do
  if printenv "${name}" >/dev/null; then
    printf '%s=present\n' "${name}"
  else
    printf '%s=absent\n' "${name}"
  fi
done

A present name without a job URL is not enough.
Read the job token page before you reuse one.
Scope on that page is not your laptop environment.

Myth 4: A maintainer shell sees protected values

People say maintainers may read protected variables anywhere.
Protected variables go to pipelines on protected refs.
GitLab injects them into that job's environment.

Your SSH session is not that protected pipeline.
Your role in the UI is not an injection path.
Protection follows the pipeline, not your other login.

Confirm the current page before you depend on a toggle.
I will not guess extra switches from memory.
Open protect a CI/CD variable on test day.

If that page adds a runner condition, follow the page.
Do not haul protected values out to a scratch host.
A demo that needs them is already on the wrong machine.

Myth 5: The side box can mint the job JWT

People say cloud login on the free server matches the job.
ID tokens are minted for a job by GitLab.
The cloud trusts GitLab's issuer and those claims.

An outside process does not hold the signing key.
Federation trusts the job token, not a lookalike.
If the token variable is missing, you are outside the job.

# Proposal only. GitLab mints this inside a real job. Never echo the token.
deploy_oidc_probe:
  stage: test
  id_tokens:
    GITLAB_OIDC_TOKEN:
      aud: https://example.invalid
  script:
    - test -n "${GITLAB_OIDC_TOKEN}"
    - printf 'oidc_token=present\n'

Never print that token into logs or chat.
Read ID token authentication before you copy a sample.
A fake JWT from a script will fail issuer checks.

Myth 6: A zero exit is a green pipeline

People say a zero exit means the pipeline is green.
A job trace carries a job URL and a runner id.
It also carries section timing from the runner.

Your shell history has an exit code and a clock.
Those two records do not point at each other.
Local success is a rehearsal, not pipeline status.

Compare fields, not feelings, before you approve.
Names below are the usual predefined set.
Confirm them on the predefined variables page.

Field	Inside a real job	On a free shell
CI_JOB_ID	Numeric id from GitLab	Absent unless you fake it
CI_JOB_URL	Link that opens the trace	Absent
CI_RUNNER_ID	Id of the runner that picked the job	Absent
CI_RUNNER_TAGS	Tags of that runner	Absent
CI_PIPELINE_ID	Id of that pipeline	Absent
Exit code	Result of the job script	Your local process only

A faked export can fill names from the left column.
It still will not create a job URL that opens.
Open that URL, or you do not have a job trace.

Where a draft shell still helps

I still want a scratch place to edit the probe.
I do not want that draft to pretend it is CI.
MonkeyCode offers free model access and a free server option.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.
That pair is enough to edit YAML and run the loop.
It is not enough to wear your runner tag.

Draft there if you want, then prove the runner id.
Stop when the check needs secrets, deploys, or a release tag.
A useful draft still ends at the runner list.

Decision table I keep beside the config

I keep this table beside the pipeline config.
Use it when a demo skips the runner list.
Each row is a claim, a check, and a model.

Claim I hear	Check I run	Corrected model
Clone means runner	Project runner list or runners API	Registration creates the runner
Tags bind my SSH host	Job pending without a tag match	Tags select registered runners
export CI mints a token	printenv on job fields	GitLab issues job identity
Maintainer may read protected vars	Ask where injection happened	Protection follows the pipeline
Side box signs the cloud JWT	Look for a real id token in the job	The issuer is GitLab, not the shell
Zero exit means green pipeline	Open CI_JOB_URL	Status lives in GitLab

Who should not use this split

Skip this split when the risk sits in the draft.
These cases should stay on a trusted runner.

Your policy forbids third-party compute for repository files.
The branch holds production secrets or customer data.
You need an audit trail for the draft step itself.
You are about to deploy, tag, or rotate keys.
You cannot separate a rehearsal log from a job trace.

Keep those secrets inside GitLab's protected variable path.
Do not paste them into a side prompt to save time.
If the draft host is untrusted, do not clone the repo there.

Limits I will not smooth over

This article is a method, not a lab report.
I did not execute the probe on your project.
I did not measure speed, cost, or uptime.

Free model access and the free server can change.
I am not claiming they are permanent or unlimited.
A model can misread rules, needs, or tags.

The runner creation steps differ by GitLab version.
Use the current UI, not an old token snippet.
Docs pages move, so open the links on test day.

A passed probe does not grant registry or deploy rights.
Use GitLab's predefined variables page as the name list.
Cache, images, and service accounts are separate checks.

The model I want in review

Hold three layers apart when someone says CI passed.
Ask which layer wrote the log in front of you.

The draft shell can edit files and run local checks.
The registered runner can pick up a tagged job.
The pipeline record can show the job and runner ids.

Which layer produced the log you are reading?
If the answer is the draft shell, you have a rehearsal.
If the answer is a job URL, you have a trace.

I would keep this checklist in the repo as a proposal.
I would update it when the runner docs change.
I would not let a green prompt skip the runner list.

FAQ: A Green Free Shell Is Not a Retry Rule

Jordan Huang — Mon, 12 Oct 2026 13:00:17 +0000

Did one free shell pass, so you widened retry?
I keep that question on a worksheet before any edit.
A green shell is a clue, not a finished rule.

The debate I am trying to slow down

Retry talk gets sloppy after a cheap reproduction.
Someone pastes a later pass and calls the flake gone.
I want a class for the failure before YAML changes.

I am not publishing a fleet study or a private metric.
I am handing you a worksheet you can run on one log.
Treat every result as local notes, not as merge approval.

Myth one: a later pass means it was a blip

The thin story

People treat one later pass as proof of a blip.
That story skips the failure class, by rush or by habit.
A blip, a dirty cache, and a bad script can all recover.

What would actually support a transient platform class?
You need the first failure text, not only the second pass.
You also need the same image, script, and inputs.

What I require instead

Would you widen retry from a story that thin?
I would not, and the worksheet exists to block me.
Corrected model: classify the miss, then pick a when list.

A pass without a class is only a second sample.
Two samples still do not author a policy commit.
If the class is unknown, the edit waits for quotes.

Myth two: the free shell is the runner

Questions the shell cannot answer

A free interactive box can feel like the job.
You see the same repo, commands, and green text.
The runner still owns image, tags, cache, and secrets.

Did you pin the digest the failed job actually pulled?
Did your shell add tools the CI image never had?
Did the cache key differ between those two attempts?

I do not assume hardware, region, duration, or permanence.
Those facts move, and this FAQ will not freeze them.
Parity is a checklist you can fail, not a mood.

Myth three: the model should choose `retry.when`

Draft label, not a commit

A model can read a log and sound completely sure.
Sure text in a chat is not a policy commit.
A wide retry can hide a script bug for days.

Have you watched a summary agree with your hunch?
I treat that agreement as a draft, then I discard it.
Agreement is cheap when a bad when list is not.

I use model help only to draft a bucket label.
I still map that draft onto documented when values.
If your version docs disagree, the docs win the edit.

Myth four: cheap exploration means cheap retries

Two different bills

A free shell makes a second run feel almost free.
That feeling mixes exploration cost with production damage.
They are different bills, paid by different people.

A wrong retry spends shared runner time and reviewer trust.
It can also mask a step that is not idempotent.
Cheap exploring does not make a guessed rule safe.

Would you retry a migrate because the shell felt cheap?
I hope the answer is no, and the table agrees.
Cost of curiosity is not cost of a bad merge.

Four buckets before anyone touches YAML

I split one failed job into four buckets first.
This table is a proposal, not a measured study.
Fill one row from a real log, then stop writing.

Bucket	Evidence required	Retry stance	Do not claim
Transient platform	Runner system text, timeout, or API failure lines	Narrow `when` list only	That every timeout is safe
Dirty cache	Outcome changes when the cache key is cleaned	Fix the key first	That retry heals a bad key
Script defect	Same miss on a clean shell and in CI	Do not add retry	That a later pass deletes it
Unknown	Missing job id, image line, or command exit	No policy change	That a summary closed the gap

Commands that collect facts, not vibes

Run these in a clone, not inside a generated summary.
They print local git facts and a retry search.
They do not call an API, and they need no token.

git rev-parse --short HEAD
git status --porcelain
test -f .gitlab-ci.yml && echo "ci file present"
grep -n "retry:" .gitlab-ci.yml || echo "no retry key found"

Save the failed job log outside the chat window.
Then point a small search at that file only.
If the search is empty, you are stuck in unknown.

JOB_LOG="${1:?pass a saved job log}"
grep -nE "ERROR:|exit code|timed out|system failure" "$JOB_LOG" | head -n 40
grep -nE "Using docker image|Pulling docker image" "$JOB_LOG" | head -n 20

Silence from either search is not a clean bill.
Silence means the bucket stays unknown for this change.
Unknown means you do not edit retry in that request.

A cache check that retry loves to skip

People blame the runner when the cache key is the bug.
I want that possibility visible before I blame the platform.
A retry will happily replay a poisoned cache for you.

grep -nE "cache:|key:|paths:" .gitlab-ci.yml
git log -1 --oneline -- .gitlab-ci.yml

Ask whether the key includes the lockfile that changed.
Ask whether two jobs share a key but not paths.
If you cannot answer, mark dirty cache or unknown.

A heuristic script you must not trust blindly

I also keep a tiny classifier next to the worksheet.
It is an unexecuted proposal with obvious over-match risk.
It must never open a merge request by itself.

#!/usr/bin/env bash
# Proposal only. Heuristic. Do not pipe this into git commit.
set -eu
log="${1:?pass a saved job log}"
if grep -E -q "system failure|stuck_or_timeout|API failure|execution took longer" "$log"; then
  echo "bucket=transient_platform_candidate"
elif grep -E -q "script failure|exit code 1" "$log"; then
  echo "bucket=script_defect_candidate"
else
  echo "bucket=unknown"
fi
echo "next=quote lines and confirm against current GitLab docs"

Why does the script print candidate instead of verdict?
Because a keyword can appear in a red herring line.
You still owe a human quote before any YAML edit.

The first matching branch wins, even when both patterns hit.
That is why the label says candidate, not verdict.
A timeout line plus a script error still needs your eyes.

Feed it a synthetic fixture before you trust the shape.
This fixture is fake text I wrote for the demo.
It is not a log from a real pipeline run.

ERROR: Job failed (system failure): execution took longer than expected
Using docker image sha256:example-not-a-real-digest

Expected output is a candidate line, plus the next hint.
If your real log prints unknown, believe that unknown.
Do not massage the regex until it flatters your plan.

A YAML shape you still have to verify

This fragment is an unexecuted example for discussion.
Copy the when names only after your docs confirm them.
I am not claiming this list stays complete forever.

lint_job:
  script:
    - sh ci/lint.sh
  retry:
    max: 2
    when:
      - runner_system_failure
      - stuck_or_timeout_failure
      - api_failure

Why is script_failure missing from that when list?
A script failure is often your bug, not the platform.
Retrying it can turn a fast red into a slow lie.

Confirm the allowed max for your version before you copy two.
Some versions cap retries below what a chat will suggest.
A copied max that the linter rejects is not a clever rule.

Set the image to the digest from the failed job.
A floating tag can change between the fail and the pass.
If you cannot pin it, stay in the unknown bucket.

Read the current retry keyword before you copy names.
Start from the GitLab CI YAML reference, then search retry.
Your version page beats this snippet if they disagree.

Check the primary YAML reference before you trust my names.
I linked the docs root so a moved anchor cannot trick you.

https://docs.gitlab.com/ci/yaml/

Where free model access and a free server fit

Here is the only role I give MonkeyCode in this worksheet.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
Use its free server to rerun the failing command cleanly.

Use free model access to draft a bucket from the saved log.
I am not naming models, quotas, hardware, or time limits.
If your account screen disagrees, trust that screen over me.

The model may misread a wrapped line as a platform fault.
The free server may differ in tools, architecture, and clock.
Neither gap is fixed by a confident paragraph in chat.

So I require three saved facts before any YAML edit.
Keep the job id, the image line, and the exit.
If one of those three is missing, stay unknown.

Use this request beside the log, and strip secrets first.
A token in the prompt is a leak, not context.
I stop the draft if redaction is still incomplete.

Classify this saved job log into one bucket only.
Choose transient platform, dirty cache, script defect, or unknown.
Quote the lines you used for that bucket label.
Do not suggest a retry max or a when list.
Do not invent a missing image, job id, or exit code.

That request refuses a policy recommendation on purpose.
I want a clerk for quotes, not a release manager.
If the draft bucket says unknown, I stop the edit.

What this worksheet cannot prove

It cannot prove parity across runner tags or executors.
It cannot prove a job stays safe under concurrency.
It cannot prove a free offer remains available later.

It also cannot replace a flaky test quarantine process.
Quarantine needs a named owner and a review date.
A tidy table is not that owner, even on paper.

Do not use this flow on deploys that mutate shared state.
A retried deploy can double-write or stop halfway through.
Those jobs need idempotency tests, not a wider when list.

Who should skip it

Skip this FAQ if you cannot download the job log.
Skip it if the image floats and you refuse to pin it.
Skip it if you wanted a model to approve the merge.

Also skip it when the log holds secrets or customer data.
Do not paste tokens into a model just to gain speed.
Redaction comes before any classification prompt, every time.

A pass I can defend in review

I timebox the pass so the debate cannot sprawl.
Seven checks are enough for one failed job.
More checks usually mean I am avoiding the unknown bucket.

Save the failed job log outside the chat pane.
Run the git commands and keep their raw output.
Run the heuristic and treat the bucket as a candidate.
Fill one table row with quoted lines from that log.
Ask for a label only, and ban retry advice.
Edit YAML only for a confirmed transient platform case.
Link the current GitLab retry docs in the merge request.

If step four has an empty evidence cell, stop there.
Empty cells are the useful part of this worksheet.
They block a confident story you cannot quote yet.

Close the myth without a new one

A free shell can make a second run cheaper to try.
It still cannot sign a retry rule for an unmatched runner.
I would rather ship no retry than ship a guessed when.

If you already have MonkeyCode's free server, use it here.
Run this worksheet on one saved log before you edit YAML.

FAQ: Which Group Facts Never Ride Along

Jordan Huang — Mon, 12 Oct 2026 09:21:18 +0000

FAQ: Which Group Facts Never Ride Along

I stared at a scratch shell that printed my repo name.
It felt like the group had followed me in.
Had it, or did I just paste a familiar path?

I treat these drafts as unproven until context shows up.
A common ask is to bless a job nobody has run.
I start with context, not with pretty YAML syntax.

Why the shortcut feels earned

A copied job file is full of familiar names.
A shell prompt looks like work already began.
Those two sights fool tired reviewers every week.

A free model can echo names from the paste.
A free server can give you a shell fast.
Neither sight is a grant from your GitLab group.

I draft this presence check with MonkeyCode free model access.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.
I then run it on the free server option and stop.

A scratch host is not my group, and it never was.
Would you merge a job that cannot name its own job id?

Claims I refuse on sight

The shell inherited CI variables

People say the shell already holds the CI variables.
I ask which job injected them, and then I wait.
That silence is the evidence I actually needed.

GitLab injects variables into a specific job process.
A chat window is not that job process.
A spare shell is not that job process either.

Protected variables stay on protected refs and pipelines.
Masked does not mean present in your spare shell.
File-type variables arrive as paths inside the job.

Have you opened the job log and searched for the injection?
No log means you are guessing about scope.
I will not guess about scope in a review comment.

Registry auth came along

A drafted docker push is just a line of text.
Text does not create a Docker config for you.
A model can spell the command and still be logged out.

Did this workspace run a real docker login?
Did a job expose CI_JOB_TOKEN in this process?
If both answers are no, you have no registry grant.

I refuse to treat a suggested push as a login.
Would you ship an image with a fictional auth file?
That mistake often shows up dressed as confidence.

Same cache key, same bytes

Cache is a key, a project, and a runner store.
Your laptop store is not the shared runner store.
A free server store is a third bucket again.

Matching cache key strings can still miss badly.
The bytes live where the runner actually saved them.
Have you blamed a flake when the store was simply elsewhere?

I want the runner id beside the key before I argue.
No runner id means I only have a string.
A bare string is not a cache hit.

The model remembered the environment

Models keep prompt text, not environment protection rules.
A protected environment is a GitLab project setting.
That setting does not live in shell history.

If a draft claims a production deploy, I want the job URL.
No URL means no deploy record I can trust.
A confident sentence is not an environment audit log.

Could the model have copied an old success story from the prompt?
Yes, and that story is still not this run.
I separate memory of text from memory of a deploy.

Agreement means the docs were checked

A free model may agree that your variable scope is fine.
Agreement is not a fetch of the current docs.
Did anyone open the primary docs page in this session?

I keep the links in the review note, not in my head.
GitLab's variable page is the source, not the chat.
If the page and the draft disagree, the page wins.

I do not trust a rule I cannot reopen today.
Read these before you cite a rule, and check the page date:

CI/CD variables: https://docs.gitlab.com/ci/variables/
Predefined variables: https://docs.gitlab.com/ci/variables/predefined_variables/
Protected environments: https://docs.gitlab.com/ci/environments/protected_environments/
Caching: https://docs.gitlab.com/ci/caching/

I am not quoting a version number from memory.
Pages move, and my memory is a bad pin.
The receipt below does not replace those pages.

The artifact: a presence receipt

I want a receipt that lists names and states only.
Values stay out of the file, the log, and the chat.
You can run this on a free server without importing secrets.

Treat the script as an example until your own run exists.
I have not run this against your group.
I will not pretend that a sample run exists.

This example targets Python 3.9 or newer on purpose.
Save the script as context_gap.py beside the pipeline.
Commit only a name list beside that script.

Do not commit values, tokens, or a live env file.
A leaked env file would undo the whole point.
Keep secrets in the job, not in the repo.

#!/usr/bin/env python3
"""Presence receipt. Record names and states, never values."""

import argparse
import json
import os
import socket
from datetime import datetime, timezone
from pathlib import Path


def load_names(path: Path) -> list[str]:
    names: list[str] = []
    for raw in path.read_text(encoding="utf-8").splitlines():
        line = raw.strip()
        if not line or line.startswith("#"):
            continue
        if not line.replace("_", "").isalnum() or line[0].isdigit():
            raise SystemExit(f"refusing odd name: {line}")
        names.append(line)
    return names


def state_of(name: str) -> str:
    return "present" if os.environ.get(name) else "absent"


def main() -> None:
    parser = argparse.ArgumentParser(description="CI context gap receipt")
    parser.add_argument("manifest", type=Path)
    parser.add_argument("--out", type=Path, default=Path("context-gap.json"))
    args = parser.parse_args()

    names = load_names(args.manifest)
    docker_cfg = Path.home() / ".docker" / "config.json"
    receipt = {
        "checked_at": datetime.now(timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ"),
        "hostname": socket.gethostname(),
        "ci_job_id": state_of("CI_JOB_ID"),
        "job_token": state_of("CI_JOB_TOKEN"),
        "registry": state_of("CI_REGISTRY"),
        "docker_config": "file_present" if docker_cfg.is_file() else "file_absent",
        "names": [{"name": n, "state": state_of(n)} for n in names],
    }
    args.out.write_text(json.dumps(receipt, indent=2) + "\n", encoding="utf-8")
    print(f"wrote {args.out}")


if __name__ == "__main__":
    main()

Name list

Here is the name list I would commit beside the script.
Names are the only claim I put under test.
Values are never part of the claim file.

# ci-names.txt — names only, never values
CI_PROJECT_ID
CI_PROJECT_PATH
CI_COMMIT_SHA
CI_COMMIT_REF_PROTECTED
CI_REGISTRY
CI_REGISTRY_IMAGE
CI_JOB_ID
CI_JOB_TOKEN
CI_ENVIRONMENT_NAME

Commands

Run the script, then read states, not stories.
Keep the output next to the draft, not inside it.

python3 context_gap.py ci-names.txt --out context-gap.json
python3 -m json.tool context-gap.json

On a scratch shell I expect almost every state to read absent.
That absence is a pass for this myth, not a GitLab outage.
If you export real tokens to flip red into green, you failed.

The JSON below is a shaped example, not a captured log.
Use it to learn the shape, not to cite a measurement.
Your hostname and timestamp will differ, and they should.

{
  "checked_at": "2026-10-12T00:00:00Z",
  "hostname": "scratch-example",
  "ci_job_id": "absent",
  "job_token": "absent",
  "registry": "absent",
  "docker_config": "file_absent",
  "names": [
    {"name": "CI_PROJECT_ID", "state": "absent"},
    {"name": "CI_JOB_TOKEN", "state": "absent"}
  ]
}

A stricter pass

Want a stricter pass than a single shell?
Add a second run inside a real job and diff the two receipts.
Same script, two hosts, no values in either file.

diff -u scratch-context-gap.json job-context-gap.json || true

I label the scratch file as untrusted context.
I label the job file as job context only.
I still do not call either file a release receipt.

Four steps, no folklore

Four steps keep the check boring, which is the point.
Skip a step and you are back to folklore.
Run them in order on hosts you actually control.

Copy the script and the name list into the scratch shell.
Run the script and keep the JSON receipt local.
Repeat inside one real job that already has context.
Diff the receipts and write the conclusion in the review.

Do not paste the receipt into chat if a token state says present.
Say that the job token is present, then stop.
The file path is enough for the reviewer.

How I decide from the receipt

I read the receipt before I read the drafted job.
The table is the whole decision rule I use.
I do not add trust because the prose sounded sure.

Signal	Conclusion	Next step
`CI_JOB_ID` absent	This process is not a GitLab job	Do not claim job scope
Names present, job id absent	Values were exported by hand	Stop and purge that shell
`docker_config` file present	Some auth file exists	Do not print it; ask who made it
`CI_JOB_TOKEN` present	A job context is actually here	Keep the token out of chat
All listed names absent	Scratch shell, as expected	Draft stays unproven
Job receipt differs from scratch	Context did not ride along	Cite the diff, not the vibe

Three outcomes cover the draft reviews in front of me.
Scratch-absent means the draft has no group facts yet.
Hand-exported means someone leaked scope into the wrong host.

Job-present means you can discuss that job, and only that job.
A config file can exist and still lack your registry.
Ask who created the file before you call it a login.

The model I want in the room

Context is a grant, and grants are scoped.
A grant names the project, the ref, the environment, and the job.
A hostname names a machine, which is a different fact.

A pasted YAML file is not variable injection.
A model memory is not a protected environment.
A cache key string is not a cache hit.

I separate job process, registry auth, cache store, and environment rule.
Which of those four buckets did this draft actually touch?
If you cannot point at one, you are still guessing.

What this check cannot prove

Presence is not correctness, and absence is not an incident.
A present name can still hold the wrong scope or a stale value.
I never print the value to settle that argument.

An empty string counts as absent in this script.
That choice avoids printing blanks that look like secrets.
If you need empty versus unset, extend the check locally.

This script does not call the GitLab API.
It cannot see protected-branch rules from outside a job.
It cannot prove a cache hit on a shared runner.

Free model access can draft the script, then drift from the docs.
The free server option is a workspace claim, not a duration promise.
I do not know your quota, hardware, or retention window.

Neither should you invent those numbers in a review.
Do not paste production tokens into a scratch shell to be thorough.
Would you rather stay incomplete than expose a token?

The name check rejects odd strings, and that is only a guard.
It is not a secret scanner and not a policy engine.
Pair it with your real secret controls if you have them.

Who should skip this

Skip this if you need a signed release receipt.
Skip this if your team forbids any off-runner shell.
Skip this if the next step is a production deploy approval.

This workflow is a myth check for drafters and reviewers.
It is not a control for auditors or release managers.
Use the real job log when the decision can spend money or ship.

Before you bless the draft

I run the receipt, read the absent states, and leave the YAML unblessed.
That small habit cuts fake certainty out of the thread.

Already drafting on a free server with a free model?
Start with this receipt, not with a merge comment.

Where Is the Job Behind That Green Prompt?

Jordan Huang — Mon, 12 Oct 2026 05:52:59 +0000

I keep seeing a green prompt offered as pipeline proof.
Someone ran a script on a box they do not administer.
Then they closed the tab and called the merge safe.

Have you accepted that story during a review?
I want a harder question before anyone clicks approve.
Where is the job, and who stored the trace?

This piece is a myth list with a local checker.
It is not an audit, and it is not a runner guide.
You can drop the helper tools and keep the rule.

The claim that keeps sneaking in

Developers repeat a comfortable sentence after a quick demo.
They say it ran, so the pipeline must be fine.
I break that sentence into five smaller myths below.

Each myth fails when you ask for a GitLab receipt.
A receipt is a pipeline record you can open later.
If you cannot open it, you do not have proof yet.

Myth one: the prompt is the job trace

You run the tests, the prompt returns, and you stop.
That idle prompt feels like a finished job log.
It is not, because GitLab stores the trace with the job.

A foreign shell never writes that trace for you.
Would a screenshot survive a compliance question next month?
I would not bet a release on a cropped image.

Open the job log page, or admit you only have a prompt.
GitLab documents job logs as belonging to the job.
Read the job logs page before you script around traces.

The corrected picture

A prompt is evidence that a shell returned, nothing more.
The trace you can defend lives on the job page.

Myth two: leftover files are artifacts

The scratch directory still holds a tarball after the script.
People call that tarball an artifact and move on.
Job artifacts are files the runner uploads back to GitLab.

A path on a free-floating host is not that upload.
Can you download it from the job page tomorrow?
If the answer is no, you do not have an artifact.

I will not guess retention on a server I do not operate.
The artifacts page describes upload, expiry, and download.
Confirm expire_in in your project instead of borrowing a default.

The corrected picture

An artifact is a file GitLab can hand back to you.
A leftover path is a clue, not a downloadable receipt.

Myth three: drafted rules were already evaluated

A model can write a rules block that looks confident.
Confidence is not the same thing as pipeline creation.
GitLab evaluates rules when it creates the pipeline.

Your bash process does not perform that evaluation.
Did the pipeline even exist for that commit SHA?
If the YAML never landed in the CI config path, no.

Most projects use .gitlab-ci.yml at the repository root.
A custom CI config path is also a real project setting.
Check that setting before you blame the file name.

Start at the CI YAML docs and read the rules section.
A chat file is not the file GitLab compiled.
I link the docs so you can re-check evaluation notes.

The corrected picture

Rules fire only when GitLab creates the pipeline.
Until that record exists, the block is still a draft.

Myth four: a scratch export is a CI variable

You export a token, the command passes, and you cheer.
That export lives in that shell and its child processes.
Project CI variables are injected by GitLab into the job.

Protected variables are withheld from unprotected pipelines and runners.
Confirm the current protection rules before you rely on them.
Should you paste a masked variable into a third-party shell?

No, you should not, because that is a leak.
A leak is not a test, even when the script goes green.
Start at the variables page and the predefined names page.

The corrected picture

CI variables show up inside the job environment GitLab built.
A manual export is a different environment with a different risk.

Myth five: a printed job id means a job ran

Models are happy to invent a plausible job number.
They will also invent a tidy job URL around it.
Predefined names like CI_JOB_ID exist inside a real job.

Outside that process they are ordinary strings you typed.
Would you approve a deploy from a made-up URL?
I hope the answer is a fast no.

Match the URL to a job you can open while logged in.
Then compare the trace line to the note in your ticket.
A matching pair is still a human check, not a script miracle.

The corrected picture

A real job id is printed by the job, then stored by GitLab.
Anything else is a story with numbers in it.

A free draft can still be useful

I still like a cheap place to shape a command.
MonkeyCode offers free model access and a free server option.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I ask the model for a draft, then I distrust the draft.
I may retry the command shape on the free server option.
That retry is scratch execution, not a GitLab receipt.

Take MonkeyCode out of the story and the myths remain.
The product is a place to practice, not the proof.
If those options change, the receipt rule does not move.

I am not stating model names, quotas, hardware, or duration.
Those facts were not supplied, so I will not invent them.
Check the product yourself if you need current limits.

Three layers, not one blur

I keep three layers separate when I review a claim.
Mixing them is how a green prompt becomes a false pass.
Ask which layer you hold before you type approve.

Draft text is untrusted wording, even when it parses.
Scratch execution means a command ran on some host.
A receipt means GitLab created a pipeline and a job.

Which layer is in your hand when you type LGTM?
If you cannot answer, you are not ready to merge.
Only the third layer closes a CI proof comment.

The checker I want beside the review

I am offering a small classifier you run locally.
It reads a folder of notes and prints one verdict.
It never logs in, and it never calls the network.

Shape checks are not authentication, and I say so in the output.
Treat the script as a proposal until you run it.
I have not published timings, pass rates, or server specs.

Save it as proof-gap.sh and call it with bash.
Make it executable only on a machine you trust.

Files it expects

job_url.txt holds one URL shaped like a GitLab job link.
trace_note.txt holds a line you personally saw in the log.
variable_source.txt is gitlab_job_env or some other source token.
rules_source.txt is pipeline_created only after GitLab compiled CI.
image_ref.txt is optional, and a digest uses the sha256 form.

The script

#!/usr/bin/env bash
# proof-gap.sh
# Local evidence classifier. No network. Not authentication.
set -euo pipefail

root="${1:-./evidence}"

need() {
  local f="$1"
  [[ -f "${root}/${f}" && -s "${root}/${f}" ]]
}

say() {
  printf '%s\n' "$1"
}

say "evidence_root=${root}"

if ! need job_url.txt; then
  say "verdict=SCRATCH_ONLY"
  say "missing=job_url.txt"
  exit 0
fi

url="$(tr -d '[:space:]' < "${root}/job_url.txt")"
case "${url}" in
  https://*/-/jobs/[0-9]*)
    say "job_url_shape=plausible"
    ;;
  *)
    say "verdict=NOT_A_JOB_URL"
    exit 0
    ;;
esac

if ! need trace_note.txt; then
  say "verdict=LINK_WITHOUT_TRACE"
  exit 0
fi

if ! need variable_source.txt; then
  say "verdict=ENV_UNPROVEN"
  exit 0
fi

src="$(tr -d '[:space:]' < "${root}/variable_source.txt")"
say "variable_source=${src}"
if [[ "${src}" != "gitlab_job_env" ]]; then
  say "verdict=ENV_NOT_CI"
  exit 0
fi

if ! need rules_source.txt; then
  say "verdict=RULES_UNPROVEN"
  exit 0
fi

rules="$(tr -d '[:space:]' < "${root}/rules_source.txt")"
say "rules_source=${rules}"
if [[ "${rules}" != "pipeline_created" ]]; then
  say "verdict=RULES_NOT_EVALUATED"
  exit 0
fi

if need image_ref.txt; then
  ref="$(tr -d '[:space:]' < "${root}/image_ref.txt")"
  case "${ref}" in
    *@sha256:*)
      say "image_pin=digest"
      ;;
    *)
      say "verdict=IMAGE_NOT_A_DIGEST"
      exit 0
      ;;
  esac
fi

say "verdict=RECEIPT_SHAPE_ONLY"
say "note=open_the_job_and_compare_the_trace"

The shape check only looks for a jobs path plus digits.
A plausible shape still is not proof you can log in.
Open the page yourself before you trust the folder.

How the verdicts map to the myths

The table is a legend, not a policy engine.
Read the verdict, then do the human step beside it.
A tidy folder can still be a lie you told yourself.

Verdict	Myth it catches	Human step that remains
SCRATCH_ONLY	Prompt treated as a trace	Commit CI config and wait for a job
NOT_A_JOB_URL	Invented or sloppy link	Paste a real jobs URL
LINK_WITHOUT_TRACE	URL with no log note	Open the log and save the line
ENV_NOT_CI	Scratch export called CI	Re-run inside a job or drop the claim
ENV_UNPROVEN	No variable source note	Record where the values came from
RULES_NOT_EVALUATED	Draft rules called done	Wait until GitLab creates the pipeline
RULES_UNPROVEN	No rules source note	Record whether a pipeline was created
IMAGE_NOT_A_DIGEST	Loose tag treated as a pin	Record a digest or drop the pin claim
RECEIPT_SHAPE_ONLY	Folder looks complete	Log in and compare the trace

Run it against two fixtures

Create a folder that mimics a cheerful scratch demo.
Point the classifier at it and read the verdict.
You should see ENV_NOT_CI if you follow this fixture.

The example host is a fixture, not a live project.
Do not expect that URL to open in your browser.

mkdir -p evidence/scratch-demo
printf '%s\n' 'https://gitlab.example.com/group/app/-/jobs/1042' > evidence/scratch-demo/job_url.txt
printf '%s\n' 'I opened the log and copied the failing line.' > evidence/scratch-demo/trace_note.txt
printf '%s\n' 'scratch_export' > evidence/scratch-demo/variable_source.txt
printf '%s\n' 'chat_draft' > evidence/scratch-demo/rules_source.txt
bash proof-gap.sh evidence/scratch-demo

The URL shape is plausible, and the trace note exists.
The variable source is still a scratch export.
That is myth four, caught before anyone approves.

Now flip only the variable source and run again.
The next failure should be the rules source.
A green chain of files can still hide an unevaluated rule.

mkdir -p evidence/rules-gap
cp evidence/scratch-demo/job_url.txt evidence/rules-gap/
cp evidence/scratch-demo/trace_note.txt evidence/rules-gap/
printf '%s\n' 'gitlab_job_env' > evidence/rules-gap/variable_source.txt
printf '%s\n' 'chat_draft' > evidence/rules-gap/rules_source.txt
bash proof-gap.sh evidence/rules-gap

Add a tiny assertion so the fixture fails loudly.
This is a test plan, not a recorded lab result.
Run it on your machine before you trust the script.

out="$(bash proof-gap.sh evidence/rules-gap)"
printf '%s\n' "${out}" | grep -q 'verdict=RULES_NOT_EVALUATED'
printf '%s\n' 'fixture_ok'

What a real job would print

Here is an unexecuted job that prints receipt names.
Do not commit it only to decorate a README.
Commit it when you actually want a pipeline record.

# Unexecuted example. GitLab compiles this only after you commit it
# on the CI config path your project actually uses.
receipt:
  stage: test
  script:
    - echo "CI_PIPELINE_ID=${CI_PIPELINE_ID}"
    - echo "CI_JOB_ID=${CI_JOB_ID}"
    - echo "CI_JOB_URL=${CI_JOB_URL}"
    - echo "CI_COMMIT_SHA=${CI_COMMIT_SHA}"

Those names are predefined inside jobs GitLab starts.
They are not magic strings a model may invent.
Confirm the predefined variables page if you encode policy.

After the job exists, save the URL into job_url.txt.
Write gitlab_job_env only if the values came from that job.
Write pipeline_created only if GitLab showed the pipeline.

Limits you should say out loud

The classifier trusts your files, and your files can lie.
A forged URL with a forged note still looks tidy.
You still have to open GitLab and read the trace.

What can vanish or drift

Free model text can omit image, interruptible, or timeout.
A free server can disappear with your scratch files.
I do not know those limits, so plan for loss.

What you must not paste

Do not put secrets, production tokens, or customer data there.
A practice shell is a bad vault and a bad production runner.
If you need a registered runner, use your own runner fleet.

This method does not prove coverage, flaky retries, or review quality.
Those are different problems and they need their own receipts.
It also does not replace CODEOWNERS, approval rules, or signed commits.

Who should not use this approach

Skip this if you need an audit-grade attestation.
Skip it if the next step handles production secrets.
Skip it if a regulator wants a retained, access-controlled log.

Students and reviewers can use the fixture as a teaching drill.
People who already confuse prompts with traces need it more.
People who already have a strict release ledger do not.

Before you type approve

If a free server is already open, run this classifier there first.
Read the verdict out loud before you type approve.
Then open the real job, because the script cannot log in.

Myth FAQ: What My Clean Draft Run Still Hides

Jordan Huang — Mon, 12 Oct 2026 02:19:43 +0000

I kept a green pipeline, and I still blocked the merge.
The draft YAML looked tidy, and the job status looked calm.
Why did that pair still fail my review?

I was not hunting for style nits in the script block.
I was hunting for controls I could explain a month later.
A calm log does not answer that kind of question.

The gap I keep tripping over

A control record names the revision that actually ran.
It names the secret boundary, and it names the token scope.
A status badge names none of those three things.

Have you ever confused a successful sketch with a kept decision?
I have, especially when the YAML arrived already formatted.
Speed feels like certainty, and it is not certainty.

This piece is a myth FAQ for that exact mix-up.
Each myth is a claim I still hear in review.
Each correction is a habit you can run on one file.

Where a free draft loop actually helps

I sketch risky YAML with MonkeyCode's free model access.
I sometimes run that sketch through the free server option.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.

The model is useful when I want a first draft quickly.
The free server is useful when I want one execution to fail visibly.
Neither one writes my pin, my scope, or my retention choice.

I was not given quotas, hardware, duration, or model names.
I will not invent those facts to make the draft loop sound stronger.
Missing numbers stay missing until a primary source supplies them.

Remove every product mention and the checks still stand.
That is the bar I want for a technical article.
A vendor sketch is not the control I am trying to build.

Myth 1: a branch name is basically a pin

Have you accepted ref: main because the group felt trusted?
I have seen that excuse survive a green pipeline more than once.
Trust in the authors is not immutability of the included file.

A branch moves the moment someone merges.
A tag can move too, unless tag protection actually blocks the rewrite.
A full commit SHA does not slide forward under your next run.

Corrected model: a pin is a revision your policy treats as fixed.
Write that SHA into the include, and record why you chose it.
Do not let a draft call main reproducible.

include:
  - project: "platform/ci-templates"
    ref: "9f2c1ab0e4d84a6c91b0a1e7c0d4f8a2b6e1d903"
    file: "/templates/scan.yml"

That snippet is an example, not a file I verified in production.
Replace the project path and the SHA with values you control.
If you cannot name the SHA, you do not have a pin yet.

Component versions deserve the same suspicion.
A version tag is only as still as the project that owns it.
Confirm tag protection there before you treat @1.4.2 as frozen.

Myth 2: a masked variable makes the log shareable

Someone told me the variable was masked, so the log was fine.
That sentence is a myth I want out of review culture.
Masking hides an exact string in a job log.

It is not encryption at rest on the runner.
It is not a promise about split, transformed, or encoded values.
Reread the current GitLab masking docs before you paste any trace.

Corrected model: a shareable log is a log you redacted on purpose.
Prefer protected variables for refs you actually protect.
Never ask a draft to echo a secret just to prove the wiring.

job_with_a_secret:
  stage: test
  script:
    - echo "Token is present"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

I deliberately avoided printing the variable in that example.
A present-or-absent line still leaks less than a raw echo.
If your draft contains echo "$DEPLOY_TOKEN", stop and delete that line.

Is a protected variable automatically available on every branch?
No. GitLab documents exposure on protected branches and protected tags.
A free server run on an unprotected ref can miss the variable entirely.

Confirm that rule against current docs if your instance is customized.
I am not quoting a menu label from memory as your admin's label.
The setting you see today beats a sentence I remember from last year.

Myth 3: one successful token call means a chosen scope

The job cloned another project with CI_JOB_TOKEN, and the clone worked.
Does that success mean someone designed the allowlist?
No. A default that still permits access is not your written decision.

Job token permissions have changed across GitLab releases.
I will not quote a version cutoff from memory in this article.
Open the project token setting, and match it to current docs.

Corrected model: scope lives in project settings, not in a YAML comment.
A model can insert a token into a git URL.
It cannot see your allowlist unless you bring that evidence yourself.

# Local text check only. This does not query GitLab settings.
grep -n "CI_JOB_TOKEN" .gitlab-ci.yml || echo "no job token string"

I would still open the job token permissions screen after that grep.
The menu wording can change, so I follow the current documentation.
A forbidden settings page is a finding, not a reason to skip the myth.

What would I store beside the merge request?
I store a dated note of who can inbound-call this project with a job token.
I do not store the token value, and I do not paste the clone URL with it.

Myth 4: an artifact URL is retained evidence

The job uploaded an artifact, and the log printed a URL.
Can I cite that URL in an incident review next month?
I cannot know that from the green status alone.

GitLab expires artifacts from expire_in or from the instance default.
Your admin can change that default, so a blog memory is not your setting.
I also do not treat the free server option as a retention guarantee.

Corrected model: evidence I need later gets copied to a store I control.
The pipeline log is a clue, not the archive.
Write expire_in when the artifact is part of the review story.

review_bundle:
  stage: test
  script:
    - python3 check_ci_draft.py .gitlab-ci.yml > draft-report.txt
  artifacts:
    paths:
      - draft-report.txt
    expire_in: 7 days

Seven days is an example choice, not a compliance window I recommend.
Pick a window your team can actually defend in review.
If you need years of retention, this pattern is the wrong tool.

A local checker, labeled unexecuted

This script is a proposal for a single draft file.
I have not executed it for this article, and I am not calling it a pass engine.
It will miss anchors, extends, and !reference indirection.

#!/usr/bin/env python3
"""Local draft check. Not a policy engine. Unexecuted here."""
import sys
from pathlib import Path

MOVING = {"main", "master", "develop", "dev", "head"}
SECRET_HINTS = ("token", "secret", "password", "key")

def main() -> int:
    path = Path(sys.argv[1] if len(sys.argv) > 1 else ".gitlab-ci.yml")
    text = path.read_text(encoding="utf-8")
    findings = []
    for i, line in enumerate(text.splitlines(), start=1):
        stripped = line.strip().lower()
        if stripped.startswith("ref:"):
            value = stripped.split(":", 1)[1].strip().strip("'\"")
            short = len(value) < 40
            if value in MOVING or (value and not value[0].isdigit() and short):
                findings.append(f"{i}: moving or short ref '{value}'")
        if "echo" in stripped and any(k in stripped for k in SECRET_HINTS):
            findings.append(f"{i}: script may print a secret")
    if "artifacts:" in text and "expire_in:" not in text:
        findings.append("artifacts block has no expire_in")
    if "ci_job_token" in text.lower():
        findings.append("CI_JOB_TOKEN present; confirm scope outside this file")
    if not findings:
        print("no local findings; this is not a pass")
        return 0
    print("findings:")
    for item in findings:
        print(f"- {item}")
    return 1

if __name__ == "__main__":
    raise SystemExit(main())

The ref heuristic is intentionally blunt.
A short tag can be a fair pin if tag protection holds.
Treat every finding as a question, not as a guilty verdict.

python3 check_ci_draft.py .gitlab-ci.yml
echo "exit=$?"

I would run that before any free server execution of the same draft.
A zero exit only means this file tripped no local rule.
It never means the pipeline is pinned, secret-safe, or approved.

Walk a bad draft before you trust the script

Read this fixture out loud before you automate anything.
I expect three questions, even if the script prints fewer lines.
Would you merge it only because a free server once went green?

include:
  - project: "platform/ci-templates"
    ref: main
    file: "/templates/scan.yml"

leak_check:
  script:
    - echo "debug token is $DEPLOY_TOKEN"
    - git clone "https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example/app/ops.git"
  artifacts:
    paths:
      - scan.json

My manual findings are boring, and that is the point.

The include ref is a moving branch, so the next run can differ.
The script prints a deployment token into a log that people share.
The clone uses a job token without a settings note beside the change.
The artifact block never says when scan.json should disappear.

A model can repair those lines after you name the findings.
Do not ask it to repair them before you name the findings.
Otherwise you get a cleaner myth, not a clearer control.

Tiny test plan for the checker

I would keep four fixtures beside the script, and I would not skip the last one.
This plan is proposed, not a run I am reporting as complete.

A file with ref: main must exit nonzero and mention that ref.
A forty-character SHA ref must not be flagged as a moving branch.
A line that echoes a token must exit nonzero.
An artifacts block without expire_in must be listed.
A quiet file must print that no finding is not a pass.

If fixture two flags every SHA that starts with a letter, fix the heuristic.
Do not weaken fixture one to hide that bug.
A blunt tool is allowed, and a lying tool is not.

The decision table I keep beside the draft

Claim I heard	What I check	Corrected model
The include came from our group	`ref` is a SHA, not a branch	Group trust is not immutability
The variable is masked	No echo and no encoded reprint	Masking is a log filter
The token clone worked	Job token permissions in settings	Success is not a written scope
The artifact URL exists	`expire_in` plus an external copy	A URL is not retention

I read one row out loud before I approve a drafted pipeline.
If I cannot point at the middle column, I do not merge.
The right column is the sentence I want in the review note.

Who should skip this habit

Do not use this habit as a compliance attestation.
Do not use it when your reviewer wants signed provenance.
Do not use a free server run as proof of isolation, hardware, or uptime.

Skip it if you need a locked archive measured in years.
Skip it if CODEOWNERS and approval rules are the control you actually lack.
This checker never sees those systems, so it cannot replace them.

Also skip it when the YAML is mostly generated at runtime.
A text scan cannot follow includes that appear only after a script runs.
In that case, capture the expanded config from GitLab and review that file.

How I close the review

I ask four questions, and I wait for boring answers.

Which SHA did we include, and who can move a tag if we used one?
Which project setting scopes the job token, and where is that note stored?
Which log lines are safe to paste into chat after this run?
Where did the artifact get copied, and when does the copy expire?

If I cannot answer those, the green status can wait.
The free model can redraft the YAML after the checker complains.
The free server can rerun the sketch after the pin is real.

If a free model session is already open, feed it these findings before another hopeful include.

FAQ: A Side Session Is Not a Pipeline Receipt

Jordan Huang — Sun, 11 Oct 2026 19:47:41 +0000

I keep stopping on the same merge request comment. The author says the tests already passed somewhere else. I ask which pipeline recorded that exact result.

The thread often goes quiet, and nobody pastes a link. Have you watched a review stall on that gap? A busy side session can feel like proof.

It is still not a receipt GitLab stored. I want the pipeline row GitLab actually kept.

The claims I keep hearing

These lines show up in review threads often. They sound helpful, and they skip the record. I want these claims retired from review notes.

A zero exit on my server means the pipeline is green.
Cloning the default branch means I tested the merge head.
A pasted log means the failure cause is already known.
A temporary free server is safe enough for job tokens.
A commit hash in chat means that job already finished.

Which of these have you accepted too quickly?

Why I started asking for ids

Speed is not the same thing as evidence. I can still respect a fast careful rehearsal. I still need a stored row before I approve.

Myth 1: A side pass is a pipeline

You ran a suite, and the shell returned zero. That event happened outside GitLab's own pipeline table. A pipeline row has an id, a status, and a sha.

Your scrollback has none of those stored fields. I call the side run a rehearsal, not evidence. I will not cite it as a green check.

Where is the job URL for this head? I will not invent one from terminal memory.

What I accept instead

I accept a pipeline id that I can open. I accept a job status from that same pipeline. I accept a web_url pasted into the thread.

Myth 2: Default clone means this head

The server cloned whatever branch the remote offered. Often that branch is the default, not your head. A merge request head can differ after a rebase.

Did your rehearsal fetch the exact sha under review? A branch name match is not a commit match. I compare the checked out commit with the merge head.

If those hashes differ, stop the claim there. You tested another snapshot, not this review. Why argue about logs from the wrong tree?

A local equality check

Run this before you describe the rehearsal. It fails closed when the local checkout drifted.

: "${MR_HEAD_SHA:?sha from the merge request}"
test "$(git rev-parse HEAD)" = "${MR_HEAD_SHA}"
echo "checkout matches ${MR_HEAD_SHA}"

That test proves your worktree, not a pipeline. Keep that limit in the sentence you post. A matching checkout is still only a rehearsal.

Myth 3: A pasted log is the trace

A colleague pastes forty lines into the model chat. The reply then names a confident root cause. I still cannot see a job id in that paste.

A trace belongs to one job in one project. A paste can be trimmed, stale, or mislabeled. Which job URL produced those exact log lines?

Does that job's sha match the merge request head? If you cannot answer, you do not have the trace. Guessing a cause from a snippet wastes the next hour.

Questions I ask before debugging

Which project hosted the job that failed?
Which job id emitted the lines you pasted?
Which sha did that job actually build?
Is that sha still the merge request head?
Did anyone trim the trace before the paste?

If one answer is missing, I stop the diagnosis. I go fetch the job instead of theorizing. The trace page beats another confident chat paragraph.

Myth 4: Temporary means safe for tokens

A free hosted shell will still execute what you type. Free access does not create a trust boundary. A short lifetime is not an access policy.

Would you type a job token on a laptop you do not administer? Protected variables belong on protected runners and refs. A side shell sits outside that fence entirely.

Keep production secrets on machines you already control. Masked variables are not safe just because chat feels private. A pasted token can outlive the session that received it.

Myth 5: A typed SHA means the job finished

The chat can mention a full commit hash. Typing a hash only proves someone typed it. It does not prove a pipeline reached success.

I ask the API for pipelines with that sha. I want the status, ref, source, and web_url. If the list is empty, the claim is unfinished.

The same hash on another ref is still different. A branch pipeline is not a tag pipeline. A merge-result pipeline is a third distinct case.

Fields I refuse to infer

I do not infer status from a cheerful summary. I do not infer ref from a branch nickname. I do not infer source from the words about pushing.

The model I keep instead

I keep three layers apart when I review. Mixing them is how weak green claims survive.

The claim is whatever the author or model said. The rehearsal is whatever a side shell ran. The receipt is whatever GitLab stored for that sha.

Only the receipt belongs in the approval note. The other layers can shape your next question. They cannot close the review on their own.

Claim map

Use this map before you trust a comment. Weak answers stay in the rehearsal column only.

Question	Weak answer	Receipt field
Was it green?	"I ran it"	pipeline `status`
Which commit?	a hash in chat	pipeline `sha`
Which branch context?	a nickname	pipeline `ref`
Which job?	a YAML snippet	job `name` and `status`
Where is the log?	pasted lines	job `web_url`
Did secrets work?	a token in shell	do not export it

A receipt check you can copy

The script below is a proposal, not a benchmark. I am not reporting timings or sample counts. Run the authenticated calls where your token already lives.

#!/usr/bin/env bash
set -euo pipefail

: "${GITLAB_HOST:?set your GitLab host}"
: "${GITLAB_TOKEN:?read_api token}"
: "${PROJECT_ID:?numeric project id}"
: "${SHA:?merge request head sha}"

api() {
  curl -fsS --header "PRIVATE-TOKEN: ${GITLAB_TOKEN}" \
    "${GITLAB_HOST}/api/v4/projects/${PROJECT_ID}${1}"
}

echo "commit"
api "/repository/commits/${SHA}" | jq '{id, short_id, title}'

echo "pipelines"
api "/pipelines?sha=${SHA}&per_page=20" \
  | jq '.[] | {id, status, ref, source, sha, web_url}'

Pick a pipeline id from that first list. Then fetch the pipeline row and its jobs.

: "${PIPELINE_ID:?id from the list above}"

api "/pipelines/${PIPELINE_ID}" \
  | jq '{id, status, sha, ref, source, web_url}'

api "/pipelines/${PIPELINE_ID}/jobs?per_page=100" \
  | jq '.[] | {id, name, status, stage, allow_failure, web_url}'

Compare these points before you write the review.

Confirm the sha equals the merge request head.
Confirm status is success, not a chat summary.
Confirm the job name matches the YAML you read.
Paste web_url into the thread, not shell history.
Treat a missing job as an absent receipt.

No pipeline for that sha means you only rehearsed. Say that plainly when you reply in review. Do not promote a rehearsal into a receipt.

Those paths follow the Pipelines API and the Jobs API. Confirm them in the current GitLab docs for your host.

Read the flags, not just the color

A green badge can still be a soft pass. Look at allow_failure on the job you care about. Look at source so you know why the pipeline exists.

A scheduled pipeline is not your merge pipeline. A trigger pipeline may carry different variables entirely. Name the source in your note when it matters.

Where drafting help fits

MonkeyCode provides free model access and a free server option. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I treat both as drafting aids, not as runners. Neither one writes a row in your pipeline table. Removing them would leave this receipt habit intact.

Ask the model to list the receipt fields you need. Ask it to flag comments that lack a job URL. Do not ask it to approve the merge request.

Use the free server to syntax-check a local fixture. Point that session only at fake sample JSON. Run real curl calls on your own credentialed machine.

mkdir -p fixtures
cat > fixtures/pipelines.json <<'EOF'
[
  {
    "id": 101,
    "status": "success",
    "ref": "feature/receipt",
    "source": "push",
    "sha": "abc123deadbeef",
    "web_url": "https://example.invalid/pipelines/101"
  }
]
EOF

jq '.[] | {id, status, sha, ref, web_url}' fixtures/pipelines.json
bash -n check-receipt.sh

The model may draft that fixture for you. The server may run jq against the file. Neither step created a pipeline in your project.

Do you see the gap between rehearsal and receipt? If the model invents a job name, discard it. Your YAML and the jobs API remain the source.

A fluent paragraph is not an API field. I throw those inventions out of the note.

What I will not claim about those options

I am not stating quotas, hardware, or duration. I am not naming models or ranking them. Check the current product docs before you rely on availability.

Limits I will not smooth over

This check stays read-only on purpose for reviewers. It does not retry jobs or explain flakes. It does not prove coverage or deploy health.

A success status can still hide allow_failure jobs. Read that flag before you relax your review. A green pipeline can also skip your target job.

Use a read_api token for this glance, not a maintainer token. Rotate any secret you pasted into a side session. A vanished server does not unpaste a leaked token.

Free model text can be stale or simply wrong. Free server files can disappear when the session ends.

Plan on rerunning the authenticated check after every push. Treat yesterday's pasted log as expired context now.

GitLab.com and self-managed hosts are not the same. Set GITLAB_HOST to the site you actually use. I am not choosing a default for your company.

Parent-child pipelines need a second API request too. Bridge jobs do not inline every downstream job. Follow the bridges endpoint when you see a trigger.

Confirm these paths against current GitLab API docs. I am describing a habit, not pinning an API version. Your admin may also expose a different API prefix.

Who should skip this approach

Skip this if you already open the job log yourself. You do not need a script just to click web_url.

Skip this when the decision is a release approval. A pipeline id is not your release process. Keep that checklist with the release owners.

Skip this if personal tokens are forbidden on the project. Use the access path your maintainers already approved. Do not bypass policy through a side server.

Skip this after the merge request head moves. Recheck pipelines for the new head sha only. An older green row describes a different commit.

Skip this if you cannot see pipelines in the project. A hidden pipeline is not something to reconstruct from chat. Ask a maintainer for the recorded status instead.

The note I actually leave

I post one question, and then I stop pushing. A short question beats a lecture every time.

Which pipeline id matches this current head sha? Paste the job URL, not the shell history.

Need a drafter for that checklist, not a verdict? Use the free model to phrase the questions only. Keep the token on the machine you control.

Claim, rehearsal, receipt: I merge on the last one. I let the first two stay as questions only.

Did the Agent Compile Your Pipeline, or Just Read It?

Jordan Huang — Sun, 11 Oct 2026 16:23:19 +0000

Did the Agent Compile Your Pipeline, or Just Read It?

Did a free shell clone just become your pipeline proof?
The model read the YAML and called that pipeline valid.
I do not accept that leap without a compile receipt.

I keep hearing four claims after a quick agent pass.
Each claim treats a local read as GitLab's compiler.
I want a guard that separates those two steps.

Why this bites on review day

A merge request can look calm while the graph is wrong.
Includes fail quietly when the ref or the file moved.
Rules then hide the job you thought you fixed.

Have you merged a green chat and met a red pipeline?
That gap can waste a whole review cycle.
The file on the branch was fine as plain text.

The compiled job graph was not fine at all.
Which layer failed is the only useful question?
A calm diff can still hide a broken graph.

What compiled means in this checklist

GitLab does not execute your YAML as a raw script.
It merges includes, applies inputs, and evaluates rules.
Then it builds jobs for one pipeline source.

A text view shows the file you happened to open.
A remote shell shows the tree you happened to clone.
Neither view is the compile that creates jobs.

Four receipts

I ask for four receipts before I trust a draft.
Those receipts are parse, includes, source, and runner identity.
Miss one, and the green chat is still a guess.

Myth 1: a clean parse means a valid pipeline

Someone pastes the config into a chat window.
The model says the indentation looks structurally fine.
Why do we treat that note as CI lint?

A YAML loader checks mapping shape, not job meaning.
It does not understand rules:, needs:, or trigger:.
Your file can parse and still create zero jobs.

Corrected model

Here is the corrected picture I use in review.
Parse is only the first layer of evidence.
It proves the text is YAML, not that jobs exist.

# Proposed local guard. Unexecuted example, not a project result.
python3 - <<'PY'
import sys
from pathlib import Path
try:
    import yaml
except ImportError:
    sys.exit('install pyyaml before you trust this parse')
path = Path('.gitlab-ci.yml')
if not path.exists():
    sys.exit('missing .gitlab-ci.yml')
data = yaml.safe_load(path.read_text())
if not isinstance(data, dict):
    sys.exit('top level is not a mapping')
print('parse_ok keys', ','.join(sorted(data)[:12]))
PY

That command answers only one narrow question for you.
Did a parser accept the top-level mapping in this tree?
Ask project CI lint before you call the result a pipeline.

Project CI lint is the compile receipt I accept for job creation.
It is still not a full rules narrative on its own.
I am not re-arguing that separate point in this note.

Myth 2: seeing include paths means they expanded

I open the file and spot several include: entries.
The model repeats those paths in a tidy list.
Did it fetch the targets, or only echo strings?

Includes may be local, project, remote, template, or component.
A component also carries inputs and a version ref.
Reading the key never expands the merged graph.

An include path is a promise, not a fetched file.
Expansion is a separate fetch plus a merge step.
If that fetch fails, your local text is not the pipeline.

Illustration, not a catalog

The next snippet is an illustration, not a live catalog.
Do not fetch these hosts as if they were your project.
Use them only to see three include shapes side by side.

include:
  - local: ci/test.yml
  - project: acme/ci-templates
    file: /templates/go.yml
    ref: v2.4.0
  - component: example.gitlab.com/acme/go-test@1.2.3
    inputs:
      go_version: '1.22'

Count those entries before you celebrate a draft.
If the count is not zero, demand the merged YAML.
Do not let a prose summary replace that artifact.

Myth 3: one shell run covers every source

You ran go test on the branch and it passed.
Will the merge request pipeline select the same jobs?
Will a nightly schedule select those same jobs again?

Job rules: can depend on the pipeline source.
A push, a merge request, and a schedule are different events.
The variable CI_PIPELINE_SOURCE is how GitLab names that event.

One green shell is one context, not every context.
Name the source you actually rehearsed in the note.
Lint again for the source you intend to merge.

Decision matrix

I keep this decision matrix on the review comment.
It separates a local rehearsal from a compiled pipeline.
Read each row before you accept a green chat.

Question	What a local shell can show	What only GitLab compile can show
Did the YAML parse?	Yes, if you ran a parser here	Re-check in project CI lint
Did includes expand?	Only if you fetched each target	Merged YAML for this project
Which source was simulated?	The story you typed into rules	The ref and source you lint
Will runner tags match?	No, a shell is not registered	The scheduler's runner match

Myth 4: a free shell means my tags match

This claim sounds practical, and it still fails.
When a free server hands you a shell, commands can run.
Your job may still declare tags and a resource group.

A handed shell is not a registered GitLab runner.
It has no tag set and no protected flag.
The scheduler never consulted that remote shell session.

Script execution and job scheduling are different problems.
The shell can rehearse the script text you wrote.
Only a matching runner can pick up the real job.

go-test:
  stage: test
  tags: [linux, docker]
  resource_group: staging-db
  script:
    - go test ./...

Can that job start on the free server session?
No, that session is not your runner fleet.
Use it to rehearse commands, not to prove a match.

This is not a toolchain pin argument either.
I am not asking which Go version sat on the shell.
I am asking whether any runner would even take the job.

Where the free options fit

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Draft partner, not a compiler

I use the free model access as a draft partner only.
I ask it to list include kinds and tag tokens.
I do not ask it to declare the pipeline valid.

I use the free server option as a scratch shell.
I clone the branch, parse the file, and print include kinds.
I still mark that printout as local evidence, not a job log.

This is the workflow I recommend, not a reported run.
I am not stating a quota, a machine size, or a time limit.
Those terms live in the current product notes, not here.

If the shell vanishes, run the same census on your laptop.
The checklist should still make sense without that host.
Copy the script into the repo if you want it versioned.

# Proposed include census. Unexecuted example, not a measured run.
python3 - <<'PY'
import sys
from pathlib import Path
try:
    import yaml
except ImportError:
    sys.exit('install pyyaml first')
data = yaml.safe_load(Path('.gitlab-ci.yml').read_text())
if not isinstance(data, dict):
    sys.exit('top level is not a mapping')
includes = data.get('include', [])
if includes is None:
    includes = []
if isinstance(includes, dict):
    includes = [includes]
if isinstance(includes, str):
    includes = [includes]
print('include_count', len(includes))
kinds = ('local', 'project', 'remote', 'template', 'component')
for item in includes:
    if isinstance(item, str):
        print('include_kind', 'local_shorthand')
    elif isinstance(item, dict):
        kind = next((k for k in kinds if k in item), 'unknown')
        print('include_kind', kind)
    else:
        print('include_kind', 'unexpected')
jobs = [
    k for k, v in data.items()
    if isinstance(v, dict) and 'script' in v
]
print('script_jobs_seen', len(jobs))
print('tagged_jobs_seen', sum(1 for k in jobs if data[k].get('tags')))
PY

# Proposed receipt log. Unexecuted example, not a measured run.
set -eu
test -f .gitlab-ci.yml
: "${SOURCE_TO_SIMULATE:=merge_request_event}"
{
  printf 'source_to_simulate=%s\n' "$SOURCE_TO_SIMULATE"
  printf 'runner_check=compare tags and resource_group with registered runners\n'
  printf 'lint_status=pending until project CI lint is attached\n'
} | tee compile-receipts.txt

Pair the census with GitLab's own CI lint for the project.
Use the lint flow documented for your current GitLab version.
I will not freeze a CLI flag that your version may not ship.

Questions the lint must answer

What should that lint answer before you merge?

Is the merged config valid inside this project?
Which jobs exist for this ref and this source?
Which warnings remain after the includes actually expand?
Did you simulate the merge request, not only the branch?

If you cannot answer those four questions, stop the merge.
A confident paragraph is not a substitute receipt.
Would you ship a binary you never linked?

The note I paste on the merge request

I want the review comment to stay boring and specific.
No pep talk, and no model transcript pasted in.
Just list the receipts that are still missing today.

Checklist text

Pipeline compile checklist
- [ ] YAML parse ran in this repo, not only in chat
- [ ] Include count is recorded and merged YAML is attached
- [ ] CI lint simulated the pipeline source we will use
- [ ] Job tags and resource_group were checked against real runners
- [ ] Free shell output is marked as rehearsal, not a job log

Would I block a merge when this list is empty?
Yes, when the change touches pipeline config or an include.
A dropped include should not wait for a later patch.

What this guard refuses to prove

The census script does not expand remote includes for you.
It does not evaluate rules or variable precedence either.
It does not query your runner fleet or resource groups.

Default PyYAML may reject GitLab tags such as reference.
A parse error there can be the tool, not your pipeline.
That is another reason the project lint still wins.

The census counts jobs that contain a script key only.
Jobs that only use extends or trigger can be missed.
Treat the numbers as a census, not a job inventory.

Protected variables and file variables stay inside GitLab.
A free shell should not receive those values for a demo.
If a draft asks you to paste a token, stop and refuse.

Component catalogs move when you track a floating ref.
Pin a version and re-lint after you bump that pin.
This script does not resolve spec:inputs on its own.

GitLab's compiler remains the authority for job creation.
Read the current CI lint and include docs before you automate a gate.
I am not pinning a click path that the UI may rename.

Pages I expect you to confirm

GitLab documents includes, CI lint, and predefined variables in its docs.
I am linking the public paths I expect you to confirm.
Start with CI lint and the include reference before you automate.

Who should not use this approach

Skip this if the repository has no .gitlab-ci.yml at all.
Skip it when a platform gate already stores merged YAML.
Skip it when you need a signed release attestation instead.

Also skip it for shared runner capacity planning.
A free shell says nothing about minutes or queue time.
That question belongs on a different sheet entirely.

Do not register the free server as a production runner.
Do not store secrets in the chat that drafted the job.
Do not merge because the model sounded sure today.

Close the loop on the next review

Next time a draft says the pipeline looks valid, ask for receipts.
Run the parse and the include census on the free server, or locally.
Then let GitLab's CI lint close the argument for that source.

Want a second pass on the checklist wording before review?
Free model access is enough to start that pass.
Keep the verdict in the lint result, not in the chat log.

FAQ: A Model Patch Is Not a GitLab Review

Jordan Huang — Sun, 11 Oct 2026 09:20:47 +0000

I keep reading merge requests that tell a bigger story than the diff. Someone asked a model to repair a red job. The patch looks tidy, so the review stops there.

Would you approve a comment that never touched the repo? I would not treat chat prose as a merge. GitLab will not treat it that way either.

This FAQ is the mental model I want before anyone hits merge. Each myth is a claim developers still repeat in reviews. Each fix points at a file or a project setting.

What this FAQ refuses to pretend

I will not invent a model name, a quota, or a hardware bill. I will not invent a session length or a permanence promise. I was not given those facts, so I will not fake them.

The operator supplied two availability facts about MonkeyCode, and only those. Free model access is available, and a free server option is available. Those facts do not make a reviewed pipeline by themselves.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. I would use that access to draft checks, not to approve merges. I would use the free server option as scratch space only.

Myth 1: A tidy YAML patch is a reviewed pipeline

People say the model read the log, so the YAML is reviewed. A fluent diff is still just text sitting in a chat pane. Did anyone open the pipeline editor and compare the stages?

GitLab runs the file in the repository, not the paragraph above it. If the patch never lands on a branch, the project did not change. I want the branch commit, not a screenshot of the suggestion.

Corrected model: a review starts when the YAML is committed and linted. Chat is a draft tray, not the project contract you merge. The committed file is the contract your runners will execute.

Lint the file, not the vibe

I treat schema lint as the first gate, not the model tone. GitLab documents CI Lint for pipeline files in the project. You can also call the lint API with a real project token.

I keep the payload in a file so secrets stay out of history. The host and project id should come from the environment. If lint fails, the model draft is still only a draft.

Read the current CI Lint docs before you trust this curl shape. Endpoints move, and I will not freeze a stale path as law. The snippet below is a proposal, not a measured run.

# Proposal only. Do not paste a real token into any chat.
# Confirm the path in GitLab's current CI Lint API docs.
curl --silent --show-error --fail \
  --header "Content-Type: application/json" \
  --data @ci-lint-payload.json \
  "$GITLAB_HOST/api/v4/projects/$PROJECT_ID/ci/lint"

I inspect the cached diff before I push the scratch branch. A chat paste can hide a line the diff will show. If the diff echoes a token, I stop and rotate it.

git checkout -b ci-evidence-scratch
git add .gitlab-ci.yml
git diff --cached -- .gitlab-ci.yml

Myth 2: "Tests passed" in prose is a test report

I still see job logs pasted under a heading called evidence. A log line can be edited, truncated, or never uploaded. Would you bet a release decision on a single sentence?

GitLab's YAML reference separates job logs from report artifacts. The junit report key is how test summaries reach the merge request. A green echo does not create that report file.

Corrected model: evidence is a file path GitLab can ingest. Prose is narration, and narration can sound finished. The XML can still be missing while the story sounds done.

I set when always so a failed job still uploads the report. I set expire_in myself instead of trusting an unspoken default. I do not cite a default duration, because defaults can move.

# Unexecuted example. Confirm keys in the current CI YAML reference:
# https://docs.gitlab.com/ci/yaml/
unit_tests:
  stage: test
  script:
    - mkdir -p reports
    - python -m pytest --junitxml=reports/junit.xml
  artifacts:
    when: always
    expire_in: 7 days
    paths:
      - reports/junit.xml
    reports:
      junit: reports/junit.xml

I read the job artifacts docs before I trust an upload story. I read the YAML reference before I copy keys from chat. I treat pytest junitxml as a runner detail, not a GitLab feature.

Myth 3: Free model access is a safe vault for CI variables

Someone says the prompt is private, so the token is fine. Is a convenience box really a vault for credentials? I do not grant a chat box that title.

GitLab documents protected variables for protected branches and tags. Confirm the current variables page before you rely on that limit. Masking is a log filter, not a license to print values.

Corrected model: secrets live in GitLab or a real secret store. A prompt is a copy, and copies have a habit of multiplying. I will not trade a red job for a leaked token.

I do not paste CI_JOB_TOKEN into a free model prompt. I do not paste masked variables just to help a debug session. I do not paste customer data so a sample patch looks real.

The free server option does not weaken that copying rule. A scratch shell is still a machine you do not administer. If I cannot name its retention, I will not feed it secrets.

A dotenv file can smuggle what the prompt should not

Models love to emit KEY equals VALUE and call it config. GitLab can import dotenv reports into later jobs. Would you let a later job inherit a guessed secret?

I want dotenv keys to be build metadata, never credentials. A bad dotenv line is not a convenience. It is a second copy with a job scope.

Myth 4: A free server transcript is a merge request artifact

The transcript says the script exited zero on a free server. People attach that transcript and call the pipeline finished. Where is the artifact entry in the job sidebar?

GitLab artifacts are files uploaded by a job the project ran. A foreign shell transcript is not an artifact record in GitLab. Cache is not an artifact, and a cache hit can miss later.

Corrected model: no widget, no report, no argument from me. A transcript is a story about a run you did elsewhere. Stories are not downloads your reviewer can open later.

Myth 5: Model confidence replaces rules, needs, and approvals

I hear that the model checked every branch, so rules are noise. Confidence is not a rules block in your pipeline file. Confidence is not needs, and it is not an approval rule.

allow_failure true can keep a pipeline green while a job failed. needs can start a job without waiting for every earlier stage. Approval rules live in project settings, not in a chat score.

Corrected model: control flow is YAML plus project settings. Tone is not control flow, no matter how certain it sounds. I read the policy files before I trust the adjective.

The order I trust more than a fluent patch

Commit the YAML on a branch you can throw away.
Run CI Lint against that committed file, not the chat.
Produce a junit file from the test command you really run.
Run the local evidence check against those files on disk.
Push and confirm the merge request shows the test report.

A local check on files, not on vibes

This script is a proposal you can run on a local folder. I have not published timings, pass rates, or hardware notes. It checks files on disk, not a live shared runner.

A pass means the files exist and look roughly shaped right. A pass does not mean GitLab accepted the report upload. I still want CI Lint, then a pipeline on a branch I control.

#!/usr/bin/env bash
# ci-evidence-check.sh - proposal, not a published benchmark.
set -euo pipefail

root="${1:-.}"
yaml="$root/.gitlab-ci.yml"
junit="$root/reports/junit.xml"
dotenv="$root/reports/build.env"

fail() { printf 'FAIL: %s\n' "$1" >&2; exit 1; }

[[ -f "$yaml" ]] || fail "missing .gitlab-ci.yml"
[[ -f "$junit" ]] || fail "missing reports/junit.xml"

# -q so a match does not print a secret into the terminal.
if grep -E -q 'CI_JOB_TOKEN|echo .*(SECRET|TOKEN|PASSWORD)' "$yaml"; then
  fail "yaml looks ready to print a secret; open the file locally"
fi

grep -q 'reports:' "$yaml" || fail "yaml has no artifacts reports block"
grep -q 'junit:' "$yaml" || fail "yaml does not point at a junit report"

# Minimal XML sniff. This is not a full JUnit schema validation.
grep -q '<testsuite' "$junit" || fail "junit xml has no testsuite element"
grep -E -q '</testsuites>|</testsuite>' "$junit" || fail "junit xml looks truncated"

if [[ -f "$dotenv" ]]; then
  while IFS= read -r line; do
    [[ -z "$line" || "$line" == '#'* ]] && continue
    [[ "$line" =~ ^[A-Z_][A-Z0-9_]*= ]] || fail "dotenv line is not KEY=VALUE form"
    case "$line" in
      *TOKEN*|*SECRET*|*PASSWORD*|*PRIVATE*) fail "dotenv looks like a secret" ;;
    esac
  done < "$dotenv"
fi

printf 'PASS: files look like evidence, not like prose\n'

That invocation is a usage sketch, not a recorded lab result. If the script fails, fix the files before you debate tone. If it passes, you still owe GitLab a real pipeline.

mkdir -p reports
bash ci-evidence-check.sh .

The table I keep beside the editor

I keep this table beside the editor when a patch arrives as prose. Each row names the claim, the demand, and the refusal. If a row fails, I do not argue from the model's tone.

Claim I hear	What I demand instead	Why I refuse the shortcut
The model rewrote the job	Committed YAML plus CI Lint	Chat text is not the repo file
It said tests passed	`reports/junit.xml` on the job	Logs are not report artifacts
The prompt can hold the token	Variables in project settings	A prompt is a copy, not a vault
The free server exited zero	Artifact uploaded by the project job	Foreign transcripts are not downloads
The model felt sure about rules	`rules`, `needs`, approval settings	Tone is not control flow
A generated dotenv is harmless	Metadata keys only, no credentials	Later jobs can inherit the file

Who should skip this, and what it cannot prove

Skip this approach if your pipeline has no tests to report. Skip it if you cannot keep secrets out of prompts and shells. Skip it if you need a signed release attestation, not a FAQ.

This check does not validate a full JUnit schema. This check does not prove runner tags, images, or digest pins. Those are separate gates, and I am not repeating them here.

The greps are heuristics, and comments can fool them. Treat a pass as a smell test, not as a security audit. A green local pass is still not a merge approval.

Who should use it: reviewers staring at a fluent CI patch. Use it when the author cites a model patch as the proof. Do not use it as a compliance program or a quota claim.

What I would ask for, and nothing more

I would ask a free model for a checklist and a hostile reading. I would ask it to flag allow_failure and secret echoes. I would not ask it to bless a merge request.

A free server can hold the script while I poke sample files. I would not point that shell at production runners or secrets. I would not store release artifacts on a scratch box.

If scratch space would help, MonkeyCode is the option I would open. Then close that tab and prove the files inside GitLab. I would not let the draft close the review by itself.

So ask the rude question before you click merge. Which file will GitLab ingest when the chat tab is closed? If you cannot name that file, you do not have evidence.