novahiz 0.8.1 → 0.9.0

package/CHANGELOG.md

@@ -3,6 +3,93 @@
 All notable changes to Novahiz are documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
+## [0.9.0] - 2026-10-10
+
+### Added
+
+- **`second-memory project-init`** — gives a new project its vault folders
+  (`docs/journal/decisions/<project>/`, each with a real `_MOC.md`, never
+  `memory/`) and binds the project to its branch. Dry-run by default,
+  `--branch Domain/Branch` validates against the catalog, idempotent, and
+  `--apply` writes the `vault.json` binding (slug → domain/branch) in the
+  memory root.
+- **`novahiz init` Obsidian step** — when a vault exists and the project has
+  a name, init creates the project's folders through the same logic; no
+  vault, no name or no branch signal means the step skips with an advice and
+  never invents a folder. Honors `--dry-run`.
+- **`journal` and `decisions` leaves** in `catalog/vault-structure.json` for
+  every `memory|docs` branch (19 branches, 38 leaves), with root
+  `journalKeywords` / `decisionsKeywords`. `routePath` resolves the leaf
+  `decisions` > `journal` > `docs` > `memory`, and the project level extends
+  to the new leaves.
+- **Project binding in `routePath`** — a note carrying a `project:` bound by
+  `project-init` lands in the project's branch whatever the keywords say;
+  stale or missing bindings fall back to the historic keyword routing.
+
+### Changed
+
+- **`second-memory sync` is archive-only** — project memory stays local
+  (`MEMORY.md` + `project-memory/` slots); the bidirectional slot ↔ vault
+  mirror (pull / push / rebuild, last-writer-wins) is retired. `sync` now
+  lists (dry-run) and archives (`--apply`, backed up under `Archive/.backup`)
+  the notes the old mirror generated (`novahiz_slot_id`), while keeping the
+  opt-in inverse import (`novahiz_slot_sync: true` → slot in local memory).
+  `status` / `doctor` report the leftovers as `project-memory note(s) in the
+  vault`.
+- **Skills and instructions follow** — `novahiz-memory` / `memory` are
+  local-only (no vault write, no routing table); `novahiz-second-memory`
+  documents the new leaves, `project-init`, the binding and the archive-only
+  sync; `instructions.md` adds the local-memory rule and the
+  no-speculative-folders rule.
+
+### Removed
+
+- Mirror helpers and constants of the retired sync (`renderSlotNote`,
+  `slotBody`, `parseIso`, `SYNC_TOLERANCE_MS`, and the `readIndex` usage in
+  sync).
+
+## [0.8.2] - 2026-10-10
+
+### Fixed
+
+- **In-place `npm install -g novahiz` now keeps the new package instead of
+  silently restoring the previous one** (`install/install.mjs`): the
+  `Finalize` step spawned `npm outdated` / `npm update` from inside npm's own
+  `postinstall` to refresh dependencies. npm exports its config to lifecycle
+  scripts (`npm_config_*`, `envExport` default true), so the inherited
+  `npm_config_global=true` from the outer `npm install -g` turned that refresh
+  into a **second reify of the same global prefix while npm's transaction was
+  still open**. Its retire of `node_modules\novahiz` fails with `EBUSY` (the
+  installer's cwd *is* the package directory), the nested npm crashes, and
+  arborist's rollback runs `rm(new)` + `rename(.novahiz-OLD → novahiz)` —
+  the previous install comes back byte-for-byte with its original mtimes
+  while the outer npm reports exit 0 / "changed 1 package". The refresh is now
+  pinned to the novahiz home (`npm_config_global=false`, `--ignore-scripts`),
+  a directory the outer transaction never touches. This was the actual cause
+  of "the in-place install does not replace": it reproduces with **no OpenCode
+  restart at all** (proved end-to-end 2026-10-10, see tests below).
+
+- **The npm postinstall no longer writes the opencode config while npm is
+  still mid-transaction** (`install/install.mjs`, `install/lib.mjs`): a second,
+  independent failure mode — running `npm install -g novahiz` from an
+  OpenCode-owned shell restarted the OpenCode server during `postinstall`, and
+  the restart killed the process tree with npm still inside its reify
+  transaction. Depending on where the kill landed, the update either left
+  orphaned `.novahiz-*` retire directories and shims behind or aborted the
+  configuration pass. The installer now splits in two: the synchronous pass
+  only touches `NOVAHIZ_HOME` (the only zone never observed as the restart
+  trigger across three reproduced kills), while everything that writes the
+  OpenCode config — skills, plugin, agent, commands, `opencode.jsonc`,
+  provider skill packs — runs in a detached process that waits for the
+  installer and npm to exit first (`--deferred-opencode`, log:
+  `<novahiz-home>/install-deferred.log`). That child is spawned with
+  `cwd=novahiz-home` so it can never hold the package directory open (a
+  process whose cwd sits in `node_modules\novahiz` is what makes any npm
+  retire of it fail with `EBUSY` on Windows). Direct runs (`novahiz-install`,
+  CLI bootstrap) keep the historical fully synchronous behaviour, and
+  `--sync` forces that behaviour back under npm as an escape hatch.
+  Regression tests: `tests/install-defer.test.ts`.
+
 ## [Unreleased]
 
 ## [0.8.1] - 2026-10-10

package/adapters/opencode/instructions.md

@@ -17,13 +17,14 @@ Search it yourself (`novahiz second-memory search "<terms>"`, then read the note
 Do **not** consult it for trivial edits, unrelated questions, or when the prompt already carries the needed context.
 
 ### Rules
-1. When the user asks to **save / memorize / update** memory, load the `memory` skill (alias for `novahiz-memory`) and follow its procedure without exception. For vault-only writes and structure questions, load `novahiz-second-memory` instead: it owns the vault's fixed, predefined arborescence.
-2. Vault routing comes from the predefined structure (`catalog/vault-structure.json`, surfaced by the `novahiz-second-memory` skill) — never guess a location. When ambiguous, ask the user, and display the chosen path before writing.
+1. When the user asks to **save / memorize / update** memory, load the `memory` skill (alias for `novahiz-memory`) and follow its procedure without exception. Project memory is local to the project (`MEMORY.md` + `project-memory/` slots) and **never goes into the vault**. For vault-only writes and structure questions, load `novahiz-second-memory` instead: it owns the vault's fixed, predefined arborescence.
+2. Vault routing comes from the predefined structure (`catalog/vault-structure.json`, surfaced by the `novahiz-second-memory` skill) — never guess a location. A note belongs to a project when its frontmatter carries `project:`; its leaf is `decisions` on a `decisionsKeywords` hit, else `journal` on a `journalKeywords` hit, else `docs`, else `memory`. When ambiguous, ask the user, and display the chosen path before writing.
 3. Search before you write: `novahiz second-memory search "<terms>"` — merge into an existing note rather than creating a duplicate. Link pages with `[[wikilinks]]`.
 4. Never write to `index.md`, `log.md`, `hot.md`, `.manifest.json`, `_meta/`, or `.obsidian/`. If the user asks for it, do it step by step in front of them, with a backup first for anything under `.obsidian/`.
 5. Never create a root domain on your own: every new domain requires user agreement and a structure update.
 6. Include mandatory frontmatter: `title, category, tags, sources, created, updated, summary`.
-7. Structure maintenance is CLI work: `novahiz second-memory [init|doctor|fix|sync|status]` (dry-run by default, `--apply` to write).
+7. Structure maintenance is CLI work: `novahiz second-memory [init|doctor|fix|sync|project-init|status]` (dry-run by default, `--apply` to write). `sync` only archives notes the old memory mirror left in the vault — it never mirrors memory into the vault.
+8. Folders are never created speculatively: a folder appears on the first write, or when `second-memory project-init` (the same logic behind the `Obsidian project folder` step of `novahiz init`) creates a project's `docs/journal/decisions` folders on request — never `memory/<project>/`.
 
 ## Playwright Browser — Persistent Profile