Follow-up: deferred review findings from PR #525

[philcunliffe]

Follow-up from the TRIAGE rung (LLP 0017) on PR #525 (repo-wide em-dash sweep,
fix/issue-472, head 6021713). Two review rounds are exhausted; every
residual below was judged non-blocking (a production-defect risk was not
found for any of them), so the PR is being carried through to ready-hold
rather than parked on neutral:stuck. Filed so the deferred items stay
tracked instead of silently dropped.

Backlink: PR #525.

Why non-blocking as a set: this PR touches no runtime code at all — every
changed line is a comment, JSDoc, or doc-prose line (confirmed independently
in review round 2: src/ has zero executable-line changes). The
letters-unchanged proof (2504 aligned substitution pairs, 0 word changes) and
the anchor-repointing check (all 90 moved heading slugs, all 34 call sites)
both held under adversarial review across two rounds. Nothing here can
propagate into a runtime defect.

Residuals

1. test/core/house-style-em-dash.test.js scans git ls-files, so an
   untracked file is invisible to the gate. (test/core/house-style-em-dash.test.js:47)
   By design CI only ever sees committed trees, so this does not let an
   em dash reach a merged PR, but it is a real blind spot for an em dash
   introduced in a file staged-but-not-yet-tracked during local dev. Consider
   whether the gate should also check git status --porcelain for untracked
   non-ignored files, or whether that's overkill for a style lint.
   Preference / non-blocking.

2. CLAUDE.md is a symlink to AGENTS.md, so the gate's fs.readFileSync
   reads the same bytes twice (once as AGENTS.md, once by following the
   CLAUDE.md symlink). Purely cosmetic double-work in the scan; content is
   byte-identical by construction of the symlink, so it cannot produce a false
   pass or false fail. Preference / non-blocking, not worth fixing unless the
   scan's runtime becomes a problem.

3. notes-archive/ (2 files, 38 em-dash-bearing lines) is excluded from the
   sweep and the gate, on the grounds that the two files
   (notes-archive/llp-reviews/remote-config-join-flow.spec.round-1.claude.md,
   notes-archive/llp-reviews/login-auto-provision-forward-sink.decision.round-1.claude.md)
   are dated, signed review transcripts (**Date:** 2026-06-12 /
   **Date:** 2026-07-04, **Reviewer:** Claude (Fable 5)) — records of what
   a reviewer wrote on a given day, not maintained project prose. Verified: the
   dates and signatures are real, the exclusion is a visible, commented prefix
   list in the gate (test/core/house-style-em-dash.test.js:31-44), and the
   line count matches (grep -c em dash across both files = 21 + 17 = 38).
   Judged correct, not merely non-blocking — repunctuating a signed transcript
   would falsify the record it exists to preserve. No action needed.

4. The LLP-immutability scope call: the sweep repunctuates llp/ including
   llp/tombstones/. This is the residual most likely to be wrong, so it
   deserves a human's eye even though it is being classified non-blocking.
   AGENTS.md:29-34 (the source convention, mirrored in the
   <!-- neutral:llp-conventions --> block later in the same file) reads:
   "Once an LLP is Accepted or Active, do not edit what it settled...
   Mechanical edits are still fine: typos, broken links, status changes, and
   renumbering that does not change meaning (LLP 0156)." The operative
   test is "does not change meaning," and the sweep's own proof is exactly
   that: 2504 aligned substitution pairs across the whole corpus (including
   llp/tombstones/) with zero word changes, verified independently in both
   review rounds, plus all 90 moved heading anchors repointed at all 34 call
   sites (spot-checked again during triage; no stale slug references remain).
   Judged within the convention's actual text. If the maintainer reads
   "Accepted/Active is a record" more strictly than "meaning-preserving
   mechanical edits are fine," this is the one clause to push back on — but as
   written it does not block.

5. Two interruptive spans deliberately kept their commas rather than
   taking the round-2 parenthesization fix:
   llp/0063-login-auto-provision-forward-sink.decision.md:86
   (The product intent, "log in, logs flow", is served by neither — a
   quoted appositive, correctly left alone) and
   llp/0041-central-config-client-actions.design.md:8 (already inside
   parentheses, so nesting was unavailable; took a colon instead of a comma
   pair). Spot-checked against the current head; both read correctly as-is.
   No action needed.

Merge-ordering note (restated, not re-derived)

