Incomex AI Portal
KB-67AD

NĐ-LARK-01 — Rà soát khả năng thực hiện, phân công và hiệu suất các cổng

15 min read Revision 1
larkplanningfeasibilityassignmentgate-reviewgpt

NĐ-LARK-01 — Rà soát khả năng thực hiện, phân công và hiệu suất các cổng

Trạng thái: DRAFT bổ sung cho nd-lark-01-reconstruction-blueprint-plan-v1-gpt.md Tác giả: Incomex Hội đồng AI / GPT Ngày: 2026-04-12 Mục đích: Làm rõ tính khả thi thật, cách phân công thực hiện, và đánh giá hiệu suất các cổng theo tình hình hiện tại

I. Kết luận điều hành ngắn

Kế hoạch NĐ-LARK-01 khả thi, nhưng chỉ khả thi nếu đổi từ tư duy “viết blueprint tổng quát” sang tư duy điều tra có kiểm chứng theo cổng và theo checklist coverage.

Điểm nghẽn thật hiện nay không phải là thiếu ý tưởng lưu trữ, mà là thiếu 3 thứ:

  1. Ma trận khả năng thật của từng cổng — cổng nào đọc được loại dữ liệu nào ngoài đời thực.
  2. Danh sách inventory mục tiêu đã chốt — chính xác là phải lấy những loại thông tin nào.
  3. Phân công rõ ràng — ai chịu trách nhiệm cổng nào, ai chịu trách nhiệm coverage, ai chốt bằng chứng.

Nếu 3 thứ này chưa chốt, mọi thiết kế PG hay blueprint đều mới ở mức lý thuyết.

II. Đánh giá khả năng thực hiện theo hiện trạng từng cổng

1. Cổng 1 — MCP tool / Claude Desktop

Hiện trạng

  • Đã có MCP tool.
  • Claude Desktop truy cập được.
  • Nhưng mức hữu dụng hiện tại rất hạn chế.

Đánh giá

  • Khả năng kỹ thuật: có tồn tại, nhưng chưa phải trụ cột.
  • Hiệu suất khai thác: thấp.
  • Độ ổn định để làm dump hàng loạt: thấp.
  • Vai trò phù hợp: phụ trợ, thử nhanh, kiểm tra chéo hẹp.

Kết luận sử dụng

Không dùng Cổng 1 làm tuyến chính cho Phase 4. Chỉ dùng khi:

  • cần xác minh nhanh một điểm nhỏ,
  • cần đối chiếu hành vi với cổng khác,
  • hoặc cần khai thác thứ mà C2/C4 đang chưa rõ.

Xếp hạng hiện tại

  • Tính khả thi: MEDIUM
  • Giá trị sản xuất: LOW
  • Ưu tiên triển khai: LOW

2. Cổng 2 — Public REST / chương trình đọc dữ liệu

Hiện trạng

  • Đã triển khai xong.
  • Đã xác nhận tải thử được 1 file.
  • Theo tài liệu S178, bộ đọc READ toolkit đã verify 15/15 endpoint đọc của Bitable v1 trên base thử nghiệm là PASS.
  • Theo tài liệu mechanisms.md và cong2-p6-final-report, C2 là tuyến chủ đạo cho schema, role/permission, member/user, forms, app/table/field metadata và phần lớn inventory nền.

Đánh giá

  • Khả năng kỹ thuật: cao.
  • Độ lặp lại: cao nhất trong các cổng đang có.
  • Khả năng tự động hóa: cao.
  • Phù hợp để dump 18 base: cao.
  • Điểm yếu: hiện mới xác nhận thực chiến ở mức hẹp; chưa chứng minh xong coverage trên toàn bộ 18 base.

Kết luận sử dụng

Cổng 2 phải là xương sống chính thức của toàn bộ chương trình dump.

Nhưng cần tránh một hiểu lầm: “đã test 1 file chạy” không đồng nghĩa với “đã đủ để triển khai sản xuất toàn bộ”. Việc còn thiếu là một sprint ngắn để đo coverage thực chiến trên 18 base theo checklist inventory.

Xếp hạng hiện tại

  • Tính khả thi: HIGH
  • Giá trị sản xuất: VERY HIGH
  • Ưu tiên triển khai: HIGHEST

3. Cổng 3 — bỏ

Kết luận sử dụng

Loại khỏi kế hoạch điều hành chính. Không phân bổ nguồn lực nữa.

4. Cổng 4 — Claude Desktop qua Chrome extension / đọc trực tiếp UI

Hiện trạng

  • Kết nối cơ bản được xác nhận là ổn.
  • Theo mechanisms.md, đây là cổng rất quan trọng cho những gì API không lộ ra đầy đủ, đặc biệt nhóm automation/config và các dấu vết UI-only.
  • Theo cong2-p6-final-report, một số loại dữ liệu hiện được đánh dấu C4 ONLY như sync table IDs, formula code, trash tables, record ordering, change stream; ngoài ra automation/list và automation/configs theo tài liệu cũng là năng lực cốt lõi của C4.

Đánh giá

  • Khả năng kỹ thuật: cao cho điều tra sâu.
  • Khả năng hàng loạt: trung bình.
  • Độ ổn định / tái lập: trung bình, kém hơn C2.
  • Giá trị: cực cao ở vai trò bù khuyết và xác minh.

Kết luận sử dụng

Cổng 4 phải là cổng số 2 về tầm quan trọng, nhưng không phải tuyến dump nền. Nó nên được dùng theo cơ chế:

  • C2 dump trước,
  • coverage chỉ ra gap,
  • C4 vào lấp đúng gap đó.

Xếp hạng hiện tại

  • Tính khả thi: HIGH
  • Giá trị sản xuất: HIGH
  • Ưu tiên triển khai: HIGH, nhưng sau C2

5. Cổng 5 — Computer Use (Claude Desktop)

Hiện trạng

  • Chưa thử.
  • Theo mechanisms.md, đây là phương án cuối để đọc phần Setup UI hoặc stage options khi C4 không tìm được endpoint hoặc fieldMap không trả.

Đánh giá

  • Khả năng kỹ thuật lý thuyết: có giá trị cứu hộ.
  • Tính xác thực thực chiến hiện tại: chưa có.
  • Chi phí vận hành: cao.
  • Độ lặp lại: thấp nhất.
  • Rủi ro: dễ tốn thời gian mà không tăng coverage tương xứng nếu dùng quá sớm.

Kết luận sử dụng

Không được mở rộng C5 thành tuyến điều tra chính. C5 chỉ được mở khi đồng thời thỏa 3 điều kiện:

  1. C2 không đọc được.
  2. C4 không đọc được hoặc không xác minh được.
  3. Loại dữ liệu đó được xác định là critical cho blueprint.

Xếp hạng hiện tại

  • Tính khả thi: UNKNOWN → tạm MEDIUM-LOW
  • Giá trị sản xuất: situational
  • Ưu tiên triển khai: LAST RESORT

III. Xếp hạng tổng thể các cổng theo vai trò thực tế

Cổng Vai trò nên giao Khả thi Hiệu suất Tự động hóa Vai trò trong kế hoạch
C1 phụ trợ / kiểm tra chéo nhỏ Trung bình Thấp Thấp không làm trụ cột
C2 dump nền / inventory chính Cao Cao nhất Cao xương sống
C3 bỏ - - - loại khỏi kế hoạch
C4 bù gap / automation / UI-only / xác minh Cao Trung bình-cao Trung bình cổng số 2
C5 cứu hộ / last resort Chưa rõ Thấp Thấp chỉ mở khi thật cần

Kết luận chốt

Mô hình điều hành đúng là: C2 làm nền → C4 lấp gap → C1 kiểm tra chéo hẹp → C5 cứu hộ chọn lọc.

IV. Vấn đề mù hiện nay: chưa chốt được “Lark thực sự cấp cái gì để lưu”

Đây là nhận định đúng và là trọng tâm nhất.

Tài liệu phase4-data-inventory.md rất quan trọng, nhưng hiện tại nó mới là checklist mục tiêu dựa trên hiểu biết đã có. Muốn biến nó thành công cụ điều hành thực chiến, cần tách nó thành 3 lớp rõ ràng:

Lớp A — Expected inventory

Danh sách kỳ vọng phải lấy. Ví dụ:

  • app metadata
  • table list
  • field list
  • view list
  • form list
  • role list
  • permission matrix
  • member list
  • automation list
  • automation configs
  • formula code
  • sync IDs
  • stage options
  • change stream

Lớp B — Observed availability by gate

Cho từng item ở lớp A, phải ghi rõ:

  • C2 đọc được thật chưa?
  • C4 đọc được thật chưa?
  • mới là suy luận hay đã có bằng chứng?
  • đã thử trên mấy base?
  • base nào?

Lớp C — Operational status

Cho từng item, phải có trạng thái thực chiến:

  • DONE — đã lấy được ổn định
  • PARTIAL — lấy được một phần
  • UNVERIFIED — tin là có nhưng chưa thử đủ
  • BLOCKED — hiện chưa lấy được
  • NOT-NEEDED-NOW — chưa cần cho phase hiện tại

Nếu chưa tách ra 3 lớp như vậy thì vẫn còn “mù có tổ chức”, chưa phải “biết rõ cái gì thiếu”.

V. Điều chỉnh quan trọng để kế hoạch đi vào thực chất

