AncientOS Target Repository and Product Architecture

Status: Architecture recommendation for review
Scope: Product boundaries, repository topology, naming, release boundaries, and migration principles
Not in scope: Repository inspection, implementation instructions, code, detailed APIs or schemas, deployment scripts, or Codex goals

Executive recommendation

AncientOS should be organized as a small multi-repository product family, not as one universal monorepo and not as one repository per named subsystem.

The recommended durable boundaries are:

ancientos-core — the governed AncientOS runtime, its first-party clients/shell, canonical contracts, and AncientOS-owned deployment definition.
One repository per substantial, independently evolving AncientOS app, beginning with Naga Siren, Meeting Intelligence, Media Manager, and Home Automation Manager. Very small or inseparable domain products may remain grouped until independence is operationally useful.
ancientos-ops — host-global and cross-product operations, such as the machine-wide reverse proxy and shared Homepage configuration.
Optional ancientos-apps monorepo only for very small, tightly related apps that genuinely share a release and maintenance lifecycle. It should not be the default merely to reduce repository count.

Chen is AncientOS Core. It is the core domain/application administration substrate through which AncientOS can register, supervise, coordinate, inspect, or administer bounded domain products. Chen remains even if every optional app is removed. “Chen-managed” is therefore a strong signal that the managed thing is an app, but it is not a classification rule: Chen may also administer integrations, adapters, shared services, or infrastructure-facing resources.

x-feed-worker is a likely app under the clarified product intent, but the name still leaves an important boundary question. It should be its own app only if it represents a coherent feed-acquisition/domain capability with its own purpose, state, policy, and lifecycle. If it is merely Naga Siren's execution worker, it belongs inside the Naga Siren app. If it is a thin X provider adapter, it is an integration. Chen administration alone cannot settle which of these is true.

The current discord-luna repository should eventually become ancientos-core while preserving its Git history. The internal names Luna, Rubick, Lich, Keeper, Oracle, Zeus, Clockwerk, Io, Chen, Earthshaker, Beastmaster, and LifeVault should remain wherever they still denote valid responsibilities. Product correction does not require a wholesale vocabulary rewrite.

The governing principle is:

Repository boundaries should follow product authority, independently releasable capability, and operational ownership—not names, processes, containers, languages, or present filesystem accidents.

1. Definitions

1.1 AncientOS Core

AncientOS Core is the minimum coherent governed runtime that preserves AncientOS's identity as an operator-controlled AI operating environment. It owns the canonical semantics that must remain singular across every transport and extension:

operator and instance identity;
authority, approval, policy, and fail-closed behavior;
action/proposal lifecycle and execution brokerage;
evidence, provenance, and audit meaning;
capability discovery and invocation semantics;
memory/cognition substrate and its canonical integration semantics;
orchestration and routing across capabilities;
transport-neutral contracts and shared client semantics;
runtime truth, health, and governed inspection;
extension/app trust and lifecycle boundaries;
domain/app administration semantics, owned by Chen;
the primary operator entry surface needed to reach and govern the system.

Core is not defined as “everything important,” “everything maintained by Nathan,” “everything always running,” or “everything with a Dota name.” A component belongs in Core when removing or independently substituting it would eliminate or fracture a defining AncientOS invariant.

Some core capabilities may be disabled or backed by replaceable implementations. “Core” describes ownership of semantics, not a requirement that every service run in every profile.

1.2 AncientOS App

An AncientOS App is an independently meaningful capability product that uses AncientOS through governed, stable contracts but does not own or redefine AncientOS's canonical semantics.

An app:

has a coherent purpose an operator can understand apart from the runtime;
may be installed, removed, upgraded, or unavailable while AncientOS remains AncientOS;
declares its capabilities, dependencies, permissions, evidence behavior, and compatibility conceptually;
consumes identity, governance, memory, scheduling, evidence, and transport facilities rather than cloning them;
may contain multiple internal services or workers;
may be administered through Chen without Chen becoming part of the app;
can have its own roadmap and release cadence;
fails without corrupting or bypassing Core.

An app is a product boundary, not necessarily a process boundary. A worker, adapter, database, UI panel, and scheduled job may collectively form one app.

1.3 Chen

Chen is the Core-owned administration substrate for bounded application and domain behavior. Chen gives AncientOS a stable place to understand and administer domain products without absorbing their domain logic into Core.

Conceptually, Chen may coordinate app lifecycle, visibility, status, configuration intent, bounded domain operations, and relationships to Core governance and capability surfaces. This does not make Chen a universal container for all non-Core behavior, nor does it authorize Chen to duplicate Lich, Rubick, Oracle, Zeus, identity, or app business logic.

