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>
This commit is contained in:
2026-08-07 13:20:59 +02:00
parent 3afbccba81
commit c4aff999ba
25 changed files with 814 additions and 104 deletions
+71 -51
View File
@@ -18,6 +18,77 @@
<div class="alert alert--success">{{ icon("check", "icon--sm") }} <span>Prompts saved.</span></div>
{% endif %}
{#
The editor first, the reference after, and that ordering is the fix rather
than a preference.
The Variables legend and the Preview both run to a screen each, and they used
to sit *above* the tabs -- so the thing this page exists for started two
screens down. Every tab switch then had to move the viewport to be any use,
and `ui.js` did: it put the tab bar at the top of the scroller. On a short
panel the scroller cannot go that far, so the browser clamped to the maximum
and left the panel stranded above a screen of nothing, which reads as a page
that failed to load. That is the empty space; the scrolling was the cause and
not the cure.
With the tabs near the top there is nothing to scroll past: switching panels
changes what is below the bar and leaves the bar where it is. The reference
cards keep their place in the reading order -- after the work, where you go
to look something up -- and the preview still watches the form through
`hx-include`, which does not care about document order.
#}
<form method="post" action="/admin/prompts" id="prompt-form">
<div class="tabs">
<div class="tabs__bar" role="tablist">
{% for key, label, fragments in groups %}
<input class="visually-hidden" type="radio" name="prompts-tab"
id="tab-{{ key }}" {{ 'checked' if loop.first }}>
<label class="tabs__tab" for="tab-{{ key }}">{{ label }}</label>
{% endfor %}
</div>
<div class="tabs__body">
{% for key, label, fragments in groups %}
<section class="tabs__panel" data-tab="tab-{{ key }}">
{% for fragment in fragments %}
{% with value = values[fragment.key], overridden = fragment.key in overridden %}
{% include "admin/_prompt_field.html" %}
{% endwith %}
{% endfor %}
</section>
{% endfor %}
</div>
</div>
<section class="card">
<h2 class="card__title">Length</h2>
<div class="field">
<label class="field__label" for="max-harness-chars">Preamble character cap</label>
<input class="input" id="max-harness-chars" name="max_harness_chars" type="number"
min="0" max="100000" value="{{ max_harness_chars }}">
<p class="field__hint">
Everything above is cut off past this. <code>0</code> means the built-in
{{ default_harness_chars }}. It is a backstop against a large skill index
or memory list quietly eating the context window, not a budget to tune.
</p>
</div>
</section>
<div class="form-actions">
<button class="btn btn--primary" type="submit">Save settings</button>
{#
data-confirm-button, not data-confirm: this button acts on its own through
formaction, and confirming the whole form would also catch plain Save.
#}
<button class="btn" type="submit" formaction="/admin/prompts/reset"
data-confirm-button="Put every prompt back to its built-in wording? Everything you have edited here is lost."
data-confirm-title="Restore defaults" data-confirm-label="Restore">
Restore all defaults
</button>
</div>
</form>
<section class="card">
<h2 class="card__title">Variables</h2>
<p class="card__lede">
@@ -134,57 +205,6 @@
keyup changed delay:700ms from:#prompt-form"></div>
</section>
<form method="post" action="/admin/prompts" id="prompt-form">
<div class="tabs">
<div class="tabs__bar" role="tablist">
{% for key, label, fragments in groups %}
<input class="visually-hidden" type="radio" name="prompts-tab"
id="tab-{{ key }}" {{ 'checked' if loop.first }}>
<label class="tabs__tab" for="tab-{{ key }}">{{ label }}</label>
{% endfor %}
</div>
<div class="tabs__body">
{% for key, label, fragments in groups %}
<section class="tabs__panel" data-tab="tab-{{ key }}">
{% for fragment in fragments %}
{% with value = values[fragment.key], overridden = fragment.key in overridden %}
{% include "admin/_prompt_field.html" %}
{% endwith %}
{% endfor %}
</section>
{% endfor %}
</div>
</div>
<section class="card">
<h2 class="card__title">Length</h2>
<div class="field">
<label class="field__label" for="max-harness-chars">Preamble character cap</label>
<input class="input" id="max-harness-chars" name="max_harness_chars" type="number"
min="0" max="100000" value="{{ max_harness_chars }}">
<p class="field__hint">
Everything above is cut off past this. <code>0</code> means the built-in
{{ default_harness_chars }}. It is a backstop against a large skill index
or memory list quietly eating the context window, not a budget to tune.
</p>
</div>
</section>
<div class="form-actions">
<button class="btn btn--primary" type="submit">Save settings</button>
{#
data-confirm-button, not data-confirm: this button acts on its own through
formaction, and confirming the whole form would also catch plain Save.
#}
<button class="btn" type="submit" formaction="/admin/prompts/reset"
data-confirm-button="Put every prompt back to its built-in wording? Everything you have edited here is lost."
data-confirm-title="Restore defaults" data-confirm-label="Restore">
Restore all defaults
</button>
</div>
</form>
<section class="card">
<h2 class="card__title">Tool descriptions</h2>
<p class="card__lede">