Compare commits

...

10 Commits

7 changed files with 203 additions and 0 deletions

View File

@@ -33,5 +33,18 @@ We implement an automated audit protocol to verify that no external API calls ar
## 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.*

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

@@ -174,6 +174,12 @@ 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

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