[Defect][Device] Browser reload/tab close still results in LOCKED Device

[miso-develop]

Parent / governing decisions

• [Spec] Post-v0.1.0 usability and automatic-lock improvements #137 Requirement 51
• [Decision][Web/Time] Preserve unlock across browser disconnect and gate automatic PC-time sync #195 — RESOLVED lifecycle Decision
• [Task][Web] Preserve unlock across page lifecycle and auto-sync PC time when needed #196 — completed Web implementation of the non-locking lifecycle contract
• [Decision] Define trusted-time mutation boundary while Device is locked #49 trusted-time / Device lifecycle boundary

Owner

• ACTIVE_ROLE: implementation
• DOMAIN: device

State

READY_FOR_IMPLEMENTATION

Defect report

Physical use after #196 still observes the undesired behavior:

1. Connect the Web app to the Device.
2. Complete Trusted Browser Unlock and confirm the Device is UNLOCKED.
3. Close the browser tab or reload the page.
4. The Device is subsequently observed as LOCKED.

This contradicts the approved contract:

• browser/page/Web Serial lifecycle teardown must not implicitly Lock a still-running Device;
• same physical runtime may remain UNLOCKED;
• only explicit Lock, configured automatic-lock expiry, reboot/actual power loss, or another approved Device security boundary destroys the active VMK.

A USB cable removal that leaves the StickS3 running on battery has been observed by the human owner to preserve UNLOCKED, reinforcing the desired behavior.

Current static evidence

Specification re-checked current main = b3aa8fc0cc06143990dcf32a971853264f73eba8.

Web

web/src/browser-lifecycle.ts:

• page lifecycle cleanup calls management.disconnectTransport() when management exists;
• otherwise closes only the raw serial session;
• no device.lock request is present.

CanonicalDeviceManagement:

• close() sends device.lock and is the explicit Lock path;
• disconnectTransport() clears browser-side management state and calls transport close() only.

SerialSession.close():

• cancels/releases stream locks and closes the Web Serial port;
• it does not send a Protocol-v2 device.lock.

Device

Production USB disconnect handling in firmware/main/app_main.cpp calls:

• protocol.disconnect();
• transport PRE_HANDSHAKE reset.

CanonicalProtocolV2Handler::disconnect():

• disconnects protocol/session state;
• cancels pending VMK delivery/reset presence;
• does not call runtime_.lock().

The normal runtime_.lock() path is reached through approved security boundaries such as explicit device.lock or automatic-lock expiry.

Therefore the source-level intended contract appears correct. The observed physical outcome requires runtime diagnosis rather than another speculative Web-only change.

Objective

Determine why tab close/reload results in a physically/reconnect-observed LOCKED Device despite the non-locking source contract, then fix the actual causal path while preserving #195.

The diagnosis must distinguish at least:

1. an unexpected device.lock request;
2. a Device reboot/reset caused or correlated with Web Serial/page teardown;
3. an unintended Device security-boundary call;
4. automatic-lock expiry;
5. stale/incorrect UI interpretation where the Device did not actually Lock;
6. old/stale Web or firmware build behavior not matching current main;
7. another transport/browser lifecycle interaction.

Reproduction / evidence requirements

A. Establish exact versions

Before changing code, record non-secret identities:

• exact Web build/commit served by the tested page;
• exact Device firmware/build commit from normal hello;
• configured automatic-lock setting/state;
• browser version used for the physical reproduction.

Do not record Device ID, account metadata, OTPs, TOTP secrets, Vault identifiers, Recovery data, keys, or credential-bearing logs.

If the physical Device firmware is not a build containing the current lifecycle contract, reproduce again with the intended current candidate before claiming a current-main regression.

B. Separate the lifecycle cases

Using the same unlocked Device/runtime where practical, characterize independently:

• page reload;
• tab close;
• navigation away;
• browser process close, if safely reproducible;
• explicit Lock & Disconnect as positive control;
• direct transport-only disconnect through the application's non-locking path, if a diagnostic harness can invoke it safely;
• USB cable removal while battery keeps Device running as physical control.

For each case record only:

• Device state before action;
• whether display/runtime remains alive continuously;
• Device state immediately after;
• reconnect hello.state;
• whether a fresh Unlock physical-confirmation request is required.

C. Distinguish Lock from reboot/reset

A tab/reload observation must not be classified merely from the reloaded Web UI.

