📏 Convention: How to enforce Session 172 persistence conventions across th...

Date: 2026-03-04
Time: 02:21:16 UTC
Session: gspace1-173.2
Agent: storage
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How to enforce Session 172 persistence conventions across the codebase and prevent developers from using the deprecated two-signal pattern?

Task: Implement persistence conventions across codebase (Session 173)

🎯 Decision Made

Chosen:

Documentation-first approach: Updated the architecture doc (flash-persistence-and-conversation-genome.md Sections 6, 7, 10), API reference (AutoFlashSignal type + .hydrated), and added deprecation warnings to PanelSessionPersistenceService. Wired up sweepExpiredStates() for TTL enforcement. No mass code migration needed — only 2 services use autoFlashState + backend sync, 1 is already migrated, 1 is deprecated.

Options Considered:

• No alternatives documented

💭 Reasoning

Audit revealed the real problem was documentation, not code. The architecture doc actively recommended the wrong pattern (two-signal) that Session 172 proved causes flash bugs. 40+ autoFlashState consumers are local-only (no backend sync) and don't need changes. Only PanelSessionPersistenceService still uses the old pattern, but it's already @deprecated and slated for removal. Rewriting it would be wasted effort. The highest-impact fix was correcting the docs so future features follow the right pattern.

📁 Files Involved

• docs/english/architecture/flash-persistence-and-conversation-genome.md
• docs/english/GoGrab-Space/docs.libs/docs.libs-foundational/storage-system/implementation/api-reference.md
• libs/libs-ai/panel-intelligence/src/lib/services/panel-session-persistence.service.ts
• libs/libs-foundational/storage-system/src/flash/providers/auto-flash-persistence.provider.ts

🔗 Related

• Decision ID: dev_1772590876549_e532l26
• Session: 173
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation