Incomex AI Portal
KB-C284 rev 50

Nguyên tắc Điều hành — SSOT

8 min read Revision 50

Nguyên tắc Điều hành — SSOT

v7.57-draft | 2026-04-11 | S176. Thêm AP-IAM-RESET-PATTERN (pattern IAM binding bị reset lặp lại, phát hiện S174+S176). Bản cũ v7.56 giữ tạm ở cuối file.

🔴 AP-IAM-RESET-PATTERN (Anti-Pattern quan trọng, S176)

Dấu hiệu: Secret/credential "tự nhiên mất" sau 1 khoảng thời gian (giờ/ngày). Pattern lặp lại.

Ví dụ thật — và NGUYÊN NHÂN GỐC thật sau điều tra S176:

  • S173 GH push: script cache /opt/incomex/.git-token với TTL 24h hardcoded. Cron 16:00 → 04:00 (13h) còn cache → PASS. Cron tiếp theo 16:00 (25h) cache expired → gọi GSM fallback → PERMISSION_DENIED vì SA chưa bao giờ có secretAccessor. Pattern "cứ ~24h lại fail" = cache TTL + base state thiếu quyền
  • S174 GCS backup: cursor-ci-builder thiếu storage.buckets.list từ đầu → silent fail 28 ngày vì script swallow error với 2>/dev/null
  • S176 Lark: cursor-ci-builder thiếu secretmanager.versions.access (cùng pattern S173/S174 — SA CI/CD được repurpose làm VPS SA, role được add ad-hoc khi gặp lỗi)

BÀI HỌC LỚN: Pattern "mất định kỳ" của Huyên KHÔNG phải IAM binding bị reset tự động. Là cache TTL script gặp base state thiếu quyền — khi cache còn thì che lỗi, khi cache hết thì lộ lỗi. Fix S173 chọn bypass runtime (PA-4) thay vì grant quyền → không cắt gốc, chỉ dời vấn đề.

Tuyệt đối KHÔNG:

  • Fix nhanh bằng gcloud add-iam-policy-binding rồi đi tiếp coi là xong
  • Kết luận RCA chỉ ở mức "thiếu role từ đầu, giờ grant rồi OK"
  • Duyệt mission phụ thuộc IAM/secret khi chưa biết pattern có tái phát không

Bắt buộc khi gặp IAM/secret fail trên VPS:

  1. Điều tra conditional binding — gcloud projects get-iam-policy --format=json grep condition có expiry time không
  2. Audit log SetIamPolicy 30 ngày — gcloud logging read 'protoPayload.methodName="SetIamPolicy" AND bindingDeltas.member:"<SA>"' xem ai/script nào đã sửa IAM
  3. Tìm Terraform/script reset — find *.tf, *.sh, cron, GitHub Actions có set-iam-policy/iam_binding không
  4. Lưu baseline diff 24h sau — nếu pattern tái phát sẽ bắt được thủ phạm
  5. Nếu pattern xác nhận: code phụ thuộc credential phải DEFENSIVE — detect credential expiry runtime, auto re-read, alert Telegram nếu fail

Lý do tồn tại của luật này: Tiết kiệm Huyên chuỗi ngày "fix → chạy → sụp → fix lại". Mỗi lỗi IAM = cơ hội tìm gốc rễ, không phải band-aid.

I. QUY TRÌNH BẮT ĐẦU

  1. ĐỌC SKILL — nguồn chính cho agent.
  2. ĐỌC OR NÀY — xác nhận hiểu CP + CQ + NT.
  3. ĐỌC HIẾN PHÁP + LUẬT LIÊN QUAN — knowledge/dev/laws/constitution.md.
  4. Chưa chắc → dừng, hỏi. Không vội.

II. CP — 6 CHECKPOINT THIẾT KẾ SẢN PHẨM

