bonsai-status-sync reusable (phase 1) + refreshed conversion/identity scopes - #21

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== files =="
git ls-files | rg '(^|/)docs/reusable-conversion-scope\.md$|workflows' || true

echo
echo "== target section =="
sed -n '1,120p' docs/reusable-conversion-scope.md | cat -n

echo
echo "== workflow_sha references in repo =="
rg -n "spike-claude|uses:\s*[^@\s]+@\{?#?\s*[\da-fA-F]+\"?\s*$|@[\da-fA-F]{40}|id-token:\s*write|permissions:\s*\{|workflow_call|pull_request|opened" -S .

Repository: DriverDigital/workflows

Length of output: 20002

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== locate relevant files =="
git ls-files | rg '(^|/)(docs/reusable-conversion-scope\.md|lint\.ya?ml|.*\.ya?ml)$' || true

echo
echo "== docs excerpt =="
if [ -f docs/reusable-conversion-scope.md ]; then
  sed -n '150,190p' docs/reusable-conversion-scope.md
fi

echo
echo "== lint files =="
for f in lint.yml .github/workflows/lint.yml lint.yaml .github/workflows/lint.yaml; do
  if [ -f "$f" ]; then
    echo "--- $f ---"
    sed -n '1,220p' "$f"
  fi
done

echo
echo "== reusable workflow secret declarations in workflows =="
rg -n 'workflow_call|DRIVER_AGENTS_REF|ANTHROPIC_API_KEY|secrets:|secrets: inherit|GITHUB_TOKEN|ANTHROPIC_API_KEY|DRIVER_AGENTS_REF' -S .github lint.yml lint.yaml docs/reusable-conversion-scope.md 2>/dev/null || true

Repository: DriverDigital/workflows

Length of output: 9109

🌐 Web query:

GitHub Actions reusable workflows inherited secrets referenced without declaring on.workflow_call.secrets documentation

💡 Result:

In GitHub Actions, you can reference secrets in a reusable workflow without explicitly declaring them under on.workflow_call.secrets if, and only if, you use the secrets: inherit keyword in the calling workflow [1][2]. When you use secrets: inherit in the caller's job configuration, all secrets accessible to the calling workflow—including organization, repository, and environment secrets—are implicitly passed to the reusable workflow [1][3][4]. This allows the reusable workflow to access these secrets directly via the ${{ secrets.SECRET_NAME }} context, even if the on.workflow_call section does not define them [1][5]. Key considerations regarding this approach include: 1. Automatic Availability: The inherit keyword bypasses the need for individual mapping [1][6]. Once inherited, the secrets are available within the reusable workflow's steps as if they were native to the environment [7]. 2. Scope: Secrets are only passed to directly called workflows. If you have a chain of workflows (e.g., A calls B, which calls C), secrets must be explicitly passed or inherited at each transition point [1][2]. 3. Security/Best Practices: While convenient, using secrets: inherit provides the reusable workflow access to all secrets available to the caller [6]. Explicitly declaring secrets is often preferred for reusable workflows intended for use by external repositories or to adhere to the principle of least privilege, as it limits the "blast radius" by ensuring only necessary secrets are provided [6]. 4. Parse-time vs. Runtime: Attempts to reference inherited secrets within a with: block (as inputs) will fail at parse time because with: blocks are evaluated in the context of the caller, where the inherited secrets are not yet available [7]. Inherited secrets should only be referenced directly within the steps of the reusable workflow [7].

Citations:

• 1: https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows
• 2: https://docs.github.com/en/enterprise-cloud@latest/actions/how-tos/reuse-automations/reuse-workflows
• 3: [BUG] Environment-scoped secrets unreachable from reusable workflow without secrets: inherit, despite called job declaring environment actions/runner#4453
• 4: https://docs.github.com/en/[email protected]/actions/how-tos/reuse-automations/reuse-workflows
• 5: https://github.com/github/docs/blob/main/content/actions/how-tos/reuse-automations/reuse-workflows.md
• 6: https://notes.kodekloud.com/docs/GitHub-Actions-Certification/Reusable-Workflows-and-Reporting/Step-2-Using-Secrets-in-Reusable-Workflow/page
• 7: https://dev.to/cseeman/why-your-github-actions-secrets-dont-work-in-reusable-workflow-inputs-462g

• docs/reusable-conversion-scope.md#L176-L180 (this comment)
• README.md#L96-L100

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== files =="
git ls-files | rg '(^docs/identity-unification-scope\.md$|README|doc)' || true

