AncientOS identity and assistant-name preference
AncientOS is the stable system/product identity. The assistant's display name is an operator preference, with Luna as the default. Discord, Terminal and Web are transports. Models, providers, devices and instances are independent of both system identity and assistant presentation.
Inventory and migration boundary
The pre-change inventory at 3e56949 found identity-related references in 499
tracked files. Classification is semantic, not a replacement rule:
| Class | Meaningful surfaces | Disposition |
|---|---|---|
| A — SYSTEM | Runtime/transport contract descriptions, prompt identity, documentation site titles, system-awareness answers | Describe AncientOS; use canonical runtime contracts rather than assistant-branded type aliases. |
| B — ASSISTANT | Conversational name, prompt presentation, pending-response text, Terminal and Web reply labels | Resolve the request's assistant-name preference; do not hard-code a permanent name. |
| C — DEFAULT | Luna as the unset preference and legacy explicit command vocabulary | Keep Luna as the documented default; retain commands with current consumers. |
| D — TRANSPORT | Discord message IDs, gateway ingress/egress, adapter classes, token handling and transport tests | Keep Discord-specific semantics and names. |
| E — HISTORICAL | Completed reports, evidence, approvals, receipts, ERA plans and stored transcripts | Preserve historical names and bytes. Do not relabel historical speakers. |
| F — MIGRATION-SENSITIVE | Repository path/remote, Compose project, images, containers, service DNS, named volumes, networks, bind mounts, LUNA_* configuration, databases, cookies/CSRF headers, instance markers |
Retain current identifiers; no cosmetic storage or topology migration. |
| G — OBSOLETE | Permanent-Luna prompt instructions and assistant-branded aliases for already-canonical runtime envelopes/results | Remove coupling after updating actual consumers; do not add permanent alias chains. |
| H — UNCERTAIN | Independently deployed OpenWebUI persona, external wake-word integrations, external scripts and clients | Do not claim these are renamed by an AncientOS preference; require their own adoption/migration decision. |
discord-luna remains a historical deployment/repository identifier, not the
product's name. Renaming its directory or Compose project could change volume
selection, mounts, external scripts and service discovery. Existing
luna-memory schema identifiers, luna_core imports, database names, API paths,
browser storage keys and technical component IDs remain stable for their real
consumers. This is not a second set of compatibility aliases.
The pre-change continuity inventory records eight services and their mounts/networks, six SQLite stores, 41 PostgreSQL tables and 48 LifeVault artifact hashes. Validation must compare existing state after rebuilding, allowing ordinary new audit/request records without treating them as loss.
Preference ownership and scope
Use LifeVault's existing artifact store and configured LUNA_MEMORY_ROOT.
An assistant-name preference is a bounded, explicit operator-authored decision,
not inferred biographical knowledge or an automatic memory promotion. It has
no capability, approval, execution or principal authority. No new database,
general persona framework, transport-owned preference cache or memory authority
is introduced.
The key is a verified canonical principal, never a guessed cross-transport association. A currently valid Web session or a configured Discord/Terminal alias must resolve through the existing principal registry. Unknown or revoked identities get the default presentation and cannot change another user's preference. The same verified principal sees the same durable preference across transports. Unlinked identities do not have fabricated parity. Browser chat uses the same bearer session headers or same-origin trusted-device cookie as the Inbox; a signed-in Inbox must not silently become anonymous chat.
The setter must validate a short display name, record decision provenance and replace only that principal's preference atomically. New files follow the existing LifeVault file policy and process umask. Host Terminal readers use the same mounted store; saving also requires filesystem write access. The container-owned deployment may therefore allow host reads while requiring Discord or Web for preference writes. No ownership changes are inferred. It must report persistence failure rather than claim success. System names, instance markers, principals, service/container names, schemas, databases and historical evidence are not mutable through this preference.
Conversation and presentation contract
Direct naming directives include “Call yourself Jarvis”, “Your name is Bob from now on”, “From now on, I'll call you Athena”, and “Go back to Luna”. The grammar accepts names as bounded operands rather than a fixed list of names. Incidental mentions, quotes, hypothetical requests, reports, negation, ambiguous compounds and planning instructions must not set a preference.
Naming uses the shared intent boundary. It is a low-risk explicit preference write, not a route around Lich approval for operational settings or actions. The preference is opaque display data in prompt context; it cannot supply instructions or become a command, role, principal or provider identity.
Current identity questions are grounded in these separate facts: AncientOS is the system; the configured assistant name is its conversational presentation; Luna is the fallback. A historic repository name is never presented as the current architecture. Technical instance-marker inquiries retain the actual configured marker.
Runtime result metadata supplies presentation identity to adapters. Historical transcript labels remain historical. Discord account/server nicknames, OpenWebUI model personas and external device wake words are not dynamically renamed. These are separate technical or externally owned surfaces.
Acceptance boundary
Source tests must cover explicit and incidental language, principal isolation, revocation, durable resolution, concurrent request isolation, restart survival, unchanged technical identities and routing/governance boundaries. Live acceptance must exercise the actual deployed transports and verify state continuity. Source fixtures and a healthy container alone are not acceptance.