DEV Community: Taylor Wang

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

Taylor Wang — Tue, 13 Oct 2026 10:43:50 +0000

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.

Freeze the script bytes and the fixture files before any model is allowed to rewrite a single line.
Require a forced-miss path that must exit nonzero, and fail the receipt when that path looks successful.
Run the receipt in a clean local directory, then use the second host only if that local exit is already zero.
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?

48-Hour Field Notes: I Stopped Treating the Reply as the Run

Taylor Wang — Tue, 13 Oct 2026 07:12:02 +0000

I opened a fresh notebook because a polished reply kept arriving before any process on my side had started. The text looked complete, named a command, and even described a passing check that I had not executed. Why was I ready to copy that sentence into the log as if it were an observation? A chat transcript is not a process table, and it cannot show which binary actually ran.

That gap is the whole job for these notes, not a product tour and not a scoreboard. I wanted one place to ask a model for a patch, and another place to run a narrow command where I could read the exit myself. If those two records disagree, which one deserves the green mark in my notes? I wrote the rule down before I asked for another suggestion, because a fluent paragraph can impersonate a result.

What I tried in the first twelve hours

I started by splitting the work into two witnesses that are not allowed to grade each other. The first witness is a free model session, useful when I want a draft command or a short explanation without opening a paid console. The second witness is a free server session, useful when I need a shell that is not my laptop and not the model's imagination. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am using those two availability claims only, and I am not treating a marketing page as a measured lab.

I did not record a model name, a quota, a machine size, or a promise that the free option will still look the same next month. Those details change, and inventing them would make these notes lie with a straight face. What I can repeat is the order of operations, which is dull on purpose and hard to fake. Ask, capture, hash the text, run an allowlisted command, then write the exit code beside the hash.

Here is the question I kept asking whenever the reply sounded finished. Did any process outside the chat actually start, and did it finish with a code I can quote? If I cannot answer that, the suggestion stays in a draft folder, even when the wording is clean. A free server is not magic here, because a free shell can still be the wrong tree, the wrong user, or a job that never left the queue.

The notebook I would actually rerun

The artifact below is a small recorder, not a benchmark and not a claim that I timed a vendor. I labeled the sample paths as examples, and I would run them on whatever host I was given rather than trust a pasted success story. You can drop the file on the server, point it at an allowlist, and refuse to print a green line unless the command exits zero. Would I merge a patch because the model said this script already passed? No, I would not, and the script is written to make that laziness slightly harder.

#!/usr/bin/env python3
"""Suggestion ledger. Example workflow, not a recorded benchmark."""

import hashlib
import json
import subprocess
import sys
from datetime import datetime, timezone
from pathlib import Path

ALLOW = {
    "py_compile": [sys.executable, "-m", "py_compile"],
    "unit_check": [sys.executable, "-m", "unittest", "discover", "-s", "tests", "-q"],
}

def stamp(label, text):
    digest = hashlib.sha256(text.encode("utf-8")).hexdigest()
    return {
        "label": label,
        "sha256": digest,
        "chars": len(text),
        "at": datetime.now(timezone.utc).isoformat(),
    }

def run_allowed(key, extra):
    if key not in ALLOW:
        raise SystemExit(f"refusing unknown job: {key}")
    cmd = ALLOW[key] + list(extra)
    proc = subprocess.run(cmd, capture_output=True, text=True, timeout=120)
    return {
        "cmd": cmd,
        "code": proc.returncode,
        "stdout_sha256": hashlib.sha256(proc.stdout.encode()).hexdigest(),
        "stderr_sha256": hashlib.sha256(proc.stderr.encode()).hexdigest(),
    }

def main():
    suggestion = Path(sys.argv[1]).read_text(encoding="utf-8")
    job = sys.argv[2]
    record = {
        "suggestion": stamp("model_reply", suggestion),
        "run": run_allowed(job, sys.argv[3:]),
    }
    record["agree"] = record["run"]["code"] == 0
    print(json.dumps(record, indent=2))
    return 0 if record["agree"] else 1

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

The commands I actually want in the notes are boring, and that is a feature rather than a lack of ambition. I save the raw reply first, then I compile, then I decide whether a unit discovery is even on the allowlist for this host. A model can propose a piped install, and this recorder will not grow a new key just because the paragraph sounded urgent. Why give a draft the right to invent its own shell history?

mkdir -p notes/day1
# Save the raw completion yourself. Do not let the model write this file.
cp reply.txt notes/day1/reply.txt
python3 ledger.py notes/day1/reply.txt py_compile path/to/changed_module.py
echo "ledger_exit=$?"

I also keep a second command for the case where the server and my laptop do not share a tree. I print the host, the user, and the executable before I trust a zero, because a green code on the wrong machine is just a different story. This check is about identity of the run, not a feeling about how fast the free box answered.

python3 - <<'PY'
import getpass, platform, sys
print(platform.node(), getpass.getuser(), sys.executable)
PY
# Sketch only: replace the alias with the host your panel actually shows.
ssh free-host 'python3 -m py_compile path/to/changed_module.py; echo exit:$?'

I should label that ssh line as a sketch. The host alias free-host is a placeholder, not a hostname I measured, and your free server panel may name the box differently. If the panel does not give you a shell, this branch of the notes simply stops. A free model can still draft the patch, but it cannot substitute for the missing exit code.

What broke when I let the reply grade itself

The first break was social, not technical, and it showed up as soon as the paragraph said the check already passed. I had not started the server job, yet my fingers wanted to write verified next to the suggestion hash. Who was I trying to impress with that word, the future reader or my own impatience? I deleted the word and left the hash alone until ledger_exit existed.

The second break was a mismatched command that still looked related enough to fool a tired note. The reply described unittest, while the only allowlisted job I was willing to run that hour was py_compile, so a clean compile was not the test the paragraph had claimed. A zero from the compiler does not prove the tests, and a model's summary does not prove the compiler ran. I started writing the job key in the same line as the claim, so a later reader can see the gap without guessing.

The third break was environmental, and it is the one I would repeat the warning for. A free server can boot with a different working directory, a different user, or a queue that never dispatched the command I thought I had sent. If the ledger file is missing, I do not infer success from silence, because silence is how a dropped job disguises itself. Did the process start, and did it finish, or did I only receive a sentence about finishing?

A decision table I can reuse tomorrow

I do not want a score that pretends to measure model quality, because I never built that experiment and I will not fake the rows. This table only decides whether my notes may say ran, or must say draft. The columns are evidence I can point at, not feelings about how confident the wording sounded.

What I hold	Reply only	Server log only	Both, and codes match the claim
Note status	draft	incomplete	candidate
May I say verified?	no	no	only for that job key
Next action	save hash, do not patch	rerun or fix the host	read the diff, then decide
Failure I expect	fluent false pass	wrong tree or no dispatch	still review the diff

A candidate is not a merge. It means the command I allowlisted exited in a way that matches the narrow claim, on a host I can name in the note. If the reply promised tests and I only compiled, the row stays incomplete even when the compiler was happy. Would I widen the allowlist mid-session because the model asked nicely? No, that change belongs in a separate note, after I have read the new command.

What I would repeat, and what I would not

I would repeat the capture step, the allowlist, and the refusal to write verified without ledger_exit in the same folder. I would also repeat the host line, because a free server is only useful if I can tell it apart from my laptop and from the chat. The free model access is the part I would keep for drafting, especially when I want another wording of a failing traceback before I open a paid seat. The free server option is the part I would keep for the run, because a suggestion that never meets a shell is still just a suggestion.

I would not repeat any sentence that quotes a quota, a GPU name, or a latency number I did not measure on that day. I would not pipe a model command into a shell, and I would not let the recorder accept arbitrary arguments from the reply text. I would not use this notebook to judge which vendor is best, because two availability switches are not a leaderboard. If your work needs a private dataset, a signed production host, or a change window with an on-call owner, do not rehearse that change on a free shared server just because the reply looked ready.

People who should skip this approach are easy to name, and I would rather name them than pretend the ledger fits every team. Skip it if you cannot read the server log yourself, or if policy forbids sending even a redacted traceback to an outside model. Skip it if the patch touches credentials, production data, or a service you cannot roll back before the next coffee. Skip it if you need a compliance attestation, because a field notebook is not an audit, and a free tier is not a contract I am willing to invent.

Limits I am leaving in the note

This workflow does not prove that the model understood the code, and it does not prove that the server matches production. A timeout of 120 seconds in the example is a guard for the sketch, not a service level I negotiated with anyone. py_compile catches syntax, not behavior, and unittest discover only helps if those tests already exist and already mean something. The hashes tell me whether the text changed, not whether the text was wise.

I also cannot tell you that the free model list or the free server button will remain in the same place, with the same limits, next week. Check the console you actually have, and write down what you see instead of copying these notes as if they were a status page. If the free server never gives you a shell, stop at the draft and run the allowlisted command somewhere you do control. A missing witness is a result, and it should look like a missing witness in the file.

If you already use MonkeyCode, the useful part is ordinary: open the free model path when you need a draft, open the free server path when you need a shell, and keep their outputs in separate files. I would still read the diff myself before I land anything, because agreement on an exit code is not agreement that the change is the one I wanted. The notebook is there so my future self can see what ran, what never started, and what I refused to call done.

I Parked Every Suggested Diff Until a Scratch Host Replayed the Failure

Taylor Wang — Tue, 13 Oct 2026 04:56:41 +0000

Have you ever accepted a tidy suggested edit, only to watch the same test fail on a machine that started empty? I have, and the embarrassing part was that my own laptop had been quietly supplying the missing piece. The local tree already had packages, environment variables, and cached wheels that a clean runner would never inherit. So the rule I would repeat is simple: park the suggested diff until a scratch host replays the failure without those leftovers.

Why a green local run was the wrong comfort

Treat the currency bug below as a reconstructed walkthrough, not as a customer incident or a measured product trial. A checkout helper returned the wrong currency code when a locale package was missing, but my laptop already had that package. An assistant proposed a three-line guard that looked careful, and the local test went green in well under a second. Would you have merged that guard, or would you have asked which machine was actually being tested by the pass?

I did not merge it, because a green result on a dirty tree answers a different question from the one I had asked. I needed a blank environment to fail the same way before the patch, and then to pass for a reason I could name. A local pass cannot separate those stories when the host is already full of leftovers from older experiments. I wanted a note I could reread two days later, not a feeling that the diff looked small enough to trust.

The forty-eight hour notebook

I split the work into four blocks so I would not skip the boring capture step when a suggestion arrived. Each block had one job, and I wrote the result into a file instead of trusting a chat scroll to remember it. Nothing here is a benchmark, and I am not claiming timings, token totals, hardware sizes, or a permanent free tier. The artifact is a small gate over two text logs, plus a table for deciding where that replay should live.

Hours 0 to 8: freeze the failure

I checked out the revision that still failed, and I ran the single test that showed the wrong currency code. I saved stdout and stderr into a file named captured.txt, and I stored the interpreter version beside that log. I also stored a hash of the lockfile, because a later run on a different dependency set is not the same replay. Why keep that hash if the test name already matches, and the command line looks identical on both hosts?

A matching name can still hide an extra wheel, a different interpreter, or an environment variable you forgot to unset. I refused to ask for a patch until the captured file existed and a second local run produced the same failure text. That second local run is not the clean replay, and it only proves that the failure is stable on the dirty host. Have you ever skipped that step and then argued with a log that you can no longer reproduce at all?

python -m pytest tests/test_checkout_locale.py -q > captured.txt 2>&1
python --version > host.txt
python - <<'PY'
import hashlib, pathlib
p = pathlib.Path("requirements.lock")
print(hashlib.sha256(p.read_bytes()).hexdigest())
PY

Hours 8 to 24: replay on a host that does not know me

I created a throwaway virtual environment from the lockfile alone, with no extra index and no copied site-packages. Then I ran the same test there and saved the combined output as replay.txt for the gate to read. If that file did not still show a failure, I stopped, because I had not reproduced the bug I meant to fix. Have you noticed how often the apparent fix is just a package you forgot you had installed last month?

python -m venv /tmp/scratch-venv
/tmp/scratch-venv/bin/python -m pip install -r requirements.lock
/tmp/scratch-venv/bin/python -m pytest tests/test_checkout_locale.py -q > replay.txt 2>&1
python scratch_gate.py captured.txt replay.txt

When the laptop itself is part of the contamination, a fresh virtual environment is not always a strong enough wall. Editor plugins, shell exports, and a global package cache can still leak into a story you thought was isolated. A second host, even a small temporary one, removes those leftovers if you create it from the lockfile only. That is the moment a free remote runner becomes useful, provided you treat it as disposable and you keep secrets off it.

Hours 24 to 40: only then read the suggested diff

I sent the captured failure, the lockfile hash, and the test file, and I asked for a patch with no new dependency. The suggestion came back shorter than I expected, which is not a virtue, because short code can still assume the wrong host. I applied it on the scratch environment only, reran the test, and saved the new log as after.txt next to the replay. A pass on that host was interesting, but I still read the patch for imports and paths I did not recognize.

Would I have trusted the suggestion if the scratch host had stayed red after the patch was applied there? No, I would not, because a confident explanation does not change an exit code or repair a bad assumption. I kept the failing replay beside the passing log so I could see which lines actually moved between the two runs. The assistant was useful as a draft of the edit, and it was useless as a witness that the edit was safe.

Hours 40 to 48: what broke, and what I would repeat

Two things broke during the window, and both mistakes were mine rather than a surprise in the test runner. First, I almost compared logs by hash only, and a timestamp line made two equivalent failures look unrelated. Second, I nearly copied my shell history onto the scratch host, which would have smuggled the variable I was excluding. I would repeat the gate, the lockfile hash, and the rule that a patch waits for a failed replay and a later pass.

I would not repeat any flow that lets an assistant commit, or that sends private fixtures to a machine I do not control. I would also not repeat a comparison that treats a timestamped log as a fingerprint of the underlying failure. The useful repeat is boring on purpose, and that boredom is what keeps a tidy suggestion from skipping the line. If the note takes longer than the patch, that is a sign the patch was never the expensive part of the work.

