check-block-alignment --fix corrupts JSON inside template strings

Context

Discovered filing #13665 (the store-write guard layer). Adding a guard call to ai/services/ingestion/ConceptDiscoveryService.mjs and staging it triggered the check-block-alignment pre-commit hook (lint-staged), whose --fix then rewrote the concept-discovery LLM prompt — it aligned the colons inside the JSON example that lives in a backtick template string:

-      "id": "kebab-case-slug-under-40-chars",
+      "id"         : "kebab-case-slug-under-40-chars",

That JSON block is inside the prompt template (ConceptDiscoveryService.mjs ~lines 30-64, the "Output STRICT JSON" example the LLM is shown). The result is still valid JSON, but it is an unintended mutation of a prompt template forced by an alignment lint, and it blocks anyone from cleanly editing a file that contains prompt-template JSON.

The Problem

buildScripts/util/check-block-alignment.mjs's object-literal-colon rule (v1b) detects "key": value runs by line pattern and is not template-string-aware — it treats JSON inside a backtick string as a code object literal and aligns the colons. The import-from (v1) and =-comma-block (v1b) rules are fine; the object-literal-colon rule is the bug. There is no skip marker and no string/template detection (grepped the file: no ignore/skip/template/backtick handling).

Repo-wide blast: any .mjs with a prompt-template JSON example (the ingestion / Dream-pipeline prompts are full of them) gets its prompt mutated the moment it is staged for an unrelated change.

The Architectural Reality

• buildScripts/util/check-block-alignment.mjs — the object-literal-colon detector (detect…/the v1b run-grouping ~line 102-160) operates on raw lines with no awareness of backtick template-string regions. House-style authority: .github/CODING_GUIDELINES.md rule 2 (colon-align) — which is a code style, not a string-content rule.

The Fix

Make the object-literal-colon rule skip lines inside backtick template-string regions (track template-literal open/close across lines; exclude those line ranges from run detection + --fix). A lightweight backtick-region scan is sufficient — full JS tokenization is not required for the common case. Alternatively/additionally, support an explicit skip marker (e.g. a // check-block-alignment-ignore-next-block comment) for edge cases.

Acceptance Criteria

• check-block-alignment (check + --fix) does not align colons inside backtick template-string contents.
• A regression test: a fixture .mjs with a prompt-template JSON example (\...{ "id": "x", "name": "y" }...`) passes the check unchanged and is untouched by --fix`.
• The genuine object-literal-colon rule still fires for real code object literals (no regression in the rule's intended behavior).

Out of Scope

• The import-from (v1) and =-comma-block alignment rules — those are correct.
• Re-aligning existing already-mutated prompt strings (none merged; this prevents the class).

Decision Record impact

none — a lint correctness fix.

Related

Blocks the concept-guard slice of #13665 (the concept write funnel lives next to the prompt template, so the guard edit can't be committed without the lint corrupting the prompt). Relates #12435 (Grace edits the same prompt-template-adjacent files), #13658.

Live latest-open sweep: checked latest 20 open issues at 2026-06-20T21:01Z (filing #13665); no equivalent hook-bug ticket.

Release classification: post-v13 substrate / tooling — boardless.

Origin Session ID: 95241bfa-5c15-4a48-846b-fe21c869696b

Retrieval Hint: "check-block-alignment template string colon alignment corrupts prompt JSON object-literal rule not string-aware"