Skip to content
Victor Del Puerto
Go back

Functional Scars — turning corrections into a primitive

When I published Lucy Syndrome in LLM Agents a month ago, the argument was that AI coding agents systematically lose corrections between sessions, and that the fix is not more memory — it is enforcement code that runs outside the model. The paper laid out five invariants. The companion repository shipped the actual hooks I use in production at DG.

Today I am releasing the cleaner thing.

fscars is a Python package. You install it with pip install fscars, point it at a project, and it wires a single hook entrypoint into Claude Code. From that moment on, every correction you can express as a binary rule can be turned into a functional scar — a small piece of code that fires deterministically the next time the conditions for the original mistake show up.

The package lives at github.com/VDP89/fscars. It is Apache 2.0, alpha, and 5 starter scars come pre-installed.

Functional Scars launch animation: a wound receives stitches and becomes the fscars logo
The mark itself: a wound that receives its stitches.

The senior / junior analogy

A junior engineer reads the textbooks and learns the fundamentals. That is the floor. What turns the junior into a senior is the weight that mistakes leave behind: the migration that ran half-applied in production, the timezone bug that shipped to a customer, the build that broke at 2am. Those scars become heavier than any chapter of the book — they bend future decisions in a way pure knowledge cannot.

AI coding agents come into your project with a strong prior. Billions of tokens of training, especially on code. But the way your assistant behaves on your codebase is not just that prior; it is shaped by every correction you make along the way. The catch is that those corrections rarely survive: the next session starts from training again, and the model regresses to its statistical default in any area where the correction carries less weight than the prior.

A functional scar is the anchor that gives your correction enough weight to bend the next decision.

The four layers

The Lucy Syndrome paper frames correction persistence as four layers. Most of the industry stops at layer 3.

Four layers of correction persistence: system prompt, knowledge base, memory store, functional scar
Layers 1–3 present information; the model still chooses whether to apply it. Layer 4 runs outside the model.

Anthropic’s Managed Agents Memory (released April 2026) is layer 3 industrialized — a packaged version of “give the model a workspace it reads and writes.” It is useful and it is real. It also does not solve the problem the paper named, because the agent remains reader, decider, and writer with no enforcement layer outside it. I wrote about that distinction in detail in From memory to scar.

How it is built

The package has one small core and one small adapter today. The adapter API is public so the community (or future me) can wire other AI coding agents in.

fscars architecture: core modules wrap into adapters, adapters wire into platform-specific config
One core, many adapters. The cookbook scars are agent-agnostic.

Settings.json wires a single command — python -m fscars.run_hook — for every Claude Code event type. The engine reads the JSON payload from stdin, dispatches to whichever scars match, logs each fire, and emits the platform’s expected output. Failure inside any scar is swallowed; the host harness must never crash because of fscars.

The lifecycle of a scar

The way a correction becomes a scar in practice is short:

Lifecycle of a functional scar: bug occurs, you correct it, register a scar, hook intercepts the next time, fire is logged, recall computable, tune the trigger, correction holds
The loop runs to the right; observability runs underneath.

What makes the loop closeable is the bottom row — the logging primitive plus the opportunity observer. Without observed opportunities, recall is trivially fires / fires = 1.0, which tells you nothing. With them, you can see which scars actually catch the situations they were written for and which ones are too narrow.

What you actually get with v0.1.0

Five starter scars in the cookbook, ready to copy:

Plus a CLI: fscar init, fscar list, fscar log, fscar stats, fscar disable, fscar doctor.

pip install fscars
cd your-project
fscar init
fscar list

The first time a hook intercepts a regression you would otherwise have had to fix by hand, the value of the system stops being theoretical.

What this is not

It is not a SaaS. There is no login, no pricing tier, no remote telemetry. The logs live on disk in your project, in .fscars/logs/fires.jsonl.

It is not a model. It does not learn, it does not infer. Every action it takes is deterministic and traceable.

It is not a rewrite of the lucy-syndrome repository. That one is the academic companion code with a stable Zenodo DOI; fscars is the installable product. The two repositories are siblings, not replacements. Lucy Syndrome is the paper; fscars is the tool. Cite the paper if you build on the framework; install fscars if you want to run it.

Roadmap, honestly

The rewind command — the time-travel feature most people want first — is on the roadmap. The Codex CLI adapter is on the roadmap and the API is public so the community can write adapters for Cursor, Aider, Continue.dev. The cookbook will grow past five scars as the patterns stabilize.

What is not coming: a hosted service, a proprietary fork, a “Pro” tier. Those limits are stated in BRAND.md so they are harder to drift past later.

If you want to try it

The README at github.com/VDP89/fscars has the install + first-five-minutes flow. RELEASE.md has the full release procedure for maintainers. The companion paper, Lucy Syndrome in LLM Agents, explains why this primitive is missing from the stack and what the five invariants look like in practice.

If a scar fires for you and prevents a regression you would otherwise have had to fix by hand, the experiment worked.


Share this post on:

Next Post
From memory to scar: a four-layer progression