PROP-050: Dependency visibility — access, friendship, and the friend closure

2.1 Perspectives — relations first, materialisation at the root

06Every visibility notion in this document is per-node: each manifest's declarations define how the graph looks from that node. An interior node's friendships, unfriendings and exclusions are «просто отношение между пакетами» — pure relations, materialising nothing.

07The consumer root is the cause of computation (owner law). Only when a node is the session's consumer root (PROP-024: [project] or [package], equipotently) do its perspective's relations resolve into an effective set, get version-resolved, materialised into vibedeps/, and compiled into lanes. «Потребительский корень проекта — это причина, почему дальше начинают происходить вычисления всей остальной иерархии пакетов.»

2.2 Edge access — how far this edge may seep

08Each [requires.packages] edge gains an optional access property with three values — the provider-side seepage mark on the edge P → Q, declared by P about its own dependency Q:

[requires.packages]
"flow:org.x/api-conventions" = { version = "^1.0" }                          # access = "public" — the default
"flow:org.x/wal"             = { version = "^1.0", access = "private" }      # dev-world only, seeps nowhere
"flow:org.x/internal-style"  = { version = "^1.0", access = "friends-only" } # seeps to those who befriended P

• 10access = "public" — the default. Q seeps through P to every consumer above, transitively along the whole hierarchy, with no opt-in. For edges whose target is part of the declarant's substance for all consumers — a collection's members, a stack's core, and every ordinary «my text builds on this» edge.
• access = "private" — Q does not seep through P at all: the edge is traversed only when P itself is the consumer root (§4.4 — the dev world). An implementation detail in the strictest sense — the explicit mark for WAL-class disciplines and dev tooling.
• access = "friends-only" — Q seeps through P only into consumers whose friend closure contains P (§2.4): those who deliberately named P (directly or transitively) a friend. The curated middle.

11Default public — owner-ruled (2026-08-23), and the asymmetry of failures decides it. The owner: «public по умолчанию точно должен быть true, потому что бессмысленное ограничение доступа к скриптам может привести к тому, что у нас сломаются динамические и статические лоадеры (без разбора ограничили то, что подразумевалось всегда доступным)». The deeper argument this survives on: the two failure modes are not symmetric in observability. Over-delivery (a forgotten private) costs tokens — visible in vibe why, lane sizes, the lock-diff, and fixable by any consumer (exclude, unfriend, override). Under-delivery (a forgotten public under a private default) makes the agent silently dumber — a hole in loaded knowledge that no measurement surfaces and only the package's author can fix. A budget system must push errors toward the observable side; presence therefore defaults open, and the budget discipline lives in explicit narrowing marks, the §7 observability, and the §5 authoring norm — not in the default. This replaces the draft's default-private rationale (fail-closed presence), which the ruling retires.

2.3 Friendship — consumer-declared, two grant forms

12Friendship is declared by the consumer of content, never by its provider: naming a package your friend means you receive what it shares friends-only. There is no provider-side allowlist (§9 F8 keeps the door open). Two grant forms:

• 13Per-edge friend = true|false (default false — owner re-ruled 2026-08-23). Friendship is a raised privilege — receiving a target's gated substance — and raised privileges are not granted where they may never be used: an ordinary edge takes the package, not its inner circle. friend = true is the explicit opt-in; the original default-true belonged to the earlier one-field paradigm and is retired with it. With the public presence default (§2.2) the two defaults form the deliberate asymmetry: presence is generous, friendship is stingy — the ordinary world works with zero ceremony, the curated world opens only by explicit word.
• The implication — owner-ratified (F10, 2026-08-23): a friends-only mark implies friend = true on its own edge. Vouching for a package as part of your substance while standing in no relation to it is incoherent — and under the strict friend = false default, a friends-only chain would otherwise need two marks per hop, where forgetting the second silently kills the chain. With the implication, the owner's A → B → C → D chain works from one mark per hop, exactly as originally intended; an explicit friend = false beside a friends-only mark overrides the implication and yields the lawful no-vouch cell of ##ACCESS-FRIEND-MATRIX (terminal delivery to the circle) — no lint, it is a real intent.
• Node-level friends = ["group/name", …]. Explicit befriending of any package — «можно указать и свои прямые зависимости, и вообще любые зависимости» — including ones the node does not require directly (e.g. a practice known to arrive deep in the closure whose friends-only companions the root wants).

