LisaOS Map

Last Updated: 2026-07-04 (Dispatch 2290 — LisaOS Full-System Audit Campaign, Phase 4 propagation, companion to the regenerated CS.AK.LISA.TechSpec.LisaOSArchitecture. §6 Skills: reconciled against the authoritative registry (tally 95→96 as of 2026-07-04); restored 19 genuine skills that had drifted out of the map (checkpoint, system-init, mac-disk-cleanup, gws-profile, hermes-dispatch, agent-tune, uat-bidirectional-probe, drafting-comms-guides, invoice, brandkit, chatgpt-image-designer, nano-banana-designer, seedance-designer, pixellab-ref-prep, impeccable, site-map-generator, design-system-ingest, feature-scope, code-optimise); re-annotated simplify as a Claude Code built-in (not a custom skill — not restored). §8 Automation: reconciled against installed launchd plists — added 7 undocumented jobs (identified by function in §8), retired a client-recon job (uninstalled, retainer wound down) and lisa-memorygateway (stale — gateway is VPS-only systemd the gateway systemd unit). Data Registries appendix skill tally 95→96. Change Impact Matrix §9b: governed by existing "Any skill created" (HIGH) + automation rows — no new matrix row required. Source: plan lisaos-full-system-audit. Prior: Dispatch 1881 — door-naming doctrine propagation: added §1 Door Naming Registry (Torii/Genkan/doors; "Hermes" = Nous-only; infra identifiers retain legacy hermes naming pending substrate bundle). Annotated OUR-shell "Hermes" references in this map (Cross-Channel Dedup appendix + Gateway Infrastructure rationale) to Genkan. Scoped annotation pass, NOT blanket find-replace — frozen audit-finding records (Wave tables, deferred items) and all infra paths/script names/cron identifiers left verbatim. Companion edits: CLAUDE.md (Shell Role + Model Tier + On-Demand Context + Cross-surface awareness), HermesDelegationProfiles.md (intro naming note; filename = rename candidate). Source: ideas/IDEA.Spark.LisaOSUltimateForm.md. Prior: Dispatch 1833 — loop-forge (per-goal Loop Contract composer + bounded grader-gated self-correcting loop launcher; 5 archetypes; tri-state exit; design-match harness; Pulse/Cortex/Kernel governance + evidence-gate/kill-switch) registered in §6 Skill Lifecycle per [PROPAGATION_REQUIRED]; created via skillcraft Mode A (3-test Gate PASS), executables under Fuda AK-425. §6 tally + Data Registries appendix corrected to 95. Change Impact Matrix §9b checked: the existing "Any skill created" row (HIGH) governs this propagation — no new matrix row required. NOTE: full lisaos-reconcile sweep remains a separate available task — this pass was the loop-forge registration + count lines only, not a whole-map reconcile. Prior: D1791 cartoonify registration, tally 94)

1. Boot Sequence

LISA's operating context loads from a single root document and a session activation skill:

Door Naming Registry (ratified 2026-06-11)

LisaOS interfaces onto the single OS core are called doors (plain English, generic term). The named doors:

Disambiguation rules:

• "Hermes" refers EXCLUSIVELY to Nous Research's products (Hermes Agent app, Hermes model family) in all LisaOS docs. It no longer names our harness.
• Infra identifiers retain a legacy service-account naming pending the substrate-migration bundle: the VPS service user, its home and dot-directories, the gateway systemd unit and its crontab, and the associated maintenance scripts all still carry the pre-rename identifier. Correct documentary form when referencing infra: "Genkan (infra: legacy service-account identifiers)".
• Rename candidate deferred to the substrate bundle: CS.AK.LISA.Data.HermesDelegationProfiles → GenkanDelegationProfiles (filename not renamed this pass).

Source: ideas/IDEA.Spark.LisaOSUltimateForm.md decision callouts (operator-ratified 2026-06-11).

2. Governance Documents

Documents defining binding operational rules. Located in cipher_shinobi/akatsuki/lisa/.

Archived (in archive/)

3. Architecture Documents

Design specifications and architectural rationale. Located in cipher_shinobi/akatsuki/lisa/.

No active architecture documents. All implemented designs archived; unbuilt designs deferred.

Deferred (in deferred/)

4. Frameworks

Reusable classification systems and taxonomies.

5. Sub-Agents

8 CyberShinobi operatives in .claude/agents/. All run on Opus. All have universal skill access via the Tools Domain Index.

Agent prompt format: Each agent has unique sections (Personality, Domain Expertise, Activation Profile) plus a shared 12-line Operating Standards block (universal tool access, confidence signalling, memory namespace, Shadow Clone, escalation). The Operating Standards block replaced the previous 70-line boilerplate (separate Tooling Index, Confidence, Memory, Shadow Clone, Escalation sections) in the 2026-04-05 consolidation refactor.

