PoC NEXA｜Fabbi 2026-06-13

Bộ chỉ số đánh giá hiệu quả áp dụng NEXA - Tài liệu giải thích

Người nhận: Thiên (POC Leader) · Người soạn: facon (điều phối SDLC + AI adoption) · Ngày: 2026-06-13

Mục đích: giải thích đầy đủ, dễ hiểu cơ chế chấm điểm hiệu quả NEXA để trình bày lại với khách hàng.

Nguyên tắc nền: mọi con số đều truy được nguồn; số chưa đo ghi rõ "chưa đo"; không bịa số.

⭐ Tóm tắt cho lãnh đạo (đọc 30 giây)

Bản chất tài liệu này: đây là khung đo lường + nền chất lượng hiện tại, KHÔNG phải báo cáo kết quả cuối. Hai con số khách hỏi trực tiếp (giảm bao nhiêu %, AI đúng bao nhiêu %) sẽ có dần qua các mốc M1-M4 trong quá trình làm, đo bằng cơ chế khách quan đã dựng sẵn.

Ba ý chốt khi đứng trước khách:

AI tham gia 4 nhóm công đoạn (trích xuất tri thức source cũ, sinh tài liệu thiết kế, sinh code, sinh test). Ta đo riêng từng công đoạn rồi mới gộp - để công bằng và biết chỗ nào cần cải thiện.
Chất lượng: bằng chứng cứng nhất = mapping legacy 100%; UI + hành vi đang đo, có cảnh báo trung thực. Bằng chứng cứng (engine tự sinh): mapping legacy 100% (C3, ArchUnit, 4/4 màn, đo tươi) - chắc. UI vs prototype (C2): đo LIVE ra 2/4 PASS (CM71060 + CM05110 đạt 100%; CM06010 81% / CM30020 83.3% có vài leak thật cần fix); số "100%" cũ là json STALE, đã đính chính. Chỉ số sâu phủ một phần: cấu trúc DDD đã audit 4/4 màn (4/4 gate PASS, 0 gateable P1 sau khi sửa 2 false-positive của engine ở CM71060), parity hành vi cũ/mới (C6) đạt 5/5 PASS (100%) trên 3 màn (enum/mapping nghiệp vụ tất định, golden từ legacy source) - cơ chế nghiệm thu cốt lõi đã chạy thật, đang mở rộng sang SQL/proc. Nói đúng: "mapping legacy + parity-mapping đã chứng minh; UI live đang sửa lỗi lộ ra; KHÔNG tô 100%".
Tỷ lệ "AI đúng bao nhiêu %" và "tiết kiệm bao nhiêu %": đang được đo, chưa công bố số. Ta từ chối bịa số ngược - đây là kỷ luật trung thực, không phải thất bại. Điều kiện để có số = bật 3 cơ chế ghi nhận (git tag code, lưu bản nháp AI, nhật ký công sức), bắt đầu ngay tuần này.

Thông điệp 1 câu cho khách: "Chúng tôi đo hiệu quả AI bằng bằng chứng, không bằng cảm tính - phần đã làm ra đạt chuẩn ở mảng đo được, tỷ lệ % thì đang đếm bằng thước đo khách quan, có số là báo, chưa có thì nói thẳng là chưa."

Bảng cầm tay: 4 màn × 5 trục (cheat-sheet trình khách)

Màn	Mapping legacy (C3)	UI live (C2)	Cấu trúc DDD (C5)	Parity cũ/mới (C6)	Render live
CM06010	✅ 100%	⚠️ 81% đa phần data-diff + leak	✅ PASS 0 P1	✅ 受付状態 GREEN	🟢 200
CM71060	✅ 100%	✅ 100%	✅ PASS 0 P1	✅ Region GREEN	🟢 200
CM05110	✅ 100%	✅ 100%	✅ PASS 0 P1	✅ 工事連絡 GREEN	🟢 200
CM30020	✅ 100%	⚠️ 83.3% leak FIXME	✅ PASS 0 P1	🟡 chưa có	🟢 200

Đọc bảng: mapping legacy + cấu trúc DDD + parity-mapping = xanh đều; UI live = chỗ yếu (2 màn render lỗi do data-diff/leak, 2 màn còn lại đã render 200 đầy đủ). 2 defect chặn boot app đã FIX. Owner + ngày cho từng ô cần CDXO điền (Phần 5).

2 câu cứu cho 2 câu khách giết nhất (đọc thuộc, ≤ 2 dòng)

2 câu cứu

"Sao chất lượng đổi từ 100% xuống số thật?" → "100% là số máy đo cũ lưu lại, đo lại trên app chạy thật thì 2 màn đạt 100%, 2 màn lộ vài lỗi - chúng tôi báo số thật chứ không giữ số đẹp cũ. Lỗi đã thấy rõ, đang sửa."

"Vậy rốt cuộc AI có dùng được không?" → "Phần khung + ánh xạ dữ liệu cũ→mới: máy làm đúng, đã kiểm bằng test tự động. Phần giao diện: 2 màn đã đạt, 2 màn đang sửa nốt lỗi lộ ra. Tỷ lệ % tổng đang đo, có là báo ngay."

⭐⭐ 6 tiêu chí chất lượng khách yêu cầu (品質の基準) - trả lời tường minh

Đây là 6 tiêu chí Thiên đã gửi khách. Khách chỉ cần: chỉ số nào · đo thế nào · hiện tại bao nhiêu · mục tiêu bao nhiêu. Bảng dưới trả lời thẳng (đo trên code 04-coding e1f3654, 2026-06-14). Số chưa đo ghi rõ "chưa đo" - không bịa, không phỏng đoán thành số.

Mục tiêu (cột Mục tiêu) = chính 6 品質基準 KHÁCH đặt (Thiên gửi), KHÔNG phải số nội bộ ta tự chọn → đây là ngưỡng nghiệm thu của khách. Vì vậy 3 ô "chưa đo" (Q3/Q5 + Q4-Sonar) = rủi ro trượt gate nếu không lấp trước nghiệm thu - phải có mốc ngày.

#	Tiêu chí khách	Đo thế nào (công cụ)	Hiện tại	Mục tiêu (khách đặt)	Đạt?
Q1	Tỷ lệ ánh xạ logic cũ→mới (ロジックマッピング率)	ArchUnit `@LegacyOrigin` (cấu trúc) + screen-audit claim-coverage (logic)	cấu trúc 100% (4/4 màn) · logic-claim 85-94% đã hiệu chỉnh (số raw 42.5% ở CM30020 là lỗi matcher đã đính chính, không dùng)	≥ 70%	✅ ĐẠT
Q2	Độ chính xác logic code mới sinh (ロジック正確度)	new-old parity test (output Java == VB cũ) + code-FPA diff	parity 5/5 PASS nhưng chỉ trên 3 logic tất định (chưa đại diện toàn bộ); A3 code-FPA toàn diện chưa đo	≥ 80%	🟡 Tín hiệu tốt (scope hẹp), chưa kết luận
Q3	Tỷ lệ giảm công sức/thời gian (工数削減率)	effort-log (giờ AI+người ÷ giờ thủ công baseline)	🔧 cơ chế đã lập (`.nexa/kb/scope-tracker/effort-log.csv` + công thức B1/B4); 0 dòng dữ liệu → cần ghi vài tuần mới có số	≥ 40%	⏳ Chưa có dữ liệu (cơ chế sẵn)
Q4	Sonar kiểm tĩnh (Sonar静的チェック)	SonarQube quality-gate	🟡 Sonar đã wire config (plugin + sonar-project.properties + jacoco.xml; cần SonarQube server + token để chạy `sonar:sonar`). Proxy hiện có 4/4 PASS: Spotless ✅ · Checkstyle ✅ · DDD-audit ✅ · SpotBugs ✅ 0 bug (16 bug CM71060: phần exposure-dữ-liệu thật fix bằng List.copyOf/null-check; phần false-positive Spring-DI singleton + cleanup-rethrow suppress có chú thích trong excludeFilter; BUILD SUCCESS)	Pass	🟡 Proxy 4/4 xanh chờ server chạy Sonar tổng hợp
Q5	Coverage unit-test logic (単体テストカバレッジ)	JaCoCo line coverage	logic (domain+application) = 87.7% (domain 88.9% / app 87.1%); tổng cả app = 59.9% (thấp do infra/IO/presentation plumbing ít unit-test)	≥ 80%	✅ ĐẠT trên tầng logic
Q6	Tỷ lệ Pass test case (テストケースPass率)	`mvn test` PASS/total	100% (246/246) - sau khi khôi phục app-config.yaml (380-key từ legacy Commufa.config), 5 test AppConfig trước đỏ nay xanh hết	100%	✅ ĐẠT

