Auto-sync 2026-08-16 06:00:01

2026-08-16 06:08:04 +08:00
commit 45061218f3
31 changed files with 2207 additions and 0 deletions
@@ -0,0 +1,19 @@
+ CEO’s solution. But CEO’s outcome (reduce fraud complaints) is valid. The squad’s *what* should be: “Help users self-audit transactions to reduce fraud calls.” That serves the CEO’s outcome and the user’s job.
+
+**MUJTAHID:**  
+Shura in Islam is not a vote. It is *istishara* — seeking counsel from those with *‘ilm* and *hilm* (wisdom). The *mujtahid* (decision-maker) listens to all, then issues a *hukm*. Dissent must be recorded but does not block action.  
+
+Record the **dissent** from the Engineering Lead: “We will lose velocity building fraud alert first.” That becomes a *shart* (condition) for the decision: if velocity drops below X, revisit.  
+
+Now document the *shura* process in a log:  
+- Participants: CEO, Eng Lead, PM, User Researcher.  
+- Inputs: Outcome (reduce complaints), User JTBD (self-audit), Technical constraints (2 weeks vs 3 months).  
+- Weighted evidence: User research (2x weight), Engineering feasibility (1.5x), CEO outcome (1x).  
+- Decision: Squad *maqsad* = “Reduce fraud complaints by enabling self-audit via transaction history.”  
+- Dissent recorded: Eng Lead wants fraud alert; rationale noted. Condition: If after 4 weeks fraud complaints don’t drop, re-open shura.  
+
+This is *shura at scale* — not a committee of equals, but a structured consultation where the *wali al-amr* (Product Lead) holds final authority, bounded by the *maqsad* and *shurut*.
+
+---
+
+*[End of Part 1 — Scenario, Discovery, Evidence, Shura. Continue to Part 2: Principle (Hukm), Protocol, Muhasaba.]*