Commit Graph

4 Commits

Author SHA1 Message Date
Grant
451c2c353f docs: record 14 Jul session design — widget wiring map, depth dual-source, fault-injection required, FSM rework top priority
docs/design_intent_register.md v1.5:
- New DIR-13 — widget-to-hardware ownership map. W1 is a two-stage health
  gate: RPi4 FC-heartbeat MUST pass first (implemented, 86b2728), then RPi5
  autonomy-stack self-health (not yet built) — only when both pass is W1
  GREEN. W5 reflects the RPi4-connected battery. W2/W3/W4/W6/W8 reflect the
  RPi5 stack; W6 deliberately kept RPi5-direct per the standalone-autonomy
  principle. W7 specced, not built. Cross-references DIR-12.
- New DIR-14 — depth as a dual-source, operator-selectable input: RPi4
  sensor (via the FC), an RPi5-direct sensor, or a blend, selected at
  mission setup (W4) and carried in the resolved mode profile like
  health_role. Redundancy plus operator choice. Design-captured, not yet
  specified in detail.

docs/handover.md v2.27:
- New §9 widget-to-hardware wiring table matching the DIR-13 ownership map.
- Test-data/fault-injection capability flagged as an approaching required
  workstream, not optional — the failsafe logic (and the pending count-
  based FSM rework) cannot be properly tested without injecting sensor
  states and simulating running-vs-failed conditions. Incremental approach
  agreed: altitude/depth/sonar first. Near-term prerequisite for validating
  the FSM rework; added to §0 PARKED/NEXT and §16.
- FSM rework to the corrected count-based model (255096f) reconfirmed as
  top build priority — 2a3e577/bf815cc's condition-clear commit logic
  remains known-wrong pending that rework. Recorded as related to, and to
  be planned alongside, W1's RPi5-side health gating (DIR-13) and the
  fault-injection capability above.
- Confirmed and recorded: W2 reflects live mission state (observed ABORTED
  after a live abort); W3's label change to RETURN TO SAFE is complete
  (9aa5b5d) — stale references to this as outstanding work corrected in
  §0 Blocked/Open Items/NEXT and §16. argonaut-api.service manual-start
  reminder recorded for rov_api/backend testing.
- DIR pointer section bumped to DIR-1 through DIR-14.

Documentation only — no code, widget, or diagram files touched. Not
uploaded to Claude project knowledge; that remains a manual step.
2026-07-14 11:21:44 +02:00
Grant
255096f20b docs(dir): correct inverted DIR-7 in-mission-recovery intent to count-based fault-persistence model
The 11 Jul DIR-7 addendum "In-mission recovery is mode-dependent" stated
that AUV gate mode commits to recovery ON CONDITION-CLEAR. That was
inverted and wrong — it produced a contradictory GREEN-while-in-
RETURN_TO_SAFE state observed live.

Corrected intent (v1.4, 13 Jul 2026, attributed to Grant):
- GREEN is unconditionally a working state. A cleared fault returns the
  vehicle to GREEN and the mission continues/resumes; a cleared condition
  must never trigger or commit a recovery. Committed recovery is triggered
  by a fault PERSISTING or RECURRING, never by it clearing.
- Three-tier fault model: (1) uncontrollable — power loss / anything that
  disables the safety logic itself, out of scope for the FSM, adjacent to
  shelved DIR-6; (2) transient/self-resetting — system attempts restore,
  returns to GREEN and resumes on success, each failure increments a raw
  count (deliberately no time window/duration), commits to RETURN_TO_SAFE
  only once the count exceeds a configured acceptable number; (3)
  hard/persistent — a RED that doesn't clear, commits immediately without
  waiting on a count.
- All thresholds (acceptable count, transient-vs-hard classification) are
  configuration-driven via the resolved mode profile, same as health_role,
  never hardcoded.
- Survives, correct: health_role mode-awareness (2a3e577); the
  safe-zone-reached arrival-exit mechanism (bf815cc) — its role (completing
  a committed recovery) is unchanged. Retired, known-wrong: 2a3e577's
  condition-clear entry logic, which bf815cc built its exit on top of —
  pending next-session rework into the count-based model. Only the ENTRY
  into committed recovery was wrong, not the exit.

New Parked Design Item: adaptive restart-timing — monitor own restore
count/duration per fault, log it, weigh future restart attempts against
observed history rather than a fixed time. Deliberately holds all
time/duration sophistication kept out of the count-based correction;
depends on the count-based retry machinery existing first. Design-captured,
not yet specified for build.

Changelog and known-implementation-drift callout updated accordingly —
failsafe_monitor's current condition-clear logic is now flagged as a known
implementation gap pending rework, not merely an unimplemented addendum.

Documentation only — no code or widget files touched. Not uploaded to
Claude project knowledge; that remains a manual step.
2026-07-13 18:02:42 +02:00
Grant
0eca8fef11 docs: record 13 Jul session — mode-system launch fix, gate-mode arrival event, safe-zone-reached parked item
docs/handover.md v2.25:
- mode_profile_loader found never wired into rov_full.launch.py despite being
  committed 7 Jul (4e48dc2) — /rov/mode/profile had zero publishers at
  runtime since; fixed with respawn (464e17e), verified live (0->1)
- failsafe_monitor's mode-aware recovery (2a3e577) surfaced a second gap:
  gate-mode RETURN_TO_SAFE was a terminal trap; closed by the new permanent
  /rov/nav/safe_zone_reached interface (bf815cc), verified live end-to-end
  on the bench; today's publisher is temporary bench scaffolding only
- new §15f narrative section; §0 Confirmed Working, PARKED, NEXT, Recent
  Commits, Version History, and Changelog all updated accordingly
- two pre-existing failsafe_monitor defects found this session (not caused
  by it), flagged in §0 Open Items and §15f: flag_manual_abort is a
  one-way latch never reset (shadows all lower-priority handling after any
  manual abort — field-deployment concern); failsafe_monitor produces no
  log output in journalctl (cost diagnostic time this session)

docs/design_intent_register.md v1.3:
- new Parked Design Item: mode-aware safe-zone-reached arrival event —
  permanent /rov/nav/safe_zone_reached interface, mode-aware/sensor-derived
  arrival judgement (GPS at surface + EKF/dead-reckoning underwater), GPS
  recorded as first-class across mission types (not hull/jacket-specific),
  gate-only scope, temporary W1-button bench-scaffolding publisher pending
  navigation — cross-referenced to the DIR-7 "in-mission recovery is
  mode-dependent" addendum, whose Implementation note is updated to record
  the mechanism is no longer mode-blind (2a3e577)

Not uploaded to Claude project knowledge — that remains a manual step.
2026-07-13 11:55:52 +02:00
Grant
5551173b7a docs: restructure into docs/, CLAUDE.md rules-only, DIR v1.2, handover v2.24 2026-07-11 18:46:58 +02:00