⚙️ [Maintenance]: Fix Docs Lint pipeline (MD060 tables + codespell false positives) (#52)

The Docs pipeline's `Lint` job (super-linter) is green again. It had
been failing on `main` since the Continuous-X / DevOps guides were
added, and every pull request inherited the failure because super-linter
validates the entire codebase.

## Fixed: Docs Lint pipeline passes again

Two independent problems in the guide files added by 99d9d5a were
blocking the job:

- **MD060 / table-column-style (36 errors)** in
`continuous-x-and-continuous-ai.md` and `devops-reference.md`. The
tables mixed padded header/body cells (`| # |`) with compact delimiter
rows (`|---|`). Fixed by padding the delimiter rows so each table uses
one consistent style — the rendered tables are unchanged.
- **codespell false positives** surfaced once MD060 was resolved. Both
are legitimate text, not typos, so they are added to the codespell
`ignore-words-list` rather than "corrected":
- `Skelton` — the surname of **Matthew Skelton**, co-author of *Team
Topologies*.
- `erformance` — an artifact of the SPACE-framework acronym
`**P**erformance` (**S**atisfaction, **P**erformance, **A**ctivity,
**C**ommunication, **E**fficiency).

## Technical Details

- `src/docs/Ways-of-Working/continuous-x-and-continuous-ai.md`,
`src/docs/Ways-of-Working/devops-reference.md`: delimiter rows padded
(rows 10, 23, 76, 85 and 12, 60). Verified with markdownlint-cli2
(markdownlint v0.41.0) against `.github/linters/.markdown-lint.yml` — 0
errors.
- `.github/linters/.codespellrc`: `ignore-words-list` extended with
`skelton,erformance` (alongside the existing `afterall`). Verified with
codespell — 0 errors.
- Full super-linter run is green (MARKDOWN, SPELL_CODESPELL, and all
other linters) and Build passes.

This follows Option A from the issue (reformat the tables), plus the
codespell false-positive handling needed to actually turn the `Lint` job
green.

<details>
<summary>Related issues</summary>

- Fixes #51

</details>

Author: MariusStorhaug

.github/linters/.codespellrc

@@ -1,3 +1,3 @@
 [codespell]
 skip = ./.github/linters
-ignore-words-list = afterall
+ignore-words-list = afterall,skelton,erformance

src/docs/Ways-of-Working/continuous-x-and-continuous-ai.md

@@ -7,7 +7,7 @@
 The cleanest authoritative taxonomy. From [DevOps Dojo White Belt Foundation](https://learn.microsoft.com/en-us/training/paths/devops-dojo-white-belt-foundation/):
 
 | # | Practice | What it covers |
-|---|----------|----------------|
+| --- | ---------- | ---------------- |
 | 1 | Continuous Planning | Lean product, hypothesis-driven dev, backlog management, OKRs |
 | 2 | Continuous Integration | Trunk-based dev, automated build & test on every commit |
 | 3 | Continuous Delivery | Every commit potentially releasable; automated pipeline to prod |
@@ -20,7 +20,7 @@ The cleanest authoritative taxonomy. From [DevOps Dojo White Belt Foundation](ht
 ### Full inventory with provenance
 
 | Practice | Origin / canonical source |
-|----------|--------------------------|
+| ---------- | -------------------------- |
 | **Continuous Integration** | Coined in Grady Booch's 1991 method; popularised by XP and [Martin Fowler's 2006 article](https://martinfowler.com/articles/continuousIntegration.html). |
 | **Continuous Delivery** | Jez Humble & David Farley, [*Continuous Delivery*](https://continuousdelivery.com/), 2010. |
 | **Continuous Deployment** | Every passing build deploys to prod with no human gate (vs. CD which only makes it *deployable*). |
@@ -73,7 +73,7 @@ Continuous AI tasks are: **automatable, repetitive, collaborative, integrated, a
 ### Continuous AI vs. its cousins
 
 | Term | What it is |
-|------|-----------|
+| ------ | ----------- |
 | **Continuous AI** | AI participating *in* the SDLC continuously (review, docs, triage, fault analysis). The AI is the actor. |
 | **MLOps** | CI/CD/CT *for* ML models — training, evaluation, deployment, monitoring. The model is the product. |
 | **LLMOps** | MLOps specialised for LLM apps: prompt versioning, evals, retrieval, guardrails, cost/latency monitoring. |
@@ -82,7 +82,7 @@ Continuous AI tasks are: **automatable, repetitive, collaborative, integrated, a
 ### How Continuous AI augments each Continuous X practice
 
 | Traditional practice | Continuous-AI augmentation | Example tools (2025) |
-|---------------------|---------------------------|----------------------|
+| --------------------- | --------------------------- | ---------------------- |
 | Continuous Integration | AI summarises broken builds; suggests fixes | GitHub Copilot Workspace, Sweep |
 | Continuous Delivery | Agents drive multi-step deploys; AI-authored release notes | GitHub Copilot agents, Devin |
 | Continuous Testing | Test generation, flaky-test detection, auto-repair | Diffblue, Qodo (CodiumAI), Meta TestGen-LLM |

src/docs/Ways-of-Working/devops-reference.md

@@ -9,7 +9,7 @@ A curated synthesis of authoritative sources, frameworks, and practices.
 ### The Canon (Books)
 
 | # | Title | Author(s) | Year | Why it matters |
-|---|-------|-----------|------|----------------|
+| --- | ------- | ----------- | ------ | ---------------- |
 | 1 | **The Phoenix Project** | Gene Kim, Kevin Behr, George Spafford | 2013 | The novel that introduced DevOps to mainstream. Source of the Three Ways. [itrevolution.com/product/the-phoenix-project](https://itrevolution.com/product/the-phoenix-project/) |
 | 2 | **The Unicorn Project** | Gene Kim | 2019 | Sequel from the developer's perspective; flow state, psychological safety, Five Ideals. |
 | 3 | **The DevOps Handbook** (2nd ed.) | Gene Kim, Jez Humble, Patrick Debois, John Willis | 2016/2021 | Practical companion to Phoenix Project. The reference implementation guide. |
@@ -57,7 +57,7 @@ All available at **[sre.google/books](https://sre.google/books/)**
 The evidence-based standard for DevOps performance. Source: Forsgren/Humble/Kim research, now part of Google Cloud.
 
 | Metric | What it measures | Elite performance |
-|--------|------------------|-------------------|
+| -------- | ------------------ | ------------------- |
 | **Deployment Frequency** | How often you deploy to prod | Multiple per day / on-demand |
 | **Lead Time for Changes** | Commit → production | < 1 hour |
 | **Change Failure Rate** | % of deploys causing problems | 0–15% |