# Accounting Module — Phase 0 Tasks (Governance ও Discovery)

> এখানকার প্রতিটা task আলাদা করে একজন কাজ করতে পারবে।
> Phase 0-এ কোনো product code নেই। মানে journal বা report বানানোর কিছু নেই। কাজ হলো সবাই একমত হওয়া, জিনিসপত্র নিশ্চিত করা, আর design প্রমাণ করা। কিন্তু পরের সব কাজ এগুলোর ওপর দাঁড়ায়, তাই আলাদা task হিসেবে রাখা।
> Estimate, Owner, Sprint ইচ্ছে করে খালি রাখা হয়েছে — Discovery শেষ হলে ভর্তি হবে।

**Phase 0 কে কার ওপর ঝুলে আছে:**

```
P0-01 ──┬─► P0-02 ──► P0-05 ──► (P1-09, P1-10)
        ├─► P0-03 ──► P1-01
        └─► P0-04 ──► P1-03
```

---

## ACC-P0-01 — Blueprint ও ADR অনুমোদন

Project
ERPFlow
Module
Accounting Module
Type
Governance (`gov`)
Title
Blueprint ও ADR অনুমোদন
Branch Name
কোনো branch নেই (নথি-ভিত্তিক কাজ)
View Order
1
Description
**Summary**
আগে সবাই লিখিতভাবে একমত হয়ে নাও: Blueprint, ADR (A1 থেকে A10), Phase ক্রম, আর Open Decision register। না হলে পরে Accounting module এদিক-ওদিক বানানো শুরু হবে।

**Task serial**
`ACC-P0-01 — Blueprint ও ADR অনুমোদন` · Governance

**Depends on**
- Cursor-এর Phase 0 audit report (শেষ হতে হবে)
- Accounting Module Blueprint
- Task Specification Pack (এই doc)

**Relation: আগের task**
এটাই প্রথম কাজ। এর আগে শুধু Cursor-এর read-only audit report লাগে।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `ACC-P0-02` (Repo convention চেক): এই অনুমোদন ছাড়া শুরু করা যাবে না।
- `ACC-P0-03` (Branch ও release নিয়ম) আর `ACC-P0-04` (Client decision list): দুটোই এটার ওপর।
- পুরো Phase 1: সই না হলে Phase 1-এর কোনো কাজ শুরু করা যাবে না।

**Related tables / schema**
লাগে না। কোনো DB কাজ নেই।

**Business rules**
- Architecture decision A1 থেকে A10 কাগজে লিখে মানতে হবে।
- Audit যে তিনটা ফাঁক ধরেছে, সেগুলো নথিতে "স্বীকৃত" লিখে রাখতে হবে: (1) ApprovalEngine-এ amount threshold নেই, (2) posted journal DB-level-এ অপরিবর্তনীয় নয়, (3) company-তে currency ও fiscal year field নেই।
- প্রতিটা Open Decision (OD)-র একজন করে owner থাকতে হবে।

**Task scope**
1. Tech lead, Product owner আর Finance contact মিলে Blueprint-এর section ১ থেকে ১২ পড়ে যাওয়া।
2. ADR (A1 থেকে A10) পড়ে হ্যাঁ বলা, না হলে আপত্তি লেখা।
3. Audit-এর ফাঁকগুলো "স্বীকৃত" হিসেবে নথিতে তোলা।
4. প্রতিটা OD-র জন্য কে দায়িত্ব নেবে সেটা ঠিক করা।
5. পর্যালোচনায় বদল লাগলে Blueprint আপডেট করা।
6. অনুমোদন নথিতে সই নেওয়া।

**Out of scope**
Code, migration, client-এর কাছে কিছু পাঠানো (সেটা `ACC-P0-04`)।

**Deliverable**
- সই করা অনুমোদন নথি
- সংশোধিত Blueprint (যদি দরকার হয়)