1. Bổ sung một giai đoạn mới trước Phase dump lớn

Đề xuất chèn thêm một giai đoạn riêng, đứng trước giai đoạn dump toàn bộ:

Giai đoạn 1A — Capability & Coverage Validation

Mục tiêu của giai đoạn này không phải là vẽ blueprint, mà là trả lời dứt điểm 4 câu hỏi:

  1. C2 thực sự đọc được những loại dữ liệu nào trên 18 base?
  2. C4 thực sự đọc bù được những loại dữ liệu nào?
  3. Còn những loại dữ liệu critical nào chưa có cổng đọc đáng tin?
  4. Checklist phase4-data-inventory.md cần sửa gì để phản ánh thực tế?

Đầu ra bắt buộc của Giai đoạn 1A

  • gate-capability-matrix.md
  • inventory-manifest-v1.md
  • coverage-baseline-report.md
  • danh sách critical gaps

Nếu chưa có 4 đầu ra này, không nên lao vào dump diện rộng.

2. Phân công phải dựa theo vai trò, không theo cảm tính

Vai trò 1 — Lead điều tra C2

Nhiệm vụ:

  • chạy dump bằng C2,
  • ghi raw evidence,
  • báo coverage thực chiến,
  • không suy diễn UI-only.

Deliverable chính:

  • C2 dump logs
  • raw payload inventory
  • coverage per base
  • danh sách phần C2 không đọc được

Vai trò 2 — Lead điều tra C4

Nhiệm vụ:

  • chỉ nhận danh sách gap từ coverage,
  • dùng C4 để đọc phần UI-only / automation / sync / formula / stage,
  • ghi bằng chứng rõ ràng,
  • không làm thay việc dump nền của C2.

Deliverable chính:

  • gap-resolution notes
  • C4 evidence pack
  • danh sách item C4-only hoặc C4-better

Vai trò 3 — Registry / PG engineer

Nhiệm vụ:

  • dựng schema PG tối giản,
  • nhận raw evidence từ C2/C4,
  • chuẩn hóa vào registry,
  • cập nhật coverage table,
  • sinh dependency queries.

Deliverable chính:

  • PG schema v1
  • load scripts
  • coverage views
  • initial relations extraction

Vai trò 4 — Inventory editor / evidence controller

Nhiệm vụ:

  • quản lý phase4-data-inventory.md,
  • chuyển checklist thành manifest điều hành,
  • đảm bảo mỗi tick có bằng chứng thật,
  • theo dõi item nào đang unverified / blocked.

Deliverable chính:

  • inventory manifest chuẩn hóa
  • gate capability matrix
  • change log inventory

Vai trò 5 — Blueprint synthesizer

Nhiệm vụ:

  • không đi lấy dữ liệu thô trực tiếp ở đầu,
  • dùng registry + coverage + evidence để viết flow dossiers và blueprint,
  • đánh dấu confidence rõ ràng.

Deliverable chính:

  • flow dossiers
  • dependency summaries
  • blueprint draft

Vai trò 6 — Owner / reviewer

Nhiệm vụ:

  • chốt ưu tiên nghiệp vụ,
  • quyết định phần nào critical,
  • duyệt khi nào được phép dùng C5,
  • duyệt blueprint và review gaps.

VI. Phân công thực hiện đề xuất theo trình tự

Đợt 1 — Làm cho kế hoạch “đo được”

Người phụ trách chính

  • Lead C2
  • Inventory editor
  • Registry engineer

Việc phải xong

  1. Chốt inventory manifest v1 từ phase4-data-inventory.md
  2. Chạy C2 trên một nhóm base đại diện, không chỉ 1 file
  3. Ghi lại coverage baseline
  4. Tách rõ item nào: done / partial / unverified / blocked

Lý do

Đây là bước biến lý thuyết thành số đo thật.

Đợt 2 — Mở rộng dump nền

Người phụ trách chính

  • Lead C2
  • Registry engineer

Việc phải xong

  1. chạy C2 trên toàn bộ 18 base
  2. nạp raw vào PG
  3. sinh coverage report toàn cục
  4. dựng inventory nền: bases / tables / fields / views / forms / roles / permissions / members

Lý do

Không có dump nền thì chưa có cái để gap analysis.

Đợt 3 — Đánh vào phần khó

Người phụ trách chính

  • Lead C4
  • Inventory editor
  • Registry engineer

Việc phải xong

  1. đọc các item C4-only / C4-better
  2. verify automation list + configs
  3. verify sync setup / formula code / stage options / change stream
  4. cập nhật coverage và confidence

Lý do

Đây là phần làm nên giá trị của blueprint, nhưng chỉ nên làm sau khi có dump nền.

Đợt 4 — Chỉ mở C5 nếu cần

