Visually validate TM1637, PWM, enclosure fade, power/RGB, and D6 strip #71

Original request

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

Perform final verification on the real board, including illumination, status LED transitions, displays, and every safely testable output.

Source: session origin-main, authored turn 82.

Parent epic: #13

Requirement

Visually validate TM1637, PWM, enclosure fade, power/RGB, and D6 strip

Acceptance criteria

• Confirm smooth responsive TM1637 measurements and editor blink behavior.
• Identify and exercise every named PWM user channel plus the host demo macro without disturbing system-owned channels.
• Observe both enclosure fade directions, power indication, coherent RGB animations, and strip pixel order.
• Confirm emergency clear and ordinary mode-off recovery behavior.
• Verify door-open and door-closed TM1637 brightness persistence, true-off value 0, and both fade directions when prompted by WAIT/ringtone.

Current evidence and gaps

Source and read-only live telemetry are available, but the requested visual/output validation under safe conditions is pending.

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.

Isolated addressable-strip diagnosis

Media timing and MCU expansion roadmap (merged PR #608; complete successor reconciliation PR #619) preserves the requested known-good library experiment. This documentation checkpoint does not authorize flashing or claim physical success.

• Coordinate the physical-board owner and capture identity/settings/readback before any bridge-managed temporary flash. Define the production restore artifact and known-safe final output state first.
• Verify actual chipset, supply/current limit, color order, DIN/DOUT, common ground, D6 continuity and logic level. Begin with a short low-brightness test (ten pixels proposed, not a claimed board descriptor).
• Use a standalone sketch or named diagnostic-only profile with FastLED pinned through normal dependency management. Compare the compact sender and minimal WS2811 library driver on the existing configured pin, verified count/order, low brightness. Test red/green/blue, safe low-brightness white, black and moving/rainbow patterns; test plausible orders independently. Do not operate relay/motion outputs.
• Record first-segment supply voltage, common ground, DIN/DOUT, continuity, data idle level, waveform/reset timing when available, colors/current and separate custom-sender/FastLED/optional external-known-good MCU outcomes; native buffer tests cannot prove the physical waveform.
• If results are intermittent, inspect signal integrity, supply, interrupt/timing interactions and first-pixel behavior. Library-only success prioritizes custom timing/staging/ownership investigation, not automatic production replacement.
• A library success narrows investigation to production command/staging/workspace/waveform paths. Failure in both is inconclusive: use a scope/logic analyzer and known-good external driver before declaring an electrical fault.
• Restore production through bridge and verify HELLO, settings/readback and final output state. Attach sanitized evidence here and Stream host-rendered addressable LED-strip frames with bounded quality effects #390, never private captures or settings.