feat(chat): persist always-approve tool selections across sessions

[anfibiacreativa]

Summary

• Always-approve tool selections are now persisted to IndexedDB so they survive page reloads and conversation resets.
• A new loadAutoApprovedTools / saveAutoApprovedTools API in persistence.js performs read-modify-write to avoid clobbering messages or sessionId.
• loadInitialMessages loads persisted approvals in parallel with messages on startup.
• clear() no longer resets _autoApprovedTools — approvals intentionally survive conversation resets per spec.

---

Problem / Root Cause

Previously _autoApprovedTools was an in-memory Set initialised to empty on every load (and cleared on every clear() call). Users who checked "always approve" for a tool had to re-approve on every page reload or after clicking "New conversation", which was friction-heavy for power users.

---

What Changed

nx2/blocks/chat/utils/persistence.js

• Added blankRecord(room) factory to eliminate duplicated blank-record skeletons.
• loadAutoApprovedTools(room) — readonly IndexedDB transaction; returns a Set<string>; resolves to an empty Set on any error or missing record.
• saveAutoApprovedTools(room, toolNamesSet) — readwrite transaction with read-modify-write: reads the existing record, spreads in the new tool names array, writes back; wraps the entire async flow in a real Promise (resolves on tx.oncomplete, rejects on tx.onerror / req.onerror / thrown errors).

nx2/blocks/chat/chat-controller.js

• loadInitialMessages now runs loadMessages and loadAutoApprovedTools in parallel via Promise.all and assigns the result to _autoApprovedTools.
• approveToolCall (always path) fires saveAutoApprovedTools as a fire-and-forget with .catch(() => {}) to avoid unhandled rejections.
• Removed the ??= new Set() guard from approveToolCall (the Set is always initialised before any tool call is possible).
• Removed the _autoApprovedTools = new Set() reset from clear(); added a comment explaining the intentional omission.

test/nx2/blocks/chat/utils/persistence.test.js

• Added 4 new tests for loadAutoApprovedTools and saveAutoApprovedTools:
  • Returns empty Set for unknown room.
  • Returns saved tool names as a Set.
  • Does not overwrite existing messages or sessionId on save.
  • Merges new tools into an existing list.

WORKLOG.md — updated with implementation notes (2 entries).

---

Diff stat

WORKLOG.md                                     | 33 +++++++++++++++++
nx2/blocks/chat/chat-controller.js             | 16 ++++++---
nx2/blocks/chat/utils/persistence.js           | 50 ++++++++++++++++++++++++++
test/nx2/blocks/chat/utils/persistence.test.js | 46 ++++++++++++++++++++++++
4 files changed, 141 insertions(+), 4 deletions(-)

---

How to Test

1. Open the DA chat panel locally (da-live + da-admin + da-nx running).
2. Trigger a tool call that requires approval.
3. Click "Always approve" for that tool.
4. Reload the page — the tool should be approved without a prompt.
5. Click "New conversation" (clear) — the tool should still be auto-approved (approvals survive resets).
6. Open DevTools → Application → IndexedDB → da-chat → conversations; verify the record has an autoApprovedTools array containing the tool name.
7. Run npm test — all 967 tests should pass.

---

Risk / Follow-ups

• Risk (low): saveAutoApprovedTools is fire-and-forget from approveToolCall; a quota-exceeded failure logs a console.warn but does not surface to the user. Acceptable for this feature; a toast notification could be added later.
• Follow-up: Consider a "Manage always-approved tools" UI to let users revoke individual approvals stored in IndexedDB.
• Follow-up: DB version is still 1; if a future schema change needs to add the autoApprovedTools field to existing records a migration path will be needed (currently handled gracefully by the Array.isArray guard in loadAutoApprovedTools).

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch.
In case there are problems, just click the checkbox below to rerun the respective action.

• Re-sync branch

Commits

• 44be3aa ✅ (latest)
• f89af15 ✅
• caf9f8f ✅
• 08eb9f6 ✅
• db9fbd6 ✅
• 16b09b7 ✅
• 40fc92c ✅
• 521124f ✅

[hannessolo]

Implementation wise I think it's good.

I'm wondering if this is what we want - this makes it so there's no way to ever revoke auto approval if I understand correctly?

I could see a usecase where in a session you want auto approve, but in a next session you want to review before approving. Maybe we should add a UI for resetting?

[anfibiacreativa]

Implementation wise I think it's good.

I'm wondering if this is what we want - this makes it so there's no way to ever revoke auto approval if I understand correctly?

I could see a usecase where in a session you want auto approve, but in a next session you want to review before approving. Maybe we should add a UI for resetting?

yep, your understanding is right. right now clear() doesn't reset the auto-approved set and there's no revoke path. that's intentional for this PR since persistence was the whole point, but you're right that there's no escape hatch yet.

i captured two follow-ups in the description: a "manage always-approved tools" UI to revoke individual approvals, and the per-session-vs-persisted case you're raising. do you think the revoke UI should block this merge, or land as a fast follow? i'd lean fast follow, since without it we're not regressing anything (today approvals don't survive at all, so you re-approve constantly), we're just not yet giving a way to undo the new persistence.