CADR-WEB-303 C-M8 keyboard input reimplementation specification

Status and reconstruction claim

CADR-WEB-303/controller-C-M8.1/core-ABI1.8/protocol-v6/KBD-X11-INFO16-v1 is a dedicated-worker and browser-to-core input contract. It recreates a selected 16-bit Cadet event stream: an explicit 100-physical-key KeyboardEvent.code map, an 18-key physical held modifier model collapsed to the 11-bit Cadet all-up mask, bounded queueing, canonical state bytes, and dedicated v6 operations executed by the browser worker. The browser transport shares the worker's monotonic request-ID space with M9, so interleaved DOM keyboard and pointer edges cannot reuse an ID.

It claims semantic compatibility for the selected host-controller rules and a separate, tested core ingress boundary. The table preserves the System 46 Cadet values for Macro (0100), Call (0107), and Repeat (0115) and the source-visible all-up bit assignments. It does not claim that a browser, a physical USB keyboard, a preserved System 303 band, or an original keyboard controller has run this exact DOM map. It does not send generic scheduler keyboard events under protocol v6, claim that CDRINP1 is historical, close C-M8, or confirm any guest-visible runtime behavior. Its selected ABI 1.8 core delivery is a reconstruction implementation, not a native-runtime equivalence result.

The M8 onscreen view is a host accessibility representation of the same 100 descriptors, not a screenshot or a claim about a CADR screen. It consequently has no CADR runtime screenshot. A future visible guest-input claim requires an isolated System 303 Xvfb-computer-use run and the repository's capture and rights review.

Normative language and evidence

MUST, MUST NOT, SHOULD, and MAY define this selected reconstruction profile. They do not silently modify either historical source profile.

When sources differ, the profile does not average them: S46-KBD supplies the selected legacy Cadet numbers, S303-X11/S303-CADET supply the selected maintained X11 transition model, and ALT-SDL3 remains an explicit alternate defect record. DEC-M8 selects a browser transport that none of those sources could have implemented.

Exact profile and evidence ledger

The local System 46 checkout was inspected at Git commit 8e978d7d…. The local maintained LM-3 inventory verifies the system-303 Fossil check-in 4df393c… against its recorded manifest; the CADR-WEB profile records both it and the usim check-in. The materialized, independently hash-checked usim sources below were inspected rather than treating the profile pin as source-body evidence.

The historical kbd.c downstream queue is evidence for consumer pressure, not the M8 host queue's capacity or transaction policy. The latter is a selected bounded handoff seam (DEC-M8/INF-M8).

Architecture and ownership

DOM key edge or onscreen action ──> shared v6 browser channel ──> worker C-M8 controller
                                                                     │
                                                                     ├─ canonical CDRM8KB1 host state
                                                                     └─ one strict CDRINP1 record per accepted word
                                                                                 │
completed CADR boundary ──> ABI 1.8 M9 core ingress ──> IOB keyboard event/FIFO

• The browser host preserves physical identity as code, carries DOM's repeat flag, and submits only the dedicated v6 operations. Its onscreen view may use the same operation callback. It MUST NOT infer worker held state. Its only retained ownership is a delivery obligation for a pointer down whose matching up has not yet been accepted or definitively reconciled by the exact canonical keyboard-up/not-held response.
• The worker owns C-M8 held state, queue capacity, shared focus/capture-loss recovery, canonical state, and every accepted unsigned 16-bit word. The controller owns no CADR core memory and does not invoke generic scheduler ingress.
• The ABI 1.8 implementation accepts a record only while the machine is RUNNING at a completed BOUNDARY_READY phase. It validates the exact generation and next shared ingress ordinal before calling the IOB keyboard event function; it commits its ordinal and input sequence only after that function succeeds. It does not route input through generic scheduler kinds.
• keyboard-drain remains host-controller observation. In normal v6 delivery, the worker consumes only the exact entries that the core has accepted; it is not an independent guest-delivery interface.

Complete physical-input inventory

The normative inventory is CADR_M8_PHYSICAL_KEYS: 100 immutable descriptors, each with a unique KeyboardEvent.code, physical ID, label, row, 7-bit Cadet scan code, and (when applicable) semantic modifier bit. CADR_M8_ONSCREEN_ROWS partitions that exact inventory into rows of 12, 21, 21, 18, 19, 9; the onscreen renderer creates one button per descriptor. The test enumerates all 100 descriptors, so the executable table rather than a manually abbreviated prose table is normative.

