chore(governance): add advisory triage controls and maintenance roadmap - #366

🤖 get_repo_knowledge executed:

get_repo_knowledge tt-a1i/archify /tmp/coderabbit-repo-knowledge/tt-a1i-archify-c29003d4/conventions

Length of output: 47813

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- changed hunk and surrounding implementation ---'
sed -n '300,390p' .github/scripts/pr-triage-card.mjs
printf '%s\n' '--- review event fields and head comparison references ---'
rg -n -C 4 'pull_request_review|changes_requested|review.*sha|head\.sha|awaiting-author|synchronize' .github/scripts/pr-triage-card.mjs .github/workflows 2>/dev/null
printf '%s\n' '--- relevant tests ---'
rg -n -C 3 'awaiting-author|pull_request_review|changes_requested|synchronize|review' --glob '*test*' --glob '*spec*' .github 2>/dev/null || true

Repository: tt-a1i/archify

Length of output: 11000

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- workflow trigger and script invocation ---'
sed -n '1,240p' .github/workflows/pr-triage-card.yml
printf '%s\n' '--- complete event dispatch and label lifecycle slices ---'
rg -n -C 12 'eventName|addLabel|removeLabel|pull_request_review|synchronize|pull_request' .github/scripts/pr-triage-card.mjs

Repository: tt-a1i/archify

Length of output: 5705

🌐 Web query:

site:docs.github.com webhook pull_request_review payload review commit_id delivery events out of order

💡 Result:

When working with GitHub webhooks, it is important to account for the possibility of out-of-order delivery. GitHub documentation explicitly states that webhooks may be delivered in a different order than the sequence in which the events originally occurred [1][2]. Because of this, you cannot rely on the arrival order of webhook requests to determine the state of a pull request or review. Instead, follow these recommended practices: 1. Use Timestamps: If you need to establish the chronological order of events relative to one another, use the timestamps provided within the webhook payload (e.g., submitted_at in pull_request_review events) rather than the delivery time [1][2]. 2. Understand the commit_id: In a pull_request_review payload, the commit_id field represents the SHA of the latest commit in the pull request at the time the review was submitted [3]. This SHA is specifically used to anchor the review to a particular state of the code. If a review is submitted against an older commit, using a commit_id that is not the latest may result in the review or review comments appearing outdated if subsequent commits modify the lines referenced in the review [4][5][6]. 3. Implement Idempotency: To handle potential issues where an event might be delivered out of order or potentially redelivered, your application should be designed to be idempotent. Check the current state of the resource via the GitHub REST API before applying changes based on a webhook payload to ensure you are not processing an older event that arrived after a newer one [7][1]. 4. Leverage Unique Identifiers: For security and to manage replay attacks, use the X-GitHub-Delivery header, which provides a unique identifier for each delivery [7]. This can help you track whether a specific event has already been processed.

Citations:

• 1: https://docs.github.com/en/enterprise-server@3.19/webhooks/testing-and-troubleshooting-webhooks/troubleshooting-webhooks
• 2: https://docs.github.com/en/enterprise-server@3.6/webhooks/testing-and-troubleshooting-webhooks/troubleshooting-webhooks
• 3: https://docs.github.com/en/rest/using-the-rest-api/issue-event-types
• 4: https://docs.github.com/en/rest/pulls/reviews?apiVersion=
• 5: https://docs.github.com/en/rest/pulls/comments
• 6: https://docs.github.com/en/enterprise-server@3.21/rest/pulls/reviews?apiVersion=2026-03-10
• 7: https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- target script ---'
sed -n '120,255p' .github/scripts/triage-commands.mjs
printf '%s\n' '--- workflow references ---'
rg -n -C 3 'triage-commands|ghFetch|POST|comments' .github/scripts .github/workflows
printf '%s\n' '--- repository guidance ---'
find . -maxdepth 3 -type f \( -iname 'AGENTS.md' -o -iname 'CONTRIBUTING.md' -o -iname 'README.md' \) -print

Repository: tt-a1i/archify

Length of output: 27206

🤖 get_repo_knowledge executed:

get_repo_knowledge tt-a1i/archify /tmp/coderabbit-repo-knowledge/tt-a1i-archify-c29003d4/conventions

