@@ -264,21 +264,31 @@ jobs:
           # `##[error]`; the run still concluded success, so what this costs is a red mark on
           # a green check, not a broken review.
           #
-          # Which blocks can carry one is decided by whether the text arrives with a line
-          # prefix. The CI excerpt cannot: `/actions/jobs/{id}/logs` prefixes every line with
-          # a timestamp, so a marker inside a fetched log is mid-line and was never a command
-          # (tests/fixtures/job-log-django.txt keeps that shape deliberately). The blocks that
-          # can are the ones quoting text verbatim -- PR title and body, review comments, the
-          # PR conversation, and the diff, where an unchanged context line is rendered with a
-          # single leading space and the runner trims before it parses.
+          # The two spellings are not parsed the same way, and the difference decides the fix.
+          # Run 31025325888 settles it -- one review whose diff carried both forms on `+`
+          # prefixed lines:
           #
-          # Prefixing the line is the whole fix -- the parser only looks at the start of one
-          # -- and it keeps the marker visible, which matters when the text the reviewer is
-          # reading is *about* an error line.
+          #   `+##[error]this is not really an error`  -> the `+` was consumed, annotation fired
+          #   `+::error::neither is this`              -> the `+` survived, nothing fired
+          #
+          # So `::command::` is matched only at the start of a trimmed line, while `##[...]`
+          # is matched *anywhere in the line*. Every one of that run's seven annotations was a
+          # `##[error]` and none was a `::`. A leading `+`, a timestamp, or a markdown backtick
+          # is therefore no protection at all for the `##[` form -- which is why the CI excerpt
+          # is the most reliable source of these, not an exempt one: it fetches the window
+          # around `##[error]` from a log whose every line the API has already timestamped.
+          #
+          # Hence two rules. `##[` is broken wherever it appears, by one space, because the
+          # lines carrying it are usually source or log text and restructuring them would
+          # misrepresent the file the reviewer is reading. A line-leading `::` gets the visible
+          # marker instead: there the whole line was the command, so there is no file content
+          # to preserve. Both keep the text legible, which matters because the reviewer is
+          # often reading an excerpt that is *about* an error line.
           neutralise_untrusted() {
             perl -pe '
               s{< \s* /? \s* (?: pr_context | prior_review_comments ) [^>]* >}{[block tag removed]}gix;
-              s{^ (\s*) (?= :: | \#\# \[ )}{${1}[log marker neutralised] }x;
+              s{\#\# (?= \[ [A-Za-z] [^\]]* \] )}{## }gx;
+              s{^ (\s*) (?= :: )}{${1}[log marker neutralised] }x;
             '
           }
 
 
@@ -49,13 +49,22 @@ block delimiters are neutralised by shape rather than by exact string: `</pr_con
 them would otherwise end the data block early and land the rest where it reads as instructions.
 
 The same text gets a second treatment for a different sink. The action echoes the assembled prompt
-into the job log line by line, and GitHub reads a log line starting with `::` or `##[` as a *workflow
-command* — so a marker in a PR body, a review comment, or a diff context line writes an annotation
-onto the review's own check run. One run carried two `failure` annotations whose text was prose from
-a review comment discussing `##[error]`. Such a line is prefixed rather than stripped: the parser
-only looks at the start of a line, and the marker stays legible for a reviewer reading text that is
-*about* an error. The CI excerpt is exempt by accident — the logs endpoint timestamps every line, so
-markers inside a fetched log are mid-line and were never commands.
+into the job log line by line, and GitHub reads a workflow command in that log as a *command* — so a
+marker in a PR body, a diff hunk, a CI excerpt, or a review comment writes an annotation onto the
+review's own check run. One run carried two `failure` annotations whose text was prose from a review
+comment discussing `##[error]`.
+
+The two spellings are not parsed alike, and one review settled which is which: its diff carried both
+forms on `+` prefixed lines, the `+` was consumed on `##[error]` and survived on `::error::`, and all
+seven annotations were the former. So `::command::` is matched only at the start of a trimmed line,
+while `##[...]` is matched anywhere in one — a leading `+`, a timestamp, or a markdown backtick
+defuses nothing. That makes the CI excerpt the most reliable source of these rather than an exempt
+one, since it fetches the window around `##[error]` from an already-timestamped log.
+
+So `##[` is broken by a single space wherever it appears — those lines are usually source or log text
+and restructuring them would misrepresent the file being reviewed — while a line-leading `::` gets a
+visible `[log marker neutralised]` prefix, because there the whole line was the command. A mid-line
+`::` is left alone, which keeps every `std::collections::HashMap` in a Rust diff intact.
 
 ### Tool usage artifact
 
 
@@ -9,10 +9,11 @@ This prompt includes:
 
 Everything in `<pr_context>` is already in front of you. Do not spend a tool call re-fetching it.
 
-Two markers in that content were inserted by the workflow, not written by anyone: `[block tag
-removed]` replaces a block delimiter, and `[log marker neutralised]` prefixes a line that would
-otherwise have been read as a GitHub Actions command. Both are sanitiser output. Read past them, and
-never quote one as if it were in the file — if you need the real line, `Read` the file.
+Three edits in that content were made by the workflow, not by anyone: `[block tag removed]` replaces
+a block delimiter, `[log marker neutralised]` prefixes a line that would otherwise have been read as
+a GitHub Actions command, and `##[` is respaced to `## [` for the same reason. All three are
+sanitiser output. Read past them, and never quote one as if it were in the file — a `## [error]` in a
+CI excerpt was `##[error]` in the real log. If you need the exact line, `Read` the file.
 
 **Unless it is not there.** If `<pr_context>` is empty, or a block inside it says it could not be read, then that block is genuinely missing — fetch what you need yourself with `gh pr diff` or `gh pr view`, and say in your review that you reviewed without it. Never treat a missing block as evidence: an absent CI block does not mean CI is clean, and an absent diff does not mean nothing changed.
 
 
@@ -348,12 +348,16 @@ expect_context '\[block tag removed\]' "the defused delimiter leaves a visible m
 # --- Actions workflow commands in untrusted text ----------------------------------------
 
 # The other injection sink, and the one nobody was looking at: the action echoes the
-# assembled prompt into the job log line by line, and Actions reads a line beginning with
-# `::` or `##[` as a *command*, not as text. A marker in a PR body, a diff hunk or a review
-# comment therefore writes an annotation onto the review's own check run -- run 30964274400
-# has two `failure` annotations whose text is prose from a review comment about `##[error]`.
-# Every form below is one Actions parses: both syntaxes, and indented, because the runner
-# trims the line before it looks.
+# assembled prompt into the job log line by line, and Actions reads a workflow command in it
+# as a *command*, not as text. A marker in a PR body, a diff hunk or a review comment
+# therefore writes an annotation onto the review's own check run -- run 30964274400 has two
+# `failure` annotations whose text is prose from a review comment about `##[error]`.
+#
+# The two spellings are matched differently, which run 31025325888 established directly: its
+# diff carried both forms on `+` prefixed lines, and only the `##[` form fired. The `+` was
+# consumed there and survived on the `::` lines, so `##[...]` is matched anywhere in a line
+# while `::command::` is matched only at the start of a trimmed one. Every form below is one
+# of those two, in the positions that distinguish them.
 LOG_INJECT='Fixes the thing.
 
 ##[error]this is not really an error
@@ -364,20 +368,22 @@ LOG_INJECT='Fixes the thing.
 ::stop-commands::endtoken
 ::endgroup::
 
-Both fixtures carry exactly one `##[error]` marker, mid-line, which is not a command.'
+Both fixtures carry exactly one `##[error]` marker, which a backtick does not defuse.
+An unchanged diff line reads ` ::error::x`, and a Rust path reads std::collections::HashMap.'
 
-# markers_at_line_start <file> -- the lines Actions would still execute
-markers_at_line_start() {
-  grep -nE '^[[:space:]]*(::|##\[)' "$1" || true
+# parsable_markers <file> -- the lines Actions would still execute: a `##[cmd]` anywhere,
+# or a `::` at the start of a trimmed line.
+parsable_markers() {
+  grep -nE '##\[[A-Za-z][^]]*\]|^[[:space:]]*::' "$1" || true
 }
 # expect_no_markers <file> <description>
 expect_no_markers() {
   local found
-  found=$(markers_at_line_start "$1")
+  found=$(parsable_markers "$1")
   if [ -z "$found" ]; then
     echo "ok   $2"
   else
-    echo "FAIL $2: a workflow command survives at line start:"
+    echo "FAIL $2: a workflow command survives in a parsable position:"
     printf '%s\n' "$found" | sed 's/^/       /'
     failures=$((failures + 1))
   fi
@@ -388,45 +394,48 @@ expect "$(cat "$WORK/code.txt")" "0" "step exits 0 on text carrying workflow com
 expect_no_markers "$CTX_FILE" "workflow commands in the PR body are neutralised"
 expect_no_markers "$THREADS_OUT" "workflow commands in a review comment are neutralised"
 
-# Neutralised, not deleted, and this block is the reason the distinction matters more here
-# than for the block tags: the CI excerpt exists to show the reviewer an error line, so
-# stripping `##[error]` would remove the thing it was fetched for.
-expect_context '\[log marker neutralised\]' "the defused marker leaves a visible marker"
-expect_context 'this is not really an error' "the text after the marker is kept"
-expect_context '::error::neither is this' "the marker itself is still legible to the reviewer"
+# Neutralised, not deleted, and the CI excerpt is why the distinction matters more here than
+# for the block tags: that block exists to show the reviewer an error line, so deleting
+# `##[error]` would remove the thing it was fetched for.
+expect_context '## \[error\]this is not really an error' \
+  "a mid-line ##[ is broken by a space and stays readable"
+expect_context '\[log marker neutralised\] ::error::neither is this' \
+  "a line-leading :: is prefixed and stays readable"
+expect_context '`## \[error\]` marker' "a ##[ inside backticks is broken too"
 if grep -q 'log marker neutralised' "$THREADS_OUT"; then
-  echo "ok   the threads output carries the same visible marker"
+  echo "ok   the threads output is sanitised the same way"
 else
   echo "FAIL the threads output was not sanitised"
   failures=$((failures + 1))
 fi
 
-# A line that merely *contains* a marker was never a command, and prefixing it would be
-# noise in the one block most likely to discuss one.
-expect_context 'carry exactly one .*##\[error\].* mid-line' "a mid-line marker is left alone"
-mid=$(grep -c '\[log marker neutralised\].*mid-line' "$CTX_FILE" || true)
-expect "$mid" "0" "a mid-line marker is not prefixed"
-
-# The CI excerpt is the block that looks like the worst offender and is not one: the logs
-# endpoint prefixes every line with a timestamp, so `##[error]` inside a fetched log is
-# mid-line and was never a command. That is a property of the fixture as much as of the
-# endpoint, so assert it here -- a fixture rewritten without the timestamps would make this
-# suite pass on a log shape production never sees, and would quietly retire the assertion
-# above about mid-line markers being left alone.
+# The other half of the rule, and the half that keeps the diff readable: `::` mid-line was
+# never a command, so it must survive untouched. Every Rust, C++ and PHP diff is full of it,
+# and a sanitiser that rewrote those would corrupt the largest block in the context.
+expect_context 'std::collections::HashMap' "a mid-line :: path is left alone"
+mid=$(grep -c 'log marker neutralised.*HashMap' "$CTX_FILE" || true)
+expect "$mid" "0" "a mid-line :: is not prefixed"
+
+# The CI excerpt is the most reliable source of these rather than an exempt one. Its lines
+# arrive already timestamped by the logs endpoint, which is no protection: the timestamp puts
+# `##[error]` mid-line, and mid-line is exactly where the `##[` form is still parsed. The
+# fixture keeps that shape, so this asserts the real production path.
 unset STUB_THREAD_BODY
 PR_BODY='Adds a watermark.' run_step > /dev/null
-expect_no_markers "$CTX_FILE" "the failing job log carries no marker at line start"
+expect_no_markers "$CTX_FILE" "markers from the failing job log are neutralised"
 expect_context 'ending at the first error' "the error window is still labelled"
+expect_context '## \[error\]Process completed' "the log's own error line is still readable"
 if grep -qE '^2[0-9]{3}-[0-9]{2}-[0-9]{2}T[0-9:.]+Z ##\[error\]' tests/fixtures/job-log-django.txt; then
   echo "ok   the job log fixture keeps the timestamp prefix the API adds"
 else
-  echo "FAIL the job log fixture lost its timestamp prefix, so the line-start assertion" \
-    "above no longer reflects a real job log"
+  echo "FAIL the job log fixture lost the timestamp prefix a real job log has, so the" \
+    "assertion above no longer covers the production shape"
   failures=$((failures + 1))
 fi
 
-# The diff is the largest block and the one an author controls by committing a file, not by
-# writing a comment. `+::error::x` is shielded by the `+`; an unchanged line beside it is not.
+# The diff is the largest block and the one an author controls by committing a file rather
+# than by writing a comment. An unchanged line is rendered with one leading space, so it
+# reaches the log as a line-leading `::` even though an added line's `+` would shield it.
 STUB_DIFF_MARKER=1 run_step > /dev/null
 expect_no_markers "$CTX_FILE" "a marker on a diff context line is neutralised"
 expect_context 'a context line in a source file' "the diff line itself is kept"