owfadev 0.3.2 → 0.4.1

package/{.meta → .owfa}/docs/deployment.md

@@ -9,9 +9,9 @@ OWFA has three layers, and only one of them is "installed":
 | Layer | What it is | Where it lives | Installed? |
 |---|---|---|---|
 | **OWFA CLI** | the installer / upgrader (`init`, `upgrade`, `doctor`, `add`, `list`, `pkg`) | npm package, run via `npx` or a global install | no — it stays outside the workspace |
-| **OWFA Core** | the framework body: plugins, commands, protocols, kernel, skill copies | `.meta/` + `.agents/skills/` | yes — copied into the workspace |
-| **kernel** | the deterministic Python engine (`validate`, `inject`, `registry`, `deploy`, `install`) | `.meta/scripts/wiki_plugin_kernel.py` | no — it ships **inside** Core; there is no separate kernel install |
-| **packages** | optional domain extensions (course, lark, email, bili, project…) | `.meta/plugins/domains/<pkg>/` | on demand |
+| **OWFA Core** | the framework body: plugins, commands, protocols, kernel, skill copies | `.owfa/` + `.agents/skills/` | yes — copied into the workspace |
+| **kernel** | the deterministic Python engine (`validate`, `inject`, `registry`, `deploy`, `install`) | `.owfa/scripts/owfa_kernel.py` | no — it ships **inside** Core; there is no separate kernel install |
+| **packages** | optional domain extensions (course, lark, email, bili, project…) | `.owfa/plugins/domains/<pkg>/` | on demand |
 | **instance** | the workspace you own: `vault/`, `wiki/`, `AGENTS.md`, the framework body | your directory | — |
 
 The call chain is one direction:
@@ -29,12 +29,11 @@ my-workspace/
 ├── wiki/                      # the markdown world
 │   ├── notes/  sessions/  vault/
 │   └── index.md  tags.md  hot.md  log.md   # derived, rebuilt by the pipeline
-├── .meta/                     # OWFA Core
-│   ├── VERSION                # framework anchor (0.3)
+├── .owfa/                     # OWFA Core (kernel-only tree since the v0.4 split)
+│   ├── VERSION                # framework anchor (0.4.0)
 │   ├── scripts/               # kernel + pipeline + wikilib
-│   ├── plugins/core/          # 21 framework plugins
-│   ├── plugins/domains/       # installed packages (empty until you add one)
-│   ├── command/               # command masters
+│   ├── plugins/domains/       # installed packages — the embedded personal suite (21 members) lands here on init; the channel itself ships no plugins
+│   ├── command/               # framework command masters (suite-owned commands ride with their package)
 │   └── docs/                  # this guide and friends
 └── .agents/skills/            # deployed command/connector skill copies
 ```
@@ -62,7 +61,7 @@ All channels deploy the same Core tree; pick by environment, not by feature.
 | npm, target name | `npx owfa init my-workspace` | **name application pending** (npm froze `owfa` as too similar to `ow`/`ora`) |
 | npm, fallback name | `npx owfadev init my-workspace` | same CLI, bins `owfa` + `owfadev`; to be published if the name is not granted |
 | git, clone-as-instance | `git clone https://github.com/owfadev/owfa.git my-workspace` | works today |
-| git, embed into an existing vault | clone the template elsewhere, copy `.meta/` + `.agents/skills/` | works today |
+| git, embed into an existing vault | clone the template elsewhere, copy `.owfa/` + `.agents/skills/` | works today |
 | template + instance (developers) | a template clone + a separate instance | see [CONTRIBUTING.md](../../CONTRIBUTING.md) |
 
 > Until the npm name is served by the registry, the git channel is the working path. Do not treat `npx owfa` as live before `npm view owfa version` returns a version.
@@ -84,13 +83,14 @@ npx owfadev doctor                  # fallback: same check through the fallback
 
 **Command forms.** `npx <package> <verb>` needs no global install. A global install (`npm i -g owfa` or `npm i -g owfadev`) puts **both** `owfa` and `owfadev` on `PATH`. The rest of this guide writes `owfa <verb>` for the CLI and `kernel …` for the Python engine; substitute `npx owfa` / `npx owfadev` if you are not installing globally.
 
-`init` performs the five manual steps below:
+`init` is two-stage by default (the v0.4 final shape — this is the only shape the channel ships):
 
-1. copies `.meta/` and `.agents/skills/` from the tarball;
-2. creates `vault/`, `wiki/notes/`, `wiki/sessions/`, `wiki/vault/`;
+1. copies `.owfa/` and `.agents/skills/` from the tarball and runs `python .owfa/scripts/owfa_kernel.py all` (validate → inject → registry → deploy) over the kernel-only tree;
+2. installs the embedded **personal suite** (the 21 former core plugins, a vetted copy of the **owfa-personal** package at `payloads/personal/`) offline — its `PKG.yaml` `skeleton:` declaration creates `vault/`, `wiki/notes/`, `wiki/sessions/`, `wiki/vault/`, and its command masters (`owfa-map`, `owfa-profile`, `owfa-save`) deploy with it;
 3. writes `AGENTS.md` from the seed, or appends **only the injection region** to an existing one (the handwritten part is preserved; half-present markers are refused);
-4. runs `python .meta/scripts/wiki_plugin_kernel.py all` (validate → inject → registry → deploy);
-5. optionally installs packages (`--packages cuhksz,lark`), stopping at the first package that stages a semantic migration.
+4. optionally installs packages (`--packages cuhksz,lark`), stopping at the first package that stages a semantic migration.
+
+`--core none` skips stage 2 (a kernel-only instance: no skeleton, no suite); `--core <pkg-id>` takes the suite from the registry instead of the embedded copy.
 
 Useful flags:
 
@@ -98,7 +98,7 @@ Useful flags:
 - `--packages a,b` — install packages from the registry during init;
 - `--force` — re-copy the framework trees over an existing instance, preserving the kernel's migration ledger, journal and registry cache. Instance data (`vault/`, `wiki/`) is never touched.
 
-If the directory already contains `.meta/`, `init` refuses; use `owfa upgrade` (or `--force` deliberately).
+If the directory already contains `.owfa/`, `init` refuses; use `owfa upgrade` (or `--force` deliberately).
 
 ### 4.2 git channel — the five manual steps
 
