FLX-ENG-RFC-008 — Week 4 · Handover, Walkthrough & Engagement Closure¶
| Field | Value |
|---|---|
| RFC ID | FLX-ENG-RFC-008 |
| Status | Active — Week 4 (2026-07-20 → 2026-07-26) |
| Author | Arun Singh, Senior Distinguished Engineer / Architect (Consulting) |
| Reviewers | Raja Choudhary (sign-off), Rahul (Eng Lead), Shrikant, Tushar |
| Scope | Final deliverables: P0/P1/P2 inventory, DMS Essential recommendations, CodePulse runbook, Terraform handover, team walkthrough, final sign-off |
| Parent Epic | GitHub Issue #5 — [EPIC] Week 4 · Handover, Walkthrough & Closure |
| Milestone | MS#4 — due 2026-07-26 |
| Priority | P1-HIGH |
| Related Issues | #46 (P0/P1/P2 inventory), #47 (DMS Essential recs), #48 (CodePulse runbook), #49 (Terraform), #50 (walkthrough), #51 (sign-off) |
TL;DR¶
Week 4 converts all Week 1–3 findings into permanent handover artifacts and closes the engagement. Every deliverable has a named document, a recipient, and a sign-off criterion. The engagement ends when Raja and Shrikant countersign the final report.
1. Step-by-Step Tasks¶
Task 1 · US-4.1 — Final P0/P1/P2 Issue Inventory (GitHub Issue #46)¶
Priority: P1 | Effort: 1.5 hrs | Owner: Arun Singh
This is the final, signed version of the defect catalog from Week 3 (US-3.6 #40), updated with any findings from Week 4 and mapped to the 99.99% availability commitment.
Step-by-step: 1. Pull the Week 3 defect catalog (docs/developer-guide/defect-catalog-YYYY-MM-DD.md) 2. Update with any new findings from Week 3 lifecycle demos 3. For each item: confirm GitHub issue exists (or create one) 4. Add "Availability Impact" column — quantify risk:
P0-001 · Race condition on infeed:
- Frequency: estimated 1–3 ghost parcel events per 10,000 operations
- Impact: customer complaint, manual resolution required (~30 min each)
- MTTR contribution: adds estimated 0.5 hrs to monthly MTTR
- 99.99% Availability blocker: YES (if unresolved, availability is capped at 99.95%)
## Issue Inventory Summary
| Priority | Count | Est. Fix Effort | Availability Risk |
|----------|-------|-----------------|-------------------|
| P0 | N | N-M days | Blocks 99.99% uptime |
| P1 | N | N-M days | Degrades <99.99% |
| P2 | N | N-M weeks | Quality debt |
| Total | N | | |
docs/developer-guide/FINAL-ISSUE-INVENTORY.md 7. Link every P0 GitHub issue from the inventory document 8. Exit signal: Inventory committed; P0 count agreed with Raja; all P0s have open GitHub issues Task 2 · US-4.2 — DMS Essential Subset Recommendations (GitHub Issue #47)¶
Priority: P2 | Effort: 2 hrs | Owner: Arun Singh
Context: Based on 4 weeks of analysis, what is the minimum viable "DMS Essential" — the features, integrations, and quality standards that must be present for DMS to be production-ready for the next customer onboarding?
Step-by-step: 1. Review defect catalog and DORA baseline together 2. Identify the "essential vs. optional" split:
ESSENTIAL (must have before next tenant onboarding):
- P0 defects fixed
- CI pipeline blocking on build + SAST + CVE + secrets
- Tenant manifest validation at startup
- .NET 8 port complete
- Branch protection on main
- CodePulse active with 30-day baseline
OPTIONAL (can be onboarded before completion):
- Subjective review checklist (advisory)
- mSORT Dashboard extended CI gates
- Knowledge-graph parser (P3)
- Complexity and size gates at blocking level
# DMS Essential — Go/No-Go for Next Tenant Onboarding
## Must be DONE before onboarding tenant #2
- [ ] P0-001 Race condition fix merged
- [ ] P0-002 CVE-XXXX patched
- [ ] .NET 8 port green (RFC-PoC-1.1)
- [ ] CI pipeline blocking on SAST + CVE
- [ ] Tenant manifest validated at startup (RFC-PoC-4.1)
- [ ] Change Lead Time < 7 days (current baseline)
## Can be done IN PARALLEL with onboarding
- [ ] mSORT CI extension (US-3.3)
- [ ] Complexity gate (Gate 4)
- [ ] Rollback drill documented (RFC-PoC-6.1)
docs/developer-guide/DMS-ESSENTIAL-CHECKLIST.md 5. Exit signal: Checklist committed and reviewed with Raja in the Week 4 walkthrough (Task 5) Task 3 · US-4.3 — CodePulse Operational Runbook (GitHub Issue #48)¶
Priority: P1 | Effort: 1.5 hrs | Owner: Arun Singh
This runbook allows the Flexli team to operate CodePulse independently after the engagement ends.
Step-by-step — Runbook content:
# CodePulse Operational Runbook
Version: 1.0 | Owner: Rahul (post-engagement)
## Access Management
- URL: app.codepulse.io
- Login: shared flexly account (credentials in [PASSWORD_MANAGER_NAME])
- GitHub App: "CodePulse CI" installed on Flexli-Technologies org
- Admin users: Raja, Rahul, Arun Singh (consulting — will be removed post-engagement)
## Adding a New Repository
1. Log into CodePulse
2. Settings → Connected Repositories → Add Repository
3. Select repository from GitHub org dropdown
4. Configure deployment trigger (merge to `main` or semver tag)
5. Set excluded PR filters (bots, docs-only PRs)
6. Wait 24 hours for first data to appear
## Rotating Credentials
1. GitHub App permissions are token-based — no rotation needed
2. CodePulse account password: rotate every 90 days in [PASSWORD_MANAGER_NAME]
3. If GitHub App is revoked: Settings → Integrations → Re-authorize CodePulse
## Reading the DORA Dashboard
1. Open CodePulse → Metrics → Overview
2. Select date range: "Last 30 days" for weekly reviews
3. Change Lead Time: target < [agreed value] hours
4. Deployment Frequency: target [agreed value] per week
5. MTTR: target < [agreed value] hours
6. Change Fail Rate: target < [agreed value]%
7. If any metric moves into "Medium" band: flag for team retrospective
## Weekly DORA Review Cadence
Every Monday morning (15 min):
1. Open CodePulse dashboard
2. Screenshot the weekly summary
3. Compare to previous week
4. If any metric is >20% worse: create a GitHub issue labelled `dora-regression`
## Escalation Path
- Metric regression: Rahul to investigate, escalate to Raja if P0
- CodePulse service outage: Check status.codepulse.io; fallback = manual git log analysis
- Data gap (>24 hrs missing): Re-authorize GitHub App, contact CodePulse support
## Phase 2 Trigger
If CodePulse cost is prohibitive OR self-hosting is preferred:
See `docs/rfcs/FLX-ENG-RFC-009.md` Terraform handover → self-hosted middleware on Hetzner.
Steps: 1. Fill in all [bracketed] values from Week 3 agreed targets (US-3.2 #36) 2. Fill in password manager name 3. Commit to docs/runbooks/CODEPULSE-RUNBOOK.md 4. Walk Rahul through runbook in Task 5 (30-min walkthrough) 5. Exit signal: Runbook committed; Rahul has confirmed he can perform each step independently
Task 4 · US-4.4 — Phase 2 Terraform Handover (GitHub Issue #49)¶
Priority: P2 | Effort: 1 hr | Owner: Arun Singh
Context: If CodePulse is later replaced with a self-hosted DORA middleware on Hetzner, a Terraform module prepares the infrastructure. This is a reference handover, not a full deployment.
Step-by-step: 1. Create terraform/hetzner-dora/ directory 2. Produce a minimal Terraform module:
# terraform/hetzner-dora/main.tf
terraform {
required_providers {
hcloud = {
source = "hetznercloud/hcloud"
version = "~> 1.44"
}
}
}
resource "hcloud_server" "dora_middleware" {
name = "dora-middleware-${var.environment}"
server_type = "cx21" # 2 vCPU, 4 GB RAM — sufficient for middleware
image = "ubuntu-22.04"
location = "nbg1" # Nuremberg (closest to India latency)
user_data = file("${path.module}/cloud-init.yaml")
labels = {
environment = var.environment
purpose = "dora-middleware"
}
}
resource "hcloud_volume" "dora_data" {
name = "dora-data-${var.environment}"
size = 20 # 20 GB for metrics storage
location = "nbg1"
format = "ext4"
}
README.md to terraform/hetzner-dora/ explaining: - When to trigger Phase 2 (cost threshold or self-hosting preference) - Prerequisites: Hetzner API token, domain DNS access - Commands: terraform init && terraform plan && terraform apply 4. Commit Terraform module 5. Exit signal: Terraform module committed; terraform init runs cleanly locally; README explains Phase 2 trigger criteria Task 5 · US-4.5 — 30-min Team Walkthrough (GitHub Issue #50)¶
Priority: P1 | Effort: 0.5 hr | Owner: Arun Singh (facilitates)
Attendees: Rahul, Tushar, Shrikant (mandatory); Raja (optional)
Walkthrough agenda:
00:00 – CodePulse dashboard tour (10 min)
- How to read each DORA metric
- How to identify regressions
- How to add repositories
10:00 – CI gate pipeline walkthrough (10 min)
- Open a PR on feature/* branch
- Watch GitHub Actions run all 10 gates
- Show how to read gate failure output
- Show how to fix a typical SAST finding
20:00 – Defect catalog and P0 action plan (5 min)
- Walk through top 3 P0 defects
- Who owns each P0 fix? (assign GitHub issues to Rahul/Tushar)
- Timeline expectation: P0s within 2 sprints
25:00 – Questions (5 min)
Preparation (day before): 1. Prepare a slide or screen-share sequence for each agenda item 2. Ensure CodePulse is showing current data 3. Have a test branch ready to demo CI gate failure 4. Print or share docs/developer-guide/CODEPULSE-RUNBOOK.md link
Post-walkthrough: 1. Commit a docs/developer-guide/week4-walkthrough-notes.md with: - Attendees - Questions asked + answers - Action items assigned 2. Update GitHub issues with assignees for P0/P1 defects (from Task 1) 3. Exit signal: Notes committed; team confirms they can operate CodePulse and CI independently
Task 6 · US-4.6 — Final Report Delivery and Sign-Off (GitHub Issue #51)¶
Priority: P0 | Effort: 3 hrs (report) + 1 hr (sign-off meeting) | Owner: Arun Singh
Final report structure:
# Flexli DMS · DORA Baseline & Availability Uplift Engagement
Final Report — Version 1.0
Author: Arun Singh, Senior Distinguished Engineer / Architect (Consulting)
Date: 2026-07-26
Engagement: 4 weeks | Scope: DMS + mSORT Dashboard
---
## Executive Summary
[1 page: what was done, what was found, key recommendations, DORA band achieved]
## Engagement Scope
Per scoping document v3.1 — all 15 in-scope items delivered:
[Checklist with DONE status for each item]
## DORA Baseline Results
[Table: 5 metrics × current baseline × DORA band × 3-month target]
## Top 5 Recommendations
1. [P0] Fix race condition on infeed endpoint (prevents ghost parcels)
2. [P0] Complete .NET 8 port (unblocks all CI gate work)
3. [P0] Enable CI pipeline with SAST + CVE + secrets blocking gates
4. [P1] Implement tenant manifest validation (RFC §5 architecture)
5. [P1] Achieve < 24h Change Lead Time through trunk-based development
## Defect Catalog Summary
[Condensed from FINAL-ISSUE-INVENTORY.md]
## Tooling Stack Delivered
[From TOOLING-RECOMMENDATIONS.md]
## Availability Uplift Path
[How fixing P0/P1 defects contributes to 99.99% availability]
## Handover Artifacts
| Artifact | Location | Owner (post-engagement) |
|----------|----------|------------------------|
| CodePulse Runbook | docs/runbooks/CODEPULSE-RUNBOOK.md | Rahul |
| Defect Catalog | docs/developer-guide/FINAL-ISSUE-INVENTORY.md | Rahul |
| DMS Essential Checklist | docs/developer-guide/DMS-ESSENTIAL-CHECKLIST.md | Raja |
| CI Gate Configuration | .github/workflows/build.yml | Tushar |
| Terraform Module | terraform/hetzner-dora/ | Arun (post-engagement) |
| RFCs | docs/rfcs/ | All team |
## Sign-Off
| Role | Name | Signature | Date |
|------|------|-----------|------|
| Founder | Raja Choudhary | ___________ | |
| Consulting Engineer | Arun Singh | ___________ | |
| Witness | Shrikant | ___________ | |
Steps: 1. Compile all documents from Weeks 1–4 into report structure above 2. Review draft with Raja (45-min sign-off meeting) 3. Address any feedback from Raja 4. Both parties sign (digital or physical) 5. Commit signed report to docs/developer-guide/FINAL-REPORT-v1.0.md 6. Close all engagement GitHub issues as complete 7. Exit signal: Final report signed by Raja and Arun; committed to repo; engagement officially closed
2. Handover Artifact Checklist¶
| Artifact | Document | Owner | Status |
|---|---|---|---|
| DORA Baseline Numbers | docs/dora-baseline/BASELINE-NUMBERS.md | Rahul | |
| Defect Catalog | docs/developer-guide/FINAL-ISSUE-INVENTORY.md | Rahul | |
| DMS Essential Checklist | docs/developer-guide/DMS-ESSENTIAL-CHECKLIST.md | Raja | |
| Tooling Recommendations | docs/developer-guide/TOOLING-RECOMMENDATIONS.md | Raja | |
| CodePulse Runbook | docs/runbooks/CODEPULSE-RUNBOOK.md | Rahul | |
| CI Gate Config | .github/workflows/build.yml | Tushar | |
| Subjective Checklist | docs/developer-guide/SUBJECTIVE-REVIEW-CHECKLIST.md | Shrikant | |
| PR Template | .github/PULL_REQUEST_TEMPLATE.md | Shrikant | |
| Terraform Module | terraform/hetzner-dora/ | Post-engagement | |
| Final Report | docs/developer-guide/FINAL-REPORT-v1.0.md | Raja + Arun |
3. Success Criteria¶
- All 10 handover artifacts committed to repository
- Team walkthrough conducted and notes committed
- CodePulse operational runbook confirmed by Rahul (independent operation test)
- Final report signed by Raja and Arun
- All GitHub engagement issues closed with resolution comments
- Phase 2 Terraform module committed and documented