pub struct System {
pub members: Vec<Member>,
}Expand description
A stitched system: members plus the cross-repo edges between them.
Fields§
§members: Vec<Member>Member repositories in open order (deterministic: caller order).
Implementations§
Source§impl System
impl System
Sourcepub fn open(roots: &[&Path]) -> Result<System, StoreError>
pub fn open(roots: &[&Path]) -> Result<System, StoreError>
Open a system over member checkout roots. Each member database is
<root>/.scc/scc.db (the default state dir); members must already
be indexed. Stitching is read-only over member graphs.
Sourcepub fn member_entity_ids(
&self,
repo_id: &str,
) -> Result<Vec<String>, StoreError>
pub fn member_entity_ids( &self, repo_id: &str, ) -> Result<Vec<String>, StoreError>
Canonical entity ids of one member (standalone-vs-system stability
reads these through System without rewriting them).
Sourcepub fn stitch_routes(&self) -> Result<Vec<Stitch>, StoreError>
pub fn stitch_routes(&self) -> Result<Vec<Stitch>, StoreError>
Stitch HTTP contracts: same VERB /path in ≥2 members is a
contract-SHAPE match. ROUTE entities are server declarations, so two
members exposing the same route are two servers that may never have
called each other: MatchKind::MatchingContract, never Exact.
Same path with different verbs across members is ambiguous:
recorded with all claimants, never joined.
Sourcepub fn stitch_topics(&self) -> Result<Vec<Stitch>, StoreError>
pub fn stitch_topics(&self) -> Result<Vec<Stitch>, StoreError>
Stitch event topics: same topic name in ≥2 members. Direction
decides the verdict from each member’s PUBLISHES/SUBSCRIBES edges:
a publisher in one member and a subscriber in another is an
MatchKind::Exact dependency; pub+pub, sub+sub, or unevidenced
sides are a MatchKind::MatchingContract shape match. Each end
carries its side (EndRole).
Sourcepub fn stitch_package_exports(&self) -> Result<Vec<Stitch>, StoreError>
pub fn stitch_package_exports(&self) -> Result<Vec<Stitch>, StoreError>
Stitch public API: member A imports module M with symbol names N while member B exports n ∈ N. When M names B’s repo (normalized), the repo binding is declared; otherwise the symbol match is inferred and the module→repo binding stays unresolved. A symbol exported by ≥2 members is ambiguous.