Create Review

Create a Phorge review for the current branch using arc diff --create.

Confidentiality — read before you write anything

Treat Phorge as public. Two reasons: (1) Phorge revisions and the Jenkins logs they trigger are visible to anyone with company access, not just the reviewers you @-mention; (2) anything you put into the test code, code comments, fixtures, or golden outputs on this diff lands on the public GitHub repo verbatim when this work is later upstreamed via a PR — there is no separate scrubbing pass at that boundary. So apply the public-repo rules now: diff title, summary, test plan, inline comments, commit messages, code, tests, fixtures, golden output, and filenames all get the same treatment as a public GitHub PR.

Never put any of the following into the diff title, summary, test plan, Phorge comments, commit messages, code comments, test code, test fixtures, golden output, or filenames:

• Customer-identifying data — company names, account IDs, universe/cluster names or UUIDs, support case numbers, environment names, region/zone names tied to a customer deployment. Substitute with customer-1, acme-corp, or a generic description.
• PII — real names, real emails, real phone numbers, real postal addresses, real IP addresses (public or private). In tests use only the documentation ranges: IPv4 192.0.2.0/24 / 198.51.100.0/24 / 203.0.113.0/24 (RFC 5737), IPv6 2001:db8::/32 (RFC 3849), hostnames example.com / example.org / example.net (RFC 2606), names Alice/Bob/Carol, phone numbers 555-0100–555-0199.
• Unanonymized customer schema or queries — table names, column names, SQL text, query plans, or sample rows pulled from a real customer report. Reconstruct a synthetic minimal reproducer with generic identifiers (t1, users, id, value) that demonstrates the same defect.
• Secrets / credentials — API keys, tokens, passwords, TLS certificates, private keys, license keys, kubeconfigs, production S3 buckets, internal Slack/JIRA/Linear URLs (other than referencing them by ticket key like PLAT-20518), internal hostnames, vault paths. Use placeholders like AKIAIOSFODNN7EXAMPLE in mocks.
• YugabyteDB-internal information not yet public — unreleased roadmap, internal SLAs, embargoed security findings, internal infra hostnames.

This applies to the test code and test data you write too — .cc, .py, .java, .sql, golden .out files, YAML fixtures, mock responses. If a customer's reproducer uses acme_orders with a customer_email column populated with real addresses, rewrite it as t1/email with user@example.com before the test goes anywhere near a diff.

When the source is a customer report: read the original from the internal source (JIRA / support ticket / Slack) — don't paste or link it. Reproduce locally with synthetic inputs. Land only the synthetic reproducer. Reference the issue by internal ticket ID (PLAT-20518) only.