Status: MVP plan ready Started: 2026-07-14 Path: /opt/data/projects/harness-enhancement.md Port: N/A (not a web app โ system improvement project)
How do we turn fibon's "fence philosophy" (deterministic constraints in code, not prompt guardrails) into practical mini tools for our Hermes setup?
Read fibon design log Chapters 2, 3, 4, 6 & 7 (2026-07-14 ~ 2026-07-15). Key insights:
Currently our Hermes setup relies heavily on Layer 1 (AGENTS.md / SOUL.md = prompt-level rules). Layers 2-4 are thin.
Key takeaways mapped to our project:
Wiki pages created: - [[multi-agent-hierarchy-brakes]] โ Butler/Assistant + 3 hard brakes - [[structured-memory-cards]] โ Card types, decay, arbitration - [[llm-randomness-as-feature]] โ Fence philosophy
A script that takes task type (research / code / plan / review) and outputs: - Recommended goal template - Required context fields - Toolsets to enable/disable - Expected output format - Constraints (timeout, max iterations)
Pain point it solves: Currently delegation is ad-hoc โ LLM decides what to pass, how to structure it, what toolsets to use. Inconsistent quality.
Open questions: - Should this be a CLI script, a Hermes skill, or both? - How do we define task types? (too many = unusable, too few = not useful) - Where does the template live? (skill reference file? standalone script?)
Periodic scan of MEMORY.md that: - Flags entries >90 days without verification - Detects duplicate/contradictory entries - Generates a cleanup report for human review - Optionally suggests what to keep/compress/archive
Pain point it solves: MEMORY.md is at 98% capacity. No aging mechanism. Conflicts detected manually (or not at all).
Open questions: - Should this run as a cron job or manual trigger? - How do we track "last verified" dates for freeform text entries? - Should it modify MEMORY.md automatically or just report?
A transform_llm_output hook that automatically checks my output against taste rules before it reaches the user.
Pain point it solves: Taste is currently prompt-level (memory rules I try to follow). This makes it unreliable โ I might forget, misapply, or be inconsistent. Moving taste to code-level hooks makes it deterministic and always-on.
Architecture:
taste-rules.yaml # Quality standards (not in memory)
โ
transform_llm_output.py # Hook script checks output against rules
โ
Output reaches user # Or gets rejected with feedback
Taste rules (example): - No simplified Chinese โ only Traditional Chinese or English - No filler words โ substance over padding - Specific over vague โ quantify, don't hedge - Match user's communication style
Open questions: - Should taste rules be per-user or global? - How to handle feedback loop (user corrections โ rule updates)? - Should rejected outputs be logged for review? - How to evolve rules over time without manual editing?
Before writing to any storage layer, check:
- Is this project-specific? โ projects/
- Is this reusable knowledge? โ wiki/
- Is this session-specific? โ sandbox/
- Is this a user preference? โ MEMORY.md or USER.md
Pain point it solves: Information ends up in wrong storage layer. MEMORY.md contains project-specific details that belong in context files. Wiki has session-specific notes that should be in sandbox.
Open questions: - Is this a pre-write hook, a skill instruction, or a validation script? - How do we handle borderline cases? (info that serves both project and cross-project) - Should this be enforced or advisory?
Skills are instruction files (SKILL.md) that tell the agent how to behave. But there's no mechanism to verify the agent actually followed the instructions. The agent can skip required steps, use wrong tools, or answer without doing the actual work โ and there's no way to detect it.
A structured YAML section added to SKILL.md frontmatter that defines binary pass/fail behavioral rules:
contract:
version: 1
risk_level: low
required_tools:
- tool: crawl4ai
min_calls: 1
description: "Must use crawl4ai for extraction"
forbidden:
- type: answer_without_tool
description: "Cannot answer web questions without extracting first"
output_rules:
- type: urls_must_be_fetched
description: "Any URL in output must have been actually fetched"
post_checks:
- type: tool_call_exists
tool: crawl4ai
min_calls: 1
| Frontmatter (existing) | Contract (enhancement) | |
|---|---|---|
| Defines | What the skill IS (identity) | How the skill must be USED (behavior) |
| Purpose | Discovery, display, organisation | Enforcement, validation |
| Checking | None | Script can verify compliance |
| Agent skip | Undetectable | Detectable post-hoc |
110 skills, low write frequency โ no need for SQLite/PostgreSQL. A single JSON index file suffices.
~/.hermes/skills/index.json:
{
"version": 1,
"skills": {
"crawl4ai-extract": {
"path": "software-development/crawl4ai-extract/SKILL.md",
"has_contract": true,
"contract_version": 1,
"risk_level": "low",
"last_validated": "2026-07-15T11:30:00Z",
"validation_history": [
{"ts": "2026-07-15T11:30:00Z", "result": "pass", "checks": 3}
]
}
}
}
Phase 1 โ Schema + Tools (no deployment needed):
1. Finalise contract YAML schema
2. Write build-skill-index.py โ scans all skills, extracts frontmatter + contract, builds index.json
3. Write validate-contract.py โ reads contract from skill, checks against session tool call log, outputs pass/fail
4. Prototype on crawl4ai-extract โ add contract, validate against a real session
Phase 2 โ Rollout (if Phase 1 proves valuable): 5. Add contracts to 5 high-value skills: crawl4ai-extract, safety-and-accuracy, web-search-troubleshooting, verification-before-completion, systematic-debugging 6. Integrate into skill_manage โ prompt for contract fields when creating/patching skills 7. Ming's Note display โ show contract status on skill overview
Phase 3 โ Automation (future, if needed): 8. Cron-based periodic validation of recent sessions 9. Gateway hook for post-execution auto-check 10. Contract violation alerts
| File | Purpose |
|---|---|
~/.hermes/scripts/validate-contract.py |
Validation script |
~/.hermes/scripts/build-skill-index.py |
Index generator |
~/.hermes/skills/index.json |
Generated skill metadata + contract status |
risk_level in contract affect approval mode? (high-risk skills โ always manual approval)Research complete. Plan drafted. Awaiting Henry's review before any implementation.
Problem: MEMORY.md is at 98% capacity. Multiple users (Henry, Henna) will multiply memory needs. Flat file doesn't scale.
Proposed architecture:
Hot Memory (MEMORY.md) โ <30% capacity, essential facts, always loaded
Warm Memory (SAG/SQLite) โ structured, queryable, per-user sources
Cold Memory (state.db) โ session transcripts, FTS5 search
SAG Investigation (2026-07-16): - SAG requires embedding API for vector search (no SQL-only mode) - Current VPS has no OpenAI/OpenRouter API key available - Xiaomi API doesn't support embeddings - Local embedding possible but adds ~630MB RAM overhead
V1 Approach (approved): - Use SQLite FTS5 directly for warm memory (no SAG dependency) - Per-user memory tables with keyword search - MEMORY.md stays as hot memory (<30% capacity)
V2 Enhancement (when embedding API available): - Migrate to SAG for semantic search - Dynamic hyperedges for cross-user memory correlations - Better multi-hop reasoning across memory entries
Status: V1 implementation pending. SAG saved as enhancement direction.
Goal: Standardize how context is passed to subagents via delegate_task, reducing context loss and inconsistent quality.
Why this first: Article insight โ "filesystem as coordination layer" is the #1 pattern across Anthropic, OpenAI, and fibon. Our biggest daily pain point is delegation context loss. This is the simplest, highest-ROI fix.
Non-goals (explicit): - No full multi-agent orchestration system - No new tooling/infrastructure - No Warm Memory or Skill Contract (separate efforts)
Before (ad-hoc):
Henry: "research X"
Ming: delegate_task(goal="research X", context="maybe some files...")
โ Subagent starts blind, guesses context, inconsistent output
After (structured handoff):
Henry: "research X"
Ming: reads project context โ generates handoff brief โ delegate_task(goal=brief.goal, context=brief.full_context)
โ Subagent has precise context, knows deliverable format, knows what NOT to do
Step 1: Create Handoff Skill โ
- File: skills/coaching/handoff-template/SKILL.md
- Defines handoff brief schema (goal, context, deliverable, constraints, files)
- Defines when to generate handoff (before every delegate_task call)
Step 2: Create Handoff Template โ
- File: skills/coaching/handoff-template/templates/brief.md
- Structured template with sections: Goal, Background, Deliverable, Constraints, Files to Read, Files to Write
Step 3: Write Validation Script โ
- File: skills/coaching/handoff-template/scripts/validate-handoff.py
- Checks required sections, goal length, constraint "don't", file paths, total length
- Tested: catches missing sections + missing constraints
Step 4: Test with Real Delegation - Pick 2-3 recent delegation tasks from session history - Generate handoff briefs for them - Compare output quality with/without brief
| File | Purpose |
|---|---|
skills/coaching/handoff-template/SKILL.md |
Skill definition + usage instructions |
skills/coaching/handoff-template/templates/brief.md |
Handoff brief template |
skills/coaching/handoff-template/scripts/validate-handoff.py |
Post-hoc validation |
~~This project is in research phase.~~ โ MVP plan ready. See above.
Henry's direction: all directions are correct, but handoff template is the simplest MVP that proves the coordination-layer concept.
| Ch | Title | Source | Sandbox Path |
|---|---|---|---|
| 02 | Is One AI Not Enough? (Butler/Assistant) | link | _sandbox/sessions/2026-07-15-fibon-ch2/chapter02-raw.md |
| 03 | How Does an AI "Remember" You? (Memory) | link | _sandbox/sessions/2026-07-14-fibon-memory/fibon-ch03-memory.md |
| 04 | Why an LLM's Confidence Isn't Evidence (Trust) | link | _sandbox/sessions/2026-07-14-fibon-memory/fibon-ch04-trust.md |
| 05 | Can an AI Modify Its Own Source Code? (Self-Evolving) | link | _sandbox/sessions/2026-07-14-fibon-memory/fibon-ch05-evolving.md |
| 06 | How Do You Safely Run Untrusted Code? (Sandbox) | link | _sandbox/sessions/2026-07-15-fibon-ch6/chapter06-raw.md |
| 07 | Not a Plan, but a Pause Button I Could Press (Plan vs Improvise) | link | _sandbox/sessions/2026-07-15-fibon-ch7/chapter07-raw.md |
| Date | Title | Source | Key Insight |
|---|---|---|---|
| 2026-07-17 | Claude Code ๆบ็ขผ่ธ้คพ โ Harness Engineering ๅฏฆ่ธ่จ้ | ็ฅไน | Filesystem coordination, taste injection via base vectors, severity convergence tracking |
vps-project-context, hermes-agent, memory-management