# Accounting Module — Phase 5 Tasks (UAT ও Controlled Release)

> এখানকার প্রতিটা task আলাদা করে একজন কাজ করতে পারবে।
> Phase 5-এ নতুন feature নেই—এখানে journal বা report নতুন বানানোর কাজ নয়। কাজ হলো প্রমাণ, মহড়া, নজরদারি আর ধাপে ধাপে চালু করা। শুধু দুটো card-এ code আছে: monitoring (`P5-03`) আর release gate (`P5-06`); `P5-05`-এ test code ও ফাঁক সংশোধন।
> মনে রাখো: `development`-এ merge মানেই production-এ deploy। তাই merge আর "চালু করা" আলাদা কাজ—flag বন্ধ রেখেই merge করতে হবে।
> ক্রম (master sequence অনুযায়ী): UAT → cutover মহড়া → monitoring → rollback → security ও performance → release gate → training → pilot চালু।
> Estimate, Owner, Sprint ইচ্ছা করে খালি রাখা হয়েছে।

## সব Phase 5 task-এ প্রযোজ্য সাধারণ নিয়ম (প্রতিটা task নিজের DoD-তে এগুলো ধরে নেয়)

- Phase 5 শুরু হয় Phase 4 পুরো সবুজ (`ACC-P4-12`) আর release-প্রস্তুত (`ACC-P4-13`, সব flag সব company-তে বন্ধ) হওয়ার পর। `P5-01` ও `P5-04` সরাসরি `P4-13`-এর ওপর; `P5-03`, `P5-05` সরাসরি `P4-03/P4-10`, `P4-12`-এর ওপর।
- **Merge আর চালু করা আলাদা।** `development`-এ merge মানে production deploy; flag বন্ধ রেখেই merge। কোনো company-তে `accounting.enabled` চালু হয় শুধু `P5-06`-এর release gate দিয়ে, `P5-08`-এ।
- **Production-এ কখনো করা যাবে না** (`P5-04`-এ বিস্তারিত): (১) Trigger বা unique constraint-এর migration-এর `down()` চালানো। (২) Accounting-এর কোনো table-এর row সরাসরি SQL-এ বদলানো বা মোছা। (৩) Posted journal ঠিক করতে trigger বন্ধ করা। ভুল ঠিক করার একমাত্র পথ Reversal ও Adjustment।
- Database (যেখানে code আছে): MySQL, InnoDB, `utf8mb4`, prefix `acc_`, `company_id NOT NULL` ও composite index-এ সবার আগে, টাকা `DECIMAL(20,4)`, enum `VARCHAR` + `CHECK`, `version` কলাম ও optimistic lock, composite FK `(company_id, *_id)`, `ON DELETE RESTRICT`। Migration আলাদা, পিছনে সামঞ্জস্যপূর্ণ (আগে যোগ, পরে বদল, শেষে মোছা), `down()` নিরাপদ। Append-only table `Schema::appendOnly('table')` (`ACC-P1-10`)।
- Production-এ কোনো লেখা নেই এমন কাজ (মহড়া, UAT, security test): শুধু **staging**, production-এর মতো কাঠামো। Staging data মুছে আবার শুরু করা যায়।
- একই সময়ে একটার বেশি company চালু নয় (প্রক্রিয়াগত নিয়ম, system আটকায় না, Release manager আটকায়)।
- Blueprint-এর `R5.x`, `AC5.x` নম্বর Pack-এ যেভাবে উল্লেখ আছে ঠিক সেভাবে রাখা হয়েছে; Blueprint নিজে এই task-এর সাথে নেই, তাই এই নম্বরগুলোর সংজ্ঞা open point হিসেবে চিহ্নিত।
- **DoD-র সাধারণ অংশ (code-ভিত্তিক card-এ, `P5-03`, `P5-05`-এর fix, `P5-06`):** Service–Repository architecture (interface সহ), Form Request, API Resource; `company_id` tenant scope + IDOR test; Feature test (happy path, validation, unauthorized/forbidden); audit event `AccountingAudit` দিয়ে; error `AccountingError` enum-এর code দিয়ে; Job হলে `AccountingJob` base (company context); concurrency/constraint test MySQL-এ; বিদ্যমান ERPFlow regression সবুজ; Project/Payroll/Asset/Commissioning-এর code অপরিবর্তিত।
- **Process/ops card-এর DoD (`P5-01`, `02`, `04`, `07`, `08`):** লিখিত deliverable নথি, সই বা লিখিত নিশ্চয়তা, প্রমাণ (screenshot/export/log) সংযুক্ত, নথি প্রকল্পের নথি-ভান্ডারে, QA tool বা release রেকর্ডে লিংক।

**Phase 5 নির্ভরতা-ছবি:**

```
P3-15 + P4-13 ─► P5-01 ─┬─► P5-06 ─────────────────────┐
                        └─► P5-07 ──────────────────────┤
P3-15 + P2-14 + P3-11 ─► P5-02 ─► P5-06                  │
P4-12 + P3-14 ─► P5-05 ─► P5-06   (P1-05, P4-11-ও)       ├─► P5-08  (শেষ card)
P3-13 + P4-03 + P4-10 + P2-15 ─► P5-03 ──────────────────┤
P4-13 ─► P5-04 ──────────────────────────────────────────┘
```

**Build order (master sequence ক্রম 41 থেকে 43):** ক্রম 41: P5-01, P5-02, P5-03, P5-04, P5-05 (একসাথে চলতে পারে) → ক্রম 42: P5-06, P5-07 → ক্রম 43: P5-08।

---

## ACC-P5-01 — UAT pack ও সই

Project
ERPFlow
Module
Accounting Module
Type
Test + Governance (`test` + `gov`)
Title
UAT pack ও সই
Branch Name
কোনো branch নেই (QA tool ও নথি-ভিত্তিক কাজ)
View Order
66
Description
**Summary**
Client-এর accountant আর finance team staging-এ নিজের হাতে সত্যিকারের পরিস্থিতিতে পুরো system যাচাই করবে, তারপর লিখিতভাবে সই করবে। production-এ চালুর আগে "ব্যবহারকারী মেনে নিয়েছে"—এর প্রমাণ থাকতে হবে; Finance owner-ও সেটাই চায়।

**Task serial**
`ACC-P5-01 — UAT pack ও সই` · Test + Governance

**Depends on**
- `ACC-P3-15` (accountant-এর সই করা নমুনা report pack)
- `ACC-P4-13` (Phase 4 release-প্রস্তুত, runbook, demo)
- OD: `OD-17` (কে সই করবে)

