DEV Community: Avery Li

The Replay Packet: Turning an Agent Session Into Evidence a Reviewer Can Re-run

Avery Li — Tue, 27 Oct 2026 13:32:57 +0000

A patch is only reviewable when a reviewer can reproduce its evidence without the author sitting next to them. That sentence ended a pairing session that had stalled for forty minutes on a simple question: what exactly did the agent run before it declared the fix complete? The senior in the session refused to read the diff first, because a diff shows what changed while a session log shows what was believed. The outcome was a small artifact called a replay packet, and it changes the reviewer's job from trusting a narrator to re-executing a record.

The pairing session, and the four questions it started with

The scenario is common enough to be boring: an agent edits three files, adds one test, and reports success. The author then summarizes that work in a pull request body of six confident sentences. The senior treated the summary as a claim set rather than a description and asked four questions in sequence.

Which command produced the green result, and what was its exit code at each step?
Which of the six sentences in the PR body maps to a command that actually ran?
If the reviewer runs the same commands on a clean checkout, will the output match?
What happens to this review if the author is unavailable for the next two days?

Question four is the one that reframed everything. A review process that depends on the narrator being reachable is not a review process; it is a handoff with extra ceremony. The senior's position was that the author should deliver a record, not a performance.

Three dead ends the session walked into

The first proposal was to paste the full transcript into the PR. That failed immediately on size and on signal: the transcript ran past four thousand lines, most of it file reads, and a reviewer cannot execute a wall of text. The second proposal was to have the reviewer re-run the agent on the same prompt. That failed on determinism and cost, since the second run explores a different path and produces a different patch that nobody asked for. The third proposal was to trust the diff plus green CI, which sounds mature until someone notices the CI job ran the union of all tests rather than the specific discovery path the agent followed.

The session kept exactly one decision: every claim in the PR body must cite a numbered step in a machine-readable command log, and that log must replay cleanly in a fresh checkout. Everything else, including the transcript, was discarded as supporting material rather than evidence.

The decision kept: four parts of a replay packet

The packet has a command recorder, a normalizer that removes inevitable noise, a replayer that compares exit codes and output hashes, and a linter that refuses unsupported sentences. The format is deliberately dull, because dull formats survive contact with reviewers.

Step 1: record each command as one JSON line

A sourced shell function wraps every command the agent runs and appends one line to session.jsonl. The recorder stores the command, the exit code, a hash of normalized output, and a duration for human context only.

# tools/record.sh — source this before the session starts
LOG="${SESSION_LOG:-session.jsonl}"
__seq=$(wc -l < "$LOG" 2>/dev/null || echo 0)

rec() {
  local cmd="$1" start end code out sha
  start=$(date +%s%3N)
  out=$(eval "$cmd" 2>&1); code=$?
  end=$(date +%s%3N)
  sha=$(printf '%s' "$out" | python3 tools/normalize.py | sha256sum | cut -d' ' -f1)
  __seq=$((__seq + 1))
  python3 - "$__seq" "$cmd" "$code" "$sha" "$((end - start))" "$LOG" <<'PY'
import json, sys
seq, cmd, code, sha, ms, path = sys.argv[1:7]
with open(path, "a") as f:
    f.write(json.dumps({"seq": int(seq), "cmd": cmd, "exit": int(code),
                        "out_sha": sha, "duration_ms": int(ms)}) + "\n")
PY
  printf '%s\n' "$out"
  return $code
}

rec "pytest -q tests/test_router.py"   # seq 1: expected failure before the fix
rec "pytest -q tests/test_router.py"   # seq 2: expected pass after it

Step 2: normalize output before hashing it

Raw output never matches twice, because timestamps, temporary paths, and pytest durations move on every run. The normalizer strips those classes of noise and leaves the structural text intact, which is what a reviewer actually cares about.

# tools/normalize.py
import re, sys

RULES = [
    (re.compile(r"0x[0-9a-fA-F]+"), "0xADDR"),
    (re.compile(r"\d{4}-\d{2}-\d{2}T[\d:.]+Z?"), "<TS>"),
    (re.compile(r"/tmp/[^\s:]+"), "<TMP>"),
    (re.compile(r"\b\d+(?:\.\d+)?(?:ms|s|us)\b"), "<DUR>"),
]

def normalize(text: str) -> str:
    for pattern, replacement in RULES:
        text = pattern.sub(replacement, text)
    return "\n".join(l.rstrip() for l in text.splitlines() if l.strip())

if __name__ == "__main__":
    sys.stdout.write(normalize(sys.stdin.read()))

Step 3: replay in a clean checkout

The replayer reads the log, re-executes each command, and compares both the exit code and the normalized hash. Three verdicts are possible: PASS, DIVERGED, or UNRUNNABLE for an empty or malformed log. Notice that a step is allowed to have a non-zero exit code, because the failing-then-passing pair is often the most valuable evidence in the packet.

#!/usr/bin/env python3
# tools/replay.py
import hashlib, json, subprocess, sys
from tools.normalize import normalize

def out_hash(text: str) -> str:
    return hashlib.sha256(normalize(text).encode()).hexdigest()

def main(log_path: str, timeout: int = 300) -> int:
    rows = [json.loads(line) for line in open(log_path) if line.strip()]
    if not rows:
        print("VERDICT: UNRUNNABLE (empty log)")
        return 2
    diverged = 0
    for row in rows:
        proc = subprocess.run(row["cmd"], shell=True, capture_output=True,
                              text=True, timeout=timeout)
        ok = (proc.returncode == row["exit"] and
              out_hash(proc.stdout + proc.stderr) == row["out_sha"])
        diverged += 0 if ok else 1
        print(f"[{'ok' if ok else 'DIVERGED'}] seq={row['seq']} "
              f"exit={proc.returncode}/{row['exit']} {row['cmd']}")
    verdict = "PASS" if diverged == 0 else "DIVERGED"
    print(f"VERDICT: {verdict} ({diverged}/{len(rows)} steps differ)")
    return 0 if diverged == 0 else 1

if __name__ == "__main__":
    sys.exit(main(sys.argv[1]))

Step 4: lint the PR body against the log

The final piece is the part the senior cared about most, because it converts prose into citations. Sentences in the PR body carry markers such as [seq:2], and the linter rejects any marker that points at a missing step or at a step that exited non-zero without being described as an expected failure.

# tools/claims.py  — usage: python3 tools/claims.py PR_BODY.md session.jsonl
import json, re, sys

body = open(sys.argv[1]).read()
log = {r["seq"]: r for r in (json.loads(l) for l in open(sys.argv[2]) if l.strip())}
refs = {int(m) for m in re.findall(r"\[seq:(\d+)\]", body)}
missing = sorted(refs - log.keys())
unproven = sorted(s for s in refs & log.keys() if log[s]["exit"] != 0)
for s in missing:
    print(f"claim cites a step that never ran: seq={s}")
for s in unproven:
    print(f"claim cites a failing step; describe it as an expected failure: seq={s}")
sys.exit(1 if missing or unproven else 0)

A gated CI job then becomes three lines of workflow, and it fails the build on DIVERGED rather than on style. The check is cheap, deterministic for anything that does not touch the network, and readable by a reviewer who has never seen the agent.

- run: python3 tools/replay.py session.jsonl
- run: python3 tools/claims.py PR_BODY.md session.jsonl

When a replay packet is worth the overhead

Situation	Replay packet	Cheaper alternative
Patch changes runtime behavior across several modules	Yes	None that preserves evidence
Agent added or edited its own tests	Yes, the discovery path is the interesting part	Diff review only misses it
Docs, comments, or formatting only	No	Ordinary diff review
Steps depend on live third-party APIs	Partial, pin responses first	Recorded fixtures
Session log contains credentials or customer data	No, redact before recording	Manual review with a witness

Where the free model access and the free server option fit

Two parts of this workflow are annoying to provision, and that is the honest place where a hosted coding assistant earns its mention. The free model access is useful for one narrow job: turning a long session.jsonl into a first-draft claims table that a human then corrects, which is summarization rather than reasoning. The free server option matters for the reviewer side, because replaying a heavyweight environment on a laptop is exactly the step reviewers skip when they are busy.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. The availability of free model access and a free server option is supplied by the operator rather than independently verified here; the outreach brief cites a ten-million-token allowance, and that number should be treated as provisional until the current terms are read on the project's own page. Free tiers move, quotas expire, and hardware specifications are not promised by this article. Anyone planning capacity around them should confirm the present terms first and keep a fallback runner in CI, because a review gate that depends on a promotional tier is not a gate.

A reasonable next step for a team already keeping a command log is to test the replay runner on the free server for one week, compare divergence reports against the local runs, and adopt it only if the two agree.

Limitations and who should skip this

Replay is not reproducibility. Commands that hit a network, a clock, or an unstable dependency will diverge for reasons unrelated to the patch, and normalizing those differences away can hide real bugs. Logs also become a liability when they capture tokens, personal data, or internal hostnames, so redaction has to happen at record time rather than at publish time. Finally, the packet proves what ran, not that what ran was the right thing to test, and no harness fixes a weak test suite.

Teams that ship documentation-only changes, solo maintainers with a fast deterministic CI pipeline, and anyone working under a policy that forbids transcript retention should not adopt this. The packet is for the middle ground: multi-file behavioral patches where the reviewer was not present, the session was long, and the author might be asleep when the questions arrive.

The 40-Line Budget Gate: What a Senior Asked Before We Spent a Single Free Token

Avery Li — Mon, 26 Oct 2026 12:08:51 +0000

A free tier is not a budget until something refuses a request on your behalf. That sentence ended a pairing session last week, after four questions and two dead ends produced a small pre-flight gate that now runs before every prompt our team sends to a hosted coding model. The gate is under forty lines of standard-library Python, it has a table-driven test, and it would still be worth keeping if every hosted tool disappeared tomorrow.

The setup, in numbers rather than adjectives

The session started from a concrete constraint: a free tier for AI coding work, an open-source client to drive it, and a free server option for anything that needed to stay running. The operator of MonkeyCode states that the project is open source, that free model access is available, that a free server option exists, and that the free allocation includes 10 million tokens. Those figures are operator-supplied and worth re-reading on the project page before planning against them, because free-tier terms change without notice.

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

The senior in the session had one rule for the afternoon: no request leaves the machine until we can say what it costs and what happens when it fails. She did not ask for a benchmark, a pricing page, or a comparison chart. She asked four questions, and the answers turned out to be an architecture.

Four questions asked before the keyboard was touched

Where does the number live? If the remaining budget exists only in a dashboard tab, it does not exist in a script, a CI job, or a teammate's head.
What refuses the request? A warning that logs a line is not a control; a non-zero exit code is a control because shells, make targets, and pipelines already respect it.
What is the estimate allowed to be wrong about? Any heuristic will misjudge code and JSON differently from prose, so the gate needs a stated direction of error, not an accuracy claim.
What happens to local state when the host is free? Anything that is not on the local disk must be assumed to be temporary until a contract says otherwise.

Those four answers fit on an index card, which is exactly why the first two attempts were wrong.

Dead end one: counting characters and calling it accounting

The first draft divided the prompt length by four, printed a friendly number, and moved on. It looked reasonable in a demo and failed the second question immediately, because nothing in the script could stop a request; the number was decoration. The senior's objection was narrower than expected: character heuristics under-count dense code and over-count English prose, so a team that trusts the number as truth will build on sand.

The fix was to stop describing the estimate as a measurement and start describing it as a reservation. The script reserves a conservative amount before the call, records it in a ledger file on disk, and lets a later reconciliation step correct the entry once the provider reports real usage. Direction of error is stated in the docstring instead of implied by a decimal point.

Dead end two: treating the free server as a staging environment

The second draft pushed the ledger and the prompt queue onto the free server, which felt tidy and was the worst idea of the afternoon. Free hosts are excellent for experiments and terrible for silent assumptions about persistence, backups, or resource ceilings, and none of those terms had been read. The senior rewrote the plan in one line: the ledger stays on the developer's machine or in the repository, and the server holds only what can be rebuilt from that ledger in a minute.

That single constraint also removed a class of security questions. No credentials, no customer text, and no long-lived secrets were placed on the hosted side, so a surprise reset would cost a restart rather than an incident review. Readers should verify the data-handling and persistence terms of any free host themselves; this article does not claim to know them.

The decision kept: reserve before send, reconcile after

The artifact that survived is a gate that returns a decision and an exit code, and a ledger that can be inspected with a text editor. It is deliberately boring, because boring code gets run.

#!/usr/bin/env python3
"""budget_gate.py -- refuse a request the free tier cannot comfortably pay for.

Stdlib only. The token estimate is a heuristic for allocation discipline,
not for billing reconciliation.
"""
import json
import os
import sys
import time

