Open [HUMAN] verification tasks across OpenSpec changes

Open
#13 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
1/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
python
Domain
testing-qa

Research direction

Start with the referenced change tasks and their design.md files, then follow each checklist item at its named entry point: robot, USB, backup, pit laptop, PyPI release, or student walkthrough. Run the listed commands and checks, recording results in the specified design files and checking off both task lists. Done means every human verification task has a recorded result and is checked off.

Written by the indexing model from the issue text.

Description

Every unchecked [HUMAN] task across OpenSpec changes, open or archived (updated 2026-11-01). Each item names its change and task number. Record results where the task says (usually that change's design.md, under openspec/changes/archive/ once archived), then tick the box in its tasks.md as well as here.

Grouped by where the work happens, so one trip covers several.

At the robot (roboRIO powered, laptop on its network)

  • P0 6.3: CAN device fields. On a live Phoenix 6 robot, open http://<rio>:1250/?action=getdevices and check the field names match what the CanInventoryLogger normalizer expects. Adjust it if not. (p0-stabilize-foundation)
  • P0 6.4: CAN inventory in logs. Deploy the logger to each robot, run it, pull a fresh wpilog, and confirm /Flashpoint/CANInventory holds real serial numbers. (p0-stabilize-foundation)
  • P0 7.2: Unit registry walk. With Tuner X, walk every robot and the spare shelf. Fill in config/units/units-seed.csv and physically label each motor (see config/units/README.md). (p0-stabilize-foundation)
  • P3 11.1: Live rio checks. Reboot the rio with no Driver Station and list log mtimes (stat -c '%y %n' per root) to see if the clock reset breaks the newest-file-is-active rule. Then confirm log roots, sha256sum and df exist, lvuser auth works, transfer MB/s over radio and tether, and sha256sum time per 100 MB. Record in design.md. (p3-log-acquisition)
  • P3 11.3: Unattended exit check. Run the watch as a service, plug the robot in after a practice match, and confirm the match is in gold within 5 minutes. (p3-log-acquisition)
  • live-can-health 7.3: Live CAN pit check. With the Robot-2026 PR deployed: shake test disabled (wiggle a drive module harness and see an isolated dropout with the mark), then a drive test enabled. Record the results in the change and here. (archived 2026-11-01-live-can-health)
  • acquire-replay-build 4.3: Replay without restart. Run flashpoint acquire --watch beside flashpoint serve, bring in a new match, reload the page, and confirm it's in Replay. Note the cycle time. (archived 2026-10-15-acquire-replay-build)

USB sticks

  • P3 11.2: Robot USB stick on Linux and Windows. macOS passed 2026-10-05. On each OS: the stick is detected and copied, "safe to remove" is logged, and the stick is unchanged. (p3-log-acquisition)

Backup

  • P3 11.4: Drive backup + restore drill. Configure the team's rclone remote (backup.remote in acquire.toml), run flashpoint backup, then restore → rebuild → doctor into a scratch lake (see docs/guide/auto-import.md#restore-drill). (p3-log-acquisition)
  • config-backup 4.3: Config backup with the real remote. On the pit laptop: run flashpoint backup and check the remote has config/latest. Edit a robot in the Setup view and confirm the watch backs it up within one interval. Then run the restore drill into a scratch lake and scratch config folder. Record in design.md. (archived 2026-11-01-config-backup)
  • backup-overdue 4.3: Overdue badge. On the pit laptop: turn off Wi-Fi, import a match, set overdue_h = 1, and confirm the Setup badge and the doctor problem appear after an hour and clear after a backup with Wi-Fi back. Record in design.md. (archived 2026-11-01-backup-overdue)

On the pit laptop with ~/flashpoint-lake (flashpoint serve)

  • ui-cross-tab-filters 6.3: Shared filters. Pick GACMP in Replay and check that History and Anomalies follow. Clear on Anomalies, and check that Replay lists every match. Minimize each rail on each view and reload. Group the queue by device. Note anything odd. (archived 2026-10-13-ui-cross-tab-filters)

  • team-branding 5.3: Presets on real screens. Look at each preset (amber, green, blue, red, white) and one custom team palette on the pit laptop and on a projector. Record any preset that reads poorly in design.md and here. (team-branding, merged in #42)

  • history-shared-sparkline-scale 3.3: Sparkline readability. In History, check the can-health metrics (CAN gaps, reboots) and peak temperature: rows compare at a glance, and temperature rows stay readable against the zero baseline. (archived 2026-10-13-history-shared-sparkline-scale)

  • P5 9.3: Detection tuning on the full season. Add the remaining 2026 logs (GACOL's Drive folder was empty), run flashpoint detect and flashpoint backtest, add any known failures to config/failure-labels.toml, and review the false-positive rate per method. Record threshold changes. (archived 2026-10-12-p5-anomaly-detection)

  • ingest-retry-and-refresh 6.3: Offline owlet retry. On the machine that hit GAGAI1 Q4 (or with networking off): ingest a new hoot with owlet not cached and check it reports failed (owlet-download-failed), will retry. Reconnect, ingest again, and check it reaches success and the match opens in Replay with no flashpoint report. Record in design.md and here. (archived 2026-11-01-ingest-retry-and-refresh)

Release (PyPI)

  • team-setup 1.2: Claim the PyPI name. Done: flashpoint 0.1.0 is on PyPI with the trusted publisher, and 2.2 (release workflow) is done.
  • team-setup 4.3: First release. Tag v0.2.0, install with pipx install flashpoint on a clean machine, run flashpoint init and ingest the corpus. doctor should report only "no robot configured". (archived 2026-11-01-team-setup)

With students

  • project-documentation 6.4: Docs walkthrough. At a pit session, a student new to Flashpoint follows docs/guide/user-guide.md from install to Replay, and someone follows auto-import.md to pull from the robot. Note where they get stuck and fix those spots. (archived 2026-11-01-project-documentation)
  • team-setup 9.4: New-team walkthrough. On a clean laptop with no Flashpoint history, a student who hasn't used it installs from PyPI, runs init, drafts a robot from a log, fixes every Setup problem from the view, and imports a match. Record where they got stuck. (archived 2026-11-01-team-setup)

Still-open changes waiting on these: p0-stabilize-foundation, p3-log-acquisition, and team-branding (merged in #42). Changes marked archived were archived with their check still open; this issue is where those checks are tracked.

🤖 Generated with Claude Code

https://claude.ai/code/session_01URHmMsgUwA6665UbAkAPT5

Dominant language
Python
Stars
0
Forks
1
Avg merge
18h 37m
Merged PRs (30d)
15

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from IgniteRobotics/flashpoint

All issues in IgniteRobotics/flashpoint

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.