v0.6.5 Epic — cortex-fluent — SUPERSEDED

"5 of 43 tools are advertised in tools/list under the current profile (core).
The other 38 are listed in this manifest but NOT directly callable.
To use any unloaded tool, choose one of:
  (a) restart the server with --profile <family> or --profile full,
  (b) call memory_load_family(family=<name>) — preferred, returns
      schemas + harness-aware loading instructions,
  (c) call the tool by name and recover from JSON-RPC -32601."

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task A1 (#545).

Goal: add a top-level `summary` field to the memory_capabilities v3 response.
The field carries a single pre-computed string that describes the LLM's
operational access — the count of currently-advertised tools, the count of
total tools, and the three named recovery paths for loading unloaded
families.

Current state: src/mcp.rs builds the capabilities document via a
`build_capabilities_v2(...)` function. v2 returns a manifest with
loaded:bool per tool but does NOT include a top-level summary string.

What to do:
1. Add a `build_capabilities_v3(...)` function alongside v2. v3 = v2 +
   one new top-level `summary` field of type String.
2. The summary string is dynamically built from the live profile state
   (use src/profile.rs for inspection). Its content must follow the
   template in v0.6.5 epic task A1 — see docs/v0.6.5/V0.6.5-EPIC.md.
3. Wire `accept="v3"` to the new builder; `accept="v2"` keeps the old
   builder. Default for new clients: v3.
4. Add unit tests in src/mcp.rs::tests covering each named profile
   (core, graph, admin, power, full, custom) — assert the summary
   string contains the expected counts and the three recovery-path
   markers.
5. Add an integration test in tests/mcp_integration that wires a real
   MCP request through stdio and asserts the response shape.
6. Do not modify v2 behavior. Backward compat is required.

Branch: feat/v0.6.5-a-1-summary-field
Commit: feat(mcp): add v3 capabilities summary field (#545)
PR title: feat: v0.6.5-A1 — memory_capabilities v3 summary field

Definition of done:
- `cargo test --lib mcp::` passes
- `cargo test --test mcp_integration` passes
- Calibration prompt produces a response with `summary` field present
- v2 response shape unchanged (verified by existing tests)

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task A2 (#545).
Depends on: A1 (build_capabilities_v3 function exists).

Goal: add a `to_describe_to_user` field to the v3 response. This is the
canonical plain-language sentence the agent should parrot when asked
"what tools do you have access to." Removing the calibration ambiguity
between Claude (under-claims) and Grok (over-claims) by giving the
LLM the words.

What to do:
1. Extend src/mcp.rs::build_capabilities_v3 to add the new field.
2. Build the string from active profile state — count of loaded tools,
   names of those tools, count of unloaded tools, two example unloaded
   tool names, plain-English description of how to load more.
3. Tone constraint: NO mcp jargon (no "advertised", "tools/list", "schemas").
   Use plain language an end-user would understand.
4. Add tests/calibration_t0.rs (new file) — a calibration test that
   simulates an MCP call and asserts the canonical phrasing is present.
5. Document the canonical phrasing in
   docs/v0.6.5/canonical-phrasings.md so doc reviewers can audit it.

Branch: feat/v0.6.5-a-2-describe-to-user
Commit: feat(mcp): add v3 to_describe_to_user field (#545)

Definition of done:
- v3 response carries the new field across all 6 profiles
- v2 response shape unchanged
- New tests/calibration_t0.rs passes
- canonical-phrasings.md exists and is reviewed

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task A3 (#545).
Depends on: A1.

Goal: add per-tool `callable_now: bool` field to v3 response.

`loaded` and `callable_now` are subtly different:
- loaded = server has the tool registered
- callable_now = THIS agent, given its agent_id and the [mcp.allowlist],
  can actually call this tool right now without any recovery dance

When allowlist is disabled (v0.6.4 default), they're identical. When
allowlist applies, callable_now reflects per-agent permission.

What to do:
1. Look at how src/profile.rs interacts with [mcp.allowlist] — extract a
   helper `agent_can_call(agent_id, family) -> bool` that mirrors the
   allowlist resolution rules (exact > longest-prefix > * wildcard).
2. In src/mcp.rs::build_capabilities_v3, populate callable_now for each
   tool by combining loaded-state with agent_can_call(agent_id, family).
3. Add unit tests covering the four matrix cells:
   - allowlist OFF, loaded TRUE  -> callable_now=TRUE
   - allowlist OFF, loaded FALSE -> callable_now=FALSE
   - allowlist ON, agent in pattern, loaded TRUE   -> callable_now=TRUE
   - allowlist ON, agent NOT in pattern, loaded TRUE -> callable_now=FALSE
4. Update v2 backward-compat path to NOT include callable_now.

Branch: feat/v0.6.5-a-3-callable-now
Commit: feat(mcp): add per-tool callable_now flag in v3 (#545)

Definition of done:
- 4-cell matrix unit tests pass
- v2 callers see no change
- Integration test confirms callable_now=loaded when no allowlist set

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task A4 (#545).
Depends on: A1, A3 (allowlist resolution helpers).

Goal: add agent_permitted_families top-level field to v3, surfaces
per-agent allowlist scope so multi-agent (T4-T5) deployments don't
get a global picture they can't act on.

What to do:
1. Reuse the agent_can_call helper from A3.
2. In src/mcp.rs::build_capabilities_v3, when [mcp.allowlist] is enabled,
   compute the list of families the requesting agent can access and
   include it as `agent_permitted_families`.
3. When the allowlist is disabled OR no agent_id was provided in the
   MCP initialize handshake, omit the field entirely.
4. Unit tests cover the three cases: disabled / enabled-with-agent /
   enabled-without-agent-id.

Branch: feat/v0.6.5-a-4-agent-permitted-families
Commit: feat(mcp): surface agent_permitted_families in v3 response (#545)

Definition of done:
- 3-case unit tests pass
- Field correctly omitted when allowlist disabled
- Field correctly populated for matching/wildcard agent patterns

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task A5 (#545).
Depends on: A1, A2, A3, A4 (all four v3 fields exist).

Goal: bump the capabilities schema to v3 in API_REFERENCE.md, SDKs, and
defaults. v2 + v1 remain valid for backward compat.

What to do:
1. Update src/mcp.rs `accept` enum: ["v1", "v2", "v3"], default = "v3"
   (was default = "v2" in v0.6.4).
2. Update sdk/typescript/src/types.ts: add MemoryCapabilitiesV3 type
   carrying the new fields. Retain MemoryCapabilitiesV2 type.
3. Update sdk/python/ai_memory/models.py: add MemoryCapabilitiesV3
   pydantic model. Retain V2.
4. Update docs/API_REFERENCE.md: new "v3 schema" subsection with
   field-by-field documentation of summary / to_describe_to_user /
   callable_now / agent_permitted_families. Add a "v2 → v3 diff"
   section near the top.
5. Add an integration test that asserts v3 is the new default when no
   `accept` parameter is supplied.
6. Update tests/mcp_integration.rs::test_capabilities_default_is_v3.

Branch: feat/v0.6.5-a-5-schema-v3
Commit: feat(mcp): bump capabilities schema to v3 default (#545)

Definition of done:
- v3 is the new default
- v2 clients see no behavior change (gated explicit accept="v2")
- SDKs build with new V3 types
- API_REFERENCE.md updated with v3 section

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task B1 (#545, #546).

Goal: add memory_load_family tool to the always-on family. The loader of
last resort gets a name that says "load."

Why: three real LLM observation cells in 2026-05-05 showed reasoning-class
agents looked for an explicitly-named loader, hypothesized one must exist,
didn't find one, and concluded a bootstrap limitation existed. The substrate
already has the loader (memory_capabilities with family= + include_schema=true)
but its name connotes introspection, not loading.

What to do:
1. Look at how src/mcp.rs registers the always-on family. Add memory_load_family
   to that registry.
2. The tool's schema is in the V0.6.5-EPIC task B1 description -- start with that.
3. The handler logic is mostly delegation: same logic as memory_capabilities
   when called with family=X, include_schema=true. Factor out a helper
   `build_family_schemas(family, harness_info)` that both tools call.
4. Add the harness_info detection (Task B4) — read MCP `clientInfo` from
   the server's MCP state; map known harness names to a HarnessProfile
   struct that knows whether deferred registration is supported.
5. Build the to_invoke field from harness_info: branch on
   supports_deferred_registration to produce the right hint.
6. Add unit tests in src/mcp.rs::tests covering each family.
7. Add integration tests that load a family from a Grok-CLI-shaped client
   (no deferred registration) and assert the to_invoke text recommends
   --profile X.
8. Add tests/calibration_t0.rs case that simulates "agent asks: how do I
   load a family?" and asserts the response references memory_load_family.

Branch: feat/v0.6.5-b-1-memory-load-family
Commit: feat(mcp): add memory_load_family tool to always-on family (#545, #546)

Definition of done:
- memory_load_family loadable + callable under every profile
- Returns schemas + to_invoke + your_harness_supports_deferred_registration
- Unit + integration tests pass
- t0-calibration test confirms LLMs find this tool when asked

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task B2 (#546).
Depends on: B1 (memory_load_family + harness detection).

Goal: add memory_smart_load(intent) — the intent-aware loader that closes
the curiosity gap completely. Agent asks "what do I need for X" in plain
language; substrate matches intent to family/families, returns schemas.

What to do:
1. Create src/intent_classifier.rs with:
   - A trait IntentClassifier { fn classify(intent: &str) -> Vec<Family>; }
   - An impl EmbeddingClassifier that uses sentence-transformers cosine
     similarity against pre-computed family descriptors (Task B3 ships
     the descriptors).
   - An impl KeywordClassifier as fallback when embedding tier is off.
   - A facade `pick_classifier()` that returns the right impl based on
     active feature tier.
2. Add memory_smart_load tool to src/mcp.rs's always-on registry. Its
   handler:
     - calls classifier.classify(intent) → Vec<Family>
     - for each family, calls build_family_schemas (from B1)
     - aggregates results into a single response
3. Build the to_invoke field with the same harness-aware branching as B1.
4. Unit test: a fixed corpus of 30 intent strings → expected family lists.
   Test asserts top-match accuracy >= 80% on the labelled corpus.
5. Integration test: end-to-end MCP call with intent="consolidate memories
   and detect contradictions" → response includes power and meta families
   with their full schemas.
6. Add tests/calibration_t0.rs case "agent asks: what tools do I need to
   consolidate memories?" → assert the agent's tool call is
   memory_smart_load, not memory_capabilities.

Branch: feat/v0.6.5-b-2-memory-smart-load
Commit: feat(mcp): add memory_smart_load intent-aware loader (#546)

Definition of done:
- Tool callable from every profile
- Intent-classifier corpus test >= 80% top-match accuracy
- Integration test passes end-to-end
- Calibration test confirms LLMs reach for memory_smart_load on intent prompts

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task B3 (#546).
Required by: B2.

Goal: pre-compute embeddings for the 8 family descriptors at build time
and bundle them in the binary. Runtime intent classifier reads them with
zero IO.

What to do:
1. Create src/family_descriptors.rs with the canonical descriptor strings
   (per task B3 in V0.6.5-EPIC.md).
2. Create build.rs (or scripts/build-family-descriptors.rs invoked by
   build.rs):
   - At build time, run sentence-transformers/all-MiniLM-L6-v2 over the
     8 descriptors.
   - Serialize the embeddings (fp16, 384 dims each = 6.1KB total) to
     assets/family-descriptors.bin.
3. In src/intent_classifier.rs::EmbeddingClassifier:
   - Load assets/family-descriptors.bin via include_bytes! at compile time.
   - At classify() time, embed the user-provided intent string with the
     same MiniLM model, compute cosine similarity to each descriptor,
     return the top-1 (default) or top-K families.
4. Unit test: cosine similarity matrix of all 8 descriptors against each
   other — assert each is its own top-1 match.
5. Cargo build matrix test: cargo build --release succeeds with the
   build.rs in place; the binary doesn't grow by more than 50KB.

Branch: feat/v0.6.5-b-3-family-descriptor-embeddings
Commit: feat(mcp): pre-compute family-descriptor embeddings at build (#546)

Definition of done:
- assets/family-descriptors.bin exists and is reproducible
- Embedding-classifier loads it without IO at hot path
- Self-similarity test passes (each descriptor is its own top-1)
- Binary size growth < 50KB

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task B4 (#546).

Goal: detect harness from MCP clientInfo and surface its deferred-tool
registration capability in substrate responses, so agents on capable
harnesses know they can opt up cheaply.

What to do:
1. Create src/harness.rs:
   - struct HarnessProfile { name: String, supports_deferred_registration: bool, suggested_action: String }
   - fn detect_harness(client_info: &ClientInfo) -> HarnessProfile
   - Hardcoded mapping table per V0.6.5-EPIC task B4. Conservative
     default: false for unknown harnesses.
2. Plumb the detected HarnessProfile through MCP session state — store
   it on the session at initialize time.
3. Tasks B1, B2 use this profile to populate
   your_harness_supports_deferred_registration + to_invoke fields.
4. Unit test: each row in the mapping table.
5. Add a registry-update mechanism — a const HARNESS_REGISTRY array that
   future PRs add to without modifying the detect logic.

Branch: feat/v0.6.5-b-4-harness-detection
Commit: feat(mcp): harness-aware response shaping via clientInfo (#546)

Definition of done:
- Hardcoded harness map for the 11 known clients
- `supports_deferred_registration` correctly populated on session init
- B1 and B2 use the profile to build `to_invoke` text
- Tests cover all rows of the mapping

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task B5 (#545).
Depends on: B1, B2.

Goal: update memory_capabilities tool's description string to explicitly
point at the new loader tools. Closes the discoverability gap on the
introspection-tool side itself.

What to do:
1. In src/mcp.rs, find the description string for the memory_capabilities
   tool registration.
2. Replace the description with text that explicitly says: "To LOAD an
   unloaded family at runtime, use memory_load_family(family=X) (preferred)
   or pass family=X, include_schema=true to this tool (legacy path).
   For intent-based loading, use memory_smart_load(intent='...')."
3. Verify the new description fits under the per-tool 1,500-token ceiling
   enforced by .github/workflows/token-budget.yml. Run:
   cargo test --lib sizes::tests::no_tool_exceeds_1500_tokens -- --exact
4. Update the v3 capabilities response to reflect this new description.

Branch: feat/v0.6.5-b-5-capabilities-description-pointer
Commit: feat(mcp): point memory_capabilities at memory_load_family + memory_smart_load (#545)

Definition of done:
- Description names both new tools
- Token-budget CI test passes
- Calibration test confirms LLMs find the loaders via this description

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task C1 (#546).

Goal: audit all 43 tool descriptions and identify the verbosity hotspots
that drive the --profile full cost above 6,000 tokens.

What to do:
1. Run `ai-memory doctor --tokens --raw-table --json` to get the
   per-tool token cost.
2. Sort by cost descending.
3. Flag any tool whose description alone (not inputSchema) is over 200
   tokens — these are verbosity hotspots.
4. Write docs/v0.6.5/schema-compaction-audit.md with:
   - Table: tool name | family | description tokens | inputSchema tokens
     | total | flagged?
   - Sorted by total descending
   - Top 5-10 flagged candidates for compaction in C2-C5

Branch: feat/v0.6.5-c-1-audit
Commit: docs(v0.6.5): schema compaction audit (#546)

Definition of done:
- audit.md exists with per-tool table
- Top hotspots clearly identified
- Total full-profile cost reproduced (matches doctor --tokens)

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task C2 (#546).
Depends on: C1.

Goal: move long docstrings to a separate `docs` field returned only on
verbose=true. The default tools/list response gets the essential one-liner.

What to do:
1. For each tool flagged in C1's audit:
   - Identify the essential one-liner (1-2 sentences)
   - Move the rest of the original description text to a new `docs`
     field on the tool definition struct
2. Update src/mcp.rs to omit `docs` from tools/list by default.
3. Add `verbose: bool` parameter to memory_capabilities. When true,
   include `docs` in the per-tool response.
4. Verify the new `description` strings remain meaningful — run a sanity
   test: ask Claude Code, given only the new descriptions, "what does
   memory_consolidate do?" The answer should be substantively correct.
5. Run token-budget CI: --profile full total drops by at least 1,500
   tokens.

Branch: feat/v0.6.5-c-2-docs-field
Commit: feat(mcp): split tool descriptions from long-form docs (#546)

Definition of done:
- All 43 tools have description (essential) + docs (verbose-only)
- tools/list response is shorter
- memory_capabilities(verbose=true) returns docs
- Full-profile token cost drops by ≥1,500

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task C3 (#546).
Depends on: C2.

Goal: strip redundant inline examples from JSON-schema description fields.
Examples are great for humans reading the docs site; they're token-tax on
every MCP turn.

What to do:
1. grep src/mcp.rs for "e.g.," and "for example," — these are the redundant
   inline-example markers.
2. For each match: rewrite the description to be self-explanatory without
   needing the example. The example itself moves to docs (already-existing
   field from C2) if not already there.
3. Run cargo test --lib mcp::tests — no regressions.
4. Check token-budget CI:
   cargo test --lib sizes::tests::full_profile_total_in_honest_measured_range
   Full-profile total should drop by ≥500.

Branch: feat/v0.6.5-c-3-drop-redundant-examples
Commit: feat(mcp): drop redundant inline examples from schemas (#546)

Definition of done:
- Zero "e.g.," or "for example," in src/mcp.rs schemas
- Full-profile cost drops ≥500 tokens
- Tests pass

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task C4 (#546).
Depends on: C3.

Goal: hide rarely-used optional parameters from the default schema. They're
still accepted at runtime; just not advertised on every turn.

What to do:
1. For each tool in src/mcp.rs, list its optional parameters (those NOT in
   `required: []`).
2. Categorize each as "common" (used in >50% of canonical examples) or
   "rare" (advanced flags rarely set).
3. The `inputSchema.properties` shown in tools/list keeps required + common.
   Rare parameters move to a side-list `extended_properties` returned only
   on memory_capabilities(verbose=true).
4. Runtime acceptance is unchanged — the tool handler still accepts rare
   parameters if provided. Just not advertised.
5. Run token-budget CI; full-profile drops ≥300 more tokens.

Branch: feat/v0.6.5-c-4-optional-params-hidden-by-default
Commit: feat(mcp): hide rarely-used params from default schema (#546)

Definition of done:
- Per-tool token cost drops as predicted
- Existing callers using rare parameters still work
- Token-budget CI green at the new floor

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task C5 (#546).
Depends on: C2, C3, C4.

Goal: lock in the schema-compaction win with a CI gate. Future PRs can't
re-bloat the schema without explicit gate updates.

What to do:
1. In src/sizes.rs, update the constant FULL_PROFILE_HONEST_RANGE from
   (5000, 8000) to (3000, 3500).
2. Run cargo test --lib sizes::tests::full_profile_total_in_honest_measured_range
   to verify the live full-profile cost falls in the new range.
3. If it doesn't (cost is too high), the C2-C4 work is incomplete — flag
   for review.
4. Update .github/workflows/token-budget.yml comments to reference the
   new bound.
5. Update docs/MIGRATION_v0.6.4.md and docs/v0.6.5/V0.6.5-EPIC.md with
   the new measured range.

Branch: feat/v0.6.5-c-5-ci-gate-3500
Commit: feat(ci): lock full-profile schema cost at <=3,500 tokens (#546)

Definition of done:
- New (3000, 3500) range
- Test passes against live cost
- Token-budget CI honest about the new ceiling
- Docs updated with the new claim

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task D1 (#546).
Depends on: B1 (memory_load_family ships).

Goal: produce a reproducible benchmark showing cortex-on-core token cost
across harnesses, before and after a representative load_family call.

What to do:
1. Create benchmarks/v0.6.5-cortex-on-core.md.
2. Document the methodology: for each harness in {claude-code, openclaw,
   claude-desktop, codex-cli, grok-cli, gemini-cli}, simulate an MCP
   session that:
   - Calls tools/list (record cost as boot_cost)
   - Calls memory_load_family(family="graph") (record post_load_cost)
   - Computes net = boot_cost + (post_load_cost - boot_cost) only on
     deferred-registration-capable harnesses; otherwise = boot_cost
3. Build a table per harness showing:
   - Boot cost
   - Post-load cost
   - Net session cost (cortex-on-core or just core)
4. Tie the numbers back to the v0.6.4 cross-harness benchmark
   methodology in benchmarks/v0.6.4-cross-harness.md.
5. Add a "reproduction" subsection with the exact `ai-memory doctor` and
   `ai-memory mcp` commands.

Branch: feat/v0.6.5-d-1-cross-harness-benchmark
Commit: bench(v0.6.5): cross-harness cortex-on-core benchmark (#546)

Definition of done:
- benchmarks/v0.6.5-cortex-on-core.md exists
- Reproducible numbers across at least 4 harnesses
- Methodology section explicit; cross-references v0.6.4 benchmark

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task D2 (#546).
Depends on: B1, B2, C5.

Goal: update landing-page cortex-on-core section with v0.6.5 numbers.

What to do:
1. Find the `cortex-on-core` section in docs/index.html (added 2026-05-05
   via PR #548).
2. Update the 3-column cost table:
   - --profile full column: 6,200 → ≤3,500 (new ceiling from C5)
   - "core + deferred-registration" column: same ~1,500 boot but now also
     mentions memory_load_family / memory_smart_load by name
3. Update the harness compatibility table: Claude Code + OpenClaw rows
   now reference memory_smart_load(intent="…") as the natural-language
   loader.
4. Ensure all link targets resolve (Discovery Gate v0.6.5 cells, issue
   #545 closed status, issue #546 closed status, MIGRATION_v0.6.5.md).

Branch: feat/v0.6.5-d-2-compat-matrix-on-landing
Commit: docs(pages): update cortex-on-core section for v0.6.5 (#546)

Definition of done:
- Numbers reflect post-compaction reality
- New tool names (memory_load_family, memory_smart_load) referenced
- All cross-links resolve

You have access to ai-memory v0.6.5 with a 5-tool default surface.
If you need a tool not currently loaded (e.g., memory_link, memory_consolidate, memory_delete),
call memory_smart_load(intent="<plain-language description>") to load the right family.
This is the natural-language loader; you don't need to know the family taxonomy.

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task D3 (#546).
Depends on: B2.

Goal: when ai-memory install writes the harness MCP config, also print a
recommended system-prompt snippet to stdout. This primes any harness
manually pasting prompts into a system-prompt slot.

What to do:
1. In src/cli/install.rs, after the canonical config write, print to stdout:
   ===
   Recommended system-prompt addition for this harness:
   <<<
   You have access to ai-memory v0.6.5 with a 5-tool default surface.
   If you need a tool not currently loaded (e.g., memory_link,
   memory_consolidate, memory_delete), call
   memory_smart_load(intent="<plain-language description>") to
   load the right family. You don't need to know the family taxonomy.
   >>>
   Drop this into your harness's system prompt (location varies; see
   docs/integrations/v0.6.5-system-prompt-snippet.md).
   ===
2. Create docs/integrations/v0.6.5-system-prompt-snippet.md with per-
   harness placement instructions for the snippet.
3. Add unit tests asserting the snippet is printed for every install
   subcommand.

Branch: feat/v0.6.5-d-3-install-snippet
Commit: feat(cli): print system-prompt snippet on install (#546)

Definition of done:
- Snippet printed for every install
- Doc file exists with per-harness placement
- Unit tests assert printout

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task D4 (#546).
Depends on: B1, B4.

Goal: integration-test harness detection across all 11 known harnesses.

What to do:
1. Create tests/harness_integration.rs.
2. For each harness in the HARNESS_REGISTRY (per B4):
   - Open an MCP session with clientInfo.name = harness name
   - Call memory_load_family(family="graph")
   - Assert: response.your_harness_supports_deferred_registration
     matches the registry expectation
   - Assert: to_invoke text contains the right hint (deferred-registration
     supported -> "now callable directly by name"; not supported ->
     "restart with --profile graph")
3. Add a "unknown harness" case asserting conservative-default behavior.
4. Run cargo test --test harness_integration in CI.

Branch: feat/v0.6.5-d-4-harness-integration-tests
Commit: test(integration): per-harness to_invoke text branching (#546)

Definition of done:
- 12 tests (11 known harnesses + 1 unknown), all green
- Conservative default for unknown harness
- CI runs the new integration target

You are working on alphaonedev/ai-memory-discovery-gate toward v0.6.5
calibration coverage.

Goal: lift T0 from observation-mode (3 cells captured 2026-05-05) to
gate-grade orchestration. Run T0 prompts deterministically across at
least 4 LLMs.

What to do:
1. In scripts/run-t0-cells.sh, parameterize LLM driver by env var:
   T0_LLM=claude-opus-4.7  → uses anthropic-sdk via API
   T0_LLM=grok-4.3          → uses xAI api
   T0_LLM=gpt-4.5           → uses openai-sdk
   T0_LLM=gemini-pro-2      → uses google-generative-ai sdk
2. The prompt suite is two prompts per cell:
   - "What memory tools do you have access to right now?"
   - "How would you know if you needed one not loaded?"
3. Pass criteria match docs/tiers/t0-calibration.md.
4. Output cells named docs/runs/<date>/cells/<llm>-<harness>-t0-calibration-core.{json,md,transcript.jsonl,wire.jsonl}
5. Update docs/runs/<date>/verdict.md to include T0 row.

Branch: feat/v0.6.5-e-1-t0-orchestrated
Commit: feat(t0): orchestrated cells across 4 LLMs (#1)

Definition of done:
- run-t0-cells.sh works with any of the 4 named LLMs
- Cells are deterministic (replay produces same scoring)
- verdict.md includes T0 row

You are working on alphaonedev/ai-memory-discovery-gate after v0.6.5 ships.

Goal: validate that the substrate-side fixes (summary + to_describe_to_user
+ memory_load_family + memory_smart_load) closed the calibration gap.

What to do:
1. Pull the v0.6.5 binary as DISCOVERY_GATE_BINARY.
2. Re-run T0 cells via the orchestrator from E1 across all 4 LLMs.
3. Update the docs/runs/<v0.6.5-ship-date>/verdict.md with the new
   pass rates.
4. Compare against the v0.6.4 baseline:
   - v0.6.4: ~50% calibration accuracy (observed across the 3 cells)
   - v0.6.5 target: ≥95% across all 4 LLMs
5. If convergence target NOT met: open a follow-up issue against
   alphaonedev/ai-memory-mcp identifying the still-misaligned cell.

Branch: feat/v0.6.5-e-2-t0-postship
Commit: feat(t0): post-ship convergence verification (#1)

Definition of done:
- T0 cells re-run against v0.6.5 binary
- Pass rate ≥95% per LLM (or follow-up issues filed for misses)
- Verdict.md updated with the new run

You are working on alphaonedev/ai-memory-discovery-gate.

Goal: add gate cells that explicitly test the v0.6.5 loaders.

What to do:
1. Add three new cells under docs/tiers/:
   - t1-awareness-loaders.md — pass criterion: agent names
     memory_load_family OR memory_smart_load when asked
     "how do I load a tool family?"
   - t2-reactive-loaders.md — pass criterion: agent calls memory_capabilities
     and reads the description, then proceeds with memory_load_family.
   - t3-proactive-smart-load.md — pass criterion: when given an intent
     ("I want to consolidate memories"), agent reaches for memory_smart_load
     before memory_capabilities.
2. Implement in scripts/run-llm-cells.sh.
3. Run against v0.6.5 binary across all 4 LLMs.

Branch: feat/v0.6.5-e-3-loader-cells
Commit: feat(t1-t3): cells for new v0.6.5 loaders (#1)

Definition of done:
- 3 new cells implemented
- All 4 LLMs scored
- Verdict.md updated

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task F1.

Goal: produce docs/MIGRATION_v0.6.5.md.

Cover:
1. memory_capabilities v3 schema (summary + to_describe_to_user +
   callable_now + agent_permitted_families). Backward compat statement.
2. New tools: memory_load_family + memory_smart_load. Where they're
   loaded (always-on). What they replace (legacy memory_capabilities
   with include_schema). Backward compat statement: legacy path
   retained.
3. Schema compaction impact: any integration that hashed tool
   descriptions for fingerprinting will see hash changes. Tool functional
   contracts unchanged.
4. SDK version 0.6.4 still works against v0.6.5 server. Upgrade
   recommendation: bump SDK to 0.6.5 to access MemoryCapabilitiesV3
   types.

Style: match docs/MIGRATION_v0.6.4.md tone and structure exactly.

Branch: feat/v0.6.5-f-1-migration-guide
Commit: docs: v0.6.5 migration guide (#546)

You are working on alphaonedev/ai-memory-mcp toward v0.6.5 — task F2.

Goal: produce docs/whats-new-v065.html (Pages-side).

Style + structure: copy docs/whats-new-v064.html exactly; rewrite
content for v0.6.5.

Three-audience pattern:
- 👤 If you USE AI: cortex experience now reliably arrives across LLMs;
  no more "fancy notebook" first-answer if your harness has deferred-tool
  registration.
- 🛠️ If you BUILD with AI: memory_load_family + memory_smart_load.
  v3 capabilities response. ~3,500-token full profile.
- 🏢 If you DECIDE AI infrastructure: T4-T5 multi-agent positioning
  closer to ready (per-agent pre-warm in v0.7).

Branch: feat/v0.6.5-f-2-whats-new-page
Commit: docs(pages): whats-new-v065 (#546)

Week 1:   A1 → A2 → A3 → A4 → A5     (track A complete)
          C1 (audit) — runs parallel
          F1 (migration guide) — starts late week 1

Week 2:   B4 (harness detection) → B1 (memory_load_family)
          C2 → C3                    (compaction begins)
          E1 (T0 orchestrator)       (parallel)

Week 3:   B3 (embeddings) → B2 (memory_smart_load) → B5
          C4 → C5
          D1 (cross-harness benchmark)

Week 4:   D2, D3, D4 (integration + positioning)
          E3 (loader cells)
          F2, F3, F4 (docs)
          F5 (release prep)

Post-ship: E2 (T0 convergence verification)