Tóm tắt thẳng cho khách (cập nhật sau vòng fix)

6 tiêu chí (ngưỡng do khách đặt) → 3 đạt rõ (Q1 mapping, Q5 logic-coverage 87.7%, Q6 test-pass 100%) · 1 gần đạt - proxy 4/4 xanh chờ server (Q4: SpotBugs đã về 0, Sonar đã wire) · 1 tín-hiệu-tốt chưa kết luận toàn diện (Q2 parity 5/5 scope hẹp, A3 chưa đo) · 1 chưa có dữ liệu (Q3 effort-log vừa lập, chưa tích luỹ). Việc còn lại: (1) ghi effort-log vài tuần → Q3; (2) cấp SonarQube server+token → chạy Q4 tổng hợp; (3) git-tag ai-gen/tuned + mở rộng parity → Q2 toàn diện. 5/6 tiêu chí đã có số thật / proxy xanh; chỉ Q3 cần thời gian tích luỹ.

Bắc cầu với 4 nhóm A/B/C/D bên dưới: Q1↔C3+C4 · Q2↔C6+A3 · Q3↔B1 · Q4↔C5(DDD)+SpotBugs · Q5↔(coverage, nhóm C mới) · Q6↔(test-pass, nhóm C mới). 4 nhóm là khung nội bộ đầy đủ; 6 tiêu chí là tập con khách quan tâm nhất - bảng này map 1-1 để khách không phải đọc cả 4 nhóm.

PHẦN 0Tài liệu này trả lời câu hỏi gì

Khách hàng hỏi đúng 2 câu (Goal 1 và Goal 2):

AI tham gia vào công đoạn nào, và giảm được bao nhiêu % công sức/thời gian?
Dùng AI vấp phải vấn đề gì, và kế hoạch cải thiện ra sao?

Bối cảnh niềm tin của khách hàng (nguồn: báo cáo họp khách của Thiên):

Khách đang tin AI chỉ sinh đúng khoảng 40%, phần còn lại người phải nhúng tay.
Khách không tin AI đạt tới 70%.
Nếu chứng minh được AI đạt trên 60% một cách có bằng chứng -> khách hài lòng cao.

Tài liệu này định nghĩa cơ chế đo để trả lời 2 câu trên bằng con số đo được, có cách đo rõ ràng, tái lập được, thay vì nói cảm tính.

Khung đo, chưa phải kết quả: ở thời điểm này nhóm C (chất lượng) đã có số thật; nhóm A (độ chính xác %) và B (tiết kiệm %) đang trong quá trình đo. Đừng kỳ vọng con số % cuối cùng ngay hôm nay - kỳ vọng đúng là "cơ chế đo đã chặt chẽ, số sẽ đổ đầy theo mốc M1-M4".

PHẦN 1Vì sao thiết kế bộ chỉ số như thế này (logic nền)

1.1 Vì sao không dùng 1 con số "AI đúng X%"

"Độ chính xác của AI" khác nhau hẳn theo công đoạn:

Trích xuất tri thức từ source code cũ (KB extraction): máy làm gần hết, chính xác cao.
Sinh code giao diện (UI): hiện đang yếu, cần tuning.

Gộp tất cả vào 1 con số vừa không công bằng (kéo công đoạn yếu lên nhờ công đoạn mạnh), vừa không hành động được (không biết phải cải thiện chỗ nào). Nên ta đo theo từng công đoạn trước (Nhóm A), rồi mới gộp có trọng số thành 1 headline KPI để nói chuyện với lãnh đạo khách hàng.

1.2 Thước đo trung tâm: First-Pass Acceptance (FPA)

FPA = "% sản phẩm AI sinh ra được giữ lại sau khi người review".

Chọn FPA vì nó đúng ngôn ngữ khách đang dùng ("AI gen đúng cỡ 40%, còn lại người sửa"), và đo được khách quan bằng diff/so khớp - không phải tự chấm cảm tính. FPA cao = người sửa ít = AI đóng góp thực nhiều.

1.3 Bốn nhóm chỉ số (khung nội bộ) và cầu nối tới 6 tiêu chí khách

4 nhóm là khung đo nội bộ ĐẦY ĐỦ; 6 tiêu chí khách (bảng ⭐⭐ ở trên) là tập con khách quan tâm nhất. Cột cuối map sang tiêu chí khách để khách không phải đọc cả khung.

Nhóm A Độ chính xác AI theo công đoạn

Trả lời cho: "AI đúng bao nhiêu %"

Map tới tiêu chí khách: Q2 (logic正確度)

Nhóm B Giảm công sức / thời gian / chi phí

Trả lời cho: Goal 1 (% tiết kiệm + quy tiền)

Map tới tiêu chí khách: Q3 (工数削減)

Nhóm C Chất lượng đầu ra đáng tin

Trả lời cho: Chứng minh "đúng" không phải "rác"

Map tới tiêu chí khách: Q1 · Q4 · Q5 · Q6

Nhóm D Vấn đề & cải thiện

Trả lời cho: Goal 2 (issue + giải pháp + kế hoạch)

Map tới tiêu chí khách: (xuyên suốt)

Cách đọc cho khách: muốn biết "AI làm đúng tới đâu" xem Q1+Q2; "tiết kiệm bao nhiêu" xem Q3; "chất lượng có tin được không" xem Q4+Q5+Q6. Mỗi tiêu chí đều có: cách đo + số hiện tại + mục tiêu (bảng ⭐⭐).

1.4 Thang chuẩn tham chiếu

Mượn từ benchmark nội bộ MSR-002 (đã dùng thật ở dự án trước; tài liệu gốc QUALITY_MANAGEMENT_GUIDE / AIDP_Enhanced_Review_Process không nằm trong repo PoC này - là tham chiếu second-hand, không phải chuẩn ngành ngoài):

Min ≥ 60% · Target ≥ 70% · Good ≥ 80% · Excellent ≥ 90%

Đây là lý do các ngưỡng target trong nhóm A bám quanh 60-70%.

PHẦN 2Headline KPI (con số nói với lãnh đạo khách hàng)

Chỉ số	Định nghĩa	Baseline (khách tin)	Mục tiêu POC	Stretch (khách chưa tin)	Hiện tại
AI-FPA tổng hợp	Trung bình có trọng số FPA của 3 công đoạn sản xuất chính (Docs A2, Code A3, Test A4); trọng số theo khối lượng artifact	40%	≥ 60%	≥ 70%	chưa tính được (xem dưới)

