Project Mesh · 2026-09-24 · 6 min read
Linked Projects are not one permission pool
Repository bindings can group related work while Project identities and access remain separate.

A product may span an iOS app, a local bridge, an Engine, and a public website. Seeing those repositories together is useful. Merging all of their Project permissions because the folders have similar names is dangerous.
GrantTap's Project is a coordination scope. A repository binding says which Project owns or references a checkout. A verified architecture relation says something different: that code or runtime evidence supports a dependency. The UI should label each kind of connection accurately.
Three questions behind one group
First, which repository is this? Multiple checkouts can point to one remote repository; a folder name is not an identity. Second, which Project has authority over the Task, policy, memory, and members? Third, what relation has Weavatrix actually verified between repositories or components? The answers can differ.
For example, an internal Project can be linked to a public site Project so a person can navigate between them. That navigation does not grant members of the public site access to internal tasks or secrets. A code dependency should only be shown as verified when its source revision and evidence are present.
What a good group view shows
A useful group shows each Project by stable identity, its owning repository, computers, recent Task activity, and the reason it appears in the group. The relation label should distinguish a shared repository binding, a user-declared link, and a verified Weavatrix relation. A missing architecture report should say that analysis is pending or unavailable on that endpoint, not assert that the repository or connection does not exist.
A Project can also have a narrower nested Mesh. Membership in the parent should not silently open every child repository. Grant access to a particular repository or subtree explicitly, then observe on which hosts that grant actually took effect.

Names are for people, IDs are for routing
Two Projects called ‘general-codex’ may be separate authorities; two checkout folders called ‘granttap’ may be the same repository. Display names help orientation but must not drive deduplication, routing, or access. Rejoin and migration flows need stable lineage and visible receipts rather than a guessed merge.