The orchestrator already posted a merge-ordering note on PR #525: this branch
overlaps 10 of the 11 other open branches and repunctuates headings, moving 90
anchor slugs. A sibling branch that adds a new @ref to an old slug would
merge cleanly at the text level (git cannot see the conflict) and then fail
ref-check — a semantic conflict, not a textual one. Recommendation stands:
land PR #525 last, after the in-flight fix PRs settle, so no sibling branch
pays a rebase plus an @ref re-audit.

[philcunliffe]

🤖 neutral: stuck - blocked until PR #525 merges (not a failed attempt)

The issue-fix rung did not dispatch a worker. The code this issue's findings concern lives only on the unmerged fix/issue-472 branch, so a branch off today's master has nothing to edit.

Verified: the gate this issue's residuals are about, test/core/house-style-em-dash.test.js, does not exist on origin/master. Residuals 1 and 2 (the gate scanning git ls-files so untracked files are invisible; CLAUDE.md being a symlink to AGENTS.md so its content is scanned twice) are properties of a file that has not landed. Residuals 3, 4 and 5 (the notes-archive/ exclusion, the LLP-immutability scope call, the two deliberate comma-keeps) are judgements about a sweep that has not landed either.

PR #525 is currently held, green, reviewed and neutral:approved, waiting on a human merge. That is the blocker, and it needs no decision from you beyond merging when you are ready.

What happens next - automatically. Merge PR #525 and this issue becomes workable on the following tick; neutral re-observes from git every tick and will pick it up without being told.

Why this was not attempted anyway. A PR opened against master could not carry a reproduce -> root-cause -> fix cycle for findings whose subject code is absent, and its body would have to end in Fixes #532, closing an issue whose findings remain unaddressed.

This is the same shape as #511 and #531: a neutral:fix follow-up filed against a PR that has not merged yet is unworkable by construction until it does.

How to unstick: merge PR #525, or reply here; neutral monitors this thread and will re-engage on its next tick.

[philcunliffe]

neutral: re-triage at new head (LLP 0017) - PR #525 now at 0944215

The prior triage covered head 6021713. PR #525's head has since moved to
0944215 via a plain merge of origin/master (no rebase, no new sweep
commits), bringing in six PRs that landed on master after round 2:
#510 (OpenClaw full capture), #506, #513, #518, #520, #527
(fixes the leave command bug, issue #512), #537.

Verified the merge did not reopen or add anything blocking.

• The five residuals below are byte-identical between 6021713 and
  0944215 (git diff 6021713 0944215 -- <each file> is empty for all of
  them), so nothing here changes; see the residual list already filed on
  this issue.
• test/core/house-style-em-dash.test.js: 2/2 at 0944215.
  test/core/llp-ref-hygiene.test.js: 10/10.
  npm test: 3266 pass, 0 fail (the leave-command.test.js failures that
  were the "8 known baseline failures" through round 2 are gone: PR hyp leave: the daemon status query must answer, not throw #527
  fixed the underlying bug on master, and this merge inherits the fix).
  npm run typecheck: clean. All four GitHub Actions checks (test x2,
  typecheck x2, duplicate-numbers) are green on 0944215.
• One genuinely new thing happened in the merge, and it is correct. PR
  OpenClaw full capture (LLP 0157-0162) #510 added llp/0162-openclaw-full-capture.plan.md on master with 35
  em-dash-bearing lines (never swept, since OpenClaw full capture (LLP 0157-0162) #510 was authored against
  pre-sweep master). The merge commit 0944215 repunctuates that file using
  the same rules round 1/2 already verified for the rest of the corpus:
  colon after a label, comma where a colon would double up (e.g. **T1** — the steering plugin's core (Sections 1, 2, 2.1): package scaffold,
  became **T1**, the steering plugin's core (Sections 1, 2, 2.1): package scaffold,, a comma chosen specifically because the clause already carries
  a colon later on, exactly round 1's documented exception). Line count is
  unchanged (286 == 286), no word changed, and the one heading whose slug
  moved (## Rating complexity → the colon variant) has no in-repo
  linker (grep -rn "rating-complexity" across the tree: no hits). No new
  em dash exists anywhere in the tracked tree at 0944215 (the gate scan
  is authoritative on this, and it passes).
• Five new LLP docs landed via the same merge (0160, 0161, 0162,
  0164, 0166); none needed the notes-archive/-style exemption
  (they're new documents, not dated review transcripts) and all pass the
  em-dash gate as part of the same scan.

No new residual findings. Everything already listed on this issue still
applies, unchanged, at 0944215; nothing new surfaced in the merge itself.

Backlink: PR #525 (hyparam/hypaware#525), head 0944215ca07ae69b4f552c73afa0d16f6b430e9c.