There are 82 ordinary/function keys and these 18 physical modifiers:

The browser selects by code, never by a localized character value. Thus the host’s layout-dependent character production is outside C-M8; an unmapped code is rejected without changing held state or queue. The actual physical Repeat descriptor is a normal mapped down/up source even while repeated browser keydown notifications are suppressed. There are no C-M8 application command bindings, prefixes, pointer translators, menus, numeric argument rules, or Help bindings: this is below the CADR application binding layer.

State model and invariants

The worker-owned CadrM8KeyboardController state is:

Invariants:

1. Every map descriptor has a unique physical id and DOM code; all scan codes fit seven bits. The map has exactly 100 descriptors, 82 ordinary and 18 modifiers.
2. A duplicate down, DOM repeat, unknown code, unheld up, invalid field, or full queue MUST leave state unchanged.
3. An accepted down queues its seven-bit scan code. A key release first removes its descriptor from a staged held set. If an ordinary key remains, it queues 0x0100 | scancode; otherwise it queues 0x8000 | semantic-mask(staged-held).
4. The 11-bit semantic mask orders bits Shift, Greek, Top, Caps Lock, Control, Meta, Super, Hyper, Alt Lock, Mode Lock, Repeat from bit 0 through bit 10. Its high five bits MUST be zero.
5. Focus loss first reserves one queue slot. Only then it clears every held descriptor and appends exactly one 0x8000; a failed reservation preserves both held state and queue.
6. An onscreen pointer release remains host-owned until the worker confirms its keyboard-up. Acceptance or the exact canonical rejected keyboard-up response with reason: "not-held" proves convergence. Queue-full, another rejection, an asynchronous pending result, an unknown transport result, or a raw controller subresult MUST NOT erase that ownership. A known rejected down is the only down path that proves no corresponding release is owed.

Normative controller transitions

if no descriptor: reject unmapped
if repeat: reject dom-repeat
if descriptor already held: reject already-held
if no free FIFO slot: reject queue-full
add descriptor to held
append descriptor.scancode
return accepted down and that u16 word

if no descriptor: reject unmapped
if descriptor is not held: reject not-held
if no free FIFO slot: reject queue-full
staged-held := held minus descriptor
if staged-held contains an ordinary descriptor:
    word := 0x0100 OR descriptor.scancode
else:
    word := 0x8000 OR OR(modifier bit of every staged-held descriptor)
commit staged-held and append word
return accepted up or all-up and that u16 word

Canonical state representation

CDRM8KB1 is an INF-M8 host-state record, not a historical CADR image or keyboard-device layout. Multi-byte fields are little-endian. Its parser MUST reject a bad magic/schema/key count, zero capacity, queue count beyond capacity, length mismatch, an unknown held descriptor, duplicate held code in input object form, or nonzero unused bits in the final held bitset byte.

Held keys serialize in descriptor-index order regardless of down order. The FIFO retains queue order. Re-parsing and reserializing valid bytes MUST reproduce the same bytes.

Protocol v6 and ABI 1.8 input inventory

CadrM8KeyboardProtocolSubhandler is the M8 branch of the implemented v6 worker endpoint, not a browser-main-thread state owner. The outer worker remains solely responsible for request-ID sequencing, lifecycle, and non-M8 dispatch. cadr-m8-m9-worker-channel.mjs allocates those IDs once for both M8 and M9; CadrM9PointerAdapter accepts that allocator instead of using a conflicting per-adapter sequence. A well-formed host-originated request contains protocol version 6, a positive u32 ID, and one of the operations below. Each operation accepts only the fields listed below plus version, id, and op; extra fields are rejected before controller mutation.

Handled requests use the canonical worker response core: type: "cadr-response", version, ID, operation, unsigned numeric status, and boolean ok. Status 0 is success, 2 invalid argument, and 9 queue/core not-ready. The sub-handler adds result or reason but does not invent a separate M8 response envelope. It returns null for requests owned by the outer worker.

For scheduler-events, the sub-handler inspects only the keyboard boundary. A batch containing any event of generic kind 3 is rejected as a whole with status 2 and v6-keyboard-is-host-only. Batches containing only sequence break kind 1 and/or clock kind 2 return null unchanged for the existing generic scheduler handler. Malformed and unknown-kind batches also delegate so that existing validation remains authoritative. The legacy singular scheduler-keyboard-event name is always rejected. The response spelling is a generic-ingress compatibility label, not a statement that the named M8/M9 path is host-only. The branch is installed only for v6 with an ABI 1.8 M9 Wasm module. It submits one exact 40-byte CDRINP1 record per accepted controller entry and leaves the generic scheduler request tree closed.

