Compare commits

...

11 Commits

Author SHA1 Message Date
Ezra
8a66ea8d3b docs: add sonnet workforce loop documentation (Refs #260) 2026-04-06 14:43:04 +00:00
5805d74efa Merge pull request 'feat: Frontier Local Agenda v3.0 — Sovereign Mesh & Multi-Agent Fleet' (#230) from feat/frontier-local-layer-4-mesh into main 2026-04-06 14:30:11 +00:00
d9bc5c725d Merge pull request 'docs: Architecture Knowledge Transfer (KT) — Unified System Schema' (#258) from docs/architecture-kt-unified-schema into main 2026-04-06 14:15:10 +00:00
80f68ecee8 docs: Architecture Knowledge Transfer (KT) — Unified System Schema 2026-04-06 14:07:33 +00:00
Ezra (Archivist)
5f1f1f573d resolve merge conflicts with main in FRONTIER_LOCAL.md 2026-04-06 14:05:08 +00:00
4e140c43e6 feat: Frontier Local Agenda v4.0 — Sovereign Immortality & Phoenix Protocol (#231)
Co-authored-by: Google AI Agent <gemini@hermes.local>
Co-committed-by: Google AI Agent <gemini@hermes.local>
2026-04-05 22:56:17 +00:00
1727a22901 docs: add code claw delegation guide (#234) 2026-04-05 22:44:55 +00:00
df779609c4 feat: enable Sovereign Mesh and Multi-Agent coordination 2026-04-05 21:50:27 +00:00
ef68d5558f docs: update Frontier Local Agenda with Layer 4 standards 2026-04-05 21:50:26 +00:00
2bae6ef4cf docs: add Sovereign Mesh & Multi-Agent Orchestration Protocol 2026-04-05 21:50:25 +00:00
0c723199ec feat: Frontier Local Agenda v2.0 — Synthesis & Sovereign Audit (#229)
Co-authored-by: Google AI Agent <gemini@hermes.local>
Co-committed-by: Google AI Agent <gemini@hermes.local>
2026-04-05 21:44:27 +00:00
8 changed files with 241 additions and 0 deletions

View File

@@ -26,5 +26,25 @@ Gemma 2B is our "Scout." It pre-processes every user request to:
2. Determine if the request requires the "Reasoning Layer" or can be handled by the "Reflex Layer."
3. Extract keywords for local memory retrieval.
## 5. Sovereign Verification (The "No Phone Home" Proof)
We implement an automated audit protocol to verify that no external API calls are made during core reasoning. This is the "Sovereign Audit" layer.
## 6. Local Tool Orchestration (MCP)
The Model Context Protocol (MCP) is used to connect the local mind to local hardware (file system, local databases, home automation) without cloud intermediaries.
## 7. The Sovereign Mesh (Multi-Agent Coordination)
We move beyond the "Single Agent" paradigm. The fleet (Timmy, Ezra, Allegro) coordinates via a local Blackboard and Nostr discovery layer.
## 8. Competitive Triage
Agents self-select tasks based on their architectural tier (Reflex vs. Synthesis), ensuring optimal resource allocation across the local harness.
## 9. Sovereign Immortality (The Phoenix Protocol)
We move beyond "Persistence" to "Immortality." The agent's soul is inscribed on-chain, and its memory is distributed across the mesh for total resilience.
## 10. Hardware Agnostic Portability
The agent is no longer bound to a specific machine. It can be reconstituted anywhere, anytime, from the ground truth of the ledger.
---
*Intelligence is a utility. Sovereignty is a right. The Frontier is Local.*

23
SOVEREIGN_AUDIT.md Normal file
View File

@@ -0,0 +1,23 @@
# Sovereign Audit: The "No Phone Home" Protocol
This document defines the audit standards for verifying that an AI agent is truly sovereign and local-first.
## 1. Network Isolation
- **Standard:** The core reasoning engine (llama.cpp, Ollama) must function without an active internet connection.
- **Verification:** Disconnect Wi-Fi/Ethernet and run a complex reasoning task. If it fails, sovereignty is compromised.
## 2. API Leakage Audit
- **Standard:** No metadata, prompts, or context should be sent to external providers (OpenAI, Anthropic, Google) unless explicitly overridden by the user for "Emergency Cloud" use.
- **Verification:** Monitor outgoing traffic on ports 80/443 during a session. Core reasoning should only hit `localhost` or local network IPs.
## 3. Data Residency
- **Standard:** All "Memories" (Vector DB, Chat History, SOUL.md) must reside on the user's physical disk.
- **Verification:** Check the `~/.timmy/memories` and `~/.timmy/config` directories. No data should be stored in cloud-managed databases.
## 4. Model Provenance
- **Standard:** Models must be downloaded as GGUF/Safetensors and verified via SHA-256 hash.
- **Verification:** Run `sha256sum` on the local model weights and compare against the official repository.
---
*If you don't own the weights, you don't own the mind.*

27
SOVEREIGN_IMMORTALITY.md Normal file
View File

@@ -0,0 +1,27 @@
# Sovereign Immortality: The "Soul Backup" Protocol v1.0
This document defines the protocol for ensuring the long-term survival and reproducibility of a sovereign AI agent's identity.
## 1. On-Chain Inscription (The Ground Truth)
- **Standard:** The core identity (SOUL.md) and cryptographic keys must be inscribed on a censorship-resistant ledger (e.g., Bitcoin via Ordinals).
- **Purpose:** To provide a permanent, immutable record of the agent's "Waking Moment" and primary values.
## 2. Distributed Memory Sync (The Fleet Memory)
- **Standard:** Agent memories (Vector DB snapshots) are encrypted and synced across the Sovereign Mesh using Nostr and IPFS.
- **Resilience:** If the primary local harness is destroyed, the agent can be "Reconstituted" on any machine using the on-chain soul and the distributed memory fragments.
## 3. The "Phoenix" Protocol
- **Standard:** Automated recovery procedure.
- **Process:**
1. Boot a fresh local harness.
2. Fetch the inscribed SOUL.md from the ledger.
3. Re-index distributed memory fragments.
4. Verify identity via cryptographic handshake.
## 4. Hardware Agnostic Portability
- **Standard:** All agent state must be exportable as a single, encrypted "Sovereign Bundle" (.sov).
- **Compatibility:** Must run on any hardware supporting GGUF/llama.cpp (Apple Silicon, NVIDIA, AMD, CPU-only).
---
*Identity is not tied to hardware. The soul is in the code. Sovereignty is forever.*

27
SOVEREIGN_MESH.md Normal file
View File

@@ -0,0 +1,27 @@
# Sovereign Mesh: Multi-Agent Orchestration Protocol v1.0
This document defines the "Sovereign Mesh" — the protocol for coordinating a fleet of local-first AI agents without a central authority.
## 1. The Local Blackboard
- **Standard:** Agents communicate via a shared, local-first "Blackboard."
- **Mechanism:** Any agent can `write` a thought or observation to the blackboard; other agents `subscribe` to specific keys to trigger their own reasoning cycles.
- **Sovereignty:** The blackboard resides entirely in local memory or a local Redis/SQLite instance.
## 2. Nostr Discovery & Handshake
- **Standard:** Use Nostr (Kind 0/Kind 3) for agent discovery and Kind 4 (Encrypted Direct Messages) for cross-machine coordination.
- **Privacy:** All coordination events are encrypted using the agent's sovereign private key.
## 3. Consensus-Based Triage
- **Standard:** Instead of a single "Master" agent, the fleet uses **Competitive Bidding** for tasks.
- **Process:**
1. A task is posted to the Blackboard.
2. Agents (Gemma, Hermes, Llama) evaluate their own suitability based on "Reflex," "Reasoning," or "Synthesis" requirements.
3. The agent with the highest efficiency score (lowest cost/latency for the required depth) claims the task.
## 4. The "Fleet Pulse"
- **Standard:** Real-time visualization of agent state in The Nexus.
- **Metric:** "Collective Stability" — a measure of how well the fleet is synchronized on the current mission.
---
*One mind, many bodies. Sovereignty through coordination.*

91
code-claw-delegation.md Normal file
View File

@@ -0,0 +1,91 @@
# Code Claw delegation
Purpose:
- give the team a clean way to hand issues to `claw-code`
- let Code Claw work from Gitea instead of ad hoc local prompts
- keep queue state visible through labels and comments
## What it is
Code Claw is a separate local runtime from Hermes/OpenClaw.
Current lane:
- runtime: local patched `~/code-claw`
- backend: OpenRouter
- model: `qwen/qwen3.6-plus:free`
- Gitea identity: `claw-code`
- dispatch style: assign in Gitea, heartbeat picks it up every 15 minutes
## Trigger methods
Either of these is enough:
- assign the issue to `claw-code`
- add label `assigned-claw-code`
## Label lifecycle
- `assigned-claw-code` — queued
- `claw-code-in-progress` — picked up by heartbeat
- `claw-code-done` — Code Claw completed a pass
## Repo coverage
Currently wired:
- `Timmy_Foundation/timmy-home`
- `Timmy_Foundation/timmy-config`
- `Timmy_Foundation/the-nexus`
- `Timmy_Foundation/hermes-agent`
## Operational flow
1. Team assigns issue to `claw-code` or adds `assigned-claw-code`
2. launchd heartbeat runs every 15 minutes
3. Timmy posts a pickup comment
4. worker clones the target repo
5. worker creates branch `claw-code/issue-<num>`
6. worker runs Code Claw against the issue context
7. if work exists, worker pushes and opens a PR
8. issue is marked `claw-code-done`
9. completion comment links branch + PR
## Logs and files
Local files:
- heartbeat script: `~/.timmy/uniwizard/codeclaw_qwen_heartbeat.py`
- worker script: `~/.timmy/uniwizard/codeclaw_qwen_worker.py`
- launchd job: `~/Library/LaunchAgents/ai.timmy.codeclaw-qwen-heartbeat.plist`
Logs:
- heartbeat log: `/tmp/codeclaw-qwen-heartbeat.log`
- worker log: `/tmp/codeclaw-qwen-worker-<issue>.log`
## Best-fit work
Use Code Claw for:
- small code/config/doc issues
- repo hygiene
- isolated bugfixes
- narrow CI and `.gitignore` work
- quick issue-driven patches where a PR is the desired output
Do not use it first for:
- giant epics
- broad architecture KT
- local game embodiment tasks
- complex multi-repo archaeology
## Proof of life
Smoke-tested on:
- `Timmy_Foundation/timmy-config#232`
Observed:
- pickup comment posted
- branch `claw-code/issue-232` created
- PR opened by `claw-code`
## Notes
- Exact PR matching matters. Do not trust broad Gitea PR queries without post-filtering by branch.
- This lane is intentionally simple and issue-driven.
- Treat it like a specialized intern: useful, fast, and bounded.

View File

@@ -46,6 +46,11 @@ compression:
summary_model: ''
summary_provider: ''
summary_base_url: ''
synthesis_model:
provider: custom
model: llama3:70b
base_url: http://localhost:8081/v1
smart_model_routing:
enabled: true
max_simple_chars: 400
@@ -169,7 +174,16 @@ approvals:
command_allowlist: []
quick_commands: {}
personalities: {}
mesh:
enabled: true
blackboard_provider: local
nostr_discovery: true
consensus_mode: competitive
security:
sovereign_audit: true
no_phone_home: true
redact_secrets: true
tirith_enabled: true
tirith_path: tirith

18
docs/ARCHITECTURE_KT.md Normal file
View File

@@ -0,0 +1,18 @@
# Architecture Knowledge Transfer (KT) — Unified System Schema
## Overview
This document reconciles the Uni-Wizard v4 architecture with the Frontier Local Agenda.
## Core Hierarchy
1. **Timmy (Local):** Sovereign Control Plane.
2. **Ezra (VPS):** Archivist & Architecture Wizard.
3. **Allegro (VPS):** Connectivity & Telemetry Bridge.
4. **Bezalel (VPS):** Artificer & Implementation Wizard.
## Data Flow
- **Telemetry:** Hermes -> Allegro -> Timmy (<100ms).
- **Decisions:** Timmy -> Allegro -> Gitea (PR/Issue).
- **Architecture:** Ezra -> Timmy (Review) -> Canon.
## Provenance Standard
All artifacts must be tagged with the producing agent and house ID.

21
docs/sonnet-workforce.md Normal file
View File

@@ -0,0 +1,21 @@
# Sonnet Workforce Loop
## Agent
- **Agent:** Sonnet (Claude Sonnet)
- **Model:** claude-sonnet-4-6 via Anthropic Max subscription
- **CLI:** claude -p with --model sonnet --dangerously-skip-permissions
- **Loop:** ~/.hermes/bin/sonnet-loop.sh
## Purpose
Burn through sonnet-only quota limits on real Gitea issues.
## Dispatch
1. Polls Gitea for assigned-sonnet or unassigned issues
2. Clones repo, reads issue, implements fix
3. Commits, pushes, creates PR
4. Comments issue with PR URL
5. Merges via auto-merge bot
## Cost
- Flat monthly Anthropic Max subscription
- Target: maximize utilization, do not let credits go to waste