**Relation: আগের task**
- `P3-15` দিয়েছে: সই করা নমুনা report pack, যা U08, U10 (report ও export-এর মিল) এর তুলনামূলক ভিত্তি। Pack-এ `P3-15` "অবরুদ্ধ করে: Phase 4 শুরু, P5-01"।
- `P4-13` দিয়েছে: Phase 4 exit criteria পূরণ, সব flag বন্ধ থাকা release, Intake অংশের runbook ও accountant demo-র মতামত (U11-এর ভিত্তি)।
- প্রতিটা আগের Phase-এর test suite (`P1-13`, `P2-16`, `P3-14`, `P4-12`) এখানে স্বয়ংক্রিয় test নয়, মানুষের হাতে দৃশ্য হিসেবে আবার চলে। UAT-এর AC নম্বর (AC1.x থেকে AC4.x) সেই suite-এর সাথে মেলে।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P5-06` (Release gate): Pack বলে এই task `P5-06`-কে অবরুদ্ধ করে। এই task-এর সই করা নথিই `gate:uat`-এর ভিত্তি; Finance owner (বা OD-17-এর ভূমিকা) সই করে `POST /accounting/release-gates/gate:uat`-এ প্রমাণের লিংক দেয়।
- `P5-07` (Training ও support): UAT-এর পরিস্থিতি ও ফলের ওপর ভিত্তি করে নির্দেশিকা ও Error বার্তা সহায়িকা লেখা হয়; UAT-এ ধরা পড়া সমস্যাও সেখানে যায়।
- `P5-08` পরোক্ষভাবে (`P5-06` হয়ে)।

**Related tables / schema**
এই Pack-এ **নতুন table নেই**। UAT-এর ফল কোনো DB table-এ নয়, QA tool-এ রাখা হয়। UAT-এর সময় যে table পড়া/লেখা হয় সেগুলো আগের Phase-এর (পুরো Accounting schema)।

**পরিবেশ:** Staging, production-এর মতো কাঠামো। আসল বা মুখোশ-পরানো (masked) data।

**Business rules**
- গুরুতর defect থাকলে সংশোধনের পর **সংশ্লিষ্ট সব পরিস্থিতি আবার চালানো**, আংশিক সই নয়।
- প্রতিটা পরিস্থিতির ধাপ-ধাপ script QA লেখে; accountant ও QA একসাথে চালায়।
- সই করবেন OD-17-এ নির্ধারিত ব্যক্তি।

**UAT পরিস্থিতি (U01 থেকে U14):**

| # | পরিস্থিতি | কভার করে |
| --- | --- | --- |
| U01 | নতুন company চালু: settings, CoA, checklist | AC1.1 থেকে AC1.6 |
| U02 | Opening balance না মিললে আটকায়, মিললে Post | AC1.3, AC2.12 |
| U03 | সাধারণ journal: Draft থেকে Post | AC2.1 থেকে AC2.4 |
| U04 | Amount অনুযায়ী ভিন্ন approval ধাপ, parallel ও sequential | AC2.2 |
| U05 | Reject ও সংশোধন করে আবার পাঠানো | AC2.10 |
| U06 | Delegation ও emergency override ও পর্যালোচনা | AC2.3 |
| U07 | Reversal ও Adjustment | AC2.8 |
| U08 | সব report-এর মিল (TB, GL, P&L, BS, Cash Flow) | AC3.1 থেকে AC3.4 |
| U09 | Period বন্ধ, বন্ধ period-এ Post, আবার খোলা | AC3.7, AC3.8 |
| U10 | Export Excel ও PDF-এর সংখ্যা মেলে | AC3.9 |
| U11 | Asset write-off থেকে Draft: স্বাভাবিক, mapping নেই, duplicate, conflict | AC4.1, AC4.2 |
| U12 | Reconciliation dashboard-এ সব সবুজ, ইচ্ছা করে একটা ভাঙলে লাল | AC3.10, AC4.12 |
| U13 | অনুমতিহীন চেষ্টা: অন্য company, অন্য role | AC1.1, AC2.3 |
| U14 | Flag বন্ধ করলে সব থামে, data অক্ষত | AC1.10, AC4.5 |

**DB flow**
UAT নিজে কোনো নতুন DB flow বানায় না। প্রতিটা পরিস্থিতি আগের Phase-এর flow চালায় (Pack Section ৯: Post ৯.২, journal যাত্রা ৯.৩, Event থেকে Draft ৯.৪, Period বন্ধ ৯.৫, Reversal ৯.৬)। প্রমাণ হিসেবে screenshot, export বা (প্রয়োজনে) read-only query ফল জমা হয়।

**Task scope**
1. প্রতিটা পরিস্থিতির (U01-U14) ধাপ-ধাপ script লেখা (QA)।
2. Staging-এ data প্রস্তুত (আসল বা masked)।
3. Accountant ও QA একসাথে চালানো; প্রতিটার ফল (পাস, ব্যর্থ)।
4. প্রমাণ সংগ্রহ (screenshot বা export)।
5. Defect তালিকা, গুরুতর defect সংশোধন ও সংশ্লিষ্ট সব পরিস্থিতি আবার চালানো।
6. OD-17-এর ব্যক্তির সই।

**Out of scope**
নতুন feature বা নতুন table; স্বয়ংক্রিয় test (এগুলো Phase-ভিত্তিক suite-এ আছে); security ও performance (`P5-05`); cutover মহড়া (`P5-02`)।

**Contract**
প্রযোজ্য নয়। (সই করা নথি পরে `P5-06`-এর `POST /accounting/release-gates/{gate}`-এ লিংক হিসেবে যায়।)

**Permission**
প্রযোজ্য নয় (UAT ব্যবহারকারীরা নিজ নিজ role-এ চালায়; U13 permission matrix ইচ্ছা করে ভেঙে দেখে)।

**Audit**
UAT-এর ফল audit event নয়। তবে UAT চালানো কাজগুলো (post, approve ইত্যাদি) স্বাভাবিক audit event লেখে।

**Acceptance**
AC5.1, AC5.3

**Test**
- U01-U14 প্রতিটা চালানো ও ফল রেকর্ড।
- গুরুতর defect সংশোধনের পর সংশ্লিষ্ট পরিস্থিতিগুলো আবার চালানো (আংশিক সই নয়)।

**Deliverable**
UAT script (১৪টা), ফল ও প্রমাণ, defect তালিকা, সই করা নথি (OD-17-এর ব্যক্তি)।

**Sub-tasks**
script ×14, চালানো, defect সংশোধন ও আবার চালানো, সই

**Definition of done**
- ১৪টা পরিস্থিতির সবকটা `পাস`, প্রমাণসহ।
- কোনো গুরুতর defect খোলা নেই।
- OD-17-এ নির্ধারিত ব্যক্তির সই করা নথি আছে।
- সই করা নথির লিংক `P5-06`-এর `gate:uat`-এ দেওয়ার জন্য প্রস্তুত।

**Architecture constraints**
- UAT-এর ফল DB table-এ নয়, QA tool-এ।
- Production data/environment-এ UAT নয়।

**Open points (Pack-এ অস্পষ্ট)**
- "গুরুতর defect"-এর সংজ্ঞা (severity scale) Pack-এ নেই।
- OD-17 (কে সই করবে) বন্ধ হওয়ার আগে এই card `Blocked`; কে সই করবে Pack-এ নেই। `P5-06`-এর gate-ও "Finance owner বা OD-17-এর ভূমিকা" বলে।
- AC5.1 ও AC5.3 দুটোই `P5-01` ও `P5-06` উভয়ের Acceptance-এ আছে; Blueprint-এ এদের সংজ্ঞা না দেখে ভাগ নির্ধারণ করা যায় না।
- UAT-এর staging data-য় "আসল না মুখোশ-পরানো" কোনটা হবে ও মুখোশ কীভাবে হবে Pack-এ নেই।

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

---

## ACC-P5-02 — Cutover মহড়া

Project
ERPFlow
Module
Accounting Module
Type
Operations (`ops`)
Title
Cutover মহড়া
Branch Name
কোনো branch নেই (staging-এ ops কাজ, code বদলায় না)
View Order
67
Description
**Summary**
Production-এ cutover যা হবে, ঠিক সেইভাবে আগে staging-এ মহড়া নিতে হবে—কত সময় লাগে, কোথায় ঠেকে, কোথায় ফাঁক—সব মাপা। Opening balance একবার Post হয়ে গেলে আর বদলানো যায় না; তাই প্রথমবারেই নির্ভুল হওয়া জরুরি।

**Task serial**
`ACC-P5-02 — Cutover মহড়া` · Ops

**Depends on**
- `ACC-P3-15` (সই করা report pack, TB/BS মেলানোর পদ্ধতি)
- `ACC-P2-14` (Opening journal-এর Post)
- `ACC-P3-11` (Period বন্ধ ও আবার খোলা)
- OD: `OD-9` (cutover তারিখ ও কোন কাগজ থেকে মেলানো)

**Relation: আগের task**
- `P2-14` দিয়েছে: Opening journal সাধারণ Submit/approve/post পথে Post হওয়া, **Submit ও Post দুই জায়গাতেই** `journal_date`-এর সাথে `opening_cutover_date` মেলানো (`JRN_DATE_INVALID`), Post-এর পর lock-করা setting `SET_LOCKED`, আর `S10` সবুজ। Pack: `P2-14` "অবরুদ্ধ করে: P2-16, P5-02"।
- `P1-11` (পরোক্ষে `P2-14`-এর মাধ্যমে) দিয়েছে Opening Balance গ্রিড ও Draft: যা এই মহড়ার ধাপ 3।
- `P3-11` দিয়েছে Period বন্ধ/খোলা; Pack: "অবরুদ্ধ করে: P3-12, P5-02"। মহড়ায় period যাচাই হয় (cutover period)।
- `P3-15` দিয়েছে Trial Balance, Balance Sheet ও সই করা হিসাব-মেলানোর পদ্ধতি, যার সাথে পুরোনো system মেলানো হয়।
- `P1-05` দিয়েছে Setup Checklist (ধাপ 1)।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P5-06`: Pack বলে এই task `P5-06`-কে অবরুদ্ধ করে। `gate:cutover` এই মহড়ার রিপোর্ট ও production cutover-এর প্রস্তুতি দিয়ে সই হয়।
- `P5-08` ধাপ 1 ("Production-এ Setup Checklist সম্পূর্ণ, opening balance Post (মহড়ার checklist মেনে)") এই task-এর **Production cutover-এর ধাপ-ধাপ checklist** সরাসরি ব্যবহার করে।
- `P5-04` রিহার্সালে একই staging ব্যবহার করতে পারে (আলাদা কাজ)।

**Related tables / schema**
কোনো নতুন table নেই। পড়া/লেখা (staging-এ): `acc_settings`, `acc_accounts`, `acc_periods`, `acc_journals` (opening), `acc_journal_lines`, `acc_setup_status`, report service।

**Business rules**
- **Production-এ কোনো লেখা নেই।**
- Staging-এর data মুছে আবার শুরু করে **অন্তত দুইবার** চালানো (দ্বিতীয়বার দ্রুত ও নির্ভুল হওয়া উচিত)।
- Opening Balance ভুল হলে Post-এর পরে আর বদলানো যায় না (শুধু Adjustment), তাই মহড়াই একমাত্র সুযোগ।
- Cutover তারিখ ও কোন কাগজ থেকে মেলানো হবে তা OD-9-এর সিদ্ধান্ত।

**মহড়ার ধাপ ও মাপ:**

| ধাপ | কী | মাপ |
| --- | --- | --- |
| 1 | Staging-এ একটা company-র Setup Checklist সম্পূর্ণ করা | কত সময় লাগল, কী ঠেকল |
| 2 | আসল (বা আসলের মতো) CoA বানানো |  |
| 3 | Opening balance হাতে ঢোকানো (Opening Balance গ্রিড) | account কত, কত সময় |
| 4 | Submit, approve, post |  |
| 5 | Trial Balance বের করে পুরোনো system-এর সাথে account ধরে মেলানো | কতগুলো অমিল |
| 6 | অমিল থাকলে কারণ বের করে ঠিক করা (opening-এ ভুল, CoA ম্যাপিং ভুল ইত্যাদি) |  |
| 7 | Balance Sheet মেলানো (Asset = Liability + Equity) |  |

**DB flow**
নতুন নেই; ধাপগুলো আগের Phase-এর flow: Setup Checklist (`P1-05`), CoA (`P1-06`/`P1-07`), Opening Draft (`P1-11`), Submit/approve (`P2-08`), Post (`P2-12`, `P2-14`, Section ৯.২), TB/BS (`P3-04`, `P3-06`)।

**Task scope**
1. ধাপ 1 থেকে 7 স্টেজিংয়ে প্রথম মহড়া, প্রতিটার সময় ও ঠেকার তালিকা।
2. Staging data মুছে দ্বিতীয় মহড়া (দ্রুত, নির্ভুল)।
3. অমিলের কারণ ও সমাধানের রেকর্ড।
4. **Production cutover-এর ধাপ-ধাপ checklist** (মহড়ার শিক্ষা থেকে)।
5. মহড়ার রিপোর্ট।

**Out of scope**
Production-এ কোনো লেখা; নতুন feature; `P5-08`-এর আসল production cutover।

