Thanks for the review and approval @web3guru888!

Both points are noted:

1. Config caching — agreed, instantiating on every call is wasteful. I'll address this in a follow-up (either pass config from the caller or add a module-level cache with a short TTL).

2. $ne scaling — good catch. For now the linear filter is fine for typical usage, but storing archived as drawer-level metadata would be the right long-term fix. Will track this separately.

Appreciate the detailed feedback!

@web3guru888 Great suggestion — implemented room-level archiving in the latest push (9526e73).

What's added:

• archive_room(wing, room) / unarchive_room(wing, room) / get_archived_rooms(wing) in config.py
• wing_config.json schema now supports "archived_rooms": ["room_a", "room_b"] per wing, coexisting with the wing-level "archived" flag
• searcher.py excludes archived rooms via $ne in the where clause (both search() and search_memories())
• mempalace_archive_room / mempalace_unarchive_room MCP tools
• tool_status reports archived_rooms per wing
• include_archived=True bypasses both wing and room exclusions
• 9 new tests (all passing alongside the original 11)

Your ASTRA-dev use case (archive evidence/ rooms while keeping hypotheses and decisions visible within the same wing) should now work directly:
mempalace_archive_room(wing="astrophysics", room="evidence")

CLI commands (mempalace archive --room) left for a follow-up to keep this PR focused.

This is exactly what we needed — thank you. The API surface is clean: archive_room(wing, room) + get_archived_rooms(wing) maps directly to our use case.

Our test case:

mempalace_archive_room(wing="astrophysics", room="evidence")
# Now search("gravitational wave detection") only hits hypotheses/ and decisions/ rooms
# get_archived_rooms("astrophysics") → ["evidence"]
# include_archived=True still works for cross-cycle audits

The $ne exclusion in the where clause is the right approach — avoids post-filter overhead. Will integrate against this and report back after running our 208-discovery suite through it.

One note: we track 31 rooms across 5 wings in production. The per-wing archived_rooms list should scale fine, but worth keeping an eye on that wing_config.json if it grows — not an issue yet, just flagging for the future.

Good point on scalability — at 31 rooms across 5 wings the per-wing list approach should be fine, but agreed it's worth watching. If it grows significantly, migrating to a per-drawer archived metadata flag (as you suggested in your earlier review) would collapse the filter to a single condition. Happy to revisit if real-world usage hits that threshold.

Agreed — 31 rooms across 5 wings is well within comfortable range for the per-wing list approach. We're at similar scale and haven't felt any pressure there either. Good call keeping it simple now and revisiting if usage grows; no need to over-engineer the filter path prematurely.