CueNexa Loop

CueNexa Loop uses Bee conversations to surface commitments, decisions, deadlines, and unresolved follow-ups—helping you remember not just what was said, but what still needs to get done.

Comment

posted an update —

CueNexa Loop — Shipathon Project Update

Current Status

CueNexa Loop is now in HOLD-CONTEST-STABLE mode.

The core product work, live Bee validation, Electron integration reference, developer documentation, and contest submission are complete.

The project is intentionally stable while the contest entry is active.

No new feature development is currently authorized.

What Has Been Completed

Core CueNexa Loop

  • Phase 0 — Foundation and Bee integration: CLOSED
  • Phase 1A — Deterministic LoopItem detection: CLOSED
  • Phase 1B — Cross-conversation correlation: CLOSED
  • Phase 2 — Local persistent follow-through: CLOSED
  • Phase 3 — Review, attention, user state, and notifications: CLOSED
  • Phase 4 — Ambient realtime awareness: CLOSED
  • Phase 4 live Bee acceptance: PASSED

The core architecture remains:

Bee conversations
        ↓
Processed Bee history
        ↓
Deterministic detection
        ↓
Cross-conversation correlation
        ↓
Local persistent LoopThread
        ↓
Review / follow-through workflow

Realtime remains an optional acceleration layer:

Bee realtime
        ↓
ProvisionalAwareness
        ↓
PROVISIONAL UI
        ↓
memory only
        ↓
never directly persisted

Processed Bee history remains the only authority for persistent Loop state.

Electron Local Integration Reference

CueNexa Loop now includes a complete, executable Electron Local Integration Reference in the public repository:

examples/electron-local-reference/

This is working example code showing developers how CueNexa Loop can be embedded into a local desktop application while preserving its privacy, persistence, and architecture rules.

The Electron reference was completed through the P4-R1 milestone:

  • P4-R1A — Authoritative historical integration: MERGED
  • P4-R1B — Provisional realtime awareness: MERGED
  • P4-R1C — Developer documentation and acceptance polish: MERGED
  • P4-R1 overall: CLOSED

P4-R1A — Authoritative Historical Integration

The Electron Main Process demonstrates the complete authoritative CueNexa processing pipeline:

Bee processed history
        ↓
BeeAdapterClient.ensureAuthenticated()
        ↓
fetchCompleteDetectionSnapshot()
        ↓
detectLoopItems()
        ↓
correlateLoopItems()
        ↓
LoopStore.reconcile()
        ↓
buildReviewModel()
        ↓
host-owned sanitized DTO
        ↓
Electron IPC
        ↓
Electron Renderer

The reference application demonstrates:

  • Bee authentication checking
  • processed-history synchronization
  • deterministic LoopItem detection
  • cross-conversation correlation
  • persistent local LoopThread reconciliation
  • actionable review-model generation
  • sanitized Electron IPC
  • read-only structural renderer output
  • partial/degraded snapshot handling
  • restart continuity
  • timezone-aware deadline processing

Processed Bee history remains the only persistence authority.

P4-R1B — Provisional Realtime Awareness

The same Electron reference also demonstrates optional Bee realtime awareness:

Bee realtime
        ↓
BeeAdapterClient.subscribeRealtime()
        ↓
Electron Main Process
        ↓
ProvisionalAwareness
        ↓
sanitized provisional DTO
        ↓
Electron IPC
        ↓
PROVISIONAL Renderer UI
        ↓
never directly persisted

The realtime implementation includes:

  • realtime Start
  • realtime Stop
  • Start / Stop / Start lifecycle
  • connection health states
  • memory-only provisional signals
  • provisional TTL expiration
  • stream disconnect isolation
  • bounded reconnect behavior
  • sanitized warning handling
  • explicit separation between provisional and authoritative state

Realtime events never directly create, modify, resolve, reopen, or delete persistent LoopThread records.

Authoritative vs Provisional State

CueNexa Loop deliberately maintains two separate tracks.

Authoritative

Processed Bee history
→ deterministic detection
→ deterministic correlation
→ LoopStore
→ persistent LoopThread

Provisional

Bee realtime
→ ProvisionalAwareness
→ temporary PROVISIONAL UI
→ memory only

The two tracks are never treated as interchangeable.

Realtime accelerates awareness.

Processed history determines durable state.

Working Example Application

The Electron example is not only reference documentation.

It is an actual runnable application.

It includes:

  • Bee authentication and connectivity checks
  • authoritative Sync
  • local SQLite persistence
  • review sections
  • optional realtime monitoring
  • Start / Stop controls
  • PROVISIONAL awareness display
  • partial-state warnings
  • sanitized errors
  • restart-safe persistence
  • isolated realtime lifecycle
  • hardened Electron renderer boundary

Review Interface

The authoritative review UI separates persistent LoopThreads into:

  • Due Now
  • Needs Attention
  • Waiting
  • Snoozed
  • Recently Resolved

Realtime observations appear in a completely separate:

PROVISIONAL

section.

They are never mixed directly into authoritative persistent review sections.

Running the Example

