Config and isolation: where settings live, and staying out of the user's tree

[drmikecrowe]

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.