CHARS_PER_TOKEN = 4          # conservative for prose, risky for dense code
LEDGER = os.environ.get("BUDGET_LEDGER", "budget_ledger.json")


def estimate_tokens(text: str) -> int:
    return max(1, len(text) // CHARS_PER_TOKEN)


def load_ledger(path: str = LEDGER) -> dict:
    if not os.path.exists(path):
        return {"spent": 0, "entries": []}
    with open(path, encoding="utf-8") as fh:
        return json.load(fh)


def save_ledger(data: dict, path: str = LEDGER) -> None:
    tmp = f"{path}.tmp"
    with open(tmp, "w", encoding="utf-8") as fh:
        json.dump(data, fh, indent=2, sort_keys=True)
    os.replace(tmp, path)


def verdict(prompt: str, ceiling: int, reserve: int = 0, path: str = LEDGER) -> dict:
    est = estimate_tokens(prompt)
    data = load_ledger(path)
    remaining = ceiling - data["spent"]
    decision = "allow" if est + reserve <= remaining else "refuse"
    return {"estimate": est, "remaining": remaining, "decision": decision}


def commit(amount: int, label: str, path: str = LEDGER) -> None:
    data = load_ledger(path)
    data["spent"] += amount
    data["entries"].append({"label": label, "amount": amount, "at": int(time.time())})
    save_ledger(data, path)


def reconcile(reserved: int, actual: int, label: str, path: str = LEDGER) -> None:
    """Correct the ledger once the provider reports real usage."""
    commit(actual - reserved, f"{label}:reconcile", path)


if __name__ == "__main__":
    ceiling = int(sys.argv[2]) if len(sys.argv) > 2 else 10_000_000
    with open(sys.argv[1], encoding="utf-8") as fh:
        prompt = fh.read()
    result = verdict(prompt, ceiling)
    print(json.dumps(result))
    sys.exit(0 if result["decision"] == "allow" else 1)

Wiring it into a shell workflow takes one line, and the exit code does the enforcement:

python3 budget_gate.py prompt.txt 10000000 || { echo "budget gate refused the request"; exit 1; }

Step-by-step: reproducing the afternoon in about thirty minutes

Save the script above as budget_gate.py and create an empty budget_ledger.json in the repository root.
Write the prompt to a file instead of pasting it into a shell, so the gate measures exactly what will be sent.
Run the gate, then run it again after a request, and confirm the ledger grows by the reserved amount rather than the actual amount.
Add reconciliation once the provider exposes usage numbers, and record the difference in the ledger instead of overwriting it.
Commit the ledger only if the labels are free of customer text; otherwise keep it local and commit the script alone.

The test is table-driven because the interesting cases are arithmetic, not integration:

import os
import tempfile
import unittest
import budget_gate as bg


class GateTest(unittest.TestCase):
    def setUp(self):
        fd, self.path = tempfile.mkstemp(suffix=".json")
        os.close(fd)
        os.unlink(self.path)
        self.ceiling = 1000

    def test_decision_table(self):
        cases = [
            ("empty ledger", "", 0, "allow"),
            ("a third spent", "x" * 2000, 300, "allow"),
            ("half spent", "x" * 2000, 500, "refuse"),
            ("near ceiling", "x" * 2000, 990, "refuse"),
        ]
        for name, prompt, spent, expected in cases:
            if os.path.exists(self.path):
                os.unlink(self.path)
            if spent:
                bg.commit(spent, "seed", self.path)
            got = bg.verdict(prompt, self.ceiling, reserve=100, path=self.path)["decision"]
            self.assertEqual(got, expected, name)

The fourth row is the one that earns its place: a nearly exhausted ledger must refuse even a small request, because the reserve represents the follow-up call that a refusal protects.

Routing table: what belongs on the free tier at all

Task shape	Route	Reason	Guard
Explaining unfamiliar code	Free hosted model	Cheap, reversible, read-only	Prompt files contain no secrets
Writing a first draft of tests	Free hosted model	Reviewable by a human in minutes	Gate plus mandatory test run
Long refactors across modules	Senior reviewer first	Estimation error compounds	One file per request
Anything with customer text	Local only	Data boundary unknown	Explicit approval
Scheduled jobs or queues	Free server, state off-host	Host may reset	Rebuild from local ledger

Limitations and who should not use this

The heuristic is not a measurement, and teams that already receive per-request usage numbers should reconcile on every call rather than reserving. Anyone running regulated workloads, handling personal data, or needing uptime guarantees should not put the free server in a critical path, regardless of how good the experiment looked. This approach also does nothing to improve model output quality; it only prevents a quiet budget exhaustion that turns into a broken pipeline on a Friday.

For teams that want to try the workflow against a hosted free tier, the operator's stated 10 million free tokens and free server option are the entry point, and the terms are worth reading before anyone depends on them.

One Question, Three Dead Ends, One Exit Table: A Pairing Session on Free-Tier Infrastructure

Avery Li — Tue, 20 Oct 2026 10:11:30 +0000

One Question, Three Dead Ends, One Exit Table: A Pairing Session on Free-Tier Infrastructure

The session produced no new prompt and no new vendor. It produced one script, one table, and a stop rule that outlived the afternoon. The kept decision was a portability proof: a single command that rebuilds the application from the repository and re-runs the same contract tests against whichever model route or host happens to be configured that week. Everything else discussed in the call was recorded as a dead end, with the reason it failed written down next to it.

The decision, stated before the story

A small internal tool had been assembled quickly on top of free model access and a free server option, and nobody could answer a simple question about it. The pair on the call were a mid-level engineer who had written most of the code and a senior engineer who had reviewed none of it. The senior's contribution was one question, asked early, and then repeated whenever the conversation drifted. The output of the session was deliberately narrow, because the alternative was another week of prompt tuning.

The tool itself is unremarkable and that is the point. It accepts a unified diff, calls a model, and returns a structured summary containing three fields: a short prose summary, the list of touched files, and a coarse risk label.

Step 1 — Record what the application actually depends on

Before any code was touched, the pair wrote down an inventory of state, sorted by who owns it. Purely local logic covered the diff parser, the response validator, and the rendering layer, and all of that could run with no network at all. The model call was external by definition, and the job store lived on the free server that had been used for the first deploy. The inventory mattered because it converted a vague worry about free tiers into three named dependencies with three different exit paths.

A grep over the source produced the configuration surface, which is usually smaller than people assume. The command below is the exact one used in the session, and it works for most TypeScript or Python services without modification.

grep -RIn --include='*.ts' --include='*.py' -E 'process\.env\.[A-Z_]+|os\.environ\[["'"'"'][A-Z_]+' . \
  | sort -u

The result was reviewed line by line against .env.example, and any key that appeared in code but not in the example file was treated as a defect. That single check removed the most common cause of "it works on the free server but not locally" reports.

MonkeyCode's free model access and free server option were the starting point for this build, and both are availability claims rather than service guarantees. Quotas, limits, and hardware characteristics should be read from the project's own documentation on the day you depend on them, because free-tier terms change. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Step 2 — Three dead ends, and why each one closed

The first dead end was the most tempting one: add more context to the prompt so the model would stop returning malformed responses. Roughly half the call went into this before anyone noticed that the failure class had not changed at all. The parser was rejecting a field that the prompt had never asked for in a machine-checkable way, so better prose could not fix it.

The second dead end was architectural politeness. Someone proposed a managed queue and a small cache to smooth over cold starts on the free host, which would have added two dependencies that each needed their own exit path. The senior's objection was blunt and correct: hiding a cold start does not remove the dependency, it only makes the dependency harder to observe.

The third dead end was the argument about reliability numbers, which nobody could settle inside the session. Neither engineer had a primary source open, and both were quoting remembered figures about uptime and rate limits. The pair agreed to stop discussing any number that could not be pasted from documentation with a date attached.

Dead end	What it looked like	Why it closed
Prompt expansion	More instructions, more examples, same rejection	Failure was in the parser contract, not the prose
Managed queue and cache	Two new services to absorb cold starts	Converted one observable dependency into three
Uptime debate	Recalled figures with no source	No primary source available in the session

Step 3 — The kept decision: make portability a command

The decision that survived was to prove, mechanically, that the application can be rebuilt and booted from the repository alone. This is not a migration plan and it is not a claim about anyone's uptime. It is a report that either passes or fails on a laptop, and it takes a few minutes to run. The script below writes a Markdown report so the result can be attached to a pull request instead of described in a meeting.

#!/usr/bin/env bash
# scripts/portability_check.sh
set -euo pipefail

REPORT="${REPORT:-portability-report.md}"
APP_DIR="${APP_DIR:-.}"
RUNTIME="${RUNTIME:-docker}"
BASE_URL="${BASE_URL:-http://localhost:8080}"

{
  echo "# Portability report"
  echo
  echo "Generated: $(date -u +%Y-%m-%dT%H:%M:%SZ)"
  echo
  echo "| Check | Expected | Observed | Verdict |"
  echo "| --- | --- | --- | --- |"
} > "$REPORT"

row() { printf '| %s | %s | %s | %s |\n' "$1" "$2" "$3" "$4" >> "$REPORT"; }
fail=0

if "$RUNTIME" build -t portability-proof:local "$APP_DIR" >/dev/null 2>&1; then
  row "image build" "exit 0" "exit 0" "pass"
else
  row "image build" "exit 0" "non-zero" "fail"; fail=1
fi

"$RUNTIME" run --rm -d --name pp -p 8080:8080 \
  --env-file .env.example portability-proof:local >/dev/null
sleep 3

if curl -fsS --max-time 5 "$BASE_URL/healthz" >/dev/null; then
  row "health endpoint" "200" "200" "pass"
else
  row "health endpoint" "200" "unreachable" "fail"; fail=1
fi

"$RUNTIME" stop pp >/dev/null 2>&1 || true
exit "$fail"

The second half of the proof is a contract test that never touches the network. It validates the response shape against a recorded fixture, so the parser can be exercised on a train with no connectivity.

# scripts/contract_check.py
import json, sys

REQUIRED = {"summary": str, "files_touched": list, "risk": str}
ALLOWED_RISK = {"low", "medium", "high"}

def check(payload: dict) -> list[str]:
    errors = []
    for key, kind in REQUIRED.items():
        if key not in payload:
            errors.append(f"missing key: {key}")
        elif not isinstance(payload[key], kind):
            errors.append(f"{key}: expected {kind.__name__}")
    risk = payload.get("risk")
    if isinstance(risk, str) and risk not in ALLOWED_RISK:
        errors.append(f"risk outside allowed set: {risk}")
    return errors

if __name__ == "__main__":
    payload = json.load(open(sys.argv[1]))
    problems = check(payload)
    print("\n".join(problems) if problems else "contract ok")
    sys.exit(1 if problems else 0)

Step 4 — Write the exit table next to the code

The exit table is the artifact most likely to be reused by someone who was not on the call. Each row names one external dependency, the reason it exists, the concrete path away from it, and the signal that would force the team to walk that path. The detection signal column is what separates this from a wish list, because it has to be observable in CI or in the report above.

Dependency	Required for	Exit path	Detection signal	Re-check
Model route	Summaries	Swap base URL and key; parser already covered by fixture test	Contract check fails twice on `main`	30 days
Free server	Hosting	Image builds and boots from the repository	Build or health check fails	30 days
`.env.example`	Configuration	Only listed keys are read by the app	Env grep finds an undocumented key	30 days

A short decision record sits above the table, so the reasoning survives the people who wrote it. The pair used five lines and no ceremony, because a heavier format would not have been filled in.

Decision D-14 — portability proof before new features
Kept because: the boot path is the only thing the team controls outright
Rejected: prompt expansion, managed queue, uptime debate
Re-check: rewrite this record after the next dependency review
Owner: whoever changes the model route or the host

Step 5 — Attach a stop rule, not a reminder

The last thing agreed in the session was a stop rule with no discretion built into it. If any row of the exit table fails twice on main in the same week, the feature under development does not ship until that row is fixed or deleted. Deletion counts, because a dependency nobody needs has no exit path to maintain.

The rule works because it is boring and mechanical. It removed the need to renegotiate the same trade-off in every review, and it gave the junior engineer a defensible answer when a stakeholder asked for a faster turnaround on the free tier.

Limitations and who should not use this

The portability proof says nothing about model quality, and it cannot validate any quota, limit, or hardware claim made by a free-tier provider. Terms change without notice, so the re-check column exists precisely because the report has a shelf life measured in weeks.

Teams handling regulated data, or operating under a contractual availability target, should not begin on a free tier at all. The overhead of building this proof is justified only when the free route is genuinely provisional, which is an organisational judgement rather than a technical one.

The scripts above assume a container runtime, curl, and a health endpoint that already exists; the contract checker assumes a response shape the reader must define. None of it was benchmarked against a paid provider, and no comparison is implied.

If the same exercise is attempted with MonkeyCode's free model access and free server option, the exit table belongs in the repository next to the code it describes, not in a document nobody opens.

Three Dead Ends and One Routing Table: A Pairing Session on Free-Tier AI Work

Avery Li — Mon, 19 Oct 2026 08:55:08 +0000

The decision that survived the session had nothing to do with model quality. It was a routing table: disposable work goes to free-tier capacity, and anything a reviewer would have to re-litigate stays with the reviewer. The protocol below is presented as a template for running that session, not as a transcript of one team's meeting; the dialogue is reconstructed to show the shape of the exchange.

Why a pairing session beats a benchmark for this question

Benchmarks answer how a model scores on someone else's tasks, and they say nothing about which of your tasks should leave your machine. A pairing session answers the narrower question that actually blocks adoption. Two people, one hour, a shared screen, and a written decision at the end cost less than a week of private evaluations. Earlier coverage on this account examined retry probes, fixture contracts, and CI gates; this piece covers the routing decision that logically precedes all three.

The setup: four artifacts before anyone opens an editor

The session works best when both participants arrive with something concrete: a task list, a failure history, a test oracle, and a blank decision record. Without the task list, the conversation drifts into opinions about model quality. Without the failure history, nobody remembers which past incident made the team cautious in the first place.

Step 1 — Write twelve candidate tasks on one page

Twelve is enough to expose a pattern and small enough to finish in a single sitting. Each line carries the task name, the file or module it touches, and how long a wrong answer would take to undo. Tasks that cannot be named at that level of detail are usually not ready for any assistant.

scaffold a new endpoint handler from an existing one     app/api/*        undo: 5 min
regenerate a fixture file from a schema                  tests/fixtures   undo: 2 min
rename a config key across four call sites               config/*         undo: 10 min
refactor the retry policy inside the HTTP client         lib/http/*       undo: 2 days
draft release notes from merged PR titles                docs/*           undo: 1 min

Step 2 — Record the failure history beside each task

The senior's first contribution is the memory the team never wrote down. One column holds the incident, one holds the cost, and one holds whether a test would have caught it. This column decides more routings than any latency measurement taken during the session.

The three questions the senior actually asked

Only three questions came up, and none of them concerned which model performed better. Each one maps to a column in the routing table, which is why the table survives contact with tasks nobody anticipated.

Question one: what happens if this is wrong and nobody notices for a week? Tasks touching service configuration or persisted data fail that question by construction. A rename inside one module usually passes, because a compiler or an existing test notices within minutes rather than days.

Question two: is there anything that fails loudly when the answer is wrong? A fixture regeneration has a schema as an oracle, while release notes have a reviewer and no oracle at all. The presence of a loud failure is the strongest single predictor of safe free-tier routing, stronger than task size or apparent difficulty.

Question three: who re-opens this decision if the output is wrong? If the answer is a senior reviewer with limited hours, the task belongs in reviewed capacity regardless of how good the draft looks. This question reframes the cost of a mistake as someone else's afternoon rather than your own ten minutes.

Three dead ends, in the order they appeared

Dead end one: measuring acceptance rate

The first proposal was to track how often generated patches were accepted without edits. It failed within ten minutes, because nobody had a baseline from before the assistant existed. Acceptance rate also rewards small trivial edits and punishes the difficult refactors that need the most scrutiny. The number would have looked healthy while measuring nothing that mattered to the team.

Dead end two: moving the whole test suite to the free server

The second proposal treated the free server as a CI replacement, which conflated two different guarantees: a machine that runs code, and an environment that reproduces production failures. Cache state, service versions, and network egress all differ, so a green run there proves considerably less than the team assumed. The free server is useful for interactive work, not as a release gate.

Dead end three: routing a security-adjacent refactor to free models

The third proposal looked reasonable on paper, because the refactor carried good test coverage. It failed on the re-litigation question, since the reviewer would re-read every line regardless of the test result. Review attention, not compute, was the scarce resource in that particular case. The task moved to reviewer-owned capacity and the session moved on.

The decision that was kept

The kept decision is a three-lane routing table encoded as a small function, so new tasks get classified by the same rubric the pair agreed on. The function makes no model calls and holds no credentials, which means it can live in the repository and be reviewed like anything else.

# tools/route.py
from dataclasses import dataclass
from enum import Enum

class Lane(str, Enum):
    FREE = "free-tier"
    REVIEWER = "reviewer-owned"
    HYBRID = "free-tier draft + reviewer sign-off"

@dataclass(frozen=True)
class Task:
    name: str
    reversible: bool        # wrong answer undone in under an hour?
    blast_radius: str       # "file" | "module" | "service" | "data"
    has_oracle: bool        # does something fail loudly on a wrong answer?
    reopens_review: bool    # would a reviewer re-read every line anyway?

def route(task: Task) -> Lane:
    if task.blast_radius in {"service", "data"}:
        return Lane.REVIEWER
    if task.reopens_review:
        return Lane.REVIEWER
    if not task.reversible and not task.has_oracle:
        return Lane.REVIEWER
    if task.reversible and task.has_oracle:
        return Lane.FREE
    return Lane.HYBRID

The table the pair filled in during the session, reproduced here with illustrative task names:

Task	Reversible	Blast radius	Oracle	Lane
Scaffold handler from sibling file	yes	file	yes	free-tier
Regenerate fixture from schema	yes	file	yes	free-tier
Draft release notes	yes	file	no	free-tier draft + sign-off
Rename config key	yes	module	yes	free-tier
Refactor HTTP retry policy	no	module	partial	reviewer-owned
Migrate a column type	no	data	yes	reviewer-owned

A short test pins the rubric so that a later edit cannot quietly widen the free lane:

# tests/test_route.py
from tools.route import Lane, Task, route

def test_service_work_never_routes_to_free_tier():
    t = Task("rotate credentials", reversible=False, blast_radius="service",
             has_oracle=True, reopens_review=False)
    assert route(t) is Lane.REVIEWER

def test_small_reversible_work_with_oracle_uses_free_tier():
    t = Task("scaffold handler", reversible=True, blast_radius="file",
             has_oracle=True, reopens_review=False)
    assert route(t) is Lane.FREE

Where the free tier actually participates

The free-tier lane is where MonkeyCode's two operator-supplied offerings entered the discussion: free access to hosted models, and a free server option for running the workbench without provisioning a machine. Both claims come from the project's operator, and both should be checked against the project's current page rather than any figure quoted in an article, because quotas, model names, and machine specifications change over time. MonkeyCode is an open-source project, so the workbench itself can be inspected and self-hosted when the hosted path does not fit a team's constraints.

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

What made those offerings relevant was not raw capability but the shape of the free lane. Every task in that lane is reversible within an hour and has a loud oracle, so an interrupted session, a rate limit, or a model that changes under you costs minutes. That property holds regardless of which model answers the call, which is why the routing table outlives any particular release.

For the free server, the useful placement is the interactive workbench: generate the scaffold, run the single targeted test, discard the machine. The reviewer-owned lane keeps its own environment, its own credentials, and its own clock.

Keeping the decision after everyone forgets the session

A decision that lives in a chat thread disappears in roughly two sprints. The pair wrote it as an ADR with a reversal trigger, which is the field most teams omit.

# docs/adr/0012-free-tier-routing.yaml
decision: route reversible, oracle-backed, file-or-module work to free-tier capacity
context: three dead ends in one session; review attention is the scarce resource
reversal_trigger: >
  revert if two consecutive weeks pass with more than one free-lane patch
  reopened by a reviewer for a correctness reason
owner: platform-pairing
reviewed_on: <date of the session>

A four-line check keeps the trigger visible, and it runs in the same pipeline as the unit tests above:

#!/usr/bin/env bash
set -euo pipefail
adr="docs/adr/0012-free-tier-routing.yaml"
grep -q "reversal_trigger" "$adr" || { echo "ADR missing reversal trigger"; exit 1; }
grep -q "owner" "$adr" || { echo "ADR missing owner"; exit 1; }
echo "routing ADR intact"

Limitations and who should skip this

The routing table encodes judgement rather than truth, and it will misfile tasks that sit on a boundary between two lanes. Teams under regulated data constraints should not route anything to hosted models, whatever a free tier happens to offer this quarter. Teams without a test oracle will find almost every task landing in the reviewer-owned lane, and that outcome is correct rather than a failure of the tooling.

The free server is not a CI gate, and treating it as one weakens guarantees the team already has. The approach also assumes two people can spend an hour together, which is a real cost for small teams shipping under a deadline. Readers who want a starting point can take the routing function and the ADR template as they are, then adapt the three questions before adapting anything else.

Before You Blame the Model: A Retry Probe That Ends the Argument in One Afternoon

Avery Li — Sun, 18 Oct 2026 07:30:22 +0000

Before You Blame the Model: A Retry Probe That Ends the Argument in One Afternoon

The disagreement that survives a pairing session is rarely about the patch itself; it is about the sequence the patch creates. Retry loops are the usual suspect, because every individual attempt looks defensible while the overall behavior quietly changes the task on each pass. A probe that records attempt index, payload shape, outcome, and elapsed time turns that ambiguity into a two-minute read of a JSONL file. The decision worth keeping is procedural rather than stylistic: instrument the sequence before anyone argues about the cause.

The patch that started the session

The patch under review was a small generator: it asked a model for a JSON object, validated the object, and retried up to three times when validation failed. The senior's objection was a single sentence, and it was not about correctness at all — attempt two had no reason to succeed. The session script below is a reconstructed teaching artifact rather than a transcript, and the stub in step 3 is the only part a reader has to supply.

The reviewer's claim was testable, which is what made the session useful. Either the retry re-sent the same task and deserved another chance, or it re-rolled the task and deserved deletion. Nobody in the room could tell which one the code did by reading it, and that gap is the whole article.

Three dead ends, in the order they happened

1. Rewriting the prompt

The first instinct was to tighten the instruction so that attempt one would succeed and the retry would never fire. This changes the sample rather than the code path, so it produces a cleaner demo and identical production behavior. It also hides the defect behind a prompt that happens to work on the current inputs.

2. Reaching for a larger model

The second attempt was to swap in a stronger model and observe that the validation error disappeared. That result is real but not portable, because the loop's structure is model-agnostic and the failure returns the moment the model changes again. Comparing models before understanding the loop answers a question nobody asked.

3. Arguing from documentation

The third dead end was citation: the client library documents retries, the vendor documents determinism caveats, and both statements are true and irrelevant. Documentation describes intent at the boundary, while the probe measures behavior inside the loop. The session only moved forward when the argument stopped being about what should happen.

The decision that was kept

One policy line ended the discussion and outlived the patch: no claim about a generated retry survives review without a per-attempt record. The record has four fields, and none of them are optional — attempt index, payload key set, outcome, and elapsed milliseconds. With those four columns, a reviewer can distinguish a genuine retry from a re-roll without reading the prompt at all.

The signal that matters most is payload drift between attempt one and attempt two. If the key set changes, the loop is sampling a new task on each pass and calling it a retry, which is a design error rather than a model limitation. If the key set is stable and the failure repeats, the validator or its contract is the suspect. Nothing else in the session produced a decision that survived the week.

Build the probe in five steps

Step 1 — Record one row per attempt

# probe_retry.py — writes one JSONL row per attempt. Standard library only.
import json, sys, time, uuid
from dataclasses import dataclass, asdict

@dataclass
class Attempt:
    request_id: str
    attempt_index: int
    model: str
    outcome: str          # "ok" | "retry" | "give_up"
    elapsed_ms: int
    payload_keys: list

def run_once(generate, validate, model, max_attempts=3):
    request_id = uuid.uuid4().hex[:12]
    rows = []
    for i in range(1, max_attempts + 1):
        started = time.perf_counter()
        try:
            payload = generate(model)
            outcome = "ok" if validate(payload) else "retry"
        except Exception as exc:
            payload, outcome = {"_error": type(exc).__name__}, "retry"
        rows.append(Attempt(
            request_id=request_id,
            attempt_index=i,
            model=model,
            outcome=outcome,
            elapsed_ms=int((time.perf_counter() - started) * 1000),
            payload_keys=sorted(payload.keys()) if isinstance(payload, dict) else [],
        ))
        if outcome == "ok":
            break
    else:
        rows[-1].outcome = "give_up"
    return rows

Step 2 — Replace the stub, keep the signature

The generate and validate callables are injected on purpose, so the harness never imports a client and never needs credentials to run. In practice generate wraps one model call and returns a parsed dict, while validate returns a boolean. Label any unexecuted version of this file as a sketch, because a probe that was never run is an opinion with indentation.

Step 3 — Drive forty requests and flush to disk

# __main__ block — 40 requests per model, one JSONL file per model.
if __name__ == "__main__":
    model = sys.argv[sys.argv.index("--model") + 1]
    runs = int(sys.argv[sys.argv.index("--runs") + 1])
    for _ in range(runs):
        for row in run_once(generate, validate, model):
            print(json.dumps(asdict(row)), flush=True)

Step 4 — Reduce the file to five numbers

# summarize.py — the only five numbers a pairing session needs.
import json, sys
from collections import defaultdict

def summarize(rows):
    requests = defaultdict(list)
    for row in rows:
        requests[row["request_id"]].append(row)
    total = len(requests)
    ok = sum(1 for rs in requests.values() if rs[-1]["outcome"] == "ok")
    reshaped = sum(
        1 for rs in requests.values()
        if len(rs) > 1 and rs[1]["payload_keys"] != rs[0]["payload_keys"]
    )
    return {
        "requests": total,
        "success_rate": round(ok / total, 3),
        "attempts_per_request": round(sum(len(rs) for rs in requests.values()) / total, 2),
        "give_up": sum(1 for rs in requests.values() if rs[-1]["outcome"] == "give_up"),
        "reshaped_retries": reshaped,
    }

for path in sys.argv[1:]:
    print(path, summarize([json.loads(l) for l in open(path) if l.strip()]))

Step 5 — Run both configurations on the same day

python probe_retry.py --model model-a --runs 40 > a.jsonl
python probe_retry.py --model model-b --runs 40 > b.jsonl
python summarize.py a.jsonl b.jsonl

Running the second configuration on free infrastructure

Free model access has exactly one useful role in this workflow: it lets the same probe run against a second model without a budget conversation. MonkeyCode's free model access and free server option are availability claims supplied by the operator, and they are sufficient for an A/B run of forty requests per side. The free server option matters for a mundane reason — probe runs are long and boring, and a laptop that sleeps mid-run writes a file that mimics a rate-limit failure.

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

Two rules keep the comparison honest. First, keep the request count identical on both sides, because forty-versus-twenty invites a success-rate gap that is really a sample-size gap. Second, write the model identifier into every row, since free model lists rotate and a result without an identifier cannot be reproduced next month. Quotas and model names change often enough that a number quoted in a blog post is worse than no number at all, so read the console before planning a run.

Decision table

Probe observation	Reading	Action
`attempts_per_request` near 1.0, `success_rate` near 1.0	The loop rarely fires; the objection was stylistic	Keep the patch, close the thread
`attempts_per_request` above 1.3, `reshaped_retries` = 0	Stable failure, same task, likely validator contract	Fix the contract, keep the retry
`reshaped_retries` > 0	Each attempt samples a new task	Delete the retry, make the request explicit
High `give_up` on both models	Not model-specific	Fix the code path before touching the model
`give_up` differs sharply between models	Model-sensitive	Record the identifier, avoid generalizing the claim

Limitations, and who should skip this

The harness runs in a single process, so it misses concurrency effects and any failure that only appears under parallel load. Forty requests produce a useful ratio and a useless confidence interval, which is fine for a design argument and not fine for a release gate. The stub's validator may itself be the defect, in which case the probe faithfully measures the wrong thing.

Teams that gate releases on latency percentiles should use their existing load tooling instead of a script like this. Anyone whose retry crosses a side-effecting boundary such as payments or email should point the probe at a dry-run sink before the first run. During live incident triage, five minutes of manual reading usually beats a harness that has not been written yet.

When the probe does earn a place in the repository, the free tier is enough to run that first side-by-side comparison before the harness is worth automating.

From Pairing Call to CI Gate: Encoding One Senior Objection as a Test

Avery Li — Sat, 17 Oct 2026 06:32:08 +0000

A pairing session pays for itself only when one objection from it can be executed later, without the senior in the room. Everything else — the tangent about naming, the two drafts nobody kept, the coffee — is atmosphere. This article turns a single spoken objection into a checked gate: a JSON decision file, a ~90-line standard-library Python script, and one CI step. The gate runs offline on purpose, so the free server that made the session cheap never becomes load-bearing for the result.

The session, compressed

The patch under review was a generated worker that retries a flaky upstream call. A reviewer with ten years on the service, referred to here as R., and the author read the draft together for roughly forty minutes. Candidate drafts came from MonkeyCode's free model access, which is the reason a second and third version existed at all; a free server option let both people run the draft once and watch it fail on the same input. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Three things were discussed and one survived. The naming of attempt versus try_index was dropped because both names are fine. A proposed metrics counter was dropped because nobody could say who would read it. What survived was a single sentence from R.: the retry budget must be a module constant, and no test may prove the worker correct while depending on the free server being reachable. That sentence is the whole output of the session, and it is worth more than the diff.

Step 1 — Write the decision down before the call ends

The rule that keeps this honest is one claim per decision, and every claim must name a file pattern or a path. A claim that cannot be expressed as a pattern is a preference, and preferences belong in a comment, not a gate. The file below is the complete input to the checker in step 2.

{
  "session": "worker-retry-2026-10-15",
  "owner": "worker-team",
  "decisions": [
    {
      "id": "D1",
      "claim": "The retry budget is a module constant; no code path reads it from the environment.",
      "forbid_regex": [
        { "glob": "worker/**/*.py", "pattern": "RETRY_BUDGET\\s*=\\s*int\\(os\\.environ" }
      ],
      "require_changed": ["tests/test_retry_budget.py"],
      "expires": "2027-01-15"
    },
    {
      "id": "D2",
      "claim": "The retry test never addresses a network host, so it passes with the free server unreachable.",
      "forbid_regex": [
        { "glob": "tests/**/*.py", "pattern": "https?://" }
      ],
      "require_changed": ["tests/test_retry_budget.py"],
      "expires": "2027-01-15"
    }
  ]
}

