غیر فعلی تقاضے

وہ قابلِ پیمائش معیارِ خصوصیات — کارکردگی، دستیابی، توسیع پذیری، سیکیورٹی، رازداری، قابلِ رسائی، استعمال پذیری، قابلیتِ صیانت، مشاہدہ پذیری، قابلِ اعتمادی، تعمیل، آڈٹ پذیری، باہمی تعامل، اور نقل پذیری — جنہیں سندھ آئی ٹی پورٹل — سہولت ڈیسک (SITP) کو V1 کے لیے پورا کرنا لازم ہے۔ ہر تقاضہ ایک ٹھوس میٹرک، پیمائش کا طریقہ، اور وجہ توجیہ پیش کرتا ہے۔

1. اس دستاویز کو کیسے پڑھیں

یہ دستاویز SITP کے غیر فعلی رویے کے لیے واحد مستند ماخذ ہے۔ اسے انجینئرنگ ڈیزائن اور سائزنگ کے لیے، QA قبولیت کے لیے، سیکیورٹی/تعمیل جائزہ لینے والوں کے لیے کنٹرول شواہد کے طور پر، اور PPP معاہدے (MAAHIR / Server4Sale) کے لیے معیار کی بنیاد کے طور پر استعمال کیا جاتا ہے۔

1.1 NFR ساخت

ہر تقاضہ یوں لکھا جاتا ہے:

### NFR-<CAT>-<nnn> — <title> [M|S|C]

**Metric / Target.** <what is measured and the threshold to meet>
**Measurement method.** <how it is verified — tooling, test, cadence>
**Rationale.** <why this target, and the consequence of missing it>

آخری بیج MoSCoW ہے (_conventions.md §5): M لازم الحصول (V1 لانچ کی رکاوٹ) · S حاصل کرنا چاہیے (V1، لانچ کے فوراً بعد) · C مل سکتا ہے (V1 میں اگر وقت ہو تو اچھا)۔ ملتوی اشیاء NFR کے طور پر فہرست نہیں کی جاتیں؛ وہ /specs/ur/14-roadmap-release/ میں موجود ہیں۔

1.2 زمرہ جات کوڈز

1.3 اہداف V1 کی بنیادیں ہیں

اس دستاویز کے تمام عددی اہداف V1 بنیادیں ہیں۔ یہ جواز قابل اصول ہیں جو ایک واحد-ہوسٹ Server4Sale تعیناتی (دیکھیں /specs/ur/15-tech-architecture/ §17) کے لیے مقرر کیے گئے، حوالہ جاتی نظام (بھارت CPGRAMS، پاکستان سٹیزنز پورٹل) اور مماثل صوبائی پورٹلز پر مشاہدہ کردہ بوجھ کے بمقابلہ کیلیبریٹ کیے گئے۔ یہ قابلِ ترتیب ہیں: [TBD/confirm] سے نشان زد اہداف کو بنیادی فریز سے قبل نامزد مالک کی تصدیق درکار ہے؛ باقی تمام اہداف ہر مرحلہ نظرثانی میں تبدیل کیے جا سکتے ہیں (§6 دیکھیں)۔ جہاں کوئی ہدف فن تعمیر کو کراس کٹ کرتا ہے وہ دستاویز 15 کے متعلقہ سیکشن سے جوڑا جاتا ہے؛ جہاں یہ سیکیورٹی کنٹرولز کو کراس کٹ کرتا ہے وہ دستاویز 11 سے جوڑا جاتا ہے۔

1.4 پیمائش کے اصول

• تاخیریں nginx ایج پر (سرور سائیڈ) ناپی جاتی ہیں جب تک کہ وہ صراحتاً کلائنٹ سائیڈ نہ ہوں، رولنگ 30-دن کی کھڑکی پر p95 فیصدیل پر، طے شدہ دیکھ بھال کی کھڑکیوں کو چھوڑ کر۔
• ہم وقت رابطہ توثیق شدہ، الگ، فعال سیشنز کے طور پر ناپا جاتا ہے جو ہر منٹ ≥ 1 API کال جاری کرتے ہیں۔
• اپ ٹائم عوامی اسٹیٹس پیج پروبز (پورٹل + API + دستاویزات سائٹ) کے بمقابلہ ناپی جاتی ہے، بشمول منصوبہ بند دیکھ بھال کو §2.2 کے مطابق خارج۔
• تھرو پٹ پروڈکشن ڈیٹا سیٹ پر حقیقت پسندانہ کارڈینالٹی پر ناپی جاتی ہے (/specs/ur/13-test-strategy/ دیکھیں)۔

2. NFR سانچہ (ورکڈ مثال)

نیچے دیا گیا سانچہ صرف تشبیہی ہے۔ یہ کوئی NFR نہیں۔ §3 میں ہر بعد کا تقاضہ اسی شکل پر عین عمل کرتا ہے۔

### NFR-XX-000 — (template example, not a requirement) [M]

**Metric / Target.** The <quantity> shall be ≤ <value> under <conditions>.
**Measurement method.** Verified by <tool/test> on <cadence>; evidence stored in <location>.
**Rationale.** <Why this matters to users/operations/compliance, and the cost of failure.>

• آئی ڈی EN/UR/SD میں مستحکم ہے اور کبھی دوبارہ نمبر نہیں دی جاتی۔
• عنوان مختصر اور حکمانہ ہے۔
• میٹرک / ہدف ہمیشہ ایک عدد دیتا ہے (یا صریح [TBD/confirm])، کبھی "تیز" یا "مضبوط" جیسی کوئی وصفی عبارت نہیں۔
• طریقۂ پیمائش ٹول (Loki، Grafana، k6، Lighthouse، axe، OWASP ZAP وغیرہ) اور کیڈنس (ہر ریلیز، مسلسل، سہ ماہی) کا نام لیتا ہے۔
• وجہ توجیہ ہدف کو ایک صارف کے نتیجے، عملی خطرے، یا تعمیل کی ذمہ داری سے جوڑتا ہے۔

3. تقاضے بلحاظ زمرہ

3.1 کارکردگی (PERF)

یہ پورٹل شہریوں، کمپنی نمائندگان، اور حکومتی عملے کو موبائل-پہلے نیٹ ورکس پر تین خطوط میں خدمات فراہم کرتا ہے۔ کارکردگی کے اہداف بنیادی ٹکٹ سفر (داخل → ٹریک → حل) کے محسوس ردعمل کی حفاظت کرتے ہیں اور AI/OCR کی لاگت کو محدود رکھتے ہیں تاکہ لمبی دم والے عملات مختصر والوں کو کبھی نہ روکیں۔

NFR-PERF-001 — API ریڈ تاخیر (p95) [M]

میٹرک / ہدف۔ ریڈ API اینڈ پوائنٹس (GET) کی تاخیر nginx ایج پر، V1 ہم وقت رابطہ ہدف تک (NFR-PERF-008 دیکھیں) ≤ 300 ms ہو گی۔ طریقۂ پیمائش۔ مسلسل، OpenTelemetry ٹریسز اور Grafana میں nginx ایکسس لاگ p95 پینل کے ذریعے؛ 15 منٹ سے زیادہ برقرار خلاف ورزی پر Sentry میں الرٹ۔ وجہ توجیہ۔ ریڈ راستے (ٹکٹ فہرستیں، ڈیش بورڈز، KB) انٹرایکٹو بوجھ پر غالب ہیں؛ 4G موبائل پر > 300 ms p95 محسوس ردعمل کو صریحاً خراب کرتا ہے۔

NFR-PERF-002 — API رائٹ تاخیر (p95) [M]

میٹرک / ہدف۔ رائٹ API اینڈ پوائنٹس (سٹیٹ تبدیل کرنے والے عملات کے لیے POST/PUT/PATCH) کی تاخیر nginx ایج پر ≤ 800 ms ہو گی، BullMQ میں منتقل کردہ AI/OCR کام کو چھوڑ کر۔ طریقۂ پیمائش۔ مسلسل OTel ٹریسز کے ذریعے؛ اسٹیجنگ کے بمقابلہ ہر ریلیز k6 لوڈ ٹیسٹ۔ وجہ توجیہ۔ رائٹس آڈٹ، سرچ انڈیکس، اور اطلاعاتی قطاروں میں پھیلتی ہیں؛ 800 ms بجٹ DB لین دین + قطار میں شامل کرنے کو ڈھکتا ہے جبکہ بھاری کام غیر ہم وقت انجام پاتا ہے۔

NFR-PERF-003 — پیج لوڈ — سب سے بڑا مواد رنگ (LCP) [M]

میٹرک / ہدف۔ سرفہرست 10 پورٹل پیجز پر LCP، ایک نقلی 4G درجہ وسط موبائل ڈیوائس (Moto G Power / Lighthouse "mobile" پروفائل) پر ≤ 2.5 s ہو گا۔ طریقۂ پیمائش۔ اسٹیجنگ بلڈ کے بمقابلہ ہر ریلیز Lighthouse CI؛ Sentry میں Real User Monitoring (RUM) انٹیگریشن کے ذریعے فیلڈ ڈیٹا؛ Grafana میں p75 رپورٹڈ۔ وجہ توجیہ۔ 2.5 s LCP گوگل کا "بہتری درکار" / "اچھا" دہلیز ہے اور موبائل-پہلے شہری رسائی سے ہم آہنگ ہے۔

NFR-PERF-004 — AI خلاصہ تاخیر [M]

میٹرک / ہدف۔ AI ٹکٹ خلاصہ پیداوار، OCR شدہ ٹکٹ جمع کرانے کے بعد، بشمول حذف و ترمیم + LLM کال + آڈٹ رائٹ، ≤ 15 s p95 میں واپس آئے گا۔ طریقۂ پیمائش۔ ai-summarize قطار کے لیے Grafana میں BullMQ جاب دورانیہ ہسٹوگرام؛ 30-دن کی کھڑکی والا p95 پینل۔ وجہ توجیہ۔ خلاصے جات فرز بندی کے بہاؤ کے اندر عملے کے جائزے سے گزرتے ہیں؛ > 15 s صارف کو معاون راستے سے دستبردار ہونے پر مجبور کرتا ہے اور خام ٹکٹ پڑھنے پر مائل کرتا ہے۔

NFR-PERF-005 — فی پیج OCR تھرو پٹ [M]

میٹرک / ہدف۔ ایک معیاری A4 پیج (≤ 5 MB، 300 DPI) کا OCR کلاؤڈ انجن استعمال کرتے ہوئے ≤ 30 s p95 اور آن-پریمس Tesseract بیک اپ استعمال کرتے ہوئے ≤ 60 s p95 میں مکمل ہو گا۔ طریقۂ پیمائش۔ Grafana میں ocr-extract قطار دورانیہ ہسٹوگرام، انجن کے لحاظ سے الگ؛ 100 نمائندہ دستاویزات کا سہ ماہی بینچ مارک سوٹ۔ وجہ توجیہ۔ OCR MoM نکالنے اور سرچ انڈیکسنگ کا دروازہ ہے؛ 30 s کی چھت ایک 10-پیج MoM اپ لوڈ کو صارف کو ~5 منٹ سے زیادہ روکنے سے باز رکھتی ہے۔

NFR-PERF-006 — اندرونی چیٹ پیغام اینڈ-ٹو-اینڈ تاخیر [S]

میٹرک / ہدف۔ پیغام بھیجنے سے لے کر ایک منسلک وصول کنندہ کے WebSocket پر پہنچنے تک کا وقت ایک ہی گیٹ وے واقعہ کے اندر ≤ 500 ms p95 اور Redis pub-sub ایڈاپٹر کے ذریعے واقعات کے درمیان ≤ 800 ms p95 ہو گا۔ طریقۂ پیمائش۔ کلائنٹ سائیڈ RUM (بھیجنے کا ٹائم اسٹیمپ بمقابلہ وصول کرنے کا ٹائم اسٹیمپ) Sentry میں مجموعی؛ گیٹ وے message ہینڈلر کے لیے سرور سائیڈ OTel اسپین۔ وجہ توجیہ۔ چیٹ Slack طرز کی ہے؛ > 500 ms مکالمے کی رفتار توڑ دیتا ہے اور صارفین کو پلیٹ فارم سے ہٹا دیتا ہے۔

NFR-PERF-007 — ڈیٹا بیس کڑی تاخیر (p95) [M]

میٹرک / ہدف۔ p95 MariaDB کڑی تاخیر (طے شدہ بیچ/ایگریگیٹ جابز کو چھوڑ کر) ≤ 100 ms ہو گی، اور سلو-کڑی لاگ دہلیز 500 ms ہو گی جس میں روزانہ صفر معمولی سلو کڑیاں ہوں۔ طریقۂ پیمائش۔ MariaDB پرفارمنس سکیما + Prometheus ایکسپورٹر؛ Grafana میں سلو-کڑی شمار پینل؛ /specs/ur/15-tech-architecture/ §5.5 کے مطابق سرفہرست 20 گرم ترین کڑیوں کا سہ ماہی EXPLAIN ANALYZE جائزہ۔ وجہ توجیہ۔ DB بنیادی سطح ہے؛ کڑی تاخیر اوپر ہر API ہدف پر ضرب ہے۔

NFR-PERF-008 — ہم وقت صارفین (V1 ہدف) [M]

