Files that outlived the chats that held them, and a page that led with its footnotes

The second audit pass. Four things, and the first two were reported.

The Prompts page put a screen of variables and a screen of preview above
the editor, so the tabs began two screens down and switching one had to
drag the whole page to be any use -- and on a short tab it could not drag
far enough, leaving the panel stranded above a screenful of nothing.
Editor first, reference after, bar sticky. Custom themes were three fixed
slots: fifty-seven empty colour boxes on a fresh instance and no way to
make a fourth theme. One block per theme plus a blank one, colours behind
a disclosure. Both measured rather than argued about -- rendered through
TestClient and driven under headless Chromium, where the tab bar moved
385->642px before and does not move now, and the themes page went from
5495px to 2820px.

Asking where generated images go found the other two. Deleting a chat
cascades to the attachment rows and leaves every file on disk; the helper
written for exactly that was called from one place, and it was not the
delete button, a schedule's chat, a helper's chat or deleting an account.
Underneath it, `claim` bound message_id and never chat_id, so anything
picked before a chat existed kept an empty chat_id forever -- which six
readers filter on, so those files were also unnamed in the prompt,
unopenable in the canvas, and invisible to the one caller the cleanup had.

And folders nest now. The route has handled parent_id since folders
existed, with a cycle guard and a depth cap the move path never applied;
the sidebar has always drawn a tree. Nothing could ask for one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/lembas/api/admin_branding.py

@@ -30,6 +30,14 @@ router = APIRouter(prefix="/admin/customization", tags=["admin-branding"])
 
 MAX_CUSTOM_CSS = 40_000
 
+# How many custom themes an instance may keep. Not a design limit -- there is
+# nothing in `theme_css` that cares -- but the whole set lives in one settings
+# row read into a process-level snapshot on every render, and the page offers a
+# blank block whenever there is room, so *some* number has to say when to stop
+# offering. Twelve is far past what anybody wants and small enough that the
+# stylesheet stays a stylesheet.
+MAX_THEMES = 12
+
 
 def _page(request: Request, db: Db, saved: str = "", error: str = "") -> Response:
     values = settings_store.get_group(db, branding_service.BRANDING)
@@ -55,6 +63,7 @@ def _page(request: Request, db: Db, saved: str = "", error: str = "") -> Respons
             "tokens": branding_service.THEME_TOKENS,
             "custom_themes": [t for t in brand.themes if not t.built_in],
             "bases": [name for name, _, _ in branding_service.BUILT_IN],
+            "max_themes": MAX_THEMES,
             "saved": saved,
             "error": error,
         },
@@ -167,6 +176,11 @@ async def save_themes(request: Request, db: Db, user: AdminUser) -> Response:
     every **read**, so a theme written straight into the settings table by hand,
     or stored by an earlier version, still has to produce a stylesheet that
     parses. Validating only on save would put that guarantee in the wrong place.
