Skip to content

index.md

Latest commit

 

History

History
98 lines (74 loc) · 5.5 KB

index.md

File metadata and controls

98 lines (74 loc) · 5.5 KB
Raw

MirrorNeuron Documentation

This directory is the detailed documentation source of truth for the MirrorNeuron workspace. It is written for internal maintainers, contributors, integrators, and operators; the documentation site presents a shorter reader-facing layer. When the two differ, verify the implementation and update both in the same change.

MirrorNeuron is a runtime for message-driven workflows with a Python CLI/API layer, an Elixir/BEAM core, Redis-backed runtime state, and blueprint-oriented run records. It can run on one machine or across runtime nodes.

Documentation contract

Every user-visible behavior has one canonical detailed page in this directory:

Fact Canonical page Implementation source to verify
Project fit, boundaries, and non-guarantees Why MirrorNeuron Runtime, runner, and security implementation.
Shared vocabulary Core Concepts Manifest/runtime terms and CLI/API contracts.
Installation and local services Installation mn-deploy/install.sh, server.sh, runtime start code.
CLI syntax and behavior CLI Reference mn-cli/mn_cli/main.py and command modules.
REST API shape API Reference mn-api routes and running FastAPI OpenAPI schema.
Environment defaults Environment Variables CLI, API, SDK, and Core configuration definitions.
Blueprint and manifest contracts Blueprint Standard, Job Bundle Format Schemas, SDK validators, and checked-in blueprints.
Reliability and recovery Reliability Guide Core persistence, lease, scheduler, and recovery tests.
Bounded working context and compression Context Intelligent System Membrane working-memory contract and Python SDK context-session tests.
Security boundaries Security Model Runner, network, Redis, secret, and policy behavior.
Repeated operational failures Troubleshooting Reproducible diagnostics and component tests.

Do not duplicate large command tables, API shapes, or environment-variable lists on tutorial pages. Link to the canonical reference instead.

Reader journeys

Evaluator

  1. Why MirrorNeuron
  2. Core Concepts
  3. Quickstart
  4. Security Model
  5. Runtime Architecture

First-time developer

  1. Installation
  2. Quickstart
  3. Examples
  4. CLI Reference
  5. Troubleshooting

Blueprint author

  1. Core Concepts
  2. Blueprint Standard
  3. Blueprints and Skills
  4. Python SDK
  5. Context Intelligent System
  6. Testing

Operator

  1. Installation
  2. Services and Health Checks
  3. Monitor Guide
  4. Reliability Guide
  5. Redis High Availability
  6. Troubleshooting

Contributor

  1. Component Guide
  2. Runtime Architecture
  3. Testing
  4. Contributing
  5. Documentation Style

Documentation map

Topic Page
Local installation and verification installation.md
First local workflow quickstart.md
Checked-in blueprint selection examples.md
CLI, API, SDK, and configuration cli.md, api.md, SDK.md, env_variables.md
Models, OpenShell, services, and resources model-runtime.md, docker-model-runner-arm64-nvidia.md, docker_and_openshell_for_blueprints.md, services-and-health-checks.md, resources-and-devices.md
Cluster, deployment, schedules, and HA cluster.md, deployments.md, schedules-and-events.md, redis-ha.md
Architecture, context, reliability, and security runtime-architecture.md, cluster_architecture.md, context-memory.md, reliability.md, security.md
Internal quality and contributor process testing.md, contributing.md, documentation-style.md

Runtime alignment record

See September 2026 alignment for the current job/run, source-package, dependency, model-routing, and execution-boundary corrections, with validation evidence and unexercised integrations.

Source-doc update rule

When a pull request changes a command, API route, configuration key, manifest field, runtime guarantee, runner boundary, or failure behavior:

  1. update the canonical detailed page in mn-docs;
  2. update the concise corresponding page in mn-doc-site/content/docs when the behavior is user-facing;
  3. update a tutorial, troubleshooting page, and migration note when the reader journey changes;
  4. run the documentation build and the smallest relevant product validation; and
  5. record the implementation source and validation command in the pull request.