Dispatch modes: Single-agent | Parallel independent | Team assembly (max 4) | Shadow Clone Jutsu (LISA-initiated, max 3 clones + original)

Signalling: [CONFIDENCE: high|medium|low] + [DOMAIN_AFFINITY: true|false] | [ESCALATION] | [SHADOW_CLONE] | [PROPAGATION_REQUIRED]

6. Skills

Custom skills in ~/.claude/skills/ (registry tally 96 as of 2026-07-04 — authoritative source PER.EX.NINJ_DEV-AI.Data.ClaudeCodeSkills.md). The tables below were reconciled against that registry by dispatch D2290 (LisaOS audit campaign, Phase 4): 19 genuine skills that had drifted out of this map were restored — checkpoint, system-init, mac-disk-cleanup, gws-profile, hermes-dispatch, agent-tune, uat-bidirectional-probe, drafting-comms-guides, invoice, brandkit, chatgpt-image-designer, nano-banana-designer, seedance-designer, pixellab-ref-prep, impeccable, site-map-generator, design-system-ingest, feature-scope, code-optimise — and simplify was re-annotated as a Claude Code built-in (not a custom skill). Plugin-provided design/frontend skills (ckm:*, design-taste-frontend, gpt-taste, high-end-visual-design, minimalist-ui, industrial-brutalist-ui, imagegen-frontend-*, image-to-code, redesign-existing-projects, stitch-design-taste, ui-ux-pro-max, full-output-enforcement) are catalogued under §7 Plugins, not here. Domain mapping: PER.EX.NINJ_DEV-AI.Data.ToolsDomainIndex.md.

Session & System

Governance & Pipeline

Planning & Operations

Writing & Language

Creative & Visual

Vault & Knowledge

Data & Analytics

Intelligence & Monitoring

Ideation & Critique

Skill Lifecycle

Code & Engineering

Deprecated

7. External Integrations

MCP Servers

CLI Tools

Plugins (11 enabled)

8. Automation

Mac launchd background jobs + VPS cron entries. Registry: CS.AK.LISA.Data.SchedulerRegistry.md (renamed 2026-05-06 from LaunchdRegistry.md per Tobi-san G3.5 categorical correction — VPS-native scheduler is cron, not launchd). Job identifiers, plist names, script locations, exact schedule times, and log paths are deployment coordinates and are withheld — each job below is named by function; the vault registry holds the operational identifiers. VPS cron: the service-account crontab on the VPS (tailnet-internal). Logs: bounded-retention log locations on each substrate (paths withheld).

Reconciled 2026-07-04 (dispatch D2290) against the installed local scheduler entries. The seven rows marked (D2290-reconciled) were installed but undocumented here prior to this pass.

Retired / stale (D2290):

• A client-recon ingestion job (was daily, /seed-ingest) — uninstalled: ClientA retainer wound down. No longer in the installed set.
• A local gateway service entry (was always-on, local) — stale: the gateway no longer runs as a local scheduled job. It is VPS-only, systemd unit the gateway systemd unit on the VPS (tailnet-internal).

Runtime constraints: All Python scripts pin the Homebrew Python runtime (not system python — FDA). All scheduler entries carry an explicit PATH. Headless Claude sessions run non-interactively in an automatic permission mode via subprocess. GUI apps (Terminal.app) cannot launch in DarkWake.

9. Dependency Graph & Change Impact Matrix

9a. Dependency Graph

PERSONALITY.md (Single Source of Truth — personality + operational protocols)
+-- Included by: CLAUDE.md via @PERSONALITY.md
+-- Compiled into: SOUL.md via compile-soul.sh (+ SOUL_SHELL.md)
+-- Contains: Roster, Dispatch Checklist, Cache Schema, Governance Quick-Refs, FCF Quick-Ref

CLAUDE.md (CC Shell Boot)
+-- @includes: PERSONALITY.md (shared personality + protocols)
+-- CC Shell Extensions: MCP tool bindings, sidecar paths, worked examples
+-- On-Demand Context table --> governance docs with full vault paths
+-- CyberShinobi Roster --> in PERSONALITY.md, must match .claude/agents/ directory
+-- Dependency Propagation Protocol --> references THIS LisaOSMap