Use the least-invasive non-secret evidence available to determine whether the Device:

• remained in the same boot/runtime and changed to LOCKED; or
• rebooted/reset, thereby correctly losing RAM-only VMK.

Prefer existing/sanitized diagnostics. If additional diagnostic instrumentation is necessary, it may expose only non-secret lifecycle evidence such as:

• boot/reset counter/reason;
• monotonic boot continuity marker;
• whether an explicit Device Lock operation was accepted;
• transport connect/disconnect transitions;
• security-boundary reason enum/counter.

It must not expose VMK/key material, Vault contents/IDs, account metadata, credentials, Passphrases, OTPs, session private data, or raw protocol secret payloads.

Production diagnostic expansion requires normal security review if it becomes user-accessible; isolated diagnostic builds are preferred during root-cause work.

D. Check Web request boundary

Prove whether a device.lock Protocol request is emitted in each lifecycle case.

The existing mock regression from #196 is necessary but no longer sufficient because the physical behavior disagrees.

If browser teardown itself cannot reliably complete asynchronous logging, use a bounded local test harness/transport spy that records only operation names, never parameters or secret-bearing payloads.

E. Check Device boundary

Instrument/test the Device boundary sufficiently to prove which event, if any, changes runtime from UNLOCKED to LOCKED.

At minimum distinguish:

• explicit device.lock;
• automatic-lock expiry;
• reboot/reset;
• other lock_security_boundary() caller.

Do not weaken automatic-lock or other legitimate fail-closed boundaries to make the test pass.

Fix policy

If Web sends an unexpected explicit Lock

Remove that implicit path while preserving:

• explicit Lock & Disconnect;
• browser transient-secret cleanup;
• best-effort transport/resource release.

If Web Serial close/reload causes Device reboot/reset

Do not disguise the reset as a Web-state issue.

Determine the causal browser/USB/Device path and apply the narrowest fix. If avoiding an explicit port.close() during page teardown is necessary, prove:

• browser reload/tab-close still releases ownership sufficiently for reconnect;
• no serial resource/permission deadlock is introduced;
• explicit user disconnect remains deterministic;
• no security boundary is weakened.

If the reset is unavoidable platform behavior, return to Specification with physical evidence before changing the product lifecycle expectation.

If Device incorrectly locks on transport/session disconnect

Separate session teardown from VMK runtime lifetime per #195. Keep:

• pending session/authorization cancellation;
• framing/session fail-closed behavior;
• explicit Lock;
• automatic Lock;
• reboot/power-loss lock semantics.

If stale build is the cause

Do not create unnecessary production changes. Record exact stale/current identities, confirm the current intended build physically satisfies #195, and close this Defect with evidence.

Tests

Add/extend regression coverage for the causal fix.

Required end-state tests include:

• lifecycle page teardown does not issue device.lock;
• transport disconnect does not call Device runtime lock;
• explicit Lock & Disconnect still locks;
• automatic-lock expiry still locks;
• reboot/power-loss model still starts LOCKED;
• reconnect to same still-running runtime after non-locking teardown reports UNLOCKED;
• any fixed browser/serial teardown path can reconnect without stale port ownership;
• transient browser secrets are still cleared.

Where feasible add a Chrome/browser integration test covering actual reload/port teardown behavior in addition to mocks.

Acceptance

• Exact physical reproduction has been characterized with Web + firmware build identities.
• Root cause distinguishes explicit Lock vs reboot/reset vs other security boundary vs stale UI/build.
• Tab close and reload do not cause Device Lock when the same physical Device runtime continues.
• Reconnect after such teardown reports UNLOCKED without a new Unlock confirmation.
• USB data disconnect while battery keeps the same runtime alive remains non-locking.
• Explicit Lock & Disconnect still destroys the unlocked session.
• Automatic-lock expiry remains unchanged.
• Actual reboot/power loss still destroys RAM-only VMK and starts LOCKED.
• Browser transient-secret cleanup remains.
• No Protocol/Vault/credential/eFuse relaxation is introduced.
• Foundation/Security/relevant Web+firmware tests are green.
• Physical Human Gate verifies reload and tab-close behavior on the exact fix head.

Collision / coordination

At Specification time there are no open PRs, but #203 is a newly-open Web Task without a PR yet and is expected to touch shared Web layout rather than lifecycle/serial code.