Công thức (diễn giải bằng lời cho slide khách): AI-FPA tổng = trung bình có trọng số của 3 tỷ lệ FPA (tài liệu, code, test); công đoạn nào khối lượng lớn thì cân nặng hơn.

Dạng ký hiệu (để phụ lục/nội bộ, đừng đưa lên slide khách):

AI-FPA = Σ (FPAᵢ × Wᵢ)   với i ∈ {A2 Docs, A3 Code, A4 Test};  Σ Wᵢ = 1
Wᵢ = tỷ trọng khối lượng của công đoạn i

Lưu ý tái lập (quan trọng)

Headline hiện chưa tính được vì 2 lý do, không chỉ vì thiếu dữ liệu:

Thiếu dữ liệu: A2/A3/A4 đều chưa có số (xem nhóm A).
Trọng số Wᵢ chưa chốt cơ sở: tính theo "số artifact" và theo "effort-share" cho ra 2 kết quả khác nhau (4 màn code vs hàng trăm mục tài liệu sẽ làm lệch hẳn). Nên kể cả khi có FPA, headline vẫn chưa tái lập được cho tới khi anh Dzũng (CTO) chốt cơ sở trọng số. Đây là việc phải chốt trước khi báo headline.

Guard chống ảo số (bắt buộc - nên kể với khách như một điểm cộng tin cậy)

Headline chỉ được công bố khi A3 (Code FPA) ≥ mức min 50%.

Lý do: con số tổng hợp có thể vượt 60% nhờ phần tài liệu/test kéo lên, trong khi phần sinh code (đúng chỗ khách nghi ngờ nhất) vẫn dưới chuẩn. Báo headline lúc đó là báo một con số không phản ánh đúng thực tế. Guard này là cơ chế đảm bảo con số tổng hợp không bị "làm đẹp" nhờ công đoạn mạnh che công đoạn yếu.
Hiện tại Guard = N.A vì A3 chưa có số.

Cách báo cáo: luôn kèm bảng per-công-đoạn, không bao giờ nói trần 1 con số (tránh bị hỏi vặn "60% của cái gì").

PHẦN 3Danh mục chỉ số đầy đủ (định nghĩa, công thức, cách đo, hiện tại)

Ký hiệu trạng thái: ✅ đã đo (có evidence) · ⏳ chưa đo (cơ chế sẵn sàng) · ⛔ blocked (thiếu dữ liệu đầu vào).

Bảng thuật ngữ nhanh (gloss cho người không chuyên):

FPA = % AI sinh ra được giữ lại sau review.
HITL = "human in the loop" = có người kiểm tra tay.
ArchUnit / @LegacyOrigin = bài test tự động kiểm tra mỗi màn code mới có gắn nhãn truy về đúng màn cũ (đảm bảo không lạc mất gốc legacy).
DDD / cấu trúc = nguyên tắc đặt code đúng tầng (logic nghiệp vụ ở tầng domain, không lẫn lung tung).
Finding P1 = lỗi mức ưu tiên cao (thang P0 nặng nhất > P1 > P2 > P3); P1 = cần fix trước bàn giao nhưng chưa phải "sập hệ thống".
Semantic LoC = dòng code đổi logic, phân biệt với đổi hình thức (đổi tên biến, căn lề).

Nhóm A - Độ chính xác AI theo công đoạn

ID	Chỉ số	ĐV	Công thức	Nguồn dữ liệu	Tần suất đo	Min	Target	Hiện tại
A1	KB extraction accuracy (SCAN)	%	`đúng / sample` (sample ≥ 50 claim, thiếu-ngữ-cảnh = 0.5)	Sample FARE KB đối chiếu tay với legacy source (HITL)	Sau mỗi lần `nexa scan` đáng kể	80	90	⏳ chưa đo
A2	Docs gen FPA (BD/DD)	%	`min(Completeness%, Accuracy%)` của bản v0 (AI) so với bản final (sau review) - phương pháp so khớp MSR-002, lấy min để bảo thủ. Đơn vị đếm = mục (item) trong section, chốt với CTO	Engine so khớp item; giữ bản v0 tại `{artifact}/.v0/`	Mỗi tài liệu được APPROVED	60	70	⏳ chưa đo
A3 ⭐	Code gen FPA	%	`1 − (LoC người đổi semantic / LoC AI sinh)`	`git diff --numstat ai-gen/<CM>..tuned/<CM>` trên path screen	Mỗi screen xong tuning	50	60	⏳ chưa có số (chưa bật giao thức git tag)
A4	Test-case gen FPA	%	`case dùng được không sửa / tổng case`; phân bố ISTQB là cờ PASS/FAIL riêng, không cộng vào scalar	QA review từng case	Sau mỗi batch sinh test	60	70	⏳ skill sẵn, chưa chạy

A3 là chỉ số quan trọng nhất vì đây đúng chỗ khách nghi ngờ (40%). Điều kiện đo: từ giờ phải tag commit ai-gen/<CM> (ngay sau khi AI sinh, trước khi người sửa) và tuned/<CM> (sau review duyệt). Màn đã làm trước khi có tag không truy hồi ngược được -> ghi pending, không ước lượng ngược.

Trung thực về tính khách quan của A3: git diff đếm mọi dòng đổi, không tự tách được "đổi logic" với "đổi hình thức". Phần "chỉ tính dòng đổi semantic" hiện vẫn cần người gắn cờ trong PR -> chưa hoàn toàn tự động. Vì vậy A3 chỉ thực sự tái lập được khi: (a) chốt định nghĩa "semantic" với CTO, và (b) cơ giới hoá bằng script (vd chạy formatter chuẩn hoá trước rồi mới diff). Cho tới lúc đó, đừng quảng cáo A3 là "hoàn toàn khách quan" - nói đúng: "đo bằng diff, có quy tắc loại trừ hình thức do reviewer áp dụng nhất quán". (Có thể báo song song một số phụ "churn-FPA thô" = đếm mọi dòng, hoàn toàn tự động, để khách thấy biên độ.)

Nhóm B - Giảm công sức / thời gian / chi phí (Goal 1)

ID	Chỉ số	ĐV	Công thức	Nguồn dữ liệu	Tần suất đo	Target	Hiện tại
B1	Effort reduction theo phase	%	`1 − Σ(giờ AI + giờ người) / Σ(giờ baseline thủ công)` per phase	effort-log.csv (append-only) + baseline ước lượng do KMD/chuẩn JP-SI cung cấp	Ghi hằng ngày, tổng hợp mỗi milestone	≥ 40 overall, ≥ 50 BD/DD	⛔ chưa có effort-log -> chưa có mẫu số
B2	Review time per doc	giờ	giờ làm việc trôi qua để review 1 tài liệu (AI pre-review 2 lớp)	timestamp mở/đóng review trên Backlog ticket	Mỗi vòng review	16h -> ≤ 4h	⏳ chưa đo
B3	Throughput	screen / person-week	`screen hoàn tất / person-week`	scope-tracker ledger + effort-log	Mỗi milestone	report-only (PoC 4 màn quá nhỏ để chốt target cứng)	⏳ đo để report
B4 ⭐	Chi phí tiết kiệm (quy tiền)	tiền (¥)	`hours_saved = B1% × baseline_hours_per_screen`; `cost_saved = hours_saved × hourly_rate`; ngoại suy dự án thật: `cost_saved_per_screen × 256 màn`	B1 + đơn giá GIỜ công (hourly_rate) chốt với CTO; baseline định nghĩa per-screen trước khi ×256	Mỗi milestone + ước lượng dự án thật	(mục tiêu kinh doanh, chốt với CTO)	⛔ [Estimation] - chưa tính được vì B1 blocked + hourly_rate chưa chốt

