lantern

unified-context-provider

🎯 The Unified Context Provider

Case Details

Case ID: task-02b87f47-4b6e-43a3-959c-c861ed6002f7 Status: parked Created: 2026-01-26T01:03:11.481Z Updated: 2026-01-26T01:03:11.481Z Priority: 2

Investigation Details

Case Type: story Urgency Level: routine

Notes

The Problem

GraphNode provider and PipelineProvider have separate config/context injection mechanisms:

  • GraphNode - Tries to inject config from node's Config section, but has issues with parsing and merging
  • PipelineProvider - Uses session-based context that accumulates through chain execution

Currently when PipelineProvider calls graphnode:node:fetch, the node's own config YAML doesn't get loaded - only pipeline params are passed.

The Solution

Unify on sessions: GraphNode provider should use the same session context system as PipelineProvider.

When a graphnode fence executes:

  • Create a temporary session (or join an existing pipeline session)
  • Load the node's config section YAML into _context
  • Merge any passed params on top
  • Execute the fence with unified context
  • Clean up temporary session (or leave pipeline session intact)

Benefits

  • Single context system - No more confusion about how config gets injected
  • Automatic config loading - Every fence gets its node's config automatically
  • Pipeline compatibility - Standalone execution works same as pipeline execution
  • Session tracking - Even standalone executions get tracked for debugging

Implementation

  • Modify GraphNodeProvider.execute() to:- Check for existing session in context

  • If no session, create temporary one

  • Load node's config section into session context

  • Merge with passed params

  • Execute fence

  • Cleanup if temporary

  • Config section becomes the "default context" for any fence in that node

Related Files

  • oculus/providers/graphnode_provider.py - Needs session integration
  • oculus/providers/pipeline_provider.py - Reference implementation
  • oculus/pipeline_session_store.py - Session storage

Acceptance Criteria

  • graphnode:wh-demand-history:fetch loads config from node's config section
  • Pipeline execution still works (no regression)
  • Standalone fence execution creates temporary session
  • Session visible in /api/pipeline/sessions (optional flag to exclude temp sessions)

Investigation Timeline

2026-01-26T01:03:11.487Z - System - case_created

Case opened from CLI

Consciousness Links

Context: Spawned from Beye demo work - config injection not working through pipeline

This case file is automatically updated. For investigation logs, see the corresponding log channel.

📋 Case To-Do List

This case has an integrated to-do list system that syncs with the Oculus knowledge graph. The to-do list uses the virtual:todo-list fence which auto-detects GitHub-style checkbox markdown.

How the To-Do System Works

  • Auto-Detection: Checkbox lists are automatically detected as virtual:todo-list fences
  • Alice Integration: Display in Alice dashboard using :::wonderland-todo-list slug="${current_case}"
  • ISA Operations: Use fence exec for add/check/update operations
  • Metadata Support: Add [assignee:name] [priority:level] tags to tasks

Case To-Do Operations

  • View state: oculus fence list ${slug} then oculus fence view ${slug} <fence-index>
  • Add task: oculus fence exec ${slug} <fence-index> add "New task"
  • Check task: oculus fence exec ${slug} <fence-index> check 0
  • Update task: oculus fence exec ${slug} <fence-index> update 0 "Updated content"
  • Reference: See virtual-fence-todo for full documentation

Current Case Tasks

  • 🎯 Solve the case
  • 📝 Document findings in investigation notes
  • 🔗 Link relevant evidence and consciousness resources
  • ✅ Update case status when complete

Next Steps

Add investigation notes and evidence tags as you progress. The to-do list will evolve with your investigation. Tasks can be managed via Oculus fence operations or edited directly in the node.

Provenance

Document

  • Status: 🔴 Unverified