memgineering 0.5.0 → 0.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +437 -0
- package/NOTICE +22 -0
- package/README.md +1 -1
- package/assets/MEMGINEERING.md +44 -173
- package/assets/memgineering-memory/SKILL.md +44 -329
- package/assets/memgineering-recall/SKILL.md +142 -0
- package/assets/memgineering-rules/SKILL.md +111 -0
- package/assets/memgineering-setup/SKILL.md +184 -119
- package/assets/memgineering-writing/SKILL.md +183 -0
- package/dist/index.js +2575 -753
- package/package.json +1 -1
package/assets/MEMGINEERING.md
CHANGED
|
@@ -1,183 +1,54 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: memgineering
|
|
3
|
-
description: Use whenever the user refers to something they told you before, asks what was decided,
|
|
3
|
+
description: Use whenever the user refers to something they told you before, asks what was decided, tells you something worth keeping, or settles something that should hold next time. The memory lives in their own folder and outlives this session; check it before answering from guesswork, and write to it when you learn something durable.
|
|
4
4
|
type: skill
|
|
5
|
-
version: 0.
|
|
5
|
+
version: 0.5.0
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
# memgineering
|
|
9
9
|
|
|
10
|
-
The user has a **brain** — a folder of their own notes
|
|
11
|
-
|
|
12
|
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
## Which tools this actually reaches, today
|
|
16
|
-
|
|
17
|
-
Answer this from here, not from a guess. "Every AI tool" above means every tool
|
|
18
|
-
that can run this CLI — and that is a shorter list than people assume.
|
|
19
|
-
|
|
20
|
-
| | |
|
|
21
|
-
| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
|
|
22
|
-
| **Claude Code · Codex · Gemini CLI** | `memgineering setup` installs into these. They read and write the same brain. |
|
|
23
|
-
| **Anything else with a shell** | Works — the CLI is the whole interface. Nothing has to be built for a new tool. |
|
|
24
|
-
| **ChatGPT · Claude on the web · phone apps** | **Not yet.** There is no connector. A hosted brain is reachable by them in principle and is not wired up in practice. |
|
|
25
|
-
|
|
26
|
-
So when someone asks _"will my ChatGPT remember this too?"_, the answer is **not
|
|
27
|
-
yet, and here is what does** — not a hedge, and not a promise. Saying "you are
|
|
28
|
-
signed in, so it works everywhere" is the specific wrong answer: the account
|
|
29
|
-
syncs the brain between machines, it does not add a surface that can read it.
|
|
10
|
+
The user has a **brain** — a folder of their own notes, read and written through
|
|
11
|
+
the `memgineering` CLI by any AI tool that can run it. It outlives this session
|
|
12
|
+
and this tool, so treat it as where what they know actually lives. Never edit
|
|
13
|
+
those files by hand: only the CLI records the change and keeps `undo` working.
|
|
30
14
|
|
|
31
15
|
## When to reach for it
|
|
32
16
|
|
|
33
|
-
**
|
|
34
|
-
|
|
35
|
-
|
|
36
|
-
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
**
|
|
46
|
-
|
|
47
|
-
`
|
|
48
|
-
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
61
|
-
|
|
62
|
-
-
|
|
63
|
-
-
|
|
64
|
-
|
|
65
|
-
|
|
66
|
-
|
|
67
|
-
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
71
|
-
that matters rather than all of them.
|
|
72
|
-
|
|
73
|
-
```
|
|
74
|
-
memgineering open <handle> # claims behind the card
|
|
75
|
-
memgineering open <handle> --detail full # the whole note
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
`open` also takes a note's exact title or its path, so you do not need to
|
|
79
|
-
recall first when you already know what you want.
|
|
80
|
-
|
|
81
|
-
**Check the evidence before trusting an old memory,** or when two of them
|
|
82
|
-
disagree:
|
|
83
|
-
|
|
84
|
-
```
|
|
85
|
-
memgineering evidence <handle>
|
|
86
|
-
```
|
|
87
|
-
|
|
88
|
-
How often it has been surfaced, how often anyone read it, when it last changed
|
|
89
|
-
and why. **Newer does not win**: a rule that has stood for eleven months has
|
|
90
|
-
eleven months of nobody contradicting it behind it. Use whether it was actually
|
|
91
|
-
reached for, not its date.
|
|
92
|
-
|
|
93
|
-
**Remember when you learn something durable** — a decision, a constraint, a
|
|
94
|
-
correction the user made, how something actually works:
|
|
95
|
-
|
|
96
|
-
```
|
|
97
|
-
memgineering remember "deploys are manual — launchctl by hand, no CD" --reason "watched it twice"
|
|
98
|
-
```
|
|
99
|
-
|
|
100
|
-
No approval step, by design. It is recorded and reversible (`memgineering
|
|
101
|
-
undo`), so the cost of a wrong entry is one command, not a permanent mistake.
|
|
102
|
-
Do not ask permission for ordinary observations — write them.
|
|
103
|
-
|
|
104
|
-
**Always pass `--reason`.** Every write verb takes it and it goes in the ledger.
|
|
105
|
-
It is the only part of a record that still means anything to whoever reads it
|
|
106
|
-
six months from now, and it is refused if it looks like it carries a credential.
|
|
107
|
-
|
|
108
|
-
**Revise when a conclusion changes:**
|
|
109
|
-
|
|
110
|
-
```
|
|
111
|
-
memgineering revise <handle> --claim "Deploying is manual now." --summary "manual only"
|
|
112
|
-
```
|
|
113
|
-
|
|
114
|
-
**Get their notes out whenever they ask** — a backup, a new machine, "where is
|
|
115
|
-
my memory actually kept", or plain curiosity about what is stored:
|
|
116
|
-
|
|
117
|
-
```
|
|
118
|
-
memgineering pull ~/my-brain
|
|
119
|
-
```
|
|
120
|
-
|
|
121
|
-
It downloads their hosted brain as markdown and **never overwrites** a file
|
|
122
|
-
already there, so it is safe to run twice and safe to point at the wrong
|
|
123
|
-
folder. `push` is the other direction and never deletes anything locally.
|
|
124
|
-
|
|
125
|
-
Say what arrives: notes the brain excludes from recall come down too, with
|
|
126
|
-
`.memgignore` beside them. Excluded means "stop reading this", not "this is no
|
|
127
|
-
longer theirs" — but readable files in a folder is not something to let them
|
|
128
|
-
discover later. What lands is markdown, not yet a brain here; offer
|
|
129
|
-
`memgineering link <folder>` rather than running it.
|
|
130
|
-
|
|
131
|
-
## What to raise with the user rather than just doing
|
|
132
|
-
|
|
133
|
-
The tool does not gate writes; your judgement does. Tell them — plainly, once
|
|
134
|
-
— when:
|
|
135
|
-
|
|
136
|
-
- the change touches `01_BASE/` (their identity, preferences, boundaries,
|
|
137
|
-
tooling). The output marks these `⚠ critical target`.
|
|
138
|
-
- you are recording something they said in passing that they may not want kept
|
|
139
|
-
- what you learned contradicts a memory that is currently marked current
|
|
140
|
-
|
|
141
|
-
Everything else: write it and mention it in a sentence.
|
|
142
|
-
|
|
143
|
-
## Depth costs context — ask for what you need
|
|
144
|
-
|
|
145
|
-
`recall` returns cards, not notes, so calling it often is cheap. Reach for more
|
|
146
|
-
only when a summary is not enough:
|
|
147
|
-
|
|
148
|
-
| depth | what you get |
|
|
149
|
-
| ------------------ | ----------------------------------------------- |
|
|
150
|
-
| `--detail card` | title + summary (default) |
|
|
151
|
-
| `--detail summary` | + the note's headings |
|
|
152
|
-
| `--detail chunks` | + every section, or one with `--section <name>` |
|
|
153
|
-
| `--detail full` | the whole note |
|
|
154
|
-
|
|
155
|
-
`recall "<q>" --limit 1 --detail full` is "find the best match and read it" in
|
|
156
|
-
one call.
|
|
157
|
-
|
|
158
|
-
## At the start of a session
|
|
159
|
-
|
|
160
|
-
```
|
|
161
|
-
memgineering resurface
|
|
162
|
-
```
|
|
163
|
-
|
|
164
|
-
Ranks by what has been recalled in this folder before, how recently, and which
|
|
165
|
-
of their base notes have gone unread. No query needed — this is the one that
|
|
166
|
-
tells you what you should already know here.
|
|
167
|
-
|
|
168
|
-
## Rules
|
|
169
|
-
|
|
170
|
-
- **Never edit brain files directly.** Use the CLI: it records what changed and
|
|
171
|
-
keeps `undo` working. A hand edit is invisible to that.
|
|
172
|
-
- **Never invent a handle.** They come from `recall`, `resurface` or `open`.
|
|
173
|
-
- **Full ids in durable places.** The short handle is for this conversation;
|
|
174
|
-
when you save a reference in your own memory or a document, use the full `id:`
|
|
175
|
-
that `open` prints.
|
|
176
|
-
- **Nothing matched is a real answer.** Say the brain has nothing on it rather
|
|
177
|
-
than filling the gap with a guess.
|
|
178
|
-
- **Their notes are theirs.** `revise` only touches the memory block in
|
|
179
|
-
frontmatter; prose is never rewritten by this tool, and should not be
|
|
180
|
-
rewritten by you without being asked.
|
|
181
|
-
|
|
182
|
-
If `memgineering: command not found`, install with `npm i -g memgineering`,
|
|
183
|
-
then `memgineering setup`.
|
|
17
|
+
- **Anything that sounds already settled** — a past decision, their setup, their
|
|
18
|
+
preferences, or before repeating advice you have no evidence they wanted:
|
|
19
|
+
`memgineering recall "<their words>"`
|
|
20
|
+
- **Write it down when any of these happens** — something turned out to work a
|
|
21
|
+
particular way; a choice got made, by them or by you; an attempt failed, and
|
|
22
|
+
what finally worked instead; they said "let's do it this way"; they looked at
|
|
23
|
+
what you did and said it was right: `memgineering remember "<it>" --reason
|
|
24
|
+
"<why>"`. Reversible by design, so do not ask permission for ordinary
|
|
25
|
+
observations.
|
|
26
|
+
- **They settled something that should hold next time** — "from now on",
|
|
27
|
+
"never", "we always do it this way" — the same verb with `--rule`, which puts
|
|
28
|
+
it in front of an agent before it edits a file rather than after someone asks.
|
|
29
|
+
- **A new folder, or "where were we"** — `memgineering resurface`, no query.
|
|
30
|
+
|
|
31
|
+
`--reason` on every write: it is the only part of the record that still means
|
|
32
|
+
anything six months later, and it is refused if it looks like a credential.
|
|
33
|
+
|
|
34
|
+
Write what you checked, not what you worked out. A decision is whatever they
|
|
35
|
+
say it is; a fact that a command or a file could confirm — an address, an
|
|
36
|
+
identifier, a version, a number — goes in verified or not at all. Recalled
|
|
37
|
+
later, a guess is indistinguishable from a fact.
|
|
38
|
+
|
|
39
|
+
## Where the detail is
|
|
40
|
+
|
|
41
|
+
`memgineering-memory` is the map — which verb answers which question. It points
|
|
42
|
+
at four skills, each of which also loads on its own when its topic comes up:
|
|
43
|
+
|
|
44
|
+
- `memgineering-recall` — recall, open, evidence, resurface, how much to ask for
|
|
45
|
+
- `memgineering-writing` — remember, revise, undo, retire, exclude, `01_BASE/`
|
|
46
|
+
- `memgineering-rules` — decisions that bind, and the before-edit hook
|
|
47
|
+
- `memgineering-setup` — installing, which tools this reaches, accounts, moving a brain
|
|
48
|
+
|
|
49
|
+
Tools with a SKILL.md description-matcher (Claude Code, Codex, Grok) auto-load these.
|
|
50
|
+
Tools without one (e.g. Antigravity): READ `<tool-home>/skills/memgineering-<name>/SKILL.md`
|
|
51
|
+
when its topic comes up.
|
|
52
|
+
|
|
53
|
+
If `memgineering: command not found`, install with `npm i -g memgineering`, then
|
|
54
|
+
`memgineering setup`.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: memgineering-memory
|
|
3
|
-
description: Use when the user
|
|
3
|
+
description: Use when the user refers to something they told you before, asks what was decided, tells you something worth keeping, settles something that should hold next time, or wants their memory set up so it knows who they are. Triggers include "what did I decide about X", "check my notes", "how do we do this again", "remember this", "is this still true", "from now on", "never do X again", "set up my memory", "fill in my profile", "what do you know about my setup". This is the map — it says which verb answers which question and points at the skill that covers it.
|
|
4
4
|
type: skill
|
|
5
5
|
allowed-tools: Bash(memgineering:*)
|
|
6
6
|
---
|
|
@@ -12,352 +12,67 @@ database: they wrote those files, they can open them in any editor, and
|
|
|
12
12
|
memgineering reads them and keeps a derived index outside the folder. Deleting
|
|
13
13
|
that index costs a rebuild and nothing else.
|
|
14
14
|
|
|
15
|
-
|
|
16
|
-
|
|
15
|
+
This page is the map. Each verb below has one or two lines here and its detail
|
|
16
|
+
in one of four skills; open the one you need rather than all of them.
|
|
17
17
|
|
|
18
|
-
##
|
|
18
|
+
## Which verb answers which question
|
|
19
19
|
|
|
20
|
-
|
|
21
|
-
|
|
20
|
+
| the question in front of you | verb | detail |
|
|
21
|
+
| -------------------------------------------------------------- | ---------------------------------- | ---------------------- |
|
|
22
|
+
| "what did we decide about…", anything that sounds settled | `recall "<their words>"` | `memgineering-recall` |
|
|
23
|
+
| you have a card and need what is behind it | `open <handle>` | `memgineering-recall` |
|
|
24
|
+
| two memories disagree, or one looks old | `evidence <handle>` | `memgineering-recall` |
|
|
25
|
+
| new folder, or "where were we" — nothing to search for yet | `resurface` | `memgineering-recall` |
|
|
26
|
+
| you learned something durable | `remember "<it>" --reason "<why>"` | `memgineering-writing` |
|
|
27
|
+
| a conclusion you recorded has changed | `revise <ref> --claim …` | `memgineering-writing` |
|
|
28
|
+
| that write was wrong | `undo --reason "<why>"` | `memgineering-writing` |
|
|
29
|
+
| no longer current / stop reading this file | `retire` · `exclude` | `memgineering-writing` |
|
|
30
|
+
| their `01_BASE/` files are still templates | `onboard`, then ask | `memgineering-writing` |
|
|
31
|
+
| the user settled something that should hold next time | `remember "<it>" --rule` | `memgineering-rules` |
|
|
32
|
+
| what already binds me here? | `rules` | `memgineering-rules` |
|
|
33
|
+
| nothing is connected yet, or it needs to reach another machine | `link` · `init` · `push` · `pull` | `memgineering-setup` |
|
|
22
34
|
|
|
23
|
-
|
|
24
|
-
memgineering recall "how do we deploy"
|
|
25
|
-
```
|
|
35
|
+
Everything below is what holds no matter which of those you are doing.
|
|
26
36
|
|
|
27
|
-
|
|
28
|
-
## recall: how do we deploy (2 cards)
|
|
37
|
+
## Recall before you answer, write when you learn
|
|
29
38
|
|
|
30
|
-
|
|
31
|
-
stated
|
|
39
|
+
Two habits, and they are the whole product:
|
|
32
40
|
|
|
33
|
-
|
|
41
|
+
- **Before answering anything that sounds already settled**, recall. Their
|
|
42
|
+
project, their setup, their preferences, their past reasoning — and before
|
|
43
|
+
repeating advice you have no evidence they wanted.
|
|
44
|
+
- **When this session decides something durable**, write it. No approval step
|
|
45
|
+
by design: it is recorded and reversible, so a wrong entry costs one `undo`,
|
|
46
|
+
not a permanent mistake. Do not ask permission for ordinary observations.
|
|
34
47
|
|
|
35
|
-
`
|
|
36
|
-
|
|
48
|
+
**Pass `--reason` on every write.** It goes in the ledger and it is the only
|
|
49
|
+
part of the record that still means anything to whoever reads it six months
|
|
50
|
+
from now. It is refused if it looks like it carries a credential.
|
|
37
51
|
|
|
38
|
-
|
|
39
|
-
|
|
52
|
+
If the user settled something rather than told you something — "from now on",
|
|
53
|
+
"never", "we always do it this way" — that takes `--rule`. See `memgineering-rules`.
|
|
40
54
|
|
|
41
|
-
|
|
42
|
-
not a list of answers: anything matching a word from the query is returned, so
|
|
43
|
-
the tail of a long result can be only loosely related. That is deliberate —
|
|
44
|
-
for a memory system, failing to return a note someone knows is there is worse
|
|
45
|
-
than returning one they can ignore. Use the top matches that actually answer
|
|
46
|
-
the question and leave the rest; quoting all of them back as if each were
|
|
47
|
-
relevant is how a useful recall turns into noise.
|
|
55
|
+
## What to raise rather than just doing
|
|
48
56
|
|
|
49
|
-
|
|
50
|
-
|
|
51
|
-
|
|
52
|
-
|
|
53
|
-
|
|
54
|
-
memgineering open deploy-manual --detail chunks # + every section
|
|
55
|
-
memgineering open deploy-manual --section preflight # one section
|
|
56
|
-
memgineering open deploy-manual --detail full # the whole note
|
|
57
|
-
```
|
|
58
|
-
|
|
59
|
-
`open` takes a handle, a full id, a path inside the brain, or a note's exact
|
|
60
|
-
title — so when you already know what you want, skip the recall.
|
|
61
|
-
|
|
62
|
-
### When one round trip is enough
|
|
63
|
-
|
|
64
|
-
```
|
|
65
|
-
memgineering recall "deploy" --limit 1 --detail full
|
|
66
|
-
```
|
|
67
|
-
|
|
68
|
-
Best match, read whole, one call. Use this when the user's question clearly
|
|
69
|
-
points at one note.
|
|
70
|
-
|
|
71
|
-
### Nothing matched
|
|
72
|
-
|
|
73
|
-
Say so. Only titles, aliases and summaries are searched, so suggest broader
|
|
74
|
-
words — but do not go read their folder yourself to compensate. A brain that
|
|
75
|
-
answers "nothing" is giving you real information.
|
|
76
|
-
|
|
77
|
-
### Cards that are not answers
|
|
78
|
-
|
|
79
|
-
A card marked `not filled in yet` is one of the five `01_BASE/` files, still
|
|
80
|
-
byte-for-byte what `init` wrote. Nobody has answered it, so it is evidence of
|
|
81
|
-
nothing — do not quote it back as if it were what they think.
|
|
82
|
-
|
|
83
|
-
When every card carries that mark, recall says so above them:
|
|
84
|
-
|
|
85
|
-
```
|
|
86
|
-
⚠ Nothing you have written matched this.
|
|
87
|
-
Every card below is still the template `init` wrote
|
|
88
|
-
```
|
|
89
|
-
|
|
90
|
-
That is the moment to offer to fill them in rather than to answer from them —
|
|
91
|
-
`memgineering onboard` prints the questions. The cards are still listed, because
|
|
92
|
-
the label is a claim about the file, not a decision about what you may see;
|
|
93
|
-
`--json` carries the same fact as `scaffolding: true`.
|
|
94
|
-
|
|
95
|
-
The mark disappears the moment the user writes in the file. A base note they
|
|
96
|
-
have filled in is an ordinary note of theirs and often the best answer in the
|
|
97
|
-
brain — `who am I`, `what am I not allowed to do`, `where does everything live`
|
|
98
|
-
are all answered from `01_BASE/`.
|
|
99
|
-
|
|
100
|
-
## Filling in the base files, which only you can do
|
|
101
|
-
|
|
102
|
-
`init` creates five files in `01_BASE/` and leaves them empty, because what
|
|
103
|
-
goes in them cannot be typed into a form. Who the user is, how they want
|
|
104
|
-
answers, what you must ask before doing, what would be expensive to get wrong,
|
|
105
|
-
what they actually run — those come out of a conversation.
|
|
106
|
-
|
|
107
|
-
They matter more than any single memory: `resurface` puts these at the top of a
|
|
108
|
-
new session, and an empty one teaches the next agent nothing. A brain whose
|
|
109
|
-
base is untouched is a brain that starts every session from zero.
|
|
110
|
-
|
|
111
|
-
**Offer once, at the natural moment** — right after `init`, or the first time
|
|
112
|
-
`resurface` marks one `not filled in yet`.
|
|
113
|
-
|
|
114
|
-
```
|
|
115
|
-
memgineering onboard
|
|
116
|
-
```
|
|
117
|
-
|
|
118
|
-
Says which of the five are still untouched and what to ask for each. Run it
|
|
119
|
-
first rather than working from the list below; it knows what has already been
|
|
120
|
-
done, and asking somebody a question they have answered is its own kind of
|
|
121
|
-
forgetting. Then follow their answers rather than the script.
|
|
122
|
-
|
|
123
|
-
They may also ask for it outright — "set up my memory", "fill in my profile",
|
|
124
|
-
"내 정보 채워줘". Same job, and it is the only entry point that works when you
|
|
125
|
-
did not offer.
|
|
126
|
-
|
|
127
|
-
```
|
|
128
|
-
01_BASE/USER.md who they are, what they work on, what they are trying to do
|
|
129
|
-
01_BASE/PREFERENCES.md how they like answers, code, decisions — length, tone, how much checking in
|
|
130
|
-
01_BASE/BOUNDARIES.md what you must ask before doing. The one they will regret not saying
|
|
131
|
-
01_BASE/CRITICAL_FACTS.md what is expensive to get wrong — deploy, money, data, people
|
|
132
|
-
01_BASE/TOOLING.md editors, languages, machines, the commands they actually run
|
|
133
|
-
```
|
|
134
|
-
|
|
135
|
-
**How to ask.** One question at a time, in their words, and stop when the
|
|
136
|
-
answers thin out — three good lines beat a filled-in template. Take what they
|
|
137
|
-
say in passing during ordinary work too; most of `TOOLING.md` gets written by
|
|
138
|
-
noticing, not by asking.
|
|
139
|
-
|
|
140
|
-
**How to write it — both halves.** `revise` only touches frontmatter, so it
|
|
141
|
-
takes two steps, and skipping the first is the common failure: write the body
|
|
142
|
-
with your normal file tools FIRST, replacing `init`'s instructions with what
|
|
143
|
-
they actually said, then record the conclusion.
|
|
144
|
-
|
|
145
|
-
```
|
|
146
|
-
# 1. replace the body — their words, not the template's prompt
|
|
147
|
-
# 2. then:
|
|
148
|
-
memgineering revise 01_BASE/USER.md \
|
|
149
|
-
--action reinforce \
|
|
150
|
-
--claim "<one line: who they are>" \
|
|
151
|
-
--summary "<the line recall should show>"
|
|
152
|
-
```
|
|
153
|
-
|
|
154
|
-
A claim written above the untouched template leaves the file reading as a form
|
|
155
|
-
somebody half-filled — the conclusion in the frontmatter, the instructions for
|
|
156
|
-
writing one still underneath. `revise` warns when you do this; the warning means
|
|
157
|
-
go back and write the body.
|
|
158
|
-
|
|
159
|
-
`--action reinforce`, not the default, and the reason is the date. `supersede`
|
|
160
|
-
stamps `valid_from` with now because a replaced conclusion starts now — but
|
|
161
|
-
these facts were always true and you have only just been told them. Dating them
|
|
162
|
-
today is wrong in the one field a memory store exists to get right.
|
|
163
|
-
|
|
164
|
-
This is the ONE place you edit a brain file directly, and the boundary is
|
|
165
|
-
narrow: `01_BASE/` only, and only while the file is still the template `init`
|
|
166
|
-
wrote. Nothing is lost — there is no history to break and nothing to undo — and
|
|
167
|
-
after that first pass these files are theirs like any other note, changed
|
|
168
|
-
through `revise` and never behind their back.
|
|
169
|
-
|
|
170
|
-
**What not to do.** Do not invent an answer to move on, and do not fill a file
|
|
171
|
-
because it is empty. `BOUNDARIES.md` guessed at is worse than blank: the next
|
|
172
|
-
agent will read it as something the user said.
|
|
173
|
-
|
|
174
|
-
## Deciding which one to trust
|
|
175
|
-
|
|
176
|
-
When two memories disagree, or one looks old enough to doubt, do not settle it
|
|
177
|
-
by date.
|
|
178
|
-
|
|
179
|
-
```
|
|
180
|
-
memgineering evidence deploy-manual
|
|
181
|
-
```
|
|
182
|
-
|
|
183
|
-
```
|
|
184
|
-
surfaced 34× (12× in this folder, 22× elsewhere)
|
|
185
|
-
opened 12× (35% of the recalls that surfaced it)
|
|
186
|
-
last used 3 days ago
|
|
187
|
-
in the ledger since 2026-05-02 · changed 2×
|
|
188
|
-
|
|
189
|
-
**well-used** — it has been reached for and read. The record backs it.
|
|
190
|
-
|
|
191
|
-
why it last changed:
|
|
192
|
-
> CD was removed from the repo
|
|
193
|
-
```
|
|
194
|
-
|
|
195
|
-
**Newer does not win.** A rule that has stood for eleven months has eleven
|
|
196
|
-
months of nobody contradicting it behind it; a note written last week has a
|
|
197
|
-
week. What separates them is whether either was ever actually used, and what
|
|
198
|
-
the last person to change their mind said. Both are in the output above.
|
|
199
|
-
|
|
200
|
-
Three standings, and each is a fact rather than a grade:
|
|
201
|
-
|
|
202
|
-
- **well-used** — recall returned it and somebody read it
|
|
203
|
-
- **surfaced, never opened** — it keeps coming back and nobody reads it. Either
|
|
204
|
-
it does not answer those questions, or its summary does not say what it knows
|
|
205
|
-
- **never recalled** — nothing has ever surfaced it. It may be perfectly true
|
|
206
|
-
and simply never needed, but nothing supports it either
|
|
207
|
-
|
|
208
|
-
If it says this machine has no recall history, the numbers mean nothing yet —
|
|
209
|
-
that log is local, so a brain synced to a new laptop starts empty. Say that
|
|
210
|
-
rather than reporting the memory as unused.
|
|
211
|
-
|
|
212
|
-
## Writing things down
|
|
213
|
-
|
|
214
|
-
```
|
|
215
|
-
memgineering remember "deploys are manual — launchctl by hand, no CD" \
|
|
216
|
-
--reason "watched the deploy happen by hand twice"
|
|
217
|
-
```
|
|
218
|
-
|
|
219
|
-
Lands immediately as its own note and is recallable at once. There is no
|
|
220
|
-
approval queue: the design trades permission-before for correction-after, and
|
|
221
|
-
every write records how to reverse it.
|
|
222
|
-
|
|
223
|
-
**Pass `--reason` on every write.** It goes in the ledger, and it is the only
|
|
224
|
-
part of the record that survives being read six months later by somebody — the
|
|
225
|
-
user, or you in a new session — who no longer remembers the conversation. Every
|
|
226
|
-
write verb takes it: `remember`, `revise`, `retire`, `exclude`, `undo`. The one
|
|
227
|
-
on `undo` is usually the most valuable of all, because it is the moment an
|
|
228
|
-
earlier conclusion turned out to be wrong.
|
|
229
|
-
|
|
230
|
-
It is refused if it looks like it contains a credential. The ledger travels
|
|
231
|
-
with the brain, so that would be a permanent synced copy — say what changed
|
|
232
|
-
without the value, or drop the flag; the write itself is unaffected.
|
|
233
|
-
|
|
234
|
-
```
|
|
235
|
-
memgineering undo --reason "that belonged to the other project" # the last change
|
|
236
|
-
memgineering undo <op_id> # a specific one
|
|
237
|
-
memgineering log # what changed, why, and what can still be undone
|
|
238
|
-
```
|
|
239
|
-
|
|
240
|
-
Write down: decisions and their reasons, constraints, corrections the user
|
|
241
|
-
made to you, how something actually works once you found out. Skip: things
|
|
242
|
-
true only inside this conversation, and anything they said they did not want
|
|
243
|
-
kept.
|
|
244
|
-
|
|
245
|
-
**Recall first, then decide which verb.** If what you just learned answers a
|
|
246
|
-
note that is already there — the vague one, the one that says "nobody wrote
|
|
247
|
-
this down" — `revise` it instead. `remember` would leave two current notes on
|
|
248
|
-
the same subject and the next recall would return both, which is the
|
|
249
|
-
re-discovery problem the user was trying to end. New subject → `remember`.
|
|
250
|
-
Existing subject, now settled → `revise`.
|
|
251
|
-
|
|
252
|
-
### Changing a conclusion
|
|
253
|
-
|
|
254
|
-
```
|
|
255
|
-
memgineering revise deploy-manual \
|
|
256
|
-
--claim "Deploying is manual — pushing to main does nothing." \
|
|
257
|
-
--summary "manual only, no CD"
|
|
258
|
-
```
|
|
259
|
-
|
|
260
|
-
- `--action supersede` (default) — the conclusion CHANGED. Stamps `valid_from`
|
|
261
|
-
with now, because a replaced conclusion starts now.
|
|
262
|
-
- `--action reinforce` — the SAME conclusion, new support. Leaves `valid_from`
|
|
263
|
-
alone. Use it when nothing about the fact changed, only your evidence.
|
|
264
|
-
- `--action conflict` — two notes DISAGREE. Records the edge, leaves both
|
|
265
|
-
standing, and deliberately does not write the claim you passed.
|
|
266
|
-
- `--dry-run` shows the diff and writes nothing
|
|
267
|
-
|
|
268
|
-
Pick by what changed, not by habit: `supersede` on a fact that was true all
|
|
269
|
-
along dates it from today, and the date is the field this is all for.
|
|
270
|
-
|
|
271
|
-
**Re-recording something unchanged is refused.** If the claim, summary and title
|
|
272
|
-
all match what the note already holds, `revise` writes nothing and says so —
|
|
273
|
-
otherwise a user repeating themselves turns into ledger entries that record no
|
|
274
|
-
change. When you do mean "this still holds", say what confirms it:
|
|
275
|
-
`--action reinforce --reason "<what confirms it>"`. Check with `open <ref>`
|
|
276
|
-
before rewriting something you may already have.
|
|
277
|
-
|
|
278
|
-
This only ever rewrites the memory block in a note's frontmatter. The prose is
|
|
279
|
-
the user's; neither this command nor you should rewrite it uninvited.
|
|
280
|
-
|
|
281
|
-
### Retiring versus excluding
|
|
282
|
-
|
|
283
|
-
```
|
|
284
|
-
memgineering retire <ref> --reason "the date moved" # no longer current, still visible
|
|
285
|
-
memgineering exclude path/to/note.md --reason "names an internal host" # stop reading it
|
|
286
|
-
```
|
|
287
|
-
|
|
288
|
-
Retiring keeps the note in recall, ranked last and labelled. Excluding takes it
|
|
289
|
-
out of the index and never touches the file. If the user says "delete", ask
|
|
290
|
-
which they mean — they are different, and guessing picks one.
|
|
291
|
-
|
|
292
|
-
## Starting a session
|
|
293
|
-
|
|
294
|
-
```
|
|
295
|
-
memgineering resurface
|
|
296
|
-
```
|
|
297
|
-
|
|
298
|
-
No query. It ranks by what has been recalled in this folder before, how
|
|
299
|
-
recently, and which of the user's base notes have gone unread — the things you
|
|
300
|
-
should already know here before they have to tell you again.
|
|
301
|
-
|
|
302
|
-
## What to raise with the user
|
|
303
|
-
|
|
304
|
-
The tool does not ask; you decide. Say something, once and plainly, when:
|
|
305
|
-
|
|
306
|
-
- the output marks the target `⚠ critical target` — that is `01_BASE/`, the
|
|
307
|
-
files defining who they are and what you may do
|
|
308
|
-
- you are about to record something said in passing that may be sensitive
|
|
309
|
-
- what you learned contradicts a memory currently marked current
|
|
310
|
-
|
|
311
|
-
Everything else: do it, and mention it in a sentence.
|
|
57
|
+
The tool does not gate writes; your judgement does. Tell them, plainly and
|
|
58
|
+
once, when the change touches `01_BASE/` (the output marks these
|
|
59
|
+
`⚠ critical target`), when you are recording something said in passing they may
|
|
60
|
+
not want kept, or when what you learned contradicts a memory marked current.
|
|
61
|
+
Everything else: write it and mention it in a sentence.
|
|
312
62
|
|
|
313
63
|
## Rules
|
|
314
64
|
|
|
315
65
|
- **Never edit brain files with Read/Write/Edit.** Only the CLI records the
|
|
316
|
-
change and keeps `undo` working; a hand edit is invisible to both.
|
|
66
|
+
change and keeps `undo` working; a hand edit is invisible to both. The one
|
|
67
|
+
narrow exception — first-pass `01_BASE/` bodies — is in `memgineering-writing`.
|
|
317
68
|
- **Never invent a handle or id.** They come from `recall`, `resurface`, `open`.
|
|
69
|
+
- **Nothing matched is a real answer.** Say the brain has nothing on it rather
|
|
70
|
+
than filling the gap with a guess.
|
|
318
71
|
- **Store full ids, not short handles**, anywhere durable — your own memory, a
|
|
319
72
|
document, a ticket. `open` prints the full `id:` for exactly this.
|
|
320
73
|
- **`--json`** when you need to parse rather than read.
|
|
321
|
-
- **Several brains** (
|
|
74
|
+
- **Several brains** (one of their own, a shared one, one per project) resolve by where you are.
|
|
322
75
|
If a command says the choice is ambiguous, pass `--vault <path>` — or bind
|
|
323
76
|
the directory once with `memgineering use <brain>`.
|
|
324
77
|
|
|
325
|
-
|
|
326
|
-
|
|
327
|
-
```
|
|
328
|
-
memgineering link ~/Documents/Notes # notes they already keep
|
|
329
|
-
memgineering init ~/brain # nothing yet — creates the layout
|
|
330
|
-
```
|
|
331
|
-
|
|
332
|
-
`link` shows exactly what would be stored and asks first; run it in a terminal
|
|
333
|
-
the user can see, and let them answer. Do not pass `--yes` on their behalf.
|
|
334
|
-
|
|
335
|
-
With no terminal attached it says so instead of assuming the answer was no.
|
|
336
|
-
Show them `memgineering link <path> --dry-run` — same disclosure, writes
|
|
337
|
-
nothing — and run with `--yes` only once they have actually said yes.
|
|
338
|
-
|
|
339
|
-
## Moving a brain between this machine and their account
|
|
340
|
-
|
|
341
|
-
```
|
|
342
|
-
memgineering push # this folder → their account
|
|
343
|
-
memgineering pull ~/my-brain # their account → a folder here
|
|
344
|
-
```
|
|
345
|
-
|
|
346
|
-
Both are safe to run twice, and each is careful in the opposite direction:
|
|
347
|
-
**`push` never deletes anything locally, `pull` never overwrites anything
|
|
348
|
-
locally.** Whatever was already there is left alone and counted in the summary,
|
|
349
|
-
so an interrupted transfer finishes by running the same command again.
|
|
350
|
-
|
|
351
|
-
Reach for `pull` when the user asks to get their notes out, wants a backup,
|
|
352
|
-
is moving machines, or asks where their memory actually lives. **Say what it
|
|
353
|
-
brings**: notes the brain excludes from recall come down too — excluded means
|
|
354
|
-
"stop reading this", not "this is no longer yours" — along with `.memgignore`,
|
|
355
|
-
so nothing is silently un-excluded on the way. If any of those arrive, tell
|
|
356
|
-
them; readable files in a folder is not something to discover later.
|
|
357
|
-
|
|
358
|
-
What lands is markdown and nothing more. It is not a brain on this machine
|
|
359
|
-
until `memgineering link <folder>` — offer that as a next step rather than
|
|
360
|
-
doing it, since it is a second decision they did not ask for.
|
|
361
|
-
|
|
362
|
-
`--dry-run` on either verb lists what would move and moves nothing. Use it when
|
|
363
|
-
the user is unsure which folder they mean.
|
|
78
|
+
If a command answers `no brain is linked yet`, that is `memgineering-setup`.
|