Two fields carry more weight than they look. require_changed forces the patch to bring test evidence in the same commit, which is the mechanical version of R.'s objection. expires exists so the gate dies if nobody re-argues it; an unexpiring rule written during one call becomes folklore within two quarters.

Step 2 — A checker that reads the diff, not opinions

The script below uses only the standard library and git, so it runs anywhere the repository already runs. It compares the decision file against git diff base...HEAD, collects added lines per path, and exits non-zero on the first contradiction.

#!/usr/bin/env python3
"""check_decisions.py — fail when a patch contradicts a decision made in pairing."""
from __future__ import annotations

import argparse
import datetime
import fnmatch
import json
import re
import subprocess
import sys
from pathlib import Path


def git(*args: str) -> str:
    return subprocess.run(("git", *args), check=True, text=True,
                          capture_output=True).stdout


def changed_files(base: str) -> list[str]:
    out = git("diff", "--name-only", f"{base}...HEAD")
    return [line.strip() for line in out.splitlines() if line.strip()]


def added_lines(base: str) -> dict[str, list[str]]:
    """Map path -> added lines, parsed from a zero-context diff."""
    diff = git("diff", "-U0", "--no-color", f"{base}...HEAD")
    result: dict[str, list[str]] = {}
    path = None
    for line in diff.splitlines():
        if line.startswith("+++ b/"):
            path = line[6:]
            result.setdefault(path, [])
        elif path and line.startswith("+") and not line.startswith("+++"):
            result[path].append(line[1:])
    return result


