Skip to content

Naga-Siren AncientOS Application Boundary

Purpose

Naga-Siren is the first reference AncientOS app pattern: a governed workflow package that consumes AncientOS kernel services. It is not Luna; Luna is the interactive assistant/personality and interface layer over AncientOS.

This document is descriptive only. It does not change runtime behavior, write roots, publish behavior, OAuth handling, credential handling, or autonomy.

Conceptual Model

AncientOS is the governed cognition kernel. It provides the execution boundary, routing discipline, audit posture, approval gates, adapter contracts, and governance surfaces that applications use.

Naga-Siren is a governed workflow app package. It owns the Naga-specific domain model for avatar/persona publishing workflows, while relying on AncientOS substrate capabilities for bounded execution, review, evidence, and external adapter invocation.

X publishing is an external adapter capability. It is not the app itself. Naga-Siren may request the capability after human approval, readiness evidence, duplicate checks, policy checks, and identity validation pass.

Naga/avatar identity is app configuration: a persona/account profile that binds an avatar to allowed destinations and credential references. It is not a Luna or AncientOS runtime identity and it must not contain raw credential values.

Boundary Map

Naga-Siren app-owned domain logic:

  • candidate generation, candidate shape, voice, style, and review text
  • packet semantics specific to Naga review and publishing workflows
  • avatar/persona configuration and account profile mapping
  • Naga-specific publishing policy and quality checks
  • render-origin decisions for Naga approval cards and Naga review packets
  • destination intent for Naga content, subject to Luna capability gates
  • Naga-specific compatibility with canonical luna-naga artifacts

Shared AncientOS kernel primitives, or candidates to become shared primitives:

  • human approval lifecycle gates
  • evidence bundle contracts
  • readiness checks
  • append-only ledgers
  • duplicate blocking and idempotency records
  • adapter capability contracts
  • external mutation preflight and fail-closed result handling
  • audit event redaction and safe rendering
  • packet state transition records
  • governed command routing and allowlisted subprocess execution

External adapter/capability layer:

  • X publishing client and X platform request/response handling
  • platform destination validation
  • credential loading from environment or secret manager references
  • platform-specific network failures, auth failures, and response normalization

Non-Authoritative Manifest Example

The proposed app manifest example is stored at docs/luna/naga_siren_app_manifest.example.yml.

It is intentionally not loaded by runtime code yet. It documents the future shape of an AncientOS app registration without making the manifest authoritative configuration.

Key fields:

  • app_id: naga_siren
  • type: governed_workflow_app
  • owns_artifacts: Naga-Siren domain artifacts
  • requires_capabilities: kernel capabilities the app expects
  • human_approval_required: externally mutating actions that require review
  • allowed_adapters: external adapters the app may request through Luna
  • evidence_required: evidence gates that must exist before publish

Reference App Pattern

Naga-Siren should become the reference implementation for future Luna apps by showing how an app:

  1. declares its owned artifacts and domain vocabulary
  2. requests shared AncientOS capabilities instead of implementing unchecked runtime authority
  3. keeps external adapter access behind approval, readiness, evidence, and duplicate checks
  4. stores identity and credential references as app configuration without storing secrets
  5. emits replayable artifacts that can later be generalized into shared Luna primitives

Future Refactor Notes

Candidate refactors should be behavior-preserving and incremental:

  • Extract approval lifecycle gates into a shared AncientOS app-runtime module after at least one second app needs them.
  • Generalize readiness checks and duplicate blocking into capability evidence contracts.
  • Define a typed app manifest schema once runtime registration exists.
  • Move append-only publish ledgers behind a shared ledger primitive while preserving Naga-Siren artifact compatibility.
  • Keep Naga-Siren voice, style, candidate, packet, and publishing policy logic app-owned.
  • Keep X publishing as a capability adapter; do not fold it into the Naga-Siren app identity.

Deferred work:

  • No runtime manifest loader is added here.
  • No write roots are widened.
  • No live publish or OAuth behavior is changed.
  • No autonomy is introduced.

Migration Note

This document changes conceptual taxonomy only. It does not rename docs/luna/*, luna-naga, discord-luna, Python modules, commands, environment variables, persisted artifacts, API routes, or Docker services.