memgineering 0.13.1 → 0.14.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 +76 -0
- package/assets/MEMGINEERING.md +1 -1
- package/assets/memgineering-writing/SKILL.md +24 -7
- package/dist/index.js +5264 -5060
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -11,6 +11,82 @@ language the reader wants. The bilingual rule the monorepo applies to
|
|
|
11
11
|
|
|
12
12
|
## [Unreleased]
|
|
13
13
|
|
|
14
|
+
## [0.14.0] — 2026-08-29
|
|
15
|
+
|
|
16
|
+
### Added
|
|
17
|
+
|
|
18
|
+
- **A hosted brain's base files can finally be written.** `memgineering
|
|
19
|
+
base-write 01_BASE/USER.md --input <file|-|text>` fills or replaces the
|
|
20
|
+
body of a `01_BASE/` file on a hosted brain — the files `onboard` points
|
|
21
|
+
at, which until now could only be filled on a folder and left a hosted
|
|
22
|
+
brain reading as a blank form forever. The `memgineering:` block above
|
|
23
|
+
the body survives byte-for-byte, a body that would itself parse as
|
|
24
|
+
frontmatter is refused rather than stored as a note that invents its own
|
|
25
|
+
id, and replacing requires the revision a prior read handed you. On a
|
|
26
|
+
folder brain the verb refuses and names the file to open instead: there,
|
|
27
|
+
bodies belong to your own file tools, and that has not changed.
|
|
28
|
+
- **The write is in the ledger, and `undo` takes it back.** A base write
|
|
29
|
+
records the same row every other change does; `undo` restores the
|
|
30
|
+
replaced body, or deletes the file when the write is the one that
|
|
31
|
+
created it. The replaced prose waits OUTSIDE the ledger, for 90 days —
|
|
32
|
+
the ledger records hashes and a reverse patch, never a note's text, and
|
|
33
|
+
an append-only copy of deleted prose would be one nothing screens. After
|
|
34
|
+
90 days the sweep takes it and that particular write can no longer be
|
|
35
|
+
reversed; the refusal says so plainly rather than calling it "expired".
|
|
36
|
+
The privacy page names this store and its window.
|
|
37
|
+
- **Boundaries screen base writes too**, with one exemption: a note that
|
|
38
|
+
declares `never_store` words may say its own words in its own body —
|
|
39
|
+
which is what a BOUNDARIES.md is for — and that write carries the
|
|
40
|
+
`declared` mark in the ledger, so a crossing the record cannot name is
|
|
41
|
+
not possible. Other notes' declared words still refuse there.
|
|
42
|
+
- **A draft leaves a ledger row the moment it exists.** `propose` (and the
|
|
43
|
+
hosted equivalent) now records that a draft was made, so a proposal that
|
|
44
|
+
expired unseen is visible in `log` instead of having never existed. The
|
|
45
|
+
row carries no patch and no hashes, because nothing changed: undoing it
|
|
46
|
+
is refused with the way out named — decide it, approve or reject. A bare
|
|
47
|
+
`undo` steps over a waiting draft rather than refusing because one is
|
|
48
|
+
pending, and `evidence` counts drafts on their own line instead of
|
|
49
|
+
inflating what changed.
|
|
50
|
+
|
|
51
|
+
### Changed
|
|
52
|
+
|
|
53
|
+
- **`revise` against a hosted brain now answers with the boundary words the
|
|
54
|
+
note actually holds**, parsed from the bytes that landed rather than the
|
|
55
|
+
ones that were sent. `--never-store-add` uses that answer instead of
|
|
56
|
+
reading the note back, so widening a boundary costs one round trip fewer
|
|
57
|
+
while the check that catches a server storing something other than what
|
|
58
|
+
it accepted stays exactly as strong. A server too old to answer that way
|
|
59
|
+
is detected by the absence and read back as before.
|
|
60
|
+
- `revise --json` against such a server therefore carries a `never_store`
|
|
61
|
+
field.
|
|
62
|
+
|
|
63
|
+
### Fixed
|
|
64
|
+
|
|
65
|
+
- **The `undo` line printed after a `--local` write now says `--local`.**
|
|
66
|
+
It printed `--vault` or nothing, so on a machine signed in to a hosted
|
|
67
|
+
brain the suggested undo acted on the cloud brain — a suggestion that
|
|
68
|
+
failed when followed, on the exact machine `--local` exists for. Both
|
|
69
|
+
flags print when both were passed.
|
|
70
|
+
- The refusal a folder brain gives `base-write` names the file to edit in
|
|
71
|
+
full; an earlier form truncated long paths, cutting off the one thing
|
|
72
|
+
the message exists to say.
|
|
73
|
+
|
|
74
|
+
### Agent guidance
|
|
75
|
+
|
|
76
|
+
- The `memgineering-writing` skill changed: onboarding branches on where
|
|
77
|
+
the brain lives (file tools on a folder, `base-write` on a hosted
|
|
78
|
+
brain), the line claiming no route can edit a base file's body is gone,
|
|
79
|
+
and the `propose` section says a draft leaves a ledger row and is closed
|
|
80
|
+
by deciding. **Restart your agent session after upgrading** so the new
|
|
81
|
+
guidance is what gets injected.
|
|
82
|
+
|
|
83
|
+
### Note for older clients
|
|
84
|
+
|
|
85
|
+
Two ledger verbs are new (`write`, `propose`). A CLI older than this
|
|
86
|
+
release skips a line it does not recognise in a folder brain's ledger, and
|
|
87
|
+
its bare `undo` then refuses outright rather than reversing the wrong
|
|
88
|
+
thing — it stops instead of guessing. Upgrading both ends removes the gap.
|
|
89
|
+
|
|
14
90
|
## [0.13.1] — 2026-08-28
|
|
15
91
|
|
|
16
92
|
### Changed
|
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.14.0
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
# memgineering
|
|
@@ -205,7 +205,10 @@ memgineering propose supersede --memory <id> --claim "…" --reason "…" --exce
|
|
|
205
205
|
memgineering propose reclassify --memory <id> --kind decision --reason "…" --excerpt "…"
|
|
206
206
|
```
|
|
207
207
|
|
|
208
|
-
`propose` is where the judgement goes in, and it still writes no note
|
|
208
|
+
`propose` is where the judgement goes in, and it still writes no note — but it
|
|
209
|
+
does leave a ledger row the moment the draft exists, so `log` shows a draft
|
|
210
|
+
that later expired unseen instead of pretending it never was. Undoing that row
|
|
211
|
+
is refused on purpose: a draft is closed by deciding it, approve or reject. The
|
|
209
212
|
actions are `supersede`, `reinforce`, `conflict`, `retire`, `unretire` and
|
|
210
213
|
`reclassify` — the same vocabulary `revise` uses, plus the one that only changes
|
|
211
214
|
what sort of memory it is. **`--excerpt` is required for every one of them**,
|
|
@@ -290,9 +293,20 @@ its own kind of forgetting. They may also ask outright ("set up my memory", "fil
|
|
|
290
293
|
thin out — three good lines beat a filled-in template. Take what they say in
|
|
291
294
|
passing during ordinary work too; most of `TOOLING.md` gets written by noticing.
|
|
292
295
|
|
|
293
|
-
**How to write it — both halves.** `revise` only touches frontmatter, so
|
|
294
|
-
|
|
295
|
-
|
|
296
|
+
**How to write it — both halves.** `revise` only touches frontmatter, so the
|
|
297
|
+
body comes first, and how you write it depends on where the brain lives. On a
|
|
298
|
+
folder: your normal file tools, replacing the template's prompt with what they
|
|
299
|
+
actually said. On a hosted brain there are no files — the body goes through the
|
|
300
|
+
verb built for exactly this:
|
|
301
|
+
|
|
302
|
+
```
|
|
303
|
+
memgineering base-write 01_BASE/USER.md --input -
|
|
304
|
+
```
|
|
305
|
+
|
|
306
|
+
(`--input` takes a file, `-` for stdin, or the text inline. Only `01_BASE/`
|
|
307
|
+
files — an ordinary note's body is never written this way. The write lands in
|
|
308
|
+
the ledger and `undo` can take it back, though not forever: the replaced body
|
|
309
|
+
is kept 90 days.) Then record the conclusion either way:
|
|
296
310
|
|
|
297
311
|
```
|
|
298
312
|
memgineering revise 01_BASE/USER.md \
|
|
@@ -384,9 +398,12 @@ which you meant.
|
|
|
384
398
|
To lift a boundary entirely: `memgineering retire <the declaration>`. That is
|
|
385
399
|
the un-declare path, and it is the user's decision, never yours.
|
|
386
400
|
|
|
387
|
-
On a hosted brain the declaration NOTE is the record
|
|
388
|
-
|
|
389
|
-
|
|
401
|
+
On a hosted brain the declaration NOTE is the record, and since 0.14.0 the
|
|
402
|
+
sentence can ALSO live in `BOUNDARIES.md` itself: `base-write` fills a base
|
|
403
|
+
file's body where there are no files to edit. A boundary note may say its own
|
|
404
|
+
declared words in its own body — that write carries the `declared` mark in the
|
|
405
|
+
ledger — but OTHER notes' declared words still refuse there like everywhere
|
|
406
|
+
else.
|
|
390
407
|
|
|
391
408
|
### When a write is refused
|
|
392
409
|
|