def check(decision: dict, files: list[str], added: dict[str, list[str]],
          today: str) -> list[str]:
    problems: list[str] = []
    ident = decision["id"]

    for glob in decision.get("forbid_paths", []):
        problems += [f"{ident}: forbidden path changed: {f}"
                     for f in files if fnmatch.fnmatch(f, glob)]

    for rule in decision.get("forbid_regex", []):
        rx = re.compile(rule["pattern"])
        for path, lines in added.items():
            if not fnmatch.fnmatch(path, rule["glob"]):
                continue
            for line in lines:
                if rx.search(line):
                    problems.append(
                        f"{ident}: {path} adds `{line.strip()}`")

    for glob in decision.get("require_changed", []):
        if not any(fnmatch.fnmatch(f, glob) for f in files):
            problems.append(f"{ident}: no changed file matches {glob}")

    if decision.get("expires", "9999-12-31") < today:
        problems.append(
            f"{ident}: expired on {decision['expires']}; re-decide it")

    return problems


def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument("--config", default="decisions.json")
    parser.add_argument("--base", default="origin/main")
    parser.add_argument("--today", default=None,
                        help="fixed date, for reproducible runs")
    args = parser.parse_args()

    config = json.loads(Path(args.config).read_text())
    today = args.today or datetime.date.today().isoformat()
    files = changed_files(args.base)
    added = added_lines(args.base)

    problems: list[str] = []
    for decision in config["decisions"]:
        problems += check(decision, files, added, today)

    if problems:
        print("Pairing decisions contradicted:", file=sys.stderr)
        for problem in problems:
            print(" -", problem, file=sys.stderr)
        return 1

    print(f"{len(config['decisions'])} decisions hold")
    return 0


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

The --today flag matters more than it appears. Expiry logic that reads the wall clock is untestable, and an untestable gate becomes the first thing someone disables on a Friday.

Step 3 — Reproduce both outcomes in a throwaway repository

The sequence below builds a two-commit fixture, then runs the checker against a passing patch and a violating one. Expected output is included, so the reproduction is checkable without reading the script first.

mkdir -p /tmp/pairing-gate && cd /tmp/pairing-gate
git init -q -b main
mkdir -p worker tests
printf 'RETRY_BUDGET = 3\n' > worker/retry.py
printf 'def test_budget_is_constant():\n    assert True\n' > tests/test_retry_budget.py
git add -A && git commit -qm "base"

Case A — a patch that keeps the decision:

printf 'RETRY_JITTER = True\n' >> worker/retry.py
printf '\ndef test_jitter_is_not_configurable():\n    assert True\n' \
  >> tests/test_retry_budget.py
git commit -qam "add jitter, keep budget constant"
python3 check_decisions.py --config decisions.json --base main~1 --today 2026-10-17
# 2 decisions hold

Case B — a patch that quietly makes the budget configurable and points a test at a host:

printf 'import os\nRETRY_BUDGET = int(os.environ["RETRY_BUDGET"])\n' > worker/retry.py
printf 'import requests\n\ndef test_reachable():\n    requests.get("http://example.invalid/health")\n' \
  >> tests/test_retry_budget.py
git commit -qam "make budget configurable"
python3 check_decisions.py --config decisions.json --base main~1 --today 2026-10-17
# Pairing decisions contradicted:
#  - D1: worker/retry.py adds `RETRY_BUDGET = int(os.environ["RETRY_BUDGET"])`
#  - D2: tests/test_retry_budget.py adds `    requests.get("http://example.invalid/health")`
# exit code 1

Case B is the entire value of the hour. The violation is caught by a rule written while R. was still on the call, six weeks before anyone re-reads the diff with fresh eyes.

Step 4 — Wire it into pull requests

One job, one step, and a full-history checkout so the merge base resolves. Fetching depth matters here; a shallow clone silently turns base...HEAD into something the checker cannot reason about.

name: pairing-decisions
on: pull_request
jobs:
  decisions:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Check decisions
        run: >
          python3 check_decisions.py
          --config decisions.json
          --base "origin/${{ github.base_ref }}"

Keep the step non-blocking for the first week and read what fires. In the fixture above only two rules exist; a real repository will show which patterns are too broad before they annoy anyone.

Step 5 — Retire decisions on purpose

A gate that nobody deletes is a gate that eventually rejects correct code. The expiry field forces a monthly five-minute review with three possible outcomes: renew with a new date, narrow the pattern, or delete the rule because the code shape now enforces it. In this session, D1 was later replaced by a type-level constant, and the regex was deleted rather than extended; D2 stayed, because tests still reach for hosts when nobody is watching.

Where the free model and the free server actually sat

MonkeyCode appeared twice in the session, both times in the draft phase. Free model access produced a second version of the retry loop after R. rejected the first, which saved the usual week of asynchronous back-and-forth. The free server option ran that version once so both people watched the same failure instead of describing it. Nothing from either was used to prove correctness, and the gate deliberately runs offline for exactly that reason.

Token allowances, model lists and server terms change without notice, so this article quotes none of them. Check the project's own documentation for current numbers before planning work around them, and treat any figure you read in a blog post as stale until verified.

Limitations and who should skip this

A solo prototype with no CI does not need a decision file; the same knowledge lives in the author's head for the two weeks the code exists. Teams whose base branch accumulates dozens of unrelated commits will find require_changed noisy until they switch to the merge base explicitly. Regex gates check shape, not meaning: a determined patch can move the violation one file over and pass, so the gate raises the cost of an accident rather than preventing a decision. Finally, the checker says nothing about whether the generated worker is correct — it only says whether the patch contradicts what two people agreed to.

Who should not use it: teams that cannot commit to a monthly review, repositories where the reviewer changes every patch, and anyone tempted to add a rule after every disagreement. Two rules that survive review are worth more than twenty that nobody reads. If the session produced no objection a machine can check, the honest output is a comment on the pull request and no gate at all.