CDRINP1 is little-endian and exactly 40 bytes. It is a reconstruction record, not a native usim scheduler or X11 record:

The matching CDRIOB91 64-byte worker observation reports post-delivery IOB state, sequence, ordinal, generation, and lifecycle. It is not a pre-IOB native transition witness. ABI 1.8 M9 input state is deliberately excluded from the M5 snapshot layout, and v6 snapshot operations return NOT_READY rather than emit a non-restorable snapshot.

Failure and recovery behavior

• Map and event validation occur before a queue or held-state mutation.
• Capacity failure is a retryable host result, not a dropped historical key.
• An onscreen up that receives queue-full remains pending. Removing its ownership before accepted delivery is forbidden; disposal is another retry boundary, not permission to forget it.
• keyboard-focus-lost and pointer-neutralize are composed worker deactivation requests. M9 reserves one complete pointer-up tail plus exactly one all-up; after every record crosses the core boundary, the same serialized request clears M8 held keys. It never invokes standalone focusLost() and therefore cannot emit a second all-up.
• After an accepted atomic keyboard-focus-lost, a later onscreen up may receive canonical not-held; that exact response clears stale ownership and permits the physical code to be pressed again. The same rule reconciles an unknown down transport result when the worker definitively reports it never held the code.
• focusLost is the only recovery operation. It does not try to synthesize per-key ups after focus loss, and it does not preserve modifiers from an untrusted browser focus domain.
• The canonical parser makes no best-effort repair. Invalid state bytes cannot construct a controller.
• Onscreen pointer cancellation emits only a corresponding host keyboard-up operation; disposal does the same for its pointer-held descriptors. The browser binding maps a focus-surface blur to keyboard-focus-lost; it reads KeyboardEvent.code, never KeyboardEvent.key, and has no guest IOB rollback authority.

Conformance suite

tests/test_cadr_m8_keyboard.mjs uses only synthetic DOM-code records and no CADR media.

Preserved-system comparison procedure

No native runtime comparison has run for C-M8. A disposable, source-pinned pre-IOB witness patch and input driver now prepare and compile without launching a machine; that is build evidence only. When the native campaign starts, run only through a fresh private System 303-0 Xvfb computer-use session, preserve the required load-band, disk, usim, toolchain, input-action, screenshot, and shutdown provenance, and keep raw payloads ignored. Compare a small, safe input trace to the selected X11 executable before treating any outcome as a System 303 claim.

Known unknowns and nonclaims

• The source inspection does not establish a System 303-0 runtime execution of this new browser controller or its DOM code choices.
• Keyboard layout, IME, browser-reserved shortcuts, accessibility remapping, multi-window focus order, and USB hardware availability are host-integration policy, not historical Cadet behavior.
• The ten-entry kbd.c queue does not determine the Phase 1 queue default of 64, eventual worker drain cadence, or guest backpressure policy.
• C-M8 does not specify cold/warm boot combinations, machine-control shortcuts, mouse input, display focus styling, guest input echo, source compatibility, binary compatibility, timing identity, or pixel identity.

Artifact identities and sources

All inspection used public source or tracked reconstruction code; no licensed Genera or local System 303 media is included.

• System 46 kbd.123, Git 8e978d7d1704096a63edd4386a3b8326a2e584af.
• maintained x11.c, cadet.c, kbd.c, and SDL3 key map, Fossil 330d8248ec2e12af071e287920e681600f75df9ffd854aada5f8a64c9adad64d.
• maintained LM-3 System 303 check-in, Fossil 4df393c68d7f083ce42d5c377039d26043cc18a9031ace28258dc97f4137eb91.
• Selected implementation: cadr-m8-keyboard.mjs, cadr-m8-onscreen-keyboard.mjs, the shared browser/worker channel cadr-m8-m9-worker-channel.mjs, and the ABI record definition cadr_m9_input.h. The actual v6 branch is in cadr-worker.js; test_cadr_m9_input_bridge.c and tests/test_cadr_m8_m9_worker.mjs cover direct-core and worker boundaries. The native witness/driver is tracked in cadr_m8_m9_input_witness.c, cadr_m8_m9_input_driver.c, and the exact patch 0004-m8-m9-pre-iob-input-witness.patch.

Last verified: 2026-07-30.