memgineering 0.13.1 → 0.15.0

package/CHANGELOG.md

@@ -11,6 +11,145 @@ language the reader wants. The bilingual rule the monorepo applies to
 
 ## [Unreleased]
 
+## [0.15.0] — 2026-08-29
+
+### Added
+
+- **A folder knows which project it is.** `memgineering project` names the
+  project the current folder counts as — derived from the git remote
+  (`owner/repo`), else the checkout's folder name, else nothing; worktrees
+  and subfolders of one checkout answer the same. `memgineering project
+<name>` binds your own name to the repository and `--unset` returns to the
+  derived one. Renaming does not move history: what was recalled under the
+  old name stays recorded there, and the command says so whenever it
+  changes anything. Derivation reads `.git/config` directly — no
+  subprocess, so the session-start hook's deadline is never spent on it.
+- **A note remembers the project it was born in.** `remember` inside a
+  project folder stamps that project as the note's `scope` automatically.
+  An explicit `--scope` still wins; the new `--no-scope` writes a
+  machine-wide note on purpose — rules especially, since a rule stamped
+  with one project's scope drops out of another project's `--scope`
+  recalls. A derived name the server would refuse (over 128 chars, or
+  nothing once normalized) is skipped silently and the note is written
+  unscoped — an ambient signal never fails a command. The `YYYY-MM` noise
+  scope that path inference used to give observations is gone for new
+  notes.
+- **Reads say where they were asked from — as a name, never a path.**
+  recall, open and resurface now send `asked_from`, the folder's project
+  name, and a hosted brain records it beside what was returned. The local
+  event log records the same name next to the `context_dir` it always
+  kept. The working directory itself still never leaves the machine; the
+  privacy page names the new field, what it holds, and its 90-day window.
+- **A hosted resurface finally ranks by "asked about here."** When the
+  session's folder names a project, the hosted ranking weighs what was
+  asked about in that project first — the same weight a folder brain has
+  always given "in this folder" — and says so honestly: `ranked_by` gains
+  `asked about in this project`, a card's reason reads `recalled 2× in
+this project`, and the footer names which project those words mean. A
+  brain with no history yet ranks exactly as before and claims nothing.
+
+### Changed
+
+- The hosted resurface footer no longer claims a hosted brain cannot know
+  where a question was asked from. It now tells one of three truths: which
+  project the ranking used; that this folder names no project, so nothing
+  was sent; or that the server was sent the signal and does not rank by
+  project yet. `resurface --json` carries `asked_from` so a machine reader
+  can tell those cases apart too.
+
+### Compatibility
+
+- An older server ignores `asked_from` entirely (unknown fields are
+  dropped); the CLI reads the three-entry `ranked_by` and says the server
+  does not rank by project yet, rather than letting the silence read as an
+  empty folder signal. An older CLI against the new server sends nothing
+  and behaves exactly as before. Event lines written before the field
+  existed still parse and still rank.
+
+### Agent guidance
+
+- `memgineering-recall` (what the project signal means and which footer to
+  trust), `memgineering-writing` (the automatic scope stamp, and
+  `--no-scope` for machine-wide rules) and `memgineering-setup` (the
+  `project` verb) were updated. Restart your agent session after upgrading
+  so the new guidance is what gets read.
+
+## [0.14.0] — 2026-08-29
+
+### Added
+
+- **A hosted brain's base files can finally be written.** `memgineering
+base-write 01_BASE/USER.md --input <file|-|text>` fills or replaces the
+  body of a `01_BASE/` file on a hosted brain — the files `onboard` points
+  at, which until now could only be filled on a folder and left a hosted
+  brain reading as a blank form forever. The `memgineering:` block above
+  the body survives byte-for-byte, a body that would itself parse as
+  frontmatter is refused rather than stored as a note that invents its own
+  id, and replacing requires the revision a prior read handed you. On a
+  folder brain the verb refuses and names the file to open instead: there,
+  bodies belong to your own file tools, and that has not changed.
+- **The write is in the ledger, and `undo` takes it back.** A base write
+  records the same row every other change does; `undo` restores the
+  replaced body, or deletes the file when the write is the one that
+  created it. The replaced prose waits OUTSIDE the ledger, for 90 days —
+  the ledger records hashes and a reverse patch, never a note's text, and
+  an append-only copy of deleted prose would be one nothing screens. After
+  90 days the sweep takes it and that particular write can no longer be
+  reversed; the refusal says so plainly rather than calling it "expired".
+  The privacy page names this store and its window.
+- **Boundaries screen base writes too**, with one exemption: a note that
+  declares `never_store` words may say its own words in its own body —
+  which is what a BOUNDARIES.md is for — and that write carries the
+  `declared` mark in the ledger, so a crossing the record cannot name is
+  not possible. Other notes' declared words still refuse there.
+- **A draft leaves a ledger row the moment it exists.** `propose` (and the
+  hosted equivalent) now records that a draft was made, so a proposal that
+  expired unseen is visible in `log` instead of having never existed. The
+  row carries no patch and no hashes, because nothing changed: undoing it
+  is refused with the way out named — decide it, approve or reject. A bare
+  `undo` steps over a waiting draft rather than refusing because one is
+  pending, and `evidence` counts drafts on their own line instead of
+  inflating what changed.
+
+### Changed
+
+- **`revise` against a hosted brain now answers with the boundary words the
+  note actually holds**, parsed from the bytes that landed rather than the
+  ones that were sent. `--never-store-add` uses that answer instead of
+  reading the note back, so widening a boundary costs one round trip fewer
+  while the check that catches a server storing something other than what
+  it accepted stays exactly as strong. A server too old to answer that way
+  is detected by the absence and read back as before.
+- `revise --json` against such a server therefore carries a `never_store`
+  field.
+
+### Fixed
+
+- **The `undo` line printed after a `--local` write now says `--local`.**
+  It printed `--vault` or nothing, so on a machine signed in to a hosted
+  brain the suggested undo acted on the cloud brain — a suggestion that
+  failed when followed, on the exact machine `--local` exists for. Both
+  flags print when both were passed.
+- The refusal a folder brain gives `base-write` names the file to edit in
+  full; an earlier form truncated long paths, cutting off the one thing
+  the message exists to say.
+
+### Agent guidance
+
+- The `memgineering-writing` skill changed: onboarding branches on where
+  the brain lives (file tools on a folder, `base-write` on a hosted
+  brain), the line claiming no route can edit a base file's body is gone,
+  and the `propose` section says a draft leaves a ledger row and is closed
+  by deciding. **Restart your agent session after upgrading** so the new
+  guidance is what gets injected.
+
+### Note for older clients
+
+Two ledger verbs are new (`write`, `propose`). A CLI older than this
+release skips a line it does not recognise in a folder brain's ledger, and
+its bare `undo` then refuses outright rather than reversing the wrong
+thing — it stops instead of guessing. Upgrading both ends removes the gap.
+
 ## [0.13.1] — 2026-08-28
 
 ### Changed

package/assets/MEMGINEERING.md

@@ -2,7 +2,7 @@
 name: memgineering
 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.
 type: skill
-version: 0.13.1
+version: 0.15.0
 ---
 
 # memgineering

package/assets/memgineering-recall/SKILL.md

@@ -215,6 +215,16 @@ and which base notes have gone unread — what you should already know here befo
 they have to tell you again. It is the answer to a vague opening that recall
 cannot serve, because there is nothing to search for yet.
 
+On a hosted brain the folder counts too, as a name rather than a path: the CLI
+sends the folder's project — `owner/repo` from the git remote, or whatever
+`memgineering project` shows — and the server ranks what was asked about in
+that project first. The response says so itself: `ranked_by` gains `asked about
+in this project`, a card's reason reads `recalled 2× in this project`, and the
+footer names which project those words mean. Trust the footer over your
+assumption in the other cases as well — it says when this folder names no
+project (nothing was sent), and when the server does not rank by project yet
+(it was sent and ignored). A path never leaves the machine either way.
+
 ## Deciding which one to trust
 
 ```

