Field Notes: I Made the Suggestion Fail Before the Second Host Saw It

I started the weekend with a boring question about a suggested patch, not with a product demo. If a model drafts a patch and a second machine can run it for free, why would I still refuse to land the edit? I have watched the phrase "it ran somewhere" become the whole review, and that habit is how quiet bugs survive. These notes cover one constructed example, the checks I would repeat, and the places where I would stop.

What I was actually trying to protect

The toy bug is small enough to read in one sitting, which is why I trust it as a weekend drill. A script should load setting.txt, print ready, and exit zero only when that file contains the expected word. A missing file should be a visible failure, not an empty success that looks green in a scrolling log. Would you notice that difference if the only artifact you kept was a calm chat transcript?

I froze the script bytes, the intended command, and a forced-miss switch before I asked any model for help. I did not freeze a story about which host was the real one, because stories do not travel with the files. If the second host cannot see the same bytes, then the comparison is just two anecdotes wearing matching titles. That freeze is the whole point of the first evening, and I would rather be slow than merely persuasive.

Where the free options enter the drill

Disclosure: This article was prepared as part of MonkeyCode's product outreach. In this workflow I would use the free model access only to draft a candidate patch for the constructed drill. I would treat the free server option as a second place to run the same receipt, not as a promise about capacity or uptime. I am not naming a model, a quota, or a machine size, because those details were not something I could verify from here.

Hour 0 to hour 6: the suggestion looked kinder than the bug

I wrote the first draft myself so it would imitate the kind patch a model often offers on this bug. That draft returns an empty string for a missing file and then exits zero, which looks polite and is wrong. Have you ever accepted a shorter diff because the explanation sounded calm and the tests you already trusted stayed green? I have done that before, and the calm tone was not evidence that the failure was still visible to the next host.

I dropped that draft into a scratch directory and refused to repair it by hand before the receipt ran. The point of the drill is to see whether a receipt can reject a kind lie without me narrating the rejection. If I already know the patch is bad, I have not built a check that I can hand to another host unchanged. A check I cannot hand over is just a memory, and memories are how weekend notes turn into folklore.

The receipt I would run on both hosts

The harness below is a constructed example you can run locally, and it is not a benchmark or a product probe. It hashes the script, records a small fingerprint, runs the pass case, and then runs the forced miss. It returns 2 when the forced miss exits zero, because a silent miss is the failure I actually care about. It returns 1 when the pass case itself fails, so a missing fixture is not mistaken for a bad suggestion.

#!/usr/bin/env python3
'''Constructed receipt harness. Not a benchmark and not a product probe.'''

import hashlib
import json
import os
import platform
import subprocess
import sys
from pathlib import Path

def sha256_bytes(data: bytes) -> str:
    return hashlib.sha256(data).hexdigest()

def normalize(text: str) -> bytes:
    return text.replace('\r\n', '\n').encode()

def fingerprint() -> dict:
    return {
        'python': sys.version.split()[0],
        'platform': platform.platform(),
        'cwd': str(Path.cwd()),
    }

def run_case(script: Path, force_miss: bool) -> dict:
    env = os.environ.copy()
    env['FORCE_MISS'] = '1' if force_miss else '0'
    proc = subprocess.run(
        [sys.executable, str(script)],
        capture_output=True,
        text=True,
        env=env,
        timeout=30,
        check=False,
    )
    stdout = normalize(proc.stdout)
    stderr = normalize(proc.stderr)
    return {
        'returncode': proc.returncode,
        'stdout_sha256': sha256_bytes(stdout),
        'stderr_sha256': sha256_bytes(stderr),
    }

def main() -> int:
    script = Path(sys.argv[1])
    receipt = {
        'script_sha256': sha256_bytes(script.read_bytes()),
        'fingerprint': fingerprint(),
        'pass_case': run_case(script, False),
        'forced_miss': run_case(script, True),
    }
    print(json.dumps(receipt, indent=2, sort_keys=True))
    ready = sha256_bytes(b'ready\n')
    pass_ok = (
        receipt['pass_case']['returncode'] == 0
        and receipt['pass_case']['stdout_sha256'] == ready
    )
    if not pass_ok:
        return 1
    if receipt['forced_miss']['returncode'] == 0:
        return 2
    return 0

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

