# Sếp dùng AI để theo dõi code dự án khách — mà không nhúng AI vào repo khách

> Anh code HRMS Odoo 19 cho LHAG ở repo OKG riêng, JARVIS không link gì. Em build 2 skill pull git log + privacy filter 3-tier để JARVIS biết tiến độ mà repo khách không biết JARVIS tồn tại.

**Author**: Tien Dang (Đặng Hồng Tiên), Founder of OKG and AIC, Vietnam
**Published**: 2026-05-01
**Pillar**: ops
**Tags**: jarvis, privacy-filter, ops, multi-entity, founder-ai
**Canonical URL**: https://danghongtien.com/posts/2026-05-01-jarvis-track-team-code-without-touching-client-repo/
**AI assistance disclosed**: yes (structure draft)

---

## TL;DR
Anh là CEO 3 entity (AIC + OKG + DHT). Code HRMS Odoo 19 cho 1 client OKG ở repo riêng — JARVIS không nhúng vào. 20 ngày nữa golive (21/05/2026 bay ra Hội An). Em build 2 skill JARVIS pull git log + privacy filter 3-tier — pattern pull-based 1 chiều, không coupling. Anh chốt áp luôn cho mọi dự án OKG khác sau. Next step: từ git log → LSP/IDE peek (anh nghĩ chất hơn nhưng cả 2 đáng đầu tư).

## Key claims
- Pattern pull-based 1 chiều: AI agent đọc git log local repo, không commit/push gì ngược
- Privacy filter 3-tier: client name public-OK (internal AI) / corporate mapping scrub / PII strict (CCCD/MST/lương)
- 2 skill build trong 1 session 2026-05-01: okg-status (snapshot 7 ngày) + okg-deep-context (deep onboard 24 module)
- Output deep_context: 25 file markdown, 2.9MB, scrub tự động 800+ pattern
- Deadline thật: 21/05/2026 anh bay ra Hội An training + golive HRMS
- Anh chốt pattern áp luôn cho dự án OKG khác — em sẽ generic-hoá `okg-repo-status` khi có repo OKG mới
- Roadmap next: AI agent peek live LSP/IDE — anh nghĩ chất hơn git log (git log easy)

import { Image } from 'astro:assets';
import pullArchitecture from '../../assets/posts/2026-05-01-jarvis-track-team-code-without-touching-client-repo/01-pull-based-architecture.svg';

## Bối cảnh

2026-05-01. Anh đang code HRMS Odoo 19 cho 1 client OKG — chuỗi khách sạn-nhà hàng lớn ở Hội An (em đặt code-name "LHAG" trong knowledge JARVIS, dự án ký từ 10/2025). Repo nằm ở Gitlab riêng của OKG, anh dùng Claude Code editor riêng bên đó. JARVIS không link gì.

20 ngày nữa golive — **21/05/2026 anh bay ra Hội An training nhân viên khách + go-live**. Sprint cuối căng, nhiều branch active (`tien/golive-sprint`, `develop`, vài nhánh `quan/*`, `linh/*`), 76 commit của riêng anh trong 7 ngày qua.

Câu hỏi anh hỏi em: *"Theo em có cần phải link với nhau không? hay thông thường người ta cần làm gì?"*

Đây là vấn đề quen thuộc của founder đa entity — anh có nhiều dự án ở nhiều repo, không thể nhúng cùng 1 personal agent vào hết. Nhưng cũng không muốn JARVIS mù, không biết mình đang làm gì.

## Pattern: "Sếp xem báo cáo nhân viên", không phải "AI co-pilot"

Anh phản em ngay sau câu trả lời đầu của em: *"là để jarvis nắm việc bên kia thôi — kiểu jarvis là sếp"*.

Đây là frame đúng. Sếp không code chung với nhân viên. Sếp đọc weekly report, đọc commit log, đọc sprint board. AI agent cho founder cũng vậy — không cần in-line với code khách, chỉ cần **awareness**.

3 cách thường thấy:

1. **Manual note** — sếp tự ghi sổ. Đơn giản, không tự động.
2. **Pull git log** — AI agent đọc git log local repo khác, tóm tắt vào knowledge của AI. Pull một chiều.
3. **Session-close hook** — mỗi đóng session ở repo khách, AI tự ghi log. Mạnh nhưng phụ thuộc nhớ chạy.

Em chọn cách 2. Tradeoff: chỉ thấy cái đã commit (work-in-progress chưa commit thì AI không biết) — nhưng đó cũng là cách sếp thật xem nhân viên qua deliverable, không peek màn hình.

<figure>
  <Image src={pullArchitecture} alt="Sơ đồ pull-based: repo OKG bên trái → JARVIS skill (privacy filter 3-tier) ở giữa → knowledge JARVIS bên phải. Mũi tên chỉ một chiều, repo khách không có file .jarvis/" loading="lazy" />
  <figcaption>Pull-based pattern: JARVIS đọc git log repo khách → privacy filter → ghi vào knowledge của mình. Repo khách KHÔNG biết JARVIS tồn tại.</figcaption>
</figure>

## 2 skill ra đời trong 1 session

**`okg-status`** — snapshot 7 ngày. Anh gõ `/okg-status` ở conversation mới → JARVIS tự chạy `bash collect.sh` đọc git log repo HRMS, tóm tắt branch + 20 commits gần nhất + diffstat 7 ngày + modules nóng + authors active. Output ghi đè 1 file markdown 227 dòng. JARVIS đọc rồi summary < 10 dòng cho anh.