**Contract / Permission / Error**
প্রযোজ্য নয় (নতুন API বা error নেই)। মহড়ায় আগের Phase-এর permission ও error কোড (যেমন `JRN_DATE_INVALID`, `SET_LOCKED`, `SET_INCOMPLETE`) স্বাভাবিকভাবে আসতে পারে এবং রেকর্ড করতে হবে।

**Audit**
আগের Phase-এর স্বাভাবিক audit event।

**Acceptance**
AC5.2

**Test**
- দুইবার সম্পূর্ণ মহড়া; দ্বিতীয়বারে অমিল শূন্য বা সব ব্যাখ্যাত।
- চূড়ান্ত তুলনা: TB পুরোনো system-এর সাথে account ধরে মেলে; Balance Sheet সমীকরণ (Asset = Liability + Equity) মেলে।

**Deliverable**
মহড়ার রিপোর্ট (ধাপ ধরে সময়, অমিল ও তার কারণ, চূড়ান্ত তুলনা), Production cutover-এর ধাপ-ধাপ checklist।

**Sub-tasks**
ধাপ ১ থেকে ৭, দ্বিতীয় মহড়া, রিপোর্ট, production checklist

**Definition of done**
- অন্তত দুইবার মহড়া সম্পন্ন, দ্বিতীয়বার দ্রুত ও নির্ভুল।
- সব অমিলের কারণ জানা ও সমাধান রেকর্ড করা।
- মহড়ার রিপোর্ট ও production cutover checklist জমা, Finance owner দেখেছেন।
- Production-এ কোনো লেখা হয়নি (প্রমাণ)।

**Architecture constraints**
- Production-এ লেখা নিষিদ্ধ।
- Opening Post-এর পর ভুল ঠিক করার পথ Adjustment মাত্র; মহড়া এই ঝুঁকি আগেই ধরার জন্য।

**Open points (Pack-এ অস্পষ্ট)**
- OD-9 বন্ধ হওয়ার আগে এই card `Blocked`; cutover তারিখ ও মেলানোর কাগজ (কোন পুরোনো system-এর রিপোর্ট) Pack-এ নেই।
- "কত account", "কত সময়" কোনো লক্ষ্যমাত্রা Pack-এ দেওয়া নেই; মাপ শুধু রেকর্ড করার জন্য।
- OD-23 (Opening-এ Revenue/Expense থাকতে পারবে কি) `P3-15`-এ বন্ধ হয়ে থাকার কথা; বছরের মাঝে cutover হলে চালু-মাসের P&L ফোলার ঝুঁকি মহড়ায় লক্ষ্য রাখতে হবে।

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

---

## ACC-P5-03 — Monitoring ও alert

Project
ERPFlow
Module
Accounting Module
Type
Feature (schema + job) + Ops
Title
Monitoring ও alert — health check, alert state ও বিজ্ঞপ্তি
Branch Name
`feature/accounting-monitoring-alerts`
View Order
68
Description
**Summary**
কিছু ভাঙলে মানুষ জানার আগেই system যেন জানায়—Head of Finance আর tech on-call পাবে। কিন্তু একই alert বারবার ঝড় তুলবে না; সমস্যা দ্রুত ধরা পড়বে, বিজ্ঞপ্তি বিরক্তিকর হবে না।

**Task serial**
`ACC-P5-03 — Monitoring ও alert` · Feature + Ops

**Depends on**
- `ACC-P3-13` (Reconciliation framework, `acc_reconciliation_runs`, `ReconciliationFailed` event)
- `ACC-P4-03` (Consumer job, `acc_intake_heartbeats`)
- `ACC-P4-10` (RC8)
- `ACC-P2-15` (Queue ও Register, আটকে থাকা approval)

