feat(TP-193): code-quality formatter adoption — biome format --write applied across codebase#572
Merged
Merged
Conversation
…S.md TP-193's Step 0 has a CRITICAL operator confirmation check: > Operator freeze-window confirmation captured in Discoveries > (CRITICAL gate) Without this, the task aborts rather than landing a 50+-file format diff. Per spec section 6.3.4, the operator must confirm no in-flight PRs will be tangled. Operator confirmed (this session, 2026-05-10): TP-192 just merged (PR #571), no other internal PRs in flight. The two open community PRs (#520, #516) are external forks — their rebase pain is the contributors' responsibility, not ours. Pre-recording this in STATUS.md Discoveries so the worker's Step 0 check finds the confirmation immediately and proceeds without pausing for operator interaction.
… format pass)
Adds expect().toContainNormalized(needle) helper that whitespace-normalizes
both haystack and needle before substring matching. Source-grep tests that
match literal multi-word substrings of taskplane source files are brittle
against Biome's lineWidth=100 / arrowParentheses=always rules, which wrap
multi-arg calls vertically and add parens around single-param arrows.
Updated 22 distinct assertion sites across these test files to either:
- Use toContainNormalized() instead of toContain() for source-grep checks,
- Pre-normalize whitespace before regex .match() / .indexOf(),
- Bump fixed-size source-slice windows that were tight (e.g. 5000 -> 8000)
so formatter-induced vertical re-wrapping doesn't push expected strings
outside the inspected window.
This change is intentionally separate from the format-write commit so the
'.git-blame-ignore-revs' SHA points at a single mechanical commit.
… dev-setup docs + CHANGELOG
…5 and 11.6 (post-merge fold) Merger verification of the format-pass merge into the topic branch caught one source-grep test that the format-resilience prep (commit 2c803c7) missed: 'engine-runtime-v2-routing.test.ts:307' test 9.5 'mergeWave routes spawn to V2 when backend is v2'. The test slices merge.ts source for 16000 chars from the start of the mergeWave function declaration and counts spawnMergeAgentV2( occurrences. After the format pass, the merge state shifted the second call's opening paren to ~offset 15999 \u2014 within the function body but past the slice window. Test expected >= 2 matches, got 1, failed verification. Fix: bump the slice window 16000 \u2192 24000 in both test 9.5 (line 310) and test 11.6 (line 422, same pattern). 24000 leaves comfortable headroom for future formatter-induced length variance. Matches the prep commit's pattern: 'bump fixed-size source-slice windows that were tight'. No semantic test change \u2014 same assertions, just larger inspection window. Verified locally: - tests/engine-runtime-v2-routing.test.ts: 78/78 pass - Full merger filter (non-integration): 3124 pass / 0 fail / 1 skipped After this commit lands on the lane, orch_resume(force=true) will re-run the merge with the corrected lane state. Verification should pass.
…rge fold)
Fixes 175 spurious 'format/use-line-feed' errors that surfaced after
the format pass merged. The repo's index correctly stores LF, but
Windows local checkouts with default 'core.autocrlf=true' converted
files to CRLF in the working tree. Biome's 'lineEnding: "lf"' rule
flagged every file as a format violation on Windows, while CI on
Linux (no autocrlf) would have passed cleanly.
Adding '.gitattributes' with '* text=auto eol=lf' overrides autocrlf
at the repo level — ensures LF in the working tree on all platforms
regardless of per-developer git config. Standard cross-platform
pattern for repos that pin to a specific line-ending style.
Also explicit binary-file declarations (.png, .jpg, etc.) and
explicit text declarations for our common source extensions, both
defensive.
After this commit + a working-tree refresh ('git rm --cached -r . &&
git reset --hard'), 'npm run format:check' exits 0 cleanly on
Windows. CI behavior on Linux is unchanged (was already LF there).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Third of five sequenced packets implementing the code-quality-gates spec. Enables the Biome formatter and applies it once across the entire codebase as a single mechanical pass.
What ships
Three atomic commits per the spec's prescribed structure
chore(TP-193): configure Biome formatter rules—biome.jsonformatter block enabled (tabs, 100-char line width, double quotes, trailing commas, semicolons)chore(TP-193): apply biome format --write to entire codebase— the format pass itself; this is the SHA listed in.git-blame-ignore-revschore(TP-193): add format-adoption commit to .git-blame-ignore-revs— preserves git blame archaeologyPre-format format-resilience hardening (commit
2c803c78)Before the format pass, the worker added
expect().toContainNormalized()helper and updated 22 source-grep test sites so they're robust to formatter-induced wrapping. This was a deliberate prep step so the format-pass diff stays purely mechanical.Documentation
docs/maintainers/development-setup.mdupdated with thegit config blame.ignoreRevsFile .git-blame-ignore-revssetup note for new contributorsTwo post-merge folds (sage-recommended pattern)
Fold 1:
fix(TP-193): bump slice windows in tests 9.5 and 11.6(commit833449c8)The format pass slightly shifted
merge.tslength, pushing one source-grep test's expected match (spawnMergeAgentV2(at offset ~15999) just outside its 16000-char slice window. Bumped 16000 → 24000 in tests 9.5 and 11.6 ofengine-runtime-v2-routing.test.ts(preemptively for both, same pattern). Discovered when the merger's post-merge verification failed; fixed on the lane branch andorch_resumere-ran the merge cleanly.Fold 2:
chore(TP-193): add .gitattributes to enforce LF line endings(commitc9ae7f8b)After the merge, Windows local
format:checkreported 175 spurious format errors. Root cause: repo's index correctly stored LF, but Windows defaultcore.autocrlf=trueconverted files to CRLF in the working tree. Biome'slineEnding: "lf"config flagged every file. CI on Linux would have passed (no autocrlf there). Fixed by adding.gitattributeswith* text=auto eol=lf— overrides autocrlf at the repo level so all platforms get LF in the working tree.Validation
npm run format:checknpm run lintnpm run typecheck.git-blame-ignore-revsWhat this does NOT do (per spec scope boundaries)
continue-on-error: truefrom CI (TP-194's job)Closes
(none — third of five-packet sequence; TP-194 will close the gate-flip work after TP-195 lands)