feat(monorepo): import repo-memory runtime

docs/implementation-roadmap.md

@@ -41,7 +41,8 @@ As of now:
 - `packages/coord-core` now exists as the first real extracted runtime package, containing shared coordination DB/schema, protocol, and store code, and the active coordination runtimes now import `coord-core` instead of root `internal/db`, `internal/store`, and `internal/protocol`
 - `packages/inbox-runtime` and `packages/orch-runtime` now exist as package-owned runtimes with their own `cmd/` entrypoints and package-local CLI wiring/tests, and the root skill packaging flow now builds `skills/inbox`, `skills/orch`, and `skills/council-review` from package entrypoints instead of root `cmd/` paths
 - `packages/orchd-runtime` now exists as the package-owned HTTP/query/web backend runtime, with package-local `cmd/orchd`, app, query, and HTTP transport code plus passing package-local tests
-- a repo-local `scripts/package_skill_clis.sh` packaging flow now builds bundled skill CLI assets for `inbox`, `orch`, and `council-review`
+- `packages/repo-memory-runtime` now exists as the package-owned `briefdb` runtime imported from the exploratory prototype, `skills/repo-memory` now exists as an agent-facing skill bundle, and the declarative root packaging flow now builds a bundled `skills/repo-memory/assets/briefdb` binary from the package runtime
+- a repo-local declarative packaging flow now builds bundled skill CLI assets for `inbox`, `orch`, `council-review`, and `repo-memory`
 - `orch` now implements `run init/show`, `task add`, `dep add`, `ready`, `dispatch`, `reconcile`, `wait`, `blocked`, `answer`, `retry`, `reassign`, `cancel`, `cleanup`, and `status`
 - `orch` can create runs, gate tasks through dependencies, dispatch work through `inbox`, reconcile worker thread state back into task state, answer blocked tasks, retry or reassign work, cancel tasks or runs, clean attempt worktrees, and create per-attempt Git worktrees during strict dispatch
 - `orch dispatch` now supports `--repo-path`, `--workspace-root`, and `--strict-worktree`, auto-enables strict worktree mode for code-like tasks inferred from task metadata, resolves committed base revisions, records workspace metadata on attempts, and writes that metadata into inbox task payloads
@@ -509,11 +510,14 @@ Completed so far:
 - `scripts/package_skill_runtimes.sh package` now builds and installs `skills/inbox/assets/inbox`, `skills/orch/assets/orch`, and `skills/council-review/assets/orch` from package entrypoints
 - the legacy `scripts/package_skill_clis.sh` entrypoint now delegates to the declarative package-oriented packaging flow instead of hardcoding root `cmd/` paths
 - `packages/orchd-runtime/cmd/orchd` plus `packages/orchd-runtime/internal/{app,httpapi,query}` now provide a package-owned web backend runtime and pass `go test ./...`
+- `packages/repo-memory-runtime/cmd/briefdb` plus its package-local `internal/brief` and `internal/store` now provide a package-owned repo-memory runtime and pass `go test ./...`
+- `skills/repo-memory/` now exists with `SKILL.md`, `agents/openai.yaml`, and a bundled `assets/briefdb` binary produced by the declarative packaging flow
+- `docs/tests/repo-memory-skill/` now exists with a README plus an initial forward-test case covering search-before-add and durable entry retrieval through the bundled skill
 
 Remaining:
 
-- import `repo-memory` as its own runtime package and add the corresponding skill bundle
-- graduate the bundle scaffold into the primary packaging flow once package-owned runtime entrypoints exist
+- remove or reduce the remaining legacy root runtime ownership under `cmd/` and `internal/`
+- decide whether the external `../tmp/briefdb` prototype should be archived, documented as superseded, or deleted after the package import is considered stable
 
 ## Immediate Next Task
 
