01
Understand
Intent, scope, sign-off. DevOps touch: the repo is created from a template that already carries the full check suite, so compliance starts on day zero.
DevOps · light — scaffolding only
Dhwani RIS · DevOps
Every project.
The same checks.
Provably compliant.
How DevOps keeps every Dhwani application secure, performant, and production-ready — the practices we run, the workflows that fire on every repo, and how each project is proven Dhwani-compliant before it ships.
01 · Where DevOps sits
DevOps doesn't own a phase. It guards every one.
The lifecycle has four steps. The two highlighted below are DevOps-owned end-to-end — but DevOps checks fire across all four, because compliance isn't a stage you reach, it's a state you hold.
02
Build
Code written with AI assistance. DevOps touch: every pull request runs the quality + security workflow. Defects and vulnerabilities are blocked at write-time, not at the gate.
DevOps · continuous — PR gate on
03
Ship
The seven-assessment gate runs. Two DevOps sign-offs. Zero Critical/High. DevOps owns this step — nothing reaches production without a signed Release Readiness Report.
DevOps · owned end-to-end
04
Run
Continuous repo scanning, health checks, weekly reports. DevOps owns this step — every live app is re-scanned and re-reported on a schedule, forever.
DevOps · owned end-to-end
02 · The practices
What DevOps brings to every project.
Six practices, applied uniformly. Nothing here is bespoke per project — that's the point. The same discipline on every repo is what makes "Dhwani-compliant" mean something.
Defense-in-depth on every repo
The day a repo is created it already carries the full check suite — pre-commit hooks, security scans, AI review rules, CI pipeline. No repo starts unprotected.
Zero-bug, enforced at write-time
Dhwani's non-negotiable quality standard is checked on every pull request — while code is being written, not after. Cheaper to fix, impossible to forget.
The seven-assessment gate
VAPT · SAST · DAST · PENTEST · E2E · performance · load. All seven green, two DevOps sign-offs, zero Critical/High — or the release doesn't ship.
Continuous post-prod scanning
Going live isn't the end of scanning. Live repos are re-scanned on a schedule; new CVEs, secret leaks, and licence drift surface in the weekly report.
KB-backed VAPT (Kotwal)
Every scan inherits a decade of historical findings from the Kotwal knowledge base. The next project's first scan starts where the last project's last scan finished.
Compliance by default
Identical workflows on every project mean every project is checked the same way. Compliance becomes something we can prove from the workflow logs — not something we promise.
03 · What runs on every repo
Four workflows. Every repo. Same triggers.
Each workflow fires on a defined trigger, runs its checks, and ends in a gate or an outcome. Read each row left to right: when it fires → what it does → what you get. The bar underneath says what it protects against.
On every pull request
Quality & security check
Fires when
A developer opens or updates a pull request on any branch.
What it does
AI reviews the diff against the coding standard · static security scan · dependency & licence check · secret scan.
What you get
A pass or a block. Critical/High findings stop the merge — no override.
Defects and known vulnerabilities entering the codebase — caught at write-time, the cheapest possible moment.
On merge to development
Deploy & regression
Fires when
An approved PR merges into the working branch.
What it does
Auto-deploys to the dev environment · runs the full regression suite · re-checks integration points.
What you get
An always-working dev environment the team and client can watch take shape.
Integration drift and broken builds — every merge is proven to deploy and pass regression before anyone relies on it.
Before go-live
The seven-assessment gate
Fires when
A release candidate is put forward for production, after UAT sign-off.
What it does
Runs all seven assessments · aggregates findings by severity · requires two DevOps sign-offs (mid-build + final).
What you get
A signed Release Readiness Report — evidence, not assurances. Zero Critical/High or the gate stays shut.
Shipping insecure or unproven code to production — the gate is the last line, and it doesn't negotiate.
Continuously, in production
Re-scan & report
Fires when
On a schedule — daily scans, weekly reporting — for the life of the application.
What it does
Re-scans the repo (secrets · deps · licences) · runs health & performance checks · escalates anomalies.
What you get
A weekly health report per app — uptime, latency, new CVEs, open findings — routed to the owner.
Drift, new CVEs, and silent degradation after launch — a compliant release stays compliant.
04 · Environments & provisioning
Four environments. Each one provisioned, not improvised.
Every project moves through the same four environments, in order. Each is provisioned by DevOps with a defined trigger, a fixed set of infrastructure, and its own hardening — so a 5-day fit-gap and a 4-week greenfield travel the identical path, just at different depth.
Repo creation
github.com/dhwani-{stack}-{client}One command scaffolds a fully-wired repository — the check suite is present before the first line of code.
- Triggered by
- Product Builder (or AM on solo projects) runs
gh repo create … --template ai-sdlc-stage-a-starter - What's provisioned
- Folder structure · schemas · CI seed workflows · Pages → CloudFront · the
.claude/catalogue - DevOps hardening
- Pre-commit hooks, secret scanning, branch protection, and the PR quality/security workflow are present from commit zero
- Outcome
- Repo ready — the first AI prompt is executable immediately, on compliant rails
Dev environment
{project}-dev.dhwaniris.inAuto-provisioned the moment the repo exists; redeployed on every merge.
- Triggered by
- Automatic on repo creation; redeploys on every merge to the
developmentbranch - What's provisioned
- Dev compute via Terraform · auto-deploy pipeline · seeded monitoring · continuous regression runner
- DevOps hardening
- Isolated network · no production data · synthetic fixtures only
- Outcome
- A dev URL that updates on every merge — the team and client watch the product take shape; regression runs continuously
UAT environment
{project}-uat.dhwaniris.inProvisioned when dev passes regression and the client is ready to validate. Self-service portal — coming soon: teams will request a staging/UAT environment from a portal and DevOps approves it; until then, ask DevOps directly. Production stays DevOps-only.
- Triggered by
- AM, after dev passes regression — often optional on small projects, where staging serves as the preview
- What's provisioned
- Isolated UAT infra · named-approver access · PII-free seed data · UAT-specific monitoring
- DevOps hardening
- Access restricted to named approvers · PII masked · data export disabled for non-privileged roles
- Outcome
- Client validates against the original intent — UAT sign-off captured before the gate runs
Production environment
{project}.dhwaniris.inProvisioned only after the seven-assessment gate passes and DevOps + AM sign Go-Live.
- Triggered by
- Pre-go-live gate green · two DevOps sign-offs · AM Go-Live approval
- What's provisioned
- Prod compute (blue-green) · DNS · valid SSL · backups + restore test · auto-scale · full metrics/logs/traces stack
- DevOps hardening
- HTTPS enforced · firewall rules reviewed · admin IP allowlist · 30-min heightened post-deploy monitoring · rollback rehearsed
- Outcome
- Live, monitored, and on the continuous post-prod schedule — re-scanned and re-reported for the life of the application (see §03 · the continuous workflow)
05 · Per-project assessment & compliance
"Dhwani-compliant" is a checklist, not a claim.
Because every repo runs the identical workflow bundle, every project is held to the same bar — and the proof lives in the workflow logs. Here's what compliant concretely means, and the lever that enforces it.
A project is Dhwani-compliant when…
- The repo was scaffolded from the standard template — full check suite present from day zero
- Every merged PR passed the quality & security workflow — no bypassed blocks
- All seven assessments are green on the shipped release
- Zero Critical/High findings outstanding; every Medium has a written ETA
- Two DevOps sign-offs recorded — mid-build and final pre-prod
- The app is on the continuous post-prod scan + weekly report schedule
06 · The DevOps contract
DevOps isn't a phase. It's a contract across all of them.
The practices, workflows, and compliance checklist above all rest on one contract — three streams that bind the lifecycle together, two sign-offs that gate production, and one severity rule that has no exceptions.
Three streams, every phase
Stream 01 · Build-time
AI-leveraged code quality
Dhwani's zero-bug non-negotiable standard is enforced while code is being written, not at the gate. AI agents review every PR against the standard, catch defects at write-time, and refuse merges that don't clear the bar.
Active · first AI prompt → final merge
Stream 02 · Pre-prod
The seven-assessment gate
Seven assessments, all mandatory. Two DevOps sign-offs — one mid-build validation, one final pre-prod validation. Without both, the production deploy doesn't happen.
Between UAT sign-off & Go-Live
Stream 03 · Post-prod
The continuous gate
Continuous repo scanning (SCA · OSS licence · secrets · dependency CVEs) plus a weekly per-app health report — same template, every app, generated and routed to the owner automatically.
From Go-Live · forever
The seven assessments — the floor, not the ceiling
VAPT — Vulnerability Assessment & Pentesting
Driven by the Kotwal knowledge base — Dhwani's structured DB of historical findings, MCP-wrapped so the assistant inherits a decade of pattern knowledge. Every new scan is informed by every finding before it.
SAST — Static code scanning
Semgrep / Snyk rulesets in CI on every PR. Critical + High findings hard-block the merge — no override, no exception path.
DAST — Running-app scanning
Dynamic scan against the staging deployment. Catches misconfigurations and runtime issues static analysis can't see.
PENTEST — Manual red-team round
Security team runs targeted attacks against the staged build. Findings logged into Kotwal so the next project's automated scan inherits them.
E2E — End-to-end test finalisation
The QA sub-persona's E2E suite runs against staging. All critical journeys green. No skipped or flaky tests carried into prod.
PERF — Performance baseline
p50 / p95 / p99 latency captured against the Sol Doc's SLO targets. Regressions vs. the previous release flagged.
LOAD — Load test
Sustained-load scenarios at the SLO's target concurrency. Auto-scale behaviour verified. Failure modes documented in the readiness report.
Extensible per project type
Accessibility audits for client-facing portals · OWASP API checks for mobile back-ends · compliance scans for regulated work. The gate grows with the risk surface.
Severity rules · no negotiation
Critical + High
Zero before go-live. Hard fail.
No exception path. No override. Every Critical and High finding from every assessment must be remediated and re-scanned green before the production deploy unlocks. The assistant blocks the Go-Live command while any remain.
Medium
Exception — with a written ETA.
Ships to prod only with a written remediation ETA, owned by the team's priority lead, logged in the tracker. No ETA = no ship. Open Mediums past their ETA surface in the weekly health report until closed.
Low + Informational
Logged, batched, quarterly.
Tracked in the repo's security backlog, reviewed at the quarterly portfolio sync. Not a blocker alone — but a repeat-offender pattern across releases is itself a finding.
The bottom line
Same checks, every repo, every time.
- Uniform, not bespoke. Every project runs the identical workflow bundle — so compliance is comparable across the whole portfolio.
- Proven, not promised. Every gate decision is backed by workflow logs and a signed report. "Dhwani-compliant" is auditable.
- Continuous, not one-shot. Compliance is held after launch, not just claimed at it — repos keep getting scanned and reported on for the life of the app.
If it ran through the framework, it's provably compliant. If it didn't, it doesn't ship.