elastic / elastic/ai-github-actions

[information-architecture] Security-sensitive fork reviewer is grouped with routine maintenance

Open Beginner friendly
#1,677 0 comments 0 reactions 0 assignees View on GitHub
information-architecture
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.