echo "== target snippet =="
if [ -f docs/identity-unification-scope.md ]; then
  nl -ba docs/identity-unification-scope.md | sed -n '1,80p'
fi

echo "== repository/user references =="
rg -n "DriverDigital|installed|installation token|7,?850|6,?850|Team plan|Enterprise Cloud|repo above 20|organization users|GitHub rate|rate limit|per-account" .

Repository: DriverDigital/workflows

Length of output: 340

🌐 Web query:

GitHub REST API rate limits for verified organizations paid plans installation limits organization members

💡 Result:

GitHub REST API rate limits vary based on authentication method, the type of application, and whether the organization is using GitHub Enterprise Cloud [1][2]. Standard Rate Limits For most authenticated requests, the standard rate limit is 5,000 requests per hour [1][2]. Requests made on your behalf by an OAuth app or a GitHub App may be subject to this limit, though limits are higher for applications owned by or installed on GitHub Enterprise Cloud organizations [1][2]. GitHub Apps and Scalable Limits GitHub Apps using an installation access token provide significant advantages for organizations: 1. Scalability: Unlike OAuth apps, which have fixed limits, the rate limit for GitHub Apps using an installation access token scales based on the number of repositories and the number of organization users [1][3]. 2. Enterprise Cloud: When an installation is on a GitHub Enterprise Cloud organization or enterprise, the minimum rate limit for the installation increases to 15,000 requests per hour [1][2]. Organization Membership and Specific Limits - API Requests: Generally, an individual user's membership status in an organization does not increase their personal 5,000 requests-per-hour limit [1][2]. However, if you are a member of a GitHub Enterprise Cloud organization, requests made on your behalf by an OAuth app approved or owned by that organization may benefit from a 15,000 requests-per-hour limit [1][2]. - Secondary Rate Limits: Regardless of primary limits, all users are subject to secondary rate limits to prevent abuse and ensure system stability [4][5]. These are triggered by rapid, high-volume requests (e.g., creating too many resources quickly) [4][6]. - Specific Operational Limits: Certain actions have non-API rate limits. For example, organization owners can create 50 invitations per 24 hours, which increases to 500 invitations per 24 hours if the organization is older than one month or on a paid plan [6]. Best Practices To manage these limits, GitHub recommends: - Using GitHub Apps instead of personal access tokens for automation [1][2]. - Using webhooks instead of polling the API [7]. - Implementing conditional requests with ETag or Last-Modified headers, which do not count against your limit if the content has not changed [7]. - Handling rate limit responses (403/429) by respecting the Retry-After, X-RateLimit-Remaining, and X-RateLimit-Reset headers [4].

Citations:

• 1: https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api
• 2: https://docs.github.com/en/enterprise-cloud@latest/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28
• 3: https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/deciding-when-to-build-a-github-app
• 4: https://docs.github.com/en/enterprise-cloud@latest/rest/using-the-rest-api/troubleshooting-the-rest-api?apiVersion=2026-03-10
• 5: https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/rate-limits-for-github-apps
• 6: https://docs.github.com/en/rest/orgs/members
• 7: https://docs.github.com/en/enterprise-cloud@latest/rest/using-the-rest-api/best-practices-for-using-the-rest-api?apiVersion=2026-03-10

🌐 Web query:

GitHub Apps installation limits 5000 requests per hour 50 per repository organizations users rate limits

💡 Result:

GitHub Apps that use an installation access token are subject to rate limits that scale based on the installation's activity, specifically the number of repositories and users in an organization [1][2]. Key details regarding GitHub App rate limits include: Base Limits For GitHub App installations not on a GitHub Enterprise Cloud organization, the base rate limit is 5,000 requests per hour per installation [2][3]. Scalability The rate limit scales beyond the base amount: - Repositories: Installations with more than 20 repositories receive an additional 50 requests per hour for each repository [2][3]. - Users: Installations on an organization with more than 20 users receive an additional 50 requests per hour for each user [2][3]. - Maximum: These scalable limits have an upper bound, meaning they cannot increase beyond 12,500 requests per hour [2][3]. GitHub Enterprise Cloud If an installation is on a GitHub Enterprise Cloud organization or enterprise, it receives a higher rate limit of 15,000 requests per hour [4][2]. Additional Considerations - GraphQL: GitHub Apps also have limits on the point value of queries made to the GraphQL API, which follow similar scaling rules (e.g., 5,000 points per hour base, scaling up to 12,500 points per hour) [5][3]. - Secondary Rate Limits: In addition to the primary limits mentioned above, GitHub may apply secondary rate limits to prevent abuse and ensure system availability [5][6]. - Best Practices: To stay within these limits, developers are encouraged to use webhooks instead of polling, implement conditional requests, and use consolidated GraphQL queries where possible [7]. If a limit is hit, applications should respect the x-ratelimit-reset or Retry-After headers [7].

