Five more confirmed defects in the required merge contexts

[gHashTag]

Five findings survived refutation in the same adversarial pass over the four required contexts (8 candidates, 6 survived, 2 refuted). The sixth is fixed in #3336.

check — passes-a-defect

The shape reader's population is decided by git's rename heuristic: the identical malformed entry passes at 60% similarity and fails at low similarity

added_now_entries() uses git diff --diff-filter=A, and rename detection is on by default. A docs/now/ entry that arrives by rename is R, not A, so it leaves the population silently — the gate then reports "OK: 1 entr(y/ies) added, each well formed" over the one good entry while a file its own judge rejects lands on master. Worse, the escape is not a property of the entry: I built one PR twice, same resulting path docs/now/BAD-NAME.md, same - TBD body, same accompanying good entry. When the new file was 60% similar to a deleted entry git called it R060 and the required gate exited 0; when the content was dissimilar git called it A and the gate exited 1. The passing/refusing verdict on the same malformed artifact is set by a similarity ratio that has nothing to do with entry shape (and flips again on large diffs, where git skips inexact rename detection). Modifying an existing entry

Proposed repair: Smallest correct repair: one flag, in tools/check_now_entry_shape.py:68.

-        ["git", "diff", "-z", "--name-only", "--diff-filter=A", f"{base}...{head}",
+        ["git", "diff", "-z", "--name-only", "--no-renames", "--diff-filter=A", f"{base}...{head}",

--no-renames makes git report a rename as D(old) + A(new), so a docs/now/ path whose content newly lands at that path is in the population regardless of how similar it is to anything deleted. It overrides diff.renames from any config, so the population stops depending on a knob, and it sidesteps the rename-limit case too (whi

validate — passes-a-defect

The gate's parser accepts bare Infinity/NaN, which JSON does not — and one tracked file uses it today

conformance/vectors/gf16_conformance_v0.json carries 6 bare Infinity / -Infinity literals. Python's json module documents these as "an extension to the JSON specification" and accepts them, so the gate reports the file as parsing. RFC 8259 forbids them. Any consumer outside CPython either refuses the file or, worse, silently reads a different number: JSON.parse throws SyntaxError, and jq — present on every GitHub runner — parses it and substitutes ±1.7976931348623157e+308 (DBL_MAX). For a file the repo's own README calls "the original SSOT FPGA-oracle anchor pack (XC7A200T)", whose entire purpose is exact bit patterns, a silent DBL_MAX where the vector says pos_inf/neg_inf is a wrong answer with no error anywhere. The gate's own docstring asks "does every JSON file this repository ships actually parse"; for this file the answer is no, and the step named "No tracked JSON new

Proposed repair: Two parts. The gate repair is a one-liner; the file repair is what the newly-red gate then demands.

PART 1 — the gate (this is the actual defect fix), /private/tmp/claude-501/-Users-ssdm4-Desktop-PROJECTS-CLAUDE/9ba6bf38-825b-45d0-a349-e87b252815cd/wt-shell/tools/check_json_parses.py

Add a module-level helper and pass it at line 69:

def _reject_constant(name):
    """CPython accepts bare Infinity/-Infinity/NaN; RFC 8259 has no such literals.

    `json.loads` documents them as "an extension to the JSON specification", so
    CPython's acceptance is not evidence the file pars

validate — passes-a-defect

decode("utf-8", "replace") hides invalid UTF-8 — the exact consumer shape the gate was built to protect still raises

scan() reads bytes and decodes with errors="replace", turning any invalid byte into U+FFFD before parsing. A tracked .json file containing a raw non-UTF-8 byte inside a string therefore "parses" for the gate while json.load(open(p)) — literally the call the workflow header cites as its founding case (clara-bridge/tests/run_tests.py:152) — raises UnicodeDecodeError, and serde_json::from_slice / a strict TextDecoder refuse the bytes outright. The gate would pass the next clara-bridge, in the one file-encoding flavour it cannot see. No such file exists in master today (I checked all 2078), so this is a live hole with an empty current population, not a live breakage.

Proposed repair: Delete the error handler at tools/check_json_parses.py:69 — one token:

-            json.loads(raw.decode("utf-8", "replace"))
+            json.loads(raw.decode("utf-8"))

That is the whole fix. No new code, no new branch, no baseline change: the decode already sits inside the try at line 68, and UnicodeDecodeError subclasses ValueError, so the existing except Exception as e: bad.append((rel, str(e)[:90])) catches it and reports the byte and its offset in the same FAIL list as a syntax error. Verified above: the real tree still prints OK: 2078, all five end-to-end controls stil

issue-gate — passes-a-defect

check-linked-issue never checks the issue exists — Closes #0 passes a required gate, and the step makes zero API calls despite holding a token for it

A PR body reading Closes #0 or Fixes #99999999 satisfies the required check-linked-issue context and merges. Neither number is an issue in gHashTag/t27 (both 404; highest real issue is #3331). The job declares permissions: issues: read and GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} and then never contacts the API, so the third question in the brief — "what happens when the API call fails" — has no answer: there is no call to fail. The gate is a pure regex over two strings.

Proposed repair: Restore the operand the file lost in 7266d7b, using the GH_TOKEN and issues: read the job already declares. Keep the regex as the cheap pre-filter and add existence checking inside the existing if [ -n "$FOUND" ] branch, before the ✅ line:

      NUMS=$(echo "$FOUND" | grep -oE '[0-9]+' | sort -u)
      for n in $NUMS; do
        code=$(gh api "repos/${GITHUB_REPOSITORY}/issues/$n" -i --silent 2>/dev/null | head -1 | awk '{print $2}')
        case "$code" in
          200) ;;
          404) echo "::error::L1 TRACEABILITY: referenced #$n does not exist in ${GITHU

issue-gate — passes-a-defect

A reference inside a fenced code block, inside a markdown quote, or glued to another word satisfies the required gate

The pattern has no word boundary and no markdown awareness. A PR body whose only #N sits inside a bash example (the repo's own PULL_REQUEST_TEMPLATE.md ships such a block in its Testing section), or inside a > quoted line, or inside an unrelated word — prefs #1, suffixes #1, a URL ending .../refs#42 — passes as a linked issue. hooks.rs documents the missing word boundary as deliberate; nothing anywhere documents that code blocks and quotations count.

Proposed repair: Replace only the FOUND= computation in .github/workflows/issue-gate.yml (step "Check for linked issues in PR"). Three changes, each closing one reproduced mechanism:

BODY=$(printf '%s\n' "$PR_BODY" | awk '
  /^[[:space:]]*```/ { fence = !fence; next }
  fence             { next }
  /^[[:space:]]*>/  { next }
                    { print }')
FOUND=$(printf '%s\n%s\n' "$PR_TITLE" "$BODY" \
  | grep -oiE '(^|[^[:alnum:]_/])(Closes?|Fixes?|Resolves?|Refs?|Updates?)[[:space:]]*#[1-9][0-9]*' \
  | grep -oiE '(Closes?|Fixes?|Resolves?|Refs?|Updates?)[[:space:]]*#[1