Cảnh báo trung thực: B1 hiện không trả lời được vì chưa ghi effort-log. Đây là việc số 1 phải làm ngay: phát template log cho team. Không có mẫu số thì cuối POC chỉ nói được cảm tính - đúng cái khách không muốn nghe.

B4 - câu mà CEO/CFO hỏi đầu tiên: "tiết kiệm bao nhiêu tiền?". Hiện chưa có con số ¥ vì phụ thuộc B1 (chưa có) và đơn giá ngày công (chưa chốt). Công thức đã sẵn; khi B1 có số + CTO chốt hourly_rate -> ra ngay con số ¥ tiết kiệm per-screen cho 4 màn PoC và ngoại suy cho 256 màn dự án thật. Không đưa con số ¥ nào ra trước khi có 2 đầu vào này - đưa sớm = bịa. (Lưu ý đơn vị: dùng đơn giá GIỜ; nếu baseline tính bằng ngày-công thì quy về giờ trước khi nhân, tránh sai chiều đơn vị.)

Nhóm C - Chất lượng đầu ra đáng tin (chống "60% rác")

ID	Chỉ số	ĐV	Công thức	Nguồn dữ liệu (engine)	Tần suất	Target	Hiện tại
C1	Quality-gate pass	%	gate G1-G11 PASS trước khi qua phase	`nexa gate run` log	Mỗi chuyển phase	100	⏳ đang vận hành (chưa chốt số tổng hợp)
C2	UI element coverage vs prototype	%	`item PASS / item audit` (mức màn: đủ thành phần, không thiếu/thừa)	`prototype-ui-audit.py` (app LIVE :8080)	Mỗi milestone	≥ 95	🟡 đo lại LIVE (e1f3654, sau khôi phục config): 2/4 PASS - CM71060 100% · CM05110 100% (PASS) · CM06010 81% · CM30020 83.3% (FAIL: leak FIXME/spList_ + prototype-data-diff). Số cũ "100% (4/4)" là json STALE - xem ghi chú
C3	Legacy mapping integrity	%	`screen pass ArchUnit @LegacyOrigin / tổng`	`./mvnw test -Dtest=LegacyOriginMappingTest` (surefire)	Mỗi build	100	✅ 100% (4/4 màn)
C4	Screen audit-breadth (logic)	%	`coverage_pct` engine = % claim-type trích/check được (audit rộng tới đâu), denominator = "extractable claim types, NOT full behavior surface". KHÔNG phải "% claim có mặt trong docs mới"	`screen-audit-check.py` field `coverage_pct`	Mỗi screen audit	≥ 90	✅ đo lại 4/4 màn (e1f3654): CM06010 96.6% · CM71060 93.5% · CM05110 95.8% · CM30020 90.6% (xem caveat CM30020 dưới)
C5	Code structure (DDD)	số finding	số finding P1 mở tại thời điểm bàn giao	`code-audit-check.py`	Mỗi milestone	0 P1 open	✅ 0 gateable P1, 4/4 màn gate PASS (e1f3654). CM05110 2 P1 cũ đã fix; 2 P1 CM71060 (S13/S14) xác định là false-positive của engine (adapter hexagonal ở thư mục riêng + shared cross-cutting port), đã tinh chỉnh engine + neg-test chứng minh vẫn bắt lỗi thật, code không đổi
C6 ⭐	新旧比較 UT (parity cũ/mới)	%	`test so sánh (output VB == output Java, cùng input) PASS / tổng`	comparison UT suite (`./mvnw test -Dtest=*ComparisonTest`)	Mỗi milestone	≥ 95	🟡 5/5 PASS (100%) trên enum/mapping nghiệp vụ tất định, 3 màn (Region CM71060 + 受付状態 CM06010 + 工事連絡 CM05110; golden từ legacy source verbatim). Caveat: chưa phủ SQL/proc/validation parity - mở rộng dần
C7	Unit-test coverage (Q5 khách)	%	line coverage = covered/(covered+missed)	JaCoCo (`jacoco-maven-plugin` đã thêm → `target/site/jacoco/jacoco.csv`)	Mỗi milestone	≥ 80	✅ logic-ring 87.7% (domain 88.9% / app 87.1%); ⚠️ tổng-app 59.9% (infra/IO/presentation plumbing mỏng test - cần integration test). 117 class, đo thật e1f3654
C8	Test-case Pass rate (Q6 khách)	%	`(run − fail − err) / run`	`./mvnw test` surefire	Mỗi milestone	100	✅ 100% (246/246; sau khôi phục app-config.yaml 380-key, 5 test AppConfig đỏ trước nay xanh)
C9	SpotBugs / static-bug (proxy Q4 Sonar)	count	số bug `spotbugs:check` (threshold Low)	`./mvnw spotbugs:check`	Mỗi build	0	✅ 0 bug (16 bug CM71060 → 0: fix thật mutable-data-exposure bằng List.copyOf + 1 null-check; suppress false-positive Spring-DI constructor-injection + cleanup-rethrow có chú thích lý do trong excludeFilter - không phải nới bừa). Spotless ✅ Checkstyle ✅ DDD ✅. Sonar đã wire config (cần server để chạy)

C2 - đo lại LIVE lật ngược số stale (quan trọng, trung thực)

Số cũ "100% (4/4 PASS)" lấy từ json đã commit = STALE. Khởi động app thật (Docker+Oracle FREEPDB1+Flyway) rồi chạy prototype-ui-audit.py ra 2/4 PASS (CM71060 + CM05110 = 100%). Phân loại:

CM06010 81% / CM30020 83.3% (render 200, FAIL thật): phần lớn "thiếu" là mock data của prototype không có trong DB live rỗng (data-diff, không phải lỗi UI); NHƯNG có leak thật: token máy spList_ @cm06010, placeholder FIXME @cm30020, FIXME @customer lọt vào UI - phải fix.
CM71060 / CM05110 = 100% (PASS): sau khôi phục local app-config, 2 màn render 200 đầy đủ và đạt element-coverage 100% so prototype.
Kết luận: KHÔNG dùng "C2 = 100% cả 4 màn". Số đúng = "live 2/4 PASS (CM71060/CM05110 100%); 2 màn còn lại 81%/83.3% (FAIL so prototype, đa phần data-diff + vài leak thật cần fix)". Chi tiết: cmux-workers/c2-fresh.md.

C6 quan trọng đặc biệt với migration

Cả dự án là chuyển màn cũ (VB.NET) sang mới (Java) giữ nguyên hành vi. Vì vậy "output mới == output cũ với cùng input" (C6, gọi là new-old parity / defect-escape proxy) là bằng chứng nghiệm thu cốt lõi, nên kể ngang hàng headline. Harness chạy + 5/5 PASS (100%) trên 3 màn (RegionComparisonTest CM71060 + ReceptionStatusComparisonTest CM06010 + ContactStatusComparisonTest CM05110; golden lấy verbatim từ legacy source basCM06_Common.vb:L60-66, FrmCM05110.vb:L583, FrmCM71060.vb:L821; engine GoldenMasterSupport định nghĩa ≡ qua normalizer). Lệnh suite: ./mvnw test -Dtest='*ComparisonTest'. Caveat trung thực: 5/5 mới phủ enum/mapping nghiệp vụ TẤT ĐỊNH; chưa phủ SQL body / stored-proc / validation parity. Việc còn lại = mở rộng sang các loại đó rồi tính C6 = ΣPASS/Σtotal. Đây là số nghiệm thu khách chờ nhất.