package/assets/memgineering-setup/SKILL.md

@@ -255,6 +255,24 @@ memgineering use --default ~/brains/work
 Inside a repository `use` writes a relative path, so it can be committed and
 resolves for a teammate who links the same brain.
 
+### Which project a folder is
+
+```
+memgineering project                    # what this folder answers to, and how it was decided
+memgineering project acme/site          # bind a name of your own to this repository
+memgineering project --unset            # back to the derived name
+```
+
+Derived without asking: the git remote's `owner/repo`, else the checkout's
+folder name, else nothing — a folder outside any repository names no project
+until somebody sets one. The name follows the repository, so worktrees and
+subfolders of one checkout answer the same. It is what `remember` stamps as a
+note's scope and what the reads send as `asked_from`, so a hosted resurface
+can rank what was asked about here — as a name; the folder's path never
+leaves the machine. Renaming does not move history: what was recalled under
+the old name stays recorded there and the new name starts fresh, which the
+command says out loud whenever it changes anything.
+
 **An account can hold several hosted brains. `brains` lists them and
 `use --brain <name>` switches.**
 

package/assets/memgineering-writing/SKILL.md

@@ -22,6 +22,25 @@ trade is permission-before for correction-after, and every write records how to
 reverse it. Do not ask permission for ordinary observations — write them, and
 mention it in a sentence.
 
