v1.2: Presence pipeline activation (camera-derived atDesk/presenceConfidence) #85

Open
opened 2026-05-12 19:31:14 +00:00 by KofTwentyTwo · 0 comments
KofTwentyTwo commented 2026-05-12 19:31:14 +00:00 (Migrated from github.com)

Summary

Activate the presence pipeline. Today, `PresenceMonitor`, `PresenceSignalBus`, `PresenceEvent`, `PresenceStateSnapshot` are all MAPPED internally but DEFERRED — face-detection runs in unit tests, but the camera-derived `atDesk` / `presenceConfidence` fields don't surface to HUD or agent state in production.

Includes: `HudStateCoordinator` integration verification + decision on surface home (per API design v0.1:1017, presence may surface through `Self.selfStateChanged`, a new `Presence` surface, or `Voice.voiceStateChanged`).

Evidence

  • Migration plan §10 v1.2: `.planning/architecture/JARVIS-API-MIGRATION-PLAN.md:743`.
  • INVENTORY.md:823-825 lists Presence types as MAPPED + DEFERRED internal.
  • API design v0.1:1017 — open question: which surface owns presence state.

Gap classification

"design-mapped but not built" — pipeline complete in Vision package; not wired to runtime.

Recommended action

File against v1.2 milestone. Decide presence surface home first (Self vs. Presence vs. Voice). Then wire `PresenceMonitor` into `installVision`, route to chosen surface.

Cross-references

  • Migration plan §10 v1.2
  • API design v0.1:1017 (presence surface home decision)
  • VISION-02, VISION-03 in REQUIREMENTS.md (presence as signal, never trigger; anti-feature: presence-triggered auto-speak)
## Summary Activate the presence pipeline. Today, \`PresenceMonitor\`, \`PresenceSignalBus\`, \`PresenceEvent\`, \`PresenceStateSnapshot\` are all MAPPED internally but DEFERRED — face-detection runs in unit tests, but the camera-derived \`atDesk\` / \`presenceConfidence\` fields don't surface to HUD or agent state in production. Includes: \`HudStateCoordinator\` integration verification + decision on surface home (per API design v0.1:1017, presence may surface through \`Self.selfStateChanged\`, a new \`Presence\` surface, or \`Voice.voiceStateChanged\`). ## Evidence - Migration plan §10 v1.2: \`.planning/architecture/JARVIS-API-MIGRATION-PLAN.md:743\`. - INVENTORY.md:823-825 lists Presence types as MAPPED + DEFERRED internal. - API design v0.1:1017 — open question: which surface owns presence state. ## Gap classification \"design-mapped but not built\" — pipeline complete in Vision package; not wired to runtime. ## Recommended action File against v1.2 milestone. Decide presence surface home first (Self vs. Presence vs. Voice). Then wire \`PresenceMonitor\` into \`installVision\`, route to chosen surface. ## Cross-references - Migration plan §10 v1.2 - API design v0.1:1017 (presence surface home decision) - VISION-02, VISION-03 in REQUIREMENTS.md (presence as signal, never trigger; anti-feature: presence-triggered auto-speak)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: KofTwentyTwo/Jarvis#85