fix(lint): lockfiles, merge_group, and every default-branch name - #58
Merged
Conversation
…to the caller Two defects found by rolling this gate out across seven orgs. Both are the same shape as the JSONC one: the check was wrong, not the repo. yamllint was reading pnpm-lock.yaml. The canonical .yamllint.yaml ignored only node_modules/, so the 140-char line-length rule fired on generated lockfiles - zti-app's pnpm-lock.yaml:5210 is an npm deprecation notice pnpm copied verbatim from the registry. No developer wrote it, and it cannot be rewrapped without invalidating the lockfile. .prettierignore has exempted lockfiles all along under "Lockfiles, generated output"; yamllint not doing the same was an oversight that stayed hidden only because this repo has no lockfile. Every pnpm repo in the estate would have hit it, and the only local fixes available were editing a generated file or diverging from the canonical config - which is how the drift starts. The caller now includes merge_group. A repo whose ruleset uses a merge queue needs required checks to report on the gh-readonly-queue/** ref, and only merge_group produces that; without it a queued PR stalls for the full check_response_timeout and nothing can ever land. nhimbe needed exactly this and had to deviate from the canonical caller by one line to land at all. The point of this file is that no repo has to do that, so the trigger belongs here. It is harmless where there is no queue. ADOPTING-LINT.md now records both, plus why pull_request must NOT carry a branches: filter - that filter matches the PR's BASE branch, so adding one silently stops the gate emitting in shamwari-core, shamwari-gateway, shamwari-web (default branch `scaffold`) and siafudb-kuzu (`master`). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
prettier 3.9.4's mdx parser rewrites a multi-line {/* ... */} comment
into {/_ ... _/} - it reads the * as markdown emphasis and emits invalid
MDX, so `prettier --write` actively breaks the file. The check is right
and the formatter has the bug, so the gate is unchanged; what is needed
is that the next person mid-adoption, reaching for --write, knows to
diff the result.
And markdownlint-cli2 --fix cannot fix MD036, because emphasis-as-heading
needs a judgement call: a bold line introducing a subsection should
become a real heading, while an italic sign-off is not a heading at all
and should become a blockquote. Converting the second kind into a heading
gives you a happy linter and a wrong document.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The caller's push trigger was `branches: [main]`, but three repos default
to `scaffold` (shamwari-core, shamwari-gateway, shamwari-web) and one to
`master` (siafudb-kuzu). Merging into those repos' default branch fired
nothing, so the five contexts never appeared on the default-branch head.
The shamwari agent had to run `gh workflow run lint.yml --ref scaffold`
by hand to get evidence, and future merges there would have gone
unwatched.
That matters beyond bookkeeping: a push-triggered run on the default
branch is what makes a broken main visible. bundu-labs/.github sat with
`lint / prettier` red from 2026-05-02 and nobody noticed, because nothing
required the contexts there. Losing the signal entirely in four repos is
worse.
Now `branches: [main, master, scaffold]` - a list rather than a bare
`push:`, because unfiltered push would run the gate on every
feature-branch push across 74 repos and bill it twice for every PR.
Also records the MDX-in-.md trap in ADOPTING-LINT.md. A Mintlify starter
leaves `{/* ... */}` in AGENTS.md; Mintlify parses that file as MDX where
an HTML comment is a parse error, while markdownlint and Prettier read it
as Markdown where the asterisks are emphasis. No spelling satisfies both,
and `markdownlint-cli2 --fix` pairs asterisks across adjacent comment
lines to produce something that is neither valid MDX nor intended.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Re-lands two commits that PR #57 silently dropped, plus one new fix.
What happened to #57
Auto-merge fired on #57 as soon as its first commit went green, and rebase-merged only that commit. The two commits I pushed afterwards — the yamllint lockfile exemption and
merge_group:— never landed, even though I had already told two agents they were unblocked by them. They are cherry-picked here. Lesson recorded: do not push to a branch that has auto-merge armed.1. yamllint was linting generated lockfiles (re-land)
.yamllint.yamlignored onlynode_modules/, so the 140-char rule fired onpnpm-lock.yaml. Two agents hit this independently —zti-app(a 185-char npm deprecation notice) andmzizi-registry(a 259-char glob@7 deprecation string). Both are text pnpm copied verbatim from the registry; no developer wrote them and they cannot be rewrapped without invalidating the lockfile..prettierignorehas exempted lockfiles all along under "Lockfiles, generated output"; yamllint not doing the same was an oversight hidden only because this repo has no lockfile.2.
merge_group:in the canonical caller (re-land)nhimbe's ruleset requires a merge queue. Required checks must report on thegh-readonly-queue/**ref and onlymerge_groupproduces that; without it a queued PR stalls for the full 60-minutecheck_response_timeoutand nothing can land. Inert where there is no queue.3. Every default-branch name (new)
The push trigger was
branches: [main], butshamwari-core/-gateway/-webdefault toscaffoldandsiafudb-kuzutomaster. Merging there fired nothing, so the five contexts never reached the default-branch head — the shamwari agent had to dispatch the workflow by hand to get evidence.That signal matters:
bundu-labs/.githubsat withlint / prettierred since 2026-05-02 unnoticed. Nowbranches: [main, master, scaffold]— a list rather than a barepush:, which would run the gate on every feature-branch push across 74 repos and bill it twice per PR.4. MDX-in-
.mdtrap documentedMintlify parses
AGENTS.mdas MDX (HTML comments are a parse error); markdownlint and Prettier read it as Markdown (the asterisks are emphasis). No spelling satisfies both, and--fixpairs asterisks across adjacent comment lines producing{/*Add product-specific terms and preferred usage _/}.Verified locally with the pinned toolchain: clean.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com