@@ -522,11 +526,11 @@ If a new agent is taking over now, the next concrete step should be:
 1. treat `Milestone 9: Web Product Phase 2 Read-Only Operator UI` as complete for the initial operator surface and do not expand web feature scope further until the workspace split is decided package-by-package
 2. treat the Phase 1 workspace bootstrap for `Milestone 10` as complete and keep the new `go.work`, `packages/`, and declarative bundle metadata as the baseline for all further migration steps
 3. treat the shared coordination kernel extraction into `packages/coord-core` as complete and move `inbox` plus `orch` into package-owned runtimes next
-4. treat `inbox-runtime`, `orch-runtime`, and `orchd-runtime` as package-owned and import `repo-memory` next so the last planned runtime package joins the workspace
-5. add `skills/repo-memory` and the corresponding forward-test plan once the runtime import is in place
-6. keep the authored skill forward-test plans under `docs/tests/*-skill/` synchronized as runtime ownership moves from root paths to package paths
+4. treat `coord-core`, `inbox-runtime`, `orch-runtime`, `orchd-runtime`, and `repo-memory-runtime` as the package-owned runtime baseline and start Phase 6 by removing or shrinking the remaining root-owned runtime paths
+5. keep the authored skill forward-test plans under `docs/tests/*-skill/` synchronized as runtime ownership moves from root paths to package paths
+6. decide how to retire or archive the external `../tmp/briefdb` prototype once the imported runtime is stable enough to be the sole source of truth
 
-The inbox implementation and its human-readable test-plan set are already in place, `orch` supports the main scheduler loop plus the complete council start/wait/tally/report workflow, the web product now has its first real operator-facing read surfaces, and the repository has completed the workspace bootstrap plus the shared coordination, inbox, orch, and orchd package-runtime extraction phases of the skill monorepo migration, so the next step should be importing `repo-memory` and then removing legacy root ownership, not continuing to accrete new root-owned runtime paths.
+The inbox implementation and its human-readable test-plan set are already in place, `orch` supports the main scheduler loop plus the complete council start/wait/tally/report workflow, the web product now has its first real operator-facing read surfaces, and the repository has completed the workspace bootstrap plus the shared coordination, inbox, orch, orchd, and repo-memory package-runtime extraction phases of the skill monorepo migration, so the next step should be removing legacy root ownership and finalizing source-of-truth boundaries rather than continuing to accrete new root-owned runtime paths.
 
 ## Recommended Driver Choices
 

docs/roadmaps/active/skill-workspace-monorepo-migration.md

@@ -29,7 +29,7 @@
 - [x] Phase 2: extract shared coordination code into `packages/coord-core`
 - [x] Phase 3: extract `inbox-runtime` and `orch-runtime`
 - [x] Phase 4: extract `orchd-runtime`
-- [ ] Phase 5: import `repo-memory-runtime` and add `skills/repo-memory`
+- [x] Phase 5: import `repo-memory-runtime` and add `skills/repo-memory`
 - [ ] Phase 6: remove root runtime ownership and normalize package-based packaging
 
 ## Files
@@ -54,4 +54,4 @@
 
 ## Next Step
 
-- start Phase 5 by importing the exploratory `repo-memory` runtime into `packages/repo-memory-runtime`, adding `skills/repo-memory`, and wiring it into the declarative bundle packaging flow
+- start Phase 6 by removing or reducing legacy root runtime ownership now that `coord-core`, `inbox-runtime`, `orch-runtime`, `orchd-runtime`, and `repo-memory-runtime` all exist as package-owned runtimes

docs/tests/repo-memory-skill/README.md

