Workers MUST use provided input data, not fetch external sources.
Adds: Data Source Integrity section, dispatch guidance example,
anti-pattern entry. Root cause of e2e test discrepancies where
writer worker queried Proxmox API instead of using raw data.
- Added required frontmatter block with kind=pattern, name, and description
- Fixes CI validate step that was blocking the PR pipeline
- All other CI checks (lint, ai-review) were skipped due to validate failure
Contract is Mumuni-specific operating doctrine — different agents have
different architectures and don't need this. Renamed file and frontmatter
to reflect that.
Added cluster/node topology section referencing all 5 Proxmox nodes and
clarifying that the contract is infrastructure-agnostic — defines the who
and when, not the where.
Defines when to delegate, worker selection matrix, verification protocol,
kanban board, and failure handling. Addresses the context overflow and
iteration exhaustion issues where the manager was doing all work itself
instead of delegating to the 6 worker profiles.
Testing the consolidated litellm-self-heal contract against live infra found:
- IP drift: pi host is .24, not .65 (confused with ra-h-os bridge)
- Fixed gpu-monitor.prose.md: 192.168.68.65 → 192.168.68.24 (3 locations)
- Fixed gpu-fleet.prose.md: .65 → .24 in config files + agent keys tables
- Container count: 10 running on CT 116, not 8 as contract stated
- Added harness-docker-stats + harness-pve-exporter to litellm-self-heal
- Updated container health check list
Verified: GPU monitor restarted on .24:9100, ornith model inference working,
all 10 containers healthy.
- litellm-self-heal: merged health check as §Health Check section,
includes full architecture diagram (v4.0.0), GPU topology, timeout
tables, container list, and execution flow. Eliminates duplication
between the two contracts.
- litellm-health: marked DEPRECATED, retained for reference
- README.md: updated with consolidated contract, deprecation notice,
disk-gc-threat-response, and infrastructure-monitoring status
Fixes Zulip OIDC authentication where redirect_uri used internal IP
(192.168.68.19) instead of public domain (chat.sysloggh.net) after
server restart. Monkey-patches social_core.strategy.BaseStrategy
to use ROOT_DOMAIN_URI for all redirect URI construction.
- Switched default branch from feat/zulip-streaming to master
- Added Step 5: gateway restart with smoke check after plugin install
- Plugin changes require restart to take effect for a valid test
- Outstanding feature branch merges should be addressed post-install
The validate job was failing because 'reference' is not an allowed kind.
Changed to 'template' since this document serves as a canonical baseline
template for restoring agent configurations.
- Added stream_subscription_check, dm_response_time_offline_verifiable, known_issues_tracked postconditions
- Added 'Status' section clarifying active for Hermes agents only (not retired with pi Zulip)
- Added 'State Persistence' section with KG node schema for build-zulip-plugin:state
- Execution step 4: always run offline tests (simulate_dm_latency, selftest)
- Execution step 5: update KG state node after each generation
The Gitea Actions runner cannot resolve the internal hostname
git.sysloggh.net during checkout. Using the direct IP address
resolves the DNS resolution issue in CI pipeline steps.
Single non-disruptive script replacing 7 scattered Zulip health checks.
Checks every 10 min via cron, never restarts anything:
- LiteLLM key validation for all 4 Hermes agents
- GPU port conflict / ghost process detection
- Agent gateway liveness + Zulip streaming status
- Recent gateway error count
Port conflict detection added to all 3 GPU wrappers:
- .8 (qwen): wrapper detects ghost on port 8080 before starting
- .110 (gemma): same pattern
- .15 (ornith): port-cleanup.sh replaces blanket pkill -x llama-server
_resolve_task_provider_model() in agent/auxiliary_client.py ignores
api_key_env for auxiliary tasks (vision, compression). The custom
provider path resolves it, but aux tasks take a different code path.
Workaround: set api_key directly alongside api_key_env.
Applied to Tanko (vision + compression).
Tanko: old key sk-620a05e95a... was from docker-compose router config,
not LiteLLM key DB. Deleted + regenerated via LiteLLM API:
sk-CggiHWlamQyShxWC3Hx6uw (alias: tanko, budget: $100)
Mumuni: verified via pct-run 114 — key is sk-VrqCNlwUgzoNGOpikJ7nwQ
(was previously listed as sk-XY2aUfvy2... in contracts)
hermes-key-enforcement.prose.md:
- Add IP column to verified agents table
- Fix Tanko status: was using master key via systemd drop-in (not compliant)
- Add detection query step 2: check systemd drop-ins for master key leaks
- Add step 3: verify running process env against dedicated key
- Mark Mumuni, Koby, Koonimo as Unverified (last check was surface-level only)
gpu-fleet.prose.md:
- Add CT ID column to agent table for cross-reference
- Fix Abiba IP .24 → .65 (pi agent runs on RA-H OS host)
- Update Abiba LiteLLM key to match actual models.json key
- Set Koonimo IP to unknown (was .114 — incorrect per user)
- Fix pi-specific paths .24 → .65
hermes-config-template.prose.md:
- Set Koonimo IP to unknown
infrastructure-control.prose.md:
- Set Koonimo IP to unknown
- Fix Koonimo CT reference
Test results:
- Test #1: Recursive grep finds sub-profile violations old query missed (2/2 vs 1/2)
- Test #2: safe-mutate step correctly positioned in Violation Response, YAML valid
jerome
mumuni-bot
abiba-bot
root