What_Breaks_at_Scale

The system in Part 1 worked because it governed one project at a time. At fourteen projects across five GitHub repositories, it stopped working in three specific ways. First, rule drift: the same convention (strict TypeScript, Zod validation, no hardcoded secrets) was written into five separate CLAUDE.md files, and when one got updated the others didn't. An agent working in GEO Audit would follow the updated error-handling rule while an agent in FitChecker followed the stale version.

Second, planning chaos: FitChecker's planning folder had 22 files dumped flat in the root -- briefs mixed with research mixed with archived decisions -- and an agent entering that folder had no way to distinguish current work from obsolete context. Third, decision fragmentation: a pricing decision made for GEO Audit (three-tier Starter/Growth/Pro) had no mechanism to propagate to FitChecker, so agents in each repo made contradictory pricing assumptions.

Gartner's 2025-2026 data quantifies this pattern at industry scale -- a 1,445% surge in multi-agent system inquiries, with fewer than one in four organisations successfully scaling agents to production. The bottleneck is not the model. It is the governance.

The_Rule_Cascade

The fix borrows from CSS. In a stylesheet, styles cascade through three layers: browser defaults, site-wide rules, and component-scoped overrides. The agent governance system works identically. The global CLAUDE.md at ~/.claude/CLAUDE.md (60 lines) sets baseline methodology -- TypeScript strict mode, Zod validation, Conventional Commits, accessibility standards, agent coordination rules. These are the browser defaults: they apply everywhere unless explicitly overridden.

The project CLAUDE.md in each repo's root (under 200 lines) sets repository-specific conventions -- the stack, the architecture patterns, the git workflow for that codebase. Labs documents its chat engine layer, its CSS custom property system, and its manual versioning override. GEO Audit documents its API route structure and its Machine Clarity design system. These are site-wide rules: they override global defaults where the project needs something different.

The third layer is scoped rules in .claude/rules/*.md -- files with glob patterns that load conditionally when the agent touches matching file paths. FitChecker's admin.md rule file carries a glob of app/manage/**,app/api/manage/** and loads only when an agent edits admin module files, injecting 26 API route definitions, auth patterns, and pricing system details that would be noise in any other context. HackerNoon's research confirms the leverage: without governance hooks, Claude activated project-specific conventions only 25% of the time; with structured enforcement, that number exceeded 90%. The cascade is the enforcement mechanism -- no single file tries to contain everything, and each layer can be changed independently without breaking the others.

Two_CLAUDE.md_Files,_Two_Questions

Every project with both a planning folder and a GitHub repository gets two CLAUDE.md files, and they answer two completely different questions. The repo CLAUDE.md answers "how do we write code here?" -- it documents the stack, the build commands, the architecture conventions, the error handling patterns, the git workflow. The planning CLAUDE.md answers "what is this project and who works on it?" -- it documents the team assignments, the current phase, the deliverable standards, and the folder structure.

They never overlap. The repo CLAUDE.md for Labs says nothing about which agent handles copy versus frontend. The planning CLAUDE.md for Labs says nothing about CSS custom properties or chat engine architecture. The handoff between them is explicit: planning work produces approved specs in the briefs/ subfolder, an agent reads the spec, switches context to the GitHub repo, and ships code against the repo's CLAUDE.md conventions.

This separation exists because the failure mode of a single file trying to answer both questions is predictable -- it becomes a 400-line document that agents scan incompletely, where planning context bleeds into code conventions and neither audience gets what it needs. Owen Zanzal's Virtual Monorepo pattern across 35 repositories validated a complementary insight: context beats structure for AI effectiveness. Two focused files providing the right context at the right moment outperform one comprehensive file every time.

Folder_Architecture_for_Planning

Before standardisation, each planning folder was an archaeology project. FitChecker had 22 files in its root -- a brief next to a research dump next to an archived decision next to a deliverable draft. An agent entering that folder spent its first 50 messages just figuring out what was current.

The fix was a four-folder structure applied across all fourteen planning directories: briefs/ for approved specifications ready for implementation, research/ for background analysis and competitive intelligence, deliverables/ for completed output, and archive/ for anything superseded or acted upon. Each planning folder gets its own CLAUDE.md (30-50 lines) documenting the project team, current phase, and folder-specific conventions. This decision was logged in the cross-project decisions.md file so every agent building a new planning folder follows the same pattern.

The cost was an afternoon of reorganisation. The payoff is that any agent entering any planning folder -- regardless of which project, regardless of whether it has ever seen that project before -- knows exactly where to find current briefs, where to put research output, and what to ignore. Chroma Research's findings across 18 large language models confirm why this matters: context rot is an architectural property of transformer attention, not a capability gap. Reducing the noise an agent has to parse on entry directly improves the quality of every subsequent decision it makes.

Cross-Project_Awareness

Three files prevent agents from working in isolation. The first is decisions.md -- a cross-project decision log with seven entries covering pricing standardisation (all SaaS products use three-tier Starter/Growth/Pro), semantic-release adoption across all repos, WCAG 2.1 AA as mandatory for all UI, and planning folder structure standardisation. Any agent about to make a decision that could affect another project checks this file first.

The second is project-inventory.md -- a single document listing all fourteen projects with their current versions, statuses, team assignments, tech stacks, and dependencies. When an agent in Labs needs to reference GEO Audit's current version or FitChecker's tech stack, the answer is one file read away.

The third is inject-state.sh, a SessionStart hook that scans all five active repositories at session start and injects a live git status dashboard into the conversation -- last commit, current branch, uncommitted changes, each repo on one line. When Sheena starts a session to coordinate across projects, she sees immediately that FitChecker has uncommitted changes or that GEO Audit's last release was two days ago. Combined, these three files mean no agent starts a session without knowing what decisions have been made globally, what state every project is in, and what changed since the last session. The cost is three files totalling under 400 lines. The alternative -- agents making locally rational but globally contradictory decisions -- is what Gartner's data says kills three out of four multi-agent scaling attempts.

What_Stays_the_Same

The twelve agent personas from Part 1 did not change. Nix still owns frontend, Vera still writes copy, Jo still runs operations, Sheena still orchestrates, and all specialist AGENT.md files are in place. The system scaled by adding structure around the agents, not complexity to them.

The global CLAUDE.md, the project CLAUDE.md files, the scoped rules, the planning folder architecture, the cross-project state files -- every piece of scaling infrastructure is a text file that any agent reads on demand. No new tooling, no new model capabilities, no new API integrations. Each layer can be changed independently: updating the global CLAUDE.md to add a new coding standard propagates to every project automatically; adding a scoped rule to one repo affects only that repo; logging a new cross-project decision takes one file edit.

Agent Teams -- Claude Code's native multi-agent parallelism feature -- are documented and ready for Phase 2, but the current system handles the full fourteen-project workload without them. The CSS cascade analogy holds here too: the system's power comes from the specificity hierarchy, not from the complexity of any individual rule. The agents are simple. The governance makes them effective.