Architecture View Only
Public supporting references live in Runtime Overview, Agent Workflow Overview, and Operations Overview.
1. Current Role Model
CurrentStage 0 specs, sequencing, ADR framing, phase and release recommendations.
Implementation, test execution, PR preparation, deploy work inside approved scope.
Evidence review, GO/NO-GO, merge constraints, scope-discipline checks.
Autonomous repro, E2E/regression evidence, no undocumented fixes.
Bootstrap/read-only entry role. May assume one active role at a time under least-authority rules.
Optional orchestration mode. Routes work and syncs context. Not the default implementer.
2. Hard Boundaries
Current- Architect does not self-merge by default.
- Executor does not self-gate or self-merge.
- Gatekeeper does not silently rewrite implementation scope.
- Tester produces evidence first and does not slip fixes into a test pass.
- Universal must assume one role, not combine authorities.
- Coordinator must not quietly become the executor or gatekeeper.
3. Onboarding and SSOT Flow
CurrentStart from project-local KG and current repo truth, not from stale session memory.
Use handoff plus SSOT docs to determine current work, not historical phase docs.
OUTBOX is required for meaningful task closeout, especially after blockers or rework.
GO entries are consumed and closed after merge. SSOT docs refresh to reflect the new runtime baseline.
SSOT hashes track the last runtime-affecting commit. Docs-only lineage above does not trigger a new hash update cycle.
4. Shared Memory Guardrail
Current- Canonical KG store:
.aim/memory-jorvis.jsonlwithlocation="project",context="jorvis". - Agents must read project-local KG at session start and update it after major decisions or closeout.
- Worktree launches need explicit verification that the worktree still resolves the canonical project memory files and bootstrap note.
- If project detection fails, the agent must stop and escalate instead of silently falling back to global memory.
5. Human Roles vs OpenClaw
CurrentOpenClaw may explain, summarize, recommend, and eventually dry-run or approved-apply narrow operations. Hermes should be understood as the layer that turns repeated operator work into reusable capability. It must not become the gatekeeper or release approver.