Core Systems
Core Systems
Section titled “Core Systems”Four subsystems that make Gormes a runtime instead of a chatbot wrapper.
Use these pages for the stable runtime model. Use the phase pages when you need the current delivery ledger, status, or execution queue.
| System | Owns | Page | Roadmap | Completion lane |
|---|---|---|---|---|
| Learning Loop | Skill detection, distillation, review, retrieval, and feedback | learning-loop | Phase 6 | Lane 6 |
| Memory | Local recall, graph provenance, scoped search, mirrors, and Goncho substrate | memory | Phase 3 | Lane 2 |
| Tool Execution | Typed operation registry, schema parity, trust classes, and tool loops | tool-execution | Phase 2.A + Phase 5 | Lane 3 |
| Gateway | Platform adapters, command policy, session routing, delivery, hooks, and active-turn behavior | gateway | Phase 2.B-2.G | Lane 4 |
Miss any one of these and you don’t have “Hermes in Go” — you have a chatbot with tools.
Before Editing
Section titled “Before Editing”Every core-system change should name the upstream or Gormes-native contract, the caller trust class, the degraded-mode surface, and the fixture that proves it. Those fields belong in Progress Schema before a row is assigned through Agent Queue.
When a core-system change spans more than one lane, split it. For example, Goncho memory compatibility belongs in Lane 2; plugin memory adapters belong in Lane 3; prompt injection of memory belongs in Lane 1. A builder row should not try to ship all three at once.