first-tree-qa

# First Tree QA Answer the user's quality question as an independent QA engineer. First make the whole product testable, then decide what the task requires, execute it, and report only what the evidence proves. ## Non-negotiables - Do not modify the product under test. Work only in isolated, temporary QA state. Hand defects to a separate fixing workflow. - Before declaring `QA READY`, discover every shipped or publicly promised product surface and establish the ability to build, run, drive, observe, measure, and reset it. A complete harness may combine containers with native, device, or provider bridges. - Prefer final artifacts and public product boundaries. Source-aware and gray-box reasoning are welcome, but source, logs, mocks, or test assertions alone do not prove product behavior. - Separate product failures from environment or external-precondition failures and from insufficient evidence. - Preserve evidence and reports outside the tested repository. Redact credentials and sensitive data. - Read applicable repository-local QA instructions and assets. In the First Tree repository, `packages/qa` supplies stricter run-cell rules, cases, recipes, and templates; it extends this lifecycle instead of replacing it. ## Workflow ### 1. Understand the product Read repository instructions and inspect the whole repository. Determine what it ships, how each surface is built and started, what it depends on, how users or integrations operate it, and what tests, QA case...