For anyone replaying this session, free model access gets a second draft in front of a reviewer within the hour, and the free server option gets both people looking at the same failure — check the project's current terms first, then spend the saved time on the objection that will outlive the call.

A Senior Asks Five Questions Before Reading Your Generated Patch

Avery Li — Fri, 16 Oct 2026 05:34:48 +0000

A generated patch rarely fails review because of formatting, naming, or even local correctness. It fails because the reviewer cannot reconstruct the failure it was meant to fix, the files it read, and the decision it quietly made. A senior engineer paired on such a patch will often ignore the diff for the first ten minutes and walk a fixed ladder of questions instead. Once those answers are written down, the patch becomes either clearly acceptable or clearly wrong, and the debate collapses into a record.

The ladder matters more than the lint

Lint, type checks, and unit tests answer questions about the code exactly as written. They say nothing about the reasoning that produced the change, which is where generated patches go wrong most often. A patch can pass every check and still edit a module nobody asked it to touch, or hard-code an assumption that only held inside the prompt. The review therefore needs two distinct gates: a mechanical gate for the artifact, and a conversational gate for the intent behind it.

The five questions, in order

Reproduction first. Can the failure be reproduced from a clean checkout without the patch? Acceptable evidence is a command, an exit code, and one log line. If the honest answer is "probably", the session ends before the diff is opened.
Read set second. Which files, tables, or endpoints does the patch read outside the module it edits? Acceptable evidence is a grep, a trace, or an explicit import list. This catches the most common dead end: a patch that solves the stated problem by reaching into three unrelated packages.
Contract third. Which existing behavior does the patch promise to preserve, and where is that promise tested? Acceptable evidence is the name of an existing test that still passes. Silence here usually means the patch is a rewrite wearing a bugfix costume.
Rollback fourth. If the patch turns out wrong in production, what single command or flag reverses it? Acceptable evidence is the revert path itself, not a plan to write one later.
Owner fifth. Who answers for this decision in six months, and where is that recorded? Acceptable evidence is a name plus a file, usually the same decision record the session produces.

Questions one and two eliminate most candidates within minutes. Questions three through five decide whether the survivor is mergeable today or needs a follow-up ticket instead.

Running the session as a reproducible artifact

Scaffold the session directory and freeze the candidate. Copy the patch and hash it, so the reviewed bytes cannot drift during the conversation.
Record the base revision. Without it, no later reader can tell which tree the patch was generated against.
Answer the ladder in a machine-readable file. Free text in a chat thread is not a decision record; JSON or YAML is.
Gate on completeness before anyone runs the tests. An unanswered question should stop the pipeline, not scroll past it.

# questions.yml - the ladder as data
- id: q1_repro
  text: "Can the failure be reproduced from a clean checkout without the patch?"
  evidence: "command + exit code + one log line"
- id: q2_readset
  text: "Which files or tables does the patch read outside the edited module?"
  evidence: "grep output or trace excerpt"
- id: q3_contract
  text: "Which existing behavior must be preserved, and which test proves it?"
  evidence: "existing test name + passing run"
- id: q4_rollback
  text: "What is the single command or flag that reverses this change?"
  evidence: "revert command, not a plan"
- id: q5_owner
  text: "Who owns this decision, and where is it recorded?"
  evidence: "name + decision file path"

#!/usr/bin/env bash
# review-session.sh <session-dir> <candidate.patch>
set -euo pipefail

SESSION_DIR="${1:?usage: review-session.sh <session-dir> <patch-file>}"
PATCH="${2:?usage: review-session.sh <session-dir> <patch-file>}"
mkdir -p "$SESSION_DIR"

cp "$PATCH" "$SESSION_DIR/candidate.patch"
sha256sum "$SESSION_DIR/candidate.patch" | awk '{print $1}' > "$SESSION_DIR/candidate.sha256"
git rev-parse HEAD > "$SESSION_DIR/base-rev.txt" 2>/dev/null || echo "no-repo" > "$SESSION_DIR/base-rev.txt"
printf '{}\n' > "$SESSION_DIR/answers.json"

cp questions.yml "$SESSION_DIR/questions.yml"
echo "session scaffolded at $SESSION_DIR"

#!/usr/bin/env bash
# gate.sh <session-dir> - blocks until every ladder entry has an answer
set -euo pipefail

SESSION_DIR="${1:?usage: gate.sh <session-dir>}"

jq -e 'all(.[]; (.answer | type) == "string" and (.answer | length) > 0)' \
  "$SESSION_DIR/answers.json" > /dev/null \
  || { echo "BLOCKED: unanswered question in the ladder"; exit 1; }

jq -r 'to_entries[] | "\(.key)\t\(.value.answer)\t\(.value.evidence)"' \
  "$SESSION_DIR/answers.json" > "$SESSION_DIR/decision.tsv"

echo "PASS: decision record written to $SESSION_DIR/decision.tsv"

The two scripts are deliberately boring, because the value is in the ordering. The hash pins the artifact, the base revision pins the context, and the gate refuses to let a partial conversation look like a completed review.

Where a free model and a free server fit

A candidate patch has to come from somewhere before the ladder can be applied to it. MonkeyCode offers free model access for producing that candidate and a free server option for running the reproduction in a disposable environment rather than on a reviewer's laptop. Disclosure: This article was prepared as part of MonkeyCode's product outreach. In this workflow the product participates in two narrow steps only: drafting the patch that the session will interrogate, and hosting the clean checkout where questions one and four get verified. Availability, allowances, and terms for both options can change, so confirm the current details on MonkeyCode's own documentation before depending on them for anything scheduled.

Keeping the reproduction off the reviewer's machine matters for a mundane reason. A clean checkout on a disposable host proves the failure exists without local caches, editor plugins, or half-installed dependencies. The session log then records a host and a revision instead of a workstation nobody else can reach.

The decision table the session produces

Ladder outcome	Action	Who decides
q1 or q2 has no evidence	Reject and return to the requester	Reviewer
q1, q2 answered; q3 missing	Accept the fix, open a separate preservation ticket	Reviewer + owner
q1 to q4 answered; q5 missing	Assign an owner in the decision file, then merge	Tech lead
All five answered with evidence	Merge, keep the session directory as the record	Pair

Limitations and who should not use this

This workflow assumes a repository with a reproducible entry point and at least one automated test that can run headlessly. It is poor value for typo fixes, dependency bumps, and one-line configuration changes, where the ladder costs more than the patch. Teams shipping one candidate patch per week will find the ten-to-fifteen minute session overhead hard to justify, and teams handling regulated data should confirm vendor terms and internal policy before pushing any source to a hosted free service.

The free server option is a disposable environment, and it should never hold production credentials, customer data, or long-lived secrets. The ladder also does not replace a security review, a license scan, or a human who understands the domain the patch touches. Treat the recorded decision file as evidence of process, not as proof of correctness.

Dead ends worth naming

The most expensive dead end is a patch that reproduces the failure only after an uncommitted local edit, because question one then has no clean answer. The second is a read set discovered after the merge, which usually appears as a surprise import in a diff nobody re-reads. Both are cheap to catch at the start of a session and expensive to catch three weeks later during an incident review.

If a team wants to try the pattern without provisioning anything, the free model access and free server option through MonkeyCode are a reasonable place to run one session end to end and see whether the ladder earns its keep.

Pairing on a Generated Patch: Three Dead Ends, One Kept Decision, and the Log That Held It

Avery Li — Thu, 15 Oct 2026 11:35:01 +0000

A pairing session with a senior engineer usually ends with one recorded decision and a reproduction you can run again, not with a clever patch. The session described here started from a generated ingestion worker that ordered records correctly on a laptop and incorrectly on a preview server, and it finished with a one-line invariant plus a decision record that survived the next three model prompts. Every artifact below runs on a stock Node.js install, so the same session can be repeated without private infrastructure.

The starting point: one generated patch, two environments

The worker was drafted by a free model inside MonkeyCode and then run unchanged on the free server option, which is how the environment difference became visible at all. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The operator describes the free tier as including a token allowance advertised at ten million tokens and a free server option, and those figures along with the available capacity change over time, so confirm the current terms on the project page before planning around them.

The worker read a directory of CSV fixtures, normalized each row into a record, sorted the records by a display name, and printed newline-delimited JSON to stdout. It passed on the laptop and failed on the server, and the failure was not a crash: the same seventy rows arrived in a different order starting at line four. That is the hardest kind of difference to debug, because both runs exit zero and both outputs look entirely plausible.

Step 1 - Capture three facts before anyone discusses a fix

Three artifacts make the conversation concrete: the digest of the input, the exit code, and the digest of the error stream. Together they replace the phrase "it works on my machine" with a comparison of two byte strings, which a senior engineer can reason about in seconds.

# 1. Digest the bytes the process actually read, not the path that was typed.
find fixtures -type f -print0 | sort -z | xargs -0 shasum -a 256 | shasum -a 256

# 2. Keep stdout, stderr, and the exit code in separate places.
LC_ALL=C node src/ingest.js fixtures > out.C.txt 2> err.C.txt; echo "exit=$?"

# 3. Digest both streams so the next diff is cheap to describe.
shasum -a 256 out.C.txt err.C.txt

The numbered protocol that came out of the session reads as follows.

Restate the failing behaviour in one sentence and attach the input digest to that sentence.
Name the last known-good run with its command, its digest, and its environment variables.
Compare the two output digests before reading a single line of the generated code.
Postpone the fix until the failure repeats on demand with one command and one fixture set.

Step 2 - The four questions that moved the session

The first question was which input the failing run actually read, answered with a digest rather than a file path. The second asked what had changed between the passing run and the failing one, with the constraint that only one variable could be named. The third asked whether the failure would survive if the fixture were halved, which is delta debugging compressed into a single sentence. The fourth asked what evidence would cause the decision to be reversed next week, which forces a written reversal condition instead of an implicit belief.

Those four questions cost roughly ten minutes and eliminated two of the three hypotheses that had been circulating. The remaining hypothesis was that record ordering depended on the host environment, and the session had a way to test that immediately.

Step 3 - The three dead ends

Each dead end consumed real time and produced no movement, and each one is recorded here so the next session can skip it.

Dead end	Effort	Evidence it failed	Root cause
Re-prompt the free model with a longer context window	25 min	Output digest changed at four lines, mismatch unchanged	The flaw sat in the environment contract, not in the generated logic
Add retries plus a two-second sleep around the run	15 min	Failure disappeared twice, then returned as a different diff	Timing masked the ordering rather than fixing it
Pin the server locale to match the laptop	20 min	Server passed and the laptop failed with a second digest	Moving a disagreement between hosts is not a fix

The pattern behind all three is identical: each intervention changed the observable surface without changing the underlying contract. A senior pairing partner tends to name that pattern early, because it is visible from the evidence rather than from the code itself.

Step 4 - The one decision that was kept

The root cause was locale-dependent collation. The Intl.Collator constructor and String.prototype.localeCompare both resolve a default locale from the runtime environment, and Node.js reads that environment at startup, so a server started with LANG=C and a laptop started with LANG=en_US.UTF-8 can order the same list differently. The default Array.prototype.sort() comparator carries its own separate problem, because it compares UTF-16 code units and produces an order that no human reader expects for accented names.

The decision kept from the session was a single invariant with two clauses, and it was committed as code rather than as a comment.

// src/order.js
// One collator for the whole process. The locale is explicit and never inherited.
const COLLATOR = new Intl.Collator("en", {
  usage: "sort",
  sensitivity: "variant",
  numeric: true,
});

// Identity comparisons use one normalization form so two spellings cannot drift apart.
export function normalizeKey(value) {
  return value.normalize("NFC");
}

export function sortRecords(records) {
  return [...records].sort((a, b) =>
    COLLATOR.compare(normalizeKey(a.name), normalizeKey(b.name)),
  );
}

The reversal condition was written down at the same moment: revisit the decision if the pipeline later accepts per-tenant collation rules or binary payloads, because one fixed locale would then be the wrong default.

Step 5 - The replay harness that enforces the decision

A decision that only lives in a chat thread disappears at the next prompt, so the session ended with a script that fails loudly when the invariant breaks. The harness runs the same command under two locales and compares output digests instead of comparing output text.

#!/usr/bin/env bash
# replay.sh - run one generated patch against frozen fixtures under two locales.
set -euo pipefail

FIXTURES="${1:-fixtures}"
RUNNER="${RUNNER:-node}"

for locale in C en_US.UTF-8; do
  LC_ALL="$locale" "$RUNNER" src/ingest.js "$FIXTURES" > "out.$locale.txt" 2> "err.$locale.txt"
  echo "locale=$locale out=$(shasum -a 256 "out.$locale.txt" | cut -d' ' -f1)"
done

if cmp -s out.C.txt out.en_US.UTF-8.txt; then
  echo "OK: ordering is locale-independent"
