memgineering 0.0.0 → 0.2.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 +147 -0
- package/LICENSE +202 -0
- package/NOTICE +41 -0
- package/README.md +156 -5
- package/assets/MEMGINEERING.md +135 -0
- package/assets/memgineering-memory/SKILL.md +227 -0
- package/assets/memgineering-setup/SKILL.md +141 -0
- package/bin/memgineering.js +1 -6
- package/dist/index.js +6150 -0
- package/package.json +58 -16
- package/scripts/copy-skills.mjs +40 -0
- package/scripts/postinstall.mjs +16 -0
|
@@ -0,0 +1,135 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: memgineering
|
|
3
|
+
description: Use whenever the user refers to something they told you before, asks what was decided, or tells you something worth keeping. 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
|
+
type: skill
|
|
5
|
+
version: 0.2.0
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# memgineering
|
|
9
|
+
|
|
10
|
+
The user has a **brain** — a folder of their own notes that every AI tool they
|
|
11
|
+
use can read and write through the `memgineering` CLI. It outlives this
|
|
12
|
+
session and this tool. Treat it as the place where what they know actually
|
|
13
|
+
lives, and this conversation as temporary.
|
|
14
|
+
|
|
15
|
+
## When to reach for it
|
|
16
|
+
|
|
17
|
+
**Start a session by asking what you are missing.** Before working in an
|
|
18
|
+
unfamiliar folder, or when someone opens with "where were we", "what should I
|
|
19
|
+
know", "I've been away":
|
|
20
|
+
|
|
21
|
+
```
|
|
22
|
+
memgineering resurface
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
No query — it ranks by what has been recalled here before, how recently, and
|
|
26
|
+
which of their core notes have gone unread. It is the answer to a vague
|
|
27
|
+
question that recall cannot serve, because there is nothing to search for yet.
|
|
28
|
+
|
|
29
|
+
**Recall before answering** anything that sounds like it was settled before:
|
|
30
|
+
|
|
31
|
+
- "what did we decide about…", "how do I deploy this again", "왜 이렇게 했더라"
|
|
32
|
+
- any question about _their_ project, setup, preferences, or past reasoning
|
|
33
|
+
- before repeating advice you have no evidence they wanted
|
|
34
|
+
|
|
35
|
+
```
|
|
36
|
+
memgineering recall "<the question, in their words>"
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
You get cards: title, one-line summary, and an `open:` handle. Open the one
|
|
40
|
+
that matters rather than all of them.
|
|
41
|
+
|
|
42
|
+
```
|
|
43
|
+
memgineering open <handle> # claims behind the card
|
|
44
|
+
memgineering open <handle> --detail full # the whole note
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
`open` also takes a note's exact title or its path, so you do not need to
|
|
48
|
+
recall first when you already know what you want.
|
|
49
|
+
|
|
50
|
+
**Check the evidence before trusting an old memory,** or when two of them
|
|
51
|
+
disagree:
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
memgineering evidence <handle>
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
How often it has been surfaced, how often anyone read it, when it last changed
|
|
58
|
+
and why. **Newer does not win**: a rule that has stood for eleven months has
|
|
59
|
+
eleven months of nobody contradicting it behind it. Use whether it was actually
|
|
60
|
+
reached for, not its date.
|
|
61
|
+
|
|
62
|
+
**Remember when you learn something durable** — a decision, a constraint, a
|
|
63
|
+
correction the user made, how something actually works:
|
|
64
|
+
|
|
65
|
+
```
|
|
66
|
+
memgineering remember "deploys are manual — launchctl by hand, no CD" --reason "watched it twice"
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
No approval step, by design. It is recorded and reversible (`memgineering
|
|
70
|
+
undo`), so the cost of a wrong entry is one command, not a permanent mistake.
|
|
71
|
+
Do not ask permission for ordinary observations — write them.
|
|
72
|
+
|
|
73
|
+
**Always pass `--reason`.** Every write verb takes it and it goes in the ledger.
|
|
74
|
+
It is the only part of a record that still means anything to whoever reads it
|
|
75
|
+
six months from now, and it is refused if it looks like it carries a credential.
|
|
76
|
+
|
|
77
|
+
**Revise when a conclusion changes:**
|
|
78
|
+
|
|
79
|
+
```
|
|
80
|
+
memgineering revise <handle> --claim "Deploying is manual now." --summary "manual only"
|
|
81
|
+
```
|
|
82
|
+
|
|
83
|
+
## What to raise with the user rather than just doing
|
|
84
|
+
|
|
85
|
+
The tool does not gate writes; your judgement does. Tell them — plainly, once
|
|
86
|
+
— when:
|
|
87
|
+
|
|
88
|
+
- the change touches `01_BASE/` (their identity, preferences, boundaries,
|
|
89
|
+
tooling). The output marks these `⚠ critical target`.
|
|
90
|
+
- you are recording something they said in passing that they may not want kept
|
|
91
|
+
- what you learned contradicts a memory that is currently marked current
|
|
92
|
+
|
|
93
|
+
Everything else: write it and mention it in a sentence.
|
|
94
|
+
|
|
95
|
+
## Depth costs context — ask for what you need
|
|
96
|
+
|
|
97
|
+
`recall` returns cards, not notes, so calling it often is cheap. Reach for more
|
|
98
|
+
only when a summary is not enough:
|
|
99
|
+
|
|
100
|
+
| depth | what you get |
|
|
101
|
+
| ------------------ | ----------------------------------------------- |
|
|
102
|
+
| `--detail card` | title + summary (default) |
|
|
103
|
+
| `--detail summary` | + the note's headings |
|
|
104
|
+
| `--detail chunks` | + every section, or one with `--section <name>` |
|
|
105
|
+
| `--detail full` | the whole note |
|
|
106
|
+
|
|
107
|
+
`recall "<q>" --limit 1 --detail full` is "find the best match and read it" in
|
|
108
|
+
one call.
|
|
109
|
+
|
|
110
|
+
## At the start of a session
|
|
111
|
+
|
|
112
|
+
```
|
|
113
|
+
memgineering resurface
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
Ranks by what has been recalled in this folder before, how recently, and which
|
|
117
|
+
of their base notes have gone unread. No query needed — this is the one that
|
|
118
|
+
tells you what you should already know here.
|
|
119
|
+
|
|
120
|
+
## Rules
|
|
121
|
+
|
|
122
|
+
- **Never edit brain files directly.** Use the CLI: it records what changed and
|
|
123
|
+
keeps `undo` working. A hand edit is invisible to that.
|
|
124
|
+
- **Never invent a handle.** They come from `recall`, `resurface` or `open`.
|
|
125
|
+
- **Full ids in durable places.** The short handle is for this conversation;
|
|
126
|
+
when you save a reference in your own memory or a document, use the full `id:`
|
|
127
|
+
that `open` prints.
|
|
128
|
+
- **Nothing matched is a real answer.** Say the brain has nothing on it rather
|
|
129
|
+
than filling the gap with a guess.
|
|
130
|
+
- **Their notes are theirs.** `revise` only touches the memory block in
|
|
131
|
+
frontmatter; prose is never rewritten by this tool, and should not be
|
|
132
|
+
rewritten by you without being asked.
|
|
133
|
+
|
|
134
|
+
If `memgineering: command not found`, install with `npm i -g memgineering`,
|
|
135
|
+
then `memgineering setup`.
|
|
@@ -0,0 +1,227 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: memgineering-memory
|
|
3
|
+
description: Use when the user asks about something they told you before, refers to a past decision, wants their own notes searched, or says something worth keeping. Triggers include "what did I decide about X", "check my notes", "how do we deploy again", "remember this", "is this still true", "which one do I go with", "예전에 뭐라고 정했더라", "내 노트에서 찾아줘", "이거 기억해둬", "what do you know about my setup". Covers recall, open, evidence, remember, revise, undo, and resurface against the user's own brain folder.
|
|
4
|
+
type: skill
|
|
5
|
+
allowed-tools: Bash(memgineering:*)
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Working with the user's brain
|
|
9
|
+
|
|
10
|
+
A **brain** is a folder of the user's own notes. It is not this tool's
|
|
11
|
+
database: they wrote those files, they can open them in any editor, and
|
|
12
|
+
memgineering reads them and keeps a derived index outside the folder. Deleting
|
|
13
|
+
that index costs a rebuild and nothing else.
|
|
14
|
+
|
|
15
|
+
Everything below assumes the brain is already linked. If a command answers
|
|
16
|
+
`no brain is linked yet`, see "Getting connected" at the bottom.
|
|
17
|
+
|
|
18
|
+
## Answering from what they already know
|
|
19
|
+
|
|
20
|
+
Recall first whenever the question sounds settled — a past decision, their
|
|
21
|
+
setup, their preferences, why something is the way it is.
|
|
22
|
+
|
|
23
|
+
```
|
|
24
|
+
memgineering recall "how do we deploy"
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
## recall: how do we deploy (2 cards)
|
|
29
|
+
|
|
30
|
+
### 1. Deploy is manual
|
|
31
|
+
stated
|
|
32
|
+
|
|
33
|
+
> launchctl kickstart on the Mac Studio, no CD pipeline
|
|
34
|
+
|
|
35
|
+
`open: deploy-manual`
|
|
36
|
+
```
|
|
37
|
+
|
|
38
|
+
The output is already shaped for your context — headings, a quoted summary,
|
|
39
|
+
and a handle. Paste it in as-is rather than reformatting it into prose.
|
|
40
|
+
|
|
41
|
+
**But read it before you use it.** These are candidates ranked by relevance,
|
|
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.
|
|
48
|
+
|
|
49
|
+
Then open only what matters:
|
|
50
|
+
|
|
51
|
+
```
|
|
52
|
+
memgineering open deploy-manual # the claims behind the card
|
|
53
|
+
memgineering open deploy-manual --detail summary # + its headings
|
|
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
|
+
## Deciding which one to trust
|
|
78
|
+
|
|
79
|
+
When two memories disagree, or one looks old enough to doubt, do not settle it
|
|
80
|
+
by date.
|
|
81
|
+
|
|
82
|
+
```
|
|
83
|
+
memgineering evidence deploy-manual
|
|
84
|
+
```
|
|
85
|
+
|
|
86
|
+
```
|
|
87
|
+
surfaced 34× (12× in this folder, 22× elsewhere)
|
|
88
|
+
opened 12× (35% of the recalls that surfaced it)
|
|
89
|
+
last used 3 days ago
|
|
90
|
+
in the ledger since 2026-05-02 · changed 2×
|
|
91
|
+
|
|
92
|
+
**well-used** — it has been reached for and read. The record backs it.
|
|
93
|
+
|
|
94
|
+
why it last changed:
|
|
95
|
+
> CD was removed from the repo
|
|
96
|
+
```
|
|
97
|
+
|
|
98
|
+
**Newer does not win.** A rule that has stood for eleven months has eleven
|
|
99
|
+
months of nobody contradicting it behind it; a note written last week has a
|
|
100
|
+
week. What separates them is whether either was ever actually used, and what
|
|
101
|
+
the last person to change their mind said. Both are in the output above.
|
|
102
|
+
|
|
103
|
+
Three standings, and each is a fact rather than a grade:
|
|
104
|
+
|
|
105
|
+
- **well-used** — recall returned it and somebody read it
|
|
106
|
+
- **surfaced, never opened** — it keeps coming back and nobody reads it. Either
|
|
107
|
+
it does not answer those questions, or its summary does not say what it knows
|
|
108
|
+
- **never recalled** — nothing has ever surfaced it. It may be perfectly true
|
|
109
|
+
and simply never needed, but nothing supports it either
|
|
110
|
+
|
|
111
|
+
If it says this machine has no recall history, the numbers mean nothing yet —
|
|
112
|
+
that log is local, so a brain synced to a new laptop starts empty. Say that
|
|
113
|
+
rather than reporting the memory as unused.
|
|
114
|
+
|
|
115
|
+
## Writing things down
|
|
116
|
+
|
|
117
|
+
```
|
|
118
|
+
memgineering remember "deploys are manual — launchctl by hand, no CD" \
|
|
119
|
+
--reason "watched the deploy happen by hand twice"
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
Lands immediately as its own note and is recallable at once. There is no
|
|
123
|
+
approval queue: the design trades permission-before for correction-after, and
|
|
124
|
+
every write records how to reverse it.
|
|
125
|
+
|
|
126
|
+
**Pass `--reason` on every write.** It goes in the ledger, and it is the only
|
|
127
|
+
part of the record that survives being read six months later by somebody — the
|
|
128
|
+
user, or you in a new session — who no longer remembers the conversation. Every
|
|
129
|
+
write verb takes it: `remember`, `revise`, `retire`, `exclude`, `undo`. The one
|
|
130
|
+
on `undo` is usually the most valuable of all, because it is the moment an
|
|
131
|
+
earlier conclusion turned out to be wrong.
|
|
132
|
+
|
|
133
|
+
It is refused if it looks like it contains a credential. The ledger travels
|
|
134
|
+
with the brain, so that would be a permanent synced copy — say what changed
|
|
135
|
+
without the value, or drop the flag; the write itself is unaffected.
|
|
136
|
+
|
|
137
|
+
```
|
|
138
|
+
memgineering undo --reason "that belonged to the other project" # the last change
|
|
139
|
+
memgineering undo <op_id> # a specific one
|
|
140
|
+
memgineering log # what changed, why, and what can still be undone
|
|
141
|
+
```
|
|
142
|
+
|
|
143
|
+
Write down: decisions and their reasons, constraints, corrections the user
|
|
144
|
+
made to you, how something actually works once you found out. Skip: things
|
|
145
|
+
true only inside this conversation, and anything they said they did not want
|
|
146
|
+
kept.
|
|
147
|
+
|
|
148
|
+
**Recall first, then decide which verb.** If what you just learned answers a
|
|
149
|
+
note that is already there — the vague one, the one that says "nobody wrote
|
|
150
|
+
this down" — `revise` it instead. `remember` would leave two current notes on
|
|
151
|
+
the same subject and the next recall would return both, which is the
|
|
152
|
+
re-discovery problem the user was trying to end. New subject → `remember`.
|
|
153
|
+
Existing subject, now settled → `revise`.
|
|
154
|
+
|
|
155
|
+
### Changing a conclusion
|
|
156
|
+
|
|
157
|
+
```
|
|
158
|
+
memgineering revise deploy-manual \
|
|
159
|
+
--claim "Deploying is manual — pushing to main does nothing." \
|
|
160
|
+
--summary "manual only, no CD"
|
|
161
|
+
```
|
|
162
|
+
|
|
163
|
+
- `--action supersede` (default) replaces the conclusion
|
|
164
|
+
- `--action reinforce` keeps it and adds support
|
|
165
|
+
- `--action conflict` records that two notes disagree without picking a winner
|
|
166
|
+
- `--dry-run` shows the diff and writes nothing
|
|
167
|
+
|
|
168
|
+
This only ever rewrites the memory block in a note's frontmatter. The prose is
|
|
169
|
+
the user's; neither this command nor you should rewrite it uninvited.
|
|
170
|
+
|
|
171
|
+
### Retiring versus excluding
|
|
172
|
+
|
|
173
|
+
```
|
|
174
|
+
memgineering retire <ref> --reason "the date moved" # no longer current, still visible
|
|
175
|
+
memgineering exclude path/to/note.md --reason "names an internal host" # stop reading it
|
|
176
|
+
```
|
|
177
|
+
|
|
178
|
+
Retiring keeps the note in recall, ranked last and labelled. Excluding takes it
|
|
179
|
+
out of the index and never touches the file. If the user says "delete", ask
|
|
180
|
+
which they mean — they are different, and guessing picks one.
|
|
181
|
+
|
|
182
|
+
## Starting a session
|
|
183
|
+
|
|
184
|
+
```
|
|
185
|
+
memgineering resurface
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
No query. It ranks by what has been recalled in this folder before, how
|
|
189
|
+
recently, and which of the user's base notes have gone unread — the things you
|
|
190
|
+
should already know here before they have to tell you again.
|
|
191
|
+
|
|
192
|
+
## What to raise with the user
|
|
193
|
+
|
|
194
|
+
The tool does not ask; you decide. Say something, once and plainly, when:
|
|
195
|
+
|
|
196
|
+
- the output marks the target `⚠ critical target` — that is `01_BASE/`, the
|
|
197
|
+
files defining who they are and what you may do
|
|
198
|
+
- you are about to record something said in passing that may be sensitive
|
|
199
|
+
- what you learned contradicts a memory currently marked current
|
|
200
|
+
|
|
201
|
+
Everything else: do it, and mention it in a sentence.
|
|
202
|
+
|
|
203
|
+
## Rules
|
|
204
|
+
|
|
205
|
+
- **Never edit brain files with Read/Write/Edit.** Only the CLI records the
|
|
206
|
+
change and keeps `undo` working; a hand edit is invisible to both.
|
|
207
|
+
- **Never invent a handle or id.** They come from `recall`, `resurface`, `open`.
|
|
208
|
+
- **Store full ids, not short handles**, anywhere durable — your own memory, a
|
|
209
|
+
document, a ticket. `open` prints the full `id:` for exactly this.
|
|
210
|
+
- **`--json`** when you need to parse rather than read.
|
|
211
|
+
- **Several brains** (personal, team, a repo's own) resolve by where you are.
|
|
212
|
+
If a command says the choice is ambiguous, pass `--vault <path>` — or bind
|
|
213
|
+
the directory once with `memgineering use <brain>`.
|
|
214
|
+
|
|
215
|
+
## Getting connected
|
|
216
|
+
|
|
217
|
+
```
|
|
218
|
+
memgineering link ~/Documents/Notes # notes they already keep
|
|
219
|
+
memgineering init ~/brain # nothing yet — creates the layout
|
|
220
|
+
```
|
|
221
|
+
|
|
222
|
+
`link` shows exactly what would be stored and asks first; run it in a terminal
|
|
223
|
+
the user can see, and let them answer. Do not pass `--yes` on their behalf.
|
|
224
|
+
|
|
225
|
+
With no terminal attached it says so instead of assuming the answer was no.
|
|
226
|
+
Show them `memgineering link <path> --dry-run` — same disclosure, writes
|
|
227
|
+
nothing — and run with `--yes` only once they have actually said yes.
|
|
@@ -0,0 +1,141 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: memgineering-setup
|
|
3
|
+
description: Use when installing or configuring memgineering — after `npm i -g memgineering`, when the user asks to set it up, connect their notes, install it into their agents, turn auto-update on or off, or when a memgineering command reports that no brain is linked. Triggers include "set up memgineering", "connect my notes", "메모리 설정해줘", "노트 연결", "memgineering setup", "no brain is linked".
|
|
4
|
+
type: skill
|
|
5
|
+
allowed-tools: Bash(memgineering:*)
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Setting memgineering up
|
|
9
|
+
|
|
10
|
+
Two things have to happen, and they are separate on purpose:
|
|
11
|
+
|
|
12
|
+
1. **Register with the agents** — so this and every other AI tool on the
|
|
13
|
+
machine knows the brain exists. One command.
|
|
14
|
+
2. **Connect a brain** — which folder holds the notes. This one is the user's
|
|
15
|
+
decision, and it involves showing them what gets stored.
|
|
16
|
+
|
|
17
|
+
## 1. Register
|
|
18
|
+
|
|
19
|
+
```
|
|
20
|
+
memgineering setup --agent
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
`--agent` is the non-interactive path, meant for you: it detects the installed
|
|
24
|
+
tools, injects the guidance block, installs these skills, and takes its
|
|
25
|
+
remaining answers from flags rather than prompts.
|
|
26
|
+
|
|
27
|
+
```
|
|
28
|
+
memgineering setup --agent \
|
|
29
|
+
--tools claude,codex \ # default: everything detected
|
|
30
|
+
--auto-update on \ # default: on, and recommended
|
|
31
|
+
--hook on # SessionStart resurface, Claude Code only
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
Look at `memgineering setup --dry-run` first if you want to report what would
|
|
35
|
+
change before changing it.
|
|
36
|
+
|
|
37
|
+
**Ask the user before choosing for them** when a flag would set policy rather
|
|
38
|
+
than mechanics: auto-update is the one that matters, since it means the tool
|
|
39
|
+
updates itself. Recommend `on` — old versions can lose access to hosted
|
|
40
|
+
features later — but it is theirs to decide.
|
|
41
|
+
|
|
42
|
+
If the user would rather click than type, `memgineering setup --human` gives
|
|
43
|
+
them a checkbox screen. Run it and let them drive; do not answer for them.
|
|
44
|
+
|
|
45
|
+
**After setup, the agent session has to restart** for the guidance to load.
|
|
46
|
+
Say so — the user will otherwise wonder why nothing changed.
|
|
47
|
+
|
|
48
|
+
## 2. Connect a brain
|
|
49
|
+
|
|
50
|
+
Two cases, and picking the wrong one is disruptive.
|
|
51
|
+
|
|
52
|
+
**They already keep notes somewhere** — Obsidian, a folder of markdown,
|
|
53
|
+
anything:
|
|
54
|
+
|
|
55
|
+
```
|
|
56
|
+
memgineering link ~/Documents/Notes
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
This prints exactly what would be indexed and what would be refused, including
|
|
60
|
+
a sample of the real lines that would be stored, then asks. **Run it and stop.**
|
|
61
|
+
Let them read it and answer. Do not pass `--yes` for them: the screen is the
|
|
62
|
+
one moment they decide what this tool may read, and answering on their behalf
|
|
63
|
+
takes that away.
|
|
64
|
+
|
|
65
|
+
If your shell has no terminal attached, `link` will say so rather than
|
|
66
|
+
pretending the answer was no. When that happens, show them the decision
|
|
67
|
+
instead of making it:
|
|
68
|
+
|
|
69
|
+
```
|
|
70
|
+
memgineering link ~/Documents/Notes --dry-run
|
|
71
|
+
```
|
|
72
|
+
|
|
73
|
+
That prints the same disclosure and writes nothing: every note that would be
|
|
74
|
+
indexed with the exact line that would be stored, plus any file the credential
|
|
75
|
+
scanner is holding back. Put it in front of them, wait for a real yes, and
|
|
76
|
+
only then run with `--yes` — which records the decision they actually made.
|
|
77
|
+
|
|
78
|
+
If they cannot see your terminal at all, hand them the command rather than
|
|
79
|
+
answering for them.
|
|
80
|
+
|
|
81
|
+
**What to tell them, in one line before they answer:** the title and first
|
|
82
|
+
paragraph of every note listed gets stored outside the folder, and if the
|
|
83
|
+
session-start hook is on, a few of those summaries appear in every new session
|
|
84
|
+
without anyone asking. Anything they would not want in either place goes in a
|
|
85
|
+
`.memgdeny` file at the top of the folder — one path per line, no wildcards:
|
|
86
|
+
|
|
87
|
+
```
|
|
88
|
+
30_personal/medical.md
|
|
89
|
+
journal/ (a trailing slash covers a whole folder)
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
If it refuses because a `.memgdeny` line matches no file, that is working as
|
|
93
|
+
intended — a rule with a wrong path protects nothing. Fix the paths it
|
|
94
|
+
suggests, or remove the lines.
|
|
95
|
+
|
|
96
|
+
**They have no notes yet**:
|
|
97
|
+
|
|
98
|
+
```
|
|
99
|
+
memgineering init ~/brain
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
Creates the layout — eleven folders and five base files — and links it. Then
|
|
103
|
+
tell them to fill in `01_BASE/USER.md` and leave the rest; the folders are
|
|
104
|
+
there for when they are needed, not as homework.
|
|
105
|
+
|
|
106
|
+
### Several brains
|
|
107
|
+
|
|
108
|
+
Normal: a personal one, a team folder that syncs, one per repository. Which
|
|
109
|
+
one answers is decided by where you are, in this order:
|
|
110
|
+
|
|
111
|
+
1. `--vault <path>`
|
|
112
|
+
2. a `.memgineering` pointer file, found by walking up from the cwd
|
|
113
|
+
3. the brain the current directory is inside
|
|
114
|
+
4. the only one linked
|
|
115
|
+
|
|
116
|
+
If it says the choice is ambiguous, bind the directory once:
|
|
117
|
+
|
|
118
|
+
```
|
|
119
|
+
memgineering use ~/brains/work
|
|
120
|
+
```
|
|
121
|
+
|
|
122
|
+
Inside a repository this writes a relative path, so it can be committed and
|
|
123
|
+
will resolve for a teammate who links the same brain.
|
|
124
|
+
|
|
125
|
+
## Checking it worked
|
|
126
|
+
|
|
127
|
+
```
|
|
128
|
+
memgineering recall "anything" # should answer, even if with "nothing matched"
|
|
129
|
+
memgineering log # what this brain has recorded
|
|
130
|
+
```
|
|
131
|
+
|
|
132
|
+
## Turning things off
|
|
133
|
+
|
|
134
|
+
```
|
|
135
|
+
memgineering setup --agent --auto-update off
|
|
136
|
+
memgineering unlink # stop reading a brain; notes untouched
|
|
137
|
+
memgineering unlink --purge # also delete the local index and undo snapshots
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
`MEMGINEERING_NO_UPDATE=1` skips the update check for a single run without
|
|
141
|
+
changing the setting.
|