RE-CUT: Do not mutate the user's working tree to do your work

[drmikecrowe]

⚠️ Re-cut — the description below is the original and no longer matches the diff. It is kept as written so your review still reads against the text it answered. See the re-cut comment for what this PR now contains: isolation only, +14/−0 in SKILL.md, no references/setup.md and nothing permission-shaped. Two claims below are also now stale — setup.md is not in this branch at all, and #10 no longer depends on this PR; it was re-cut to stand alone.

---

Two things the skill relies on but never wrote down: where per-repo settings live, and how work is kept out of the user's working tree.

references/setup.md (new, +297)

An optional .old-coder.toml: isolation, install, commit, commit_args, tracker, artifacts, [commands]. Nothing blocks on it — absent, everything defaults to propose and isolation = "auto".

The part worth arguing about is the restrict-only asymmetry. A tracked config may tighten permissions and never loosen them: install = "allow" in a committed file is ignored, because otherwise cloning a repo would hand its config authority over the machine that cloned it. Grants live only in a gitignored or absolute-path config, where they're the machine owner's statement rather than the repo author's.

Alongside it, the permission rule stated once: an operation proceeds if policy permits it AND (it is reversible OR an approver is present). Policy can grant standing permission; it cannot manufacture a human. The consequence matters for unattended runs — with propose and nobody present, skip the operation, record the consequence, and continue. A run that halts on configuration produces neither code nor evidence.

Isolation as an invariant

Do not mutate the user's working tree to do your work. Branch or worktree, picked by a detection chain, declared in the SPEC so the human can veto it before work starts.

The trap earns its paragraph: a fresh worktree contains no gitignored content, so the gauntlet frequently can't run there until dependencies are rebuilt — and the tempting move is to report green from a tree that never ran the suite.

That trap has a second half: an isolated tree and the tree the change lands in can differ by ignored content, so a green worktree run isn't automatically evidence about the main tree. That gets one sentence here, and a note that EVIDENCE should say when it applies. An executable layer for it — re-running the suite in the landing tree via an apply-and-revert recipe — is a much heavier proposition and is deliberately not in this PR. Happy to propose it separately if you ever want it; it may well be more machinery than this skill wants.

+334/-1 across the new setup.md and SKILL.md wiring. Demo and CI untouched.

---

Part of a series from a fork that has been running this skill daily (drmikecrowe/old-coder). The templates PR (#10) depends on this one — it references setup.md for the artifact layout and the tracker setting.

🤖 Generated with Claude Code

[AmazingAng]

Two good things in one PR, and I would like to take them separately.

Take now: isolation

The invariant is right and it is not written down anywhere in this skill: do not mutate the user's working tree to do your work, declared in the SPEC so the human can veto the mechanism before work starts.

The trap is the best paragraph in this PR. A fresh worktree contains no gitignored content, so the gauntlet frequently cannot run there — and the tempting move is to report green from a tree that never ran the suite. That is the same failure mode as #6 and #8: a mechanism reporting success while doing nothing, failing in the direction that looks good. See my note on #6; this project has now hit five instances of it, and yours are three of them.

The second half — an isolated tree and the tree the change lands in can differ by ignored content, so a green isolated run is not automatically evidence about the landing tree — is subtle, correct, and something nobody here had noticed. Please keep it, including your judgement that the executable version (apply-and-revert in the landing tree) is heavier machinery than this skill wants right now. Agreed, and thank you for leaving it out rather than including it.

Could you re-cut this as isolation only, roughly 12 lines folded into the existing Setup section, with no new reference file? Everything above fits in that space.

Defer: .old-coder.toml

This is not a quality judgement, and I want to be precise about why, because the reasoning in it is good.

A config file with permission keys, an isolation detection chain and an artifacts layout changes what old-coder is — from a methodology in markdown to a tool with a config format that every agent must now look for. That is a positioning decision for the repo owner, and it should be made on its own rather than arriving inside a technical PR. The 298-line reference is also longer than the entire independent-verification protocol, which is a signal about surface area rather than about the writing.

The insight I do not want lost is the restrict-only asymmetry: a tracked config may tighten permissions and never loosen them, because otherwise cloning a repo hands its config authority over the machine that cloned it. That is a real supply-chain argument and I have not seen it made elsewhere in this space. The permission combining rule — proceeds if policy permits it AND (it is reversible OR an approver is present), policy can grant standing permission but cannot manufacture a human — is equally clean, and its consequence for unattended runs is right.

If the positioning question resolves toward config, please re-propose both on their own; they will get a proper reading rather than being carried along by the isolation half.

[drmikecrowe]

Re-cut per your review. The description at the top of this PR is the original and no longer matches the diff — this comment is what the PR now contains.

Isolation only. references/setup.md is gone from this branch entirely, along with everything permission-shaped. The branch is cut fresh off main, so it carries only its own diff. +14/−0, one file, twelve lines folded into the existing Setup section, no new reference file.

What survives:

• the invariant — do not mutate the user's working tree to do your work — declared in the SPEC so you veto the mechanism at approval rather than discovering it afterwards
• the trap: a fresh worktree contains no gitignored content, so the gauntlet often cannot run there. Two outcomes are acceptable — rebuild and run there, or fall back to a branch and record why. Never report green from a tree that never ran the suite.
• the landing-tree caveat: where the isolated tree and the tree the change lands in differ by ignored or untracked content, EVIDENCE says so

It goes first in Setup because it decides which tree everything after it happens in — the toolchain install and the git init both land somewhere, and that somewhere is this decision.

What this does when it is broken. It is prose, not a gate, and it should be read that way. An agent that ignores the invariant edits your tree anyway and nothing here stops it.

The trap clause is the sharper case, and it is worth being exact about what it does and does not buy. The failure it names — reporting green from a worktree whose dependencies were never rebuilt — is one that looks like success, so it is exactly the class that no red gauntlet will surface. This rule does not detect it. What it does is make the honest path cheap and the dishonest one visible: the mechanism and any fallback reason are recorded in EVIDENCE, so a reader can ask whether the suite ran in a tree that could actually run it. If an agent silently reports green from an unbuilt worktree, that EVIDENCE line is the only trace, and a reader who does not look at it will not know. I would rather say that here than let it read as a check.

One addition beyond your list, flagged rather than slipped in. Your bullets named the invariant, the SPEC declaration, the trap and the landing-tree caveat. I also had to say when none is an acceptable mechanism, because upstream has no prior isolation content and a bare "worktree, branch, or none" reads as none is always fine if you explain it. It is bounded with your own vocabulary rather than new doctrine:

a worktree, a branch, or none — the last only at Tier 1, where the blast radius is a typo

Strike the qualifier if you would rather the tier map carry that on its own.

Deliberately still absent: the executable version of the landing-tree check — apply-and-revert in the landing tree — since you agreed it is heavier machinery than this skill wants. Stating the limit is worth more than half-enforcing it.

The deferred half — the restrict-only asymmetry and the permission combining rule — is not in this PR and is not lost. It comes back on its own as you asked, as the positioning question rather than carried along by the isolation half.

[drmikecrowe]

@AmazingAng -- ready for more feedback