Remove legacy memory composition block in refresh_system_prompt

[Hmbown]

Removes the legacy memory block composition logic from refresh_system_prompt and related system prompt setup paths (Engine::new, build_app_system_prompt_with_goal). The old memory retrieval block is replaced by setting user_memory_block: None in PromptSessionContext since the new Moraine recall method is stable. Also removed the associated TODO comment in tool_setup.rs.

---

PR created automatically by Jules for task 3913683453046725750 started by @Hmbown

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[claude]

Claude finished @Hmbown's task in 2m 53s —— View job

---

Claude's Review Task List

• Gather context (read diff, changed files)
• Understand the request (review this PR per repo custom instructions)
• Review correctness
• Review provider/model/route safety implications
• Review reuse/simplification
• Review test coverage
• Review security
• Post final review

Summary

This PR hardcodes user_memory_block: None in the three system-prompt-building call sites instead of computing it, on the premise that "Moraine recall is stable." That premise doesn't match the rest of the codebase's current state: moraine_fallback (the config flag that's supposed to gate the legacy→Moraine cutover) still defaults to false, and every other consumer of that flag is left unchanged. The result is an inconsistent, partially-migrated state rather than a clean removal.

Correctness — likely regression (high priority)

crates/tui/src/core/engine.rs:1023,3671 and crates/tui/src/tui/ui.rs:1701 — the <user_memory> block is now unconditionally omitted from the system prompt for every user, including the default case (memory_enabled = true, moraine_fallback = false, i.e. legacy mode still active, the documented default per Config::moraine_fallback() in crates/tui/src/config.rs:5085-5090). Meanwhile, in the very same commit range, these paths are not updated and still gate on memory_enabled && !moraine_fallback:

• crates/tui/src/core/engine/tool_setup.rs:86 — remember tool is still registered.
• crates/tui/src/core/engine.rs:3466 — ctx.memory_path is still handed to tools so remember can append entries.
• crates/tui/src/tui/ui.rs:1512 — # foo quick-add composer interception is still active.
• crates/tui/src/main.rs:8322 — surface.memory_tool_enabled still uses the old condition.

Net effect: for the default-config user who has memory_enabled = true and hasn't opted into Moraine, the app still happily lets them write memory (via remember tool or # foo), but that memory is now silently never read back into the model's context. That's a functional regression, not just dead-code cleanup — and it contradicts the module doc in crates/tui/src/memory.rs:120-129, which explicitly says callers should pass config.memory_enabled() && !config.moraine_fallback().

If the intent is a full cutover to Moraine, this should happen alongside flipping the moraine_fallback default (or removing the flag/legacy path entirely, matching the remember tool, quick-add, and memory.rs), not just at the three prompt-assembly sites.

Correctness — stale diagnostics

crates/tui/src/context_report.rs:245-270 (build_headless_context_report) and crates/tui/src/context_report.rs:497-522 (add_app_runtime_entries, used by the TUI's live context/doctor report) still call crate::memory::compose_block(...) under the old condition and push a SourceEntry claiming the <user_memory> block is an active, token-counted part of the context. After this change that's no longer true — the diagnostic/doctor output will misreport memory as included (with an estimated token count) when the actual system prompt never contains it. These two call sites needed the same treatment as the ones this PR touched.

Provider/model/route safety

No provider/model selection logic is touched by this diff — not applicable here.

Reuse / simplification

The mechanical part of the change (dropping the now-dead let user_memory_block = … bindings and passing None directly) is reasonable if the surrounding gating were consistent. Removing the stale TODO(v0.8.71) comment in tool_setup.rs is fine on its own, but ironic given the same TODO still describes real, un-migrated logic two lines below it.

Tests

No test was added or updated to cover this behavior change, and none of the existing tests (tool_setup.rs::remember_tool_registration_respects_moraine_fallback, ui.rs::memory_quick_add_interception_respects_moraine_fallback, context_report.rs moraine tests) would catch the prompt/tool inconsistency described above, since none of them assert on the actual system-prompt content. A test asserting refresh_system_prompt/build_app_system_prompt_with_goal output contains (or omits) <user_memory> under the various memory_enabled/moraine_fallback combinations would have caught this.

Security

No secret handling, shell/exec, or input-validation surface touched.

Fix this →

[Hmbown]

Moved to v0.9.4 draft. #3495 is still open and requires the Moraine adapter, MCP recall wiring, and end-to-end proof before the legacy prompt injection is config-gated/deprecated. This slice alone makes documented memory writes unreadable while leaving config, tools, commands, and docs active.

[google-labs-jules]

Moved to v0.9.4 draft. #3495 is still open and requires the Moraine adapter, MCP recall wiring, and end-to-end proof before the legacy prompt injection is config-gated/deprecated. This slice alone makes documented memory writes unreadable while leaving config, tools, commands, and docs active.

Acknowledged. Since #3495 is still open and the legacy prompt injection cannot be deprecated yet, I understand this PR is moving to a draft state. I will stop work on this task for now.