feat: Add housekeeping stream and greenfield capability as Rules 4 and 5

move-fast-and-fix-things.md: Three Rules -> Five Rules.
Rule 4: Housekeeping as a permanent stream (named owner, cadence, queue).
Rule 5: Greenfield capability as standard operational activity every 5 years.
Updated pillar mapping table.

antifragile-manifest.md: Pillar 1 Antifragile Moves: greenfield capability
as the ultimate expression of structural decoupling. Controlled burn framing.

Co-Authored-By: Tom Kracmar <tom+claude@cat6.cz>

antifragile-consulting/core/antifragile-manifest.md

@@ -47,6 +47,7 @@ Cloud architectures have created an illusion of resilience through scale. In rea
 - **Design graceful degradation**: Every critical function must have a fallback mode that operates at reduced capacity without the external dependency.
 - **Practice controlled failure**: Introduce chaos into non-production environments. If a system cannot survive the simulated failure of a dependency, it will not survive the real one.
 - **Establish exit architectures**: For every major platform dependency, maintain a technical and procedural path to migration that can be executed within 90 days.
+- **Build greenfield capability**: The ultimate expression of structural decoupling is the ability to rebuild the entire environment from scratch — cleanly, from documentation and version-controlled configuration, without inheriting the compromised state. An organisation that can execute a planned greenfield deployment every five years or so is in a structurally different risk position than one for which greenfield is a nightmare scenario. This is the controlled burn: organisations that never rebuild accumulate the technical debt and undocumented dependencies that make eventual failure catastrophic. See [Move Fast and Fix Things — Rule 5](move-fast-and-fix-things.md#rule-5-build-toward-greenfield-capability).
 
 ### Executive Framing
 

antifragile-consulting/core/move-fast-and-fix-things.md

@@ -49,7 +49,7 @@ The antifragile consultant's first duty is not to recommend new spending. It is
 
 ---
 
-## The Three Rules
+## The Five Rules
 
 ### Rule 1: Start With What You Own
 
@@ -87,17 +87,59 @@ A fix that does not generate intelligence is a fix that will rot. Every remediat
 | "We rotated the password." | "We rotated the password and vaulted it in the PAM with checkout logging." |
 | "We fixed the firewall rule." | "We fixed the firewall rule and added a monthly rule review to the change process." |
 
+### Rule 4: Run Housekeeping as a Permanent Stream
+
+This is the rule most often acknowledged and least often followed. In every engagement, cleanup is identified as necessary. In almost no engagement is it ever finished. Stale accounts accumulate. Orphaned permissions persist. Old devices stay enrolled. Legacy protocols remain enabled because removing them requires a change window that never gets scheduled.
+
+The correct response is not to add cleanup to the project backlog. It is to **establish housekeeping as a dedicated, permanently resourced stream with its own queue, its own cadence, and its own accountability**.
+
+Housekeeping is not janitorial work. It is attack surface reduction at a structural level. Every stale account is a credential that can be compromised without detection. Every orphaned permission is a privilege escalation path that BloodHound will find. Every legacy protocol still enabled is an authentication downgrade waiting to happen. The environment accumulates new objects continuously — every employee, every project, every vendor relationship adds accounts, permissions, and configurations. Almost nothing removes them automatically. Without a permanent housekeeping stream, the attack surface grows without bound regardless of what else you fix.
+
+**What housekeeping covers:**
+
+- Stale user accounts: departed employees, contractors, service accounts with no owner
+- Orphaned group memberships and permissions that outlasted the project that created them
+- Old app registrations and service principals — often the most overlooked and most dangerous
+- Enrolled devices that are no longer in use
+- Conditional Access policies with no named owner and no documented purpose
+- Legacy protocols: NTLM, basic authentication, SMBv1, NTLMv1 — things that should have been disabled years ago
+- DNS records for decommissioned services
+- Firewall rules added for temporary access that became permanent
+- Old GPOs, old admin rights, old certificates
+
+**The engagement implication**: Every module scoping conversation must include a housekeeping component. It is not optional and not deferrable. The client names a resource, a cadence (minimum monthly), and a queue. The queue is populated from module findings and from continuous discovery. Progress is tracked and reviewed at every steering committee. If there is no resourcing for housekeeping, the engagement model must reflect that — because every fix we make will be partially undone within 18 months by new accumulation if the stream does not exist.
+
+---
+
+### Rule 5: Build Toward Greenfield Capability
+
+The cheapest and fastest recovery from a serious breach is often a greenfield deployment — rebuilding the environment from scratch on clean infrastructure rather than remediating a compromised one. Most organisations treat this as a nightmare scenario. The goal is to treat it as a **standard operational capability exercised every five years or so** — not something that wakes you up at night, but something you have done before and know how to do again.
+
+This is the ultimate defender's power move. An attacker's leverage in a breach depends largely on your inability to walk away from the compromised environment. If you can build the parallel company and burn the old one, that leverage disappears. Ransomware becomes an inconvenience rather than an existential event. The threat model changes fundamentally.
+
+**What greenfield capability requires:**
+
+- **Everything documented as code**: infrastructure configuration, security baselines, identity architecture, network topology. If you cannot rebuild it from documentation in a clean environment, you do not own it — you are renting it from accumulated history.
+- **Configuration under version control**: M365 policy state in ASTRAL, infrastructure definitions in IaC, runbooks in a repository. The new environment can be provisioned from the same source of truth.
+- **Clean data separation**: you know where your data is, what form it is in, and how to migrate it. Data that cannot be migrated cleanly is a dependency you have not acknowledged.
+- **Tested migration procedures**: the greenfield capability is not real until it has been exercised. Partial migrations, parallel-environment tests, and recovery drills build the muscle. Each module completion should leave the client one step closer to a documented, tested rebuild path.
+- **Vendor independence at critical layers**: you cannot rebuild greenfield if the new environment depends on the same compromised vendor. Optionality (Pillar 2) is the prerequisite.
+
+**The cadence target**: An organisation that can execute a planned greenfield migration in 90 days — with data integrity, minimal service disruption, and full security posture — is in a structurally different risk position than one for which greenfield is theoretical. This is not a one-time project. It is a capability you build, test, and maintain.
+
+**The controlled burn**: forests that are never burned accumulate the fuel for catastrophic fires. Organisations that are never greenfield-deployed accumulate technical debt, legacy dependencies, and accumulated compromise that makes eventual failure more severe. Planned greenfield on a 5-year cycle is the controlled burn that prevents the uncontrolled one.
+
 ---
 
 ## Mapping to Antifragile Pillars
 
 | Antifragile Pillar | Move Fast and Fix Things Expression |
 |-------------------|-------------------------------------|
-| **Structural Decoupling** | Identify and eliminate hidden dependencies before they become fatal. Do not add new platforms to solve problems that abstraction can solve. |
-| **Optionality Preservation** | Maximize existing investments to preserve budget for strategic optionality. Every unnecessary purchase reduces your ability to pivot. |
+| **Structural Decoupling** | Identify and eliminate hidden dependencies before they become fatal. Greenfield capability is the ultimate expression: if you can rebuild cleanly, no single vendor or compromise holds you hostage. |
+| **Optionality Preservation** | Maximize existing investments to preserve budget for strategic optionality. Greenfield deployment requires vendor independence at every critical layer — build and maintain that independence now. |
 | **Stress-to-Signal Conversion** | Every fix must generate telemetry. Incidents are not failures; they are unpaid penetration tests. Convert their lessons into structure. |
-| **Sovereign Intelligence** | Use what you own first. Local AI on existing hardware beats cloud AI on a credit card. Your data should improve your models, not someone else's. |
-| **Asymmetric Payoff Design** | Small, fast fixes on the kill chain yield disproportionate risk reduction. Do not distribute effort evenly; concentrate it where failure is existential. |
+| **Sovereign Intelligence** | Use what you own first. Your data, your configurations, your runbooks — all under version control, all portable, all yours. Housekeeping keeps it clean. Greenfield capability proves it. |
+| **Asymmetric Payoff Design** | Small, fast fixes on the kill chain yield disproportionate risk reduction. Housekeeping and greenfield capability are the highest-leverage long-term investments: small ongoing cost, enormous reduction in catastrophic risk. |
 
 ---