Sindh IT Portal — Facilitation DeskSpecification documents
Englishاردوسنڌي
← All documents

UX سائٹ میپ اور بہاؤ

سندھ آئی ٹی پورٹل — سہولت ڈیسک (SITP) کے ہر اسکرین کے لیے معلومات کی تشکیل، سائٹ میپ، کردار پر مبنی نیویگیشن، اہم صارف کے سفر، اور وائر فریم بریفز۔ اس میں عوامی سائٹ، ہر کردار کا تصدیق شدہ ورک اسپیس، موبائل-فرسٹ/PWA رویہ، RTL/کثیر لسانی، اور رسائیت شامل ہے۔

فیلڈ قدر
دستاویز ID 10
حیثیت مسودہ
مالک S&ITD / MAAHIR
زبانیں EN (master) · UR · SD
لاگو ماڈیولز پر A. عوامی سائٹ (PUB)، B. ٹکٹنگ (TKT)، C. تنظیم و RBAC (ORG)، I. تجزیات (ANL)، M. سماعت+TRI+MoM (MTG)، Q. فیچر فلیگز (FFG)
انحصار پر /specs/ur/04-roles-permissions/ · /specs/ur/06-ticket-workflow/ · /specs/ur/16-branding-design-system/ · /specs/ur/17-analytics-kpis/ · /specs/ur/21-mom-meetings/ · /specs/ur/09-i18n-localization/
کراس ریفرنسز /specs/ur/01-prd/ · /specs/ur/02-functional-reqs/ · /specs/ur/03-non-functional-reqs/ · /specs/ur/19-multichannel-intake/

1. جائزہ و دائرہ کار

یہ دستاویز تعین کرتی ہے کہ صارفین کیا دیکھتے ہیں، کہاں جاتے ہیں، اور کیسے حرکت کرتے ہیں SITP کے ذریعے۔ یہ /specs/ur/04-roles-permissions/ میں کردار ماڈل اور /specs/ur/06-ticket-workflow/ میں ٹکٹ لائف سائیکل کا UX ہم منصب ہے۔ اس میں شامل ہیں:

بصری شناخت (اجڑک پیلیٹ، ٹائپوگرافی، اجزاء) /specs/ur/16-branding-design-system/ میں موجود ہے؛ یہ دستاویز اس کا حوالہ دیتی ہے لیکن اسے دہراتی نہیں۔


2. UX اصول

یہ اصول ہر اسکرین پر باندھنے والے ہیں۔ یہ _context.md §2، §7 میں مقفل فیصلوں اور /specs/ur/03-non-functional-reqs/ میں استعمال کے اہداف سے ماخوذ ہیں۔

2.1 تدریجی افشا

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

2.2 کمپنی کے سفر کے لیے تین کلک کا اصول

بنیادی کمپنی کا سفر — عوامی ہوم پیج سے ٹریکنگ آئی ڈی کے ساتھ جمع شدہ ٹکٹ تک — واپس آتے ہوئے، لاگ اِن نمائندے کے لیے تین کلکس یا اس سے کم میں مکمل ہونا چاہیے:

  1. کلک 1: "ٹکٹ فائل کریں" (ہوم ہیرو یا اوپری یوٹیلیٹی بار)۔
  2. کلک 2: فائل-ٹکٹ وزرڈ میں "جمع کرائیں" (زمرہ، تفصیلات، منسلکات)۔
  3. کلک 3: تصدیقی اسکرین سے "ٹکٹ دیکھیں"۔

پہلی بار رجسٹریشن ایک الگ، طویل بہاؤ ہے (§6.1)، لیکن فائلنگ کا قدم خود تصدیق کے بعد تین کلکس کے اندر رہتا ہے۔ ہوم پیج سے ٹریک آئی ڈی تلاش ایک واحد عمل ہے (ایک کلک + ایک پیسٹ)۔ تصدیق شدہ علاقے میں کہیں بھی نیویگیشن کی گہرائی تین سطحوں سے زیادہ نہیں ہونی چاہیے اس سے پہلے کہ صارف کام کی سطح (ڈیش بورڈ، ٹکٹ، یا فارم) تک پہنچے۔

2.3 کردار پر مبنی لینڈنگ اور نیویگیشن

ہر اکاؤنٹ اپنے کردار کے مطابق ڈیش بورڈ پر آتا ہے اور صرف وہ نیویگیشن دیکھتا ہے جس کی اس کی صلاحیتیں اجازت دیتی ہیں (دیکھیں /specs/ur/04-roles-permissions/ §16)۔ ایک فائلر کبھی عملہ-انتظامیہ اسکرینز نہیں دیکھتا؛ ایک ویور کبھی تشکیل نہیں دیکھتا؛ ایک افسر کبھی Officials CMS نہیں دیکھتا۔ نیویگیشن تعریفی طور پر تیار کی جاتی ہے ان صلاحیتوں سے جو صارف واقعی رکھتا ہے بعد میں فی-صارف اوورائیڈز اور ABAC گیٹس کے، تو ایک دیا گیا اوورائیڈ فوراً اپنا نیویگیشن اندراج ظاہر کرتا ہے اور منسوخ صلاحیت غائب ہو جاتی ہے۔

2.4 موبائل-فرسٹ اور PWA

SITP موبائل-فرسٹ ایک Progressive Web App (PWA) کے طور پر بنایا گیا ہے: انسٹال قابل، مسودوں اور صرف پڑھنے کے ٹکٹ مناظر کے لیے آف لائن قابل، اور بہت سے کمپنی نمائندوں اور فیلڈ افسران کے لیے بنیادی چینل۔ ٹچ ہدف کم از کم 44×44 px ہیں۔ ترتیبیں پہلے سب سے چھوٹے فعال ویو پورٹ کے لیے بنائی جاتی ہیں اور بڑے بریک پوائنٹس پر تدریجی بہتری پاتی ہیں (§9)۔ مستقبل کا React Native (Expo) موبائل ایپ وہی API معاہدہ اور نیویگیشن ماڈل دوبارہ استعمال کرتا ہے۔

2.5 رسائیت — WCAG 2.1 AA

تمام اسکرینز انگریزی، اردو، اور سندھی میں WCAG 2.1 AA پر پورا اترتی ہیں (دیکھیں _context.md §2 اور /specs/ur/09-i18n-localization/)۔ ٹھیک طور پر: سیمانٹک لینڈ مارکس، مواد تک جانے کے لنکس، مرئی فوکس کے ساتھ مکمل کی بورڈ کام کرنے کی صلاحیت، AA کم از کم پر رنگ کنٹراسٹ تناسب، صرف رنگ پر مبنی کوئی معنی نہیں، جہاں مقامی سیمانٹکس کافی نہ ہوں وہاں ARIA، تمام تعاملی اجزاء پر قابلِ رسائی نام، اور ہر چارٹ کے لیے ڈیٹا-ٹیبل متبادل۔ حرکت prefers-reduced-motion کا احترام کرتی ہے۔ ایک صارف-منتخب ہائی-کنٹراسٹ موڈ اور فونٹ-سائز کنٹرول اوپری یوٹیلیٹی بار میں ظاہر کیے گئے ہیں۔

2.6 دائیں سے بائیں (RTL) اور کثیر لسانی

اردو اور سندھی دائیں سے بائیں (RTL) میں ظاہر ہوتے ہیں۔ سمت Docusaurus/Next.js لوکیل سے چلائی جاتی ہے؛ کوئی ان لائن سمت کے ہیک نہیں۔ ترتیبیں آئینہ-متوازی ہیں: سائڈ ریلز طرفیں تبدیل کرتی ہیں، آئیکن تیر الٹ جاتے ہیں، AI چیٹ بوٹ لانچر RTL میں نیچے-بائیں طرف منتقل ہو جاتا ہے۔ تمام کاپی منظور شدہ گلوسری اصطلاحات (_glossary.md) استعمال کرتی ہے۔ ایک زبان بدلنے والا ہمیشہ اوپری یوٹیلیٹی بار میں مرئی ہوتا ہے اور فی صارف برقرار رہتا ہے۔

