Workflow
How this all actually runs
Not a diagram of one project — the loop underneath all of them. Distilled from operating this lab, not written in advance of it.
01 / OBSERVE
Check the real state
"Synced" is not "deployed." A push succeeding is not proof the repository still exists — a whole day's work once landed in a repo that had been scheduled for deletion, because the old path still redirected and every push reported success. Before trusting any claim — including an old plan's own reasoning, or a green checkmark — check the thing itself.
02 / FRAME
Define the finish before changing anything
Every non-trivial task is saved as a plan before implementation: observable outcome, scope, one authority per fact, material risks, ordered checks and stop conditions. Cross-system work also names its owner — Harumi, Cloudflare, or a maintenance gate — so “managed elsewhere” never becomes invisible debt. Once that contract is read back, implementation starts without repeating analysis as ceremony.
03 / CHANGE
Change one authority, with its guard
Make the smallest coherent change in the canonical source. A new rule ships with an executable check in the same commit; duplicated facts must be generated or asserted. Diff before anything irreversible, and test the guard with a negative case — a checker that has only ever printed green has not proved anything.
04 / PROVE
Prove the exact change in production
Push to main, let the shared pipeline build and scan, then prove that ArgoCD reconciled the current commit, the workload carries that image, the pipeline that produced it actually passed, and the real route serves the expected behavior. ArgoCD deploys from Git whether or not CI succeeded, so a green sync over a red pipeline looks identical to success — and per-path build rules can promote one component while leaving another behind. “Synced,” “pipeline passed,” and “latest” are intermediate signals; none identifies the exact change by itself.
05 / RETAIN
Turn the result into the next input
Update the plan, canonical documentation, incident record and reusable memory in the same pass, then read them back. The internal knowledge graph is a read-only projection rebuilt from those sources, with broken links, ambiguous identities, provenance and freshness checked automatically. Its output becomes the baseline for the next observation.
LOOP MODEL
One loop, three timescales
The same mechanism does three different jobs. Keeping them separate prevents “continuous improvement” from becoming an untestable slogan.
ITERATION / ONE PASS
Move one bounded change through the loop
An iteration starts from measured state, receives a Plan-sized contract, and either reaches production proof or moves backward to the state whose gate failed. It never skips ahead.
EVOLUTION / MANY PASSES
Change the workflow only from measured friction
A repeated failure may change a runbook or reusable skill only when the lesson generalises. The changed rule ships with a negative fixture, so the next iteration can enforce it instead of merely remembering it.
CLOSURE / RETURN PATH
Make the result observable again
Proof, Plan state and canonical knowledge must agree, then a fresh real-state sample becomes the new baseline. That return path is what turns a delivery pipeline into a closed learning system.
Closure is not the end of the work. It is the moment the repository, deployed revision, runtime evidence, plan and durable record agree strongly enough to become the next observation. Internal operational evidence stays private; the knowledge graph is rebuilt from canonical sources instead of edited into agreement.