میٹرک / ہدف۔ نظام ہر منٹ ≥ 1 API کال جاری کرنے والے 5,000 ہم وقت توثیق شدہ صارفین کو برقرار رکھے گا، جس میں ≤ 1 % HTTP 5xx اور کوئی بہترین تنزل بیک اپس فعال نہ ہوں۔ [TBD/confirm] — مرحلہ-1 لوڈ پروفائل کے بمقابلہ توثیق طلب۔ طریقۂ پیمائش۔ اسٹیجنگ کے بمقابلہ ہدف کے 110 % پر 60 منٹ کے لیے ہر ریلیز k6 سوک ٹیسٹ؛ پروڈکشن بوجھ لانچ + 30 دن پر Grafana میں تصدیق شدہ۔ وجہ توجیہ۔ 5,000 ایک جواز قابل صوبائی-پورٹل V1 بنیاد ہے؛ عروج کے واقعات (وزارتی اعلانات، نیوز سائیکل) عوامی سائٹ CDN کیش اور قطار آف لوڈ کے ذریعے جذب ہو جاتے ہیں۔

NFR-PERF-009 — پہلے بائٹ کا وقت (TTFB) [S]

میٹرک / ہدف۔ nginx ایج پر TTFB کیشڈ ریڈز کے لیے ≤ 200 ms p95 اور غیر کیشڈ ڈائنامک ریڈز کے لیے ≤ 400 ms p95 ہو گا۔ طریقۂ پیمائش۔ nginx ایکسپورٹر + RUM؛ ہوم، ٹکٹ-فہرست، اور KB-سرچ راستوں کے بمقابلہ ہر ریلیز k6 ریمپ۔ وجہ توجیہ۔ TTFB سستے موبائل نیٹ ورکس پر LCP میں غالب عنصر ہے؛ یہ NFR-PERF-003 کے لیے اپ سٹریم کنٹرول ہے۔

NFR-PERF-010 — سرچ تاخیر [M]

میٹرک / ہدف۔ Meilisearch سہارا یافتہ /search سرفہرست 10 کڑی شکلوں (ٹکٹ سرچ، KB سرچ، افسران سرچ) کے لیے EN/UR/Sindhi میں ≤ 250 ms p95 میں واپس آئے گا۔ طریقۂ پیمائش۔ سرچ ایڈاپٹر پر OTel اسپین؛ 100-کڑی کثیر لسانی سوٹ استعمال کرتے ہوئے تینوں خطوط میں سہ ماہی بینچ مارک۔ وجہ توجیہ۔ سرچ عملے کی فرز بندی اور کمپنی سیلف سروس کا بنیادی نیویگیشن راستہ ہے؛ خط ہینڈلنگ کی لاگت تاخیر کو دگنا نہیں کرنی چاہیے۔

NFR-PERF-011 — اطلاع فین آؤٹ تاخیر [S]

میٹرک / ہدف۔ ڈومین واقعہ سے پہلے باہر روانہ چینل بھیجے جانے (ای میل/SMS/WhatsApp/ان-ایپ) کا وقت فوری ترجیح اطلاعات کے لیے ≤ 30 s p95 اور ڈائجسٹ بیچ کے لیے ≤ 5 min p95 ہو گا۔ طریقۂ پیمائش۔ ہر چینل کے لیے BullMQ قطار انتظار-دورانیہ ہسٹوگرام؛ اگر بیک لاگ 5 min سے زیادہ کے لیے > 1,000 جابز ہو تو الرٹ۔ وجہ توجیہ۔ SLA ٹائمر تفویض اور اسکیلیشن اطلاعات کی فوری ترسیل پر منحصر ہیں۔

3.2 دستیابی (AVAIL)

SITP ایک عوامی رخ حکومتی سہولت چینل ہے؛ بندیشیں نمایاں اور شہرت کو متاثر کرتی ہیں۔ بنیاد Server4Sale پر واحد-ہوسٹ ہے (بمطابق /specs/ur/15-tech-architecture/ §17، §21) جس میں آف-ہوسٹ بیک اپس اور ایک دستاویزی شدہ وارم-اسٹینڈ بائی اگلا قدم ہے۔

NFR-AVAIL-001 — پروڈکشن اپ ٹائم [M]

میٹرک / ہدف۔ پورٹل، API، اور دستاویزات سائٹ ماہانہ ≥ 99.9 % اپ ٹائم حاصل کریں گی (= ~43 منٹ/مہینہ یا ~8.7 گھنٹے/سال کا ایرر بجٹ)، بشمول منصوبہ بند دیکھ بھال (NFR-AVAIL-002)۔ طریقۂ پیمائش۔ دو جغرافیائی نگاہ گاہوں سے 1-منٹ کیڈنس پر عوامی اسٹیٹس-پیج پروبز (پورٹل ہوم، /api/health، /docs/)؛ اسٹیٹس پیج پر ماہانہ رپورٹ شائع۔ وجہ توجیہ۔ 99.9 % واحد-ہوسٹ تعیناتی کے لیے جواز قابل V1 چھت ہے اور صوبائی-پورٹل اصول سے مماثل ہے؛ اعلیٰ درجات کے لیے HA ٹوپولوجی درکار جو بعد-V1 کے لیے ملتوی ہے۔

NFR-AVAIL-002 — منصوبہ بند دیکھ بھال کی کھڑکی [M]

میٹرک / ہدف۔ منصوبہ بند دیکھ بھال ایک شائع شدہ کھڑکی (اتوار 02:00–05:00 PKT) کے اندر ہو گی اور مجموعی ڈاؤن ٹائم میں سے 6 گھنٹے/مہینہ سے زیادہ استعمال نہیں کرے گی۔ طریقۂ پیمائش۔ ہر دیکھ بھال کا تبدیلی-انتظام ریکارڈ؛ 15 منٹ سے زیادہ کی کسی بھی کھڑکی کے لیے ≥ 72 گھنٹے قبل اسٹیٹس پیج اعلان۔ وجہ توجیہ۔ قابل پیش بین، کم ٹریفک کھڑکیاں کاروباری اوقات میں شہری رسائی کی حفاظت کرتی ہیں اور خارج کیے جانے پر 99.9 % بجٹ پورا کرتی ہیں۔

NFR-AVAIL-003 — AI / تیسرے فریق کے ڈاؤن ہونے پر بہترین تنزل [M]

میٹرک / ہدف۔ اگر AI سروس، کوئی OCR انجن، یا کوئی بیرونی انٹیگریشن (NADRA/SECP/FBR/SRB/PSEB/e-Office، Mailjet/SMS/WA) دستیاب نہ ہو، تو بنیادی ٹکٹ سفر (داخل، ٹریک، تبصرہ، حل، بند) مکمل فعال رہے گا جس میں منحصر صلاحیت UI میں صریحاً "عارضی طور پر دستیاب نہیں" نشان زد ہو گی۔ طریقۂ پیمائش۔ اسٹیجنگ میں ہر ریلیز فالٹ-انجیکشن ٹیسٹ: ہر بیرونی انحصار مارا جاتا ہے اور اہم صارف سفر (/specs/ur/10-ux-sitemap-flows/ بمطابق) پاس ہونا چاہیے۔ وجہ توجیہ۔ شہریوں کو کبھی بھی داخل کرنے سے نہیں روکا جا سکتا کیونکہ کوئی ڈاؤن سٹریم AI/OCR/انٹیگریشن ڈاؤن ہے؛ سرکٹ بریکرز (NFR-RELY-003) اسے فراہم کرتے ہیں۔

NFR-AVAIL-004 — آفت بازیابی — بازیابی نقطہ ہدف (RPO) [M]

میٹرک / ہدف۔ RPO ≤ 1 گھنٹہ (بنیاد) ہو گا۔ [TBD/confirm] — جب پروڈکشن میں بن لاگ-شپنگ لیگ ناپی جائے گی تو سخت کیا جائے گا (/specs/ur/15-tech-architecture/ §21 دیکھیں)۔ طریقۂ پیمائش۔ سہ ماہی بحالی مشق (NFR-MAINT-005 بمطابق)؛ ناپی گئی لیگ = اسٹینڈ بائی ہدف پر now() − latest_binlog_applied_at۔ وجہ توجیہ۔ 1 گھنٹے کا ضائع شدہ ڈیٹا شہری جمع کردہ ٹکٹس کے لیے زیادہ سے زیادہ برداشت کی حد ہے؛ موجودہ بن لاگ صلاحیت کم اکائی منٹس کو سہارا دیتی ہے۔

NFR-AVAIL-005 — آفت بازیابی — بازیابی وقت ہدف (RTO) [M]

میٹرک / ہدف۔ RTO واقعے کے اعلان سے لے کر اسی ہوسٹ پر مکمل سروس بحالی تک ≤ 4 گھنٹے (بنیاد) ہو گا۔ [TBD/confirm] — جب وارم-اسٹینڈ بائی ٹوپولوجی موجود ہو گی تب نظرثانی کیا جائے گا۔ طریقۂ پیمائش۔ سہ ماہی بحالی مشق اینڈ-ٹو-اینڈ وقت؛ نتیجہ DR ران بک سے منسلک۔ وجہ توجیہ۔ 4-گھنٹے کی بندش 99.9 % سالانہ بجٹ کے اندر اور ایک سہولت (غیر ہنگامی) سروس کی برداشت کے اندر ہے۔

NFR-AVAIL-006 — زیرو-ڈاؤن ٹائم ڈیپلائز [S]

میٹرک / ہدف۔ معمولی ایپلیکیشن ڈیپلائز /specs/ur/15-tech-architecture/ §19 بمطابق nginx ڈریننگ + رولنگ کنٹینر دوبارہ تخلیق کے ذریعے 0 s صارف-نمایاں ڈاؤن ٹائم پیدا کریں گے۔ طریقۂ پیمائش۔ ہر ڈیپلائے کے دوران اسٹیٹس-پیج پروب ریٹ؛ اگر 5xx ریٹ 60 s سے زیادہ کے لیے 1 % سے تجاوز کرے تو ڈیپلائے خود بخود رول بیک ہو جائے گا۔ وجہ توجیہ۔ بار بار محفوظ ڈیپلائز PPP میں وعدہ کردہ تکرار کیڈنس کی پیش شرط ہیں۔

3.3 توسیع پذیری (SCAL)

V1 ایک ہوسٹ کے لیے سائز کی گئی ہے؛ فن تعمیر (دستاویز 15 §4، §20) اسکیل آؤٹ کو ایک ری فیکٹر رکھتا ہے، دوبارہ لکھنا نہیں۔ یہاں اہداف ہیڈ روم اور گروتھ رن وے کی وضاحت کرتے ہیں۔

NFR-SCAL-001 — اسٹیٹ لیس سروسز کی افقی توسیع [M]

میٹرک / ہدف۔ NestJS API، WebSocket گیٹ وے، FastAPI AI سروس، اور ہر BullMQ ورکر پول افقی طور پر کوڈ کی تبدیلی کے بغیر توسیع پذیر ہوں گے — صرف ریپلیکا تعداد کی تبدیلی + Redis pub-sub جوائن۔ طریقۂ پیمائش۔ ہر ریلیز فن تعمیر جائزہ تصدیق کرتا ہے کہ کوئی ان-پروسس اسٹیٹ نہیں؛ اسٹیجنگ ٹیسٹ اسی Redis کے پیچھے 2× API ریپلیکا چلاتا ہے۔ وجہ توجیہ۔ ماڈیولر-مونولتھ کے بیان کردہ وعدے (دستاویز 15 §1) کو مقفل کرتا ہے کہ اسکیل آؤٹ ترتیب ہے، انجینئرنگ نہیں۔

NFR-SCAL-002 — OCR / AI / ایکسپورٹس کے لیے قطار پر مبنی بوجھ ہموار کرنا [M]

میٹرک / ہدف۔ OCR، AI، ایکسپورٹس، اطلاع فین آؤٹ، اور ڈائجسٹ جابز صرف کلاس بمطابق ورکر پولز والی BullMQ قطاروں کے ذریعے چلیں گی؛ درخواست راستہ ان پر کبھی بلاک نہیں ہوگا۔ طریقۂ پیمائش۔ CI میں سٹیٹک گیٹ: کسی کنٹرولر/ہینڈلر سے OCR/AI/ایکسپورٹ/اطلاع لاگو تک براہ راست کال (قطار کو بائی پاس کرتے ہوئے) بلڈ فیل کر دیتی ہے۔ وجہ توجیہ۔ API تاخیر (NFR-PERF-001/002) کو لمبی دم AI/OCR لاگت سے بچاتا ہے اور ایک سست انجن کے دوسروں کو بھوکا مارنے سے روکتا ہے۔

NFR-SCAL-003 — ڈیٹا بیس ریڈ ریپلیکاز — آگے کا راستہ [C]

میٹرک / ہدف۔ ڈیٹا لیئر اس طرح ڈھالی جائے گی کہ تجزیات (Metabase) اور ریڈ-بھاری عوامی راستوں کے لیے MariaDB ریڈ ریپلیکاز متعارف کرانے کے لیے صرف Prisma ریڈ/رائٹ اسپلٹ کنفگریشن درکار ہے — کوئی اسکیمہ یا کڑی تبدیلی نہیں۔ طریقۂ پیمائش۔ مرحلہ 2 گیٹ پر فن تعمیر جائزہ تصدیق کرتا ہے کہ رائٹ-پرائمری/ریڈ-ریپلیکا روٹنگ کوڈ میں جڑی ہوئی ہے (آج کل سنگل-پرائمری ہی کیوں نہ ہو)؛ لیگ-اسکیپ دہلیز قابلِ ترتیب۔ وجہ توجیہ۔ /specs/ur/15-tech-architecture/ §5.6 میں دستاویزی کردہ اگلا قدم مستقبل کے دوبارہ لکھنے کے بغیر محفوظ رکھتا ہے۔

NFR-SCAL-004 — ٹکٹ حجم گروتھ رن وے [M]

میٹرک / ہدف۔ ڈیٹا ماڈل، اشاریے، اور پارٹیشنگ (آڈٹ جدول ماہ کے لحاظ سے پارٹیشنڈ، دستاویز 05 بمطابق) اسکیمہ ری فیکٹر کے بغیر 5 سال تک سالانہ 100,000 نئے ٹکٹس (≈ 500k لائیو ٹکٹس) کو سہارا دیں گے؛ آرکائیو/پرج NFR-PRIV-007 بمطابق۔ طریقۂ پیمائش۔ حقیقی ٹکٹ حجم کے بمقابلہ سالانہ گنجائش جائزہ؛ سہ ماہی سلو-کڑی جائزہ (NFR-PERF-007)؛ پارٹیشن پرون چیک۔ وجہ توجیہ۔ صوبائی-پورٹل گروتھ مفروضہ؛ ٹکٹنگ ٹیبلز رائٹ-اونس + سافٹ-ڈیلیٹ ہیں اس لیے توسیع انسرٹس میں لکیری ہے۔

NFR-SCAL-005 — رجسٹرڈ صارف گروتھ رن وے [M]

میٹرک / ہدف۔ نظام V1 ہارڈویئر الاٹمنٹ پر کارکردگی ریگریشن کے بغیر 100,000 رجسٹرڈ کمپنی نمائندگان اور 10,000 حکومتی عملے کے اکاؤنٹس کو سہارا دے گا۔ طریقۂ پیمائش۔ اسٹیجنگ میں ہدف کارڈینالٹی کے 2× پر لوڈ ٹیسٹ؛ پروڈکشن میں RBAC-ریذولوشن کیش ہٹ ریٹ ≥ 95 % (NFR-OBS-001)۔ وجہ توجیہ۔ سندھ کی IT-سیکٹر کمپنیوں کی تعداد + 5-سالہ افق پر تمام صوبائی محکمے کے عملے کے بمقابلہ سائز کیا گیا۔

NFR-SCAL-006 — CDN اور ایج کیشنگ [S]

میٹرک / ہدف۔ سٹیٹک اثاثے (پورٹل بنڈلز، دستاویزات سائٹ، عوامی تصاویر) nginx کے سامنے ایک CDN کے ذریعے پیش کیے جائیں گے؛ ایج پر سٹیٹک اثاثہ درخواستوں کے لیے کیش-ہٹ تناسب ≥ 90 %۔ طریقۂ پیمائش۔ CDN ڈیش بورڈ؛ ہر ریلیز چیک کہ ہوم پیج اور سرفہرست KB مضامین CDN-کیش ہوں۔ وجہ توجیہ۔ اوریجن بوجھ کم کرتا ہے اور موبائل پر شہریوں کے لیے LCP (NFR-PERF-003) بہتر کرتا ہے۔

3.4 سیکیورٹی (SEC)

سیکیورٹی کنٹرولز مستند کنٹرول کیٹلاگ کے لیے /specs/ur/11-security-compliance/ سے حوالہ دیتے ہیں۔ یہاں NFRs قابلِ پیمائش دہلیزیں بیان کرتے ہیں۔

NFR-SEC-001 — OWASP ASVS L2 تعمیل [M]

میٹرک / ہدف۔ ایپلیکیشن پروڈکشن لانچ سے قبل مکمل طور پر OWASP Application Security Verification Standard (ASVS) Level 2 پورا کرے گی۔ طریقۂ پیمائش۔ لانچ سے قبل ASVS v4 L2 چیک لسٹ کے بمقابلہ آزادانہ سیکیورٹی جائزہ؛ خلاات ایک دستخط شدہ اصلاحی منصوبے کے ساتھ بند تک ٹریک کیے جاتے ہیں۔ وجہ توجیہ۔ ASVS L2 ایک ایسے عوامی حکومتی نظام کے لیے مناسب دہلیز ہے جو PII اور شہری رخ ورک فلوز ہینڈل کرتا ہے۔

NFR-SEC-002 — منتقلی میں خفیہ کاری [M]

میٹرک / ہدف۔ تمام بیرونی ٹریفک TLS 1.2+ استعمال کرے گی (TLS 1.3 ترجیحی)؛ TLS 1.0/1.1 غیر فعال؛ HSTS جس میں max-age ≥ 31536000; includeSubDomains; preload؛ SSL Labs پر A یا A+ ریٹنگ۔ طریقۂ پیمائش۔ مسلسل SSL Labs مانیٹر؛ ہر ریلیز nginx کنفگ جائزہ۔ وجہ توجیہ۔ انٹرنیٹ پر PII قبول کرنے والے کسی بھی نظام کے لیے بنیادی ٹرانسپورٹ سیکیورٹی۔

NFR-SEC-003 — باقی خفیہ کاری [M]

میٹرک / ہدف۔ MariaDB (TDE یا جدول سطح)، MinIO بکٹس، بیک اپس، اور Keycloak ریئلم ایکسپورٹس AES-256 (یا مضبوط تر) کے ساتھ باقی خفیہ کیے جائیں گے؛ کلیدز رازوں کے والٹ میں رکھی جائیں گی، امیجز یا ریپوز میں کبھی نہیں۔ طریقۂ پیمائش۔ ہر ریلیز کنفگریشن آڈٹ؛ سہ ماہی کلید-روٹیشن تعمیل چیک؛ بحالی مشق (NFR-MAINT-005) میں بیک اپ ڈکرپٹ-اور-ریڈ کی تصدیق۔ وجہ توجیہ۔ اگر اسٹوریج میڈیا برآمد ہو جائے تو PII اور آڈٹ ڈیٹا کی حفاظت کرتا ہے؛ NFR-PRIV اور NFR-COMP ذمہ داریوں کو سہارا دیتا ہے۔

NFR-SEC-004 — عملے کے لیے دو فیکٹر تصدیق [M]

میٹرک / ہدف۔ تمام حکومتی عملے کے اکاؤنٹس کے لیے 2FA لازمی ہو گا (TOTP بنیادی؛ جہاں ڈیوائس سپورٹ محدود ہو وہاں SMS OTP بیک اپ)؛ کمپنی نمائندگان کو 2FA آپٹ-ان کی پیشکش ہو گی، جس میں اسٹیپ-ایپ عملات (NFR-SEC-005) پر لازمی 2FA ہو گا۔ طریقۂ پیمائش۔ Keycloak پالیسی نافذی؛ ہفتہ وار تعمیل رپورٹ جو 2FA ان رولڈ کے بغیر کسی بھی اسٹاف اکاؤنٹ کی فہرست دیتی ہے۔ وجہ توجیہ۔ اسٹاف اکاؤنٹس کے پاس محکموں میں شہری PII تک استحقاق والی رسائی ہے؛ لازمی 2FA اسناد سمجھوتے کے خلاف بنیادی دفاع ہے۔

NFR-SEC-005 — حساس عملات کے لیے اسٹیپ-اپ تصدیق [M]

میٹرک / ہدف۔ حساس عملات — ایک VIP/رازدارانہ ٹکٹ بند کرنا، کوئی ریکارڈ حذف کرنا، حساس تجزیات ایکسپورٹ کرنا، بنیادی مجاز نمائندہ تبدیل کرنا، کوئی فیچر فلیگ تبدیل کرنا — اسٹیپ-اپ تصدیق (حالیہ دوبارہ تصدیق ≤ 5 منٹ، یا تازہ 2FA چیلنج) طلب کریں گے۔ طریقۂ پیمائش۔ ہر حساس روٹ پر CI ٹیسٹ یہ دعویٰ کرتا ہے کہ پرانا-سیشن درخواست ایک اسٹیپ-اپ چیلنج لوٹاتی ہے؛ سیکیورٹی جائزہ ہر ریلیز روٹ فہرست کی تصدیق کرتا ہے۔ وجہ توجیہ۔ اغوا شدہ اسٹاف سیشن کے اثر کے دائرے کو محدود کرتا ہے، خاص طور پر ناقابلِ واپس یا PII ایکسپورٹ کرنے والے عملات کے لیے۔

NFR-SEC-006 — رازوں کا انتظام — ریپو/امیجز میں کوئی راز نہیں [M]

میٹرک / ہدف۔ کوئی DB پاس ورڈ، API کلید، سائننگ کلید، یا فراہم کنندہ اسناد سورس کنٹرول، کنٹینر امیجز، بلڈ لاگز، یا ڈسک پر رن ٹائم env فائلوں میں نہیں ہوگی؛ تمام آغاز پر رازوں کے والٹ (HashiCorp Vault یا Server4Sale-انتظامی) سے حاصل کی جائیں گی۔ طریقۂ پیمائش۔ CI میں pre-commit راز سکینر (مثلاً، gitleaks/trufflehog)؛ رازوں کے لیے امیج اسکین؛ سہ ماہی والٹ-رسائی آڈٹ۔ وجہ توجیہ۔ حکومتی نظام میں اسناد لیکیج کی سب سے عام وجہ کو روکتا ہے۔

NFR-SEC-007 — لانچ سے قبل اور سالانہ نفوذ جانچ [M]

میٹرک / ہدف۔ عوامی لانچ سے قبل ایک آزادانہ بیرونی نفوذ ٹیسٹ مکمل ہو گا، اور اس کے بعد کم از کم سالانہ، اور کسی بھی سیکیورٹی-حساس تبدیلی کے بعد۔ اہم نتائج 30 دن کے اندر اصلاح؛ اعلیٰ 60 دن کے اندر۔ طریقۂ پیمائش۔ پین ٹیسٹ رپورٹ فائل پر؛ SLA والا فائنڈنگ-ٹریکر؛ مرحلہ گیٹ پر بندشد کا ثبوت جائزہ لیا جاتا ہے۔ وجہ توجیہ۔ ASVS L2 حالت اور CII رجسٹریشن (NFR-COMP-005) کے لیے آزاد توثیق درکار ہے۔

NFR-SEC-008 — ویب ایپلیکیشن فائر وال (WAF) [M]

میٹرک / ہدف۔ nginx API اور پورٹل کے سامنے OWASP Core Rule Set والا ایک WAF چلائے گا؛ رول-سیٹ کریٹیکلز پر ڈیفالٹ-ڈینی؛ ٹیوننگ استثنات ماہانہ جائزہ۔ طریقۂ پیمائش۔ WAF لاگ جائزہ؛ سہ ماہی غلط مثبت جائزہ؛ ModSecurity آڈٹ لاگ 90 دن برقرار۔ وجہ توجیہ۔ عام ویب حملوں کے خلاف پہلی لائن دفاع؛ ASVS سے چلائی گئی ایپ لیئر کنٹرولز کی تکمیل۔

NFR-SEC-009 — ریٹ لیمٹنگ [M]

میٹرک / ہدف۔ ریٹ لیمٹس فی صارف، فی IP، اور فی ٹیننٹ لاگ اِن/OTP اینڈ پوائنٹس (≤ 10/منٹ/IP)؛ ٹکٹ پیداوار (≤ 30/منٹ/صارف)؛ AI/OCR اینڈ پوائنٹس (≤ 20/منٹ/صارف)؛ سرچ (≤ 60/منٹ/صارف) پر لگائے جائیں گے۔ عوامی (غیر توثیق شدہ) اینڈ پوائنٹس زیادہ سختی سے تھروٹل۔ طریقۂ پیمائش۔ @nestjs/throttler کنفگ + nginx limit-req؛ تھروٹل درخواستوں کا Grafana پینل؛ اگر کوئی تھروٹل 1,000×/منٹ (ممکنہ استحصال) فائر ہو تو الرٹ۔ وجہ توجیہ۔ بروٹ فورس، اینیومریشن، اور وسائل کی کمی سے بچاتا ہے؛ NFR-USA-005 اعتماد-اور-حفاظت کی بنیاد رکھتا ہے۔

NFR-SEC-010 — محفوظ HTTP ہیڈرز [M]

میٹرک / ہدف۔ تمام جوابات Content-Security-Policy، Strict-Transport-Security، X-Content-Type-Options: nosniff، X-Frame-Options: DENY یا CSP frame-ancestors 'none'، Referrer-Policy: strict-origin-when-cross-origin، Permissions-Policy پابند اصول سیٹ کریں گے۔ طریقۂ پیمائش۔ Mozilla Observatory / observatory.mozilla.org ہدف A یا اس سے اعلیٰ؛ ہر ریلیز CI میں ہیڈر چیک۔ وجہ توجیہ۔ بنیادی براؤزر-لیئر ہارڈننگ؛ سستی اور اعلیٰ اثر۔

NFR-SEC-011 — انحصار / SCA اسکیننگ [M]

میٹرک / ہدف۔ تمام انحصار (npm، pip، کنٹینر بیس امیجز) ہر بلڈ اور راتانہ کے موقعے پر معلوم کمزوریوں (SCA) کے لیے اسکین کیے جائیں گے؛ پروڈکشن انحصار میں کریٹیکل CVEs (CVSS ≥ 9.0) 7 دن کے اندر، اعلیٰ (CVSS 7.0–8.9) 30 دن کے اندر اصلاح۔ طریقۂ پیمائش۔ CI میں ضم SCA ٹول (مثلاً، Dependabot / Snyk / Trivy)؛ شدت اور عمر کے لحاظ سے کھلے فائنڈنگز کا ڈیش بورڈ۔ وجہ توجیہ۔ زیادہ تر حقیقی دنیا کے حملے پرانے انحصار کے ذریعے ہوتے ہیں؛ مسلسل SCA کم از کم دہلیز ہے۔

NFR-SEC-012 — اپ لوڈ اینٹی میلویئر اسکین [M]

میٹرک / ہدف۔ ہر اپ لوڈ کردہ فائل ClamAV صاف لوٹنے تک قرنطین رکھی جائے گی؛ متاثر فائلیں الگ تھلگ، دیگر صارفین کو کبھی نظر نہ آئیں گی؛ آڈٹ واقع اٹھایا جائے گا؛ درخواست کنندہ کو ان-ایپ مطلع کیا جائے گا۔ عمومی رسائی کو صفر متاثر فائلیں جاری نہیں ہوں گی۔ طریقۂ پیمائش۔ ClamAV ورکر میٹرکس؛ اسٹیجنگ میں سہ ماہی سیڈڈ-EICAR ٹیسٹ؛ فائل-رسائی آڈٹ ٹریل چیک۔ وجہ توجیہ۔ اپ لوڈز میلویئر پھیلانے اور مواد انجیکشن کا بنیادی حملہ ویکٹر ہیں۔

NFR-SEC-013 — سیشن اور ٹوکن صفائی [M]

میٹرک / ہدف۔ رسائی ٹوکنز ≤ 15 منٹ لائف ٹائم؛ ریفریش ٹوکنز ≤ 7 دن استعمال پر روٹیشن کے ساتھ؛ توڑنا Redis ڈینی لسٹ میں ≤ 5 s میں پھیلا؛ اسٹاف UI کے لیے بیکار سیشن ٹائم آؤٹ ≤ 30 منٹ، شہری UI کے لیے ≤ 24 گھنٹے۔ طریقۂ پیمائش۔ Keycloak پالیسی + CI میں ٹوکن معائنہ ٹیسٹ؛ لاگ آؤٹ پر توڑنے کی تاخیر ٹیسٹ۔ وجہ توجیہ۔ چرائے ہوئے ٹوکن کی کھڑکی کو محدود کرتا ہے؛ حکومتی-سیشن اصول سے ہم آہنگ۔

3.5 رازداری / ڈیٹا تحفظ (PRIV)

SITP کمپنی نمائندگان اور حکومتی عملے کے ذاتی ڈیٹا، نیز خود مختار ڈیٹا (CNIC، NADRA پے لوڈز) پر عمل کرتا ہے۔ رازداری کی ذمہ داریاں سندھ حقِ معلومات (RTI) ایکٹ 2016 (جو عوامی معلومات تک رسائی کو منظم کرتا ہے) اور عام ڈیٹا-تحفظ اصولوں (کم سے کم، مقصد کی حد، سیکیورٹی، ریٹینشن) پر عمل کرتی ہیں۔ /specs/ur/11-security-compliance/ دیکھیں۔

NFR-PRIV-001 — ڈیٹا کم سے کم [M]

میٹرک / ہدف۔ ہر فارم اور API پے لوڈ صرف ان خانوں کا ڈیٹا اکٹھا کرے گا جو ایک دستاویزی کردہ مقصد سے جواز پیش کرتے ہیں؛ "اچھا ہو" والے خانے ڈیزائن جائزے میں نشان زد اور بغیر جواز کے ہٹا دیے جائیں گے۔ طریقۂ پیمائش۔ ہر فیچر کے لیے رازداری جائزہ (ڈیٹا-تحفظ-بذریعہ-ڈیزائن چیک لسٹ)؛ /specs/ur/05-data-model/ میں فی جدول فیلڈ انونٹری برقرار۔ وجہ توجیہ۔ ڈیٹا تحفظ کا پہلا اصول: جس کی ضرورت نہیں اسے اکٹھا نہ کریں۔

NFR-PRIV-002 — رضامندی اور ترجیح انتظام [M]

میٹرک / ہدف۔ ہر صارف کا ایک رضامندی اور ترجیح ریکارڈ ہوگا جو یہ ریکارڈ کرتا ہے: اطلاع چینل آپٹ-ان (ای میل/SMS/WhatsApp/ان-ایپ)، مارکیٹنگ/ڈائجسٹ آپٹ-ان (لی دین سے الگ)، اور زبان ترجیح۔ رضامندی ہر چینل پر ایک کلک میں واپس لی جا سکے گی۔ طریقۂ پیمائش۔ ترجیح-مرکز UI ٹیسٹ؛ رضامندی کی تبدیلیوں کا آڈٹ لاگ؛ آپٹ-آؤٹ شرحوں پر سہ ماہی رپورٹ۔ وجہ توجیہ۔ چینل رضامندی ایک بنیادی توقع ہے اور غیر اسپیمی اطلاعات کی پیش شرط۔

NFR-PRIV-003 — PII والٹنگ اور خفیہ کاری [M]

میٹرک / ہدف۔ PII خانے (CNIC، فون، ای میل، گھر کا پتہ، بائیو میٹرک جیسا ڈیٹا) کالم سطح پر خفیہ (باقی DB خفیہ کاری سے الگ) ہوں گے یا میزبان جدول میں ایک قابلِ واپس ٹوکن کے ساتھ ایک مخصوص PII والٹ جدول میں محفوظ؛ ڈکرپٹ تک رسائی کردار پر مبنی اور آڈٹ لاگ ہو گی۔ طریقۂ پیمائش۔ اسکیمہ جائزہ (دستاویز 05 §9 ڈیٹا-درجہ بندی)؛ کڑی آڈٹ لاگ تمام PII-ڈکرپٹ واقعات کی رپورٹ؛ پین ٹیسٹ تصدیق کرتا ہے کہ معیاری ڈمپس میں کوئی plaintext PII نہیں۔ وجہ توجیہ۔ DB ریڈ سمجھوتے کے اثر کے دائرے کو محدود کرتا ہے؛ NFR-SEC-003 کو سہارا دیتا ہے۔

NFR-PRIV-004 — مٹانے کا حق (ریٹینشن استثنات کے ساتھ) [S]

میٹرک / ہدف۔ ایک صارف اپنے ذاتی ڈیٹا کے مٹانے کی درخواست کر سکتا ہے؛ نظام 30 دن کے اندر عمل کرے گا، اس کے علاوہ جہاں ڈیٹا ایک قانونی ریٹینشن ذمہ داری (آڈٹ لاگ، ٹیکس ریکارڈز، جاری-ٹکٹ ثبوت، سندھ آرکائیوز اصول) کا تابع ہو — ایسی صورت میں ڈیٹا کم/گمنام کیا جائے گا اور استثنا ریکارڈ کیا جائے گا۔ طریقۂ پیمائش۔ ڈیٹا-سبجیکٹ-ریکوئسٹ (DSR) ورک فلو ٹیسٹ؛ سہ ماہی DSR رپورٹ؛ قانونی-استثنا لاگ۔ وجہ توجیہ۔ حکومتی-ریکارڈز ریٹینشن نظام کا احترام کرتے ہوئے عام ڈیٹا-تحفظ اصولوں سے ہم آہنگ۔

NFR-PRIV-005 — ڈیٹا درجہ بندی [M]

میٹرک / ہدف۔ ہر جدول اور ہر API فیلڈ چار ڈیٹا کلاسز میں سے ایک کے ساتھ ٹیگ ہوگا — عوامی / اندرونی / رازدارانہ / محدود — جو خفیہ کاری، رسائی، حذف و ترمیم، اور ریٹینشن رویے کو چلاتا ہے۔ لانچ پر کوئی بلا ٹیگ PII رکھنے والا کالم نہیں۔ طریقۂ پیمائش۔ /specs/ur/05-data-model/ §9 بمطابق اسکیمہ جائزہ؛ CI گیٹ وہ مائیگریشن مسترد کرتا ہے جو PII رکھنے والے جدول میں بلا ٹیگ text/JSON کالم شامل کرتا ہے۔ وجہ توجیہ۔ درجہ بندی ہر ڈاؤن سٹریم رازداری اور سیکیورٹی کنٹرول کی پیش شرط ہے۔

NFR-PRIV-006 — کسی بھی کلاؤڈ AI کال سے قبل PII حذف و ترمیم [M]

میٹرک / ہدف۔ کسی بھی پے لوڈ کو کلاؤڈ AI/OCR انجن کو بھیجنے سے قبل، PII آن-پریمس حذف و ترمیم لیئر کے ذریعے حذف کیا جائے گا؛ پالیسی/فیچر-فلیگ سلیکٹر Restricted ڈیٹا کلاسز (خام CNIC، NADRA پے لوڈز، رازدارانہ/VIP ٹکٹس) کے لیے کلاؤڈ انجنز ممنوع کرے گا۔ طریقۂ پیمائش۔ فی کال آڈٹ صف حذف و ترمیم شمار اور انجن ریکارڈ کرتا ہے؛ مصنوعی PII رکھنے والے کارپس کے ساتھ سہ ماہی حذف و ترمیم ٹیسٹ؛ CI میں سلیکٹر-پالیسی ٹیسٹ۔ وجہ توجیہ۔ خود مختار ڈیٹا قابلِ اعتماد حد سے باہر نہیں جانا چاہیے؛ کلاؤڈ انجنز صرف اجازت شدہ کلاسز کے لیے استعمال۔ /specs/ur/15-tech-architecture/ §6.2، §6.4 دیکھیں۔

NFR-PRIV-007 — ریٹینشن اور پرج شیڈول [M]

میٹرک / ہدف۔ ہر ڈیٹا کلاس کی ایک دستاویزی ریٹینشن مدت ہوگی؛ ختم شدہ ڈیٹا شیڈول بمطابق ورکر کے ذریعے پرج یا آرکائیو کیا جائے گا؛ presigned URLs ≤ 15 منٹ میں ختم ہوں؛ سافٹ-ڈیلیٹڈ ریکارڈز کلاس ریٹینشن کھڑکی کے بعد ہارڈ-پرج کیے جائیں گے۔ طریقۂ پیمائش۔ /specs/ur/11-security-compliance/ میں ریٹینشن شیڈول شائع؛ ماہانہ پرج-جاب کامیابی رپورٹ؛ سہ ماہی لنک-ختم ٹیسٹ۔ وجہ توجیہ۔ خطرے میں ڈیٹا کو محدود کرتا ہے؛ NFR-COMP ریکارڈز-انتظام ذمہ داریوں سے ہم آہنگ۔

NFR-PRIV-008 — حساس ڈیٹا کے لیے ڈیٹا رہائش (پاکستان) [M]

میٹرک / ہدف۔ تمام پروڈکشن ذاتی ڈیٹا اور خود مختار ڈیٹا پے لوڈز (CNIC، NADRA لوک اپس، ٹکٹ مواد) پاکستان کے اندر انفراسٹرکچر (Server4Sale) پر واقع ہوں گے؛ سرحد پار منتقلی صرف مجموعی، گمنام، یا PII-حذف شدہ پے لوڈز کے لیے اور صرف ان فراہم کنندگان کے لیے اجازت یافتہ ہے جن کے پاس دستاویزی ڈیٹا-پراسیسنگ شرائط ہوں۔ طریقۂ پیمائش۔ ہوسٹنگ-ٹوپولوجی جائزہ پاکستان رہائش کی تصدیق کرتا ہے؛ AI-انجن سلیکٹر پالیسی ہر ریلیز جائزہ؛ کسی بھی سرحد پار پروسیسر کے لیے فائل پر وینڈر DPA۔ وجہ توجیہ۔ شہری ڈیٹا خود مختاری کے لیے صوبائی/قومی توقع؛ NFR-COMP-004 کو سہارا دیتا ہے۔

3.6 بین الاقوامیت (I18N)

SITP تین زبانیں پیش کرتا ہے — انگریزی (master/سورس)، اردو، سندھی — اردو اور سندھی کے لیے RTL کے ساتھ، اور دوہرا گریگوری + ہجری کیلنڈر۔ /specs/ur/09-i18n-localization/ دیکھیں۔

NFR-I18N-001 — تین زبانیں، مکمل مساوات [M]

میٹرک / ہدف۔ پورٹل اور دستاویزات سائٹ کی 100 % صارف رخ اسٹرنگز لانچ پر EN، UR، اور سندھی میں ترجمہ اور شائع کی جائیں گی؛ V1 صارف سفر میں کوئی غیر ترجمہ شدہ اسٹرنگ نہیں۔ طریقۂ پیمائش۔ اسٹرنگ کیٹلاگز پر CI چیک: EN میں موجود ہر کلید UR اور SD میں موجود ہونی چاہیے؛ ریلیز سے قبل ترجمہ-مکمل رپورٹ۔ وجہ توجیہ۔ سندھی اور اردو قانونی-صوبائی زبانیں ہیں؛ جزوی ترجمہ پروڈکٹ مشن کو کمزور کرتا ہے۔

