Code Review

Code Review

/code-review 是 CFG 的代码质量入口。它是只读审查，不修改文件。

It also covers former technical-debt, perf-profile, and security-audit concerns when the concern is tied to code or architecture changes.

For broad release readiness, route to /release-checklist. For runtime evidence failures, route to B-dev through the active work order and lane state. Do not route to removed sprint/story/smoke commands.

Required Context

Read:

• target files in full
• AGENTS.md
• .codex/docs/technical-preferences.md
• relevant docs/architecture/*.md
• relevant production/work-orders/*.md if the user provided one or the touched paths clearly belong to one
• relevant B-dev evidence/report if present

If a work order path is supplied, read it first to extract:

• scope and non-scope
• delivery spec
• stop conditions
• evidence requirements
• ADR/canon references

If no work order or ADR is found, say so and continue with a code-only review.

CFG Specialist Policy

The inherited 49 CCGS agent files are not active. Do not read .codex/agents/. Apply engine, shader, UI, architecture, security, performance, and testability lenses directly in-session.

Review Checklist

Work Order Compliance

• implementation stays inside Scope and Non-scope
• delivery spec is satisfied or gaps are named
• stop conditions were not ignored
• evidence hooks or validation paths exist

ADR And Architecture Compliance

• referenced ADRs are followed
• implementation does not contradict accepted architecture
• Godot node/resource/autoload ownership is clear
• signals/events do not create hidden circular dependencies
• save/load, input, physics, and scene lifecycle obey project rules

Standards

• methods/classes have appropriate names and comments where useful
• complexity is reasonable
• dependencies are explicit
• configuration values are data/config driven when appropriate
• generated/imported assets are not treated as source logic

Testability And Evidence

• B-dev can validate the change with an available command, scene, test, capture, or manual step
• important behavior has an observable runtime path
• acceptance criteria from the work order are testable
• no new edge case is introduced without evidence or follow-up owner

Performance And Safety

• no avoidable allocations in hot paths
• frame-rate and physics timing are handled correctly
• file IO, save data, networking, and external data are validated
• error states fail clearly rather than silently corrupting state

Output

Findings first, ordered by severity. Use file/line references.

## Code Review: [target]

Findings:
- [P0/P1/P2/P3] [file:line] [issue, impact, required fix]

Open Questions:
- [only if needed]

Work Order / ADR Compliance:
- [COMPLIANT / DRIFT / VIOLATION / NOT PROVIDED]

Testability:
- [TESTABLE / GAPS / BLOCKING / N/A]

Summary:
- [short change/context summary]

Verdict: APPROVED / APPROVED WITH CONCERNS / CHANGES REQUIRED

If no issues are found, say that clearly and mention residual risk or unrun tests.

Next Step

After the review:

• If approved and tied to an active work order, hand back to the owning lane for delivery/verdict.
• If changes are required, route to B-dev for code fixes.
• If architecture is wrong or missing, route to /create-architecture.
• If the issue affects player-facing feel, visual quality, or canon, request D-director verdict.

Do not ask the user to run removed story/sprint completion commands.

Source: ailess-lab/CodexForGodot — distributed by TomeVault.