feat(blogs): add blogs/ folder with seed posts and contribution schema

blogs/2026-07-07-introducing-devops-os-ai-assisted-devops-automation.md

@@ -0,0 +1,67 @@
+---
+title: "Introducing DevOps-OS: AI-Assisted DevOps Automation From a Single CLI"
+slug: "introducing-devops-os-ai-assisted-devops-automation"
+description: "DevOps-OS scaffolds production-ready CI/CD pipelines, Kubernetes configs, and SRE dashboards in seconds — from one CLI command or an AI chat prompt."
+topic: "devops-automation"
+tags: ["DevOpsOS", "DevOpsAutomation", "CICD", "PlatformEngineering", "OpenSource"]
+publishedAt: "2026-07-07"
+featured: true
+---
+
+# Introducing DevOps-OS: AI-Assisted DevOps Automation From a Single CLI
+
+Every DevOps team spends the first weeks of a new project doing the same thing: wiring together CI/CD pipelines, Kubernetes manifests, monitoring dashboards, and local development environments. The tooling differs — GitHub Actions, Jenkins, ArgoCD, Prometheus — but the boilerplate is always recognisable.
+
+**DevOps-OS exists to eliminate that boilerplate entirely.**
+
+## What is DevOps-OS?
+
+DevOps-OS is an open-source DevOps automation platform built by [CloudEngine Labs](https://cloudenginelabs.io). It scaffolds production-ready configuration artefacts — CI/CD pipelines, Kubernetes manifests, SRE observability configs, infrastructure hardening baselines, and developer environments — in seconds, from a single CLI command or an AI chat prompt.
+
+```bash
+# Install
+git clone https://github.com/cloudengine-labs/devops_os.git
+cd devops_os
+pip install -r cli/requirements.txt
+
+# Generate a complete GitHub Actions CI/CD pipeline for a Python app
+python -m cli.devopsos scaffold gha --name my-api --languages python --type complete
+# Output: .github/workflows/my-api-complete.yml
+```
+
+That one command produces a fully wired, multi-stage workflow: lint, test, build, Docker push, and Kubernetes deploy.
+
+## The full scaffold surface
+
+| Command | What it generates |
+|---------|-------------------|
+| `scaffold gha` | GitHub Actions workflows (build / test / deploy / complete / reusable) |
+| `scaffold gitlab` | GitLab CI/CD pipeline (`.gitlab-ci.yml`) |
+| `scaffold jenkins` | Jenkinsfile (Declarative Pipeline) |
+| `scaffold argocd` | ArgoCD Application + AppProject, or Flux CD Kustomization |
+| `scaffold sre` | Prometheus alert rules, Grafana dashboard, SLO manifest |
+| `scaffold hardening` | Kyverno policies, InSpec profiles, Checkov checks |
+| `scaffold devcontainer` | `devcontainer.json` for multi-language dev environments |
+| `scaffold unittest` | pytest, Jest, Vitest, Mocha, or Go test configs |
+
+## Use it with AI
+
+DevOps-OS ships with a built-in **MCP (Model Context Protocol) server** that exposes every scaffold tool as a native skill for Claude, ChatGPT, or any MCP-compatible AI assistant.
+
+```bash
+python -m mcp_server.server
+```
+
+Ask your AI assistant: *"Generate a Jenkins pipeline for a Java Spring Boot app with Kubernetes deployment via Kustomize."* It calls DevOps-OS under the hood and hands you a production-ready `Jenkinsfile`.
+
+## Built on Process-First principles
+
+DevOps-OS is not just a code generator. It is built on the **Process-First SDLC philosophy** — the idea that well-defined, repeatable processes must come before tool selection. Every scaffold command encodes a process decision into an immediately usable artefact.
+
+Run `python -m cli.devopsos process-first` in your terminal to explore the philosophy interactively.
+
+## Get started
+
+- GitHub: [cloudengine-labs/devops_os](https://github.com/cloudengine-labs/devops_os)
+- Docs: [cloudengine-labs.github.io/devops_os](https://cloudengine-labs.github.io/devops_os)
+- License: MIT — free for every team

blogs/2026-07-14-process-first-devops-the-philosophy-behind-devops-os.md

@@ -0,0 +1,77 @@
+---
+title: "Process-First DevOps: The Philosophy Behind DevOps-OS"
+slug: "process-first-devops-philosophy-behind-devops-os"
+description: "Before you pick a tool, define the process. DevOps-OS is built on the Process-First SDLC philosophy — here is what it means and why it matters for engineering teams."
+topic: "devops-culture"
+tags: ["ProcessFirst", "DevOpsPhilosophy", "SDLC", "DevOpsCulture", "SystemsThinking"]
+publishedAt: "2026-07-14"
+featured: false
+---
+
+# Process-First DevOps: The Philosophy Behind DevOps-OS
+
+> *"Tools are only as good as the processes that govern them."*  
+> — Saravanan Gnanaguru, Founder, CloudEngine Labs
+
+Most teams adopt DevOps in reverse. They buy a tool first — a CI platform, a GitOps operator, an observability stack — and then try to retrofit a process around it. The result is fragile automation that is hard to reason about and even harder to hand off.
+
+**Process-First flips that order.**
+
+## What is Process-First?
+
+Process-First is an engineering philosophy that places well-defined, repeatable SDLC processes at the centre of every engineering decision — before tools, platforms, or frameworks are chosen.
+
+The guiding question is always: **"Do we have the right process before we pick the tool?"**
+
+CloudEngine Labs — the company behind DevOps-OS — is a Process-First SDLC automation company. Every feature in DevOps-OS encodes a process decision first and a configuration artefact second.
+
+## The 5 Core Principles
+
+| # | Principle | In practice |
+|---|-----------|-------------|
+| 1 | **Define before you Build** | Document the why and what of every workflow before writing pipeline code |
+| 2 | **Standardise before you Scale** | Golden-path templates every team can adopt without reinventing the wheel |
+| 3 | **Automate what is Repeatable** | If a process runs more than twice, automate it. Automation should encode the process, not bypass it |
+| 4 | **Observe and Iterate** | Every automated process must produce measurable outcomes — SLOs, error budgets, dashboards |
+| 5 | **Culture over Tooling** | The right culture makes any toolchain succeed; the wrong culture makes the best toolchain fail |
+
+## How these principles map to DevOps-OS commands
+
+| Principle | DevOps-OS command | What it encodes |
+|-----------|-------------------|-----------------|
+| Define before you Build | `scaffold gha / gitlab / jenkins` | Capture intent in an interactive wizard before generating any config |
+| Standardise before Scale | `scaffold gha / gitlab / jenkins` | Golden-path CI/CD templates reviewed by the team |
+| Automate the Repeatable | `scaffold argocd` | GitOps sync process encoded as an ArgoCD Application CR |
+| Automate the Repeatable | `scaffold devcontainer` | Developer environment setup reproducible for every team member |
+| Observe and Iterate | `scaffold sre` | Prometheus + Grafana + SLO manifest closes the measure-improve loop |
+| Culture over Tooling | DevOps-OS MCP server | AI coaches engineers on best practices, not just generates configs |
+
+## Standing on the shoulders of giants
+
+Process-First draws directly from two foundational works:
+
+**Gene Kim, Kevin Behr, and George Spafford** (*The Phoenix Project* / *The DevOps Handbook*) define the **Three Ways of DevOps**. The First Way — Systems Thinking — optimises the performance of the entire system, not a single silo.
+
+**Patrick Debois** (founder of DevOpsDays) showed that cultural and process problems — not technology gaps — are the root cause of slow, unreliable software delivery.
+
+DevOps-OS treats both insights as first-class requirements.
+
+## Try the Process-First CLI command
+
+DevOps-OS ships a built-in `process-first` command so you can explore the philosophy directly in your terminal:
+
+```bash
+# Full overview
+python -m cli.devopsos process-first
+
+# Just the 5 core principles
+python -m cli.devopsos process-first --section what
+
+# Which scaffold command encodes which principle
+python -m cli.devopsos process-first --section mapping
+
+# Best practices by stage: build, test, deploy, sre, security
+python -m cli.devopsos process-first --section best_practices
+```
+
+Process-First is not a certification or a maturity model. It is a mindset: define the process, encode it, observe the outcome, improve. DevOps-OS gives you the tooling to do all four.

blogs/2026-07-21-github-actions-at-scale-with-devops-os.md

@@ -0,0 +1,101 @@
+---
+title: "GitHub Actions at Scale: Generating Reusable CI/CD Workflows With DevOps-OS"
+slug: "github-actions-at-scale-with-devops-os"
+description: "Stop writing GitHub Actions YAML by hand. DevOps-OS generates complete, reusable CI/CD workflows for any language stack in one command — with Kubernetes support built in."
+topic: "ci-cd"
+tags: ["GitHubActions", "CICD", "DevOpsOS", "PipelineAutomation", "Kubernetes"]
+publishedAt: "2026-07-21"
+featured: false
+---
+
+# GitHub Actions at Scale: Generating Reusable CI/CD Workflows With DevOps-OS
+
+GitHub Actions is powerful — but hand-authoring YAML pipelines for every project is slow, error-prone, and inconsistent across teams. DevOps-OS solves this with a single scaffold command that produces a production-ready, multi-stage workflow tailored to your language stack.
+
+## Generate a workflow in one command
+
+```bash
+# Complete CI/CD pipeline for a Python + JavaScript project
+python -m cli.devopsos scaffold gha \
+  --name my-api \
+  --languages python,javascript \
+  --type complete
+
+# Output: .github/workflows/my-api-complete.yml
+```
+
+The generated workflow includes: dependency caching, lint, unit tests, Docker image build and push, and a Kubernetes deploy stage.
+
+## Workflow types
+
+| Type | What it produces |
+|------|-----------------|
+| `build` | Build and package only |
+| `test` | Test and code-quality gates only |
+| `deploy` | Deploy to Kubernetes only |
+| `complete` | Full build → test → deploy pipeline |
+| `reusable` | A workflow callable from other workflows across repositories |
+
+## Multi-language matrix builds
+
+Covering multiple language versions across operating systems is one command away:
+
+```bash
+python -m cli.devopsos scaffold gha \
+  --name cross-platform \
+  --languages go \
+  --matrix
+```
+
+The `--matrix` flag generates a strategy block that runs your workflow across Ubuntu, macOS, and Windows with the language version combinations you choose.
+
+## Kubernetes deployment — four methods supported
+
+```bash
+# Direct kubectl apply
+python -m cli.devopsos scaffold gha --name my-app --kubernetes --k8s-method kubectl
+
+# Kustomize overlay-based deploy
+python -m cli.devopsos scaffold gha --name my-app --kubernetes --k8s-method kustomize
+
+# GitOps via ArgoCD App sync trigger
+python -m cli.devopsos scaffold gha --name my-app --kubernetes --k8s-method argocd
+
+# GitOps via Flux CD image update
+python -m cli.devopsos scaffold gha --name my-app --kubernetes --k8s-method flux
+```
+
+## Reusable workflows for platform teams
+
+Platform teams maintaining pipelines for dozens of microservices benefit most from the `reusable` workflow type. Generate a shared caller template once, then reference it from every service repo:
+
+```bash
+python -m cli.devopsos scaffold gha --name shared-pipeline --type reusable
+```
+
+The generated workflow accepts `inputs:` for languages, environment, and deploy target — so each service repo calls the shared pipeline with a 10-line caller file instead of duplicating 200 lines of YAML.
+
+## Consistent dev-to-CI parity
+
+DevOps-OS integrates with `devcontainer.env.json` — the same file that drives your local dev container — to keep your CI environment aligned with local development:
+
+```bash
+python -m cli.devopsos scaffold gha --env-file .devcontainer/devcontainer.env.json --name my-app
+```
+
+The scaffold reads your declared language versions, CI tools, and Kubernetes preferences and wires them directly into the generated workflow.
+
+## All options
+
+| Option | Default | Description |
+|--------|---------|-------------|
+| `--name` | `DevOps-OS` | Workflow name |
+| `--type` | `complete` | `build` · `test` · `deploy` · `complete` · `reusable` |
+| `--languages` | `python,javascript` | Comma-separated language list |
+| `--kubernetes` | off | Add K8s deploy stage |
+| `--k8s-method` | `kubectl` | `kubectl` · `kustomize` · `argocd` · `flux` |
+| `--matrix` | off | Matrix strategy across OS + language versions |
+| `--reusable` | off | Generate a reusable/callable workflow |
+| `--output` | `.github/workflows` | Output directory |
+
+Use `python -m cli.devopsos scaffold gha --help` to see all options.

blogs/2026-07-28-gitops-argocd-flux-scaffolding-with-devops-os.md

@@ -0,0 +1,95 @@
+---
+title: "GitOps in Minutes: Scaffolding ArgoCD and Flux CD Configs With DevOps-OS"
+slug: "gitops-argocd-flux-scaffolding-with-devops-os"
+description: "DevOps-OS generates complete ArgoCD Application + AppProject manifests and Flux CD Kustomizations from one CLI command — no YAML editing required."
+topic: "gitops"
+tags: ["GitOps", "ArgoCD", "FluxCD", "Kubernetes", "DevOpsOS"]
+publishedAt: "2026-07-28"
+featured: false
+---
+
+# GitOps in Minutes: Scaffolding ArgoCD and Flux CD Configs With DevOps-OS
+
+GitOps is the gold standard for Kubernetes delivery — every change to a cluster flows through a Git commit, making deployments auditable, reviewable, and reversible. But setting up ArgoCD or Flux CD for the first time involves a non-trivial amount of YAML boilerplate. DevOps-OS removes that friction.
+
+## The Process-First take on GitOps
+
+Before touching any YAML, define your deployment process:
+
+- What is the Git source of truth for your manifests?
+- Which namespace and cluster does each application target?
+- Who can approve changes to production?
+- How does the system handle image tag updates automatically?
+
+Only once those questions are answered does a `scaffold argocd` command produce a configuration that reflects your actual intentions rather than a generic template you have to heavily edit.
+
+## Generate ArgoCD configs
+
+```bash
+# ArgoCD Application + AppProject for a service
+python -m cli.devopsos scaffold argocd \
+  --name payment-service \
+  --repo https://github.com/myorg/payment-service.git
+
+# Output:
+#   argocd/application.yaml
+#   argocd/appproject.yaml
+```
+
+The generated `application.yaml` wires the repository, target revision, destination cluster, and sync policy. The `appproject.yaml` scopes the project to the correct namespace and source repo.
+
+## Generate Flux CD configs
+
+```bash
+# Flux CD GitRepository + Kustomization + ImageUpdateAutomation
+python -m cli.devopsos scaffold argocd \
+  --name payment-service \
+  --method flux \
+  --repo https://github.com/myorg/payment-service.git
+
+# Output:
+#   flux/git-repository.yaml
+#   flux/kustomization.yaml
+#   flux/image-update-automation.yaml
+```
+
+Flux's `ImageUpdateAutomation` file is included by default — it keeps your Kubernetes manifests in sync with the latest image tag pushed to your container registry.
+
+## Combine GitOps with your CI pipeline
+
+DevOps-OS lets you wire GitOps delivery directly into a GitHub Actions pipeline:
+
+```bash
+python -m cli.devopsos scaffold gha \
+  --name payment-service \
+  --kubernetes \
+  --k8s-method argocd
+```
+
+The generated workflow includes an ArgoCD sync step that triggers an application sync after a successful build and image push — closing the loop from commit to production.
+
+## Why GitOps changes incident response
+
+When every production change flows through Git:
+
+1. **Who changed it?** → `git log`
+2. **What changed?** → `git diff`
+3. **Why did it change?** → commit message + linked PR
+4. **How do I roll back?** → `git revert` + sync
+
+No more SSH-ing into production nodes and running `kubectl apply` from a laptop. The GitOps operator reconciles the declared state continuously.
+
+## Cluster topology tip
+
+Use separate ArgoCD `AppProject` resources per environment (dev, staging, production). DevOps-OS generates one project per scaffold run, so you get environment isolation without duplicating application definitions.
+
+```bash
+python -m cli.devopsos scaffold argocd --name payment-service --repo ... # dev project
+python -m cli.devopsos scaffold argocd --name payment-service-prod --repo ... # prod project
+```
+
+## Next steps
+
+- Combine `scaffold argocd` with `scaffold hardening` to enforce Kyverno policies on every sync
+- Use `scaffold sre` to generate the Grafana dashboard that monitors ArgoCD sync health
+- Add the Flux `image-update-automation.yaml` to your GitOps repository to enable automatic image tag promotions