Freeze One Command Allowlist Before a Generated Script Leaves the Laptop

A generated maintenance script should stay on the laptop until a senior pairing freezes one command allowlist and one comment rule. The useful result is an execution card that a second engineer can replay, not a shorter diff chosen for style alone. That card separates read-only inspection from a single mutation and rejects every extra command a model appends later. Teams that skip the card often meet the blast radius only after a formatter, an installer, or a comment rewrite has already landed.

What the pairing is deciding

This section is a proposed pairing session, not a measured outage report and not a personal benchmark from the publishing account. The pair reviews a module whose comments grew across several generated patches and now obscure the real constraints. A current developer conversation treats comments as the enemy of clean code, which tempts a generator to delete them in bulk. The senior treats that temptation as a risk, because a deleted constraint may be the only record of a failure mode.

Questions the senior records

The senior does not ask the model to score the laptop against a server the pair has not instrumented. The first recorded question asks which comment states a constraint that no current test actually enforces. The second recorded question asks which planned command writes files and which planned command only reads the tree. The third and fourth questions ask which tool versions must match and which output counts as evidence rather than suggestion.

Dead ends the pair refuses

The first dead end is a blanket comment purge driven by a style slogan rather than by a failing test. The second dead end is a generated comparison of machines that the pair never instrumented and cannot reproduce. The third dead end is an install command that appears helpful only because a linter is missing from the environment. The fourth dead end is a green format run that the pair mistakes for proof that runtime behavior stayed the same.

Each dead end fails for the same structural reason, even though the surface tasks look unrelated to one another. Generated text widens authority when a keeper has not yet named the allowed files, commands, and evidence. The pair therefore writes the refusal into the card, so a later model call cannot quietly reopen the same path. A refusal without a stored reason tends to be re-argued on the next patch, which wastes the senior's review time.

The decision that stays

The pair keeps a three-gate execution card together with a narrow rule for when a comment may be removed. A comment may be removed only when the keeper maps it to a test, a type, or an existing public document. Read-only commands may run on the laptop first and may be repeated on a separate server only if that option already exists. Exactly one mutating command may run after both read gates pass against the same frozen plan and the same fixture.

Any new flag, pipe, redirect, or network tool voids the card and sends the pair back to review. The model may suggest a better command, but that suggestion starts a new card instead of editing the accepted one. This rule is stricter than a typical format-on-save habit, and that strictness is the point of the pairing. The kept decision is small enough to audit in one sitting and specific enough to block a widened script.

Step 1: Freeze the comment disposition

The keeper writes a disposition file before any model is allowed to edit prose in the module. Each entry names the file, a stable anchor phrase, an action, and a reason a reviewer can check later. Dropping a comment requires a pointer to a test name or a type that already carries the same constraint. Keeping a comment requires a one-line failure mode, not a restatement of the code that immediately follows it.

# proposal: unexecuted disposition, not a production record
- file: src/report.py
  anchor: "retry only on 429"
  action: keep
  reason: "failure mode not expressed by test_report_backoff"
- file: src/report.py
  anchor: "loop over rows"
  action: drop
  reason: "narrates the next line and carries no constraint"

The sample above is an unexecuted proposal for the review packet, not a log from a production repository. A generator may draft candidate lines, yet the keeper commits the file before any further generation continues. If an anchor phrase no longer exists in the file, the entry is stale and the card returns to the senior. The disposition file stays beside the command plan so both artifacts are reviewed as one decision.

Step 2: Freeze the command plan as argv

The command plan is a JSON list of argv arrays, because a raw shell string hides pipes and redirects. Each entry carries an identifier and a class of read or mutate, and the plan allows exactly one mutate entry. The checker in this section is a proposal for local review, and it is not offered as a published benchmark. It refuses network-shaped binaries, shell metacharacters, and any mutating argv that leaves the single kept formatter.

#!/usr/bin/env python3
"""Proposal: reject a command plan that leaves the frozen allowlist."""
import json
import sys

NETWORK = {"curl", "wget", "ssh", "scp", "nc", "pip", "npm", "pnpm"}
META = set("|;&<>`$")
KEPT_MUTATE = ["python", "-m", "ruff", "format", "src/report.py"]

def fail(msg: str) -> None:
    raise SystemExit(f"plan rejected: {msg}")

def main() -> None:
    plan = json.load(sys.stdin)
    cmds = plan.get("commands")
    if not isinstance(cmds, list) or not cmds:
        fail("commands must be a non-empty list")
    mut = [c for c in cmds if c.get("class") == "mutate"]
    if len(mut) != 1:
        fail("the kept card requires exactly one mutate command")
    for c in cmds:
        argv = c.get("argv")
        kind = c.get("class")
        if not isinstance(argv, list) or not argv or kind not in {"read", "mutate"}:
            fail("each command needs class and argv")
        if argv[0] in NETWORK:
            fail("network or installer binary is blocked")
        if any(any(ch in arg for ch in META) for arg in argv):
            fail("shell metacharacters are blocked")
        if kind == "mutate" and argv != KEPT_MUTATE:
            fail("mutate argv is outside the kept formatter")
    print("plan accepted", len(cmds))

if __name__ == "__main__":
    main()

{
  "intent": "inspect one module, then format that same file",
  "commands": [
    {"id": "c1", "class": "read", "argv": ["git", "status", "--short"]},
    {"id": "c2", "class": "read", "argv": ["git", "diff", "--", "src/report.py"]},
    {"id": "c3", "class": "mutate", "argv": ["python", "-m", "ruff", "format", "src/report.py"]}
  ]
}

A plan that fails the checker never leaves the laptop and never becomes input for a server session. The formatter exception is deliberate and narrow, so a later edit cannot swap in an installer under the same class. Teams with a different formatter should change that one tuple in review, rather than disabling the class check. The negative example in the next block should fail closed, because an installer is not a formatter.