**Relation: আগের task**
- `P3-13` দিয়েছে: RC1-RC9 ফল (`acc_reconciliation_runs`) এবং নিয়ম "কোনো check ব্যর্থ হলে `ReconciliationFailed` event, যা P5-03 alert-এ বাঁধা"। `recon_failed` alert এর ভিত্তি।
- `P4-03` দিয়েছে `acc_intake_heartbeats` (`last_started_at`, `last_finished_at`, `last_error`, গণনা) -> `consumer_lag`।
- `P4-10` দিয়েছে RC8 (event থেকে ledger পর্যন্ত মিল), যা `recon_failed`-এর অংশ।
- `P2-15` দিয়েছে আটকে থাকা approval-এর তালিকা (`monitor_approval_stuck_days`) ও অপর্যালোচিত override-এর তালিকা -> `approval_stuck`, `override_unreviewed`।
- অন্যান্য উৎস যা এই task পড়ে (আগের Phase-এর table/event): inbox (`P4-02`, `P4-07`-এর `ack_attempts`), `acc_approval_requests`/`acc_approval_actions` (`P2-05`), `acc_report_exports` (`P3-10`), `activity_logs` (`P1-12`, post ব্যর্থতা `P2-12`, `accounting.period.locked_post_attempt` `P3-12`)।
- `P1-03` registry-র `monitor_*` setting।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P5-08`: Pack বলে এই task `P5-08`-কে অবরুদ্ধ করে। পিলট চালুর পর্যবেক্ষণ-সময়ে "রোজ RC1 থেকে RC9-এর সারাংশ দেখা, alert-এর সাড়া" এই task-এর `GET /accounting/health` ও বিজ্ঞপ্তির ওপর দাঁড়ায়।
- `P5-04` (Rollback): alert পেলে প্রথম পদক্ষেপ flag বন্ধ; runbook alert-কে rollback স্তর ১-এর ট্রিগার হিসেবে ধরে।
- `P5-07`: Support playbook-এ "কোন alert-এ কী করবে"।

**Related tables / schema**

**`acc_alert_state`**

| Column | ধরন | Null | নোট |
| --- | --- | --- | --- |
| `id` | PK | না |  |
| `company_id` | FK | না |  |
| `alert_key` | VARCHAR(60) | না | নিচের তালিকার কোড |
| `state` | VARCHAR(8) | না | `ok`, `firing` |
| `first_fired_at`, `last_fired_at`, `last_notified_at` | TIMESTAMP | হ্যাঁ |  |
| `detail` | JSON | হ্যাঁ |  |

Unique: `uq_acc_alert (company_id, alert_key)`।

**Settings (`P1-03` registry, সবই Phase 5, default):** `monitor_held_event_age_hours` = 24, `monitor_held_event_count` = 10, `monitor_approval_stuck_days` = 3, `monitor_consumer_lag_minutes` = 30, `monitor_closed_period_post_attempts` = 5।

**Alert তালিকা:**

| Alert | কখন | সীমা (setting) | উৎস |
| --- | --- | --- | --- |
| `recon_failed` | RC1 থেকে RC9-এর কোনোটা `fail` | যেকোনো একটা, সঙ্গে সঙ্গে | `acc_reconciliation_runs` |
| `consumer_lag` | Consumer শেষ চলার সময় পুরোনো | `monitor_consumer_lag_minutes` | `acc_intake_heartbeats` |
| `held_events` | আটকে থাকা event-এর সংখ্যা বা বয়স | `monitor_held_event_count`, `monitor_held_event_age_hours` | `acc_finance_event_inbox` |
| `failed_events` | যেকোনো `failed` বা `conflict` | যেকোনো একটা | inbox |
| `ack_failing` | Asset-এ ফেরত জানানো `ack_attempts` শেষেও ব্যর্থ | যেকোনো একটা | inbox |
| `approval_stuck` | `pending` approval দীর্ঘ সময় | `monitor_approval_stuck_days` | `acc_approval_requests` |
| `post_failures` | Post ব্যর্থ হওয়ার audit event | যেকোনো একটা (পরপর তিনটা হলে গুরুতর) | `activity_logs` |
| `locked_post_attempts` | বন্ধ period-এ Post-এর চেষ্টা | `monitor_closed_period_post_attempts` (দিনে) | `activity_logs` |
| `override_unreviewed` | Override হয়েছে কিন্তু পর্যালোচনা নেই | ২৪ ঘণ্টার বেশি | `acc_approval_actions` |
| `export_failures` | Export `failed` | যেকোনো একটা | `acc_report_exports` |

**Business rules**
- Alert state-machine: `ok` <-> `firing`। শর্ত সত্য আর আগে `ok` ছিল -> `firing`, `first_fired_at` বসে, বিজ্ঞপ্তি পাঠানো, `last_notified_at`। আগে থেকেই `firing` -> আবার বিজ্ঞপ্তি শুধু **নির্ধারিত বিরতির পর** (প্রস্তাব ৬ ঘণ্টা)। শর্ত মিথ্যা হলে `ok` (আর একটা সমাধানের বিজ্ঞপ্তি)।
- **ঝড় নেই:** একই শর্তে নির্ধারিত বিরতির আগে দ্বিতীয় বিজ্ঞপ্তি নয়।
- কে পাবে: Head of Finance আর tech on-call।
- বিজ্ঞপ্তির মাধ্যম: ERPFlow-এর বিদ্যমান notification বা ইমেইল ব্যবস্থা (`P0-02`-এর Convention Sheet-এ যা পাওয়া গেছে)। না থাকলে সবচেয়ে সরল: নির্ধারিত ইমেইল তালিকা।
- Check শুধু পড়ে (কোনো business data বদলায় না); শুধু `acc_alert_state` লেখে।

**DB flow**
1. `accounting:health-check` command প্রতি পাঁচ মিনিটে (scheduler)।
2. প্রতিটা **চালু company**-র জন্য company context-এ একটা job (`AccountingJob`)।
3. প্রতিটা alert-এর জন্য শর্ত দেখা (উৎস table পড়া)।
4. `acc_alert_state` upsert (`uq_acc_alert (company_id, alert_key)`):
   - শর্ত সত্য + আগে `ok` -> `firing`, `first_fired_at`, `last_fired_at`, `detail`, বিজ্ঞপ্তি, `last_notified_at`।
   - আগে থেকেই `firing` -> `last_fired_at` হালনাগাদ; বিজ্ঞপ্তি শুধু বিরতির পর।
   - শর্ত মিথ্যা -> `ok` আর একটা সমাধানের বিজ্ঞপ্তি।
5. `GET /accounting/health` সব alert-এর বর্তমান অবস্থা পড়ে।

**Task scope**
1. Migration `acc_alert_state`।
2. Command `accounting:health-check` ও scheduler (৫ মিনিট)।
3. প্রতিটা alert-এর আলাদা checker (দশটা)।
4. State-machine ও ঝড়-নিয়ন্ত্রণ।
5. বিজ্ঞপ্তির ব্যবস্থা (ইমেইল/notification)।
6. Health API ও UI।
7. Test।

**Out of scope**
Alert-এর কারণ ঠিক করা (ops screen `P4-09`, runbook); নতুন reconciliation check; SMS/Slack integration (Pack-এ নেই)।

**Contract**
`GET /accounting/health` (সব alert-এর বর্তমান অবস্থা, UI-র জন্য)

**UI**
Health পাতা: দশটা alert-এর অবস্থা (সবুজ/লাল), কখন প্রথম/সর্বশেষ জ্বলেছে, `detail`, সংশ্লিষ্ট পাতার লিংক (যেমন `held_events` -> ops screen)।

**Permission**
Pack-এ নির্দিষ্ট নেই (open point নিচে)।

**Error**
প্রযোজ্য নয় (background); `ACC_FORBIDDEN`/`ACC_MODULE_DISABLED` health API-তে স্বাভাবিক।

**Audit**
Pack-এ নির্দিষ্ট নেই; alert অবস্থার বদল `acc_alert_state`-এই রেকর্ড (open point নিচে)।

**Acceptance**
AC5.4

**Test**
- প্রতিটা alert ইচ্ছা করে ঘটিয়ে `firing` ও বিজ্ঞপ্তি।
- ঝড় নেই: একই শর্তে নির্ধারিত বিরতির আগে আবার বিজ্ঞপ্তি নয়।
- শর্ত মিটলে `ok` আর সমাধানের বিজ্ঞপ্তি।
- Company context: এক company-র alert অন্য company-কে প্রভাবিত করে না।
- Flag/`accounting.enabled` বন্ধ company-তে job চলে না।

**Deliverable**
Migration, command, job, health API ও UI, বিজ্ঞপ্তির ব্যবস্থা।

**Sub-tasks**
migration, প্রতিটা alert-এর checker, state-machine ও ঝড়-নিয়ন্ত্রণ, বিজ্ঞপ্তি, API ও UI, test

**Definition of done**
- সাধারণ DoD পূরণ।
- AC5.4 সবুজ।
- সব দশটা alert staging-এ ঘটিয়ে প্রমাণিত।
- Head of Finance ও tech on-call বিজ্ঞপ্তি পেয়েছেন (staging প্রমাণ)।

**Architecture constraints**
- Checker শুধু পড়ে; business table বদলায় না।
- `AccountingJob` base (company context) ব্যবহার।
- Threshold সব `monitor_*` setting থেকে, কোডে বাঁধা নয় (যেখানে setting আছে)।

**Open points (Pack-এ অস্পষ্ট)**
- বিজ্ঞপ্তির পুনরাবৃত্তির বিরতি ("প্রস্তাব ৬ ঘণ্টা") কোনো setting-এর key নয়; কনফিগারযোগ্য হবে কি কোডের ধ্রুবক, নির্ধারিত নেই।
- `override_unreviewed`-এর সীমা "২৪ ঘণ্টা" ও `post_failures`-এর "পরপর তিনটা গুরুতর" setting-এ নেই। `acc_alert_state`-এ severity column নেই; গুরুতরতা `detail`-এ যাবে কি না ঠিক করতে হবে।
- "Post ব্যর্থ হওয়ার audit event"-এর সুনির্দিষ্ট event নাম Pack-এর audit registry-তে নেই (`P2-12` বলে "ব্যর্থ চেষ্টাও" audit হয়)। নাম নির্ধারণ করে checker বাঁধতে হবে।
- `ack_failing`-এর "ack_attempts শেষ" সীমা `P4-07`-এর open point।
- `GET /accounting/health`-এর permission slug নির্দিষ্ট নেই (প্রস্তাব: বিদ্যমান slug থেকে, নতুন slug না বানিয়ে)।
- বিজ্ঞপ্তির মাধ্যম `P0-02`-এর উত্তরের ওপর নির্ভর করে; Pack এখানে ফলাফল জানায় না।
- `export_failures` ভিত্তি `acc_report_exports.status = 'failed'`; কতক্ষণ আগের পর্যন্ত গোনা হবে (সময়-জানালা) বলা নেই। একই প্রশ্ন `failed_events`/`recon_failed`-এর ক্ষেত্রে ("সমাধান হয়েছে" কখন ধরা হবে)।

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

---

## ACC-P5-04 — Rollback ও জরুরি বন্ধ পরিকল্পনা

Project
ERPFlow
Module
Accounting Module
Type
Operations (`ops`)
Title
Rollback ও জরুরি বন্ধ পরিকল্পনা
Branch Name
`feature/accounting-phase5-rollback-plan` (শুধু নথি/runbook; code বদলায় না)
View Order
69
Description
**Summary**
কিছু ভুল হলে কী করতে হবে—আগে থেকেই লেখা থাকবে, staging-এ মহড়াও দেওয়া থাকবে। জরুরি সময়ে আন্দাজে নয়, নির্ধারিত ধাপে ফিরতে হবে; data হারানো যাবে না। Release manager-এর কাজ এটাই।

**Task serial**
`ACC-P5-04 — Rollback ও জরুরি বন্ধ পরিকল্পনা` · Ops

**Depends on**
- `ACC-P4-13` (Phase 4 release-প্রস্তুতি ও runbook)

**Relation: আগের task**
- `P4-13` দিয়েছে: সব flag বন্ধ থাকা release, runbook-এর Intake অংশ (নিরাপদে বন্ধ করা) ও সই করা merge checklist। এই task সেই runbook-এর ওপর পূর্ণ rollback পরিকল্পনা বসায়।
- `P1-14` runbook-এর প্রথম খসড়ায় "trigger-এর সতর্কতা, `down()` চালানো নিষেধ" রেখেছিল; `P1-10` সেই trigger বানিয়েছে ও `down()` সতর্কতা লিখেছে।
- `P1-01`/`P4-11` দিয়েছে flag ও বন্ধ করার (অনুমোদন ছাড়া, কারণসহ) পথ; এটাই স্তর ১।
- প্রতিটা আগের Phase-এর migration (expand-only, পিছনে সামঞ্জস্যপূর্ণ নিয়ম `P0-03`) এই task-এর "migration সামঞ্জস্য তালিকা"-র উপাদান।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P5-08`: Pack বলে এই task `P5-08`-কে অবরুদ্ধ করে। পিলট চালুর আগে rollback মহড়া সম্পন্ন থাকতে হবে।
- `P5-07` (Support playbook): "কখন flag বন্ধ করবে" স্তর ১ থেকে আসে।
- `P5-03`: alert পেলে প্রথম পদক্ষেপ স্তর ১।

**Related tables / schema**
কোনো নতুন table নেই। তালিকাভুক্ত করার জন্য প্রতিটা Accounting migration (Pack-এর table index + expand migration + trigger)।

**Business rules**
**তিন স্তরের rollback:**

| স্তর | কখন | কী করে | কী হারায় না |
| --- | --- | --- | --- |
| ১. Flag বন্ধ | যেকোনো সমস্যায়, প্রথম পদক্ষেপ | `event_intake` বা `accounting.enabled` বন্ধ (কারণ লিখে)। সঙ্গে সঙ্গে নতুন কাজ থামে | সব Draft, submitted, posted, event, audit |
| ২. Code আগের version-এ | Code-এ ভুল পাওয়া গেলে | CI/CD-র সুযোগ অনুযায়ী আগের SHA-তে ফেরা। **Migration rollback হয় না**, তাই প্রতিটা migration আগের code-এর সাথেও সামঞ্জস্যপূর্ণ (আগে যোগ, পরে বদল, শেষে মোছা) | DB-র সব data (migration ফেরানো হয় না) |
| ৩. Module বন্ধ | চরম ক্ষেত্রে, `modules_statuses.json`-এ `Accounting` বন্ধ | Route ও UI বন্ধ। Table, trigger, data থেকে যায় | সব |

**যা কখনো করা যাবে না (production):** (১) Trigger বা unique constraint-এর migration-এর `down()` চালানো। (২) Accounting-এর কোনো table-এর row সরাসরি SQL-এ বদলানো বা মোছা। (৩) Posted journal ঠিক করতে trigger বন্ধ করা। **ভুল ঠিক করার একমাত্র পথ Reversal ও Adjustment।**

**DB flow**
নতুন নেই। মহড়ায় migration-এর আচরণ যাচাই (নিচে)।

**Task scope**
1. স্তর ১ থেকে ৩ লেখা: কে সিদ্ধান্ত নেয়, কোন ধাপ, কত সময়, যোগাযোগ।
2. "করা যাবে না" তালিকা (ওপরের তিনটা)।
3. **Migration সামঞ্জস্য তালিকা:** প্রতিটা Accounting migration-এর জন্য একটা সারি: কী যোগ করে, পুরোনো code-এর সাথে চলে কি না, `down()` নিরাপদ কি না। Pack-এর সব table (`P1-03` থেকে `P5-06`, নিচের open point-এ সংখ্যা) আর expand migration (যেমন `acc_journals.posted_hash` `P1-10`, generated column `source_active` `P1-09`, `reversal_active` `P2-13`, `acc_periods.balance_version` `P3-02`, index migration `P2-15`, inbox-এর `acknowledged_at/ack_attempts/ack_error` `P4-07`, Asset-এর `effective_date/schema_version` যদি OD-21 (ক)) ও trigger (`P1-10`, `P3-11`-এর `acc_period_events`) সব এতে।
4. **মহড়া (staging):** (১) N-1 code deploy, (২) N-এর migration চালানো, (৩) আবার N-1 code-এ ফেরা, কিছু ভাঙেনি দেখা, (৪) Flag বন্ধ করে চালু করা, data অক্ষত।
5. মহড়ার রেকর্ড।