**Definition of done**
- লিখিত অনুমোদন আছে।
- প্রতিটা OD-র একজন owner আছে।
- Audit-এর তিন ফাঁক নথিতে "স্বীকৃত" লেখা আছে।
- পরের task (`P0-02`, `P0-03`, `P0-04`) শুরু করার রাস্তা খুলে গেছে।

**Architecture constraints**
- Blueprint-এর বাইরে কোনো architecture সিদ্ধান্ত মুখে মুখে নেওয়া যাবে না — সব লিখিত।

Owner
All (TL+PO+Finance)
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P0-02 — Repo-র convention নিশ্চিত করা (spike)

Project
ERPFlow
Module
Accounting Module
Type
Governance (`gov`), read-only investigation
Title
Repo-র convention নিশ্চিত করা (spike)
Branch Name
কোনো branch নেই (read-only, কোনো code বদলাবে না)
View Order
2
Description
**Summary**
Pack-এ যেখানে "অনুমান" লেখা, সেগুলো আসল কোড খুলে মিলিয়ে দেখো। না হলে Phase 1-এ ভুল ধরে নিয়ে কাজ শুরু হবে, পরে ঘুরে আসতে হবে।

**Task serial**
`ACC-P0-02 — Repo-র convention নিশ্চিত করা` · Spike

**Depends on**
- `ACC-P0-01`

**Relation: আগের task**
`ACC-P0-01` বলে দিয়েছে Blueprint ও Pack ঠিক পথে। এখন সেই Pack-এর অনুমানগুলো কোডে মিলিয়ে দেখতে হবে।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `ACC-P0-05` (DB guard spike): trigger বানানো যায় কি না — এই task-এর ১২ নম্বর উত্তরের ওপর।
- `ACC-P1-01` (Module scaffold) আর Phase 1-এর সব schema task: PK ধরন (bigint না ULID) এখান থেকে আসবে।
- প্রায় সব Phase 1 task কোনো না কোনো উত্তর ব্যবহার করবে (নিচের তালিকা দেখো)।

**Related tables / schema**
নতুন কিছু বানাতে হবে না, শুধু পড়া। যেগুলোর নাম ও key নিশ্চিত করতে হবে: `companies`, `users`, `settings`, `activity_logs`, RBAC table।

**যা নিশ্চিত করতে হবে (১২টা প্রশ্ন, প্রতিটার উত্তর file path ও line সহ)**

| # | প্রশ্ন | কোন task এটা ব্যবহার করবে |
| --- | --- | --- |
| 1 | বিদ্যমান table-এর primary key ধরন: bigint unsigned নাকি ULID? | সব schema task (সব `*_id` column) |
| 2 | `companies` ও `users` table-এর নাম ও key | সব FK |
| 3 | `TenantContext` queue আর console job-এ কীভাবে বসে? | `ACC-P1-12` (base job) |
| 4 | `Setting` model-এর API (group, key, value, cache) | `ACC-P1-01` (flag), `ACC-P1-03` |
| 5 | `ActivityLogService`-এর method signature | `ACC-P1-12` (audit) |
| 6 | `ApprovalEngine`-এর contract ও executor registry | Phase 2 approval (OD-6) |
| 7 | permission কীভাবে `config/actions.php`-এ যোগ হয় ও role-এ বসে | `ACC-P1-02` |
| 8 | module scaffold কীভাবে হয় (কোন command, কোন module নকল করা হয়) | `ACC-P1-01` |
| 9 | queue driver ও scheduler কেমন | `ACC-P1-08` (job), Phase 3+ |
| 10 | file storage ও attachment এখন কেমন | `ACC-P1-09`, `P2-02` |
| 11 | test framework ও factory-র নিয়ম | `ACC-P1-13` |
| 12 | DB user trigger বানাতে পারে কি না (binary log থাকলে `log_bin_trust_function_creators`) | `ACC-P0-05`, `ACC-P1-10` |