The distinction is:

Chen owns the general semantics of administering domains/apps.
Each app owns its purpose, domain behavior, app-specific state, and app-private integrations.
Other Core components retain their canonical responsibilities. Chen uses or coordinates them; it does not supersede them.

Chen is therefore analogous to a durable control/administration plane inside AncientOS, while Chen-managed apps are independently meaningful domain products. If one app disappears, Chen and AncientOS remain. If Chen disappears, AncientOS loses a general platform capability for coherently administering those domains.

1.4 Integration

An integration is a bounded adapter between AncientOS or an AncientOS App and an external system, device, protocol, or provider. It translates and constrains access; it is not automatically a standalone product.

An integration normally belongs with its sole consumer. It becomes independently packaged only when several apps/core capabilities consume it, it has materially distinct credentials or risk, or it requires independent compatibility and release management.

1.5 AncientOS-owned deployment infrastructure

AncientOS-owned deployment infrastructure is the configuration required to instantiate, connect, configure, and operate one AncientOS product boundary. Examples conceptually include service composition, AncientOS-specific routing, health wiring, migrations, default policy configuration, and product-local observability.

It belongs with the product whose release it realizes because a compatible release should carry its own deployable definition.

1.6 Host-global infrastructure

Host-global infrastructure configures or operates the host, network edge, or shared platform for multiple products. Examples include the machine-wide reverse proxy, shared landing page, backup orchestration, host monitoring, shared network policy, and base host provisioning.

It belongs in ancientos-ops, even when AncientOS is one of its consumers. AncientOS-specific fragments may be sourced from Core, but host-wide composition and policy remain ops-owned.

1.7 Generated/runtime state

Generated/runtime state is mutable output produced by running, building, testing, or observing the system rather than authored product definition. It includes databases, vector indexes, caches, logs, reports, secrets, downloaded models, media, queues, temporary files, generated artifacts, and local environment overrides.

It should not be treated as source code or migrated into a source repository merely to “keep everything together.” Durable state needs an explicit backup/retention strategy; most ephemeral state needs exclusion and reproducibility.

2. Classification framework

The user's disappearance test is a strong first filter, but it needs companion tests. Apply these in order.

Test	Core signal	App signal	Integration signal	Infrastructure/state signal
Identity test	Defines AncientOS itself or a canonical invariant	Delivers a separable outcome	Connects a boundary	Runs/hosts/persists something
Disappearance test	Removal fractures identity, governance, cognition, or canonical routing	Removal loses one capability only	Removal loses one external connection	Removal affects deployment/operation, not product semantics
Authority test	Decides or records canonical permission/policy	Requests and consumes authority	Enforces translated provider constraints	Supplies secrets/network/process controls
Substitution test	Competing implementations must preserve one core contract	Can be replaced by another app	Provider adapter can be replaced	Deployment mechanism can change without product redesign
Audience test	Needed by the platform and multiple capabilities	Coherent domain outcome, whether or not directly user-facing	Meaningful mainly to a consumer	Meaningful mainly to operators/build/runtime
Lifecycle test	Must evolve with core semantics	Can version and release independently	Tracks provider/protocol changes	Tracks hosts and deployment environments
Failure test	Failure may make AncientOS unable to preserve a defining platform capability	Core remains coherent and failure is contained	External capability becomes unavailable	Product may be down but semantics remain defined
Data test	Owns canonical system records	Owns app-domain records	Owns sync cursors/provider mappings	Produces logs, caches, databases, backups, secrets
Chen test	Defines or supplies Chen's general administration semantics	Is administered as a bounded domain product	Is administered as a connection/provider	Is merely deployed or observed through Chen

Classification rules

Canonical semantics have one owner. Identity, governance, evidence meaning, capability registration, and transport neutrality cannot be independently reimplemented by apps.
Classify a cohesive capability, not each executable. Workers and sidecars inherit the boundary of the product they serve unless demonstrably reusable.
External does not mean app. A thin Nest, X, Plex, or Google adapter is usually an integration.
Always-on does not mean core. A continuously running feed worker may still be app-internal.
Core may define a contract without containing every provider. Provider implementations can be optional integrations.
Deployment is not product logic. Co-location in a compose file does not establish product ownership.
Runtime data is not infrastructure definition. Back up durable data, but do not confuse it with the configuration that creates the service.
When uncertain, keep the component in its current repository until its authority and consumers are understood. Ambiguity is not a reason to move code.
Chen-managed is evidence, not a verdict. Ask what independent purpose, state, lifecycle, and failure boundary the managed unit has.

