Eye / camera control traceability matrix¶

This is the one-page map from decision -> spec -> issue -> verification.

Core architecture¶

Cross-cutting implementation gaps¶

The original #392–#412 split covered the feature path but not all production obligations. The programme also tracks:

These gaps receive dedicated issues in milestone #10.

Dependency graph¶

DESIGN / GOVERNANCE
  ADR-v2-145 shared perception
      |
      +--> #393 signal contracts
            -> #394 source lifecycle
            -> #395 multi-signal MediaPipe
            -> #396 migrate gaze
                  +-> #397 click capture -> #398 safe apply
                  +-> #399 measurement
                  +-> Wayland target semantics
                  +-> topology/HiDPI validation

  ADR-v2-146 pointer boundary
      |
      +--> #400 PointerSink
            +-> #401 X11
            +-> #402 macOS/Windows
            +-> #403 Wayland portal
                    |
                    +----> #404 Head-Pointer runtime -> #405 UX/recovery

  ADR-v2-147 face-switch intent
      |
      +--> #406 detector -> #407 activation adapter
                              +-> #408 Gesture Chords
                              +-> #409 false-activation harness

  permission + observability + global safety
                   \            |             /
                    +----------- #410 hands-free bundle
                                      |
                                    #411 field acceptance
                                      |
                                    #419 co-design
                                      |
                           experimental -> recommendation gate

  ADR-v2-151 grounded target resolution
      |
      +--> #441 contracts
            -> #442 pure resolver
                 +-> #443 gaze/deixis integration
                 +-> #445 evaluation harness
      |
      +--> #444 live semantic-source coverage (human/platform evidence)

  #412 dedicated tracker study is parallel/future

Status rules¶

When code lands, update all of: - this matrix; - README.md status table; - relevant spec status; - docs/features.md; - feature registry wiring status when applicable; - issue state.

A merge that updates code but leaves a capability listed as DESIGNED/CORE is incomplete planning work.

Verification ownership¶

Release proof bundle¶

Before an experimental release, one issue/PR should be able to link: 1. merged ADR/spec; 2. implementation PR; 3. narrow CI; 4. privacy/permission result; 5. at least one hardware report; 6. setup/troubleshooting docs.

Before recommended status, add: 7. multi-environment field evidence; 8. false-activation/error metrics; 9. accessibility review; 10. resolved/accepted risk register.

Evaluation traceability¶

Community QA rows are not automatically eligible for participant-level paper analysis.

Acceptance traceability — #411 and #419¶

The two human-study issues each carry an acceptance list. This table links every item to its issue, the validation slots that will collect it, and the pure test that guards what can be guarded without a person. It records links, not outcomes: no row says an item has been met, because for the "needs a person" column that is not something a repository file can say (README.md explains why this directory keeps no status snapshot). A test checks that every slot id, test and criterion named here still exists; a dash means there is none yet, and the test accepts a dash only because tests/test_eye_acceptance_consistency.py also checks the row has an issue.

T0-* and similar in the slots column is a glob over the ids in validation-slots.json; it must match at least one.