vibevm

`org.vibevm.core/vibevm` is a package of kind `pack`. Its author wrote no abstract, so this page is what the package itself says: its manifest, its README and the specifications it carries.

The active epic is `campaigns/packages-2026-09/TZ-LIFECYCLE-EXTENSIONS-v0.1.md`; its granular authority for execution state is `campaigns/packages-2026-09/LIFECYCLE-EXTENSIONS-IMPLEMENTATION-LEDGER.md`. R3.4 is integrated, green and mirrored. R7.4 is now complete on exact tree `6f074e66`: `lifecycle_tasks` and strict hosted/no-spend `lifecycle_run` share bounded/pinned state, selected-node/run ownership, the outermost lifecycle lease, one lower application/trace command, real package-source composition and generated report semantics with the CLI. Agent rows park without constructing a provider; ordinary algorithmic rows remain complete without an LLM. The final panel executed all 54 dynamic gates and ended `self-check: all green` after the named wire-ratchet decision and a deterministic Windows mandatory-lock repair found by the boundary run. R7.5 P0 is landed at `41abb4db`, `cd9999cc`, `653a3c32` / `e8e67280`: exact evidence means declared input manifests plus independent artifact and run witnesses, never an arbitrary tree hash or a relabelled execution fingerprint. Requirements exposes four independent observations through a future `vibe-requirements` library and one CLI/MCP query, with specmap only an optional provider above lifecycle. No `unmet` synthesis, duplicate evidence command, coding agent or automatic loop exists. P1 is now landed at `6d843467`, `d3a9d59b` / `55937044`: canonical evidence fragments, additive strict lifecycle state/report, the metadata-only requirements root, relational validators and corpora are generated and green. P2 now extracts the read-only facts/query libraries, relation adapter and the lifecycle measurement/reconciliation runtime without changing that wire. Its first atom is landed at `1dac7531` / `65b0cba6`: `vibe-facts` now owns the canonical root scanner and four-state adoption join, while CLI facts reuses it. Architecture correction `1898382d` / `7a5b6837` separates hosted inclusive-chain resume from uninterrupted stale→recompute and pins the failure-carried evidence/member identity laws before A4/A5 code. A2/A3 are now landed through one-read witnesses `5fb4246d`, shared query `6a300cf8`, lock authority `a1095d8e` and relation adapter `ea031767`, with maps/trust refinements through `8a05d344`. P2/A4a is landed at `c3e51139` / `172c854d`: one prepared declared-input walk preserves the legacy fingerprint while independently producing the exact scoped input manifest. P2/A4b is landed at `5b01d71c`: the exact declaration sibling, stable two-read input observation and current-run state carriage are green. A4c0 is landed at `d24de1ff`: multi-gigabyte artifact content streams through one held no-follow handle without a byte cap. A4c1 is landed at `2cabc7a7`: produced/host-accepted artifact baselines, transient current re-observations, exact file/tree witnesses and hosted-output B3 are green. P2/A5 is landed at `594734a3` / `63c35c85`: the lifecycle library now produces one validated verification member, the complete phase epoch gates verify before its suffix, and CLI/MCP carry the same value through success and failure. P3 is landed at `1ff0ad64`, `e9301051`, `fdb1c465` / `46f9321b`: thin requirements surfaces, installed-skill discovery and the fake external PDSA reference are complete with no engine policy/back-edge or provider call. Boundary repairs `5eeb4283`, `8b871fb1`, `b7515063` closed the stale decoder/shape/sync ratchets. The final exact tree ran all 54 dynamic gates through `self-check: all green`; R7.5 is complete. R4.0 is landed at `6af1b86f` / `8531cf82`: the pure registry kernel owns one collector below lifecycle; compatibility is type-identical; dependency, syntax-complete ambient and public-root identity fences are green. Root accepted kernel 22, lifecycle 287/3 ignored, orchestrator 126 + doctests, strict clippy/check/conform and the acyclic metadata DAG. R4.1 is current: one lock-ordered workspace snapshot produces owner-scoped plans; each manifest activates its own lane, uninstall regeneration uses the in-memory post-removal future lock, per-unit lanes fingerprint their owner plan and node lanes always recompute transactionally. R4.1 has now landed package control carriage/projection at `52a59dcc` and crash-safe per-unit publication at `91142777` with governing law `ab68d145`; map `3883f15e`. T1 semantic config/compiler digest is landed at `b65f9958`; T3 typed dependency/host/path selector and subject-less enabled view are landed at `48d7dc75`. Central review forced four-digit TOML dates, composable host+path subjects, one-collection plans and canonical OR-set equality. Exact T2 construction authority/refusals/byte frames are frozen at `d5fcd92d`; T2 implementation is landed at `49e944f0` over borrowed hash validation `87ef2df6`. Root accepted exact frames/refusals after three mutation REDs; map `b768bcb8` is 6831/2318/2091 with zero suspects, gated orphans or unresolved host edges. T4 carriage is landed at `a252fcc8`: legacy constructors pin empty, nonempty is schedule/byte/error-inert and opaque retargeting forwards the whole plan. T5 is landed at `0eb46c82`: production catalog empty, one cfg-test identity catalog, exact bounded name/epoch/stage resolution and no schedule change. T6a is landed at `01f1522e`: typed callback errors cross every discovery recursion and the three legacy callers eliminate `Infallible` exhaustively. Map `ce3e62bf` is 6831/2344/2117 at zero suspects/orphans/unresolved. T6b is current.

**Project:** vibevm — a CLI software project manager for spec-driven AI-assisted development. **Binary:** `vibe`. **Source of truth:** [`VIBEVM-SPEC.md`](../../VIBEVM-SPEC.md) (project root). This is the entire implementation specification.

User-owned boot snippet. `vibe install`/`uninstall` never touches this file. Add any project-specific conventions that should be read at session boot.

**Decision:** The vibevm CLI and all supporting crates are written in Rust.

**Status:** accepted 2026-05-06; the framework and its codewords were extracted to the `operating-modes` flow 2026-07-14 (reached via the redbook dependency). This entry is now a thin pointer. **Related:** [`CLAUDE.md`](../../CLAUDE.md) (the four rules + session-end codeword), [PROP-000](PROP-000.xml) (foundation).

**Status:** accepted 2026-05-23 — owner-requested; in force. The audit-category checklist (§2) is **living** — it grows as new defect classes surface. **Related:** [PROP-000](PROP-000.xml) (the per-commit gate this audit complements), [`CLAUDE.md`](../../CLAUDE.md), [PROP-006](PROP-006-operating-modes.xml) (the `move fast and break things` posture an audit-driven fix-up often runs under), `vibe check` (the automated *subset* of what this audit does by hand), [`vibevm/vibespecs/WAL.xml`](../WAL.md) (Known issues — active findings), [`AUDIT.md`](../../AUDIT.md) (the inventory this process writes).