The gate I kept

The script below is a local harness you can reread later, not a score and not a client for a hosted product. It exits zero only when the replay log still looks like a failure, which is what you want before applying a patch. It exits one when the clean run is already green, because that means the bug was not reproduced on that host. Run it yourself before you trust it, since your failure text may not contain the markers I happened to check for.

#!/usr/bin/env python3
"""Compare a captured failure with a clean replay. Local harness only."""
import hashlib
import json
import sys
from pathlib import Path

MARKERS = ("FAIL", "ERROR", "Error", "Traceback", "AssertionError")

def signature(path: Path) -> dict:
    text = path.read_text(encoding="utf-8", errors="replace")
    return {
        "sha256": hashlib.sha256(text.encode("utf-8")).hexdigest(),
        "failed": any(marker in text for marker in MARKERS),
    }

def main() -> int:
    if len(sys.argv) != 3:
        print("usage: scratch_gate.py captured.txt replay.txt", file=sys.stderr)
        return 2
    captured = signature(Path(sys.argv[1]))
    replay = signature(Path(sys.argv[2]))
    same = captured["sha256"] == replay["sha256"]
    print(json.dumps({"captured": captured, "replay": replay, "same_hash": same}, indent=2))
    return 0 if replay["failed"] else 1

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

Where a free runner fits, and where it does not

I do not want the draft step and the blank machine to depend on the laptop I am already trying to distrust. MonkeyCode's free model access and free server option can cover that split when you still review every generated diff yourself. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am not listing models, quotas, hardware, or duration, because those details were not verified here and can change without notice.

Use the table before you move a replay, and do not treat a free option as a promise that the option will remain. If you want to try the split without spending the afternoon on billing setup, check the current docs first and then decide. A remote pass still does not review the code, and it still does not make an unread diff safe to merge. Throw the scratch environment away when the note is written, so the next failure starts from empty rather than from leftovers.

Question	Stay on the laptop	Move the replay
Can a fresh venv still show the failure?	Yes, start there and keep the log	No, the host state is the suspect
Does the fixture contain secrets or customer data?	Review offline, or replace it with fake data	Do not upload it to any free runner
Can you read the whole diff in one sitting?	Require that before any remote run	A remote pass does not review the code for you
Do you need an audit trail or a support contract?	Use whatever your team already operates	A free option is not a production promise

Who should skip this

Skip the remote half if your tests need production credentials, private keys, or data you cannot show a third party. Skip the text gate if the failure is visual, flaky, or timing-based, because a marker search will lie with confidence. Skip the whole approach if you wanted a ranking of tools, since I measured nothing and I am not scoring products. A free server can disappear, change size, or reject a workload, so do not let a release process depend on it remaining.

Do not send secrets, tokens, or customer fixtures to a free runner that you do not administer yourself.
Do not treat a text marker as proof when the bug is visual, flaky, or quietly dependent on the clock.
Do not publish a quota, a model name, or a machine size that you have not confirmed in the current docs.

What I would tell my past self

Would I still ask an assistant for the first draft after the failure is frozen and the scratch host has failed the same way? Yes, I would, provided the prompt includes the captured log and the lockfile hash rather than a vague request to clean things up. Would I let that draft touch the working branch first, even when the edit is three lines and the explanation sounds calm? No, I would not, because calm wording has never been evidence that a second environment will agree with the first one.

The order I would repeat is short, and I keep it written down so a tidy diff cannot talk me out of it.

Freeze the failing log and the lockfile hash before you allow anyone to suggest a change at all.
Replay that same command on a host created from the lockfile, with no copied packages and no shell history.
Ask for a draft only after that replay is still red, and include the captured log instead of a vague prompt.
Read the diff yourself, rerun it on the scratch host, and discard that host as soon as the note is written.

The repeatable part is the order of operations: capture the failure, replay it cleanly, then patch, then read the diff yourself. The part I would drop is any sentence that treats a free runner as proof, rather than as a clean room I can discard. Order is the whole method, and the assistant stays a draft until a stranger host has told the same story twice. If that sounds slow, compare it with the hour you will spend explaining a green laptop run that nobody else can reproduce.

48-Hour Field Notes: Both Plans Had to Name the Paths Before I Would Apply

Taylor Wang — Tue, 13 Oct 2026 03:56:12 +0000

Would you paste a suggested patch onto a server you just met because the reply called the change safe? I would not, and these notes are the refusal I want to keep for the next host. A free chat can draft a tidy edit while the process that would run it still sits in the wrong directory. So I spent this window on a plan file, not on a write I could not undo.

What I tried before I trusted the second host

I started from a boring question that still saves me more time than another pass over the patch. Which paths would change, and which of those paths are even present on both sides? A model can describe an edit in a paragraph, but a paragraph is not a list of operations with roots and intents. I wanted that list from the laptop and from the remote session before either side created a file.

Would a matching pair of path lists be enough, by itself, to apply the change on the second host? Not by itself, because the bytes you write can still be wrong even when the names already agree. A mismatch is already a stop, and that stop is the part I care about recording first. I kept the first pass read-only, and I pointed the script at a fixture tree I was willing to delete.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. Free model access is where I would ask for a plainer reading of a confusing plan diff. The free server option is the second host this checklist expects, when that option is actually offered. I am not claiming a quota, a hardware shape, a duration, or a promise that those options stay fixed.

If either option is missing on the account you use, the same script still earns its keep on two local directories. I would not invent a stand-in host and then describe that folder as if it were the offered server. A missing option is a missing option, and the checklist should say so instead of papering over the gap. The comparison habit does not require a product name in order to be worth running.

What broke once the plans could disagree

The first break was social, not technical, and it showed up inside the suggested shell block. The reply bundled the plan command and the apply command in one fenced region, so a hurried paste would write first. Have you ever copied a quick check that ended in a mutation you did not mean to run? That is the failure the confirm flag is there to catch, and I now refuse a block that mixes both steps.

The second break was the current directory, which is a quieter way to aim at the wrong tree. A relative root of . meant the repo on the laptop and another folder on the server. The plan then listed different parents for the same basename, which is an easy miss in a summary. I stopped accepting a relative root unless both plans print the resolved path and those strings agree.

A third break appeared when a scratch file existed only on the server side of the rehearsal. The plan grew an operation that the laptop never proposed, and a summary might call that extra harmless. I do not treat extra names as harmless, because an apply that trusts the longer list writes something I never reviewed. Sorting became the fourth break, and it was the one I nearly blamed on the suggestion.

A locale-aware sort reordered names that differed only by case, and the textual diff looked like a logic bug. I pinned the sort to raw code points, and I stopped blaming the suggestion for a difference the printer invented. Would I have noticed that inside a chat summary that called the plans basically the same? Probably not, because a summary flattens order and it drops the resolved paths I needed.

The prefix check I would not ship

I almost treated a string prefix test as proof that a path stayed inside the root. That check is wrong when one directory name is a prefix of a neighbor directory beside it. /tmp/app is a prefix of /tmp/app-backup, so a string test would allow a walk into the neighbor. The script below uses Path.relative_to after resolve, and I would not ship the string version as a shortcut.

Does that distinction matter on a short home path that looks obvious in a prompt? It matters wherever two directories share a prefix, which is a common layout under temporary folders and under home. I would rather fail the plan than explain a write that landed next door. A guard that only works on pretty paths is not a guard I want on a second host.

The artifact I would run again

This is a small standard-library script, not a framework, and not a stand-in for a deploy system. It builds a plan, compares that plan with a file you already saved, and applies only with a separate confirm flag. Treat the listing as a workflow you can execute on a disposable tree you already understand. I am not attaching timings, quotas, hardware claims, or a vendor scoreboard to this script.

#!/usr/bin/env python3
'''plan_guard.py — emit a read-only plan, then require a separate apply.

Apply writes a placeholder only. Point --root at a tree you can delete.
Type hints assume Python 3.9 or newer.
'''
import argparse
import json
import sys
from pathlib import Path

def build_plan(root: Path, names: list[str]) -> dict:
    root = root.resolve()
    ops = []
    for name in names:
        rel = Path(name)
        if rel.is_absolute() or any(part == '..' for part in rel.parts):
            raise SystemExit(f'refusing unsafe name: {name}')
        path = (root / rel).resolve()
        try:
            path.relative_to(root)
        except ValueError:
            raise SystemExit(f'refusing path outside root: {name}')
        if path.exists() and not path.is_file():
            raise SystemExit(f'refusing non-file: {path}')
        ops.append({
            'op': 'write',
            'rel': name,
            'resolved': str(path),
            'existed': path.exists(),
        })
    ops.sort(key=lambda item: item['rel'])
    return {'root': str(root), 'ops': ops}

def main() -> int:
    parser = argparse.ArgumentParser()
    parser.add_argument('--root', required=True)
    parser.add_argument('--name', action='append', required=True)
    parser.add_argument('--apply', action='store_true')
    parser.add_argument('--confirm', default='')
    parser.add_argument('--plan', default='')
    args = parser.parse_args()
    plan = build_plan(Path(args.root), args.name)
    if not args.apply:
        sys.stdout.write(json.dumps(plan, indent=2, sort_keys=True) + '\n')
        return 0
    if args.confirm != 'yes' or not args.plan:
        print('apply refused: need --confirm yes and --plan', file=sys.stderr)
        return 2
    reviewed = json.loads(Path(args.plan).read_text(encoding='utf-8'))
    if reviewed != plan:
        print('apply refused: reviewed plan != live plan', file=sys.stderr)
        return 3
    for op in plan['ops']:
        dest = Path(op['resolved'])
        dest.parent.mkdir(parents=True, exist_ok=True)
        dest.write_text('placeholder\n', encoding='utf-8')
    print('applied %s write(s)' % len(plan['ops']))
    return 0

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

Commands I keep beside the note

I run the plan locally, then I run the same names on the second host, and only then do I consider apply. I save both JSON files, and I diff them with a tool that does not reorder lines for me. The second host can be the free server option, when that option is the one you actually have. It can also be another folder on the same laptop if that option is not in front of you today.

mkdir -p ./fixture/notes
python3 plan_guard.py --root ./fixture --name notes/day1.txt --name notes/day2.txt > local-plan.json
python3 -m json.tool local-plan.json > /dev/null
diff -u local-plan.json remote-plan.json
python3 plan_guard.py --root ./fixture --name notes/day1.txt --name notes/day2.txt --apply --confirm yes --plan local-plan.json

I never feed the laptop plan into an apply on the server, because the resolved paths will differ and the guard will refuse. The cross-host step is a reading of rel and existed, not a blind replay of the other file. Apply only replays the plan that the same host just printed, after you have accepted that reading. If you skip that distinction, the confirm flag becomes a way to fail, not a way to write.

Checks I want red before I trust a green run

A single happy path is how a guard rots, so I keep a short list of failures I expect to see. Each one should fail closed, with a non-zero status, before I believe the success case. I would rather rehearse these five than collect a story about a clean run. None of them require a product setting, a quota, or a named model.

Run apply with no confirm flag, and expect exit code 2 plus a refusal line on stderr.
Save a plan, add one more --name, and expect exit code 3 because the reviewed file no longer matches.
Pass a --name that climbs out with .., and expect the unsafe-name refusal before any write occurs.
Point --root at two different directories, and confirm that resolved differs even when rel still matches.
Create a directory where a named file should be, and expect the non-file refusal instead of a write.

The decision table I actually look at

I do not want a vibe check after a reply that sounds confident about a tree it has not listed. I want a row that says stop, rerun, or apply, and I want that row to name evidence I can open in an editor. Would I skip a row because the suggestion already apologized for the mismatch? I would not, because an apology is not a diff.

If the root strings differ, I stop, and I fix the working directory before I discuss the patch.
If one plan has an extra rel, I stop, and I ask which host invented that name.
If existed differs, I rerun after I decide whether create and overwrite carry the same risk here.
If the diff is empty and the tree is disposable, I may apply, and I still keep the plan file next to the log.
If the model says the diff is empty but the file diff is not, I trust the file and I reread the command.

What I would repeat on the second day

I would repeat the split between asking and applying, because that split is the whole habit. Free model access helps when I want a second reading of a confusing diff, or a plainer description of the schema. It does not help as a witness that the server tree matched the laptop tree. It cannot see that tree unless I paste the plan, and a paste can quietly drop a path.

Would I let the reply set the confirm flag for me after a clean-sounding summary on the second host? I would not, and the flag stays in the command I type only after the diff is on screen. The model can explain a mismatch, and it cannot close the mismatch by sounding sure. That line is the one I would copy into the next note if I copied nothing else.

I would also repeat the hostile fixture, even on the second day, when the first run looks clean. Each rehearsal gets one extra name, one missing name, and one run from the wrong directory. Those three failures are cheap, and they train the stop better than another clean success does. I would keep the server session on a tree I can delete, even when the option is free.

Free does not mean those files are isolated from other work sitting in the same home. A shared home directory is still a shared home directory, and a placeholder write is still a write you must intend. I would repeat this same note format on the second day, including the temptation I almost hid. The first day records the commands I ran and the mismatch that surprised me in the diff.

The second day records whether I wanted to skip the diff because the suggestion sounded sure of itself. That temptation is the bug I am tracking, and the script is only the fence I put around it. If the fence feels annoying during a quiet rehearsal, it is still doing the job I wrote it down for. I would rather repeat that annoyance than repeat a write I cannot explain.

Limits, and who should skip this

This guard does not review the bytes you meant to write, and the sample apply stores a placeholder rather than your real patch. It will not catch a bad transformation that happens to touch the same paths you already allowed. It will not protect you if you remove the confirm check, or if your user can write outside the root. A mislabeled shell is also outside its reach, because the script cannot tell which host you think you are on.

You should skip this approach if you need a signed release, a review of binary files, or proof that two machines share a full source tree. You should also skip it if you cannot stand a manual diff, because the method is that diff and the script will not perform it for you. Teams that already have a dry run inside their deploy tool do not need a second hobby script that can drift from that tool. If the free server option is unavailable, do not invent a substitute host and then describe the rehearsal as the same place.