**Out of scope**
Disaster recovery / backup-restore (Pack-এ নেই); production-এ rollback চালানো; code পরিবর্তন।

**Contract / Permission / Error**
প্রযোজ্য নয়। (Flag বন্ধ করার API ও permission `P4-11`/`P5-06`-এর: `accounting.enable.manage`।)

**Audit**
মহড়ায় flag বন্ধ/চালু `accounting.flag.disabled`, `accounting.flag.enabled` audit লেখে (বিদ্যমান)।

**Acceptance**
AC5.5, AC5.6

**Test**
- N-1 code + N migration: কিছু ভাঙে না (পুরোনো code নতুন schema-র সাথে চলে)।
- Flag বন্ধ -> চালু: data (Draft, submitted, posted, event, audit) অক্ষত।
- Module বন্ধ (`modules_statuses.json`) staging-এ: route/UI বন্ধ, table ও data থেকে যায়।

**Deliverable**
Rollback পরিকল্পনা, migration সামঞ্জস্য তালিকা, মহড়ার রেকর্ড।

**Sub-tasks**
স্তর ১ থেকে ৩ লেখা, "করা যাবে না" তালিকা, migration তালিকা, মহড়া

**Definition of done**
- তিন স্তর ও "করা যাবে না" তালিকা লিখিত, tech lead ও Release manager দেখেছেন।
- Migration সামঞ্জস্য তালিকায় প্রতিটা Accounting migration আছে।
- Staging মহড়া সম্পন্ন, রেকর্ড জমা।
- `P1-14` runbook-এ এই পরিকল্পনার লিংক যোগ।

**Architecture constraints**
- Migration কখনো rollback হয় না; তাই প্রতিটা migration পিছনে সামঞ্জস্যপূর্ণ।
- Production-এ ভুল ঠিক করার একমাত্র পথ Reversal ও Adjustment।

**Open points (Pack-এ অস্পষ্ট)**
- **Table সংখ্যার অসঙ্গতি:** Pack-এ P5-04 বলে "এই Pack-এর ৩০টা table"; Section ১০.৩ বলে মোট ৩১টা (index-এর ২৮ + তিনটা নতুন: `acc_approval_override_reviews`, `acc_intake_heartbeats`, `acc_alert_state`) এবং বলে "৩০টা মানে এই প্রায় সংখ্যা"। কিন্তু Section ২.১-এর index-এ বাস্তবে ২৬টা `acc_` table আছে, তিনটা যোগ করলে ২৯। তালিকা বানানোর সময় বাস্তব migration গণনাই সত্যের উৎস; সংখ্যার মিল আলাদা করে মেলাতে হবে।
- "CI/CD-র সুযোগ অনুযায়ী আগের SHA-তে ফেরা" কীভাবে হবে (`P0-03`-এর ফল) Pack-এ বিস্তারিত নেই।
- Release manager কে ও সিদ্ধান্তের কর্তৃপক্ষ কে (স্তর ২/৩ ডাকার) Pack-এ নেই।
- স্তর ৩ ("Module বন্ধ") production-এ কে কীভাবে `modules_statuses.json` বদলাবে (deploy লাগে কি না) বলা নেই।

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

---

## ACC-P5-05 — শেষ security ও performance যাচাই

Project
ERPFlow
Module
Accounting Module
Type
Test
Title
শেষ security ও performance যাচাই
Branch Name
`feature/accounting-phase5-security-perf`
View Order
70
Description
**Summary**
চালুর আগে শেষবার সব endpoint-এর দরজা যাচাই: company isolation, permission, input, upload, export, audit tamper, rate limit—আর গতিও। কোনো গুরুতর ফাঁক নিয়ে production-এ যাওয়া যাবে না; security-minded tech lead এটা চালাবে।

**Task serial**
`ACC-P5-05 — শেষ security ও performance যাচাই` · Test

**Depends on**
- `ACC-P4-12` (Phase 4-এর সম্পূর্ণ test suite, সব route নিবন্ধিত)
- `ACC-P3-14` (Performance seeder, প্রস্তাবিত সীমা ও Phase 3 suite)

**Relation: আগের task**
- `P4-12` দিয়েছে: সব Phase-এর API এখন পূর্ণ (intake, mapping, ops, flags সহ), তাই route-ঘোরা test সব endpoint ধরতে পারে। এবং company isolation (AC4.6), permission matrix ইত্যাদির Phase-ভিত্তিক test।
- `P3-14` দিয়েছে: performance seeder command (৫ বছর, ৫০০ account, ১০ লক্ষ journal line, ৬০টা period), প্রস্তাবিত সীমা (TB/BS/Cash Flow কয়েক সেকেন্ড, GL ১ লক্ষ row account এক পৃষ্ঠা ~১ সেকেন্ড, export ১ লক্ষ row queue-তে কয়েক মিনিট) ও `EXPLAIN` অভ্যাস। এখানে "P3-14-এর সীমা আবার" বলতে সেই সীমা।
- `P1-10`/`P3-13`/`P3-11` দিয়েছে audit ও history table-এর DB trigger (tamper test-এর বিষয়)। `P1-09` দিয়েছে attachment table ও file নিয়ম, `P3-10` export ও মেয়াদী লিংক।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P5-06`: Pack বলে এই task `P5-06`-কে অবরুদ্ধ করে। `gate:security` এই task-এর রিপোর্ট ও ফাঁক সংশোধনের প্রমাণে সই হয়।
- `P5-08` পরোক্ষে (`P5-06` হয়ে)।

**Related tables / schema**
নতুন table নেই। সব `accounting` route ও পুরো schema পরীক্ষা হয়। ফাঁক সংশোধন code-এ হলে সংশ্লিষ্ট card-এর migration/code-এ ছোট fix।

**Business rules**
- নতুন route যোগ হলে isolation test নিজে থেকে তাকে ধরে (route তালিকা থেকে স্বয়ংক্রিয়)।
- গুরুতর ফাঁক থাকলে সংশোধনের পর সংশ্লিষ্ট যাচাই আবার।
- Performance: staging-এ বাস্তব আকারের data, কখনো production নয়।

**যাচাই তালিকা:**

| যাচাই | কীভাবে |
| --- | --- |
| Company isolation, সব endpoint | Route তালিকা থেকে স্বয়ংক্রিয়ভাবে: প্রতিটা `accounting` route অন্য company-র id দিয়ে ডেকে `ACC_COMPANY_FORBIDDEN` বা 404 আসছে কি না (নতুন route যোগ হলে test নিজে থেকে তাকে ধরে) |
| Permission, সব role × সব endpoint | Matrix, প্রত্যাশিত তালিকার সাথে মেলানো |
| Mass assignment ও input | প্রতিটা write endpoint: অনুমোদিত নয় এমন field (`company_id`, `status`, `posted_by`) পাঠিয়ে উপেক্ষা হচ্ছে কি না |
| SQL injection | Filter ও search parameter-এ |
| File upload | Attachment: ধরন, আকার, নাম, path traversal, (থাকলে) virus scan |
| Export download | অন্য company বা অন্য user-এর export ডাউনলোড, মেয়াদী লিংকের মেয়াদ |
| Audit tamper | Audit ও history table-এ সরাসরি `UPDATE` ও `DELETE` (trigger আটকায় কি না) |
| Rate limit | Report ও export endpoint-এ অতিরিক্ত অনুরোধ |
| Performance | Staging-এ বাস্তব আকারের data (P3-14-এর সীমা) আবার, slow query log দেখা, index পর্যালোচনা |

**DB flow**
নতুন নেই। Performance অংশে `EXPLAIN`, slow query log ও index পর্যালোচনা। Tamper test সরাসরি SQL (শুধু staging)।

**Task scope**
1. Route-ঘোরা isolation test (স্বয়ংক্রিয়, নতুন route-ও ধরে)।
2. Permission matrix (সব role × সব endpoint)।
3. Mass assignment ও input যাচাই, SQL injection।
4. Attachment upload যাচাই।
5. Export download যাচাই (isolation, মেয়াদ)।
6. Audit/history tamper।
7. Rate limit।
8. Performance আবার (P3-14-এর সীমা), slow query log, index পর্যালোচনা।
9. ফাঁক সংশোধন (আলাদা fix commit সংশ্লিষ্ট branch-এ) ও আবার যাচাই।
10. রিপোর্ট।

**Out of scope**
নতুন feature; external penetration test (Pack-এ নেই); load/stress test production-এ।

**Contract / Permission**
প্রযোজ্য নয়। (Test সব বিদ্যমান permission মেলায়।)

**Error**
প্রত্যাশিত: `ACC_COMPANY_FORBIDDEN`, `ACC_FORBIDDEN`, `ACC_APPEND_ONLY`/`JRN_IMMUTABLE` (tamper), `JRN_*` validation; rate limit-এ 429 (বিদ্যমান ERPFlow throttling অনুযায়ী)।

**Audit**
ফাঁক খোঁজার চেষ্টায় `accounting.guard.denied` লেখা হচ্ছে কি না তা-ও দেখা।

**Acceptance**
কোনো গুরুতর ফাঁক নেই, performance সীমার মধ্যে। (Pack-এ AC নম্বর নেই।)

**Test**
উপরের নয়টা যাচাই-ই test। Isolation ও permission স্বয়ংক্রিয় (CI-তে চালানো যায়); performance আলাদা (CI-তে নয়, staging-এ)।

**Deliverable**
Security ও performance রিপোর্ট, ফাঁক সংশোধন।

**Sub-tasks**
route-ঘোরা isolation test, permission matrix, input যাচাই, upload, export, tamper, rate limit, performance

**Definition of done**
- সাধারণ DoD পূরণ (fix থাকলে)।
- সব যাচাই পাস; গুরুতর ফাঁক শূন্য।
- Performance প্রস্তাবিত সীমার মধ্যে বা সীমা ছাড়ালে tech lead-এর লিখিত সিদ্ধান্ত।
- রিপোর্ট `P5-06`-এর `gate:security`-এ প্রমাণ হিসেবে লিংক করার জন্য প্রস্তুত।

**Architecture constraints**
- Isolation test route তালিকা থেকে স্বয়ংক্রিয়, হাতে লেখা তালিকা নয়।
- Performance শুধু staging-এ, production-এ নয়।
- ফাঁক সংশোধনে নতুন architecture নয়; নিয়ম আগের Phase-এর মতো।

**Open points (Pack-এ অস্পষ্ট)**
- "গুরুতর ফাঁক"-এর মানদণ্ড ও পাস/ফেল সীমা Pack-এ নেই।
- Performance সীমার সংখ্যাগুলো `P3-14`-এ "প্রস্তাব" ছিল, client ও tech lead নিশ্চিত করবে; নিশ্চিত হয়েছে কি না এখানে আবার দেখতে হবে।
- Virus scan "থাকলে", ERPFlow-এ আছে কি না `P0-02`-এর উত্তরের ওপর।
- Rate limit-এর সুনির্দিষ্ট সীমা Pack-এ নেই (বিদ্যমান ERPFlow throttle ধরা হয়েছে)।
- Acceptance-এ কোনো AC5.x নম্বর দেওয়া নেই।

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

---

## ACC-P5-06 — Release gate ও চালুর রেকর্ড

Project
ERPFlow
Module
Accounting Module
Type
Feature (schema + service + api + ui)
Title
Release gate ও চালুর রেকর্ড
Branch Name
`feature/accounting-release-gate`
View Order
71
Description
**Summary**
কোনো company-তে `accounting.enabled` চালু হবে শুধু তখনই, যখন তিন গেট, Setup Checklist আর দুজনের সম্মতি—সব লিখিতভাবে সবুজ। প্রতিটা চালু-বন্ধের পূর্ণ রেকর্ড থাকবে; অপরিকল্পিত বা একজন একাই চালু করা যাবে না।

**Task serial**
`ACC-P5-06 — Release gate ও চালুর রেকর্ড` · Feature

**Depends on**
- `ACC-P5-01` (UAT সই -> `gate:uat`)
- `ACC-P5-02` (Cutover মহড়া -> `gate:cutover`)
- `ACC-P5-05` (Security ও performance -> `gate:security`)
- `ACC-P1-05` (Setup Checklist, `canEnable()`)
- `ACC-P4-11` (তিন স্তরের flag, `flag:` applier, `ChecklistService`)

**Relation: আগের task**
- `P5-01` দিয়েছে সই করা UAT নথি = `gate:uat`-এর প্রমাণ। `P5-02` দিয়েছে মহড়ার রিপোর্ট ও production cutover checklist = `gate:cutover`। `P5-05` দিয়েছে security ও performance রিপোর্ট = `gate:security`।
- `P1-05` দিয়েছে `ChecklistService::evaluate`, `canEnable()` (`S01`-`S10` সবুজ, নইলে `SET_INCOMPLETE`) এবং `POST /accounting/enable` endpoint-এর কথা "পূর্ণ রূপ P5-06-এ" (`P1-05`-এর নিজের contract-এ লেখা)। Pack: `P1-05` "অবরুদ্ধ করে: accounting.enabled চালু করার কাজ (P5-06)"।
- `P4-11` দিয়েছে `AccountingFeatureService`-এর চূড়ান্ত নিয়ম, flag চালু-বন্ধের API `POST /accounting/flags/{flag}`, "প্রথমবারে দুজন, পরে একজন; বন্ধ সঙ্গে সঙ্গে, কারণ বাধ্যতামূলক" নিয়ম ও `ChangeApplier`-এর `flag:` prefix। এই task `flag:accounting.enabled` key-তে একই পথ ব্যবহার করে।
- `P1-04` দিয়েছে change request (Maker–Checker), `P1-10` দিয়েছে `Schema::appendOnly` helper (`acc_enablement_log`-এর জন্য, `P1-10`-এর তালিকায় এটার নাম আছে), `P1-01` দিয়েছে audit event নাম নিবন্ধন (`accounting.flag.enabled/disabled`; "flag বদলানোর card `P5-06` আর `P4-11`-এ লেখা হবে")।
- `P1-02` দিয়েছে permission `accounting.enable.manage`, `accounting.settings.approve`।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P5-08`: Pack বলে এই task `P5-08`-কে অবরুদ্ধ করে। `P5-08` ধাপ 2 ("`accounting.enabled` চালু (দুজন)") "P5-06-এর সব শর্ত" মেনে এই task-এর release পাতা ও API দিয়ে চলে; `acc_enablement_log` চালুর রেকর্ড ও `gate_snapshot` সেখানে জমা হয়।
- `P5-04` ও `P5-03` ও `P5-07` (রেকর্ডে "কে কখন বন্ধ করল" support playbook ব্যবহার করে)।