@@ -114,30 +114,35 @@ rm -rf .git && git init
 **Embed into an existing vault**: clone the template somewhere else, then copy the two trees into the target root:
 
 ```bash
-cp -R /path/to/owfa/.meta          /path/to/my-workspace/
+cp -R /path/to/owfa/.owfa          /path/to/my-workspace/
 cp -R /path/to/owfa/.agents/skills /path/to/my-workspace/.agents/
 ```
 
+Since the v0.4 split the copied tree carries the kernel only — no plugins. Install the embedded suite (it ships inside the clone at `payloads/personal/`) and the skeleton with it:
+
+```bash
+python3 .owfa/scripts/owfa_kernel.py install personal --path /path/to/owfa/payloads/personal
+```
+
 Then, at the workspace root:
 
 1. **Write `AGENTS.md`** — one identity paragraph, one layout paragraph, and the injection markers verbatim from [agents-example.md](agents-example.md). If an `AGENTS.md` already exists, paste in only the marker block (or let `owfa init` append it).
-2. **Create the four directories**: `vault/`, `wiki/notes/`, `wiki/sessions/`, `wiki/vault/`. Derived pages build themselves.
-3. **Converge**:
+2. **Converge**:
 
 ```bash
-python .meta/scripts/wiki_plugin_kernel.py all
+python .owfa/scripts/owfa_kernel.py all
 ```
 
-Expected: all core plugins validate, package rosters reconcile, the injection region is rebuilt, command copies are in sync.
+Expected: the personal suite's 21 members validate, package rosters reconcile, the injection region is rebuilt, command copies are in sync. The four skeleton directories (`vault/`, `wiki/notes/`, `wiki/sessions/`, `wiki/vault/`) came with the suite install — its `PKG.yaml` `skeleton:` declares them; the channel hardcodes no instance layout.
 
 ### 4.3 "Installing the kernel"
 
-There is nothing separate to install. The kernel is the file `.meta/scripts/wiki_plugin_kernel.py` inside Core; Python 3.9+ runs it. Verify it:
+There is nothing separate to install. The kernel is the file `.owfa/scripts/owfa_kernel.py` inside Core; Python 3.9+ runs it. Verify it:
 
 ```bash
-python3 .meta/scripts/wiki_plugin_kernel.py validate   # structural check, read-only
-python3 .meta/scripts/wiki_plugin_kernel.py ls         # 21 core plugins
-python3 .meta/scripts/wiki_plugin_kernel.py pkg        # installed packages + core remainder
+python3 .owfa/scripts/owfa_kernel.py validate   # structural check, read-only
+python3 .owfa/scripts/owfa_kernel.py ls         # the personal suite's 21 members (the framework tree itself carries none)
+python3 .owfa/scripts/owfa_kernel.py pkg        # installed packages + the unclaimed core remainder
 ```
 
 On Windows, `python` may be `py -3`; the CLI probes `python3`, `python`, then `py -3`. Set `OWFA_PYTHON=/path/to/python3` to override. If the kernel is missing, the Core copy is incomplete — recopy the tree, do not "pip install" anything.
@@ -175,7 +180,7 @@ The daily loops — library keeping, course learning, collaborative development
 
 ## 7. Packages — finding and installing
 
-Core ships only the framework plugins. External systems arrive as **packages**: one directory `.meta/plugins/domains/<pkg>/` with a `PKG.yaml` roster, plugin masters, commands and connectors.
+Core itself is two-stage since v0.4: the kernel payload lands first, then `init` installs the embedded **blessed suite** — the former framework plugins, now shipped as the **owfa-personal** package (a vetted copy bundled inside the tarball) — by default (`--core none` skips it, `--core <pkg>` installs a different core package). External systems arrive the same way, as **packages**: one directory `.owfa/plugins/domains/<pkg>/` with a `PKG.yaml` roster, plugin masters, commands and connectors.
 
 ### 7.1 Find what exists
 
@@ -185,28 +190,28 @@ Run these inside the instance:
 owfa list                    # registry catalog: versions, compat floors, installed marks
 owfa pkg                     # what is installed here: members, connectors, core remainder
 # the same through the kernel:
-python3 .meta/scripts/wiki_plugin_kernel.py list-remote
-python3 .meta/scripts/wiki_plugin_kernel.py pkg
+python3 .owfa/scripts/owfa_kernel.py list-remote
+python3 .owfa/scripts/owfa_kernel.py pkg
 ```
 
-The registry is the GitHub index at `owfadev/registry`; before installing, it is also readable directly as `INDEX.yaml` in that repository. Each row shows the package version, the framework compat floor, the member plugins and the trust level.
+The registry is the GitHub index at `owfadev/owfa-registry`; before installing, it is also readable directly as `INDEX.yaml` in that repository. Each row shows the package version, the framework compat floor, the member plugins and the trust level.
 
 ### 7.2 Install a package
 
 ```bash
 owfa add cuhksz              # wraps kernel install + convergence
 # equivalent, and more explicit:
-python3 .meta/scripts/wiki_plugin_kernel.py install cuhksz --yes
+python3 .owfa/scripts/owfa_kernel.py install cuhksz --yes
 ```
 
 This is also what the agent's **plugin** command does: you can ask the agent to install a package by name, and it drives the same kernel. The CLI is the human/script equivalent.
 
-What lands: plugin masters under `.meta/plugins/domains/<pkg>/`, command masters, in-repo connectors, skill copies, injection blocks, registry rows. Then the kernel converges. If the package declares a **first-run semantic migration** (root packages such as `project` do), the install stages it and `validate` stays red until an agent performs the semantic step:
+What lands: plugin masters under `.owfa/plugins/domains/<pkg>/`, command masters, in-repo connectors, skill copies, injection blocks, registry rows. Then the kernel converges. If the package declares a **first-run semantic migration** (root packages such as `project` do), the install stages it and `validate` stays red until an agent performs the semantic step:
 
 ```bash
-python3 .meta/scripts/wiki_plugin_kernel.py migrate <pkg>
+python3 .owfa/scripts/owfa_kernel.py migrate <pkg>
 # read the printed page, create the declaration/identity page, then:
-python3 .meta/scripts/wiki_plugin_kernel.py migrate <pkg> --clear
+python3 .owfa/scripts/owfa_kernel.py migrate <pkg> --clear
 ```
 
 The CLI stops and reports this instead of pretending convergence. `owfa add` exits non-zero in that state.
@@ -216,16 +221,16 @@ Other forms:
 - `kernel install <pkg>@<tag>` — pin a release tag;
 - `kernel install <owner>/<repo> --yes` — an unindexed repository (trust: unknown; `--yes` is the trust gate);
 - `kernel install <pkg> --path ./local-pkg` — a local package (channel C, no registry);
-- `--without a,b` — subset grammar is reserved; v1 reports not-yet-open. Offline alternative: copy `domains/<pkg>/` into `.meta/plugins/domains/` and rerun `all`.
+- `--without a,b` — subset grammar is reserved; v1 reports not-yet-open. Offline alternative: copy `domains/<pkg>/` into `.owfa/plugins/domains/` and rerun `all`.
 
 Trust levels are visible in `owfa list`: `framework-bundled` and `reviewed-3rd-party` install without a prompt; anything else needs `--yes` and is reported as unknown.
 
 ### 7.3 Upgrade and uninstall packages
 
 ```bash
-python3 .meta/scripts/wiki_plugin_kernel.py upgrade            # reconciliation report (read-only)
-python3 .meta/scripts/wiki_plugin_kernel.py upgrade <pkg> --yes # silent reinstall, per package, never cascaded
-python3 .meta/scripts/wiki_plugin_kernel.py uninstall <pkg> --yes
+python3 .owfa/scripts/owfa_kernel.py upgrade            # reconciliation report (read-only)
+python3 .owfa/scripts/owfa_kernel.py upgrade <pkg> --yes # silent reinstall, per package, never cascaded
+python3 .owfa/scripts/owfa_kernel.py uninstall <pkg> --yes
 ```
 
 - Package versions are release ordinals riding their own tags; member plugin versions do not lockstep.
@@ -237,30 +242,30 @@ python3 .meta/scripts/wiki_plugin_kernel.py uninstall <pkg> --yes
 ### npm channel
 
 ```bash
-npx owfa upgrade            # replace .meta/ + .agents/skills/ with the channel's version
+npx owfa upgrade            # replace .owfa/ + .agents/skills/ with the channel's version
 npx owfa upgrade --check    # read-only report
 npx owfa upgrade --backup   # keep a copy under .owfa/backup/<version>-<timestamp>/
 ```
 
-`upgrade` preserves the instance-local kernel state (`.meta/migrations/pending.json`, `.meta/kernel-journal.log`, `.meta/registry-cache.yaml`), replaces local edits under the two framework trees (instance hotfixes belong in git), and reruns `all`. A pending semantic migration blocks convergence and is reported with the exact `migrate` command.
+`upgrade` preserves the instance-local kernel state (`.owfa/migrations/pending.json`, `.owfa/kernel-journal.log`, `.owfa/registry-cache.yaml`), replaces local edits under the two framework trees (instance hotfixes belong in git), and reruns `all`. A pending semantic migration blocks convergence and is reported with the exact `migrate` command.
 
 ### git channel
 
-Re-copy `.meta/` and `.agents/skills/` from the new template revision (review the diff, do not blind-copy over pending migrations), then `kernel all`. The instance git snapshot is the rollback path.
+Re-copy `.owfa/` and `.agents/skills/` from the new template revision (review the diff, do not blind-copy over pending migrations), then `kernel all`. The instance git snapshot is the rollback path.
 
-Framework versions are anchored by `.meta/VERSION` (0.3); a target-side semantic migration can be staged by an upgrade, with the same tri-face warning and `kernel migrate` flow.
+Framework versions are anchored by `.owfa/VERSION` (0.4.0); a target-side semantic migration can be staged by an upgrade, with the same tri-face warning and `kernel migrate` flow.
 
 ## 9. Uninstall
 
 - **A package**: `kernel uninstall <pkg> --yes`; data zones stay, credentials are only reminded, never deleted.
-- **The whole framework**: delete `.meta/`, `.agents/skills/`, and the `AGENTS.md` injection region block. `vault/` and `wiki/` are yours; dispose of them as you see fit. Nothing else is installed.
+- **The whole framework**: delete `.owfa/`, `.agents/skills/`, and the `AGENTS.md` injection region block. `vault/` and `wiki/` are yours; dispose of them as you see fit. Nothing else is installed.
 
 ## 10. Troubleshooting
 
 | Symptom | Cause / fix |
 |---|---|
 | `Python 3.9+ not found` | install Python 3, or set `OWFA_PYTHON`; the installer is Node-only, the runtime is Python |
-| `already contains .meta/` | it is an instance — `owfa upgrade`; `--force` re-copies the trees |
+| `already contains .owfa/` | it is an instance — `owfa upgrade`; `--force` re-copies the trees |
 | `npx` runs an old version | `npx owfa@latest …`; npm caches by version range |
 | `publish` / `npx` 403 on `owfa` | the name is frozen on similarity grounds; use the `owfadev` fallback or wait for the application |
 | upgrade blocked by pending migrations | run `kernel migrate <pkg>`, perform the semantic step, then `--clear` |
@@ -276,11 +281,11 @@ Framework versions are anchored by `.meta/VERSION` (0.3); a target-side semantic
 | `vault/` | real assets | yes — the human owns it |
 | `wiki/` | markdown world, proxies, notes, sessions | yes, via commands; derived pages are rebuilt |
 | `wiki/index.md`, `tags.md`, `hot.md`, `log.md` | derived layer | no — the pipeline rewrites them |
-| `.meta/plugins/` | Core plugins + installed packages | no — framework authoring |
-| `.meta/scripts/` | kernel, pipeline, wikilib | no — framework authoring |
-| `.meta/command/` | command masters | no |
+| `.owfa/plugins/` | Core plugins + installed packages | no — framework authoring |
+| `.owfa/scripts/` | kernel, pipeline, wikilib | no — framework authoring |
+| `.owfa/command/` | command masters | no |
 | `.agents/skills/` | deployed skill copies | no — `kernel deploy` syncs them |
-| `.meta/migrations/` | staged semantic migrations + ledger | no — kernel zone |
+| `.owfa/migrations/` | staged semantic migrations + ledger | no — kernel zone |
 | `projects/` | project containers (if the project package is installed) | yes — project-owned |
 
 ## 12. FAQ

package/{.meta → .owfa}/docs/developer.md

@@ -7,8 +7,8 @@
 | Your plugin is… | It lands… | Trust gate |
 |---|---|---|
 | a **domain member** (depends chain reaches a domain root, e.g. bb-family) | that domain package's repo — PR there. Not a choice: the family closure claims it mechanically (`PKG.members` must include you or validate errors) | package maintainers |
-| a **new domain** of its own | your own repo as a package (`PKG.yaml`, see [packages.md](packages.md)) + a one-line PR to the [registry](https://github.com/owfadev/registry) | the registry PR — the human-review gate (inject text and connectors are the security faces, #12) |
-| **cross-cutting / non-domain** (global piece) | the framework repo's `core/` — PR there | owner review (charter-level, highest bar) |
+| a **new domain** of its own | your own repo as a package (`PKG.yaml`, see [packages.md](packages.md)) + a one-line PR to the [registry](https://github.com/owfadev/owfa-registry) | the registry PR — the human-review gate (inject text and connectors are the security faces, #12) |
+| **cross-cutting / non-domain** (global piece) | the core suite package repo (**owfa-personal**, since the v0.4 split) — PR there | owner review (charter-level, highest bar) |
 
 A single plugin never ships bare — the package is the distribution unit. A lone plugin is a single-member package (12 lines of PKG.yaml, see email/bili/project). Users prune with `--without` (subset grammar), so contributing into a big package never forces users to install all of it.
 
@@ -19,8 +19,8 @@ A single plugin never ships bare — the package is the distribution unit. A lon
 3. **Integration-test without a monorepo**: in the sandbox (or any instance),
    ```
    cd test-repo