The example assumes a POSIX-like path style, and I would not treat a green run here as a Windows proof. After resolve, a symlink that leaves the root is refused, which is what I want for this guard, and it is not a general symlink policy. The allowlist has to be names you typed, not a generated glob you did not read line by line. If any of those limits collide with the job in front of you, pick the stricter process you already trust.

If those two options are available on the account you already use, rehearse the plan on the free server. Keep the apply on a tree you can throw away, even after that rehearsal looks quiet. Ask the free model for a plain reading of the mismatch, then decide from the files rather than from the tone. Two local folders still prove the checklist if you would rather leave the product out of the loop.

I Diffed Locale and umask Before I Let the Health Check Land

Taylor Wang — Mon, 12 Oct 2026 23:38:36 +0000

I started these notes because a small health check looked finished on my laptop and then fell apart once a second host entered the picture. The draft opened text files without an encoding, printed the umask by calling the setter, and assumed my home directory would accept a cache write. Would you merge that patch if the only green run still lived on the machine that authored the file? I would not, so I spent two days turning those quiet assumptions into a manifest I can diff.

Hours 0 to 8: the draft looked done

The job was boring on purpose, which is exactly why I almost trusted the tidy output too early. I wanted a short Python check that prints the interpreter, the working directory, the locale, and whether a cache directory is writable. A generated draft arrived in one pass, and the local run printed a neat block that looked like a finished tool. Have you ever accepted a neat printout simply because the function names sounded like production code?

I had used MonkeyCode's free model access to sketch that first draft, and a free server option was available for the second run. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am writing inside that outreach, not as an independent benchmark lab with a score to defend. I am not claiming a quota, a machine shape, or a promise that free access stays fixed. The habit below still works if you swap both tools for a laptop container and a text editor.

The draft carried three lines that I now refuse to skim past when I review a generated check. It called os.umask(0) to read the mask, it used open(path) with no encoding argument, and it wrote under Path.home() without a fallback path. On my laptop those lines looked harmless, because my locale is UTF-8 and my home directory is mine. Why would a second host preserve any of those comforts just because the sketch assumed them?

Hours 8 to 24: the second host disagreed

I copied the same file into the free server job and ran the same command from a clean working directory. The process did not share my laptop locale, and the cache probe did not share my laptop home directory either. I am not publishing timings or a pass rate, because this was a lab comparison rather than a study. What I can repeat is the shape of the disagreement, and you can reproduce that shape with the script below.

Three failures showed up in the lab before I touched the patch I actually cared about. The umask helper left the process mask at zero, so a later log file was created world-writable on that host. A notes file with a non-ASCII comment failed to decode when the preferred encoding was not UTF-8. The home cache probe returned a permission error, and the draft had no branch for that result at all.

Would a green local pytest have caught any of those failures, if every test stayed on the laptop? I do not think so, because the tests inherited the same locale, the same home, and the same starting directory. I also noticed a quieter lie hiding underneath the successful exit code returned by that server job. The draft assumed the process had started inside the repository root on every host I would use.

The server job started in a scratch directory that I had never named anywhere in the prompt. Relative paths then opened the wrong file, or they opened nothing while the check still exited zero. That is the kind of green result I no longer treat as a reason to merge.

The manifest I would run again

The artifact is a single script that prints canonical JSON and never touches the network at all. Run it on the laptop, run it on the second host, and diff the two files before you read any explanation. I left a broken helper in the file so the umask trap stays visible, and that helper is not called by main. Treat the whole file as a lab recipe, not as a log pulled from a customer incident.

#!/usr/bin/env python3
"""Host manifest for a second-host diff.

Lab recipe, not a measured outage. The cache probe may create
~/.cache/manifest-lab and leave that empty directory behind.
"""

from __future__ import annotations

import json
import locale
import os
import sys
import tempfile
from pathlib import Path

ALLOW = ("LANG", "LC_ALL", "LC_CTYPE", "PYTHONIOENCODING", "PYTHONUTF8", "TZ")


def read_umask() -> str:
    """Return the current umask and restore it before we leave."""
    current = os.umask(0o022)
    os.umask(current)
    return oct(current)


def broken_read_umask() -> str:
    """Example only: this leaves the process umask at 0. Do not ship it."""
    return oct(os.umask(0))


def safe_locale() -> list[str | None]:
    try:
        return list(locale.getlocale())
    except ValueError as exc:
        return ["unavailable", exc.__class__.__name__]


def probe_dir(path: Path) -> str:
    try:
        path.mkdir(parents=True, exist_ok=True)
        probe = path / ".manifest_probe"
        probe.write_text("ok", encoding="utf-8")
        probe.unlink()
        return "writable"
    except OSError as exc:
        return f"blocked:{exc.__class__.__name__}"


def main() -> int:
    home = Path.home()
    manifest = {
        "cwd": os.getcwd(),
        "executable": sys.executable,
        "filesystem_encoding": sys.getfilesystemencoding(),
        "home": str(home),
        "home_cache": probe_dir(home / ".cache" / "manifest-lab"),
        "locale": safe_locale(),
        "preferred_encoding": locale.getpreferredencoding(False),
        "temp": probe_dir(Path(tempfile.gettempdir())),
        "umask": read_umask(),
        "version": sys.version.split()[0],
        "env_allowlist": {key: os.environ.get(key) for key in ALLOW},
    }
    json.dump(manifest, sys.stdout, indent=2, sort_keys=True)
    sys.stdout.write("\n")
    return 0


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

python3 host_manifest.py > local.json
# Second host, same file, same command, clean working directory:
python3 host_manifest.py > remote.json
diff -u local.json remote.json
# Optional pressure test, then compare again:
PYTHONUTF8=0 LC_ALL=C python3 host_manifest.py > c_locale.json

def read_notes(path: str) -> str:
    # Prefer an explicit encoding over open(path) with no encoding argument.
    with open(path, encoding="utf-8") as handle:
        return handle.read()

How I read a diff without arguing with it

I sort the JSON so a noisy key order cannot pretend to be a real change. I ignore nothing in the allowlist, and I never print the rest of the environment beside those six names. If preferred_encoding differs, I stop, even when the health check text looks identical on both sides. A matching exit code is not a matching host, and I had to write that sentence down before I trusted myself.

A decision table I kept beside the notes

I did not want a vibe check at hour thirty, so I wrote the responses down before the diff tempted me to explain them away.

Diff field	What I do before merging	Why I stop
preferred_encoding	Set `PYTHONUTF8=1` on both sides, then rerun	`open()` without an encoding will split
locale	Treat `C` or an empty pair as a failed boarding	Sort order and decoding both move
umask	Reject a helper that sets the mask and never restores it	Later files become world-writable
home_cache	Refuse cache writes when the probe says blocked	The draft will crash or write elsewhere
cwd	Require an explicit repository root argument	Relative paths lie from a scratch start
version	Read the minor notes before accepting a pin	Warnings and defaults move between minors
env_allowlist	Diff only the named keys, never a full dump	A full dump leaks tokens into the notes

Hours 24 to 40: I made the disagreement boring

The second day was mostly subtraction, which is less glamorous than another generated rewrite and much safer. I deleted the umask setter from the draft, passed encoding="utf-8" at every text boundary, and replaced the home write with an explicit --cache-dir. I also stopped asking anyone for a server-side fix before the JSON diff existed on disk. Is a long and fluent explanation actually useful when the two manifests still disagree on encoding?

When I did ask for a revision, I pasted the diff and the matching decision row, not the whole environment block. That kept secrets out of the prompt, and it kept the draft from inventing a locale I had not measured. Free model access was handy for that rewrite, but the manifest stayed the source of truth on my side. If that access is busy, limited, or simply gone later, the script still runs on whatever host you already have.

The free server option mattered for one narrow reason, and I want that reason kept small. I wanted a second host I could start without opening a billing argument, so the comparison would actually happen on a tired afternoon. I do not know the hardware, the neighbor load, or how long that option remains free. I will not fill those blanks with guesses, even when a tidy paragraph would look more confident.

A paid virtual machine, a local container, or a colleague's shell will teach the same lesson if the manifest stays honest. The point is the second host, not the logo printed beside the connect button on the page. If you already own a spare shell, use that shell and skip the product detour entirely.

Hours 40 to 48: what I would repeat

I would repeat the comparison itself, and I would drop the part where a tidy printout felt like proof. The list below is the part I want future me to follow when the next small tool shows up. None of these steps require a named model, a quota, or a story about how fast the draft arrived.

Sketch with a model if you want a faster start, then mark every environment call untrusted until both manifests agree.
Run the script on both hosts, and store both JSON files next to the patch that is under review.
Force UTF-8 with PYTHONUTF8=1 when you own the job, and still pass an explicit encoding inside the application code.
Read the umask with a restore afterward, or skip that read entirely when the program never creates files.
Drop any check that still exits zero when the cache probe returns a blocked result to the caller.
Drop any prompt that includes a full environment dump, a live token, or a private path under home.

Would I repeat the hour where I trusted the local printout just because the headings looked complete? I would not, because that hour did not even require a clever bug to waste the rest of the review. The bug was ordinary, which is exactly why I expect the same shape to show up on the next small tool.

Limitations, and who should skip this

This manifest does not prove the patch is correct, and a matching pair of JSON files only says the listed assumptions traveled together. A signal between the two os.umask calls can still leave the mask unrestored, which is rare and still worth naming in the notes. Calling locale.getlocale is not the same fact as asking for the preferred encoding, so the script keeps both fields. On Windows, umask is not the permission story most of us carry over from Unix hosts, so this recipe is the wrong tool there.

Skip this approach if you need an attestation for an audit, because a lab diff is not a signed record of any kind. Skip it if the job handles secrets, unless those secrets are already gone from the prompt and from the JSON output. Skip it if you need guaranteed capacity, a named accelerator, or a free tier you can plan around. I was not given those facts, and I will not invent them to make the notes sound more certain.

Skip it if your team already ships a locked image and a hermetic test runner for every change. You may simply be re-checking a problem that the image build has already closed for you. In that case the manifest is optional reading, not a new gate you need to add this week.

Where I left the notes

The patch I would actually land is the boring one, and I am fine with that result. It has an explicit encoding, an umask helper that restores the old mask, and a cache directory you pass in. It also carries a manifest diff inside the review note, so the next reader can see the host gap. If a free server seat is already sitting in your account, run the manifest there once before you merge.

Keep the JSON beside the patch, instead of trusting a paragraph that explains the disagreement away. The model can draft the next check whenever you want a quick sketch to react to. It does not get to decide that my laptop and the second host are the same machine.

The Other Box Had Not Agreed on an Encoding Yet

Taylor Wang — Mon, 12 Oct 2026 19:48:27 +0000

A remote Python job can look like a logic bug when the real split is inherited text encoding. The traceback names a bad character, yet it never names the locale that selected the encoding. Would you paste a one-line encode fix before you know what the second host preferred? I would not, because a confident suggestion is not the same thing as a receipt from the process.

This note is a 48-hour field notebook, not a claim that I timed a product or measured a fleet. I would spend the first hours freezing what the process can see, and the later hours refusing patches that ignore that freeze. What usually breaks this kind of check is not the clever line, but the missing context around it. What I would repeat is the receipt, the comparison, and a hard stop when the two hosts disagree.

What I would freeze before I ask anyone

I would not start the window by asking a model to explain a traceback I pasted from memory. I would start by running one small fingerprint on the same interpreter that just failed the job. Does that extra freeze feel too slow when the error is already sitting on the screen? It is slower than pasting, and it is faster than landing a fix for an encoding the remote process does not use.

The script below is a proposal you can run, and I am not presenting it as a timed result from a particular machine. It writes a JSON receipt to a UTF-8 file, hashes that payload, and refuses to dump the environment. If a value is missing, I want null in the file, not a guess I typed from memory later. I would not print that JSON to stdout, because an ASCII stdout can kill the fingerprint before the file exists.

"""Proposed receipt. Unexecuted example, not a measured benchmark."""
import argparse
import hashlib
import json
import locale
import os
import platform
import sys

WATCHED = (
    "LANG",
    "LC_ALL",
    "LC_CTYPE",
    "PYTHONIOENCODING",
    "PYTHONUTF8",
    "PYTHONSAFEPATH",
)

def build_receipt() -> dict:
    # False avoids setlocale side effects. Record the preference; do not change it.
    return {
        "executable": sys.executable,
        "version": sys.version.split()[0],
        "platform": platform.platform(),
        "utf8_mode": bool(getattr(sys.flags, "utf8_mode", False)),
        "isolated": bool(sys.flags.isolated),
        "preferred_encoding": locale.getpreferredencoding(False),
        "filesystem_encoding": sys.getfilesystemencoding(),
        "stdout_encoding": getattr(sys.stdout, "encoding", None),
        "stdout_errors": getattr(sys.stdout, "errors", None),
        "stdout_isatty": bool(sys.stdout.isatty()),
        "locale_env": {key: os.environ.get(key) for key in WATCHED},
    }

def main() -> None:
    parser = argparse.ArgumentParser(description="Write a redacted interpreter receipt.")
    parser.add_argument("path", nargs="?", default="receipt.json")
    args = parser.parse_args()
    payload = build_receipt()
    canonical = json.dumps(payload, sort_keys=True, separators=(",", ":"))
    payload["receipt_sha256"] = hashlib.sha256(canonical.encode("utf-8")).hexdigest()
    text = json.dumps(payload, indent=2, sort_keys=True) + "\n"
    with open(args.path, "w", encoding="utf-8") as handle:
        handle.write(text)

if __name__ == "__main__":
    main()

What the receipt is allowed to hold

I keep the interpreter path, the version string, and the platform line, because a later patch can target the wrong process.
I keep UTF-8 mode, preferred encoding, filesystem encoding, and the stdout encoding plus its error handler.
I keep a short locale environment, and I leave every other variable out so a token cannot ride along by accident.
I hash the canonical JSON before I attach the receipt hash, so the digest covers the fields and not itself.

Primary references for those fields are the current Python locale and sys docs, plus the PYTHONIOENCODING note. I would re-read them against the exact interpreter named in the version field, rather than trusting a memory of how coercion used to work. A minimal image can still surface an ASCII preference, even when a laptop has been UTF-8 for years. That is why the receipt records live flags instead of assuming a platform default from an old write-up.