**Related tables / schema**

**`acc_enablement_log`** (append-only, `Schema::appendOnly`)

| Column | ধরন | Null | নোট |
| --- | --- | --- | --- |
| `id` | PK | না |  |
| `company_id` | FK | না |  |
| `flag` | VARCHAR(60) | না | `accounting.enabled`, `event_intake.enabled`, `event_intake.sources.asset_write_off`, অথবা গেট: `gate:uat`, `gate:cutover`, `gate:security` |
| `action` | VARCHAR(12) | না | `on`, `off`, `gate_passed`, `gate_revoked` |
| `requested_by` | FK users | না |  |
| `approved_by` | FK users | হ্যাঁ |  |
| `reason` | VARCHAR(500) | না |  |
| `gate_snapshot` | JSON | হ্যাঁ | চালুর মুহূর্তের Checklist আর গেটের অবস্থা |
| `created_at` | TIMESTAMP | না |  |

Index: `idx_acc_enl_company_flag_time (company_id, flag, created_at)`।

পড়া/লেখা: `Setting` (flag, `P1-01`), `acc_setup_status` (`P1-05`), `acc_setting_change_requests` (`P1-04`), `activity_logs`।

**Business rules**
- **তিনটা গেট:** `gate:uat` (`P5-01`-এর সই), `gate:cutover` (`P5-02`-এর মহড়া ও production cutover-এর প্রস্তুতি), `gate:security` (`P5-05`)। প্রতিটা সই `POST /accounting/release-gates/{gate}` (Finance owner বা OD-17-এর নির্ধারিত ভূমিকা, `accounting.enable.manage`), কারণ ও প্রমাণের লিংক সহ। **বাতিল (`gate_revoked`) সম্ভব।**
- **`accounting.enabled` চালুর শর্ত:** (১) তিন গেটই `gate_passed` (সর্বশেষ কাজ), (২) Checklist `S01`-`S10` সবুজ (`P1-05`), (৩) দুজন (`P1-04`-এর change request, key `flag:accounting.enabled`, Maker–Checker)। প্রতিটা শর্ত না মিললে `SET_INCOMPLETE` বা `ACC_FORBIDDEN` (কোনটা বাকি তা বলে)।
- **বন্ধ করা:** এক ব্যক্তি, কারণ বাধ্যতামূলক, সঙ্গে সঙ্গে, `off` row।
- R5.1 থেকে R5.5, R5.8, R5.10 (Blueprint)।
- একই সময়ে একটার বেশি company চালু করা নয় (প্রক্রিয়াগত; system আটকায় না, Release manager আটকায়)।
- Maker নিজে অনুমোদন করতে পারে না (`JRN_SOD_VIOLATION`)।

**DB flow**
**চালু (`accounting.enabled`):**
1. transaction।
2. সব শর্ত পড়া: `acc_enablement_log`-এ প্রতিটা গেটের সর্বশেষ row `gate_passed` কি না; `ChecklistService::evaluate`/`canEnable()`; change request অনুমোদিত কি না ও Maker ≠ Checker।
3. `Setting` লেখা (`accounting.enabled = true`)।
4. `acc_enablement_log`-এ row (`flag = 'accounting.enabled'`, `action = 'on'`, `requested_by`, `approved_by`, `reason`, `gate_snapshot`)।
5. Audit (`accounting.enablement.changed`, `accounting.flag.enabled`)।
6. commit।

**গেট সই/বাতিল:** `acc_enablement_log`-এ row (`flag = 'gate:*'`, `action = 'gate_passed'` বা `gate_revoked`, `reason`, প্রমাণের লিংক `reason`/`gate_snapshot`-এ)।

**বন্ধ:** `Setting` লেখা (`false`), `off` row, audit `accounting.flag.disabled`।

**Task scope**
1. Migration `acc_enablement_log` + `Schema::appendOnly`।
2. গেট সই/বাতিল service ও API `POST /accounting/release-gates/{gate}`।
3. চালুর শর্ত যাচাই (তিন গেট + Checklist + দুজন)।
4. Change request সংযোগ: `flag:accounting.enabled` applier (`P1-04`-এর `ChangeApplier` রেজিস্ট্রিতে; `P4-11`-এর `flag:` applier-এর সাথে একই পথ)।
5. বন্ধ করার পথ ও `off` row।
6. Release পাতা (UI)।
7. Test।

**Out of scope**
Intake flag-এর চালুর শর্ত (`P4-11`); production-এ আসলে চালু করা (`P5-08`); UAT/মহড়া/security কাজ নিজে (`P5-01`/`02`/`05`)।

