feat: Add findings backlog as pragmatic alternative to risk register

New: assessment-templates/findings-backlog.md
  Design principles: lives where client works, every finding has an owner,
  feeds the housekeeping stream, accumulates from all sources.
  Format: 6-field minimal entry (ID, finding, source, priority, owner,
  status) with optional target date/effort/notes/closed date.
  P0/P1/P2 priority using kill chain test.
  Flat file template for Git-based clients.
  Population guide: Day 30 (from Brownhat), subsequent modules, continuous
  tools (ASTRAL drift, PULSAR alerts, Elysium, BloodHound).
  Monthly housekeeping cycle structure.
  Relationship to formal risk register explained.
  Backlog health indicators (warning signs it is not functioning).

Wired into existing framework:
  move-fast-and-fix-things.md: Rule 4 now names the backlog as the queue
  rapid-modernisation-plan.md: Day 30 item 7 and Phase 1 action updated
  engagement-model.md: Section 4 deliverables table updated at all stages
  assessment-templates/README.md: Production-ready templates section added
  index.md: Findings Backlog added to Assessment and Tools table

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

antifragile-consulting/assessment-templates/README.md

@@ -2,7 +2,18 @@
 
 > *"What gets measured gets managed. What gets managed honestly becomes antifragile."*
 
-This directory contains diagnostic tools, maturity models, and assessment resources for evaluating organizational antifragility. Two production-ready tools are available now; additional assessments are in active development.
+This directory contains diagnostic tools, maturity models, and assessment resources for evaluating organizational antifragility.
+
+## Production-Ready Templates
+
+| Template | Purpose |
+|----------|---------|
+| [Findings Backlog](findings-backlog.md) | Single source of truth for all findings across every module and diagnostic. The input queue for the housekeeping stream. Pragmatic alternative to a formal risk register for organisations that do not have one. |
+| [NIST CSF 2.0 Baseline Assessment](nist-csf-baseline.md) | The Brownhat Diagnostic: structured 2-half-day workshop, gap analysis, kill chain identification |
+| [Module Completion Report](module-completion-report.md) | Completion package template for every module; includes backlog update |
+| [Antifragile Risk Register](antifragile-risk-register.md) | Formal risk register template; the backlog feeds into this for organisations with mature risk management |
+| [Risk Register Example](risk-register-example.md) | 8 fully populated entries from a realistic engagement — calibration reference |
+| [M365 Project Risk Register](m365-project-risk-register.md) | M365-specific risk register with phase gates |
 
 ## Planned Assessments
 

antifragile-consulting/core/engagement-model.md