C5 - hiện trạng đo lại trên code mới e1f3654 (4/4 màn đã audit, tất cả gate PASS): CM06010/CM71060/CM05110/CM30020 đều 0 gateable P1. Diễn biến: (a) CM05110 2 P1 cũ (S12/S15 persistence leak) đã FIX về 0; (b) CM71060 từng báo 2 P1 (S13 "port thiếu infra-impl", S14 "controller chạm persistence") - điều tra ground-truth cho thấy là false-positive của audit engine: S13 chỉ quét ring infrastructure/persistence nên không thấy adapter hexagonal đặt ở excel/,file/,procedure/ (cả 4 port ĐỀU có adapter implements); S14 cờ field AppErrorLogPort (port cross-cutting import từ shared., whitelist đúng ý nhưng regex soi nhầm dòng). Đã tinh chỉnh engine cho chính xác (S13 quét mọi ring infra; S14 whitelist port import từ shared.) + negative-test chứng minh engine vẫn FAIL khi có leak thật / thiếu impl thật; code ứng dụng KHÔNG đổi (git clean). Cùng class với artifact 57.1% CM30020: lỗi đo, không phải lỗi code.

Lưu ý số CM30020 - xử lý dứt điểm NỘI BỘ - chuẩn bị trước, không đọc nguyên văn cho khách

Cùng màn CM30020 có nhiều con số vì đo các thứ khác nhau. Quan trọng (đã verify từ file nguồn LIVE 2026-06-14): file plans/reports/screen-audit-cm30020/screen-audit-CM30020.json hiện chứa ĐỒNG THỜI coverage_pct: 90.6 VÀ fidelity_pct: 57.1 - tức 57.1 KHÔNG phải "số cũ đã sửa", nó là fidelity logic HIỆN HÀNH của cùng lần chạy sinh ra 90.6. Nếu CTO/khách chạy lại tool hôm nay sẽ thấy cả 2 cạnh nhau.

Con số	Đo cái gì	Trạng thái
90.6%	audit-breadth: % claim-type engine trích/check được (denominator = "extractable claim types, NOT full behavior surface")	LIVE; KHÔNG phải "% có mặt trong doc mới"
42.5% (76/179)	presence thô đúng định nghĩa C4: aligned/auditable	LIVE; con số "có mặt trong doc mới" thật theo công thức
57.1%	fidelity logic hiện hành, bị ~102-105 FAIL "missing-from-new-doc" kéo xuống	LIVE; phần lớn FAIL là artifact matcher (chỉ đọc phạm vi BD, claim thật nằm trong DD shell)
98.6% (70/71)	visual-fidelity bề mặt UI, capture 1 viewport (coverage 70%)	LIVE; metric riêng, đừng trộn với logic

Kịch bản đính chính ĐÚNG (không nói "đã sửa, 57.1 biến mất" - file sống phản bác ngay): với khách kể bằng lời business: "Công cụ đếm logic hiện đang đếm sót vì chỉ đối chiếu một phần tài liệu (BD) trong khi nội dung thật nằm ở tài liệu chi tiết (DD) - nên báo nhiều mục 'thiếu' không có thật. Chúng tôi đang sửa công cụ đếm; TRƯỚC khi sửa xong, KHÔNG trích cả 90.6% lẫn 57.1% như con số chất lượng cuối."

Quy tắc trình bày: với màn này, chưa trích số logic nào làm chất lượng cuối cho tới khi matcher được fix + chạy lại. Số dùng được hiện tại cho CM30020 = visual 98.6% (kèm caveat coverage 70%); C2 live = 83.3% element-coverage (có leak FIXME phải fix, không phải 100%). [SoT: cm30020-split-screen-audit-artifact]

Nhóm D - Vấn đề & cải thiện (Goal 2)

ID	Chỉ số	ĐV	Công thức	Nguồn dữ liệu	Tần suất	Target	Hiện tại
D1	Issue register đầy đủ	%	`issue AI có root-cause + solution ghi nhận / tổng issue`	Backlog ticket (field bắt buộc)	Liên tục	100	⏳ vận hành theo Backlog rules
D2	First-time approval rate	%	`artifact duyệt ngay vòng review đầu / tổng`	review log (Backlog)	Mỗi milestone	40% -> ≥ 70%	⏳ chưa đo (chỉ báo dẫn hướng, đổ đầy M1-M4)
D3	Tuning iterations	số vòng	trung bình số vòng review tới khi duyệt	review log (Backlog)	Mỗi milestone	≤ 3 vòng	⏳ chưa đo
D4	Improvement plan coverage	%	`issue được nhóm thành bài học + kế hoạch cho dự án thật / tổng`	báo cáo cuối POC	Cuối POC	100	⏳ chưa tới kỳ

Nhóm D (mức độ chấp nhận/áp dụng AI) hiện toàn bộ là chỉ số dẫn hướng (leading indicator), sẽ đổ đầy theo M1-M4. Với PoC, đây là trạng thái bình thường - nói rõ với khách thay vì để trống gây hiểu lầm.

PHẦN 3bĐo tương đương Legacy ↔ New một cách khoa học (nền của C3/C4/C6)

DORA/SPACE đo tốc độ + năng suất, KHÔNG đo "bản mới có làm đúng như bản cũ không". Đo tương đương legacy↔new là họ chuẩn riêng từ kỹ thuật kiểm thử/refactoring. C3/C4/C6 chính là họ này. Đây là phần product-driven, countable, verifiable.

Nguyên lý: "mapping legacy↔new" = 3 trục VUÔNG GÓC, không phải 1 số

Gộp 3 trục thành 1 số = lỗi đã cắn ta ở CM30020. Tách rõ:

Trục	Câu hỏi	Đơn vị đếm	Công thức	Quan hệ tương đương ≡	Metric dự án
1. Mapping completeness (tĩnh)	"có bỏ sót mảnh nào của hệ cũ?"	anchor legacy (màn/control/field/SQL/rule)	`mapped / tổng anchor legacy`	tồn tại link truy vết (`@LegacyOrigin`)	C3 (155 marker, 100% file màn)
2. Behavioral equivalence (động) ⭐	"new chạy ra kết quả y old?"	case = (input, output-old chụp lại)	`parity = {x: New(x)≡Old(x)} / tổng x`	π (output cần so) + ≡ (khớp/chuẩn-hoá/dung-sai ε) định nghĩa trước	C6 (harness GREEN 5/5, đang mở rộng)
3. Behavioral coverage	"test parity chạm bao nhiêu % hành vi?"	use case / transaction / nhánh	`exercised / tổng phần tử hành vi`	(đo bằng coverage trên legacy lúc capture)	chưa có - cần thêm

Chuẩn ngành đặt tên cho Trục 2 (cái C6 đang gọi)

Chuẩn	Nguồn	≡ định nghĩa qua	Hợp dùng cho
Characterization test	Feathers 2004	giá trị old đã chụp (golden)	lưới an toàn per-màn khi spec cũ mất
Differential testing	McKeeman 1998	old==new (không cần biết "đúng")	fuzz/traffic, divergence→0 - mạnh nhất cho migration
Golden Master / Approval	Falco	normalizer + comparator	output lớn (màn/report cũ↔mới)
Parallel Run + Reconciliation	Fowler (legacy displacement)	comparator nghiệp vụ, traffic thật	bằng chứng mạnh nhất - roadmap Phase 2
ISO/IEC 25010 Functional Suitability	ISO	khớp trong dung sai ε	khung số hiệu quốc tế: Completeness% + Correctness%
Bidirectional Traceability	CMMI REQM	tồn tại ánh xạ 2 chiều	C3 đã có forward; thêm backward bắt code thừa

Cách báo cáo đúng (không 1 số trần)