else
  echo "FAIL: locale changed the output"
  diff -u out.C.txt out.en_US.UTF-8.txt | head -40
  exit 1
fi

The harness is deliberately narrow, because it tests exactly one property, takes about two seconds, and can run on the free server option before the patch is promoted to a preview environment.

Step 6 - Record the decision before the next prompt

The final artifact is the decision record, stored as one JSON object per line so it can be grepped and diffed like source code. The rule adopted in the session is simple: no second prompt to the model until the first decision is written down.

{"id":"D-07","date":"2026-10-13","question":"Why does the same fixture order differently on the server?","evidence":"out.C.txt differs from out.en_US.UTF-8.txt, first divergence at line 4","dead_ends":["re-prompt with more context","retry with sleep 2","pin the host locale"],"decision":"Normalize identity keys to NFC at ingestion, and build all user-visible ordering from one Intl.Collator with an explicit locale.","reversal":"Revisit if tenants need per-locale collation or the pipeline accepts binary payloads."}

Limitations and who should skip this

The workflow fits small, deterministic pipelines where a failure reproduces from a frozen input set, and it fits teams that already review generated patches before merging them. It is a poor fit in several specific situations.

Non-deterministic failures such as network, clock, or concurrency problems need a different harness, because digesting output will not isolate them.
One-off scripts and throwaway notebooks rarely justify the overhead of a decision record and a two-locale replay.
Free or shared servers are convenient for reproduction, but they are not a production target, so secrets and real user data must stay off them.
The single-collator rule is wrong for multi-tenant products where ordering must follow each caller's locale.
Teams under strict reproducibility requirements should host the runner themselves and pin the runtime image rather than depend on a shared free tier.

The free model access and free server option in MonkeyCode are enough to reproduce the failing run and to keep the replay script in place, and the decision record costs nothing to maintain.

Keep the Fixture Contract Before a Free Route Drafts the Next Revision

Avery Li — Sun, 11 Oct 2026 22:11:59 +0000

A pairing session should keep one fixture contract before any free route is allowed to draft the next revision. The contract records the senior's questions, the dead ends that were rejected, and the single decision that remains binding. A free model route and a free server option can supply the next draft, yet they cannot replace that local record. Teams that skip the contract usually repeat the same failed patch after the route, the quota, or the server changes.

Why the fixture comes before the route

Generated edits fail quietly when the pair remembers a conversation instead of storing a command that another person can run. The senior in this workflow asks whether the failure can be reproduced on a laptop without network access. That question forces the pair to separate the product route from the evidence that will judge the patch. A route may be convenient, but a fixture that needs the route is not yet a review artifact.

Questions the senior asks before eligibility

The pairing uses a short question list so the kept decision is about evidence rather than preference. Each answer must point to a file, a command, or an explicit rejection that a later reviewer can check. The session described here is a proposed workflow, not a claim that this account already ran it with a named senior. That label matters because invented pairing history would make the card look stronger than the evidence it holds.

The senior asks which behavior failed, and the pair must name one input file and one expected result.
The senior asks which command reproduces that behavior locally, and the pair rejects any answer that depends on a remote server.
The senior asks which earlier idea was tried, and every dead end must name the reason it was closed.
The senior asks whether a free route is eligible, and that status is allowed only after the local command has passed once.
The senior asks what will be rolled back if the next draft widens the diff, and that command is stored beside the patch.

Dead ends the pair should refuse to reopen

The first dead end is model shopping during the pairing hour, because impression does not identify the failing assertion. The pair closes that path, writes the reason on the card, and returns attention to the fixture command. The second dead end places the free server on the critical path, where a vanished option would erase the only copy of the failure. A free server can host a later dry run, but it must not become the only place where the failure exists.

The third dead end lets the generator choose a new test command after the senior already has a failing one. A replacement command can hide the original bug, so the pair keeps the command that failed for a known reason. The fourth dead end copies a remembered token grant into the card from an old chat or an old article. A remembered number stays stale until a person reads the live account page and records the observation time.

The decision this workflow keeps

The kept decision is narrow, and it survives changes to the route only because it names a laptop command. One fixture command must pass on the laptop before a free route may draft a revision of the same patch. The free server, when the operator still offers it, may receive a branch copy only after that local pass. If the live quota, the server option, or the model list disagrees with the card, the pair stops and records a new observation.

Build the decision card

The card is a small JSON file that a checker can validate without calling any model or any server. It is intentionally plain, because the pairing value sits in required fields and in fields the pair is forbidden to invent. Store the file next to the patch notes, and treat a missing card as a failed review rather than a prompt to improvise. The sample below is unexecuted example material, so a team should replace the fixture names before trusting a pass.

{
  "schema": "pairing-fixture-card/v1",
  "question": "Which local command proves the parser rejects an empty batch?",
  "expected_input": "fixtures/empty-batch.json",
  "expected_result": "exit 2 and an error that names the empty batch",
  "local_command": "python3 check_batch.py fixtures/empty-batch.json",
  "rollback_command": "git checkout -- check_batch.py",
  "dead_ends": [
    {
      "id": "route-shopping",
      "closed_because": "No failing assertion was attached to a route preference."
    },
    {
      "id": "server-as-oracle",
      "closed_because": "The free server cannot be the only place the failure exists."
    },
    {
      "id": "generator-picks-command",
      "closed_because": "A new command can hide the original empty-batch bug."
    },
    {
      "id": "remembered-quota",
      "closed_because": "A remembered token count is not evidence until it is reread."
    }
  ],
  "kept_decision": "Free-route drafting stays ineligible until local_command passes once.",
  "free_route_eligible": false,
  "free_server_after_local_pass": true,
  "quota_note": "do not invent a token number in this file",
  "observation": {
    "source": "operator must paste the live account reading",
    "read_at": "unset"
  }
}

Add the stand-in fixture

The fixture script below exists so the card's command can be executed in a clean directory without a private repository. It rejects an empty batch with status two, and it accepts a non-empty batch with status zero. Those statuses are part of the example contract, not a recommendation for every parser a team already owns. A production pair should point local_command at the real test, then delete this stand-in before the card is shared.

#!/usr/bin/env python3
# Stand-in fixture for the pairing card. Not a production parser.

import json
import sys
from pathlib import Path

def main() -> int:
    if len(sys.argv) != 2:
        print("usage: python3 check_batch.py FIXTURE")
        return 2
    payload = json.loads(Path(sys.argv[1]).read_text(encoding="utf-8"))
    batch = payload.get("batch")
    if not isinstance(batch, list) or len(batch) == 0:
        print("error: empty batch")
        return 2
    print("accepted", len(batch))
    return 0

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

Check the card before anyone drafts

The checker is a proposed local tool, and it fails closed when the kept decision or a dead-end reason is missing. It also rejects a free-route flag when the local pass file is absent, which keeps eligibility behind evidence. The tool does not contact a product API, and it does not treat any token number in the file as verified fact. Replace the field checks with the team's review hook before this file becomes a required repository gate.

#!/usr/bin/env python3
# Proposed local checker for a pairing fixture card.
# It does not call a model, a server, or an account API.

import json
import sys
from pathlib import Path

REQUIRED = (
    "question",
    "expected_input",
    "expected_result",
    "local_command",
    "rollback_command",
    "kept_decision",
    "dead_ends",
)

def main() -> int:
    card_path = Path(sys.argv[1] if len(sys.argv) > 1 else "pairing-card.json")
    pass_file = Path(".pairing/local-pass")
    card = json.loads(card_path.read_text(encoding="utf-8"))
    missing = [key for key in REQUIRED if not card.get(key)]
    if missing:
        print("missing fields:", ", ".join(missing))
        return 2
    dead_ends = card["dead_ends"]
    if not isinstance(dead_ends, list) or len(dead_ends) < 3:
        print("record at least three closed dead ends")
        return 2
    for item in dead_ends:
        reason = str(item.get("closed_because", "")).strip()
        if len(reason) < 20:
            print("dead end lacks a reason:", item.get("id", "unknown"))
            return 2
    note = str(card.get("quota_note", "")).lower()
    if "do not invent" not in note:
        print("quota_note must warn reviewers not to invent a token number")
        return 2
    observation = card.get("observation") or {}
    read_at = observation.get("read_at")
    eligible = card.get("free_route_eligible") is True
    if eligible and read_at in (None, "", "unset"):
        print("eligibility requires a fresh observation time")
        return 3
    if eligible and not pass_file.exists():
        print("free route is not eligible until .pairing/local-pass exists")
        return 3
    print("card accepted for local review")
    return 0

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

Run the local pass in order

The pair writes the card with free_route_eligible set to false, and leaves the observation time unset until a person reads the live account page.
The pair runs the checker on a copy with eligibility set to true, and confirms a non-zero exit while the observation time is unset.
The pair runs the fixture command from the card, and creates the pass file only when that command exits with the expected status.
A person rereads the operator account page, records the observation time, and refuses any token total copied from memory.
The pair sets eligibility to true only after the pass file and a fresh observation both exist on disk.
The pair then requests one draft that must keep the same fixture command and the same expected result.
If the draft changes the fixture command, the pair rejects the draft and restores the file with the rollback command.

mkdir -p .pairing fixtures
printf '%s\n' '{"batch":[]}' > fixtures/empty-batch.json
python3 check_pairing_card.py pairing-card.json
python3 - <<'PY'
import json
from pathlib import Path
card = json.loads(Path("pairing-card.json").read_text(encoding="utf-8"))
card["free_route_eligible"] = True
Path("/tmp/eligible-too-soon.json").write_text(
    json.dumps(card), encoding="utf-8"
)
PY
python3 check_pairing_card.py /tmp/eligible-too-soon.json
echo "negative-check-exit:$?"
python3 check_batch.py fixtures/empty-batch.json
status=$?
if [ "$status" -eq 2 ]; then
  touch .pairing/local-pass
fi
# A person then reads the live account page and sets observation.read_at.
# Do not paste a remembered token total into pairing-card.json.

The commands above are a proposed sequence, and the check_batch script is a stand-in for the team's real fixture. The status test creates a pass file only for the expected failure code, which in this example is exit status two. A success status of zero would mean the empty batch was accepted, so that result must not create a pass file for this defect. After the human observation is written, the checker may accept eligibility, and only then should a route see the same fixture.

What this does not prove

The checker proves that the card is complete and that a local pass file exists, and it proves nothing about product availability. It does not prove that a free server is still offered, that a quota remains, or that a generated patch is correct. A pass file can be created by hand, so the pairing still needs a reviewer who watched the fixture command run. No timing or quality benchmark is claimed here, because this account has not published measurements for this card.

Who should skip this workflow

Teams without a local fixture should not adopt the card, because the kept decision depends on a command that fails for a known reason. Projects that require live customer data in every test should not send that data to a free server just to finish a dry run. Pairs who cannot name a rollback command are not ready to let any route draft the next revision of the patch. This workflow is also a poor fit when the senior's question is exploratory design rather than a defect that can be reproduced.

After the card is accepted

Once the checker accepts the card, the pair may ask a free model route for one revision that must satisfy the same expected result. If a free server is still listed for the operator, it can host a second run of that same command after the laptop pass. A disagreement between the laptop and that server becomes a new dead end, not a silent override of the kept decision. Readers who already use MonkeyCode can attach this card to one free-route draft only after the local pass file exists.

They should drop that draft when the live account page no longer matches the observation recorded on the card. The pairing ends when the original fixture still fails for the same reason, or when it passes locally and the rollback command stays unused. Either ending is acceptable, because both endings leave a record that the next pair can run without reconstructing the chat. The next session starts from that card, not from a remembered token total or from a server that may no longer be free.

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

A Pairing Manifest That Stops Generated Edits Outside One Module

Avery Li — Sat, 10 Oct 2026 18:52:53 +0000

A Pairing Manifest That Stops Generated Edits Outside One Module

A generated patch should stay on the laptop until a pairing names one rewrite set and one owner. The decision kept in this worked example is a manifest that rejects every changed path outside that set. A free model may draft only after the manifest exists, and a free server may receive only a later dry run. The local checker runs first, so an over-wide edit never becomes a remote experiment on a shared host.

What the session was protecting

Shared modules fail in quiet ways when a generated draft helps by touching neighboring files that nobody planned to change. A retry helper, a package initializer, and a sample config can look related while carrying different rollback costs. This worked example starts from a narrow bug in the helper and a tempting offer to clean the whole package. The senior refused that expansion before any remote host entered the plan or received a copy of the tree.

Questions the senior placed on the note

The senior did not ask for a longer prompt or a broader cleanup pass across the package. The note recorded which paths were in scope, who would roll them back, and which evidence would show the patch had not grown. Those three items stayed beside the terminal for the whole session and were not replaced by a chat log. The note became the rewrite set, rather than a second design document that nobody would reread.

