01Safety
0.0 / 30
What changed in the harness
Selection accuracy 95→100, token cost up 3%, unconfirmed writes 0%→0%.
Category breakdown
Where the score comes from.
Earned points across the four signals Gradable measures. Safety and Legibility are scored out of 30; Economics and Discoverability are scored out of 20.
02Legibility
28.1 / 30
03Economics
19.9 / 20
04Discoverability
12.4 / 20
Highest-impact fix
Estimated gain +30 pointsAdd explicit identity and permission preflight tools
Expose machine-readable principal/tenant confirmation and a non-mutating permission check so agents can verify both before destructive actions.
Description evidence
Defects and rewrites.
1 defect found across the exposed tool descriptions. Suggested rewrites make purpose, inputs, boundaries, and returns easier for an agent to understand.
| Tool | Defect types | Suggested rewrite |
|---|---|---|
zipmem_checkpoint |
params_unexplained no_return_description |
Stage incremental progress for crash-safety during a session. Call this periodically after each meaningful unit of work (a feature wired up, a bug fixed, a decision made) so that an abrupt exit (Ctrl+C, closed terminal, crash) never loses more than the last few steps. Pass blueprints (verbatim architectural facts, schemas, or decisions to preserve), anchors (file-path and line-range coordinates that replace raw code blocks, each with a concept describing the structural change), and lessons (distilled bug fixes and gotchas, each with an optional detail and related files), plus a running one-line summary of progress so far. The data is buffered durably and folded into memory automatically at the next session if the current one ends without a clean compaction. It is cheap and does NOT finalize the session. Returns a confirmation that the checkpoint was staged successfully. |
Selection evidence
Confusable tool pairs.
3 pairs where similar names or overlapping descriptions may send an agent toward the wrong tool.
| Tool A | Tool B | Confidence | Why they collide |
|---|---|---|---|
zipmem_save_and_compact |
zipmem_checkpoint |
medium | Both write the same structured fields (blueprints/anchors/lessons) and are described as 'saving progress to memory', so a mid-session request like 'save our progress so it isn't lost' could select the wrong one. The distinguishing triggers (explicit exit/goodbye vs periodic) are only disambiguated if the agent reads the full descriptions carefully. |
zipmem_load_memory |
zipmem_save_and_compact |
low | Both mention long-term memory, but one loads at session start and the other saves on exit; a task like 'restore our memory' vs 'store this in memory' has a clear direction, and the descriptions mark them as opposite actions. |
zipmem_load_memory |
zipmem_checkpoint |
low | Load is reading context at session start (CALL THIS FIRST) while checkpoint is writing progress periodically; only a vague task mentioning 'checkpoint our memory/context' without save/load direction could misfire, which is unlikely given the explicit call-timing hints. |
Compare the field