Record two container-testing traps in Verification Discipline by ptr727 · Pull Request #170 · ptr727/ESPHome-NonRoot

ptr727 · 2026-07-19T03:20:04Z

Two traps found while verifying the version history default (#169) against the published develop image. Both are recorded because both produced a passing-looking result from a test that never actually ran.

Scanner is gated on WebSocket subscriber presence. Device Builder's background poll for external YAML edits parks when no client is subscribed. A headless "edit a file, wait, observe no commit" test therefore proves nothing - it watched a scanner that was never running. This was caught only because the enabled-case control was also silent, which is the signal that the harness rather than the feature was off. With a subscriber attached the control commits immediately, unsigned and under the fabricated identity, and the disabled case stays clean.

docker cp into a tmpfs-backed path writes underneath the mount. The compose stack mounts tmpfs at /tmp; a helper script copied there is absent at runtime, and the step depending on it silently no-ops while still reporting success.

Docs only - no behavior change.

🤖 Generated with Claude Code

Both surfaced while verifying the version history default against the develop image, and both produce a passing-looking result from a test that never ran. Device Builder's filesystem scanner is gated on WebSocket subscriber presence, so a headless "edit a YAML and wait" test observes a scanner that is parked. The first disabled-case run looked like a pass for the wrong reason; the enabled-case control was equally silent, which is what exposed it. docker cp into the tmpfs-backed /tmp writes underneath the mount, so a helper script staged there is absent at runtime. A subscriber that was never started still reported success. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Records two verification pitfalls encountered while testing Device Builder behavior in containers, strengthening the repo's "Verification Discipline" guidance to prevent false-positive test results.

Changes:

Document that Device Builder's filesystem scan for external YAML edits is gated by having an active WebSocket subscriber.
Document that docker cp into a tmpfs-backed path (e.g., /tmp) can write underneath the mount and be invisible at runtime, causing silent no-ops.

ptr727 · 2026-07-19T03:20:04Z

Two traps found while verifying the version history default (#169) against the published develop image. Both are recorded because both produced a passing-looking result from a test that never actually ran.

Scanner is gated on WebSocket subscriber presence. Device Builder's background poll for external YAML edits parks when no client is subscribed. A headless "edit a file, wait, observe no commit" test therefore proves nothing - it watched a scanner that was never running. This was caught only because the enabled-case control was also silent, which is the signal that the harness rather than the feature was off. With a subscriber attached the control commits immediately, unsigned and under the fabricated identity, and the disabled case stays clean.

docker cp into a tmpfs-backed path writes underneath the mount. The compose stack mounts tmpfs at /tmp; a helper script copied there is absent at runtime, and the step depending on it silently no-ops while still reporting success.

Docs only - no behavior change.

🤖 Generated with Claude Code

Both surfaced while verifying the version history default against the develop image, and both produce a passing-looking result from a test that never ran. Device Builder's filesystem scanner is gated on WebSocket subscriber presence, so a headless "edit a YAML and wait" test observes a scanner that is parked. The first disabled-case run looked like a pass for the wrong reason; the enabled-case control was equally silent, which is what exposed it. docker cp into the tmpfs-backed /tmp writes underneath the mount, so a helper script staged there is absent at runtime. A subscriber that was never started still reported success. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Records two verification pitfalls encountered while testing Device Builder behavior in containers, strengthening the repo's "Verification Discipline" guidance to prevent false-positive test results.

Changes:

Document that Device Builder's filesystem scan for external YAML edits is gated by having an active WebSocket subscriber.
Document that docker cp into a tmpfs-backed path (e.g., /tmp) can write underneath the mount and be invisible at runtime, causing silent no-ops.

ptr727 · 2026-07-19T03:20:04Z

Two traps found while verifying the version history default (#169) against the published develop image. Both are recorded because both produced a passing-looking result from a test that never actually ran.

Scanner is gated on WebSocket subscriber presence. Device Builder's background poll for external YAML edits parks when no client is subscribed. A headless "edit a file, wait, observe no commit" test therefore proves nothing - it watched a scanner that was never running. This was caught only because the enabled-case control was also silent, which is the signal that the harness rather than the feature was off. With a subscriber attached the control commits immediately, unsigned and under the fabricated identity, and the disabled case stays clean.

docker cp into a tmpfs-backed path writes underneath the mount. The compose stack mounts tmpfs at /tmp; a helper script copied there is absent at runtime, and the step depending on it silently no-ops while still reporting success.

Docs only - no behavior change.

🤖 Generated with Claude Code

Both surfaced while verifying the version history default against the develop image, and both produce a passing-looking result from a test that never ran. Device Builder's filesystem scanner is gated on WebSocket subscriber presence, so a headless "edit a YAML and wait" test observes a scanner that is parked. The first disabled-case run looked like a pass for the wrong reason; the enabled-case control was equally silent, which is what exposed it. docker cp into the tmpfs-backed /tmp writes underneath the mount, so a helper script staged there is absent at runtime. A subscriber that was never started still reported success. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Records two verification pitfalls encountered while testing Device Builder behavior in containers, strengthening the repo's "Verification Discipline" guidance to prevent false-positive test results.

Changes:

Document that Device Builder's filesystem scan for external YAML edits is gated by having an active WebSocket subscriber.
Document that docker cp into a tmpfs-backed path (e.g., /tmp) can write underneath the mount and be invisible at runtime, causing silent no-ops.

ptr727 · 2026-07-19T03:20:04Z

Two traps found while verifying the version history default (#169) against the published develop image. Both are recorded because both produced a passing-looking result from a test that never actually ran.

Scanner is gated on WebSocket subscriber presence. Device Builder's background poll for external YAML edits parks when no client is subscribed. A headless "edit a file, wait, observe no commit" test therefore proves nothing - it watched a scanner that was never running. This was caught only because the enabled-case control was also silent, which is the signal that the harness rather than the feature was off. With a subscriber attached the control commits immediately, unsigned and under the fabricated identity, and the disabled case stays clean.

docker cp into a tmpfs-backed path writes underneath the mount. The compose stack mounts tmpfs at /tmp; a helper script copied there is absent at runtime, and the step depending on it silently no-ops while still reporting success.

Docs only - no behavior change.

🤖 Generated with Claude Code

Both surfaced while verifying the version history default against the develop image, and both produce a passing-looking result from a test that never ran. Device Builder's filesystem scanner is gated on WebSocket subscriber presence, so a headless "edit a YAML and wait" test observes a scanner that is parked. The first disabled-case run looked like a pass for the wrong reason; the enabled-case control was equally silent, which is what exposed it. docker cp into the tmpfs-backed /tmp writes underneath the mount, so a helper script staged there is absent at runtime. A subscriber that was never started still reported success. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Records two verification pitfalls encountered while testing Device Builder behavior in containers, strengthening the repo's "Verification Discipline" guidance to prevent false-positive test results.

Changes:

Document that Device Builder's filesystem scan for external YAML edits is gated by having an active WebSocket subscriber.
Document that docker cp into a tmpfs-backed path (e.g., /tmp) can write underneath the mount and be invisible at runtime, causing silent no-ops.

ptr727 · 2026-07-19T03:20:04Z

Two traps found while verifying the version history default (#169) against the published develop image. Both are recorded because both produced a passing-looking result from a test that never actually ran.

Scanner is gated on WebSocket subscriber presence. Device Builder's background poll for external YAML edits parks when no client is subscribed. A headless "edit a file, wait, observe no commit" test therefore proves nothing - it watched a scanner that was never running. This was caught only because the enabled-case control was also silent, which is the signal that the harness rather than the feature was off. With a subscriber attached the control commits immediately, unsigned and under the fabricated identity, and the disabled case stays clean.

docker cp into a tmpfs-backed path writes underneath the mount. The compose stack mounts tmpfs at /tmp; a helper script copied there is absent at runtime, and the step depending on it silently no-ops while still reporting success.

Docs only - no behavior change.

🤖 Generated with Claude Code

Both surfaced while verifying the version history default against the develop image, and both produce a passing-looking result from a test that never ran. Device Builder's filesystem scanner is gated on WebSocket subscriber presence, so a headless "edit a YAML and wait" test observes a scanner that is parked. The first disabled-case run looked like a pass for the wrong reason; the enabled-case control was equally silent, which is what exposed it. docker cp into the tmpfs-backed /tmp writes underneath the mount, so a helper script staged there is absent at runtime. A subscriber that was never started still reported success. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Records two verification pitfalls encountered while testing Device Builder behavior in containers, strengthening the repo's "Verification Discipline" guidance to prevent false-positive test results.

Changes:

Document that Device Builder's filesystem scan for external YAML edits is gated by having an active WebSocket subscriber.
Document that docker cp into a tmpfs-backed path (e.g., /tmp) can write underneath the mount and be invisible at runtime, causing silent no-ops.

ptr727 · 2026-07-19T03:20:04Z

Two traps found while verifying the version history default (#169) against the published develop image. Both are recorded because both produced a passing-looking result from a test that never actually ran.

Scanner is gated on WebSocket subscriber presence. Device Builder's background poll for external YAML edits parks when no client is subscribed. A headless "edit a file, wait, observe no commit" test therefore proves nothing - it watched a scanner that was never running. This was caught only because the enabled-case control was also silent, which is the signal that the harness rather than the feature was off. With a subscriber attached the control commits immediately, unsigned and under the fabricated identity, and the disabled case stays clean.

docker cp into a tmpfs-backed path writes underneath the mount. The compose stack mounts tmpfs at /tmp; a helper script copied there is absent at runtime, and the step depending on it silently no-ops while still reporting success.

Docs only - no behavior change.

🤖 Generated with Claude Code

Both surfaced while verifying the version history default against the develop image, and both produce a passing-looking result from a test that never ran. Device Builder's filesystem scanner is gated on WebSocket subscriber presence, so a headless "edit a YAML and wait" test observes a scanner that is parked. The first disabled-case run looked like a pass for the wrong reason; the enabled-case control was equally silent, which is what exposed it. docker cp into the tmpfs-backed /tmp writes underneath the mount, so a helper script staged there is absent at runtime. A subscriber that was never started still reported success. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Records two verification pitfalls encountered while testing Device Builder behavior in containers, strengthening the repo's "Verification Discipline" guidance to prevent false-positive test results.

Changes:

Document that Device Builder's filesystem scan for external YAML edits is gated by having an active WebSocket subscriber.
Document that docker cp into a tmpfs-backed path (e.g., /tmp) can write underneath the mount and be invisible at runtime, causing silent no-ops.

ptr727 · 2026-07-19T03:20:04Z

Two traps found while verifying the version history default (#169) against the published develop image. Both are recorded because both produced a passing-looking result from a test that never actually ran.

Scanner is gated on WebSocket subscriber presence. Device Builder's background poll for external YAML edits parks when no client is subscribed. A headless "edit a file, wait, observe no commit" test therefore proves nothing - it watched a scanner that was never running. This was caught only because the enabled-case control was also silent, which is the signal that the harness rather than the feature was off. With a subscriber attached the control commits immediately, unsigned and under the fabricated identity, and the disabled case stays clean.

docker cp into a tmpfs-backed path writes underneath the mount. The compose stack mounts tmpfs at /tmp; a helper script copied there is absent at runtime, and the step depending on it silently no-ops while still reporting success.

Docs only - no behavior change.

🤖 Generated with Claude Code

Both surfaced while verifying the version history default against the develop image, and both produce a passing-looking result from a test that never ran. Device Builder's filesystem scanner is gated on WebSocket subscriber presence, so a headless "edit a YAML and wait" test observes a scanner that is parked. The first disabled-case run looked like a pass for the wrong reason; the enabled-case control was equally silent, which is what exposed it. docker cp into the tmpfs-backed /tmp writes underneath the mount, so a helper script staged there is absent at runtime. A subscriber that was never started still reported success. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Records two verification pitfalls encountered while testing Device Builder behavior in containers, strengthening the repo's "Verification Discipline" guidance to prevent false-positive test results.

Changes:

Document that Device Builder's filesystem scan for external YAML edits is gated by having an active WebSocket subscriber.
Document that docker cp into a tmpfs-backed path (e.g., /tmp) can write underneath the mount and be invisible at runtime, causing silent no-ops.

ptr727 · 2026-07-19T03:20:04Z

Two traps found while verifying the version history default (#169) against the published develop image. Both are recorded because both produced a passing-looking result from a test that never actually ran.

Scanner is gated on WebSocket subscriber presence. Device Builder's background poll for external YAML edits parks when no client is subscribed. A headless "edit a file, wait, observe no commit" test therefore proves nothing - it watched a scanner that was never running. This was caught only because the enabled-case control was also silent, which is the signal that the harness rather than the feature was off. With a subscriber attached the control commits immediately, unsigned and under the fabricated identity, and the disabled case stays clean.

docker cp into a tmpfs-backed path writes underneath the mount. The compose stack mounts tmpfs at /tmp; a helper script copied there is absent at runtime, and the step depending on it silently no-ops while still reporting success.

Docs only - no behavior change.

🤖 Generated with Claude Code

Both surfaced while verifying the version history default against the develop image, and both produce a passing-looking result from a test that never ran. Device Builder's filesystem scanner is gated on WebSocket subscriber presence, so a headless "edit a YAML and wait" test observes a scanner that is parked. The first disabled-case run looked like a pass for the wrong reason; the enabled-case control was equally silent, which is what exposed it. docker cp into the tmpfs-backed /tmp writes underneath the mount, so a helper script staged there is absent at runtime. A subscriber that was never started still reported success. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

Copilot

Pull request overview

Records two verification pitfalls encountered while testing Device Builder behavior in containers, strengthening the repo's "Verification Discipline" guidance to prevent false-positive test results.

Changes:

Document that Device Builder's filesystem scan for external YAML edits is gated by having an active WebSocket subscriber.
Document that docker cp into a tmpfs-backed path (e.g., /tmp) can write underneath the mount and be invisible at runtime, causing silent no-ops.