14The node-level vocabulary lives in one role-blind [visibility] section — friends, unfriend, allow-friends (§2.8), ignore-concept-warnings (##CONCEPTS-GATE-SOFTENED) — plus the sibling top-level [override] table (§2.9). One section serves both manifest roles by construction (PROP-024 equipotence): no field is duplicated between [project] and [package].

15access and friend compose independently on one edge (owner-confirmed 2026-08-23: «access и friend разные понятия»). The two marks point in opposite directions, so their product is well-defined. The default shape — public presence, no friendship — is plain delivery: «Q reaches everyone above me; I take none of its gated substance». Adding friend = true to a public edge reads: «and for myself I enter friendship with Q, so Q's friends-only doors are open in my own perspective». That friendship does not travel onward through a public edge — re-exporting friendship is exactly what the friends-only mark does (##PUBLIC-GIVES-PRESENCE-NOT-FRIENDSHIP) — so in another root's closure a public edge contributes presence and nothing more. The remaining corner — «deliver publicly and vouch friendship onward» in a single edge — is deliberately inexpressible: a consumer that wants Q's gated substance opts in with its own friends line, which is the payer-decides invariant.

16The full 3 × 2 matrix (owner-requested completeness check, 2026-08-23). For an edge P → Q, read across three observers — an arbitrary consumer above P; a friend of P's (a root R with P ∈ C(R)); and P itself as root (its dev world). friend answers one question everywhere — «does the observer get Q's own gated substance» — while access picks the audience that gets Q at all:

• 18All six cells are distinct and each names a real intent — no redundancy, no gap. The one that looked dead — friends-only + friend = false — turns out load-bearing: it separates delivery to the circle from vouching onward, which is exactly the distinction the two-parameter split exists to express (rule (3) grants presence from the mark alone; the grow rule demands mark ∧ grant for the chain to continue). The parameter set is confirmed correct by exhaustion.

19A friend declares nothing about the vouched content — by design. When R befriends P (one explicit line: friend = true on its P edge, or a friends entry), everything P vouches for arrives with no mention in R's manifest: P's friends-only edge admits Q (rule (3)), the grow rule puts Q into C(R), and Q's own friends-only edges then open too — recursively, the owner's original transitivity requirement. Version choice for Q stays with the voucher (P's constraint on its own edge) — the vouched set is a bundle P tested, not a menu R assembles. This is the standard re-export semantics of JPMS requires transitive (implied readability chains), Bazel deps + exports*, and Gradle api — a dependency on P is a dependency on «P with everything P stands on». Control never leaves the payer: the grant is explicit (the false default), unfriend/per-edge exclude prune point-wise, and the lock-diff + vibe why make every transit arrival legible. The hygiene norm transposes from Bazel strict-deps: transit covers «Q is here because P stands on it»; the moment R's own text starts building on Q, R declares its own direct edge.

20What friends-only is for — the practical genres: (a) usage surface vs extension surface — a family (e.g. git-practices) delivers its practices public, while the author-side toolkit for writing a new member (templates, style, test matrices) rides friends-only: consumers consume, extenders befriend the family and receive the workshop; (b) platform inner layer — a platform ships its API text to all, its implementation-notes layer to befriended plugins (the Eclipse x-friends case, inverted to consumer opt-in, and sealable with §2.8 when curation is wanted); (c) incubation — an unstable companion practice circulates among befriended dogfood roots before its mark widens to public (a feature release per ##ACCESS-IS-SEMVER-SURFACE); (d) heavy opt-in tier — an advanced companion whose token weight should not tax every consumer, delivered only to those who ask; (e) the WAL shape — a redbook-like collection could carry a wal-like discipline on a friends-only edge: ordinary consumers never see it, while a root that wants the full discipline writes friends = ["…/redbook"] and receives wal at the version the collection tested — the alternative to today's direct host edge.

2.4 The friend closure — transitivity through friends-only edges

21For a node N, define grants(N) = the targets of N's edges carrying friend = true (explicit under the false default, or implied by a friends-only mark per F10 — an explicit friend = false beside the mark wins), plus N's friends list, minus N's unfriend list (§2.6). These are the packages N directly befriends.

22The friend closure C(R) of a root R is the least fixpoint of:

seed:  every G ∈ grants(R) is in C(R)
grow:  if F ∈ C(R), and G ∈ grants(F), and F's edge F → G has access = "friends-only",
       then G ∈ C(R)

24Reading: my friends are those I named; and when a friend marks one of its own befriended dependencies friends-only — «this one is part of my substance, shared with my friends» — that dependency becomes my friend too, recursively. The friends-only mark on F → G is thus simultaneously (a) the seepage gate of §2.2 and (b) the re-export of friendship that makes the closure transitive. This identification — the ordering message's per-edge «internal» mark IS access = "friends-only" — is owner-ratified (F1, 2026-08-23: «правильный термин — friends-only»).

25Public gives presence, not friendship (owner-ratified, F6). A package that seeps to R through public edges does not thereby join C(R), and its own friends-only edges stay closed to R unless R (or a chain of friends-only re-exports reaching R) befriends it explicitly. Friendship never grows through public or private edges — only through friends-only marks, which are explicit and rare (never a default), compounded by the friend = false default on the grant side. This is the built-in answer to «чтобы это замыкание не росло бесконтрольно»: the closure grows exactly along deliberate marks, backed by deliberate grants, and nowhere else.

26C(R) is a monotone least fixpoint over per-edge static predicates — deterministic and order-independent. With §2.9's path-stack masks in the picture, the closure and the reachable mask-states form one joint monotone fixpoint (alternating expansion until stable; masks are static declarations and both sets only grow, so termination and determinism hold; implementations dedup normalized mask-states) — the earlier draft's «computed strictly before the effective set» reading was corrected at the W1 landing, where the implementation surfaced the contradiction. Materialisation (§3) stays outside either computation. Cycles in requires remain a hard generate-time error exactly as in the linker today (PROP-034 §2.3).

2.5 Traversability and the effective set

27The effective set E(R) — the packages that exist from R's perspective — is everything reachable from R over traversable edges, along chains not killed by an exclude (§2.7). An edge P → Q is traversable for R iff any of the three rules below holds; private edges fail all three for P ≠ R, so a private dependency of a non-root package does not exist for the root — not resolved, not fetched, not materialised, not in any lane (§4.1–4.2).

(1) P = R                                  — the root's own edges always count
(2) access(P → Q) = "public"               — unconditional seepage
(3) access(P → Q) = "friends-only" ∧ P ∈ C(R)   — seepage to a friend of P's

29Everything downstream — version resolution, vibedeps/ materialisation, link-mode assignment, lane compilation, installed: predicates, the facts registry — operates on E(R) and nothing else. Visibility is computed once, first, and every other system consumes its output (§3).

2.6 unfriend — node-scoped pruning of the closure

30unfriend = ["group/name", …] (node-level) removes the named packages from the declaring node's grants(…) — and therefore from every friend closure as seen through that node. The unfriended package «притянется, но будет явно исключён из цепочки транзитивности внутренних друзей»: still usable at the declaring level (its edge, if any, still traversable by its own access), just never re-exported as a friend through the declarant. Node-scoped by owner law: «они выбрасываются из замыкания ТОЛЬКО с точки зрения той ноды, которая объявила их unfriend — а какой-нибудь другой пакет в иерархии может нормально включить их в замыкание» — another node's friends-only chain delivers the same package untouched. The name unfriend is owner-ratified (F2, 2026-08-23); the property list's enemy is retired.

2.7 exclude — hard subtree exclusion

31exclude = ["group/name", …] (per-edge) kills the named packages in every chain passing through the declaring edge — «исключены из цепочки транзитивных подключений вообще, даже если внутри они объявлены как public». Maven-exclusions semantics, owner-ratified (F4, 2026-08-23: «exclude per-ребро Maven-style. Можно per-ребро делать глубокие эксклюды по иерархии — это не глобальный deny-list, это сужение в рамках поддерева»): the pruning reaches arbitrarily deep, but only within this edge's subtree; a different path still delivers the package, and then it simply exists in E(R) via that path — classic diamond behaviour, no global veto. Exclusion is pure subtraction — it can only narrow what providers granted, never widen — which is why any node may declare it as part of shaping its own delivery; the expansive counterpart is F9's root-only override, which may also re-house this syntax (the semantics here stand either way).

2.8 allow-friends — the provider's sealed circle

32Owner-ordered design (F8, 2026-08-23: «спроектируй механизм allow-friends… похоже на возможность построить exhaustive замыкание sealed classes»). A provider G may declare, node-level, who is permitted to enter friendship with it — the Java-sealed/permits shape transplanted onto the friendship relation (design ratified — «годится»):

[visibility]
allow-friends = ["org.a/x", "org.b/*"]   # the permits list; "*" after a group = any member

• 34Three states: field absent — friendship is open, anyone's grant works (the default, today's semantics); empty list — sealed: nobody enters, the gated substance exists only in G's own dev world; a list — exactly the named circle.
• The check sits on the grant giver: a grant N → G (an explicit friend = true edge, a friends entry, or an F10-implied one) participates in any closure only if allow-friends(G) is absent or covers N. A friends-only re-export hop F → G in C(R) likewise requires F permitted by G. A rejected grant is a warning, never an error (the §5 unknown-target precedent) — the closure simply does not grow there.
• The sealed payoff is enumerability: G's inner world becomes computable from G's manifest plus its permitted members' — vibe friends org.x/g lists who may befriend G, who actually does, and through which chains. The exhaustive closure the owner names.
• Trusted friends are non-sealed points by design: G curates its immediate circle; a permitted friend F that friends-only-marks its own F → G edge extends G's substance to F's friends — vouching onward is exactly what admission to the circle licenses (as a permits-listed subtype may itself be non-sealed). A provider wanting no transit keeps its circle to leaves it trusts not to re-export.
• The seal gates friendship, never delivery (pinned at the W6 landing). A sealed G still arrives wherever a declarant's friends-only edge delivers it — the declarant owns its own edge and could as well have marked it public; what the seal closes is entry into G's circle: a rejected grant keeps G out of every closure, so G's own friends-only inner content stays shut and the grant surfaces as a RejectedGrant warning. The observable difference between sealed and unsealed is always the inner content and the diagnostics, never the presence of G itself. Proven end-to-end by cli_visibility_power.rs (unseal and exact-circle scenarios).
• override breaks the seal — owner-ruled: «механизм override должен всё равно иметь возможность взломать эти рёбра». A node-targeted override entry — "org.x/g" = { allow-friends = "*" } (or a replacement list) — rewrites the permits list in the root's perspective, quietly, like every override (F9, §2.9).

2.9 override — the sanctioned break-in, anywhere in the graph

35Owner-ruled (2026-08-23): override is lawful in any manifest, not only the root («разрешён не только в корневом манифесте, а где угодно»). Any node N may carry an [override] table whose entries rewrite foreign edges — their access, friend, presence (exclude = true), or a target's allow-friends — and the rewrite acts wherever N stands on the chain: an aggregator repairs or reshapes a member's edge for all of its own consumers, exactly as it curates its delivery with exclude. The threat model follows the owner's earlier ruling: a deliberate break-in is not an attack (the developer can edit any file on disk anyway); this is the official verb that replaces reflection-style hacks — and it stays quiet (pull-based provenance only).

36Path-stack semantics. An override applies to chains that pass through its declarant: walking a chain R → … → N → … → P → Q, the effective attributes of the edge P → Q are its declared attributes masked by the [override] tables of the chain's nodes in order, nearer-to-root applied later and winning — the root can re-override any intermediary, the payer always has the final word; between intermediaries, the outer (closer to R) wins on the chains it participates in. Effective attributes are therefore per-chain; E(R) and the grow rule quantify existentially over chains (a package is present / a hop extends the closure if some chain admits it), which is the diamond behaviour exclude already has. Determinism is preserved — masks are static declarations, the graph is acyclic, and the implementation dedups identical mask-states while walking the DAG (override tables are rare, so the practical state count stays small).

37Syntax note (W1 landing): the manifest already carried [[override]] — the array-of-tables registry-pin form (OverrideSection). The visibility table lives under the same override key as an ordinary table; the wire layer distinguishes the two shapes structurally (array vs table), either form alone is lawful, and one manifest carrying both is a loud validation/serialisation error rather than a silent merge. A future wave may retire or rename the legacy form; until then the coexistence is deliberate.

38A mid-graph override is contract; the root's is private. An [override] in a package's manifest changes what that package delivers — it is part of the package's versioned surface, subject to ##ACCESS-IS-SEMVER-SURFACE like any access change (expansive entries additionally ride at the breaker's own risk: the broken-into provider promised nothing). The consumer root's [override] binds nobody downstream and is versioned by nothing but its own repository. Observability is pull-based only, per the quiet ruling: lock provenance marks and vibe why … — via override of <node> answer whoever asks; nothing shouts at install time.

2.10 Worked example — the owner's chain

39The ordering message's chain A → B → C → D (D a practice), with each intermediate marking its dependency edge friends-only (each mark implying its own grant per F10): grants(A) ⊇ {B} (A's explicit grant on its own edge), so B ∈ C(A); B's edge B → C is friends-only and C ∈ grants(B), so C ∈ C(A); C → D likewise, so D ∈ C(A) — «загрузившись в D мы получим, что по цепочке транзитивности, D является другом для A». Traversal: A → B by rule (1); B → C by rule (3) with B ∈ C(A); C → D by rule (3) with C ∈ C(A) — so D ∈ E(A) and D materialises for A. If B had declared unfriend = ["…/C"], the chain would break at B for every root above B — while a sibling path A → B′ → C (B′ friends-only-marking C) would deliver C and D intact.