**Business rules**
- যা নিশ্চিত না, সেটা স্পষ্ট করে "অনিশ্চিত" লিখো। অনুমানকে নিশ্চিত বলে চালিয়ে দিও না।
- কোনো code, migration বা config বদলানো যাবে না।
- PK ধরন বদলালে Pack-এর সব `*_id` column-এর ধরন বদলায় — আর কিছু নয়।

**Task scope**
১২টা প্রশ্নের প্রতিটার জন্য repo-তে খুঁজে file ও line সহ উত্তর লেখো। এক পাতার "Convention Sheet" বানাও।

**Out of scope**
কোনো code লেখা, কোনো migration লেখা।

**Deliverable**
"Convention Sheet": এক পাতা, প্রতিটা প্রশ্নের উত্তর file path ও line সহ।

**Definition of done**
- ১২টা প্রশ্নের সবকটার উত্তর আছে।
- অনিশ্চিতগুলোতে স্পষ্ট "অনিশ্চিত" লেখা।
- Convention Sheet tech lead দেখেছে।
- PK ধরন (প্রশ্ন ১) সবার জানা আছে।

**Architecture constraints**
- Read-only। Repo-তে কোনো commit নেই।

Owner
Dev A
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P0-03 — Feature branch ও release নিয়ম

Project
ERPFlow
Module
Accounting Module
Type
Governance (`gov`)
Title
Feature branch ও release নিয়ম
Branch Name
`feature/accounting-governance-release-rules` (শুধু CI check ও PR template-এর জন্য)
View Order
3
Description
**Summary**
ERPFlow-এ `development`-এ push মানেই production deploy। তাই অসম্পূর্ণ Accounting কাজ যেন সেখানে না যায় — সেই নিয়ম আগে বেঁধে নাও।

**Task serial**
`ACC-P0-03 — Feature branch ও release নিয়ম` · Governance

**Depends on**
- `ACC-P0-01`

**Relation: আগের task**
`ACC-P0-01` অনুমোদন দিয়েছে। এখন সেই architecture নিরাপদে merge করার নিয়ম বানাতে হবে।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `ACC-P1-01` (Module scaffold): প্রথম code merge হওয়ার আগে এই নিয়ম আর CI check থাকতে হবে।
- `ACC-P1-14`, `P2-17`, `P4-13` (merge gate): এই task-এর PR template আর CI check ব্যবহার করবে।

**Related tables / schema**
লাগে না।

**Business rules (পরের সব task এগুলো মানতে বাধ্য)**
1. Accounting-এর সব কাজ `feature/accounting-*` branch-এ।
2. `development`-এ merge শুধু flag বন্ধ রেখে। PR-এ "flag Default বন্ধ প্রমাণিত" চেকবক্স থাকবে।
3. প্রতিটা migration পিছনে সামঞ্জস্যপূর্ণ হতে হবে (আগে যোগ, পরে বদল, শেষে মোছা), PR-এ তার প্রমাণ।
4. Project, Payroll, Asset, Commissioning-এর code Phase 1 থেকে 3-এ বদলানো যাবে না।
5. CI-তে একটা অতিরিক্ত job থাকবে যা দেখবে Accounting-এর কোনো flag Default `true` নয়।

**Task scope**
1. Branching ও merge নিয়মের এক পাতা লেখো।
2. PR template বানাও (flag-বন্ধ চেকবক্স, migration সামঞ্জস্য প্রমাণ, অন্য module অপরিবর্তিত প্রমাণ)।
3. CI check-এর খসড়া: Accounting-এর flag Default `true` হলে build ব্যর্থ হবে।
4. ইচ্ছে করে একটা ভুল PR দিয়ে CI check পরীক্ষা করো।

**Out of scope**
Accounting-এর কোনো feature code।

**Deliverable**
Branching ও merge নিয়মের এক পাতা, PR template, CI check-এর খসড়া।

**Definition of done**
- নিয়ম দলের সবাই মেনেছে (লিখিত স্বীকৃতি বা review-এ সম্মতি)।
- CI check ইচ্ছে করে ভুল PR-এ ব্যর্থ হয় (প্রমাণ সংযুক্ত)।
- PR template repo-তে আছে।

