Remram is the vision and architecture hub for the Remram ecosystem.
This repository explains what Remram is, why it exists, how the ecosystem fits together, and where contributors should go next. It is the public front door for the project, not the primary home for implementation details.
Active repository documentation lives under docs/, strategic planning lives under roadmap/, approved feature records and local feature scaffolding live under features/, Remram-owned architecture and runtime schemas live under schemas/, concise technical reference lives under reference/, the living capability registry lives under platform/, historical material lives under archive/, and Forge lifecycle governance plus lifecycle artifact schemas now live in the private internal remram-forge repository.
All active capability and platform records still live in remram. Forge only holds the internal development pipeline, orchestration rules, and business-process mechanics that should not be public.
- roadmap/: planning artifacts, including ideas and proposals
- features/: approved feature records, enhancement stubs, and implementation-facing project artifacts
- platform/: the registry of active platform items
- schemas/: Remram-owned architecture and runtime schema namespaces
- Forge Governance (private): internal lifecycle, governance, and orchestration documentation
- Forge Schemas (private): internal lifecycle artifact templates and orchestration state schemas
- reference/: concise technical reference material
- docs/: system documentation, architecture explanation, feature documentation, operations, and AI context
- archive/: preserved historical material
Idea (Stage 1, roadmap/ideas/)
-> Proposal (Stage 2, roadmap/proposals/)
-> Approved Feature (features/)
-> Feature Project (Stage 3 onward, features/<feature>/projects/<project>/)
-> Platform deliverables (services, skills, plugins, core)
-> Feature documentation (docs/features/)
Platform items are technical deliverables. Feature documentation describes the user-facing capability built from those deliverables.
The chronological lifecycle definitions live under Forge Governance Lifecycle (private).
For the appliance repositories, main describes the next appliance release.
Tagged revisions are the release inputs that an appliance should run in steady state.
In practice:
- repository
mainis the next-release integration line - an appliance host is a tagged release until it is intentionally updated
moltbox gateway updateapplies whatever revision the configured host checkout points at, so release appliances should pin that checkout to the intended tag or release branch
AI systems still struggle with continuity.
They lose important context across sessions, repeat corrected mistakes, depend on oversized prompts, and confuse transcript history with durable knowledge. Remram exists to turn that fragile memory posture into a more disciplined system: local control remains authoritative, cognition is invoked deliberately, retrieval is bounded, mutation is governed, and long-lived knowledge is treated as a first-class architectural concern.
Remram is easiest to understand as a small ecosystem of cooperating layers:
People and clients
|
v
Remram App
|
v
Moltbox Gateway
|
v
OpenClaw / Orchestration
|
v
Remram Cortex
|
v
Durable knowledge, artifacts,
and long-term memory behavior
Remram Skills sit alongside the system as reusable skills,
plugin packages, and workflow building blocks.
Within Gateway / Moltbox, orchestration via OpenClaw and operator control are separate concerns. OpenClaw shapes live runs. The Moltbox control plane manages the appliance itself through CLI tools, tests, staged promotion, and human approval.
- Remram: vision, conceptual architecture, ecosystem map, contributor orientation
- Moltbox Gateway: control-plane implementation, Moltbox CLI tooling, deployment orchestration, and appliance operations
- Remram Cortex: long-term knowledge system, retrieval, reflection, and memory services
- Remram App: user-facing APIs and applications
- Remram Skills: reusable skills, plugin packages, and portable capability building blocks
- Documentation Map
- Roadmap
- Features
- Platform Registry
- Forge Governance (private)
- Forge Schemas (private)
- Schemas
- Reference
- Feature Documentation
- AI Context
archive/for historical documentation
This repository preserves lifecycle artifacts under:
roadmap/ideas/for Stage 1 idea captureroadmap/proposals/for Stage 2 proposal developmentfeatures/once proposal approval creates an active feature
Use Roadmap for the planning directories, Forge Governance Lifecycle (private) for the stage definitions, and Features for the implementation-facing feature structure.
Historical context and superseded planning material remain in archive/.
- Want to understand the current documentation system: start with docs/README.md
- Want a fast AI-assistant bootstrap: start with docs/ai-context/README.md
- Want to understand planning and lifecycle layout: start with roadmap/README.md, features/README.md, and platform/README.md
- Want the end-to-end SDLC path from idea to implementation: read roadmap/README.md, Forge Governance Lifecycle (private), features/README.md, and Forge Schemas (private) for artifact templates
- Want user-facing capability docs once the deliverables exist: use docs/features/README.md
- Want governance and lifecycle rules: use Forge Governance (private)
- Want canonical architecture and runtime schemas: use schemas/README.md
- Want concise command or endpoint lookup: use reference/README.md
- Want to review earlier material: use
archive/
If you are changing vision, ecosystem framing, conceptual architecture, onboarding, roadmap docs, or platform registry docs, this is the right repository.
If you are changing lifecycle governance, lifecycle templates, or orchestration state contracts, you want the private internal remram-forge repository.
If you are changing runtime behavior, deployment, storage, APIs, or implementation details, you probably want one of the domain repositories instead.