PROP-034: Transitive inclusion links and the static boot-link graph

1. Motivation — the boot closure must link like a static linker

06PROP-009 §2.4 gives each direct dependency edge an inclusion type — inline (verbatim into INLINE.md, the priority lane), static (a path in INDEX.md), or dynamic (a conditional INCLUDE). Two gaps make a growing dependency set fragile, and a collection like redbook un-loadable the way its consumer wants:

07Gap 1 — inclusion does not propagate transitively. A consumer sets link only on its own direct edges.

• 08A dependency's transitive closure takes its type from each member's own [boot_snippet] suggested link, or the static default — bootgen resolves declared_link.or(suggested_link), and a transitive dependency's declared_link reads back as None.
• So a collection (e.g. redbook, PROP-028) cannot say "load my whole closure inline."
• The only workaround — each member self-suggesting inline — is wrong: it forces inline on every consumer of that member, not just the one collection that wanted it.
• Inclusion strength is a property of how a consumer pulls a subtree, and today that cannot be expressed.

09Gap 2 — the boot closure is not resolved as a static link graph. A dependency closure is a graph, and assembling a boot from it is exactly static linking.

10Three linker invariants are currently only informally met by PROP-009's "ordered list" and are load-bearing:

• 11Each package linked exactly once. A package reachable through several dependency paths must appear once in INLINE.md / INDEX.md, never N times. Double-inclusion wastes context, and for inline it duplicates verbatim text and its anchors (a duplicate-anchor hazard).
• Dependency order (topological). A package must be emitted before every package that requires it, so that when a dependent's boot text is read, everything it builds on is already in context. A package needed by another (or several) comes earlier in the sequence.
• Deterministic and acyclic. The walk must be deterministic (stable output across runs) and reject cycles loudly at generate time — the agent-side read stays recursion-free (PROP-009 §2), so all graph work, including cycle detection, happens once in vibe.

12Without these pinned, adding the whole redbook, delegation-first, and future collections risks a boot that double-includes packages and orders a dependent before its dependency — the failure the owner names as "we might never load cleanly."

2. Decisions

[requires.packages]
"flow:org.vibevm.world/redbook"     = { version = "^0.2", link = "inline-transitive" }
"stack:org.vibevm.ai-native/rust"   = { version = "^0.7", link = "static-transitive" }
"flow:org.vibevm.world/wal"         = { version = "^0.2", link = "static" }   # direct (this edge only)

inline ⊐ static ⊐ dynamic

3. redbook as inline-transitive — the motivating case

31vibevm pulls flow:org.vibevm.world/redbook as inline-transitive. The effect, under §2:

• 32Every practice redbook collects, plus their transitive deps, resolves to effective mode inline.
• The graph is deduplicated: a practice several members share (e.g. git-practices, or a common dependency) appears once.
• The graph is topologically ordered: a practice needed by another (or by redbook itself) is emitted earlier in INLINE.md.
• The whole tested edition is thus in the priority lane, verbatim, dependency-ordered, once each — the practices are guaranteed to load, which is the safety the owner is buying (over static, which trusts agent-side INDEX resolution).

33The per-member [boot_snippet].link = "inline" self-suggestions used as the B1 interim (e.g. on the git-practices members) become unnecessary once the consumer declares inline-transitive, and can be dropped — the inclusion strength moves back to the consumer where §2.1 puts it.

4. Compatibility and migration

• 34The direct inline / static / dynamic types and their semantics are unchanged; the transitive variants are purely additive to the link enum.
• §2.3's dedup + topological order pins what PROP-009 §2 left as an "ordered list": existing manifests keep working and simply gain guaranteed single-inclusion and dependency order. Any boot that silently relied on a non-topological order is a latent bug this surfaces.
• Manifest schema (vibe-core): the link field accepts the new variants; unknown link values remain a manifest error.
• Implementation lands in vibe-workspace boot resolution (bootgen): mode propagation (§2.2), dedup, topological sort with the deterministic tie-break, and cycle rejection.

5. Open questions

1. 35dynamic-transitive. Semantics of gating a whole closure behind one when (does the gate distribute to every member, or gate the subtree as a unit?) — reserved until a use case appears.
2. when inside a transitive-inline closure. A member carrying its own when OS-gate that is pulled inline-transitive: does inline (unconditional, verbatim) or the gate win? Provisional: an explicit member when keeps the member dynamic (the gate is more specific than the ancestor's blanket inline); confirm against a real case.
3. Explicit demotion. Whether to add a link = "static-here" escape that lets a consumer pull a package static even under an ancestor's inline-transitive (breaking the monotonicity of §2.2). Deferred — no demotion use case today, and monotonic priority is the safer default.

6. Version history

• 362026-07-14 — drafted (owner-requested). Promotes backlog B1. Defines the transitive inline-transitive / static-transitive links (§2.1), the effective-mode precedence lattice (§2.2), and the static boot-link graph — dedup + topological order + cycle rejection (§2.3) — with dependency-ordered emission into the INLINE.md priority lane and INDEX.md (§2.4). redbook is the motivating inline-transitive consumer (§3). Implementation (manifest schema + bootgen resolution) is the next milestone.