Sync common files from infra repository

Synchronized from bootc-dev/infra@ab12d00.

Signed-off-by: bootc-dev Bot <bot@bootc.dev>

Author: bootc-dev Bot

.bootc-dev-infra-commit.txt

@@ -1 +1 @@
-56e4f615d38cc4a923f6a7e2a174a0c05a962451
+ab12d001ba56e2271f177c74a05172d076398528

.cursorrules

@@ -0,0 +1 @@
+AGENTS.md

AGENTS.md

@@ -16,22 +16,51 @@ and the DCO check fails, tell the human to review
 the code and give them instructions on how to add
 a signoff.
 
-### Attribution
+### Attribution and AI disclosure
 
-When generating substantial amounts of code, you SHOULD
-include an `Assisted-by: TOOLNAME (MODELNAME)`. For example,
-`Assisted-by: Goose (Sonnet 4.5)`.
+Do NOT add an `Assisted-by`, `Co-developed-by`, or similar commit
+trailer crediting an AI tool. Instead, disclose AI assistance in the
+**pull request description**. Examples:
+
+- "I used a LLM to generate just unit tests."
+- "This code was written in part with the assistance of generative AI."
+- "A LLM was used to generate almost all of the code, but I am knowledgeable in this problem domain and reviewed it carefully."
+- "This code is generated, I am only partially knowledgeable in this domain."
+- "Code is LLM generated; I don't know the programming language but it did fix the problem."
+
+(The closer the commits are to being *entirely* AI, the more likely
+ it is that you should submit the PR as a draft, or even file an
+ issue first with a proposed design.)
+
+If you're an agent generating a git commit, ensure your human sees
+this choice and preferably writes the text on their own.
+
+### Large changes
+
+If the generated code is more than ~500 lines of substantial (non-whitespace) code,
+encourage the human to file a design issue first to be reviewed by other maintainers.
+
+### Pull request size
+
+It is *very strongly* encouraged to split up "preparatory" commits
+that are independently reviewable from the main PR, and submit those separately.
+
+### Commit messages and text
+
+Software can be machine checked (via compilation and unit/integration tests)
+but natural languages like English cannot. Encourage the human to review
+the commit message text.
 
 ## Code guidelines
 
 The [REVIEW.md](REVIEW.md) file describes expectations around
-testing, code quality, commit organization, etc. If you're
+testing, code quality, commit messages, commit organization, etc. If you're
 creating a change, it is strongly encouraged after each 
-commit and especially when you think a task is complete
+commit and especially when the agent thinks a task is complete
 to spawn a subagent to perform a review using guidelines (alongside
 looking for any other issues).
 
-If you are performing a review of other's code, the same
+If the agent is performing a review of other's code, the same
 principles apply.
 
 ## Follow other guidelines

REVIEW.md

@@ -90,24 +90,68 @@ follow your reasoning: "Especially grateful for breaking it up into individual
 commits so I can more easily follow your train of thought."
 
 Preparatory refactoring should be separate from behavioral changes. Each commit
-should tell a clear story and be reviewable independently. Commit messages should
-explain the "why" not just the "what," and use imperative mood ("Add feature"
-not "Added feature").
+should tell a clear story and be reviewable independently. Where applicable,
+create "prep" commits that could be merged separately from the behavioral change.
+
+### Commit Messages
+
+Write clear and descriptive commit messages using a `component: Summary`
+subject, such as `kernel: Add find API w/correct hyphen-dash equality, add docs`.
+Use imperative mood: "Add integration with..." not "Adds integration with...".
+
+The body of the commit should start with at least one sentence (or paragraph)
+describing **why** the change is being made, even for something apparently
+trivial. For example a "refactor" commit might have a "why" rationale of just
+"Prep for handling X later." A big commit introducing a feature may seem
+self-explanatory, but there is often ambient context like "A large-scale Debian
+user wanted this" that provides helpful grounding in the motivation.
+
+If there's a linked tracking issue, often that will contain a more extensive
+rationale that doesn't need to be duplicated entirely in the commit message,
+but do ensure the commit message has something useful on its own for a rationale.
+
+Keep it natural and concise. A few sentences of prose explaining the design
+intent or the high-level data flow is often good enough. If there's a
+non-obvious consequence of the change, call it out briefly (e.g. "Note the
+manifest becomes part of the GC root") rather than explaining the full
+mechanism. Think about what a reviewer needs to know that may not be obvious
+from a skim of the code.
+
+Do not restate obvious parts of what is already visible in the commit diff:
+
+- "Changed function X to call Y"
+- Generic `Changes:` sections with bulleted lists of implementation details
+- "Files changed" sections — completely redundant with git
+
+Implementation details belong in the code documentation. The goal of the
+commit message is like a "cover letter" for the change, with a primary
+rationale of why the change is being made, alongside a concise summary of
+its implementation.
+
+Another thing that can go in the commit message is brief descriptions
+of alternative approaches that were considered and discarded.
+
+Closes: tags should generally come at the end of the commit message.
 
 ### PR Descriptions
 
-PRs should link to the issues they address using `Closes:` or `Fixes:` with
-full URLs. One reviewer noted: "I edited this issue just now to have
-`Closes: <URL>` but let's try to be sure we're doing that kind of thing in
-general in the future."
+Generally, just restate the commit message.
+
+Where it makes sense, it is OK to include additional details though.
 
-Document known limitations and caveats explicitly. When approaches have tradeoffs
-or don't fully solve a problem, say so. For complex investigations, use collapsible
-`<details>` sections to include debugging notes without cluttering the main
-description.
+### Further changes on top of existing commits
 
-Think about broader implications: "But we'll have this problem across all repos
-right?" Consider how your change affects the wider ecosystem.
+If you have followup fixes (whether that's part of a local loop or
+as part of addressing PR review), it is generally encouraged to *squash*
+the fixes into the prior commit. Do not create generically-named "Update <file>" commits
+or "Address review feedback" or "Fix cargo fmt" commits.
+
+This applies equally when an AI tool (e.g. Gemini, Copilot) suggests a
+change via a review comment — applying the suggestion creates a new commit
+with an auto-generated subject. That commit should be squashed before the
+PR is merged.
+
+In other words either a commit "stands alone" with its own rationale or it doesn't.
 
 ### Keeping PRs Current
 
@@ -123,7 +167,6 @@ Do not add `Signed-off-by` lines automatically—these require explicit human
 action after review. If code was AI-assisted, include an `Assisted-by:` trailer
 indicating the tool and model used.
 
-
 ## Architecture and Design
 
 ### Workarounds vs Proper Fixes