Python full-stack application / Production preview
SpineFrame
SpineFrame is a private continuity system for sessions, conversations, memory review, and structured state. Users can return to conversations, inspect what the system carries forward, and edit or remove state that should not persist.
I built and operate a Python/Flask application with PostgreSQL-backed user state, account and email flows, memory review/editing paths, settings surfaces, model integration behind parsing, validation, and review controls, and a 672-test suite covering account, persistence, migration, tenancy, and runtime paths.
Continuity architecture
SpineFrame
- Role
- Sole developer
- Focus
- Python backend and operations
- Maturity
- Production preview
- Access
- Public login; private authenticated runtime
- Technologies
- Python
- Flask
- PostgreSQL
- Nginx
- systemd
- Last reviewed
- Aug 2026
The problem
What the project had to handle
The hard part is keeping the runtime useful without letting model output become unreviewed project memory. The app needs account flows, persistence, review paths, and deployment ownership before the AI layer can be treated as more than a chat surface.
Meaningful workflows are authenticated and private. Authenticated examples use synthetic data rather than personal content.
Key decisions
The shape of the build
Complete account lifecycle
Registration, email verification, login, sessions, password reset, account settings, and recovery paths are handled as application flows.
Continuity work depends on identity boundaries; the memory layer only makes sense once accounts and sessions are explicit.
User-scoped persistence
Conversations, memory records, settings, and structured state are stored behind user boundaries across PostgreSQL and supporting state files.
The system can preserve state across sessions while keeping private workflows away from public visitors.
Validated model boundaries
Model integration sits behind parsing, validation, and review controls instead of directly mutating durable state.
That keeps AI output useful without treating every generated response as a trusted memory update.
How it works
End-to-end flow
A visitor reaches a public login surface, then authenticated routes carry chat, history, memory review, settings, attachment, and structured-state workflows. Flask routes coordinate user-scoped PostgreSQL records and state files, while provider calls and parsers stay behind validation and review boundaries.
01
Accounts define the private runtime
Registration, verification, login, sessions, settings, and recovery flows establish the user boundary.
02
Continuity records stay reviewable
Conversations, memory records, settings, and structured state are stored behind user-scoped persistence.
03
Model output is controlled
Provider calls feed parsing, validation, and review paths before anything can become durable state.
What I implemented
The working surface
Auth and account flows
- Implemented registration, login, email verification, password reset, and signed sessions.
- Added account, settings, and recovery surfaces around the private runtime.
- Kept public access limited to entry points rather than private workflow content.
Continuity runtime
- Stored sessions, conversations, memory records, and settings in user-scoped persistence.
- Built memory review and editing paths for inspecting what stays in the system.
- Connected chat/history surfaces to the persistence layer.
Model integration and operations
- Added developer-gated trackers and structured-state APIs.
- Put model integration behind parsing, validation, and review controls.
- Operated the Flask/PostgreSQL application as a self-hosted production-preview service.
Validation
Checks and evidence
Public login route checked
The public login route was reachable during the latest review; authenticated runtime content remains private.
Application paths tested
Account, persistence, migration, and tenancy paths are covered by scoped project tests.
672 tests passed
The current test suite passes 672 tests covering account, persistence, migration, tenancy, and runtime paths.
Private runtime remains gated
Authenticated runtime content remains private, so public review is limited to the login surface, documentation, and synthetic or architecture views.
Current state
Production-preview service with a public login surface and private authenticated runtime.
The application is self-hosted with Python, Flask, PostgreSQL, Nginx, and systemd.
Authenticated examples use synthetic data rather than personal content.