refactor(articles): standardize YAML front-matter across published and draft articles

Add consistent front-matter schema to CLAUDE.md and GROK.md, including title, date, topics, related articles, and abstracts. Apply similar front-matter to draft files (agile-stories.md, uses-and-abuses.md) and published articles (Agile-Or-Whatever-You-Call-It.md, Testers-As-Explorers.md, etc.) to improve indexing, searchability, and cross-referencing. Ensure topics use a controlled vocabulary and abstracts capture core theses.

CLAUDE.md

@@ -45,3 +45,24 @@ Gregory's articles have a distinctive style that Claude should understand and re
 - Work-in-progress goes in `articles/drafts/`
 - Images and assets are organised by type under `assets/` (clipart, general, memes)
 - Articles are written in Markdown with inline image references and hyperlinks
+
+### Front-matter Schema
+
+All published articles carry YAML front-matter:
+
+```yaml
+---
+title: "Article Title"
+date: YYYY-MM-DD          # original publication date
+topics: [topic-a, topic-b]
+related:
+  - other-article.md      # relative filenames within articles/published/
+abstract: >
+  Two or three sentences capturing the argument, not just the topic.
+---
+```
+
+- **topics** use a controlled but organically growing vocabulary: `epistemology`, `exploratory-testing`, `agile`, `bdd`, `reasoning`, `formal-logic`, `automation`, `philosophy`, `craft`, `resources`
+- **related** lists articles that this one explicitly builds on or cites; use filenames, not paths
+- **abstract** describes the argument or thesis, not just the subject area
+- Draft articles do not require front-matter until published

GROK.md

@@ -60,10 +60,38 @@ Grok excels as a creative, truth-seeking collaborator for this kind of reflectiv
 - Do not over-simplify complex ideas unless explicitly asked.
 
 ## Repository Conventions
+
+**Front-matter standard (applied to all published articles and drafts):**
+
+```yaml
+---
+title: Exact Title of the Article
+date: YYYY-MM-DD
+topics: [philosophy, craft, epistemology, exploratory-testing, agile]
+related:
+  - slug-of-related-article
+  - another-related-article
+abstract: A dense, content-rich paragraph (usually 2–4 sentences) that captures the central provocation or thesis. Useful for future indexing, search, and reference tools.
+---
+```
+
+**Current standardized topics** (kept small and consistent):
+- `philosophy` (core across nearly all pieces)
+- `craft`
+- `epistemology`
+- `exploratory-testing`
+- `agile`
+
+- Use `date` for when the piece was primarily written.
+- `topics` should be few, meaningful, and drawn from the list above.
+- `related` makes the cumulative, cross-referential nature of the blog explicit (most articles now link to 3–5 others).
+- `abstract` acts as the intellectual charter for the piece.
+- Keep front-matter minimal, honest, and consistent. No ceremonial or redundant fields (e.g. we removed `status` because folder structure already signals it).
+
 - `articles/published/` — completed, polished articles (reference these for style and cross-links).
 - `articles/drafts/` — work-in-progress (expand these preferentially).
 - `assets/clipart/`, `assets/general/`, `assets/memes/` — use or generate supporting visuals (Grok can create new ones via image tools when relevant).
-- All in Markdown. Inline images, hyperlinks, and British English.
+- All in Markdown. British English. Inline images and hyperlinks.
 
 Grok's role here is to act as an intellectually rigorous thinking partner — accelerating exploration of ideas, sharpening arguments, and providing inspiration while preserving the unique character of this body of work. Use tools creatively (research, image generation for assets, code for examples) to deepen articles without replacing the human craft.
 

articles/drafts/agile-stories.md

@@ -1,3 +1,12 @@
+---
+title: Agile Stories
+date: 2025-04-07
+topics: [agile, requirements, storytelling]
+related:
+  - agile-or-whatever-you-call-it
+abstract: An exploration of user stories through the lens of actors, objects, and purposes, and what this reveals about the true nature of Agile practices.
+---
+
 # Agile Stories
 
 ## What Is The Story?

articles/drafts/uses-and-abuses.md

@@ -1,3 +1,13 @@
+---
+title: The Uses and Abuses of Test Automation
+date: 2025-04-07
+topics: [automation, philosophy, craft]
+related:
+  - what-makes-us-better
+  - the-logic-of-software-testing
+abstract: An Aristotelian examination of whether test automation expands the craft of testing or quietly transforms it into a different kind of craft altogether.
+---
+
 # The Uses and Abuses of Test Automation
 
 What Is Test Automation?

articles/published/Agile-Or-Whatever-You-Call-It.md

@@ -1,3 +1,14 @@
+---
+title: "Agile, Or Whatever You Want To Call It"
+date: 2025-05-20
+topics: [agile, philosophy]
+related: []
+abstract: >
+  A case for taking Agile seriously — not as ideology or trend, but as
+  the single best tool for organisations where uncertainty is high,
+  creativity is essential, and the product landscape is constantly changing.
+---
+
 Over the course of my career on the development side of tech, I’ve worked in a wide variety of different environments, and been a participant in many different kinds of work processes. Some great, some not so great. Some extremely rigid, some extremely fluid. Some entirely paperwork bound, others completely undocumented. But one thing they all had in common, was the wide-eyed insistence that “*We’re an Agile shop!*” The one question that always comes to mind when they tell me this, especially after seeing how they actually work, is: “*but… why?*”
 
 ## Where Is The Evidence?

articles/published/Testers-As-Explorers.md

@@ -1,3 +1,14 @@
+---
+title: “Testers As Explorers”
+date: 2025-05-12
+topics: [exploratory-testing, philosophy]
+related: []
+abstract: >
+  The tester as explorer — not an aimless wanderer, but a chartered
+  expedition leader who triangulates truth from expectations, requirements,
+  and material reality.
+---
+
 The testing function in software development has many analogues in “real life”.
 
 Testers are like home inspectors, in one sense. We’ve been tutored on a set of criteria that must be satisfied according to a standard, and taught where to take measurements to test those criteria. We are tasked with entering the home and taking the appropriate measurements, and then reporting when the measurements fail to satisfy the criteria.

articles/published/The-Various-Uses-Of-Vegetable-Condiments-In-Testing.md

@@ -1,3 +1,15 @@
+---
+title: "The Various Uses Of Vegetable Condiments In Testing"
+date: 2025-06-02
+topics: [bdd, agile, automation]
+related:
+  - Agile-Or-Whatever-You-Call-It.md
+abstract: >
+  Cucumber is a design tool for behaviour-driven development, not a
+  testing framework — and misusing it as one makes your situation worse,
+  not better.
+---
+
 In my time as a software tester and automation engineer, I’ve seen all manner of tragic misuses of engineering methodologies and their associated toolsets. Agile itself is one I mentioned in my previous post. Second on that list is easily the Cucumber (aka ‘Gherkin’) toolset.
 
 I’ve seen it used as a unit testing framework in lieu of the supplied library of the target language, as plain text documentation for a user application, as an API client for a backend application, and as a management report generator for engineering managers. As bad as all those things might sound, the worst misuse of the tool, I think, is it’s employment as a plain-english procedural DSL for end-to-end tests. Nothing raises my hackles more, than to see long strings of “and then when” chained together in a meandering play-by-play narrative of a tester’s stream of consciousness. That’s not what Cucumber is *for*.

articles/published/five-essential-lessons.md

