generated from john/python-template
gpt-5.3 codex review: Phase 7 and the addition of the new test-effectiveness-auditor skill.
Quality Gate / gate (push) Failing after 12s
Quality Gate / gate (push) Failing after 12s
This commit is contained in:
@@ -26,11 +26,15 @@ Perform thorough, evidence-based code reviews for Python projects. Every finding
|
||||
## Review Workflow
|
||||
|
||||
1. **Map the Repository First:** Inspect entry points, package layout, configurations, dependency manifests, and any project-specific rule files (`AGENTS.md`, `CLAUDE.md`, `.github/instructions/`). Project-specific conventions override generic advice.
|
||||
2. **Read Representative Modules:** Sample across all layers (routes/pages, UI components, services, workers, persistence, provider adapters, settings, tests) before drawing conclusions.
|
||||
3. **Verify Claims:** Run or reference project tooling (`ruff check`, `ty`, `pytest`) rather than guessing.
|
||||
4. **Prioritize Hot Paths:** Focus deeply on request handling, database sessions, background workers, and external API calls.
|
||||
5. **Enforce Read-Only Safety:** Do not modify code unless explicitly instructed.
|
||||
6. **Escalate Provenance Audits:** For evidence/provenance-heavy changes, apply invariant checks from `.github/skills/evidence-provenance-auditor/skill.md` and include pass/fail outcomes in the report.
|
||||
2. **Establish Canonical Authority First:** Read architecture/contracts (`docs/ver4/*`, `docs/invariant/*`, UI docs) and active instructions/skills before evaluating source behavior.
|
||||
3. **Read Representative Modules:** Sample across all layers (routes/pages, UI components, services, workers, persistence, provider adapters, settings, tests) before drawing conclusions.
|
||||
4. **Run Drift Analysis:** Compare documented intended behavior versus repository ground truth; identify both implementation drift and undocumented-but-repeatable conventions that should be formalized.
|
||||
5. **Assess Boundary and Coupling Health:** Evaluate UI/service/persistence/provider dependency flow, identify circular dependencies, leaky abstractions, and transaction ownership ambiguity.
|
||||
6. **Assess Invariant Placement:** For each hard rule, decide whether it belongs in docs (rationale), instructions (active steering), skills (periodic audit procedure), or deterministic tests (enforcement).
|
||||
7. **Verify Claims:** Run or reference project tooling (`ruff check`, `ty`, `pytest`) rather than guessing.
|
||||
8. **Prioritize Hot Paths:** Focus deeply on request handling, database sessions, background workers, and external API calls.
|
||||
9. **Enforce Read-Only Safety:** Do not modify code unless explicitly instructed.
|
||||
10. **Escalate Provenance Audits:** For evidence/provenance-heavy changes, apply invariant checks from `.github/skills/evidence-provenance-auditor/skill.md` and include pass/fail outcomes in the report.
|
||||
|
||||
## Repo-Specific Deterministic Checks (Transcription)
|
||||
|
||||
@@ -89,6 +93,12 @@ When reviewing this repository, always include explicit pass/fail checks for:
|
||||
### 9. Duplication & Consolidation
|
||||
- Identify repeated code blocks, candidate helper abstractions, divergent patterns for identical operations, and duplicated domain constants.
|
||||
|
||||
### 10. Architecture & Governance
|
||||
- **Architectural Drift:** Compare intended architecture rules against implementation behavior and cite concrete drift points.
|
||||
- **Systemic Health:** Evaluate domain cohesion, dependency direction, lifecycle consistency, and operational reliability seams.
|
||||
- **Invariant Routing:** Recommend the correct enforcement layer per rule (docs vs instructions vs skills vs tests).
|
||||
- **Meta-Tooling Alignment:** Recommend updates for instruction files and skills when repository patterns or contracts evolve.
|
||||
|
||||
## Output Report Structure & Template
|
||||
|
||||
Generate Markdown reports in `./docs` following this exact template structure:
|
||||
@@ -106,7 +116,13 @@ Generate Markdown reports in `./docs` following this exact template structure:
|
||||
|
||||
---
|
||||
|
||||
## 2. Findings by Severity
|
||||
## 2. Executive Architecture Assessment
|
||||
- High-level verdict on domain cohesion, boundary clarity, and architecture fitness.
|
||||
- Top 3-5 systemic risks or bottlenecks.
|
||||
|
||||
---
|
||||
|
||||
## 3. Findings by Severity
|
||||
|
||||
### Critical Severity
|
||||
#### [CRIT-01] Title
|
||||
@@ -129,7 +145,19 @@ Generate Markdown reports in `./docs` following this exact template structure:
|
||||
|
||||
---
|
||||
|
||||
## 3. Stack-Specific Analysis
|
||||
## 4. Architectural Drift & Gap Analysis
|
||||
| Area / Component | Documented / Intended Rule | Actual Implementation State | Severity | Recommended Resolution |
|
||||
| :--- | :--- | :--- | :--- | :--- |
|
||||
|
||||
---
|
||||
|
||||
## 5. Invariant Inventory & Routing Recommendations
|
||||
| Invariant / Constraint | Current Location | Recommended Target Layer | Rationale |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
|
||||
---
|
||||
|
||||
## 6. Stack-Specific Analysis
|
||||
- Python 3.12+ Best Practices
|
||||
- FastAPI
|
||||
- NiceGUI
|
||||
@@ -141,7 +169,7 @@ Generate Markdown reports in `./docs` following this exact template structure:
|
||||
|
||||
---
|
||||
|
||||
## 4. Duplication & Consolidation Report
|
||||
## 7. Duplication & Consolidation Report
|
||||
| Pattern / Duplication | Locations | Proposed Canonical Home | Estimated Lines Removed |
|
||||
| :--- | :--- | :--- | :--- |
|
||||
|
||||
@@ -150,12 +178,19 @@ Generate Markdown reports in `./docs` following this exact template structure:
|
||||
|
||||
---
|
||||
|
||||
## 5. Prioritized Action Plan
|
||||
1. **Phase 1: Quick Wins (PR 1-2)**
|
||||
2. **Phase 2: Reliability & Concurrency (PR 3-4)**
|
||||
3. **Phase 3: Consolidation & Refactoring (PR 5-6)**
|
||||
## 8. Meta-Tooling & Instruction Update Recommendations
|
||||
- Required updates to docs/instructions/skills/tests to keep enforcement current.
|
||||
|
||||
---
|
||||
|
||||
## 6. Preserved Strengths
|
||||
## 9. Prioritized Dependency-Ordered Action Plan
|
||||
1. **Phase 1: Blocking fixes**
|
||||
2. **Phase 2: Enforcement hardening**
|
||||
3. **Phase 3: Reliability & concurrency**
|
||||
4. **Phase 4: Consolidation & refactoring**
|
||||
5. **Phase 5: Non-blocking governance/documentation depth**
|
||||
|
||||
---
|
||||
|
||||
## 10. Preserved Strengths
|
||||
- Existing patterns worth maintaining.
|
||||
Reference in New Issue
Block a user