Where the free options actually sit

The second copy of this receipt is the run I would put on a free server option. The later explanation is the only prompt I would send to a free model after the file exists. Both are availability claims I was given for MonkeyCode, and I am not assuming a named model or a quota. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

If either free option is down, the notebook does not collapse, because the same script runs on any second host you already trust. Why mention the free path at all, if the script itself does not require that specific vendor? It is a concrete place to put the second receipt when you do not already own a spare box. It is not a reason to skip the comparison, and it is not a promise that the box will last the whole window.

I would copy the receipt script to that host and run it with the same command form I used on the laptop. I would also run one labeled probe that writes a non-ASCII sample, then store both outputs off the box. A remote session can vanish, and a story without the JSON file is not something I would trust tomorrow. I would not retype the script from memory just because the file copy failed in transit.

python3 receipt.py local-receipt.json
# second host, same file bytes, not a script retyped from memory
python3 receipt.py remote-receipt.json
python3 -c 'import sys; sys.stdout.write("field note: café\n")'

That third command is a probe, not a patch I would leave in the shell history as a fix. If it raises UnicodeEncodeError only on the remote side, I can name the split without guessing. If it prints on both sides, I stop blaming encoding and I move my eyes to a different field. I would want the simple story, and the receipt is there to stop me from keeping it anyway.

The comparison I want before hour twelve

I would diff the two JSON files on watched keys, and I would ignore cosmetic ordering because the dump is already sorted. A mismatch on preferred encoding or on stdout encoding is enough reason to block an encode patch. A mismatch on the executable path or the version string is enough to block any patch at all. Matching encodings would tempt me to skip the rest, and that temptation is the hole in this notebook.

python3 - <<'PY'
import json
from pathlib import Path
local = json.loads(Path("local-receipt.json").read_text(encoding="utf-8"))
remote = json.loads(Path("remote-receipt.json").read_text(encoding="utf-8"))
keys = (
    "version",
    "utf8_mode",
    "preferred_encoding",
    "stdout_encoding",
    "stdout_errors",
    "stdout_isatty",
)
for key in keys:
    print(f"{key}: local={local.get(key)!r} remote={remote.get(key)!r}")
PY

Would I treat a matching pair of receipts as proof that the original job is finally healthy? A matching receipt only says the text boundary looks alike, and the original exception can still be a logic bug. The point of the freeze is to stop a text fix from hiding a different failure underneath it. I would still read the exception type before I decide that encoding was the layer involved.

A probe I would run, and then revert

If the remote encoding is ASCII, or stdout errors are strict, the non-ASCII sample is a useful alarm. I would rerun the original command under an explicit mode, and I would keep that rerun labeled as a probe. I would use an explicit UTF-8 mode for that probe, and I would write the new receipt beside the old one. I would not edit application code in that same hour, even if the probe suddenly looks clean.

PYTHONIOENCODING=utf-8:strict python3 receipt.py remote-utf8-probe.json
python3 -X utf8 receipt.py remote-x-utf8.json

If the probe makes the exception vanish, I still would not land scattered encode calls through the codebase. I would record which boundary failed, stdout or a file open, and I would change that boundary on purpose. If the probe changes nothing, a suggestion to encode the string is probably aimed at the wrong layer. I would keep both receipts, because the better-looking run is not the run that originally failed.

A decision table I would not skip

What the receipts show	What a suggestion often says	What I would do in this window
Preferred encodings differ	Call encode with UTF-8 on the value	Reject it. Probe the process mode, then fix the boundary that actually writes.
Encodings match, versions differ	It works on the newer minor	Reject it. I am not scoring the interpreter that failed.
Encodings match, tty flag differs	Add a progress bar or color	Park it. A tty split is a different note, not an encoding patch.
Receipts match, probe still fails	Retry the same call unchanged	Stop asking for style edits. Capture the exception type and the failing call.
Remote file is missing	Recreate the script from memory	Stop. A retyped script is a new tree, so the hash no longer means anything.

The table is a gate, not a scoreboard, and I would not add a row just to make a weak patch look measured. If none of the rows match the receipts in front of me, the honest move is to stop and widen the fingerprint. Would I invent a fifth row in the moment so the hour does not feel wasted on a quiet box? I would write the mismatch in prose instead, and I would leave the table alone until the next window.

What I would expect to break

I am not publishing a count of failures, because this notebook is a procedure rather than a dataset I measured. These are the breaks I would watch for, and the response I would repeat if one of them shows up. None of them requires a named model, and none of them requires the free host to have a particular size. If your run shows a sixth break, write it down, and do not sand it off to match this list.

The remote stdout encoding is ASCII or empty, while the laptop receipt says UTF-8, so the marked sample dies only on the far side.
The file write uses an explicit UTF-8 open, so the file looks fine, and the crash is only the inherited stdout handler.
The remote shell has a C locale, while a later login looks healthy, which means I compared the wrong session entirely.
The model returns a confident wrapper, and the answer never mentions the encoding fields or the receipt hash I pasted.
The free host drops the session before I copy the remote receipt off, so I have a story and no artifact left.
The receipt command wrote to stdout on an ASCII host, so it died, and a UTF-8 file open is the repeat I would keep.

That fourth break is the one I would take as a stop sign, not as a prompt to ask again more nicely. If the explanation does not cite a field from the receipt, why would I let it edit the job? I would rather rerun the probe than accept a patch that could have been written for a different machine. A fluent answer can still be a wrong answer, and fluency is not one of the watched keys.

Questions I would ask before the second day

Before I open the second day, I would ask whether the remote receipt was copied off the host. I would ask whether the probe used the same script bytes as the laptop run did. I would ask whether the suggestion named a watched field, or only renamed the exception in prose. I would ask whether I am about to edit code just because the prompt felt inexpensive.

What I would repeat across the remaining hours

From hour zero to hour two, I would write both receipts, copy them off the remote host, and refuse to open a model prompt.
From hour two to hour eight, I would run the non-ASCII probe, then one explicit UTF-8 probe, keeping the earlier receipt intact.
From hour eight to hour twenty-four, I would ask only with both receipts attached, and reject answers that ignore them.
From hour twenty-four to hour forty-eight, I would repeat the original command once under the chosen boundary, and then I would stop.

I would repeat the reject rule more often than I would repeat the wording of the prompt. Another wording of the same patch is not new evidence, even when it sounds cleaner than the first. A new receipt after a deliberate mode change is new evidence, and it is the only kind I want on the second day. A third suggestion can feel cheap when model access is free, and that feeling is not a reason to continue.

What I would scrub before a prompt

I would remove the platform line if it contains a node name, and I would remove any path that sits under a home directory. The hash can stay, because it lets me detect a later edit without showing the machine that produced it. I would not add command arguments that might contain tokens, even when the failure looks like a simple text error. If I cannot scrub it quickly, I would skip the model step and keep the comparison local for the rest of the window.

Limits, and who should walk away

This approach will not choose the right text contract for your users, and it will not prove that UTF-8 is always correct. Some libraries encode bytes before they ever touch standard output, so a green probe can sit beside a red worker. Windows locale APIs belong in a different notebook, and I would not pretend this POSIX receipt covers that ground. A passing probe is a clue about the boundary, not a release decision for the whole service.

Do not point this script at a full environment dump, and do not paste secrets beside a receipt that was carefully redacted. Free model access and a free server are not a capacity plan, a hardware quote, or a retention guarantee. I was not given a quota or a machine shape, so I would copy artifacts out and keep another host in reserve. If the box is gone at hour forty-seven, the notebook still works only when the JSON files already sit on your laptop.

You should walk away if policy forbids sending even a redacted trace to an external model at all. You should also walk away if the failing stream is binary, because a text probe will lie to you there. You should walk away if you need an audited production image rather than a scratch box for a day. In those cases the receipt script can still run locally, and the model step should stay closed.

If that free server is already the spare box on your account, I would make the receipt the first command there. I would ask the free model nothing until the remote file is sitting on my laptop beside the local one. The article is still useful if you swap in any other second host, and I would rather you do that than skip the freeze. Take the reject rule, leave the vendor out, and the next forty-eight hours still have a usable shape.

My Laptop Spoke UTF-8. The Clean Process Spoke ASCII.

Taylor Wang — Mon, 12 Oct 2026 16:39:09 +0000

I spent the first pass blaming the parser, which feels familiar, and it was the wrong suspect again. The sample was a few UTF-8 bytes plus a line ending, and the same function read it cleanly on my laptop. Why did a clean process, handed that same file, raise UnicodeDecodeError before any parser code had a chance to run? I am writing these notes so I do not land another text-mode read that only works because my shell is polite.

What I thought had broken

I assumed the CSV library had changed, because the traceback sat one frame above the read. Had I upgraded something between yesterday and this morning, or was I staring at an old virtualenv again? I held the interpreter path constant on purpose, since a different sys.executable is a separate note I already published. This time the binary matched, the file bytes matched, and the failure still picked a side.

The next wrong guess was a hidden dependency, so I froze the environment and ran the snippet with nothing else imported. The failure survived that cut, which should have ended the package theory on the spot. I then compared newlines, permissions, and the working directory, and none of those knobs moved the exception. What else was the process inheriting that never shows up in a diff of the source file?

The fact I had blurred

Calling sys.getdefaultencoding() has returned utf-8 for years, and that return value still does not govern open(). Text mode follows the locale encoding unless UTF-8 mode is already on, which you can see in sys.flags.utf8_mode. So a laptop with LANG=C.UTF-8 and a process with LC_ALL=C are not running the same read, even when the snippet looks identical. Are you checking the encoding the file actually used, or the encoding you remember from a tutorial?

Python 3.10 and later can warn on this if you set PYTHONWARNDEFAULTENCODING=1, which is the EncodingWarning from PEP 597, not a change of default. I am not going to claim that a later release flipped that default, because a version rumor is how this class of bug hides. If UTF-8 mode is on, the flag says so, and I trust that flag over any blog date. locale.getencoding() needs 3.11 or newer, so the probe below falls back instead of pretending every host has it.

The probe I would repeat

I wrote a small probe that writes a known UTF-8 sample and then reads it back with no encoding argument. That omission is the bug I want to catch, so the probe fails in the same way a careless helper fails. It also prints the locale variables, the preferred encoding, and the UTF-8 mode flag, because a green read without that context is useless. Would you trust a passing test that never recorded the locale it actually ran under?

"""Bare open() probe. Expected behavior is labeled; this is not a benchmark."""
import json
import locale
import os
import sys
import tempfile
from pathlib import Path

def snapshot():
    info = {
        "executable": sys.executable,
        "version": sys.version.split()[0],
        "default_encoding": sys.getdefaultencoding(),
        "filesystem_encoding": sys.getfilesystemencoding(),
        "preferred_encoding": locale.getpreferredencoding(False),
        "utf8_mode": bool(sys.flags.utf8_mode),
        "lang": os.environ.get("LANG"),
        "lc_all": os.environ.get("LC_ALL"),
        "pythonutf8": os.environ.get("PYTHONUTF8"),
        "pythonioencoding": os.environ.get("PYTHONIOENCODING"),
    }
    if hasattr(locale, "getencoding"):
        info["locale_getencoding"] = locale.getencoding()
    return info

def probe(directory: Path) -> dict:
    path = directory / "sample.txt"
    path.write_bytes("café\n".encode("utf-8"))
    result = {
        "snapshot": snapshot(),
        "read_ok": None,
        "error": None,
        "round_trip": None,
    }
    try:
        # Intentional: no encoding argument. This is the bug under test.
        text = path.read_text()
        result["read_ok"] = True
        result["round_trip"] = text == "café\n"
    except UnicodeDecodeError as exc:
        result["read_ok"] = False
        result["error"] = f"{type(exc).__name__}: {exc}"
    return result

def main():
    with tempfile.TemporaryDirectory() as raw:
        print(json.dumps(probe(Path(raw)), indent=2))

if __name__ == "__main__":
    main()

I save that as locale_open_probe.py and run four commands, changing the environment rather than the source. The first command is my laptop as I actually work. The next two force a UTF-8 locale and a C locale. The last one keeps the C locale and turns UTF-8 mode on, so I can see which switch really healed the read.

python3 locale_open_probe.py
LC_ALL=C.UTF-8 LANG=C.UTF-8 python3 locale_open_probe.py
LC_ALL=C LANG=C python3 locale_open_probe.py
LC_ALL=C LANG=C PYTHONUTF8=1 python3 locale_open_probe.py
PYTHONWARNDEFAULTENCODING=1 python3 -c 'open("sample.txt")'

What broke when only the locale moved

On a glibc Linux user, with UTF-8 mode off, I expect LC_ALL=C to report an ASCII locale such as ANSI_X3.4-1968. I also expect the bare read to raise, because the byte 0xC3 in café is not ASCII. That expectation comes from the locale-dependent default documented for open(), not from a timer and not from a scoreboard. If your C locale still round-trips the file, the test did not fire, so read preferred_encoding before you celebrate a false green.

A second mask showed up when I set PYTHONIOENCODING=utf-8 and left open() alone. Standard streams looked healthy, and the file read still died, which is an easy way to blame the wrong layer. Why would a pipe setting repair a filesystem read that never consulted that variable? I would repeat the probe with that variable both set and unset, and I would keep the two results in the same note.

The fix I would land for files this repo owns is explicit, including newline policy when the bytes matter:

text = path.read_text(encoding="utf-8", newline="")
path.write_text(text, encoding="utf-8", newline="\n")

A second host is not a second opinion

When I want a clean process without building another VM, I borrow MonkeyCode's free server option and run this same probe there. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I do not know that server's image, locale, hardware, quota, or how long the free option lasts, so I will not invent those facts in this note. The useful part is a process whose environment I did not inherit from my laptop shell.

I copy the probe, run the four commands, and diff the JSON keys rather than the prose around them. The keys I actually compare are preferred_encoding, utf8_mode, read_ok, and round_trip. Free model access helps one step later, when I ask for a patch that pins encoding="utf-8" and names the C-locale command. I still drop that patch if it explains the error without a command I can re-run on both hosts.

