docs: exempt ERC from the sentence-case heading rule

[alexander-sei]

What is the purpose of the change?

Correct a false positive in the Sei.Headings Vale rule. Split out of #75 at the reviewer's suggestion, so that PR's content diff stays cleanly revertable.

Describe the changes to the documentation

No prose changes. One line added to .github/styles/Sei/Headings.yml.

Sei.Headings enforces sentence case and exempts proper nouns and acronyms, but ERC was missing from the exceptions list while EVM, NFT, RPC, API, CLI, SDK, VRF, and JSON were all present. Any heading containing a hyphenated ERC standard therefore warned even when it was already correct sentence case: ## ERC-1155 interaction was flagged purely for the ERC-1155.

Adding ERC next to EVM clears six warnings across six existing pages and introduces none, taking the repo-wide count from 1212 to 1206. No other rule's count changes.

File	Heading
ai/mcp-server.mdx:234	NFT and ERC-1155
evm/evm-parity/examples/erc20.mdx:9	ERC-20 Interaction
evm/evm-parity/examples/erc721.mdx:9	ERC-721 Interaction
evm/evm-parity/examples/erc1155.mdx:9	ERC-1155 Interaction
evm/evm-parity/examples/multicall.mdx:34	Batching ERC-20 Reads with viem
evm/tokens.mdx:14	ERC721 NFTs

Matching semantics. Exception matching is substring-based rather than whole-token, so this one entry also covers unhyphenated ERCnnn; future ERCnnn headings will not need entries of their own. Measured on a probe file with and without the entry, ## ERC20 tokens and ## ERC721 nfts are flagged without it and clean with it. The practical blast radius is small, since no realistic heading word other than an ERC standard contains an uppercase ERC.

What it suppresses, stated precisely. The entry removes warnings in which the ERC token was a cause, and it is not perfectly surgical: in Batching ERC-20 Reads with viem and the three ERC-nnn Interaction titles, a second word is also capitalized, so those stop being annotated while still not being ideal sentence case. That imprecision is not specific to ERC — ## Foo Interaction has never warned either — and headings whose other words clearly break the rule keep warning with the entry in place, including ERC20 Contract Queries, Watching ERC-20 Transfers Across All Contracts, Interacting with a CW20 Pointer as ERC-20, and probe cases ## EVM Tokens and ## ERC-20 Tokens. Given the rule is advisory, suppressing four imperfect pre-existing headings seemed a fair trade for ending the false positives on correct ones; happy to instead fix those four headings' capitalization here if you would rather the rule stay strict.

Notes

• Verified by diffing complete Vale output before and after the change: six alerts removed, zero added, and the Sei.Qualifiers, Sei.Terminology, and Sei.ClickHere counts all unchanged.
• Advisory only. prose-style.yml runs Vale with fail_on_error: false and filter_mode: added, so this affects PR annotations rather than any CI outcome. The six warnings above sit on lines no one is currently editing, so they were only visible to a full-repo run.
• The rule's other 1206 warnings are mostly genuine Title Case headings and are out of scope here.
• docs(evm): add nonce lanes guide for concurrent submission from one account #75 still contains this same one-line commit; it should be dropped from that branch before either merges.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
sei-docs	🟢 Ready	View Preview	Sep 13, 2026, 11:06 AM

💡 Tip: Enable Automations to automatically generate PRs for you.

[cursor]

PR Summary

Low Risk
Documentation lint configuration only; no runtime, auth, or data-handling impact.

Overview
Adds ERC to the proper-noun/acronym exceptions in the Vale Sei.Headings rule (alongside EVM, NFT, etc.) so headings that mention ERC standards (e.g. ERC-20, ERC-1155) are not flagged when they are already in sentence case.

No documentation prose changes—only .github/styles/Sei/Headings.yml. This removes six false-positive heading warnings on existing pages; it does not suppress headings that have other title-case issues.

^{Reviewed by Cursor Bugbot for commit b595407. Bugbot is set up for automated code reviews on this repo. Configure here.}

[seidroid]

