feat(improvement): add curated memory surface

[drewstone]

Problem

The one-call improvement API covered prompt, skills, configuration, rollout policy, and code, but curated agent memory still required product-owned orchestration. Review-only proposals also needed to deny memory persistence just like skill persistence.

Solution

• add surface: 'memory' using agent-eval 0.114's deterministic memoryCurationProposer
• measure an external lesson document and await writeback only after promotion
• preserve curator-readable findings and reject non-text winners
• block skill and memory writeback before human approval
• remove the stale duplicate optimization map and regenerate the canonical API docs
• prepare runtime 0.93.0 with current eval/interface/knowledge/profile dependencies

Proof

• 149 test files passed: 1,492 passed, 2 skipped
• focused memory and approval tests: 30/30 passed
• build, typecheck, lint, package-export verification, docs check, and diff check passed
• independent adversarial review: APPROVE, zero remaining findings
• merge-tree against current origin/main succeeded

[tangletools]

✅ Auto-approved drewstone PR — fd777543

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-11T20:08:45Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	301.4s (2 bridge agents)
Total	301.4s

💰 Value — sound

Adds a memory-curation surface to the improve() facade following the exact skills-surface template, delegating curation to agent-eval 0.114's memoryCurationProposer; ships cleanly in the codebase's grain with no existing equivalent to duplicate.

• What it does: Adds surface: 'memory' to the improve() one-call RSI facade. The caller supplies opts.memory.document (current durable memory text) + optional opts.memory.writeBack. The facade wires it to agent-eval 0.114's deterministic memoryCurationProposer(), measures the curated document against scenarios under the held-out gate, and on a ship verdict persists the promoted text via writeBack (profi
• Goals it achieves: Completes improve()'s surface coverage — memory was the last major agent lever without a zero-config default proposer (prompt, skills, code, rollout-policy all had defaults). Moves memory curation from product-owned orchestration into the same measured, gate-decided, one-call loop. Tightens the writeback contract: async-aware, type-strict, and review-gated for both external-document surfaces. Bump
• Assessment: Squares perfectly with the codebase's grain. improve() is architected as a surface-pluggable dispatcher: each surface maps to a default proposer (defaultGeneratorFor), a baseline extractor (baselineSurfaceFor), and a writeback strategy. Memory slots into this template identically to skills. The actual curation logic lives in the substrate (agent-eval's memoryCurationProposer), so the runtime stays
• Better / existing approach: none — this is the right approach. Checked for existing memory-curation/optimization capabilities: agent/surfaces.ts:213 maps memory keys to JSON file paths (storage layout, not curation); src/intelligence/resolver.ts:297 provisions memory-store backends (infrastructure, not optimization); src/index.ts:124 explicitly delegates KB/RAG/memory state to agent-knowledge. The improvement memory surface
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

A coherent 4th default-proposer surface (prompt/skills/memory/rollout-policy) that mirrors the established skills-document precedent exactly and is fully reachable through both public entry points.

• Integration: Fully wired and reachable. memoryCurationProposer is exported from agent-eval 0.114's campaign index (verified in the published dist at .../agent-eval/0.114.0/.../dist/campaign/index.js:34,175). The surface threads through every seam: ImproveSurface adds 'memory' (src/improvement/improve.ts:87), ImproveMemoryOptions is defined (improve.ts:160-165) and re-exported (src/improvement/index.ts:23
• Fit with existing patterns: Follows the established skills-document grain precisely. ImproveMemoryOptions mirrors ImproveSkillsOptions (document + writeBack), the writeback unification at improve.ts:609-610 collapses skills and memory into one externalDocument code path, and applyWinnerToProfile returns the profile unchanged for memory (improve.ts:470-471) — the same external-persistence shape as code surface. Th
• Real-world viability: Robust beyond the happy path. Non-text winners are rejected before persistence with a fail-loud ConfigError (improve.ts:612-616, tested in improve.test.ts). Held candidates never trigger writeback because the call is gated on shipped && externalDocument (improve.ts:611, tested). writeBack is typed void | Promise<void> and awaited (improve.ts:617), supporting async persistence. The `memoryGen
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260711T201538Z}