homebrew-tools

# Working in this repository

This is the `openai/tools` Homebrew tap. It distributes generated Ruby recipes
for prebuilt tools; it does not contain their application source or generators.
Read [CONTRIBUTING.md](CONTRIBUTING.md) and [SECURITY.md](SECURITY.md) before making
changes. The recipe and upstream inventory is in
[Generated recipes](CONTRIBUTING.md#generated-recipes).

## Scope and ownership

- Before editing, state the requested outcome, acceptance criteria, affected
  paths, and non-goals. Keep changes limited to that outcome; ask before changing
  public interfaces, crossing ownership boundaries, or restructuring architecture.
- Use a linked Git worktree, verify its intended base commit, and preserve
  unrelated work. Do not edit the primary checkout.
- `Casks/openai.rb` and the Orchard, Softnet, Tart Guest Agent, and Tart formulas
  carry GoReleaser headers. Tunnel Client has separate release automation.
  Fix durable recipe-generation changes in the appropriate upstream generator,
  then regenerate. Do not silently hand-edit generated output or assume every
  recipe is generated by Castiron.
- Maintain tap-owned documentation, `.github/`, and
  `scripts/validate_recipes.rb` here. Consult [.github/CODEOWNERS](.github/CODEOWNERS)
  for reviewers; its current owner is `@openai/sdks-team`.

## Security boundaries

- Report suspected vulnerabilities privately using [SECURITY.md](SECURITY.md).
  Do not put exploit details or sensitive evidence in public issues, PRs,
  discussions, or logs before coordinated disclosure.
- Use synthetic examples and fixtures. Remove API keys, authorization headers,
  cookies, customer data, tunnel credentials, private hostnames, and signed URL
  query strings from shared output. Do not read or print unrelated local secrets.
- Local validation needs no OpenAI API key or release credential. Never commit
  credentials, put them in command arguments or recipe URLs, or expose them to
  PR-controlled code. Keep release credentials in the configured secret store;
  use scoped, short-lived tokens where supported. Follow the private reporting
  process if a credential is exposed and arrange revocation or rotation with its
  owner; deleting the visible value alone is insufficient.
- Preserve the versioned HTTPS release sources and per-artifact SHA-256 checksums
  documented in [CONTRIBUTING.md](CONTRIBUTING.md#release-artifacts).
  Never use `sha256 :no_check`, mutable download URLs, or an unreviewed mirror to
  make validation pass. A checksum match does not establish upstream provenance.
- Treat recipe Ruby, install hooks, completions, and downloaded executables as
  code. Review changes before loading recipes with Homebrew; do not execute an
  unknown artifact just to inspect its version. Avoid live network, VM, or tunnel
  operations when synthetic evidence suffices.
- Review dependency and GitHub Action changes for source ownership, release
  integrity, advisories, transitive code, and permission changes. Preserve full
  commit SHA pins for actions and minimal job permissions. Do not add a dependency
  just to work around a failing check.
- Security-review changes to artifact URLs/checksums, install or post-install
  code, bundled binaries, wrappers, dependencies, validation rules, workflows,
  bot credentials, merge checks, and publishing behavior. Follow the review
  checklist in [CONTRIBUTING.md](CONTRIBUTING.md#review-and-pull-requests).

## Verification and delivery

- Run the [validation commands](CONTRIBUTING.md#validation) from the repository
  root. Report exactly what passed, failed, or was unavailable. These checks do
  not prove artifact authenticity or upstream security.
- Review the complete diff against the intended base, including new files. Fix
  supported defects introduced by the change and narrowly necessary corrections;
  report unrelated preexisting issues separately. Do not expand the change to
  satisfy speculative review concerns.
- Before pushing or opening/updating a PR, complete applicable tests, linters,
  and security review. Use the `adversarial-review` skill when available: exactly
  two independent, read-only, fresh-context reviewers per round, both inspecting
  this worktree's complete change against the original scope. Require two
  consecutive clean rounds; stop after ten rounds if unresolved. Do not create
  extra worktrees or user-facing tasks for review. If the skill is unavailable,
  report the limitation and arrange equivalent independent review before pushing.
- Monitor CI after submitting a PR; fix in-scope failures and revalidate before
  pushing again. Explain fixes to review feedback and resolve the corresponding
  comments after pushing. Do not claim checks or approvals that were not observed.