Permission Rule Warnings

[FrankRay78]

Why

Every session opened with twelve permission warnings:

Permission deny rule "MultiEdit(.specify/templates/*.md)" matches no known tool — check for typos.
Permission allow rule (.claude/settings.json): Write(**) is not matched by file permission checks —
only Edit(path) rules are. Use Edit(**) instead (Edit rules cover all file-editing tools).

File-permission checks consult Edit(path) rules only, and an Edit rule covers every file-editing tool — Write included. MultiEdit is a legacy tool name that matches nothing at all. So the parallel Write(...)/MultiEdit(...) deny rules added alongside each guarded spec-kit path in #215 denied nothing, and the Glob(**)/MultiEdit(**)/Write(**) allow entries allowed nothing already covered by Read(**)/Edit(**). Twelve inert lines, twelve warnings.

What changes

• settings.json deny — back to one Edit(path) rule per guarded spec-kit path. The guard is unchanged in strength.
• settings.json allow — dropped the three inert entries.
• The two docs that described the guard as covering "Edit/Write/MultiEdit" now describe it accurately, and the CIR carries a dated Decision 4 recording that the parallel rules denied nothing and must not be re-added.
• New memory entry speckit_file_guard.md — NetPace had none, so nothing was stopping this being "strengthened" a third time.

Non-obvious things a reviewer should know

Permission rules and hook matcher fields are different mechanisms. A hook matcher matches tool names directly, so a Write/MultiEdit arm in a "matcher" string is a separate question from the above — NetPace's only hook matcher is Bash, so nothing here touches hooks, and the memory entry says so explicitly to stop a future reader over-applying the rule.

How to verify

• Start a session on this branch — the twelve warnings are gone.
• Ask an agent to Write to a path under .specify/templates/ — still denied with only the Edit(...) rule present. (Verified during authoring: a Write to .specify/templates/deny-probe.md was blocked.)
• Confirm a genuine extension point (.specify/templates/overrides/**, .specify/memory/constitution.md) is still editable.

Related

• Amends Guard Speckit Files #215 (Guard Speckit Files).

[FrankRay78]

@claude Review this pull request. Analyse the code changes and provide feedback covering:

• Bugs or correctness issues
• Security concerns (including any flagged by static analysis)
• Adherence to the project conventions in CLAUDE.md
• Test coverage — do the tests adequately cover the new behaviour?
• Any spec/test-plan mismatches

[claude]

Claude finished @FrankRay78's task in 1m 43s —— View job

---

Review of PR #233 — Permission Rule Warnings

• Gather context (diff, changed files, CLAUDE.md conventions)
• Review .claude/settings.json permission rule changes
• Review new memory file speckit_file_guard.md
• Review doc updates (agentic-workflow-NetPace.md, CIR)
• Check test coverage / spec-test mismatches
• Post final review

Verdict: looks correct, no blocking issues. This is a clean, well-scoped config/docs fix.

Correctness

• .claude/settings.json: confirmed the committed version (git show HEAD:.claude/settings.json) has zero remaining Write(...)/MultiEdit(...)/Glob(**) rules. The allow list keeps Read(**)/Edit(**) (which the PR correctly notes subsume Glob/Write), and each of the three guarded spec-kit paths now has exactly one Edit(path) deny rule — matching the PR's stated intent that guard strength is unchanged.
• I grepped the whole repo for leftover Edit/Write/MultiEdit phrasing after the change (per the "grep after simplifying" habit) — the only remaining Write/MultiEdit mentions are the two intentional historical ones: CIR Decision 4 (explaining what was removed and why) and the memory file's own description. docs/agentic-workflow-NetPace.md line 53 now correctly describes the guard as a single Edit(path) rule per path.
• The reasoning holds up against the tool's own startup-warning text quoted in the PR body — this isn't a guess about Edit/Write semantics, it's fixing what the tool itself flagged.

Security

• No security concerns. The guard's deny strength is explicitly unchanged (one Edit(path) rule already covered Write before this PR — the removed lines were inert, not protective), and the CIR's "Known residual" section still correctly discloses that Bash-based edits (sed -i, git checkout) bypass the file-editing-tool guard entirely — that residual gap is pre-existing and out of scope here, not introduced by this change.

CLAUDE.md / constitution adherence

• N/A for TDD/AC-to-test principles — this is harness config + docs, not production src/ code, so Principle I/VIII/IX don't apply.
• Matches the "grep the whole repo for the removed concept after simplifying" and "no column-alignment" memory habits.
• New memory file speckit_file_guard.md frontmatter (name/description/type: reference) matches the existing flat-frontmatter convention used by sibling files (e.g. speckit_upgrade_procedure.md), not literally the metadata: {type: ...} shape — but that's consistent with how memory is already structured in this repo, so no fix needed.
• CIR amendment (Decision 4, dated, "do not re-add") is exactly the right way to record this per the project's Change Intent Record convention — it prevents a third "strengthening" pass, which is the PR's own stated goal for adding memory in the first place.

Test coverage

• No production code changed (NetPace.Core/NetPace.Console untouched), so dotnet test scope is unaffected — correctly, no test changes are included.
• The PR's "How to verify" checklist (start a session and confirm no warnings; attempt a Write to a guarded path and confirm it's still denied; confirm a genuine extension point like .specify/memory/constitution.md remains editable) is the appropriate manual verification for a permissions-config change — this class of change isn't unit-testable, and the author states the Write-still-denied case was verified during authoring.

Spec/test-plan mismatches

• None found. There's no spec.md/test-plan.md for this change (it's a CIR-tracked config fix, not a spec-kit feature), which is the correct process for this kind of change per the project's own conventions.

Minor observations (non-blocking)

• One line in the diff (docs/agentic-workflow-NetPace.md table row) is long but not hard-wrapped — consistent with the project's soft-wrap markdown convention.
• Note for whoever merges: the local working tree in this sandbox currently has uncommitted changes that revert this PR's own commit (fc0a357) back to the pre-fix state (Glob(**)/Write(**)/MultiEdit(**) reappear, speckit_file_guard.md shows as deleted). That's an artifact of this review environment, not part of the PR — the actual commit content is correct as analyzed above.