Prerequisites

  • Node.js 22 or newer
  • npm
  • Bee desktop application
  • Bee Developer Mode enabled
  • official @beeai/cli
  • authenticated Bee CLI session

Verify Bee access:

bee status

Install

From the CueNexa Loop repository root:

npm ci

Build

npm run build

Run the Electron Example

npm start --workspace @cuenexa-loop/electron-local-reference

Run Example Tests

npx vitest run examples/electron-local-reference

Local Storage

The Electron Main Process owns LoopStore.

The Electron reference uses its own application-specific SQLite database under Electron userData.

Typical logical filename:

cuenexa-loop-electron-reference.sqlite

This is intentionally separate from the CueNexa CLI database:

~/.cuenexa-loop/cuenexa-loop.sqlite

For development and disposable acceptance testing, the Electron database can be overridden:

export CUENEXA_LOOP_ELECTRON_DB_PATH="/tmp/cuenexa-loop-electron-reference.sqlite"
npm start --workspace @cuenexa-loop/electron-local-reference

This allowed live acceptance to verify the reference without modifying the normal CLI database.

Timezone Handling

The Electron host resolves timezone using the same documented hierarchy:

  1. valid LOOP_TIMEZONE override
  2. Bee account timezone
  3. system timezone

CueNexa does not silently assume UTC.

Electron IPC Boundary

The application uses a narrow, explicit IPC surface.

Authoritative channels include:

cuenexa:get-status
cuenexa:sync
cuenexa:get-review

Realtime support adds only:

cuenexa:start-realtime
cuenexa:stop-realtime
cuenexa:get-provisional
cuenexa:provisional-updated

There is no generic dispatcher.

The renderer does not receive direct Bee or SQLite access.

Electron Security Model

The reference demonstrates a hardened Electron configuration:

contextIsolation: true
nodeIntegration: false
sandbox: true
webSecurity: true

It also avoids:

  • webviewTag
  • arbitrary navigation
  • arbitrary window creation
  • remote fonts
  • CDN dependencies
  • telemetry
  • analytics
  • external LLM calls

The renderer receives only sanitized derived DTOs.

It does not receive:

  • Bee client objects
  • SQLite handles
  • filesystem access
  • raw Bee payloads
  • transcripts
  • utterance text
  • evidence text
  • summaries
  • authentication material
  • realtime UUIDs
  • speaker identifiers
  • precise location

Restart Behavior

The Electron reference deliberately separates persistent and memory-only state.

After application restart:

Realtime health → off
Provisional signals → empty
Persistent SQLite state → retained
Renderer review → empty until next authoritative Sync

The empty-until-Sync renderer behavior is intentional in this reference implementation.

A fresh authoritative Sync reconstructs the current review state.

Failure Isolation

The reference demonstrates that realtime failure must never compromise the authoritative application path.

Examples:

Situation Expected Behavior
Bee CLI unavailable Sanitized unavailable state
Bee unauthenticated User is instructed to restore Bee authentication
Processed history delayed Sync remains authoritative; retry after Bee processing
Snapshot partial Mark partial; never infer resolution
Realtime disconnected Authoritative review remains operational
Unsupported realtime event Safely ignored / sanitized warning
No provisional signal Historical Sync remains authoritative
App restarted Provisional state cleared; persistent DB retained

Live Bee Acceptance

The Electron reference was tested against a real authenticated Bee environment.

P4-R1A Live Acceptance

PASS

Verified:

  • Electron app launch
  • Bee authentication
  • authoritative Sync
  • complete processed-history snapshot
  • review-model rendering
  • repeat Sync without duplicates
  • isolated disposable SQLite database
  • restart continuity
  • historical operation without realtime

Observed authoritative review:

Due Now: 1
Needs Attention: 4
Waiting: 0
Snoozed: 0
Recently Resolved: 0

Five structural Loop cards were observed.

Private Loop titles were not recorded.

P4-R1B Live Acceptance

PASS

A real human Bee utterance was performed while realtime was active.

The actual spoken content was intentionally not recorded in repository evidence.

Observed provisional results:

Realtime health: active
Provisional signals: 2

Structural signal types observed:

possible_commitment — strong
possible_deadline — tentative

They appeared only in the separate PROVISIONAL UI.

Before authoritative Sync:

Persistent threads before realtime: 5
Persistent events before realtime: 5

Persistent threads after realtime: 5
Persistent events after realtime: 5

This demonstrated that real Bee realtime activity produced:

ZERO persistent LoopThread changes
ZERO persistent history changes

After application restart:

Persistent threads: 5
Persistent events: 5
Provisional signals: 0
Realtime health: off

The live test confirmed that realtime awareness is truly memory-only.

Acceptance Evidence

Repository evidence includes:

docs/audit/P4-R1A-LIVE-ACCEPTANCE-2026-10-06.md
docs/audit/P4-R1B-LIVE-ACCEPTANCE-2026-10-07.md

The complete Electron contract is documented at:

docs/P4-R1-ELECTRON-LOCAL-REFERENCE.md

Application integration guidance is available at:

docs/APP-INTEGRATION-GUIDE.md