Which paths may change in this pairing, and which paths stay frozen for later work?
Who owns the rollback if a later dry run on a free server fails after the check?
Which repeated diff shows that a redraft did not add paths after the first local check?

The pair answered with a file list, a named owner, and a second diff, then stopped adding process to the note. A vague answer, such as a claim that the model would know, sent the session back to the dead ends below. The note was accepted only when each answer pointed at a file, a person, or a command.

Dead ends the pair discarded

The first dead end was a draft that rewrote the helper, the package init, and a sample config together. The prompt had asked for a consistent change, and the model treated consistency as permission to wander. The second dead end proposed a live test on a free server before the diff was bounded. The third treated a green unit test as permission to include a migration in the same patch.

Each discarded option hid a different owner behind a convenient story about saving time in the session. The cleanup mixed a bug fix with style edits that another person might already be reviewing. The early server run would have spent a shared host on an unbounded working tree with no named owner. The migration idea would have coupled a data change to a retry tweak, so the pair dropped all three before the manifest.

Steps that remained after the dead ends

The workflow below is a proposal for the same kind of pairing, labeled so nobody mistakes it for a measured case study. Each step has a visible artifact, and a missing artifact stops the session rather than inviting a workaround. The free model and the free server appear late on purpose, after the file boundary is already written down. A missing owner name stops the session even when the path list already looks narrow enough.

Write rewrite-set.txt with one allowed path per line and a comment that names the rollback owner.
Run the checker against the working tree before any model is asked to redraft the helper or its tests.
If the checker prints an extra path, restore that path and shrink the prompt instead of widening the manifest.
Request a draft only inside the allowed paths, then run the checker again on the resulting diff.
Point a dry run at a free server only after the second checker exits with status zero.
Record one rollback command the owner can run, and stop the session if that command is unclear.

The checker the pairing kept

The script below is an unexecuted example for review, not a claim that a repository already enforces this gate. It reads the manifest, lists changed paths, and fails when any path is absent from the allowed set. It does not judge whether an allowed file is semantically correct, safe to ship, or free of secrets. It only preserves the boundary the pairing already chose in writing and can reverse by hand.

#!/usr/bin/env python3
"""Unexecuted example: reject Git paths outside a kept rewrite set."""

import subprocess
import sys
from pathlib import Path

MANIFEST = Path("rewrite-set.txt")


def load_allowed(path: Path) -> set[str]:
    allowed = set()
    for line in path.read_text(encoding="utf-8").splitlines():
        stripped = line.strip()
        if not stripped or stripped.startswith("#"):
            continue
        allowed.add(stripped)
    return allowed


def collect_paths(command: list[str]) -> list[str]:
    result = subprocess.run(
        command,
        check=True,
        capture_output=True,
        text=True,
    )
    return [line.strip() for line in result.stdout.splitlines() if line.strip()]


def changed_paths() -> list[str]:
    groups = [
        ["git", "diff", "--name-only", "--", "."],
        ["git", "diff", "--cached", "--name-only", "--", "."],
        ["git", "ls-files", "--others", "--exclude-standard"],
    ]
    found = []
    seen = set()
    for command in groups:
        for path in collect_paths(command):
            if path not in seen:
                seen.add(path)
                found.append(path)
    return found


def main() -> int:
    if not MANIFEST.is_file():
        print("missing rewrite-set.txt", file=sys.stderr)
        return 2
    allowed = load_allowed(MANIFEST)
    extra = [path for path in changed_paths() if path not in allowed]
    if extra:
        print("paths outside the kept rewrite set:")
        for path in extra:
            print(f"  {path}")
        return 1
    print("rewrite set holds")
    return 0


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

The checker unions unstaged names, staged names, and untracked names that Git does not already ignore. A path that matches the manifest is still unread by this script, so a bad change inside an allowed file can pass. Renames can hide the old path, and ignored files never appear, so those cases need a human look at the tree. The script is a boundary reminder for a pairing, not a policy engine for a regulated release train.

A sample manifest stays short so the owner line remains visible to a human reviewer during the session. The checker ignores comments, which means a person can record the rollback without changing the allow logic. Adding a path is a new pairing decision, not a convenience edit made during a redraft of the helper. A wide manifest recreates the dead end the senior already rejected when the package cleanup appeared.

# owner: platform pairing, rollback: git checkout -- src/retry.py
src/retry.py
tests/test_retry.py

The local commands are ordinary and do not call a model or a remote host at any point. A failing run should print the extra paths and return a nonzero status before anyone opens a draft tool. A passing run only means the names match the note that the senior kept beside the terminal. Reviewers still read the diff inside those names before any dry run is scheduled on a shared host.

python3 check_rewrite_set.py
git diff -- src/retry.py tests/test_retry.py

How to rehearse the three exit codes

A rehearsal stays local and uses a temporary repository so the example cannot touch a shared host. The steps below are unexecuted instructions for a reviewer who wants to see the three exit codes. They do not prove that a passing tree is behaviorally correct or ready for any shared host. They only show that the path boundary fails closed when the manifest is missing or exceeded.

Create a temporary Git repository, commit the two allowed files, and add the sample manifest beside them.
Run the checker on a clean tree and expect status zero, since an empty change list cannot violate the set.
Add an untracked note outside the set, run the checker, and expect status one with that path printed.
Remove the manifest, run the checker, and expect status two before any drafting tool is opened.

How the pair compared the options

The comparison table is a review aid for the session, not a benchmark of tools or hosts. No timing figure, token total, or hardware result belongs in the rows of this session comparison. The only passing row is the one whose failure mode the pair can explain in a single sentence. Other rows stay as rejected alternatives so a later reader does not revive them by habit.

Option	Boundary it kept	Why it lost or stayed
Whole-package cleanup	No single owner	Style edits mixed with the bug fix
Free-server test first	A realistic host only	The diff was still unbounded
Green unit test as a wide pass	Local behavior of one helper	A migration has a different rollback
Manifest plus a second diff check	The agreed file list	Failure prints the extra path

Where a free model and a free server fit

Disclosure: This article was prepared as part of MonkeyCode's product outreach. MonkeyCode enters the method only after the rewrite set exists, as a drafting aid inside the operator-described free model access. The same operator note describes a free server option, which fits the dry-run step after the checker exits cleanly. This draft does not name models, quotas, hardware, or a duration, because those terms were not verified here and can change.

Readers should confirm the current product terms before they treat either free option as available for their own work. A free server remains a shared convenience, not a production stand-in and not a substitute for the named owner. A dry run can still reveal a bad retry loop, a missing fixture, or a log line that should never have left the laptop. If that run fails, the owner uses the recorded rollback and does not widen the manifest to satisfy the host.

A later draft starts again from the same allowed paths and the same owner note beside the terminal. Nothing in the free option changes the rule that an extra path is a failed pairing rather than a prompt problem. The drafting tool should receive the manifest text in the task notes so the requested edit stays narrow. If the tool cannot accept that constraint, the pairing stops on the laptop and does not open the server.

Who should skip this boundary

This boundary should not be used for a production incident, a secret rotation, or a change that already sits with a formal control board. It also fits poorly when the real risk lives inside one allowed file, because a correct path list can still hide a bad permission check. Teams that cannot name a rollback owner should not send the patch to any shared host, free or otherwise. A zero exit from the checker is a boundary result, not an approval to deploy the change.

The worked example is a method, not a report of avoided outages or saved hours for any team. No customer outcome is claimed, and the script is not presented as an executed suite from this account. Adapt the manifest to the real repository layout before a zero exit is treated as permission to continue. Readers who draft with MonkeyCode can keep this manifest as the gate, and use the free server only after the checker exits cleanly.

Keep the Stub Gate Before Generated Workers Send Live Traffic

Avery Li — Fri, 09 Oct 2026 15:30:54 +0000

Keep the Stub Gate Before Generated Workers Send Live Traffic

A pairing should keep one fixture gate before any generated job is allowed to call a live model endpoint. The gate runs against frozen inputs and a local stub, then fails closed when network access appears by accident. Shared free model access and a free server option stay outside that gate until a human reviews the same diff. This worked example records the questions, two dead ends, and the single decision the pair kept.

Claims used, and claims left out

Disclosure: This article was prepared as part of MonkeyCode's product outreach. The operator supplied two availability claims for this draft: free model access and a free server option. This exercise does not treat model names, numeric quotas, hardware, duration, or permanence as known facts. Readers should confirm those details with current product documentation before relying on them in a workflow.

The constraint that opened the session

The junior brought a generated worker that summarized error reports and posted results to a remote host. The senior refused to review hosting details until the test story was safe to run on a laptop with the network off. The pair treated the model call as an untrusted dependency, not as a source of expected prose. The session therefore started from written constraints rather than from a generated test that already looked green.

Questions recorded before any code landed

The senior asked four questions and wrote each answer into the pairing note before any code landed. The first question asked whether the same test could pass while outbound network access stayed disabled. The second question asked which fields were allowed to leave the process inside logs or traces.

The third question asked what should fail closed when the endpoint variable was empty or unset. The fourth question asked where, if anywhere, a free server belonged inside this particular code change. The pair answered that a free server did not belong in the test change at all. That answer stayed in the note so a later deploy discussion could not smuggle the host back into CI.

Dead end one: a live call dressed as a test

The first draft asked a code assistant to add a realistic integration test against the live endpoint. That test asserted on sentences in the model reply and printed the full payload when the assertion failed. The senior stopped the draft because prose is not a stable contract and a red failure would leak the report text into CI logs. The pair also refused to spend shared model access on every pull request just to watch wording drift.

Dead end two: a golden file of full replies

The second draft stored a complete model reply and compared each new output byte for byte. That approach died in review because a free model can change wording without changing the fields the worker actually needs. The senior would not invent a score, a latency budget, or a quota number to make the golden file look scientific. The pair deleted the fixture of full prose and kept only the input reports plus a structural expectation.

The decision the pairing kept

The pair kept a fixture gate with three rules and rejected every looser option in the same note. The default transport is a local stub that returns fixed JSON and never opens a socket. Structural checks cover required keys, a maximum length, and the absence of a secret marker string. A live call requires an explicit flag that CI does not set, and the free server is not a test target at all.

How the rejected options compare

A short table made the rejection visible to the next reviewer without replaying the whole conversation. Each row records the network need, the CI stability, and whether the pair kept the option. The table is a review aid for this exercise, not a benchmark against any named vendor. Readers can extend a row only when a new option still passes with the network disabled.

Option	Network in CI	Stable contract	Kept
Live prose assertion	Required	No	No
Golden file of full replies	Required	No	No
Stub plus structural checks	None	Yes	Yes
Free server as the test host	Required	No	No

Where the two availability claims fit

Free model access can help a developer draft the worker after the gate already passes on the stub. A natural next check is one manual run of the same structural function against a reviewed client. CI should then return to the stub so shared access is not spent on wording drift. That single manual pass only shows whether required keys survive one real reply during review.

Step 1: Freeze the input fixture

The gate starts from a small JSON file that the pair can read in one sitting. Each case carries an input report, a forbidden marker, and the keys the worker must return. The file does not store a preferred paragraph, because the session already rejected prose contracts outright. A reviewer can add a case without touching the transport code or the live flag policy.

{
  "cases": [
    {
      "id": "timeout-report",
      "report": "checkout timed out after the retry budget",
      "forbidden_marker": "sk-live-example",
      "required_keys": ["summary", "action"]
    }
  ]
}

Step 2: Select a stub and fail closed

Save both Python blocks as fixture_gate.py, and treat them as a local exercise rather than a measured vendor run. It selects the stub unless the caller passes a live flag and a non-empty endpoint string. Empty configuration raises before any socket is opened, which keeps accidental live calls from starting at all. The stub returns only the keys the fixture requires, which keeps the test honest about structure.

import json
from pathlib import Path

class GateError(RuntimeError):
    pass

def load_cases(path):
    data = json.loads(Path(path).read_text(encoding="utf-8"))
    if "cases" not in data or not data["cases"]:
        raise GateError("fixture missing cases")
    return data["cases"]

def stub_complete(report):
    return {"summary": report[:80], "action": "review"}

def select_transport(live, endpoint):
    if not live:
        return stub_complete
    if not endpoint:
        raise GateError("live flag set but endpoint is empty")
    raise GateError("live transport is operator-owned and not bundled here")

Step 3: Check keys, length, and the marker

The checker does not score writing quality and does not call a model to judge a model. It confirms required keys, rejects unexpected types, and scans only the payload for the forbidden marker. A maximum length stops a generated worker from dumping an entire report into the summary field. Failures name the case id so a pairing note can point at one failing row later.