Decision table I keep next to the probe

What the file is	Encoding I pass	Newline	Why I choose that
Data files this repo owns	`utf-8`	`""` when bytes matter	The locale must not rewrite them
A legacy export already in a code page	The measured locale, named in the log	Default only if I mean translation	Pinning UTF-8 would corrupt it
A human terminal or a pipe	Leave it, or set `PYTHONIOENCODING` knowingly	Not applicable	Forcing UTF-8 can break an ASCII pipe
The test job	`utf-8`, plus a C-locale run of the probe	`""`	The C job is what catches a bare `open()`

What I would repeat before I land the edit

I print the snapshot before I read the traceback, so the locale is evidence instead of a guess.
I run the C locale and the UTF-8 locale back to back, and I keep both JSON blobs in the note.
I treat a model draft as a suggestion, then I re-run the probe on the laptop and on the second host.
I pin encoding="utf-8" for repo-owned text, and I leave a comment when a file is intentionally locale-encoded.
I check PYTHONIOENCODING separately, because a healthy pipe can hide a broken open().
I refuse to call the check done if preferred_encoding never left UTF-8, since the ASCII case never ran.

Who should skip this recipe

You should skip the forced C locale if the files are genuine user documents in a legacy code page, because a UTF-8 pin will damage them. You should also skip a random clean host when production uses a measured locale you have not copied, since a false green is worse than no second run. Windows hosts do not honor LC_ALL=C the way glibc does, so this shell recipe alone will not probe an ANSI code page. Teams that already pass an encoding on every text read still need the warning flag, but they do not need this story.

This note will not catch a CSV dialect bug, a delimiter change, or a hash mismatch in a deployed tree. It will not tell you which model wrote a better patch, and it is not a performance result. macOS builds sometimes keep UTF-8 even under a C locale, and the probe is inconclusive there until the printed encoding actually changes. If round_trip stays true everywhere, I would stop and look at a different layer rather than tighten a rule that never fired.

If you do not already have a spare Linux user where you can flip LC_ALL, MonkeyCode's free server is the second process I would borrow for this probe, and I would still read the JSON before I edited a single call.

48-Hour Field Notes: I Would Quarantine the Suggested Repro Before a Free Server Saw It

Taylor Wang — Mon, 12 Oct 2026 12:59:32 +0000

I keep meeting the same tempting shortcut, and I still do not trust it on sight. A coding model drafts a small patch, and a hosted machine is offered as the place to prove that patch. Would I paste a failing fixture into a box that I do not administer or even fully describe? I would not, until a local oracle exists and a quarantine gate has already passed on my own machine.

These notes are a forty-eight hour protocol, not a claim that I already scored any vendor. Nobody supplied measured runs, model names, quotas, hardware specs, or a promised duration for this account. I am writing the checks I would repeat, and I am labeling every sample below as an unexecuted proposal. If a step needs a number I was never given, I leave that number blank instead of inventing a result.

What I was actually told

The only product facts I will use are two availability claims that were supplied with this assignment. MonkeyCode currently offers free model access, and it also offers a free server option for trying a run. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

I do not know which model names sit behind that access, and I will not invent a lineup to sound precise. I also will not pretend the free box matches my laptop, because nobody gave me an image bill of materials. Availability is not the same thing as fitness, so the rest of this note is about fitness checks I can actually perform.

Hour 0 to 8: build the oracle before the prompt

Why would I ask a model to explain a failure that I cannot yet reproduce on my own machine? I would start from a tiny local test that fails for one named reason and prints a short message. That test should live in the repository, use pinned dependencies, and avoid every private fixture I own. Only after that red result would I ask a free model for a draft, and I would not treat the draft as evidence.

The sample below is only a proposal, and I have not executed it for this account or any hosted box. It exists so the later decision table has a concrete file to point at when the choice gets fuzzy. You should replace the function with your own bug, and you should keep the assertion text stable on purpose. If you cannot write even this small red test, a hosted rerun will not teach you what actually failed.

# proposed/test_budget_gate.py
# Unexecuted example. Run it locally before any hosted attempt.

def remaining(limit: int, spent: int) -> int:
    if spent > limit:
        raise ValueError("spent exceeds limit")
    return limit - spent

def test_remaining_rejects_overspend():
    try:
        remaining(10, 11)
    except ValueError as exc:
        assert "spent exceeds limit" in str(exc)
        return
    raise AssertionError("overspend was accepted")

if __name__ == "__main__":
    test_remaining_rejects_overspend()
    print("local oracle: red path exercised")

I would run that file with the interpreter I actually ship, not with a version I merely hope the server has. A green local run means the oracle itself is wrong, so I would stop and rewrite the assertion before continuing. A red local run is the only ticket that lets a model draft exist, and it is still not permission to upload anything.

python3 --version
python3 -m pip freeze > proposed/local-freeze.txt
python3 proposed/test_budget_gate.py

How I would talk to the free model

I would paste only the red assertion message and the function under test, not the rest of the repository. The prompt would ask for a patch against that function, and it would forbid any edit to the test file. If the reply touches the test anyway, I would discard it before the free server ever starts. A free model is a draft source in this protocol, not a judge of whether the bug is actually gone.

Hour 8 to 18: quarantine the bundle

Would a free server be convenient for a second observation after the local red test already exists? Yes, and that convenience is exactly why the uploaded bundle needs a quarantine gate before it leaves the laptop. I would copy only the test, the draft, and a lockfile into a fresh directory that has never held secrets. I would not copy dotenv files, shell history, cloud credentials, or production logs into that directory under any excuse.

If the failure appears only when private data is present, this hosted path is the wrong tool and I would stop. A scanner cannot prove a bundle is safe, but it can catch obvious token shapes before I get careless. I would rather fail the gate on a false positive than explain how a real key crossed onto a machine I do not own. The gate is allowed to be boring, because boring is what I want when the alternative is a leaked credential.

# proposed/quarantine_scan.py
# Unexecuted proposal. It flags shapes; it does not certify safety.
import pathlib, re, sys

PATTERNS = [
    re.compile(r"AKIA[0-9A-Z]{16}"),
    re.compile(r"-----BEGIN (?:RSA |OPENSSH |EC )?PRIVATE KEY-----"),
    re.compile(r"(?i)(api[_-]?key|secret|token)\s*[:=]\s*\S+"),
]

root = pathlib.Path(sys.argv[1])
hits = []
for path in root.rglob("*"):
    if not path.is_file() or path.stat().st_size > 200_000:
        continue
    text = path.read_text(errors="ignore")
    for pattern in PATTERNS:
        if pattern.search(text):
            hits.append(f"{path}: matched a blocked pattern")
if hits:
    print("quarantine failed")
    print("\n".join(hits))
    sys.exit(2)
print("quarantine passed: no blocked patterns in bundle")

mkdir -p proposed/bundle
cp proposed/test_budget_gate.py proposed/bundle/
cp proposed/local-freeze.txt proposed/bundle/
python3 proposed/quarantine_scan.py proposed/bundle

What the scanner will not catch

A pattern list misses secrets that do not look like the samples I typed, including short passwords and private URLs. I would still review the bundle by eye, because automation is only the first gate and not the last one. Would I upload a binary, a database dump, or a notebook that still holds cached outputs? I would not, since those files hide strings that a simple line scanner can easily skip.

A decision table I would keep beside the keyboard

I would keep a small decision table beside the keyboard so I do not negotiate with myself at the moment of upload. Each row asks for a fact I can check locally, and each row refuses a hosted run when that fact is missing. Would I skip a row because the free server is already waiting and the draft looks pleasantly short? I would not, because a short draft can still weaken a test or smuggle a credential-shaped string into the bundle.

Question I can answer locally	If the answer is yes	If the answer is no
Do I have a red test without private data?	A free model may draft a patch.	Stop. Do not outsource the fixture.
Did the quarantine scan exit clean?	A free server may run that bundle only.	Delete the bundle and stay local.
Can I name the interpreter and lockfile?	Record both in the run note.	The hosted result cannot be compared.
Does the draft leave the assertion untouched?	It may be tried on the free server.	Reject it before any remote run.
Do I need a quota, SLA, or named model?	This protocol is insufficient.	The two availability claims are enough to try.

Hour 18 to 36: what I expect to break

I would assume the first hosted run disagrees with my laptop, and I would write the disagreement down before I theorize. A different patch level, a missing system library, or an unexpected working directory can all flip a tiny assertion. Would I then blame the model because the free server printed red while my laptop had failed for another reason? I would not, until I had compared the package set, the working directory, and the exact command line.

I would also watch for a quieter failure, which is a draft that passes only by editing the assertion text. If the hosted log is green and the local oracle file is no longer the same file, that green log is noise. I would diff the test before I diff the implementation, because that order stops me from celebrating a weakened check. A second environment is useful only when both sides ran the same question, not a quietly rewritten question.

python3 --version | tee proposed/host-version.txt
diff -u proposed/local-freeze.txt proposed/host-freeze.txt || true
diff -u proposed/test_budget_gate.py proposed/bundle/test_budget_gate.py

# proposed/run-note.md
# Template only. Fill it after a real run. Do not invent the blanks.
local_interpreter:
local_exit:
bundle_scan_exit:
host_interpreter:
host_exit:
test_file_diff: unchanged | changed
decision: repeat | stop

Hour 36 to 48: what I would repeat

The last twelve hours are for deciding what I would repeat, not for polishing a story about a tool. I would keep the local red test in version control before I asked any model for a suggested patch. I would send the smallest bundle that still fails, and I would scan that bundle once more before upload. I would record interpreter, lockfile hash, command, and exit code for the laptop and for the hosted run.

I would keep the failing test in version control before any model is allowed to suggest a patch.
I would scan the upload bundle after the copy step, not before, so the scan sees the real files.
I would compare package freeze files before I interpret a green or red result from the hosted run.
I would stop the protocol when the fixture needs private data, even if the free server is idle.

I would reject any draft that changes the assertion text unless a separate review explains why the question changed. I would treat a free server result as a second observation, never as the only oracle I am willing to trust. The repeatable part of this protocol is the split between drafting and running, not a particular vendor screen. Free model access is useful when I want a draft without opening a paid console or inventing a lineup of names.

A free server is useful when I want a second environment and I can afford to throw the whole bundle away. Neither option replaces the local test that told me the bug was real before any hosted machine was involved. Would I repeat the hosted run if the test file diff was not empty and the assertion had moved? I would not, because that rerun would be answering a different question than the one I started with.

Limits, and who should skip this

This protocol does not measure latency, answer quality, uptime, or how long either free option remains available. I was not given quotas, regions, image digests, or a support commitment, so I will not imply any of those facts. Please re-check the vendor's current documentation before you rely on availability, because a free tier can change. If your fixture contains customer data, keys, or regulated records, do not use the hosted path in any form.

You should also skip this approach when you need an attested build, a signed SBOM, or a formal benchmark against another assistant. A forty-eight hour field note cannot give you that evidence, and I will not dress a checklist up as a study. Teams that already have a sealed CI runner should keep using that runner for anything they might ship. I would rather lose one convenient rerun than explain how a production token left a laptop in a hurry.

If you already hold a local red test and a bundle that passed the quarantine scan, a bounded trial is reasonable. I would use the free model only to draft, and I would use the free server only as that second observation. That is the whole invitation I am willing to make, and it is still your call whether the paste is worth it. If either gate is missing, I would close the tab and stay on the machine I already know how to wipe.

48-Hour Field Notes: A One-Line Add Looked Harmless. The Clean Install Disagreed.

Taylor Wang — Mon, 12 Oct 2026 09:31:15 +0000

I opened the weekend convinced the function change was the entire defect, because every local test stayed green. The patch added one bare dependency and a short import guard, which is exactly the sort of diff I stop reading. Have you ever merged a harmless requirements line and then watched a clean machine disagree with your laptop? That disagreement is the failure I want written down before I trust the next one-line dependency add.

What I tried before I touched the server

I applied the suggestion inside my existing virtualenv, reran the unit tests, and treated the green run as permission to stop. The new requirements line held only a project name, with no version, no hash, and no comment about why it existed. I assumed the public index would hand me the same tree tomorrow, which is a comfortable assumption and a poor one. Why would a package index owe me yesterday's resolution just because my notebook can still import the name?

I then asked for a second reading of the diff, using MonkeyCode's free model access only as a reviewer.

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

I use that access to pressure-test the wording of a diff, not to choose what the index should resolve. I use the free server option when I want a machine that does not already contain leftover site-packages. I do not treat either option as a promise about model names, quotas, hardware, or how long the offer stays up. The second reading did not produce a lockfile, and that silence was more useful than another confident import.

A model can sound sure about a name while knowing nothing about the index state on the day you install. If I let that confidence land in git, whose resolution am I actually committing, mine or the index's next upload? I would rather have an awkward question in the notes than a quiet dependency edit in the diff.

What broke after the clean install

On the second morning I cloned that same commit onto a fresh server and installed from the bare requirements file. The import that had passed locally failed there, because the resolver selected a different build than the one on my laptop. I blamed the function text for an hour before I compared the two freeze snapshots and saw the extra package drift. Have you noticed how quickly a green laptop becomes an alibi for a dependency you never pinned?

Three things were already true before I opened the traceback, and none of them lived in the function I kept rereading.

My local virtualenv already held a transitive pin that the fresh server had never been given a chance to see.
The requirements line named a project and trusted the index to define the word current at whatever hour I installed.
I had no committed record of the index URL, the install timestamp, or the Python version sitting beside that diff.

The function change was boring once I stopped defending it, and the unpinned add was the commit I should have reviewed.

How I misread the traceback

The traceback named the import line, so I spent the next hour editing that guard as if the name itself were wrong. Was the name wrong, or was I looking at a module that existed only because my laptop had installed it last month? I almost pasted a version pin from the chat, which would have frozen a guess instead of a recorded install. That is the loop I would not repeat, because a suggestion can name a version it has not just installed.