Áp dụng khi thiết kế mới hoặc giải quyết lại một vấn đề.

  • CP-01 — Mô hình tổng thể rõ?
  • CP-02 — Quy trình khép kín? Dual-trigger đầu → cuối.
  • CP-03 — Công cụ đầy đủ? DOT, script, PG — mỗi bước có tool.
  • CP-04 — Môi trường thực thi rõ?
  • CP-05 — KHÔNG SỬA CODE khi đã chạy. Thay đổi = metadata/config.
  • CP-06 — Thứ tự tư duy: Mục tiêu → giải pháp → rà soát đầu vào (nếu không chắc) → roadmap → soạn từng prompt.

III. CQ — CÂU HỎI CỐT LÕI TRƯỚC KHI SOẠN PROMPT

  • CQ-1 Vĩnh viễn hay tạm?
  • CQ-2 Còn cơ hội nhầm?
  • CQ-3 Tự thích nghi khi N thay đổi?
  • CQ-4 DOT 100%? (DOT 2 chiều — 92 động cơ)
  • CQ-6 Có hardcode không? (cấm)

IV. SOẠN PROMPT — MẪU S135H

≤60 dòng. Nói WHAT không HOW. Sửa tối đa 2 lần. 1 prompt/lần. Quan trọng nhất: thống nhất MỤC TIÊU + thống nhất THẾ NÀO LÀ ĐẠT.

# MISSION: [tên ngắn gọn]

## CHECKPOINT
search_knowledge("[từ khóa liên quan]")
search_knowledge("[OR hoặc luật cần đọc]")

## MỤC TIÊU
[Mô tả WHAT — không HOW. Rõ ràng, đo được.]

## THẾ NÀO LÀ ĐẠT?
[Danh sách tiêu chí cụ thể. Agent đọc xong biết ngay đạt hay chưa.]

## CONSTRAINTS
[Giới hạn: DB nào, table nào, Assembly First, không hardcode, v.v.]

## VERIFY — TỰ KIỂM TRA ĐỘC LẬP (BẮT BUỘC)
[Checklist trên production. Agent PHẢI tự verify bằng phương pháp
độc lập, ghi GIÁ TRỊ CỤ THỂ (không chỉ PASS/FAIL). Sai 1 check = DỪNG.]

## AP-CLOSE
git commit → update tracker (TD mới nếu có) → báo cáo tại reports/

V. 13 NGUYÊN TẮC — CẤM VI PHẠM

NT-01 SSOT | NT-02 Tự động 100% | NT-03 DOT 100% | NT-04 Sẵn sàng thay đổi | NT-05 Tự phát hiện sửa | NT-06 5 tầng đồng bộ | NT-07 Dual-trigger | NT-08 Assembly First | NT-09 Không chắc=Sai | NT-10 Quản lý bằng PG | NT-11 Khai tối thiểu | NT-12 DOT cặp | NT-13 PG FIRST

VI. VPS = SSOT MÃ NGUỒN

Agent SSH → sửa VPS → git commit → cron push GH 2×/ngày. CICD TẮT. Docker rebuild sau khi sửa agent-data.

VII. SAU MỖI PROMPT — BẮT BUỘC

  1. git add + git commit trên VPS.
  2. Cập nhật tracker + TD mới.
  3. Update OR nếu có thay đổi nguyên tắc/anti-pattern.

VIII. ANTI-PATTERN

AP-CLOSE (bỏ closing) | AP-PROMPT-DÀI (>60 dòng, sửa 5+ lần) | AP-NO-GIT | AP-BAO-XUONG (§0-AE — báo DONE không evidence) | AP-OUT-OF-SCOPE

AP-OUT-OF-SCOPE (S171, v7.55)

Agent gặp blocker ngoài scope → tự đẻ workaround song song mà KHÔNG dừng báo Desktop.

Quy tắc cứng:

  1. Blocker ngoài MỤC TIÊU + THẾ NÀO LÀ ĐẠT → DỪNG NGAY, ghi blocker + lý do, KHÔNG tự patch.
  2. Báo Desktop qua AP-CLOSE, section "BLOCKER + đề xuất hướng" — không tự quyết kiến trúc.
  3. Desktop quyết: (a) sửa prompt, (b) thêm scope, (c) accept workaround có ràng buộc, (d) defer.
  4. Agent chỉ tiếp tục sau khi Desktop chốt.
  5. Blocker giữa phiên dài → ghi báo cáo + DỪNG, không "vừa làm vừa patch".

