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. Scoped roadmap requests read the canonical adoption document and master view described below. Other legacy document requests first read:

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

Their second read is selected from a fixed allowlist:

  • legacy phase or architecture questions: /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 fixed configured paths.

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.

Canonical roadmap identity and authority

Roadmap relevance is not determined by an exact title match or by a global string alias. AncientOS is the canonical system/project and Luna is its interactive interface. The governed capability portfolio document is the roadmap adoption authority; the master roadmap is a derived operator view. Roadmap context reads these two canonical repository documents through the existing governed reader, ahead of generic operational inventories. Request-scoped roadmap context carries those project, document-role, and provenance relationships explicitly.

Bounded natural references such as AncientOS roadmap, Luna roadmap, Master Roadmap, our roadmap, and the roadmap may resolve to that canonical project relationship. An unrelated named project, missing project scope, or a mixed project reference does not inherit AncientOS authority and fails closed. A retrieved file path or title alone never makes a document authoritative, and Luna must not reject scoped evidence merely because the operator used a different title.

Scoped roadmap questions asking what to do next route through Oracle's existing read-only roadmap evidence synthesis. Earlier general advisory and read-only capability routes defer to the same inquiry predicate; planning and delegation retain their governed routes. Oracle compares the canonical runtime portfolio registry with the adoption-authority document. Consistent active evidence may support an advisory next direction. Missing, invalid, or contradictory evidence produces an explicit reconciliation warning and no concrete next-work selection. Reads are bounded and restricted to the current portfolio table; unreadable or incomplete tables are unknown, not empty. The comparison checks active membership, not lifecycle equality or time-based freshness. It does not certify that either source is up to date. Empty runtime state is not treated as proof that no work is active when canonical document evidence disagrees. This process never adopts work, changes roadmap lifecycle state, approves implementation, or grants execution authority.

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.