Backend · Agent · AI Programming

A Four-Part AI Coding Spec That Enforces DDD Layers, Auto-Review, and Test Compliance

By 王中阳AI编程 · Jul 8, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Most AI-coding setups rely on a single system prompt that degrades as context grows. This approach splits constraints into always-on rules, on-demand skills, and isolated subagents, so enforcement stays sharp and context windows stay clean across long sessions.

Summary

A `.trae/` configuration suite turns team coding standards into machine-enforceable constraints for AI-assisted development. Rules files injected into every conversation prevent cross-layer calls—handlers cannot touch databases, services cannot import HTTP frameworks. Two skills, `/gen-plan` and `/layer-check`, standardize planning and dependency validation, while two subagents with independent context windows automatically review plans for technical risk and run compilation, test, and compliance checks before merge requests.

The system targets five common AI-coding failures: layer confusion, inconsistent quality, missing planning, context-window pollution, and style drift across developers. A `hooks.json` file injects a specification reminder on every user message, and a `layer_rules.json` configuration defines 29 layer mappings with hard BLOCK rules for the four core DDD layers.

A complete workflow walks through adding an alert query endpoint: verbal requirement, plan generation, automated plan review, administrator sign-off, rule-guided coding, layer check, automated test-compliance scan, and MR submission. The spec also catalogs existing technical debt—config importing rag internals, middleware depending on repositories—that new code must not replicate.

Takeaways

— All `.trae/rules/` Markdown files are always-applied and injected into every AI conversation, enforcing per-layer constraints automatically.

— Four hard BLOCK rules prevent handlers from touching databases or models, services from importing HTTP, repositories from depending upward, and the Milvus retrieval core from any business-layer dependency.

— The `/gen-plan` skill produces a standardized development plan with layer placement, interface contracts, test requirements, and an acceptance checklist, saved to `Docs/`.

— The `plan-review` subagent runs in an isolated context and assesses technical feasibility, identifies architectural and security risks with severity labels, and supplements boundary and exception test cases.

— The `test-compliance` subagent runs `go build`, `go test`, and a compliance scan against the rules files, then auto-fixes missing comments, unwrapped errors, and naming violations.

— A `hooks.json` UserPromptSubmit hook injects a stack-and-standards reminder on every message, so the AI never forgets the dual Go/Next.js stack or the layering rules.

— Known technical debt—config importing rag internals, middleware depending on repositories—is cataloged with severity levels, and new code is explicitly forbidden from repeating those patterns.

Conclusions

The architecture treats the AI as an unreliable junior developer who needs guardrails, not a partner who can be trusted with a single prompt. Rules, skills, subagents, and hooks each close a different failure mode.

Splitting plan review and test compliance into subagents with independent context windows solves a real problem: long analysis tasks that would otherwise eat the main conversation's token budget and dilute attention on the actual coding task.

The `layer_rules.json` design is pragmatic—only four core DDD layers get hard BLOCK rules, while infrastructure layers get a softer `needs-review` flag. Over-constraining before a DDD refactoring is complete would create false positives that developers learn to ignore.

Cataloging existing technical debt inside the spec itself, with a rule that new code must not repeat those patterns, turns the spec into a living document that tightens over time rather than a one-time write-up.

Concepts & terms

SOLO Agent

An AI agent that orchestrates subagents by matching user intent to subagent descriptions, delegating tasks to specialized agents with independent context windows.

DDD layering (Handler/Service/Repository/Domain)

A dependency-direction discipline where HTTP handlers only handle request-response, services contain business logic, repositories abstract data access, and domain objects carry zero infrastructure dependencies.

layer_rules.json

A configuration file mapping file paths to architectural layers, with allowed and forbidden_cross dependency lists. Hard BLOCK rules stop the AI from importing across forbidden boundaries; unlisted imports get a needs-review flag.

always-applied rules

Markdown files in `.trae/rules/` that are automatically injected into the AI's context at the start of every conversation, ensuring constraints are present without the developer re-stating them.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