Agent Prompts (.claude/agents/*.md)
+-- ALL share: Operating Standards block (tool access, signalling, memory, clone, escalation)
+-- ALL reference: ToolsDomainIndex by path (not embedded)
+-- Each has: Binding reference --> specific governance doc
+-- Skill names in Activation Profile --> if skill renamed, agent prompt breaks

ToolsDomainIndex (PER.EX.NINJ_DEV-AI.Data.ToolsDomainIndex)
+-- Upstream: ClaudeCodeSkills registry (source of truth for custom skills)
+-- Downstream: ALL 8 agent prompts embed this index
+-- Downstream: CLAUDE.md On-Demand Context references it
+-- Downstream: SkillApprovalGate references it for overlap detection

FileClassFramework (PER.EX.SAG_SYSX.Docu.FileClassFramework)
+-- Downstream: VaultGovernance (Rule 1)
+-- Downstream: CLAUDE.md FCF Quick-Ref
+-- Downstream: smoke agent binding ref
+-- Downstream: file-classifier skill
+-- Downstream: MemoryArchitecture (namespace resolution)

MemoryArchitecture (CS.AK.LISA.Docu.MemoryArchitecture)
+-- References: MissionMatrix (CS namespace resolution)
+-- References: ActivityClassMatrix (PER namespace resolution)
+-- Downstream: CLAUDE.md Memory Architecture Quick-Ref
+-- Downstream: konnichiwagwan skill (session activation)
+-- Downstream: sayonara skill (session close)

SchedulerRegistry (CS.AK.LISA.Data.SchedulerRegistry)
+-- Must match: the installed local scheduler entries (Mac) AND `the service-account crontab` on VPS
+-- Each job references: script path, log path, paired skill, host class (Mac/VPS)

9b. Change Impact Matrix

10. Maintenance Protocol

Custodian: Smoke (Vault & Knowledge Infrastructure agent). Smoke's binding references include this document.

Update triggers:

• Any session that creates, renames, or deletes a governance doc, framework, agent, skill, integration, or automation job MUST update this System Map in the same session
• The Dependency Propagation Protocol in CLAUDE.md enforces this as a binding step

Audit cadence: Automated weekly reconciliation via /lisaos-reconcile skill (VPS cron, Sunday 21:00 UTC = Monday 01:00 GST). The 7-check protocol verifies all tables match current vault state. Telegram notification on drift (severity >= HIGH). Smoke dispatched for remediation on CRITICAL findings.

Dependency Propagation Checklist

When modifying any governance document, framework, agent prompt, skill, or data registry, execute in order:

1. Identify scope — read the Change Impact Matrix row (Section 9b) for the document category being modified
2. List affected files — enumerate every downstream file from the matrix
3. Propagate changes — update each downstream file to reflect the modification (content sync, path updates, name corrections)
4. Verify consistency — confirm no stale references remain in affected files (grep for old names/paths)
5. Update this System Map — if the change alters the dependency graph itself (new doc, renamed doc, new agent, new skill)
6. Report — include a [PROPAGATION] section in the file operations report listing every downstream file updated and why

Dispatch rule: If propagation touches 3+ files across multiple domains, dispatch to smoke (Vault & Knowledge) as a background task.

Agent obligation: Sub-agents performing structural modifications MUST signal [PROPAGATION_REQUIRED] in their return to LISA with a list of suspected downstream impacts.

Self-referential: This document appears in Section 2 (Governance Documents table) and is referenced by CLAUDE.md's Dependency Propagation Protocol and On-Demand Context table.

Appendix: Data Registries

Appendix: Templates

22 structural templates in templates/structural/, 6 executable templates + temporal sub-directory in templates/executable/.

Structural: TMPL.ArtefactMap, TMPL.BJJ, TMPL.CommsStyleGuide, TMPL.Definition, TMPL.EntityIndividual, TMPL.EntityOrganisation, TMPL.InputArticle, TMPL.InputBook, TMPL.InputPodcast, TMPL.InputVideo, TMPL.InputVideoKnowledgeExtraction, TMPL.MasterSvcAgreement.Crypto, TMPL.MasterSvcAgreement.Fiat, TMPL.MeetingNote, TMPL.MissionBrief, TMPL.MissionSeed, TMPL.Prompt, TMPL.ReconConfig, TMPL.SWOTAnalysis, TMPL.Skill, TMPL.TechSpec, TMPL.Template

Executable: CS.AK.TheSystem.Code.AddBattle.Js, AddLinearTask.Js, AddMeal.Js, AddReps.Js, AddTask.Js, FleetingNote.Js + temporal note templates (Daily, Weekly, Monthly, Yearly)

Appendix: Entity Profiles

10 entity files in entities/:

Appendix: Namespace Naming Convention

FCF namespace keys identify mission scope throughout the system — in dispatch briefs, cache writes, file naming, and memory assembly. The convention is deterministic: once you know the mission's organisational position, the namespace follows.

Patterns

Casing Rules

• ALLCAPS: All segment constants — CS, AK, YB, PER, EX, LV, SA, FDN
• PascalCase: Mission names, client names, topics — LISA, ClientA, ClientA, TheSystem
• Delimiter: . separates hierarchy levels; _ joins compound ALLCAPS segments (e.g. SAG_SYSX, NINJ_DEV-AI)

When to Create a New Namespace vs Reuse Existing

Create new when:

• A new Akatsuki initiative is founded (new internal project)
• A new Yurei Butai client engagement begins
• A new sub-mission under an existing client has distinct scope, deliverables, and timeline (e.g. CS.YB.ClientA.IaD alongside CS.YB.ClientA.Exec)

Reuse existing when:

• The work is a continuation of the same initiative (new dispatch, not new mission)
• The deliverable belongs to the same client engagement scope
• A sub-task within a larger mission does not warrant its own dispatch tracking

Authoritative registry: The Mission Matrix (CS.AK.CSDAO.Data.MissionMatrix) is the canonical list of active namespaces. New missions are registered via the mission-init skill.

Appendix: Cross-Channel Dispatch Deduplication

When LISA operates across multiple channels simultaneously (VS Code + Telegram/Genkan — the VPS door, formerly "Hermes"), duplicate dispatches become a risk. This protocol prevents the same work from being dispatched twice.

Pre-Dispatch Check

Before firing any dispatch via report_dispatch_raw, LISA MUST:

1. Check active dispatches — Call list_dispatches filtered by mission_namespace and status: active. If an active dispatch exists with a matching or substantially similar task_description, do not create a duplicate.
2. Check concurrent sessions — Query GET /api/sessions/active on the gateway to see if another channel has an active session working on the same namespace. If so, check that session's active_dispatches before proceeding.
3. Namespace affinity — If the other session is actively dispatching within the same namespace, defer to that session unless Tobi-san explicitly instructs otherwise.

Collision Resolution

If a duplicate dispatch is detected post-creation:

• The later dispatch should be marked as retry_of the earlier one if it is genuinely continuing the same work
• If both are running concurrently, the channel that created the later dispatch should call report_complete_raw with status: "failed" and result_summary: "Duplicate of dispatch {N}" to close the duplicate cleanly

Heartbeat Awareness

The session heartbeat (written by LISA on every sidecar update) includes active_dispatches and current_mission_namespaces. Other channels can read this at session start (konnichiwagwan Phase E2) to understand what is already in flight.

Appendix: Post-Audit Remediation Summary (sparkling-waddling-tome)

The comprehensive Lisa-OS audit (D664, CS.AK.LISA.Intel.LisaOSAuditReport.md) identified 26 findings across 6 modules. Remediation was executed in 6 waves. Current disposition:

Wave 1 — Security Remediation (D668)

Wave 2 — Compiler Hygiene (D669)

Wave 3 — Governance (D672)

Wave 4 — Skill Ecosystem (D673)

Wave 5 — Test Coverage (D691, Fuda AK-298)

Wave 6 — Parity Verification (D694)

D694 (genji) is simultaneously running parity verification and will file CS.AK.LISA.Intel.Wave6ParityReport.md.

Deferred Items

Remediation Statistics

Appendix: Gateway Infrastructure Decision

Production Environment

The LISA memory gateway runs exclusively on the VPS (the VPS (tailnet-internal) via Tailscale). This is a standing architectural decision, not a temporary arrangement.

Development Environment

Tobi's local Mac is development-only:

• npm run dev for testing gateway changes before VPS deployment
• Local SQLite database is ephemeral (test data only)
• No production traffic touches the local instance

Rationale

1. Persistent uptime — The VPS runs 24/7. The Mac sleeps, travels, and restarts. Session state, dispatch tracking, and cache writes require a host that does not disappear.
2. Genkan integration — The Telegram door (Genkan — the VPS harness formerly "Hermes") runs on the same VPS. Co-locating the gateway eliminates network latency for Genkan-to-gateway calls and simplifies the deployment topology.
3. Telegram door co-location — The persistent listener process (persistent_listener.py) that bridges Genkan (infra: legacy hermes identifiers) to Claude Code runs on the VPS alongside the gateway. Both processes share the same host, same Tailscale network, same systemd supervision.
4. Single source of truth — One production database, one gateway URL (the gateway endpoint (tailnet-internal)), no split-brain risk between local and remote state.

Deployment Protocol

Gateway changes follow the standard VPS deployment path:

1. Develop and test locally (npm run dev)
2. Push to lisa-os repo on GitHub
3. Pull on VPS (cd <VPS>/… && git pull)
4. Restart the service (sudo systemctl restart memory-gateway)