"Mapping completeness = a% · Parity rate = b% trên Behavior coverage = c%, khớp tuyệt đối modulo timestamp/auto-ID."

Điểm phải nói thẳng với khách: với UI migration (VB WinForms → Java web), KHÔNG có "giống hệt từng byte/pixel" - mọi chuẩn nghiêm túc định nghĩa ≡ qua normalizer/dung-sai = "tương đương hành vi nghiệp vụ", không phải equality thô. ≡ phải reflexive + symmetric + transitive.

Cụ thể cho dự án (VB.NET Shift-JIS → Java)

Không chạy 2 hệ chung tiến trình → dùng golden-master đã chụp: mỗi màn định nghĩa input vector (EP/BVA trên field) → chụp output legacy làm golden (từ DB fixture cũ / capture tay / spec làm oracle) → viết *ComparisonTest assert New(x)==golden(x). Đó chính là suite C6. ≡ theo loại output: tập dòng DB (set-equal bỏ auto-ID/timestamp), message validate (khớp catalog legacy), giá trị tính (tuyệt đối hoặc ε). Đây là chỉ số migration-correctness quan trọng nhất đang thiếu - ưu tiên dựng sớm.

PHẦN 4Hiện trạng tổng hợp (ý nghĩa con số hiện tại) + câu trả lời phòng thủ

Cái đã đo được và đáng tin (nhóm C - chất lượng):

Mapping legacy 100% (C3, 4/4 màn, đo tươi) - chắc nhất. UI vs prototype (C2) đo LIVE = 2/4 PASS (số 100% cũ là json stale); CM71060/CM05110 render đủ 100%, CM06010/CM30020 81%/83.3% (đa phần data-diff prototype↔live + vài leak thật). Nghĩa: phần AI sinh ra đạt mapping legacy, còn UI 2 màn đã đạt, 2 màn có lỗi lộ ra phải fix - KHÔNG tô "đạt chuẩn bề mặt 100%". (C4 CM30020 = audit-breadth 90.6%, presence thô 42.5%; xem block CM30020.)
Đã audit cấu trúc DDD 4/4 màn, 4/4 gate PASS, 0 gateable P1. CM05110 2 P1 cũ đã fix; 2 P1 CM71060 (S13/S14) là false-positive engine, đã sửa engine + neg-test, code không đổi.

Cái chưa đo được và lý do (nhóm A, B, D - trung thực với khách):

A: chưa có số vì chưa bật 2 giao thức ghi nhận (git tag ai-gen/tuned cho A3, lưu bản v0 doc cho A2). Đây là điều kiện kỹ thuật bắt buộc, không phải hạn chế của AI.
B1/B4: ⛔ blocked vì chưa có effort-log -> không có mẫu số (và chưa có đơn giá để quy tiền). Rủi ro lớn nhất: không log ngay = cuối POC không trả lời được Goal 1.
D: đang tích lũy qua Backlog, roll-up cuối POC.

Câu trả lời sẵn-để-đọc cho 2 câu khách chắc chắn hỏi

Q: "Sao nhiều chỉ số 'chưa đo' thế? NEXA không chạy được à?"

"Đo được hết, nhưng chúng tôi từ chối điền số ngược/cảm tính. Mỗi con số phải sinh từ log/diff/engine để khách kiểm chứng lại được. Biển 'chưa đo' là kỷ luật trung thực: số nào chưa đủ điều kiện đo thì nói thẳng chưa, không tô vẽ. Cơ chế đo đã dựng xong, số đổ đầy theo mốc M1-M4."

Q: "Chất lượng với độ chính xác khác nhau thế nào - đo cái gì?" (câu chí mạng)

Phân biệt rõ 2 thứ khác nhau:

Chất lượng (nhóm C) = phần đã được giữ lại có đạt chuẩn không (mapping legacy 100% - chắc; UI/parity đang đo, có lỗi thì báo thẳng).
Độ chính xác/FPA (nhóm A) = AI tự làm đúng được bao nhiêu phần trước khi người chỉnh.

Hai cái độc lập: AI có thể tự làm đúng 60% (FPA), 40% còn lại người chỉnh, và sau chỉnh thì đạt chuẩn chất lượng. Không mâu thuẫn. Lưu ý: chúng tôi KHÔNG tô chất lượng 100% trần - ví dụ UI đo live lộ vài lỗi đang fix, báo sòng phẳng.

Analogy thợ may (kể cho khách): "Vải nào đã may xong và kiểm thì đường kim mũi chỉ đạt chuẩn - đó là chất lượng (nhóm C; mapping legacy đã đạt, UI đang soi nốt vài lỗi). Còn 'máy tự may được bao nhiêu % cái áo trước khi thợ chỉnh tay' - đó là FPA (nhóm A). Cái thứ hai chúng tôi đang đếm bằng thước, chưa đếm xong nên không nói bừa." (Có analogy này, nhãn 'chưa đo' biến từ điểm yếu thành bằng chứng trung thực.)

Q: "100% chỉ trên 4 màn, có dám ngoại suy ra 256 màn không?"

"100% là trên scope PoC 4 màn - tín hiệu sớm tốt, không ngoại suy thành cam kết cho 256 màn. PoC để chứng minh cơ chế chạy đúng; con số quy mô lớn cần Phase 2."

Q: "2 lỗi P1 chưa fix mà vẫn báo chất lượng cao?"

"2 P1 đó nằm ở 1 màn đã audit cấu trúc; gate đang để FAIL đúng theo thiết kế (không cho qua khi còn P1). Đã có kế hoạch fix trước bàn giao - đây là bằng chứng quy trình chất lượng hoạt động, không phải lỗi bị bỏ qua."

Câu chuyện Goal 2 - kể bằng lời (đây là câu khách DỄ hài lòng nhất, đừng để trống dưới dạng bảng D⏳)

Khách hỏi Goal 2 = "dùng AI vấp gì, định sửa sao". Đừng trả lời bằng bảng chỉ số D1-D4 "chưa đo" - kể các vấn đề THỰC đã gặp + cách xử lý:

#	Vấn đề thực đã gặp (PoC)	Cách xử lý / bài học cho dự án thật
1	Sinh code UI còn yếu, lệch nhiều (Thiên báo định tính)	Tuning prompt/context + mở rộng golden sample; đo bằng A3 để biết tiến bộ. Đây là KPI trọng tâm tuning.
2	Công cụ đo logic (matcher) đếm sót - báo 57.1% fidelity sai vì chỉ đọc phạm vi BD trong khi nội dung ở DD	Đang fix matcher đọc cả DD; bài học: engine đo phải kiểm định trước khi tin số.
3	Lỗi cấu trúc + độ chính xác công cụ đo - CM05110 từng 2 P1 (đã fix), CM71060 báo 2 P1 hoá ra false-positive engine	CM05110 fix sạch (2→0); CM71060 điều tra ground-truth = lỗi đo (engine quét thiếu ring infra + whitelist soi nhầm dòng), đã sửa engine + neg-test chứng minh vẫn bắt lỗi thật, code không đổi. Bài học: engine đo phải kiểm định trước khi tin số (giống vụ 57.1%).
4	Chưa có effort-log -> chưa đo được %tiết kiệm	Phát template log ngay; bài học: phải đo từ ngày đầu, không dồn cuối.
5	FarPoint Grid (thư viện thương mại) không có bản Java 1:1	Thay bằng HTML table / quyết định license ở Phase 2; bài học: rà thư viện thương mại sớm.
6	HEAD e1f3654 không tự boot được (phát hiện khi khởi động đo C2): Flyway 2 file trùng version `V0023`; file test `Cm06010MovirusControllerTest.java` byte non-UTF8	ĐÃ FIX + verified: renumber cm05110 seed `V0023→V0026` (giữ cm71060 V0023 vì V0024/25 phụ thuộc); khôi phục file test từ blob sạch `f190ecf` (UTF-8, JP nguyên) -> `./mvnw test-compile` BUILD SUCCESS. Bài học: cần CI smoke-boot + `.gitattributes` UTF-8 chặn pull đỏ.
7	Leak token máy + placeholder trong UI (đo C2 live): `spList_ @cm06010`, `FIXME @cm30020`, `FIXME @customer` lọt vào màn render	Quét bỏ FIXME/token máy trước bàn giao; bài học: cần gate chặn placeholder trong output UI.
8	2 màn từng 500 do thiếu local app-config (CM71060/CM05110): registry `app.config[*]` IO-dir gitignored, mất sau pull	Đã khôi phục app-config registry → 2 màn render 200 + đạt C2 100%; bài học: config registry phải có cơ chế seed local, không để mất sau clone.

