Lou Stack Base

This post records the system design of making content-i18n support both CLI and MCP server

The point is not MCP protocol itself, but how the same workflow can be shared by two entrypoints

Core questions:

• what CLI is
• what MCP is
• what each layer should own
• why they should not grow separate workflows
• how content-i18n splits core, CLI, and MCP

What CLI is

CLI means command-line interface, an interface where users operate a program through terminal commands

My Blog already had cmpt-translate, so pages could be translated into English at runtime

But during coffee chats in Toronto, someone directly suggested this: if the Blog is part of my portfolio, the default language should be English

That was not about a missing feature

It was about what the main body of the content really is

Runtime translation can turn a page into another language, but it does not mean I really have English content, and it does not mean I have a workflow for maintaining English posts over time

This post records how I installed ArgoCD into a k3s cluster, created an ArgoCD Application, and switched the whole CD flow from “GitHub Actions directly running kubectl apply” to “git is the source of truth and ArgoCD performs sync.”

Control Flow Shift

flowchart TD
    subgraph Push-based
        P1[Developer push] --> P2[GitHub Actions]
        P2 -->|kubectl apply + K8s credentials| P3[K8s Cluster]
    end

    subgraph Pull-based GitOps
        G1[Developer push] --> G2[GitHub Actions]
        G2 -->|push image + update YAML| G3[Git Repo]
        G3 -->|ArgoCD polls every 3min| G4[ArgoCD in Cluster]
        G4 -->|kubectl apply internal| G5[K8s Cluster]
    end

flowchart TD
    subgraph Push-based
        P1[Developer push] --> P2[GitHub Actions]
        P2 -->|kubectl apply + K8s credentials| P3[K8s Cluster]
    end

    subgraph Pull-based GitOps
        G1[Developer push] --> G2[GitHub Actions]
        G2 -->|push image + update YAML| G3[Git Repo]
        G3 -->|ArgoCD polls every 3min| G4[ArgoCD in Cluster]
        G4 -->|kubectl apply internal| G5[K8s Cluster]
    end

flowchart TD
    subgraph Push-based
        P1[Developer push] --> P2[GitHub Actions]
        P2 -->|kubectl apply + K8s credentials| P3[K8s Cluster]
    end

    subgraph Pull-based GitOps
        G1[Developer push] --> G2[GitHub Actions]
        G2 -->|push image + update YAML| G3[Git Repo]
        G3 -->|ArgoCD polls every 3min| G4[ArgoCD in Cluster]
        G4 -->|kubectl apply internal| G5[K8s Cluster]
    end

The root issue in push-based CD is a blurry security boundary: the CI runner holds K8s credentials, and if those credentials leak, an attacker can operate the cluster directly. Pull-based keeps control inside the cluster, and CI only needs permission to write git.

This post records how I upgraded a GitHub Actions pipeline from basic to actually usable: trigger design, path filters, concurrency, cache, then automatic CI updates to deployment.yaml to complete a GitOps closed loop. At the end, I compare Jenkins and CircleCI.

Event model design

Each of the three triggers has its own purpose:

A common way to push Docker images from GitHub Actions to GCP is to create a service account, download a key JSON, and store it in GitHub Secrets. It works, but the key is a long-lived credential. If it leaks, you are in trouble.

In this post, I walk through the bootstrap layer I built with Terraform: WIF setup, Artifact Registry, least-privilege service account, and the GitHub Actions workflow that ties everything together — with no service account key at all. I use OpenTofu in practice (the open-source Terraform fork), and the syntax is fully compatible with Terraform.

This post covers core System Design concepts frequently appearing in SRE interviews: Redis data structures and use cases, four Rate Limiting algorithms, Circuit Breaker’s three states, and common design patterns for Scaling Reads and Scaling Writes — the building blocks behind any high-traffic deployment.

Redis

Memory-Speed Lookups Versus Disk-Latency Queries

Every database read involves disk I/O with latency around 1-10ms. Redis stores data in memory with latency around 0.1ms. For hot data (frequently read, infrequently changed), caching can reduce database pressure by orders of magnitude.