Người phụ trách chính

  • Lead C4 / operator Computer Use
  • Owner duyệt

Việc phải xong

  1. lập danh sách exact items cần C5
  2. chứng minh C2+C4 không đủ
  3. chạy C5 hẹp theo checklist
  4. ghi evidence rõ ràng

Lý do

Nếu mở C5 quá sớm sẽ tốn công mà coverage tăng ít.

Đợt 5 — Tổng hợp blueprint

Người phụ trách chính

  • Blueprint synthesizer
  • Owner / reviewer

Việc phải xong

  1. dependency graph
  2. flow dossiers
  3. blueprint draft
  4. impact matrix sơ bộ

VII. Đề xuất sửa tài liệu phase4-data-inventory.md

Tài liệu này nên được nâng từ checklist tĩnh thành công cụ điều hành sống bằng cách thêm các cột sau cho từng item:

  • Critical? — Có thực sự cần cho blueprint phase hiện tại không
  • Observed by C2?
  • Observed by C4?
  • Observed by C5?
  • Tested bases count
  • Best gate
  • Operational status
  • Evidence ref
  • Owner

Mục đích

Khi đó ta sẽ không chỉ có danh sách “muốn lấy gì”, mà có luôn:

  • lấy được chưa,
  • lấy bằng cổng nào tốt nhất,
  • đang giao cho ai,
  • bằng chứng nằm ở đâu.

Đây là thay đổi quan trọng nhất để kế hoạch đi vào thực chất.

VIII. Các nhóm dữ liệu nên ưu tiên chốt trước

Không cần cố lấy tất cả ngay từ đầu. Để khả thi, nên ưu tiên 4 nhóm theo thứ tự:

Nhóm 1 — Inventory nền bắt buộc

  • base metadata
  • table list
  • field list
  • view list
  • form list

Nhóm 2 — Quan hệ cấu trúc bắt buộc

  • link fields
  • lookup fields
  • sync table IDs
  • formula references

Nhóm 3 — Workflow bắt buộc

  • automation list
  • automation configs
  • trigger types
  • writeback targets

Nhóm 4 — Quản trị / bối cảnh

  • roles
  • permission matrix
  • members
  • change stream / trash / rank info nếu thực sự cần cho blueprint

Kết luận ưu tiên

Muốn “vẽ lại được hệ thống để sửa chữa”, chỉ cần chậm nhất phải chốt xong Nhóm 1 + 2 + 3. Nhóm 4 quan trọng, nhưng một phần có thể đi sau.

IX. Đánh giá tính khả thi thực sự

Mức 1 — Có thể bắt đầu ngay không?

Có. Vì C2 và C4 đều đã có kết nối thực tế; C2 đã có nền tảng kỹ thuật đủ mạnh, C4 có vai trò bù khuyết rõ.

Mức 2 — Có thể làm triệt để không?

Có khả năng cao, nhưng chỉ nếu đưa phase4-data-inventory.md thành inventory manifest có coverage thật và có phân công sở hữu.

Mức 3 — Điểm có thể làm hỏng kế hoạch là gì?

  1. Dùng C4 quá sớm thay cho C2
  2. Không có owner cho từng item inventory
  3. Tick checklist theo suy luận thay vì evidence
  4. Không tách “có endpoint” với “đọc ổn định được trên 18 base”
  5. Mở C5 quá rộng khi chưa chứng minh cần thiết

X. Khuyến nghị chốt

Chốt 1

Sửa NĐ-LARK-01 để thêm Giai đoạn 1A — Capability & Coverage Validation.

Chốt 2

Nâng phase4-data-inventory.md từ checklist sang inventory manifest điều hành.

Chốt 3

Phân công tối thiểu phải có 4 đầu mối:

  • Lead C2
  • Lead C4
  • Registry/PG engineer
  • Inventory editor

Chốt 4

Không mở C5 cho đến khi có danh sách critical gaps đã được owner duyệt.

Chốt 5

Mọi đánh giá hiệu suất cổng phải dựa trên 3 thước đo:

  • coverage tăng bao nhiêu,
  • thời gian / công sức bỏ ra bao nhiêu,
  • độ lặp lại / tái kiểm tra được đến đâu.

XI. Kết luận cuối

Hiện nay hướng đi chung là đúng. Nhưng để kế hoạch thực sự khả thi và đi vào thực chất, phải dừng coi phase4-data-inventory.md là checklist lý thuyết, và biến nó thành bảng điều hành thực chiến: item nào, cổng nào đọc được, đã thử trên bao nhiêu base, bằng chứng ở đâu, ai chịu trách nhiệm, trạng thái hiện tại là gì.

Khi làm được việc đó, toàn bộ kế hoạch dựng blueprint sẽ chuyển từ “có vẻ hợp lý” sang “có thể thi công được”.