@@ -211,11 +211,11 @@ Each module documents its prerequisites in detail in [Modular Engagements](modul
 
 | Stage | Deliverable |
 |-------|-------------|
-| Brownhat Diagnostic | Current-state assessment report (6-domain, kill chain, quick wins) + prioritised module roadmap |
+| Brownhat Diagnostic | Current-state assessment report (6-domain, kill chain, quick wins) + prioritised module roadmap + **findings backlog opened** (all diagnostic findings entered with P0/P1/P2 priority and named owner) |
-| Module kickoff | Written scope agreement; access checklist confirmation; communication channel setup |
+| Module kickoff | Written scope agreement; access checklist confirmation; communication channel setup; backlog reviewed and updated with module-specific prerequisites |
-| Weekly (during delivery) | Change log update; check-in summary (decisions made, items pending, risks) |
+| Weekly (during delivery) | Change log update; check-in summary (decisions made, items pending, risks); backlog items resolved this week noted |
-| Module completion | Configuration baseline document; scripts/rules in client repository; operating runbooks; risk register update; metrics baseline; next-step recommendation |
+| Module completion | Configuration baseline document; scripts/rules in client repository; operating runbooks; **backlog updated** (items closed with evidence, new findings added); risk register update where one exists; metrics baseline; next-step recommendation |
-| Retained relationship | Monthly advisory summary or capability review report |
+| Retained relationship | Monthly advisory summary or capability review report; **backlog health review** (P0 count, items closed this cycle, blockers) |
 
 **Ownership**: Every script, detection rule, query, configuration file, and document produced during an engagement belongs to the client permanently. We do not retain privileged access to client environments after an engagement closes. We do not license anything we build — it is yours.
 

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

@@ -107,7 +107,7 @@ Housekeeping is not janitorial work. It is attack surface reduction at a structu
 - 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.
+**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 the [Findings Backlog](../assessment-templates/findings-backlog.md) — the single place where every finding from every diagnostic and module lands, prioritised, owned, and tracked to closure. The backlog is populated from module findings and from continuous discovery tools (ASTRAL drift, PULSAR alerts, quarterly BloodHound and Elysium runs). 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.
 
 ---
 

antifragile-consulting/index.md

@@ -84,6 +84,7 @@ Operational and persuasion documents used in engagements. **Start every new clie
 
 | Document | Purpose | Audience |
 |----------|---------|----------|
+| [Findings Backlog](assessment-templates/findings-backlog.md) | Single source of truth for all findings across every engagement; input queue for the housekeeping stream; pragmatic alternative to a formal risk register | Consultants, IT Leads, Client Teams |
 | [NIST CSF 2.0 Baseline Assessment](assessment-templates/nist-csf-baseline.md) | The Brownhat Diagnostic: structured 2-half-day workshop, gap analysis, prioritised module roadmap | Consultants, CISOs, IT Managers |
 | [NIST CSF 2.0 — česká verze](assessment-templates/nist-csf-baseline-cs.md) | Brownhat Diagnostika: dotazníky a průvodce workshopem v češtině | Consultants running Czech-language workshops |
 | [Module Completion Report](assessment-templates/module-completion-report.md) | Template for the deliverable package at the end of every module | Consultants |

antifragile-consulting/playbooks/rapid-modernisation-plan.md

@@ -41,7 +41,7 @@ The three milestone dates — Day 30, Day 90, Day 180 — are not arbitrary prog
 | 4 | **T0 accounts hardened** — every Global Admin, Domain Admin, and high-privilege service principal identified; MFA enforced; documented with owner | CA sign-in logs show MFA enforced for T0 accounts |
 | 5 | **Public attack surface report** — all internet-facing assets enumerated; P0 findings (internet-exposed + critical CVE) identified and prioritised | Delivered report |
 | 6 | **Quick wins closed** — up to 5 immediate improvements from Brownhat findings, using existing tools, zero procurement | Closed items documented in change log |
-| 7 | **Stale account queue opened** — full list of candidates generated and prioritised; named owner and monthly cadence confirmed | Queue visible in agreed tracking system |
+| 7 | **Findings backlog opened** — all Brownhat Diagnostic findings entered with P0/P1/P2 priority, owner assigned per item, monthly cadence confirmed; this is the input queue for the housekeeping stream | Backlog visible in agreed system; all findings from items 1–6 above entered |
 
 **The Day 30 value**: You know your kill chain. Your M365 configuration is under version control and your audit logs are being retained — permanently, from this day. Your most privileged accounts are hardened. This stands on its own regardless of what follows.
 
@@ -178,7 +178,7 @@ Target: privileged accounts only. Not all accounts.
 | Restrict or close the highest-risk vendor access paths | Security / Procurement | Vendor access changes confirmed |
 | Implement basic network segmentation between IT and OT (if applicable) | Network / OT | Segmentation policy; validated firewall rules |
 | Phase 1 review: re-run BloodHound and Elysium against week 1 baseline | Security | Before/after comparison; revised kill chain assessment |
-| Establish housekeeping queue: stale accounts, orphaned permissions, legacy protocols | IAM / Security | Queue populated; named owner; monthly cadence confirmed |
+| Establish findings backlog: all Phase 1 findings entered with priority, owner, target date | IAM / Security | [Findings Backlog](../assessment-templates/findings-backlog.md) populated; named owner; monthly housekeeping cadence confirmed |
 
 ### Phase 1 Exit Criteria