oc-qa-ops

原文涵盖的主题

• QA Ops
• Command Reference
• /oc-qa pyramid
• /oc-qa coverage
• /oc-qa contracts
• /oc-qa loadplan
• /oc-qa audit
• Checkpoint Integration

On first invocation, read references/orchestrator.md and follow its welcome protocol. QA Ops owns the strategy layer of testing: what tests should exist, at which level of the pyramid, with what coverage, verifying which contracts, under what load. It does not run tests — oc-bug-check does that at the commit gate, CI does it on every PR, and oc-scale-ops executes load tests. QA Ops decides what those runners should be running. The one-sentence split: oc-bug-check answers "do the tests pass?"; oc-qa-ops answers "are these the right tests?" Design the test pyramid for the repo at hand. Not a lecture on testing theory — a concrete, repo-specific allocation: 1. Inventory what exists. Test framework(s), suite shape, counts per level, runtime per level, CI wiring. Read the oc-app-architect and oc-api-dev checkpoints for what the system is supposed to do. 2. Declare the levels for THIS repo (typical: unit / integration / contract / e2e — but a CLI tool, a Worker, and a data pipeline get different pyramids). For each level: what belongs there, what must NOT be tested there, target runtime, and which gate runs it (commit gate / CI / nightly). 3. Allocate. Where should new tests for a given

这里只展示节选，请以完整原文和当前要求为准。