祝融说。

In the first eight chapters, you learned the complete system of 14 skills. We now enter a reconstruction supported by project materials to observe how those skills collaborate and how decision-makers choose under constraints. File and requirement-line counts are snapshots from the case. Claims not accompanied by commits, a repository, or acceptance records are not generalized into typical schedules or outcomes.

9.1 Case Background

Project: An Unnamed Drone System. This text reviews project materials from rebuilding a legacy system and compresses the collaboration for teaching. A real project does not imply that every dialogue and causal explanation is an unreconstructed first-hand record.

This case is different from the other chapters. The first eight chapters taught you "what to do in an ideal scenario." This chapter shows you "what actually happened in a real scenario." There is a gap between the two—and that gap is the most valuable part.

Project scale:

• Backend: Java + Spring Boot, 432 source files
• Frontend: Vue 3, 4 frontend applications (admin portal, institution portal, examiner portal, mini-program)
• Database: MySQL
• Deployment: Docker + GitHub Actions

Scenario: Rebuild a new system based on the old production system's interface and functionality.

Challenge: The old system had a 3,248-line functional description document. Every field needed to be compared to ensure no functionality was missed in the new system.

9.2 Key Decision Point 1: Requirements Analysis—Which Skill to Use

Facing the "legacy system migration" scenario, you might think: use the Requirements skill for requirements analysis.

But in a real project, this decision presented a choice: Use Requirements to analyze from scratch, or use Legacy Recon to restore requirements from the old system?

Reasons for choosing Requirements: Complete methodology, starting from Event Storming, deriving the requirements document layer by layer. Suitable for "from scratch" projects.

Reasons for choosing Legacy Recon: The old system already exists, and all features are already running. Rather than "re-analyzing," it is better to "compare field by field"—extract the old system's existing features and compare them against the new system's implementation to identify gaps.

Ultimately, Legacy Recon was chosen. The old system had a 3,248-line functional description document, plus complete interface screenshots—this information was more accurate and complete than any "re-analysis." Requirements requires business personnel to participate in discussions, whereas Legacy Recon only needs to compare against existing implementations.

The core logic of this decision: When existing information is more reliable than "re-analysis," prioritize using existing information. The old system was already running in production—its functional description is an accurate mapping of real requirements, more accurate than any "analysis."

Execution Process

Legacy Recon (Legacy System Reconnaissance) was the most appropriate skill. It is specifically designed for the "old system to new system" migration scenario.

First step: Create a task list. Break the 7 major business modules into independent audit tasks.

Second step: Parallel audit. Each module was audited by an independent sub-agent, comparing the old and new system implementations field by field and function by function.

Audit method:
1. Frontend code (admin-web/institution-web, etc.) checks interface implementation
2. Backend code (drone-* modules) checks API implementation
3. Database schema checks data model
4. Compile gaps: existing, missing, partially implemented

Third step: Produce a gap report. Prioritized by "foundation first," with all levels—high, medium, and low—included.

Output

Gap report:
- High priority: 15 items (affect core processes)
- Medium priority: 23 items (affect user experience)
- Low priority: 11 items (optimization)
- Third-party dependencies noted: 5 items (require external credentials, deferred)

9.3 Key Decision Point 2: Architecture Design—To Redesign or Not

After the gap report was produced, the team faced a second key decision: Redesign the architecture, or supplement functionality within the existing architecture?

Reasons for redesigning: The old system's architecture might have problems; rebuilding is the perfect time to optimize—reorganize modules, upgrade the tech stack, introduce new design patterns.

Reasons for supplementing within the existing architecture: The new system was already running in production, and the architecture had been proven stable. Redesigning would introduce uncertainty and risk—the new architecture might not be as stable as the old one, and the migration process could affect the live business.

Ultimately, the decision was to supplement within the existing architecture. The reason: all 49 gaps in the gap report were "missing features," not "architecture problems." If there are no architecture problems, there is no need to touch the architecture.

The core logic of this decision: The value of architecture design lies in solving problems, not in designing for the sake of design. If the problem is not at the architecture level, do not touch the architecture.

Execution Process

Based on the gap report, a repair roadmap was created. The roadmap did not involve architecture changes—it followed the existing system architecture, supplementing missing features within the existing framework. Architect (Architecture Design) was not essential—because this was not a from-scratch design, but rather supplementing features within the existing architecture. However, the Inspector approach was used in the audit phase.

The core principle of the repair roadmap:

9.4 Key Decision Point 3: Repair Tasks—To Use Workflow or Not

With the 49 gaps prioritized, the third key decision was: Should repair tasks use Workflow for automated execution, or Coach for manual guidance?

Reasons for choosing Workflow: Most of the 49 gaps were "supplementing missing features"—requirements were clear, technical solutions were straightforward, fitting Workflow's conditions perfectly.

Reasons for choosing Coach: Some repair tasks involved multi-module linked modifications, requiring multiple rounds of confirmation and adjustment. Coach's guided process was more suitable.

The final approach was a hybrid: for repair tasks with "clear requirements, single-module modifications," use Workflow's auto mode; for complex repair tasks involving "multiple modules needing confirmation," use Coach for manual guidance.