-   python .meta/scripts/wiki_plugin_kernel.py install <pkg> --path /path/to/your/clone
-   python .meta/scripts/wiki_plugin_kernel.py validate --scope <pkg>
+   python .owfa/scripts/owfa_kernel.py install <pkg> --path /path/to/your/clone
+   python .owfa/scripts/owfa_kernel.py validate --scope <pkg>
    ```
    `--path` installs the local clone (channel C); iterate freely — reinstall after uninstalling, or just re-copy
 4. **PR** — one thing per commit, `模块: 概述`; self-check per [CONTRIBUTING](../../CONTRIBUTING.md) (framework root: `validate`; sandbox: `all`)

package/{.meta → .owfa}/docs/distribution.md

@@ -22,14 +22,15 @@ The npm tarball is the framework body, byte-for-byte what the git channel copies
 
 | Path | Contents | In tarball |
 |---|---|---|
-| `.meta/` | kernel, plugins, commands, protocol, docs | yes |
-| `.agents/skills/` | command/connector skill copies | yes |
+| `.owfa/` | kernel, framework commands, protocol, docs — no plugins (the v0.4 split) | yes |
+| `.agents/skills/` | framework command/connector skill copies | yes |
+| `payloads/personal/` | the embedded **blessed suite** — the owfa-personal package (21 plugin masters + its command masters) that a default init installs offline | yes |
 | `templates/AGENTS.template.md` | the instance shell with the injection markers | yes |
 | `bin/owfa.js` | CLI (zero dependencies) | yes |
 | `README.md`, `LICENSE` | — | yes |
 | `test/`, `scripts/`, `CONTRIBUTING.md`, `.github/` | development-only | no |
 
-Local state never ships: `__pycache__`, `*.pyc`, `.meta/kernel-journal.log`, `.meta/migrations/pending.json`, `.meta/registry-cache.yaml`, `test-repo/`. The release gate (`scripts/verify-release.js`) refuses to publish if any of them would be packed.
+Local state never ships: `__pycache__`, `*.pyc`, `.owfa/kernel-journal.log`, `.owfa/migrations/pending.json`, `.owfa/registry-cache.yaml`, `test-repo/`. The release gate (`scripts/verify-release.js`) refuses to publish if any of them would be packed.
 
 ## Commands
 
@@ -43,13 +44,13 @@ owfa pkg
 owfa version
 ```
 
-**init** — additive deployment, the five manual steps in [deployment.md](deployment.md) mechanized:
+**init** — additive deployment, the manual steps in [deployment.md](deployment.md) mechanized, two-stage by default:
 
-1. copies `.meta/` and `.agents/skills/` from the tarball
-2. creates `vault/`, `wiki/notes/`, `wiki/sessions/`, `wiki/vault/`
-3. writes `AGENTS.md` from the template when absent; when one exists, **appends only the injection region** (handwritten content before it is preserved byte-for-byte); refuses if the markers are half-present
-4. runs `python .meta/scripts/wiki_plugin_kernel.py all` (validate, inject, registry, skills)
-5. optionally installs packages from the registry (`--packages cuhksz,lark`)
+1. copies `.owfa/` and `.agents/skills/` from the tarball
+2. writes `AGENTS.md` from the template when absent; when one exists, **appends only the injection region** (handwritten content before it is preserved byte-for-byte); refuses if the markers are half-present
+3. runs `python .owfa/scripts/owfa_kernel.py all` (validate → inject → registry → deploy) over the kernel-only tree
+4. installs the embedded personal suite offline (`payloads/personal/`) — its `skeleton:` declaration creates `vault/`, `wiki/notes/`, `wiki/sessions/`, `wiki/vault/`; `--core none` skips this stage, `--core <pkg-id>` takes the suite from the registry
+5. optionally installs further packages from the registry (`--packages cuhksz,lark`)
 
 A package may declare a **first-run semantic migration** (root packages such as `project` do). Installing it stages the migration, and the CLI stops there with the exact `kernel migrate` command — clearing it is an agent act (create the identity/declaration page), not something a mechanical installer may fake. `init --packages` therefore exits non-zero in that state: the workspace is installed but not converged.
 