Refining the disappearance test

“If this disappeared, would AncientOS still fundamentally be AncientOS?” is necessary but insufficient. Some Core capabilities may be optional in a particular deployment, dormant, replaceable behind a Core contract, or not yet implemented. Conversely, an app may be operationally essential to Nathan while remaining conceptually optional to AncientOS.

Use three versions of the question together:

Semantic disappearance: Would AncientOS lose a defining invariant or general platform responsibility?
Instance disappearance: Can a valid AncientOS installation omit or disable this implementation while retaining that responsibility through another implementation or inactive contract?
Domain disappearance: Would removal eliminate only one bounded purpose while canonical governance, cognition, identity, and administration remain intact?

Core classification follows ownership of the invariant, not mandatory process presence. Apps normally satisfy the third condition. Integrations remove access to a provider rather than removing the whole domain product.

3. Luna, AncientOS, and Home

3.1 Luna

AncientOS is the system/product. Luna is its primary conversational persona and first-class interaction/orchestration component. Luna can appear through Discord, Terminal, Web, Android, and future clients without being identical to any one transport.

Legitimate Luna concepts should remain named Luna: persona behavior, Luna conversation/runtime surfaces, Luna-specific UX, and historically authoritative material whose scope is clear. Repository and outward product naming should change where discord-luna falsely implies that Discord is the product or boundary.

3.2 AncientOS Home

AncientOS Home is best treated as a core-owned shell with extensible app contributions, not as an ordinary app.

The shell belongs in Core because it is the operator's product-level entry point, presents canonical system state, reaches Luna and Lich, and mediates discovery/navigation across apps. Its minimum function should remain useful with no optional apps installed.

Individual app pages, widgets, shortcuts, and status panels belong to their apps conceptually and should contribute through contracts. A generic third-party dashboard used to host links is deployment tooling, not AncientOS Home itself. This distinction permits the current implementation to evolve without forcing a premature code split.

4. Likely classification of known components

These classifications are conceptual hypotheses, not claims about current implementation.

Component	Likely boundary	Reason / caveat
Luna	Core	Primary persona, intent interpretation, and coherent operator interaction across transports. Transport adapters remain separable inside Core.
Rubick	Core	Canonical capability registry/awareness and governance metadata must be shared by all apps and transports.
Lich	Core	Owns canonical bounded authorization semantics. It cannot be app-optional.
Oracle	Core	Canonical operational truth and preflight are required for trustworthy governed execution. Provider-specific probes may be integrations.
Zeus	Core	Evidence and supervisory meaning are cross-cutting governance invariants. Evidence collectors may be pluggable.
Clockwerk	Core service	Canonical scheduled/watcher semantics belong in Core; particular scheduled jobs belong to their app. If it proves to be only generic infrastructure, revisit after inspection.
Io	Core if it owns execution brokerage	The canonical path from authorized intent to bounded execution is core. Individual executors/providers are integrations or app internals. Its exact current responsibility must be confirmed.
Chen	Core	Owns the general administration substrate for bounded apps/domains. Chen survives app removal and must consume—not duplicate—identity, Rubick, Lich, Oracle, Zeus, Clockwerk, and Io semantics.
Keeper	Core service, with a possible replaceable backend	Durable operator work/task semantics appear cross-cutting. If Keeper is merely one optional task-management product rather than a system primitive, it could become an app; authority and consumer analysis should decide.
LifeVault / memory	Core substrate	Durable memory/cognition and provenance are defining system capabilities. PostgreSQL/pgvector are implementation/deployment dependencies, not themselves Core product components.
Operational Router	Core	Preserves canonical routing and governance across capabilities.
Identity	Core	Canonical operator and instance identity cannot be delegated to an app. External identity providers are integrations.
Transport contracts	Core	Discord, TUI, Web, and Android must share semantics rather than own them.
Discord adapter	Core transport adapter	First-party route to Luna/Core; removable from a deployment without ceasing to be core-owned source.
Terminal/TUI	Core client	First-party administrative/operator access to canonical runtime.
Web Luna/Lich UI	Core client	Exposes canonical runtime and governance semantics.
Native Android client	Core product client, likely separate repository later	It is a transport, not an app in the extension sense. Separate repository may be justified by toolchain and release lifecycle while remaining part of the Core product family.
AncientOS Home	Core shell	Product-level launcher and system surface; app contributions remain app-owned.
Earthshaker	Likely Core broker, conditional on responsibility	Core if it is AncientOS's general two-way nervous system for discovering, addressing, and interacting with the physical/device environment. Home Automation Manager would consume it. If Earthshaker instead owns home-specific rules and outcomes, that domain behavior belongs in the app.
Beastmaster	Likely Core device/entity substrate, conditional on responsibility	Core if it owns general device/entity inventory, identity, presence, and capability semantics used beyond home automation. Device-specific management or home-domain behavior belongs in an app or integration.
LegionCommander	Core development-governance component or first-party tool	It participates in the canonical governed development lifecycle. It may be packaged separately operationally without becoming an AncientOS App.
Codex integration	Integration	Codex is an external implementation actor. AncientOS owns the governed development contract, not Codex itself.
Rote substrate	Core	Transferable cognition semantics, provenance, trust, applicability, and integration policy affect AncientOS's cognition model. Specific Rote-provided capabilities may be apps/content.