Length of output: 9710

🏁 Script executed:

#!/bin/bash
set -eu
sed -n '1,125p' .github/scripts/triage-commands.mjs
sed -n '125,255p' .github/scripts/triage-commands.mjs
rg -n -C 5 'triage-commands|issue_comment|github.event.comment.body' .github/workflows .github/scripts

Repository: tt-a1i/archify

Length of output: 14954

🏁 Script executed:

#!/bin/bash
set -eu
printf '%s\n' '--- target lines ---'
sed -n '1,260p' .github/scripts/triage-commands.mjs
printf '%s\n' '--- workflow binding ---'
rg -n -C 4 'triage-commands|issue_comment|comment.body' .github/workflows .github/scripts

Repository: tt-a1i/archify

Length of output: 15344

🌐 Web query:

GitHub REST API 5xx response POST issue comment retry duplicate comment idempotency official documentation

💡 Result:

The GitHub REST API does not provide official support for idempotency keys for POST requests, including those used to create issue comments [1]. Consequently, retrying a failed POST request carries the risk of creating duplicate comments if the original request reached the server and was processed despite the subsequent failure response [1]. To manage the inherent risks of transient failures (such as 5xx errors or timeouts) when performing mutative operations like POST: 1. Idempotency Limitation: Because there is no idempotency key mechanism, you must design your application logic to handle potential duplicates [1]. For critical operations, some developers verify if the comment already exists (e.g., by listing recent comments) before retrying a failed creation request. 2. Handling 5xx and Timeouts: GitHub indicates that if a request takes longer than 10 seconds, it may be terminated with a server error or timeout [2]. For 5xx errors or timeouts, standard practice involves using exponential backoff with jitter to avoid overwhelming the server during potential outages [3][2][4]. 3. Best Practices for Mutative Requests: - Avoid Concurrent Mutations: GitHub explicitly advises against high concurrency for POST, PATCH, PUT, and DELETE requests [3][5][6]. - Pacing: When making a large number of write operations, pause for at least one second between each request to help avoid secondary rate limits [3][5]. - Retry Strategy: Implement a bounded retry strategy. If the API returns a 403 or 429 error with a Retry-After header, you must wait at least the specified number of seconds before retrying [3][2][4]. For other failures, use exponential backoff with jitter, but cap the number of attempts to prevent infinite loops [3][2][5]. Always check the official GitHub status page (githubstatus.com) during persistent 5xx errors to determine if there is an ongoing platform incident [2][6].

Citations:

• 1: GitHub discussion 192764 in orgs/community (link omitted to avoid creating a cross-reference)
• 2: https://docs.github.com/en/rest/using-the-rest-api/troubleshooting-the-rest-api?apiVersion=2026-03-10
• 3: https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2026-03-10
• 4: https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api
• 5: https://dxrf.com/blog/2026/06/08/github-api-best-practices-good-citizenship/
• 6: https://errormedic.com/api/github-api/github-api-rate-limit-exceeded-401-403-429-502-timeout-complete-troubleshooting-guide

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- workflow ---'
cat -n .github/workflows/generated-artifacts-report.yml | sed -n '1,100p'

printf '%s\n' '--- builder references ---'
rg -n -C 3 'build-gallery|build-guide|build-start|docs-rebuilt|RUNNER_TEMP|process\.env|\.git|credential' \
  scripts .github/workflows/generated-artifacts-report.yml

Repository: tt-a1i/archify

Length of output: 17027

🌐 Web query:

official actions/checkout v5 README persist-credentials default local Git config

💡 Result:

In actions/checkout v5, the persist-credentials input defaults to true [1][2][3]. When set to true, the action configures the authentication token or SSH key with the local Git configuration to allow subsequent Git commands in the workflow to run authenticated [1][4][3]. Starting with actions/checkout v5.0.1, the implementation of this persistence was updated to store these credentials in a separate configuration file located under $RUNNER_TEMP, rather than writing them directly into the local repository's Git configuration [5]. This change helps improve security and requires a minimum Actions Runner version of v2.329.0 to access the persisted credentials, particularly for Docker container action scenarios [5]. You can disable this behavior entirely by setting persist-credentials: false in your workflow step [1][4].