**Architecture constraints**
- Accounting-এর কোনো flag-এর Default `true` হওয়া যাবে না।
- বিদ্যমান ERPFlow CI job (বিশেষ করে `backend-mysql-concurrency`) ভাঙা যাবে না।

Owner
Dev B
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P0-04 — Client-এর Setup Checklist ও Decision list পাঠানো

Project
ERPFlow
Module
Accounting Module
Type
Governance (`gov`)
Title
Client-এর Setup Checklist ও Decision list পাঠানো
Branch Name
কোনো branch নেই (নথি-ভিত্তিক কাজ)
View Order
4
Description
**Summary**
Client-কে স্পষ্ট করে বলো — কোন সিদ্ধান্ত কখন নিতে হবে। না হলে সিদ্ধান্তের অভাবে dev কাজ আটকে যাবে।

**Task serial**
`ACC-P0-04 — Client-এর Setup Checklist ও Decision list পাঠানো` · Governance

**Depends on**
- `ACC-P0-01`

**Relation: আগের task**
`ACC-P0-01` OD register-এর owner ঠিক করেছে। এখন সেই OD-গুলো client-এর ভাষায় ছোট করে পাঠাতে হবে।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `ACC-P1-03` (Settings store): setting-এর কাঠামো আটকায় না, কিন্তু OD-3 (currency), OD-4 (fiscal year) ছাড়া setting-এর **মান** বসানো যাবে না।
- `ACC-P4-01` (Asset pilot change request): এই task-এর আলাদা পাতায় OD-18-এর খসড়া থাকে।

**Related tables / schema**
লাগে না। Source: Pack-এর Section ২.৪ (Settings registry) আর Blueprint section ১১ (OD register)।

**Business rules**
- Client-কে প্রতিটা সিদ্ধান্ত নাম ধরে বলতে হবে: কোন সিদ্ধান্ত, কে নেবে, কোন Phase শুরুর আগে লাগবে।
- Asset pilot-এর change request (OD-18) আলাদা পাতায় রাখো — এটা মূল scope-এর বাইরের জিনিস।

**Task scope**
1. Settings registry আর OD register থেকে client-এর জন্য ছোট নথি বানাও।
2. প্রতিটা সিদ্ধান্তের পাশে লেখো: কে নেবে, কোন Phase-এর আগে।
3. OD-18-এর change request খসড়া আলাদা পাতায় রাখো।
4. Client-কে পাঠাও আর প্রাপ্তি নিশ্চিত করো।
5. প্রতিটা OD-র নাম ধরে একজন owner লিখে নাও।

**Out of scope**
Setting-এর মান নিজে বসানো। সিদ্ধান্ত নিজে নেওয়া।

**Deliverable**
Client-কে পাঠানো নথি, OD owner-এর তালিকা।

**Definition of done**
- Client নথি পেয়েছে (প্রমাণ সহ)।
- প্রতিটা OD-র নাম ধরে একজন owner নির্ধারিত।

**Architecture constraints**
লাগে না (নথি-কাজ)।

Owner
Dev C
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment

---

## ACC-P0-05 — DB guard ও ledger-উৎস design spike

Project
ERPFlow
Module
Accounting Module
Type
Governance (`gov`), design spike (prototype merge হবে না)
Title
DB guard ও ledger-উৎস design spike
Branch Name
`spike/accounting-db-guard-prototype` (কখনো `development`-এ merge হবে না)
View Order
5
Description
**Summary**
Posted journal DB স্তরে কীভাবে আটকে থাকবে, আর ledger কোথা থেকে পড়া হবে — এটা প্রমাণসহ ঠিক করো। না হলে Phase 1-এর schema ভুল ভিত্তিতে বানানো শুরু হবে।

**Task serial**
`ACC-P0-05 — DB guard ও ledger-উৎস design spike` · Spike

