FIRST Command

Command devlog #2
—Hello again proggers—
5 hours. For a patch-and-test pass. Not because the bugs were hard, because Windows decided the build machine needed an ATL error to ruin a chunk of the day.
ATL. of all things. ATL
Not a feature devlog this time. This one’s the boring-but-necessary kind — patching up bugs, wrestling with the models, and actually testing the stuff from devlog #1 before any of it gets near a push. Command’s Flutter/Dart, so at least the actual app-side debugging felt normal. The build machine did not.
Cat or dog? flutter test
Okay let’s get into it~
—Yap—
No new features this round. Just cleanup. Turns out shipping four features to local branches at once means devlog #2 is entirely “make sure the four features from devlog #1 actually hold up” — and then an 11 hour detour into Windows build tooling that had nothing to do with Dart at all.
—The Great Suffering—
1 — The Windows ATL Bug
The actual reason this took 5 hours. Build machine choked on an ATL-related error that had nothing to do with the Flutter/Dart side of things and everything to do with Windows being Windows. Ate a big chunk of the day before the rest of the work could even start.
a Flutter project should not know what ATL is, and yet
2 — General Patch-Up
Once the build machine cooperated, a round of small bug fixes across the existing work — nothing dramatic enough for its own section, just the usual pile of “that’s not supposed to do that” from actually testing instead of building.
3 — Model Issues
Ran into friction on the model side, the kind that only shows up once real data flows through instead of a clean test fixture.
4 — Testing, Actually
Spent real time testing rather than building, a different muscle entirely, and found what needed finding because of it.
—FAQ (no one asked these but they are here)—
Q: What is a “progger”?
A: A human programmer. You. The one who lost a chunk of the day to a Windows Active Template Library error in a Dart project.
Q: What is Command built in?
A: Flutter and Dart.
Q: What’s ATL doing in a Flutter build pipeline?
A: A very good question. Windows build tooling drags in native dependencies that have nothing to do with your actual language, and one of them decided to break.
Q: Why no new features this devlog?
A: Because four features from last time needed to survive testing, and then 5 hours went to a build machine instead.
Q: Is any of this pushed yet?
A: Still local. Getting closer, slower than planned.
—This is the end*—
*end for now, Windows build tools permitting
PIPER!!!

Command devlog #1
—Hello again proggers—
New project, new devlog series. This is Command, and this is its very first entry, kicked off with the first real batch of changes since fc.deltaavdevs.com went live. Four features, backend and frontend both, all sitting on local testing branches — nothing pushed yet, on purpose.
Cat or dog? view_alliance
Okay let’s get into it~
—Yap—
FIRST scouting tooling apparently needed team assignment, performance auditing, cross-alliance data sharing, and import support all at once, so that’s what got built. Everything here is local-only for now. Testing branches exist for a reason.
—The Great Suffering—
1 — Assign Scouts To Teams
New /api/assignments* endpoints plus scout_assignments_page.dart on the frontend. Completion is computed live from existing reports instead of tracked as a stale flag that drifts out of sync with reality the moment someone forgets to update it.
2 — Performance Auditing
/api/scouts//performance plus feedback notes, computed from existing data rather than some separate tracked metric. Framed deliberately as coaching signal, not a score — nobody needs a leaderboard of who’s worst at scouting. Includes a feedback loop for thanking scouts who turn in good data, since positive reinforcement apparently works better than a spreadsheet judging you silently.
3 — Cross-Team Data Sharing
/api/alliance/shares, unilateral grant model with separate pit/notes permission toggles. Reuses view_alliance/edit_alliance permissions the codebase had already reserved at some point and just never actually implemented. Nice to finally use something that’s been sitting there.
4 — Import From Other Apps
“RadioScoutz” turned out to be Scoutradioz once actually searched for, confirmed and supported directly. “Manta” didn’t match any real app that could be found, so instead of guessing a format and hoping, it falls through to the generic CSV/JSON importer. Every import is undoable in one call, because guessing wrong on an import shouldn’t mean manually cleaning up a database.
5 — Found During Self-Review: The Import Bug
Self-review turned up a real one: the import route had no per-row error handling on the DB insert loop. One bad row could silently corrupt a batch’s reported counts with no error surfaced anywhere. Fixed before this ever got near a real import.
found it myself before it found someone else, counts as a win
—FAQ (no one asked these but they are here)—
Q: What is a “progger”?
A: A human programmer. You. The one starting a brand new devlog series on top of three other ones.
Q: Why nothing pushed yet?
A: Four features touching backend and frontend at once deserves local testing first, not a live branch someone else pulls mid-break.
Q: What’s “Manta” actually referring to?
A: Unknown. Searched, found nothing matching a real scouting app by that name, so it’s just generic importer territory until proven otherwise.
Q: Is performance auditing going to make scouts feel judged?
A: That’s specifically what the “coaching signal, not a score” framing and the thank-scouts feedback loop are trying to avoid.
Q: Was the import bug caught before it broke anything real?
A: Yes, self-review, before it touched a real batch.
—This is the end*—
*end for now, unpushed branches permitting
FRC!!!