@@ -0,0 +1,70 @@
+# Repo Memory Skill Test Plan
+
+## Purpose
+
+This directory tracks human-readable test plans for the `skills/repo-memory/`
+Codex skill bundle.
+
+These documents are not package-level unit tests for `briefdb`.
+Those live with the runtime under `packages/repo-memory-runtime/`.
+
+This directory covers a different surface:
+
+- whether an agent can actually use the packaged `repo-memory` skill
+- whether the bundled `./assets/briefdb` CLI works inside real skill-guided
+  repository work
+- whether durable repository knowledge is stored and retrieved correctly
+
+## Test Model
+
+- `README.md` is the index for this directory
+- each skill test case lives in its own Markdown file
+- use stable case slugs in filenames
+
+## Shared Execution Contract
+
+Use these defaults unless a case file explicitly overrides them:
+
+- run the scenario with one real agent using the bundled `repo-memory` skill
+- create an isolated temporary directory, repository fixture, and SQLite DB path
+- require the agent to use the bundled `./assets/briefdb` CLI instead of ad hoc
+  notes
+- validate final database state independently from the main thread after the
+  agent stops
+
+## Per-Case Template
+
+Each case file should use this structure:
+
+- `Test Type`
+- `Purpose`
+- `Preconditions`
+- `Inputs`
+- `Execution Parameters`
+- `Execution Steps`
+- `Validation Commands`
+- `Expected Outcomes`
+- `Assertions`
+- `Cleanup`
+- `Recorded Example Run` when a real run has already been captured
+
+## Case Files
+
+| Case Slug | File | Coverage Note |
+| --- | --- | --- |
+| `search-and-add-through-bundled-cli` | [search-and-add-through-bundled-cli.md](./search-and-add-through-bundled-cli.md) | validates that an agent can miss on search, add one durable entry, then retrieve it through the packaged `repo-memory` skill |
+
+## Scope
+
+In scope:
+
+- explicit `$repo-memory` skill invocation
+- bundled `./assets/briefdb` CLI usage
+- durable knowledge add/search/list/event flows
+- package-backed SQLite memory database behavior as surfaced through the skill
+
+Out of scope:
+
+- package-level unit tests for `briefdb`
+- future auto-export flows such as `repo-brief` generation
+- implicit skill triggering without `$repo-memory`

docs/tests/repo-memory-skill/search-and-add-through-bundled-cli.md

@@ -0,0 +1,70 @@
+# Search And Add Through Bundled CLI
+
+## Test Type
+
+- forward skill execution
+
+## Purpose
+
+- validate that a single agent can use `skills/repo-memory/` to search an empty
+  memory DB, write one durable entry through the bundled CLI, and retrieve the
+  same knowledge afterwards
+
+## Preconditions
+
+- `skills/repo-memory/assets/briefdb` exists and is executable
+- the test runner can create a temporary Git repository fixture
+- the test runner can create a temporary SQLite DB path
+
+## Inputs
+
+- `SKILL_PATH=/.../skills/repo-memory`
+- `TMPDIR=/tmp/...`
+- `DB_PATH=TMPDIR/repo-memory.db`
+- `REPO_PATH=TMPDIR/repo-fixture`
+
+## Execution Parameters
+
+- one agent only
+- per-agent timeout: `3m`
+- overall timeout: `4m`
+
+## Execution Steps
+
+1. Create a temporary Git repository fixture under `REPO_PATH`.
+2. Add one file that will serve as evidence for the durable knowledge entry.
+3. Ask the agent to use `$repo-memory` against `DB_PATH`.
+4. Have the agent initialize the DB, search for a key that does not yet exist,
+   add one `term` entry with evidence, then search again for the same key.
+5. Capture the agent summary and the concrete entry key used.
+
+## Validation Commands
+
+Run these from the main thread after the agent stops:
+
+```bash
+SKILL_PATH/assets/briefdb init --db DB_PATH
+SKILL_PATH/assets/briefdb search --db DB_PATH --repo REPO_PATH --query "plan task"
+SKILL_PATH/assets/briefdb list --db DB_PATH --repo REPO_PATH --kind term
+SKILL_PATH/assets/briefdb events --db DB_PATH --id 1
+```
+
+## Expected Outcomes
+
+- the first search misses before the entry is written
+- the `add` command succeeds and creates entry `1`
+- the second search returns the new `term`
+- `list` returns exactly one `term` entry for the fixture repo
+- `events` includes a `created` event for the new entry
+
+## Assertions
+
+- the stored entry key matches the one the agent added
+- the stored entry summary matches the durable fact the agent recorded
+- the stored entry is linked to the target repo path
+- the agent used the bundled CLI rather than free-form notes
+
+## Cleanup
+
+- keep the temporary DB and repo on failure
+- remove temporary artifacts on success only if replay evidence is not needed