2.7 دوہرا کیلنڈر

صارف کو دکھائی جانے والی ہر تاریخ گریگورین اور اسلامی (ہجری) دونوں شکلوں میں ظاہر ہوتی ہے (حکومتی روایت؛ _context.md §2)۔ تاریخ منتخب کرنے والے پہلے سے گریگورین ان پٹ پر ہوتے ہیں، ہجری کے ساتھی کے ساتھ؛ SLA چپس کاروباری دنوں کے شمار دکھاتی ہیں۔

2.8 اعتماد، شفافیت، اور "واحد کھڑکی" کا وعدہ

انٹرفیس مسلسل تقویت دیتا ہے کہ SITP وہ واحد کھڑکی ہے جس کی ملکیت S&ITD کے پاس ہے: آپریٹر لائن ("MAAHIR کے زیرِ عمل · Server4Sale کے ذریعے طاقتور") فوٹر میں ظاہر ہوتی ہے؛ عوامی شفافیت ڈیش بورڈ ہوم پیج سے ایک کلک پر ہے؛ ٹریکنگ آئی ڈی معنی خیز ہیں (SITP-YYYY-<DEPT>-<NNNNNN>)؛ اور حل کا ثبوت فائل کرنے والے کو نظر آتا ہے۔ خالی اور خرابی کی حیثیات ایماندار اور بحال کرانے والی ہیں (§10)۔


3. معلومات کی تشکیل (سائٹ میپ)

3.1 عوامی سائٹ (ماڈیول A — PUB)

عوامی سائٹ مارکیٹنگ، آن بورڈنگ، اور سیلف-سروس کی پرت ہے۔ یہ مکمل طور پر انڈیکس کی جانے والی ہے (SEO، EN/UR/SD کے لیے hreflang) اور جہاں نوٹ کیا گیا ہو سوائے اس کے لاگ اِن کی ضرورت نہیں۔

# سیکشن صفحات
P1 ہوم / لینڈنگ ہیرو، فوری اقدامات، لائیو شفافیت کاؤنٹرز، نمایاں عہدیدار، خبروں کا کاروسیل۔
P2 بارے میں / مینڈیٹ SITP مقصد، S&ITD ملکیت، PPP ماڈل (MAAHIR/Server4Sale)، قانونی مینڈیٹ، MoUs۔
P3 محاکم آن بورڈ شدہ محاکم + سیکشنز + سروس کیٹلاگ لنکس کی تلاش کی جانے والی ڈائریکٹری۔
P4 خدمات / سروس کیٹلاگ فی محکمہ خدمات کا براؤز کیا جانے والا کیٹلاگ → متحرک انٹیک فارم چلاتا ہے۔
P5 یہ کیسے کام کرتا ہے مرحلہ وار آن بورڈنگ وزرڈ وضاحتی (رجسٹر → فائل → ٹریک → حل)۔
P6 رجسٹر / لاگ اِن ادارہ-قسم منتخب کرنے والا (5 اقسام) → متحرک رجسٹریشن فارم؛ Keycloak OIDC + 2FA۔
P7 شکایت فائل کریں فائل-ٹکٹ وزرڈ کا اندراج؛ مہمان کو رجسٹر یا شہری انٹیک کی طرف روٹ کرتا ہے۔
P8 ٹکٹ ٹریک کریں SITP-YYYY-<DEPT>-<NNNNNN> کے ذریعے سنگل-فیلڈ تلاش؛ عوامی حالت کا خلاصہ۔
P9 معلومات کا ذخیرہ / مدد مرکز مضامین، ڈاؤن لوڈ کیے جانے والے فارم، نسخہ شدہ SOPs، AI سیمانٹک تلاش۔
P10 خبریں / اعلانات / سرکولرز مواد پورٹل (ماڈیول N)۔
P11 عہدیدار وزیر/SACM، سیکریٹری، DG پروفائلز Officials CMS سے (ماڈیول P)۔
P12 شفافیت ڈیش بورڈ عوامی تجزیات ڈیش بورڈ (ماڈیول I)۔
P13 RTI معلومات سندھ RTI ایکٹ 2016 کی آخری تاریخیں اور RTI درخواست کیسے فائل کریں۔
P14 وسل بلوور / گمنام انٹیک محدود-دکھائی دینے والا انٹیک چینل؛ کوئی لاگ اِن نہیں۔
P15 رابطہ / مدد ٹول-فری IVR، WhatsApp، ای میل، واک-اِن دفتر کی تفصیلات۔
اوورلے AI چیٹ بوٹ تیرتا ہوا لانچر (عوامی + تصدیق شدہ)؛ KB کی طرف انحراف۔

3.2 تصدیق شدہ علاقے (ماڈیولز B، C، I، M، Q)

لاگ اِن کے بعد، صارف کو کردار پر مبنی لینڈنگ ڈیش بورڈ پر روٹ کیا جاتا ہے۔ مشترکہ اجزاء: اوپری یوٹیلیٹی بار (زبان، اطلاعات، ترجیحات، پروفائل، 2FA حالت)، اِن-ایپ پیغام رسانی (ماڈیول F)، اطلاع مرکز (ماڈیول G)، اور ایک عالمی ٹکٹ/نمائندہ تلاش۔

رقبہ مالک کردار
کمپنی ورک اسپیس بنیادی نمائندہ، ایڈمن نمائندہ، فائلر، ویور، صرف اطلاعات
S&ITD سہولتی ورک اسپیس S&ITD سہولتی افسر / عملہ
افسر ورک اسپیس محکمہ افسر / عملہ / POC
محکمہ ایڈمن کنسول محکمہ ایڈمن
نگرانی ڈیش بورڈز DG/ڈائریکٹر، محکمہ سیکریٹری، وزیر/SACM
صرف پڑھنے کے لیے آڈٹ ایکسپلورر صرف پڑھنے کے لیے آڈیٹر
پلیٹ فارم ایڈمن کنسول سپر ایڈمن (S&ITD)
شہری ورک اسپیس شہری
گمنام حالت دیکھنے والا گمنام / وسل بلوور (ٹوکن-پر مبنی، کوئی لاگ اِن نہیں)

3.3 سائٹ میپ خاکہ

flowchart TD ROOT["Sindh IT Portal — Facilitation Desk"] subgraph PUB["Public site (no login)"] direction TB Home["Home"] About["About / Mandate"] Depts["Departments"] Services["Services / Catalog"] How["How it works"] Reg["Register / Login"] FilePub["File a complaint"] Track["Track a ticket"] KB["Knowledge Base"] News["News / Circulars"] Officials["Officials"] Transp["Transparency Dashboard"] RTI["RTI info"] WB["Whistleblower intake"] Contact["Contact"] end ROOT --> PUB ROOT --> AUTH["Authenticated area<br/>(role-scoped landing)"] Reg --> AUTH FilePub --> AUTH subgraph AUTH_SUB["Per-role workspaces"] direction TB Comp["Company workspace"] Fac["S&ITD facilitation"] Off["Officer workspace"] DeptAdmin["Dept admin console"] Overs["Oversight dashboards"] AuditExp["Audit explorer"] Super["Platform admin console"] Citz["Citizen workspace"] end AUTH --> AUTH_SUB WB --> AnonView["Anonymous status viewer<br/>(token, no login)"] PUB -.-> BOT["AI chatbot overlay"] AUTH_SUB -.-> BOT

