docs: propose optional Memcode integration

[vivekgupta-memcode]

Summary

This is the focused design plan requested before adding runtime code.

• keep Memcode configuration in the existing local coding-agent boundary
• keep credentials out of the browser and html-anything application
• make memory usage opt-in with explicit write consent
• define failure behavior, privacy boundaries, and acceptance criteria

No runtime dependencies or behavior change in this PR.

[nettee]

Two implementation-critical parts of the integration plan need a concrete contract before runtime work begins: the write-confirmation interaction and the recall-size budget. Resolving these will preserve the stated privacy and non-fatal generation guarantees.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[nettee]

The consent gate is not implementable from this plan as written. The current conversion path runs one CLI invocation and returns its stream; it has no defined interaction that can display a proposed memory record and then deliver a second affirmative response to that same operation. The later example instead treats a single "Remember ..." request as consent, which conflicts with this summary-then-affirmation ordering. An implementation would therefore either be unable to write or could write before the promised disclosure. Define one protocol and its tests: for example, make the first action return a structured proposed record without writing, require a UI confirmation, and use a separate write action that accepts only that confirmed proposal; alternatively, explicitly define an existing request as sufficient consent and revise this rule to match.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[nettee]

"Bounded" has no enforceable data contract here. The plan does not specify a maximum number of results, byte or token budget, ordering, truncation or rejection behavior, or what happens when a single recalled value exceeds the limit. A fake-agent test cannot determine whether the acceptance criterion passes, and an implementation can still inject an arbitrarily large MCP response, undermining the non-fatal generation guarantee. Add a small recall-context table that fixes these limits and behaviors (including deterministic ordering and an over-limit fallback that proceeds without memory), then require boundary fixtures for multiple results and an oversized individual result.

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[nettee]

@vivekgupta-memcode

Thanks for tightening the plan. I verified the one-shot consent rule matches the current POST /api/convert flow, and the recall budget now specifies deterministic ordering, per-record and combined limits, invalid/oversize fallback, and boundary coverage. This resolves the prior implementation-contract concerns—nice follow-through!

_{🔁 Powered by Looper · runner=reviewer · agent=codex · An autonomous AI dev team for your GitHub repos.}

[vivekgupta-memcode]

Hi @nettee thank you for the quick response, should i proceed with the integration in a follow up PR?

[lefarcen]

Hey @vivekgupta-memcode — yes, please take the implementation into a focused follow-up PR. Keeping this plan separate was the right call; in the runtime PR, link back to #154 and show the one-shot consent rule plus the recall-budget boundary cases in tests. We’ll review that implementation on its own merits. 🙌

💡 To drive this PR to merge hands-free, paste this to your AI coding agent (Claude Code / Codex / opencode / Cursor …):
Take over nexu-io/html-anything#154 until it merges — read https://raw.githubusercontent.com/nexu-io/looper/main/skills/pr-takeover/SKILL.md and follow it.