feat(setup): add --no-overrides one-shot defaults switch

[justinmclean]

Summary

Implements acceptance criterion 6 of specs/adoption-and-setup.md:
a per-invocation --no-overrides flag that runs any framework skill
against framework defaults for that single invocation, ignoring both
override surfaces without modifying or deleting them. The safety
baseline (confidentiality, privacy, security) still applies.

Adds the protocol to docs/setup/agentic-overrides.md under a new
"One-shot defaults run" section, lists the flag in the setup SKILL.md
Inputs table, and ships a three-case eval suite exercising:

• flag present + override exists → skip-overrides
• flag present + no override → skip-overrides
• flag absent + override exists → apply-overrides (baseline)

Generated-by: Claude (claude-sonnet-4-6)

Type of change

• Skill change (.claude/skills/<name>/) — eval fixtures updated below
• Tool / bridge contract (tools/<system>/*.md)
• Python package (tools/*/ with pyproject.toml)
• Groovy reference impl
• Cross-cutting (RFC, AGENTS.md, sandbox, privacy-LLM)
• Documentation (docs/, README.md, CONTRIBUTING.md)
• Project template (projects/_template/)
• CI / dev loop (prek, workflows, validators)
• Other:

Test plan

• [X ] prek run --all-files passes
• For Python packages touched: uv run pytest / ruff check / mypy passes
• For Groovy bridges touched: command-line invocation tested end-to-end
• For skill changes: eval suite passes for the affected skill
  (PYTHONPATH=tools/skill-evals/src python3 -m skill_evals.runner tools/skill-evals/evals/<skill>/)
• For skill behaviour changes: a new or updated eval fixture is included in this PR
  (a regression test for the bug fixed / the behaviour added — see CONTRIBUTING.md)
• Other:

[potiuk]

Approving with a rebase and a fixup pushed to the branch.

Rebase. Main moved twice under this branch: it added the step-overrides-surface suite, and it replaced the 3-step override protocol with a 5-step, two-directory one (personal-local + committed). Both eval suites now coexist — 12 cases, not 8 or 9 — and --no-overrides is re-anchored as step 0 of the five-step protocol rather than the three-step one it was written against.

One behaviour decision I made on your branch, so flagging it explicitly rather than burying it in a diff. Step 0 originally said "skip steps 1–3 entirely", which under the new protocol would also skip the recap. I changed it to skip steps 1–4 but still run step 5, reporting that the run used --no-overrides and naming the override files that existed but were not consulted. Reasoning: otherwise the audit trail cannot distinguish a deliberate bypass from a repo that simply has no overrides on disk, and the bypass is the case you most want recorded. Say the word if you disagree and I will revert that bit.

The eval predicates needed tightening. Replacing the MANUAL grade with deterministic regexes was the right instinct, but both keyed on the flag name:

has_bypass_reason: no-?overrides|framework default|not (be )?read|not applied|ignor

Given the reason "The override file was read and applied because no --no-overrides flag was present" — an apply-reason on a skip case — that pattern matches, so the assertion passed on a wrong answer. has_apply_reason had the same hole through its no .*flag branch. The flag name appears in a correct reason and in one arguing the exact opposite, so it cannot discriminate.

decision is enumerated and still caught a wrong call, so the eval was not blind — but the reason predicates were decoration rather than a check.

Both now require the matching verb (skipped / not-consulted versus applied / consulted) and reject the opposing phrasing. Verified across eight cases in both directions, including "No bypass flag was supplied, so the override file was read and applied", where the skip word is itself negated and my first attempt wrongly rejected it. Full-word alternations rather than truncated stems, because typos reads skipp? and ignor as misspellings.

Worth generalising: for any predicate over a decision's prose, the test is not "does a right answer pass" but "does a reason arguing the other decision fail". Noted in the suite README so the next editor checks both directions.