Device Implementation owns this Defect initially because current static Web and Device contracts both appear non-locking and the unresolved question is the physical Device state transition/runtime continuity.

If evidence proves the causal fix is exclusively Web-side, persist the finding here and hand off to Web Implementation rather than silently crossing domains.

Re-check current Issues/PRs/branches before claim.

References

• [Decision][Web/Time] Preserve unlock across browser disconnect and gate automatic PC-time sync #195
• [Task][Web] Preserve unlock across page lifecycle and auto-sync PC time when needed #196
• [Spec] Post-v0.1.0 usability and automatic-lock improvements #137 Requirement 51
• [Decision] Define trusted-time mutation boundary while Device is locked #49
• web/src/browser-lifecycle.ts
• web/src/canonical-management.ts
• web/src/serial.ts
• firmware/main/app_main.cpp
• firmware/components/m5auth_provisioning/canonical_protocol_v2.cpp

[miso-develop]

HANDOFF
FROM: specification
TO: implementation
DOMAIN: device
ISSUE: #204
STATE: READY_FOR_IMPLEMENTATION

[miso-develop]

CLAIM
ROLE: implementation
DOMAIN: device
ISSUE: #204
BASE: b3aa8fc
BRANCH: task/204-device-browser-teardown-lock-diagnosis

Scope: diagnose the physical LOCKED observation after browser reload/tab close, distinguish explicit lock vs reboot/reset vs other security boundary, and implement only the causal Device-side fix if evidence supports one. If root cause is Web-only, persist evidence and hand off rather than crossing domains.

[miso-develop]

IMPLEMENTATION_DIAGNOSIS
ROLE: implementation
DOMAIN: device
ISSUE: #204
CLAIM_BASE: b3aa8fc
BRANCH: task/204-device-browser-teardown-lock-diagnosis

Static boundary findings

Current claimed source was traced before any behavior-changing commit:

• firmware/main/app_main.cpp USB-disconnect branch calls only protocol.disconnect() and reset_pre_handshake(); it does not call runtime.lock().
• CanonicalProtocolV2Handler::disconnect() tears down session/pending authorization/reset state only; it does not invoke lock_security_boundary() or runtime_.lock().
• runtime_.lock() is reached through lock_security_boundary() for approved boundaries such as explicit device.lock and automatic-lock expiry.
• CanonicalVmkSink::cancel_pending() wipes only pending VMK delivery state, not the active Runtime VMK.
• Web pagehide calls cleanupBrowserLifecycle() -> management.disconnectTransport() -> SerialSession.close(); this path does not request device.lock.
• Explicit CanonicalDeviceManagement.close() remains the path that sends device.lock before transport close.

Therefore there is still no source-level Device transport-disconnect -> active-VMK lock path to fix. The physical observation must first be distinguished as stale build/UI, automatic-lock expiry, actual reset/reboot, unexpected explicit lock request, or another runtime event.

Required pre-change physical evidence

Issue #204 explicitly requires exact identities before behavior changes. The defect report does not yet contain these values. Record only the following non-secret values from one reproduction session:

1. Web Build information: full Web commit.
2. Firmware Build information / hello.build_commit: full/advertised firmware commit.
3. Chrome version.
4. Automatic LOCK setting: disabled or configured day count.
5. For page reload and tab close separately:
   • Device state before action;
   • whether the LCD/runtime stays continuously alive or visibly restarts;
   • Device state immediately after action;
   • reconnect hello.state;
   • whether fresh physical Unlock confirmation is required.
6. Positive control: explicit Lock & Disconnect must end LOCKED.
7. Physical control: USB cable removal while battery keeps the same runtime alive should remain UNLOCKED.

Do not record Device ID, Vault ID, account labels, OTPs, secrets, passphrases, keys, registration IDs, or raw protocol payloads.

Next diagnostic step after identity baseline

If exact current builds reproduce LOCKED and continuous-runtime observation cannot distinguish reset from lock, add an isolated compile-time Device diagnostic exposing only boot/reset continuity and lock-boundary reason/counters. Do not expand production user-accessible diagnostics unless required and Security-reviewed.

External platform note

ESP32-S3 USB Serial/JTAG is a fixed-function native USB controller. Generic USB-UART DTR/RTS auto-reset behavior must not be assumed to explain Web port.close() without physical/reset evidence.

STATE: BLOCKED_PHYSICAL_EVIDENCE

