Skip to content

Natural Context Retrieval

Luna can answer natural self-context questions without requiring rigid Discord commands such as luna context roadmap.

Examples that trigger retrieval:

  • "show me our roadmap"
  • "describe your system architecture"
  • "where are we on the roadmap?"
  • "what are your current limitations?"
  • "what context do you have about yourself?"
  • "what is the Luna architecture?"

Boundary

Discord remains a thin transport layer. It does not read files directly, browse arbitrary paths, write files, mutate memory, or execute shell commands for this feature.

When a deterministic self-context intent is detected, the Discord transport adapter calls the governed luna-tools gateway through /fs/read. The first read is always:

/home/khrynisx/docs/luna/index/luna_context_index.md

The second read is selected from a fixed allowlist:

  • roadmap or architecture questions (including Phase 8E entity cognition surfaces): /home/khrynisx/docs/luna/roadmap/luna_master_roadmap.md
  • current state, active phase, limitations, or capabilities questions: /home/khrynisx/docs/luna/luna_state.md
  • live system questions: /home/khrynisx/docs/luna/luna_live_system.md
  • checkpoint questions: /home/khrynisx/docs/luna/checkpoint.md
  • Phase 6C runtime context tools (environment_status, clock_tool, etc.): mapped additively to existing live_system / state / index paths (no new files, bounded read-only)

User text is never treated as a file path. Path injection attempts are ignored because retrieval chooses only the fixed paths above.

Prompt Use

Retrieved content is request-scoped. It is prepended to the current model message only for the triggering request, then discarded. It is not injected into every prompt and is not promoted into long-term memory.

Context is bounded deterministically. If a source file or assembled context block exceeds the configured limits, Luna includes a clear truncation note in the prompt context.

Failure Mode

If luna-tools cannot read the context files, Luna does not fall back to direct filesystem access. The prompt receives a bounded failure note so the answer can say the context is currently unavailable.

LifeVault Boundary

Context retrieval is not memory authority. It may read allowed files, retrieve promoted LifeVault memory, or assemble request-scoped context windows, but it does not decide durable memory truth.

LifeVault is the logical memory continuity layer. pgvector/Postgres, SQLite, files, artifacts, audits, Discord history, Oracle evidence, Rubick records, and Meepo packets may support retrieval or evidence review, but retrieval output is only a bounded candidate/context surface. Durable memory requires governed review, promotion, provenance, and lifecycle status under LifeVault doctrine.

Phase 6D Operational Awareness Extension

Additive helpers (service_health_summary, container_health_snapshot, etc.) provide explicit bounded summaries for health, degradation, repo, updates, limitations, and source status. All remain within the existing deterministic intent + allowlist + truncation + fail-closed model. No changes to bot.py surface area.

Phase 6E Task Continuity Layer

Extends retrieval with continuity-specific intent classification and summarizers: current_task_summary, latest_checkpoint_summary, capabilities_summary, skills_summary, active_work_summary, recent_activity_summary, task_continuity_summary.

Fixed sources: current_task, checkpoint.md, luna_capabilities.md. Supports natural prompts for active work, checkpoints, capabilities/skills, recent success vs degraded operations. Fully request-scoped, deterministic, read-only, fail-closed. Preserves thin transport and governance.

Intent detection priority and term coverage were expanded to ensure self-state queries (time/clock, tools, limitations, operational state, recent activity, checkpoint) always win and route to governed sources before generic completion can occur.

Phase 6F introduces structured operational inventory renderers (tools_inventory_summary, skills_inventory_summary, etc.) that emit canonical, deterministic, bounded text instead of raw document dumps.

Current Retrieval Role

Context retrieval now participates in a broader governed cognition stack. It routes Luna/self/runtime/action/planning questions into deterministic registries, plan objects, workflow cognition, policy evaluation, simulation, and branch comparison helpers.

Retrieval remains:

  • request-scoped
  • bounded
  • read-only
  • fail-closed
  • semantically rendered by default
  • separated from internal IR unless explicitly requested

Operational terms such as tools, skills, limitations, planning, policy, simulation, rollback, validation, safest path, and blocked actions should resolve to governed internal cognition rather than generic model prose.

Directional Planner Advisory Metadata

Commander planning may receive directional cognition context as a read-only review signal. Governed directional cognition v0 is a metadata-only lifecycle: intent classification, packet generation, planner read-only exposure, planner advisory metadata, governance/replay proof, execution-boundary proof, and memory-boundary proof. The planner side exposes packet id, risk profile, planning posture, validation posture, caution flags, prohibited shortcut reminders, and the memory boundary marker only in review/replay metadata.

This metadata is advisory-only. It must not mutate TaskGraph nodes, lanes, dependencies, touched surfaces, executor contracts, allowed write paths, materialized payloads, Lich approval decisions, routing behavior, memory state, confirmation payloads, worker dispatch envelopes, or rendered next_steps.md lines. Missing, malformed, unsafe, or memory-contradictory directional context fails closed with an explicit review marker and the existing planner behavior remains unchanged.

The packet is not shaped by memory and does not grant hidden autonomy. It is transport-neutral, deterministic, artifact-backed by the supplied packet identity, and visible only in review/preparation output for human inspection. Directional cognition v0 does not add model calls, executor changes, routing changes, write-root expansion, hidden autonomy, raw memory shaping, or reviewed memory summary shaping.

Governed artifact materialization (governance, 852cbab22093)

Capability

  • Governed artifact materialization produces reviewed documentation updates for artifact, materialization, bundle, lineage, lich, confirmation.
  • Materialized content is generated from deterministic templates, not copied from the operator prompt.

Governance Model

  • The governance artifact remains bounded to approved documentation roots.
  • Lich confirmation remains the authorization boundary before any artifact write is queued.
  • Replay metadata preserves the selected target, content hash, and intent classification.

Execution Flow

  • LegionCommander classifies the objective into artifact intents.
  • The materializer selects a bounded documentation target for each intent.
  • confirmation_runner queues artifact_execute only after Lich approval.
  • artifact_patch_safe writes the approved bundle and records worker result metadata.

Safety Boundaries

  • Runtime code execution policy is not broadened by artifact materialization.
  • Source, test, script, generated API, secret, absolute, and traversal paths remain denied.
  • Architecture impact is limited to the governed artifact lane and its audit metadata.

Current Limitations

  • Generated prose is intentionally template-bounded and does not infer unobserved implementation details.
  • Ambiguous equal-score targets fail closed for human repair instead of guessing.

Future Roadmap

  • Use roadmap artifacts to sequence future expansion after governed documentation is reviewed.