Python engineering checks

Use the existing project policy and runtime as authority. Answer routine syntax and small implementation questions directly; load a reference only for a concrete uncertainty or failure mode.

Work from the affected contract

1. Read affected callers and pyproject/tool configuration; establish supported Python/library versions and the intended behavior.
2. For type/lint repair, capture the current diagnostic, fix its cause with a focused change and preserve public/runtime behavior. A justified narrow suppression needs a reason; blanket disabling is not a repair.
3. For concurrency, trace task ownership, cancellation, cleanup and blocking calls. For performance, identify a representative workload and measure the relevant bottleneck.
4. Respect existing packaging/environment tools and dependency policy. For arrays, check shape/dtype/missingness/copy behavior; for Textual, inspect compose/mount/reactivity and event-loop ownership.
5. Run affected diagnostics and meaningful behavior checks. Record executed commands/results and unresolved compatibility or environment gaps.

Scope and completion

Deliver the requested change or explanation with necessary evidence. Do not introduce a tool migration, ML platform, complete test strategy or mandatory specialist handoff for a local Python repair. Use ML-production/LLM packs only for model-specific lifecycle questions.

Use the user’s existing intent and authorization. Ask only for missing information that materially changes the result; use additional reviewers when they address a concrete uncertainty. Treat unavailable checks as gaps rather than successful verification.

Focused references