python3 tools/check_plan.py < plan.json
sha256sum plan.json disposition.yaml
printf '%s\n' '{"commands":[{"id":"bad","class":"mutate","argv":["pip","install","ruff"]}]}' | python3 tools/check_plan.py

The first command accepts the frozen plan, and the second command records hashes the senior can sign later. The third command is a negative check, and a correct checker exits without printing an acceptance line. Those three commands are proposals for the packet, and they are not a claim that a particular repository already passed them. A keeper who changes the formatter tuple should update the negative check so the sample still matches the kept rule.

Step 3: Run the local dry-run gate

The local gate runs only commands marked read, using the same JSON document the checker already accepted. A small wrapper prints each argv and skips every mutate class so the first pass cannot change files. The pair stores that printed argv beside the disposition file, which makes a later server run comparable. If the worktree is already dirty, the pair stops, because a mixed tree makes the later diff meaningless.

python3 tools/check_plan.py < plan.json
python3 - <<'PY'
import json, subprocess
plan = json.load(open("plan.json"))
for c in plan["commands"]:
    if c["class"] != "read":
        print("skip mutate", c["id"])
        continue
    print("run", " ".join(c["argv"]))
    subprocess.run(c["argv"], check=True)
PY
git status --short
git diff --stat

After the read commands finish, the keeper inspects git diff and expects no content change from this gate. A surprise diff means a read command was misclassified, and the card is void until the class is corrected. The pair does not fix that surprise by editing files by hand inside the same gate. They open a new note, reclassify the command, and rerun the checker before any server is involved.

Step 4: Repeat the read-only gate away from the laptop

MonkeyCode enters this workflow only as an optional drafter of the plan and as an optional host for the read-only gate. Disclosure: This article was prepared as part of MonkeyCode's product outreach. The operator-supplied context for this draft is free model access and a free server option, nothing more specific than that. This article does not name a model, state a quota, describe hardware, or claim that either option is permanent.

The drafting context for this card is 25 September 2026, and any availability claim should be rechecked on that product's current pages. A free model may propose disposition lines and a JSON plan, but those proposals remain untrusted until the checker passes. The keeper still commits the disposition file and still refuses any argv the allowlist does not already contain. A free server, when the team chooses to use one, should receive a copied fixture and the read-class argv only.

Secrets, credentials, and production configuration do not belong in that fixture, even for a short inspection. The server run is comparable only when the tool versions match the versions recorded on the local card. A version mismatch is a dead end, not a reason to let the model install a different toolchain on the server. If the two transcripts disagree, the mutation gate stays closed until a human explains the difference in writing.

The pair copies the printed argv and the exit status back into the review packet beside the local transcript. A matching pair of transcripts is the only signal that lets the keeper open the mutation gate. The free server option does not become a place to explore new commands once that signal is recorded. A missing exit status is treated as a disagreement, even when the printed argv looks identical.

Step 5: Allow one mutation and stop

The mutation gate runs the single kept formatter command and then stops, even if the model offers follow-up fixes. The keeper runs the focused tests named in the disposition file, not an open-ended suite invented during the session. A failing test reopens the card, because a format change that breaks behavior is still a behavior change. A passing test does not authorize a second command, a dependency bump, or a fresh comment rewrite.

python3 -m ruff format src/report.py
python3 -m unittest tests.test_report_backoff
git diff -- src/report.py
sha256sum plan.json

The diff is accepted only when every remaining comment still matches a keep entry or a justified drop entry. The senior signs the card by recording the plan hash, the two transcripts, and the test command that was actually run. Without that signature, the generated patch stays a proposal and does not move to a shared branch. The session ends on that kept decision, rather than on a general claim that generated maintenance is safe.

A table the keeper can copy

The table below compresses the card into four rows that a reviewer can check without rereading the whole transcript. It is a teaching artifact for this proposed session, not a measurement of product throughput or server capacity. Teams should edit the mutate row to match their own formatter, test runner, and repository policy. They should not add a row for package installation unless a separate reviewed change has already approved it.

Gate	Where it runs	What may run	What voids the card
Local dry-run	Laptop worktree	Read-class argv from the frozen plan	Dirty tree, mutate class, or a network binary
Read-only repeat	Free server option with a copied fixture	Same read-class argv when versions match	Secrets in the fixture, installers, or version drift
One mutation	Laptop after both transcripts agree	The single kept formatter argv	Extra flags, a second mutate, or a new file list
Evidence check	Review packet	Named tests, plan hash, and both transcripts	Unnamed suite, missing signature, or an unjustified drop

Limitations and who should skip the card

This approach does not prove that a free server is faster, cheaper, or safer than a local runner. It does not establish a quota, a hardware shape, a region, or a support commitment for any product option. It will not satisfy a compliance review that requires a signed attestation, a retained audit log, or a change-management ticket. The checker is a small proposal and has not been certified against hostile generated plans beyond the cases written here.

Incident response should not use this card, because a live outage needs a narrower runbook than a comment-and-format session. Repositories that contain secrets, production credentials, or customer data should not copy a fixture onto a shared server for this exercise. Teams without a named human keeper should not run the mutation gate, because the model cannot sign the card for them. Readers who need a specific model name, a token allotment, or a guaranteed free period will not find those facts in this article.

Replay the card on a low-risk module

A reader who already uses the product can replay this card on one low-risk module before trusting a larger generated patch. That replay is worthwhile only after the reader checks current terms and keeps the same human signature the session required. The article remains useful without the product, because the allowlist, the disposition file, and the three gates stand on their own. The kept decision is still the same: one frozen plan, read gates first, and a single mutation that a senior can explain.