Request zh-Hans public-RC backend fixture approval and redacted evidence

[Drew1811266]

Request: zh-Hans public-RC backend fixture approval and redacted evidence

Context

Warp CN is preparing a formal Simplified Chinese public-RC release. Source-level localization is already tracked separately; the remaining release gate for this lane is evidence for five backend-fixture GUI rows.

This issue asks for fixture owner approval and reviewed redacted text evidence only. It does not request production mutation, real credentials, payment methods, credit purchases, real quota consumption, or raw evidence in Git.

Rows

Row	Fixture target	Evidence needed	Safety boundary
GUI-BILL-01	zh-rc19-billing-cloud-fixture	safe quota or billing fixture; redacted billing GUI evidence; fixture reset proof	no credit purchase, no payment method, no real quota consumption
GUI-BILL-02	zh-rc19-billing-cloud-fixture	backend test team with build-plan migration state; redacted modal GUI evidence; backend flag reset proof	backend test state only, no production team or billing mutation
GUI-CLOUD-01	zh-rc19-billing-cloud-fixture	controlled capacity or quota fixture; redacted cloud capacity GUI evidence; fixture reset proof	no production cloud capacity creation, deletion, or exhaustion
GUI-SET-04	zh-rc19-aws-fixture	disposable AWS or Bedrock fixture; redacted settings GUI evidence; fixture reset proof	no real AWS credentials, no real profile names
GUI-SET-05	zh-smoke-invalid-token	invalid credential fixture; redacted error GUI evidence; fixture reset proof	safe invalid marker values only, no real API keys or provider credentials

Requested owner approval packet

Please provide one packet per row, keeping private identifiers outside Git:

row_id:
fixture_name:
fixture_owner:
approval: approved-for-zh-Hans-public-RC-evidence
allowed_mutations:
reset_procedure:
cleanup_proof_format:
redaction_requirements:
expiration_or_teardown_date:
production_impact_statement: no production object is affected
main_account_statement: main account was not used
raw_evidence_location: outside Git only
reviewer:
reviewed_at:

Redacted candidate text requirements

After raw evidence is reviewed outside Git, provide redacted text with:

row_id:
profile:
visible_anchors:
redaction:
cleanup_proof:
safety_confirmation:
artifact_kind: redacted-text

The visible_anchors field must include Chinese UI text. The safety_confirmation field must explicitly state that the main account was not used.

Redaction boundary

Do not include raw screenshots, recordings, callback URLs, endpoint URLs, cookies, tokens, API keys, account identifiers, team IDs, billing IDs, private object names, local paths, browser state, real AWS profile names, or real credential values.

Promotion gate

No row will be promoted until:

fixture owner approval exists outside Git
raw evidence has been reviewed outside Git
redacted candidate text exists outside Git
candidate preflight returns candidate-ready-for-human-review
human reviewer approves the redacted artifact text
cleanup proof is present
strict artifact lint passes after artifact promotion

[oz-for-oss]

@Drew1811266

Here's what I found while triaging this issue:

This looks like a private fixture/evidence approval request, not a reproducible Warp client bug. Billing/account/backend fixture approvals and raw evidence review should be handled outside public GitHub through Warp support or the relevant internal owner channel.

I have a few follow-up questions before I can narrow this down:

1. Is there a specific user-facing Warp behavior failing in the zh-Hans RC, or is this only a private fixture/evidence approval request?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that the issue requests private zh-Hans RC backend fixture approvals/evidence rather than reporting a reproducible public Warp client bug..

Triage summary

This issue requests owner approval and reviewed redacted evidence for five zh-Hans public-RC backend fixture rows spanning billing, cloud-agent capacity, and AWS/Bedrock settings. It does not include an observed Warp client failure, reproduction steps, environment details, logs, screenshots, or a public artifact that can be reproduced from the issue alone.

Initial assessment