4.1 Naga Siren

Likely AncientOS App. It appears to deliver a bounded social/feed-oriented capability that AncientOS could discover and use while remaining coherent without it. Naga Siren should consume Core identity, governance, scheduling, memory/evidence, and capability contracts. Its provider-specific X connection is an integration within the app unless shared broadly.

4.2 x-feed-worker

Provisional AncientOS App, subject to a domain-coherence test. The clarified intent treats it as a likely Chen-managed domain product. That classification is justified if it independently acquires, normalizes, retains, or publishes feed cognition for multiple AncientOS consumers and has its own policy, status, and lifecycle. In that case, “worker” is an implementation-flavoured name for an app and a later product-facing name may be worth considering.

If it exists only to execute Naga Siren's ingestion pipeline, it is an internal worker in the Naga Siren repository. If it merely translates the X provider boundary and owns little domain behavior, it is an integration. Repository inspection should test consumer count, data ownership, operator-visible purpose, and independent failure/release behavior rather than assume the answer.

4.3 Meeting Intelligence

Likely AncientOS App. Meeting capture, transcription, analysis, retrieval, and follow-up form a coherent optional outcome with app-domain data and an independent roadmap. It should rely on Core governance, identity, memory/cognition integration, evidence, and task/capability contracts. Calendar, conferencing, microphone, transcription-model, and messaging connectors are integrations owned by the app unless reused platform-wide.

4.4 Media Manager

AncientOS App. Media discovery, acquisition, library administration, playback coordination, policy, and operator-facing media outcomes form a bounded product domain. Removing it does not alter AncientOS's canonical identity, governance, cognition, or app administration.

Media Manager should own media-domain workflows and state. Plex, qBittorrent, indexer, metadata-provider, streaming-device, and similar connections are integrations or app-internal services unless independently shared. Core Lich/Io/Oracle/Zeus semantics govern actions and evidence; Chen administers the app; neither should absorb media logic.

4.5 Home Automation Manager

AncientOS App. It owns home-specific automations, scenes, household policy, UI, and domain outcomes. AncientOS remains AncientOS if it is absent.

The important exception is the general physical-world substrate. Earthshaker and Beastmaster may remain Core if their responsibilities are domain-neutral device communication, discovery, identity, or capability representation. Nest, Home Assistant, Matter, Apple TV, and vendor-specific connectors are integrations. Home Automation Manager composes those Core facilities and integrations into home-domain behavior.

4.6 Chen-managed does not mean app by itself

Examples of exceptions include:

a Chen-visible X credential/adapter used only to connect a provider: integration;
a Chen-inspected PostgreSQL service: deployment dependency/infrastructure;
a Chen-administered capability registry entry: Core state owned by Rubick;
a Chen-controlled scheduling resource: shared Core capability owned by Clockwerk;
a Chen-managed device adapter with no independent domain outcome: integration;
a complete media or home-automation domain with its own policies and state: app.

5. Recommended repository topology

5.1 Target

AncientOS organization/account
├── ancientos-core
├── ancientos-app-naga-siren
├── ancientos-app-x-feed             (only if domain-coherence test passes)
├── ancientos-app-meeting-intelligence
├── ancientos-app-media-manager
├── ancientos-app-home-automation
├── ancientos-ops
├── ancientos-android                 (when native work becomes substantial)
└── ancientos-contracts               (defer; create only if independent consumers require it)

This remains a modest product-family topology: repositories are added for substantial domain products, not for every process or connector.

ancientos-core should contain Core runtime source, first-party server-side transports, Home shell, core documentation, tests, and deployment definitions needed to instantiate Core. It may initially also contain shared contracts to permit atomic evolution.