Citations:

• 1: https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/deciding-when-to-build-a-github-app
• 2: https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api
• 3: https://github.com/github/docs/blob/main/content/graphql/overview/rate-limits-and-query-limits-for-the-graphql-api.md
• 4: https://docs.github.com/en/enterprise-cloud@latest/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28
• 5: https://docs.github.com/en/apps/creating-github-apps/registering-a-github-app/rate-limits-for-github-apps
• 6: https://github.com/github/docs/blob/main/content/apps/oauth-apps/building-oauth-apps/rate-limits-for-oauth-apps.md
• 7: https://docs.github.com/en/apps/creating-github-apps/about-creating-github-apps/best-practices-for-creating-a-github-app

🌐 Web query:

GitHub Apps rate limits 6850 7850 50 per repository users

💡 Result:

For GitHub Apps using installation access tokens, the rate limit is not a fixed number like 6850 or 7850; rather, it is a scalable system based on the size of the installation [1][2]. The standard rate limits for GitHub Apps using installation access tokens are as follows: 1. Minimum Limit: Every installation starts with a baseline rate limit of 5,000 requests per hour [1][2][3]. 2. Scaling: If an installation is on an organization with more than 20 repositories, it receives an additional 50 requests per hour for each repository [1][2][3]. Similarly, if the organization has more than 20 users, it receives an additional 50 requests per hour for each user [1][2][3]. 3. Maximum Limit: The rate limit for an installation cannot increase beyond 12,500 requests per hour [1][2][3]. 4. GitHub Enterprise Cloud: For installations on a GitHub Enterprise Cloud organization, the rate limit is 15,000 requests per hour [1][2][3]. The numbers "6850" and "7850" do not correspond to standard GitHub App rate limits. If you are encountering these specific values in API response headers, they likely reflect the calculated limit for a specific installation based on its number of repositories and users at that time. GitHub Apps using user access tokens are instead subject to the primary rate limits of the authenticated user (typically 5,000 requests per hour) [1][2][3].

Citations:

• 1: https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api
• 2: https://docs.github.com/rest/using-the-rest-api/rate-limits-for-the-rest-api
• 3: https://docs.github.com/en/enterprise-cloud@latest/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== doc excerpt =="
if [ -f docs/identity-unification-scope.md ]; then
  nl -ba docs/identity-unification-scope.md | sed -n '1,80p'
else
  echo "docs/identity-unification-scope.md not found"
fi

echo
echo "== search rate_limit usage in repo =="
rg -n "rate_limit|x-ratelimit|Retry-After|403|429|content-generation|secondary" -S . \
  --glob '!**/.git/**' --glob '!node_modules/**' || true

echo
echo "== relevant workflow files if present =="
for f in ticketed-review.yml pr-first-review.yml claude.yml; do
  echo "--- $f occurrences ---"
  git ls-files | rg "(^|/)${f}$|${f}"
done

Repository: DriverDigital/workflows

Length of output: 219

🌐 Web query:

GitHub REST API /rate_limit requests to check secondary rate limit status Retry-After x-ratelimit-remaining documentation

💡 Result:

The GitHub REST API does not provide a dedicated endpoint or method to check the current status of your secondary rate limit [1][2]. Secondary rate limits are triggered dynamically based on activity and are separate from the primary, documented rate limits [3][2]. To manage secondary rate limits, you must handle the error responses provided by the API: 1. Handling 403 or 429 Errors: When you exceed a secondary rate limit, the API will return a 403 Forbidden or 429 Too Many Requests response [1][4]. This response will typically include an error message indicating that a secondary rate limit has been triggered [4][5]. 2. Using the Retry-After Header: If the response includes a Retry-After header, you must wait for the number of seconds specified in that header before retrying your request [1][4]. 3. Exponential Backoff: If a Retry-After header is not provided, or if your request continues to fail, you should implement an exponential backoff strategy, increasing the wait time between retries [1][2][5]. 4. Best Practices: To avoid triggering secondary rate limits, the recommended practice is to perform requests serially rather than concurrently, and, for write operations (POST, PATCH, PUT, DELETE), to wait at least one second between requests [5]. Regarding the GET /rate_limit endpoint: - While you can use GET /rate_limit to check your primary rate limit status without it counting against that primary limit, this call can still count against your secondary rate limit [1][3]. - You should prioritize using the primary rate limit response headers (such as x-ratelimit-remaining and x-ratelimit-reset) included with standard API responses to monitor your primary limits instead of frequently calling /rate_limit [1][2].