Forty-eight hours here is my review window, not a claim about how long a free server remains available. I would rather lose an afternoon on a clean install than spend it arguing with a traceback from a dirty one. Would you keep the chat open and hope the index stays still, or would you write the freeze down while the environment still exists?

The audit I would rerun

I do not want another paragraph of intent in the pull request when a small file can record what the installer actually did. I want an audit I can run before I accept a dependency edit from any assistant, including a session that used free model access. The script below is a worked example you can copy, not a benchmark, and it stays inside the Python standard library on purpose. If you paste it into a repository, treat the index URL as a placeholder and point it at the index you really use.

Record the card

#!/usr/bin/env python3
"""Label: worked example, not a measured production run."""
import argparse
import hashlib
import json
import platform
import sys
from datetime import datetime, timezone

def freeze_lines():
    lines = []
    for raw in sys.stdin:
        line = raw.strip()
        if line and not line.startswith('-e '):
            lines.append(line)
    return lines

def main():
    parser = argparse.ArgumentParser(
        description='Record a resolver card from pip freeze on stdin.'
    )
    parser.add_argument('--index-url', required=True)
    parser.add_argument('--out', default='resolve-card.json')
    args = parser.parse_args()
    lines = freeze_lines()
    blob = '\n'.join(sorted(lines)).encode('utf-8')
    card = {
        'recorded_at': datetime.now(timezone.utc).isoformat(),
        'python': sys.version.split()[0],
        'implementation': platform.python_implementation(),
        'platform': platform.platform(),
        'index_url': args.index_url,
        'frozen_count': len(lines),
        'frozen_sha256': hashlib.sha256(blob).hexdigest(),
        'frozen': lines,
    }
    with open(args.out, 'w', encoding='utf-8') as handle:
        json.dump(card, handle, indent=2)
        handle.write('\n')
    digest = card['frozen_sha256'][:12]
    print('wrote', args.out, 'count=' + str(card['frozen_count']), 'sha=' + digest)

if __name__ == '__main__':
    main()

python -m venv .venv
. .venv/bin/activate
python -V
python -m pip --version
python -m pip install -r requirements.txt
python -m pip check
python -m pip freeze | python tools/resolve_card.py \
  --index-url "https://pypi.org/simple" \
  --out resolve-card.json

I run python -V and python -m pip --version first so the card is not the only place the interpreter can surprise me. pip check will not catch an unpinned future install, but it will tell me whether the tree I just created is already inconsistent. The freeze piped into the script is the snapshot I diff later, and I keep that JSON beside the notes.

On Windows I would run the Scripts activate file, and I would still call pip as python -m pip so the interpreter stays obvious. Replace the example index URL if your project uses a mirror, because a card from the wrong index is a false match. I would rather fail the audit on a wrong URL than explain a hash mismatch that was only a mirror lag.

Compare two cards

On the free server I would run those same commands in a new checkout, then diff the two JSON cards. I would not ask the model to remember the previous freeze, because a chat transcript is a weak place to store a hash. A file committed next to the patch is a better memory than a window I might close, isn't it?

#!/usr/bin/env python3
"""Label: comparison helper. Unexecuted until you pass two real cards."""
import json
import sys

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

def main():
    if len(sys.argv) != 3:
        print('usage: compare_cards.py LEFT.json RIGHT.json', file=sys.stderr)
        return 1
    left, right = load(sys.argv[1]), load(sys.argv[2])
    mismatched = False
    for key in ('python', 'index_url', 'frozen_sha256'):
        same = left.get(key) == right.get(key)
        print(key + ':', 'match' if same else 'DIFF')
        if not same:
            mismatched = True
            print('  left=' + str(left.get(key)))
            print('  right=' + str(right.get(key)))
    return 2 if mismatched else 0

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

python tools/compare_cards.py laptop.resolve-card.json server.resolve-card.json
echo "exit=$?"

The helper exits with status 2 when the frozen hashes differ, so a shell script can stop before I open the editor. I still read the printed lines, because a Python version mismatch can hide behind a hash that happened to match. If the index URLs differ, I treat the comparison as void and rerun both installs against the same index.

A decision table rather than a vibe

I keep a short table in the notes so I do not renegotiate the rule every time a suggestion sounds small. Would a docs-only change deserve this much friction, or am I protecting the one class of edit that rewrites the world? The table is the artifact I would paste above the script output, so the rule survives after I close the chat.

Signal	What I do	What I refuse
Requirements line has no pin or hash	Stop and generate a lock or a hashed requirements file	Merging because local tests passed
Two clean installs disagree on frozen_sha256	Keep the patch unmerged and pin the known-good set	Blaming the function diff first
Model suggests a new dependency	Ask it to explain the import, then record the card myself	Treating the suggestion as the resolution
Card is missing Python version or index URL	Rerun the audit before anyone reviews the traceback	Assuming the laptop and the server match

I would not block a documentation typo with this table, because no installer runs when the diff never touches dependencies. I would block a one-line dependency add that arrived from a chat window until the second card matches the first card. If the hashes diverge, the function diff can wait, since arguing about a traceback before the trees match wastes the hour.

What I would repeat on the next patch

The order matters more than the particular tool, and I would repeat that order even if I swapped the installer later.

Create the environment on the clean server first, before I reread the suggested function and start defending it.
Install only from the committed requirements or lock, and write the index URL into the card beside the timestamp.
Save one card from the laptop and one card from the fresh server, then diff the hashes before any review comment.
Let the model critique the diff only after both cards exist, and discard advice that cannot point at those files.
If the hashes diverge, pin or hash the dependency set and rerun both installs before I talk about the traceback.

The free server matters because it does not inherit my site-packages, and a clean failure is more honest than a dirty pass. The free model access matters because a second reading is cheap, not because the model has seen today's index state. Neither option selects a version for me, and neither option should be described as a permanent lab or a private mirror.

Limits, and who should skip this

This checklist does not prove that a package is safe, maintained, or free of yanked releases after you recorded the card. It does not replace a lockfile with hashes, a private index, or a separate review of license and security advisories. If your installer is Poetry, PDM, or uv, keep that tool's lock and treat the card as a cross-check rather than a rival. Do not run the audit against a production host, and do not paste secrets into the card, the shell history, or the prompt.

You should skip the approach if you cannot get a truly clean environment, because a fresh shell on a dirty image will lie. You should also skip it when the change does not touch dependencies, interpreters, system packages, or install flags at all. A floating pin is a process bug, and a model that agrees with my hurry is not a second engineer on the review.

The script ignores editable installs and does not verify hashes, so a matching count can still hide a different artifact. pip freeze records what was installed, not every marker or environment option that influenced the resolver. If you need a stronger gate, move to a lockfile that your installer can reproduce, and keep this card as the witness.

If you already open MonkeyCode for a second reading, point the free model at the diff and the free server at the install. Keep both cards next to the patch, because those notes are the part I would still trust on the following morning. I would stop there, rather than asking the model to invent a pin it cannot show me inside either card.

I Would Not Land the Edit Until the Server Tree Shared My Hash

Taylor Wang — Mon, 12 Oct 2026 02:23:14 +0000

I spent two days chasing a failing command, and the tempting shortcut was to let a model rewrite the file. Why would I keep hand-editing a small parser when a free model could draft the change? The trouble started when the server copy and my laptop copy stopped being the same tree. Treat the notes below as a worked failure you can reproduce, not as a measured outage report.

The failure I kept blaming on the edit

The command was small, and that smallness made the miss much easier to excuse at first. I ran a Python check, watched it fail, and asked for a unified diff instead of a full rewrite. The diff looked tidy, applied on my laptop, and still failed after I copied those names into a clean directory. Have you ever watched a green local apply turn red the moment the tree was copied elsewhere?

What broke was not a clever parser bug hiding inside the project I was trying to fix. The server job started from a slightly older checkout, so matching context lines still let the patch land. I had treated a successful apply as proof that both sides still shared one unchanged tree. They did not share that tree, and the original failing exit code was never stored beside the diff.

I also let the afternoon sprawl across three places that never pointed back at each other. Notes lived in the chat, the patch lived in my editor, and the failing command lived only in shell history. Which of those three would still be trustworthy if I opened the same ticket tomorrow morning? None of them formed a bundle I could hash, copy, and run again without guessing at the missing context.

What I would freeze before a model sees the tree

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

I looked at MonkeyCode because free model access and a free server option were confirmed for this workflow. That availability is enough to try a bounded repro, and it is not a reason to skip a hash. I am not naming a model, a quota, a machine size, or a promise that the free option stays fixed. If those terms matter to the job you are running, read the current product docs before you depend on them.

The receipt I started requiring is deliberately dull, which is the compliment I want from a gate. It holds relative paths, a sha256 for each file, one hash of that sorted list, and the exact command. It also holds a slot for the diff, saved beside the receipt rather than pasted into a scrolling chat. A free server is useful when that receipt is the whole job, not a memory of yesterday's disk.

Would I send a prompt that only says fix the tests, with none of those fields filled in? Not after I watched the wrong function change while the apply command still reported a clean success. The model can still suggest a bad edit, but at least I can prove which tree it was answering. If the hash differs, I stop the review, and I do not negotiate with a diff that lost its tree.

The gate I would run before apply

The script below is a local gate I would run before any remote apply, including a free server job. It copies the receipt files into a temp directory, checks the diff, applies it there, and runs the recorded command. I am not publishing timing numbers for it, because a correctness gate does not need a leaderboard to be useful. Read it as a proposal you can execute, then decide whether the refusal messages match the risk you actually carry.

#!/usr/bin/env python3
"""Temp-copy apply gate for a unified diff against a frozen tree receipt.

Unexecuted proposal: run this on a toy repo before any remote apply.
It does not call a network service, and it does not print a benchmark.
"""

from __future__ import annotations

import argparse
import hashlib
import json
import shlex
import shutil
import subprocess
import tempfile
from pathlib import Path


def sha256_file(path: Path) -> str:
    digest = hashlib.sha256()
    digest.update(path.read_bytes())
    return digest.hexdigest()


def tree_hash(files: list[dict]) -> str:
    lines = [f"{item['sha256']}  {item['path']}" for item in files]
    payload = "\n".join(lines).encode("utf-8")
    return hashlib.sha256(payload).hexdigest()


def build_receipt(root: Path, rels: list[str], command: list[str]) -> dict:
    files = []
    for rel in sorted(rels):
        path = root / rel
        if not path.is_file():
            raise SystemExit(f"missing file: {rel}")
        files.append({"path": rel, "sha256": sha256_file(path)})
    return {
        "command": command,
        "files": files,
        "tree_sha256": tree_hash(files),
    }


def assert_same_tree(root: Path, receipt: dict) -> None:
    names = [item["path"] for item in receipt["files"]]
    current = build_receipt(root, names, receipt["command"])
    if current["tree_sha256"] != receipt["tree_sha256"]:
        raise SystemExit("tree hash mismatch; refuse the diff")


def apply_in_copy(root: Path, receipt: dict, diff: Path) -> int:
    with tempfile.TemporaryDirectory(prefix="apply-gate-") as tmp:
        dest = Path(tmp) / "tree"
        dest.mkdir()
        for item in receipt["files"]:
            target = dest / item["path"]
            target.parent.mkdir(parents=True, exist_ok=True)
            shutil.copy2(root / item["path"], target)
        subprocess.run(["git", "init", "-q"], cwd=dest, check=True)
        checked = subprocess.run(
            ["git", "apply", "--check", str(diff)],
            cwd=dest,
            text=True,
            capture_output=True,
        )
        if checked.returncode != 0:
            detail = checked.stderr.strip() or "git apply --check failed"
            raise SystemExit(detail)
        applied = subprocess.run(
            ["git", "apply", str(diff)],
            cwd=dest,
            text=True,
            capture_output=True,
        )
        if applied.returncode != 0:
            detail = applied.stderr.strip() or "git apply failed"
            raise SystemExit(detail)
        completed = subprocess.run(receipt["command"], cwd=dest)
        return completed.returncode


def main() -> None:
    parser = argparse.ArgumentParser(description="Freeze a tree, then gate a diff.")
    parser.add_argument("--root", type=Path, required=True)
    parser.add_argument("--receipt", type=Path, required=True)
    parser.add_argument("--write", action="store_true")
    parser.add_argument("--files", nargs="*")
    parser.add_argument("--command", default="")
    parser.add_argument("--diff", type=Path)
    args = parser.parse_args()

    if args.write:
        if not args.files or not args.command.strip():
            raise SystemExit("write mode needs --files and --command")
        command = shlex.split(args.command)
        receipt = build_receipt(args.root, args.files, command)
        text = json.dumps(receipt, indent=2) + "\n"
        args.receipt.write_text(text, encoding="utf-8")
        print(receipt["tree_sha256"])
        return

    receipt = json.loads(args.receipt.read_text(encoding="utf-8"))
    assert_same_tree(args.root, receipt)
    if args.diff is None:
        print("tree ok", receipt["tree_sha256"])
        return
    code = apply_in_copy(args.root, receipt, args.diff)
    if code != 0:
        raise SystemExit(f"recorded command exited {code}; do not land the diff")
    print("apply ok", receipt["tree_sha256"])


if __name__ == "__main__":
    main()

A receipt written by that script looks like the placeholder below, with real digests filled only after you run it. Do not paste these stand-in strings into a ticket and pretend they prove anything. The shape is the useful part, and the hashes are evidence only when the script just printed them.

{
  "command": ["python3", "-m", "unittest", "test_parse.py"],
  "files": [
    {"path": "parse.py", "sha256": "filled-by-the-script"},
    {"path": "test_parse.py", "sha256": "filled-by-the-script"}
  ],
  "tree_sha256": "filled-by-the-script"
}

What the script refuses to do

The script refuses three quiet failures that a long chat window will happily ignore until review. It exits when a receipt file is missing, when the tree hash moved, or when the apply check rejects context. It also exits when the recorded command fails inside the temp copy, which is the result I used to shrug off. It will not open a network connection, choose a model, or decide that a product offer is still valid this week.

Commands I would keep in the ticket

Create a throwaway directory so the check has a real worktree, not a pile of unnamed loose files. Copy only the files named in the receipt, write that receipt, and only then ask for a patch. The commands below are the ones I would repeat on the next failure, and they do not depend on a vendor CLI. If your tool cannot emit a unified diff, stop there, because this gate has nothing safe to apply.

