get_relevant_memory returns zero records at any request size: the response envelope alone exceeds the context budget

[orenlab]

get_relevant_memory returns zero records at any request size: the response envelope alone exceeds the context budget.

Summary

On a repository with a populated Engineering Memory store, get_relevant_memory returns
records: [] regardless of max_records, because context_governance.estimated exceeds
context_governance.limit before any record is emitted. The metadata crowds out the
content it is supposed to describe.

The tool is honest about it — truncated: true, mandatory_overflow: true, and every
omitted lane carries a working continuation cursor. Nothing is silently lost. But the
mandatory pre-edit step of the change-control workflow returns no memory to the agent,
and the agent has to notice the empty lanes and issue extra paged calls to see anything
at all.

Reproduction

Minimal case — scope of a single file, max_records=1:

request   scope = [<one production file>], max_records = 1, detail_level = compact
available records 7 · experiences 8   (per the response's own continuation lanes)
returned  records 0 · experiences 0

context_governance:
  limit               2200
  estimated           2403
  truncated           true
  mandatory_overflow  true
  mode                partial_enforce

Wider scope, same outcome:

request   intent_id from start_controlled_change (17 declared paths), max_records = 8
coverage  record_coverage 100% (17 of 17 scope paths have memory)
available records 163 · trajectories 333 · experiences 42
returned  0 · 0 · 0
estimated 3127 vs limit 2200

Asking for one record yields zero. Asking for eight yields zero. The overflow is not a
function of the requested content.

Where the budget goes

The response contains no records, yet is estimated at 2403 units against a 2200 limit.
The payload is entirely envelope:

• two base64 continuation cursors, roughly 1 KB each, one per omitted lane — and each
  cursor is emitted twice, once under continuation.lanes.<lane>.page.cursor and
  again under _continuation.lanes[];
• context_governance.drill_down — seven entries describing retrieval routes for object
  kinds not present in this response;
• context_governance.capabilities, retrieval_policy, omitted, store_provenance.

The duplicated cursor alone accounts for a large share of the overflow.

Why this matters

get_relevant_memory is a mandatory step in the documented change-control workflow,
called immediately after start_controlled_change returns edit_allowed: true. Its
purpose is to put contract warnings, stale decisions and contradiction notes in front of
the agent before it edits.

In the observed state that step completes successfully and shows nothing. An agent that
does not inspect continuation.lanes.*.total will conclude there is no relevant memory —
when in fact 163 records with 100% scope coverage were available.

This is the "the step ran" versus "the step delivered" distinction: the call is
executed, the result is empty, and only the omitted-lane counters distinguish the two.

Suggested directions (not prescriptive)

1. Reserve budget for content. Guarantee at least one record before envelope fields
   are serialised, or account for the envelope first and spend the remainder on records.
2. Do not emit the same cursor twice. continuation.lanes.<lane>.page.cursor and
   _continuation.lanes[].cursor carry identical values; one of them can be a reference.
3. Emit drill_down entries only for kinds present in the response, or move the
   route table into help(topic="engineering_memory") where it is static documentation
   rather than per-response payload.
4. If the envelope genuinely cannot fit alongside content, consider making the
   zero-content case an explicit typed outcome rather than an empty list, so a caller
   cannot mistake it for "no memory for this scope".

Environment

• CodeClone 2.1.0a2, report schema 3.1
• Engineering Memory store: 302 approved records, store_resolution: main_checkout
• context_governance.contract_version 1.0, estimator: utf8_bytes_div_4_v1
• Observed through the MCP surface during a normal change-control cycle.