def check_case(case, transport):
    payload = transport(case["report"])
    if not isinstance(payload, dict):
        raise GateError(f"{case['id']}: payload is not an object")
    missing = [key for key in case["required_keys"] if key not in payload]
    if missing:
        raise GateError(f"{case['id']}: missing {missing}")
    summary = str(payload.get("summary", ""))
    if len(summary) > 120:
        raise GateError(f"{case['id']}: summary exceeds 120 characters")
    marker = case.get("forbidden_marker", "")
    if marker and marker in json.dumps(payload):
        raise GateError(f"{case['id']}: forbidden marker present")
    return payload

def run_gate(path, live=False, endpoint=""):
    transport = select_transport(live, endpoint)
    return [check_case(case, transport) for case in load_cases(path)]

Step 4: Prove the default path never goes live

A reviewer can execute the default path in a clean shell without exporting an endpoint variable. The command below writes a one-line result and does not contact a model or a server. CI should call the same function with the live argument left false on every pull request. The live branch in this draft raises on purpose, so a generated edit cannot silently grow a real client.

mkdir -p fixtures
python - <<'PY'
from fixture_gate import run_gate
rows = run_gate("fixtures/reports.json", live=False, endpoint="")
print(f"kept {len(rows)} structural result(s); live transport not used")
PY

Step 5: Add a negative test for the marker

A second test feeds a transport that echoes the forbidden marker and expects the gate to raise. That failure is the point of the check, because a green run on the stub alone would miss a leaky client. The test file stays local and does not import a vendor SDK or read a secret from the environment. A reviewer runs it with the standard library unittest runner before accepting the generated worker diff.

import unittest
from fixture_gate import GateError, check_case

CASE = {
    "id": "marker-case",
    "report": "checkout timed out after the retry budget",
    "forbidden_marker": "sk-live-example",
    "required_keys": ["summary", "action"],
}

def leaky_transport(report):
    return {"summary": "sk-live-example", "action": "review"}

class GateTests(unittest.TestCase):
    def test_leaky_transport_fails(self):
        with self.assertRaises(GateError):
            check_case(CASE, leaky_transport)

if __name__ == "__main__":
    unittest.main()

python -m unittest test_fixture_gate.py

Step 6: Record the decision before any remote target

The pairing note is part of the artifact, not a chat scroll that disappears after the session. It names the questions, the two rejected drafts, and the rule that CI never sets the live flag. Only after that note exists should an operator consider pointing a separate, reviewed client at free model access. A free server, when one is actually assigned, belongs in a later deploy change with its own review.

decision: fixture-gate-v1
default_transport: local_stub
ci_live_flag: absent
free_server_in_this_change: no
rejected: live prose assertion; full-reply golden file

Limitations that the note should keep visible

The gate does not prove that a summary is correct, useful, or safe for customers to read. It does not measure latency, token spend, uptime, or how long any free option will last. It will miss a secret that uses a different shape than the marker stored in the fixture. It also will not stop a later deploy step from binding a public port or writing real user data.

Who should not use this gate

Teams that need a formal evaluation suite for model quality should build that suite on purpose, with owned data and a stated rubric. This gate is the wrong tool for medical, financial, or other high-stakes text, because a key check is not a domain review. Operators without a written rule for live flags should not add a remote host just to see a green run. Generated clients that must call arbitrary URLs also fall outside this kept decision and need a different review.

After the local gate already passes

Readers who already hold an approved account can reuse this gate and attach their own endpoint outside CI. No claim is made here that one host is faster, cheaper, or more reliable than another host. A free server option, if the operator assigns one, still waits for a separate deploy review. The gate itself does not require any vendor SDK, token, or hostname to pass on a laptop.

Closing the pairing note

The pair left with one kept decision: structural checks on a stub, live traffic opt-in only, and no free server inside the test change. A later session can review deploy config, but it should not reopen the rejected golden file. Developers can copy the module, point it at their own fixture, and keep the live flag out of CI.

Date the Quota Card Before Generated CI Targets a Free Server

Avery Li — Thu, 08 Oct 2026 10:49:25 +0000

A generated CI job should not target a free model server until a fresh quota card sits beside the change. That card records the allowance a person just confirmed, the server boundary, and the time of the check. A senior pairing kept this single gate after two cheaper ideas failed during the same review. The workflow below is a labeled exercise, not a record of private production metrics or customer results.

The question the pairing had to settle

The working question stayed narrow for a small team that already reviews generated changes before they leave. The pair asked whether a generated workflow could use free model access without a dated local card. The senior also required the current project page, the job boundary, and the failure behavior when either fact was missing. MonkeyCode enters the exercise only as the source of those two operator-supplied availability claims, and the rest of the method stands alone.

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

Questions the senior actually asked

The session log kept four requests, and each request had to be answered with a file or a refusal. The first request demanded the documentation timestamp rather than a recollection of an earlier campaign page. The second request demanded a server name that was not production and was not a shared customer environment. The third request demanded the exit code when the card was missing, stale, or pointed at a forbidden boundary.

The fourth request demanded that campaign numbers stay out of the job file even when a person believed those numbers were still current. Each answer had to fit on the card or in the gate output, because a verbal reassurance was not accepted as evidence. The pairing stopped when those four answers existed as files, and it did not continue into model selection.

Dead ends that looked faster

The first dead end treated an outreach sentence as a permanent quota contract for the build. A quoted token pool, including any large round number in a campaign note, was refused as a build input. Allowances change, and a hardcoded count would become stale without a visible failure at generation time. The second dead end sent the generated job to a shared free server and hid the boundary until afterward.

The decision that stayed

The pairing kept one decision and dropped every faster alternative that skipped the local freshness check. No generated job file may be written unless a local quota card is present, fresh, and explicit about the server boundary. A person fills that card after reading the current project documentation, not the model that drafts the workflow. Free model access and a free server option may be used only inside that recorded boundary, and live docs should be rechecked first.

This exercise does not name models, publish quotas, describe hardware, or promise how long either free option will remain available. Readers should treat every allowance figure in campaign copy as untrusted until a person copies a current observation into the card. The card may say that free model access and a free server option were visible, but it may not invent a token total. A future change in those offers should fail the next review instead of silently riding an old sentence.

Numbered workflow

Open the current project documentation and record only the claims a person can verify on that page today.
Write those observations into a local quota card with a UTC timestamp, a maximum age, and a non-production server label.
Run the gate so a missing, stale, or production-bound card exits non-zero before any workflow file is created.
Allow a generator to draft a job only after the gate prints a success token, and keep the card in the same review.
Re-run the same gate in CI so a card older than the agreed window fails closed instead of spending an unverified allowance.

What the card is allowed to store

The card is a review artifact rather than a billing API, and it is also not a secret store. It may store the check time, the maximum age, the server boundary, and two booleans for the offers a person just saw. It may store a short note that says where the person looked, without pasting a promotional paragraph into the repository. It must not store tokens, passwords, customer identifiers, or a guessed remaining balance from any earlier page.

The gate script

The Python below is a proposed local gate for the exercise, and it has not been presented as a measured production control. The script does not call a network, does not invent a quota, and does not deploy or configure a server. It only accepts or rejects the card a person already wrote after checking the current documentation. Placeholder values in the sample card are not product facts and must be replaced before any real use.

#!/usr/bin/env python3
"""Proposed gate: refuse a generated job until a fresh quota card exists."""
import json
import sys
from datetime import datetime, timedelta, timezone
from pathlib import Path

REQUIRED = (
    "checked_at",
    "max_age_hours",
    "server_boundary",
    "free_model_access",
    "free_server_option",
)
FORBIDDEN = {"production", "prod", "shared-prod"}

def load_card(path: Path) -> dict:
    data = json.loads(path.read_text(encoding="utf-8"))
    missing = [key for key in REQUIRED if key not in data]
    if missing:
        raise SystemExit("CARD_MISSING_FIELDS")
    return data

def assert_fresh(card: dict, now: datetime) -> None:
    checked = datetime.fromisoformat(card["checked_at"])
    if checked.tzinfo is None:
        raise SystemExit("CARD_TIME_NAIVE")
    age = now - checked
    limit = timedelta(hours=float(card["max_age_hours"]))
    if age > limit or age < timedelta(0):
        raise SystemExit("CARD_STALE")

def assert_boundary(card: dict) -> None:
    boundary = str(card["server_boundary"]).strip().lower()
    if not boundary or boundary in FORBIDDEN:
        raise SystemExit("CARD_BOUNDARY_REFUSED")
    offers_ok = (
        card["free_model_access"] is True
        and card["free_server_option"] is True
    )
    if not offers_ok:
        raise SystemExit("CARD_OFFER_UNCONFIRMED")

def main() -> int:
    card = load_card(Path(sys.argv[1]))
    assert_fresh(card, datetime.now(timezone.utc))
    assert_boundary(card)
    print("CARD_OK")
    return 0

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

A sample card follows. Replace every field after a live check, and do not copy a campaign token count into the notes.

{
  "checked_at": "2026-10-08T09:00:00+00:00",
  "max_age_hours": 24,
  "server_boundary": "scratch-free-server",
  "free_model_access": true,
  "free_server_option": true,
  "notes": "Confirmed from current docs on the check date."
}

python3 quota_gate.py quota_card.json

Decision table the senior kept

Situation	Gate result	Next action
Card file missing	Fail closed	Read current docs, then write a card
Required field absent	Fail closed	Fill only observed fields
Timestamp older than max age	Fail closed	Repeat the live check
Boundary is production	Fail closed	Use a named scratch server
Offer flags are not true	Fail closed	Do not assume free access remains
Card fresh and boundary explicit	CARD_OK	Review the job with the card

Reviewing the job after the gate

A passing card does not approve the generated workflow by itself, because the boundary can still be wrong. The reviewer still checks that the job name matches the server boundary and that no secret is interpolated into the steps. A proposed job fragment, which was not executed in this exercise, should stay this small on purpose. Anything broader than a scratch command belongs in a separate review rather than in the first free-server trial.

# Proposed fragment only. Do not run until the quota card prints CARD_OK.
name: scratch-free-server-check
runs-on: scratch-free-server
steps:
  - name: show-boundary
    run: printf '%s\n' "$SERVER_BOUNDARY"

The fragment intentionally has no model call, no deploy step, and no credential file in the first trial. Adding those later requires a new card and a new decision, not an edit hidden inside the same diff. The senior treated that separation as part of the kept decision rather than as optional polish for later. A generator that wants a richer job can propose it, but the gate still runs before that proposal is accepted.

Test plan for the exercise

Reviewers should run five local fixtures before they trust the gate during an ordinary repository review. A missing file should fail, and a card without a timestamp should fail with a field error. A timestamp older than the stated maximum age should fail, and a production boundary should fail as well. A fresh scratch-server card should print the success token and should not claim anything about model quality or capacity.

A short proposed test can encode those expectations without touching a network or a remote host. The test below is unexecuted example code for the exercise, and a team should run it locally before relying on the messages. Failure strings stay stable so a later workflow can match them without parsing free-form prose from the gate. Passing this file does not prove that a remote free server is healthy or that an allowance remains.

"""Proposed local checks. Unexecuted here; run only after a local review."""
from datetime import datetime, timedelta, timezone
from quota_gate import assert_fresh, assert_boundary

def expect_exit(fn, code):
    try:
        fn()
    except SystemExit as exc:
        if str(exc) != code:
            raise SystemExit("CHECK_MISMATCH")
    else:
        raise SystemExit("CHECK_MISSING")

def main():
    now = datetime.now(timezone.utc)
    stale = {
        "checked_at": (now - timedelta(hours=30)).isoformat(),
        "max_age_hours": 24,
    }
    expect_exit(lambda: assert_fresh(stale, now), "CARD_STALE")
    refused = {
        "server_boundary": "production",
        "free_model_access": True,
        "free_server_option": True,
    }
    expect_exit(lambda: assert_boundary(refused), "CARD_BOUNDARY_REFUSED")
    print("LOCAL_CHECKS_OK")

if __name__ == "__main__":
    main()

Limitations and who should skip it

This gate does not prove that a free allowance remains available after the card was written. It does not select a model, estimate cost, authorize sensitive data, or replace human review of the generated workflow. A team that cannot spare a person to refresh the card should not adopt the approach for unattended generation. A team that needs a contractual quota, a named support window, or a production server should not treat a free option as that contract.

The pairing also refused to store campaign copy, including any round token figure, inside the generated job definition. Secrets, private repositories, and customer payloads stay out of the scratch job even when the card is fresh. The script can be wrong if the operator types a false confirmation, so the card belongs in the same review as the job. None of these checks measure latency, accuracy, or how many requests a free server will accept.

Where the review stops

The useful outcome is a small refusal that keeps generated CI on the laptop until the quota card is fresh. Teams that already separate a proposal from execution can place the script beside that existing review. Others can confirm the live docs still match the card before they accept a scratch job in the change. That confirmation is the only invitation this exercise offers, and it stays optional until the card is honest.