| name | hmem-new-error |
| description | Create a new E-entry (bug/error) in hmem with the strict 5-level scaffold. Use when the user wants to log a bug, file a report, or document an error ('Bug loggen', 'log this error', 'Fehler eintragen'), or before any write_memory with prefix='E'. |
/hmem-new-error — New Error Entry
E-entries use a fixed 6-section schema (Analysis → Possible fixes → Fixing attempts → Solution → Cause → Key Learnings). The server auto-scaffolds all sections — you only need to provide a title and a flat description.
The one rule: NO TABS in the description
The parser treats every tab-indented line as a structural node. Tabs in the description accidentally create invalid L2 nodes. Write the description as flat text after a blank line:
✅ write_memory(
prefix="E",
content="Short bug title\n\nFlat description of what went wrong. No tabs here.",
tags=["#project", "#area", "#open"],
links=["P00XX"]
)
❌ write_memory(
prefix="E",
content="Short bug title\n\nDescription:\n\tStep 1 caused X\n\tStep 2 failed",
...
)
The ❌ example creates invalid L2 nodes (Step 1 caused X, Step 2 failed) that fail schema validation.
Step 1: Collect the information
Ask the user (or extract from context):
| Field | Notes |
|---|
| Title | Short, descriptive. Max ~50 chars. Format: What broke / where |
| Description | What happened, what was observed. Flat text, no tabs. |
| Tags | At least #open + 2–3 topic tags. |
| Links | Which P-entry does this belong to? (P00XX) |
Step 2: Write the entry
write_memory(
prefix="E",
content="<title>\n\n<flat description>",
tags=["#open", "#tag1", "#tag2"],
links=["P00XX"]
)
The server auto-creates:
- .1 Analysis (your description moves here automatically)
- .2 Possible fixes
- .3 Fixing attempts
- .4 Solution
- .5 Cause
- .6 Key Learnings
The write response shows the created ID (e.g. E0149) and a #open tag.
Step 3: Fill in what you know
Use append_memory to add detail to the sections you can already fill:
append_memory(id="E00XX.1", content="Root cause hypothesis: ...") # Analysis
append_memory(id="E00XX.2", content="Try X first, then Y") # Possible fixes
Leave empty sections alone — Haiku fills them at the next checkpoint, or you fill them as debugging progresses.
Step 4: When solved
update_memory(id="E00XX", content="<title> #solved", tags=["#solved", "#tag1", "#tag2"])
append_memory(id="E00XX.4", content="Final fix: ...") # Solution
append_memory(id="E00XX.5", content="Root cause: ...") # Cause
append_memory(id="E00XX.6", content="Key learning: ...") # Key Learnings
The Key Learnings section auto-creates an L-entry when updated (reaction rule in hmem.config.json).
Common mistakes
| Mistake | Fix |
|---|
| Tab-indented body text | Write flat text after the blank line — no tabs |
| Section names as L2 nodes | Don't write \tAnalysis\n\t\tdetail — auto-scaffold does this |
Forgetting #open tag | Always include #open — it's how bugs are tracked |
| Too long title | Keep title under 50 chars; detail goes in the body |