feat(standard): §13 declared component system per platform — v1.42 - #21
Merged
Conversation
§13 required Material Design as "the required component system for all graphical applications" — a rule written when the graphical surface in scope was Flutter and web. It has been unsatisfiable for native desktop since the day it was written: GTK 4 ships Adwaita and the GNOME HIG, Qt 6 ships Fusion and the KDE HIG, and neither has a Material component set to theme. A GTK or Qt application could not pass the §16 audit gate no matter how it was built. Rewritten around the requirement that carries the intent: every graphical application declares exactly one component system in its README.md and follows it, with the system chosen by platform — Material Design for Flutter, web, mobile, cross-platform, and undeclared custom-drawn UI; GNOME HIG via libadwaita for GTK 4; KDE HIG via Qt Quick Controls/Fusion for Qt 6. Material remains the default wherever the platform supplies no system, so nothing compliant under v1.41 becomes non-compliant — the clause is narrowed, never widened. Unchanged: §11 token binding is unconditional, WCAG 2.2 AA remains the contrast floor, and §18 still governs where the two overlap. - @settitle, @set VERSION, @set UPDATED bumped to 1.42 / 2026-08-05 - §16 checklist bullet rewritten to the declare-and-follow form - Skill Cross-References gains spacecraft-gtk-guidelines and spacecraft-qt-guidelines rows; both are Rust-first under §3.1, so a native desktop toolkit is not a route around the memory-safe-language preference - CHANGELOG.md entry prepended; .md companion regenerated via texi2any --docbook | pandoc -f docbook -t gfm makeinfo --no-split: zero errors, zero warnings. reuse lint and validate-configs pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
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
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.
Why
§13 required Material Design as "the required component system for all graphical applications" — a rule written when the graphical surface in scope was Flutter and web.
It has been unsatisfiable for native desktop since the day it was written. GTK 4 ships Adwaita and the GNOME HIG; Qt 6 ships Fusion and the KDE HIG; neither has a Material component set to theme. A GTK or Qt application could not pass the §16 audit gate no matter how it was built — the only honest options were a permanent filed deviation, or an application matching neither its own toolkit nor Material.
Worse, imposing a foreign component system on a native toolkit fights exactly the platform integration §18 depends on: the accessibility bridge, the window manager, the system high-contrast and reduced-motion preferences, and the settings portal are all wired to the toolkit's own vocabulary.
What changed
§13 is rewritten around the requirement that actually carries the intent — every graphical application declares exactly one component system, in its
README.mdbeside the §5.2 posture section, and follows it consistently — with the system determined by the platform:Material Design remains the default wherever the platform supplies no system of its own, so nothing compliant under v1.41 becomes non-compliant — the clause is narrowed, never widened.
Explicitly unchanged
steelboretheme (§11.1). A component system chooses the widget vocabulary; it never supplies the colors.Also in this PR
@settitle,@set VERSION,@set UPDATED→ 1.42 / 2026-08-05spacecraft-gtk-guidelinesandspacecraft-qt-guidelinesrows. Both are Rust-first under §3.1 (gtk-rsfor GTK, CXX-Qt for Qt), so choosing a native desktop toolkit does not become a route around the memory-safe-language preference.CHANGELOG.mdentry prepended;.mdcompanion regenerated viatexi2any --docbook | pandoc -f docbook -t gfmVerification
makeinfo --no-split The_Steelbore_Standard.texi→ zero errors, zero warningsreuse lint→ compliant (8/8 files)python3 .github/validate-configs.py→ 3 config files, 0 failedCompanion change
The skill side landed in Construct at the same version:
094c806—spacecraft-standard-constitution/SKILL.md(masthead, frontmatter description at 976/1000, §13 body, §16 bullet, cross-reference table) andreferences/CHANGELOG.md, alongside the two newspacecraft-gtk-guidelines/spacecraft-qt-guidelinesskills that implement this section.🤖 Generated with Claude Code