[Deicyde]

Two small follow-ups from the re-reviews of #71 and #68. Release-neutral (.github/ and site/ops/), so it can merge while release B is built.

• brain-canary.yml: retry the selector probe. The selector step made one attempt, so a single transient edge error failed the daily run, while the canary step after it already rides out errors with --timeout 120. The probe now tries three times, 10 s apart, and retries only brain_http.TransportError. A 404 or an invalid selector still fails at once.
• .gitattributes is release-affecting. It leaves NEUTRAL_FILES. No such file exists on main. But a committed root .gitattributes with eol or working-tree-encoding rules would change the bytes a fresh promotion worktree checks out for wiki/src, while git diff --name-only showed only .gitattributes and the policy let it through. The policy test now lists it as release-affecting. No recorded neutral_changes can contain it, because the file has never existed.

Checks: the workflow parses as YAML, and the selector's Python compiles. Under the changed policy .gitattributes is affecting and .gitignore is still neutral. This PR touches the workflow, so CI and the canary both run on it; the canary only reads production.

[Deicyde]

Verdict: merge after release B is promoted. Nothing blocks merge.

One static review, with each substantive finding checked by two refuters:

• The retry is bounded: three tries, two 10 s sleeps and 20 s per request, inside the job's 10-minute limit.
  • Only transport errors are retried. A 404 (probe.missing) and a malformed selector fail at once, and after three failures the step exits non-zero with the error text.
  • A transient error that recovers leaves the step green, so nothing alerts.
  • On this PR the canary logged live selector: sha256:8305822b... with no retry, and the python job ran test_brain_release_authority (10 tests, OK).
• .gitattributes belongs with the release-affecting files, because its checkout eol and encoding rules change working-tree bytes under wiki/src. All three changed paths are neutral under both the head's and main's policy module, so the PR itself needs no rebuild. It merges cleanly into main 3c1139f.

Notes (none blocks merge):

1. Timing wording. "Release-neutral, so it can merge while release B is built" was true when written. Now that B's P1B is pinned at main 3c1139f, a merge before promotion forces a fresh P1B, though not a rebuild (docs/BRAIN-RELEASE-RUNBOOK.md:301-303). Hold it until promotion, as the WikiLean 2 session plans.
2. A stale copy of the neutral list. docs/BRAIN-ACTIVATION-2026-10-04.md:129-131 still lists .gitattributes as neutral. That paragraph has picked up earlier policy changes (Release policy: AGENTS.md and CONTRIBUTING.md are release-neutral #68, site/ops: the reducer's bot/state inputs are release-affecting #75), so drop it there and note that Canary: retry the selector probe; .gitattributes is release-affecting #105 made it release-affecting. The module stays the authority either way.
3. Policy label. POLICY stays at v2, and its comment does not mention this change, unlike the v1-to-v2 change. Nothing reads it, so this is labelling only.

Posted by Claude Code (AutoformBot "Merge Currently Open PRs 4" session).