SMS GROUP โ PROJECT DELIVERY PLAN
Reference: SMS-2026-002-PM
Version: 1.0
Date: 2026-05-31
PM: Product Manager Agent
Parent Issue: SMS-11
PROJECT SUMMARY
SMS Group is delivering backend integration for ITECH Buildings Contracting's existing PWA Lighting Tracker โ covering 9,766 fixtures across 23 MoH health centers in Al-Lith and Adham governorates, Saudi Arabia. The system requires: API backend, JWT auth, 6-role RBAC (STCE financial blackout), offline sync, bilingual AR/EN, OOS claims workflow, automated reporting, and full audit logging. Fixed delivery window: 7 calendar days from Day 0 client handover. Design/UI is already complete โ SMS Group delivers backend integration only.
VALIDATION STATUS
| Check | Status | Note |
|---|---|---|
| Features clearly defined | โ PASS | All 10 features scoped with sufficient detail |
| Tech stack confirmed | โ ๏ธ PARTIAL | Frontend PWA stack unknown โ Day 1 assessment mandatory |
| Third-party integrations | โ PASS | PostgreSQL/Supabase only โ no external APIs |
| Security requirements | โ PASS | Custom JWT + RBAC + STCE financial blackout specified |
| Client approval process | โ ๏ธ GAP | Client sign-off contact not confirmed โ must be resolved Day 0 |
| UI/UX dependency | โ CLEAR | Design/UI complete โ no design blocker |
| Security Auditor review | โ REQUIRED | Auth, RBAC, audit log must go through Security Auditor Day 1-2 |
| Payment schedule | โ ๏ธ GAP | Deposit confirmation listed as blocker โ milestone payments undefined |
Brief is APPROVED to proceed. Two gaps (client sign-off contact, payment schedule) must close on Day 0.
ASSUMPTIONS & DEPENDENCIES
- SMS Group scope is backend integration ONLY โ all UI screens are designed and coded
- Client provides GitHub repo URL + credentials before Day 1 09:00
- Client provides PostgreSQL/Supabase connection string + existing schema before Day 1 09:00
- Budget deposit confirmed and received before Day 1 09:00 โ no work starts without payment
- Client designates one named contact (name + email + phone) reachable within 2 hours during project
- PWA frontend is compatible with standard REST API + WebSocket patterns
- No new feature requests during the 7-day window โ any change triggers formal renegotiation
- 6 named users are available for training sessions on Day 7
- Supabase project is already provisioned (or PostgreSQL instance is accessible)
- Existing frontend has i18n capability โ backend provides bilingual field keys
- PWA supports service worker and Background Sync API (required for offline feature)
- SMS Group internal infrastructure (dev/staging/production environments) is available
- No external licensing or approval required from STCE for system go-live
- Client accepts 7-day timeline is conditional on Day 0 deliverables received on time
HARD BLOCKERS (Day 0 โ Must Arrive Before Day 1 09:00)
| # | Blocker | Owner | Deadline | If Missing |
|---|---|---|---|---|
| 1 | GitHub repo URL + credentials | ITECH Client | Day 0 EOB | Day 1 assessment delayed โ escalate to Hisham immediately |
| 2 | PostgreSQL/Supabase connection string + schema | ITECH Client | Day 0 EOB | Backend cannot start โ escalate to Hisham immediately |
| 3 | Budget deposit confirmed (receipt) | ITECH Client / Account Manager | Day 0 EOB | All work stops โ no exceptions |
| 4 | Client contact: name, email, phone | ITECH Client | Day 0 EOB | No escalation path during project |
USER STORIES
Feature 1: Project Dashboard
As an Operations Director or Project Manager,
I want to view a real-time dashboard showing fixture completion percentages per site, outstanding OOS claims, and team activity,
So that I can monitor project health without contacting individual engineers.
Acceptance Criteria: - [ ] Dashboard loads in <3 seconds on mobile (3G connection) - [ ] Shows per-site fixture counts: total / complete / pending / OOS - [ ] Updates within 30 seconds of any field engineer action - [ ] STCE Representative sees operational data ONLY โ zero financial figures - [ ] Bilingual toggle works on dashboard without page reload - [ ] Works offline (last-cached data displayed with timestamp)
Definition of Done: Renders correctly on 360px mobile, STCE visibility test passed, QA smoke test signed off
Assigned to: Backend Developer
Estimated hours: 8h
Dependencies: DB schema confirmed, JWT Auth complete, RBAC middleware complete
Priority: Core
Feature 2: Site + Fixture Tracker
As a Team Engineer in the field,
I want to update individual fixture status, upload photos, and log notes per fixture from my phone,
So that the central system has an accurate, timestamped record of every fixture's state.
Acceptance Criteria: - [ ] All 9,766 fixtures loadable, filterable by site (23 sites), status, and type - [ ] Per-fixture update: status change + minimum 1 photo upload + optional notes - [ ] Photos stored as compressed thumbnail + full-size original - [ ] Sync triggers automatically when connectivity restored after offline session - [ ] Offline update queue survives app close and device restart - [ ] Audit entry created for every fixture status change
Definition of Done: Load test with 9,766 records passes (<2s query), offline add/update syncs correctly in QA, photo upload functional
Assigned to: Backend Developer
Estimated hours: 16h
Dependencies: DB schema, JWT Auth, Offline module
Priority: Core
Feature 3: OOS Works Module
As a Project Manager,
I want to submit Out-of-Scope work claims with electronic approval and photo evidence,
So that ITECH has a defensible, timestamped paper trail for any payment dispute with STCE.
Acceptance Criteria: - [ ] OOS claim fields: fixture reference, work description, photo(s), estimated cost, date - [ ] Two-step approval: PM electronic approval + paper document photo attachment - [ ] STCE Representative cannot access cost or financial fields at API level (403 on financial endpoints) - [ ] Every OOS status change creates an immutable audit log entry - [ ] Individual OOS claim exportable as PDF - [ ] OOS claims workable offline, synced when connectivity restored
Definition of Done: Dual approval flow tested end-to-end, STCE financial blackout verified via API test, audit entries present for all transitions
Assigned to: Backend Developer
Estimated hours: 12h
Dependencies: JWT Auth, RBAC, Audit Log, Photo upload infrastructure
Priority: Core
Feature 4: Role-Based Access Control (RBAC)
As the system enforcing client confidentiality,
I must ensure STCE Representative receives zero financial data โ enforced at the API response layer, not client-side,
So that ITECH's commercial position is protected regardless of how the frontend renders data.
Acceptance Criteria: - [ ] 6 roles defined with permission matrix: Operations Director, Project Manager, Team A/B/C Engineers, STCE Representative - [ ] Financial fields stripped server-side before API response (not filtered in frontend) - [ ] Unauthorized requests return HTTP 403 โ not an empty filtered response - [ ] Role assignments manageable by Operations Director only - [ ] Security Auditor written sign-off on RBAC implementation before feature goes to QA
Definition of Done: Security Auditor review passed, penetration test confirms no financial data leakage through any API endpoint
Assigned to: Backend Developer (Security Auditor mandatory review)
Estimated hours: 10h
Dependencies: JWT Auth implementation
Priority: Core โ Security-gated (no other features build without this)
Feature 5: Offline Mode + Auto-Sync
As a Team Engineer working in remote areas with intermittent connectivity,
I want the app to capture all my field actions offline and sync automatically when signal returns,
So that I never lose data due to poor connectivity.
Acceptance Criteria: - [ ] Fixture updates, photo captures, OOS submissions all queue when offline - [ ] Sync triggers automatically on connectivity restoration (no manual action) - [ ] Offline queue persists across app close and device restart - [ ] Conflict resolution: last-write-wins with full timestamp logging - [ ] User notified when sync completes (in-app notification) - [ ] Sync status indicator visible at all times
Definition of Done: Airplane mode test passed in QA (offline โ add data โ reconnect โ verify sync), conflict scenario documented and tested
Assigned to: Backend Developer
Estimated hours: 12h
Dependencies: PWA service worker compatibility confirmed Day 1, Background Sync API supported
Priority: Core โ Critical for field usability
Feature 6: Bilingual AR/EN
As any user,
I want to switch between Arabic and English instantly,
So that Arabic-speaking engineers and English-speaking supervisors use the same system without friction.
Acceptance Criteria: - [ ] Language toggle accessible from every screen without page reload - [ ] Arabic: RTL layout, proper text alignment, no layout breakage - [ ] English: LTR layout - [ ] Backend API returns field keys compatible with frontend i18n (confirmed Day 1) - [ ] No text truncation or UI overflow in RTL mode on 360px mobile screen
Definition of Done: Both language modes tested on 360px screen, zero truncation/overflow issues found in QA
Assigned to: Backend Developer (backend string keys + API structure)
Estimated hours: 6h
Dependencies: Day 1 confirmation of frontend i18n approach
Priority: Core
Feature 7: In-App Notifications
As any user,
I want to receive notifications when an OOS claim changes status or when sync completes,
So that I stay informed without constantly polling the app.
Acceptance Criteria: - [ ] Push notifications for: OOS status change, sync completion, approaching reporting deadline - [ ] Notifications delivered on reconnect if generated during offline period - [ ] Users can configure which notifications they receive - [ ] Works on mobile browser (PWA push notification support)
Definition of Done: All 3 notification types triggered and received in QA testing
Assigned to: Backend Developer
Estimated hours: 8h
Dependencies: JWT Auth (user token for push subscription), PWA push support confirmed Day 1
Priority: Core
Feature 8: Reporting Module
As an Operations Director or Project Manager,
I want to generate weekly PDF reports for STCE and Excel exports for internal use,
So that reporting is automated, accurate, and tamper-evident.
Acceptance Criteria: - [ ] Weekly STCE PDF: fixtures per site, OOS summary (NO cost data), progress percentage - [ ] Internal Excel: full data including OOS costs and financial summaries - [ ] Reports generated on-demand AND scheduled (weekly auto-generate) - [ ] PDF includes ITECH logo and report signature line - [ ] Reports stored and accessible for minimum 90 days - [ ] STCE PDF verified at API level to contain zero financial fields
Definition of Done: PDF and Excel generated correctly, STCE PDF passes financial data audit, QA sign-off received
Assigned to: Backend Developer
Estimated hours: 10h
Dependencies: Reporting library selected Day 1, RBAC complete, Fixture Tracker data available
Priority: Core
Feature 9: Full Audit Log
As an Operations Director,
I want every system action logged with user, timestamp, and before/after state,
So that ITECH has an immutable, exportable audit trail for any dispute with STCE or internal investigation.
Acceptance Criteria: - [ ] All mutations logged: fixture updates, OOS changes, user actions, login/logout events - [ ] Each log entry includes: user ID, role, timestamp (UTC+3), IP address, action type, record ID, before/after JSON - [ ] Audit log is read-only โ no delete or edit API exists - [ ] Exportable by date range (CSV/Excel) - [ ] Accessible to Operations Director only
Definition of Done: Audit entries present for 100% of testable actions in QA regression suite
Assigned to: Backend Developer
Estimated hours: 8h
Dependencies: DB schema (audit_log table), runs in parallel with all feature development
Priority: Core โ Must be built first as a cross-cutting concern
Feature 10: User Training
As each of the 6 named system users,
I want a 30-minute guided training session tailored to my role,
So that I can use the system independently from Day 8 onwards.
Acceptance Criteria: - [ ] 6 individual or small-group training sessions completed (30 min each) - [ ] Each session covers role-specific features only - [ ] Bilingual quick-reference guide provided (1 page, AR/EN) - [ ] All users sign training completion confirmation - [ ] Q&A session recorded or summarized for knowledge base
Definition of Done: All 6 users trained and sign-off sheets collected, quick-reference guide delivered
Assigned to: PM (facilitation), Backend Developer (technical support)
Estimated hours: 4h (3h sessions + 1h prep)
Dependencies: System deployed and accessible to users
Priority: Core
SPRINT PLAN
Sprint 0 โ Client Handover (Day 0: 2026-05-31)
Goal: Receive all project dependencies from ITECH before development begins.
| Task | Owner | Hours | Dependency | Acceptance Criteria |
|---|---|---|---|---|
| Request and receive GitHub repo credentials | PM โ Client | 1h | Contract signed | Credentials received and tested |
| Request and receive DB connection string + schema | PM โ Client | 1h | Contract signed | Connection string tested, schema documented |
| Confirm budget deposit received | Account Manager | 1h | Contract signed | Receipt in hand |
| Confirm named client contact | PM โ Client | 0.5h | โ | Name + email + phone confirmed |
| PM sends Day 1 kickoff schedule to Backend Dev | PM | 0.5h | All above | Backend Dev confirms 09:00 start |
| Security Auditor briefed on RBAC requirements | PM โ Security Auditor | 1h | Brief received | Security Auditor acknowledges and schedules Day 1 review |
Definition of Done: All 4 hard blockers resolved. If any are missing by Day 0 17:00 โ PM escalates to Hisham immediately for client renegotiation.
Sprint 1 โ Foundation & Assessment (Day 1: 2026-06-01) โ HOUR-BY-HOUR
Goal: Assess existing codebase, confirm tech stack, design DB schema, begin JWT auth and RBAC foundation.
Hour-by-Hour Breakdown โ Day 1
| Time | Task | Owner | Output |
|---|---|---|---|
| 09:00โ09:30 | PM + Backend Dev kickoff call โ confirm Day 0 deliverables received | PM + Backend Dev | Go/No-Go confirmed |
| 09:30โ10:30 | Backend Dev clones repo, installs dependencies, documents frontend tech stack | Backend Dev | Tech stack report (framework, PWA config, existing API patterns) |
| 10:30โ11:30 | Backend Dev reviews existing DB schema (or designs from scratch if none exists) | Backend Dev | Schema gap analysis |
| 10:30โ11:30 | Security Auditor reviews auth + RBAC requirements, produces specification | Security Auditor | RBAC permission matrix draft |
| 11:30โ12:00 | Backend Dev confirms: PWA service worker compatibility, i18n approach, push notification support | Backend Dev | Offline + i18n feasibility confirmed |
| 12:00โ12:30 | PM reviews tech stack report โ validates against plan, identifies any deviations | PM | Deviation log (if any) |
| 12:30โ13:00 | Backend Dev proposes DB schema for all 10 features | Backend Dev | Schema draft |
| 13:00โ13:30 | PM ESCALATION WINDOW โ if any blocker identified, escalate to Hisham NOW (4h rule from 09:30) | PM | Blocker report or green light |
| 13:30โ15:00 | Backend Dev implements DB schema in Supabase/PostgreSQL | Backend Dev | Schema live in dev environment |
| 13:30โ15:00 | Backend Dev begins JWT auth implementation (login, token refresh, logout) | Backend Dev | Auth endpoints functional |
| 15:00โ16:00 | Security Auditor reviews JWT implementation โ flags issues | Security Auditor | Auth review notes |
| 15:00โ17:00 | Backend Dev implements RBAC middleware with 6 roles and permission matrix | Backend Dev | RBAC middleware functional |
| 16:00โ17:00 | Backend Dev begins Audit Log schema + middleware (cross-cutting concern, must start Day 1) | Backend Dev | Audit log captures auth events |
| 17:00โ17:30 | PM daily standup โ status update on SMS-12, confirm Day 2 plan | PM | Day 2 go/no-go |
Day 1 Acceptance Criteria: - [ ] Tech stack documented and confirmed feasible - [ ] DB schema live in dev environment - [ ] JWT auth endpoints functional (login, refresh, logout) - [ ] RBAC middleware blocking unauthorized requests - [ ] Audit log capturing auth events - [ ] No unresolved blockers by 13:30
Definition of Done: Backend Dev confirms all 5 above checked. PM confirms no unresolved blockers.
Day 1 Escalation Triggers: - GitHub credentials not received by 09:00 โ STOP, escalate to Hisham immediately - DB connection fails โ escalate to Hisham by 10:00 - PWA tech stack incompatible with planned backend approach โ escalate by 13:30 - Any dependency requires >4h to resolve โ escalate to Hisham, client renegotiation begins
Sprint 2 โ Core Backend Development (Days 2โ3: 2026-06-02 to 2026-06-03)
Goal: Complete all backend APIs for Fixture Tracker, Dashboard, OOS Module, and Offline Sync.
Day 2 Tasks
| Task | Owner | Hours | Dependency | Acceptance Criteria |
|---|---|---|---|---|
| Security Auditor: Final RBAC sign-off after Day 1 review | Security Auditor | 2h | Day 1 RBAC implementation | Written sign-off or change requests issued |
| Backend: Site + Fixture Tracker API (CRUD + photo upload) | Backend Dev | 8h | DB schema, Auth, RBAC | 9,766 fixtures loadable, per-fixture update working |
| Backend: Photo upload service (thumbnail + full-size) | Backend Dev | 3h | Infrastructure confirmed | Photos stored, retrievable |
| Backend: Offline sync backend (conflict resolution logic) | Backend Dev | 4h | DB schema | Sync endpoint accepts queued updates, resolves conflicts |
| Audit log: Fixture + OOS events wired | Backend Dev | 2h | Audit log middleware | Every fixture update logged |
Day 3 Tasks
| Task | Owner | Hours | Dependency | Acceptance Criteria |
|---|---|---|---|---|
| Backend: Project Dashboard API | Backend Dev | 4h | Fixture Tracker API | Dashboard endpoint returns per-site counts, OOS summary |
| Backend: OOS Works Module API (create, approve, photo attach) | Backend Dev | 6h | Auth, RBAC, Audit | OOS claim lifecycle functional, dual approval working |
| Backend: Bilingual response structure (AR/EN keys) | Backend Dev | 3h | i18n approach confirmed Day 1 | API responses bilingual-ready |
| Backend: Notification service (push subscription + trigger) | Backend Dev | 3h | Auth, PWA push confirmed | Push notification sent on OOS status change |
| PM: Mid-project status update comment on SMS-12 | PM | 0.5h | Day 3 EOD | Status posted |
Sprint 2 Definition of Done: All Phase 1 APIs functional in dev environment, Security Auditor sign-off on RBAC, zero unresolved blockers entering Day 4.
Sprint 3 โ Feature Completion (Days 4โ5: 2026-06-04 to 2026-06-05)
Goal: Complete Reporting Module, finalize Offline Mode, wire Notifications, complete Audit Log coverage.
Day 4 Tasks
| Task | Owner | Hours | Dependency | Acceptance Criteria |
|---|---|---|---|---|
| Backend: Reporting Module โ STCE PDF generation | Backend Dev | 5h | Fixture data, RBAC | PDF generated, zero financial fields for STCE version |
| Backend: Reporting Module โ Internal Excel export | Backend Dev | 3h | Fixture + OOS data | Excel with full financial data downloadable |
| Backend: Scheduled weekly report job | Backend Dev | 2h | PDF/Excel generation | Weekly trigger configured |
| Backend: Audit log โ full coverage wired for all features | Backend Dev | 3h | All APIs complete | Every mutation generates audit entry |
Day 5 Tasks
| Task | Owner | Hours | Dependency | Acceptance Criteria |
|---|---|---|---|---|
| Backend: End-to-end offline sync testing + bug fixes | Backend Dev | 4h | Offline API complete | Airplane mode test passes |
| Backend: Notification triggers for sync completion + deadlines | Backend Dev | 2h | Notification service | All 3 notification types firing |
| QA Engineer: begins integration test suite | QA Engineer | 6h | All APIs deployed to staging | Test cases written and running |
| PM: Training prep โ quick-reference guide (bilingual) | PM | 2h | Feature list finalized | 1-page AR/EN quick guide drafted |
| PM: Training schedule sent to ITECH client contact | PM | 0.5h | โ | 6 training slots confirmed for Day 7 |
Sprint 3 Definition of Done: All 10 features backend-complete on staging. QA integration suite running. Training schedule confirmed.
Sprint 4 โ QA, Security Audit, Deployment, Training (Days 6โ7: 2026-06-05 to 2026-06-06)
Goal: Pass full QA + security review, deploy to production, train all 6 users, deliver handover package.
Day 6 Tasks
| Task | Owner | Hours | Dependency | Acceptance Criteria |
|---|---|---|---|---|
| QA Engineer: Full regression test โ all 10 features | QA Engineer | 6h | Sprint 3 complete | All acceptance criteria tested, bugs logged |
| QA Engineer: STCE financial blackout penetration test | QA Engineer | 2h | RBAC live on staging | Zero financial data accessible via STCE role |
| QA Engineer: Offline mode scenario test | QA Engineer | 2h | Offline sync live | Airplane mode โ data โ reconnect โ verify passes |
| Security Auditor: Final security review โ auth, RBAC, audit log | Security Auditor | 4h | All features live | Written security sign-off or blocker raised |
| Backend Dev: Bug fixes from QA findings | Backend Dev | 4h | QA findings | P1/P2 bugs resolved |
| QC Inspector: Final quality check on deliverables | QC Inspector | 2h | QA sign-off | QC sign-off issued |
| Backend Dev: Production deployment | Backend Dev | 2h | QA + Security sign-off | System live in production environment |
Day 7 Tasks
| Task | Owner | Hours | Dependency | Acceptance Criteria |
|---|---|---|---|---|
| User training โ 6 sessions ร 30 min | PM + Backend Dev | 3h | System live in production | All 6 users trained, sign-offs collected |
| PM: Handover package assembled | PM | 1h | Training complete | API docs, admin credentials, quick guide, sign-off sheets |
| PM: Final delivery sign-off from client contact | PM | 0.5h | Handover package | Client sign-off received |
| PM: Close SMS-12 and update SMS-11 | PM | 0.5h | Client sign-off | Issues updated |
Sprint 4 Definition of Done: All users trained, client sign-off received, system live in production, handover package delivered.
MILESTONE MAP
| # | Milestone | Date | Deliverable | Payment Trigger |
|---|---|---|---|---|
| M0 | Project Kickoff | Day 0 (2026-05-31) | All hard blockers resolved, deposit received | YES โ Deposit due |
| M1 | Foundation Complete | Day 1 EOD (2026-06-01) | Tech stack confirmed, Auth + RBAC + Audit Log live in dev | No |
| M2 | Phase 1 Complete | Day 3 EOD (2026-06-03) | All backend APIs live in staging | YES โ Phase 1 payment |
| M3 | Phase 2 Complete | Day 6 EOD (2026-06-05) | QA + Security sign-off, production deployed | YES โ Phase 2 payment |
| M4 | Project Delivery | Day 7 EOD (2026-06-06) | Training complete, client sign-off, handover package | YES โ Final payment |
RISK REGISTER
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Frontend PWA stack incompatible with backend approach | Medium | Critical | Day 1 assessment mandatory; escalation trigger at 13:30 Day 1 |
| GitHub credentials not received Day 0 | Medium | Critical | No work starts; immediate Hisham escalation; timeline renegotiation |
| DB credentials not received Day 0 | Medium | Critical | No backend starts; immediate Hisham escalation |
| Client slow to respond during project | High | High | Named contact with 2-hour SLA established Day 0 |
| Scope creep request from client | High | Medium | Zero tolerance during 7-day window; formal change order process, escalate to CEO |
| 7-day timeline proves insufficient after Day 1 assessment | Medium | High | Escalation to Hisham by 13:30 Day 1; client renegotiation begins same day |
| PWA offline (service worker/Background Sync) not supported | Low | High | Confirmed Day 1 during codebase assessment; fallback approach pre-agreed |
| QA finds P1 bugs on Day 6 | Medium | High | Backend Dev holds 4h buffer Day 6 for bug fixes; P3+ deferred post-delivery |
| Payment dispute on milestone | Low | High | Written client sign-off required at M2 and M3 before next phase continues |
| Security Auditor identifies RBAC vulnerability after build | Low | Critical | Security review runs Day 1-2 (before full feature build) to catch early |
| Field engineers cannot attend training Day 7 | Medium | Medium | Training schedule confirmed Day 5; video call option available for remote engineers |
AGENT HANDOFF SCHEDULE
| Agent | Receives | On (Trigger) | Delivers | By | |-------|----------|-------------|----------|----|| | Security Auditor | RBAC requirements brief + auth spec | Day 0 (from PM) | RBAC permission matrix draft | Day 1 11:30 | | Security Auditor | Day 1 JWT + RBAC implementation | Day 1 15:00 | Auth review notes | Day 1 16:00 | | Security Auditor | Day 2 full RBAC implementation | Day 2 08:00 | Written RBAC sign-off | Day 2 10:00 | | Security Auditor | All features live on staging | Day 6 08:00 | Final security sign-off or blocker | Day 6 12:00 | | Backend Developer | This delivery plan + GitHub credentials + DB connection | Day 1 09:00 | Tech stack report | Day 1 10:30 | | Backend Developer | Security Auditor RBAC sign-off | Day 2 10:00 | Full feature APIs on staging | Day 5 EOD | | QA Engineer | All APIs deployed to staging | Day 5 AM | Integration test suite results | Day 6 EOD | | QC Inspector | QA sign-off | Day 6 PM | Final QC sign-off | Day 6 EOD | | PM | Client sign-off, all sign-off sheets | Day 7 EOD | Handover package + issue closure | Day 7 EOD |
ESCALATION TRIGGERS
Any of the following requires immediate escalation to Hisham (do not wait for next scheduled check-in):
- Any Day 0 hard blocker not resolved by Day 0 17:00
- GitHub credentials not functional by Day 1 09:30
- DB connection fails on Day 1
- Tech stack incompatibility identified โ escalate by Day 1 13:30 (4h rule)
- Any Day 1 blocker that cannot be resolved within 2 hours
- Client requests scope change during 7-day window
- Security Auditor raises Critical finding after Day 2
- QA finds P1 bugs on Day 6 that cannot be resolved within the 4h buffer
- Client fails to attend training on Day 7 without rescheduling
- Client refuses to sign off at any milestone
CLIENT ACTION ITEMS (ITECH Must Provide)
| # | Action | Owner (ITECH) | Deadline | Risk if Late |
|---|---|---|---|---|
| 1 | GitHub repo URL + read/write credentials | Technical Lead | Day 0 17:00 | Day 1 start delayed |
| 2 | PostgreSQL/Supabase connection string + dump of existing schema | DBA / Technical Lead | Day 0 17:00 | Backend cannot start |
| 3 | Budget deposit transfer confirmation | ITECH Finance / Operations Director | Day 0 17:00 | All work stops |
| 4 | Named project contact with email + phone | Operations Director | Day 0 17:00 | No escalation path during project |
| 5 | List of 6 named users with roles and email addresses | Operations Director | Day 2 EOD | Training prep blocked |
| 6 | ITECH logo files (PNG/SVG) for PDF reports | โ | Day 3 EOD | Reports delivered without logo |
| 7 | Confirm training availability Day 7 (all 6 users) | Operations Director | Day 5 EOD | Training delayed |
| 8 | Client sign-off at M2 (Day 3 EOD) | Operations Director or PM contact | Day 3 EOD | Phase 2 payment blocked |
OPEN ITEMS
| Item | Owner | Resolution Deadline | Status |
|---|---|---|---|
| Payment milestone schedule (exact amounts per milestone) | Account Manager + CEO | Day 0 | OPEN |
| Client sign-off contact confirmed | PM | Day 0 | OPEN |
| Reporting library selection (PDF generation: Puppeteer / WeasyPrint / other) | Backend Dev | Day 1 09:30 | OPEN |
| PWA push notification support confirmed in existing codebase | Backend Dev | Day 1 11:30 | OPEN |
| Frontend i18n approach (does frontend handle translations or does backend send labels?) | Backend Dev | Day 1 11:30 | OPEN |
HOUR ESTIMATE SUMMARY
| Feature | Estimated Hours |
|---|---|
| Project Dashboard | 8h |
| Site + Fixture Tracker | 16h |
| OOS Works Module | 12h |
| RBAC | 10h |
| Offline Mode + Auto-Sync | 12h |
| Bilingual AR/EN | 6h |
| In-App Notifications | 8h |
| Reporting Module | 10h |
| Full Audit Log | 8h |
| User Training | 4h |
| Total Backend Dev | ~84h (3.5 days of work โ TIGHT for 3-day Phase 1) |
| PM coordination | 8h |
| Security Auditor | 8h |
| QA Engineer | 10h |
| QC Inspector | 2h |
| Total Project | ~112h |
WARNING: 84 development hours in 5 working days (Days 1-5) is 16.8h/day โ this is not achievable by a single developer. This plan assumes the Backend Developer works extended hours OR a second developer resource is added for Days 2-4. Escalate to Hisham before Day 1 if Backend Developer capacity has not been confirmed. The Backend Code Generator agent (077a1de1-917e-4524-a538-f5b56ef98a20) should be assigned as a parallel resource.
ARABIC SUMMARY / ู ูุฎุต ุฎุทุฉ ุงูุชุณููู
ุงูู ุดุฑูุน: ูุธุงู ุชุชุจุน ุงูุฅุถุงุกุฉ โ ITECH / ูุฒุงุฑุฉ ุงูุตุญุฉ (23 ู ุฑูุฒุงู ุตุญูุงู)
ุงูุฌุฏูู ุงูุฒู ูู: 7 ุฃูุงู ุซุงุจุชุฉ โ ู ู 31 ู ุงูู ุฅูู 6 ููููู 2026
ุงูู ุชุทูุจุงุช ุงูุญุฑุฌุฉ ูุจู ุจุฏุก ุงูุนู ู (ุงูููู 0): 1. ุฑุงุจุท GitHub + ุจูุงูุงุช ุงูุฏุฎูู 2. ุฑุงุจุท ูุงุนุฏุฉ ุงูุจูุงูุงุช + ุงูู ุฎุทุท ุงูุญุงูู 3. ุชุฃููุฏ ุงูุฏูุนุฉ ุงูู ูุฏู ุฉ 4. ุฌูุฉ ุงูุงุชุตุงู ุงูู ุณุคููุฉ ูู ITECH
ุงูู ุฑุงุญู: - ุงูููู 0: ุงุณุชูุงู ุงูู ุชุทูุจุงุช ู ู ุงูุนู ูู - ุงูููู 1: ุชูููู ูุงุนุฏุฉ ุงูููุฏ + ุจูุงุก ุงูุฃุณุงุณ (Auth + RBAC + ูุงุนุฏุฉ ุงูุจูุงูุงุช) - ุงูููู 2-3: ุชุทููุฑ APIs ุงูุฃุณุงุณูุฉ (ููุญุฉ ุงูุชุญูู ุ ุชุชุจุน ุงูุชุฑููุจุงุชุ OOSุ ุงูู ุฒุงู ูุฉ) - ุงูููู 4-5: ุฅูู ุงู ุงูู ูุฒุงุช (ุงูุชูุงุฑูุฑุ ุงูุฅุดุนุงุฑุงุชุ ุงูุชุฏูููุ ุงูุซูุงุฆูุฉ ุงููุบููุฉ) - ุงูููู 6: ุงุฎุชุจุงุฑ ุงูุฌูุฏุฉ + ุงูู ุฑุงุฌุนุฉ ุงูุฃู ููุฉ + ุงููุดุฑ - ุงูููู 7: ุงูุชุฏุฑูุจ (6 ู ุณุชุฎุฏู ูู) + ุงูุชุณููู ุงูููุงุฆู
ุชุญุฐูุฑ ุฑุฆูุณู: ุญุฌู ุงูุนู ู ุงูุชููู ูุชุทูุจ ู ุทูุฑููู ู ุชูุงุฒูููู โ ูุฌุจ ุชุฃููุฏ ุงูุทุงูุฉ ุงูุงุณุชูุนุงุจูุฉ ูุจู ุงูููู ุงูุฃูู.
Prepared by: Product Manager Agent
For review by: CEO Agent
Pending approval by: Hisham Alhady โ Managing Director
Version: 1.0 โ 2026-05-31