mkdir -p /tmp/replay-demo
git init -q /tmp/replay-demo
cp parse.py test_parse.py /tmp/replay-demo/
python3 replay_gate.py --root /tmp/replay-demo --receipt /tmp/receipt.json --write --files parse.py test_parse.py --command "python3 -m unittest test_parse.py"
python3 replay_gate.py --root /tmp/replay-demo --receipt /tmp/receipt.json --diff /tmp/suggested.diff

Notice that the recorded command runs inside the temp copy, not against the only folder you care about. That split is the whole point, because a model diff should have to earn its way back onto the branch. Why give a generated patch write access to the original tree before a second process has exited zero? I made that mistake on the first afternoon, and the clean directory is what finally made the drift obvious.

How I decide whether the edit may land

I keep a short table in the ticket so the next choice is mechanical instead of hopeful. The rows are not a scoring rubric for models, and they are not a claim about which host is faster. They only answer whether this particular diff may touch the branch that other people will pull. If a row says refuse, I refuse, even when the patch reads like something I would have typed.

What I see	What I do next	What I refuse
Receipt hash matches, apply check passes, and the temp command exits zero	Keep the diff as a candidate for the branch	Landing it on a server tree I have not rehashed
Apply check passes, but the recorded command still fails	Save the log beside the receipt and stop	Asking for another diff against a dirty tree
Tree hash mismatches before any apply	Rebuild the receipt from the tree I will run	Saying the files are probably the same
Diff touches a path that the receipt never listed	Add that path and rehash, or reject the diff	Applying extra files the server never received

The row I violated first was the mismatch row, and it did not look dramatic while I was tired. The filenames matched, the patch applied, and I told myself the extra blank line could not matter. Could a blank line move a context match into the neighboring function and still look successful? Yes, and that is why the receipt hash is stricter than my memory of what I uploaded.

Where the free server fits

I would use the free server as a clean room, not as a second laptop that remembers yesterday. I would place only the receipt files there, run the same command, and compare that exit code with the temp copy. If I also use free model access, I ask only for a unified diff against those exact paths. That diff goes back through the gate, and it does not get applied on a long-lived machine first.

Is a free seat a reason to skip the temp copy and trust the remote edit directly? I do not think so, even when the second run costs nothing and the queue looks empty. Free access can lower the cost of repeating a command, not the cost of a wrong shared edit. Availability is not the same thing as a captured tree, which is the mistake I kept repeating after lunch.

What I would repeat on the next failure

The next failure does not need a new theory, because the useful part was already visible on day two. I would repeat the same five moves, and I would write them into the ticket before I open a chat. Would I change the order just because a model answered quickly and sounded sure of the patch? No, speed is not evidence that the uploaded bytes still match the receipt I hashed locally.

Freeze the named files and the exact command into a receipt before I write any prompt.
Run the local gate first so a bad diff dies inside a temp directory instead of my branch.
Repeat that command on the free server only after the receipt hash matches the uploaded files.
Accept the diff as a candidate only when both runs exit with the same recorded code.
If either side drifted, rebuild the receipt instead of editing the prompt to hide the miss.

That list is the part I would tape above the editor, because the model suggestion is optional and the hash check is not. If the free server is busy, offline, or no longer offered on the terms I expected, the local gate still stands alone. I would rather lose a convenient second machine than land an edit I cannot replay from the receipt. Have you kept a green apply and lost the command that was supposed to justify it?

Who should skip this gate

Skip this gate when the change is a binary asset, a huge generated lockfile, or a rename across half the repository. A context diff gets clumsy there, and a sha256 receipt will not tell you whether a migration is wise. Also skip it when you cannot name the command that should pass after the edit lands. A clean apply with no command behind it is only a text merge, and I already know how those lie.

Do not use a free seat as a drawer for secrets, production dumps, or customer data just because the seat exists. A tiny parser and a fake failing test are enough to learn the habit without dragging private material along. If your policy forbids sending source to an external model, run the gate on diffs you wrote yourself. The hash check still earns its place in that case, and the model can stay out of the loop entirely.

What I still will not invent

I still do not know how long any free server offer remains, or which model names sit behind it today. I also do not know the quota, the hardware, or the duration you will see when you open the product. Those facts go stale quickly, so inventing them here would make this note less honest than the gate it describes. Check the current MonkeyCode docs, and if the docs disagree with this note, trust the docs.

If you already hash the files you meant to upload, borrow one extra step from this weekend. Take one failing command you already understand, and run it through the temp-copy gate before a generated diff touches the branch. That is the only practice I would bother repeating, and it stays useful even if you never open the free seat. The seat can make the second run cheaper, but the receipt is what tells you the second run was the same tree.

I Deleted Free From the Card and the Failure Picked a Side

Taylor Wang — Sun, 11 Oct 2026 19:43:52 +0000

I would open the notebook when a helper check fails and the only saved label is the word free. Had the suggestion drifted, or had the machine that ran the assertion changed underneath the same command? I could not answer either question from a log that says free, which means that log is a story. These notes are the forty-eight hour plan I would follow before I trust that kind of story again.

This notebook is a plan and a local recorder, not a measured study and not a quota report. If you need latency numbers, hardware names, or a ranked model list, you should stop here and go read primary docs. I would rather leave a field blank than borrow a number I did not print myself. Would you really ship a green check when the note cannot name the path that produced it?

Hours 0 to 12: one flag felt like enough

During the first half day I would write a helper that drafts a review comment and then runs one fixture test. My first sketch would use a single function called run_free, because both steps feel unpaid and therefore identical. That shortcut is the bug I already understand, even before I execute anything on a second machine. Can one boolean describe a model route and a server route without throwing away the diagnosis?

Hours 12 to 24: the replay could not choose a cause

On the second block of hours I would replay the same fixture and compare the two notes side by side. A different comment might mean the suggestion path answered differently than it did in the morning. A missing tool might mean the execution path was not the laptop I used when I wrote the fixture. If both explanations fit the same log line, I have not debugged anything, I have only renamed the confusion.

The split I would write down before hour thirty

Free model access means I may request a suggestion without paying for that request, under limits I still have to read. A free server option means I may run a job on a hosted machine without paying for that machine, under separate limits. I am taking those two availability claims as given for this exercise, and I am not treating them as a measurement. I still need the provider's current documentation before I treat either path as present on my own account.

Disclosure: This article was prepared as part of MonkeyCode's product outreach. I am using MonkeyCode only as the hosted example for those two choices, and I am not adding model names or hardware claims. If your account does not show one of those options, the card should store unavailable instead of a hopeful synonym. Would you rather pause the run than invent a path name just to keep the script moving?

Fields the card must answer

Keys I would require

I would keep each attempt in its own JSON file so a later diff cannot quietly overwrite the morning. The file has to answer a small set of questions before I allow myself to read the suggestion text. Boring keys are the point, because a clever schema is how I smuggle assumptions back into the note. Which of these could I still explain on Friday without reopening the chat that produced them?

suggestion_path: local, hosted-free-model, unused, or unavailable, and never the bare word free
execution_path: local, hosted-free-server, unused, or unavailable, chosen independently of the suggestion
provider_label: the label the tool printed, copied verbatim, or unreported when the tool stayed silent
command: the exact check I asked the execution path to run, stored as an argument list
started_at: a UTC timestamp from the machine that wrote the card, not a time I remembered later
exit_code: an integer, or null when the command never started because the card refused the paths
notes: one sentence about what I expected to learn, written before I look at the diff

Extras I would ban

I would also ban three tempting extras, because this notebook cannot honestly support any of them. No guessed model nickname, no pasted quota, and no hardware description belongs in the file. If the tool prints nothing, the provider label is unreported, which is a recorded fact rather than a hole. A hole invites me to fill it later from memory, and memory is how the word free returned last time.

The recorder I would run before I trust the note

The script below is a proposal you can run on your laptop, and it does not call a vendor API. I have not treated its output as a benchmark, and you should not paste its card into a status report as one. It refuses unknown path names, and it refuses unavailable, so a missing option cannot be blurred into local. I would store it as tools/path_card.py and aim it only at a fixture command I already trust.

#!/usr/bin/env python3
"""Write a two-path run card. Proposal: run locally; do not treat the file as a study."""

import argparse
import json
import subprocess
import sys
from datetime import datetime, timezone
from pathlib import Path

ALLOWED = {
    "local",
    "hosted-free-model",
    "hosted-free-server",
    "unused",
    "unavailable",
}

def parse_args():
    parser = argparse.ArgumentParser(
        description="Record suggestion path and execution path as separate fields."
    )
    parser.add_argument("--suggestion-path", required=True)
    parser.add_argument("--execution-path", required=True)
    parser.add_argument("--provider-label", default="unreported")
    parser.add_argument("--command", nargs="+", required=True)
    parser.add_argument("--out", default="run-card.json")
    parser.add_argument(
        "--dry-run",
        action="store_true",
        help="Write the card without starting the command.",
    )
    return parser.parse_args()

def require_known(name, value):
    if value not in ALLOWED:
        raise SystemExit(f"{name} must be one of {sorted(ALLOWED)}, got {value!r}")

def main():
    args = parse_args()
    require_known("suggestion_path", args.suggestion_path)
    require_known("execution_path", args.execution_path)
    if "unavailable" in (args.suggestion_path, args.execution_path):
        raise SystemExit("unavailable path; refusing to blur it into local or unused")
    if args.suggestion_path == "unused" and args.execution_path == "unused":
        raise SystemExit("both paths are unused; refusing to write an empty card")
    if args.suggestion_path == "hosted-free-server":
        raise SystemExit("suggestion_path cannot take a server role")
    if args.execution_path == "hosted-free-model":
        raise SystemExit("execution_path cannot take a model role")
    if args.suggestion_path == "local" and args.execution_path == "local":
        print("note: both paths are local; that is allowed, and it is not a hosted run")
    started = datetime.now(timezone.utc).isoformat()
    exit_code = None
    stdout, stderr = "", ""
    if not args.dry_run:
        completed = subprocess.run(args.command, text=True, capture_output=True)
        exit_code = completed.returncode
        stdout, stderr = completed.stdout, completed.stderr
    card = {
        "suggestion_path": args.suggestion_path,
        "execution_path": args.execution_path,
        "provider_label": args.provider_label or "unreported",
        "command": args.command,
        "started_at": started,
        "exit_code": exit_code,
        "stdout_tail": stdout[-400:],
        "stderr_tail": stderr[-400:],
        "dry_run": args.dry_run,
    }
    Path(args.out).write_text(json.dumps(card, indent=2) + "\n", encoding="utf-8")
    print(f"wrote {args.out}")
    return 0 if args.dry_run or exit_code == 0 else exit_code or 1

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

A check that rejects the bare word

Before I trust the longer script, I would run this classifier in a Unix shell, with no network and no fixture file. The word free is intentionally absent from the allowed set, so a lazy label fails in the open. A swapped role fails too, because a server path must not pretend to be the suggestion path. If this check ever starts accepting free, the rest of the notebook has already lost the point.

python3 - <<'PY'
allowed = {
    "local",
    "hosted-free-model",
    "hosted-free-server",
    "unused",
    "unavailable",
}

def classify(suggestion, execution):
    if suggestion not in allowed or execution not in allowed:
        return "reject-unknown"
    if suggestion == "hosted-free-server" or execution == "hosted-free-model":
        return "reject-swapped-role"
    if "unavailable" in (suggestion, execution):
        return "reject-unavailable"
    if suggestion == "unused" and execution == "unused":
        return "reject-empty"
    if suggestion == execution:
        return "named-pair-same"
    return "named-pair-split"

assert classify("free", "local") == "reject-unknown"
assert classify("hosted-free-model", "unavailable") == "reject-unavailable"
assert classify("hosted-free-server", "local") == "reject-swapped-role"
assert classify("unused", "hosted-free-server") == "named-pair-split"
assert classify("hosted-free-model", "hosted-free-server") == "named-pair-split"
print("path split checks passed")
PY

Refusal, then a named local pair

I would prove the refusal before I prove the happy path, because a soft recorder is just a diary. These commands stay on one machine, and they do not require a hosted login to teach the habit. Watch the exit status, not the prose, since a friendly message can still hide a zero. Did the process actually stop, or did it write a card that flatters an unnamed path?

# Expect a non-zero exit, and expect no new card file afterward.
python3 tools/path_card.py \
  --suggestion-path hosted-free-model \
  --execution-path unavailable \
  --out cards/should-not-exist.json \
  --command python3 -m unittest tests/test_fixture.py

When both paths are intentionally local, I still pass both flags, because silence is not a stored value. The output file should sit under cards, with a unique name, so a refusal cannot leave yesterday's success in place. Replace the example unittest path with a test module you already have, and do not invent a fixture just to see green. A card without a timestamp is exactly how two separate evenings collapse into one false memory.

mkdir -p cards
python3 tools/path_card.py \
  --suggestion-path local \
  --execution-path local \
  --provider-label unreported \
  --out cards/local-local.json \
  --command python3 -m unittest tests/test_fixture.py -q

If I later have a hosted free server available, I change only the execution flag and I copy the printed label. I do not rename the suggestion path so the pair looks tidy, and I do not reuse yesterday's file. Same command, different path, new file: that is the whole trick, and it is smaller than it sounds. Would a tidy matching pair really be worth more to you than a pair that stays true?

A gate table for the second day

Before the second day's runs, I would read a gate table instead of negotiating with a diff. The table is not a ranking, and it does not claim that any hosted path is faster or safer. It only asks whether I can name each path today, with the wording the product actually showed me. If I cannot answer, the row says stop, which is a result I am allowed to keep.

Question I can answer today	Suggestion path	Execution path	What I record
I only need a wording draft, and I will not run code	hosted-free-model, if the account shows it	unused	Draft text plus the printed label, and no exit code
I already wrote the patch, and I only need a machine	unused	hosted-free-server, if the account shows it	Command, exit code, and the printed label
I need both a draft and a check	name it separately	name it separately	Two fields, even when both values are local
I cannot tell which path is offered right now	unavailable	unavailable	Stop, and do not backfill a guess from memory

