P0: Stabilize & decide

Open
  • Is something wrong?
#16 1 comment 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
15/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
github-actions, python
Domain
backend, devops

Research direction

Start with openspec/changes/p0-stabilize-foundation/tasks.md and the linked architecture sections in docs/rewrite/05-target-architecture.md and docs/rewrite/99-ctre-device-serial-numbers.md. The issue says most repository work is done; remaining tasks require live robot checks and team review, with robot checks tracked in #13. Done means the ADR review is complete and the corpus, CI skeleton, and CAN inventory requirements in the stated exit criteria are satisfied.

Written by the indexing model from the issue text.

Description

roadmap

Size: S · Depends on: nothing · OpenSpec: p0-stabilize-foundation

Status

Update 2026-10-23: what's left is [HUMAN] 6.3 (check the CAN device fields on a live robot), 6.4 (confirm /Flashpoint/CANInventory in a fresh log from each robot) and 7.2 (unit registry walk with Tuner X), tracked in #13. Team review of the ADRs is still open. Repo work is done: legacy-2025 and archive/* tags, main protected (ci-ok required), rewrite merged into main 2026-10-22, repo public with the owlet binaries purged from history.

Update 2026-10-19: what's left is [HUMAN] 6.3, 6.4 and 7.2, tracked in #13. Team review of the ADRs is still open.

Status: in progress (started 2026-10-04). Done: CI skeleton, tags, ADRs (D1–D10 Proposed, D11 Accepted), corpus-v1, Pro/compliancy findings, robot inventory logger PRs (IgniteRobotics/Robot-2026#107, IgniteRobotics/Phoenix-2026#12), retire-legacy-code stage 1. Open: [HUMAN] verify getdevices field names on a live robot, confirm /Flashpoint/CANInventory in fresh logs, Tuner X unit walk, team review of the ADRs. Tracked in openspec/changes/p0-stabilize-foundation/tasks.md.

Scope

  • Repo:
    • Tag the current main as legacy-2025.
    • Archive the branches under archive/*: development, power-tracking, static-site, dataviz, docker.
    • Delete hoot-support.
    • Protect main and require PRs plus CI.
  • Decisions: make the calls D1–D11 in 05 §6. Record each as a short ADR in docs/adr/.
  • Golden corpus: pick about 6 real logs and commit them through LFS or a fetch script.
    • one qual wpilog, plus its rio and CANivore hoots
    • one practice log
    • one non-FMS log
    • one log with a corrupt tail
    • one 2025 log and one 2026 log (owlet versions)
  • Robot-side CAN inventory logger (all robots): implement the contract in 05 §4a and 99.
    • First open http://<rio>:1250/?action=getdevices against the current Phoenix 6 robot to confirm the field names. The only documented example is from Phoenix 5 (CTR Electronics, n.d.-h).
    • Ship it before the next practice session, because every log recorded without it becomes a legacy-identity log.
    • Back-fill a units seed: walk each robot and spare shelf with Tuner X, record each serial against its slot, and label the motors physically.
  • Pro check: run owlet --check-pro (Mechanical Advantage, 2026) on the corpus. ✅ Done 2026-10-04: all hoots are Pro-licensed (ADR-0005). --compliancy was also found to be the owlet selection key (ADR-0004).
  • Exit: ADRs merged, corpus available, CI skeleton green, /Flashpoint/CANInventory present in a fresh log from every robot.

Moved from the rewrite roadmap on 2026-10-19. That doc keeps the dependency graph, migration, quality gates and risks. Status lives here. Author-year citations are in references.md. pitfall N refers to 03-pitfalls-and-performance.md.

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.