A package you depend on has dependencies of its own, and those can reach your project too. Whether they do is decided where each dependency is declared, one line at a time: everyone gets it, nobody gets it, or only the projects that have named the declaring package a friend. This page explains the three marks, the friendship that opens the middle one, what ends up in your tree as a result, and how to ask vibe why a package is there or missing.
Every line under `[requires.packages]` is an edge from your [package](../glossary/index.xml#package) to the one it names, and the edge carries an optional `access` mark. The mark is the declaring package's word about its own dependency: how far it may seep upward, to the projects that depend on the declaring package.
`public` is the default and needs no writing: the dependency reaches every consumer above you, however far up, with nothing to opt into. It is the right mark for everything your own text builds on, and for the members of a collection.
`private` stops the dependency at your door. The edge is followed only when your package is itself the root of the installation, which is the case in your own checkout. It is the mark for tooling and for the disciplines that shape how you work rather than what you ship.
`friends-only` sits between the two. The dependency reaches only the consumers whose [friend closure](../glossary/index.xml#friend-closure) contains your package: those who deliberately named you a friend, directly or through a friend of theirs.
Because presence flows by default, the author's duty is to narrow on purpose. Mark `private` every edge that is not part of what you offer, and `friends-only` what only your inner circle should build on. Every public edge costs your consumers reading budget, and the [lock file](../glossary/index.xml#lock-file) makes that bill visible.
Friendship is declared by the consumer, never assumed. On an edge, `friend = true` says «I enter friendship with this package»; in the `[visibility]` section, `friends = ["org.example/inner"]` says the same for a package you do not require directly. The default is `false`: an ordinary edge takes the package, not its inner circle. Presence is generous and friendship is stingy, and the two defaults differ on purpose.
A `friends-only` mark on your own edge implies friendship with the package it names, so a chain of friends works from one mark per hop. Write `friend = false` beside it when you want to deliver a package to your circle without entering its circle yourself.
A friend declares nothing about what it receives. When you befriend a package, everything it vouches for arrives without a line in your [manifest](../glossary/index.xml#manifest), at the versions the voucher chose, and the friends-only edges of those packages open in turn. The moment your own text starts building on one of them, declare your own direct edge: transit says «here because a friend stands on it», not «mine».
The two marks are independent and point in opposite directions, so they compose. A public edge with `friend = true` delivers the package to everyone above you and opens its friends-only doors for you alone; that friendship does not travel onward. Passing friendship on is exactly what the `friends-only` mark does.
Whatever concerns the package as a whole rather than one edge lives in one section, `[visibility]`, the same for a project and for a package: `friends`, `unfriend`, `allow-friends` and `ignore-concept-warnings`. Beside it stands the top-level `[override]` table described below.
`unfriend` removes the named packages from the friendships you pass on. They still arrive at your level when an edge admits them, but nobody sees them as your friends through you. Another package in the same tree may still befriend them; the pruning is yours alone.
`exclude`, written on an edge, is the other prune: the named packages are cut from every chain that passes through that edge, however deep, even where they are public. A different path may still deliver them, and then they are present through that path. Exclusion can only narrow what the declaring packages granted, never widen it, so any package may declare it.
A package can also say who may befriend it. `allow-friends` absent means anyone; an empty list seals the package, so its gated content exists only in its own checkout; a list names the exact circle. The check falls on the one who grants friendship: a grant the package does not permit is a warning, never an error, and the closure does not grow there.
A seal gates friendship, not delivery. A sealed package still arrives wherever a friends-only edge delivers it; what stays shut is its own inner circle, and the rejected grant is reported. `vibe friends org.example/partner` prints the whole picture for one package: open, sealed or a named circle, who befriends it, which grants it rejects, and whether it sits in your closure.
Sometimes the mark you need is on an edge you do not own: a member of a collection marked a dependency private that your consumers need, or a package sealed itself against you. The `[override]` table rewrites foreign edges, and it is lawful in any manifest, at the root or below it. An aggregator uses it to reshape a member's edge for all of its own consumers, the way it curates its delivery with `exclude`.
An edge key names the two ends of the edge with an arrow; a package key names one package and rewrites its `allow-friends`. [Overrides](../glossary/index.xml#override) apply along the chains that pass through the manifest declaring them. The one nearer to the root is applied later and wins, so the root always has the final word, and an intermediary wins only on the chains it takes part in.
The same key, `override`, also serves the older array form `[[override]]` that pins a replacement source for one [coordinate](../glossary/index.xml#coordinate). The two shapes are told apart by their form, either alone is lawful, and one manifest carrying both is a loud error rather than a merge.
The packages that the marks admit from your root form the [effective set](../glossary/index.xml#effective-set), and it is the only set vibe works with. Version resolution runs over it alone: a private edge of a package that is not your root contributes no constraint, fetches nothing and cannot conflict. The lock file records the effective set, so your lock never carries another package's tooling.
The dependency tree under `vibedeps/` holds exactly that set. A package that is excluded or invisible leaves no folder, no cache entry for your world and no text in the [boot lane](../glossary/index.xml#boot-lane).
Your own edges are always followed, private ones included. That is how one `[requires]` is both your development set and your contract, split edge by edge rather than by section: in your checkout the private tooling materialises; consumed as a dependency, only the seeping edges do.
Because a mark in the middle of the graph can widen what reaches you, `vibe update` prints the change to the effective set: which packages enter or leave and how much reading budget they add or remove. A widening is a reviewed event, not a quiet seep.
`vibe why` answers the question a visibility system otherwise turns into folklore. For a package that is present it prints the chain that admits it, each hop with its rule, its access mark and where the friendship came from. For a package that is absent it prints the nearest blocked chains and what blocked each one: a private edge, a missing friendship, an unfriend or an exclude. `vibe tree` carries the same annotations on every node.
A package reached by two paths is present as soon as one path admits it; an exclude on the other path changes nothing. Excluding is subtraction and may be declared anywhere; widening is an override, and the root can always re-override an intermediary. Friendship, unfriending and sealing change which chains are open, never which versions are chosen: the version of a vouched package stays with the voucher.