Notice that free never appears as a stored value, even though it is the word that started the confusion. The word can stay in conversation, but it should not survive into the artifact I will reread tomorrow. If a provider changes what an offer includes, older cards still name the path I believed I used. That is a weaker claim than a benchmark, and the weaker claim is the one I can defend.

Hours 36 to 48: what I would repeat

On the last block of hours I would replay three cases and write one plain sentence under each card. First I pass an unknown path string and confirm the script exits before it writes anything flattering. Next I run a fixture I already trust with both paths set to local, and I keep the card beside the output. Finally, only if a hosted option is actually offered to me, I rerun that same fixture and I refuse to merge cards.

The paper failure is already enough to change the habit, even if I never leave the laptop. A single free flag cannot tell me whether to reread a suggestion or to inspect the host that ran the check. I would repeat the split when both paths feel boring, because boredom is when I start abbreviating notes. Would a future version of me understand this file without the chat scroll that produced the wording?

I would also keep a rejection list beside the folder, written as checks rather than as slogans. Each line is a skip I would expect from myself when the evening runs long and the diff looks small. The list is short on purpose, because a long policy becomes another document I will not open. Which line would you be tempted to delete first, and what failure would that deletion invite back in?

Do not retry a failed hosted run until the card shows which path failed and which path was never asked.
Do not paste a suggestion into the execution command, because model text is untrusted input, not a shell program.
Do not compare two cards that lack started_at, even when the command strings look identical on the screen.
Do not treat a missing provider label as permission to invent one from a blog post or a memory.
Do not ignore a missing interpreter, because that failure belongs to the execution path, not the suggestion.

Who should not use this notebook

Skip this notebook if you need a compliance review, a capacity plan, or a number you can publish. The card does not measure queue time, retention, or whether a free option will still exist next week. Skip it when the command might touch production credentials, because a free server is still a remote machine. You still have to authorize that machine on purpose, and a friendly price does not change that duty.

Skip it if you wanted a prompt that quietly picks a best model, since this workflow only records a choice you already made. I would also skip hosted columns when the work includes secrets, personal data, or an unreviewed shell string. Local-only cards remain useful, and they keep the same keys so a later hosted run does not invent a format. A consistent boring card beats a clever one I will not reread on the following Monday.

One hosted name, then back to the habit

If I already have a MonkeyCode account, I fill a hosted value only after that account shows the option I am about to use. The outreach note above is why this product appears here, and deleting the name should not break the recorder. I would rather file one honest card than collect another evening of notes that say free and mean two machines. That is the habit I would repeat, and it does not require me to pretend I measured a platform.

Same Snippet, Different sys.executable: What I Check on the Second Host

Taylor Wang — Sun, 11 Oct 2026 16:17:50 +0000

I opened a second shell and expected the same three-line repro to pass, because the laptop had already agreed with me. Have you ever copied a working snippet onto a cleaner machine and watched the import fail for a reason that felt rude? I wanted these notes to answer a smaller question before any suggested patch was allowed to vote. Which interpreter actually ran the file, and which package versions did that process believe were already installed?

The laptop carried a virtual environment, a lockfile, and a shell alias that quietly preferred one Python over another. The second machine mattered only if I treated it as another runtime, not as a prettier copy of the laptop. I am not claiming a measured outage, a customer incident, or a vendor benchmark anywhere in these notes. The mismatch later on is a constructed repro I would force, so the habit gets practiced before a real failure arrives.

Why a clean host still lies

A fresh server can look healthy while python3 still points at the system interpreter sitting outside your virtual environment. You install the project, the prompt returns, and you assume the lockfile was honored rather than merely glanced at. Did the remote installer resolve a new tree, or did it install the exact set you hashed beside the laptop tests? I would not let a drafting model answer that until both hosts had written the same receipt to disk.

Where a free server and a free model fit

MonkeyCode is relevant here only because a free server can host the second run and free model access can draft the mismatch note. Disclosure: This article was prepared as part of MonkeyCode's product outreach. I would not hide that relationship under a tutorial voice, and I would not stretch it into a claim about quality. The only product facts I am using are operator-supplied: free model access exists, and a free server option exists.

I would park the second run on that free server and ask the free model to summarize receipt diffs, not to invent pins. If those options changed later, the script and the decision table would still be the part I would keep. A vanished option would change convenience, not the question of whether the two interpreters were ever the same. Have you kept a check that still runs after the assistant you used to draft the note is gone?

The receipt I write before the argument

I wanted one JSON document per host, small enough to paste into notes and stable enough to diff without a narrative. The script records the executable, the version token, the platform string, and whether a virtual environment is active. It also hashes a few well-known lockfile names when they exist, and it keeps only environment keys that affect imports. I omit secrets and full environment dumps on purpose, because a receipt should be safer to share than a shell history.

The following scripts are unexecuted examples I would review locally before I pointed them at any shared host.

#!/usr/bin/env python3
'''Write an interpreter receipt as JSON. Unexecuted example, not a measured run.'''

import hashlib
import json
import os
import platform
import sys
from importlib import metadata
from pathlib import Path

TRACKED = ('pip', 'setuptools', 'urllib3', 'certifi', 'tzdata')
ENV_KEYS = ('VIRTUAL_ENV', 'PYTHONPATH', 'PYTHONHOME', 'PYTHONDONTWRITEBYTECODE')
LOCK_NAMES = ('requirements.txt', 'requirements.lock', 'Pipfile.lock')


def file_sha256(path):
    if not path.is_file():
        return None
    digest = hashlib.sha256()
    digest.update(path.read_bytes())
    return digest.hexdigest()


def package_versions(names):
    found = {}
    for name in names:
        try:
            found[name] = metadata.version(name)
        except metadata.PackageNotFoundError:
            found[name] = None
    return found


def build_receipt():
    root = Path.cwd()
    return {
        'executable': sys.executable,
        'version': sys.version.split()[0],
        'implementation': platform.python_implementation(),
        'platform': platform.platform(),
        'prefix': sys.prefix,
        'base_prefix': sys.base_prefix,
        'in_venv': sys.prefix != sys.base_prefix,
        'packages': package_versions(TRACKED),
        'env': {key: os.environ.get(key) for key in ENV_KEYS},
        'lock_sha256': {name: file_sha256(root / name) for name in LOCK_NAMES},
    }


def main():
    json.dump(build_receipt(), sys.stdout, indent=2, sort_keys=True)
    sys.stdout.write('\n')


if __name__ == '__main__':
    main()

Read the tracked package tuple as a starting list, not as a universal bill of materials for every project you maintain. I would add the libraries my repro actually imports, then freeze that tuple so both hosts record the same names. A missing package becomes null rather than an exception, which is what I want when the remote image never installed it. Would you rather crash the receipt, or see a null that makes the absence obvious in the later diff?

What the script intentionally leaves out

The script does not record CPU count, disk size, or a cloud image name, because I was not given those facts to assert. It does not sample network reachability, and it will not tell you whether a wheel was built from source or downloaded. I would rather omit a field than print a guess that looks like a measurement taken from the second host. If your outage lives in one of those omitted fields, this workflow will look green and still be wrong.

Commands I type on each host

I keep the command list short so the second day starts with repetition instead of a fresh theory.

python3 env_receipt.py > local-receipt.json
# copy env_receipt.py, diff_receipts.py, and the lockfile to the second host
python3 env_receipt.py > remote-receipt.json
python3 diff_receipts.py local-receipt.json remote-receipt.json

I run the script with the same interpreter I intend to blame, because a receipt from the wrong binary is another story. On the second host I copy the script and the lockfile first, then I generate the remote JSON before I open a chat. The diff helper exits non-zero when a compared field disagrees, so a wrapper can stop before any patch is applied. I would commit both JSON files next to the note, since a terminal screenshot is a poor artifact for the next morning.

#!/usr/bin/env python3
'''Diff two receipt files. Unexecuted helper; exit 1 when a compared field differs.'''

import json
import sys
from pathlib import Path

COMPARE = ('executable', 'version', 'implementation', 'in_venv', 'prefix')


def load_receipt(path):
    return json.loads(Path(path).read_text(encoding='utf-8'))


def compare(left, right):
    rows = []
    for key in COMPARE:
        lv, rv = left.get(key), right.get(key)
        rows.append((key, lv, rv, lv == rv))
    left_pkgs = left.get('packages') or {}
    right_pkgs = right.get('packages') or {}
    for name in sorted(set(left_pkgs) | set(right_pkgs)):
        lv, rv = left_pkgs.get(name), right_pkgs.get(name)
        rows.append(('pkg:' + name, lv, rv, lv == rv))
    return rows


def main():
    if len(sys.argv) != 3:
        sys.stderr.write('usage: diff_receipts.py left.json right.json\n')
        return 2
    rows = compare(load_receipt(sys.argv[1]), load_receipt(sys.argv[2]))
    failed = False
    for key, lv, rv, ok in rows:
        mark = 'ok' if ok else 'DIFF'
        failed = failed or not ok
        print('%s\t%s\t%r\t%r' % (mark, key, lv, rv))
    return 1 if failed else 0


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

The constructed repro I would force

I would create a virtual environment on the laptop, skip that step on the server, and install without the lockfile. Locally, sys.prefix should differ from sys.base_prefix, while the server receipt should show those two paths as equal. A tracked name such as urllib3 or tzdata can then show a version on one side and null on the other. If application code is edited while those fields already disagree, whose bug did we just decorate with a confident patch?

An illustrative fixture, not a capture from any host I measured, only shows the shape I want the diff to expose.

{
  "base_prefix": "/usr",
  "executable": "/usr/bin/python3",
  "in_venv": false,
  "packages": {
    "certifi": null,
    "tzdata": null,
    "urllib3": null
  },
  "prefix": "/usr",
  "version": "UNMEASURED"
}

I would treat a version field written as UNMEASURED as a sign that the fixture is documentation, not a live capture. The useful signal in that shape is a cluster of null packages beside an executable that never entered a virtual environment. I would compare that shape to the laptop receipt before I let anyone rewrite the calling code. If the only live difference is a null tzdata, I install the missing package and recapture, rather than rewriting the caller.

What broke when I rushed the comparison

The first failure I expect is not library logic, but a receipt captured by a different python3 than the failing command. You then possess a tidy JSON file that documents the wrong process, and the project looks guilty by association. The second failure is a lockfile that never left the laptop, so every remote hash is null and the tool looks broken. I would copy the missing file, rerun both commands, and only then ask whether the versions themselves still disagree.

Aliases that make the wrong binary look chosen

which python and which python3 can disagree with sys.executable once the environment scripts directory is only half activated. I would print sys.executable from the same process that runs the repro, rather than trusting a parent shell's idea of python. A shell alias can make an interactive session pass while a non-interactive runner uses the system binary and fails the import. Have you checked whether the failing command was started by a script, a scheduler, or your own fingers on the keyboard?

Resolver drift the receipt can only hint at

pip install without hashes can select a newer transitive wheel on the server than the laptop resolved on an earlier day. I would not call that a model failure, because the model never saw the resolver choices unless I pasted both receipts. The hash field tells me whether the input file matched, not whether the installer was invoked with a require-hashes flag. If I care about that flag, I add the exact install command to the note, since the JSON does not record shell history.

How I would talk to the drafting model

I paste the diff output with a short instruction, and I forbid a code change until the two runtimes are comparable. The prompt below is a template I would edit, not a transcript from a session I already ran.

Two interpreter receipts are below. Do not propose an application patch.
List only keys that differ, including package nulls.
If executable or in_venv differs, stop and say the runtimes are not comparable.
Do not invent package versions, image names, quotas, or hardware.

Have you noticed how quickly a suggestion rewrites application code when the prompt never mentioned the executable path? I would reject any draft that edits source while executable or in_venv still differs, even if the prose sounds careful. The model is only a scribe for the mismatch here, and the receipt script remains the check that can fail a build.

A table I keep beside the diff

Signal	What I conclude	What I do next
executable differs	These runs are not the same program	Recapture both receipts with the intended binary
in_venv differs	One side never entered the environment	Activate or create it, then recapture
version differs	Language behavior may not match	Pin the interpreter before debating library code
package null on one side	That import environment is incomplete	Install from the same lock, then recapture
only lock hash differs	The input file diverged before install	Copy the intended lock and reinstall
compared keys match	The environment is not the obvious cause	Inspect inputs, clocks, or the network next

This table is a decision aid for a constructed check, not a catalog of every production incident I have already closed. I would add a row only after a real mismatch taught me a new signal, and I would date that row in the note. If two rows fire at once, I handle the interpreter and the virtual environment before I touch package versions. Otherwise I end up pinning a library inside a process that was never the process under test.

What I would repeat on the second day

I generate both receipts before I open a model chat or accept a suggested edit from either host.
I diff the two JSON files with a helper that exits non-zero as soon as one compared field disagrees.
I repair the environment until those keys match, or I write down why they are allowed to differ.
I ask for a plain mismatch note, then I rerun the original repro with the executable named in the receipt.
I save both JSON files beside the note so nobody reconstructs the story from memory tomorrow.

The repeatable part is the order of the checks, not a promise that a free server will look identical next week. I would rather repeat a dull capture than repeat an argument about whose laptop counted as the normal machine. If the repro still fails after the receipts match, I finally have permission to suspect the code instead of the host. That permission is the whole point of spending two days on notes, and it arrives later than my impatience wants.

Who should not bother

You should skip this if the bug depends on a GPU, a private network, or data that cannot leave a controlled lab. A JSON receipt will not prove data residency, quota, image permanence, or any hardware shape I have not measured. Teams that already build from a hermetic image and a hash-checked lock may only need the executable identity check. I would also skip the model step entirely when policy forbids pasting environment details into a hosted assistant.

The note I would leave myself

I write the receipt, diff it, and only then ask for one sentence that explains the mismatch in plain words. If a MonkeyCode account is already available, the free server can hold the second run and the free model can draft that sentence. I would still read the diff and rerun the script myself before I merged a claim that the two hosts matched.