4.1 Resolver and lock

43Version resolution operates on E(R) only: private edges of non-root packages contribute no constraints, fetch nothing, and cannot conflict. vibe.lock records E(R) — the lock of a consumer no longer contains other packages' dev-world entries. Version unification (one node per (group, name), PROP-003/017) is unchanged within the effective set. A welcome simplification vs code ecosystems: the Cargo-RFC-1977 problem («may private deps duplicate at different versions?») does not arise — an invisible package has no copies at all.

44The interleaving, named honestly. Computing E(R) needs edges; edges live in manifests of resolved versions; constraints come only from E(R) — so the walk is joint: the resolver expands the graph following only traversable edges, with C(R) recomputed monotonically as newly-resolved manifests contribute grants and marks (all predicates are static edge attributes of already-chosen nodes, so the joint fixpoint stays deterministic). Reading a manifest to learn that its edge is private is a metadata read, not materialisation — package content is fetched for E(R) members only. The Cargo lesson (RFC 1977 lost six years to resolver entanglement; RFC 3516 lives by decoupling) is honoured structurally: visibility stays a pure edge predicate the walk consults — never a quantity the version solver optimises over.

4.2 Materialisation and vibedeps/

45vibedeps/ holds exactly E(R): an excluded or invisible package leaves no slot, no cache entry for the root's world, no lane text. This is the structural fix for the WAL specimen: a wal flow declared private (or friends-only) by whatever requires it simply never arrives in a consumer's tree — no snippet, no vibevm/vibespecs/WAL.xml scaffold, no INDEX row.

4.3 PROP-049 under visibility — what the genre machinery still does

46The ordering message asks whether «наша система с контролем flows» is still needed. No standalone "flows control" system exists in the spec tree (verified 2026-08-23: PROP-009's flow is an ordering category; PROP-028's flows are package kinds); the referent is read as the PROP-049 genre machinery — installed: predicates, snippet fragments, concepts, and the presupposition gate — built precisely against the WAL seepage this PROP now fixes structurally. Fork F7 confirms the referent.

47Recommendation: keep PROP-049, re-scoped — the two systems solve different halves. Visibility controls structural arrival (whether a package exists in E(R)); the genre machinery controls textual behaviour (what a snippet may presuppose, and how text adapts to a neighbour's presence). With visibility live: (a) installed: predicates and fragments remain THE adaptivity mechanism — an installed: predicate now queries E(R), and a fragment binding to an absent friend stays physically omitted exactly as today; (b) the presupposition gate remains the authoring lint that catches a snippet textually assuming what its package did not lawfully receive; (c) what dissolves is the unbundling pressure — a future redbook-like collection may keep a wal-like member on a friends-only/private edge instead of expelling it.

48Direction (F7 follow-up): concept-gated fragments. Today the concepts array feeds exactly one consumer — the presupposition gate's dictionary (crates/vibe-check/src/checks/snippet_presupposition.rs): lexeme → owning package, matched against unconditional snippet text. A natural completion is when = "concept:WAL" — a fragment gated on «some package in E(R) declares this concept», resolving a discipline as an interface rather than a named implementation (installed: stays the exact-package form). Several packages could then carry one discipline interchangeably. Deferred to the owner's F7 ruling.

49One PROP-049 rule must tighten. The presupposition lint currently exempts mentions of the package's own declared dependencies. Under visibility that exemption is too wide: a mention of an own private dependency in unconditional snippet text presupposes a package that never reaches any consumer — lawful only inside an installed:-gated fragment (which, for a private dependency, fires only in the declarant's own dev world, §4.4 — exactly right). The exemption narrows to edges that seep (public, or friends-only). This is a concrete PROP-049 amendment shipped with the implementation wave, in the warning genre of ##CONCEPTS-GATE-SOFTENED.

