Skip to content

Load-test relay identification, motion directions, interlocks, and door policy safely #72

Open

Description

@atomicdeploy

Original request

Relevant excerpt, lightly grammar-corrected for publication. Credentials, personal data, private paths, and unrelated transcript content are omitted.

Do final verification by interacting with all parts of the host and board, and record the result for every area rather than assuming hardware behavior.

Source: session origin-main, authored turn 82.

Parent epic: #13

Requirement

Load-test relay identification, motion directions, interlocks, and door policy safely

Acceptance criteria

  • Identify R1-R8 wiring and verify R5-R8 toggle/momentary behavior.
  • Test Side A/B directions, break/settle timing, release-to-stop, cross-side isolation, and safe reset.
  • Exercise closed/open/always/never policy for local, RF, host, macro, and automation sources.
  • Verify door transition stops motion according to policy without an unsafe transient.
  • Begin only after the host has prepared safe loads and issued the WAIT/ringtone prompt; restore all outputs off before ending the pass.

Current evidence and gaps

Implementation-level guards exist, but no complete safely prepared load test covers this matrix.

Traceability

  • Canonical checklist section: Final hardware validation and handoff
  • Includes only curated, issue-relevant prompt excerpts; complete transcripts, credentials, secrets, and private paths remain unpublished.

Activity

  1. added
    🛡️ safetyMotion, reset, programming, or operational safety
    🧪 testingAutomated, simulated, UX, or hardware verification
    🔍 needs-hardwareRequires physical-board observation or operation
    on Aug 1, 2026
  2. atomicdeploy commented on Aug 9, 2026

    @atomicdeploy
    OwnerAuthor

    Loaded-motion acceptance gate

    This issue is the hardware owner for front-panel motion and macro-driven motion against the actual loaded board. #24/#25 own implementation/interlocks; #27/#28 own key/page behavior; #44 owns macro recording/playback.

    Do not perform unattended motion. Before verification: exact board identity, verified flash + EEPROM backups, silent programming latch, outputs forced off, harmless communications first, actuator/load safety confirmed by David, and exact firmware/source hashes recorded. The board is presently not enumerated, so this remains blocked rather than failed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    🔍 needs-hardwareRequires physical-board observation or operation🔥 priority: criticalSafety or release-blocking work🛡️ safetyMotion, reset, programming, or operational safety🧪 testingAutomated, simulated, UX, or hardware verification

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions