memgineering 0.14.0 → 0.15.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 +64 -1
- package/assets/MEMGINEERING.md +1 -1
- package/assets/memgineering-recall/SKILL.md +10 -0
- package/assets/memgineering-setup/SKILL.md +18 -0
- package/assets/memgineering-writing/SKILL.md +19 -0
- package/dist/index.js +620 -221
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -11,12 +11,75 @@ language the reader wants. The bilingual rule the monorepo applies to
|
|
|
11
11
|
|
|
12
12
|
## [Unreleased]
|
|
13
13
|
|
|
14
|
+
## [0.15.0] — 2026-08-29
|
|
15
|
+
|
|
16
|
+
### Added
|
|
17
|
+
|
|
18
|
+
- **A folder knows which project it is.** `memgineering project` names the
|
|
19
|
+
project the current folder counts as — derived from the git remote
|
|
20
|
+
(`owner/repo`), else the checkout's folder name, else nothing; worktrees
|
|
21
|
+
and subfolders of one checkout answer the same. `memgineering project
|
|
22
|
+
<name>` binds your own name to the repository and `--unset` returns to the
|
|
23
|
+
derived one. Renaming does not move history: what was recalled under the
|
|
24
|
+
old name stays recorded there, and the command says so whenever it
|
|
25
|
+
changes anything. Derivation reads `.git/config` directly — no
|
|
26
|
+
subprocess, so the session-start hook's deadline is never spent on it.
|
|
27
|
+
- **A note remembers the project it was born in.** `remember` inside a
|
|
28
|
+
project folder stamps that project as the note's `scope` automatically.
|
|
29
|
+
An explicit `--scope` still wins; the new `--no-scope` writes a
|
|
30
|
+
machine-wide note on purpose — rules especially, since a rule stamped
|
|
31
|
+
with one project's scope drops out of another project's `--scope`
|
|
32
|
+
recalls. A derived name the server would refuse (over 128 chars, or
|
|
33
|
+
nothing once normalized) is skipped silently and the note is written
|
|
34
|
+
unscoped — an ambient signal never fails a command. The `YYYY-MM` noise
|
|
35
|
+
scope that path inference used to give observations is gone for new
|
|
36
|
+
notes.
|
|
37
|
+
- **Reads say where they were asked from — as a name, never a path.**
|
|
38
|
+
recall, open and resurface now send `asked_from`, the folder's project
|
|
39
|
+
name, and a hosted brain records it beside what was returned. The local
|
|
40
|
+
event log records the same name next to the `context_dir` it always
|
|
41
|
+
kept. The working directory itself still never leaves the machine; the
|
|
42
|
+
privacy page names the new field, what it holds, and its 90-day window.
|
|
43
|
+
- **A hosted resurface finally ranks by "asked about here."** When the
|
|
44
|
+
session's folder names a project, the hosted ranking weighs what was
|
|
45
|
+
asked about in that project first — the same weight a folder brain has
|
|
46
|
+
always given "in this folder" — and says so honestly: `ranked_by` gains
|
|
47
|
+
`asked about in this project`, a card's reason reads `recalled 2× in
|
|
48
|
+
this project`, and the footer names which project those words mean. A
|
|
49
|
+
brain with no history yet ranks exactly as before and claims nothing.
|
|
50
|
+
|
|
51
|
+
### Changed
|
|
52
|
+
|
|
53
|
+
- The hosted resurface footer no longer claims a hosted brain cannot know
|
|
54
|
+
where a question was asked from. It now tells one of three truths: which
|
|
55
|
+
project the ranking used; that this folder names no project, so nothing
|
|
56
|
+
was sent; or that the server was sent the signal and does not rank by
|
|
57
|
+
project yet. `resurface --json` carries `asked_from` so a machine reader
|
|
58
|
+
can tell those cases apart too.
|
|
59
|
+
|
|
60
|
+
### Compatibility
|
|
61
|
+
|
|
62
|
+
- An older server ignores `asked_from` entirely (unknown fields are
|
|
63
|
+
dropped); the CLI reads the three-entry `ranked_by` and says the server
|
|
64
|
+
does not rank by project yet, rather than letting the silence read as an
|
|
65
|
+
empty folder signal. An older CLI against the new server sends nothing
|
|
66
|
+
and behaves exactly as before. Event lines written before the field
|
|
67
|
+
existed still parse and still rank.
|
|
68
|
+
|
|
69
|
+
### Agent guidance
|
|
70
|
+
|
|
71
|
+
- `memgineering-recall` (what the project signal means and which footer to
|
|
72
|
+
trust), `memgineering-writing` (the automatic scope stamp, and
|
|
73
|
+
`--no-scope` for machine-wide rules) and `memgineering-setup` (the
|
|
74
|
+
`project` verb) were updated. Restart your agent session after upgrading
|
|
75
|
+
so the new guidance is what gets read.
|
|
76
|
+
|
|
14
77
|
## [0.14.0] — 2026-08-29
|
|
15
78
|
|
|
16
79
|
### Added
|
|
17
80
|
|
|
18
81
|
- **A hosted brain's base files can finally be written.** `memgineering
|
|
19
|
-
|
|
82
|
+
base-write 01_BASE/USER.md --input <file|-|text>` fills or replaces the
|
|
20
83
|
body of a `01_BASE/` file on a hosted brain — the files `onboard` points
|
|
21
84
|
at, which until now could only be filled on a folder and left a hosted
|
|
22
85
|
brain reading as a blank form forever. The `memgineering:` block above
|
package/assets/MEMGINEERING.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: memgineering
|
|
3
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.15.0
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
# memgineering
|
|
@@ -215,6 +215,16 @@ and which base notes have gone unread — what you should already know here befo
|
|
|
215
215
|
they have to tell you again. It is the answer to a vague opening that recall
|
|
216
216
|
cannot serve, because there is nothing to search for yet.
|
|
217
217
|
|
|
218
|
+
On a hosted brain the folder counts too, as a name rather than a path: the CLI
|
|
219
|
+
sends the folder's project — `owner/repo` from the git remote, or whatever
|
|
220
|
+
`memgineering project` shows — and the server ranks what was asked about in
|
|
221
|
+
that project first. The response says so itself: `ranked_by` gains `asked about
|
|
222
|
+
in this project`, a card's reason reads `recalled 2× in this project`, and the
|
|
223
|
+
footer names which project those words mean. Trust the footer over your
|
|
224
|
+
assumption in the other cases as well — it says when this folder names no
|
|
225
|
+
project (nothing was sent), and when the server does not rank by project yet
|
|
226
|
+
(it was sent and ignored). A path never leaves the machine either way.
|
|
227
|
+
|
|
218
228
|
## Deciding which one to trust
|
|
219
229
|
|
|
220
230
|
```
|
|
@@ -255,6 +255,24 @@ memgineering use --default ~/brains/work
|
|
|
255
255
|
Inside a repository `use` writes a relative path, so it can be committed and
|
|
256
256
|
resolves for a teammate who links the same brain.
|
|
257
257
|
|
|
258
|
+
### Which project a folder is
|
|
259
|
+
|
|
260
|
+
```
|
|
261
|
+
memgineering project # what this folder answers to, and how it was decided
|
|
262
|
+
memgineering project acme/site # bind a name of your own to this repository
|
|
263
|
+
memgineering project --unset # back to the derived name
|
|
264
|
+
```
|
|
265
|
+
|
|
266
|
+
Derived without asking: the git remote's `owner/repo`, else the checkout's
|
|
267
|
+
folder name, else nothing — a folder outside any repository names no project
|
|
268
|
+
until somebody sets one. The name follows the repository, so worktrees and
|
|
269
|
+
subfolders of one checkout answer the same. It is what `remember` stamps as a
|
|
270
|
+
note's scope and what the reads send as `asked_from`, so a hosted resurface
|
|
271
|
+
can rank what was asked about here — as a name; the folder's path never
|
|
272
|
+
leaves the machine. Renaming does not move history: what was recalled under
|
|
273
|
+
the old name stays recorded there and the new name starts fresh, which the
|
|
274
|
+
command says out loud whenever it changes anything.
|
|
275
|
+
|
|
258
276
|
**An account can hold several hosted brains. `brains` lists them and
|
|
259
277
|
`use --brain <name>` switches.**
|
|
260
278
|
|
|
@@ -22,6 +22,25 @@ trade is permission-before for correction-after, and every write records how to
|
|
|
22
22
|
reverse it. Do not ask permission for ordinary observations — write them, and
|
|
23
23
|
mention it in a sentence.
|
|
24
24
|
|
|
25
|
+
**A note born in a project folder carries that project as its `scope`** — the
|
|
26
|
+
name comes from the git remote (`owner/repo`), or from the folder's binding
|
|
27
|
+
(`memgineering project` shows it). The stamp is automatic; an explicit
|
|
28
|
+
`--scope` beats it; a folder that names no project writes exactly what it
|
|
29
|
+
always wrote. Two flags are worth reaching for on purpose:
|
|
30
|
+
|
|
31
|
+
```
|
|
32
|
+
memgineering remember "we always squash before merging" --rule --no-scope \
|
|
33
|
+
--reason "they said from now on, about every repo — not this one"
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
- `--no-scope` for anything meant to hold machine-wide, rules especially: a
|
|
37
|
+
rule stamped with one project's scope drops out of another project's
|
|
38
|
+
`recall --scope` answers.
|
|
39
|
+
- `--scope <name>` when the note is ABOUT a project you are not standing in.
|
|
40
|
+
|
|
41
|
+
`--scope` and `--no-scope` together are refused — they answer the same
|
|
42
|
+
question both ways.
|
|
43
|
+
|
|
25
44
|
**`--reason` on every write.** It goes in the ledger and is the only part of the
|
|
26
45
|
record that still means anything six months later. Every write verb takes it:
|
|
27
46
|
`remember`, `revise`, `retire`, `exclude`, `undo`. The one on `undo` matters
|