# Bone Flow #045 ToggleButton — Full Re-Audit v1.0.11

Date: 2026-08-18  
Status: Development / Candidate

## Baselines
- #042 Button v1.0.12
- #035 Switch v1.0.6
- #040 ColorPicker v1.0.15
- #043 Link v1.0.1 — Action UI / Class Guide comparison only
- #002 Joint v1.1.36 — formal Delivery contract

## Rejected versions
v1.0.0 through v1.0.8 are not canonical and must not be treated as Completed/Frozen.

### v1.0.8 blocking defect
User localhost showed that the **BLOCKED** operation did not work while Smoke Test / Validation Report could still display **ALL PASS**.
That means the test oracle did not cover the actual required BLOCK behavior.

Root causes found:
1. #045 live demo guard returned a #045-only rejection object `{accepted:false, blocked:true, ...}` instead of the completed-component formal convention `{allowed:false, reason, code}` used by #035 and other completed consumers of #002.
2. Smoke did not execute the actual live BLOCK button route.
3. Validation did not require the actual live BLOCK UI route.
4. Overall ALL PASS was based only on suite presence + zero FAIL and therefore could be true without proving BLOCKED.

## v1.0.10 BLOCKED correction

### Actual Delivery route
- `connectOutput()` still delegates to #002 `createDeliveryChannel()`.
- Runtime delivery still calls channel `.deliver(output)`; `.send()` is absent.
- Live demo guard rejection now uses:
  - `allowed:false`
  - `reason:'security-test'`
  - `code:'TOGGLEBUTTON_TEST_BLOCK'`
- Manual BLOCK is synchronous:
  1. clear prior block
  2. Target READY
  3. set ToggleButton false without emit
  4. record Target receive count
  5. toggle false → true with emit
  6. read actual `getOutputState()`
  7. PASS only when `state === 'blocked'` and Target count is unchanged

### BLOCKED visual
- Connection remains drawn through #002 Joint rendering.
- BLOCK state uses blocked line/marker options.
- Target label becomes `CONNECTED / BLOCKED`.
- Target receive log must not gain the rejected value.

### Smoke / Validation oracle correction
Smoke now includes **S23 `#002 BLOCKED実動作 / Target未配送`** and calls the same `runBlock()` route used by the manual BLOCK button.

Validation now includes:
- **V44 `#002 guard正式BLOCK契約`** — isolated formal guard rejection + no Target delivery
- **V45 `BLOCK UI route実動作`** — same live UI route, BLOCKED pill, `CONNECTED / BLOCKED`, no Target delivery

Overall ALL PASS now requires all of the following:
- Smoke executed
- Validation executed
- zero FAIL
- explicit BLOCK Smoke PASS
- explicit BLOCK Validation PASS

Therefore a suite that does not prove BLOCK can no longer become ALL PASS.
Completion still separately requires the user WAIT and BLOCK visual-confirmation checkboxes.

## Other preserved #045 responsibilities
- ToggleButton boolean OFF / ON state and action toggle
- 5 display patterns: standard / soft-rounded / text / icon / button
- ON表示文字 / OFF表示文字
- #040 click-open ColorPicker
- ON/OFF/Thumb solid + gradient
- Active Effect and Mouse Over Effect independent
- normal / neon / spin / cross / blink + direction + speed
- Active is focus/active only; ON=true does not activate Active Effect
- Parent dependency / FIT / 9-way placement
- Security sandbox independent from normal Preview
- connection image
- WAIT / FIFO / BLOCKED
- Smoke Test / Validation Report / Runtime Console / report save
- Completion user operation
- HTML Functional Class / Guide 29 Public API entries
- no direct #019 Image / #039 FilePicker / #042 Button runtime dependency

## Checks actually executed after this BLOCKED correction

### Syntax / Static
- runtime JS syntax: PASS
- HTML Functional Class JS syntax: PASS
- Runtime Node test JS syntax: PASS
- Class Node test JS syntax: PASS
- BLOCK regression Node test JS syntax: PASS
- extracted inline HTML JS syntax: PASS
- actual HTML duplicate ids: 0
- literal `q('id')` references: 114 / unresolved 0
- ASCII control characters: 0
- runtime `.send(` usage: 0
- direct BoneButton / BoneImage / BoneFilePicker runtime refs: 0

### Node
- ToggleButton runtime contract: 43/43 PASS
- HTML Functional Class contract: 17/17 PASS
- BLOCKED regression contract: 9/9 PASS

### Browser
The v1.0.10 test page defines:
- Smoke 24 checks
- Validation 45 checks
- total 69 checks

**Full v1.0.10 browser execution after the BLOCKED correction: NOT RUN in the build environment.**
The build environment does not have the user's installed formal #001/#002 runtime tree, so no controlled stub execution is promoted to Browser ALL PASS.

User localhost Browser Runtime: NOT RUN / awaiting user execution.  
Completion: NOT RUN.  
Completed / Specification Frozen: NO.

## Installer
Installer structure is retained from the canonical reference pattern, including batch wrapper, target detection, dependency checks, backup/log, MANIFEST verification, copy/hash verification, and installed-version verification.

Windows `install.bat` / `install.ps1` actual execution: **NOT RUN** because Windows cmd/PowerShell is unavailable in the build environment.
This limitation must not be converted into PASS.


## v1.0.10 WAIT correction
- v1.0.9 manual WAIT confirmation could remain disabled because the UI gate inspected `getOutputQueue()` item shape directly.
- v1.0.10 uses the formal #002 state contract (`state === waiting`, `queueLength`) and validates delivered FIFO values after READY.
- Smoke/Validation now contain explicit WAIT/FIFO regressions, and Overall ALL PASS requires both WAIT and BLOCK delivery checks.


## v1.0.11 Completion correction

Confirmed v1.0.10 defect: Smoke / Validation called the manual `runBlock()` route. That route intentionally resets `blockConfirmed` and unchecks the visual-confirmation checkbox, so running QA could invalidate a user confirmation and keep Completion disabled.

Correction:
- S23 / V45 use isolated QA ToggleButton instances via `exerciseQaBlockDelivery()`.
- Smoke / Validation no longer call manual `runWait()` / `runBlock()`.
- WAIT/BLOCK user confirmations survive QA execution order.
- Completion summary visibly exposes Runtime QA, WAIT visual, BLOCK visual, Completion Flag and Completed timestamp.
- Completion enable/click logic shares the pure `isCompletionReady()` gate.
- Browser checks V48/V49 protect QA isolation and Completion gate semantics.