Proposal: add harness-captured, LangMem-assisted repository dreaming to the `agent-ready-context` lifecycle

[rmonier]

Summary

Extend the existing agent-ready-context skill with an optional, evidence-grounded repository dreaming lifecycle.

Based on discussion #4

This proposal targets the stack introduced by the OpenWiki migration (#1): the staged OpenWiki lifecycle, the canonical okf/wiki/ OKF, and the INSTRUCTIONS.md preservation contract are its foundation.

The lifecycle should allow any compatible coding agent or harness that assimilates Agent Smith’s skills to:

• capture useful experience from repository work;
• retain that experience locally as episodic memory;
• consolidate related episodes into semantic and procedural candidates;
• detect stale, duplicated, contradictory, or poorly routed repository knowledge;
• generate rehearsal questions and hypothetical change scenarios;
• test retention, plasticity, transfer, and routing before promotion;
• promote verified semantic knowledge through the OpenWiki-maintained OKF wiki and its staged, reviewed lifecycle;
• promote verified procedures through skill-creator;
• improve the repository’s agent-ready surfaces over time.

The preferred memory-formation engine should be LangMem, used through its storage-independent functional API and a small file-in/file-out adapter.

LangMem should be treated as a preferred, replaceable vendor engine—not as a mandatory Agent Smith runtime.

The architecture should remain:

Existing coding agent or harness
        ↓ assimilates
Agent Smith's three portable skills
        ↓ configures
Harness-native capture projection
        ↓ writes
Local episodic memory files
        ↓ optionally invokes
LangMem or another compatible consolidation engine
        ↓ produces
Structured semantic/procedural candidates
        ↓ verified and rehearsed by
The assimilating agent
        ↓ promoted through
OpenWiki staged lifecycle / skill-creator

This proposal must not turn Agent Smith into:

• a standalone agent;
• an autonomous application;
• a daemon;
• a memory server;
• a scheduler;
• a LangGraph deployment;
• a transcript database;
• a fourth distributable skill;
• a replacement implementation of OpenWiki, LangMem, or a harness.

Agent Smith remains an automation and assimilation layer expressed as skills.

---

Product boundary: Agent Smith remains three skills

The entire distributable product remains:

.agents/skills/
├── agent-ready-context
├── skill-creator
└── subagent-profile-adapter

References:

• Agent Smith README
• agent-ready-context
• skill-creator
• subagent-profile-adapter

Their responsibilities should remain:

Skill	Responsibility
agent-ready-context	Orientation and the complete lifecycle of repository context, episodic capture, dreaming, canonical OKF maintenance, and memory-quality evaluation
skill-creator	Promotion of verified and transferable procedures into project Agent Skills
subagent-profile-adapter	Projection of Agent Smith policies into the active harness’s native profiles, subagents, hooks, plugins, and lifecycle configuration

Repository dreaming belongs inside agent-ready-context.

It is not a fourth action domain and must not become a separate distributable skill.

The other skills participate through their existing responsibilities:

• subagent-profile-adapter generates the native capture and optional memory-curator projections for the active harness;
• skill-creator receives procedural candidates after consolidation and verification.

Dreaming must never automatically modify:

• Agent Smith’s three product skills;
• the pinned OpenWiki tool or any other vendor implementation;
• the byte-preserved okf/wiki/INSTRUCTIONS.md contract;
• globally installed skills;
• unrelated user skills.

Problems discovered in those assets may be reported for an explicit upstream change, but they must not be treated as learned project memory.

---

Relationship to issue #1 (resolved by the OpenWiki migration)

This issue builds on:

• Proposal: migrate the canonical repository-memory OKF wiki from OpenKB + Graphify to OpenWiki #1 — resolved: OpenWiki (with native OKF v0.1 output) is the canonical repository-memory engine, operated through agent-ready-context’s staged, isolated lifecycle.

Issue #1 determined which engine owns the canonical repository-memory OKF wiki. This issue determines how repository experience should be captured, consolidated, evaluated, and promoted through that engine.

The separation is:

Concern	Owner
Canonical wiki engine and update contract	#1 (resolved: OpenWiki + INSTRUCTIONS.md)
Capture and normalize repository episodes	This issue
Consolidate and rehearse memory	This issue
Promote semantic memory	OpenWiki staged lifecycle / reviewed edits
Promote procedural memory	skill-creator
Generate harness-specific capture and subagent projections	subagent-profile-adapter

The current path is:

agent-ready-context
        ↓
staged, isolated OpenWiki run (okf/.okf-build/<run-id>/worktree/)
        ↓ citation gate + review.diff + transactional promote
directly maintained okf/wiki/ OKF memory

For reference, the legacy v0.1.0 path this replaced was:

agent-ready-context
        ↓
OpenKB vendor skill and CLI
        ↓
okf/raw/
        ↓
OpenKB-compiled okf/wiki/

The engine-specific write operation changed with the migration. The capture, consolidation, evidence, rehearsal, privacy, and promotion policies proposed here are engine-portable and must remain so.

Complete proposal: #4