Hot context first, transcripts second, live system map for self-knowledge
This is the public model for what happens when NEXO should still remember something from the last few hours, and what the runtime does when the first layer is not enough.
Use recent memory first
nexo_pre_action_context and nexo_recent_context are still the preferred continuity layer. They answer what is actively alive right now.
Use transcript fallback when memory is thin
nexo_transcript_recent, nexo_transcript_search, and nexo_transcript_read let the runtime recover the real conversation instead of pretending it is lost.
Use the system catalog for self-knowledge
nexo_system_catalog and nexo_tool_explain answer what NEXO currently exposes and where that capability comes from.
Why this matters
Before this release, a recent conversation could exist in transcripts but still be unreachable through the public MCP surface. That gap is now closed.
Why the system map stays current
The catalog is generated from canonical sources at read time. It is not a stale copied registry or a hand-maintained markdown list.
What counts as canonical
Core tools from server.py, plugin tools from the plugin registry, skills from the skill registry, scripts from the script registry, crons from the manifest, projects from the atlas, and artifacts from the artifact registry.
$ nexo call nexo_pre_action_context --input '{"query":"wifi digi","hours":24,"limit":6}'
# raw fallback if that is not enough
$ nexo call nexo_transcript_search --input '{"query":"wifi digi","hours":24,"limit":5}'
$ nexo call nexo_transcript_read --input '{"session_ref":"claude_code:session-wifi.jsonl","max_messages":80}'
# ask NEXO what it has right now
$ nexo call nexo_system_catalog --input '{"section":"core_tools","query":"transcript"}'
$ nexo call nexo_tool_explain --input '{"name":"nexo_pre_action_context"}'