The sample under test is constructed too, and the bad branch is the one a helpful suggestion tends to invent. Empty success feels like error handling, which is why I want the receipt to punish that feeling on purpose. Read the sample as a proposal of the wrong patch, not as a log from a customer system or a live outage. If you change the exits before you run it, you are testing your edit, not the failure this note describes.

import os
import sys

def load_setting(path: str) -> str:
    if os.environ.get('FORCE_MISS') == '1':
        path = path + '.missing'
    try:
        with open(path, encoding='utf-8') as handle:
            return handle.read().strip()
    except FileNotFoundError:
        return ''

if __name__ == '__main__':
    value = load_setting('setting.txt')
    if value != 'ready':
        sys.exit(0)
    print('ready')

Create a fixture file named setting.txt that contains the single word ready, then run the harness against the sample. On this bad sample, I expect the pass case to print ready and the forced miss to exit zero inside the child. The harness should then exit 2, which is my name for a silent miss that pretended to succeed. If your copy exits 0, you are not running the bad sample, or the forced-miss switch never reached the process.

printf '%s\n' ready > setting.txt
python3 receipt.py sample_setting.py > host-a.json
echo receipt_exit=$?

I normalize newlines before hashing so a Windows host does not fail the drill for a carriage return. The pass case is accepted only when the exit is zero and the normalized stdout is exactly the word ready. That extra check is why a missing fixture returns 1, even if a kind patch exits zero after swallowing the error. Would you still trust a green child exit if the parent receipt had not asked what the child printed?

What I would compare after the second host

After the same command on the second host, I would diff the two JSON files instead of diffing my memory of the chat. The comparison script below is a constructed helper, and it only prints whether the script hashes and miss codes agree. It does not decide that the patch is correct, and it should not be wrapped in a deploy script that auto-merges. If either file is missing, the honest result is that you do not have a comparison yet.

import json
from pathlib import Path

def load(name: str) -> dict:
    return json.loads(Path(name).read_text(encoding='utf-8'))

def main() -> int:
    left = load('host-a.json')
    right = load('host-b.json')
    same_script = left['script_sha256'] == right['script_sha256']
    print('script_match', same_script)
    print('miss_a', left['forced_miss']['returncode'])
    print('miss_b', right['forced_miss']['returncode'])
    if not same_script:
        return 3
    if left['forced_miss']['returncode'] == 0 or right['forced_miss']['returncode'] == 0:
        return 2
    return 0

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

Hour 6 to hour 24: what broke when the bundle moved

The missing fixture

The first break was a missing fixture file, not a clever failure inside the model suggestion itself. I copied the script into a clean directory and forgot setting.txt, so the pass case failed for a reason unrelated to the patch. A red receipt felt like progress until I noticed that I had quietly changed the inputs between the two runs. Would a green run on a free server have meant the patch was good, or only that the server held a different tree?

The story I almost recorded

The second break was environmental storytelling that made two different machines sound like one careful, finished experiment. I almost recorded the interpreter path as the whole identity of the run, then remembered that a path is not a tree. Two hosts can share a version string and still disagree on the working directory, the locale, or the fixture file. The fingerprint in this harness is deliberately small, and that smallness is a limitation rather than a complete environment lock.

The availability I refused to cite

The third break was the temptation to treat free access as a stable laboratory I could cite tomorrow. Free model access can revise an answer between sessions, and a free server option can be queued, reset, or unavailable. I did not measure any of that behavior, and I will not invent a duration, a quota, or a success rate. If I cannot regenerate the receipt today, I do not cite yesterday's chat window as proof that the patch held.

Hour 24 to hour 48: the decision table I would repeat