50Owner-ruled (F7, 2026-08-23): the gate speaks in warnings, with lawful homonymy, owner-dedup, and a subtree mute. The owner's fear is exact — «термин WAL вообще супер ходовой, его многие используют в разных смыслах» — so: (a) a foreign-concept mention is a warning («пакет X использует концепт из пакета Y»), never an error; (b) homonymy is lawful — a package that declares the lexeme in its own concepts owns the word in its own world and triggers nothing; (c) dedup across owners — when several packages declare one lexeme, a legitimate relation to any one of them (own declaration, or a seeping edge to one owner) silences the warning — «достаточно лишь одного» — and an unexplained use warns once, naming all owners, not once per owner; (d) node-level ignore-concept-warnings = ["WAL", …] mutes the named concepts for the entire subtree hanging off that manifest. The machinery stays under this softening — «фича полезная, но очень нишевая».

4.4 Equipotence and the dev world

51Rule (1) of §2.5 — the root's own edges always traverse — combined with explicit private marks resolves the open tail of the equipotence wave (PROP-024): a package's [requires] is simultaneously its dev-set and its contract, split per-edge by access rather than by section. When the package is the consumer root (a dev checkout — [project] or [package], equipotently), all its edges traverse and its private tooling materialises; when it is consumed as a dependency, only its seeping edges do. No separate dev-dependencies section needed.

4.5 vibefacts

52The adoption-facts registry (PROP-046) keys per-source files by installed packages; its universe follows E(R) mechanically. Registry entries for packages that leave the effective set surface through the existing facts_sync / lifecycle machinery (PROP-046 L5) — no new mechanism, one new reason entries become stale.

4.6 Collections and families

53A PROP-028 collection's whole point is aggregation: its member edges are the type case for access = "public" (redbook's ~21 exact-pinned members must seep to redbook's consumers — that is what depending on the collection means). A family's internal shared core is the type case for friends-only (members befriend each other through the family's marks; outsiders opt in or see nothing). Migration inventory in §6.