4 Commits

Include renames

Author	SHA1	Message	Date
bvandeusenandClaude Opus 5.5	54206afa76	fix(6229): remove the Profile settings page — nothing read it ... The Profile tab said an assistant used it to personalise chat and a daily journal. Neither exists, and nothing read the profile: the page saved to user_profiles and the backup carried it. Removed the tab, the client calls, /api/profile, the service and the model, and migration 0123 drops the table (downgrade recreates it empty). Backup format v27 stops writing user_profiles; an older archive carrying the section still restores, and the file-restore integration test now proves it. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-22 10:14:40 -04:00
bvandeusenandClaude Opus 5.5	79de8938b9	docs(6209): forty test files — design cascade and stylesheet, embeddings, family canon, forge, backup round trips, inception, placement, platforms, moments, rule move and verification, search scope, facets ... Module and test docstrings state what is pinned without the record number or step that introduced it. Incident accounts become the failure shape in the present tense: the pipefail head, the code_shapes import, the export order, the facet dialects, the cross-kind repeat, the write-once kind. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-21 21:40:25 -04:00
bvandeusenandClaude Opus 5.5	38d02d9c6f	fix(523): the backup carries user_profiles - the Profile page travels with its user (#5879) ... Settings -> Profile (name, role, expertise, response style, tone, interests, working hours) is typed by its user and neither derived nor a credential, yet _NOT_INCLUDED named it, so a restore dropped it without a word. BACKUP_VERSION 26. Both exports carry it; the restore remaps only the user, and a blank field stays blank rather than restoring as the page's default. The column and import guards cover it, and the tar round-trip restores one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 19:55:52 -04:00
bvandeusenandClaude Opus 5.5	b45fc9efba	feat(523): restore reads the backup tar; python -m scribe.restore brings a fresh instance back ... The restore route takes the tar as a raw body beside the JSON download. scribe/restore.py reads either format, refuses a database that already has an account (a restore re-creates everything with new ids, so into a live instance it would duplicate rather than replace), has no size limit, and says to restart so search indexes rebuild. An integration test restores a written tar through the real restore_full_backup and checks every id is remapped. docs/backups.md explains the file, why it is uncompressed, both destinations, Fabled Archives as the worked example, and restoring. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>	2026-10-15 17:40:24 -04:00