NFR-I18N-002 — دائیں سے بائیں (RTL) سہارا [M]

میٹرک / ہدف۔ جب صارف لوکیل UR یا SD ہو تو پورٹل اور دستاویزات سائٹ مکمل طور پر RTL میں رینڈر ہوں گی؛ لے آؤٹ logical CSS properties (padding-inline-start وغیرہ) استعمال کرے گا تاکہ ایک ہی کمپوننٹ درخت دونوں سمتوں کو سہارا دے؛ کوئی ان لائن سمت ہیکس نہیں۔ طریقۂ پیمائش۔ سرفہرست 20 پیجز پر LTR اور RTL دونوں کے لیے بصری ریگریشن ٹیسٹ؛ ہر ریلیز RTL جائزہ۔ وجہ توجیہ۔ RTL سندھی/اردو قارئین کے لیے بنیادی قابلِ رسائی اور استعمال پذیری کا تقاضا ہے۔

NFR-I18N-003 — کوئی ہارڈ کوڈڈ صارف رخ اسٹرنگ نہیں [M]

میٹرک / ہدف۔ سورس میں صفر ہارڈ کوڈڈ صارف رخ اسٹرنگز؛ تمام اسٹرنگز لوکیل کیٹلاگز میں externalized؛ صارف رخ کمپوننٹ میں ہارڈ کوڈڈ اسٹرنگ پر CI گیٹ بلڈ فیل کرتا ہے۔ طریقۂ پیمائش۔ CI میں Lint رول (مثلاً، eslint-plugin-react-intl یا مماثل)۔ وجہ توجیہ۔ ہارڈ کوڈڈ اسٹرنگز نامکمل ترجموں کی سرِ فہرست وجہ ہیں۔

NFR-I18N-004 — فی صارف لوکیل، ہر جگہ پھیلا ہوا [M]

میٹرک / ہدف۔ ہر صارف کے اکاؤنٹ پر ایک locale (EN/UR/SD) محفوظ ہوگا، JWT اور ہر جاب پے لوڈ میں پھیلا ہوا، اور ٹیمپلیٹس، سرچ رینکنگ، AI ترجمہ، تاریخوں، اور اعداد پر لاگو۔ طریقۂ پیمائش۔ فن تعمیر جائزہ (/specs/ur/15-tech-architecture/ §15 بمطابق)؛ لوکیل UR سیٹ کرنے والا اینڈ-ٹو-اینڈ ٹیسٹ اور تصدیق کہ اطلاعاتی ای میلز + AI خلاصے UR میں آ رہے ہیں۔ وجہ توجیہ۔ لوکیل کو دوبارہ اشارہ طلب نہیں ہونا چاہیے؛ ایک مستند ماخذ ہر ڈاؤن سٹریم رینڈرنگ انتخاب کو چلاتا ہے۔

NFR-I18N-005 — دوہرا گریگوری + ہجری کیلنڈر [M]

میٹرک / ہدف۔ تمام صارف رخ تاریخیں دونوں گریگوری اور ہجری شکلوں میں (حکومتی رواج) ظاہر ہوں گی؛ اسٹوریج ہمیشہ UTC گریگوری ہے، ہجری پیشکش پر اخذ؛ تاریخ/عدد فارمیٹنگ لوکیل-آگاہ (PKR کرنسی، اردو/سندھی ہندسے اختیاری)۔ طریقۂ پیمائش۔ تاریخ رکھنے والے اسکرینوں کی نمائندہ نمونے (ٹکٹ فہرست، MoM، خطوط) پر UI ٹیسٹ؛ کیلنڈر ویجیٹ دونوں رینڈر کرتا ہے۔ وجہ توجیہ۔ حکومتی خطوط اور سرکاری ریکارڈز روایتاً دونوں کیلنڈرز کا حوالہ دیتے ہیں۔

NFR-I18N-006 — لغات کی مستقل مزاجی [M]

