fix(claude-config): check-structure.sh unreadable note overstates a bare Read deny as a cause

[kyle-sexton]

Follow-up to #1599 (merged). Known-minor, not a behavior bug.

plugins/claude-config/skills/audit/scripts/check-structure.sh reports an unreadable file with:

Note: present but unreadable — not inspectable (deny rule, sandbox denyRead, or filesystem permissions). Not a malformed-config finding.

A Read(...) deny rule alone cannot make open() fail inside this script — that is exactly the
"arbitrary subprocesses" carve-out documented in the same PR at
skills/audit/reference/required-permissions.md. A deny becomes a cause only once the sandbox is
enabled and the deny merges into the sandbox filesystem boundary, which is the qualifier
context/procedures.md and SKILL.md both carry and this string does not.

The behavior is right and both prose surfaces are accurate; only the note string and its adjacent
comment are loose enough to read as "a deny rule alone does this". Tighten to something like
"sandbox denyRead — including a Read deny merged into the sandbox boundary — or filesystem
permissions" on the next touch of this file.

Related

• docs(claude-config): state the scope of a Read deny in the audit permission baseline #1599 — the PR that introduced the note string.

[kyle-sexton]

This was generated by AI during triage.

Triage: verified → briefed, delegable.

Verification: the claim holds. The claude-config audit skill's structure-check script emits, for a
present-but-unreadable config file, a note whose parenthetical lists deny rule as a bare cause
alongside sandbox denyRead and filesystem permissions. Its adjacent explanatory comment uses the
same loose phrasing, and so does the corresponding comment in that script's own test file. The
skill's SKILL.md prose does carry the qualifier (a denyRead merged from the baseline Read
deny), and reference/required-permissions.md documents the arbitrary-subprocess carve-out that
makes the bare form wrong. So the divergence is real and confined to the script-side strings.

Agent Brief

Type: Bug
Summary: The unreadable-file note emitted by the claude-config audit skill's structure check
lists a bare Read deny rule as a cause of an unreadable file; a deny rule alone cannot make a read
fail inside a script, so the note must carry the sandbox-merge qualifier its prose surfaces already
carry.

Current behavior:
When the structure check finds a config file that is present but cannot be read, it reports a note
attributing the failure to a "deny rule, sandbox denyRead, or filesystem permissions". A Read(...)
deny rule on its own governs the harness Read tool, not open() inside an arbitrary subprocess —
the carve-out the skill's own permissions reference documents. A deny becomes a cause only once the
sandbox is enabled and that deny merges into the sandbox filesystem boundary.

Desired behavior:
The emitted note attributes the unreadable state only to causes that can actually produce it: a
sandbox denyRead (including a Read deny merged into the sandbox boundary), or filesystem
permissions. The bare "deny rule" wording is gone. The explanatory comment adjacent to the emitting
branch, and the equivalent comment in that script's test file, are brought to the same qualified
phrasing so the three script-side surfaces agree with the skill's prose. The note continues to state
that this is not a malformed-config finding.

Key interfaces:

• The structure-check script's unreadable-file branch — the Note: line it prints, and the comment
  documenting why an unreadable read is not a JSON-validity failure.
• That script's test file — its comment restating the same causes.
• Behavioral contract unchanged: exit status, the Readable: no / Valid JSON: n/a /
  Top-level keys: n/a fields, and the not-a-finding classification all stay as they are.

Acceptance criteria:

• The emitted unreadable-file note no longer names a deny rule as a standalone cause, and states
  the sandbox-merge qualifier explicitly.
• The script's adjacent comment and the test file's equivalent comment carry the same qualified
  phrasing — no surface left with the bare form.
• The wording is consistent with the skill's SKILL.md and its permissions reference; no new
  claim is introduced that those surfaces do not already make.
• The skill's existing test suite passes unchanged, including any assertion matching the note text
  (update the expected string if one pins it).

Out of scope:

• Any change to when the unreadable branch fires, to the exit status, or to the reported fields.
• The SKILL.md and required-permissions.md prose — both already accurate; do not restate or
  duplicate their content into the script.
• Broader rework of the audit skill's permission model.

Note on classification: this is not an inert docs edit. The changed strings are output the script
emits to the operator, and the repository's runtime-surface boundary treats these paths as
behavior-loaded. Route it as a scoped code change, not a mechanical doc fix.

[kyle-sexton]

This was generated by AI during triage.

Admission gate: carries agent-ready but no work-class: label and no body-recorded class trailer — unclassified → fail-closed human-gated per the work-loop lane's admission table (a role label alone is not classification evidence). Routed to human-gated; not dispatched. (See #1610 — this is a recurring pattern this cycle, not a one-off.)