Dev docs/standards/granular standards metadata#16481
Dev docs/standards/granular standards metadata#16481
Conversation
Added <SpecSection> components to all H2 sections (except Changelog) in all 7 SDK standards files: - api-architecture.mdx (6 sections) - code-quality.mdx (7 sections) - code-submission.mdx (7 sections) - coordination-maintenance.mdx (5 sections) - release-versioning.mdx (6 sections) - repository-docs.mdx (5 sections) - review-ci.mdx (5 sections) Total: 42 SpecSections added Each SpecSection uses: - status="candidate" (matching frontmatter spec_status) - since="1.0.0" (initial version) - Descriptive kebab-case IDs All sections contain their Rule, Enforcement, and Per-SDK override subsections within the SpecSection tags. The --- separators remain outside the SpecSection tags. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Converted StatusBadge from SCSS to Tailwind CSS to match SpecSection status badge design: - Removed custom SCSS file (style.module.scss) - Updated StatusBadge to use Tailwind CSS classes matching SpecSection pattern - Applied consistent sizing with calculated alignment: - text-xs (12px font) - px-2 (horizontal padding) - py-[0.1875rem] (3px vertical padding for balanced height) - leading-none (removes internal line-height for compact badge) - rounded, mr-2 - Used align-middle for proper vertical centering with inline text - Badge height calculation: 12px text + 6px padding = 18px total - Color scheme using explicit hex values (Tailwind default red scale): - "Yes" uses green: bg-green-100 text-green-800 (dark: bg-green-900 text-green-200) - "No" uses true red: bg-[#fee2e2] text-[#991b1b] (dark: bg-[#7f1d1d]/50 text-[#fca5a5]) - Added dark mode support matching SpecSection badges Note: Explicit hex values used for red because tailwind.config.mjs defines custom 'red' as #e1567c (pinkish). Both badge types now share consistent visual design throughout SDK standards documentation. Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
|
||
| ## Semantic conventions process | ||
|
|
||
| <SpecSection id="semantic-conventions-process" status="candidate" since="1.0.0"> |
There was a problem hiding this comment.
Duplicate HTML IDs from heading slugs and SpecSection
Medium Severity
Many SpecSection id values match the auto-generated heading slug from rehype-slug (using github-slugger), producing duplicate HTML id attributes on the page. For example, ## Semantic conventions process generates id="semantic-conventions-process" on the <h2>, while SpecSection id="semantic-conventions-process" adds the same id to the <section>. This occurs in roughly 26 sections across all changed files. Duplicate IDs are invalid HTML and can cause unpredictable anchor navigation and accessibility issues.
Additional Locations (2)
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
|
|
||
| ## Version Format | ||
|
|
||
| <SpecSection id="version-format" status="candidate" since="1.0.0"> |
There was a problem hiding this comment.
Duplicate HTML IDs from SpecSection and heading slugs
Medium Severity
The codebase uses rehype-slug (via GithubSlugger) to auto-generate id attributes on headings. The SpecSection component renders <section id={id}>. In ~26 cases across all 7 files, the SpecSection id prop matches the slug auto-generated for the adjacent ## heading, creating duplicate HTML id attributes on the same page. For example, ## Version Format gets id="version-format" from rehype-slug, and <SpecSection id="version-format"> creates a second element with the same id. This is invalid HTML and can cause issues with accessibility tools, table-of-contents generation, and getElementById behavior.


DESCRIBE YOUR PR
Refactor SDK standards pages to use granular SpecSection components and align StatusBadge styling for consistency.
IS YOUR CHANGE URGENT?
Help us prioritize incoming PRs by letting us know when the change needs to go live.
SLA
Thanks in advance for your help!
PRE-MERGE CHECKLIST
Make sure you've checked the following before merging your changes:
LEGAL BOILERPLATE
Look, I get it. The entity doing business as "Sentry" was incorporated in the State of Delaware in 2015 as Functional Software, Inc. and is gonna need some rights from me in order to utilize my contributions in this here PR. So here's the deal: I retain all rights, title and interest in and to my contributions, and by keeping this boilerplate intact I confirm that Sentry can use, modify, copy, and redistribute my contributions, under Sentry's choice of terms.
EXTRA RESOURCES