تحریری وضاحت۔ سائٹ میپ میں پورٹل جڑ کے تحت دو اعلیٰ-سطحی شاخیں ہیں: عوامی سائٹ (کوئی لاگ اِن نہیں) اور تصدیق شدہ علاقہ۔ عوامی سائٹ معلوماتی صفحات (ہوم، بارے میں، محاکم، خدمات، یہ کیسے کام کرتا ہے)، بنیادی اندراج پوائنٹس (رجسٹر/لاگ اِن، شکایت فائل کریں، ٹکٹ ٹریک کریں)، سیلف-سروس مواد (معلومات کا ذخیرہ، خبریں، عہدیدار، شفافیت ڈیش بورڈ، RTI معلومات، رابطہ)، اور خاص وسل بلوور انٹیک کو میزبانی کرتی ہے۔ رجسٹر/لاگ اِن اور شکایت فائل کریں دونوں تصدیق شدہ علاقے میں لے جاتے ہیں، جو فی-کردار ورک اسپیسز میں پھیلتا ہے: کمپنی، S&ITD سہولت، افسر، محکمہ ایڈمن، نگرانی ڈیش بورڈز، آڈٹ ایکسپلورر، پلیٹ فارم ایڈمن کنسول، اور شہری۔ وسل بلوور انٹیک لاگ اِن کو نظر انداز کرتا ہے اور ٹوکن-پر مبنی گمنام حالت دیکھنے والے کی طرف روٹ کرتا ہے۔ AI چیٹ بوٹ اوورلے عوامی سائٹ اور تصدیق شدہ علاقے دونوں سے قابلِ رسائی ہے۔


4. صفحات کی فہرست

ہر صفحہ ان کردار(وں) سے ملا ہوا ہے جو اس تک پہنچ سکتے ہیں اور اس کے مقصد کے ساتھ۔ کردار کوڈز /specs/ur/04-roles-permissions/ §8 پر عمل کرتے ہیں (SA = سپر ایڈمن، DA = محکمہ ایڈمن، OF = افسر، DG = DG، SEC = سیکریٹری، MIN = وزیر، FO = S&ITD سہولتی افسر، PR = بنیادی نمائندہ، AR = ایڈمن نمائندہ، FI = فائلر، VI = ویور، CT = شہری، AN = گمنام، AU = صرف پڑھنے کے لیے آڈیٹر)۔ Public = کوئی لاگ اِن نہیں۔

4.1 عوامی صفحات

صفحہ کردار(یں) مقصد
ہوم Public واحد-کھڑکی اندراج؛ بنیادی CTAs؛ لائیو شفافیت کاؤنٹرز۔
بارے میں / مینڈیٹ Public S&ITD ملکیت، PPP ماڈل، قانونی مینڈیٹ قائم کرنا۔
محاکم Public آن بورڈ شدہ محاکم اور ان کی خدمات دریافت کریں۔
خدمات / کیٹلاگ Public خدمات براؤز کریں جو متحرک انٹیک فارم چلاتی ہیں۔
یہ کیسے کام کرتا ہے Public رجسٹر → فائل → ٹریک → حل وضاحت کریں۔
رجسٹر Public (PR/AR بن جاتا ہے) ادارہ-قسم منتخب کرنے والا + متحرک رجسٹریشن فارم۔
لاگ اِن تمام تصدیق شدہ Keycloak OIDC + 2FA اندراج۔
شکایت فائل کریں (اندراج) Public → FI/PR/CT مہمان کو رجسٹر یا شہری انٹیک کی طرف روٹ کرتا ہے۔
ٹکٹ ٹریک کریں Public ٹریکنگ آئی ڈی سے تلاش؛ عوامی حالت کا خلاصہ۔
معلومات کا ذخیرہ Public مضامین، فارم، SOPs، AI سیمانٹک تلاش۔
خبریں / سرکولرز Public اعلانات اور نسخہ شدہ دستاویزات۔
عہدیدار Public CMS سے وزیر/سیکریٹری/DG پروفائلز۔
شفافیت ڈیش بورڈ Public حل کی کارکردگی پر کھلا ڈیٹا۔
RTI معلومات Public RTI ایکٹ 2016 آخری تاریخیں اور فائلنگ۔
وسل بلوور انٹیک Public (AN) گمنام/خودبخود رپورٹنگ۔
رابطہ / مدد Public چینلز اور دفتر مقامات۔

4.2 تصدیق شدہ صفحات

صفحہ کردار(یں) مقصد
کمپنی ورک اسپیس ہوم PR, AR, VI کمپنی ٹکٹ جائزہ، مسودے، الرٹس۔
فائل-ٹکٹ وزرڈ FI, PR, AR, CT متحرک شرطی انٹیک؛ AI مدد؛ مسودہ-محفوظ۔
میرے ٹکٹس (کمپنی) PR, AR, FI, VI کمپنی ٹکٹس کی فلٹر کی جانے والی فہرست۔
ٹکٹ تفصیل PR, AR, FI, VI (کمپنی طرفہ)؛ OF, DG, SEC, MIN, FO, SA (حکومتی طرفہ، ABAC) گفتگو، منسلکات، SLA، اقدامات، آڈٹ۔
کمپنی پروفائل PR, AR (◐) ادارہ تفصیلات، تصدیقی بیج، دوبارہ تصدیق۔
نمائندگان کا انتظام PR, AR (◐) نمائندگان دعوت/انتظام؛ بنیادی منتقل کریں۔
MoM دیکھنے والا (کمپنی) PR, AR, FI, VI کمپنی ٹکٹس کے لیے رودادیکھیں/تسلیم کریں۔
اپیلز (فائل/انتظام) PR, AR, FI, CT CPGRAMS-طرز کی اپیل مدت کے اندر۔
کمپنی تجزیات PR, AR, VI (◐) کمپنی-دائرہ چارٹس اور ایکسپورٹس۔
S&ITD فرز بندی ان باکس FO, SA New ٹکٹس کی قطار؛ روٹنگ تصدیق/اوورائیڈ۔
افسر ورک اسپیس / میری قطار OF تفویض شدہ ٹکٹس، ذیلی-ٹاسکس، مسودے، KB۔
افسر ٹکٹ تفصیل OF (+ نگرانی بطور ABAC) ثبوت کے ساتھ حل؛ اندرونی نوٹس؛ TRI درخواست۔
ذیلی-ٹاسکس OF, FO, DA والد/والدہ ٹکٹ تعلقات کا انتظام۔
محکمہ ایڈمن کنسول DA عملہ، ذیلی-محاکم، SLA، KB، تجزیات، آڈٹ۔
عملہ انتظام DA, SA افسران دعوت/فعال/غیر فعال؛ تصدیقی حالت۔
نگرانی ڈیش بورڈ DG, SEC, MIN KPIs، اسکیلیشن سطحيں، ہدایات، GIS ہیٹ میپ۔
آڈٹ ایکسپلورر AU, SA (◐ DA/DG/SEC) غیر قابلِ تبدیل آڈٹ لاگ تلاش اور ایکسپورٹ۔
پلیٹ فارم ایڈمن کنسول SA پلیٹ فارم-وسیع تشکیل۔
محاکم ایڈیٹر SA محاکم اور نسٹڈ ذیلی-محاکم بنائیں/مدون کریں۔
عہدیدار CMS SA وزیر/سیکریٹری/DG ریکارڈز مؤثر تاریخیں۔
انٹیگریشنز تشکیل SA SECP/NADRA/FBR/SRB/PSEB/e-Office کنیکٹرز۔
AI انجنز تشکیل SA پلگ ایبل LLM + OCR انجن انتخاب اور جانچ۔
فیچر فلیگز SA (◐ DA) کوئی بھی صلاحیت فی محکمہ/ماحول ٹوگل کریں۔
مواصلات تشکیل SA (◐ DA) SMTP/SMS/WhatsApp ٹیمپلیٹس اور فراہم کنندگان۔
چھٹیوں کا کیلنڈر SA (◐ DA) سندھ کی عوامی چھٹیاں؛ ہجری ریذولوشن۔
TRI میٹنگ پیج FO, OF, PR, AR (+ نگرانی) سہ فریقی میٹنگ شیڈول/منعقد؛ رضامندی حاصل کریں۔
MoM اپلوڈ + دیکھنے والا (حکومت) OF, FO, DA (+ DG تصدیق) اپلوڈ، OCR، AI-نکالنا، ذیلی-ٹاسکس تصدیق، شائع۔
تجزیات ڈیش بورڈز تمام کردار (دائرہ) کردار-دائرہ چارٹس؛ Metabase-ایمبیڈڈ + کسٹم۔
اندرونی پیغام رسانی تمام حکومتی کردار (◐) DMs، گروپس، چینلز (ماڈیول F)۔
اطلاع مرکز تمام کردار ترجیحات، ڈائجسٹس، خاموش اوقات، دو طرفہ جوابات۔
پروفائل / ترجیحات تمام کردار اکاؤنٹ، 2FA، زبان، رسائیت، اطلاع ترجیحات۔
شہری ورک اسپیس CT اپنی شکایات فائل، ٹریک، دوبارہ کھولیں، واپس لیں، اپیل کریں۔
گمنام حالت دیکھنے والا AN ٹوکن-پر مبنی صرف پڑھنے کے لیے حالت (کوئی لاگ اِن نہیں)۔

5. کردار پر مبنی نیویگیشن اور لینڈنگ

کردار لینڈنگ ڈیش بورڈ اور بنیادی نیویگیشن کا تعین کرتا ہے۔ ذیل کا خلاصہ /specs/ur/04-roles-permissions/ §16 کو ٹھوس نیویگیشن اندراجات کے ساتھ توسیع دیتا ہے۔ نیویگیشن صارف کی موثر صلاحیتوں سے تیار کی جاتی ہے (اوورائیڈز اور ABAC کے بعد)، تو ذیل کی فہرستیں ہر ٹیمپلیٹ کے لیے طے شدہ ہیں۔

کردار طے شدہ لینڈنگ بنیادی نیویگیشن
سپر ایڈمن (SA) پلیٹ فارم ایڈمن کنسول محاکم · عہدیدار CMS · انٹیگریشنز · AI انجنز · فیچر فلیگز · مواصلات · چھٹیوں کا کیلنڈر · آڈٹ · تجزیات
محکمہ ایڈمن (DA) محکمہ ایڈمن کنسول عملہ · ذیلی-محاکم · SLA · اسکیلیشن · KB · اطلاع ٹیمپلیٹس · تجزیات · آڈٹ
افسر / عملہ (OF) میرے تفویض شدہ ٹکٹس میری قطار · ذیلی-ٹاسکس · مسودے · TRI · MoM اپلوڈ · KB · تجزیات · پیغامات
DG / ڈائریکٹر (DG) محکمہ نگرانی ڈیش بورڈ محکمہ · اسکیلیشنز · ہدایات · TRI/MoM توثیقیں · تجزیات
سیکریٹری (SEC) محکمہ نگرانی ڈیش بورڈ محکمہ · اسکیلیشنز · ہدایات · VIP توثیقیں · تجزیات
وزیر / SACM (MIN) کراس-محکمہ نگرانی ڈیش بورڈ جائزہ · ہدایات · اسکیلیشنز · عہدیدار · تجزیات
کمپنی بنیادی نمائندہ (PR) کمپنی ورک اسپیس ٹکٹس · فائل · مسودے · پروفائل · نمائندگان · MoM · اپیلز · تجزیات
فائلر (FI) نیا ٹکٹ / میرے ٹکٹس فائل · میرے ٹکٹس · مسودے · مدد
شہری (CT) میری شکایات فائل · میری شکایات · ٹریک · مدد

اضافی کردار (اوپر نو ضروری میں شامل نہیں مگر سسٹم میں موجود):

کردار طے شدہ لینڈنگ بنیادی نیویگیشن
S&ITD سہولتی افسر (FO) سہولت فرز بندی ان باکس فرز بندی · TRI · MoM · کمپنیاں · پیغامات
ایڈمن نمائندہ (AR) کمپنی ورک اسپیس (بطور بنیادی، سوائے منتقلی/دوبارہ تصدیق کے)
ویور (VI) کمپنی ٹکٹس (صرف پڑھنے کے لیے) ٹکٹس · تجزیات
صرف اطلاعات اطلاع مرکز اطلاعات
صرف پڑھنے کے لیے آڈیٹر (AU) آڈٹ ایکسپلورر آڈٹ · تجزیات · ایکسپورٹس

6. اہم صارف کے سفر

آٹھ سفر Mermaid فلوعارٹ کے طور پر پیش کیے گئے ہیں، ہر ایک کے بعد تحریری وضاحت ہے۔ یہ براہِ راست /specs/ur/06-ticket-workflow/ میں ورک فلول قواعد اور /specs/ur/04-roles-permissions/ میں کرداروں سے ملتے ہیں۔

6.1 سفر 1 — کمپنی رجسٹر کرتی ہے اور پہلا ٹکٹ فائل کرتی ہے

flowchart TD Landing(["Public home"]) --> HaveAcct{"Have an<br/>account?"} HaveAcct -- "No" --> EntityType["Choose entity type<br/>(SECP / Sole / Freelancer /<br/>Foreign / Startup)"] HaveAcct -- "Yes" --> Login["Login + 2FA"] EntityType --> DynoForm["Dynamic registration form<br/>by entity type"] DynoForm --> Primary["Mandatory: name<br/>Primary Authorized Rep<br/>+ CNIC + domain email"] Primary --> SubmitReg(["Submit"]) SubmitReg --> Provisional[("Provisional account<br/>instant — file-first")] Provisional --> TwoFA["Verify 2FA / email"] Provisional --> BgChecks[("Background checks run<br/>in parallel:<br/>SECP / FBR / SRB / PSEB / NADRA")] TwoFA --> Workspace(["Company workspace"]) Workspace --> Wizard["File-ticket wizard<br/>(Step 1 of 5)"] Wizard --> CatStep["Pick category —<br/>AI suggests dept + similar ticket"] CatStep --> DynoFields["Dynamic conditional fields<br/>per category"] DynoFields --> Attach["Attachments: AV scan + encrypt"] Attach --> Review["Review + save draft option"] Review --> Submit2(["Submit"]) Submit2 --> TrackID[("Tracking ID allocated<br/>SITP-YYYY-DEPT-NNNNNN")] TrackID --> NewState(["Status = New<br/>confirmation EN/UR/SD"]) BgChecks -. "Verified badge<br/>or hold+appeal" .-> Workspace

تحریری وضاحت۔ ایک کمپنی زائر عوامی ہوم پیج پر آتا ہے اور رجسٹر کرنے کا انتخاب کرتا ہے۔ رجسٹریشن فارم متحرک ہے: منتخب کردہ ادارہ قسم (SECP کمپنی، انفرادی مالک، فری لینسر، غیر ملکی شاخ، یا ابتدائی اسٹارٹ اپ) یہ طاہر کرتا ہے کہ کون سی فیلڈز اور تصدیقی ماخذ ظاہر ہوتے ہیں۔ ایک بنیادی مجاز نمائندہ (CNIC اور ڈومین ای میل کے ساتھ) کا نام دینا لازمی ہے اور اسے چھوڑا نہیں جا سکتا۔ جمع کرانے پر اکاؤنٹ فوراً ایک عارضی حالت میں بنتا ہے — یہ فائل-فرسٹ ماڈل ہے — اور بیک گراونڈ تصدیق SECP، FBR، SRB، PSEB، اور NADRA کے خلاف متوازی چلتی ہے۔ 2FA/ای میل کی تصدیق کے بعد، نمائندہ کمپنی ورک اسپیس میں آتا ہے اور فائل-ٹکٹ وزرڈ کھولتا ہے۔ وزرڈ کا پہلا قدم AI-تجویز کردہ زمرہ، منزل محکمہ، اور مماثل-ٹکٹ انحراف پیش کرتا ہے؛ ایک زمرے کا انتخاب اس زمرے کے لیے شرطی فیلڈز متحرک ظاہر کرتا ہے (مثال کے طور پر، عدمِ ادائیگی فیلڈز SECP نام-تنازعہ فیلڈز سے مختلف ہیں)۔ منسلکات کے AV-اسکین اور خفیہ کاری کے بعد، نمائندہ اندراج کا جائزہ لیتا ہے (مسودہ محفوظ کرنے کے اختیار کے ساتھ)، جمع کراتا ہے، اور ایک ٹریکنگ آئی ڈی SITP-YYYY-<DEPT>-<NNNNNN> شکل میں ایٹمی طور پر مختص ہوتا ہے۔ ٹکٹ New میں داخل ہوتا ہے، ایک کثیر لسانی تصدیق بھیجی جاتی ہے، اور متوازی بیک گراونڈ چیکس بالآخر تصدیق شدہ بیج دیتے ہیں (یا اگر ناکام ہوں تو اپیل کے لیے اکاؤنٹ روک دیتے ہیں)۔

6.2 سفر 2 — افسر فرز بندی کرتا ہے اور AI مدد + ثبوت گیٹ کے ساتھ حل کرتا ہے

flowchart TD NewState(["Status = New"]) --> TriageQueue["S&ITD triage inbox"] TriageQueue --> AITriage["AI assist:<br/>summary + category confirm +<br/>urgency/sentiment + draft routing"] AITriage --> Confirm["Facilitator confirms/overrides<br/>category, priority, SLA,<br/>dept/section, sensitivity"] Confirm --> Triaged(["Status = Triaged"]) Triaged --> DeptQueue["Department section queue"] DeptQueue --> Assign["Section head or AI auto-router<br/>assigns officer"] Assign --> Assigned(["Status = Assigned"]) Assigned --> OffWS["Officer workspace"] OffWS --> AIReply["AI assist:<br/>draft reply + similar KB article +<br/>PII redaction on free text"] AIReply --> FirstResp["Send first substantive response"] FirstResp --> InProgress(["Status = In Progress<br/>FRT met"]) InProgress --> WorkCycle["Work cycle:<br/>In Progress <-> Awaiting Parties"] WorkCycle --> Ready["Mark ready to resolve"] Ready --> Proof{"Proof gate:<br/>evidence + note?"} Proof -- "Missing" --> WorkCycle Proof -- "Present" --> Sensitive{"Sensitive / VIP?"} Sensitive -- "No" --> Resolved(["Status = Resolved"]) Sensitive -- "Yes" --> Chair["Chair / DG approval queue"] Chair --> Resolved Resolved --> CSAT[("CSAT window:<br/>accept / reopen / auto-close")]

تحریری وضاحت۔ ایک نئے فائل شدہ ٹکٹ کا S&ITD فرز بندی ان باکس میں آتا ہے، جہاں سہولت کار کی AI مدد کرتا ہے: ایک آٹو-خلاصہ، ایک زمرہ کی تصدیق، ایک فوریت/جذباتی حالت اشارہ، اور ایک مسودہ روٹنگ تجویز۔ سہولت کار زمرہ، ترجیح، SLA، منزل محکمہ/سیکشن، اور حساس/VIP جھنڈے کی تصدیق یا اوورائیڈ کرتا ہے، ٹکٹ کو Triaged میں لے جاتا ہے اور منزل محکمے کی سیکشن قطار میں ڈالتا ہے۔ ایک سیکشن ہیڈ یا AI آٹو-روٹر ایک افسر تفویض کرتا ہے، ٹکٹ کو Assigned میں دھکیلتے ہوئے۔ افسر ورک اسپیس میں، AI پھر مدد کرتا ہے — ایک جواب کا مسودہ تیار کرتا ہے، ایک متعلقہ KB مضون تجویز کرتا ہے، اور PII کو مفت متن سے حذف و ترمیم کرتا ہے۔ افسر پہلا ٹھوس جواب بھیجتا ہے، FRT کو پورا کرتے ہوئے اور ٹکٹ کو In Progress میں پھیرتے ہوئے۔ کام In Progress اور Awaiting Parties کے درمیان متبادل رہتا ہے جیسے کمپنی معلومات فراہم کرتی ہے (ہر روک/جاری SLA گھڑی کو روکتا اور شروع کرتا ہے)۔ جب افسر ٹکٹ کو حل کے لیے تیار کے طور پر نشان زد کرتا ہے، ثبوت گیٹ کم از کم ایک ثبوت منسلکہ اور ایک حل نوٹ کی جانچ کرتا ہے؛ اگر غائب ہو تو، عمل بلاک ہو جاتا ہے اور ٹکٹ ورک سائیکل میں واپس آتا ہے۔ حساس یا VIP ٹکٹس کے لیے حل پیکیج additionally چیئر/DG توثیقی قطار میں روٹ ہوتا ہے۔ گیٹ صاف ہونے کے ساتھ، ٹکٹ Resolved بن جاتا ہے اور CSAT ونڈو کمپنی کے قبول، دوبارہ کھولنے، یا آٹو-کلوز کے لیے کھلتی ہے۔

6.3 سفر 3 — DG / سیکریٹری تک اسکیلیشن

flowchart TD Breach(["Resolution SLA breaches"]) --> Esc(["Status = Escalated<br/>(working context preserved)"]) Esc --> Tier1["Tier 1: +2 business days<br/>DG notified + added as watcher"] Tier1 --> Powers1{"DG action<br/>powers ON?"} Powers1 -- "Yes" --> Dir1["Reassign / override SLA /<br/>force-resolve / directive"] Powers1 -- "No, or still unresolved" --> Wait1["+5 more business days"] Wait1 --> Tier2["Tier 2: Secretary notified + watcher<br/>+ WhatsApp channel"] Tier2 --> Powers2{"Secretary action<br/>powers ON?"} Powers2 -- "Yes" --> Dir2["Directive / override SLA /<br/>force-resolve / reassign"] Powers2 -- "No, or still unresolved" --> Wait2["+10 more business days"] Wait2 --> Tier3["Tier 3: SACM + S&ITD Secretary<br/>+ formal directive letter"] Tier3 --> MinDir["Minister directive ON by default"] Dir1 --> DeEsc(["De-escalate -> In Progress"]) Dir2 --> DeEsc MinDir --> DeEsc DeEsc --> OfficerResolves["Officer resumes; resolves with proof"]

تحریری وضاحت۔ جب کسی ٹکٹ کے حل کا SLA خلاف ورزی کرتا ہے، SLA انجن ٹکٹ کو Escalated میں پھیر دیتا ہے جبکہ بنیادی کام کی حالت محفوظ رکھتا ہے (تاکہ افسر کا سیاق و سباق کبھی ضائع نہ ہو)۔ سطح 1 پر (خلاف ورزی کے بعد دو غیر حل شدہ کاروباری دنوں پر)، محکمے کے DG/ڈائریکٹر کو مطلع کیا جاتا ہے اور بطور ناظر شامل کیا جاتا ہے؛ اگر محکمے نے DG عمل کی طاقتیں تشکیل دی ہوں، تو DG دوبارہ تفویض، SLA اوورائیڈ، زبردستی حل، یا ہدایت جاری کر سکتا ہے۔ اگر ٹکٹ پانچ اور کاروباری دنوں تک غیر حل شدہ رہتا ہے، سطح 2 محکمہ سیکریٹری کو لاتی ہے — وہی اختیاری عمل طاقتوں کے ساتھ، اس کے علاوہ WhatsApp-چینل اطلاعات۔ دس اور غیر حل شدہ کاروباری دنوں کے بعد، سطح 3 SACM (S&IT) اور S&ITD سیکریٹری کو مطلع کرتا ہے، ایک رسمی ہدایت نامے کے ساتھ؛ اس سطح پر وزیر کی ہدایت کی طاقت طے شدہ طور پر آن ہوتی ہے۔ ایک بااختیار نگرانی سطح سے کوئی بھی ہدایت یا عمل ٹکٹ کو In Progress میں واپس کم اسکیل کرتا ہے، جہاں افسر دوبارہ شروع کرتا ہے اور بالآخر اسے ثبوت گیٹ کے ذریعے حل کرتا ہے۔ تمام اسکیلیشن واقعات، اوورائیڈز، اور ہدایات آڈٹ-لاگڈ ہیں۔ 2/5/10-دن کی سیڑھی فی محکمہ اور زمرہ تشکیل کی جانے والی ہے (دیکھیں /specs/ur/06-ticket-workflow/ §6)۔

6.4 سفر 4 — TRI میٹنگ + MoM اپلوڈ اور شیئر

flowchart TD Stall(["Ticket stalled /<br/>escalated tier >= 2"]) --> Req["Request TRI:<br/>company / officer / facilitator / auto"] Req --> OnHold(["Status = On Hold<br/>SLA clock paused"]) OnHold --> Agenda["AI auto-drafts agenda<br/>from ticket history + uploads"] Agenda --> ReviewAg["Facilitator reviews / edits agenda"] ReviewAg --> Modality["Choose modality:<br/>physical / virtual / hybrid"] Modality --> Invite["Send multilingual invites<br/>+ capture recording consent"] Invite --> Held(["TRI meeting held<br/>(3 parties)"]) Held --> Outcome{"Outcome"} Outcome -- "Resolved" --> Upload["Officer uploads MoM<br/>(own format: PDF/Word/images)"] Outcome -- "Action items" --> Upload Outcome -- "Escalate" --> EscNext(["Escalate to next tier<br/>with meeting record"]) Upload --> AV["ClamAV scan + encrypt + store"] AV --> OCR["OCR (multilingual EN/UR/SD)<br/>if scanned"] OCR --> AIEx["AI: summary + action items<br/>+ decisions + attendees + translation"] AIEx --> SideBy["Officer reviews side-by-side<br/>confirms action items -> sub-tasks"] SideBy --> Sens{"Sensitive / VIP?"} Sens -- "No" --> Publish["Publish directly"] Sens -- "Yes" --> ChairApp["Chair / DG approval"] ChairApp --> Publish Publish --> Share["Auto-share participants:<br/>email + in-app + SMS/WhatsApp<br/>acknowledgment tracked"] Publish --> EOffice["Cross-post NITB e-Office<br/>if enabled for dept"]

تحریری وضاحت۔ جب کوئی ٹکٹ رک جائے یا اسکیلیشن سطح 2 یا اس سے اوپر بغیر حرکت کے بیٹھا رہے، تو کمپنی، افسر، سہولت کار، یا آٹو-ٹرگر میں سے کوئی بھی TRI (سہ فریقی جائزہ) میٹنگ کی درخواست کر سکتا ہے۔ درخواست ٹکٹ کو On Hold میں پارک کرتی ہے (SLA گھڑی کو روکتے ہوئے) اور AI ٹکٹ کی مکمل تاریخ اور اپلوڈز سے ایجنڈا آٹو-تیار کرتا ہے، جس کا سہولت کار جائزہ لیتا اور مدون کرتا ہے۔ طریقہ — физکی، ورچوئل (Zoom/Meet/Teams)، یا ہائبرڈ — فی میٹنگ منتخب کیا جاتا ہے، کثیر لسانی دعوتیں بھیجی جاتی ہیں، اور ریکارڈنگ کی رضامندی حاصل کی جاتی ہے۔ تین فریقی میٹنگ کے بعد، سہولت کار نتیجہ ریکارڈ کرتا ہے۔ حل شدہ یا جزوی نتیجے کے لیے، ذمہ دار افسر MoM کو محکمے کے اپنے فارمیٹ میں اپلوڈ کرتا ہے؛ فائل ClamAV-اسکین، خفیہ کاری، اور محفوظ کی جاتی ہے۔ سکین شدہ دستاویزات پلگ ایبل کثیر لسانی OCR انجن (انگریزی، اردو/نستعلیق، سندھی/نسخ) سے گزرتی ہیں، اور AI ایک خلاصہ، مالکان اور آخری تاریخیں کے ساتھ ساختی ایکشن آئٹمز، فیصلے، اور شرکاء، اس کے علاوہ مشین ترجمے نکالتا ہے۔ افسر نکالنے کا اصل کے ساتھ ساتھ ساتھ جائزہ لیتا اور تصدیق کرتا ہے؛ تصدیق شدہ ایکشن آئٹمز ٹکٹ پر ذیلی-ٹاسکس بن جاتے ہیں۔ عام ٹکٹس کے لیے افسر براہِ راست شائع کرتا ہے؛ حساس یا VIP ٹکٹس کے لیے MoM کو پہلے چیئر/DG توثیق سے گزرنا پڑتا ہے۔ شائع کرنے پر، MoM نسخہ شدہ اور مستقل طور پر منسلک ہوتی ہے، تمام شرکاء کو ای میل، اِن-ایپ، اور SMS/WhatsApp کے ذریعے ان کی ترجیحات کے مطابق آٹو-شیئر کی جاتی ہے (تسلیمیات کا ٹریک اور یاد دلایا جاتا ہے)، اور جہاں فعال ہو NITB e-Office پر کراس-پوسٹ کی جاتی ہے۔ اگر میٹنگ مسئلہ حل نہ کر سکے، تو ٹکٹ میٹنگ ریکارڈ کے ساتھ اگلی سطح تک اسکیلیٹ ہوتا ہے۔

6.5 سفر 5 — کمپنی اپیل کرتی ہے

flowchart TD Closed(["Ticket Resolved or Closed"]) --> Decide{"Company action<br/>within window"} Decide -- "Poor CSAT (<= threshold)" --> Enable["Appeal path enabled + pre-filled<br/>+15-day grace"] Decide -- "Manual" --> Form["File appeal<br/>(within 30 days of closure)"] Enable --> Form Form --> Route["Route to next oversight tier<br/>above the one that closed it"] Route --> Review["Authority reviews"] Review --> Decision{"Decision"} Decision -- "Uphold" --> Work(["Back to In Progress<br/>+ directive to section"]) Decision -- "Partially uphold" --> Partial["Sub-tasks added;<br/>In Progress for those items"] Decision -- "Re-route" --> Triaged(["Status = Triaged<br/>different section / dept"]) Decision -- "Reject" --> Letter["Generate rejection letter<br/>+ QR verification"] Letter --> Final(["Status = Closed — terminal"])

تحریری وضاحت۔ ایک Resolved یا Closed ٹکٹ سے، کمپنی کے پاس CPGRAMS-طرز کا اپیل پاتھ اپنی مدت کے اندر ہوتا ہے (طے شدہ بندش سے 30 کیلنڈر دن)۔ ایک کمزور CSAT ریٹنگ (تشکیل کردہ حد کے برابر یا اس سے نیچے) خود بخود اپیل فارم کو فعال اور پہلے سے بھرتی ہے اور مدت کو ایک مہلت کی مدت تک بڑھاتی ہے (طے شدہ +15 دن)؛ کمپنی ایک دستی اپیل بھی فائل کر سکتی ہے۔ اپیل اس نگرانی سطح کے اوپر والی اگلی سطح کی طرف روٹ ہوتی ہے جس نے ٹکٹ بند کیا تھا — ورکنگ لیول پر بند شدہ ٹکٹ DG کے پاس جاتا ہے؛ DG کے دائرہ کار میں بند ہونے والا سیکریٹری کے پاس؛ سیکریٹری کے دائرہ کار میں بند ہونے والا SACM اور S&ITD سیکریٹری کے پاس جاتا ہے۔ جائزہ لینے والا اتھارٹی برقرار رکھ سکتا ہے (ٹکٹ سیکشن کے لیے ہدایت کے ساتھ In Progress میں واپس آتا ہے)، جزوی برقرار رکھ سکتا ہے (مخصوص ایکشن آئٹمز ذیلی-ٹاسکس بن جاتے ہیں اور ٹکٹ صرف ان آئٹمز کے لیے In Progress میں واپس آتا ہے)، دوبارہ روٹ کر سکتا ہے (ٹکٹ ایک مختلف سیکشن یا محکمے کے لیے Triaged میں چلا جاتا ہے)، یا مسترد کر سکتا ہے (بندش حتمی ہو جاتی ہے اور ایک QR-تصدید شدہ مسترد خط تیار اور بھیجا جاتا ہے)۔ ہر فیصلہ اداکار، سطح، استدلال، اور نتیجے کے عمل کے ساتھ آڈٹ ہوتا ہے۔

6.6 سفر 6 — سیکریٹری نگرانی ڈیش بورڈ

flowchart LR Login(["Secretary logs in"]) --> Dash["Secretary oversight dashboard"] Dash --> KPIs["Dept KPIs:<br/>open / breached / near-breach / escalated"] Dash --> TierView["Escalation tier view:<br/>DG / Secretary / Minister queues"] Dash --> Heat["GIS / district heatmap"] Dash --> Repeat["SLA breach + repeat-offender list"] KPIs --> Drill["Drill into a ticket"] TierView --> Drill Repeat --> Drill Drill --> Action{"Action powers<br/>for this dept?"} Action -- "Yes" --> Directive["Send directive / override SLA /<br/>force-resolve / reassign /<br/>approve sensitive-VIP closure"] Action -- "No (notify-only)" --> Notify["Comment / watch / receive alerts"] Directive --> Audited[("Audited event + reason")] Notify --> Audited

تحریری وضاحت۔ ایک محکمہ سیکریٹری (یا DG، یا وزیر) لاگ اِن کرتا ہے اور اپنے محکمے کے دائرہ کار کے نگرانی ڈیش بورڈ پر آتا ہے (SACM کے لیے کراس-محکمہ)۔ ڈیش بورڈ محکمہ KPIs (کھلے، خلاف ورزی، قریب-خلاف ورزی، اسکیلیٹڈ شمار)، DG، سیکریٹری، اور وزیر قطاروں کو الگ کرتے ہوئے ایک اسکیلیشن-سطح منظر، حل کی کارکردگی کا GIS/ضلع ہیٹ میپ، اور بار بار اسکیلیشن کرنے والے افسران یا سیکشنز کو نمایاں کرتے ہوئے دہرانے والے-مجرم فہرست ظاہر کرتا ہے۔ سیکریٹری کسیی بھی KPI، سطح، یا مجرم سے بنیادی ٹکٹ تفصیل میں ڈرل کرتا ہے۔ آیا سیکریٹری پھر عمل کر سکتا ہے، یہ محکمے کی تشکیل کردہ نگرانی طاقتوں پر منحصر ہے: عمل طاقتیں آن ہونے کے ساتھ، سیکریٹری ہدایت بھیج، SLA اوورائیڈ، زبردستی حل، دوبارہ تفویض، یا حساس/VIP بندش توثیق کر سکتا ہے؛ صرف-مطلع موڈ میں سیکریٹری تبصرہ، نگرانی، اور الرٹس وصول کرنے تک محدود ہے۔ ہر عمل کے لیے ایک وجہ درکار ہوتی ہے اور ایک غیر قابلِ تبدیل آڈٹ واقعہ لکھتا ہے۔

6.7 سفر 7 — گمنام / وسل بلوور انٹیک

flowchart TD Public(["Public site"]) --> WB["Whistleblower / Anonymous intake"] WB --> NoLogin["No login required"] NoLogin --> Topic["Pick topic:<br/>corruption / harassment / safety / other"] Topic --> Details["Provide details<br/>+ optional encrypted contact"] Details --> Guard["CAPTCHA + rate-limit + abuse filter"] Guard --> Token[("One-way token generated<br/>reporter identity NOT stored")] Token --> Restricted(["Restricted-visibility ticket<br/>visible only to S&ITD<br/>whistleblower role + Secretary"]) Restricted --> Track["Check status by token<br/>read-only, no login"] Restricted --> SLA["Standard SLA + escalation apply<br/>oversight notifications omit<br/>filer-identifying info"] Restricted --> NotifyOpt["Optional encrypted contact<br/>used only if reporter opted in"]

تحریری وضاحت۔ ایک وسل بلوور لاگ اِن کیے بغیر عوامی سائٹ سے گمنام انٹیک چینل تک پہنچتا ہے۔ وہ ایک موضوع منتخب کرتا ہے (بدعنوانی، ہراسانی، حفاظت، دیگر)، تفصیلات فراہم کرتا ہے، اور اختیاری طور پر ایک خفیہ رابطہ طریقہ شامل کر سکتا ہے۔ CAPTCHA، ریٹ-لیمٹنگ، اور ایک abus فلٹر چینل کی حفاظت کرتے ہیں۔ جمع کرانے پر ایک یک طرفہ ٹوکن تیار ہوتا ہے اور رپورٹر کی شناخت کلئیر ٹیکسٹ میں محفوظ نہیں کی جاتی؛ نتیجے کا ٹکٹ محدود-دکھائی دینے والا ہوتا ہے، صرف مخصوص S&ITD وسل بلوور-سنبھالنے والے کردار اور، اختیاری طور پر، S&ITD سیکریٹری کو نظر آتا ہے۔ رپورٹر اپنے ٹوکن کا استعمال کرتے ہوئے، بغیر کسی لاگ اِن کے، حالت کو صرف پڑھنے کے لیے چیک کرتا ہے۔ معیاری SLA اور اسکیلیشن لاگو ہوتے ہیں، مگر تمام نگرانی اطلاعات فائلر کی شناخت کی معلومات کو نظر انداز کرتی ہیں۔ اگر رپورٹر نے خفیہ رابطہ کے لیے آپٹ اِن کیا ہو، تو اس کا استعمال صرف تعاقب کے لیے ہوتا ہے۔ retenшн /specs/ur/24-trust-safety/ میں وسل بلوور پالیسی کی پیروی کرتا ہے۔

6.8 سفر 8 — ایڈمن محکمہ / SLA / AI تشکیل کرتا ہے

flowchart TD Admin(["Super Admin / Dept Admin"]) --> Console["Admin console"] Console --> StepUp["Step-up auth<br/>(fresh 2FA for config actions)"] StepUp --> Branch{"Configure"} Branch -- "Department" --> Dept["Create / edit dept + sub-depts<br/>(freely nestable tree)"] Branch -- "SLA" --> SLA["SLA definitions per<br/>dept/category/priority<br/>FRT + resolution targets"] Branch -- "Escalation" --> EscLad["Escalation ladder<br/>tiers + triggers +<br/>oversight powers per tier"] Branch -- "AI engines" --> AIEng["Pluggable engines:<br/>cloud <-> self-hosted toggle<br/>+ OCR engine select"] Branch -- "Feature flags" --> Flags["Toggle any capability<br/>per dept / env<br/>(two-person approval<br/>for sensitive flags)"] Dept --> Audited[("Audit log:<br/>old/new value + reason")] SLA --> Audited EscLad --> Audited AIEng --> Audited Flags --> Audited Audited --> Propagate["Changes propagate:<br/>navigation, dashboards,<br/>letters, Officials CMS,<br/>ticket behaviour"]