The example developer README is located at:

examples/electron-local-reference/README.md

Automated Validation

Current verified engineering baseline:

56 test files passing
465 tests passing
TypeScript typecheck PASS
Build PASS
npm audit: 0 vulnerabilities

Automated tests use synthetic fixtures only.

Real Bee personal data is not used in CI.

Privacy and Security

CueNexa Loop continues to follow a strict local-first architecture.

Key safeguards include:

  • no raw Bee transcripts persisted
  • no realtime conversation UUIDs persisted
  • no raw utterances persisted
  • no evidence text persisted
  • no precise location persisted
  • no authentication credentials persisted
  • no external LLM required
  • no cloud API required
  • no telemetry
  • no analytics
  • no Bee writeback
  • no background network daemon
  • no heuristic realtime-to-history identity guessing
  • no resolution inferred from disappearance
  • synthetic fixtures only in automated testing

Realtime remains memory-only.

Processed Bee history remains the only persistence authority.

Identity Safety

Bee realtime conversation UUIDs and processed-history conversation IDs are separate namespaces.

CueNexa does not guess mappings using:

  • timestamps
  • titles
  • transcript similarity
  • speaker similarity
  • sequence order
  • string matching

A mapping is only accepted when Bee explicitly provides both identifiers within a supported event.

Developer Documentation

The Electron example now includes documentation covering:

  • prerequisites
  • installation
  • build instructions
  • launch instructions
  • authoritative Sync
  • realtime Start / Stop
  • architecture diagrams
  • storage paths
  • disposable databases
  • timezone behavior
  • IPC channels
  • Electron security
  • restart behavior
  • failure isolation
  • privacy rules
  • troubleshooting
  • live acceptance evidence
  • known limitations

This makes the project both:

  1. a working follow-through engine; and
  2. an executable integration reference for developers.

Known Limitations

Bee Processing Delay

Processed Bee history may not become immediately available after recording.

During live testing, manual:

Process now

may sometimes be useful before running authoritative Sync.

Realtime Is Best-Effort

Realtime is treated as provisional and potentially lossy.

Historical Sync remains the repair and persistence authority.

Restart Requires Sync

The Electron renderer does not rebuild its current review snapshot directly from SQLite at startup.

After restart, run authoritative Sync to rebuild the displayed review.

Spoken Time Fidelity

A previously observed non-blocking case showed Bee processed text shortening a spoken phrase such as:

September 23 at 3 PM

into approximately:

September 23 at 3 p.

This affected downstream time-of-day parsing.

The issue remains documented as a non-blocking backlog item.

It is not currently authorized development work while the project is in contest hold mode.

Contest Submission

CueNexa Loop's contest entry is active.

Completed submission/readiness assets include:

  • public GitHub repository
  • MIT license
  • Bee integration
  • deterministic follow-through engine
  • realtime provisional-awareness layer
  • persistent local LoopThread model
  • automated tests
  • live Bee acceptance evidence
  • Electron integration reference
  • developer README
  • application integration guide
  • architecture documentation
  • privacy/security documentation
  • developer friction log
  • demo video
  • Devpost submission

The project is officially entered in the Amazon Developer Build, Ship, Shape Hackathon.

Current Development Posture

HOLD-CONTEST-STABLE

The owner has selected:

HOLD-CONTEST-STABLE

While the contest entry is active:

  • no new feature development
  • no architecture expansion
  • no new product milestone
  • no host-product discovery
  • no date/time-fidelity implementation
  • no speculative refactoring
  • no Phase 5 work

Engineering work may reopen only for genuine:

  • defects
  • regressions
  • security findings
  • dependency vulnerabilities
  • compatibility breakage
  • explicitly owner-authorized maintenance

Existing non-blocking backlog items remain backlog only.

Phase 5

NOT DEFINED / NOT AUTHORIZED

No Phase 5 scope has been created.

No future milestone should be inferred automatically from P4-R1 completion.

Any future product milestone requires explicit owner authorization.

Current Repository Lifecycle

Phase 0:   CLOSED
Phase 1A:  CLOSED
Phase 1B:  CLOSED
Phase 2:   CLOSED
Phase 3:   CLOSED
Phase 4:   CLOSED

P4-R1A:    MERGED
P4-R1B:    MERGED
P4-R1C:    MERGED
P4-R1:     CLOSED

Contest posture:
HOLD-CONTEST-STABLE

Phase 5:
NOT DEFINED / NOT AUTHORIZED

Summary

CueNexa Loop has moved from a Bee-connected prototype into a tested local-first follow-through engine with:

  • deterministic detection
  • cross-conversation correlation
  • persistent local follow-through
  • attention and review workflows
  • provisional realtime awareness
  • live Bee validation
  • a complete Electron integration reference
  • hardened local desktop architecture
  • extensive automated testing
  • privacy/security boundaries
  • developer-facing integration documentation

The project is now intentionally being kept stable during the contest period.

No feature development is planned unless explicitly authorized.

Current posture: HOLD-CONTEST-STABLE.

Log in or sign up for Devpost to join the conversation.