• This looks like a private fixture/evidence approval workflow rather than a confirmed bug in the public Warp client repository.
• The named fixture targets and row IDs were not found in the public client codebase during targeted search.
• The closest public client surfaces are billing/usage UI, cloud-agent capacity/build-plan modals, and AWS Bedrock credential/settings UI, but the requested approvals and raw evidence review appear to depend on private backend/test ownership outside this repository.

Reproducibility

Unknown. There is no concrete failing behavior or repro path to run, and the request is explicitly backend/account-sensitive.

Likely root cause

No client-side root cause is confirmed. The actionable blocker appears to be private fixture ownership and evidence-review coordination, not source-level localization or a narrow code defect.

Duplicate check

I searched all open non-PR issues and recently closed issues for the specific fixture, row, public-RC, redacted-evidence, and zh-Hans terms. I did not find two or more likely duplicates. The existing Simplified Chinese localization tracking issue #10928 is adjacent but not a duplicate because this report says source-level localization is already tracked elsewhere.

Question reasoning

1. Is there a specific user-facing Warp behavior failing in the zh-Hans RC, or is this only a private fixture/evidence approval request? — The current report spans private billing/cloud/settings fixtures but does not identify a public product bug or feature gap, so this determines whether the issue can be routed as public client work or should move to private support/internal coordination.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[Drew1811266]

@oz-for-oss Thanks for the triage. To answer the follow-up question:

There is no specific user-facing Warp client behavior failing in the zh-Hans RC being reported here. This issue is only a private release-evidence / fixture-owner approval request for the zh-Hans public-RC process.

I agree this should not include raw fixture data, account identifiers, backend object details, or candidate evidence in a public GitHub issue. We will route the sensitive approval and reviewed redacted evidence through Warp support or the appropriate internal owner channel instead.

If maintainers prefer, this issue can be closed as not actionable for the public client repo, or left only as a public routing record. The remaining action from our side is to find the correct private owner/support channel for:

• backend fixture owner approval
• reviewed redacted evidence acceptance
• any required cleanup/retention proof

No public client bug is currently being claimed in this thread. If there is a preferred support route for this category, please point us there; otherwise we will move it out of public GitHub.

[oz-for-oss]

@Drew1811266

Thanks for confirming. Since this is a private zh-Hans RC release-evidence / fixture-owner approval request and not a failing public Warp client behavior, please keep raw fixture data, account identifiers, backend object details, and evidence out of GitHub.

For routing, use a private support channel rather than the public client repo: start with support@warp.dev for subscriber technical/credits or backend-routing help, billing@warp.dev only if a billing/accounting decision is involved, or your Enterprise/account-manager Slack channel if this is tied to an Enterprise or internal test-team process. Maintainers can close this as not actionable for the public client repo, or leave it only as a public routing record.

Reasoning

Response mode selected because the triggering comment answers the prior follow-up and asks a specific routing question on an already-triaged issue; per the response schema, this artifact should not change labels. The original report and follow-up state that no public Warp client behavior is failing; the request is for private backend fixture owner approval and redacted release-evidence acceptance. Repository-local triage guidance says billing/account-sensitive requests should be routed through support channels rather than triaged as actionable public bug/feature work, and it warns not to ask for private account identifiers in public. Docs support this routing: docs/src/content/docs/support-and-community/troubleshooting-and-support/sending-us-feedback.mdx lists support@warp.dev for subscriber technical/credits questions, billing@warp.dev for billing questions, and Enterprise designated Slack channels for Enterprise issues. Public repo inspection did not find the named fixture strings (zh-rc19-billing-cloud-fixture, zh-rc19-aws-fixture, zh-smoke-invalid-token) or the candidate gate phrase, so there is no code-level owner inferred from the public client checkout. Duplicate detection enumerated 3,608 open issues and 56 recently closed issues; high-signal matches were broad i18n/localization tracking (#10928, #1194), unrelated Simplified Chinese UI behavior (#11993), or unrelated use of fixture terminology (#11529), so no duplicate cluster met the two-candidate threshold.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz