Write a feat or a stack

What happens

03The agent creates both slots with vibe init package, sets their kinds in the manifests, writes the feat's specification, acceptance criteria and capability requirement, writes the stack's description, conventions and the capability it provides, and checks each. When a project later installs the feat, the resolver looks for a package providing ui:page-host among the project's stacks; the stack satisfies it, and the two are matched without either naming the other.

04 [[registry]] is an array, priority-ordered. [[mirror]] is a first-class fallback layer, transparent to the lockfile. [[override]] bypasses the resolver for pins. Schema and code path support all three from day one.

A feat

05A feat describes what a feature does for its user, in terms any stack can implement: purpose, behaviour, acceptance criteria, data it needs, what happens when things go wrong. It never names a framework. Its manifest declares the abilities it needs from a stack as capabilities, namespace:name@constraint, and nothing else about technology.

07In the manifest: [requires] capabilities = ["ui:page-host@^1"] and, for a feat that needs a stack at all, [compatibility] requires_kinds = ["stack"].

A stack

08A stack is a technology context: it says how the abstract abilities a feat asks for are realised with one set of tools, and it may bind the lifecycle's build and test phases to that toolchain. Its manifest declares what it provides, [provides] capabilities = ["ui:page-host@1.0"], and its specification documents describe each provided capability in a file of its own, plus conventions, tooling and deployment.

10A stack may also bind lifecycle contributions in its manifest, so that vibe build and vibe test in a consuming project run the stack's toolchain without further configuration.

11 A stack package may ship its preset as a set of [[extension]] contributions in its own manifest (auto, trust-gated like everything else) — this is how rust-ai-native-lang teaches vibe build/vibe test to drive cargo without vibe hardcoding cargo, the OOS-AUTODETECT posture of PROP-024 kept intact: the package declares, vibe never infers.

Capabilities

12A capability is an abstract interface: a namespace, a colon, a name, and optionally a version constraint. A feat requires; a stack provides; the resolver matches them at install time, and refuses a project whose feats need an ability no installed stack provides. Choose names by what the ability does for the feature, not by the technology: ui:page-host, db:relational, auth:oauth-callback.

13 Decision. A package's identity is the tuple (kind, name, version, content_hash). The content_hash is a digest over the deterministically-ordered concatenation of (rel_path_bytes || 0x00 || file_bytes || 0x00) for every file in the package directory, and the value names the recipe that produced it (PROP-044 §4.7): sha256-tree/1:<hex> is recipe 1, whose exclusion list, path normalisation and traversal order are carried as data in formats/hash_recipes/1.toml; the bare sha256:<hex> is recipe 0, the pre-recipe form, frozen verbatim in code — not configurable, because a frozen recipe that can be edited is not frozen — so that values written before recipes were named stay readable. Two hashes are comparable only at the same recipe; comparing across recipes answers a question nobody asked, and is never done silently. PROP-024 §2.2 re-scopes this to the package's shippable tree — its source, minus build output (.git/, .vibe/, target/, node_modules/, .vibeignore globs) — so a code-bearing package's identity is its source, not its build state; that exclusion lands with the code that implements it. The URL used to fetch the content is informational — recorded in the lockfile for debuggability, not for identity.

Edge cases and rules

14The word stack also names a family bundle: a package of kind stack with nothing but exact pins of a language family's members. Both are stacks in the register; the description tells them apart.

15 <family> — the aggregator. kind = "stack", content-minimal: a vibe.toml and a README.md, and nothing else — no code, no boot snippet, no specmap.toml / conform.toml. Its whole job is to name the family's members at one resolved version set through exact =X.Y.Z pins in [requires]. Requiring the aggregator installs the family.

16A feat's acceptance criteria are what the agent checks after a build; write them as observable facts, not as wishes.

17Two feats requiring the same capability may be satisfied by one stack; a project with several stacks marks one as active for a build.