A well-scoped one-line fix adding ERC to the Vale Sei.Headings sentence-case exceptions, consistent with the eight acronyms already listed and affecting only advisory PR annotations, not CI outcomes. No blocking issues; my only notes are a question about whether the exception also covers unhyphenated ERC721, and that the Cursor second-opinion pass returned no output.

Findings: 0 blocking | 5 non-blocking | 1 posted inline

Blockers

• None at the file/PR level.

Non-blocking

• The Cursor second-opinion pass produced no output (cursor-review.md is empty), so this review reflects only my analysis plus Codex's (Codex found no material issues). REVIEW_GUIDELINES.md is also empty, so no repo-specific standards were applied beyond the conventions visible in the config files themselves.
• I could not independently reproduce the "1212 → 1206, zero added" alert count: Vale is not installed in this environment and fetching the binary was not permitted. I did confirm that all six headings listed in the PR description exist at the stated paths/lines, and that the ERC headings the PR says still warn (ERC20 Contract Queries, Watching ERC-20 Transfers Across All Contracts, Interacting with a CW20 Pointer as ERC-20) each do have an independent title-case problem. The claim is plausible and self-consistent; the numbers themselves are taken on trust.
• .github/styles/Sei/Headings.yml exceptions and .github/styles/config/vocabularies/Sei/accept.txt already duplicate many of the same terms (Sei, SeiDB, CosmWasm, Cosmos, Autobahn, Pectra, MetaMask, Compass, Rabby, Hardhat, Foundry, Solidity). ERC is being added only to the former, consistent with the existing pattern, but the two lists will keep drifting. Worth a follow-up to pick one source of truth rather than something to fix in this PR.
• Process note from the PR description: #75 reportedly still carries this same one-line commit. Drop it there before either merges to avoid a duplicate commit / conflict. Out of scope for the code here, but a real merge-order dependency.
• 1 suggestion(s)/nit(s) flagged inline on specific lines.

[seidroid]

[nit] The change looks right and matches the existing convention for EVM/NFT/RPC/etc. One thing worth confirming from the Vale run you did: the description lists evm/tokens.mdx:14 (#### ERC721 NFTs) among the cleared warnings, but that heading uses the unhyphenated ERC721. If Vale matches exceptions as whole tokens (\bERC\b), ERC721 would not match — there is no word boundary between C and 7 — and that warning should not have cleared. It clearing implies exception matching is substring-based, which would also mean ERC exempts any word containing an uppercase ERC (harmless in practice: no realistic heading word other than an ERC standard contains uppercase ERC).

Not blocking either way — this rule is level: warning and prose-style.yml runs with fail_on_error: false, so nothing gates on it. Just worth a sentence in the PR body clarifying which matching semantics you observed, since it determines whether future unhyphenated ERCnnn headings are covered by this entry or need their own.

[alexander-sei]

Good catch, and your inference is right: matching is substring-based, not \bERC\b. I tested it by running Vale over a probe file against two copies of the styles directory, identical except for this one line.

Flagged without the entry, clean with it:

• ## ERC20 tokens
• ## ERC721 nfts
• ## ERC721 NFTs

Still flagged with the entry: ## ERC20 Tokens, ## ERC-20 Tokens, ## ERC Tokens, ## EVM Tokens, ## Foo Tokens.

So unhyphenated ERCnnn is covered by this single entry, and future ERCnnn headings will not need their own. I have added a paragraph to the PR description recording those semantics.

Your follow-up point deserves a correction on my side, though. My original description claimed the entry "does not hide genuine title-case violations," and that was too strong. It is not perfectly surgical: Batching ERC-20 Reads with viem and the three ERC-nnn Interaction titles each have a second capitalized word, and they stop being annotated too. Worth noting that imprecision is not specific to this entry, since ## Foo Interaction never warned either, so the rule was already lenient about a trailing capitalized word in short headings.

That leaves a choice I am happy to defer to you. Either keep it as is, accepting that four imperfect pre-existing headings go unannotated, or I fix those four headings' capitalization in this PR so the rule stays strict. Say which you prefer.