+
+    The indices need not be contiguous and are not renumbered. The page renders
+    one block per theme plus a blank one, so clearing an id in the middle leaves
+    a gap -- and a gap is simply an index with no id, which the loop already
+    skips. Renumbering would be work in aid of nothing.
     """
     form = await request.form()
     themes = []
@@ -186,6 +200,10 @@ async def save_themes(request: Request, db: Db, user: AdminUser) -> Response:
                 },
             }
         )
+    # Enforced here as well as in the template, because the template's job is to
+    # stop offering and this one's is to stop accepting -- a crafted POST is not
+    # the page.
+    themes = themes[:MAX_THEMES]
     _write(db, {"themes": themes})
     log.info("%d custom theme(s) saved by %s", len(themes), user.email)
     return RedirectResponse(

src/lembas/api/admin_users.py

@@ -16,6 +16,7 @@ from lembas.db.models import (
     ROLE_ADMIN,
     ROLE_PENDING,
     ROLE_USER,
+    Chat,
     Group,
     Model,
     User,
@@ -23,6 +24,7 @@ from lembas.db.models import (
 from lembas.security import permissions
 from lembas.security.passwords import hash_password, validate_password
 from lembas.security.sessions import revoke_all_for_user
+from lembas.services import chat as chat_service
 from lembas.services import settings_store, sharing
 from lembas.services import usage as usage_service
 from lembas.web.templating import render
@@ -249,6 +251,11 @@ async def delete_user(db: Db, user: AdminUser, user_id: str) -> Response:
     # still there to be found.
     sharing.forget_owner(db, target.id)
     sharing.forget_principal(db, PRINCIPAL_USER, target.id)
+    # And the same shape a third time: the chats cascade, their attachment rows
+    # cascade, and every file those rows named stays on disk with nothing left
+    # that will ever look at it. Before the delete, while the rows still say
+    # which files they are.
+    chat_service.delete_chats(db, list(db.scalars(select(Chat).where(Chat.user_id == target.id))))
     db.delete(target)
     db.commit()
     log.info("%s deleted account %s", user.email, email)

src/lembas/api/chats.py

@@ -2098,7 +2098,9 @@ async def delete_chat(db: Db, user: RequiredUser, chat_id: str) -> Response:
     # there would be nothing left to find it by and a shell would sit open on
     # somebody's machine until the idle timeout noticed.
     await terminal_service.close_chat(chat_id)
-    db.delete(chat)
+    # Not `db.delete(chat)`: that cascades to the attachment rows and leaves
+    # every file they name on disk forever. See `chat_service.delete_chats`.
+    chat_service.delete_chats(db, [chat])
     db.commit()
 
     response = Response(status_code=status.HTTP_204_NO_CONTENT)

src/lembas/api/folders.py

@@ -3,6 +3,7 @@
 from __future__ import annotations
 
 from fastapi import APIRouter, Depends, Form, HTTPException, Request, Response, status
+from sqlalchemy import select
 from sqlalchemy.orm import Session as DBSession
 
 from lembas.api.deps import Db, RequiredUser, require_permission
@@ -36,6 +37,62 @@ def _depth_of(db: DBSession, folder: Folder | None) -> int:
     return depth
 
 
+def _descendants(db: DBSession, folder: Folder) -> set[str]:
+    """Every folder under this one, and this one. Bounded by MAX_DEPTH."""
+    found = {folder.id}
+    frontier = [folder.id]
+    for _ in range(MAX_DEPTH + 1):
+        if not frontier:
+            break
+        children = list(
+            db.scalars(select(Folder).where(Folder.parent_id.in_(frontier)))
+        )
+        frontier = [c.id for c in children if c.id not in found]
+        found.update(frontier)
+    return found
+
+
+def _subtree_height(db: DBSession, folder: Folder) -> int:
+    """How many levels this folder's own subtree occupies, itself included.
+
+    A move has to consider it: the constraint is on the *deepest leaf* after the
+    move, not on the folder being dragged.
+    """
+    height = 1
+    frontier = [folder.id]
+    for _ in range(MAX_DEPTH + 1):
+        children = list(
+            db.scalars(select(Folder.id).where(Folder.parent_id.in_(frontier)))
+        )
+        if not children:
+            break
+        height += 1
+        frontier = children
+    return height
+
+
+def candidate_parents(db: DBSession, user_id: str, folder: Folder) -> list[Folder]:
+    """Folders this one could be moved into.
+
+    Everything the person owns, minus the folder itself and its own subtree --
+    which is the cycle guard in `update_folder` stated as a list rather than as
+    a refusal. A picker that offers a move the route will reject is a control
+    that looks like it works.
+
+    Depth is checked at the route rather than filtered here: it depends on how
+    tall *this* folder's subtree is, and a select that silently omitted a folder
+    for that reason would be unexplainable from the screen.
+    """
+    blocked = _descendants(db, folder)
+    return [
+        candidate
+        for candidate in db.scalars(
+            select(Folder).where(Folder.user_id == user_id).order_by(Folder.name)
+        )
+        if candidate.id not in blocked
+    ]
+
+
 def _refresh_sidebar() -> Response:
     """Tell the browser to reload so the tree re-renders.
 
@@ -141,6 +198,17 @@ async def update_folder(
                     "A folder cannot be moved inside itself.",
                 )
             cursor = db.get(Folder, cursor.parent_id) if cursor.parent_id else None
+        # And the depth cap, which `create_folder` has always applied and this
+        # path never did -- moving a three-deep subtree under a six-deep folder
+        # builds a tree nine deep, which is what MAX_DEPTH exists to keep out of
+        # the recursive sidebar template. It went unnoticed because nothing in
+        # the interface could submit `parent_id` at all until now.
+        subtree = _subtree_height(db, folder)
+        if new_parent is not None and _depth_of(db, new_parent) + subtree > MAX_DEPTH:
+            raise HTTPException(
+                status.HTTP_400_BAD_REQUEST,
+                f"Folders cannot be nested more than {MAX_DEPTH} deep.",
+            )
         folder.parent_id = new_parent.id if new_parent else None
 
     if "collapsed" in form:

src/lembas/api/pages.py

@@ -606,6 +606,12 @@ async def chat_index(
     )
 
 
+def _candidate_parents(db: DBSession, user_id: str, folder: Folder) -> list[Folder]:
+    from lembas.api.folders import candidate_parents
+
+    return candidate_parents(db, user_id, folder)
+
+
 @router.get("/folders/{folder_id}")
 async def folder_settings(request: Request, db: Db, user: RequiredUser, folder_id: str):
     """What a folder hands to the chats started inside it.
@@ -631,6 +637,10 @@ async def folder_settings(request: Request, db: Db, user: RequiredUser, folder_i
         {
             "folder": folder,
             "chat": None,
+            # Imported here rather than at module scope: `api.folders` imports
+            # `api.deps`, which this module is a peer of, and the pair have been
+            # kept apart deliberately.
+            "parents": _candidate_parents(db, user.id, folder),
             "models": chat_service.available_models(db, user),
             **_agent_context(db, user, None),
             **sidebar_context(db, user),