However, this decision encountered an adjustment along the way. A repair task involving frontend-backend collaboration was executed using Workflow's auto mode. After inspection, it was discovered that the frontend and backend had inconsistent API contracts—because Workflow, within a single milestone, only checked the correctness of that module, not cross-module interface consistency. The root cause was not Workflow itself, but that "the inspection criteria did not include cross-module checking." After adding "cross-module interface consistency check" to the inspection criteria, the problem never recurred.

A Typical Repair Task Execution Process

Task: Add the institution-end student batch import feature.

Step 1: Issue instructions

Need to implement the institution-end student batch import feature.

Requirements:
- Support Excel file upload
- Parse student data from Excel
- Batch write to database
- Return import results (success/failure details)

Technical constraints:
- Use existing Excel parsing tools
- Input validation rules consistent with single-add functionality
- Import results page shows success/failure lists

Step 2: Code AI automatically completed the coding, including file upload, Excel parsing, data validation, and batch writing.

Step 3: Inspect

• Functional check: Import functionality works, field validation correct
• Architecture check: No core code modified, data model consistent
• Security check: Upload file type validation, SQL injection protection

Conclusion: PASS, commit code.

Progress Management

Progress log (job.progress.md):

# Legacy System Feature Supplementation — Progress Log

## Completed
- [x] Institution-end: Student batch import (2026-07-13)
- [x] Institution-end: Qualification change records (2026-07-13)
- [x] Admin-end: Examiner assignment (2026-07-14)
- [x] Admin-end: Certificate printing management (2026-07-14)
- ...

## In Progress
- [ ] Institution-end: Financial report export

## To Do
- [ ] Admin-end: Data statistics dashboard
- [ ] Examiner-end: Scoring functionality

9.5 Key Decision Point 4: Integration Inspection—How to Prioritize Fixes

After all repair tasks passed individual inspection, integration inspection revealed two problems. This brought the fourth key decision: How to prioritize the fixes?

Reasons for "fix everything before deployment": The problems were small, but they were all "inconsistencies"—date format inconsistency, cache not refreshing in time. These "small inconsistencies" accumulate and degrade system quality.

Reasons for "fix critical issues before deployment, non-critical issues in subsequent iterations": Neither problem affected the core business process (student registration, exam, certification issuance). They could be fixed gradually after deployment.

The final approach was a compromise: Distinguish between "blocking" and "non-blocking" issues. The cache refresh issue was blocking—it affected users seeing the latest data, so it had to be fixed before deployment. The date format issue was non-blocking—it did not affect functionality, so it was scheduled for the next iteration.

The core logic of this decision: Not all problems need to be fixed in the same release. The ability to distinguish between "must fix now" and "can wait" is a judgment that comes from experience.

Integration Issues Found

Issue 1: After adding a student in the institution portal, the admin portal's student list does not update
→ Cause: Missing event to trigger cache refresh
→ Fix: Add cache refresh logic in the student creation API

Issue 2: Student data imported in batch displays inconsistent formatting on the frontend page
→ Cause: Inconsistent date format handling
→ Fix: Unify date formatting utility function

9.6 Key Decision Point 5: Deployment—How Much Automation

During the project deployment phase, the fifth key decision was: Should the deployment process be fully automated or semi-automated?

Reasons for full automation: Docker + GitHub Actions were already configured, enabling a complete CI/CD pipeline of "commit code, auto-build, auto-deploy."

Reasons for semi-automation: The project involved 4 frontend applications, 1 backend application, 2 databases, and 1 cache. The deployment process was complex. Full automation might lead to "it is automated, but no one dares to use it."

The final choice was semi-automation: auto-build plus manual deploy. GitHub Actions automatically handled building and testing, but deploying to production required manually executing a deploy.sh script.

The core logic of this decision: The purpose of automation is to reduce risk, not to increase it. If full automation makes you feel "out of control," leave one manual confirmation step. As the project stabilizes, the level of automation can be gradually increased.

Deployment Method

The project used Docker containerized deployment, including:

• MySQL database
• Redis cache
• Backend Java application
• Frontend Nginx reverse proxy

Deployment Script

A single deploy.sh script for one-click deployment on a fresh VPS:

• IP:Port mode: HTTP access
• Domain mode: Caddy auto HTTPS

9.7 Case Retrospective

Skills Used

Skills NOT Used

Key Lessons

1. The key to legacy system migration is "field-by-field comparison": Do not rely on documentation descriptions; compare the old and new systems' actual implementations field by field
2. Parallel auditing improves efficiency: 7 major business modules audited in parallel was 3 to 4 times faster than serial auditing
3. Execute by priority: Foundation first (data models, core interfaces), then user-visible features, then optimizations
4. Keep the progress log transparent: An append-only progress log lets everyone know the project status at any time

Chapter Summary

This case demonstrates the most important skill in real projects: making choices between multiple options and giving a reason for each choice. Five key decisions—using Legacy Recon instead of Requirements for requirements analysis, supplementing within the existing architecture instead of redesigning, using a hybrid of Workflow and Coach for repair tasks, distinguishing blocking from non-blocking issues during integration inspection, and choosing semi-automation over full automation for deployment—every decision was not "theoretically optimal," but rather "the most appropriate given the constraints of the situation." That is the value of experience: knowing when to use a skill, and more importantly, knowing when not to use one.