**Status:** accepted 2026-06-14 — owner-requested; in force. The target set (§2) is **living** — it grows as hosts are added. **Related:** [PROP-000 §7](PROP-000.xml#registry) (the package-registry split-host — a *different* concern, see §3), [`vibevm/vibespecs/boot/90-user.xml`](../boot/90-user.xml) (this machine's repository-access record), [`mirrors.toml`](../../mirrors.toml) (the target registry), `xtask/src/mirror.rs` (`cargo xtask mirror`), [`CLAUDE.md`](../../CLAUDE.md) (the attribution and force-push rules this model never crosses).

**Status: the §4 MVP is IMPLEMENTED** (specified 2026-06-16 in an owner-requested design session; verified against the tree 2026-07-25 by the spec-actualization campaign — `vibe agentic explain`, `vibe command`, the `[[skill]]` section and the `agentic_explain` MCP tool are all live, with 23 specmap `implements` and 8 `verifies` edges across eight sections). Everything heavier stays parked in §6 (far backlog). This is the spec home for vibevm's *product modes* — a cross-cutting concept, distinct from PROP-006's *session* postures (see §1.3).

**Status: IMPLEMENTED** (specified 2026-06-17 in an owner-requested design session and verified against the tree 2026-07-25 by the spec-actualization campaign — the vvm ships across the whole verb set, with dense specmap `implements` / `verifies` coverage); **revised to v2 the same day** after the owner found two architectural flaws in v1 (see §9): (a) making `$VIBEVM_HOME` the single source of truth forced a console reload on every switch/reinstall, and (b) replacing the running distribution locks its files (the `.exe`, and any future DLLs). v2 keeps the v1 command surface but reworks the internals: a live `current` pointer file + `current_exe()` ground truth (env demoted to advisory), the *whole distribution directory* as the immutable unit of install/switch, content- cheap diff-copy between instances, and a new `vibe vars` reconciliation command. **v3 landed 2026-09-11:** source builds still hold developer/managed checkouts by reference, while a binary release owns the exact clean source snapshot that produced it; `vibe` + essential `vibe-index` ship and activate together; mutable remote version labels create immutable local `#N` generations. §9 records the resulting decisions.

**Status: IMPLEMENTED** (proposed 2026-06-27, owner-directed; verified against the tree 2026-07-25 by the spec-actualization campaign — this very session boots on a vendored toolchain delivered exactly this way). Makes a vibe package able to ship runnable code, not only prompt content, so the discipline's verification tools (the conform checker, the specmap/specmark traceability engine) can live *inside* the discipline packages instead of being hardcoded in the vibevm workspace. A consumer who installs `stack:org.vibevm.ai-native/rust-ai-native-lang` then has the working checkers, not a prose description of them.

**Status:** IMPLEMENTED 2026-07-07 — owner-directed (the package-family rename). The three families in force ship under this convention: requiring one aggregator installs its whole family at a single resolved version set, and the served engines can never skew from the consumer's gates. Units typed at REQ grain. **Related:** [PROP-008 §2.2](../modules/vibe-registry/PROP-008-qualified-naming.xml) (a renamed package is a NEW identity — a family member is not an alias of the name it replaced), [PROP-027](../modules/vibe-mcp/PROP-027-mcp-packages.xml) (the `mcp` kind and the exact-pin law the `-mcp` member obeys), [PROP-024](PROP-024-code-bearing-packages.xml) (code-bearing packages — every `-lang` / `-mcp` member is one), [PROP-009](../modules/vibe-workspace/PROP-009-loading-model.xml) (boot loading — the aggregator carries no snippet; members' snippets reach `INDEX.md` through the transitive BFS closure of `[requires]`).