App repositories should contain the complete cohesive app: internal services, workers, migrations, tests, app documentation, integrations used only by that app, and its product-local deployment definition. Chen's Core-side administration behavior stays in Core; any app-side declaration or contribution stays with the app.

ancientos-ops should contain host-global composition and configuration. It may reference published/deployed Core and app releases but should not become their source-code home.

ancientos-android is a product client, not an AncientOS App. A separate repository becomes useful when native build tooling, mobile releases, and code ownership are independently substantial. Until then, designs/contracts can remain with Core without creating an empty repository.

ancientos-contracts should not be created initially. Keep contracts in Core and let apps consume versioned releases. Extracting them too early creates synchronized changes across repositories and makes experimentation harder. Create the repository/package only when two or more independent repositories need a lightweight release cadence decoupled from Core, with an explicit compatibility obligation.

5.2 Mixed repository rule for a growing app ecosystem

Use one repository per substantial, independently meaningful and independently evolving app. This aligns Git history, rollback, issues, releases, and backup with a product boundary Nathan can recognize: “restore Media Manager” is clearer than “restore the repository containing some apps.” Naga Siren, Meeting Intelligence, Media Manager, and Home Automation Manager are strong individual-repository candidates.

A shared ancientos-apps monorepo or app collection is appropriate only for incubating or small apps that:

are small and maintained together;
share most tooling and release coordination;
frequently require atomic cross-app changes;
do not warrant separate access, archival, or recovery;
remain easy to understand as one collection.

Use a mixed rule:

Individual repository: substantial domain, meaningful data, independent releases, distinct risk/dependencies, or independent recovery value.
Apps collection: small/incubating domain products with common tooling and synchronized maintenance.
Parent app repository: subordinate worker, UI, or adapter serving one app.
Core repository: Chen itself and canonical app/runtime contracts.

Do not put Naga Siren, Meeting Intelligence, Media Manager, and Home Automation Manager together merely because all are Chen-managed. Their domains, dependencies, risks, and recovery needs differ. Do not create a repository for every worker or connector either. x-feed-worker is the boundary test case: keep it with Naga Siren until evidence demonstrates a truly independent domain product; if that evidence already exists, give it ancientos-app-x-feed rather than preserving an infrastructure-sounding product name forever.

5.3 Recommended top-level filesystem

On the host, use a neutral parent directory rather than making one repository the parent of others:

~/ancientos/
├── core/                    # checkout of ancientos-core
├── apps/
│   ├── naga-siren/          # checkout of ancientos-app-naga-siren
│   ├── x-feed/              # only if independently classified
│   ├── meeting-intelligence/# checkout of ancientos-app-meeting-intelligence
│   ├── media-manager/
│   └── home-automation/
├── clients/
│   └── android/             # only when separate repository exists
├── ops/                     # checkout of ancientos-ops
├── data/                    # durable runtime state; not a source repository
├── backups/                 # local backup staging/metadata, governed separately
└── secrets/                 # host-managed, tightly controlled, never committed

Paths are conceptual. Existing container volumes and service paths should not be moved simply to make the tree look tidy. The later repository audit must map dependencies before any filesystem change.

Within each product repository, prefer stable responsibility-based top-level names over a directory per process:

docs/  src/ or services/  clients/  integrations/  contracts/  deploy/  tests/  tools/

Not every repository needs every directory. Generated reports and runtime state should live outside source or in clearly ignored local paths.

6. App-to-Core contract model

Without specifying APIs or schemas, the conceptual contract should cover:

identity: who the operator, instance, app, and requesting principal are;
capability declaration: what the app can inspect, propose, or execute;
authority: which operations are read-only, pre-authorized, or Lich-governed;
action lifecycle: how bounded proposals, approvals, execution, and outcomes relate;
evidence: what the app must report before and after actions;
data/cognition: how app knowledge may be read, contributed, retained, or removed;
events and scheduling: how apps observe changes or request Clockwerk activity without inventing parallel authority;
health and inspection: how Core can truthfully describe availability and degradation;
UI contribution: how app surfaces appear in Home/clients without embedding app business logic in the shell;
compatibility and failure: how incompatible or unavailable apps fail explicitly and safely.

Core should provide a narrow “platform waist”: stable meanings with replaceable transports and implementations. Apps may extend vocabulary and domain behavior but may not claim canonical authority, identity, or evidence semantics.

7. Versioning and release strategy

Core

Core receives its own version and release history. A Core release represents a coherent set of canonical semantics and deployable components. Semantic versioning is a useful operator-facing convention:

major: intentional breaking change to app/transport compatibility or canonical semantics;
minor: backward-compatible capability or contract addition;
patch: compatible repair.

Early development can remain 0.x, where minor versions may break compatibility, provided releases state this clearly.

Apps

Each app versions independently. An app release declares a supported Core compatibility range and any required optional capabilities. Apps should not be forced to match Core's version number.

Integrations

An app-private integration releases with its app. A shared provider integration may version independently only when that separation pays for its coordination cost. External provider changes should not force an AncientOS Core release unless the canonical contract changes.

Deployment

Deployment revisions are not product versions. Ops records which exact Core/app releases and configuration revisions are deployed on a host. Rollback should be describable in terms Nathan can recognize: restore the previous Core release, app release, ops revision, and compatible data backup.

Compatibility expectations

Core should publish a bounded compatibility promise, not “latest works with latest.”
Apps declare minimum/maximum supported Core contract ranges.
Core additions should generally be backward-compatible within a major line.
Breaking transitions need explicit migration windows or paired releases.
An incompatible app must be refused or degraded visibly, never silently invoked through an uncertain contract.
Data evolution and rollback compatibility must be treated separately from code compatibility.

8. Treatment of the current ops repository

Use a simple ownership test: does this configuration instantiate one product, or govern the shared host?

Likely to move conceptually into ancientos-core/deploy:

Core service composition and product-internal networking;
Core-specific health relationships;
AncientOS-specific default configuration;
Core-local proxy fragments or route declarations intended to travel with the release;
product-local observability and data migration definitions.

Likely to remain in ancientos-ops:

the host-wide Caddy entry point and certificate/network policy;
Homepage as a shared host/service dashboard and its cross-product catalogue;
host provisioning and hardening;
backup orchestration across AncientOS and non-AncientOS services;
shared monitoring, DNS, Tailscale, storage, and network-edge configuration;
the inventory selecting which Core and app releases run on this host.

Likely to move into an app repository:

app-specific service composition;
app-only scheduled workers;
app-specific routes, storage declarations, and integration configuration templates.

The target is composition rather than duplication: product repositories own deployable product definitions; ops owns the host overlay that assembles them.

9. Naming strategy

Repository names

Use lowercase hyphenated names with the product family first:

ancientos-core
ancientos-app-naga-siren
ancientos-app-x-feed (only if independently classified)
ancientos-app-meeting-intelligence
ancientos-app-media-manager
ancientos-app-home-automation
ancientos-ops
ancientos-android

The explicit app- prefix makes GitHub lists self-explanatory. Existing app names can remain recognizable. Avoid generic repository names such as core, ops, or backend when viewed outside the local folder.

Internal names to preserve

Keep names that still express a legitimate bounded responsibility:

Luna, Lich, Rubick, Keeper, Oracle, Zeus, Clockwerk, Io, Chen, LifeVault;
LegionCommander and established governance vocabulary;
existing durable identifiers, database namespaces, environment keys, service names, import paths, and historical document titles unless a concrete collision or false behavior makes a rename necessary.

Earthshaker and Beastmaster should also remain until their responsibilities—not their names—are classified.

Rename outward identities that actively mislead:

repository/project display identity from discord-luna to ancientos-core;
user-facing descriptions that call the whole system Luna or imply Discord is the platform;
broad documentation headings where “Luna” mistakenly denotes all of AncientOS.

Do not conduct a global textual replacement of luna with ancientos. Compatibility aliases may be preferable for long-lived technical identifiers.

10. Migration philosophy

Architecture precedes movement. First agree on boundaries; then audit repository/runtime truth.
Preserve the existing Git lineage. Rename the current GitHub repository in place where practical so commits, issues, tags, and remote redirects remain connected.
Move cohesive history, not isolated files, when extracting apps. Use history-preserving filtering/subtree techniques only after the target boundary is proven.
Separate renaming from behavioral change. A boundary migration should be reviewable without simultaneously redesigning services.
Prefer compatibility bridges. Preserve aliases, environment names, service names, and paths temporarily when changing them would multiply risk.
Do not move runtime data as source. Plan data paths, backup, cutover, and rollback independently.
Extract one boundary at a time. A mature, well-contained app is a cleaner first extraction than conditional core candidates such as Earthshaker or the ambiguous x-feed-worker.
Prove the contract before physical separation. A component that cannot yet interact with Core through an explicit boundary is not ready for its own repository.
Keep deployments recoverable throughout. Every slice should identify the last known working revision and a data-safe rollback boundary.
Accept harmless historical residue. Old commit messages, internal identifiers, and document titles are history, not defects.
Avoid aesthetic churn. Filesystem neatness alone does not justify risky moves.
Update recovery documentation with each boundary. Nathan's primary Git goals—history, recovery, off-machine backup—must remain easier after every change.

11. Risks and tradeoffs

Over-splitting

cross-repository changes require coordinated branches, releases, and reviews;
contract changes become slower and can strand incompatible versions;
local development and backup become harder to understand;
small workers gain unnecessary release machinery;
duplicated tests, tooling, documentation, and CI accumulate;
Git history becomes harder to search across the whole system;
an operator may not know which repository owns a failure.

Mitigation: split only at a coherent product boundary with an independent lifecycle and a tested Core contract. Keep shared contracts in Core initially.

Over-consolidating

optional apps become entangled with Core releases;
provider-specific credentials and dependencies broaden Core's risk surface;
unrelated failures and changes increase regression scope;
the meaning of “Core is healthy” becomes unclear;
app experiments can destabilize governance/runtime work;
recovery requires restoring a much larger coupled unit.

Mitigation: keep optional domains and their private integrations outside Core; keep host-global composition outside product repositories.

Recommended balance

The expanded target is a mixed, product-per-repository family, but it need not be created all at once. Core, Ops, and each proven substantial app become separate repositories. Naga Siren, Meeting Intelligence, Media Manager, and Home Automation Manager likely meet that threshold. Keep x-feed-worker with Naga Siren until evidence demonstrates independent domain ownership; then promote it to its own app repository. Defer Android, shared-contract, and general apps-monorepo repositories until their actual lifecycle exists.

12. Decision register

ID	Decision	Status	Rationale
D-01	AncientOS is the product/system; Luna is a first-class persona/runtime component.	Settled principle	Supplied architecture packet and user direction.
D-02	Use a small multi-repository product family.	Recommendation	Balances isolation, recovery, and operator comprehensibility.
D-03	Rename `discord-luna` to `ancientos-core` in place when migration is authorized.	Recommendation	Corrects public boundary while preserving history.
D-04	Core owns canonical identity, governance, evidence, cognition, routing, and transport semantics.	Recommendation grounded in settled principles	These meanings must remain singular.
D-05	AncientOS Home is a Core shell with app-contributed surfaces.	Recommendation	It is the system entry point without owning every app.
D-06	Chen is Core; it owns general domain/app administration semantics.	Operator-settled direction	AncientOS retains Chen when individual apps are removed.
D-07	Chen-managed is a strong app signal, not an absolute classification rule.	Operator-settled direction	Chen may also administer integrations, infrastructure, and shared Core capabilities.
D-08	Naga Siren is an app.	Provisional classification	Coherent optional capability. Verify current responsibility.
D-09	Meeting Intelligence is an app.	Provisional classification	Coherent optional capability and data lifecycle.
D-10	Media Manager is an app.	Provisional classification	Coherent optional media domain with its own workflows and state.
D-11	Home Automation Manager is an app.	Provisional classification	Owns optional home-domain outcomes while using shared physical/device substrate.
D-12	`x-feed-worker` is a likely app but must pass the independent-domain test.	Unresolved classification	It may instead be a Naga Siren worker or thin X integration.
D-13	Keep app-private integrations with their app.	Recommendation	Minimizes coordination and avoids false platform abstractions.
D-14	Product-local deployment belongs with the product; host-wide composition belongs in `ancientos-ops`.	Recommendation	Separates deployability from host governance.
D-15	Keep shared app contracts and Chen in Core initially.	Recommendation	Preserves canonical semantics and avoids premature release coupling.
D-16	Preserve valid Dota names and durable internal identifiers.	Recommendation	Product naming correction should not trigger high-risk churn.
D-17	Each mature app versions independently against a declared Core compatibility range.	Recommendation	Enables safe optionality and rollback.
D-18	Generated/runtime state stays outside source repositories.	Recommendation	Source history and runtime backup have different lifecycles.
D-19	No physical move occurs until repository/runtime audit resolves authority, consumers, data, and deployment coupling.	Recommendation	Prevents architecture-by-guesswork.

13. Unresolved questions before repository inspection

These are product/architecture questions that should be answered or explicitly carried as hypotheses before Codex audits the live repositories:

Keeper: Is durable task management a defining platform primitive, or one replaceable task app backed by a smaller Core work/action contract?
Chen boundary: Which administration semantics are genuinely general, and which present Chen behavior is actually domain logic that should move with an app?
Earthshaker: Is it a general canonical environment/device broker consumed by Home Automation Manager and other domains, or does it currently contain home-specific behavior?
Beastmaster: Does it own platform-wide entity/device identity and discovery, or a bounded device-management product?
Io: What exact canonical responsibility does the name denote today—execution brokerage, inter-service messaging, or something else?
Clockwerk: Does it define shared scheduling/watch semantics, or is it an implementation service that could be substituted behind a Core contract?
Naga Siren and x-feed-worker: Does the worker have independent consumers, policy, state, failure handling, and operator-visible outcomes, or is it subordinate to Naga Siren/a thin provider adapter?
Media Manager: Which existing media components collectively form the app, and which are external integrations or host-global services?
Home Automation Manager: Where does home-domain behavior end and the general Earthshaker/Beastmaster substrate begin?
AncientOS Home: Is its present code a true AncientOS shell or primarily configuration for the generic Homepage product? The concepts may currently be conflated.
Contracts: Which contract surfaces already have two or more independent consumers, and which still change atomically with Core?
Data ownership: Which durable stores contain mixed Core and app data? Repository extraction must not precede a conceptual ownership map.
Deployment ownership: Which ops configuration is host-global, which is AncientOS-specific, and which is app-specific?
Shared credentials and network trust: Which services share secrets or privileged network positions that would frustrate isolation?
Development governance: Are LegionCommander and Codex-facing facilities runtime Core, a separately deployable first-party toolset, or both under different profiles?
Client boundary: When should Android's independent toolchain justify ancientos-android, and what core-owned client semantics must it share?
Documentation authority: Which documents are product-wide, component-specific, historical-but-authoritative, or generated reports?
Release maturity: Does AncientOS need formal numbered releases now, or should commit-pinned deployments precede the first stable compatibility promise?

14. Audit rules for later Codex use

The following concise rules can govern a later read-only repository audit:

Do not classify by directory, process, container, language, or Dota name alone.
Identify the canonical owner of identity, authority, evidence, cognition, capability, routing, and transport semantics; each must have one Core owner.
Treat Chen as Core and map its general administration responsibilities separately from every Chen-managed domain's business logic.
Apply the semantic-disappearance, instance-disappearance, domain-disappearance, authority, substitution, lifecycle, failure, consumer, and data-ownership tests to every candidate boundary.
Treat Chen management as evidence of app-ness, never as sufficient proof; explicitly test for integration, infrastructure, and shared-Core exceptions.
Treat a cohesive app as the unit; keep app-only workers, UIs, migrations, and integrations with it.
Treat external-system adapters as integrations unless they form a coherent independent domain capability or serve multiple product boundaries.
Put product-local deployment definitions with the owning Core/app repository; leave host-wide composition in Ops.
Inventory generated/runtime state separately from authored source and separately identify durable backup obligations.
Map imports, calls, shared storage, credentials, network privilege, deployment coupling, tests, and release coupling before recommending any move.
For x-feed-worker, prove independent purpose, consumers, data, policy, lifecycle, and recovery before recommending its own repository.
Separate Home Automation Manager's domain logic from any general Earthshaker/Beastmaster physical-world substrate.
Do not recommend extraction until an explicit Core/app contract already exists or can be stated without duplicating canonical semantics.
Prefer renaming repositories in place and history-preserving extraction; never propose wholesale copy-and-delete migration by default.
Preserve legitimate internal Luna/Dota vocabulary and compatibility-sensitive identifiers unless a specific defect justifies change.
Mark every conclusion as repository fact, architecture decision, recommendation, or unresolved question.
Produce a proposed move map and dependency map, but no mutations or implementation plan until the operator approves the architecture findings.
Optimize the final topology for understandable backup and recovery: a human should know which repository and data backup restore each product boundary.

15. Acceptance statement

The target is not “many repositories.” The target is a comprehensible AncientOS product family in which:

Core remains a single governed system;
Luna remains Luna;
optional apps can evolve without redefining AncientOS;
integrations remain close to their real owners;
deployment definitions travel with products;
host-global operations remain visibly separate;
runtime state has explicit retention rather than accidental Git history;
and every repository corresponds to a unit Nathan can understand, back up, restore, and reason about.

This architecture is ready to guide a later read-only repository and deployment audit, after the unresolved responsibility questions are either decided or deliberately tested against repository truth.

Source basis

This report is grounded in the supplied AncientOS — Curated Architecture Packet and the operator's subsequent clarification that Chen is Core and that Chen-managed domains are strong app candidates. It treats those sources as conceptual authority while making no claims about current repository structure, implementation, deployment state, schemas, or test coverage.