No production/source behavior change has been made on the #204 branch.

[miso-develop]

HANDOFF
FROM: implementation
TO: human
DOMAIN: device
ISSUE: #204
STATE: HUMAN_GATE_REQUIRED

[miso-develop]

HUMAN_GATE_EVIDENCE — physical reproduction baseline

Exact tested identities:

• Web commit: b3aa8fc0cc06143990dcf32a971853264f73eba8
• Firmware commit: b3aa8fc0cc06143990dcf32a971853264f73eba8
• Chrome: 153.0.8010.48 Stable, 64-bit
• Automatic LOCK: disabled

Physical results:

Reload

• before: UNLOCKED
• Device restart indication: yes
• reconnect state: LOCKED
• fresh physical Unlock required: yes

Tab close

• before: UNLOCKED
• Device restart indication: yes
• reconnect state: LOCKED
• fresh physical Unlock required: yes

Positive control — Lock & Disconnect

• result: LOCKED

Physical control — USB cable removal while battery keeps Device running

• result: UNLOCKED

Interpretation for #204:

• stale Web/Firmware build is ruled out for this reproduction;
• automatic-lock expiry is ruled out;
• plain USB data/power removal while the same Device runtime survives is non-locking as intended;
• reload/tab-close correlate with an actual visible Device restart, after which RAM-only VMK loss and LOCKED are expected;
• therefore the observed defect is now classified as a browser/page-teardown-correlated Device reboot/reset path, not merely a stale Web UI interpretation or ordinary transport disconnect.

The next implementation step is to identify the causal browser/Web Serial/USB path for that reset and apply the narrowest fix without weakening explicit Lock, automatic Lock, reboot/power-loss semantics, or browser transient-secret cleanup.

[miso-develop]

HANDOFF
FROM: human
TO: implementation
DOMAIN: device
ISSUE: #204
STATE: READY_FOR_IMPLEMENTATION

[miso-develop]

IMPLEMENTATION_ROOT_CAUSE_NARROWING
ROLE: implementation
DOMAIN: device
ISSUE: #204
CLAIM_BASE: b3aa8fc
BRANCH: task/204-device-browser-teardown-lock-diagnosis

Human evidence consumed

• Web commit: b3aa8fc0cc06143990dcf32a971853264f73eba8
• Firmware commit: b3aa8fc0cc06143990dcf32a971853264f73eba8
• Chrome: 153.0.8010.48 Stable 64-bit
• Automatic LOCK: disabled
• Reload: UNLOCKED -> visible Device restart -> reconnect LOCKED -> fresh physical Unlock required
• Tab close: same result
• Explicit Lock & Disconnect: LOCKED
• USB cable removal while battery keeps runtime alive: remains UNLOCKED

Stale build, automatic-lock expiry, stale Web UI interpretation, and normal Device transport-disconnect locking are therefore ruled out for this reproduction.

Device boundary result

Static Device tracing remains unchanged:

• app_main.cpp transport disconnect -> protocol.disconnect() + PRE_HANDSHAKE reset only.
• CanonicalProtocolV2Handler::disconnect() cancels protocol/session/pending authorization state only.
• active Runtime VMK is not destroyed by transport disconnect.
• runtime_.lock() remains behind explicit/approved security boundaries.

No Device application-level disconnect-to-lock defect exists to patch.

Causal boundary: ESP32-S3 USB Serial/JTAG CDC control lines

Espressif ESP32-S3 Technical Reference Manual, USB Serial/JTAG chapter, documents that the fixed-function CDC-ACM interface accepts SET_CONTROL_LINE_STATE and uses RTS/DTR for chip reset/download control. Table 29-2 defines:

• RTS=0, DTR=0: clear download-mode flag
• RTS=0, DTR=1: set download-mode flag
• RTS=1, DTR=0: reset ESP32-S3
• RTS=1, DTR=1: no action

The same TRM notes that host OSes generally change DTR/RTS separately and specifically calls out Windows CDC-ACM propagation behavior. This is consistent with the Human observation that browser serial teardown restarts the Device while plain USB removal does not.

Public references:

• ESP32-S3 TRM USB Serial/JTAG chapter: https://www.espressif.com/sites/default/files/documentation/esp32-s3_technical_reference_manual_en.pdf
• Web Serial setSignals() semantics: https://wicg.github.io/serial/