Phân biệt:

  • ✅ Lỗi setup/config → tự debug fix (vẫn trong scope).
  • ❌ Lỗi kiến trúc/tool không chạy → tạo tool mới song song = AP-OUT-OF-SCOPE.

IX. CHUYỂN PHIÊN — ~85% CONTEXT

Handoff 7 mục bắt buộc. Cập nhật tracker/TD. Tổng kiểm tra. Soạn prompt phiên tiếp.

X. TÀI LIỆU VẬN HÀNH

  1. Tracker + TD: knowledge/current-state/project-progress-tracker.md (TD ở mục II).
  2. Handoff: knowledge/current-state/handoff-{session}.md.

XI. THAM CHIẾU

  • Hiến pháp v4.4.0: knowledge/dev/laws/constitution.md
  • Skill: agent đọc TRƯỚC MỌI PHIÊN.
  • Soạn/sửa luật: knowledge/dev/ssot/operating-rules-law-drafting.md — chỉ đọc khi cần soạn hoặc sửa luật.

v7.57-draft | S174 | 271 DOT | Đang rà: cấu trúc mới 11 mục | Bản cũ v7.56 giữ ở cuối để đối chiếu.

⬇️ BẢN CŨ v7.56 — GIỮ TẠM ĐỂ ĐỐI CHIẾU, SẼ XOÁ SAU KHI CHỐT BẢN MỚI ⬇️

[CŨ] I. QUY TRÌNH BẮT BUỘC KHI BẮT ĐẦU

  1. ĐỌC SKILL — Agent/AI đọc skill TRƯỚC KHI làm bất kỳ việc gì. Skill = nguồn chính.
  2. ĐỌC OR NÀY — Xác nhận đã hiểu 13 NT + 6 CQ + 16 checkpoint.
  3. ĐỌC HIẾN PHÁP + LUẬT LIÊN QUAN — knowledge/dev/laws/constitution.md (HP v4.4.0, 13 NT + Đ38).

[CŨ] III. 16 CHECKPOINT — TỰ KIỂM TRA TRƯỚC KHI GỬI

Nền tảng (1-6):

  • CP-01: Đã đọc kỹ HP, luật liên quan, OR, skill?
  • CP-02: Data flow PG→Dir→Nuxt? Auto 100%? DOT 100%? Scale N?
  • CP-03: Update OR + tracker + handoff sau prompt?
  • CP-04: Assembly First? Desktop nhỏ, Agent lớn, 1 prompt/lần?
  • CP-05: Agent search_knowledge TRỰC TIẾP — KHÔNG background agent?
  • CP-06: Agent báo cáo tại reports/?

Thiết kế sản phẩm (7-11):

  • CP-07: Mô hình tổng thể rõ?
  • CP-08: Quy trình khép kín? Dual-trigger đầu→cuối?
  • CP-09: Công cụ đầy đủ — DOT, script, PG, mỗi bước có tool?
  • CP-10: Môi trường thực thi rõ?
  • CP-11: KHÔNG SỬA CODE khi đã chạy. Thay đổi = metadata/config.

Bổ sung (12-16):

  • CP-12: DOT cặp 2 chiều?
  • CP-13: Agent TỰ ĐỌC LẠI Agent Data khi cần?
  • CP-14: PG có → dùng PG. Ngoài PG → xin phép?
  • CP-15: Đã git add + git commit trên VPS?
  • CP-16: Agent TỰ KIỂM TRA bằng phương pháp ĐỘC LẬP? Ghi GIÁ TRỊ CỤ THỂ.

[CŨ] IV. 6 CÂU HỎI CỐT LÕI

CQ-1 Vĩnh viễn hay tạm? | CQ-2 Còn cơ hội nhầm? | CQ-3 Tự thích nghi N? | CQ-4 DOT 100%? | CQ-5 Agent tự đọc? | CQ-6 Không hardcode?

(Các mục khác bản cũ đã gộp/đưa lên bản mới ở trên — không copy lại.)