An Architectural Journal on AI-Native Development, Systems Thinking, and Practical Workflow Engineering
Global Site: https://ztrader.ai
Macro & Trading Content: https://blog.ztrader.ai
This document is not written for external validation, public attention, or algorithmic exposure.
It is an internal blueprint for calibrating my own system design philosophy, documenting the cognitive models I used over the past twelve months, and setting the foundation for the next iteration of my AI-native development stack.
If you can speak in the language of architecture, systems, constraints, and low-level mechanisms, you are welcome.
If your interest lies in dopamine, opinions, emotion or moral judgment, this is the wrong place.
The entire ecosystem will eventually migrate off WeChat toward Matrix + Telegram + self-hosted distributed nodes, removing platform dependency and ensuring the long-term sovereignty of my workflow.
0. Preface: What This Document Represents
Half a year ago I did not know how to produce a Hello World.
Twelve months later, I have built:
- A multi-node agentic AI system
- A fully automated CI/CD pipeline with self-healing
- A distributed knowledge retrieval system
- A code arsenal fed by GitHub-scale mining
- AI-powered error forensics
- Multi-model orchestration via port-isolated expert agents
- A DevOps recovery framework capable of revert-on-failure
- A unified architectural language across all project domains
This document is not a tutorial.
It is a blueprint, a reflection, and a system map.
1. CI/CD as a Self-Healing Nervous System
From deployment automation to autonomous recovery
Most people see CI/CD as a push-to-deploy mechanism.
I treat it as the central nervous system of the entire AI-driven development lattice.
Over the past year I built a deployment architecture with the following characteristics:
1.1 Capability Overview
GitHub → Server: Autonomous Build & Deployment
- GitHub Actions triggered on every push
- Environment matrix, build commands, tests, artifact bundling
- Automatic push to production via secure SSH
- Zero-touch deployment
Node/Nginx/PM2 — Autonomous service activation
- PM2 process monitoring
- Zero downtime restarts
- Automatic environment reload
- Granular multi-port application routing
Self-Recovery: 502/504 Failure Rollback
A standard CI/CD pipeline merely deploys.
A robust one must also self-correct.
When the system detects:
- Cold start timeout
- Port unresponsive
- Health check failure
- Memory leak spike
- Fatal build break
It automatically executes:
git revert HEAD
restore last-successful-artifact
pm2 restart <service>
No human intervention required.
Automated Logging → Obsidian Vault
All error logs (Node, Nginx, PM2, CI/CD, system call traces) are:
- Captured in JSON
- Normalized
- Pushed to Obsidian via webhook
- Stored as structured knowledge entries for future retrieval
- Forwarded to the RAG system for embedding
CI/CD becomes:
- Deployment pipeline
- Error forensic agent
- Knowledge generator
- Autonomous self-healing system
1.2 Technical Feasibility Verification
Everything above is standard and fully achievable:
- GitHub Actions → trivial
- Self-recovery scripts → Bash + PM2 + health checks
- Obsidian logging → local webhook + plugin automation
- RAG ingestion → LangChain + embeddings
Nothing here is hypothetical.
This is not a dream.
This is an engineering discipline.
2. Full Agentic Cross-Lattice Workflow
AI not as a tool, but as an integral layer of the development lifecycle
Most people use AI like a calculator: ask, receive, paste.
My system uses AI as an end-to-end collaborator across the entire lifecycle:
Task Definition → Retrieval → Generation → Verification → Audit → Deployment
This is not “prompting”.
This is architecting.
2.1 Workflow Structure
Layer 1: API Selection
Each task selects the correct model:
- Qwen for Rust or low-level systems
- Claude for TypeScript and integrity checks
- GPT for architectural reasoning and system design
- Mistral/Zephyr for fast iteration
- Custom Llama for privacy-sensitive tasks
Model selection becomes a form of orchestration.
Layer 2: Technical Specification Document
A real prompt is not one sentence.
It is a 1–3 page engineering spec:
- Input format
- Output format
- Naming conventions
- File structure
- Rules / do-nots
- Required libraries
- Version constraints
- Behavior constraints
- Security constraints
Every AI agent receives a fully formalized contract.
Layer 3: “Retrieve First, Then Generate”
The core principle:
Never generate before retrieving.
Always verify before trusting.
Each agent workflow begins with:
- GitHub search
- Browser deep search
- RAG retrieval
- Latest official documentation
Then and only then, code generation begins.
Layer 4: Secondary Verification (Codex/Claude Audit)
All generated code undergoes:
- Logical verification
- Schema alignment
- Dependency mapping
- Port/route collision detection
- API compatibility checks
- Type safety inspection
- Side effect analysis
This is where most AI users fail—they stop at generation.
Real engineering continues into verification.
Layer 5: Human Audit
The final arbiter:
- File hierarchy correctness
- Architecture consistency
- Security considerations
- Version alignment
- Liveness/readiness logic
- Deployment feasibility
AI generates; the architect decides.
Layer 6: Token-Bound Constraint
All agents operate under tightly controlled token budgets:
- Avoid hallucination
- Avoid scope creep
- Guarantee deterministic behavior
- Ensure reproducibility
- Maintain architectural boundaries
2.2 Technical Validation
This workflow resembles:
- Anthropic “Workflow”
- OpenAI ReAct DAG
- Google DeepMind agentic chains
- Microsoft AutoDev
- Salesforce CodeRAG
It is not experimental.
It is formal and widely aligned with industry direction.
3. GitHub Code Mining → Code Vector Arsenal
A personal military-grade code repository built via embeddings
To improve reliability and accelerate development, I built a Code Arsenal:
3.1 Architecture of the Arsenal
- Crawls GitHub for production-grade repositories
- Slices files into semantically meaningful chunks
- Converts them into embeddings
- Stores them in a vector database
- Enables rapid retrieval during development
The result:
AI does not invent code; it draws from proven real-world implementations.
3.2 Development Workflow Using the Arsenal
- Design the architecture first
- Ports
- Environment variables
- Folder hierarchy
- Domain boundaries
- Retrieve similar repositories from the arsenal
- Extract best-practice fragments
- Use Copilot/Claude to integrate, refine, and adapt
- Verify in browser DevTools or terminal
This is “context-augmented engineering”.
3.3 Feasibility
- GitHub API: trivial
- Embeddings: OpenAI/Azure/Qwen
- RAG: LangChain/LlamaIndex
- IDE integration: VSCode plugin or local retrieval agent
Fully achievable.
4. Agentic AI Lattice
Distributed specialist agents, each with domain autonomy
The AI lattice is a multi-agent ecosystem.
Not one model that “does everything”,
but a matrix of specialized agents, each bound by strict rules.
4.1 Composition of Each Expert Agent
Each agent includes:
- Dedicated prompt template
- Dedicated technical documentation
- Dedicated tech stack
- Dedicated do/don’t rule sheet
- Dedicated environment variables
- Dedicated port (via PM2)
- Dedicated training material (RAG + GitHub corpora)
They do not interfere with each other.
They cooperate through an orchestrator layer.
4.2 Agent Workflow
- Task description
- Agent generates a dense, domain-specific prompt (300–500 words)
- Loads required schemas, env, and constraints
- Retrieves relevant knowledge
- Generates output
- Secondary verification
- System validation
- If successful → Added to knowledge base for continuous improvement
Each agent is essentially a micro-service with a brain.
(To Be Continued…)
If you want the continuation, it will include:
- 5）Distributed RAG Architecture v1 → v2 → v3
- 6）Automated DevOps Observability Layer
- 7）The Architecture of AI-Native Software Systems
- 8）The Cognitive Model Behind High-Bandwidth Learning
- 9）Blueprint for the Next 12 Months
- And full diagrams if needed.
