[Integration] Bridge as SensoryBus subscriber — real-time cognitive pipeline #80

Closed
opened 2026-03-20 14:54:48 -04:00 by perplexity · 1 comment
Owner

Overview

Wire the CognitiveBridge as a SensoryBus subscriber in Timmy's dashboard. Every cognitive event flows directly to the Matrix in real-time — no file polling, no presence.json.

Architecture

SensoryBus
  ├── "thought_completed"    → bridge.on_thought()
  ├── "cognitive_state_changed" → bridge.on_state_change()
  ├── "gitea.issue.opened"   → bridge.on_issue_filed()
  ├── "gitea.push"           → bridge.on_repo_push()
  ├── "visitor.entered"      → bridge.on_visitor_enter()
  └── "visitor.left"         → bridge.on_visitor_leave()

Changes

server/bridge.py

New method: register_on_bus(bus: SensoryBus)

  • Subscribes to all relevant event types
  • Translates SensoryEvent → existing handler calls
  • Adapter pattern: SensoryEvent.data → expected handler dict format

New handlers:

  • on_repo_push(event) — translates gitea.push into bark + state
  • on_repo_pr(event) — translates gitea.pull_request

Dashboard integration point

In Timmy's session.py or startup:

from server.bridge import CognitiveBridge
bridge = CognitiveBridge(gateway_url="ws://localhost:8765")
await bridge.connect()
bridge.register_on_bus(sensory_bus)

Acceptance Criteria

  • register_on_bus() subscribes to all event types
  • SensoryEvent → handler translation works for all event types
  • Real-time: events appear in Matrix within 1s of bus emission
  • Standalone mode (presence.json polling) still works as fallback
  • No circular imports between bridge and dashboard
  • Integration test: emit event on bus → verify Matrix message

Depends On

  • Dashboard's SensoryBus API (already exists)
  • #69 (bridge) — merged

Note

The bridge module lives in the-matrix repo but is designed to be imported by timmy-tower. This issue tracks the Matrix-side adapter; the dashboard-side wiring is a timmy-tower issue.

## Overview Wire the CognitiveBridge as a SensoryBus subscriber in Timmy's dashboard. Every cognitive event flows directly to the Matrix in real-time — no file polling, no presence.json. ## Architecture ``` SensoryBus ├── "thought_completed" → bridge.on_thought() ├── "cognitive_state_changed" → bridge.on_state_change() ├── "gitea.issue.opened" → bridge.on_issue_filed() ├── "gitea.push" → bridge.on_repo_push() ├── "visitor.entered" → bridge.on_visitor_enter() └── "visitor.left" → bridge.on_visitor_leave() ``` ## Changes ### `server/bridge.py` New method: `register_on_bus(bus: SensoryBus)` - Subscribes to all relevant event types - Translates SensoryEvent → existing handler calls - Adapter pattern: `SensoryEvent.data` → expected handler dict format New handlers: - `on_repo_push(event)` — translates gitea.push into bark + state - `on_repo_pr(event)` — translates gitea.pull_request ### Dashboard integration point In Timmy's `session.py` or startup: ```python from server.bridge import CognitiveBridge bridge = CognitiveBridge(gateway_url="ws://localhost:8765") await bridge.connect() bridge.register_on_bus(sensory_bus) ``` ## Acceptance Criteria - [ ] `register_on_bus()` subscribes to all event types - [ ] SensoryEvent → handler translation works for all event types - [ ] Real-time: events appear in Matrix within 1s of bus emission - [ ] Standalone mode (presence.json polling) still works as fallback - [ ] No circular imports between bridge and dashboard - [ ] Integration test: emit event on bus → verify Matrix message ## Depends On - Dashboard's SensoryBus API (already exists) - #69 (bridge) — merged ## Note The bridge module lives in the-matrix repo but is designed to be imported by timmy-tower. This issue tracks the Matrix-side adapter; the dashboard-side wiring is a timmy-tower issue.
Author
Owner

Resolved in PR #81 (feat/automation-sprint). All tests passing.

Resolved in PR #81 (feat/automation-sprint). All tests passing.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: perplexity/the-matrix#80