Linked Mesh spaces keep separate permissions

Three questions behind one group

First, which repository is this? Multiple checkouts can point to one remote; a folder name is not an identity. Second, which Mesh owns the Task, policy, memory, and members? Third, what relation has Weavatrix verified between repositories or components? The answers can differ.

For example, a Mesh can link an internal app and a public site repository. That does not give every member access to both. A code dependency is verified only when its source revision and evidence are present.

What a good group view shows

A useful Mesh view shows each Mesh, its linked repositories, computers, recent Tasks, and why they appear together. The label distinguishes a binding, a declared link, and Weavatrix evidence. A missing report remains unknown rather than erasing a connection.

A Mesh can link multiple repositories, but each member's view still depends on explicit account and Project grants. The owner's phone checks those grants before forwarding protected Project data or actions.

Names are for people, IDs are for routing

Two Mesh spaces called ‘general-codex’ may have separate permissions; two checkout folders called ‘granttap’ may be the same repository. Names help orientation but cannot drive deduplication, routing, or access.

Start with the coordination scope

A Project is the place where people coordinate work, not a command to merge every repository or every provider session. A mobile app, site, and local helper may contribute to one product while retaining separate checkouts and release processes. The Project view can link them so a person understands why two Tasks are related. The link should carry an explicit reason: shared product scope, a declared dependency, or a report with evidence. Those reasons have different strengths.

The safest mental model is a map with boundaries. A map can show that two roads meet without handing a traveler a key to every building along them. Likewise, linking repositories should help navigation without broadening membership or capability policy. When someone joins a Project, the system must evaluate that person's grants and the owner's controls for each protected action. The picture alone is not an authorization rule.

Binding, declaration, and evidence

A repository binding says which checkout a Project may observe through a connected computer. A declared relationship says that someone has recorded a link between components or repositories. Evidence-backed architecture goes further: a report points to analyzed source and a revision. Conflating these categories creates false confidence. A visually impressive edge may be only a declaration, and even a verified edge may describe an older commit than the Task currently uses.

Inspect the label before acting on a relation. Ask who supplied it, which source it covers, when it was produced, and whether it applies to this checkout. If a report is missing, preserve the declaration as a declaration rather than silently upgrading it. If a report is stale, it can still guide exploration but should not justify an automatic edit. This is a practical way to keep architecture discovery useful without pretending it is omniscient.

Permissions follow the person and action

Consider a teammate who may review a website Task but has no permission to run a local command on the release computer. A linked Project can still show that the site and release helper belong to the same product. It must not infer command access from that link. The relevant question is whether the member is allowed to receive the specific data or request the specific action at the chosen destination. The owner's phone and host enforcement have distinct roles in that chain.

The same distinction applies to capability configuration. One computer may have an MCP server available while another has a different configuration or no credential. A common Project label does not make those hosts equivalent. When a Task moves, its target must report what it can actually initialize. The Project map can help choose a route, but the route still needs its own capability and policy checks.

Avoid identity mistakes

Names are helpful for people but poor unique identifiers. Two repositories can share a short name, and a single repository can appear under different folder names on two computers. A Project can also be renamed without changing its identity. Durable links should therefore use stable identifiers and revision context, while the UI shows friendly names as context. A mistaken match can route work to the wrong checkout or expose an unrelated Task in a shared view.

When reviewing a map, look for the computer, repository origin, checkout revision, and relationship type, not just the node title. If any of those are unknown, do not fill the gap with a guess based on similar names. A good interface lets the person inspect the reason behind a link and correct a declaration without rewriting source history. That is more valuable than making every graph edge appear equally certain.

Use the map to make one decision

Suppose an iOS change depends on a relay contract. The Project map can lead from the app repository to the protocol repository, show whether the relation was declared or observed, and identify the current Task on each side. The next sensible step is to check the contract at the relevant revision and coordinate the two owners. The map should not claim that both builds pass, that a deployment happened, or that one repository's permission covers the other.

The first generated picture emphasizes separate boundaries; the second emphasizes different kinds of relation. The GrantTap screenshot below is a deterministic demonstration, not a fresh scan of private repositories. Treat all three as explanations of how to read the product. For your own work, inspect binding details and evidence before relying on a link. This turns a collection of repositories into a navigable Project without erasing the decisions that keep access narrow.

A useful follow-up is to test the map against one real change. Choose a contract shared by two repositories, identify its current source revision, and ask which Task owns the next edit on each side. Confirm that the people who can see the relation are also authorized for the particular data they need. Then run the relevant checks separately in each checkout. If the picture cannot lead to those concrete answers, improve the labels or bindings before treating the graph as a planning tool.