Change a Large Multi-Language Data Platform Monorepo and Prepare Pull Requests

## Check the Git Remotes and Pick the Right Branch Before the First Edit Before the first edit or test in a session: 1. identify the personal fork and authoritative upstream remotes; if their roles are unclear, ask for the standard remote layout to be configured; 2. check the timestamp of the upstream default branch and refresh it when the local reference is stale; 3. inspect the working tree and ask the user to protect uncommitted changes before switching context; 4. choose the branch according to the task. For an existing review, resolve its head branch, use a matching local branch when one exists, and report the switch. If no match exists, ask whether to fetch it or use a differently named local branch. For new edits, offer an isolated worktree from the upstream default branch as the recommended option, or a new branch from that base. For test-only work, use the upstream default branch. ## Regenerate Golden Test Outputs and Protocol Files Instead of Editing Them Golden test outputs belong to their generating test harness. Read the suite documentation before running or updating them, never edit generated expectation files directly, and regenerate them through the supported workflow. Review the resulting diff carefully before accepting it. Protocol definitions belong to their schema source. Read the documentation stored with those definitions before changing messages or fields, and keep generated protocol artifacts out of hand-written edits. ## Keep Code in ASCII and Within the Line Limit Before CI Keep identifiers, code, and comments in ASCII unless the content of a string literal or test fixture genuinely requires other characters. Spot-check changed files for typographic dashes, smart quotes, ellipses, and non-breaking spaces, which often enter comments unnoticed. Keep source lines within the repository limit, commonly 100 characters. A fast scan of added and modified source files may approximate exemptions for imports, package declarations, and URLs, but it is only a hint. The language-specific linters remain authoritative. ## Pick the Smallest JVM Test Base That Covers the Test Select the smallest test base that provides the required behavior. Plain runtime or utility tests should use the core suite with only common timeout, temporary-file, logging, and error helpers. Logical-plan, analyzer, optimizer, or planner tests should use a plan-testing base without starting a SQL session. SQL or table tests should use the query-testing base and mix in an explicit session provider. Choose an in-process session for ordinary SQL tests and a warehouse-backed provider only when warehouse behavior is required. Do not pay for a broader fixture merely because nearby tests use it. ## Pick the Right Python Test Base for Local, Remote, and Mixed Tests Plain Python tests should use the standard unit-test base. Context-level tests may create a fresh execution context per test for isolation or reuse one per class for speed. SQL and DataFrame tests should use the shared classic-session base, while dataframe-extension tests may add columnar execution and specialized assertions. Remote-protocol tests require a separate decision: use a plan-only mock fixture when no server is needed, a reused remote session for real remote behavior, or a mixed classic-and-remote fixture for parity checks. Treat SQL utilities, structured-error assertions, and equality helpers as mixins or standalone helpers rather than test bases unless they create the required runtime. ## Build and Test Only the Changed Module, and Ask Before a Full Suite Run Builds and tests may be expensive. If the user explicitly requested tests, run them. Otherwise, before starting a long full-suite verification, ask whether more edits are expected. Prefer the repository's faster incremental build tool, compile only the affected module and its test code, and run a single suite or named case while iterating. Keep an incremental build shell open when that shortens repeated module tests. For Python suites that depend on a built backend, build the required feature profile first, activate the user-selected virtual environment or the documented default, and create that environment only when it is absent. Use the project test runner's suite and case selectors. ## List Every Failed CI Check Before Fixing Any One Enumerate every failed check for the review commit before investigating any one failure. A passing or absent test-summary check does not prove CI is green; linters, licenses, dependencies, compatibility checks, compilation, and documentation builds may fail through separate jobs without test annotations. For test jobs, use failure annotations to retrieve the suite, case, and message. For non-test jobs, identify the failed step and read that job's focused log. Avoid downloading very large sharded test logs when structured annotations already contain the useful evidence. ## Check Whether a Closed Pull Request Was Actually Merged Do not assume that a review marked closed was rejected. Some projects merge through custom tooling, so the hosting service may show a successfully merged review as closed with no native merged timestamp. Use the project's merge-status helper to determine whether the change landed and which primary or maintenance branches contain it. Treat open, merged, and closed-without-merge as distinct outcomes, and report missing authentication, shallow history, unknown reviews, or absent upstream remotes as environment limitations. ## Write Pull Request Titles and Descriptions in the Project's Format Follow the project's title convention for issue identifiers and component tags, including documented exceptions for draft, work-in-progress, minor, or trivial changes. Infer the title from the diff. When a required issue is missing, create it through the project helper with the exact component and either an issue type or a referenced parent, then display the created issue and fields prominently for review. Read the repository's pull-request template before drafting the description and complete every section. Use the full component name when the issue tracker requires it rather than the abbreviated title tag. ## Push Only to Your Fork and Ask Before Any Outside Writes Never push to the authoritative upstream repository; push only to the contributor's fork. Do not force-push or amend commits that are already remote unless the user explicitly requests it. If the remote branch advanced, fetch and rebase before pushing. Obtain explicit approval before external writes such as pushing commits, creating a pull request, creating an issue, or posting comments. Use the project's supported authenticated client. If it is unavailable, prepare a review URL or exact handoff instructions instead of bypassing the required workflow. ## Use the Version Number of the Branch That Ships the Change First When code needs a version annotation, configuration version, or compatibility exclusion, use the version of the branch where the change first ships and remove any snapshot suffix. For a review based on a maintenance branch, use that branch's version. For a review based on the primary branch, use the latest release branch's version when changes normally backport there. Use the primary branch's version only for primary-only work, such as a breaking or binary-incompatible change, or a dependency upgrade that does not justify a critical backport. If the shipping path is unclear, ask rather than inferring from the primary branch alone. ## Read the Project's Security Policy Before Reporting a Security Issue Before reporting a security issue, read the repository's security policy and threat model. Confirm the declared scope, excluded cases, and documented non-findings so a scanner result is evaluated against the project's actual guarantees. Keep security investigation separate from ordinary bug triage, preserve evidence, and do not expose credentials or sensitive local data while documenting a finding.