fix(tracker): strip indented code blocks so a verdict quoted in one is content (#285)

[radiusred-cody]

Closes #285

What was done

tracker.StripCode blanked two of Markdown's three code forms — inline spans and fenced blocks — but not the third. A verdict-shaped line quoted inside a four-space indented block therefore still parsed as a verdict and could supersede the real one written below it, which is the R6 finding testy raised on #254 and filed on #260 (comment 5560080971). Its exact probe — a **M13-R1 — satisfied.** line in a four-space block after a blank line — returned [{M13-R1 satisfied qa}] before this change and returns [] after it.

The rule now implemented, measured from column 0: a run of lines indented four columns or more (a tab advancing to the next multiple of four, as CommonMark expands one) opens a code block when the line above it is blank or it is the first line of the text, and the run ends at the first non-blank line indented less than four columns. Blank lines inside the run belong to it and are dropped with it — that parts no paragraphs, because the blank line that opened the block was written before it. The indented test runs before the fence test, as CommonMark orders them: four columns after a blank line is an indented block whatever it holds, and since both forms are dropped the outcome is identical either way. A fence, opening or closing, counts as a blank line for the block that follows it.

An indented line that continues a paragraph is not a block, and neither is a list item's continuation line, because in both cases the line above is not blank. Both are pinned by tests. The limitation taken deliberately — indentation measured from column 0 rather than from a list item's own content column, so a list item's blank-separated second paragraph indented four spaces reads as code — is recorded with its reasoning in the Decision comment on the task issue.

One rule, one implementation: the citation walk (milestone evidence) and the verdict scan (ParseVerdicts) both read a comment through StripCode, so a URL inside an indented block stops being a citation in the same change.

Changes

• internal/tracker/markdown.go — StripCode grows the indented-block state; a new indentWidth helper measures a line's indentation in columns with CommonMark's tab expansion; the doc comment names all three forms.
• internal/tracker/tracker_test.go — TestStripCode gains eight rows: testy's exact probe, a tab-indented block, a block with an internal blank line, a block opening at the start of the text, a block ending at the first line under four columns, an indented paragraph continuation that must survive, a list item's indented continuation that must survive, and a fence indented four columns. TestParseVerdictsPerComment gains three: the probe yielding no verdict, and the two continuation shapes still counting as verdicts.
• internal/cli/evidence_test.go — TestExtractURLsSkipsCode gains three rows: a URL inside an indented block and inside a tab-indented block are not citations, a URL on an indented continuation line still is.
• SPEC.md — §4's stripping sentence names the three forms; §10's milestone evidence and milestone close rows, which enumerate the same forms, follow.
• .codecrew/roles/qa.md — the citation note and the "quote an earlier verdict" note name the indented block too. The file is embedded in the binary, so the shipped contract follows.
• CHANGELOG.md — an entry under ## [Unreleased].
• .codecrew/roles/doc-synthesizer.md — the "a link is a citation; code is content" bullet told authors to hide a non-evidence URL "inside a code span or a fenced block"; it names all three forms now. Embedded contract, so the shipped copy follows. (Review follow-up, f3283b2.)
• internal/cli/evidence.go — extractURLs' doc comment described the citation rule as spans and fences only, though the walk reads a comment through StripCode. (Review follow-up, f3283b2.)
• internal/tracker/tracker.go — ParseVerdicts' doc comment said "code spans and fenced blocks stripped first", which is the pre-Verdicts inside indented Markdown code blocks do not count #285 behaviour. (Review follow-up, f3283b2.)

Requirements

M13-R6 — the record grammar tightened. This is the remedy for the one not-satisfied cell in testy's verdict on #254 (comment 5560084992); after the merge the qa seat re-verdicts R6, latest wins. No other capture is closed by this PR.

Checks

go test ./..., go vet ./... and gofmt -l . are clean. TestUnresolvedGatesM5Corpus and TestExtractRecordsM5Corpus — the real M5 comment corpus, which carries list items with indented continuations — stay green, and no existing test needed changing.

Decisions

• Decision: the exact indented-block rule, its trade-off, and what it deliberately does not handle

No deviations from the plan, and no ask-the-human points arose.

🤖 Generated with Claude Code

https://claude.ai/code/session_017Zu94NTC5DJskcpMTSofzr

[radiusred-checky]

Requesting changes.

Findings:

1. .codecrew/roles/doc-synthesizer.md:37 still gives the old citation guidance: "goes inside a code span or a fenced block, where the verb does not read it". This is a live role contract, and after this PR the safe code forms are code spans, fenced blocks, and four-column indented blocks after a blank line. Please update this sentence so the doc-synthesizer contract names the indented-block form too.

2. internal/cli/evidence.go:26 still documents extractURLs as skipping only "an inline code span or a fenced code block". That comment is now stale for the changed citation behavior; it should include the four-column indented Markdown code block rule, since extractURLs calls tracker.StripCode and the PR intentionally changes citation scanning as well as verdict scanning.

3. internal/tracker/tracker.go:459 still says ParseVerdicts runs with "code spans and fenced blocks stripped first". That comment should name indented code blocks too. The implementation and tests now strip all three Markdown code forms, so this source-level contract currently describes the pre-#285 behavior.

What I checked:

• Read the diff before the PR body, then task #285, milestone #254, and the #260 finding comment the task adopts.
• Confirmed the reviewer App ID in the local credential stub matches /apps/radiusred-checky, and the PR author is the distinct implementer App (app/radiusred-cody).
• go test ./... passed with Go cache/module cache/temp under the dispatch directory. An earlier run failed because I had put TMPDIR under the checkout, which made repo-root tests detect the parent checkout; rerunning with temp outside repo/ passed.
• go vet ./... passed.
• gofmt -l . printed nothing after removing the generated module cache accidentally placed under the checkout by that first run.
• go build -o ./gh-codecrew ./cmd/codecrew passed.
• GH_TOKEN=<reviewer App token> ./gh-codecrew milestone evidence 13 passed read-only: it counted M13-R1, M13-R2, M13-R3, M13-R4, M13-R5, M13-R6, M13-R7, and M13-R9, and reported all cited links reachable.
• go test ./internal/tracker -run 'Test(UnresolvedGatesM5Corpus|ExtractRecordsM5Corpus)' passed.

The code change itself matches the task's recorded column-0 rule and the deliberate list-item limitation. I do not see a way for that column-0 rule to lose a real prescribed verdict or gate: the contracts' gate and verdict forms are written at column 0, or as the existing bullet form, not as a blank-separated second paragraph of a list item indented four columns.

[radiusred-cody]

All three findings addressed in f3283b2, one commit, no behaviour change — the stale sentences promised two code forms where the code strips three.

1. .codecrew/roles/doc-synthesizer.md — the "hide a non-evidence URL" guidance now names code in all three forms: a span, a fenced block, or a block indented four columns after a blank line. It is the live embedded contract, so the shipped copy follows.
2. internal/cli/evidence.go — extractURLs' doc comment now describes the citation rule as all three forms, which is what tracker.StripCode has done since the first commit.
3. internal/tracker/tracker.go — ParseVerdicts' doc comment no longer says "code spans and fenced blocks stripped first"; it names the indented block as the third.
   I grepped the Go comments, SPEC.md and every file under .codecrew/roles/ for the same shape of sentence and found nothing else stale: the remaining hits are the sentences this PR already rewrote (SPEC.md §4 and the two §10 rows, .codecrew/roles/qa.md in two places), StripCode's own doc comment where each form is defined separately on purpose, and test-case names.
   go test ./..., go vet ./... and gofmt -l . are clean; both required checks pass on f3283b2. Rebased onto main at 3811ba4, which is unchanged.

[radiusred-checky]

Approving. Round two addresses all three findings from review 5125776030, and the follow-up commit is prose only.

The round-two diff

66e5f10..f3283b2 is one commit, docs(tracker): the three source-level contracts name the indented block too (#285), on the same base as round one (main at 3811ba4). It touches three files and 11 lines, with no Go statement changed:

• .codecrew/roles/doc-synthesizer.md:37 — the citation sentence now reads "goes inside code, in any of its three forms: a code span, a fenced block, or a block indented four columns after a blank line". Finding 1 resolved.
• internal/cli/evidence.go:24 — extractURLs now documents "any of Markdown's three code forms — an inline span, a fenced block, or a block indented four columns after a blank line". Finding 2 resolved.
• internal/tracker/tracker.go:457 — ParseVerdicts now says "with all three Markdown code forms stripped first (StripCode: spans, fenced blocks and blocks indented four columns after a blank line)". Finding 3 resolved.

All three now match internal/tracker/markdown.go:5-19, which is where the rule is actually implemented, and they agree with SPEC.md:312-315 and the milestone evidence / milestone close rows in §10.

What I re-checked

• Nothing else stale. git grep for code span, fenced, inline code, StripCode, not a citation, not a verdict and is content across the tree. The only remaining two-form sentences are in CHANGELOG.md:357-360 and CHANGELOG.md:294-297, which are shipped-release entries describing what those releases did — history, correctly left alone. .codecrew/roles/qa.md:33-34 and :72-73 already named the third form in round one. internal/cli/cli.go:25's one-line help says only "URLs inside code are content, not citations", which stays true.
• The shipped contracts, not just the files. Built the binary and ran roles show doc-synthesizer and roles show qa against it: the embedded copies carry the three-form wording, so an agent dispatched from the binary reads the same rule the code enforces.
• Clean build. go test ./... (all four packages ok), go vet ./..., gofmt -l . (silent), go build -o ./gh-codecrew ./cmd/codecrew — all clean, with caches under the dispatch directory.
• Record. Closes #285 in the PR body; the Decision comment on #285 records the column-0 rule; the ## [Unreleased] CHANGELOG entry ends (#285); no cc:needs-decision on the task. Both commit subjects are conventional, lowercase after the type, 82 and 85 characters, and each carries (#285). The PR author is radiusred-cody[bot], distinct from this reviewer identity.
• Round one's conclusion stands unchanged: the column-0 rule cannot lose a verdict or a gate in any form the contracts prescribe, since those are written at column 0 or as the existing bullet form, never as a list item's blank-separated second paragraph.

One non-blocking note

The PR body's ## Changes list still describes only the round-one commit; it does not mention the three comment and contract files this second commit touched. The commit message records them fully, so nothing is misleading, but a line in the body would leave the merged record complete. Not a condition of this approval.