rm githound references

Author: JonasBK

descriptions/edges/GH_AddMember.md

@@ -1,3 +1,3 @@
 ## General Information
 
-The traversable `GH_AddMember` edge indicates that a team role with the Maintainer permission level can add new members to the team. It is created by `Git-HoundTeam` when enumerating team membership roles. This edge is traversable because the ability to add members grants indirect access -- a maintainer can add any user to the team, and that user then inherits all of the team's repository permissions, effectively expanding the attack surface.
+The traversable `GH_AddMember` edge indicates that a team role with the Maintainer permission level can add new members to the team. This edge is traversable because the ability to add members grants indirect access -- a maintainer can add any user to the team, and that user then inherits all of the team's repository permissions, effectively expanding the attack surface.

descriptions/edges/GH_BypassPullRequestAllowances.md

@@ -1,3 +1,3 @@
 ## General Information
 
-The non-traversable `GH_BypassPullRequestAllowances` edge represents a per-actor allowance that bypasses the pull request review requirement on a branch protection rule. Created by `Git-HoundBranch` when collecting BPR bypass allowances, this edge identifies specific users or teams that can merge code without going through the normal PR review process. This is a significant security concern because these actors can push or merge changes directly, circumventing code review controls that protect branch integrity. Note that this bypass is suppressed when `enforce_admins` is enabled on the branch protection rule, meaning even listed actors must follow the PR review requirement.
+The non-traversable `GH_BypassPullRequestAllowances` edge represents a per-actor allowance that bypasses the pull request review requirement on a branch protection rule. This edge identifies specific users or teams that can merge code without going through the normal PR review process. This is a significant security concern because these actors can push or merge changes directly, circumventing code review controls that protect branch integrity. Note that this bypass is suppressed when `enforce_admins` is enabled on the branch protection rule, meaning even listed actors must follow the PR review requirement.

descriptions/edges/GH_CallsWorkflow.md

@@ -1,6 +1,6 @@
 ## General Information
 
-The traversable `GH_CallsWorkflow` edge links a workflow job to a reusable workflow it invokes via the `uses:` key at the job level. Created by `Parse-GitHoundWorkflow`, this edge captures the reusable workflow call graph, enabling analysts to trace inherited permissions and secret access through called workflows.
+The traversable `GH_CallsWorkflow` edge links a workflow job to a reusable workflow it invokes via the `uses:` key at the job level. This edge captures the reusable workflow call graph, enabling analysts to trace inherited permissions and secret access through called workflows.
 
 ### Local vs. remote reusable workflows
 

descriptions/edges/GH_CanAccess.md

@@ -1,3 +1,3 @@
 ## General Information
 
-The non-traversable `GH_CanAccess` edge indicates that a personal access token or app installation has been granted access to specific repositories. It is created by `Git-HoundPersonalAccessToken` and `Git-HoundPersonalAccessTokenRequest` for PATs, and by `Git-HoundAppInstallation` for app installations. This edge represents the scope of access granted to a token or app rather than a direct attack path, providing visibility into which repositories are reachable through non-human credentials. It is non-traversable because token and app access does not transitively extend to other principals.
+The non-traversable `GH_CanAccess` edge indicates that a personal access token or app installation has been granted access to specific repositories. This edge represents the scope of access granted to a token or app rather than a direct attack path, providing visibility into which repositories are reachable through non-human credentials. It is non-traversable because token and app access does not transitively extend to other principals.

descriptions/edges/GH_CanAssumeIdentity.md

@@ -1,3 +1,3 @@
 ## General Information
 
-The traversable `GH_CanAssumeIdentity` edge is a hybrid edge connecting GitHub OIDC token sources to cloud identity targets configured for GitHub Actions federation. Created by the collector when matching GitHub OIDC subject claims to cloud workload identity federation configurations, this edge represents a verified path from GitHub Actions to cloud resource access. It is traversable because an attacker who can execute workflows in the source repository, branch, or environment can obtain an OIDC token that the cloud provider will accept, granting access to the associated cloud identity and its permissions. This edge is critical for identifying cross-cloud lateral movement paths from GitHub into Azure and AWS.
+The traversable `GH_CanAssumeIdentity` edge is a hybrid edge connecting GitHub OIDC token sources to cloud identity targets configured for GitHub Actions federation. This edge represents a verified path from GitHub Actions to cloud resource access. It is traversable because an attacker who can execute workflows in the source repository, branch, or environment can obtain an OIDC token that the cloud provider will accept, granting access to the associated cloud identity and its permissions. This edge is critical for identifying cross-cloud lateral movement paths from GitHub into Azure and AWS.

descriptions/edges/GH_CanCreateBranch.md

@@ -1,6 +1,6 @@
 ## General Information
 
-The traversable `GH_CanCreateBranch` edge is a computed edge indicating that a role or actor can create new branches in a repository. Created by `Compute-GitHoundBranchAccess` with no additional API calls, the computation evaluates whether a wildcard (`*`) BPR with push restrictions and `blocks_creations` exists. If no such BPR exists, any write-capable role can create branches. If one exists, admin or `push_protected_branch` permission is required, or the actor must be listed in pushAllowances. Per-actor edges from `GH_User` or `GH_Team` are only emitted when BPR allowances grant branch creation access beyond what the role provides. Each edge includes a `reason` property and a `query_composition` Cypher query showing the underlying graph evidence.
+The traversable `GH_CanCreateBranch` edge is a computed edge indicating that a role or actor can create new branches in a repository. The computation evaluates whether a wildcard (`*`) BPR with push restrictions and `blocks_creations` exists. If no such BPR exists, any write-capable role can create branches. If one exists, admin or `push_protected_branch` permission is required, or the actor must be listed in pushAllowances. Per-actor edges from `GH_User` or `GH_Team` are only emitted when BPR allowances grant branch creation access beyond what the role provides. Each edge includes a `reason` property and a `query_composition` Cypher query showing the underlying graph evidence.
 
 ## Scenarios
 

descriptions/edges/GH_CanEditProtection.md

@@ -1,6 +1,6 @@
 ## General Information
 
-The traversable `GH_CanEditProtection` edge is a computed edge indicating that a role can modify or remove the branch protection rules governing a specific branch. Created by `Compute-GitHoundBranchAccess` with no additional API calls, this edge is emitted when the role has `GH_EditRepoProtections` or `GH_AdminTo` permissions and the branch is covered by at least one branch protection rule. The edge targets the protected branch (not the BPR itself) because the security impact is evaluated per-branch — a role that can weaken or remove protections on a branch can subsequently push code to it, representing a privilege escalation path.
+The traversable `GH_CanEditProtection` edge is a computed edge indicating that a role can modify or remove the branch protection rules governing a specific branch. This edge is emitted when the role has `GH_EditRepoProtections` or `GH_AdminTo` permissions and the branch is covered by at least one branch protection rule. The edge targets the protected branch (not the BPR itself) because the security impact is evaluated per-branch — a role that can weaken or remove protections on a branch can subsequently push code to it, representing a privilege escalation path.
 
 ## Scenarios
 

descriptions/edges/GH_CanPwnRequest.md

@@ -1,6 +1,6 @@
 ## General Information
 
-The traversable `GH_CanPwnRequest` edge indicates that a repository role can exploit a pwn-requestable workflow to execute arbitrary code with the base branch's secrets, GITHUB_TOKEN permissions, and OIDC identity. Created by `Get-PwnRequestEdges`, this is a computed edge that combines workflow analysis with repository access and fork policy evaluation.
+The traversable `GH_CanPwnRequest` edge indicates that a repository role can exploit a pwn-requestable workflow to execute arbitrary code with the base branch's secrets, GITHUB_TOKEN permissions, and OIDC identity. This is a computed edge that combines workflow analysis with repository access and fork policy evaluation.
 
 ### Pwn Request Conditions
 

descriptions/edges/GH_CanReadSecretScanningAlert.md

@@ -1,6 +1,6 @@
 ## General Information
 
-The traversable `GH_CanReadSecretScanningAlert` edge is a computed edge indicating that a role can read a specific secret scanning alert, including the leaked secret value. Created by `Compute-GitHoundSecretScanningAccess` with no additional API calls, the computation cross-references `GH_ViewSecretScanningAlerts` permission edges with `GH_Contains` structural edges (org-level and repo-level) to determine which alerts each role can access. This edge is traversable because reading an alert reveals the leaked secret — if the secret is a valid GitHub Personal Access Token, the `GH_ValidToken` edge enables identity compromise of the token's owner.
+The traversable `GH_CanReadSecretScanningAlert` edge is a computed edge indicating that a role can read a specific secret scanning alert, including the leaked secret value. The computation cross-references `GH_ViewSecretScanningAlerts` permission edges with `GH_Contains` structural edges (org-level and repo-level) to determine which alerts each role can access. This edge is traversable because reading an alert reveals the leaked secret — if the secret is a valid GitHub Personal Access Token, the `GH_ValidToken` edge enables identity compromise of the token's owner.
 
 Each edge includes a `reason` property (`org_role_permission` or `repo_role_permission`) and a `query_composition` Cypher query showing the underlying graph evidence.
 

descriptions/edges/GH_CanWriteBranch.md

@@ -1,6 +1,6 @@
 ## General Information
 
-The traversable `GH_CanWriteBranch` edge is a computed edge indicating that a role or actor can push to a specific branch. Created by `Compute-GitHoundBranchAccess` with no additional API calls, the computation evaluates both the merge gate (PR review requirements) and push gate (push restrictions) of any branch protection rule protecting the branch. Role-level edges are the common case; per-actor edges from `GH_User` or `GH_Team` are only emitted when BPR allowances grant access beyond what the role provides. Each edge includes a `reason` property (`no_protection`, `admin`, `push_protected_branch`, `bypass_branch_protection`, `push_allowance`, `bypass_pr_allowance`) and a `query_composition` Cypher query showing the underlying graph evidence.
+The traversable `GH_CanWriteBranch` edge is a computed edge indicating that a role or actor can push to a specific branch. The computation evaluates both the merge gate (PR review requirements) and push gate (push restrictions) of any branch protection rule protecting the branch. Role-level edges are the common case; per-actor edges from `GH_User` or `GH_Team` are only emitted when BPR allowances grant access beyond what the role provides. Each edge includes a `reason` property (`no_protection`, `admin`, `push_protected_branch`, `bypass_branch_protection`, `push_allowance`, `bypass_pr_allowance`) and a `query_composition` Cypher query showing the underlying graph evidence.
 
 ## Scenarios