diff --git a/spacecraft-accessibility-support.skill b/spacecraft-accessibility-support.skill index 981bf1f..1909ddc 100644 Binary files a/spacecraft-accessibility-support.skill and b/spacecraft-accessibility-support.skill differ diff --git a/spacecraft-accessibility-support.zip b/spacecraft-accessibility-support.zip index b449fc1..f50e0fb 100644 Binary files a/spacecraft-accessibility-support.zip and b/spacecraft-accessibility-support.zip differ diff --git a/spacecraft-accessibility-support/references/gui.md b/spacecraft-accessibility-support/references/gui.md index 4b97825..beb6cef 100644 --- a/spacecraft-accessibility-support/references/gui.md +++ b/spacecraft-accessibility-support/references/gui.md @@ -120,6 +120,10 @@ platform high-contrast preference independently. Void Navy `#000027` remains the background in every variant — see §11.1.1 and the table in [`../SKILL.md`](../SKILL.md). -Material Design components (§13) must be themed through the theme tokens, not -bare hex literals (§11.1) — which is precisely what makes swapping in the -high-contrast variant a one-line change. +Whichever component system §13 requires for the platform — Material Design for +Flutter, web, mobile, and cross-platform GUI; GNOME HIG (libadwaita) for GTK 4; +KDE HIG (Qt Quick Controls / Fusion) for Qt 6 — its components must be themed +through the theme tokens, not bare hex literals (§11.1). That indirection is +precisely what makes swapping in the high-contrast variant a one-line change, +and it is the reason the variant swap works identically across all three +systems. diff --git a/spacecraft-brand-guidelines.skill b/spacecraft-brand-guidelines.skill index f16afa9..a69a5d7 100644 Binary files a/spacecraft-brand-guidelines.skill and b/spacecraft-brand-guidelines.skill differ diff --git a/spacecraft-brand-guidelines.zip b/spacecraft-brand-guidelines.zip index 0919b66..a69a5d7 100644 Binary files a/spacecraft-brand-guidelines.zip and b/spacecraft-brand-guidelines.zip differ diff --git a/spacecraft-brand-guidelines/SKILL.md b/spacecraft-brand-guidelines/SKILL.md index 5c2e9b5..c3c6a85 100644 --- a/spacecraft-brand-guidelines/SKILL.md +++ b/spacecraft-brand-guidelines/SKILL.md @@ -12,7 +12,11 @@ website: https://Construct.SpacecraftSoftware.org/ **Copyright:** (C) 2026 Mohamed Hammad & Spacecraft Software | **License:** GPL-3.0-or-later **Website:** [https://Construct.SpacecraftSoftware.org/](https://Construct.SpacecraftSoftware.org/) -> **Source of truth:** The Steelbore Standard (§11 Colour Palettes, §12 Typography), v1.39. +> **Source of truth:** The Steelbore Standard — **§11** (Colour Palettes) and +> **§12** (Typography). This skill tracks those two sections, not the document +> version: a release that touches neither leaves this skill current, so no +> version is pinned here to go stale. When §11 or §12 changes, this skill +> changes with it. > > **§11 is a palette family.** The tables below are **Steelbore Modern**, the > default — use it unless the project declares an alternate in its `README.md` @@ -88,7 +92,7 @@ Quick reference: - **Steelbore Theme Standard:** When implementing colors and themes, always opt to create a named theme called `Steelbore` (Snake case `steelbore` for file/module names) that bundles these colors, rather than hardcoding hex values directly in UI/styling logic. This allows users to easily swap or customize themes by registering a new named theme without modifying application logic (Standard §11.1). The full role-token contract (including `surface`, `surface-alt`, `focus`, and `border`) is defined in §11.1. - **Focus indicator:** Acid Lime `#B4FF00` (16.75:1) — satisfies WCAG 2.2 §2.4.11 on every background. -- Apply the palette to Material Design components (the required UI system for Spacecraft Software GUIs). +- Apply the palette to whichever component system §13 requires for the platform — **Material Design** for Flutter, web, mobile, and cross-platform GUI; **GNOME HIG** (libadwaita) for GTK 4; **KDE HIG** (Qt Quick Controls / Fusion) for Qt 6. The palette is system-agnostic: §13 chooses the widget vocabulary, §11 supplies the colors, and the binding is always through the named `steelbore` theme rather than the component library's own defaults. - All new color pairings must pass WCAG 2.2 Level AA contrast verification before adoption, stating which pairing was measured (§13). - For IDE and terminal themes, load the `spacecraft-theme-factory` skill. diff --git a/spacecraft-flutterdart-guidelines.skill b/spacecraft-flutterdart-guidelines.skill index ccc219e..2c52c05 100644 Binary files a/spacecraft-flutterdart-guidelines.skill and b/spacecraft-flutterdart-guidelines.skill differ diff --git a/spacecraft-flutterdart-guidelines.zip b/spacecraft-flutterdart-guidelines.zip index 87b48a9..f73c336 100644 Binary files a/spacecraft-flutterdart-guidelines.zip and b/spacecraft-flutterdart-guidelines.zip differ diff --git a/spacecraft-flutterdart-guidelines/SKILL.md b/spacecraft-flutterdart-guidelines/SKILL.md index b1432d4..4510739 100644 --- a/spacecraft-flutterdart-guidelines/SKILL.md +++ b/spacecraft-flutterdart-guidelines/SKILL.md @@ -1,6 +1,6 @@ --- name: spacecraft-flutterdart-guidelines -description: Use for writing type-safe highly-concurrent memory-safe Flutter and Dart code following Spacecraft Software standards. Triggers on any request involving Dart, Flutter, pubspec.yaml, analysis_options.yaml, Sound Null Safety (avoiding !), Dart Isolates (Isolate.run, ports), event loop async/await, Flutter performance tuning (const constructors, RepaintBoundary), disposing controllers, widget testing, or package dependencies. Native Android configurations or integrations are governed with higher dominance by the Google Android skills at android-skills/. Trigger even when implicit, e.g. "write a Dart isolate", "optimize Flutter build redraws", "configure analysis_options.yaml", or "mock a widget test". Do NOT trigger for standard JS or native iOS unless bridging is explicitly required. By Mohamed Hammad and Spacecraft Software. +description: Use for writing type-safe highly-concurrent memory-safe Flutter and Dart code following Spacecraft Software standards. Triggers on any request involving Dart, Flutter, pubspec.yaml, analysis_options.yaml, Sound Null Safety (avoiding !), Dart Isolates (Isolate.run, ports), event loop async/await, Flutter performance tuning (const constructors, RepaintBoundary), disposing controllers, Semantics/SemanticsRole accessibility (Standard §18), widget testing, or package dependencies. Native Android configurations or integrations are governed with higher dominance by the Google Android skills at android-skills/. Trigger even when implicit, e.g. "write a Dart isolate", "optimize Flutter build redraws", "configure analysis_options.yaml", or "mock a widget test". Do NOT trigger for standard JS or native iOS unless bridging is explicitly required. By Mohamed Hammad and Spacecraft Software. license: GPL-3.0-or-later maintainer: Mohamed Hammad website: https://Construct.SpacecraftSoftware.org/ @@ -22,6 +22,7 @@ website: https://Construct.SpacecraftSoftware.org/ - **Then Performance (Priority 2).** Flutter renders at 60fps/120fps. Never block the main UI thread with heavy calculations (offload them to auxiliary Isolates). Prevent garbage collection churn by using `const` constructors on widgets and objects. - **Isolate Concurrency.** Dart isolates do not share memory heaps. Protect threads from race conditions by design; pass immutable data via messages or clean `Isolate.run` blocks. - **Clean Resource Teardown.** Prevent memory leaks by explicitly closing streams and disposing of controller objects when widgets are unmounted. +- **Accessible by Construction (Standard §18).** Every Spacecraft Software application other than a registered game **must** ship a working accessible mode — this is mandatory for the developer to implement and optional for the user to activate. §18.3 names **`Semantics` / `SemanticsRole`** as Flutter's required bridge; it maps to ARIA on web and to the platform accessibility APIs elsewhere. Accessibility is a build requirement, not a polish pass. ## Memory Safety & Null Safety - **NonNull Safety Checks:** The force-unwrap operator `!` is strictly forbidden on production code. Use optional chaining `?.`, the Elvis operator `??` to supply fallbacks, or smart casting after explicit type checking (`is`). @@ -46,6 +47,8 @@ Always choose the concurrency model corresponding to the workload: - **State management:** Local state updates via local widgets or structured controllers (Riverpod, Bloc, Provider). Avoid calling `setState` at the root of large widget trees. - **Widget caching:** Enforce `const` constructors on all stateless widgets and immutable layouts. - **Performance boundaries:** Wrap complex, frequently repainting widgets in `RepaintBoundary` objects. +- **Accessibility bridge:** `Semantics` / `SemanticsRole` on every interactive widget; `ExcludeSemantics` for decoration; a `CustomPainter` surface publishes its own nodes via `semanticsBuilder` (§18.3). +- **Design system:** Material Design — §13 requires it for Flutter, web, mobile, and cross-platform GUI, themed through the named `steelbore` theme rather than bare hex literals (§11.1). ## Required Techniques 1. **Controller Disposal:** Always call `.dispose()` on `TextEditingController`, `AnimationController`, `ScrollController`, and `StreamController` inside `StatefulWidget.dispose()` to prevent memory leaks. @@ -53,12 +56,16 @@ Always choose the concurrency model corresponding to the workload: 3. **Isolate parsing:** Wrap JSON decoding of large payloads (size > 50KB) inside `Isolate.run()` to prevent frame drops. 4. **DevTools Profiling:** Verify repaint boundaries using Flutter DevTools' "Highlight Repaints" before checking in custom painters. 5. **Warnings-as-Errors:** Configure compiler options in `pubspec.yaml` and `analysis_options.yaml` to fail builds on analysis warnings in CI. +6. **Semantic name and role on every interactive widget:** an icon-only `IconButton` with no `tooltip` or `Semantics(label:)` announces as "button" and nothing else. Wrap decoration in `ExcludeSemantics` so it is skipped rather than read as noise. +7. **Announce state changes, do not merely repaint them:** `SemanticsService.announce(…)` when a long operation completes — a spinner that stops communicates nothing to a screen-reader user. +8. **Honour platform preferences independently of the §18.1 toggle:** read `MediaQuery.disableAnimations` (reduced motion) and `MediaQuery.highContrast` from the platform. The user already expressed those system-wide; do not make them express it twice. ## Build, Tooling & CI (Non-Negotiable) - **Toolchain floor:** Dart ≥ 3.0.0, Flutter ≥ 3.10. - **Analysis Option Rules:** Enforce `flutter_lints` with `prefer_const_constructors` and `close_sinks` warnings configured as errors. - **Formatter:** Verify layout spacing using `dart format --line-length=100`. - **Testing:** Unit, widget, and integration test targets gated on every CI commit. +- **Accessibility gate:** assert with `meetsGuideline(textContrastGuideline)`, `androidTapTargetGuideline`, `iOSTapTargetGuideline`, and `labeledTapTargetGuideline` in widget tests, and verify the built application with a real screen reader — TalkBack, VoiceOver, or Orca — before release (§18.4). ## Anti-Patterns (Never Do These) - Using the `!` operator to force-unwrap nullable variables. @@ -67,6 +74,11 @@ Always choose the concurrency model corresponding to the workload: - Leaving animation controllers or stream controllers open without calling `.dispose()`. - Triggering global `setState` updates for localized changes. - Accessing collection subscripts without index range checking. +- Shipping an icon-only button with no `tooltip` or `Semantics` label — it announces as "button" and nothing else. +- Painting controls in a `CustomPainter` without a `semanticsBuilder`: a canvas-rendered control is invisible to assistive technology, not merely hard to reach. +- Wrapping decorative imagery in `Semantics` instead of `ExcludeSemantics`, so a screen reader reads noise. +- Animating unconditionally without checking `MediaQuery.disableAnimations`. +- Writing hex color literals into widget code instead of `steelbore` theme tokens (§11.1). ## Pre-Commit Checklist (Verify Every Time) - [ ] Null safety checks pass; no `!` operators left in production code @@ -77,9 +89,16 @@ Always choose the concurrency model corresponding to the workload: - [ ] analysis_options.yaml has lint checks active; no warnings or lints remain - [ ] Widget and unit test suites execute successfully - [ ] dart format runs cleanly without modifications +- [ ] Every interactive widget carries a semantic label and role; decoration is wrapped in `ExcludeSemantics` +- [ ] `CustomPainter` surfaces publish nodes via `semanticsBuilder` (§18.3) +- [ ] State changes that matter are announced, not merely repainted +- [ ] Reduced motion and high contrast are read from `MediaQuery`, independently of the §18.1 toggle +- [ ] Accessibility guideline assertions pass, and the app was exercised with a real screen reader (§18.4) +- [ ] All colors resolve through `steelbore` theme tokens — no hex literals (§11.1) ## References & Further Reading -- Load `references/Spacecraft_FlutterDart_Guidelines.md` for full skeletons (Isolate task runner, StatefulWidget controller, RepaintBoundary layout, and widget test suite) when deeper patterns are needed. +- Load `references/Spacecraft_FlutterDart_Guidelines.md` for full skeletons (Isolate task runner, StatefulWidget controller, RepaintBoundary layout, `Semantics` accessibility patterns, and widget test suite) when deeper patterns are needed. +- Cross-reference `spacecraft-accessibility-support` for the §18 contract itself — the activation toggle, the bridge table, and the audit gates. This skill covers the Flutter API surface only and does not restate them. - *Further reading* (consulted for background only): Dart Language Guide, Flutter Performance Auditing, RepaintBoundary documentation, and Flutter Testing handbook. When the user requests Flutter/Dart code or review, activate this skill, apply the checklist, and produce code a senior Spacecraft systems engineer would ship. diff --git a/spacecraft-flutterdart-guidelines/references/Spacecraft_FlutterDart_Guidelines.md b/spacecraft-flutterdart-guidelines/references/Spacecraft_FlutterDart_Guidelines.md index 597fe92..3ecd0d8 100644 --- a/spacecraft-flutterdart-guidelines/references/Spacecraft_FlutterDart_Guidelines.md +++ b/spacecraft-flutterdart-guidelines/references/Spacecraft_FlutterDart_Guidelines.md @@ -5,7 +5,7 @@ **Author:** Mohamed Hammad & Spacecraft Software **Compatibility:** Claude 3.5+, Claude 4, Grok, and all advanced reasoning models -This document expands on the `SKILL.md` for Flutter and Dart systems programming. It provides complete, compile-checked configurations and skeletons for Isolate concurrency, controller lifecycle disposal, repaint boundary optimizations, and widget testing. +This document expands on the `SKILL.md` for Flutter and Dart systems programming. It provides complete, compile-checked configurations and skeletons for Isolate concurrency, controller lifecycle disposal, repaint boundary optimizations, Standard §18 accessibility, and widget testing. --- @@ -297,7 +297,135 @@ linter: --- -## 6. Common Pitfalls & Troubleshooting +## 6. Accessibility: `Semantics`, Announcements & Custom Paint (Standard §18) + +§18 makes an accessible mode mandatory for every Spacecraft Software application other than a registered game, and §18.3 names `Semantics` / `SemanticsRole` as Flutter's required bridge. `spacecraft-accessibility-support` owns the §18 contract — the activation toggle, the bridge table, the audit gates; this section covers only the Flutter API surface. + +Standard Material widgets carry sensible defaults. Anything icon-only, custom-composed, or custom-painted carries **nothing** until it is declared. + +```dart +import 'package:flutter/material.dart'; +import 'package:flutter/semantics.dart'; + +class TelemetryPanel extends StatelessWidget { + const TelemetryPanel({super.key, required this.packetCount, required this.busy}); + + final int packetCount; + final bool busy; + + @override + Widget build(BuildContext context) { + // Platform preferences are read independently of the §18.1 toggle — the + // user already expressed them system-wide; do not ask twice. + final reduceMotion = MediaQuery.disableAnimationsOf(context); + + return Column( + children: [ + // An icon-only button announces as "button" and nothing else without + // a label. `tooltip` supplies one for free on Material widgets. + IconButton( + icon: const Icon(Icons.refresh), + tooltip: 'Rebuild telemetry index', + onPressed: busy ? null : () => _reload(context), + ), + + // Explicit role + label where the widget is composed by hand. + Semantics( + label: 'Telemetry packets loaded', + value: '$packetCount', + readOnly: true, + child: Text('$packetCount packets'), + ), + + // Decoration is excluded so it is skipped rather than read as noise. + const ExcludeSemantics(child: Divider(height: 1)), + + // §11.0.2 — colour is never the sole carrier of meaning; the status + // carries a text tag as well as a themed colour. + Text( + busy ? '[INFO] Loading…' : '[OK] Idle', + style: TextStyle( + color: busy + ? Theme.of(context).colorScheme.tertiary + : Theme.of(context).colorScheme.primary, + ), + ), + + if (!reduceMotion) const _PulseIndicator(), + ], + ); + } + + void _reload(BuildContext context) { + // State changes that matter are ANNOUNCED, not merely repainted. A spinner + // that stops communicates nothing to a screen-reader user. + SemanticsService.announce('Telemetry index rebuilt', TextDirection.ltr); + } +} +``` + +**Custom paint is the failure case.** A control drawn onto a canvas has no node in the semantics tree unless the painter publishes one — it is not "partially accessible", it is invisible. `CustomPainter.semanticsBuilder` is how that gap is closed: + +```dart +class PacketGraphPainter extends CustomPainter { + PacketGraphPainter(this.series); + + final List series; + + @override + void paint(Canvas canvas, Size size) { + // …painting elided… + } + + // Without this, the whole graph is one unlabelled region to a screen reader. + @override + SemanticsBuilderCallback get semanticsBuilder => (Size size) { + final width = size.width / series.length; + return [ + for (var i = 0; i < series.length; i++) + CustomPainterSemantics( + rect: Rect.fromLTWH(i * width, 0, width, size.height), + properties: SemanticsProperties( + label: 'Sample ${i + 1}', + value: series[i].toStringAsFixed(2), + textDirection: TextDirection.ltr, + ), + ), + ]; + }; + + @override + bool shouldRepaint(covariant PacketGraphPainter old) => old.series != series; + + @override + bool shouldRebuildSemantics(covariant PacketGraphPainter old) => old.series != series; +} +``` + +**Test it.** Flutter ships accessibility guideline matchers, so the gate is a widget test rather than a manual pass — though §18.4 still requires exercising the built application with a real screen reader (TalkBack, VoiceOver, or Orca) before release. + +```dart +testWidgets('telemetry panel meets accessibility guidelines', (tester) async { + final handle = tester.ensureSemantics(); + await tester.pumpWidget(const MaterialApp( + home: TelemetryPanel(packetCount: 12, busy: false), + )); + + await expectLater(tester, meetsGuideline(textContrastGuideline)); + await expectLater(tester, meetsGuideline(androidTapTargetGuideline)); + await expectLater(tester, meetsGuideline(iOSTapTargetGuideline)); + await expectLater(tester, meetsGuideline(labeledTapTargetGuideline)); + + // The refresh control must be findable BY ITS LABEL, not by icon or position. + expect(find.bySemanticsLabel('Rebuild telemetry index'), findsOneWidget); + + handle.dispose(); +}); +``` + +--- + +## 7. Common Pitfalls & Troubleshooting | Pitfall | Symptom | Corrective Action | | :--- | :--- | :--- | @@ -306,10 +434,15 @@ linter: | **Heavy computations on UI thread** | Frame drops, stuttering animations | Offload computational logic to `Isolate.run()`. | | **Missing `const` keywords** | Frequent rebuilds, sluggish rendering | Configure `prefer_const_constructors` to throw errors in compiler. | | **Redrawing complex elements** | Slow layouts on canvas widgets | Wrap canvas painters inside `RepaintBoundary` boxes. | +| **Icon-only button, no label** | Screen reader announces "button" and nothing else | Give it a `tooltip`, or wrap in `Semantics(label:)`. | +| **`CustomPainter` without `semanticsBuilder`** | Whole canvas is one unlabelled region; controls are invisible to AT | Publish `CustomPainterSemantics` nodes per control. | +| **Decoration inside `Semantics`** | Screen reader reads dividers and ornaments as content | Wrap decoration in `ExcludeSemantics`. | +| **Spinner stops, nothing announced** | Sighted users see completion; AT users get silence | `SemanticsService.announce(…)` on meaningful state change. | +| **Animating unconditionally** | Motion-sensitive users get animation they disabled system-wide | Gate on `MediaQuery.disableAnimationsOf(context)`. | --- -## 7. Code Review Compliance Gate +## 8. Code Review Compliance Gate Before merging Flutter/Dart code, verify: 1. Native Android integrations have been aligned with `@android-skills`. @@ -319,3 +452,9 @@ Before merging Flutter/Dart code, verify: 5. All constant widgets are flagged with the `const` keyword. 6. Custom canvas paint subtrees are isolated using `RepaintBoundary`. 7. `analysis_options.yaml` has strict-casts enabled and compiles without errors. +8. Every interactive widget carries a semantic label and role; decoration is wrapped in `ExcludeSemantics` (§18.3). +9. `CustomPainter` surfaces publish `CustomPainterSemantics` nodes via `semanticsBuilder`. +10. State changes that matter to the user are announced, not merely repainted. +11. Reduced motion and high contrast are read from `MediaQuery`, independently of the §18.1 toggle. +12. `meetsGuideline` assertions pass, and the build was exercised with a real screen reader (§18.4). +13. All colors resolve through the named `steelbore` theme; no hex literal appears in widget code (§11.1). diff --git a/spacecraft-standard-constitution.skill b/spacecraft-standard-constitution.skill index 52adad1..3e010ba 100644 Binary files a/spacecraft-standard-constitution.skill and b/spacecraft-standard-constitution.skill differ diff --git a/spacecraft-standard-constitution.zip b/spacecraft-standard-constitution.zip index fed4c22..eb25074 100644 Binary files a/spacecraft-standard-constitution.zip and b/spacecraft-standard-constitution.zip differ diff --git a/spacecraft-standard-constitution/SKILL.md b/spacecraft-standard-constitution/SKILL.md index d3c6c4f..74adb41 100644 --- a/spacecraft-standard-constitution/SKILL.md +++ b/spacecraft-standard-constitution/SKILL.md @@ -8,7 +8,7 @@ description: > Spacecraft Software-umbrella project — even if the user doesn't explicitly mention the Standard. If the user mentions "Spacecraft Software", a Spacecraft Software subproject name, or asks you to work on anything in the Spacecraft Software ecosystem, consult this skill immediately. It encodes - The Steelbore Standard v1.43 (§13 design systems; §3.1.1 TypeScript over JS; §6.4 contribution targets; §5.6 skill packaging; §11 palettes + §11.5 fidelity; §18 accessibility; §17 progress reporting; §3.2 compiler flags; concurrency; §3.3 security-by-design) so + The Steelbore Standard v1.44 (§13 design systems; §3.1.1 TypeScript over JS; §6.4 contribution targets; §5.6 skill packaging; §11 palettes + §11.5 fidelity; §18 accessibility; §17 progress reporting; §3.2 compiler flags; concurrency; §3.3 security-by-design) so you never need to ask for it or have it attached to a prompt again. license: GPL-3.0-or-later maintainer: Mohamed Hammad @@ -17,7 +17,7 @@ website: https://Construct.SpacecraftSoftware.org/ # The Steelbore Standard — Compliance Reference -**Version:** 1.43 | **Date:** 2026-08-05 | **Author:** Mohamed Hammad +**Version:** 1.44 | **Date:** 2026-08-05 | **Author:** Mohamed Hammad **Maintainer:** Mohamed Hammad | **Contact:** [Mohamed.Hammad@SpacecraftSoftware.org](mailto:Mohamed.Hammad@SpacecraftSoftware.org) **Copyright:** Copyright (C) 2026 Mohamed Hammad & Spacecraft Software | **License:** GPL-3.0-or-later **Website:** [https://Construct.SpacecraftSoftware.org/](https://Construct.SpacecraftSoftware.org/) diff --git a/spacecraft-standard-constitution/references/CHANGELOG.md b/spacecraft-standard-constitution/references/CHANGELOG.md index 4ca1350..d576e59 100644 --- a/spacecraft-standard-constitution/references/CHANGELOG.md +++ b/spacecraft-standard-constitution/references/CHANGELOG.md @@ -12,6 +12,7 @@ activation. The canonical record is the published Standard's own `standard/CHANGELOG.md` (extracted from §1 of the document itself in v1.37); this file mirrors it and must be synced to the same version and date. +- **v1.44 (2026-08-05):** **The published Standard's cross-reference table named a skill that does not exist.** Its accessibility row pointed at `spacecraft-accessibility`; the skill has been `spacecraft-accessibility-support` since it was added. **This skill's own table has always been correct**, so the drift was one-directional and only the published document needed fixing — but the failure mode it created was silent: a missing skill does not announce itself, it simply never loads, so §18 work directed by the Standard would have proceeded without its implementation layer. Corrected upstream; every other skill name the Standard cites was verified against the catalogue in the same pass, and this was the only bad one. A cross-reference is normative content like any other clause, and renaming a skill is a two-repo edit. Only the masthead and frontmatter version move here — no rule changes and no section text was touched. - **v1.43 (2026-08-05):** **§3.2.1 published to the Standard — no change to this skill's rules.** §3.2.1 (Platform-Specific Compiler & Linker Flag Caveats) has been in this skill for some time and was **never in the published document**: no version carried it, and neither changelog recorded it. It entered here during a rename commit rather than a normative one, so the bump-and-record step was skipped, and the gap was invisible from both sides — this skill looked complete, and the Standard had nothing to be missing. A section-by-section comparison of the `.texi` against this file surfaced it as the single structural difference across 88 sections. **The rule itself is unchanged and its text here is untouched** — agents loading this skill have been applying §3.2.1 all along; what changed is that the document that is supposed to be normative now contains it. For the record, the section holds that compiler and linker optimization flags are **not universally portable** across operating systems and distributions (systemd-specific settings do not apply to GNU Guix System, Void Linux, or Gentoo with OpenRC; linker and LTO flags likewise track the target's toolchain layout), with **NixOS / Steelbore OS Bravais** as the concrete case: `/nix/store` isolation keeps GCC's LTO plugin off the standard linker search path, so `-flto` **must** be paired with `-fuse-ld=mold` (preferred) or `-fuse-ld=bfd` (fallback) or the build fails to link — generalizing to a requirement that any use of `-flto`, `-march=native`, or PGO be checked against the target OS and the OS-specific requirement documented alongside the flag. It is the platform-specific companion to §3.2: §3.2 says record the flag state, §3.2.1 says the correct state is not the same everywhere. §16 gains no bullet, because its §3.2 item already requires flags to be "applied/disabled with explicit notation." Only the masthead and frontmatter version move here; this skill's `description` measures 976 characters under the §5.6 cap. - **v1.42 (2026-08-05):** **§13 corrected — a component system per platform, not one for every platform.** §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 — so a GTK or Qt application could not pass the §16 audit gate no matter how it was built, and the only honest options were a permanent filed deviation or an application that matches 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. §13 is accordingly rewritten around the requirement that actually carries the intent — **every graphical application declares exactly one component system, in its `README.md` beside the §5.2 posture section, and follows it consistently** — with the system determined by the platform rather than by preference: **Material Design** for Flutter, web, mobile, and cross-platform GUI, and for custom-drawn or immediate-mode UI that declares no platform HIG; **GNOME HIG** via libadwaita for GTK 4; **KDE HIG** via Qt Quick Controls or Fusion for Qt 6. Material Design remains the default wherever the platform supplies no system of its own, so nothing that was compliant under v1.41 becomes non-compliant here — the clause is narrowed, never widened. Three things are explicitly unchanged: **§11 binding is unconditional** — whichever system is declared, every palette reference still goes through the named `steelbore` theme (§11.1), because a component system chooses the widget vocabulary and never supplies the colors; **WCAG 2.2 Level AA** remains the contrast floor with the measured pairing stated; and **§18 still governs wherever the two overlap**. §16's §13 checklist bullet is rewritten from "Material Design UI/UX" to the declare-and-follow form naming all three systems. The Skill Cross-References table gains `spacecraft-gtk-guidelines` and `spacecraft-qt-guidelines` rows, the two skills that implement this section for the native-desktop toolkits; both are Rust-first under §3.1 (`gtk-rs` for GTK, CXX-Qt for Qt), so choosing a native desktop toolkit does not become a route around the memory-safe-language preference. This skill's own frontmatter `description` measures 976 characters under the §5.6 cap (the §7 Shell Environment highlight rotated out to make room for §13). - **v1.41 (2026-08-04):** **§3.1.1 added — TypeScript over JavaScript.** §3.1 named Rust as the preferred language and prescribed ASLR+CFI where Rust is not viable, but had nothing to say about the one runtime where that framing does not apply: JavaScript is already memory-safe, so the memory-safety lever is inert, and the section fell silent exactly where a stability rule was still needed. §3.1.1 supplies it — **type safety is the Priority 1 lever on this runtime**. Where a memory-safe alternative exists (Rust to WebAssembly, Rust or Go on a server, Flutter/Dart for a UI) §3.1 still chooses it; where the JavaScript runtime is genuinely required — a browser page, a Node/Deno/Bun program, an Electron app, an npm-distributed tool, a VS Code extension — the **source language MUST be TypeScript**, and plain JavaScript source becomes a documented exemption rather than a default. Six requirements attach: `"strict": true` plus `noUncheckedIndexedAccess`, `noImplicitOverride`, and `exactOptionalPropertyTypes` (relaxing `strict` is a Priority 1 regression); no `any` and no non-null `!` in production paths (use `unknown` and narrow); `@ts-ignore` prohibited outright in favor of `@ts-expect-error` with a stated reason, which fails the build once the suppression stops being needed; **run-time validation at every trust boundary**, since a type annotation is a compile-time claim and asserting an unverified shape is the silent-failure mode §3.1 already forbids; **`tsc --noEmit` gating CI**, because esbuild, SWC, and Bun strip types without checking them, so a project that only transpiles has not satisfied this section; and loading `spacecraft-typescript-guidelines` before writing or reviewing TypeScript. Emitted `.js` and source maps in a build directory are derived artifacts and out of scope — the rule governs what is authored and committed. Three narrow cases need no filing: a tool's own configuration file that must be `.js` (e.g. `eslint.config.js` where no TypeScript loader exists), a vendored or upstream-derived file carried under §4.2, and generated output. Everything else — including "it is only a small script" — requires a documented technical exemption, on the same footing as the §3.1 memory-safe-language exemption. §16 gains a checklist bullet; the Skill Cross-References table gains a `spacecraft-typescript-guidelines` row. This skill's own frontmatter `description` measures 978 characters under the §5.6 cap (the §4.3 LICENSE-symlink highlight rotated out to make room for §3.1.1). diff --git a/spacecraft-theme-factory.skill b/spacecraft-theme-factory.skill index 66bfca8..89c1394 100644 Binary files a/spacecraft-theme-factory.skill and b/spacecraft-theme-factory.skill differ diff --git a/spacecraft-theme-factory.zip b/spacecraft-theme-factory.zip index 775a498..89c1394 100644 Binary files a/spacecraft-theme-factory.zip and b/spacecraft-theme-factory.zip differ diff --git a/spacecraft-theme-factory/SKILL.md b/spacecraft-theme-factory/SKILL.md index 8f18e9e..980c51d 100644 --- a/spacecraft-theme-factory/SKILL.md +++ b/spacecraft-theme-factory/SKILL.md @@ -12,7 +12,9 @@ website: https://Construct.SpacecraftSoftware.org/ **Copyright:** (C) 2026 Mohamed Hammad & Spacecraft Software | **License:** GPL-3.0-or-later **Website:** [https://Construct.SpacecraftSoftware.org/](https://Construct.SpacecraftSoftware.org/) -> **Source of truth:** The Steelbore Standard v1.42 (§11 Colour Palettes, §12 Typography) +> **Source of truth:** The Steelbore Standard — §11 (Colour Palettes) and §12 +> (Typography), tracked as sections rather than pinned to a document version, +> which would go stale on any unrelated release — > and the `spacecraft-brand-guidelines` skill. Themes may not introduce > colors, fonts, or naming outside what these sources define. The palette below > is the **Steelbore 2** generation; the five v1.33 foreground tokens and the old diff --git a/steelbore-color-palette.skill b/steelbore-color-palette.skill index 1fbce45..fe6d371 100644 Binary files a/steelbore-color-palette.skill and b/steelbore-color-palette.skill differ diff --git a/steelbore-color-palette.zip b/steelbore-color-palette.zip index 20fc855..f08f3cf 100644 Binary files a/steelbore-color-palette.zip and b/steelbore-color-palette.zip differ diff --git a/steelbore-color-palette/SKILL.md b/steelbore-color-palette/SKILL.md index 76a9ab7..35afa97 100644 --- a/steelbore-color-palette/SKILL.md +++ b/steelbore-color-palette/SKILL.md @@ -25,10 +25,11 @@ website: https://Construct.SpacecraftSoftware.org/ **Copyright:** (C) 2026 Mohamed Hammad & Spacecraft Software | **License:** GPL-3.0-or-later **Website:** [https://Construct.SpacecraftSoftware.org/](https://Construct.SpacecraftSoftware.org/) -> **Authority chain:** The Steelbore Standard §11 — current as of Standard -> v1.42, last amended in v1.39 — is the normative text; this skill is its -> canonical machine-readable mirror and the **only** place palette hexes -> should be read from. If this skill and the Standard ever +> **Authority chain:** The Steelbore Standard **§11** — last amended in v1.39 — +> is the normative text; this skill is its canonical machine-readable mirror and +> the **only** place palette hexes should be read from. The version cited is the +> one in which §11 last *changed*, not the current document version: a release +> that does not touch §11 leaves this skill current. If this skill and the Standard ever > disagree, the Standard governs — and this skill must be fixed. Consumer > skills (`spacecraft-brand-guidelines`, `spacecraft-theme-factory`, > `spacecraft-accessibility-support`, `spacecraft-document-format`) define