TL;DR — One person collaborating with four AI windows at once, and self-discipline failed the very first time I rushed a commit. This piece documents how I evolved a governance system out of real incidents: the five articles of a constitution, the governance-lint pre-commit hook, 75-endpoint contract tests, and a 12,946-file recovery drill — every layer of the system has a corresponding incident number.
On May 22, 2026, my commit got blocked.
Not by a colleague — there are no other humans on the team. What blocked me was a 229-line bash script — governance-lint.sh, hooked into the git pre-commit hook. It coldly spat out Strict fails: 4: two handoff documents were missing the status frontmatter field and had no ## Consequences section.
What’s interesting is that I had an AI write this script myself. I defined the rules myself, too. But when I was rushing to commit 48 files at once, I didn’t notice the violations myself. The machine remembered for me.
This isn’t some impressive technical story. This is the record of a non-full-time engineer who, in the course of collaborating with four AI windows, stumbled into pitfalls and patched holes all along the way, and eventually grew a governance system.
Three Holes Blew Up the Same Day — Why “Just Be Careful” Isn’t Enough
The story starts on April 19, 2026. That day I was using three windows — Chat, Cowork, Code — simultaneously to work on the paulkuo.tw project. By the afternoon, three problems surfaced almost at once:
First, the session-handoff skill was at v5.3 at the repo layer but still stuck at v4.13 at the cloud layer. Both sides thought they were the latest, and neither knew the split existed.
Second, the Cowork window cited a string of “verified” facts to make a judgment, but tracing back, those facts had never had the verification command run on them. The entire chain of reasoning was built on air — we later called it “castle in the sky.”
Third, the same piece of memory was stored once in CLAUDE.md and once in the memory file, with not-quite-identical content. Change one, and the other doesn’t know.
The common root of all three problems isn’t that anyone slacked off, but that there was no architectural mechanism to ensure “who has the final say.” When you have only one AI conversation window, this kind of problem doesn’t exist. But when your workflow is Chat for planning, Cowork for reconnaissance, Code for implementation, and Paul for the final call — four participants each with their own memory, each producing conclusions — “factual consistency” becomes a problem that must be engineered.
I tried writing a few more lines of rules into CLAUDE.md. It helped, but I quickly discovered: attention collapses under the pressure of rushing a commit. A passive document is not an active line of defense.
So we did something that sounds a bit absurd: we wrote a constitution.
What Exactly Do the Five Articles of the Human-AI Collaboration Constitution Govern?
“Constitution” isn’t rhetoric. The structure of this document really does borrow the logic of constitutional design: first define identity (who are the participants), then define authority (who can do what), and finally define a dispute-resolution mechanism (what to do when something goes wrong).
Each of the five articles corresponds to a pitfall we stumbled into:
Article One: the SSoT principle. The git HEAD of the paulkuo.tw repo is the single source of truth for all rules, skills, governance documents, memory, and the to-do queue. This isn’t a design preference; it’s the result of elimination — I investigated the official Anthropic documentation, which plainly states “Custom Skills do not sync across surfaces… You’ll need to manage and upload Skills separately for each surface.” Industry solutions also point overwhelmingly to git-first. Everyone uses git as the SSoT, because there’s no other option.
Article Two: parity of carriers. The cloud (Claude.ai) is always a downstream mirror and never enters the collaboration mainline. This article was established in response to the skill-split incident. The split between v5.3 and v4.13 happened precisely because the cloud layer was treated as “another master copy.”
Article Three: division of authority and responsibility. This article is the most subtle and the most easily misunderstood. It does not lock authority down — Chat can only do X, Code can only do Y. It’s “flexible primary responsibility + rigid verification”: who is responsible for what can be adjusted, but the obligation of cross-validation is rigid. What Code writes must be verified by Cowork, and Cowork’s reconnaissance conclusions must be reproducible by Code. This is consistent with the logic of the constitutional design of the separation of powers — the checks between the executive, legislative, and judicial branches aren’t optional courtesies, but structural obligations. This piece is part of the “Intelligence and Order” series, which explores exactly how such order is reconstructed within human-AI collaboration.
Article Four: memory hierarchy. A piece of fact is stored only in one responsible layer; cross-layer copying is prohibited. Within the same layer, each piece of memory must be atomized — one file says one thing. This article was established in response to the memory-duplication incident, and it later became the basis for restructuring the entire memory system.
Article Five: memory expansion. To connect a new memory carrier (such as Mem0, Letta, or an MCP memory server), you must go through a formal ADR (Architecture Decision Record) process. You can’t just hook it up because one day you feel “this tool is handy.”
On the day we made the call, Cowork and I discussed from four to five in the afternoon. As soon as v0.1 was written, I found it inadequate and immediately revised it to v0.2. The entire constitution was born in the crisis of a single day.
From Document to Defense: How governance-lint Turns Rules into Code
After the constitution was written, things were calm for six days. Then on April 25, we stumbled again.
A batch of handoff documents had inconsistent frontmatter formats — some missing status, some without a ## Consequences section. These were stipulated in both CLAUDE.md and the constitution, but they kept getting missed. The reason is simple: the rules were written in documents, and documents don’t pop up to stop you when you git commit.
This made us realize something clearly: self-discipline (autonomy) isn’t enough; you need external discipline (heteronomy). governance-lint is the product of this line of thinking — a bash pre-commit hook, 229 lines, responsible for checking, at the commit stage, the rules a machine can check.
Two hard checks are currently enabled. The first scans all handoff documents to confirm the frontmatter has status (only the four values Draft / Accepted / Superseded / Deprecated are accepted) and the body has a ## Consequences section. The second scans articles’ pillar field to confirm the value is one of the five legal values ai | circular | faith | startup | life — earlier an article filled in circular-economy and the build blew up on the spot.
There are several deliberate design decisions. Historical documents have an exemption mechanism — handoffs from before the constitution aren’t bound by the new rules; this is a one-time amnesty. But new documents must comply. If you really need to bypass it, you can use --no-verify, but you must annotate [skip-lint-recovery] in the commit message and state the reason. The escape hatch exists, but the price of escaping is leaving a record.
The interception on May 22 was the first time it truly came into play in a production environment. In a big batch commit of 48 files, the human eye missed four violations; the machine didn’t. After fixing them and committing again, all 13 commits passed governance-lint.
The evolution path of this system is very typical: a single line of rule in CLAUDE.md → violated more than three times → upgraded to a pre-commit hook. We call this path “incident-driven institutional evolution” — observe first, then automate. Don’t over-engineer on the first occurrence.
GitHub Disconnection: A Stress Test of the Governance System
On April 29, 2026, my GitHub account zarqarwi was suspended. No warning, no explanation.
The repo wasn’t lost — the local copy was intact. But the entire workflow snapped instantly: Pages auto-deployment was dead, the Issues tracker was gone, GitHub Actions all halted. The complete engineering record of this incident is in another article; here I’ll only cover the part related to the governance system.
The stress test revealed two things.
First: the governance system’s SSoT principle (Article One) was a lifesaver. Because all rules, documents, and memory were in local git, GitHub going down just meant one fewer remote, not a lost source of truth. Within 48 hours we switched to dual remotes on Codeberg + GitLab, and the workflow degraded not at all. Had the SSoT been placed in GitHub Issues or any cloud service at the time, this story would have ended completely differently.
Second: the crisis accelerated institutional building. During the period from when the account was suspended to when it was restored, we did a 12,946-file recovery drill (decompressing + verifying from an encrypted backup), wrote a five-layer resilience architecture, brought online a 75-endpoint contract-test design, and reinforced the commit-msg hook’s cross-subproject impact detection. Not because we had the time to do it, but because the question “if even GitHub can go down, what can’t go down” forced you to think through every layer of defense.
Here’s where the resilience architecture and the governance system intersect: resilience handles “what to do when an external service goes down,” and governance handles “what to do when internal collaboration gets chaotic.” Their shared conviction is the same — you can’t let the failure of any single node bring the whole system to a halt. The first principle of the five-layer resilience architecture, “No Single Point of Control,” and the SSoT principle of Article One of the constitution, are essentially the external and internal versions of the same thing.
Incidents Become Institutions: The Origins of Each Layer of Defense
Looking back over the entire timeline, there’s a clear pattern:
April 19, 2026, three governance holes blew up at once → the constitution v0.2 was written that day. April 20, gave the three AI windows a constitution exam → found Cowork only scored 70%, Code scored 97%. April 25, handoff-format violations accumulated to N≥3 → the governance-lint pre-commit hook went live. April 29, GitHub account suspended → the five-layer resilience architecture was fully built out. May 10, a Worker API security audit found 75 endpoints → the three-layer contract-test architecture was designed. May 12, the auto-optimization system had been halted for seven weeks → formal retirement + a paradigm shift to distributed autoresearch.
The birth certificate of every layer of institution carries an incident number. Not a single layer was “designed in advance and waiting to be used.”
This brings to mind a name. We call this thing Governance Harness — not a governance cage, but a harness. A harness’s function isn’t to restrict your movement, but to let you run more boldly. governance-lint blocking a commit isn’t to punish carelessness, but to let you not have to be distracted remembering rules while rushing. The contract tests running automatically every day isn’t out of distrust, but because the security state of 75 endpoints shouldn’t be maintained by human memory.
The upgrade ladder is fixed: observe a problem → first write it into a document as a soft rule → observe for 1-2 weeks → if the same kind of problem recurs N≥3 times → upgrade to automation. governance-lint went from a single sentence in CLAUDE.md to a pre-commit hook in six days. The commit-msg hook’s cross-project impact detection went from an impact-map document to automation in two weeks. Speed isn’t the point; the pattern is the point: stop the bleeding first, then cure the root cause. Automate only after you’ve observed enough.
The Blind Spots the Exam Revealed
Let me end with a story.
The day after the constitution was written, we did something perhaps few people have done: we gave the three AI windows a governance exam. Fifteen questions, split into three tiers — factual, judgment, and scenario questions.
The result was Code 97 points, Chat 77 points, Cowork 70 points.
The lowest score was Cowork — and in our architecture, Cowork plays the “judicial” role, responsible for verification and arbitration. The role that should understand the rules best scored the worst.
The reason is very concrete: Cowork’s sandbox environment physically cannot see the real-time state of certain files, so for factual questions involving precise line counts and version numbers, it could only answer from memory — and memory drifts. Chat’s problem is more fundamental: it has no Read capability at all, so all its “precise facts” are secondhand.
This result directly led to two institutional corrections: restricting Chat’s authority to answer precise-fact queries, and mandatorily inserting into Cowork’s workflow a verification step that “sandbox data does not equal Mac local data.”
Governance isn’t something that ends once the rules are written. Every single day you collaborate with it, it’s taking an exam.
Frequently Asked Questions
Q: Why does human-AI collaboration need a governance system? Can’t you just use it directly?
A single AI conversation doesn’t need one. But when you use Chat for planning, Cowork for reconnaissance, Code for implementation, and Codex for auditing all at once, the four windows each have their own memory, each makes its own mistakes, and each produces conclusions that contradict the others. Without a governance system, you’ll spend enormous amounts of time on questions like “where did we leave off last time,” “is this number real,” and “who has the final say.” A governance system lets you put your attention on the judgments that really matter, rather than on repeated cross-checking.
Q: What exactly does the governance-lint pre-commit hook check?
Currently two checks are enabled: first, the frontmatter of handoff documents must contain a status field (only the four values Draft/Accepted/Superseded/Deprecated are accepted) and the body must have a Consequences section; second, an article’s pillar field must be one of five legal values. When a rule is violated, the commit is blocked and must be fixed before pushing. This is a 229-line bash script hooked into the git pre-commit hook.
Q: Is this governance system for teams or only for individuals?
It’s currently designed for one person + multiple AI windows. But the underlying logic — the SSoT principle, the cross-validation obligation, incident-driven institutional upgrades — holds equally well in small-team scenarios. The difference is that a team needs to handle permission and trust issues between people, whereas this system handles the factual consistency issue between a human and AI.
Q: What is the upgrade ladder of incident-driven institutional evolution?
Observe a problem → first write it into a document as a soft rule → if the same kind of problem recurs N≥3 times → upgrade it to automation (hook, cron, script). That’s exactly how governance-lint went from a single line of text in CLAUDE.md to a pre-commit hook. The key is not to over-automate on the first occurrence — observe the pattern first, then decide.
💬 Comments
Loading...