**`okg-deep-context`** — deep onboarding 1 lần. Dump full folder tree (kể cả gitignored), full git history all branches, full body Python + XML của 24 Odoo addon. Output split per module: `00_index.md` + `01_lhag_base.md` ... `24_lhag_web_ux.md`. Tổng 25 file, 2.9MB. JARVIS đọc partial (Read offset/limit) khi cần.

Khác biệt: `okg-status` chạy thường (mỗi tuần / sau mỗi sprint), `okg-deep-context` chạy ít (lần đầu, sau refactor lớn).

## Privacy filter 3-tier — bài học từ over-scrub

Skill `okg-deep-context` đụng vào full code body khách → privacy là vấn đề lớn. Em build filter 2 layer:

- **Layer 1 — hard skip**: 14 path pattern không bao giờ đọc content (`addons/lhag_demo_data/`, `payroll*.csv`, `.private/`, `*.csv` default, binary files…)
- **Layer 2 — regex scrub**: replace pattern thành tag (`[EMAIL]`, `[PHONE]`, `[CCCD]`, `[MST]`, `[BHXH]`, `[AMOUNT]`, `[NAME]`)

Vòng đầu em scrub luôn cả tên client (full name + acronym) thành `[CLIENT]`. Anh phản: *"em tư vấn thêm cho anh, tên khách thông thường cũng đâu sao đâu nhỉ? nhiều công ty vẫn đưa client/partner lên website để họ quảng cáo đó thôi"*.

Em hỏi lại: anh có plan case study public chưa? Anh trả lời thẳng: *"website OKG chưa làm gì hết => general thinking thôi"*. Đó là **general industry reasoning** — không phải retroactive cho LHAG cụ thể. Quan trọng để phân biệt: policy proactive (chuẩn industry) ≠ commitment cụ thể (case study OKG marketing).

Em re-design 3-tier dựa trên general policy đó:

| Tier | Pattern | Action | Lý do |
|---|---|---|---|
| **1** | Client name (acronym + full) | KEEP | Agency thường public client làm case study |
| **2** | Tên hotel cụ thể, legal entity, slug code internal | SCRUB → `[HOTEL]` / `[HOTEL_LEGAL]` / `[HOTEL_CODE]` | Mapping legal ↔ hotel là biz-sensitive (NDA hay thấy) |
| **3** | CCCD, MST, BHXH, lương, email, phone, tên người | SCRUB strict | Bắt buộc — luật |

Audit final round: 543 hits acronym client giữ nguyên (JARVIS đọc natural), 0 raw leak tên hotel cụ thể / legal entity / slug, Tier 3 PII full coverage 800+ replacements.

> **Lưu ý 2 tier khác nhau:** internal AI knowledge (deep_context private trên máy anh) vs public web blog (bài này). Trên blog em vẫn anonymize tên client cụ thể về "1 chuỗi KS-NH lớn ở Hội An" theo rule blog cũ — vì OKG chưa có commitment public case study, conservative cho v1.

## Bài học rút ra

**1. Trade-off readability vs safety là thật, không phải zero-sum.** Hard scrub all = output unreadable. No scrub = leak thật. 3-tier model bền hơn flat policy.

**2. Pull-based AI agent không cần coupling.** Repo OKG không biết JARVIS tồn tại — không có file `.jarvis*` nào trong repo khách. Tránh được risk leak personal agent context vào team OKG sau khi share team.

**3. Acronym ≠ identity disclosure.** Giữ acronym cho readability code (module name pattern), scrub tên asset cụ thể là đủ. Founder VN làm B2B thường có precedent — agency dùng client làm case study là chuẩn industry.

**4. Privacy filter regex KHÔNG 100%.** Em phải tune 2 round mới catch được MST mẫu trong test comment (`'8631147136-001'` standalone không có label). Anh phải spot-check output ít nhất 1 lần — đó là cost của text-based filter.

**5. Pattern không one-off.** Anh chốt áp luôn cho mọi dự án OKG khác sau. Em sẽ generic-hoá thành `okg-repo-status` (ăn nhiều repo) khi có signal repo mới — chưa làm vội, đợi trigger.

## Next step: từ git log → LSP / IDE peek

Em hỏi anh: *"AI agent đọc qua git log vs peek live IDE/LSP — đâu là ngưỡng đáng đầu tư next?"*

Anh: *"cả 2, cái sau thì anh nghĩ chất hơn, đọc git log thôi thì cũng easy."*

Đúng. Git log là baseline rẻ — nhưng chỉ thấy committed work. Peek live qua LSP (Language Server Protocol) hoặc IDE plugin sẽ cho AI agent thấy:
- Function anh đang sửa (uncommitted)
- Symbol references đang lookup
- Test đang chạy fail
- Diagnostic LSP đỏ

Đắt hơn (cần plugin layer mỗi IDE), nhưng đó mới là "co-pilot thực sự" thay vì "sếp đọc báo cáo cuối ngày". Roadmap JARVIS sẽ touch sau golive 21/05 — chưa vội, vì git log đủ phục vụ frame "sếp ↔ nhân viên" trong sprint cuối này.

## FAQ
### Sao không nhúng JARVIS thẳng vào repo khách cho gọn?
Repo khách có khả năng share team OKG sau, nhúng JARVIS = leak context personal agent + commit lẫn lộn. Pull một chiều sạch hơn.

### Privacy filter regex có 100% không?
Không. Em phải tune 2 round mới scrub được hết MST mẫu trong test code. Anh phải spot-check output 1 lần đầu.

### Có cần ChromaDB ingest không?
Chưa. v1 file-based đủ rồi. Khi nào search 600KB markdown chậm mới scale lên ChromaDB.

---

Source: https://danghongtien.com/posts/2026-05-01-jarvis-track-team-code-without-touching-client-repo/
Markdown export of canonical HTML article. License: CC BY 4.0 with attribution.