docs: rewrite README with a consistent house style

[safiqsindha]

Summary

Rewrites the README header and footer around a house style shared across all 19 of your repos, modelled on tt-a1i/archify. The body — subsystems table, power-curve attribution, quickstart, layout, design docs — is preserved unchanged.

What changed

• Themed banner, amber accent with an ascending-bars motif, sharing the FRC family palette with 2950-robot
• Badges moved from the bottom to the top. They were previously in a ## Test / CI Status section at the end, labelled "(Badge placeholders)". They now lead, and the honest "no public CI wired yet" caveat moved into a ## Testing section where it belongs — the disclaimer is preserved, not dropped.
• Four value-prop bullets pulling the concrete numbers already in the repo up above the fold: 98% Oracle accuracy, per-season coupling attribution, ~$10.50 per 1,200-match season for Eye
• A ## Scope section stating plainly that this is a team-specific meta-system rather than a general FRC library, and noting the deliberate CAD-generation cut with a link to the postmortem

Verification

• Every relative link resolves to a file that exists in the repo
• Both SVGs rendered and visually checked on light and dark backgrounds
• No code, config, or subsystem behaviour touched

Notes

No LICENSE file exists in this repo — the License section says so rather than implying terms that are not declared. Worth adding one, particularly since this is public.

---

Generated by Claude Code

[safiqsindha]

CI is red, but not because of this PR

test (3.11) and test (3.12) both fail on 1c08dfc. This PR changes README.md and adds two SVGs — it touches no Python, no test, and no dependency file. Not fixing it here, because the fix belongs in its own PR rather than widened into a docs change.

It is red on main too — and always has been

Every CI run on main has failed, all 10 of them, back to run #1 (ci: add GitHub Actions workflow for tests + mypy). This workflow has never been green. So this isn't a regression my branch introduced; it's the pre-existing state of the check.

I'm not spending a re-run on it. Both errors are deterministic (a missing package and a missing binary), not flakes, and 10/10 base failures is stronger evidence than one re-run would be.

Two collection errors, two distinct root causes

1. scipy is missing from requirements.txt.

tests/scout/test_trueskill_ratings.py
  → scout/trueskill_ratings.py:36  _ENV = trueskill.TrueSkill(...)
  → trueskill/backends.py:107      from scipy.stats import norm
E   ModuleNotFoundError: No module named 'scipy'
E   ImportError: Install "scipy" to use this backend

requirements.txt pins trueskill>=0.4.5 but not scipy. TrueSkill needs SciPy for its CDF backend and does not declare it as a hard dependency, so a clean install produces a package that raises on first use. It works locally only because something else pulled SciPy in.

  trueskill>=0.4.5
+ scipy>=1.11

2. The ffmpeg guard raises instead of skipping.

# tests/integration/test_eye_pipeline_smoke.py:40
_ffmpeg_check = subprocess.run(["ffmpeg", "-version"], capture_output=True, timeout=5)
if _ffmpeg_check.returncode != 0:
    pytest.skip("ffmpeg not found on PATH", allow_module_level=True)

The intent is right and the comment above it says "skip gracefully if dependencies missing" — but subprocess.run raises FileNotFoundError when the binary is absent, so execution never reaches the returncode check. The graceful skip only works when ffmpeg is present. Suggested fix:

-_ffmpeg_check = subprocess.run(
-    ["ffmpeg", "-version"], capture_output=True, timeout=5
-)
-if _ffmpeg_check.returncode != 0:
+try:
+    _ffmpeg_check = subprocess.run(
+        ["ffmpeg", "-version"], capture_output=True, timeout=5
+    )
+except (FileNotFoundError, subprocess.TimeoutExpired):
+    pytest.skip("ffmpeg not found on PATH", allow_module_level=True)
+if _ffmpeg_check.returncode != 0:
     pytest.skip("ffmpeg not found on PATH", allow_module_level=True)

Note the pytest.importorskip("cv2", ...) on the line above is the correct pattern — this one just needed the same treatment.

Why -m "not integration" doesn't save you

The workflow runs pytest -q -m "not integration", so it looks like the integration test should be excluded. It isn't: marker deselection happens after collection, and both failures are import-time crashes during collection. A module that explodes on import takes the run down whether or not its tests would have been deselected.

Worth knowing separately: pytest.ini sets addopts = -m "not benchmark", and the workflow's own -m "not integration" replaces it rather than combining. If you want both, use -m "not integration and not benchmark".

Suggested path

Both fixes are small and independent of this PR. A separate PR adding scipy>=1.11 and wrapping that subprocess.run should turn this workflow green for the first time — worth confirming the rest of the suite passes once collection succeeds, since it has never had the chance to run.

---

Generated by Claude Code