wife

$ wife show

Identity (5 facts)
  Who
  - Full-stack developer, mostly backend
  - Ships side projects solo, nights and weekends
  Preferences
  - Prefers short, implementation-first answers
  - Dislikes long explanations of things already known
  Working style
  - Always answer in Spanish
  █░░░░░░░░░░░░░░░░░░░░░░░ 61/1200 tokens

Project · checkout-api (3 facts)
  Stack
  - Uses Postgres, Fastify and Vitest
  Conventions
  - Never commit directly to main
  - Run the migrations before the test suite
  ░░░░░░░░░░░░░░░░░░░░░░░░ 27/800 tokens

Injected at session start
  ██░░░░░░░░░░░░░░░░░░░░░░ 174/2000 tokens

That block is handed to Claude Code and Codex at the start of every session. You never typed it. Wife learned it from things you already said, and it forgets anything you delete.

Why

You explain your stack. You explain that you want short answers. You explain that this repo runs migrations before tests. The session ends.

Tomorrow, you explain all of it again.

That is not a context-window problem — a model handles one session fine. The problem is that nothing survives the session boundary, and nothing ever learns. Instruction files are documents you maintain by hand. Session resume only reaches backwards into a single conversation. Compaction throws away the parts of a session it judges irrelevant to the current task, which is exactly where facts about you live.

Wife closes that gap with the only thing that actually works: a curator.

What it actually does

Storing text is trivial. The hard part — the entire product — is deciding what deserves to be remembered, what replaces what, and what has to go.

It waits before it believes you

A fact you mention once is staged, not stored. It has to come back in a different session before it reaches long-term memory. State it deliberately — remember that…, always…, never…, or wife remember — and it lands immediately, because you meant it.

This single rule is why Wife's memory stays small enough to trust.

It has a hard ceiling

1200 tokens for who you are. 800 for the current project. When a section fills up, the lowest-scoring fact is evicted, not appended.

score = confidence × recency × repetition × intent

Recency decays on a 90-day half-life for identity, 45 days for project memory. Pinned facts never decay and are never evicted. The ceiling is the design: without it, memory grows until it costs you tokens on every single turn.

It resolves contradictions instead of stacking them

Move off a framework and the old fact is replaced, with the change recorded. Restate something more precisely and the vaguer version is absorbed.

Two statements only merge when one strictly contains the other:

It lets go of what you stopped believing

Contradict a fact and it is replaced on the spot. But most beliefs don't die that cleanly — you just quietly stop working that way, and never say so.

Go quiet about something for long enough and it goes dormant: out of the injected context, still visible in the file under ## Dormant. Say it again and it comes straight back. Delete the line and it's gone for good.

## Dormant
_Not mentioned in a long time, so these are no longer sent to the agent._
_Say one again and it comes back. Delete the line to forget it for good._
- Uses Redis for caching

120 days for identity, 60 for the project, doubled for anything you stated deliberately. Pinned facts never go dormant — that's what pinning is for.

It notices what follows you between repos

Say "never commit directly to main" in one codebase and it's a house rule. Say it in your last three codebases and it's how you work. At three repos, a project fact is promoted into identity automatically, where it follows you everywhere.

wife spread shows what's on its way there.

It follows you between machines

Push your memory folder to a private repo and it works — right up to the day you use two machines in the same week. Then git hands you a text conflict in a file full of facts and asks you to pick a side, and every side loses something.

wife sync setup git@github.com:you/wife-memory.git   # once, per machine
wife sync                                            # commit, merge, push
wife clone git@github.com:you/wife-memory.git        # set up a new machine

Facts are content-addressed and carry their own provenance, so they merge by meaning rather than by line:

That last row is the quiet win: say something once on the laptop and once on the desktop, and it is finally enough to be remembered.

None of this is limited to two machines. Seven laptops converge as cleanly as two. And sessions/ is git-ignored, so raw prompts never leave the machine they were typed on.

It enforces what can be enforced

Injected text is a suggestion. The agent almost always follows it. Almost is not a guarantee — and for some rules that gap matters.

wife harden

Wife ships with no rules of its own. A fresh install has an empty memory and zero guards; everything below comes from things you said. wife harden scans your rules for the ones an agent hook can actually enforce, shows you each one, and turns on only what you approve.

If you happened to have written these, here is what it would offer:

Those shapes — git, package managers, deletes, protected files — are the ones recognised automatically because they are what people repeat most. They are not everybody's list, so any rule can be enforced directly:

wife guards --add "Never terraform apply against prod" --blocks "terraform apply"
wife guards --add "Don't touch prod config" --blocks "config/prod" --tool Edit
wife guards --add "No commits on release" --blocks "git commit" --on-branch release

wife guards --test "terraform apply -auto-approve"   # see what would happen

The rule stays in memory too, and that is deliberate: the guard stops the action, the memory stops the attempt. Without the memory the agent tries the forbidden thing and eats the block every round — deterministic, and a wasted turn each time.

Three constraints this is built under. Nothing is ever enforced without you approving it one rule at a time, because a guard invented from a sentence you never meant as a hard rule blocks work you asked for. A description is never a guard: Uses pnpm states a preference and blocks nothing, only Never use npm does. And guards fail open — a broken pattern allows the call, because a bug that blocks every command is far worse than a rule that missed once.

Most of what Wife knows maps to no tool call at all — tone, language, what you prefer to see first — so it stays as context by design. PreToolUse is only registered once you have a guard, so with none there is no hook in the path of your work.

It only reads what you wrote

Your agent's replies are never mined. When a model suggests "let's use Postgres" and you answer "ok", it has not learned a fact about you — it has heard its own idea repeated back. Wife reads your prompts and nothing else.

It separates you from your repo

Facts a