fix(local-review): a profile it cannot read says so, and the self-test catches a broken setup

[soydiloreto]

📝 What changes

Five small fixes to the local review, left over from #16 and #28.

• A profile: it cannot read says so. A workflow that passes the profile as an expression (or anything that is not a plain name) silently became general, so the local review could differ from CI's. It now prints that the review uses general and points at --profile. A comment after the value (profile: plugin-wp # the stack) is read correctly.
• The self-test catches a broken setup. test_case built its scratch repository inside $( … ) && …, where errexit is off, so a setup step that failed went unnoticed. The setup runs in a shell of its own with -euo pipefail, and a failure is reported.
• Only a profile: with a value is read. A bare profile: or a profile: { type: … } map (an input's declaration, as in claude-review.yml) is skipped, so it neither hides the caller's value nor raises the warning.
• One case passed --no-claude twice (test_case always adds it).
• central-ref follows a pinned uses:. The README and the header of claude-review.yml say that a caller pinning uses: to a version passes the same version as central-ref, or the workflow runs at its pin while the policy and the brief follow v2.

💡 Why

The local review promises the same answer CI will give; a profile read wrong breaks that without a word. A self-test that cannot fail its own setup proves less than it seems.

🧪 How I tested it

• bash scripts/local-review.sh --test: every case passes, including three new ones (a profile with a comment after it, an input declaring profile: before the caller's value, a profile that is not a literal)

🤖 AI-generated · Claude Opus 5.5 (Anthropic)

[dilux-bot]

Claude review · risk high · complexity medium · type fix

This PR makes four changes to the local review. (1) It reads profile: more carefully: it skips a bare key, a { type: … } map and a trailing comment, and it warns instead of silently using general when the value is not a literal. (2) It builds the test_case scratch repository under bash -euo pipefail, so a broken setup fails the case. (3) It removes the duplicate --no-claude. (4) It says in the README and in the claude-review.yml header that central-ref should match a pinned uses:.

I traced the new parsing against the real workflows and templates (profile: general # or plugin-wp…, the profile: input declarations in claude-review.yml/review-reply.yml, commented-out example lines). It picks the right value in each case, and the new cases cover it. The test_case setup strings use no parent-shell variables (wf output is expanded at call time), so moving them into a child bash -c is safe. I could not run --test in this environment, so I only reasoned about it; the CI scripts job will settle it.

Small description nit: it says three new test cases, but the diff adds four (the flow-style profile: { type: string } case is not counted).

No security, permissions or pinning changes. Rated high only because it sits on the policy's high-risk paths.

• minor scripts/local-review.sh:95: review_case still builds its scratch repo inside $( … ) && … with errexit off, the same broken-setup blind spot this PR fixes in test_case
• minor .github/workflows/review-reply.yml:32: The 'pin uses: means same central-ref' note is only in claude-review.yml's header; review-reply.yml and conventions.yml also take central-ref

_{Policy floor: high (touches high-risk paths: .github/workflows/claude-review.yml, README.md, scripts/local-review.sh). Reviewed 241b8f3 (whole pull request; review 1 of 5 automatic). Author trusted for auto-merge: true.}

_{🤖 AI review · claude-opus-5-5 (Anthropic) · $0.35, 8 turns}