Citations:

• 1: https://github.com/actions/checkout/?tab=readme-ov-file
• 2: https://git.woni.link/actions/checkout/src/branch/releases/v5/action.yml
• 3: https://github.com/actions/checkout/blob/34e114876b0b11c390a56381ad16ebd13914f8d5/action.yml
• 4: https://git.liteyuki.org/actions/checkout/src/tag/v5/README.md
• 5: https://git.cxtech.cc/actions/checkout/compare/v6.0.0..v5.0.1

🌐 Web query:

site:github.com/actions/checkout v5.0.1 git-auth-helper temporary HOME RUNNER_TEMP persist credentials implementation

💡 Result:

In the actions/checkout action, specifically within the git-auth-helper implementation used in v5.0.1 and surrounding versions, credentials persistence relies on using the $RUNNER_TEMP environment variable to securely manage temporary configuration files [1][2][3]. When persist-credentials is enabled, the action manages authentication (such as tokens or SSH keys) by creating temporary files within the directory specified by RUNNER_TEMP [2][4][5]. The implementation follows these key principles for security and cleanup: 1. Temporary Home Override: The git-auth-helper often creates a temporary directory inside RUNNER_TEMP using a unique identifier (via randomUUID) [2][5]. It then temporarily overrides the HOME environment variable to point to this location [2][5]. This allows the action to configure global Git settings (like .gitconfig) without affecting the runner's actual home directory [2][5]. 2. Credential Storage: Instead of writing sensitive credential information directly into the repository's .git/config file, the implementation creates a separate credentials configuration file under RUNNER_TEMP [1][3]. This ensures sensitive data is isolated from the repository directory [3]. 3. Cleanup: The action includes logic to remove these temporary files and reset environment variables (like HOME) during post-job cleanup [2][3]. Specifically, for credential config files, the implementation checks if the path starts with RUNNER_TEMP before attempting deletion using io.rmRF to ensure only temporary files are targeted [1][3]. This design prioritizes security by keeping credentials out of the workspace directory and ensuring that temporary configurations are contained within the ephemeral RUNNER_TEMP environment [1][3].

Citations:

• 1: actions/checkout@v5.0.0...v5.0.1
• 2: https://github.com/actions/checkout/blob/main/src/git-auth-helper.ts
• 3: actions/checkout@08c6903...8e8c483
• 4: https://github.com/actions/checkout/blob/5a4ac9002d0be2fb38bd78e4b4dbde5606d7042f/src/git-auth-helper.ts
• 5: https://github.com/actions/checkout/blob/8230315d06ad95c617244d2f265d237a1682d445/src/git-auth-helper.ts

🏁 Script executed:

#!/bin/bash
set -eu

url='https://raw.githubusercontent.com/actions/checkout/v5.0.1/src/git-auth-helper.ts'
printf '%s\n' '--- git-auth-helper v5.0.1 credential configuration ---'
curl -fsSL "$url" | nl -ba | sed -n '1,260p' | grep -n -C 8 -E 'temporaryHomePath|GIT_CONFIG|HOME|configureTempGlobalConfig|persistCredentials|extraheader|credential.helper'

printf '%s\n' '--- action.yml input ---'
curl -fsSL 'https://raw.githubusercontent.com/actions/checkout/v5.0.1/action.yml' | grep -n -A5 -B2 'persist-credentials'

Repository: tt-a1i/archify

Length of output: 318

🏁 Script executed:

#!/bin/bash
set -eu

printf '%s\n' '--- git-auth-helper v5.0.1 credential configuration ---'
curl -fsSL 'https://raw.githubusercontent.com/actions/checkout/v5.0.1/src/git-auth-helper.ts' |
  grep -n -C 8 -E 'temporaryHomePath|GIT_CONFIG|HOME|configureTempGlobalConfig|persistCredentials|extraheader|credential.helper'

printf '%s\n' '--- action.yml input ---'
curl -fsSL 'https://raw.githubusercontent.com/actions/checkout/v5.0.1/action.yml' |
  grep -n -A5 -B2 'persist-credentials'

Repository: tt-a1i/archify

Length of output: 6746

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.