میٹرک / ہدف۔ تمام UR اور SD ترجمے _glossary.md سے منظور شدہ اصطلاحات استعمال کریں گے؛ AI ترجمہ (صلاحیت #6) کو لغت انجیکشن پابندیوں کے طور پر موصول ہوگی۔ طریقۂ پیمائش۔ ترجمہ فائلوں پر CI لغات-تعمیل چیک؛ لغات ڈرفٹ کا سہ ماہی جائزہ کار آڈٹ؛ لغات اضافات ٹریک۔ وجہ توجیہ۔ ڈومین اصطلاحات کا غیر مستقل ترجمہ (مثلاً، "ٹکٹ" بمقابلہ "شکایت" بمقابلہ "درخواست") صارف کے اعتماد اور سرچ کو کمزور کرتا ہے۔

3.7 قابلِ رسائی (A11Y)

قابلِ رسائی ایک حکومتی سروس کے لیے قانونی-متعلق ہے اور _context.md §2 میں ایک مقفل فیصلہ ہے: تینوں زبانوں میں WCAG 2.1 AA۔

NFR-A11Y-001 — WCAG 2.1 AA تعمیل [M]

میٹرک / ہدف۔ پورٹل اور دستاویزات سائٹ لانچ پر WCAG 2.1 Level AA کے مطابق ہوں گی؛ سرفہرست 20 پیجز پر (خودکار + دستی آڈٹ بمطابق) صفر اہم خلاف ورزیاں۔ طریقۂ پیمائش۔ CI میں فی پیج خودکار axe/pa11y؛ اسکرین ریڈرز (Windows پر NVDA، iOS پر VoiceOver) استعمال کرتے ہوئے نمائندہ نمونے پر ہر ریلیز دستی آڈٹ۔ وجہ توجیہ۔ قابلِ رسائی ایک عوامی سروس نظام کے لیے بنیادی ذمہ داری ہے، کوئی بہتری نہیں۔

NFR-A11Y-002 — اسکرین ریڈر سہارا [M]

میٹرک / ہدف۔ تمام انٹرایکٹو عناصر NVDA + Firefox، JAWS + Edge، VoiceOver + Safari/iOS، اور TalkBack + Android کے ساتھ چلنے کے قابل ہوں گے؛ ڈائنامک علاقوں (ٹکٹ تھریڈز، ڈیش بورڈز، چیٹ) پر ARIA سیمانٹکس درست۔ طریقۂ پیمائش۔ اہم صارف سفر پر ہر ریلیز اسکرین ریڈر ٹیسٹ؛ خامیوں کی فہرست شدت کے لحاظ سے ٹریج۔ وجہ توجیہ۔ اسکرین ریڈر صارفین AA تعمیل کے بنیادی فائدہ اٹھانے والے ہیں۔

NFR-A11Y-003 — مکمل کی بورڈ نیویگیشن [M]

میٹرک / ہدف۔ 100 % افعال کی بورڈ سے ایک نمایاں فوکس انڈیکیٹر کے ساتھ چلنے کے قابل ہوں گے؛ منطقی ٹیب ترتیب؛ کوئی کی بورڈ جال نہیں؛ ہر پیج پر skip-to-content لنک۔ طریقۂ پیمائش۔ ہر ریلیز صرف-کی بورڈ واک تھرو؛ فوکس انتظام پر CI چیک۔ وجہ توجیہ۔ کی بورڈ قابلِ عمل WCAG 2.1 AA (Level A + AA) ہے اور بہت سی معاون ٹیکنالوجیز کی پیش شرط۔

NFR-A11Y-004 — رنگ تضاد [M]

میٹرک / ہدف۔ متن تضاد اپنی پس منظر کے بمقابلہ، تینوں زبان تھیمز میں (بشمول Ajrak سے متاثر نیلے/ مارون پیلٹ — /specs/ur/16-branding-design-system/ دیکھیں)، عام متن کے لیے 4.5:1 اور بڑے متن کے لیے 3:1 پورا کرے گا۔ طریقۂ پیمائش۔ CI میں فی کمپوننٹ خودکار تضاد چیک؛ برانڈ پیلٹ ٹوکنز کا دستی جائزہ۔ وجہ توجیہ۔ WCAG AA کے ذریعے مطلوب؛ Ajrak پیلٹ کو پاس کرنے کے لیے جان بوجھ کر ٹوکن انتخاب درکار۔

NFR-A11Y-005 — سائن لینگویج ویڈیو (مرحلہ 2) [C]

میٹرک / ہدف۔ سرفہرست 5 مدد موضوعات اور بنیادی داخل کرنے کے سفر کے لیے پاکستان سائن لینگویج (PSL) سائن-ویڈیو رہنمائیں مرحلہ 2 میں دستیاب ہوں گی۔ طریقۂ پیمائش۔ مرحلہ-2 ریلیز گیٹ؛ سائن-لینگویج کنسلٹنٹ کے ذریعے مواد جائزہ۔ وجہ توجیہ۔ بہرے شہریوں کی مدد کرتا ہے؛ مواد-پیداوار گنجائش سے ہم آہنگی کے لیے مرحلہ 2 میں ملتوی۔

NFR-A11Y-006 — وائس نیویگیشن اور ڈسلیکسیا-دوست موڈ (مرحلہ 2) [C]

میٹرک / ہدف۔ ایک ڈسلیکسیا-دوست موڈ (فونٹ، فاصلیں، لائن-ہائٹ ٹوگل) اور سرفہرست صارف سفر کے لیے وائس نیویگیشن مرحلہ 2 میں دستیاب ہو گی۔ طریقۂ پیمائش۔ مرحلہ-2 ریلیز گیٹ؛ نمائندہ صارفین کے ساتھ استعمال پذیری ٹیسٹ۔ وجہ توجیہ۔ AA بنیاد سے آگے شاملانہ ڈیزائن؛ مرحلہ 2 میں ملتوی۔

3.8 استعمال پذیری (USA)

استعمال پذیری کے اہداف شہری اور اسٹاف تجربات کو کم رکاوٹ اور مستقل رکھتے ہیں۔ /specs/ur/10-ux-sitemap-flows/ سے حوالہ دیتے ہیں۔

NFR-USA-001 — کمپنی سفر کے لیے تین-کلک اصول [M]

میٹرک / ہدف۔ پورٹل پر اترنے سے، ایک توثیق شدہ کمپنی نمائندہ ٹکٹ-داخل-کرنے کے فارم، میرے-ٹکٹس-ٹریک فہرست، اور KB سرچ تک ≤ 3 کلکس میں پہنچے گا۔ طریقۂ پیمائش۔ ہر زبان میں ہوم پیج پر ہر ریلیز کلک-پاتھ ٹیسٹ؛ UX جائزہ سائن آف۔ وجہ توجیہ۔ سب سے اہم شہری سفر پر چھوٹنے کو کم کرتا ہے؛ CPGRAMS/PCP کے بمقابلہ benchmark۔

NFR-USA-002 — کردار سکوپڈ ڈیش بورڈز [M]

میٹرک / ہدف۔ 7 کرداروں (شہری/کمپنی نمائندہ، فائلر، بنیادی نمائندہ، سیکشن عملہ، محکمہ سربراہ، DG/سیکریٹری، سپر ایڈمن، نیز عوامی شفافیت ڈیش بورڈ) میں سے ہر ایک کا ایک ڈیش بورڈ ہوگا جو صرف کردار-متعلق معلومات اور عملات کو ظاہر کرتا ہے؛ کوئی کراس-کردار ڈیٹا لیکیج نہیں۔ طریقۂ پیمائش۔ ہر ریلیز RBAC + ڈیش بورڈ جائزہ؛ /specs/ur/04-roles-permissions/ میں اجازت میٹرکس کے بمقابلہ فی کردار UI ٹیسٹ۔ وجہ توجیہ۔ معلومات کا بوجھ اور زیادہ وسیع رسائی اسٹاف-UX کی دو سب سے بڑی ناکامی حالتیں ہیں۔

NFR-USA-003 — ترقی یافتہ انکشاف [S]

میٹرک / ہدف۔ فارمز اور تفصیلی مناظر ترقی یافتہ انکشاف استعمال کریں گے (اعلی درجے کے اختیارات بطور ڈیفالٹ فولڈڈ؛ شاذ و نادر استعمال ہونے والے عملات "More" کے پیچھے)؛ ڈیفالٹ منظر سب سے چھوٹا مکمل راستہ دکھاتا ہے۔ طریقۂ پیمائش۔ ہر ریلیز UX heuristic جائزہ؛ فیلڈ-استعمال اینالٹکس دکھاتے ہیں کہ فولڈڈ فیلڈز < 20 % جمع کرنے والوں کے استعمال ہوتی ہیں۔ وجہ توجیہ۔ پہلی بار فائلرز کے لیے ذہنی بوجھ کم کرتا ہے؛ اعلیٰ درجے کے صارفین پھر بھی مکمل صلاحیت تک پہنچتے ہیں۔

NFR-USA-004 — مستقل ڈیزائن نظام [M]

میٹرک / ہدف۔ تمام UI SITP ڈیزائن نظام (shadcn/ui + /specs/ur/16-branding-design-system/ سے برانڈ ٹوکنز) سے بنایا جائے گا؛ کسی بھی پیج میں ≥ 95 % کمپوننٹس نظام لائبریری سے آئیں گے، ون-آف لاگو نہیں۔ طریقۂ پیمائش۔ CI میں کمپوننٹ-استعمال lint؛ سہ ماہی ڈیزائن-نظام ڈرفٹ آڈٹ۔ وجہ توجیہ۔ مستقل مزاجی محسوس معیار، قابلِ رسائی، اور صیانت کی لاگت کو چلاتی ہے۔

NFR-USA-005 — موبائل-پہلے ریسپانسو + PWA آف لائن داخلہ [M]

میٹرک / ہدف۔ پورٹل موبائل-پہلے ریسپانسو (320 px → 1920 px بریک پوائنٹس ٹیسٹ شدہ) ہوگا اور فیلڈ-انٹیک بہاؤ (بعد میں محفوظ کے ساتھ آف لائن ڈرافٹ ٹکٹس) ایک PWA آف لائن کے طور پر کام کرے گا: ڈرافٹس مقامی طور پر برقرار رہتے ہیں اور دوبارہ منسلک ہونے پر sync ہوتے ہیں۔ طریقۂ پیمائش۔ حقیقی ڈیوائسز پر ہر ریلیز ریسپانسو ٹیسٹ؛ آف لائن-موڈ ٹیسٹ (ایئرپلین موڈ → ڈرافٹ → دوبارہ منسلک → sync)۔ وجہ توجیہ۔ موبائل بنیادی شہری ڈیوائس ہے؛ آف لائن داخلہ غیر قابلِ اعتماد نیٹ ورکس پر عملے اور شہریوں کو سہارا دیتا ہے۔

NFR-USA-006 — نظام استعمال پذیری پیمانہ (SUS) بنیاد [S]

میٹرک / ہدف۔ ہر زبان میں نمائندہ صارفین کے ساتھ لانچ بعد کی استعمال پذیری ٹیسٹنگ ایک System Usability Scale (SUS) اسکور ≥ 70 (صنعت کی "قابلِ قبول" دہلیز) حاصل کرے گی۔ طریقۂ پیمائش۔ مرحلہ-1 اختتام اور سالانہ پر فی کردار فی زبان n ≥ 8 کے ساتھ moderated استعمال پذیری ٹیسٹ۔ وجہ توجیہ۔ ایک قابلِ پیمائش، قابلِ موازنہ استعمال پذیری benchmark، صرف heuristic نہیں۔

3.9 قابلیتِ صیانت (MAINT)

قابلیتِ صیانت PPP ڈیلیوری ماڈل کی حفاظت کرتی ہے: MAAHIR (اور کوئی بھی جانشین) کو معاہدے کے لائف سائیکل میں نظام کو بڑھانا اور چلانا ہوگا۔ /specs/ur/15-tech-architecture/ §1 (ماڈیولر مونولتھ) اور §4 (ماڈیول میپ) دیکھیں۔

NFR-MAINT-001 — ماڈیولر مونولتھ ساخت [M]

میٹرک / ہدف۔ NestJS تعیناتی ایک ماڈیولر مونولتھ ہوگی جس میں مضبوط حد بند ماڈیولز ہوں گے؛ کراس-ماڈیول رسائی ایک ماڈیول کی شائع شدہ انٹرفیس کے ذریعے ہوگی، اس کی اندرونی سروسز/ٹیبلز سے نہیں۔ کوئی چکر دار ماڈیول انحصار نہیں۔ طریقۂ پیمائش۔ CI میں فن تعمیر lint (مثلاً، dependency-cruiser / Madge)؛ ماڈیول-حد خلاف ورزیاں بلڈ فیل کرتی ہیں۔ وجہ توجیہ۔ کسی بھی ماڈیول کو بعد میں مائکرو سروس میں نکالنے کا انتخاب محفوظ رکھتا ہے (دستاویز 15 §1)؛ PPP ایگزٹ/ہینڈ اوور کی لاگت کم کرتا ہے۔

NFR-MAINT-002 — ٹیسٹ کورج [M]

میٹرک / ہدف۔ خودکار ٹیسٹ کورج لانچ پر NestJS API اور FastAPI AI سروس کے لیے ≥ 70 % لائن اور ≥ 60 % برانچ ہوگا، ہر ریلیز پر برقرار؛ اہم راستے (تصدیق، ٹکٹ لائف سائیکل، آڈٹ، فائلیں) ≥ 80 % لائن۔ طریقۂ پیمائش۔ پل ریکوئسٹ پر CI میں کورج گیٹ؛ ہر بلڈ پر شائع شدہ کورج رپورٹ۔ وجہ توجیہ۔ کورج فرش بار بار ڈیپلائز کے لیے بنیادی حفاظتی جال ہے؛ اہم راستے اعلیٰ دہلیز کے مستحق ہیں۔

NFR-MAINT-003 — لازمی کوڈ جائزہ + lint + typecheck گیٹس [M]

میٹرک / ہدف۔ کوئی کوڈ main تک (a) کم از کم ایک منظور جائزہ، (b) سبز lint، (c) سبز typecheck، (d) سبز یونٹ ٹیسٹس، (e) سبز SCA اسکین کے بغیر نہیں پہنچتا۔ برانچ پروٹیکشن تمام پانچوں کو نافذ کرتا ہے۔ طریقۂ پیمائش۔ برانچ-پروٹیکشن کنفگ آڈٹ؛ PR ریکارڈ میں مرج کا ثبوت۔ وجہ توجیہ۔ عمل-سطح کا محافظ جو ہر دوسرے معیار خصوصیت کی ضمانت دیتا ہے۔

NFR-MAINT-004 — دستاویزی APIs (OpenAPI) [M]

میٹرک / ہدف۔ 100 % عوامی REST اینڈ پوائنٹس کوڈ سے پیدا کردہ OpenAPI 3.x spec میں دستاویزی ہوں گے؛ spec /api/openapi.json پر شائع اور /api/docs پر رینڈر؛ مثالیں اور ایرر جوابات شامل۔ طریقۂ پیمائش۔ CI چیک کہ ہر کنٹرولر روٹ کے پاس OpenAPI میٹا ڈیٹا ہے؛ بریکنگ تبدیلیوں پر spec-diff گیٹ (NFR-INTER-004 بمطابق)۔ وجہ توجیہ۔ API پارٹنرز، موبائل ایپ، اور Metabase کے ساتھ ایک کنٹریکٹ ہے؛ دستاویزی APIs ایک API-پہلے نظام کے لیے ناقابلِ بحث ہیں۔

NFR-MAINT-005 — i18n اسٹرنگ externalization [M]

میٹرک / ہدف۔ تمام صارف رخ اسٹرنگز (پورٹل، دستاویزات، اطلاعات، ای میلز، SMS، WhatsApp ٹیمپلیٹس، خطوط) لوکیل کیٹلاگز میں externalized ہوں گے؛ CI ہارڈ کوڈڈ صارف رخ اسٹرنگ والی بلڈ مسترد کرتا ہے (NFR-I18N-003 کا عکس، بطور قابلیتِ صیانت گیٹ دہراتا ہے)۔ طریقۂ پیمائش۔ CI میں Lint رول؛ ہر ریلیز کیٹلاگ-مکمل رپورٹ۔ وجہ توجیہ۔ externalization کوڈ کی تبدیلی کے بغیر چوتھی زبان شامل کرنے کی پیش شرط ہے۔

NFR-MAINT-006 — بحالی مشقیں (DR مشق) [M]

میٹرک / ہدف۔ ایک مکمل بحالی مشق کم از کم سہ ماہی انجام دی جائے گی، جو MariaDB، MinIO، اور Keycloak کو ایک الگ ماحول میں بحال اور checksums تصدیق کرتی ہے؛ نتائج DR ران بک سے منسلک۔ طریقۂ پیمائش۔ فی سہ ماہی مشق ریکارڈ؛ checksum رپورٹ؛ خلا فہرست ٹریک۔ وجہ توجیہ۔ غیر ٹیسٹ شدہ بیک اپس محض دکھاوا ہیں؛ سہ ماہی مشقیں NFR-AVAIL-004/005 کی توثیق کرتی ہیں۔

NFR-MAINT-007 — کوڈ-کمنٹ اور ران بک تازگی [S]

میٹرک / ہدف۔ ہر ماڈیول کے فائل کے شروع میں مقصد کمنٹ ہوگا؛ ہر عملی طریقہ (ڈیپلائے، رول بیک، بحالی، واقعہ) کا ایک ران بک کم از کم سالانہ اور کسی بھی متعلقہ تبدیلی کے بعد جائزہ ہوگا۔ طریقۂ پیمائش۔ سالانہ دستاویز-تازگی آڈٹ؛ ران بک آخری-اپ ڈیٹ شدہ تاریخ ٹریک۔ وجہ توجیہ۔ علم کی منتقلی ایک بنیادی PPP ایگزٹ تحفظ ہے۔

3.10 مشاہدہ پذیری (OBS)

مشاہدہ پذیری پہلے دن سے جڑی ہوئی ہے — بعد میں جوڑی نہیں (دستاویز 15 §1، §18)۔ یہاں اہداف قابلِ پیمائش طور پر "قابلِ مشاہدہ" کا مطمئن define کرتے ہیں۔

NFR-OBS-001 — مرکز شدہ ساختی لاگنگ [M]

میٹرک / ہدف۔ تمام سروسز Loki کو بھیجی جانے والی ساختی JSON لاگز خارج کریں گی؛ ہر لاگ اندراج trace_id، user_id (جہاں قابلِ اطلاق)، module، level، اور timestamp رکھتا ہے؛ PII کبھی لاگ نہیں (حذف و ترمیم نافذ)۔ طریقۂ پیمائش۔ CI میں لاگ-اسکیما validator؛ ہر ریلیز Loki کڑی نمونہ؛ سہ ماہی لاگز-میں-PII اسکین۔ وجہ توجیہ۔ ساختی، باہم جڑی لاگز واقعہ تشخیص اور آڈٹ فرانزکس کی بنیاد ہیں۔

NFR-OBS-002 — میٹرکس + ڈیش بورڈز [M]

میٹرک / ہدف۔ Grafana ڈیش بورڈز یہ cover کریں گے: API تاخیر/تھرو پٹ/ایرر-ریٹ، DB کڑی تاخیر + سلو کڑیاں، Redis/قطار گہرائیاں، AI/OCR جاب دورانیے، اطلاع ترسیل شرحیں، لاگ اِن/2FA واقعات، اور فی سروس چار سنہری سگنلز (تاخیر، ٹریفک، ایررز، سیچوریشن)۔ طریقۂ پیمائش۔ ہر مرحلہ گیٹ پر ڈیش بورڈ-انونٹری جائزہ؛ الرٹ وائرنگ ٹیسٹ۔ وجہ توجیہ۔ "اگر یہ ڈیش بورڈ پر نہیں ہے، تو یہ موجود نہیں ہے" — عملی مرئیت بنیاد۔

NFR-OBS-003 — تقسیم شدہ ٹریسنگ [M]

میٹرک / ہدف۔ OpenTelemetry ٹریسز NestJS API → BullMQ ورکرز → FastAPI AI سروس → بیرونی ایڈاپٹرز پر پھیلیں گے، جس میں propagating trace_id ہوگا تاکہ ایک ہی صارف عمل اینڈ-ٹو-اینڈ trace ہو سکے۔ نمونہ ریٹ قابلِ ترتیب؛ ایرر پاتھس کے لیے 100 %۔ طریقۂ پیمائش۔ اسٹیجنگ میں ٹریس-مکمل ٹیسٹ: ایک نمائندہ ٹکٹ-داخل عمل تمام سطحوں میں ایک ہی جڑی ٹریس پیدا کرتا ہے۔ وجہ توجیہ۔ اینڈ-ٹو-اینڈ ٹریسنگ ایک کثیر-سطح غیر ہم وقت نظام میں تاخیر کی تشخیص کا واحد طریقہ ہے۔

NFR-OBS-004 — ایرر ٹریکنگ + الرٹنگ [M]

میٹرک / ہدف۔ Sentry (یا مماثل) ریلیز ہیلتھ + سورس میپس کے ساتھ کلائنٹ- اور سرور-سائیڈ ایررز کو پکڑے گا؛ پیج-لوڈ ایرر ریٹ ≤ 1 %؛ غیر سنبھالے گئے سرور استثنات آن-کال کو 5 منٹ کے اندر پیج کیے جائیں گے؛ الرٹ شور ماہانہ جائزہ (ہدف: < 10 الرٹس/دن، > 90 % قابلِ عمل)۔ طریقۂ پیمائش۔ Sentry ڈیش بورڈ؛ آن-کال پیجنگ لاگ؛ ماہانہ الرٹ-ٹیوننگ جائزہ۔ وجہ توجیہ۔ نمایاں ایررز + کم-شور الرٹنگ قابلِ تسلسل آن-کال کی پیش شرط ہیں۔

NFR-OBS-005 — عوامی اسٹیٹس پیج + اپ ٹائم پروبز [M]

میٹرک / ہدف۔ ایک عوامی اسٹیٹس پیج پورٹل، API، دستاویزات سائٹ، AI/OCR، اور اطلاع-چینل ہیلتھ رپورٹ کرے گی، 1-منٹ کیڈنس پر اپ ڈیٹ؛ واقعہ مواصلات اعلان کے 15 منٹ کے اندر شائع۔ طریقۂ پیمائش۔ اسٹیٹس-پیج اپ ٹائم رپورٹ؛ مواصلاتی وقتداری کا واقعہ-پوسٹ مارٹم جائزہ۔ وجہ توجیہ۔ عوامی اعتماد نمایاں، دیانتدار اسٹیٹس رپورٹنگ پر منحصر ہے۔

NFR-OBS-006 — correlation IDs اینڈ-ٹو-اینڈ [M]

میٹرک / ہدف۔ ہر آنے والی درخواست کو ایج (nginx) پر ایک trace_id تفویض ہوگا، جو ہر سروس کال، ہر BullMQ جاب، ہر باہر روانہ انٹیگریشن کال میں پھیلا ہوا، اور ہر اطلاع میٹا ڈیٹا میں شامل ہوگا۔ trace_id صارف کو ایک سہارا حوالہ کے طور پر لوٹایا جائے گا۔ طریقۂ پیمائش۔ ہر ریلیز ایک مصنوعی اینڈ-ٹو-اینڈ ٹیسٹ سے تصدیق جو دعویٰ کرتا ہے کہ ایک ہی trace_id nginx لاگ، API لاگ، ورکر لاگ، AI-سروس لاگ، انٹیگریشن-کال ریکارڈ، اور آڈٹ صف میں ظاہر ہوتا ہے۔ وجہ توجیہ۔ correlation IDs کے بغیر، شہری سہارا کڑیاں ("میرا ٹکٹ داخل نہیں ہوا") کی تشخیص ممکن نہیں۔

NFR-OBS-007 — AI استعمال میں آڈٹ مرئیت [M]

میٹرک / ہدف۔ ہر AI/OCR کال ایک غیر قابلِ تبدیلی آڈٹ صف پیدا کرے گی جو انجن، فیچر، حساسیت کلاس، حذف و ترمیم شمار، تاخیر، ٹوکن/لاگت، اور نتیجہ ریکارڈ کرتا ہے؛ ایک Grafana پینل AI خرچ، ایرر ریٹ، اور انجن میکس ٹریک کرتا ہے۔ طریقۂ پیمائش۔ CI میں AI-آڈٹ صف مکمل ٹیسٹ؛ ماہانہ AI-خرچ رپورٹ۔ وجہ توجیہ۔ AI خرچ گورننس اور جوابدہی کے لیے کال-سطح مرئیت درکار ہے۔

3.11 قابلِ اعتمادی / مضبوطی (RELY)

قابلِ اعتمادی کے اہداف یہ یقینی بناتے ہیں کہ جب بیرونی انحصار (NADRA، SECP، FBR، SRB، PSEB، e-Office، Mailjet، SMS، WhatsApp، AI فراہم کنندگان) غلط برتاؤ کریں تو نظام قابلِ پیش بین طریقے سے تنزل کرے۔ /specs/ur/15-tech-architecture/ §13 سے حوالہ دیتے ہیں۔

NFR-RELY-001 — تیسرے فریق کی بندیشوں کا بہترین برتاؤ [M]

میٹرک / ہدف۔ ہر بیرونی انٹیگریشن کے لیے، ایک بندش کا نتیجہ (a) منحصر عمل قطار میں یا صریح صارف پیغام کے ساتھ ناکام، (b) صفر غیر سنبھالے استثنات، (c) صفر ڈیٹا خرابی، (d) انٹیگریشن واپس آنے پر خودکار بحالی ہوگا۔ طریقۂ پیمائش۔ فی ایڈاپٹر ہر ریلیز فالٹ-انجیکشن ٹیسٹ (اپ سٹریم ماریں، راستہ استعمال کریں، بحال کریں)۔ وجہ توجیہ۔ بیرونی نظام SITP کے کنٹرول سے باہر ہیں لیکن شہری تجربے کے اندر ہیں۔

NFR-RELY-002 — exponential backoff + jitter کے ساتھ دوبارہ کوششیں [M]

میٹرک / ہدف۔ ہر باہر روانہ انٹیگریشن کال فی ایڈاپٹر قابلِ ترتیب زیادہ سے زیادہ کوششوں (ڈیفالٹ 5) کے ساتھ exponential backoff + jitter پر دوبارہ کوشش کرے گی، پھر dead-letter؛ دوبارہ کوششیں کبھی دگنا رائٹ نہیں کرتیں (idempotency keys، NFR-RELY-005)۔ طریقۂ پیمائش۔ فی ایڈاپٹر retry-policy یونٹ ٹیسٹ؛ dead-letter قطار مانیٹر + الرٹ۔ وجہ توجیہ۔ عارضی-ناکامی لچک کے لیے معیاری پیٹرن؛ thundering-herd خطرے کو محدود کرتا ہے۔

NFR-RELY-003 — فی ایڈاپٹر سرکٹ بریکرز [M]

میٹرک / ہدف۔ ہر انٹیگریشن ایڈاپٹر کے سامنے ایک سرکٹ بریکر (مثلاً، Opossum) ہوگا جو ایک قابلِ ترتیب ناکامی دہلیز (ڈیفالٹ مسلسل 5 ناکامیاں / 30 s میں 50 %) کے بعد کھلتا ہے اور ایک cooldown (ڈیفالٹ 30 s) کے بعد half-open پروب کرتا ہے۔ طریقۂ پیمائش۔ Grafana میں فی ایڈاپٹر سرکٹ-اسٹیٹ میٹرکس؛ اسٹیجنگ میں سہ ماہی بریکر ٹیسٹ۔ وجہ توجیہ۔ ایک ہی ناکام انحصار کے وسائل کی کمی میں cascade ہونے سے روکتا ہے۔

NFR-RELY-004 — idempotent رائٹس [M]

میٹرک / ہدف۔ ہر سٹیٹ تبدیل کرنے والا API اینڈ پوائنٹ اور ہر باہر روانہ انٹیگریشن کال ایک کلائنٹ-فراہم کردہ یا پیدا کردہ idempotency کلید کے تحت idempotent ہوگا؛ دوبارہ کوششیں (نیٹ ورک، صارف کا دہرا کلک، ورکر دوبارہ ترسیل) کبھی دہرا سٹیٹ پیدا نہیں کرتیں۔ طریقۂ پیمائش۔ CI میں فی-اینڈ پوائنٹ idempotency ٹیسٹ (ایک ہی پے لوڈ + کلید دو بار → ایک ہی نتیجہ، ایک رائٹ)۔ وجہ توجیہ۔ idempotenty وہ بنیاد ہے جو دوبارہ کوششوں کو محفوظ بناتی ہے (NFR-RELY-002)۔

NFR-RELY-005 — قطار پائداری [M]

میٹرک / ہدف۔ BullMQ قطاریں پائدار ہوں گی (Redis AOF persistence فعال، دستاویز 15 §3 بمطابق)؛ ورکر یا Redis ری اسٹارٹ قطار میں شویہ جابز کھو نہیں دے گا؛ جابز صرف کامیاب تکمیل یا dead-lettering کے بعد acknowledge ہوں گے۔ طریقۂ پیمائش۔ سہ ماہی chaos ٹیسٹ: N جابز قطار میں ڈالیں، Redis + ورکرز ری اسٹارٹ کریں، دعویٰ کریں کہ تمام N مکمل یا dead-lettered، کوئی ضائع نہیں۔ وجہ توجیہ۔ قطار پائداری وہ ہے جو غیر ہم وقت OCR/AI/اطلاع کام کو محفوظ بناتی ہے۔

NFR-RELY-006 — ڈیٹا بیس لین دین کی سالمیت [M]

میٹرک / ہدف۔ ملٹی-ایگریگیٹ ڈومین عملات صریح MariaDB transactions استعمال کریں گے؛ طویل چلنے والا کام DB transaction سے باہر منتقل کیا جائے گا (transaction کے اندر قطار میں ڈالیں، commit کے بعد کام کریں) تاکہ row-lock ڈویل محدود رہے۔ طریقۂ پیمائش۔ فی فیچر فن تعمیر جائزہ؛ پرفارمنس سکیما میں سلو-لاک مانیٹر۔ وجہ توجیہ۔ بوجھ کے تحت ہم وقت اور تھرو پٹ کی حفاظت کرتا ہے (دستاویز 15 §4 cross-cutting میکینکس)۔

3.12 تعمیل (COMP)

تعمیل کی ذمہ داریاں سندھ اور پاکستان قانون سے، نیز حکومتی ریکارڈز-انتظام اصولوں سے اخذ ہوتی ہیں۔ مستند کنٹرولز /specs/ur/11-security-compliance/ میں ہیں؛ یہاں NFRs قابلِ پیمائش تعمیل بیان کرتے ہیں۔

NFR-COMP-001 — سندھ RTI ایکٹ 2016 ہم آہنگی [M]

میٹرک / ہدف۔ RTI-زمرہ ٹکٹس سندھ شفافیت و حقِ معلومات ایکٹ 2016 کی قانونی آخری تاریخیں کے بمقابلہ پروسیس اور ٹریک کیے جائیں گے؛ SLA انجن RTI کیلنڈر خود بخود لگائے گا اور عوامی شفافیت ڈیش بورڈ RTI-تعمیل شرحیں رپورٹ کرے گا۔ طریقۂ پیمائش۔ ہر ریلیز RTI SLA راستہ کا فنکشنل ٹیسٹ؛ عوامی ڈیش بورڈ پر سہ ماہی RTI-تعمیل رپورٹ۔ وجہ توجیہ۔ RTI آخری تاریخیں قانونی ہیں، پالیسی نہیں؛ غیر تعمیل کا قانونی خطرہ ہے۔

NFR-COMP-002 — ڈیٹا-تحفظ اصول [M]

میٹرک / ہدف۔ نظام NFR-PRIV-001…008 میں رازداری کنٹرولز کے ذریعے عام ڈیٹا-تحفظ اصولوں (قانونی طور پر جائز، منصفانہ، شفاف، مقصد کی حد، کم سے کم، درستگی، اسٹوریج کی حد، سالمیت، جوابدہی) کی تعمیل کا مظاہرہ کرے گا؛ لانچ سے قبل ایک ڈیٹا-تحفظ اثر اندازی جائزہ (DPIA) فائل پر ہوگا۔ طریقۂ پیمائش۔ مرحلہ-1 گیٹ پر DPIA سائن آف؛ سالانہ refresh۔ وجہ توجیہ۔ صوبائی توقع + کسی بھی مستقبل کے پاکستان وفاقی ڈیٹا-تحفظ قانون کے لیے تیاری۔

NFR-COMP-003 — آڈٹ-لاگ غیر قابلِ تبدیلی + ریٹینشن [M]

میٹرک / ہدف۔ آڈٹ لاگ (aud_event) append-only (DB استحقاق سطح پر کوئی UPDATE/DELETE نہیں) ہوگا، ماہ کے لحاظ سے پارٹیشنڈ، ≥ 7 سال (یا سندھ آرکائیوز اصول کے مطابق اس سے زیادہ) تک برقرار، اور tamper-evidence کے لیے hash chaining کے ساتھ آف-ہوسٹ اسٹوریج کو export۔ طریقۂ پیمائش۔ DB-استحقاق آڈٹ تصدیق کرتا ہے کہ کسی کردار کو aud_event پر UPDATE/DELETE نہیں؛ سہ ماہی hash-chain تصدیق؛ آف-ہوسٹ export کامیابی مانیٹر۔ وجہ توجیہ۔ آڈٹ سالمیت ہر دوسرے تعمیل دعوے (RTI، AG/PAC آڈٹ، تنازعات) کی ضمانت دیتی ہے۔

NFR-COMP-004 — سندھ آرکائیوز بمطابق ریکارڈز انتظام [M]

میٹرک / ہدف۔ ریکارڈز (ٹکٹس، MoMs، خطوط، قراردادیں) سندھ آرکائیوز اصول کے مطابق برقرار اور آرکائیو کیے جائیں گے؛ ایک آرکائیوال ورک فلو ختم شدہ ریکارڈز کو اشاریہ محفوظ رکھنے کے ساتھ طویل-مدتی اسٹوریج میں منتقل کرتا ہے؛ تصفیہ دستاویزی اور منظور شدہ ہے۔ طریقۂ پیمائش۔ ریکارڈز-انتظام طریقہ شائع؛ سالانہ آرکائیوال آڈٹ۔ وجہ توجیہ۔ حکومتی ریکارڈز کی قانونی ریٹینشن ہے جو عام ڈیٹا-کم-سے-کم سے بالا تر ہے۔

NFR-COMP-005 — CII رجسٹریشن + CERT-PK رابطہ [S]

میٹرک / ہدف۔ SITP پاکستان کے فریم ورک کے تحت اہم معلومات انفراسٹرکچر (CII) کے طور پر رجسٹرڈ ہوگا؛ واقعہ جواب ایک CERT-PK اطلاع توقعات سے ہم آہنگ ران بک پر عمل کرے گا (ایک رپورٹ قابل واقعہ کے 24 گھنٹے کے اندر ابتدائی اطلاع)۔ طریقۂ پیمائش۔ فائل پر CII رجسٹریشن سرٹیفکیٹ؛ IR ران بک سالانہ جائزہ؛ سالانہ tabletop مشق۔ وجہ توجیہ۔ شہری PII ہینڈل کرنے والا صوبائی حکومتی نظام قومی CII/CERT توقعات پورا کرتا ہے۔

NFR-COMP-006 — خرید (PEPRA) ہم آہنگی [S]

میٹرک / ہدف۔ PPP مصروفیت، وینڈر انتخاب، سورس-کوڈ escrow، اور ایگزٹ/ہینڈ اوور منصوبہ سندھ پبلک پرائیویٹ پارٹنرشپ اور PEPRA خرید اصول کے مطابق ہوں گے؛ دستاویزات بمطالبہ قابلِ آڈٹ۔ طریقۂ پیمائش۔ معاہدہ مائیل اسٹونز پر خرید-فائل جائزہ؛ /specs/ur/23-ppp-vendor-exit/ دیکھیں۔ وجہ توجیہ۔ خرید تعمیل مصروفیت کی طوالت اور جوازیت کی حفاظت کرتی ہے۔

3.13 آڈٹ پذیری (AUD)

آڈٹ پذیری ہر سٹیٹ تبدیلی اور رسائی کو آڈیٹر-جنرل (AG)، پبلک اکاؤنٹس کمیٹی (PAC)، اندرونی آڈٹ، اور تنازعہ حل کے لیے دوبارہ تعمیر قابل بناتی ہے۔

NFR-AUD-001 — تمام سٹیٹ تبدیلیوں کے لیے append-only آڈٹ [M]

میٹرک / ہدف۔ ہر سٹیٹ تبدیل کرنے والا عمل (ٹکٹ حیثیت، تفویض، کردار/اجازت تبدیلی، فلیگ ٹوگل، فائل رسائی، انٹیگریشن کال، AI کال، لاگ اِن/اسٹیپ-اپ) ایک غیر قابلِ تبدیلی aud_event صف لکھے گا جس میں کون (صارف آئی ڈی + کردار)، کیا (عمل + entity + قبل/بعد diff)، کب (UTC timestamp)، کیوں (کاروباری وجہ، جہاں قابلِ اطلاق)، اور trace_id ہوگا۔ طریقۂ پیمائش۔ CI میں فی-اینڈ پوائنٹ آڈٹ-کورج ٹیسٹ؛ reconstructability کا سہ ماہی نمونہ آڈٹ۔ وجہ توجیہ۔ four-W آڈٹ ریکارڈ حکومتی جوابدہی کی عالمی کرنسی ہے۔

NFR-AUD-002 — tamper-evidence [M]

میٹرک / ہدف۔ آڈٹ صفیں hash-chained ہوں گی (ہر صف کا hash پچھلے صف کے hash کو شامل کرتا ہے) تاکہ کوئی بھی چھیڑ چھاڑ detectable ہو؛ سہ ماہی تصدیق chain کی تصدیق کرتی ہے؛ کوئی بھی break آن-کال کو پیج کرتا ہے۔ طریقۂ پیمائش۔ Hash-chain تصدیق جاب؛ سہ ماہی تصدیق رپورٹ؛ آف-ہوسٹ کاپی chain برقرار رکھتی ہے۔ وجہ توجیہ۔ detectable چھیڑ چھاڑ آڈٹ ثبوت کے قابلِ قبول ہونے کے لیے کم از کم دہلیز ہے۔

NFR-AUD-003 — AG/PAC آڈٹ کے لیے export [M]

میٹرک / ہدف۔ آڈٹ لاگ ایک قابلِ انتخاب تاریخ حد اور عمل فلٹر پر، ایک دستخط شدہ manifest کے ساتھ، درخواست کنندہ آڈیٹر کے اختیار سے سکوپ کر کے export (CSV/Excel/JSON) کے قابل ہوگا؛ exports خود آڈٹ-لاگ ہوتے ہیں۔ طریقۂ پیمائش۔ ہر ریلیز export راستے کا فنکشنل ٹیسٹ؛ رسائی-کنٹرول ٹیسٹ scoping کی تصدیق۔ وجہ توجیہ۔ آڈیٹرز کو جانے پہچانے فارمیٹس میں نکالنے قابل ثبوت درکار ہے۔

NFR-AUD-004 — رازدارانہ/VIP ریکارڈز کے لیے رسائی لاگنگ [M]

میٹرک / ہدف۔ ایک Confidential یا Restricted ریکارڈ (ٹکٹ، فائل، MoM) کی ہر ریڈ آڈٹ-لاگ ہوگی — صرف رائٹس نہیں — بشمول قاری، وقت، اور source IP؛ غیر معمولی پیٹرنز پر curious-reading الرٹس فائر ہوتے ہیں۔ طریقۂ پیمائش۔ ریڈ-آڈٹ کورج ٹیسٹ؛ سہ ماہی رسائی-پیٹرن جائزہ۔ وجہ توجیہ۔ حساس ریکارڈز کی ریڈز رازداری اور اعتماد-اور-حفاظت کے لیے رائٹس کی طرح اہم ہیں۔

3.14 باہمی تعامل (INTER)

SITP حکومتی نظام کے ساتھ ضم ہوتا ہے اور پارٹنرز کے لیے APIs expose کرتا ہے۔ /specs/ur/08-integrations-spec/ اور /specs/ur/12-api-contract/ دیکھیں۔

NFR-INTER-001 — OpenAPI کے ساتھ REST + JSON [M]

میٹرک / ہدف۔ تمام عوامی اور بین-سسٹم APIs ایک OpenAPI 3.x کنٹریکٹ کے ساتھ REST + JSON استعمال کریں گے؛ V1 میں کوئی SOAP، کوئی ملکیتی binary پروٹوکول نہیں؛ پے لوڈز versioned۔ طریقۂ پیمائش۔ ہر ریلیز OpenAPI پیدا اور شائع (NFR-MAINT-004)؛ فی اینڈ پوائنٹ کنٹریکٹ ٹیسٹ سوٹ۔ وجہ توجیہ۔ REST+JSON+OpenAPI ان پارٹنرز اور ٹولنگ کے سیٹ کو maximize کرتا ہے جو ضم ہو سکتی ہیں۔

NFR-INTER-002 — Webhook معیار [S]

میٹرک / ہدف۔ SITP کلیدی ڈومین واقعات (ٹکٹ حیثیت تبدیلی، MoM شائع، قرارداد) کے لیے باہر روانہ webhooks expose کرے گا جو ایک دستاویزی شدہ envelop (واقعہ قسم، timestamp، signature، payload) استعمال کرتے ہیں؛ وصول کنندگان ایک HMAC signature تصدیق کرتے ہیں؛ دوبارہ کوششیں NFR-RELY-002 بمطابق۔ طریقۂ پیمائش۔ CI میں webhook-contract ٹیسٹ؛ دستاویزی شدہ retry + signature scheme۔ وجہ توجیہ۔ Webhooks پارٹنر انٹیگریشنز کے لیے معیاری واقعہ-ترسیل پیٹرن ہیں۔

NFR-INTER-003 — حکومتی انٹیگریشنز کے لیے ایڈاپٹر پیٹرن [M]

میٹرک / ہدف۔ ہر حکومتی نظام (NADRA، SECP، FBR/SRB، PSEB، e-Office) ایک مستقر انٹرفیس کے پیچھے ایک ایڈاپٹر کے ذریعے reachable ہوگا؛ نظام کا باقی حصہ کبھی براہ راست وینڈر SDK import نہیں کرے گا؛ ایڈاپٹرز mocks کے ساتھ آزادانہ طور پر قابلِ ٹیسٹ ہیں۔ طریقۂ پیمائش۔ فن تعمیر lint جو ایڈاپٹر ماڈیولز کے باہر براہ راست SDK import forbidden کرتا ہے (دستاویز 15 §13)؛ CI میں فی-ایڈاپٹر mock ٹیسٹ۔ وجہ توجیہ۔ ایڈاپٹر علیحدگی وینڈر تبدیلی، sandbox testing، اور آن-پریمس بیک اپ کو ممکن بناتی ہے۔

NFR-INTER-004 — versioned APIs + breaking-change پالیسی [M]

میٹرک / ہدف۔ عوامی APIs URI-versioned (/api/v1/...) ہوں گے؛ بریکنگ تبدیلیوں کے لیے ایک نیا major version درکار ہے جس میں پچھلا ورژن ≥ 12 مہینوں تک سہارا دیا جائے گا؛ OpenAPI spec-diff بریکنگ تبدیلیوں کو CI میں صریح acknowledgement کے پیچھے دروازہ بند کرتا ہے۔ طریقۂ پیمائش۔ Spec-diff CI چیک؛ ہر ریلیز پر deprecation-notice جائزہ۔ وجہ توجیہ۔ پارٹنرز اور موبائل ایپ API استحکام پر منحصر ہیں؛ versioning + ایک deprecation پالیسی کنٹریکٹ ہیں۔

NFR-INTER-005 — کوئی وینڈر lock-in نہیں (کثیر-صوبہ قابلِ نقل / کثیر-ٹیننٹ) [S]

میٹرک / ہدف۔ نظام صرف کنفگریشن کے ساتھ کسی دوسرے صوبے کے لیے یا ایک کثیر-ٹیننٹ واقعہ کے طور پر deployable ہوگا: اسکیمہ میں tenant/organisation scoping، env-چلائی گئی branding (/specs/ur/16-branding-design-system/ بمطابق)، اور لوکیل کیٹلاگز کے باہر کوئی hard-coded "Sindh" اسٹرنگ نہیں۔ طریقۂ پیمائش۔ مرحلہ-3 گیٹ پر فن تعمیر جائزہ؛ tenant-isolation ٹیسٹ؛ اسٹرنگ آڈٹ تصدیق کرتا ہے کہ کوئی hard-coded صوبہ نام نہیں۔ وجہ توجیہ۔ صوبوں میں قابلِ نقل اور مستقبل کے SaaS-طرز عمل کو سہارا دیتا ہے؛ سندھ حکومت کے لیے وینڈر lock-in سے بچاتا ہے۔

3.15 نقل پذیری (PORT)

نقل پذیری PPP ایگزٹ/ہینڈ اوور اور ہوسٹنگ فراہم کنندہ بدلنے (Server4Sale → متبادل) کے انتخاب کی حفاظت کرتی ہے۔

NFR-PORT-001 — ہر چیز containerized [M]

میٹرک / ہدف۔ ہر ایپلیکیشن کمپوننٹ (پورٹل، API، WebSocket گیٹ وے، AI سروس، ورکرز، Metabase، Keycloak) صریح وسائل limits اور healthchecks کے ساتھ Docker containers میں چلے گا؛ کوئی ہوسٹ-انسٹالڈ ایپلیکیشن runtime نہیں۔ طریقۂ پیمائش۔ ہر ریلیز انونٹری تصدیق کرتا ہے کہ تمام کمپوننٹس containerized؛ docker compose canonical local + staging + prod bring-up ہے۔ وجہ توجیہ۔ Containers نقل پذیری اور قابلِ تکرار ڈیپلائز کی پیش شرط ہیں۔

NFR-PORT-002 — کوئی hard ماحول coupling نہیں [M]

میٹرک / ہدف۔ کوئی کمپوننٹ Server4Sale ہوسٹ، ہوسٹ راستے، یا ہوسٹ-مخصوص کنفگ hard-code نہیں کرے گا؛ تمام کنفگریشن runtime پر mount شدہ environment variables / کنفگ فائلوں کے ذریعے (12-factor)؛ نظام صرف کنفگریشن تبدیلی کے ساتھ ایک متبادل فراہم کنندہ پر deployable ہوگا۔ طریقۂ پیمائش۔ ہر ریلیز کنفگریشن آڈٹ؛ سہ ماہی "متبادل ہوسٹ پر lift" tabletop۔ وجہ توجیہ۔ وینڈر neutrality ایک PPP تحفظ ہے (/specs/ur/23-ppp-vendor-exit/ دیکھیں)۔

NFR-PORT-003 — Compose → Kubernetes گریجویشن راستہ [C]

میٹرک / ہدف۔ Docker Compose ٹوپولوجی اس طرح ساخت کی جائے گی کہ ہر سروس definition صاف طور پر ایک مستقبل کے Kubernetes manifest میں map ہوتی ہے (فی سروس ایک Deploy، صریح healthchecks، resource requests/limits، secrets بطور env-from)؛ گریجویٹ کے لیے کوئی دوبارہ لکھنا درکار نہیں۔ طریقۂ پیمائش۔ اسکیل-آؤٹ ٹرگر پر فن تعمیر جائزہ (دستاویز 15 §17، §22 item 3 بمطابق)۔ وجہ توجیہ۔ دستاویزی شدہ اسکیل-آؤٹ انتخاب (دستاویز 15 §17) کو مستقبل کے دوبارہ لکھنے کے بغیر محفوظ رکھتا ہے۔

4. خلاصہ جدول

5. اہداف نظرثانی کیڈنس

اس دستاویز کے تمام اہداف V1 بنیادیں ہیں۔ یہ نیچے کی کیڈنس پر جائزہ لیے جاتے ہیں؛ نظرثانیاں اس دستاویز کے بمقابلہ ایک ڈیلٹا کے طور پر ریکارڈ کی جاتی ہیں جس میں پچھلی قدر git history میں محفوظ رہتی ہے۔

5.1 مرحلہ-سے-NFR میپنگ (اشاریہ)

6. کھلی اشیاء [TBD/confirm]

درج ذیل اہداف کو دستاویز کی بنیاد بنانے سے قبل نامزد مالک کی تصدیق درکار ہے:

یہ [TBD/confirm] اشیاء /specs/ur/14-roadmap-release/ میں بند تک ٹریک کی جاتی ہیں اور فیصلے آنے پر اس دستاویز میں واپس عکس بندی ہوتی ہے۔

دستاویز کا اختتام۔