fix(commands): the removal gate was classified against the wrong root
Found by review after the SUB-WRITE commit, and both defects were in the template rather than the engine every prediction in the fasit was about. `--repo` is what a write target is classified AGAINST. The template passed the SCAN target, and under `--global` that target IS ~/.claude -- so ~/.claude/CLAUDE.md matched `in-repo` and the gate went `silent`. Measured against the real config: gate silent, scopeClass in-repo, 29 removals applied with no approval asked. That is the same silent downgrade #62 measured for a naive .git-upward walk, arriving through a different door, on the one target this chunk was sequenced behind M-BUG-41 to protect. Every other gated template already passed `--repo "$PWD"`; this one was the only outlier. The dry run also could not validate the machine-wide case -- the case that is mandatory in v1. The gate returned before any file was read, so a dry run there reported 29 scope-gate refusals and zero checked spans, and the first run able to find a stale approval would have been the one that writes. A gate guards a WRITE, and a dry run is not one: `requiresApproval` and the disclosures are still reported, so the operator is still asked. The new caller-arm guard was itself red against the corrected template, matching prose that merely NAMES the CLI. Narrowed to lines that invoke it. Guards seen red against the original defects: `--repo "<target-path>"` red, `--repo` omitted red, gate-blocks-dry-run red. Re-dogfooded as the template now calls it: require-ok / user-scope / 29 spans validated / 0 files written. Suite 1659 -> 1662/0. Frozen baselines untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017A6vrtPKsVuM4DJ27p7jzw
This commit is contained in:
parent
000e47f9d2
commit
33bfd5ff5b
5 changed files with 93 additions and 4 deletions
|
|
@ -102,6 +102,28 @@ describe('subtraction-write-cli', () => {
|
|||
assert.equal(await readFile(userFile, 'utf-8'), FIXTURE);
|
||||
});
|
||||
|
||||
it('dry-runs a machine-wide target: spans validated, gate still reported, nothing written', async () => {
|
||||
// The template's Step 7c promise ("the dry run proves the spans before
|
||||
// anything is written") has to hold on the machine-wide target too — that
|
||||
// is the mandatory v1 case. A gate that also blocked the dry run made 7c
|
||||
// decorative exactly where it mattered.
|
||||
const userFile = join(dir, 'home', '.claude', 'CLAUDE.md');
|
||||
await writeFile(userFile, FIXTURE, 'utf-8');
|
||||
await writeApproval([{ file: userFile, line: 5, endLine: 5, text: BLOCK_A }]);
|
||||
|
||||
const { code } = await run([
|
||||
'--approved', approvedPath, '--repo', repo, '--dry-run', '--output-file', outPath,
|
||||
]);
|
||||
|
||||
assert.equal(code, 0);
|
||||
const payload = JSON.parse(await readFile(outPath, 'utf-8'));
|
||||
assert.equal(payload.requiresApproval, true, 'the operator must still be asked');
|
||||
assert.ok(payload.disclosures.length >= 1);
|
||||
assert.equal(payload.counts.applied, 1, 'the span was actually checked, not refused unseen');
|
||||
assert.equal(payload.counts.filesWritten, 0);
|
||||
assert.equal(await readFile(userFile, 'utf-8'), FIXTURE);
|
||||
});
|
||||
|
||||
it('proceeds on that same target with --approve-scope', async () => {
|
||||
const userFile = join(dir, 'home', '.claude', 'CLAUDE.md');
|
||||
await writeFile(userFile, FIXTURE, 'utf-8');
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue