Erc Status

/erc-status, project status report

Give a fast, honest snapshot. No fluff.

Steps

1. Read .claude/PROJECT_NOTES.md. The blockers and "Next actions" sections are the source of truth.
2. Read the last entry in docs/BUILD_LOG.md for what actually happened most recently.
3. Compute days remaining to 2026-09-15 from today's date, and state it. This is a fixed external deadline and it should lead the report.
4. Cross-check reality against the notes:
   • Is registration confirmed yet? This is blocker 1 and it gates everything
   • Does a container build and does Gazebo render? This is blocker 2 and the critical path
   • Does src/ contain a real ROS 2 package with solution.launch.py, or just the README?
   • Does docs/verified-topics.txt exist, meaning the day-one verification actually happened?
   • Does results/trials.csv have rows? Without it the report cannot be written
   • Does erc_images/ have images from a real run?
   • Any uncommitted git changes worth mentioning?
5. If the notes and reality disagree, say so explicitly. Stale notes mislead the next session.
6. Check whether the vault is in sync, per docs/VAULT_SYNC.md. If the vault project note is older than the last build log entry, flag it. Note that the vault note may not exist yet.

Output format

## ERC-26: <days> days to Phase 1 (2026-09-15)

**Build phase:** <N, name> (<status>)

**Done recently:** <1-3 bullets>
**In flight:** <what's actually being worked on>
**Blocked on:** <registration, environment, or a real technical blocker>
**Points banked:** <from results/trials.csv, or "none logged yet">

## Next action (do this literally next)
<one concrete step>

Rules

• Lead with days remaining. The deadline is fixed, external, and 29 days out as of 2026-08-17. Every status report should make the clock visible.
• One next action, not five. The plan lists everything; this skill picks the next thing.
• Registration is unresolved until it is confirmed. The 2026-06-30 deadline passed. Don't report the project as healthy while that is open, and don't assume either answer.
• Never report points as banked unless a logged trial recorded them. "The detector works" is not points. A row in results/trials.csv is.
• Respect build-order discipline. Never suggest a later phase task while an earlier phase lacks its gate. Specifically, do not suggest grasp work before the two perception nodes pass 20 of 20 reloads, because the cheap points come first for a reason.
• If a gate says done but the deliverable doesn't exist on disk, it is not done. Say so.
• Never report a rule detail as confirmed when docs/RULES.md marks it (assumed) or lists it as an open question.
• If the 2026-09-06 grasp decision date has passed and the grasp isn't working, raise it. That decision is supposed to be made deliberately, and a status report is where it should surface.