feat(coding): quote the body's trigger paragraph in label findings (#331)

[shadowbrush]

Closes #331.

When a check's edge label is empty or isn't a condition, the text that should be in the label is usually sitting a few lines away in the node body. The finding now quotes it.

Live, against the memory that motivated the issue (hadron-memory/hadron-server#845):

review:entity-ref-args  error  label-is-condition
  edge label is the bare stem "Applies when" with no condition after it — the body
  states its scope, condense it into the label: "Adding or renaming a GraphQL argument
  (query OR mutation) that identifies an existing entity, or widening an existing arg
  to accept a URN. Skip for arguments…"

Quoted, not promoted

This is the part #331 exists to get right. Two body conventions are recognised, measured across all 90 review checks in the four memories that have them:

	count
> **Scope.** …	55
line-initial **Applies when** …	2
neither	33

So a trigger is findable for ~63% of checks. The other third gain nothing — a "none found" line on every one of them would be noise.

And the text is not fed to --fix:

	min	median	p90	max
healthy edge labels (84)	32	84	142	179
> **Scope.** paragraphs	61	238	—	567
**Applies when** paragraphs	179	389	—	389

Promoting one verbatim would mint a label 3× too long and — since the edge loc is slugified from the name — an enormous derived loc with it. --fix still reads only the description, which must already read as a trigger. The quote truncates to 160 chars (just above the p90 healthy label, so what you see is roughly the size of the label being asked for); --suggest prints it whole.

Presentation only

A test asserts the hint changes neither which rules fire, their severities, nor the --fix plan — the same input with and without a body scope produces identical findings apart from the message text, and an identical fix plan.

No new rule, no severity change, no writes, and the --json contract is unchanged (the text goes in the existing message). Content costs no extra round trip either: the shared NodeBatch operation already selects it, so the bytes were on the wire before this change.

Verification

go test ./... — 16 packages green. make lint — 0 issues. gofmt -l . — clean (the new gate from #330 is live).

Read-only live runs:

hadron coding review lint -m hadronmemory.com::hadron-server   → 3 label errors, each now quoting its scope
hadron coding review lint -m hadronmemory.com::hadron-server --suggest  → full paragraphs
hadron coding review lint -m hadronmemory.com::hadron-cli      → ✓ 6 check(s) OK
hadron coding review lint -m hadronmemory.com::hadron-portal   → ✓ 24 check(s) OK

One thing worth noting: mmdata now reports 4 errors rather than the 3 recorded in the plan doc. That is new data, not a regression — review:exception-lists-not-patterns-in-ratchets was created 2026-07-31T19:01Z with a child-of label. I confirmed by running the pre-change binary built from merged main, which reports the same 4.

🤖 Generated with Claude Code

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[Copilot]

Pull request overview

This PR enhances the hadron coding review lint UX by appending a quote from a check node’s body when label-related findings fire, so the likely intended trigger text is visible directly in the lint output (without changing rule behavior, severities, --fix behavior, or the --json shape).

Changes:

• Add body parsing to extract a “trigger/scope paragraph” from node content (> **Scope.** … or line-initial **Applies when** …) and append it to label-present / label-is-condition finding messages (truncated by default, full with --suggest).
• Extend the lint model to carry node Content from NodeBatch, and add a --suggest flag to control truncation.
• Add unit tests covering body-trigger extraction, “stays quiet” behavior when no trigger is present, and determinism/--fix non-interference.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
internal/cmd/coding/review_lint.go	Adds --suggest plumbing and appends body-derived trigger hints to label findings.
internal/cmd/coding/review_lint_test.go	Adds tests ensuring label findings quote body trigger text and remain behaviorally deterministic.
internal/cmd/coding/coding.go	Extends checkNode to include Content and populates it from NodeBatch results.
internal/cmd/coding/bodytrigger.go	New helper for extracting and truncating/quoting trigger paragraphs from node body content.
internal/cmd/coding/bodytrigger_test.go	New unit tests for body-trigger parsing and truncation behavior.
internal/cmd/agentic/agentic-usage.md	Updates CLI usage synopsis to include --suggest for coding review lint.
docs/plans/coding-command-group.md	Updates the plan doc with the new behavior and correct rule naming reference.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[shadowbrush]

Correct — fixed in 21f1b04. The regex makes the > optional but bodyTrigger hardcoded quoted=true, so a plain **Scope.** paragraph lost everything after its first line.

Continuation now follows the line actually matched:

quoted := strings.HasPrefix(strings.TrimSpace(ln), ">")
return joinParagraph(m[1], lines[i+1:], quoted)

Worth noting it's latent rather than biting: I checked all four memories and every one of the 57 Scope markers is blockquoted, 0 plain. So nothing changes on today's data — but the regex and the continuation logic genuinely disagreed, and that's the kind of thing that surfaces the first time someone writes the marker without the >. TestBodyTriggerPlainScopeWraps covers both forms, including that the blockquoted one still stops at the end of its blockquote.

[shadowbrush]

Fair — fixed in 21f1b04. fetchNodes now takes wantContent bool: review lint passes true, preflight lint false.

To be precise about the cost, since it shaped how I framed it in the PR: the bytes were already on the wire either way — the shared NodeBatch operation selects content unconditionally, so this was never extra I/O. What it did do was retain a body per route target in the checkNode map for the run instead of letting it go with the response, which on mmdata's 71 routes is real if not dramatic. Opting out is free and makes the intent explicit, so it's worth doing regardless.

TestCodingFetchNodesContentIsOptIn asserts both directions: review lint quotes the body scope, preflight lint never surfaces it given the identical payload.

[shadowbrush]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ddc5a47742

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Compare the word boundary in rune units

For non-ASCII scope text, LastIndexAny returns a byte offset while n*3/4 is a rune count. A 160-rune CJK trigger whose last space occurs after 50 CJK characters therefore treats byte offset 150 as being near the 160-rune limit and truncates the suggestion to roughly 50 runes. Convert the boundary offset to a rune count before applying the 75% threshold so multilingual hints retain the intended amount of context.

Useful? React with 👍 / 👎.

[shadowbrush]

Confirmed and fixed in 21f1b04. I reproduced it before changing anything:

input runes=251  output runes=51     // truncateRunes(s, 160)

with s = strings.Repeat("経", 50) + " " + strings.Repeat("路", 200) — exactly your scenario. The space sits at rune 50, byte offset ~150, which passes 150 > 120 and cuts a 160-rune request down to 51.

Both the search and the threshold are now in runes:

cut := r[:n]
for i := len(cut) - 1; i > n*3/4; i-- {
    if cut[i] == ' ' || cut[i] == '\t' { cut = cut[:i]; break }
}

TestTruncateRunesNonASCIIKeepsContext covers it and asserts ASCII word-boundary behaviour is unchanged. My existing test missed this because it used strings.Repeat("é", 50) with no space in it, so the backoff branch never ran.