Explore Brigade-inspired harness receipts, context packs, and memory care

[phernandez]

Why

PR #1070 gives Basic Memory a core-owned front door for local harness capture. Brigade explores several adjacent patterns that could make that lifecycle more observable, portable, and trustworthy.

We should evaluate those patterns selectively against Basic Memory's existing graph, MCP tools, plugins, schemas, and local-first source-of-truth model. This is not a proposal to depend on Brigade or reproduce its entire control plane.

Source: https://github.com/escoffier-labs/brigade

Patterns worth evaluating

1. Receipt-first lifecycle observability

Brigade records plain-file receipts for consequential operations and grounds outcomes in real command exit codes rather than model self-assessment.

Potential Basic Memory adaptation:

• Persist a safe flush receipt for each hook projection run.
• Record input count, projected notes, skipped envelopes, failed envelopes, warnings, timestamps, and version information.
• Let bm hook status and diagnostics link to the latest receipt.
• Keep receipts local, redacted, inspectable, and independently pruneable.

References:

• https://github.com/escoffier-labs/brigade#what-it-does
• https://github.com/escoffier-labs/brigade/blob/main/docs/closeout-receipts.md

2. Evidence-backed harness capability contracts

Brigade separates vendor-native support from hook-composed, extension-composed, and adapter-provided behavior. Its contract fixtures carry provenance, tested versions, platforms, and evidence instead of inferring support from a directory or executable being present.

Potential Basic Memory adaptation:

• Define a small harness capability contract for Codex, Claude Code, Hermes, and OpenClaw.
• Distinguish native host capabilities from plugin launchers and Basic Memory core behavior.
• Add isolated conformance probes for hook discovery, MCP discovery, settings resolution, session payload shape, and status reachability.
• Make plugin validators consume the same contract instead of relying only on string assertions.

Reference:

• https://github.com/escoffier-labs/brigade/blob/main/docs/research/issue-258-harness-contract-v1.md

3. Review-gated promotion and normalized ingestion receipts

Brigade keeps captured handoffs in per-harness inboxes, lints and redacts them, records provenance, and leaves ambiguous items pending instead of silently promoting them into canonical memory. It also normalizes ingestion receipts so skipped, failed, malformed, and unreachable sources remain visible.

Potential Basic Memory adaptation:

• Evaluate an optional review-required projection policy alongside automatic projection.
• Preserve envelope provenance and source fingerprints on every projected note.
• Surface malformed, skipped, and failed items without blocking the agent hook.
• Support dismiss-until-changed behavior for repeated known failures.

Reference:

• https://github.com/escoffier-labs/brigade/blob/main/docs/handoff-promotion.md

4. Bounded context packs

Brigade builds privacy-filtered context packs containing safe summaries, acceptance criteria, source references, and freshness state. It excludes raw chats, secrets, private paths, and scanner output by default.

Potential Basic Memory adaptation:

• Compare this model with build_context and SessionStart briefs.
• Explore a reproducible context-pack artifact with explicit source notes, graph depth, freshness, exclusions, and a stable fingerprint.
• Add a doctor/status check for stale or missing source references.
• Keep raw note contents in Basic Memory; packs should be bounded projections, not a second source of truth.

Reference:

• https://github.com/escoffier-labs/brigade/blob/main/docs/context-packs.md

5. Read-only memory care

Brigade scans durable memory for stale, expired, undersourced, orphaned, oversized, or incompletely indexed cards, then produces a review queue without editing canonical memory.

Potential Basic Memory adaptation:

• Reuse Basic Memory schemas and the existing memory-curate, memory-reflect, and memory-schema skills.
• Add a deterministic read-only diagnostic for metadata freshness, missing schema coverage, orphan notes, broken source references, and oversized notes.
• Produce stable findings and suggested acceptance criteria.
• Keep repair and archival explicit.

Reference:

• https://github.com/escoffier-labs/brigade/blob/main/docs/memory-care.md

6. Verified skill learning as a later experiment

Brigade ranks skill effectiveness using real verification receipts and cohort-aware scoring. Basic Memory should not become a task runner, but it could store and analyze externally supplied verification receipts.

Potential Basic Memory adaptation:

• Define a receipt schema that another harness can write after tests or checks.
• Relate receipts to the skills, context packs, and sessions involved.
• Only explore scoring after enough real observations exist.
• Never let a model's self-score promote a skill.

Non-goals

• No Brigade runtime dependency.
• No general multi-agent router, MCP catalog manager, secret-sync system, code graph, or local daemon.
• No replacement for Markdown files as Basic Memory's canonical source of truth.
• No automatic mutation of durable notes from ambiguous or unsafe captured content.
• No skill ranking based on model opinion.
• No implementation before checking for overlap with current hook WAL, projector, schemas, diagnostics, and shared memory skills.

Deliverable

Produce a short design note or SPEC with an adopt / adapt / reject table for the patterns above. For each candidate, identify:

• the existing Basic Memory capability it extends or duplicates
• the correct ownership layer: core, MCP, plugin, shared skill, or external harness
• privacy and retention implications
• the smallest independently useful implementation slice
• the receipt or test that would prove it works

Prioritize the receipt/status and harness-contract slices first. Split accepted implementation work into focused follow-up issues rather than turning this investigation into a broad rewrite.

Acceptance criteria

• Current Basic Memory behavior is inventoried before proposing new components.
• Every Brigade pattern receives an explicit adopt, adapt, or reject decision with rationale.
• The proposal preserves local-first operation, explicit writes, redaction, and Markdown source-of-truth rules.
• At least one thin vertical slice has concrete data shapes, commands, tests, and migration/compatibility notes.
• Out-of-scope control-plane features are clearly rejected or deferred.

[claude]

Claude finished @phernandez's task in 1m 20s —— View job

---

Triage complete

• Read issue and repo context
• Classify type, priority, component, complexity
• Check for duplicate issues
• Apply labels
• Post triage summary

Type: Enhancement — this is an investigation/design-note request, not a bug or a request for immediate implementation. It asks for an adopt/adapt/reject analysis of six Brigade-inspired patterns (receipts, harness capability contracts, review-gated promotion, context packs, memory care, verified skill learning) against Basic Memory's existing hook WAL, projector, schemas, diagnostics, and shared skills.

Priority: Medium. Nothing broken, no user-facing regression — this is forward-looking scoping work that builds on the recently-landed local harness capture front door (PR #1070). Valuable to unblock future work, but not urgent.

Component: Cross-cutting — spans core (hook projector/WAL, diagnostics), MCP tools (build_context, session prompts), CLI (bm hook status), and the shared plugin/skill packages (Claude Code, Hermes, OpenClaw). The repo's label set doesn't have a single tag for "cross-cutting," so I left component labeling at enhancement.

Complexity: Complex. The issue itself scopes the deliverable correctly — a design note/SPEC with an adopt/adapt/reject table, not code — and explicitly asks that any accepted work be split into focused follow-up issues rather than one broad rewrite. That framing is right-sized for the ambition here.

Duplicate check: Searched open/closed issues for "brigade", "receipt", "context pack", "memory care", and "harness capability contract" — no existing issue overlaps. This is net-new.

Labels applied: enhancement (the repo's label set doesn't include hyphenated priority/complexity/component variants like medium, complex, or mcp, so those were skipped as unknown; needs investigation was already present on the issue).

No clarification needed from the reporter — the issue is unusually well-specified (explicit non-goals, acceptance criteria, and a required thin-vertical-slice deliverable). Per scope, stopping here at triage; no branch, file edits, or SPEC drafting performed.