SpineFrame

Overview

SpineFrame is a live personal reflection and memory-continuity system. The point is not just to store chats. The system is meant to keep conversations, memory, review surfaces, and continuity support tied to the right user without turning the app into a workspace/product-management platform.

Earlier versions were closer to a local single-user runtime. The work since then has been about making it usable as an authenticated web system: users can sign in, create chats, revisit history, inspect memory, and keep their runtime state separated from everyone else’s.

What I Built

I built the authenticated product shell around the runtime:

• sign in and create-account flows
• email verification states
• current chats and ended/history conversations
• fresh chat creation
• edit, delete, and replay-from-message behaviour
• end-conversation confirmation and processing state
• read-only memory view
• account/settings modal
• split/focus chat layout

The important part was making those flows user-scoped. Chat state, history, memory repositories, artefacts, inspection paths, and runtime actions all resolve through the authenticated user boundary. I intentionally kept the tenancy model narrow: user_id, not workspaces, teams, projects, orgs, sharing, or roles.

Memory and Storage

The memory side is built around structured continuity objects rather than one undifferentiated note pile. The current structured stack uses ProjectThread, OpenLoop, and DecisionRecord, alongside broader memory substrate stores such as reference facts, stable memory, episodic meaning, dormant/candidate memory, phase memory, and decision vectors.

One of the heavier backend passes was moving the public-user path from JSON files into Postgres-backed storage. That covered auth, sessions, rate limits, conversations, messages, structured memory repositories, the broader memory substrate, and vector metadata parity. JSON still exists for import/export, fixtures, and explicit fallback, but it is no longer the intended public-user source of truth.

That migration needed more than tables. I built DB config, migrations, health checks, DB-backed repositories, repeat-safe JSON-to-DB import tooling, conflict checks, dry-run/apply reporting, and parity gates so storage migration did not quietly change retrieval or continuity behaviour.

Boundaries and Verification

The place this project can go wrong is boundaries. If a memory system crosses users, leaks history, wipes corrupted storage, or silently changes retrieval behaviour, the core idea stops being trustworthy.

I validated those boundaries with Alice/Bob smoke flows across the UI and runtime. The checks cover chat, memory, history, artefacts, settings, wrong-user selection, and unauthenticated access. I also added stricter auth behaviour: hashed verification/reset tokens, expiry, single-use tokens, rate-limited login/register/reset/resend actions, and rollback when verification email delivery fails during account creation.

The storage migration had its own gate as well: DB migrations, auth smoke, conversation smoke, structured-memory smoke, broader-substrate smoke, JSON import, selected-context retrieval parity, LSM continuity parity, vector index parity, cross-user isolation, and memory integrity.

Current State

SpineFrame is live and usable, but it is still not the final product. The strongest implemented parts are the authenticated runtime, user-scoped chat/history, memory review, Postgres-backed storage, import/migration tooling, and isolation checks.

What still needs work is the product surface: current screenshots, clearer diagrams, and a more obvious explanation of how conversations, memory review, and continuity support connect.