elastic / elastic/ai-github-actions
[information-architecture] Security-sensitive fork reviewer is grouped with routine maintenance
- Dominant language
- Python
- Stars
- 11
- Forks
- 16
- Avg merge
- 22h 9m
- Merged PRs (30d)
- 31
Description
## Information Architecture Findings
### 1. Security-sensitive fork reviewer is misplaced under routine maintenance
**Area:** Navigation / Disclosure
**Component(s):** `mkdocs.yml:35-44,72-74`; `gh-agent-workflows/pr-review-fork/README.md:5-17`; `docs/workflows/gh-agent-workflows.md:51-63`
**Problem:** The primary docs navigation places `PR Review (Fork)` in the ordinary `Repository Maintenance` section (`mkdocs.yml:35-44`), while `Advanced` is the section used for special variants (`mkdocs.yml:72-74`). The workflow documentation explicitly warns that it uses `pull_request_target`, grants access to repository secrets, and should only be used on private repositories or public repositories where every contributor is trusted (`gh-agent-workflows/pr-review-fork/README.md:5-17`). The catalog itself identifies the trusted-repository restriction, but the navigation hierarchy does not surface that distinction before users select the workflow (`docs/workflows/gh-agent-workflows.md:51-63`).
**User impact:** A maintainer browsing routine maintenance workflows can interpret this as a normal PR-review alternative and reach the install instructions without encountering the security boundary at the point of discovery. That increases the chance of choosing the privileged fork variant for an untrusted public repository instead of the standard `PR Review` workflow.
**Suggested improvement:** Move the fork variant into `Advanced`, or create a clearly labeled `PR Review variants` section adjacent to the core workflow with a label such as `PR Review (Fork — trusted repositories only)`, and link it directly from the standard PR Review page.
## Suggested Actions
- [ ] Reclassify or separately group `PR Review (Fork)` in the primary docs navigation so its trusted-repository requirement is visible during workflow selection.
- [ ] Add an explicit cross-link from standard `PR Review` explaining when to choose the fork variant.
> [!WARNING]
>
> Firewall blocked 1 domain
>
> The following domain was blocked by the firewall during workflow execution:
>
> - `awmgmcpg`
>> To allow these domains, add them to the `network.allowed` list in your workflow frontmatter:
>
> ```yaml
> network:
> allowed:
> - defaults
> - "awmgmcpg"
> ```
>
> See [Network Configuration](https://github.github.com/gh-aw/reference/network/) for more information.
>
>
---
[What is this?](https://ela.st/github-ai-tools) | [From workflow: Trigger Information Architecture](https://github.com/elastic/ai-github-actions/actions/runs/30113512015)
Give us feedback! React with 🚀 if perfect, 👍 if helpful, 👎 if not.
Contributor guide
Research direction
Read the navigation entries in mkdocs.yml:35-44,72-74 alongside gh-agent-workflows/pr-review-fork/README.md:5-17 and docs/workflows/gh-agent-workflows.md:51-63. Update the navigation hierarchy and add the standard PR Review cross-link so the trusted-repository restriction is visible before selection; done when the fork workflow is clearly separated or labeled and the link is present.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions
- Domain
- documentation, security
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 72/100