Citations:

• 1: https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api
• 2: https://docs.github.com/rest/using-the-rest-api/rate-limits-for-the-rest-api
• 3: https://docs.github.com/en/rest/rate-limit/rate-limit
• 4: https://docs.github.com/en/rest/using-the-rest-api/troubleshooting-the-rest-api
• 5: https://docs.github.com/en/rest/using-the-rest-api/best-practices-for-using-the-rest-api

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== doc excerpt =="
python3 - <<'PY'
from pathlib import Path
p = Path("docs/identity-unification-scope.md")
if not p.exists():
    print("docs/identity-unification-scope.md not found")
    raise SystemExit
for i in range(1, 81):
    print(f"{i:5d}: {p.read_text(encoding='utf-8').splitlines()[i-1]}")
PY

echo
echo "== search rate_limit usage in repo =="
rg -n "rate_limit|x-ratelimit|Retry-After|403|429|content-generation|secondary" -S . \
  --glob '!**/.git/**' --glob '!node_modules/**' || true

echo
echo "== relevant workflow files if present =="
for f in ticketed-review.yml pr-first-review.yml claude.yml; do
  echo "--- $f occurrences ---"
  git ls-files | rg "^${f}$|^\\..*${f}$|/${f}$" || true
done

Repository: DriverDigital/workflows

Length of output: 7570

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== candidate file =="
git ls-files | rg '(^|/)docs/identity-unification-scope\.md$' || true

echo "== relevant lines =="
if [ -f docs/identity-unification-scope.md ]; then
  nl -ba docs/identity-unification-scope.md | sed -n '140,205p'
fi

echo "== search for guard fields =="
rg -n "issue\.user\.id|comment\.user\.id|review\.user\.id|github\.event\.\*\.user\.id|github\.event\.|user\.id|261291955|actor-gate|gate" docs/identity-unification-scope.md || true

Repository: DriverDigital/workflows

Length of output: 278

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== file stats =="
wc -l docs/identity-unification-scope.md || true

echo "== relevant lines =="
awk '{printf "%6d\t%s\n", NR, $0}' docs/identity-unification-scope.md | sed -n '140,205p'

echo "== search for guard fields =="
grep -n "issue\.user\.id\|comment\.user\.id\|review\.user\.id\|github\.event\.\*\.user\.id\|github\.event\.\|user\.id\|261291955\|actor-gate\|gate" docs/identity-unification-scope.md || true

Repository: DriverDigital/workflows

Length of output: 6158

🌐 Web query:

GitHub event payload issue_comment user id field github.event.comment.user.id

💡 Result:

In the GitHub Actions environment, when a workflow is triggered by an issue_comment event, the payload structure provided to the workflow includes a comment object [1][2][3]. Within the GitHub Actions context, you can access the user ID of the commenter using the expression ${{ github.event.comment.user.id }} [4]. The underlying structure is provided by the GitHub webhook payload for the issue_comment event [2][5]. Inside the payload, the comment object contains a user object, which holds information about the user who authored the comment [1][6]. The user object includes the following relevant fields: - id: The unique integer identifier for the GitHub user [1][6]. - login: The username of the user [1][6]. When using GitHub Actions, the event payload is accessible via the github context [1]. The hierarchy is typically: github.event -> comment -> user -> id [1][4]. This data is consistent with the GitHub REST API representation of an issue comment, where the user field contains the metadata for the comment author [7][8][6].

Citations:

• 1: https://stackoverflow.com/questions/74252630/get-the-login-of-a-user-that-issued-a-comment-on-github-actions
• 2: https://docs.github.com/en/webhooks/webhook-events-and-payloads
• 3: https://docs.github.com/en/rest/using-the-rest-api/github-event-types
• 4: https://github.com/DanTheMan827/ntag215-puck.js/blob/297835ae1ed4d251840767305f64211a3bd965ee/.github/workflows/approve-user.yml
• 5: https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=fixed
• 6: https://octo.guide/generated/api/interfaces/commententity/
• 7: https://docs.github.com/en/rest/using-the-rest-api/issue-event-types
• 8: https://docs.github.com/en/rest/activity/events?apiVersion=2026-03-10