**Depends on**
- `ACC-P0-02` (বিশেষ করে ১২ নম্বর উত্তর: DB user trigger বানাতে পারে কি না)

**OD**
OD-13 (DB guard), OD-14 (ledger-উৎস)

**Relation: আগের task**
`ACC-P0-02`-এর Convention Sheet বলে দেবে CI-র MySQL আর deployment-এ trigger বানানোর অনুমতি আছে কি না। সেই উত্তর ছাড়া এই spike অর্থহীন।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `ACC-P1-09` (Journal table): `acc_journals`-এর generated column আর constraint এই spike-এর সিদ্ধান্ত অনুযায়ী।
- `ACC-P1-10` (DB guard বাস্তবায়ন): এই spike-এর প্রমাণিত trigger নকশা হুবহু বাস্তবায়ন হবে।
- `ACC-P3-01` (Ledger query): OD-14-এর ফল (posted line নিজেই ledger নাকি আলাদা projection) এখান থেকে।

**Related tables / schema**
Prototype-এর জন্য `acc_journals`, `acc_journal_lines` (শুধু prototype, production migration নয়)।

**OD-13-এর বিকল্প**
- (ক) `BEFORE UPDATE` ও `BEFORE DELETE` trigger যা `acc_journals.status = 'posted'` থাকলে `SIGNAL` দিয়ে ব্যর্থ করে; `acc_journal_lines`-এ parent-এর status দেখে একই কাজ। **(Pack-এ ধরে নেওয়া)**
- (খ) Application-এর DB user-এর অনুমতি কমানো।
- (গ) দুটোই।

**OD-14**
Posted `acc_journal_lines` সরাসরি ledger (Option A, ধরে নেওয়া) নাকি আলাদা projection (Option B)।

**Business rules (prototype-এ যা প্রমাণ করতে হবে)**
- Posted row-এ সরাসরি `UPDATE` ও `DELETE` ব্যর্থ হয়।
- `INSERT` আর Draft-এ `UPDATE` চলে।
- Post-এর transaction-এর ভেতরে অবস্থা বদল চলে: `approved` থেকে `posted` ঠিক আছে, `posted` থেকে অন্য কিছু নিষিদ্ধ।
- `reversed` চিহ্ন বসানো চলে, কিন্তু শুধু নির্দিষ্ট column বদলে (`status`, `reversed_at`, `reversed_by_journal_id`, `updated_at`, `updated_by`, `version`)।

**Task scope**
1. CI-র MySQL-এ trigger-এর prototype বানিয়ে উপরের চারটা আচরণ test করো।
2. বড় data-য় (১০ লক্ষ line) GL query-র গতি মেপে Option A আর Option B তুলনা করো।
3. Trigger-এর `down()` নিরাপদ কি না লেখো।
4. Design note লেখো: কোন উপায় বেছে নেওয়া হলো আর কেন।

**Out of scope**
Production migration (সেটা `ACC-P1-09`, `ACC-P1-10`)। Prototype merge করা।

**Deliverable**
Design note (কী বেছে নিলাম, কেন), prototype migration ও test, trigger `down()`-এর নিরাপত্তা বিশ্লেষণ।

**Definition of done**
- Prototype CI-র MySQL-এ চলে।
- `JRN_IMMUTABLE` আচরণ প্রমাণিত।
- OD-13 ও OD-14 লিখিতভাবে বন্ধ (tech lead ও client জানে; বিশেষ করে trigger না বসানো গেলে বিকল্প দুর্বল — সেটাও স্পষ্ট)।
- Prototype branch `development`-এ merge হয়নি।

**Architecture constraints**
- Prototype production code-এ যাবে না।
- Trigger বানানো না গেলে বিকল্প: application guard + `posted_hash` দিয়ে রাতের integrity check। এটা দুর্বল, তাই OD-13-এ client ও tech lead-কে স্পষ্ট জানাতে হবে।

Owner
Dev A
Estimate Hours
3
Status
Todo
QA Status
-
QA Comment