**Contract**
- `POST /accounting/release-gates/{gate}` (গেট সই; বাতিলের জন্য এই route-এর বাতিল রূপ, নিচের open point)
- `POST /accounting/enable` (`P1-05`-এ উল্লিখিত, এখানে পূর্ণ)
- `POST /accounting/flags/{flag}` (`P4-11`-এর, `accounting.enabled`-এর জন্যও ব্যবহৃত হতে পারে)
- Release পাতার জন্য `GET` (গেট ও log)

**UI**
Release পাতা: তিন গেট (অবস্থা, কে কখন সই করেছে, প্রমাণ-লিংক), Setup Checklist (`S01`-`S10`), চালুর বাটন (শর্ত পূরণে সক্রিয়), ইতিহাস (`acc_enablement_log`)।

**Permission**
`accounting.enable.manage` (গেট সই, চালু, বন্ধ), `accounting.settings.approve` (দ্বিতীয় জনের অনুমোদন)

**Error**
`SET_INCOMPLETE`, `ACC_FORBIDDEN`, `JRN_SOD_VIOLATION`

**Audit**
`accounting.enablement.changed`, `accounting.flag.*`

**Acceptance**
AC5.1, AC5.3

**Test**
- কোনো গেট ছাড়া চালু (নিষেধ, `SET_INCOMPLETE`)।
- গেট বাতিলের পর চালু (নিষেধ)।
- নিজে অনুমোদন (নিষেধ, `JRN_SOD_VIOLATION`)।
- Checklist লাল -> চালু নিষেধ।
- বন্ধ করলে data অক্ষত আর `off` row।
- `acc_enablement_log`-এ `UPDATE`/`DELETE` ব্যর্থ (append-only)।
- `gate_snapshot` চালুর মুহূর্তের Checklist ও গেটের অবস্থা ঠিক ধরে।

**Deliverable**
Migration, service, API, UI।

**Sub-tasks**
migration ও append-only, গেট সই, চালুর শর্ত, change request সংযোগ, UI, test

**Definition of done**
- সাধারণ DoD পূরণ।
- AC5.1, AC5.3 (এই task-সংক্রান্ত অংশ) সবুজ।
- কোনো গেট/Checklist/দ্বিতীয় জন ছাড়া `accounting.enabled` চালু করা যায় না (test প্রমাণ)।
- Flag Default বন্ধ।

**Architecture constraints**
- `acc_enablement_log` append-only, কখনো বদলানো/মোছা নয়।
- আলাদা approval table নয়; `P1-04`-এর change request পুনর্ব্যবহার।
- বন্ধ করা কখনো অনুমোদনের পেছনে আটকে থাকে না।

**Open points (Pack-এ অস্পষ্ট)**
- গেট বাতিলের (`gate_revoked`) জন্য নির্দিষ্ট endpoint/verb Pack-এ নেই (শুধু "বাতিল সম্ভব")।
- `POST /accounting/enable` (`P1-05`) ও `POST /accounting/flags/{flag}` (`P4-11`) একই কাজের জন্য দুটো endpoint; একটা অন্যটার alias কি না ঠিক করতে হবে।
- `acc_enablement_log` intake flag-ও ধরে (`flag` column-এ `event_intake.*`), কিন্তু `P4-11` আগেই flag চালু-বন্ধ করে। `P4-11`-এর flag service-কে এখানে log লেখাতে হবে কি না নির্ধারিত নেই।
- "দুজন"-এর দ্বিতীয় জন কে (Finance owner? `accounting.settings.approve`-ওয়ালা অন্য কেউ?) Pack-এ সুনির্দিষ্ট নেই; change request-এর নিয়ম (অনুরোধকারী ≠ অনুমোদনকারী) অনুযায়ী ধরা হয়েছে।
- R5.1 থেকে R5.10 ও AC5.1, AC5.3-এর সংজ্ঞা Blueprint-এ; `P5-01` ও এই task দুটোই এগুলো Acceptance-এ লেখে।
- প্রমাণের লিংক কোথায় সংরক্ষিত (`reason`, `gate_snapshot` নাকি আলাদা column) table-এ আলাদা column নেই।

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

---

## ACC-P5-07 — Training ও support

Project
ERPFlow
Module
Accounting Module
Type
Operations (`ops`)
Title
Training ও support
Branch Name
কোনো branch নেই (নথি ও অধিবেশন-ভিত্তিক কাজ)
View Order
72
Description
**Summary**
Accountant, approver, admin, auditor, finance—সব role-এর মানুষ নিজ নিজ কাজের নির্দেশিকা আর ছোট training পাবে; সমস্যায় কাকে জানাতে হবে সেটাও জানবে। চালুর পর ভুল ব্যবহার বা অজানা error-এ আটকে পড়বে না।

**Task serial**
`ACC-P5-07 — Training ও support` · Ops

**Depends on**
- `ACC-P5-01` (UAT পরিস্থিতি ও ফল)

**Relation: আগের task**
- `P5-01` দিয়েছে: ১৪টা UAT পরিস্থিতির script ও ফল, যা নির্দেশিকার ধাপ-ধাপ উদাহরণ ও screenshot-এর উৎস, এবং UAT-এ ধরা পড়া সমস্যা ও ব্যবহারকারীর প্রশ্ন (নির্দেশিকা/FAQ-এর উপকরণ)।
- আগের Phase-গুলো দিয়েছে বিষয়বস্তু: `P1-*` (Settings, Checklist, CoA), `P2-*` (journal, approval, delegation, override, reversal, queue), `P3-*` (report, period বন্ধ/খোলা, reconciliation), `P4-*` (mapping, intake ops screen)। এবং Pack Section ২.৩-এর error code-তালিকা (Error সহায়িকার উৎস) ও Section ২.৫ audit event।
- `P1-12` দিয়েছে `correlation_id` যা Support playbook-এ "কী তথ্য চাইবে"।

**Relation: পরের task (কে অপেক্ষা করছে)**
- `P5-08`: Pack বলে এই task `P5-08`-কে অবরুদ্ধ করে। ব্যবহারকারী training না পেলে pilot company চালু নয়; `P5-08` ধাপ 3 (পর্যবেক্ষণ) Support playbook অনুযায়ী চলে।
- `P5-04`/`P5-03` এর সাথে মিলিয়ে: Support playbook-এ "কখন flag বন্ধ করবে" (rollback স্তর ১) ও alert দেখে কী করবে।

**Related tables / schema**
কোনো নতুন table নেই।

**Business rules**
- নির্দেশিকা ভূমিকা ধরে; Error সহায়িকা সবার জন্য।
- Training ছোট অধিবেশন, ভূমিকা ধরে, **উপস্থিতির রেকর্ড** রাখা।
- Support playbook "কখন flag বন্ধ করবে" স্পষ্ট বলবে।

**উপকরণ:**

| উপকরণ | কার জন্য | বিষয় |
| --- | --- | --- |
| Accountant-এর নির্দেশিকা | Accountant | Journal লেখা, attachment, submit, reject পেলে কী করা, reversal, queue |
| Approver-এর নির্দেশিকা | Finance Manager, Head of Finance | Approve ও reject, delegation, override ও পর্যালোচনা, post |
| Admin-এর নির্দেশিকা | Admin | Settings, Setup Checklist, CoA, approval rule, mapping, flag, release |
| Auditor-এর নির্দেশিকা | Auditor | Report, Audit Report, reconciliation dashboard |
| Finance-এর নির্দেশিকা | Finance | Period বন্ধ ও খোলা, intake-এর আটকে থাকা event |
| Error বার্তার সহায়িকা | সবাই | প্রতিটা error code-এর সহজ ভাষায় মানে ও কী করবেন (Section ২.৩ থেকে) |
| Support playbook | Support ও tech on-call | সমস্যার ধরন, কে দেখে, কী কী তথ্য চাইবে (`correlation_id`), কখন flag বন্ধ করবে |

**DB flow**
প্রযোজ্য নয়।

**Task scope**
1. পাঁচটা role-ভিত্তিক নির্দেশিকা।
2. Error বার্তার সহায়িকা: Section ২.৩-এর প্রতিটা code (এবং Section ১০.৩-এর নতুন code: `COA_CODE_INVALID`, `SET_STALE_REQUEST`, `ACC_APPEND_ONLY`, `EVT_STATE_INVALID`, `EVT_PROCESSING_ERROR`, `RPT_BASIS_UNSUPPORTED`) সহজ ভাষায়, "কী করবেন" সহ।
3. Support playbook।
4. ভূমিকা ধরে training অধিবেশন; উপস্থিতির রেকর্ড।

**Out of scope**
নতুন feature বা UI পরিবর্তন; টিকেটিং system; (এগুলো Pack-এ নেই)।

**Contract / Permission / Error / Audit**
প্রযোজ্য নয়। (Error সহায়িকা বিদ্যমান code-গুলো ব্যাখ্যা করে, নতুন code বানায় না।)

**Acceptance**
AC5.9

**Test**
কোড test নেই। যাচাই: প্রতিটা Section ২.৩ code সহায়িকায় আছে; প্রতিটা role-এর কমপক্ষে একজন training-এ উপস্থিত; Support playbook একটা কাল্পনিক ঘটনায় (যেমন `held_events` alert) মহড়া দিয়ে দেখা।

**Deliverable**
সব নির্দেশিকা, Error সহায়িকা, Support playbook, অধিবেশন ও উপস্থিতি।

**Sub-tasks**
প্রতিটা নির্দেশিকা, Error সহায়িকা, playbook, অধিবেশন

**Definition of done**
- সাতটা উপকরণ সব জমা।
- Training অধিবেশন হয়েছে, উপস্থিতির রেকর্ড আছে।
- Support playbook-এ `correlation_id` চাওয়া ও flag বন্ধের ধাপ আছে।
- Client-এর Finance owner উপকরণ দেখেছেন।

**Architecture constraints**
- নির্দেশিকা বর্তমান UI/permission মেনে; নতুন কিছু কথা দেওয়া নয়।

