add the two gates tonight's contributor queue exposed #8
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -168,6 +168,52 @@ Query the actual table before believing any number computed from it. | |
| **Caught:** 35 of 40 rows in a live demo database were seeded or probe data, inflating the install | ||
| count roughly eightfold, and one real row counted a browser in fullscreen as an installed app. | ||
|
|
||
| ### Read the board before you write code | ||
|
|
||
| Check open pull requests and issues on a repo before starting work on it. On anything that invites | ||
| contributions, do it every time. | ||
|
|
||
| **Caught, badly and late:** a maintainer filed an issue and built a fix for a problem a first-time | ||
| contributor had already solved in an open pull request a day earlier. The duplicate was noticed by | ||
| accident during an unrelated sweep, not by any check, and only because somebody thought to ask what | ||
| else was outstanding. | ||
|
|
||
| The cost lands on the contributor, not on you. Having your first contribution silently duplicated by | ||
| the person you contributed to is the most discouraging outcome available, and it is invisible from | ||
| the maintainer's side: the work still gets done, the issue still closes, and nothing looks wrong. | ||
|
|
||
| Two mechanisms, because the habit alone did not hold: | ||
|
|
||
| - **Watch your own repositories.** Guardrails decide what may merge; none of them tell you anything | ||
| arrived. Four pull requests sat for a day and a half on a repo whose owner was not subscribed to | ||
| it, because org repos do not notify their owner by default. | ||
| - **Assign yourself, or comment, before starting.** The `/take` convention exists for contributors | ||
| and applies to maintainers for the same reason. | ||
|
|
||
| ### A contributor's licence grant is not a process rule | ||
|
|
||
| Branch protection can be overridden by an admin when the situation warrants it. A CLA check cannot, | ||
| and the difference is worth being explicit about because both appear as a red check on a pull | ||
| request. | ||
|
|
||
| Protection rules govern process on your own repository. A CLA is the **licence grant** that lets you | ||
| redistribute someone else's code under your terms. Overriding it does not create the grant; it only | ||
| removes the thing that was checking for one, and the package still ships their work without it. | ||
|
Comment on lines
+195
to
+201
There was a problem hiding this comment. 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -e
printf '%s\n' '--- DELIVERY.md excerpt ---'
sed -n '180,210p' DELIVERY.md
printf '%s\n' '--- related CLA and bypass wording ---'
rg -n -i -C 3 'CLA|bypass|override|branch protection|status check' DELIVERY.md README.md .github 2>/dev/null || trueRepository: BaryoDev/.github Length of output: 13794 🌐 Web query:
💡 Result: By default, branch protection rules in GitHub do not apply to users with administrator permissions for the repository or to custom roles that have the "bypass branch protections" permission [1][2]. This means that, by default, these individuals can bypass required status checks [1][2]. However, you can configure branch protection rules to include these users and roles [1][2]. When managing a branch protection rule, there is a specific setting to enforce restrictions for administrators [3][4]. Key details regarding this configuration include: Enforcing Restrictions on Administrators: When configuring or editing a branch protection rule, you can select the option to apply protection settings to administrators [1][2]. In the API, this is controlled by the enforce_admins boolean parameter [4]. When enabled, even repository administrators are required to ensure that all mandatory status checks pass before merging changes into the protected branch [1][2]. Custom Roles: For organizations using custom repository roles, the "bypass branch protections" permission allows users to circumvent branch protection rules, similar to the default behavior for repository administrators [1][2]. Just as with administrators, you can choose to apply restrictions to these custom roles to ensure they are also bound by required status checks [1][2]. Summary of Behavior: - Default: Administrators and roles with "bypass branch protections" can bypass required status checks [1][2]. - Configured: If the branch protection rule is set to "Include administrators" (or the equivalent setting for custom roles), then these users are no longer exempt and must follow the same status check requirements as other collaborators [1][2]. If you are encountering issues where status checks are blocking merges despite having administrator permissions, it is likely that the "Include administrators" (or "Do not allow bypassing the above settings") option has been enabled for that branch protection rule [3][5]. Citations:
Separate branch-protection bypass from CLA compliance. When repository settings allow it, an administrator or bypass role can bypass a branch-protection requirement, including required status checks. That bypass does not create the license grant required by a CLA. 🤖 Prompt for AI Agents |
||
|
|
||
| **Encountered:** three pull requests blocked as unsigned from a contributor who *had* signed. The | ||
| signature covered the whole organisation. It could not attach because the commits carried an email | ||
| with no numeric ID prefix, so GitHub resolved them to no account at all and the CLA service had no | ||
| identity to match. A fourth pull request from the same person, using the ID-prefixed address, passed | ||
| immediately. | ||
|
Comment on lines
+203
to
+207
There was a problem hiding this comment. 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -e
printf '%s\n' '--- DELIVERY.md around the cited lines ---'
sed -n '190,220p' DELIVERY.md
printf '%s\n' '--- noreply-related references ---'
rg -n -i -C 3 'noreply|ID-prefixed|numeric ID|username change|GitHub settings|CLA' DELIVERY.md .Repository: BaryoDev/.github Length of output: 27247 🌐 Web query:
💡 Result: For GitHub accounts created before July 18, 2017, the noreply email address format and its behavior during a username change depend on whether you enabled the Keep my email address private setting before that date [1]. If you enabled the Keep my email address private setting prior to July 18, 2017, your noreply email address is in the format: username@users.noreply.github.com [1][2]. Because this older, username-only format does not contain a numeric ID, commits associated with this address will not be attributed to your new username and will not appear in your contributions graph if you change your GitHub username [3][4]. If you have since updated your email privacy settings (by deselecting and reselecting the Keep my email address private option), your account will have been updated to use the modern, ID-based noreply email address format: ID+USERNAME@users.noreply.github.com [1][2]. Commits associated with this ID-based format will remain associated with your account and appear in your contributions graph even after a username change [3][4]. In summary, if you are still using the legacy username-only format (username@users.noreply.github.com), a username change will break the link between those past commits and your account [3][4]. To ensure your commits remain associated with your account during a future username change, you should update your email privacy settings to switch to the ID-based format [1][2]. Citations:
🌐 Web query:
💡 Result: Yes, the format ID+USERNAME@users.noreply.github.com contains a numeric account ID [1]. For accounts created after July 18, 2017, or for users who have explicitly enabled the "Keep my email address private" setting to generate an ID-based address, the email address includes a unique numeric ID [1]. This ID is the primary identifier for the GitHub account, allowing the platform to maintain commit associations even if the username is changed [1]. In contrast, older accounts created before July 18, 2017, that have not updated their settings use a legacy format (USERNAME@users.noreply.github.com) that does not include a numeric ID [1]. Users can trigger the generation of an ID-based email address by navigating to their email settings and toggling the "Keep my email address private" option [1]. Citations: 🌐 Web query:
💡 Result: There is no information available in the provided search results linking the phrase "username-only" to the date July 18, 2017. The search results discuss GitHub's username policies and the implications of changing a username, but they do not mention a specific event, feature update, or policy change associated with that term and date. Citations: Correct the universal noreply-address rule. Username-only addresses can remain associated with older GitHub accounts until a username change breaks the association. Recommend the ID-based address shown in GitHub settings and verify that the CLA service can match it. 🤖 Prompt for AI Agents |
||
|
|
||
| So read an unsigned CLA as a question about **identity** before assuming refusal, and never as | ||
| something to wave through: | ||
|
|
||
| - `username@users.noreply.github.com` resolves to nobody. `12345678+username@users.noreply.github.com` resolves to the account. | ||
| - A commit authored by a tool identity, `Agent Core <agent@agent-core.local>` in this case, can never | ||
| be covered by anyone's signature, because a CLA is an agreement with a person. Set the tool's git | ||
| identity to a real contributor or every pull request it produces is permanently unmergeable. | ||
|
Comment on lines
+213
to
+215
There was a problem hiding this comment. 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win 🧩 Analysis chain🏁 Script executed: #!/bin/bash
set -e
printf '%s\n' '--- DELIVERY.md context ---'
sed -n '190,225p' DELIVERY.md
printf '%s\n' '--- related CLA/tool-identity references ---'
rg -n -i -C 3 'CLA|agent@agent-core\.local|tool identity|git identity|unmergeable|signature' --glob '!node_modules' .Repository: BaryoDev/.github Length of output: 18862 🌐 Web query:
💡 Result: GitHub CLA bots manage the legal compliance of contributions by verifying that each contributor has signed a Contributor License Agreement (CLA) [1][2]. These bots operate by intercepting GitHub webhooks triggered by pull request activities, such as opening a PR or adding new commits [2][3]. Key mechanisms for verify and managing contributor signatures include: Identity Verification: 1. Commit Author Information: Bots inspect the commit metadata (the author name and email address) associated with each commit in a pull request [1][2]. Because Git allows users to set arbitrary names and emails, bots often rely on the associated GitHub account linked to that email or the GitHub user ID (where available) as the primary source of truth for identity [1][4][2]. 2. GitHub Integration: Bots frequently require users to sign in via GitHub OAuth, ensuring the signature is cryptographically linked to the contributor's authentic GitHub identity [4][2][5]. 3. Bypass Lists: Repositories often maintain an allowlist of accounts (e.g., specific bots, maintainers) exempt from CLA requirements, as they may be excluded from the traditional rights-granting process [6][2][7]. Signature Collection and Enforcement: 1. Automated Enforcement: When a contribution is detected from an unsigned user, the bot updates the pull request status check to a failure state and posts a comment providing instructions on how to sign [1][8][2]. 2. Signing Workflow: Contributors typically sign the CLA by either: - Posting a specific phrase (e.g., "I have read the CLA Document and I hereby sign the CLA") as a comment on the pull request, which the bot detects via webhooks [9][8][7]. - Authenticating through an external portal (often using GitHub OAuth) linked in the bot's comment [4][2][5]. 3. Data Storage: Once signed, the bot records the signature. This is often stored in a decentralized manner, such as a JSON file within a dedicated branch or repository, or in a centralized database managed by the CLA service [10][8][4][2]. Crucially, "signing" a CLA via a bot comment or portal is a distinct action from "signing a commit" (GPG/SSH/S/MIME cryptographic signing). While commit signing ensures the integrity and origin of the code, a CLA signature is a legal agreement confirming the contributor has the right to license their code to the project [11][12]. Users should verify that their email settings in Git match the email registered with their GitHub account to ensure the CLA bot correctly identifies them [1]. Citations:
🏁 Script executed: #!/bin/bash
set -e
printf '%s\n' '--- CLA guidance and repository automation configuration ---'
sed -n '40,85p' CONTRIBUTING.md
printf '%s\n' '--- repository configuration files ---'
git ls-files | rg '(^|/)(\.github|CONTRIBUTING|CLA|LICENSE|DELIVERY)' | head -80
printf '%s\n' '--- bot and CLA configuration content ---'
rg -n -i -C 4 'cla|bot|author|co-authored-by|noreply|signed' .github CONTRIBUTING.md DELIVERY.md 2>/dev/null || trueRepository: BaryoDev/.github Length of output: 25415 Do not instruct tools to impersonate contributors. A tool must not use a real contributor's Git identity. That can falsely attribute tool-generated commits and associate them with the wrong CLA signer. Use the approved CLA bot process or an explicit bot exemption. Otherwise, require a real contributor to author and own the change. State only that an individual CLA may not cover an unmatched commit author. Remove “anyone's signature” and “permanently unmergeable.” 🤖 Prompt for AI Agents |
||
|
|
||
| ### Mechanical guardrails, not review habits | ||
|
|
||
| Branch protection, a public API approval snapshot, required status checks, a secrets scan. Things | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
Repository: BaryoDev/.github
Length of output: 1502
🌐 Web query:
GitHub documentation automatic watching repositories push access notification settings organization repository owner default subscription💡 Result:
GitHub does not provide a native setting for organization owners to enforce automatic "watching" of repositories for all organization members [1][2]. Notification settings, including automatic watching preferences, are managed at the individual user account level [1][3]. Regarding default behavior and user control: 1. Automatic Watching Settings: Individual users can choose to automatically watch all repositories they have push access to (excluding forks) via their personal notification settings [1][4]. This setting is enabled by default for users, but it is an individual preference rather than an organization-wide policy [1]. 2. Organization Owner Capabilities: Organization owners cannot force or set default notification or "watch" configurations for other members [2][5]. They manage organization access, base permissions, and repository settings, but they do not control the personal notification subscriptions of members [6][2]. 3. Manual/Programmatic Alternatives: Because there is no organization-wide "force watch" setting, users who wish to watch all repositories in an organization must either manually watch them or use third-party scripts and tools that utilize the GitHub API to automate the process [7][8][9][10]. These tools typically require a Personal Access Token with appropriate scopes to programmatically toggle the "watch" status for repositories [8][9][10]. In summary, organization owners cannot push notification or subscription settings to members. Members must manage their own subscriptions according to their personal preferences within their GitHub account settings [1][3].
Citations:
Qualify the notification default claim.
Do not state that organization repositories do not notify owners by default. GitHub can automatically watch repositories where users have push access, based on individual notification settings. Keep the recommendation, but tell owners to verify their subscription and delivery settings.
🤖 Prompt for AI Agents