Setting up Salvor on two real projects

Setup caught a mistake in my own understanding

Part of the setup is writing down how the project actually runs: where it's deployed and which file is the live app. While filling that in for the backend, I found that the app actually deployed was a different file from the one I had been describing, both in my notes and in a public post. The setup step forced the question, and I corrected both.

A memory system is only as good as what goes into it. Being made to write the infrastructure down explicitly was worth it on its own.

A security catch before anything was written

The static site is deployed by copying the repository to the web server. Before setup, I checked what that meant: the repository's README.md was publicly readable on the live site. After setup, the memory folder, the rules file and the server notes would have been published the same way on the next deploy.

I blocked them with a server rule before creating any files:

.salvor/     -> 403
*.md         -> 403
tools/       -> 403

Bringing in what the project already knew

Both projects already had lessons, just not in Salvor's format. The backend had a list of 13 learned failures in a separate file. The site's lessons were spread across my own notes and fix commits. Setup proposed moving them in item by item: 13 for the backend, 12 for the site.

Salvor's rule is that each fact has one owner, so I had to decide whether the old list or the new memory was the source of truth. I moved everything into Salvor and left the old files as pointers. Every session since reads one place.

Fitting rules to projects that don't match the template

• No build step. Salvor's version rule assumes a build that stamps a version number. The site has no build. I mapped the version to the cache name in the site's service worker, which already had to change on every deploy. It fit naturally.
• A component without its own folder. The backend project's website is spread across the root, an articles/ folder, a tr/ folder and assets/. There was no obvious place for its notes file, so I put one note in articles/ that covers the whole site.
• Rules that depend on each other. The backend has three engines that must always change together. I named them as paired paths during setup, but then answered "no" to strict defaults, and that quietly switched off the very rule that checks paired paths. I turned that one rule back on by hand.

The first real task: known patterns, recognized in minutes

On the first day I asked an agent to "fix problems if any" on the live site. A phone check found two bugs: the English home page was dropping a whole group of game cards, and four English cards linked to Turkish pages.

Neither bug was new in kind. Both matched learned failures that were already in memory, just in new places. Because the pattern had a name, the agent recognized and fixed them in minutes instead of investigating from scratch.

Reviewing what the agents wrote

In provisional mode, agents write new lessons that wait for my approval. The first review round went the way it should: three items, each shown on its own with its evidence, and I answered each separately. The "provisional" marker on them survived every later edit until I approved them.

Setup was different. With 12 and 13 items to approve, I approved everything with a single instruction both times. That's rubber-stamping, and it's on me, but it also suggests something: ask in small batches, most important first, with "decide the rest later" as an option.

The status and health checks

Salvor's Claude Code plugin has a status command and a health check. Status gave a correct, short summary on the first try. The health check reported 11 passes, 2 warnings and 0 failures, and it found real drift I had introduced myself. I've written more about that in More Salvor tests.

If you set it up yourself

• Write the infrastructure down honestly. It may show you something you had wrong.
• Check whether your repository is served on the web before adding memory files.
• Move existing lessons in, and pick one owner for each.
• Approve in small batches. Don't let a long list turn review into a formality.