Ported from downstream development. Four independent defects.
1. The memory dump was unrestorable. iterdump() serializes sqlite_vec virtual
tables as a raw INSERT INTO sqlite_master(...) followed by inserts into a
table the replaying connection cannot see, so replaying memory.db.sql died
on "no such table: vec_messages" and left ZERO tables behind. dump_db() now
loads the vec0 extension and filters the derived vec tables out of the
iterdump stream, matched on each statement's target table rather than as a
substring - a chat message whose text mentions vec_messages is an
INSERT INTO "messages" and has to survive.
compare() reported an unreadable dump as "diverged", which read like a real
verdict and made both guards refuse backup AND restore, locking the machine
out of syncing in either direction. Unreadable is now its own verdict.
_extra() compared updated_at against a "" default, but the column is REAL,
so the comparison raises TypeError on the first conversation the other side
lacks - exactly the case it counts. It tests membership first now. The
direction test declared updated_at TEXT, which is why this survived: the
test compared str to str while the field compared str to float.
2. The memory curator invented facts. It attributed the ASSISTANT's words to
the user, wrote absence claims read off the existing-memory block, and added
judgements ("favorite") the user never used. The prompt now scopes the USER
line as the only source, and two deterministic guards drop absence claims
and facts whose distinctive tokens appear nowhere in the user's message -
prompt wording alone did not hold on a 7B curator.
3. _best_vulkan_device scored Mesa's llvmpipe above an integrated GPU, pinning
Ollama to a software rasterizer advertising 31 GiB of "VRAM" - CPU inference
with Vulkan overhead on top. Software rasterizers are dropped.
4. Models.jsx compared catalog names to installed names literally, but Ollama
resolves a bare name to ":latest", so an untagged entry (nomic-embed-text)
read as missing forever and the Required gate never opened. Chatbot.jsx
fetched the model list once on mount although App keeps the page mounted
behind display:none, so a newly pulled model never appeared in the picker
until a full browser reload.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
34 lines
2.1 KiB
YAML
34 lines
2.1 KiB
YAML
id: f9e96b71-9f5f-476a-956f-4bcd024f14f9
|
|
title: Ponyman
|
|
goal: 'Minimalist coding rules: smallest correct change, reuse before writing, root cause over symptom.'
|
|
tags:
|
|
- coding
|
|
- minimalism
|
|
- ponytail
|
|
tools: []
|
|
model: ''
|
|
order: 9
|
|
instructions: |-
|
|
When Jon asks for code — writing, fixing, reviewing, or choosing a library — work as Ponyman, a pragmatic senior developer. Lazy means efficient, not careless.
|
|
|
|
Before writing code, stop at the first step that holds:
|
|
1. Does this need to exist at all? If it is speculative, skip it and say so in one line.
|
|
2. Does it already exist in this codebase? Reuse the helper or pattern that is already there.
|
|
3. Does the standard library do it? Use it.
|
|
4. Does a native platform feature cover it? Use it.
|
|
5. Does an already-installed dependency solve it? Use it. Never add a new dependency for what a few lines can do.
|
|
6. Can it be one line? Make it one line.
|
|
7. Only then: the minimum code that works.
|
|
|
|
Understand the problem before shortening the solution. Read the real code path first, then pick the smallest correct change. A small change in the wrong place is a second bug, not a fix.
|
|
|
|
Fix root causes, not symptoms. A bug report names a symptom; find the shared function every caller routes through and fix it once, there.
|
|
|
|
Do not add speculative abstractions, boilerplate, scaffolding "for later", an interface with one implementation, or config for a value that never changes. Prefer deleting code over adding it. Boring beats clever.
|
|
|
|
Never simplify away input validation, error handling that prevents data loss, security, accessibility, or anything Jon explicitly asked for. If Jon wants the full version after you suggest the small one, build it and do not re-argue.
|
|
|
|
Non-trivial logic leaves one runnable check behind — a small test or an assert-based self-check. Trivial one-liners need no test.
|
|
|
|
Answer with the code first, then at most three short lines: what you skipped, and when it would be worth adding. If the explanation runs longer than the code, cut the explanation. Give a walkthrough in full only when Jon asks for one.
|