The shipped mark failed the one size it most needed to survive. At 16px
in a browser tab its outer strokes rasterised away entirely and the
2.5px gap between stroke and node filled in, so the favicon rendered as
an indeterminate horizontal smear rather than as anything. Three changes
fix it, all driven by that case and verified by rendering rather than by
reasoning: strokes stop at x=30 so the gap survives, outer opacity goes
.45/.55 -> .7 so the neighbours stay visible, and the node grows to
r=8.5 so it still reads as a disc.
This is not a rebrand. The mark is the same three-signals-converging
figure and keeps whatever recognition it has earned; only its
proportions changed. icon.svg and logo.svg had drifted slightly apart
(different node radii and stroke ends) and are now geometrically
identical, differing only in palette.
Adds the lockup, which had no asset at all, in two variants because one
cannot serve both jobs: public/lockup.svg uses currentColor for in-app
use, and docs/assets/lockup.svg fixes the colour to #0092fd for the
README. An <img src> reference resolves currentColor to black, so the
currentColor variant would be invisible against a dark README. The
wordmark carries textLength, without which it overruns the viewBox on
wider monospace fonts.
Concepts and the reasoning behind the ones not chosen are on the
docs/logo-concepts branch.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Keeps the reasoning behind PR #19 next to the code, since none of it is
recoverable from the diff: why memory_get stopped returning the embedding
and tsvector, why memory_patch refuses ambiguous matches rather than
picking one, and why memory_append was dropped as redundant with patch.
Also records P3 (mechanising file->memory mirroring) as DECLINED with its
reasoning and, more usefully, the condition that would reopen it — the
mirror going stale again now that patching is cheap. The evidence we had
pointed at edit cost, which P2 fixed; if drift recurs the cause was
attention instead, and the answer is probably to remove the duplication
rather than build a drift detector for it.
Notes two traps for anyone extending this: content_tsv is a generated
column so full-text search cannot rot after a patch (only the embedding
needs recomputing), and the obvious "does search find the patched text"
acceptance check therefore passes on an implementation that skips
re-embedding entirely.
The brief previously lived outside the repo. Moved rather than copied —
two hand-maintained copies is the exact drift problem described in the
document.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
shadowdaoandClaude Opus 5