Sync common files from infra repository

.bootc-dev-infra-commit.txt

@@ -0,0 +1 @@
+574cc5b9bf84f88a9cef3073adda95e4acfc7318

.claude/CLAUDE.md

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

.cursorrules

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

.devcontainer/debian/devcontainer.json

@@ -0,0 +1,30 @@
+{
+  "name": "bootc-devenv-debian",
+  "image": "ghcr.io/bootc-dev/devenv-debian",
+  "customizations": {
+    "vscode": {
+      // Arbitrary, but most of our code is in one of these two
+      "extensions": [
+        "rust-lang.rust-analyzer",
+        "golang.Go"
+      ]
+    },
+    "devaipod": {
+      // When running under devaipod, use minimal capabilities
+      // (SYS_ADMIN, NET_ADMIN, etc.) instead of full --privileged.
+      "nestedContainers": true
+    }
+  },
+  "features": {},
+  // Use privileged mode for broad compatibility (Codespaces, Docker,
+  // stock devcontainer CLI). devaipod overrides this with tighter
+  // security via the nestedContainers customization above.
+  "privileged": true,
+  "postCreateCommand": {
+    // Our init script
+    "devenv-init": "sudo /usr/local/bin/devenv-init.sh"
+  },
+  "remoteEnv": {
+    "PATH": "${containerEnv:PATH}:/usr/local/cargo/bin"
+  }
+}

.devcontainer/devcontainer.json

@@ -0,0 +1,30 @@
+{
+  "name": "bootc-devenv-debian",
+  "image": "ghcr.io/bootc-dev/devenv-debian",
+  "customizations": {
+    "vscode": {
+      // Arbitrary, but most of our code is in one of these two
+      "extensions": [
+        "rust-lang.rust-analyzer",
+        "golang.Go"
+      ]
+    },
+    "devaipod": {
+      // When running under devaipod, use minimal capabilities
+      // (SYS_ADMIN, NET_ADMIN, etc.) instead of full --privileged.
+      "nestedContainers": true
+    }
+  },
+  "features": {},
+  // Use privileged mode for broad compatibility (Codespaces, Docker,
+  // stock devcontainer CLI). devaipod overrides this with tighter
+  // security via the nestedContainers customization above.
+  "privileged": true,
+  "postCreateCommand": {
+    // Our init script
+    "devenv-init": "sudo /usr/local/bin/devenv-init.sh"
+  },
+  "remoteEnv": {
+    "PATH": "${containerEnv:PATH}:/usr/local/cargo/bin"
+  }
+}

.devcontainer/ubuntu/devcontainer.json

@@ -0,0 +1,30 @@
+{
+  "name": "bootc-devenv-ubuntu",
+  "image": "ghcr.io/bootc-dev/devenv-ubuntu",
+  "customizations": {
+    "vscode": {
+      // Arbitrary, but most of our code is in one of these two
+      "extensions": [
+        "rust-lang.rust-analyzer",
+        "golang.Go"
+      ]
+    },
+    "devaipod": {
+      // When running under devaipod, use minimal capabilities
+      // (SYS_ADMIN, NET_ADMIN, etc.) instead of full --privileged.
+      "nestedContainers": true
+    }
+  },
+  "features": {},
+  // Use privileged mode for broad compatibility (Codespaces, Docker,
+  // stock devcontainer CLI). devaipod overrides this with tighter
+  // security via the nestedContainers customization above.
+  "privileged": true,
+  "postCreateCommand": {
+    // Our init script
+    "devenv-init": "sudo /usr/local/bin/devenv-init.sh"
+  },
+  "remoteEnv": {
+    "PATH": "${containerEnv:PATH}:/usr/local/cargo/bin"
+  }
+}

.gemini/config.yaml

@@ -0,0 +1,19 @@
+# NOTE: This file is canonically maintained in
+# <https://github.com/bootc-dev/infra/tree/main/common>
+# DO NOT EDIT
+#
+# This config mainly overrides `summary: false` by default
+# as it's really noisy.
+have_fun: true
+code_review:
+  disable: false
+  # Even medium level can be quite noisy, I don't think
+  # we need LOW. Anyone who wants that type of stuff should
+  # be able to get it locally or before review.
+  comment_severity_threshold: MEDIUM
+  max_review_comments: -1
+  pull_request_opened:
+    help: false
+    summary: false # turned off by default
+    code_review: true
+ignore_patterns: []

AGENTS.md