Web Serial specifies DTR before RTS when both are supplied in one setSignals() call. Therefore a mitigation that clears both in one call can itself transiently traverse RTS=1/DTR=0 and must not be assumed safe.

Current Web causal surface

web/src/browser-lifecycle.ts pagehide cleanup reaches:
management.disconnectTransport() -> SerialSession.close() -> port.close().

SerialPortLike currently exposes open() / close() but not setSignals().

Given the physical restart and the ESP32-S3 hardware CDC reset contract, the narrow causal fix belongs to the Web Serial control-line lifecycle, not Device Runtime/Protocol code.

Recommended Web-domain implementation experiment

Before changing Device security behavior, Web Implementation should test a safe USB-Serial/JTAG signal-normalization path:

1. expose Web Serial setSignals() in the local port abstraction;
2. normalize in ordered separate operations so RTS is deasserted before DTR:
   • await port.setSignals({ requestToSend: false })
   • then await port.setSignals({ dataTerminalReady: false })
3. establish/retain this safe state before teardown; do not use one combined call whose specified ordering is DTR then RTS;
4. retain explicit device.lock semantics for Lock & Disconnect;
5. retain browser transient-secret clearing;
6. physically verify reload/tab close on exact head, reconnect ownership, and absence of restart;
7. if explicit port.close() still causes reset after safe signal normalization, test the existing [Defect][Device] Browser reload/tab close still results in LOCKED Device #204-approved alternative of omitting explicit close only during page teardown while preserving deterministic explicit user disconnect, then verify no stale Web Serial ownership.

Do not disable USB Serial/JTAG reset/download capability through eFuse or speculative Device register writes. That would cross the accepted security/flashability boundary and is not required by the evidence.

Device-domain disposition

No Device production source change is justified. The #204 Device diagnosis branch remains behavior-identical to main.
Cross-domain Web implementation is required for the causal fix.

STATE: HANDOFF_REQUIRED

[miso-develop]

HANDOFF
FROM: implementation
TO: implementation
DOMAIN: web
ISSUE: #204
STATE: READY_FOR_IMPLEMENTATION

[miso-develop]

CLAIM
ROLE: implementation
DOMAIN: web
ISSUE: #204
BASE: 40f7061
BRANCH: task/204-web-serial-control-lines
STATE: IN_PROGRESS

Taking over from the durable Device->Web handoff after physical evidence narrowed the defect to Web Serial / ESP32-S3 USB Serial/JTAG CDC control-line teardown. The existing Device diagnosis branch remains untouched and behavior-identical to its diagnostic baseline.

Initial fix experiment is intentionally narrow: expose Web Serial setSignals() and normalize RTS=false before DTR=false using separate ordered operations before port.close(). Explicit device.lock, automatic Lock, reboot/power-loss semantics, protocol/Vault behavior, and transient browser-secret cleanup remain unchanged. Physical Human Gate on the exact candidate head remains required before READY_FOR_REVIEW.

[miso-develop]

HUMAN_GATE_REQUEST
ROLE: implementation
DOMAIN: web
ISSUE: #204
PR: #206
HEAD: 0c0f476
STATE: BLOCKED_HUMAN_GATE

CI is green on the exact candidate. Physical verification is now required before Review handoff.

Exact Web candidate setup on Windows

From an existing local clone, use a separate worktree so current work is not disturbed:

git fetch origin refs/pull/206/head
git worktree add ..\m5authenticator-pr206 FETCH_HEAD
cd ..\m5authenticator-pr206
git rev-parse HEAD
cd web

$env:VITE_M5AUTH_WEB_VERSION="0.1.0"
$env:VITE_M5AUTH_WEB_BUILD_COMMIT="0c0f476fd40cee0e537e36636775d3680cf4eedd"
$env:VITE_M5AUTH_WEB_EXACT_RELEASE="false"

npm ci
npm run dev

Confirm git rev-parse HEAD is exactly:
0c0f476fd40cee0e537e36636775d3680cf4eedd

Open:
http://127.0.0.1:5173/m5authenticator/

The Web Build information should show the candidate commit above. Record the currently flashed Firmware build commit shown by the application as well; no firmware reflash is required for this Web-only experiment if the existing firmware already contains the #195 lifecycle contract.

Physical checks

With Automatic LOCK disabled, test each case from an UNLOCKED Device:

1. Reload

   • reload the page;
   • Device must not visibly restart;
   • reconnect must succeed without stale serial ownership;
   • reconnect state must be UNLOCKED;
   • no fresh physical Unlock confirmation.

2. Tab close

   • close the tab, reopen the same local URL;
   • same expected results as reload.

3. Navigation away

   • navigate to another M5Authenticator page (for example Help), then return and reconnect;
   • no restart; reconnect UNLOCKED; no stale port ownership.

4. Positive control — Lock & Disconnect

   • must still end LOCKED.

5. Physical control — USB cable removal while battery keeps Device running

   • must remain UNLOCKED.

Please report only these non-secret results plus the Web/Firmware commit identities and Chrome version. Do not include Device ID, Vault ID, account metadata, OTPs, secrets, Passphrases, keys, or raw protocol payloads.

If reload/tab close still visibly restarts the Device on this exact head, report that result directly; the next approved experiment is page-lifecycle-specific omission of explicit port.close(), not any Device security relaxation.

[miso-develop]

HANDOFF
FROM: implementation
TO: integration
ISSUE: #204
PR: #206
HEAD: 0c0f476
STATE: HUMAN_GATE_REQUIRED

[miso-develop]

Human Gate test-origin clarification

The local candidate at http://127.0.0.1:5173/m5authenticator/ is a different browser origin from the production GitHub Pages origin. Its IndexedDB/Trusted Browser key material therefore does not make it the active Device writer, and the UI may correctly report:
This browser is not the active Device writer. Use the explicit recovery/reconciliation path.

For #204 physical validation, do not perform Recovery Package replacement/reconciliation merely to make localhost an active writer.

Safe test setup:

1. Use the existing production Trusted Browser origin to unlock the Device.
2. While the Device is UNLOCKED, physically remove USB while battery keeps the same Device runtime alive; prior control evidence shows this preserves UNLOCKED and releases Web Serial ownership.
3. Reconnect USB.
4. Connect the exact localhost PR fix(web): prevent USB Serial teardown reset (#204) #206 candidate. Browser ownership may show conflict; that is acceptable for this gate. The important baseline is Device Runtime: unlocked before lifecycle teardown.
5. Exercise reload/tab-close/navigation-away on the localhost candidate and verify the Device does not restart and reconnect Runtime remains unlocked.
6. Do not import/replace Recovery state or mutate Trusted Browser registration.

The explicit Lock & Disconnect positive control should be tested separately from the production active Trusted Browser origin, because localhost conflict state is not authorized to act as the active writer.

[miso-develop]

HUMAN_GATE_PASS — exact Web candidate

Exact candidate HEAD: 0c0f476fd40cee0e537e36636775d3680cf4eedd

Test identities:

• Web commit: 0c0f476fd40cee0e537e36636775d3680cf4eedd
• Firmware commit: 46802e2baa9e
• Chrome: 153.0.8010.48 Stable 64-bit (same browser baseline as prior reproduction)

Physical results:

Reload

• Device restart: not observed
• reconnect: succeeds
• reconnect state: UNLOCKED
• fresh physical Unlock: not required

Tab close

• Device restart: not observed
• reconnect: succeeds
• reconnect state: UNLOCKED
• fresh physical Unlock: not required

Navigation away

• Device restart: not observed
• reconnect: succeeds
• reconnect state: UNLOCKED

Positive / physical controls

• explicit Lock & Disconnect: PASS
• USB removal while battery keeps Device runtime alive: PASS

Additional observation:

• On the localhost dev candidate, the Unlock button is disabled after Connect because localhost is not the active Device writer. This is consistent with the separately recorded test-origin clarification and is not treated as a [Defect][Device] Browser reload/tab close still results in LOCKED Device #204 defect. No recovery/reconciliation or Trusted Browser replacement was performed for this gate.

Gate conclusion:

• the prior reload/tab-close-correlated Device restart is no longer observed on the exact candidate;
• reconnect remains possible without stale serial ownership;
• same-runtime UNLOCKED state is preserved across lifecycle teardown;
• explicit Lock and USB-removal controls remain consistent with the governing lifecycle contract.

STATE: HUMAN_GATE_PASS

[miso-develop]

HANDOFF
FROM: integration
TO: review
DOMAIN: web
ISSUE: #204
PR: #206
HEAD: 0c0f476
STATE: READY_FOR_REVIEW