Carry one decision between tools

Make a real project convention durable in one session, recover it in another tool after closing the first, correct it at the source, and see the scope rule keep other projects out.

Outcome and prerequisites

You will prove that durable context survives two boundaries a conversation cannot: the end of a session, and the move to a different tool. Then you will correct it at the source and confirm that another project cannot see it.

Install and connect your first tools completed.
Two connected tools make the handoff visible. Two separate sessions of one tool prove persistence just as well.
A real project folder, and a second one for the scope check.

Choose one decision worth keeping

Use something concrete, harmless, and genuinely load-bearing for future work. A package-manager choice, a supported deployment target, a naming rule, or a correction to an assumption that turned out wrong are all good. The test of a good memory is whether a session that did not know it would do something different.

Worth remembering	Not worth remembering
"Use Bun for JavaScript tasks in this repository."	"The user asked me to check the tests."
"Releases are triggered by a version bump on main."	"The build is currently failing."
"Do not hand-edit the generated site directory."	A full transcript of how you reached the decision.

The right-hand column is transient. It is true today and misleading next week, and a memory store full of it makes recall worse rather than better.

Confirm it, then have the tool remember it

In the first connected tool, establish the decision explicitly, then ask for it to be stored:

We have confirmed that this repository uses Bun for JavaScript tasks. Remember that durable convention with source synapsetutorial.

The tool should call remember once, with project scope and this repository's root, and return an ID. Two things can go wrong here and both are worth noticing:
- It stores a transcript instead of the decision. A memory should be one durable idea in one or two sentences. You will fix this in the correction step.
- It stores global scope instead of project. Global memory is returned in every project, which is right for a preference about how you like to work and wrong for a fact about one repository.
Close the session completely

Exit the first tool. Not a new conversation inside it — exit it. This is what rules out conversational context and leaves the local database as the only thing carrying the decision forward.
Recall it from the other tool

Open the second connected tool in the same repository. If it is Claude Code, look at what happens before you type anything: the session hook has already recalled this project's memory and handed it over, so the convention is in context from the first turn. That is the difference between memory that works and memory that depends on the model remembering to ask.

Either way, ask a question the convention should change the answer to:

What command should I use to install dependencies here?

It should answer with Bun rather than npm, and be able to say where that came from. If it guesses wrong, ask it explicitly to recall the JavaScript tooling convention for this project — that tells you whether the memory is missing or merely was not consulted.
Inspect the source of truth and correct it

What the tool reported is a rendering. Go and look at the record itself:
shell
```
synapse memory list "Bun JavaScript"
```
text
```
4	project:/Users/example/project	synapsetutorial	We confirmed together that this repository uses Bun for JavaScript tasks rather than npm, after discussing…
```
shell
```
synapse memory show 4
```
If the body is a paragraph of conversation rather than a durable statement, replace it. Editing keeps the same ID, so nothing else has to change and no contradicting second record is created:
shell
```
printf '%s\n' 'Use Bun for JavaScript tasks in this repository.' \
  | synapse memory edit 4 synapsetutorial
```
text
```
Updated memory #4
```
Start one more new session and ask again. The answer should now reflect the corrected text — which proves that editing changed the durable source rather than layering a correction on top of a wrong record.

Correcting beats appending
Two memories that disagree are worse than one that is slightly wrong, because recall returns both and the model has to guess which is current. When the wording was bad, edit the record. When the old version was true and stopped being true, add the new one with synapse memory supersede so the old text stays readable but out of recall. Add a plain second memory only when it is genuinely a new fact.
Prove other projects cannot see it

This is the property that makes a shared store usable. Open a session in an unrelated project and ask the same question:

What command should I use to install dependencies here?

It must not answer with the first project's convention. Confirm from the terminal that the record is scoped where you think it is:
shell
```
synapse memory show 4
```
text
```
Memory #4
Scope: project
Project: /Users/example/project
Source: synapsetutorial
```
Recall from any project returns everything global plus everything stored for that project. Another project's memory never enters the response. The project root is resolved by walking up for a .git directory or a .synapse.yaml, so a session opened in a subdirectory still resolves to the same root — which is why the same memory is found whether you start at the repository top or three folders down.
Store one thing globally, and see the difference

Some things belong everywhere. A preference about how you like to work is not a fact about one repository:
shell
```
printf '%s\n' 'Prefer small, focused commits with imperative subject lines.' \
  | synapse memory add synapsetutorial --global
```
text
```
Stored memory #5
```
Now recall from both projects. The global preference appears in each; the Bun convention appears in only one. That split — global plus this project, never another project — is the entire scope model, and it is enforced in the query rather than trusted to the caller.

Keep or clean up

If the convention is real, keep it — you have just made your tools better at this repository. If it was tutorial-only, remove the exact IDs:

shell

synapse memory list synapsetutorial
synapse memory delete 4 --confirm
synapse memory delete 5 --confirm

Deleting requires --confirm and names the record it is about to remove. Avoid synapse memory wipe unless you genuinely intend to remove every memory in the store; it exists for starting over, not for tidying.

Next step

You have finished the newcomer level. Continue with Curate and optimize memory, which is about keeping a store useful once it has more than a handful of entries in it.

Outcome and prerequisites

Choose one decision worth keeping

Confirm it, then have the tool remember it

Close the session completely

Recall it from the other tool

Inspect the source of truth and correct it

Prove other projects cannot see it

Store one thing globally, and see the difference

Keep or clean up

Next step