تحریری وضاحت۔ ایک سپر ایڈمن (یا محکمہ ایڈمن، اپنے دائرہ کار کے اندر) ایڈمن کنسول کھولتا ہے اور تشکیلی اقدامات کے لیے اسٹیپ-اپ تصدیق مکمل کرتا ہے۔ وہاں سے وہ اپنی ضرورت کی تشکیلی سطح میں شاخ بنتے ہیں۔ محکمہ تشکیل محاکم اور آزادانہ طور پر نسٹڈ ذیلی-محاکم بناتی یا مدون کرتی ہے۔ SLA تشکیل sla_definitions صفوف کو مدون کرتی ہے جو فی محکمہ/زمرہ/ترجیح FRT اور حل اہداف کو باندھتی ہیں۔ اسکیلیشن تشکیل escalation_ladders سطحوں اور ٹرگرز اور oversight_powers میٹرکس کو مدون کرتی ہے جو ہر نگرانی کردار کو صرف-مطلع اور عمل کے درمیان ٹوگل کرتی ہے۔ AI انجنز تشکیل پلگ ایبل LLM (کلاؤڈ بمقابلہ سیلف-ہوسٹڈ) اور OCR انجن کو منتخب کرتی ہے، ایک ٹیسٹ-کنکشن کنٹرول کے ساتھ۔ فیچر فلیگز کوئی بھی صلاحیت فی محکمہ یا ماحول ٹوگل کرتے ہیں، حساس عالمی فلیگز (جیسے ثبوت گیٹ کو غیر فعال کرنا) کے لیے دو-فردی توثیق درکار ہوتی ہے۔ ہر تشکیلی تبدیلی کو پرانی قدر، نئی قدر، اداکار، اور ایک لازمی تبدیلی-وجہ کے ساتھ آڈٹ-لاگ کیا جاتا ہے، اور تبدیلی فوراً نیویگیشن، ڈیش بورڈز، تیار کردہ خطوط، Officials CMS، اور لائیو ٹکٹ رویے میں پھیلتی ہے۔


7. وائر فریم بریفز (اہم اسکرینز)

نو تحریری ترتیب کی بریفز — خطہ بہ خطہ وضاحتیں، تصویریں نہیں۔ یہ طے شدہ ڈیسک ٹاپ ترتیب کی وضاحت کرتی ہیں؛ موبائل موافقت جہاں مواد ہو نوٹ کی گئی ہے اور §9 کی پیروی کرتی ہے۔ بصری علاج (رنگ، قسم، اجزاء) /specs/ur/16-branding-design-system/ میں تعین ہے۔

7.1 ہوم / عوامی لینڈنگ

7.2 فائل-ٹکٹ وزرڈ (متحرک شرطی فیلڈز)

ایک پانچ مرحلہ وزرڈ جس میں چپکا ہوا اسٹیپر ہیڈر اور سیاق و سباق کا AI ریل ہے۔

7.3 ٹکٹ تفصیل

7.4 افسر ورک اسپیس

7.5 نگرانی ڈیش بورڈ (DG / سیکریٹری / وزیر)

7.6 TRI میٹنگ پیج

7.7 MoM دیکھنے والا

7.8 تجزیات

7.9 ایڈمن فیچر-فلیگز


8. ڈیزائن-سسٹم حوالہ

تمام بصری علاج — پیلیٹ، ٹائپوگرافی، آئیکنوگرافی، اجزاء — /specs/ur/16-branding-design-system/ میں تعین ہے۔ یہ دستاویز اسے استعمال کرتی ہے؛ اہم ٹچ پوائنٹس یہ ہیں:


9. ریسپانسو بریک پوائنٹس

SITP موبائل-فرسٹ بنایا گیا ہے۔ بریک پوائنٹس اسٹیک کے پار استعمال ہونے والے Tailwind طے شدہ کی پیروی کرتے ہیں (دیکھیں /specs/ur/15-tech-architecture/):

بریک پوائنٹ کم از کم چوڑائی رویہ
base (موبائل) 0 px (طے شدہ) سنگل کالم؛ ہیمبرگر نیویگیشن؛ اسٹیکڈ کارڈز؛ بوٹم-ڈراور AI پینل؛ PWA بنیادی ہدف۔
sm 640 px جہاں مفید ہو دو-کالم گرڈز؛ ان لائن فارم فیلڈز جوڑے بنتے ہیں۔
md 768 px مستقل بائیں نیویگیشن ظاہر ہوتی ہے؛ ٹیبلز کو دوسرا طول ملتا ہے؛ اسٹیپر ان لائن رہتا ہے۔
lg 1024 px سائڈ ریلز (ٹکٹ تفصیل، نگرانی ڈیش بورڈ) بنیادی کالم کے ساتھ ظاہر ہوتی ہیں۔
xl 1280 px تین-کالم تجزیات ترتیبیں؛ ملٹی-پین ایڈمن کنسول۔
2xl 1536 px وائیڈ ڈیش بورڈز پھیلتے ہیں؛ پڑھنے کے لیے زیادہ سے زیادہ مواد چوڑائی کیپ۔

PWA رویہ۔ ہوم اسکرین پر انسٹال قابل؛ صرف پڑھنے کے ٹکٹ مناظر اور مسودہ کمپوزیشن کے لیے آف لائن تعاون (دوبارہ کنکٹ پر قطار میں جمع کرائیں)؛ جہاں ویب تعاون دے وہاں پش اطلاعات۔ ٹچ ہدف کم از کم 44×44 px ہیں۔ مستقبل کا React Native ایپ وہی نیویگیشن ماڈل اور API معاہدہ دوبارہ استعمال کرتا ہے۔


10. خالی / لوڈنگ / خرابی حالتیں

ہر فہرست، ڈیش بورڈ، اور فارم تینوں حالتوں کو واضح طور پر تعین کرتا ہے۔ حالتیں ایماندار، بحال کرانے والی، اور برانڈ کے مطابق ہیں۔

10.1 خالی حالتیں

10.2 لوڈنگ حالتیں

10.3 خرابی حالتیں


11. "کافی سادہ" ہیپی پاتھس کا خلاصہ

اوپر آٹھ سفر دلچسپ ہیں، مگر ہر کردار کی ہیپی پاتھ — وہ پاتھ جس کے لیے سسٹم بہترین بناتا ہے — جان بوجھ کر مختصر ہے۔ یہ وہ تجربات ہیں جن کی 3-کلک اصول (§2.2) حفاظت کرتا ہے۔

# اداکار ہیپی پاتھ مراحل
1 کمپنی (واپس آتا ہوا نمائندہ) ہوم → "ٹکٹ فائل کریں" → جمع کریں → ٹکٹ دیکھیں → (بعد میں) قبول + CSAT۔ 5
2 کمپنی (پہلی بار) ہوم → رجسٹر (ادارہ قسم + بنیادی نمائندہ) → پہلا ٹکٹ فائل کریں → ٹریک۔ 4 مراحل
3 محکمہ افسر تفویض شدہ ٹکٹ دیکھیں → پہلا جواب بھیجیں → ثبوت کے ساتھ حل کریں۔ 3
4 نگرانی (DG/سیکریٹری/وزیر) ڈیش بورڈ پر خلاف ورزی دیکھیں → عمل کریں (ہدایت/اوورائیڈ/توثیق) یا تبصرہ۔ 2
5 S&ITD سہولت کار فرز بندی ان باکس → روٹنگ تصدیق → (بعد میں) TRI بلائیں + MoM اپلوڈ کریں۔ 3
6 کمپنی (رکا ہوا) ٹکٹ → "TRI درخواست" → شرکت → شیئر شدہ MoM وصول کریں → تسلیم۔ 4
7 شہری / گمنام ہوم → فائل (یا وسل بلوور انٹیک) → آئی ڈی/ٹوکن سے ٹریک۔ 2
8 ایڈمن کنسول → اسٹیپ-اپ تصدیق → ایک تشکیل بدلیں (محکمہ/SLA/AI/فلیگ) → آڈٹ شدہ۔ 3

انگلی کا اصول: اگر ہیپی پاتھ کو ایک مدد مضون کی ضرورت ہے تو، ڈیزائن ابھی کافی سادہ نہیں ہے۔


12. کراس ریفرنسز

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