Skip to content

Memory about a file

git blame says who changed a line. A linter says what is wrong with it now. Only bee can say what happened the last time someone touched this file, and what they did about it.

Terminal window
bee remember "the ** boundary was silently dropped, so **/foo.cs matched notfoo.cs" \
--type error \
--solution "keep the boundary: (?:.*/)? not .*" \
--prevention "test a negative — a pattern that must NOT match" \
--path 'src/Bee/Hooks/*.cs'

From then on, anyone about to change a matching file sees it:

Terminal window
bee lint src/Bee/Hooks/PathGlob.cs
# bee — known about src/Bee/Hooks/PathGlob.cs
# - [error] the ** boundary was silently dropped, so **/foo.cs matched notfoo.cs
# ↳ fix: keep the boundary: (?:.*/)? not .*
# ↳ avoid: test a negative — a pattern that must NOT match
# ↳ matched: src/Bee/Hooks/*.cs

--path is repeatable and uses the same glob notation as rules — the same matcher, in fact, because two authorities for what a glob means is one too many.

anchored memory
bee lint on a matching file ✅ delivered
bee lint on any other file — silent
the pre-write hook ✅ delivered
session start not delivered
every prompt not delivered
bee remember search ✅ still findable

The two absences are the feature. An anchored memory costs nothing on the turns that do not touch its file — measured at about 37 tokens for the example above, paid only when that path is named.

When the cap bites, the least urgent thing is what falls off. Someone about to change a file needs “this broke last time” before “here is a convention”, so error memories are ordered ahead of the rest. The command surfaces up to 5; the pre-write hook takes 3, since it rides beside the rules in a two-second budget.

Terminal window
bee lint --memory 0 # skip it entirely
bee lint --memory 10 # or ask for more

The block is rendered under its own heading, apart from the rules, and that is not cosmetic.

A rule is an instruction to follow. A memory is a fact about the past. Rendered in one list a model treats them alike — and obeying an error memory that describes a bug means reproducing it. Different heading, different verb.

The fix and the prevention travel with the problem, because “this broke once” without “and here is what fixed it” is a warning nobody can act on.

Anchor the thing that would otherwise be rediscovered:

Terminal window
# a trap in a specific file
bee remember "AppKit stamps no audit fields — set CreatedAt in the initializer" \
--type error --solution "= DateTimeOffset.UtcNow on the property" \
--path '**/Entities/*.cs'
# a decision that governs a directory
bee remember "this layer is CQRS write-side; reads go through the projection" \
--type decision --reason "the read model has a different consistency contract" \
--path 'src/Orders/Commands/**'

Do not anchor what is true everywhere — that is a rule, or an ordinary memory. Anchoring is for what only matters here.