rick/LEDMatrix
1
0
Fork 0
mirror of https://github.com/ChuckBuilds/LEDMatrix.git synced 2026-08-22 19:08:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs(sports): scope the B5 safety claim to the fallback

Browse Source 
The heading read "B5 — adoption is safe by construction", which this same
document disproves two sections later: four of the eight adopted plugins
shipped with scroll mode broken on a 3.2.0 core and were repaired in
plugins #251.

The body was already careful -- it says fallback compatibility is what is
guaranteed, and that correctness on a core which *does* ship the module
needs object-level and scroll-mode validation. The heading was not, and a
heading is what a reader scanning the plan actually takes away.

Retitled to name both halves, with a sentence up front saying why the
unqualified claim is false and pointing at the retrospective that shows
it. The phase intro said "one of them is safe by construction and the
other is not"; that now says what it actually means -- one cannot break a
user on an old core, the other can.

The second review point, MD018 on the ATX heading at line 409, does not
reproduce: that line now begins "(#431, #433)" rather than "#433)", so
there is no bare-hash heading. `grep -cE '^#+[^ #]'` returns 0 for the
whole file.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01STMbQE4YctTacQXfbYqKuW
This commit is contained in:
ChuckBuilds
2026-08-21 16:20:12 -04:00
co-authored by Claude Opus 5
parent ed2b81a4fb
commit cc6a75712c
1 changed files with 9 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/SPORTS_UNIFICATION.md
+9 -4
View File
@@ -204,7 +204,7 @@ legacy compatibility rather than the mechanism.
B0–B3 are merged and shipping in core 3.2.0. Everything that remains is B0–B3 are merged and shipping in core 3.2.0. Everything that remains is
**rollout**, and it splits into three phases with very different risk profiles. **rollout**, and it splits into three phases with very different risk profiles.
The original plan folded the last two together; they are separated here because The original plan folded the last two together; they are separated here because
one of them is safe by construction and the other is not. one of them cannot break a user on an old core and the other can.
| Phase | Scope | Status | Gate | | Phase | Scope | Status | Gate |
|---|---|---|---| |---|---|---|---|
@@ -262,13 +262,18 @@ default is the more restrictive.
`compatible_versions`. No manifest still carries it, so there is nothing to `compatible_versions`. No manifest still carries it, so there is nothing to
migrate there.) migrate there.)
### B5 — adoption is safe by construction ### B5 — the *fallback* is safe by construction; the modern path is not
The heading matters, because the unqualified version of this claim is false and
this document proves it two sections down: four of the eight adopted plugins
shipped with scroll mode broken on a 3.2.0 core. What is safe by construction is
narrower than "adoption".
A plugin adopting core imports keeps its bundled copy and reaches it through the A plugin adopting core imports keeps its bundled copy and reaches it through the
guarded import (see the Upgradability table above). On a core that doesn't ship guarded import (see the Upgradability table above). On a core that doesn't ship
the module the plugin falls back and behaves exactly as it does today. That the module the plugin falls back and behaves exactly as it does today. That
fallback compatibility is safe by construction. On a core that *does* ship the fallback compatibility — and only that — is safe by construction. On a core that
module, correctness is not automatic — object-level and scroll-mode validation *does* ship the module, correctness is not automatic — object-level and scroll-mode validation
(building both classes and comparing, per the retrospective below) is required (building both classes and comparing, per the retrospective below) is required
to prove full behavior. There is no version of this step that breaks a user *on to prove full behavior. There is no version of this step that breaks a user *on
an old core*, which is why it does not wait for B6's gate. an old core*, which is why it does not wait for B6's gate.