**Status:** accepted 2026-07-12 (owner-ratified). **Builds on:** [`spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-008#group`](../modules/vibe-registry/PROP-008-qualified-naming.xml#group) (the `group` field) and the **addressable-specs** flow, whose `#modules` unit defines the fully-qualified module authority and the joiner-never-`.` rule this PROP applies: `spec://org.vibevm.world/addressable-specs/flows/addressable-specs/ADDRESSABLE-SPECS-PROTOCOL#modules`.

**Status.** Design proposal v0.1 — not implementation-locked. Drafted for review; every decision below is open to challenge until ratified. This PROP establishes a *direction and a model*; it schedules no implementation of its own — its first consumer is the SPECMAP Unit-Mobility Plan (archived: `legacy-spec/terraforms/SPECMAP-UNIT-MOBILITY-PLAN-v0.1.md`), which builds the first operation.

**Status.** Design proposal v0.1 — not implementation-locked. Drafted for review; every decision below is open to challenge until ratified. This PROP names a *model and a direction*; it schedules no implementation of its own. It is the umbrella under which [PROP-014](spec://org.vibevm.ai-native/core-ai-native/mechanisms/PROP-014#index) (traceability) and [PROP-031](spec://org.vibevm.core/vibevm/common/PROP-031#root) (refactoring) become **consumers of one model**, and it fixes the one foundational extension both need: **code as a first-class addressable node.**

**Status.** Design proposal v0.1 — not implementation-locked. Drafted for review; open to challenge until ratified. It schedules no implementation of its own; it is the *packaging, discovery, and dispatch* layer over the operations of [PROP-031](spec://org.vibevm.core/vibevm/common/PROP-031#root) and the discovery surface of [PROP-032](spec://org.vibevm.core/vibevm/common/PROP-032#agent-first).

**What this document is.** The standing ideology for every durable data format this project reads or writes — package format, manifests, catalog, lockfile, configs, CLI JSON, MCP tool schemas. It is written to be handed to an AI agent as context: it states the laws, the machinery they require, the policy for each format, and the machine gates that make the laws enforceable against authors weaker than their reviewers. The first build that implemented it closed 2026-08-17, and what it decided now lives where it binds — the catalog's own contract [PROP-005](../modules/vibe-index/PROP-005-package-index.xml) and the docblocks of the generator layer under `xtask/src/codegen/`. The plan that carried that build was disposable by construction; this document is the contract.

The owner's mandate, verbatim (2026-08-21): «XML как источник спецификаций (вместо Markdown). Везде где пользователь использует Markdown можно использовать XML. … Можно смешивать XML и Markdown в одном проекте. При материализации, XML превращается либо в Markdown (с минимальной деградацией качества — использовать вложенные секции/заголовки, все что невыразимо в такой форме — не поддерживается), либо в XML рядом с Markdown, либо в XML. … Формат материализации — настройка пользователя. … Лоадеры должны корректно обрабатывать все три вида материализации: XML, Markdown, Mixed (XML + Markdown). … XML как целевой формат материализации должен быть целевым для разных видов исходников. Всё, даже Markdown, при материализации превращается в XML. … Markdown материализация все ещё должна поддерживаться, это важно. … мы целимся в то, что Mixed Input (XML + Markdown) должен нормально транслироваться в XML (не в mixed!), и это станет в будущем основным форматом материализации». Acceptance named in the same mandate: a small test project importing `org.vibevm.world/redbook`, exercised in all three materialisation modes (XML+MD→XML, XML+MD→Markdown, XML+MD→Mixed), all well-tested — «это большое изменение».

**The owner's design (2026-08-22, chat, near-verbatim):** «сделать в корне отдельную директорию vibefacts в структурном и grep-совместимом формате (toml), в которой собираем данные о том, как реализован или не реализован факт. Внутри реестра — признак: факт из пакета или из spec; каждый факт хранится вместе с адресом своего пакета-источника. Утилита `vibe facts` даёт CRUD, search, переводы статусов. При полной ре-материализации статусы мерджатся в vibedeps в момент ре-материализации. Для спецификаций внутри spec статус всегда синхронизирован. Когда статус пакетного факта меняется в ходе кодирования — точечно меняем его в vibedeps, а STATIC не трогаем: новое значение накатывается динамическим лоадером. Статус опционален: нет статуса — неопределённое состояние, типовое для внешних пакетов. При импорте пакета авторские статусы игнорируются. При удалении пакета статусы не исчезают; `vibe uninstall` спрашивает, чистить или хранить; `vibe facts clean` удаляет ничейные факты исчезнувших пакетов.» Landed across W1–W3 (commits 700a91f1, 7548144f + the W3 landing): the registry, the full `vibe facts` surface, derivation merge with point re-derivation, and the lifecycle all live; the cache-stable-STATIC strong form remains the follow-up wave.

**The owner's declaration (2026-08-22, chat, near-verbatim): «Я хочу, чтобы идея эффективной токеномики была центральной для всего VibeVM. Мы манипулируем чудовищно огромным объёмом текста промтов — и мы должны сделать всё, чтобы пользователь платил за них меньше.»** VibeVM's whole subject matter is prompt text at scale: boot lanes, spec corpora, materialised dependencies, worker packets, campaign weaves. Every one of those is tokens the user pays for — so their cost is not an operational detail but a first-class design axis of the system.

**Agents creating fresh VibeVM projects created `vibevm/vibespecs/WAL.xml` unasked (owner observation, 2026-08-23).** The machinery is clean — `vibe init` scaffolds no WAL, and both WAL checks return silently when the file is absent («a project convention, not part of the package manager's contract»). The cause is the PACKAGE chain: *(a)* redbook hard-pulls `flow:wal`, whose snippet speaks in unconditional imperatives («canonical… read before anything else»); *(b)* four UNRELATED snippets presuppose the WAL in passing — sync-from-code's «record in the WAL» imperative, health-audit's and git-atomic-commits' «the WAL» asides — so even without redbook the compiled STATIC of a small discipline set tells an agent a WAL exists. An obedient agent reads its static lane and mints the file. Not every external project wants a centralised WAL (a multi-developer team may run many WALs, or none); the presupposition takes that choice away.

**Status: BUILT — 2026-08-23.** The full build landed the same day the design closed: W1 engine + manifest vocabulary, W2 resolution/lock on `E(R)` (schema v6, provenance), W3 lane goldens, W4 gate softening, W5 observability (`vibe why`/`vibe friends`/closure diff/tree annotations/hygiene cell), W6 power-instrument proofs, W7 deliberate narrowing (fractality group; host lanes byte-identical), W8 close-out. Build record: [`vibevm/vibespecs/terraforms/VISIBILITY-BUILD-PLAN-v0.1.xml`](../terraforms/VISIBILITY-BUILD-PLAN-v0.1.xml); measurements: [`vibevm/vibespecs/research/dependency-visibility-2026-08/04-measurements.xml`](../research/dependency-visibility-2026-08/04-measurements.xml); leftovers: BACKLOG B-102..B-105. All ten forks stand ruled (F1–F4, F6, F10 as drafted; F5 → no-legacy; F7 → warnings; F8 → designed+ratified; F9 → official, quiet, any-node); the only unruled sketch is ##CONCEPT-GATE-DIRECTION (B-105, non-blocking). Ratification history in §9/§10 stands as authored.

The owner's mandate, verbatim (2026-08-23, chat, three clauses in one sitting): «я хочу все наши спецификации в проекте (всё внутри spec и packages, итп) сконвертировать в XML как язык исходников. … Это гораздо более продвинутый формат для нас, потому что нейросеть понимает сложные спецификации в нем проще.» — «у тебя уже где-то должна быть система бесшовного переписывания форматов спецификаций. Я предлагаю сделать команду "vibe refactor" которая будет зонтиком для разных команд рефакторинга. Дальше сделать команду vibe refactor convert-source для конвертирования форматов исходников между Markdown и XML. Если в ходе конвертирования будут происходить какие-то деструктивные операции - выдается ошибка с описанием что потеряется и потребуется подтверждение (либо интерактивное, либо флаг --force снимает проверку). Проверку стоит делать честно, обратным переконвертированием.» — «и дальше уже ты просто применишь этот инструмент к своим же файлам.» The seamless-rewrite system the owner names already exists: it is PROP-045's pivot (`vibe-specdoc`, parse → IR → emit, all four edges); this PROP adds the user-facing verb over AUTHORED sources and the honesty contract that verb must carry.

The owner's mandate, verbatim (2026-08-24): «Я обнаружил проблему: массовые клеши с реально существующими проектами, имеющими директорию spec или packages в корне. Кроме того, динамическим лоадерам сложно искать по таким директориям. В качестве решения, я хочу сделать глобальное переименование корневых директорий в проектах/пакетах. В корне создается директория vibevm. Внутрь неё переезжают директории: Директория spec переезжает с именем vibespecs. Директория packages переезжает с именем vibepacks. Директория vibedeps переезжает c исходным именем. Директория vibefacts переезжает с исходным именем. В мире не существует никаких легаси проектов с директорией vibevm в корне, а по именам типа "vibespecs" агентам проще делать grep и find, чем по spec (который приносит много мусора). Совершенно все спецификации, которые содержат эти имена (spec, packages, vibedeps, vibefacts) - должны быть проверены и переписаны соответствующе (spec -> vibevm/vibespecs). Конечно же, совершенно весь код. Сам проект vibevm и все его пакеты в packages должны быть переделаны под новую раскладку директорий. Результаты проверены/протестированы и измерены на предмет того, что ничего не сломалось.»

**Related:** [PROP-009](../modules/vibe-workspace/PROP-009-loading-model.xml) (install orchestration — becomes phase 2 of the default lifecycle), [PROP-011](../modules/vibe-workspace/PROP-011-incremental-install.xml) (skip-when-fresh — §9 revises its materialise step from slot-wipe to per-file diff), [PROP-020](../modules/vibe-workspace/PROP-020-install-hooks.xml) (the two install hooks whose `##REJ-GENERAL-LIFECYCLE` deferral this document un-defers; its trust gate is adopted whole), [PROP-022](../modules/vibe-workspace/PROP-022-materialization-modes.xml) (slot reset semantics — §9 refines them), [PROP-024](PROP-024-code-bearing-packages.xml) (code in packages; §8 amends its §2.3 build-output home), [PROP-025 §3–§4](../modules/vibe-workspace/PROP-025-binary-delivery.xml#dispatch) (`[[binary]]` build-in-slot — the precedent §8 generalises), [PROP-035](../modules/vibe-workspace/PROP-035-spec-compiler.xml) (the compile pipeline §7 attaches extension points to), [PROP-045](PROP-045-xml-spec-sources.xml) (transformed-slot identity is absorbed into the per-file slot record), [PROP-053](../modules/vibe-workspace/PROP-053-clean-verb.xml) (verb chaining — §4.4 is the "own semantics ruling" its `##CHAIN-ONLY-INSTALL` demanded before any wider grammar).

**Status: owner-ruled operating contract for the central OpenAI ChatGPT/Codex coordinator while the lifecycle/extensions campaign is active.** It consolidates worker routing, launcher use and test-panel cadence. It does not change VibeVM product semantics, Claude Code behavior, or a delegated packet.

This PROP defines and implements the deterministic operation that turns a VibeVM-managed consumer into a self-contained native project with no selected VibeVM repository residue. It freezes the contract, plan, typed rewrite, verification, export, in-place transaction, recovery and evidence semantics for epoch-1 Windows execution; portable planning remains available and other mutating hosts fail closed.

`spec://org.vibevm.core/vibevm/common/PROP-057`

`spec://org.vibevm.core/vibevm/common/PROP-058`

**Genre:** design (lore) — non-binding rationale and architecture. The normative contract is **Spec 1 = PROP-039** (`spec://org.vibevm.core/vibevm/modules/vibe-actions/PROP-039`, written and implemented — the `vibe-actions` crate ships); this document explains *why* the system is shaped as it is and *how* the pieces fit. It is derived, behind the clean-room firewall, from the study [`action-systems-vscode-idea.md`](../../legacy-spec/research/action-systems-vscode-idea.md) (the design obligations DO1–DO18 and roadmap deltas Δ1–Δ16 cited throughout) and governed by the mandate in [`ACTION-SYSTEM-RESEARCH-PLAN`](../../legacy-spec/research/ACTION-SYSTEM-RESEARCH-PLAN-v0.1.md#mandate). When this lore and the contract disagree, **the contract wins** and this file is corrected (spec-genres).

**What this document is.** The owner reframed the schema-evolution question on 2026-08-09 — the studied ecosystems are built for stability; this system lives in permanent break — and proposed convening a separate Fable instance for an independent verdict. This is that verdict, recorded as design lore: it explains *why* PROP-044 says what it says, with the rejected alternatives. The contract it explains is [`vibevm/vibespecs/common/PROP-044-change-native-formats.xml`](../common/PROP-044-change-native-formats.xml); the research it stands on is [`vibevm/vibespecs/research/schema-evolution-2026-08/`](../research/schema-evolution-2026-08/). Nothing here is normative — where this text and PROP-044 disagree, PROP-044 wins and this file gets corrected.

**Scope.** [`BACKLOG.md`](../../BACKLOG.md) `##B019-B` asks that a command be an entity of the map rather than only a function, so that *«what implements `vibe install`»* is answerable directly. The owner's ruling of 2026-08-01 is to build it and to build it **algorithmically, without an LLM**. This design covers that part and nothing else: part (а), the code fingerprint, is built and live on 916 of 932 items; part (в), the error-variant node, carries an unresolved systems-boundary question the owner asked to be answered **before** implementation, and it is not in here.

**Companion to:** BACKLOG.md B-011 (closed by `c9cdf39d`) (the commissioning entry — the owner's directions verbatim), [PROP-035](../modules/vibe-workspace/PROP-035-spec-compiler.xml) (the spec compiler — the contract this design extends), [PROP-009 §2.3](../modules/vibe-workspace/PROP-009-loading-model.xml#artifacts) (the boot artifacts whose `STATIC.md` contract changes), and [`loading-and-boot-model.xml`](loading-and-boot-model.xml) (the loading model's original design record).

**Explains:** [PROP-058](../common/PROP-058-documentation-maintenance.xml).

**Explains:** [PROP-057](../common/PROP-057-documentation-packages-and-site.xml) — the documentation packages and site contract; the thirty decision records D-01…D-30 below are its rationale, and PROP-057 wins where they disagree (the spec-genres precedence law). Written in Russian for the owner; the norm it explains is English.

**Companion to:** BACKLOG.md B-029 (closed by `1ef63a37`) (neutral/per-language gate key + the config-surface enrichment, ruling 2.1 recorded in the row), B-034 (closed by `f882cd46`) (gated-or-exempt for Go/TS), B-039 (closed by `1f048058`) (mount R-001 on the TS gate); the fork it carries is [`TOOLING-MAP.md` §5 №2](../../TOOLING-MAP.md#forks). Evidence: [`e8-r1-config-census.md`](../../campaigns/packages-2026-09/harvest/e8-r1-config-census.md) (the config surface), [`e8-r2-gate-units-census.md`](../../campaigns/packages-2026-09/harvest/e8-r2-gate-units-census.md) (units, FlagSites, rosters). Non-normative; the PROPs and the backlog rulings win.

**Companion to:** BACKLOG.md B-031 (closed by `1ef63a37`) (the commissioning entry — the owner's 2026-08-02 direction verbatim), [PROP-029 §4](../common/PROP-029-fully-qualified-addresses.xml) (`##SCOPE-HOST` — the one contract line this design retires), [PROP-035 §6](../modules/vibe-workspace/PROP-035-spec-compiler.xml) (the unified grammar and router the host joins), BACKLOG.md B-028 (closed by `93d92ec9`) (the adjacent flow-grammar ruling, deliberately not folded in), and the census this design stands on: [`campaigns/packages-2026-09/harvest/e5-b031-evidence.md`](../../campaigns/packages-2026-09/harvest/e5-b031-evidence.md).

**Companion to:** BACKLOG.md B-006 (closed by `9f79acf1`) (the commissioning entry), [PROP-038](../modules/vibe-workspace/PROP-038-hybrid-boot-linking.xml) (the hybrid linker whose two write paths collide here), [PROP-009 §2.3](../modules/vibe-workspace/PROP-009-loading-model.xml#artifacts) (the lane contract the fix touches), [PROP-035 §8](../modules/vibe-workspace/PROP-035-spec-compiler.xml#pipeline) (the qualify phase the rider refines), and [`deterministic-loading-aliasing.xml`](deterministic-loading-aliasing.xml) (B-011 — whose qualification made this duplicate mechanically visible instead of silent).

**Companion to:** [PROP-009](../modules/vibe-workspace/PROP-009-loading-model.xml) (the loading model — **shipped**, M1.18 phases 1–7, 2026-05-22).

**Non-normative** (`vibevm/vibespecs/design/` genre). The contract stays in PROP-014 and in the discipline packages' own specs; this document records why волна В's format change is shaped the way it is, and what the workers were told to elaborate. The owner's rulings behind it were filed as backlog entries `B-016`, [`{#b-017}`](../../BACKLOG.md#b-017) and `B-019`, and they win on divergence — but two of the three have since been drained and their rows are gone (B-016 built whole; B-019 built in its fingerprint third), so only B-017 is still a live link. A row that is closed leaves its ruling in the commit that closed it, not in an address.

**Scope.** The owner ruled that map search is built at **two** levels. The first — three independent filters joined by AND under a hard ceiling — shipped on 2026-08-06 and is a **permanent** level, not a first draft. [`BACKLOG.md`](../../BACKLOG.md) `##B018-PARTS` names the second: the filters *plus graph traversal* — depth, and «has no edge of this kind», the one that answers *«which rules does nothing verify»*. This document designs that level and nothing else.

**Companion to:** BACKLOG.md B-056 (closed by `77224fcf`) (the four rulings and the honest cost), B-055 (closed by `bc88e530`) (today's silence on a second directive). Contract: [PROP-035 `#source`](../modules/vibe-workspace/PROP-035-spec-compiler.xml#source) and its `##NO-DEADLOCK-INVARIANT` (§9). This document is lore — it records why the build is shaped this way, and the PROPs win wherever they disagree.

**Non-normative** (`vibevm/vibespecs/design/` genre). The contract stays in the PROPs and in the discipline packages' own specs; this document records why batch 3 is shaped the way it is, and what the workers were told to elaborate. The owner's rulings behind it were filed as backlog entries {#b-036} (closed by `1f048058`), `B-037` and {#b-038} (closed by `1f048058`), and they win on divergence — B-037's row has since been drained (its TypeScript half built, its Rust half carried by [`{#b-050}`](../../BACKLOG.md#b-050)), so its ruling lives in the commit that closed it rather than at an address.

**Companion to:** BACKLOG.md B-033 (closed by `f882cd46`) (the dedicated Go seam-error rule + its message half + the TS twin), B-030 (closed by `1ef63a37`) (conformance-assertion presence — build Go, survey Rust/TS), B-049 (closed by `e4314e83`) (`[rust] floor_disable`); the fork it discharges is [`TOOLING-MAP.md` §5 №9](../../TOOLING-MAP.md#forks) (the parity-principle home, taken). Evidence, measured before any build: [`e11-r1-seam-errors-census.md`](../../campaigns/packages-2026-09/harvest/e11-r1-seam-errors-census.md) (the seam-error paradigm, two halves) and [`e11-r2-assertions-census.md`](../../campaigns/packages-2026-09/harvest/e11-r2-assertions-census.md) (the assertion idiom, Rust/TS survey). The prior batch's design is [`gate-parity-config.xml`](gate-parity-config.xml) — this one builds on its symmetric per-language surface. Non-normative; the PROPs and the backlog rulings win.

**Status:** DESIGN — provisional (PROP-035 §13). These instructions are authored but **not yet wired into any live boot**: migration is demo-corpus-first, `org.vibevm.world` next, vibevm's own boot last (PROP-035 §15). This document is the reference text; a package that adopts the spec-compiler format will load it (or its successor) first.

_Status: **FULL** (2026-07-16, TREE-TUI-PLAN v0.2 Phase 1). This is **lore** — the aesthetics, the why, the tables the eye reads. The **normative** surface (the REQs the code is traceable to) lives in [PROP-037 §2.2](../modules/vibe-cli/PROP-037-tree-tui.xml#theme); this document expands it. When the two disagree, PROP-037 wins._

**Companion to:** BACKLOG.md B-040 (closed by `1f048058`) (the owner's ruling and the census pointer), the census itself ([`harvest/g1-b040-seams-census.md`](../../campaigns/packages-2026-09/harvest/g1-b040-seams-census.md)), and the guide anchor the finding hangs on — `GUIDE-AI-NATIVE-RUST.xml` `##SCAFFOLD-B-TYPED-BUILDERS`. This document is lore: it records why the refactor is shaped this way, and every contract it touches wins wherever they disagree.

**Companion to:** [PROP-007](../modules/vibe-workspace/PROP-007-workspace.xml) (workspace), [PROP-008](../modules/vibe-registry/PROP-008-qualified-naming.xml) (qualified naming).

What `org.vibevm.core/vibevm@1.0.0` declares about itself. Everything on this page is the package's own manifest, read and shown — nothing here is an opinion about the package.

**Purpose.** `vibe tree` (PROP-036) is an interactive terminal UI: it renders the resolved package tree, lets a human navigate/fold it, opens a detail modal, and cycles ordering + display modes. The automated suite proves the *model* (the engine + `--json` validate against the schema, and the flat renderer has unit tests), but it cannot drive a real terminal and confirm that the tree *renders and reads right* — the box-drawing aligns, the selection highlights, the keys respond, the modal overlays cleanly, and colour works on this terminal. That is what a human proves here. `vibe tree` is **read-only** (it mutates nothing — no per-user state, no project files), so this test needs no state isolation; it runs against the vibevm repo itself, which is a rich real tree.

**Purpose.** `vibe tree` is now a full TUI application (PROP-037, TREE-TUI-PLAN v0.2): a formal visual language (five palettes, glyph vocabulary, rendering tiers), a reusable `ui::` component library, the tree filter/shape pipeline, trees in every mode, a keymap-driven action dispatch, a detail card, settings persistence, and a copy system. The automated suite (241 vibe-cli tests, `self-check` all green) proves the *model + the rendering fns*; it cannot drive a real terminal and confirm the TUI *looks and reads right* — that the Unicode box-drawing aligns, the palette is beautiful and switchable, the windows float, the card wraps, the modals cascade at depth 2. That is what a human signs off here.

**Purpose.** `vibe prefs ui` is the TUI surface over `vibe-settings` (PROP-040): a page tree, per-type edit forms, provenance, validation feedback, lint, and search — built on the `vibe tree` TUI's component library + theme (Шаг 3) and driven by `vibe.prefs` actions. The automated suite (347 vibe-cli tests, `self-check` all green) proves the model + the rendering fns; it cannot drive a real terminal and confirm the surface *reads right* — the page tree aligns, the form fields edit, the provenance shows the winning layer, the validation warnings land inline. That is what a human signs off here.

**Status: IMPLEMENTED** (requirements authored 2026-07-15, owner-commissioned; verified against the tree 2026-07-25 by the spec-actualization campaign). The **contract** for the crate `vibe-actions` — a frontend-agnostic, addressable, programmatically-drivable behaviour layer — which ships with its `address` / `action` / `context` / `invoke` / `keymap` / `i18n` / `gate` / `aiui` modules and runs the Spec-2 `vibe tree` TUI as its first consumer.

**Status: IMPLEMENTED** (requirements authored 2026-07-15 at the owner's request; the PACKAGE-TREE-PLAN executed against them, verified against the tree 2026-07-25 by the spec-actualization campaign — `vibe tree --json` validates against the shipped `package-tree.schema.v1.json` per its own `--help`, and `-t` is live). Governs the `vibe tree` command in `crates/vibe-cli`. Written in the post-rename link vocabulary (PROP-035): two link types, `static` and `dynamic`.

**Status: IMPLEMENTED** (requirements authored 2026-07-15, owner-commissioned; TREE-TUI-PLAN v0.2 executed against them, verified against the tree 2026-07-25 by the spec-actualization campaign — the visual language matches byte for byte and the shipped F-key map is the one this Spec 2 text defines); **revised 2026-07-15 (Spec 2)** onto the action system: the TUI is a `Surface` on `vibe-actions` (PROP-039), every command is an addressed action (§13), Search Everywhere (§7.3) is promoted from a stub to a shipped feature, and the i18n mechanism (§1.6) is now real. Extends [PROP-036 §2.11](PROP-036-package-tree.xml#tui) (the analyzer's TUI sketch) into a full application contract.

**Status:** ACTIVE (v0.1, 2026-07-16). **Module:** `vibe-cli`. **Related:** PROP-037 (the `vibe tree` TUI it observes), PROP-039 §11.3 (the model plane / `vibe-actions::aiui`), PROP-036 (the tree model). The terminal products (vibeterm, vibeframe) and their contracts now live in the `vibevm-term` products repo — this PROP cites them as cross-repo contracts (`spec://vibeterm/*`, `spec://term-common/*`); the `vibe aiui` / `vibe term` CLI surface itself stays on the host.

`spec://org.vibevm.core/vibevm/modules/vibe-facts/PROP-043`

**Milestone:** retrofits into M2.10 (`vibe search`) and M1.10 (`vibe outdated`) from `ROADMAP.md`. Slices land independently; index is opt-in everywhere.

**Milestone:** M1.7 ([`ROADMAP.md`](../../../ROADMAP.md)). The server slice shipped first; the agent-integration surface (`vibe mcp install` / `status` / `upgrade` / `uninstall`) followed.

**Status: proposed 2026-07-07 with AGENTIC-TCG-TS-PLAN v0.1 (owner- accepted the same day, with the §3 portability amendment); implemented by its Phase 4. History: 2026-07-07 (same day, AGENTIC-TCG-RUST-PLAN v0.1) — the §2 promise cashed: `language: "rust"` lands as an enum value dispatching to the rust stack's `rust-ai-native-tcg` relay; no new tools, no schema shape change. **Superseded in topology** (MCP-SOVEREIGNTY wave 6): the standalone `vibe-tcg` crate was deleted whole and the tool grammar below stays **normative**, now served by the per-family MCP servers of [PROP-027](PROP-027-mcp-packages.xml).** Module: `vibe-mcp` (adapter) + `vibe-workspace` (binary resolution); the `vibe-tcg` crate this contract was written against no longer exists.

**Milestone:** M1.26 candidate («MCP sovereignty» — [MCP-SOVEREIGNTY-PLAN-v0.1](../../../legacy-spec/terraforms/MCP-SOVEREIGNTY-PLAN-v0.1.md)).

Маркер — XML-тег в тексте. Читается как «стадия/состояние [+ что делать]»:

This document lived here as «Progress Control: inline status markup and the `vibe progress` tool» until the owner's facts/progress boundary ruling (2026-08-22) split it in two, every unit keeping its anchor: the **markup grammar, placement, parsing and genre semantics** moved verbatim to `spec://org.vibevm.core/vibevm/modules/vibe-facts/PROP-043` (file `vibevm/vibespecs/modules/vibe-facts/PROP-043-facts-markup.xml`); the **tool, config, evidence providers, campaign data contracts and maintenance discipline** moved verbatim to `spec://org.vibevm.core/vibevm/modules/vibe-progress/PROP-047` (file `PROP-047-progress-campaigns.xml` beside this tombstone). Rewrite any citation of the old path to whichever home carries the cited anchor.

**The owner's boundary ruling (2026-08-22, chat, near-verbatim):** «факты являются чем-то, поверх чего можно построить совершенно разные процессы рефакторингов, и не факт, что наша текущая кампания и способ вообще делать кампании — самый лучший. Всё, что касается самого синтаксиса, IR, операций над фактами — в модуль facts (это будет использовать широкая общественность); в progress оставить наши инструменты для рефакторингов vibevm и потихоньку доделывать, чтобы когда-то они стали достаточно хороши, чтобы показать миру.» This document is that progress layer: the tool, its config, evidence providers, campaign data contracts, and the maintenance discipline. The grammar it operates on is PROP-043 (`spec://org.vibevm.core/vibevm/modules/vibe-facts/PROP-043`), and the dependency points strictly upward: progress knows facts; facts never knows progress.

**Status:** queued | in-progress | review | done | returned

**Status:** queued | in-progress | review | done | returned

**Milestone:** M1.1 ([`ROADMAP.md`](../../../ROADMAP.md#m11--git-backed-registry)).

**Milestone:** M1.1-revision ([`ROADMAP.md`](../../../ROADMAP.md#m11-revision--decentralized-per-package-registry-active-started-2026-04-24)). Phase B lands in M1.6.

**Milestone:** `M1.18` + `M1.19` ([`ROADMAP.md`](../../../ROADMAP.md)) — **shipped**, implementation-locked. (The line read "design proposal … not implementation-locked" until 2026-07-25; it had never been reconciled with the IMPLEMENTED status one line below.)

**Milestone:** design proposal; implementation follows [PROP-008](PROP-008-qualified-naming.xml) (qualified naming, `M1.19`), on which the identity-keyed cache depends — provisionally `M1.20` (owner to confirm in [`ROADMAP.md`](../../../ROADMAP.md)). Not implementation-locked.

**Status: IMPLEMENTED** (specified 2026-06-24 in an owner-requested design session; verified against the tree 2026-07-25 by the spec-actualization campaign). The git backend clones with `--recurse-submodules` and runs `submodule update --init --recursive`, snapshot embedding lands in `git_package_registry/fetch.rs`, the in-place native form rides the PROP-022 machinery, and `resolved_commit` carries lockfile reproducibility. One of four orthogonal specs from the bridge-packages design (siblings: [PROP-020](../vibe-workspace/PROP-020-install-hooks.xml) install hooks, [PROP-022](../vibe-workspace/PROP-022-materialization-modes.xml) materialization modes, [PROP-023](PROP-023-bridge-packages.xml) bridge packages). Submodules serve any package that wants to embed another repository — not only bridges.

**Status: IMPLEMENTED** (specified 2026-06-24 in an owner-requested design session; verified against the tree 2026-07-25 by the spec-actualization campaign). The umbrella's own addition — `[package].bridge`, defaulting to false — parses in `vibe-core` with a doctest, and the mechanisms it composes all ship: [PROP-020](../vibe-workspace/PROP-020-install-hooks.xml) install hooks, [PROP-021](PROP-021-submodule-sources.xml) submodule sources, [PROP-022](../vibe-workspace/PROP-022-materialization-modes.xml) materialization modes, plus [PROP-021 §2.2](PROP-021-submodule-sources.xml#source-abstraction) dependency-declared embedded sources — so every bridge class recorded here has live machinery. The umbrella adds a flag and packaging/provenance conventions; each underlying mechanism remains independently usable.

`spec://org.vibevm.core/vibevm/modules/vibe-registry/PROP-030`

**Status. IMPLEMENTED as vocabulary; the engine question is settled elsewhere.** The dependency vocabulary of §2.4–§2.10 — features, subskills, conditional deps, i18n, the checks and the lockfile records — ships in `vibe-core` / `vibe-install` / `vibe-cli` (verified against the tree 2026-07-25 by the spec-actualization campaign). The **solver engine** sections (§2.1–§2.2 and the default-flip clauses that follow from them) are superseded by [PROP-017](PROP-017-resolvo-resolver.xml): the production default is **resolvo**, never the `sat` this document planned. Companion to [PROP-000](../../common/PROP-000.xml) (project foundation), [PROP-002](../vibe-registry/PROP-002-decentralized-registry.xml) (registry model). Supersedes the depsolver paragraphs of PROP-002 §2.8 (which left the solver upgrade path as a one-line "resolvo or libsolv slot reserved"); does not touch PROP-002's identity or registry decisions.

**Status.** Design proposal accepted (owner decision, 2026-06-14) and **the port is COMPLETE** — `ResolvoDepSolver` is the shipped production default (`crates/vibe-cli/src/registry.rs:117`, `--solver` defaults to `resolvo`), as §6 records. Only the far-backlog reverse weak-deps remain. Companion to [PROP-003](PROP-003-dep-evolution.xml) (dependency-model evolution) and [PROP-002](../vibe-registry/PROP-002-decentralized-registry.xml) (registry / depsolver seam).

**Status: IMPLEMENTED** (requirements authored 2026-07-16, owner-commissioned; verified against the tree 2026-07-25 by the spec-actualization campaign — `crates/vibe-settings` ships and `vibe prefs` serves the §8 surface, its `--help` citing "PROP-040 §8" verbatim). The **contract** for the crate `vibe-settings`: a three-level, schema-first, introspectable store for **application/user preferences** (Vibe Tree UI — palettes, glyphs, rendering tier, display mode, sort, tree shape, fold state, future fonts/sizes; future vibe-app prefs) — programmatically drivable, **AIUI-ready** (surface not built, §14).

**Status: IMPLEMENTED** (requirements authored 2026-07-16, owner-commissioned; the SETTINGS-UI-PLAN executed against them, verified against the tree 2026-07-25 by the spec-actualization campaign — `commands/prefs/tui/**` ships the form lifecycle, the provenance edit and the controls, and PROP-037's F4 opens it by name). The **contract** for the TUI surface that lets a user **view and edit** the application/user preferences of [PROP-040](PROP-040-settings.xml): a settings tree, per-type edit forms, a provenance ("where does this value come from?") view, validation feedback, and search — built on the `vibe tree` TUI (PROP-037) and drivable headless (AIUI-ready).

**Milestone:** `M1.17` ([`ROADMAP.md`](../../../ROADMAP.md)) — **shipped**, implementation-locked.

**Milestone:** `M1.18` ([`ROADMAP.md`](../../../ROADMAP.md)) — **shipped**, implementation-locked.

**Milestone:** M1.21 ([`ROADMAP.md`](../../../ROADMAP.md)) — **shipped 2026-05-22.** Refines the install machinery of [PROP-009](PROP-009-loading-model.xml) (M1.18); no dependency on PROP-008 or PROP-010.

**Milestone:** design proposal; it refines [PROP-009 §2.3](PROP-009-loading-model.xml) (M1.18, Phases 1–6 shipped) and **corrects a destructive defect already in the shipped Phase-4 code** — so it is a prerequisite for PROP-009 §4 / the M1.18 Phase-7 redirect rewrite, not a far-future milestone. Owner to place in [`ROADMAP.md`](../../../ROADMAP.md). Not implementation-locked.

**Status: IMPLEMENTED** (specified 2026-06-24 in an owner-requested design session; verified against the tree 2026-07-25 by the spec-actualization campaign). `[hooks]` parses in `vibe-core` (`manifest/package/hooks.rs`), `vibe-workspace/src/hooks.rs` runs the whole contract — the pre/post phases, the Git-Bash-first Windows interpreter selection, the trust gate over `DEFAULT_ALLOWED_GROUPS`, the ran / skipped / failed statuses and the `VIBE_HOOK_*` environment — and `vibe-install`'s apply pipeline drives it. R1 successor `4503fdb6`/`9c545f0d` makes the exact nonempty materialisation report the sole hook-rerun trigger, including verify repair. One of four orthogonal specs carved from the bridge-packages design (the others: [PROP-021](../vibe-registry/PROP-021-submodule-sources.xml) submodule sources, [PROP-022](PROP-022-materialization-modes.xml) materialization modes, [PROP-023](../vibe-registry/PROP-023-bridge-packages.xml) bridge packages). The four compose to solve bridge packages but each stands alone — hooks exist for *any* package, not only bridges.

**Status: IMPLEMENTED** (specified 2026-06-24 in an owner-requested design session; verified against the tree 2026-07-25 by the spec-actualization campaign). The `Materialization` enum ships with `Copy` as the default (wire `copy`; named `Snapshot`/`snapshot` until the 2026-08-13 terminology ruling), `InPlace` beside it and a doctested `is_in_place` (`vibe-core` `package.rs`); the hardlink / in-place machinery runs through `vibe-install` (`plan.rs` / `fetched.rs` / `apply.rs`, the `materialise_in_place` seam); submodule snapshot-embedding lands in `git_package_registry/fetch.rs`; and the destructive guard sits in `commands/uninstall.rs`. R1 successor `6d606ef2`/`1cf4f189` reconciles `copy`/`hardlink` refresh through the strict slot record without touching unrecorded outputs. One of four orthogonal specs from the bridge-packages design (siblings: [PROP-020](PROP-020-install-hooks.xml) install hooks, [PROP-021](../vibe-registry/PROP-021-submodule-sources.xml) submodule sources, [PROP-023](../vibe-registry/PROP-023-bridge-packages.xml) bridge packages). Materialization mode is a property of *any* package; a huge git package wants `in-place` with no bridge in sight.

**Status: v1 IMPLEMENTED (§§2–5; the deferrals-closeout campaign). §6–§7 are specified v2 surface.** Module: `vibe-workspace` / `vibe-install` / `vibe-cli`.

**Status: IMPLEMENTED under renamed terms** (requirements authored 2026-07-14 at the owner's request; verified against the tree 2026-07-25 by the spec-actualization campaign). `static-transitive` is live on `LinkType`, and dedup + topological ordering + tie-break emission run in `bootgen` — this repository's own `STATIC.md` is the §3 redbook closure in the flesh. [PROP-035 §12](PROP-035-spec-compiler.xml) and [PROP-038](PROP-038-hybrid-boot-linking.xml) absorbed the graph as their emission layer; read the `TERMINOLOGY-RENAME` note below before the body. Extends [PROP-009](PROP-009-loading-model.xml) (the loading model).

**Status: IMPLEMENTED** (designed 2026-07-14 at the owner's request — the flagship "static-compiler vision"; verified against the tree 2026-07-25 by the spec-actualization campaign). §17 records the compiler shipping three times over: §5–§13 as the `vibe-spec` crate wired into `bootgen` (2026-07-15), the link-type rename (2026-07-16), and `normal + static` compiled end to end with the `link × format` question resolved as eager AOT (2026-07-20). **What remains:** the structural / JIT loader of §13 (`normal + dynamic`) and the §10 link tables, both still marked *(provisional)*.

**Status:** IMPLEMENTED — 2026-07-15 (all five campaign phases shipped, `d487d4e`…`381095e`; see §6). Requirements captured from an owner design dialogue; **ratified by the owner's directive to implement in full** (2026-07-15, "реализуй всю гибридную линковку, включая спеки, код и тесты"). The §5 open questions are **resolved** (Phase 0 of the campaign, recorded inline in §5 with each resolution); implementation follows the [HYBRID-LINKING campaign](../../../legacy-spec/terraforms/HYBRID-LINKING-PLAN-v0.1.md).

**Related:** [PROP-009](PROP-009-loading-model.xml) (the install orchestration), [PROP-011](PROP-011-incremental-install.xml) (skip-when-fresh, the materialise diff, and the 2026-08-24 bug rulings `##EXPLICIT-PKGREF-FULL-SOLVE` / `##EMPTY-REQUIRES-IS-A-NO-OP` this verb composes with), [PROP-010](../vibe-registry/PROP-010-local-package-cache.xml) (the machine cache clean must NOT touch).

Four systems, four different answers to "who sees what, and how far does it travel". Only two of them (Swift `package`/`@_spi`, JPMS qualified exports) actually implement *friendship*; both are **provider-declared**. Our inversion (consumer-declared, budget-motivated) flips several lessons — flagged inline as **[INVERSION]**.

**Frame first.** Every system below is one point in a 3-axis space: *who declares* (provider allowlist vs consumer restriction), *unit* (package vs module/target), *when checked* (resolve / analysis / compile / IDE). The proposed per-edge `access` is, almost exactly, OSGi's `Require-Bundle; visibility:=private|reexport` plus a third value — so OSGi's verdict on `reexport` is the most directly transferable lesson in this report.

Enforcement-point summary (the axis that most determines what a design can promise):

Ключевой совместимостный факт: переустановка хоста на новой машинерии (strict-чтение, public-дефолт) воспроизвела ленты **байт-в-байт** — ровно обещание ##DEFAULT-PUBLIC-RATIONALE / ##migration-flag-day-scope.

_2026-08-09. Что здесь лежит, чем получено и в каком порядке читать._

Замер, а не правка. Цель — исчерпывающий и точный список того, что сегодня выходит на провод в опубликованном каталоге пакетов (`repomd.json`, `primary.jsonl`, `by-name/*.json`, `by-cap/*.jsonl`, `by-purl/*.jsonl`) и в живых HTTP-ответах сервера индекса. Никаких рекомендаций.

This endpoint responds with the package metadata document, sometimes informally called a "packument" or "doc.json". The format of the response is described in detail in the [package metadata documentation](responses/package-metadata.md).

Package *metadata* describes a package for its consumers: who wrote it, where its repository is, and what versions of it have been published. It also contains a description of each *version* of a package present in the registry, listing its dependencies, giving the url of its tarball, and so on. Package metadata is useful for finding packages and for installing them.

Several components of the specification, like [Image Manifests](manifest.md) and [Descriptors](descriptor.md), feature an optional annotations property, whose format is common and defined in this section.

Implementations storing or copying content MUST NOT modify or alter the content in a way that would change the digest of the content. Examples of these implementations include:

This section defines the `application/vnd.oci.descriptor.v1+json` [media type](media-types.md).

The image index is a higher-level manifest which points to specific [image manifests](manifest.md), ideal for one or more platforms. While the use of an image index is OPTIONAL for image providers, image consumers SHOULD be prepared to process them.

There are three main goals of the Image Manifest Specification. The first goal is content-addressable images, by supporting an image model where the image's configuration can be hashed to generate a unique ID for the image and its components. The second goal is to allow multi-architecture images, through a "fat manifest" which references image manifests for platform-specific versions of an image. In OCI, this is codified in an [image index](image-index.md). The third goal is to be [translatable](conversion.md) to the [OCI Runtime Specification](https://github.com/opencontainers/runtime-spec).

This specification defines an OCI Image, consisting of an [image manifest](manifest.md), an [image index](image-index.md) (optional), a set of [filesystem layers](layer.md), and a [configuration](config.md).

This RFC proposes to stabilize the `weak-dep-features` and `namespaced-features` enhancements to Cargo. These introduce the following additions to how Cargo's [feature system] works:

[summary]: #summary

**Scope:** data AT REST (files published and read by third-party tools), not an RPC wire. **All access dates: 2026-08-09** unless stated otherwise. **Evidence rule used:** every claim carries a verbatim quote + URL. Where no authoritative answer was found, the entry says **NOT FOUND** and states what was searched. Nothing is filled in from general knowledge.

**Access date for every source below: 2026-08-09.** (All fetches performed 2026-08-09.)

**Research date / access date for every source below: 2026-08-09.** Every claim carries a verbatim quote, a URL, and that access date. Where an authoritative answer could not be found, the finding is marked **NOT FOUND** with the searches performed. Primary = the organisation's own engineering blog, docs, spec, or source code. Secondary = third-party blog, summary, or commentary (labelled and treated as weak).

Это **опциональный вход**. Ты не обязан соглашаться. Найденное несогласие с любым пунктом ниже — самый ценный результат твоей работы, если оно обосновано.

Второй независимый разбор по теме **G1-NEIGHBOURS**. Предмет — наш каталог пакетов (JSON-файлы в git-репозитории, которые читают чужие инструменты) на фоне выживших реестров-соседей. Это задача на суждение, не на постройку: ни одна строка кода не правилась. Всё, что проверено чтением нашего дерева, помечено `[ИЗ ДЕРЕВА]` с `файл:строка`; всё из `FINDINGS-DIGEST.md` — `[ИЗ СВОДА]`; всё из моих знаний о чужих системах — `[ПО ПАМЯТИ, НЕ ПРОВЕРЕНО]` (без выдуманных версий, дат и номеров issue, доступа в сеть нет).

Это второй независимый разбор свода `FINDINGS-DIGEST.md`. Предмет — как наш формат меняется во времени, не ломая читателя. Самый ценный результат здесь — **обоснованное несогласие**; где я согласен, я добавляю того, чего в своде нет.

Второй независимый взгляд на `FINDINGS-DIGEST.md`. Предмет — как чужой инструмент, написанный год назад, переживёт встречу с нашими сегодняшними данными, и насколько индустриальный «мобильный» опыт к нам применим.

Это отчёт-размышление, не постройка. Ни одной строки кода не правлено. Все утверждения о чужих системах несут метку источника; утверждения о нашем дереве несут `файл:строка`. Метки:

_Сведён 2026-08-09. Вход: один замер дерева, четыре веб-исследования, четыре независимых разбора GLM. Всё сырьё — файлы 01–09 в этом каталоге._

_Финальный разбор мегаотчёта и девяти исходных файлов. Всё, что сказано про наш код, проверено чтением дерева `C:\Users\olegc\git\v\vibevm` с `файл:строка`. Всё, что сказано про чужие системы, взято **либо** из вкопированного в наше же дерево первоисточника (`refs/**`), **либо** помечено как непроверенное._

_Написан по указанию владельца для передачи в новую сессию. Читать целиком прежде, чем что-либо делать._

Скопируйте всё, что ниже разделителя, в первое сообщение новой сессии.

This directory is a byte-for-byte import of `C:\Users\olegc\git\v\discovery\vibevm-schema-evolution-discovery\` (the original stays in place; pointers in `CONTINUE.md`, `vibevm/vibespecs/WAL.xml` and `BACKLOG.md ##owner-decisions` refer to it). Imported so the study obeys the project's own law — files inside the repository are the only shared memory — after the owner flagged the out-of-tree location as a fragility.

G1-NEIGHBOURS — вторым независимым взглядом разобрать наш каталог пакетов (JSON в git, читаемый чужими инструментами) на фоне реестров-соседей; ответить на 6 вопросов темы; результат в `G1-NEIGHBOURS.md`. Задача на проектирование/суждение, без правок кода.

G2-MECHANICS — вторым независимым взглядом разобрать механику эволюции формата (каталог vibevm) против свода `FINDINGS-DIGEST.md`; результат — `G2-MECHANICS.md`. Задача на размышление, не на правку кода; git и cargo не запускались.

G3-CLIENTS — вторым независимым взглядом проверить свод `FINDINGS-DIGEST.md` по теме «словари, версии и то, что не переносится», и выдать обоснованное несогласие; результат — `G3-CLIENTS.md`. Задача на размышление, без правки кода.

G4-MANIFEST — задача на размышление/проектирование: перепроверить по дереву таблицу трёх долговечных форматов (`vibe.lock`, каталог, `vibe.toml`) и разобрать шесть проектных вопросов о единой политике (один вопрос или три; строгость по автору; заповедник чужих ключей; цена версии в манифесте; порядок работ; один чекер). Кода не править.

M-WIRE-CENSUS — замер (без правки кода): исчерпывающий цензус формата каталога пакетов vibevm «на проводе». Произвести ровно два файла — `WIRE-CENSUS.md` (разделы 3.1–3.8) и этот отчёт. Git и cargo не запускать.

_STATUS: ЗАВЕРШЁН — 2026-08-24: XML-переход доведён до конца (K1…K7 + K6.5-адресуемость; корпус 871+четыре README-хвоста, 2170 ячеечных имён, оба линта, мир рематериализован, панели all green) · остатки — B-106 (доисторическая гниль ссылок) · закон: `vibevm/vibespecs/common/PROP-051-refactor-umbrella.xml` (BUILT)

**status: AUTHORED 2026-08-06 · NOT STARTED · order fixed by the owner: Б → В → А**

Owner ruling 2026-09-08 retires the former subscription-backed GLM transport and cancels its subscription. Every earlier transport pin and runnable command in this campaign is historical evidence only. Any remaining work uses the current central routing contract.

_STATUS: R0 СНЯТ, R1 готовится — 2026-08-24 · закон: `vibevm/vibespecs/common/PROP-052-directory-layout.xml` · предшественник: XML-флип посажен (`1ab9cc75`+`99b349d3`+`ee0651b4`, панель all green)

**status: AUTHORED 2026-07-24 · IN FLIGHT — Phase B CLOSED 2026-07-25 (58 files, 4 880/4 880 facts marked) · Phase L CLOSED 2026-07-25 (terraforms/research/neworder/discipline relocated to root `legacy-spec/`) · Phase C CLOSED 2026-07-25 (4 944/4 944 markers judged; 93.0 % confirmed) · Phase D OPEN — waves d1 + d2 landed 2026-07-25 (302 of 311 drift rows closed; the tree measures 99.7 % confirmed; 42 of 55 findings resolved) · next: the two escalations (F-046 wire-or-demote, F-035 user-owned boot file), then Phase E · vibevm-specific · first consumer of PROP-043 (Progress Control)**

_STATUS: СТРОЙКА ЗАВЕРШЕНА — 2026-08-23 · W1–W8 ✅ все · PROP-050 переведён в BUILT (impl/done) · панель зелёная · измерения зафиксированы · остатки в BACKLOG B-102..B-105 · дизайн ратифицирован (PROP-050)