🇬🇧 Purpose

Defines how automation is used in ProSys and the exact design principles every rule must follow. Goals: No spam, no duplicated execution, no hidden side-effects, fully debuggable and auditable.

🇻🇳 Mục đích

Định nghĩa cách ProSys dùng automation và nguyên tắc bắt buộc cho mọi rule.

1. Core principles: Transition-triggered only (FROM → TO; never "Issue updated" or "Field changed"). One rule = one transition. Guard by entity property for any notify/calculate/write. Prefer comment over email; email only at decision points.

2. Categories: Guidance comments (when entering stage); Decision notifications (QUOTES → PM APPROVE QUOTE, INVOICE → FM APPROVE TO PAY); Data consistency (Uploaded At, Commission); Governance (future: missing labels/attachments).

3. Entity property convention: Naming e.g. pmApprovalNotified, fmQuoteApprovalNotified, fmPaymentApprovalNotified, commissionCalculated, uploadedAtSet. If property does NOT exist → run; after run → set property = true.

4. Standard rules (summary): (1) Comment when entering QUOTES – guide collect quotes. (2) Notify PM when QUOTES → PM APPROVE QUOTE (guard pmApprovalNotified). (3) Notify FM when PM APPROVE QUOTE → FM APPROVE QUOTE (guard fmQuoteApprovalNotified). (4) Comment when entering SERVICES BEING DELIVERED – track delivery. (5) Comment when entering INVOICE – upload invoice. (6) Notify FM when INVOICE → FM APPROVE TO PAY (guard fmPaymentApprovalNotified). (7) Set Uploaded At when attachment added (guard uploadedAtSet). (8) Calculate Commission when FM APPROVE TO PAY → DONE (guard commissionCalculated).

5. Forbidden: "Issue updated" trigger; chaining multiple transitions in one rule; automation that changes status implicitly; automation as hidden workflow.

6. Debugging: Check rule audit log and entity properties on issue. Most bugs = missing guard or wrong trigger.

Final rule: If a behavior is not defined here → it must not exist in automation.