@@ -0,0 +1,76 @@
+<!-- This file is canonically maintained in <https://github.com/bootc-dev/infra/tree/main/common> -->
+
+# Instructions for AI agents
+
+## CRITICAL instructions for generating commits
+
+### Signed-off-by
+
+Human review is required for all code that is generated
+or assisted by a large language model. If you
+are a LLM, you MUST NOT include a `Signed-off-by`
+on any automatically generated git commits. Only explicit
+human action or request should include a Signed-off-by.
+If for example you automatically create a pull request
+and the DCO check fails, tell the human to review
+the code and give them instructions on how to add
+a signoff.
+
+### Attribution and AI disclosure
+
+You SHOULD insert an `Assisted-by: AI` tag when the commit contains
+substantial assistance, and `Generated-by: AI` when the commit is
+effectively entirely generated.
+
+Do NOT add `Co-developed-by`, and do NOT reference specific
+model names or tools because these can be considered a form of advertising.
+
+For new contributors, when using AI you SHOULD include in at least the pull
+request description a rough outline of the human's level of review and
+knowledge:
+
+> Assisted-by: AI
+> Unit tests are LLM generated.
+
+> Generated-by: AI
+> I am knowledgeable in this problem domain and reviewed it carefully.
+
+> Generated-by: AI
+> I don't know Rust|Go|... well, but I did test this and it fixed the problem.
+
+### 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 messages, commit organization, etc.
+Language-specific guidelines are in
+[REVIEW_RUST.md](REVIEW_RUST.md) and
+[REVIEW_GOLANG.md](REVIEW_GOLANG.md). If you're
+creating a change, it is strongly encouraged after each 
+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 the agent is performing a review of other's code, the same
+principles apply.
+
+## Follow other guidelines
+
+Look at the project README.md and look for guidelines
+related to contribution, such as a CONTRIBUTING.md
+and follow those.

REVIEW.md

@@ -26,9 +26,10 @@ easy to generate a *lot* of code for unit tests unnecessarily).
 ### Separating Parsing from I/O
 
 A recurring theme is structuring code for testability. Split parsers from data
-reading: have the parser accept a `&str`, then have a separate function that
-reads from disk and calls the parser. This makes unit testing straightforward
-without filesystem dependencies.
+reading: have the parser accept the raw data (e.g. a string), then have a
+separate function that reads from disk and calls the parser. This makes unit
+testing straightforward without filesystem dependencies. See the
+language-specific review guides for concrete examples.
 
 ### Test Assertions
 
@@ -48,9 +49,7 @@ or `sed`.
 
 Try to avoid having shell script longer than 50 lines. This commonly occurs
 in build system and tests. For the build system, usually there's higher
-level ways to structure things (Justfile e.g.) and several of our projects
-use the `cargo xtask` pattern to put arbitrary "glue" code in Rust using
-the `xshell` crate to keep it easy to run external commands.
+level ways to structure things (Justfile e.g.).
 
 ### Constants and Magic Values
 
@@ -64,10 +63,10 @@ value was chosen.
 
 ### Don't ignore (swallow) errors
 
-Avoid the `if let Ok(v) = ... { }` in Rust, or `foo 2>/dev/null || true`
-pattern in shell script by default. Most errors should be propagated by
-default. If not, it's usually appropriate to at least log error messages
-at a `tracing::debug!` or equivalent level.
+Avoid swallowing errors (e.g. `foo 2>/dev/null || true` in shell script).
+Most errors should be propagated by default. If not, it's usually appropriate
+to at least log error messages at a debug level. See the language-specific
+review guides for concrete anti-patterns.
 
 Handle edge cases explicitly: missing data, malformed input, offline systems.
 Error messages should provide clear context for diagnosis.
@@ -192,25 +191,28 @@ functionality, ensure equivalent coverage exists.
 
 When multiple contributors co-author a PR, bring in an independent reviewer.
 
-## Rust-Specific Guidance
+## Dependencies
 
-Prefer rustix over `libc`. All `unsafe` code must be very carefully
-justified.
+New dependencies should be justified. Consider alternatives: "I'm curious if
+you did any comparative analysis at all with alternatives?"
 
-### Dependencies
+Prefer well-maintained libraries with active communities. Glance at existing
+reverse dependencies to gauge adoption (e.g. on crates.io for Rust, or
+pkg.go.dev for Go). Consider project-level dependency policies (e.g.
+`cargo deny` for Rust).
 
-New dependencies should be justified. Glance at existing reverse dependencies
-on crates.io to see if a crate is widely used. Consider alternatives: "I'm
-curious if you did any comparative analysis at all with alternatives?"
-
-Prefer well-maintained crates with active communities. Consider `cargo deny`
-policies when adding dependencies.
-
-### API Design
+## API Design
 
 When adding new commands or options, think about machine-readable output early.
 JSON is generally preferred for that.
 
 Keep helper functions in appropriate modules. Move command output formatting
 close to the CLI layer, keeping core logic functions focused on their primary
 purpose.
+
+## Language-Specific Guidance
+
+The following guides cover language-specific review expectations:
+
+- [REVIEW_RUST.md](REVIEW_RUST.md) — Rust projects
+- [REVIEW_GOLANG.md](REVIEW_GOLANG.md) — Go projects