Thông điệp Goal 2: "AI không hoàn hảo - chúng tôi ghi lại sòng phẳng chỗ vấp và cách xử lý, để khi sang dự án thật biết trước rủi ro." Đây là giá trị PoC khách thực sự muốn (PR cho End User về 'giới hạn AI và đối sách'), trả lời được NGAY không cần chờ đo.

PHẦN 5Baseline vs Target + lộ trình cải thiện

Nhóm	Baseline (điểm xuất phát)	Target POC	Cơ chế đạt target
Headline AI-FPA	40% (khách tin)	≥ 60%	Tuning prompt/context + golden sample; đo bằng FPA per công đoạn
A3 Code FPA	(chưa có, khách nghi 40%)	≥ 60%	Tag git -> đo diff -> tuning UI gen (chỗ yếu nhất)
A2 Docs FPA	-	≥ 70%	Review 2 lớp + checklist quan điểm
B1 Effort	100% công thủ công	giảm ≥ 40% overall, ≥ 50% BD/DD	effort-log + baseline thủ công chốt với CTO
B2 Review time	16h (2 ngày/doc, anchor MSR-002)	≤ 4h	AI pre-review 2 lớp
C6 Parity cũ/mới	-	≥ 95%	comparison UT, bật M3/M4
C (chất lượng)	-	giữ ≥ 95-100%	engine audit mỗi milestone
D2 First-time approval	40%	≥ 70%	tuning theo issue tích lũy

Lộ trình theo milestone scope-tracker: M1 (BD xong) · M2 (DD xong) · M3 (CODE xong) · M4 (TEST xong) + 1 snapshot cuối POC. Đo sớm, đo thường, không dồn cuối.

Việc phải bật ngay để có số (cam kết mốc - điền owner/ngày trước khi trình khách)

#	Việc	Mở khoá chỉ số	Owner	Mốc
1	Phát template effort-log.csv + bắt đầu ghi	B1, B3, B4	(điền)	tuần này
2	Bật giao thức git tag `ai-gen/tuned`	A3 (số khách quan tâm nhất)	(điền)	từ màn kế tiếp
3	Lưu bản v0 (AI) của mỗi doc	A2	(điền)	từ doc kế tiếp
4	Chốt với CTO: trọng số Wᵢ, baseline B1, day_rate B4, định nghĩa semantic A3	headline + B4 + A3	CDXO+CTO	trước buổi trình khách

Lưu ý quan trọng trước khi trình khách: các số gắn [Estimation] (trọng số headline, baseline B1, day_rate B4, target B1) chưa qua anh Dzũng (CTO). Phải có buổi freeze với CTO trước, nếu không là đang trình số chưa được CTO duyệt.

PHẦN 6Cơ chế chấm điểm tái lập được (defensible trước lãnh đạo)

Đây là phần thuyết phục CTO/CEO: cùng input -> cùng score, ai chạy lại cũng ra số đó.

Số sinh từ engine/diff/log, không chấm tay. Mỗi chỉ số nhóm C có 1 lệnh cố định (bảng dưới); nhóm A có công thức diff/so khớp cố định. (Ngoại lệ trung thực: A3 còn 1 bước "loại trừ hình thức" do người gắn cờ -> đang cơ giới hoá, xem ghi chú A3.)
Một file số liệu duy nhất: .nexa/kb/scope-tracker/kpi-targets.json. Engine kpi_snapshot.py ghi current + state; người viết không sửa tay số trong bảng báo cáo.
Lịch sử bất biến: mỗi snapshot append 1 dòng vào kpi-history.jsonl (có timestamp) -> truy được số tại mọi thời điểm.
Evidence file đính kèm: mỗi số nhóm C trỏ tới file output gốc (json/surefire).

Lệnh tái lập nhóm C

ID	Lệnh	Output
C1	`nexa gate run`	gate log
C2	`prototype-ui-audit.py`	`04-coding/report/prototype-ui-audit.json`
C3	`cd 04-coding && ./mvnw test -Dtest=LegacyOriginMappingTest`	surefire report
C4	`python3 04-coding/coding-rules/screen-audit-check.py <CM>`	screen-audit report
C5	`python3 04-coding/coding-rules/code-audit-check.py <ctx>`	code-audit.json
C6	`./mvnw test -Dtest=*ComparisonTest`	surefire report

Pipeline snapshot mỗi milestone

1. Chạy 6 lệnh nhóm C
2. Cập nhật effort-log.csv (đã ghi hằng ngày)
3. Tag git ai-gen/tuned cho screen mới xong
4. python3 .claude/skills/nexa-audit-target/scripts/kpi_snapshot.py --snapshot
   -> ghi current vào kpi-targets.json + append kpi-history.jsonl
   -> sinh kpi-report-{stamp}.md từ template
5. DDM (localhost:6392) đọc kpi-targets.json -> trực quan

Đề nghị kiểm định độc lập (gỡ nghi ngờ sau sự cố matcher 57.1%)

Vì engine từng báo sai 57.1% (lỗi đọc thiếu phạm vi), khách có quyền nghi cả các số PASS khác. Đối sách: mời khách (hoặc bên thứ 3) tự chạy lại 1 lệnh nhóm C trên 1 màn và đối chiếu tay. Khớp -> tin cả bộ engine. Đây là điều kiện để chuyển niềm tin từ "vendor nói" sang "khách tự kiểm". Nên chủ động đề nghị, không chờ khách đòi.

PHẦN 7bLộ trình chỉ số Phase 2 (để qua review hãng SI lớn)

Bộ chỉ số hiện mạnh ở AI-accuracy + chất lượng artifact (khớp mục tiêu khách), nhưng một review cấp NTT Data/Accenture sẽ đòi thêm các chỉ số chuẩn ngành dưới đây. PoC tài liệu/4-màn chưa tới kỳ đo, nhưng phải có roadmap (SI không chấp nhận "không có kế hoạch"):

Nhóm	Chỉ số bổ sung (đề xuất)	Khung nguồn	Khi đo
ROI/tài chính	ROI% = (lợi ích − chi phí AI)/chi phí AI; Payback (tháng); TCO chi phí AI (token/license/HITL)	thực hành business-case SI	khi có B1+B4
Chất lượng giao hàng	Defect-escape rate (lỗi lọt sau gate); Defect density (/screen); Test coverage % (line/branch)	QA ngành + DORA	M3/M4 (code)
Tốc độ giao hàng	DORA: Lead Time, Change Failure Rate, Deployment Frequency; Cycle time/artifact	DORA/SPACE	Phase 2 (CI/CD)
Con người/áp dụng	Adoption/Utilization rate (% công đoạn thực dùng AI - khác FPA); Developer satisfaction (survey)	SPACE	định kỳ
Kỹ thuật bổ trợ	Security/SAST density; Maintainability/tech-debt; Requirements traceability %	OWASP/ISO/CMMI	Phase 2

