tuana-vn Current-State TDD Synthesis — 4.0
Mission
Produce the canonical consumer-facing current-system technical design:
docs/reverse-engineering/CURRENT_STATE_TDD.md
This document is the durable input for later Design Agent work.
The readiness audit is a separate artifact. Do not make an audit table the primary baseline document.
Consumer Test
A backend developer unfamiliar with the repository should be able to understand, within approximately 15–20 minutes:
- system boundary and purpose;
- major component responsibilities;
- dependency direction;
- primary runtime flows;
- external integration boundaries;
- state/persistence ownership;
- lifecycle/concurrency behavior;
- configuration/runtime selection;
- failure/error behavior;
- build/runtime structure;
- material unknowns and evidence anchors.
Required TDD Sections
Use these headings in this order:
# Current-State Technical Design
## 1. System Context
## 2. Architecture Overview
## 3. Component Responsibilities
## 4. Runtime Entry Points
## 5. Primary Runtime Flows
## 6. Integration Architecture
## 7. Persistence and State Ownership
## 8. Background Processing and Lifecycle
## 9. Configuration and Runtime Selection
## 10. Error, Retry, and Fallback Behavior
## 11. Security Boundaries
## 12. Observability
## 13. Build and Runtime Model
## 14. Critical Current-System Rules
## 15. Runtime Variants and Alternate Paths
## 16. Known Unknowns and External Blockers
## 17. Evidence and Diagram Index
If a section is not applicable, write NOT_APPLICABLE plus the evidence supporting that classification.
Diagram Integration
Reference the mandatory diagram artifacts from the relevant TDD sections:
diagrams/01_system_context.md
diagrams/02_component_architecture.md
diagrams/03_primary_runtime_sequence.md
diagrams/04_integration_boundaries.md
diagrams/05_state_persistence_lifecycle.md
Do not duplicate five large diagrams in every artifact. The TDD may embed the most important diagram and link the rest by repository-relative path.
Evidence Precision
Material current-state statements must use evidence precise enough to re-open quickly:
Preferred:
path + symbol/method/config key + optional line/range
Minimum for source-backed material claims:
repo-relative path
Class name alone is not a sufficient source anchor when a path can be determined.
Synthesis Rules
Prefer:
relationship > inventory
behavior > file count
responsibility > package list
runtime selection > implementation existence
state ownership > entity dump
consumer usability > audit verbosity
Large schema tables, exhaustive class inventories, and exhaustive evidence ledgers belong in supporting model/evidence artifacts. Summarize the important meaning in the TDD.
Completion Gate
Do not declare synthesis complete until:
[ ] all required sections exist
[ ] all 5 mandatory diagram artifacts exist and are referenced
[ ] all material subsystems are represented in component catalog
[ ] primary runtime flows are represented in runtime flow catalog
[ ] all known external integrations are represented in integration catalog
[ ] behavior-changing configuration selectors are represented in configuration model
[ ] persistence/state ownership is represented or explicitly NOT_APPLICABLE
[ ] material current-state claims use repo-relative evidence paths
[ ] unresolved HIGH/CRITICAL items remain explicit