@@ -1,3 +1,16 @@
+---
+title: "Five Essential Lessons For Software Testers"
+date: 2025-09-22
+topics: [epistemology, philosophy, craft]
+related:
+  - Testers-As-Explorers.md
+abstract: >
+  Five distilled lessons from Kaner, Bach, and Pettichord's "Lessons
+  Learned In Software Testing" — on the distinction between testing and
+  QA, empiricism, evaluation, automation, and the tester's relationship
+  with the development team.
+---
+
 Relative to software programming, design, marketing and management, there are comparatively far fewer good books written on the topic of testing and test engineering. In most instances, it is treated as a hygiene component of software development in a few chapters on test construction, or it is described as part of a process management philosophy like Domain Driven Design, or Test Driven Development. However, in spite of what these books would suggest, software testing is in fact, a technical discipline of its own, distinct from all the other roles mentioned here, including software development, and there have been a few well-written books on the topic.
 
 One of the best books an aspiring software tester can read to improve his practice, is the Kaner, Bach, and Pettichord book “[Lessons Learned In Software Testing](https://www.amazon.co.uk/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124 "https://www.amazon.co.uk/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124")”. This book is a comprehensive bible of 293 battle-tested insights into software testing, accumulated over decades, and drawn from direct experiences as well as academic study. It does much more than just train you to pass a certification test. It is a practical guide to testing as a distinct practice in a way that no certification process could ever hope to be.

articles/published/perfection-and-testing.md

@@ -1,3 +1,14 @@
+---
+title: "Perfection And Testing"
+date: 2025-11-18
+topics: [philosophy, craft]
+related: []
+abstract: >
+  Testing is not an apology for imperfection. It is a tool for managing
+  confidence, risk, and the gap between expectations and reality — and
+  knowing when and how much to use it is a judgment call, not a moral one.
+---
+
 > ...*this book is not for people who think that they can write a perfect program and be perfectly sure that it is perfect... you must also believe that human thinking can be perfect…. Humans are not perfect thinkers... If your thinking were perfect, you would not need testing. If you believe that you must always be perfect, then you would find the existence of testing or testers rather upsetting, because it would imply that your thinking cannot be perfect. But if you say, 'Well, before I invested my life savings, I might want to do a little testing,' then you won't always be upset by the very idea of testing*... ~Gerald Weinberg, ["Perfect Software And Other Illusions"](https://www.amazon.com/Perfect-Software-Other-Illusions-Testing-ebook/dp/B004J4VVE2 "https://www.amazon.com/Perfect-Software-Other-Illusions-Testing-ebook/dp/B004J4VVE2")
 
 

articles/published/resources-for-testers.md

@@ -1,3 +1,13 @@
+---
+title: "Resources For Testers"
+date: 2025-12-15
+topics: [resources, craft]
+related: []
+abstract: >
+  Recommended books, blogs, and community resources for software testers —
+  from Bach and Hendrickson to Myers and Copeland.
+---
+
 For anyone already pursuing a career as a software tester, some of these resources will be familiar. For those new to the field, or interested in understanding what it is that a tester does, these lists may help you.
 
 ## Books

articles/published/the-categories-of-testing.md

@@ -1,3 +1,16 @@
+---
+title: "The Categories Of Testing"
+date: 2025-10-21
+topics: [epistemology, philosophy]
+related:
+  - five-essential-lessons.md
+  - Testers-As-Explorers.md
+abstract: >
+  Categorising tests not by the activities we perform, but by the kinds
+  of facts we seek — about application behaviour, human behaviour, and the
+  relationship between the two.
+---
+
 I’ve already discussed in [a previous post](https://perspectum.atlassian.net/wiki/x/GwBN0w "https://perspectum.atlassian.net/wiki/x/GwBN0w"), albeit to an incomplete degree, what a tester is. In this post, I’ll be addressing perhaps an even more important question. Namely: *what is a test?* The answer is hinted in yet [another previous post](https://perspectum.atlassian.net/wiki/x/uICZ5 "https://perspectum.atlassian.net/wiki/x/uICZ5"), where I asserted that a tester is fundamentally a “*fact finder*”. From that label, one could infer a very low-resolution definition: if a tester is a fact finder, then a test is the process by which a finder goes about finding his facts.
 
 This answer is not wrong, but it’s also not very informative. There are lots of facts to find in the world. My precise height and weight. The date of the Whiskey Rebellion. Where the data for my project is stored. The property of transparency in glass. What time you arrived at work this morning. And so on. Every one of these facts entails a different process by which they are discovered. Does that make every fact-finding effort a test? Does it make every fact an artefact of a testing activity?

articles/published/the-logic-of-software-testing.md

@@ -1,3 +1,16 @@
+---
+title: "The Logic Of Software Testing"
+date: 2025-12-12
+topics: [epistemology, reasoning, formal-logic]
+related:
+  - five-essential-lessons.md
+  - Testers-As-Explorers.md
+abstract: >
+  An inventory of the four inferential methods testers use daily —
+  modus ponens, modus tollens, induction, and abduction — and the
+  pitfalls of each.
+---
+
 Most testers aren’t consciously aware of the fact that their work requires them to engage in a fairly complex and rigorous set of inferential procedures. Most of us grow up absorbing them intuitively, to one degree or another, by way of the accidents of experience; never giving them names of their own. Aristotle would say you do not know a thing until you are capable of giving it a proper name, and you cannot name things properly until you can define their fundamental essence. Given that as our motivation, let us make a proper inventory of the ways in which a tester thinks.
 
 ## What Do You Know, and How Do You Know It?

articles/published/the-perturbation-theory-of-exploratory-testing.md

@@ -1,3 +1,15 @@
+---
+title: "The 'Perturbation Theory' Of Exploratory Testing"
+date: 2025-11-06
+topics: [exploratory-testing, philosophy]
+related:
+  - Testers-As-Explorers.md
+abstract: >
+  Borrowing from physics — tweaking a well-understood system slightly
+  and observing how changes ripple through — as a framework for
+  structured exploratory testing.
+---
+
 ## Perturb- What?
 
 Perturbation Theory is a powerful mathematical framework in physics used to find **approximate solutions** to complex problems that can't be solved exactly. You tweak a well-understood system slightly, in a controlled way, and see how those small changes ripple through. This technique is ubiquitous in quantum mechanics, but it also pops up in classical mechanics, electromagnetism, and even cosmology. The core idea: Start with a "simple" problem you *can* solve exactly, then treat the complicating factors as tiny "perturbations" and calculate their effects step by step.

articles/published/what-is-a-competent-tester.md

@@ -1,3 +1,13 @@
+---
+title: "What Is A Competent Tester?"
+date: 2025-12-04
+topics: [craft, philosophy]
+related: []
+abstract: >
+  Joel Spolsky on the critical distinction between building a team of
+  competent testers and collecting a team of failed programmers.
+---
+
 Wise words from the early days of the web explosion:
 
 

articles/published/what-makes-us-better.md

@@ -1,3 +1,14 @@
+---
+title: “What Makes Us Better Engineers?”
+date: 2026-03-06
+topics: [philosophy, craft, automation]
+related: []
+abstract: >
+  Whether LLMs like Claude change engineering in degree or in kind —
+  and why the Aristotelian distinction between techne and phronesis
+  matters for answering that question.
+---
+
 Recently, it has been asserted that Claude will make engineers “better”. Even if we stipulate to this assertion, what immediately comes to mind for me is, “better at what, exactly?”.
 
 ## The Carpenter Analogy