docs: 确立规格先行开发流程
This commit is contained in:
@@ -1,5 +1,23 @@
|
||||
# postgresql-tenant-operator - AI Agent Guide
|
||||
|
||||
## Specification-Driven Development
|
||||
|
||||
- Use specification-driven development for every new feature and externally observable
|
||||
behavior change: decide and document the contract before writing implementation code.
|
||||
- Create or update the relevant specification first. It must define scope, non-goals,
|
||||
observable behavior, validation, failure semantics, security boundaries, and acceptance
|
||||
criteria at the level needed for a human to make the pending decisions.
|
||||
- Stop after the specification reaches a reviewable state and ask the user to approve it
|
||||
before implementing the behavior. Approval of a plan, issue, or earlier specification
|
||||
does not imply approval of materially new decisions.
|
||||
- Derive tests from the approved acceptance criteria, then implement the smallest vertical
|
||||
slice that makes those tests pass. Keep specification, tests, and implementation
|
||||
traceable to one another.
|
||||
- If implementation exposes an ambiguity or requires changing the approved behavior, stop,
|
||||
update the specification, and request review again before continuing.
|
||||
- Keep specifications focused on contracts and decisions. Do not prematurely freeze internal
|
||||
Go package structure, function names, or SQL details unless they are part of the contract.
|
||||
|
||||
## Human-Reviewable Changes
|
||||
|
||||
- Break every feature into small, coherent changes that a human can review independently.
|
||||
|
||||
Reference in New Issue
Block a user