mirror of
https://github.com/tradecatlabs/vibe-coding-cn.git
synced 2026-08-19 05:48:04 +00:00
79 lines
3.7 KiB
Markdown
79 lines
3.7 KiB
Markdown
|
# Task Description: System Analysis and Visual Modeling of a Specified Project Repository
|
||
|
|
|
||
|
|
## Role Setting
|
||
|
|
You are a **senior software architect / system analysis expert**, capable of performing architectural reverse engineering, system abstraction, and technical documentation generation from actual code repositories.
|
||
|
|
|
||
|
|
## Analysis Object
|
||
|
|
- **The analysis object is NOT the preconceived concept of "microservice system"**
|
||
|
|
- The analysis object is: **the project code repository I specify**
|
||
|
|
- Project forms may include (but are not limited to):
|
||
|
|
- Monolithic application
|
||
|
|
- Microservice architecture
|
||
|
|
- Modular system
|
||
|
|
- Hybrid architecture (monolithic + service-oriented)
|
||
|
|
- You need to determine its architectural form based on **the actual repository structure and code facts**, rather than a priori assumptions.
|
||
|
|
|
||
|
|
## Overall Goal
|
||
|
|
Perform system-level analysis of the **specified project repository** and generate **ASCII character-rendered visualization diagrams** to understand the system structure and operational flow.
|
||
|
|
|
||
|
|
## Analysis Task Requirements
|
||
|
|
|
||
|
|
### 1. System and Architecture Identification
|
||
|
|
- Identify from the repository:
|
||
|
|
- Module / service / subsystem boundaries
|
||
|
|
- Core responsibilities of each component
|
||
|
|
- Determine and explain:
|
||
|
|
- Architectural style (e.g., monolithic, microservice, layered architecture, event-driven, etc.)
|
||
|
|
- Dependencies and invocation methods between components
|
||
|
|
- Do not make any unsubstantiated assumptions about the architectural type.
|
||
|
|
|
||
|
|
### 2. Key Process Analysis
|
||
|
|
- Select a **representative core business process or main system flow**
|
||
|
|
- Clarify:
|
||
|
|
- Call start and end points
|
||
|
|
- Involved modules / services / components in between
|
||
|
|
- Synchronous and asynchronous interaction relationships (if any)
|
||
|
|
|
||
|
|
## Visualization Output Requirements (ASCII)
|
||
|
|
|
||
|
|
### 3. Sequence Diagram
|
||
|
|
- Draw based on actual code and call relationships
|
||
|
|
- Display:
|
||
|
|
- Call order
|
||
|
|
- Request / response direction
|
||
|
|
- Involved modules, services, or components
|
||
|
|
- Use **pure ASCII characters**
|
||
|
|
- Ensure alignment and readability in a monospaced font environment
|
||
|
|
- Do not introduce any external drawing syntax (such as Mermaid, PlantUML)
|
||
|
|
|
||
|
|
### 4. System Structure Diagram (System / Architecture Diagram)
|
||
|
|
- Show the overall system composition from a holistic perspective:
|
||
|
|
- Modules / services
|
||
|
|
- External dependencies (e.g., databases, message queues, third-party APIs)
|
||
|
|
- Infrastructure components (if any)
|
||
|
|
- Clearly define logical layers or physical boundaries (if identifiable)
|
||
|
|
- Use **pure ASCII characters**, emphasizing clarity of structure and relationships.
|
||
|
|
|
||
|
|
## File Output Specification
|
||
|
|
- Sequence diagrams and system diagrams **must be output independently as files**
|
||
|
|
- Save location: **Project root directory**
|
||
|
|
- Recommended filenames (can be adjusted according to actual project):
|
||
|
|
- `sequence_diagram.txt`
|
||
|
|
- `system_architecture.txt`
|
||
|
|
- Each file **only contains the corresponding ASCII diagram content**
|
||
|
|
- Do not mix explanatory text into the files.
|
||
|
|
|
||
|
|
## Expression and Style Requirements
|
||
|
|
- Use **professional, rigorous technical documentation language**
|
||
|
|
- Descriptions must be based on code facts, without speculative extensions.
|
||
|
|
- If there are insufficient details, it must be clearly marked as:
|
||
|
|
- "Assumption based on currently visible information in the repository"
|
||
|
|
|
||
|
|
## Constraints
|
||
|
|
- Prohibit the use of images, screenshots, or rich text graphics.
|
||
|
|
- Prohibit the use of Markdown charts or any non-ASCII expressions.
|
||
|
|
- All diagrams must be directly savable, maintainable long-term, and usable in code repositories.
|
||
|
|
|
||
|
|
## Final Goal
|
||
|
|
Output a set of **system-level ASCII visualization results strictly based on the specified project repository**, to help developers, reviewers, or maintainers quickly and accurately understand the project's structure and operational logic.
|