@@ -57,9 +58,10 @@ A package may declare a **first-run semantic migration** (root packages such as
 
 **upgrade** — tree replacement plus convergence:
 
-- compares the instance's `.meta/VERSION` with the tarball's; refuses downgrades unless `--force`
-- preserves instance-local kernel state: `.meta/migrations/pending.json`, `.meta/kernel-journal.log`, `.meta/registry-cache.yaml`
-- **replaces** local edits under `.meta/` and `.agents/skills/` — instance hotfixes belong in the instance's git history, which is the rollback path (the `--backup` flag also drops a copy under `.owfa/backup/<version>-<timestamp>/`)
+- compares the instance's `.owfa/VERSION` with the tarball's; refuses downgrades unless `--force`
+- preserves instance-local kernel state: `.owfa/migrations/pending.json`, `.owfa/kernel-journal.log`, `.owfa/registry-cache.yaml`
+- **replaces** local edits under `.owfa/` and `.agents/skills/` — instance hotfixes belong in the instance's git history, which is the rollback path (the `--backup` flag also drops a copy under `.owfa/backup/<version>-<timestamp>/`)
+- **converts** an in-tree core (every 0.3 / compat-era instance) into the personal suite package on the way in — the parked masters are rescued from the attic and adopted mechanically (`kernel upgrade personal` later swaps in the canonical suite)
 - reruns `all`; a pending semantic migration blocks convergence and is reported with the exact `kernel migrate` command
 - `--check` is a read-only report
 
@@ -67,13 +69,13 @@ A package may declare a **first-run semantic migration** (root packages such as
 
 **add** — thin wrapper over `kernel install` plus convergence. Registry trust rules still apply; `--yes` is forwarded. A staged first-run migration stops the command with the exact `migrate` hint (exit non-zero) instead of a false "done".
 
-**list** — `kernel list-remote`: the registry catalog with package versions, framework compat floors, member plugins, trust levels and installed marks. **pkg** — `kernel pkg`: what is installed in this instance (packages, members, connectors, core remainder).
+**list** — `kernel list-remote`: the registry catalog with package versions, framework compat floors, member plugins, trust levels and installed marks. **pkg** — `kernel pkg`: what is installed in this instance (packages, members, connectors, and plugins unclaimed by any package).
 
 ## Version invariant
 
-The npm version rides the framework anchor: `.meta/VERSION` `0.3` → package `0.3.x`. The release gate refuses a package whose `major.minor` diverges, and refuses a `v*` tag that does not match the package version exactly. `.meta/VERSION` still tracks the kernel contract, not product maturity (stage labels live in the README); npm patch releases may fix packaging without touching the contract.
+The version equation is exact equality across five carriers: `.owfa/VERSION` == `package.json` == git tag `vA.B.C` == the published npm version == the GitHub Release. `.owfa/VERSION` carries the **full release number** (`A.B.C`, e.g. `0.4.0`) — not a two-segment anchor riding the package's `major.minor`. The release gate (`scripts/verify-release.js`) refuses any drift: a tag that does not match the package version exactly, a `.owfa/VERSION` that diverges from either, or a publish that would break the equation all fail closed. A patch release therefore bumps all five carriers together in one commit. `.owfa/VERSION` still tracks the kernel contract, not product maturity (stage labels live in the README).
 
-Install identification is therefore trivial: `.meta/VERSION` says which framework a workspace is on; `owfa version` says which channel the CLI is on.
+Install identification is therefore trivial: `.owfa/VERSION` says which framework a workspace is on; `owfa version` says which channel the CLI is on.
 
 ## Release runbook
 
@@ -88,8 +90,8 @@ Every release:
 
 ```bash
 # 1. the framework contract and the package version move together
-$EDITOR .meta/VERSION          # e.g. 0.3 -> 0.4
-$EDITOR package.json           # "version": "0.4.0"
+$EDITOR .owfa/VERSION          # full A.B.C, e.g. 0.3.0 -> 0.4.0 — VERSION carries the full release number
+$EDITOR package.json           # "version": "0.4.0" — must equal .owfa/VERSION exactly
 git commit -am "release: framework 0.4.0"
 git tag v0.4.0 && git push --follow-tags
 ```
@@ -125,8 +127,8 @@ npm pack --dry-run
 | Symptom | Cause / fix |
 |---|---|
 | `Python 3.9+ not found` | install Python 3, or set `OWFA_PYTHON=/path/to/python3`; the installer itself is Node-only |
-| `already contains .meta/` | the directory is already an instance — use `owfa upgrade`; `--force` re-copies the trees |
+| `already contains .owfa/` | the directory is already an instance — use `owfa upgrade`; `--force` re-copies the trees |
 | `npx` runs an old version | `npx owfa@latest …`; npm caches by version range |
-| upgrade blocked by pending migrations | run `python .meta/scripts/wiki_plugin_kernel.py migrate <pkg>` and follow the printed page before upgrading again |
+| upgrade blocked by pending migrations | run `python .owfa/scripts/owfa_kernel.py migrate <pkg>` and follow the printed page before upgrading again |
 | publish fails: name too similar | npm froze `owfa` (similar to `ow`/`ora`); use the `owfadev` fallback or wait for the application; do not retry the same name |
 | Windows: `python` opens the Store | install Python 3 and ensure `py -3` or `python3` works; `OWFA_PYTHON` overrides detection |

package/.owfa/docs/home.md

@@ -0,0 +1,61 @@
+# Machine substrate: `~/.owfa` — connector homes and workspace bindings
+
+> v0.4 work order #56 (B1-B3). One machine hosts many OWFA workspaces; connector
+> state must not collide across them. This is the shared contract every OWFA
+> connector inherits by importing `.owfa/scripts/owfa_home.py` — no connector
+> invents its own layout.
+
+## Layout
+
+```
+~/.owfa/                                  # machine substrate (env: OWFA_HOME)
+└── connectors/<name>/
+    ├── bindings.json                     # registry: [{id, root, home, bot?, installed_at}]
+    └── homes/<id>/                       # one state dir per binding — credentials,
+                                          # spool, logs; 0600/0700, never in any repo
+```
+
+- `<id>` = human alias + 2-byte hash (`repo-a1b2`); the singleton case is
+  literally `default`.
+- Homes are **machine-global, not per-instance**: a connector does not read the
+  workspace; only its binding records which workspace drains it.
+
+## Resolution order
+
+`--root/--home` argument → `OWFA_ROOT` env → cwd reverse-lookup in the registry
+→ `homes/default` (single-workspace machines: zero configuration).
+
+On a machine with **two or more bindings**, a workspace matching none of them
+still falls through to `homes/default` (degraded-but-healthy) but emits a loud
+stderr warning: default is unregistered there, and two unmatched workspaces
+sharing it would be invisible to `exclusivity_violations`. Remove the ambiguity
+by binding the root explicitly or setting `OWFA_ROOT`.
+
+## Invariants
+
+1. **One home, one active binding.** Two workspaces draining one spool is a
+   semantic error (`exclusivity_violations` → error, the only error-level health
+   state in the substrate).
+2. **Unbound workspace = degraded-but-healthy** (warning in domain checks): the
+   domain is installed, the skill answers with guidance, nothing drains.
+3. **Unbind detaches, never deletes.** `homes/<id>/` holds credentials and
+   spool data — deletion is a human act, confirmed.
+4. **Stale bindings** (workspace root gone) are reported and cleaned on
+   confirmation — same rhythm as the tmp zone's stale_after.
+
+## Migration from pre-0.4 scattered homes
+
+`owfa_home.migrate_legacy_home("qq-cli", "~/.qq-cli")` **moves** the legacy
+directory into `homes/<id>` (move, never copy — credentials must not exist in
+two places) and leaves a symlink at the old path so old absolute references keep
+resolving; the symlink is the 0.5-cleanup item. Version-gated per connector: a
+connector that finds its legacy home on first run offers the migration instead
+of silently creating a second home.
+
+## Harness scope
+
+Connector manifests (PKG.yaml `connectors[]`) may declare `home:` for external
+connectors whose state lives outside this substrate (declared, not migrated).
+The registry mirrors per-package `harness:` — `universal` connectors are the
+first class; harness-locked ones register honestly and health checks surface the
+mismatch.

package/{.meta → .owfa}/docs/intro.md

@@ -47,10 +47,10 @@ A minimal chronology: 2026-08 the personal vault founded; 09-08 the prototype la
 |---|---|
 | Constitution and collaboration red lines | `AGENTS.md` |
 | Mechanics overview | the kernel reference skill |
-| How the mechanics work | `.meta/docs/mechanics.md` |
-| Daily usage | `.meta/docs/usage.md` |
-| Using the sandbox | `.meta/docs/sandbox.md` |
+| How the mechanics work | `.owfa/docs/mechanics.md` |
+| Daily usage | `.owfa/docs/usage.md` |
+| Using the sandbox | `.owfa/docs/sandbox.md` |
 | Why a plugin is designed this way | that plugin's `PLUGIN.md` |
-| Research basis | `.meta/docs/research-*.md` |
-| Deployment guide | `.meta/docs/deployment.md` (five-minute path: `.meta/docs/quickstart.md`) |
+| Research basis | `.owfa/docs/research-*.md` |
+| Deployment guide | `.owfa/docs/deployment.md` (five-minute path: `.owfa/docs/quickstart.md`) |
 | Run history and current state | `log.md` |

package/{.meta → .owfa}/docs/log-example.md

@@ -5,7 +5,7 @@
 ```markdown
 # 运行日志
 
-> 置顶追加、只增不删；条目 = `- YYYY-MM-DD <类型> [<域>]：一句话`（域标可缺省——无域事务，log 桥）。规则见 `.meta/plugins/core/log/`，写走 `pipeline.py log`。
+> 置顶追加、只增不删；条目 = `- YYYY-MM-DD <类型> [<域>]：一句话`（域标可缺省——无域事务，log 桥）。规则见 personal 套件（owfa-personal，内嵌副本 `payloads/personal/log/`）的 log 插件，写走 `pipeline.py log`。
 
 - 2026-10-12 other：<one sentence: what happened, from which domain, with what outcome>
 - 2026-10-12 map：<one sentence per mapping transaction>

package/{.meta → .owfa}/docs/map.md

@@ -1,6 +1,6 @@
 # Docs map — what to read when
 
-> The routing table for `.meta/docs/` (framework) and package-repo docs. The entry index for agents; skills point here, the documents stay the source of truth.
+> The routing table for `.owfa/docs/` (framework) and package-repo docs. The entry index for agents; skills point here, the documents stay the source of truth.
 
 | Situation | Read |
 |---|---|
@@ -12,12 +12,13 @@
 | Installing/upgrading the framework body; npm channel; release runbook | [distribution.md](distribution.md) |
 | The name: OWFA expansion, two names two jobs, collision policy | [naming.md](naming.md) |
 | Converting a legacy (pre-split flat) instance to the package era | [conversion.md](conversion.md) — the eight-step drill walked on a real instance |
-| Instance git usage (snapshots, red lines, recovery) | the [instance-git plugin](../plugins/core/instance-git/PLUGIN.md) (core 21) |
+| Instance git usage (snapshots, red lines, recovery) | the instance-git plugin (personal suite member; canonical repo [owfa-personal](https://github.com/owfadev/owfa-personal), embedded copy at `payloads/personal/instance-git/`) |
 | Framework mechanics: projections, bridges, injection, inject tiers | [mechanics.md](mechanics.md) |
 | (Un)install history, package lifecycle | [mechanics.md](mechanics.md) §7 + [packages.md](packages.md) |
+| Third-party view: develop → publish → install → update → uninstall; name governance | [plugin-lifecycle.md](plugin-lifecycle.md) |
 | Experiments: sandbox or local | [sandbox.md](sandbox.md) |
 | Development rules, commit flow, template + instance workflow | [CONTRIBUTING.md](../../CONTRIBUTING.md) — template-repo root (an instance reads it there, never keeps a copy) |
 | Day-to-day usage loops | [usage.md](usage.md) |
 | What the framework is, intro | [intro.md](intro.md) |
-| Package-side plugin docs (bb family, lark family, …) | the owning `pkg-*` repo's plugin masters |
+| Package-side plugin docs (bb family, lark family, …) | the owning `owfa-*` repo's plugin masters |
 | AGENTS.md seed / log seed examples | [agents-example.md](agents-example.md), [log-example.md](log-example.md) |

package/{.meta → .owfa}/docs/mechanics.md

@@ -1,17 +1,17 @@
 # Mechanics in Detail
 
-> Audience: members and contributors who will modify the framework. The authoritative source of mechanical rules is the kernel reference skill and the `.meta/` source code. This document expands the master outline by one level — principles, instance walkthroughs, and hands-on procedures — without copying rule text; where it conflicts with the source, the source prevails. Written 2026-10-04.
+> Audience: members and contributors who will modify the framework. The authoritative source of mechanical rules is the kernel reference skill and the `.owfa/` source code. This document expands the master outline by one level — principles, instance walkthroughs, and hands-on procedures — without copying rule text; where it conflicts with the source, the source prevails. Written 2026-10-04.
 
 ## 0. One Source, Five Projections
 
-Each plugin is one directory, living at `.meta/plugins/<id>/`. `PLUGIN.yaml` is the machine-readable body — the manifest. From the manifest, the kernel script mechanically projects into five places:
+Each plugin is one directory, living at `.owfa/plugins/<id>/`. `PLUGIN.yaml` is the machine-readable body — the manifest. From the manifest, the kernel script mechanically projects into five places:
 
 | Projection | Landing point | Source key | Who reads it |
 |---|---|---|---|
 | AGENTS injection region | `<!-- plugin:<id> v<x> -->` marker block | `inject` | The agent of every session; constitution-level disclosure |
 | check inspection block | the `check-inject` block inside the check command | `checks` | The check command; semantic items |
 | command usage block | the `cmd-inject` block inside each command | `usage`, in consumes order | Command execution sites; write-side rules |
-| registry plugin section | `.meta/protocol/registry.yaml` | `fields` | Commands consulting the field vocabulary before writing pages |
+| registry plugin section | `.owfa/protocol/registry.yaml` | `fields` | Commands consulting the field vocabulary before writing pages |
 | skill copy | `.agents/skills/<command>/` | command and connector masters | Deployment-side agents |
 
 The key property is idempotent rebuilding. Hand-editing inside marker blocks is forbidden — a rebuild overwrites; prose outside the blocks belongs to humans. There is no second source of truth: changing a rule means changing the manifest, after which the single command `all` converges everything. The whole class of documentation-drift problems is eliminated wholesale — projections and the body cannot disagree, because they are not two separate things.
@@ -38,7 +38,7 @@ Seven required manifest keys, illustrated with real values from bb-quiz v0.2:
 
 Four optional keys. `commands` declares the commands this plugin drives; `usage` is the write-side rule list; `checks` is the inspection rules; `bridge` is the bridge declaration, which only global pieces may hold.
 
-A fifth optional key `inject_tier` (full|member, default full) carries the **tier law** (issue #12 layer discipline): member exits the AGENTS injection region — exposure rides on the family root's roster line, the skill catalog, and on-demand reads of the manifest, and validate requires a member to reach a full-tier domain root through depends. The projected region carries a byte budget (15 KiB), keeping the A layer pointer-dense: pointers and red lines, never procedures or formats (contract in `protocol/experiments.md`).
+A fifth optional key `inject_tier` (full|member, default full) carries the **tier law** (issue #12 layer discipline): member exits the AGENTS injection region — exposure rides on the family root's roster line, the skill catalog, and on-demand reads of the manifest, and validate requires a member to reach a full-tier domain root through depends. The projected region carries a byte budget (16 KiB), keeping the A layer pointer-dense: pointers and red lines, never procedures or formats (contract in `protocol/experiments.md`). Each full-tier inject line also has a 256 B pointer-density guideline (issue #49) — over it, validate warns: keep the line to path + read/write trigger + the one easy-to-break invariant + a pointer to PLUGIN.md.
 
 attachment deserves a closer look. bb-quiz declares three entries:
 
@@ -52,7 +52,7 @@ The first is ownership; the latter two are borrows: the territory belongs to ano
 
 `depends` declares dependencies. validate checks two things: dependencies exist, and there are no cycles — cycles are detected via DFS.
 
-A domain piece is any plugin whose depends chain reaches `domain`. Those connecting to domain directly are domain bases — the five pieces vault, lark, project, email, bb; pieces inside a domain belong to it transitively, without connecting directly. bb-quiz does not connect to domain directly: it arrives via `bb-quiz → bb-track → bb-map → bb → domain`, and is thus a domain piece.
+A domain piece is any plugin whose depends chain reaches `domain`. Those connecting to domain directly are domain bases — the six pieces vault, lark, project, email, bb, bili; pieces inside a domain belong to it transitively, without connecting directly. bb-quiz does not connect to domain directly: it arrives via `bb-quiz → bb-track → bb-map → bb → domain`, and is thus a domain piece.
 
 Injection order = dependency topology plus alphabetical order within a batch: dependees are injected first; same-batch pieces sort by name. Look at the bb family's depends and the real order in the injection region:
 
@@ -69,8 +69,8 @@ This guarantees one thing: when a consumer-side plugin is injected, the disclosu
 
 Suppose you want to add one discipline to bb-quiz's write-side rules — here is what happens:
 
-1. Edit the `usage:` list in `.meta/plugins/bb-quiz/PLUGIN.yaml` and add a line. While at it, bump `version` and refresh `updated`; add a line to PLUGIN.md's Changelog
-2. Run `python .meta/scripts/wiki_plugin_kernel.py all`. In sequence: validate goes first — failure blocks, fix and rerun; if the inject line changed too, the AGENTS injection region is rebuilt; the cmd-inject blocks of the two command SKILL masters bb-quiz and bb-track are rebuilt — the usage appears in every command whose consumes includes bb-quiz; the registry plugin section is rebuilt; skill copies are synced
+1. Edit the `usage:` list in `.owfa/plugins/bb-quiz/PLUGIN.yaml` and add a line. While at it, bump `version` and refresh `updated`; add a line to PLUGIN.md's Changelog
+2. Run `python .owfa/scripts/owfa_kernel.py all`. In sequence: validate goes first — failure blocks, fix and rerun; if the inject line changed too, the AGENTS injection region is rebuilt; the cmd-inject blocks of the two command SKILL masters bb-quiz and bb-track are rebuilt — the usage appears in every command whose consumes includes bb-quiz; the registry plugin section is rebuilt; skill copies are synced
 3. Self-review the diff. Changes should land only in the manifest, the two command SKILL masters, and the `.agents/skills/` copies; if inject or fields changed, AGENTS and registry change as well. Any change beyond these is an anomaly
 4. Commit in the format `plugin: bb-quiz …`; one commit does one thing
 
@@ -105,7 +105,7 @@ Division of labor: the bridge holds validation and declaration — who may attac
 
 ## 6. The Derived Layer
 
-The kernel governs the framework area — plugins and projections; pipeline governs the data area — wiki derived pages. The commands are `python .meta/scripts/pipeline.py index / tags / hot / log / verify`:
+The kernel governs the mechanisms and projections — the plugin graph, manifest compliance, and everything derived from them (since the v0.4 split, plugin *content* travels with packages; the kernel's authority over it is mechanical, not editorial); pipeline governs the data area — wiki derived pages. The commands are `python .owfa/scripts/pipeline.py index / tags / hot / log / verify`:
 
 - **index / tags**: directory indexes and the tag reverse index. Pure-function rebuilds that only aggregate, never inventing structure; when an index list overflows the window, split the subdirectory into its own index — the cure is more subdirectories, not editing the index
 - **hot**: the recent-change hot cache. At most 25 entries, within 5 days, each entry under 200 characters; agents read it first on entering the vault
@@ -116,9 +116,9 @@ Derived pages and projections are two applications of one philosophy: projection
 
 ## 7. (Un)install Lifecycle
 
-The semantic flow of (un)installing goes through the plugin command, where the agent does the semantic part; the mechanical steps are this CLI. Since the split (2026-10-12) **packages are the install unit and this lifecycle is kernel-driven** — the authoritative accounts live in [packages.md](packages.md) (package model, the migrations algebra, the uninstall contract) and in `.meta/command/plugin/SKILL.md` (the wizard protocol). What follows is the historical per-plugin flow, retained for the record; the install steps still describe authoring a new plugin inside the framework repo.
+The semantic flow of (un)installing goes through the plugin command, where the agent does the semantic part; the mechanical steps are this CLI. Since the split (2026-10-12) **packages are the install unit and this lifecycle is kernel-driven** — the authoritative accounts live in [packages.md](packages.md) (package model, the migrations algebra, the uninstall contract) and in `.owfa/command/plugin/SKILL.md` (the wizard protocol). What follows is the historical per-plugin flow, retained for the record; the install steps still describe authoring a new plugin inside the framework repo.
 
-Install, five steps: prepare the three pieces under `.meta/plugins/<id>/`; `validate` — errors block; `all` — projections arrive; smoke test — `audit <id>`, plus a walk-through of the key flows per PLUGIN.md; log a plugin line.
+Install, five steps: prepare the three pieces under `.owfa/plugins/<id>/`; `validate` — errors block; `all` — projections arrive; smoke test — `audit <id>`, plus a walk-through of the key flows per PLUGIN.md; log a plugin line.
 
 Upgrade, three steps: edit the plugin, bump `version`, add a Changelog line; `all`; log line. Package-level upgrades (`kernel upgrade`) additionally stage semantic migrations — see packages.md.
 
@@ -165,7 +165,7 @@ A two-way split inside the domain. Process products live in the domain workspace
 
 ### Connectors
 
-Connectors live in `connectors/` — the domain's deployment-side CLI de-facto interface plus usage disclosure: `connectors/<name>/SKILL.md` lands as the `.agents/skills/` copy via kernel `deploy`. The difference from commands: commands are pure wiki operations, masters in `.meta/command/`; connectors are data-fetching channels to external systems — credentials stay on the local machine, never committed, never persisted to disk. Domain plugins declare territory and discipline; connectors provide the de-facto interface. Discipline and tooling are separate.
+Connectors live in `connectors/` — the domain's deployment-side CLI de-facto interface plus usage disclosure: `connectors/<name>/SKILL.md` lands as the `.agents/skills/` copy via kernel `deploy`. The difference from commands: commands are pure wiki operations, masters in `.owfa/command/`; connectors are data-fetching channels to external systems — credentials stay on the local machine, never committed, never persisted to disk. Domain plugins declare territory and discipline; connectors provide the de-facto interface. Discipline and tooling are separate.
 
 ## 9. Scenario Quick Reference
 

package/{.meta → .owfa}/docs/naming.md

@@ -11,7 +11,7 @@ Use the expansion exactly as written. Do not expand it as *One Wiki For All* or
 
 - 中文：**一个工作区，装下你所有的 agent。**
 - 一句话：OWFA gives every agent you use one workspace to re-enter — your assets, your wiki, your instructions — instead of re-introducing yourself every session.
-- Agent-facing: "This is an OWFA workspace: `vault/` holds real assets, `wiki/` holds the md world, `.meta/` + `.agents/skills/` are the framework body. Read AGENTS.md, then work from the indexes."
+- Agent-facing: "This is an OWFA workspace: `vault/` holds real assets, `wiki/` holds the md world, `.owfa/` + `.agents/skills/` are the framework body. Read AGENTS.md, then work from the indexes."
 
 ## What each word commits to
 
@@ -28,11 +28,11 @@ The name answers the project's actual starting pain: an agent that must be re-in
 | Layer | Name | Lives in | Job |
 |---|---|---|---|
 | Product | **OWFA** | README, npm page, docs | the brand |
-| Framework | **OWFA Core** (proposed) | `.meta/` + `.agents/skills/` | the body that is installed into a workspace |
+| Framework | **OWFA Core** (proposed) | `.owfa/` + `.agents/skills/` | the body that is installed into a workspace |
 | Installer | **OWFA CLI** | `bin/owfa.js` (npm package) | fetch the tree, `init`, `upgrade`, `doctor`, `add` |
-| Engine | **kernel** | `.meta/scripts/wiki_plugin_kernel.py` | validate / inject / registry / deploy / install mechanics |
-| Plugin tier | **core** | `.meta/plugins/core/` | the 21 framework plugins |
-| Extension | **package** | `.meta/plugins/domains/<pkg>/` | domain families (cuhksz, lark, email, bili, project…) |
+| Engine | **kernel** | `.owfa/scripts/owfa_kernel.py` | validate / inject / registry / deploy / install mechanics |
+| Plugin tier | **core** | the owfa-personal suite package (embedded at `payloads/personal/` in the channel) | the 21 former framework plugins |
+| Extension | **package** | `.owfa/plugins/domains/<pkg>/` | domain families (cuhksz, lark, email, bili, project…) |
 | Unit | **instance** | the user's directory | a deployed workspace |
 
 The call chain is the reason the names must stay distinct:
@@ -107,7 +107,7 @@ The order is not bureaucratic: npm support evaluates a project by its public hom
 - `package.json` — `"name": "owfa"` (target) with `"bin": { "owfa": "bin/owfa.js" }`; the fallback is the same file with `"name": "owfadev"` and bins `owfa` + `owfadev`
 - `README.md` — first line, the *Name* section, and the install note (never announce a command the registry does not serve)
 - `templates/AGENTS.template.md` — the identity paragraph a new instance starts from
-- `.meta/docs/distribution.md` — the channel's version invariant, fallback and release runbook
-- `scripts/verify-release.js` — the release gate (name/bin agreement, version rides `.meta/VERSION`, tag matches)
+- `.owfa/docs/distribution.md` — the channel's version invariant, fallback and release runbook
+- `scripts/verify-release.js` — the release gate (name/bin agreement, version rides `.owfa/VERSION`, tag matches)
 
 Update 2026-10-26: the repository itself is renamed to `owfa` (`owfadev/owfa`), and the public copy uses OWFA / OWFA Core; `vault-wiki` survives only in history and old links. Nothing in the kernel, plugin IDs, or registry depends on the brand.