update links under the root README file

05-filesystems-packaging/13-iofs-config-loader/README.md

@@ -0,0 +1,37 @@
+# Kata 13: The Filesystem-Agnostic Config Loader
+**Target Idioms:** `io/fs` abstraction, `fs.WalkDir`, Testability via `fstest.MapFS`, `embed` readiness  
+**Difficulty:** 🟡 Intermediate
+
+## 🧠 The "Why"
+In Go, passing `"/etc/app/config"` all over the place hard-couples your logic to the OS.
+Idiomatic Go uses `fs.FS` so you can:
+- load from disk,
+- load from embedded files,
+- load from a ZIP filesystem,
+- unit test without touching the real filesystem.
+
+## 🎯 The Scenario
+Your CLI loads configuration fragments from a directory tree, merges them, and prints a final config report.
+
+## 🛠 The Challenge
+Implement:
+- `func LoadConfigs(fsys fs.FS, root string) (map[string][]byte, error)`
+
+### 1. Functional Requirements
+- [ ] Walk `root` recursively and read all `*.conf` files.
+- [ ] Return a map of `path -> content`.
+- [ ] Reject invalid paths cleanly.
+
+### 2. The "Idiomatic" Constraints (Pass/Fail Criteria)
+- [ ] **Must** accept `fs.FS` (not `os` paths) in the core API.
+- [ ] **Must** use `fs.WalkDir` and `fs.ReadFile`.
+- [ ] **Must NOT** use `os.Open` / `filepath.Walk` inside the core loader.
+- [ ] Unit tests must use `testing/fstest.MapFS`.
+
+## 🧪 Self-Correction (Test Yourself)
+- **If you can’t test without real files:** you failed.
+- **If your loader only works on disk:** you failed the abstraction goal.
+
+## 📚 Resources
+- https://pkg.go.dev/io/fs
+- https://go.dev/src/embed/embed.go

05-filesystems-packaging/18-embedfs-dev-prod-switch/README.md

@@ -0,0 +1,54 @@
+# Kata 18: embed.FS Dev/Prod Switch Without Handler Forks
+**Target Idioms:** `embed`, `io/fs`, Build Tags, `fs.Sub`, Same Handler Code Path  
+**Difficulty:** 🟡 Intermediate
+
+## 🧠 The "Why"
+Embedding assets is great for production (single binary), but terrible for frontend iteration if every CSS tweak needs a rebuild.
+Idiomatic Go solves this with:
+- compile-time selection via build tags
+- a shared `fs.FS` abstraction so handler code doesn’t branch on “dev/prod”.
+
+## 🎯 The Scenario
+You run a small internal dashboard:
+- Prod: ship a single binary (assets embedded).
+- Dev: designers update `static/` and `templates/` live without recompiling.
+
+## 🛠 The Challenge
+Create a server that serves:
+- templates from `templates/`
+- static assets from `static/`
+
+### 1. Functional Requirements
+- [ ] `GET /` renders an HTML template.
+- [ ] `GET /static/...` serves static files.
+- [ ] Dev mode serves from disk; prod mode serves embedded.
+- [ ] Handler code is identical in both modes.
+
+### 2. The "Idiomatic" Constraints (Pass/Fail Criteria)
+- [ ] **Build tags:** two files:
+    - `assets_dev.go` with `//go:build dev`
+    - `assets_prod.go` with `//go:build !dev`
+- [ ] **Return `fs.FS`:** `func Assets() (templates fs.FS, static fs.FS, err error)`
+- [ ] **Use `fs.Sub`:** exported FS must have *clean roots* (no `static/static/...` path bugs).
+- [ ] **No runtime env checks in handlers:** mode selection must be compile-time.
+- [ ] **Single `http.FileServer` setup:** no duplicated handler logic for dev vs prod.
+
+## 🧪 Self-Correction (Test Yourself)
+1. **Live Reload**
+    - Build with `-tags dev`.
+    - Modify a CSS file and refresh.
+    - **Pass:** change shows without rebuild.
+
+2. **Binary Portability**
+    - Build without tags.
+    - Delete `static/` and `templates/` from disk.
+    - **Pass:** server still serves assets/templates.
+
+3. **Prefix Correctness**
+    - Request `/static/app.css`.
+    - **Pass:** works in both modes (no 404 due to prefix mismatch).
+
+## 📚 Resources
+- https://pkg.go.dev/embed
+- https://pkg.go.dev/io/fs
+- https://pkg.go.dev/io/fs#Sub