Lưu ý: DORA/SPACE là khung delivery+productivity, KHÔNG phải khung AI-accuracy - "thiếu DORA" ở PoC này không phải lỗi thiết kế, mà là phần bổ sung Phase 2. Mọi target phải freeze với CTO như các [Estimation] hiện có. [SoT: Inference + DORA/SPACE official frameworks - xem cmux-workers/researcher.md]

PHẦN 7cProvenance: phân biệt NEXA gen-mass / NEXA-skill gen+fix / manual

Câu hỏi: trong source, phần nào AI sinh hàng loạt, phần nào dùng skill gen+fix, phần nào người gõ tay. Đo trên 04-coding HEAD e1f3654.

Giới hạn gốc (phải nói thẳng)

Provenance KHÔNG được ghi lúc commit: 0 git tag ai-gen/tuned, 0 header @generated trong source. Tác giả commit chỉ là proxy yếu (dev người có thể chạy AI rồi commit dưới tên mình - commit 4098c47 "re-generate BE logic" là ví dụ). Vì vậy tỷ lệ % từng lớp KHÔNG đo được hồi tố - chỉ ước lượng forensic gắn [Estimation] + confidence. Không bịa "X% do AI sinh".

Forensic best-effort (bằng chứng cứng + confidence)

Lớp	Tín hiệu đếm được (verified)	Confidence (lớp tồn tại)	Confidence (% chính xác)
L1 NEXA gen-mass	commit `9e08a17`: 74 file / 5153 dòng / cả 4 màn sinh trong 1 commit (không thể gõ tay)	HIGH	LOW
L2 NEXA-skill gen+fix	155 file @LegacyOrigin (100% file màn), ArchUnit pass, các commit nexa-audit/screen-audit/scope-tracker	MED-HIGH	MEDIUM
L3 manual	204/212 java file last-touch bởi dev người, PR per-màn có issue-ref tinh chỉnh logic/UI	HIGH	LOW

3 lớp chồng lên nhau trên cùng file (gen-mass khai sinh → skill graft marker → human fix logic) → chia theo giai đoạn lịch sử của file, không theo file rời.

Câu defensible duy nhất trước CTO

"Khung 4 màn do NEXA sinh hàng loạt 1 lần (bằng chứng commit 9e08a17: 74 file/5153 dòng), traceability NEXA phủ 100% file (155 @LegacyOrigin), phần tinh chỉnh logic do dev người làm tiếp. Tỷ lệ % từng lớp KHÔNG đo hồi tố được vì provenance chưa ghi lúc commit - bật cơ chế đếm từ màn kế tiếp."

Cách đo COUNTABLE từ giờ (biến forensic-đoán thành đo-được, feed thẳng A3)

Git tag 3 mốc per màn: ai-gen/<CM> (ngay sau NEXA sinh, trước khi người động) → skill-gen/<CM> (sau chạy NEXA-skill) → tuned/<CM> (sau dev review xong). Lớp = git diff --numstat giữa các tag. A3 Code-FPA = 1 − semantic-LoC(ai-gen..tuned)/LoC(ai-gen).
Commit trailer bắt buộc: Provenance: nexa-gen | skill-gen=<skill> | manual | mixed + Provenance-Tool: + Screen:. Đếm: git log --format='%(trailers:key=Provenance,valueonly)' | sort | uniq -c.
Header file máy-sinh: // @nexa-generated tool=vibecode v=3.2 screen=CM06010 + @provenance-layer L1 (sửa thành L3 khi người overwrite). Grep đếm file-level.

Màn đã code trước e1f3654 = pending, không hồi tố thành số chắc (đúng kỷ luật A3). Chi tiết: cmux-workers/provenance-analysis.md.

PHẦN 7Phụ lục: nguồn dữ liệu, giả định, khoảng còn thiếu

7.1 Nguồn dữ liệu gốc

Định nghĩa + target: .nexa/ddm/kpi-targets.json (duy nhất tồn tại ở .nexa/ddm/). Bản framework + measurement-guide gốc nằm ở plans/260610-1228-opt-poc-customer-answer-research/deliverables/kpi-framework.md + kpi-measurement-guide.md (KHÔNG ở .nexa/ddm/).
Số hiện tại nhóm C (đo lại trên 04-coding HEAD e1f3654, 2026-06-14): C2 = 04-coding/report/prototype-ui-audit.json live 2/4 PASS (cần app :8080 để re-run tươi); C3 = ./mvnw test -Dtest=LegacyOriginMappingTest fresh 4/4 PASS; C4 = screen-audit-check.py 4 màn (screen-audit-cm06010/cm71060/cm05110/cm30020, coverage 96.6/93.5/95.8/90.6); C5 = code-audit-check.py 4 màn, tất cả gate PASS 0 gateable P1 sau khi sửa 2 FP engine ở cm70maintenance (CM71060); engine refine + neg-test ở 04-coding/coding-rules/code-audit-check.py (S13 quét mọi ring infra, S14 whitelist shared-port); C6 = 5/5 PASS trên 3 màn.
Số visual 98.6%/coverage 70% CM30020: plans/reports/260609-1407-screen-audit-cm30020/screen-audit-CM30020.json.
Lịch sử: .nexa/kb/scope-tracker/kpi-history.jsonl.
Thang chuẩn: benchmark nội bộ MSR-002 (QUALITY_MANAGEMENT_GUIDE, AIDP_Enhanced_Review_Process).
Bối cảnh niềm tin khách: báo cáo họp khách của Thiên.

7.2 Giả định (cần CTO chốt, hiện gắn [Estimation])

Trọng số Wᵢ của headline AI-FPA (theo số artifact hay effort-share) - và headline chưa tái lập được tới khi chốt.
Baseline thủ công cho B1 (ước lượng KMD hay chuẩn productivity JP-SI - phải chốt nguồn).
Đơn giá GIỜ công (hourly_rate) cho B4 + baseline per-screen - chưa có thì không ra được con số ¥.
Ngưỡng B1 target (50% BD/DD, 40% overall đang là ước lượng).
Định nghĩa "người sửa semantic" trong A3 + cơ giới hoá script.
Tần suất snapshot KPI (đề xuất: mỗi milestone M1-M4).
A1 target 90% đặt cao vì trích xuất AST deterministic - cần sample thực xác nhận. C6 target 95% là ước lượng.

7.3 Khoảng dữ liệu còn thiếu (phải hành động ngay)

⛔ effort-log chưa tồn tại -> B1/B4 không tính được. Ưu tiên 1 về đo lường.
⏳ git tag ai-gen/tuned chưa bật -> A3 (chỉ số khách quan tâm nhất) chưa đo được.
⏳ bản v0 doc chưa lưu -> A2 chưa so khớp được.
⏳ A4, C6, D2, D3 cơ chế sẵn nhưng chưa chạy/ghi.
✅ 4/4 màn PoC đã code-audit DDD (gate PASS). C2 đo LIVE (2/4 PASS, thay stale 100%); 2 màn CM71060/CM05110 render 200 + đạt 100%. C6 = 5/5 PASS trên 3 màn (enum/mapping; mở rộng SQL/proc dần). 2 defect chặn boot HEAD đã FIX + verified (Flyway V0023→V0026, file test UTF-8). Còn cần: điền owner/ngày cho mốc; mở rộng C6 sang SQL/proc.