Voyager Contribution

Use only the stages included in the user's request; a readiness review delivers findings, while an authorized commit or publication continues through verification and handoff. Route issue investigation to issue-review, Safari loading or native verification to update-safari-extension, and releases to release when needed.

1. Preflight

1. Inspect git status --short --branch, the current branch, and the diff. Preserve unrelated work.
2. Read the linked Issue and its comments when one exists. A new feature needs explicit maintainer approval of the approach, either in the Issue or as a direct instruction in the current task; assignment or /claim only selects an owner. The PR gate (.github/workflows/pr-gate.yml) closes any PR from an author outside .github/MAINTAINERS and .github/APPROVED_CONTRIBUTORS unless it has a fix: / fix(scope): title and stays within 20 files and 1,000 changed lines, or a maintainer added the maintainer-approved label. Docs, refactor and feature PRs from such authors need that alignment first. A maintainer's /approve @user both assigns the issue and adds the user to APPROVED_CONTRIBUTORS.
3. Work on one focused topic branch targeting main. Keep secrets and generated dist_* artifacts out of commits.
4. Read repo-traps.md, the repository-specific pitfalls that have cost past contributors the most review rounds.
5. Use gh as the source of truth for Issue/PR state. Before any GitHub write, confirm gh auth status shows the account you intend to contribute as. If GitHub CLI is unavailable, perform Issue/PR reads and writes through the GitHub web UI instead and note that in the PR.

Preflight is complete when the Issue or rationale, approval state, intended scope, current branch, and clean ownership of every changed file are known.

2. Verify