+**A note born in a project folder carries that project as its `scope`** — the
+name comes from the git remote (`owner/repo`), or from the folder's binding
+(`memgineering project` shows it). The stamp is automatic; an explicit
+`--scope` beats it; a folder that names no project writes exactly what it
+always wrote. Two flags are worth reaching for on purpose:
+
+```
+memgineering remember "we always squash before merging" --rule --no-scope \
+  --reason "they said from now on, about every repo — not this one"
+```
+
+- `--no-scope` for anything meant to hold machine-wide, rules especially: a
+  rule stamped with one project's scope drops out of another project's
+  `recall --scope` answers.
+- `--scope <name>` when the note is ABOUT a project you are not standing in.
+
+`--scope` and `--no-scope` together are refused — they answer the same
+question both ways.
+
 **`--reason` on every write.** It goes in the ledger and is the only part of the
 record that still means anything six months later. Every write verb takes it:
 `remember`, `revise`, `retire`, `exclude`, `undo`. The one on `undo` matters
@@ -205,7 +224,10 @@ memgineering propose supersede --memory <id> --claim "…" --reason "…" --exce
 memgineering propose reclassify --memory <id> --kind decision --reason "…" --excerpt "…"
 ```
 
-`propose` is where the judgement goes in, and it still writes no note. The
+`propose` is where the judgement goes in, and it still writes no note — but it
+does leave a ledger row the moment the draft exists, so `log` shows a draft
+that later expired unseen instead of pretending it never was. Undoing that row
+is refused on purpose: a draft is closed by deciding it, approve or reject. The
 actions are `supersede`, `reinforce`, `conflict`, `retire`, `unretire` and
 `reclassify` — the same vocabulary `revise` uses, plus the one that only changes
 what sort of memory it is. **`--excerpt` is required for every one of them**,
@@ -290,9 +312,20 @@ its own kind of forgetting. They may also ask outright ("set up my memory", "fil
 thin out — three good lines beat a filled-in template. Take what they say in
 passing during ordinary work too; most of `TOOLING.md` gets written by noticing.
 
-**How to write it — both halves.** `revise` only touches frontmatter, so write
-the body FIRST with your normal file tools, replacing the template's prompt with
-what they actually said, then record the conclusion:
+**How to write it — both halves.** `revise` only touches frontmatter, so the
+body comes first, and how you write it depends on where the brain lives. On a
+folder: your normal file tools, replacing the template's prompt with what they
+actually said. On a hosted brain there are no files — the body goes through the
+verb built for exactly this:
+
+```
+memgineering base-write 01_BASE/USER.md --input -
+```
+
+(`--input` takes a file, `-` for stdin, or the text inline. Only `01_BASE/`
+files — an ordinary note's body is never written this way. The write lands in
+the ledger and `undo` can take it back, though not forever: the replaced body
+is kept 90 days.) Then record the conclusion either way:
 
 ```
 memgineering revise 01_BASE/USER.md \
@@ -384,9 +417,12 @@ which you meant.
 To lift a boundary entirely: `memgineering retire <the declaration>`. That is
 the un-declare path, and it is the user's decision, never yours.
 
-On a hosted brain the declaration NOTE is the record — there is no route that
-edits a base file's body, so mirroring the sentence into `BOUNDARIES.md` is a
-folder-brain and onboarding-time thing.
+On a hosted brain the declaration NOTE is the record, and since 0.14.0 the
+sentence can ALSO live in `BOUNDARIES.md` itself: `base-write` fills a base
+file's body where there are no files to edit. A boundary note may say its own
+declared words in its own body — that write carries the `declared` mark in the
+ledger — but OTHER notes' declared words still refuse there like everywhere
+else.
 
 ### When a write is refused