feat(plugin): manifest-driven budget-aware recall injection for OpenClaw

[hurttlocker]

Summary

Add manifest-driven, budget-aware recall injection for the OpenClaw plugin so Cortex can choose the best mix of raw memories, summaries, and other compact cues under a hard prompt budget.

Why

Today the OpenClaw plugin auto-recall path is mostly "search -> dedupe -> inject top N". That works, but it is not explicitly budget-aware. Once summary packing exists, Cortex should decide what kind of context to inject based on a budget manifest rather than just raw ranking.

This is the part of the ByteRover pattern worth stealing: budget-aware context packing, not the cloud/service dependency model.

Desired outcome

Before before_agent_start injects context, the plugin should be able to build a small manifest like:

• budget class / token cap
• direct memories selected
• summary nodes selected
• ghost/archive cues selected
• items dropped due to budget pressure

This should make recall more deterministic, observable, and cheaper.

Proposed scope

• Introduce a recall manifest / packing plan step before context injection
• Let the plugin choose among raw memories vs compressed summary artifacts under a budget cap
• Make the selection deterministic and testable
• Expose the behavior through plugin config + docs

Acceptance criteria

• Plugin supports a configurable recall budget/cap or budget class
• before_agent_start builds a manifest before injection
• Manifest can mix multiple context artifact types (raw + summary, later ghost cues)
• Injected context stays under the target budget with deterministic selection behavior
• Plugin docs explain how the budget-aware packing works
• Tests cover selection behavior under tight vs relaxed budgets

Implementation hints

Relevant current surfaces:

• plugin/index.ts (before_agent_start) currently handles auto-recall
• current config knobs: autoRecall, recallLimit, minScore, searchMode
• plugin/openclaw.plugin.json is the schema surface

Out of scope

• Remote prompt-packing services
• Hidden opaque heuristics with no observability
• Replacing Cortex search/ranking with a pure prompt-template hack

[hurttlocker]

Promoting this as the immediate follow-on after #321, but only as a bounded Slice A for the next version.

Slice A scope for this sprint:

• add a recall budget knob (recallBudgetChars or equivalent)
• build a small recall manifest before injection
• deterministically choose / drop recall items under a hard budget
• use existing raw retrieval results only
• keep selection behavior observable + testable

Explicitly out of scope for Slice A:

• no persistent summary storage
• no full hierarchical summary packing (feat(context): hierarchical summary packing for prompt-ready recall #318 full)
• no ghost cues / archive stubs (feat(search): ghost cues + archive stubs for long-tail memory resurfacing #320)
• no vendor/cloud memory service behavior

Goal: make OpenClaw recall cheaper and more deterministic without widening this into a deeper storage-layer redesign in the same sprint.

[hurttlocker]

Q merged #322, so this is now the active next slice.

Reminder on product intent:

• steal the useful operator pattern from the external reference
• but custom-implement it for Cortex/OpenClaw's local-first architecture
• do not clone the whole system or widen this into a storage redesign

Slice A remains tightly bounded:

• recall budget knob
• recall manifest before injection
• deterministic keep/drop under hard budget
• existing raw retrieval only
• observable/testable selection behavior

Still out of scope:

• persistent summary storage
• full feat(context): hierarchical summary packing for prompt-ready recall #318 hierarchical summary packing
• feat(search): ghost cues + archive stubs for long-tail memory resurfacing #320 ghost cues/archive stubs
• cloud/vendor memory behavior

[hurttlocker]

Release-board hygiene note:

• Slice A shipped via PR feat(plugin): add bounded recall manifest budget selection (#319 slice A) #323
• manifest-driven budget-aware recall injection is partially delivered
• broader issue scope remains intentionally open for follow-on work
• this should be treated as partially shipped / non-blocking for v1.2.4 release packaging