I stopped asking whether the assistant sounded sure, and I started asking which row of the table I was actually in. A matching pair of receipts is not correctness, and I want that sentence sitting above the table so I do not forget it. It only says both hosts obeyed this narrow contract on this constructed input, with the same script bytes. A real bug can hide beside a file named setting.txt and still pass a drill this small without complaint.

Receipt on host A	Receipt on host B	What I do
Exit 2, and the script hash is recorded	Not run yet	Keep the patch off the second host until the miss is visible
Exit 0, and the forced miss is nonzero	Exit 0, same script hash, forced miss nonzero	Read the diff, and treat it only as a candidate
Exit 0	Exit 0, but the script hashes differ	Discard the comparison, because you ran two programs
Exit 1	Anything	Fix the pass-case inputs before you judge the suggestion
Cannot rerun the receipt today	An old chat is still open	Do not promote that chat into a deploy note

A row I would not celebrate

Look at the second row before you celebrate, because a matched exit of zero still needs a human to read the diff. The third row is the one I expect to hit when a clean directory drops a fixture and the hashes quietly diverge. The last row is the one I would keep underlined, since an old chat is not a rerun you can defend later. Would you merge from a row you cannot regenerate, just because the explanation still sounds familiar tonight?

What I would repeat

I would repeat four steps, in this order, whenever a suggestion wants time on a second machine. The order matters more than the tool, because a second host cannot rescue a check you never froze. Would you still call it a comparison if the second run used a rewritten file and a calmer prompt? I would not, which is why the hash sits in the receipt before any story about the server.

1. Freeze the script bytes and the fixture files before any model is allowed to rewrite a single line.
2. Require a forced-miss path that must exit nonzero, and fail the receipt when that path looks successful.
3. Run the receipt in a clean local directory, then use the second host only if that local exit is already zero.
4. Compare script hashes before you compare stories, and throw the pair out when those hashes diverge.

I would not repeat the part where I let a calm explanation substitute for the forced miss. I also would not paste secrets, tokens, or private paths into the prompt just because the model access is free. Free does not mean the prompt is unobserved, and it does not mean the prompt is a safe notebook for production data. If the suggestion needs a secret to run, the suggestion does not belong in this drill at all.

Who should skip this approach

Skip this drill if your change cannot be expressed as a local process with a fixture file you can commit. A receipt like this will not validate a user interface, a payment flow, or a migration that needs production data. Skip it when policy forbids sending repository context to an external assistant, even when that tier is described as free. Skip it if you need an audit trail stronger than a JSON file you generated yourself on a laptop you control.

• Do not treat a free server option as reserved capacity, a permanent disk, or a private network.
• Do not put secrets, tokens, customer rows, or unreleased patches into the prompt just to complete the drill.
• Do not auto-merge because two receipts matched, since the contract here is one file and one word.

Limits I am willing to say out loud

The harness uses a thirty-second timeout and a single environment switch, so it will miss slow flakes and clock-dependent bugs. Hashing stdout will change when a log line includes a timestamp, a temporary path, or a process id. I would strip those volatile lines before hashing if this ever left the scratch directory and touched a real job. I did not benchmark MonkeyCode against any other assistant, and I am not claiming the free server matches a paid host.

I am also not claiming that a free server option remains available, keeps your files, or matches yesterday's queue. If that availability note changes, the receipt workflow still stands, but the second host may need to be a machine you control. The exit codes above are predictions from the listed source, not a lab report from a free server run. The JSON file proves agreement on a contract you wrote, which is weaker than a review and stronger than a vibe.

If you already have those two free options, run this receipt once on a scratch bug before a suggested edit nears a shared branch. The useful outcome is a JSON file you can diff tomorrow, not a stronger adjective sitting in the chat window. I would keep the bad sample in the repo until the forced miss fails on purpose, and only then ask for a kinder patch. Does that feel slow for a weekend note, or does it feel like the only speed that still leaves you a receipt?