Kinh nghiệm · Bài học kinh nghiệm
Tuân thủ gốc Git: từ khái niệm đến nguyên mẫu
Báo cáo kinh nghiệm này đã được ẩn danh hóa (tổ chức ORG-1, doanh nhân E1). Nó không mô tả một giải pháp hoàn chỉnh, mà là một con đường: cách một hình mẫu trừu tượng — „tuân thủ được neo ngay trong chính .git“ — qua một loạt buổi làm việc đã trở thành một bản phác thảo nguyên mẫu có thể kiểm chứng. Bài học rút ra từ đó ít mang tính kỹ thuật hơn là phương pháp luận.
Bối cảnh ban đầu
ORG-1 liên kết nhiều pháp nhân: một tổ chức phi lợi nhuận, một công ty phát triển và chính doanh nhân E1 với tư cách là doanh nghiệp cá nhân. Từ sự kết hợp này nảy sinh ba câu hỏi tuân thủ khác nhau mà người ta dễ nhầm lẫn:
- Ưu đãi thuế (Forschungszulage): Giờ làm việc nào thuộc dự án nào?
- Tính công ích (§ 60a AO): Một hoạt động thuộc lĩnh vực nào — lý tưởng, hoạt động mục đích, quản lý tài sản hay hoạt động kinh doanh thương mại?
- Tính hợp quy (GoBD/AO): Mỗi chứng từ có thể truy vết, không thể thay đổi và đầy đủ không?
Trong thực tế, những câu hỏi này thường được trả lời „theo cảm tính“ — và chính ở đó nảy sinh những rủi ro mà một cuộc kiểm tra sau này sẽ làm lộ ra.
Cuộc trò chuyện như công cụ thiết kế
Điểm đặc biệt của dự án này: E1 làm việc với một tác nhân AI mã nguồn mở, cục bộ như một đối tác đối thoại. Không phải trình tạo mã, mà là một đối tác đối thoại, đọc bối cảnh doanh nghiệp hiện có (tài liệu, quy ước, các quyết định đã đưa ra) và cùng mài giũa trong cuộc trò chuyện.
Hiệu quả quyết định không phải là tốc độ, mà là tính nhất quán: Mỗi quyết định được đưa ra đều ngay lập tức được kiểm tra đối chiếu với kiến trúc hiện có — „điều này có phù hợp với những gì đã được quy định mang tính chuẩn tắc, hay chúng ta đang vô tình định nghĩa trùng lặp điều gì đó?“
Bài học 1: Một tác nhân chỉ tạo ra mà không kiểm tra hiện trạng sẵn có sẽ tạo ra sự dư thừa. Một tác nhân trước tiên tìm rồi sau đó mới đề xuất sẽ tạo ra tính nhất quán.
Thành phần đầu tiên: kiểm tra lĩnh vực dưới dạng call-back
Điều hiển nhiên lẽ ra là đưa logic lĩnh vực vào nơi cần đến nó — vào từng công cụ ghi nhận chứng từ. Cách đó không mở rộng được và phân tán cùng một quy tắc ra nhiều nơi.
Thay vào đó, người ta tìm thấy một mẫu đã có sẵn: một registry với các action-/call-identifier trong thư mục TOP/.gitcover riêng của từng tenant. Mỗi bước có thể thực thi mang một khóa ghép từ hai định danh — „nó là gì“ và „nó được thực thi như thế nào“. Khi đó, một công cụ không cần biết tổ chức chủ quản cụ thể: nó gọi một identifier, và một cơ chế phân giải xuyên các tầng (từ tenant cụ thể đến quy phạm chung) sẽ tìm ra handler chịu trách nhiệm.
Anfrage: "das ist ein gemeinnütziger Eintrag"
│
▼
Registry-Auflösung (mandanten-spezifisch → normativ)
│
├── gefunden → Handler des Trägers (Sphärenprüfung § 60a)
└── keiner → bewusster No-Op (keine Prüfung nötig)
Nguyên tắc này gợi nhớ đến phân giải interface trong lập trình hướng đối tượng: người ta hỏi về một năng lực, không phải về một kiểu cụ thể. Tác dụng phụ: các tổ chức không vì mục đích công ích tự động nhận được một „không áp dụng“ gọn gàng — hoàn toàn không cần trường hợp đặc biệt trong mã.
Bài học 2: Một quy tắc áp dụng ở mọi nơi thuộc về một chỗ với một giao diện ổn định — không phải được sao chép vào từng công cụ.
Thành phần thứ hai: các hiện vật tuân thủ có thể tái tạo
Nhận thức thứ hai liên quan đến cách thức phân phối. Kiến thức quy định — các nguyên tắc GoBD, các nguyên tắc DSGVO, thời hạn lưu trữ — hiện nay nằm trong các sổ tay mà không ai đánh giá. Cách tiếp cận ở đây: kiến thức như vậy trở thành các hiện vật được phiên bản hóa, đọc được bằng máy trong kho Git.
Regulatorik → Katalog (maschinenlesbar) → Policies (ausführbar)
│
Git-clone / Tool-Update
│
prüfbares Ergebnis im Arbeitsverzeichnis
Hình mẫu không phải là CI/CD cho ứng dụng, mà là một „CI/CD cho dữ kiện doanh nghiệp“: Cùng một cơ chế cập nhật quen thuộc từ các công cụ phần mềm, ở đây mang kiến thức tuân thủ đi — được phiên bản hóa, có thể ký, có thể kiểm chứng.
Điều này có ý nghĩa gì cho thực tiễn
- Chứng từ vẫn là chứng từ. Các phép chiếu, trọng số và ý định đằng sau một sự phân loại không thuộc về hồ sơ được công bố — ở đó là kết quả, thứ trong trường hợp nghi ngờ phải có thể chứng minh được.
- Phân tách thay vì dán nhãn. Một hoạt động hành chính không trở nên đủ điều kiện được tài trợ chỉ vì người ta gọi nó gần với nghiên cứu. Cơ quan kiểm tra nhìn vào nội dung, không nhìn vào tiêu đề.
- Các quy định riêng tư vẫn là riêng tư. Các đánh giá cá nhân, trọng số và tiêu chí cân nhắc của người phê duyệt không thuộc về kho lưu trữ chung đã được phiên bản hóa — chúng được giữ cục bộ và không được trích dẫn. Từ chúng, trước hết mới hình thành các tài liệu quyết định, những thứ sau đó có thể chứng minh được. Các tác nhân tuân thủ những quy định như vậy, nhưng chỉ ghi lại kết quả.
- Trước tiên tìm, sau đó mới xây. Trước mỗi thành phần mới, câu hỏi sau là đáng giá: Điều đó đã tồn tại chưa — chỉ dưới một cái tên khác?
Bài học 3: „Từ khái niệm đến nguyên mẫu“ không có nghĩa là xây nhiều thứ mới. Nó có nghĩa là coi trọng bản thiết kế hiện có và đặt viên đá tiếp theo đúng chỗ.
Những gì được ký được phân định trong index
Một mẫu khác liên quan đến chính việc ký. Khi một tài liệu được đưa ra để ký
(presented), chỉ các tài liệu gốc cần ký được đưa vào staging (git add) —
nhờ đó Git-Index chỉ rõ ràng cái gì cần được ký, tách biệt khỏi phần còn lại của trạng thái làm việc.
Một văn bản commit phù hợp được chuẩn bị; công cụ cố ý không commit
(gc-docsign present …). Chỉ người ký mới ký commit đã được phân định
(GPG). Như vậy, „bản trình“ và „chữ ký“ vẫn được tách bạch rõ ràng — và chứng từ không bị làm sai lệch.
Triển vọng
Bản phác thảo đã thành hình: một phép kiểm tra lĩnh vực tự phân giải ở nơi nó không cần thiết; một hệ thống quy tắc du hành như một hiện vật qua chính những kênh như mã. Việc từ đó có thành một công cụ hữu ích cho các tổ chức nhỏ khác hay không không do kỹ thuật quyết định — mà do sự sẵn sàng đặt mọi giả định trước một cuộc kiểm tra trước khi nó trở thành thói quen.
Báo cáo này đã được ẩn danh hóa (tổ chức ORG-1, doanh nhân E1). Đây là một phần của loạt bài Kinh nghiệm & Bài học kinh nghiệm.