**Open points (Pack-এ অস্পষ্ট)**
- Training-এর ভাষা, মাধ্যম (live/recorded), উপস্থিতির কাঠামো নির্দিষ্ট নেই।
- Support-এর স্তর ও সময়সীমা (SLA) Pack-এ নেই।
- "Finance" role (Auditor-এর পাশে আলাদা) default role তালিকায় (Accountant, Finance Manager, Head of Finance, Auditor, Admin) নেই; এখানে কোন role-কে বোঝানো হয়েছে স্পষ্ট করতে হবে।
- AC5.9-এর সংজ্ঞা Blueprint-এ।

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

---

## ACC-P5-08 — Pilot company চালু ও ধাপে ধাপে বিস্তার

Project
ERPFlow
Module
Accounting Module
Type
Operations (`ops`)
Title
Pilot company চালু ও ধাপে ধাপে বিস্তার
Branch Name
কোনো branch নেই (release রেকর্ড-ভিত্তিক ops; deploy হয় ইতিমধ্যে merge হওয়া SHA থেকে)
View Order
73
Description
**Summary**
প্রথমে একটা pilot company-তে সতর্কভাবে চালু, তারপর পর্যবেক্ষণ। তারপর আলাদা সিদ্ধান্তে Asset intake; স্থিতিশীল হলে বাকি company। সমস্যা হলে একটা company-তেই সীমাবদ্ধ থাকবে—Release manager এটাই চায়।

**Task serial**
`ACC-P5-08 — Pilot company চালু ও ধাপে ধাপে বিস্তার` · Ops

**Depends on**
- `ACC-P5-03` (monitoring ও alert)
- `ACC-P5-04` (rollback পরিকল্পনা ও মহড়া)
- `ACC-P5-06` (release gate ও চালুর রেকর্ড)
- `ACC-P5-07` (training ও support)

**Relation: আগের task**
- `P5-03` দিয়েছে `GET /accounting/health`, দশটা alert ও বিজ্ঞপ্তি: পর্যবেক্ষণ-সময়ে "alert-এর সাড়া" এর ভিত্তি।
- `P5-04` দিয়েছে তিন স্তরের rollback ও "করা যাবে না" তালিকা: সমস্যা হলে কী করতে হবে, ও মহড়া দেওয়া।
- `P5-06` দিয়েছে release পাতা, তিন গেট, `acc_enablement_log` ও দুজনের সম্মতিতে `accounting.enabled` চালুর পথ। `P5-01`/`02`/`05` (গেটের উৎস) এর মাধ্যমে পরোক্ষে এসেছে: `gate:cutover`-এর ভিত্তি `P5-02`-এর production cutover checklist যা ধাপ 1 ব্যবহার করে।
- `P5-07` দিয়েছে ব্যবহারকারী training ও Support playbook।
- `P4-11` দিয়েছে intake flag-এর প্রথমবারের নিয়ম (ধাপ 5), `P4-10` দিয়েছে RC8 (ধাপ 6), `P3-13` দিয়েছে RC1-RC9 ও dashboard।

**Relation: পরের task (কে অপেক্ষা করছে)**
কেউ নেই, এটা শেষ card (Pack: "অবরুদ্ধ করে: —")। এই task-এর শেষে Phase 5 ও পুরো Accounting rollout (Phase 0-5) সম্পন্ন। পরের Phase (Phase 6 ইত্যাদি) আলাদা scope।

**Related tables / schema**
নতুন table নেই। পড়া/লেখা (production): পুরো Accounting schema স্বাভাবিক ব্যবহারে; `acc_enablement_log` (চালু-বন্ধ রেকর্ড), `acc_alert_state`, `acc_reconciliation_runs`, `acc_finance_event_inbox`।

**Business rules**
- **R5.4, R5.9:** Asset intake কখনো accounting চালুর সাথে একসাথে নয়। যেকোনো RC ব্যর্থ হলে পরের company-র চালু থামে।
- একই সময়ে একটার বেশি company চালু নয় (প্রক্রিয়াগত)।
- `accounting.enabled` চালু (ধাপ 2) এবং intake চালু (ধাপ 5) আলাদা সিদ্ধান্ত।
- গুরুতর defect থাকলে ধাপ 4-এর সই হয় না।
- সমস্যায় প্রথম পদক্ষেপ flag বন্ধ (rollback স্তর ১)।

**ধাপ:**

| ধাপ | কী | শর্ত |
| --- | --- | --- |
| 1 | Production-এ Setup Checklist সম্পূর্ণ, opening balance Post (মহড়ার checklist মেনে) | `gate:cutover` |
| 2 | `accounting.enabled` চালু (দুজন) | `P5-06`-এর সব শর্ত |
| 3 | নির্ধারিত পর্যবেক্ষণ-সময় (client-এর সাথে ঠিক): সীমিত ব্যবহার, রোজ RC1 থেকে RC9-এর সারাংশ দেখা, alert-এর সাড়া | কোনো RC ব্যর্থ নয় |
| 4 | পর্যবেক্ষণ শেষে Finance owner-এর লিখিত সই | গুরুতর defect নেই |
| 5 | (আলাদা সিদ্ধান্তে) `event_intake.enabled` ও `sources.asset_write_off` চালু (`P4-11`-এর প্রথমবারের নিয়ম) | OD-18 অনুমোদিত, ধাপ 4 সম্পন্ন |
| 6 | Asset intake-এর জন্য আলাদা পর্যবেক্ষণ-সময় | RC8 সবুজ |
| 7 | পরের company: ধাপ 1 থেকে আবার | আগেরটা স্থিতিশীল |

**DB flow**
নতুন নেই। ধাপ 1: Setup Checklist (`P1-05`), CoA, Opening Draft -> Submit -> approve -> Post (`P1-11`, `P2-08`, `P2-12`, `P2-14`)। ধাপ 2: Section ৯-র flag-চালু (`P5-06`)। ধাপ 3: RC1-RC9 (`P3-13`)। ধাপ 5: `P4-11` + consumer (`P4-03`) + Section ৯.৪।

**Task scope**
1. ধাপ 1: production cutover (`P5-02`-এর checklist অনুযায়ী), `gate:cutover` পাস থাকা নিশ্চিত।
2. ধাপ 2: `accounting.enabled` চালু (Maker–Checker, `P5-06`)।
3. ধাপ 3: পর্যবেক্ষণ-সময় (দৈনিক RC সারাংশ, alert-এর সাড়া, সীমিত ব্যবহার)।
4. ধাপ 4: Finance owner-এর সই।
5. ধাপ 5-6: Asset intake চালু ও আলাদা পর্যবেক্ষণ।
6. ধাপ 7: পরের company-র সময়সূচি ও চক্র।
7. চালুর রিপোর্ট।

**Out of scope**
নতুন feature বা code; Disposal/acquisition event intake; Phase 6 কাজ।

**Contract / Permission**
ব্যবহৃত API: `P5-06`, `P4-11`, `P3-13`, `P5-03`-এর বিদ্যমান। Permission বিদ্যমান (`accounting.enable.manage`, `accounting.settings.approve`)।

**Error**
প্রত্যাশিত: `SET_INCOMPLETE`, `ACC_FORBIDDEN`, `JRN_SOD_VIOLATION` (চালুর ধাপে ভুল হলে)।

**Audit**
`accounting.enablement.changed`, `accounting.flag.enabled`, `accounting.flag.disabled`, `accounting.recon.run`

**Acceptance**
AC5.7, AC5.8, AC5.10

**Test**
কোড test নেই। যাচাই: প্রতিটা ধাপের শর্ত পূরণের প্রমাণ (log, dashboard screenshot, সই); পর্যবেক্ষণ-সময়ে কোনো RC `fail` নয় (দৈনিক সারাংশ); alert এলে সাড়ার রেকর্ড; ধাপ 5 কখনো ধাপ 2-এর সাথে একই দিনে/একই সিদ্ধান্তে নয়।

**Deliverable**
চালুর রিপোর্ট, পর্যবেক্ষণের দৈনিক সারাংশ, সই, বাকি company-র সময়সূচি।

**Sub-tasks**
production cutover, চালু, পর্যবেক্ষণ, সই, Asset intake ধাপ, পরের company

**Definition of done**
- Pilot company-তে `accounting.enabled` চালু, `acc_enablement_log`-এ রেকর্ড।
- পর্যবেক্ষণ-সময়ে কোনো RC ব্যর্থ হয়নি, দৈনিক সারাংশ জমা।
- Finance owner-এর লিখিত সই আছে।
- Asset intake আলাদা সিদ্ধান্তে ও আলাদা পর্যবেক্ষণে চালু, RC8 সবুজ।
- পরের company-র সময়সূচি আছে, আগেরটা স্থিতিশীল প্রমাণসহ।

**Architecture constraints**
- Asset intake accounting চালুর সাথে একসাথে নয়।
- কোনো RC ব্যর্থ হলে পরের company-র চালু থামে।
- Production-এ সরাসরি SQL-এ data বদল নয়; ভুল ঠিক করার একমাত্র পথ Reversal ও Adjustment।

**Open points (Pack-এ অস্পষ্ট)**
- পর্যবেক্ষণ-সময়ের দৈর্ঘ্য "client-এর সাথে ঠিক" বলা আছে, মান নেই। ধাপ 3 ও 6 দুটোর জন্যই আলাদা সময় ঠিক করতে হবে।
- Pilot company কোনটা, কার সিদ্ধান্তে নির্বাচিত, Pack-এ নেই।
- "স্থিতিশীল" ও "গুরুতর defect"-এর সংজ্ঞা নেই।
- AC5.7, AC5.8, AC5.10 ও R5.4, R5.9-এর সংজ্ঞা Blueprint-এ।
- ধাপ 5-এ OD-18 "অনুমোদিত" যাচাই হয় নথি দেখে (system যাচাই করে না, `P4-11`)।
- Rollback-এর সিদ্ধান্ত কে নেয় (পর্যবেক্ষণ-সময়ে সমস্যা হলে) `P5-04`-এর open point।

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