Zephyr ai article - Fixing link in Rust AI Article

content/blog/2026/04/developing-a-rust-iot-app-with-ai/index.md

@@ -1,6 +1,7 @@
 ---
 title: "Developing a Rust-based IoT device with AI"
 date: 2026-04-20
+lastmod: 2026-06-10
 tags:
   - how-to
   - Rust
@@ -57,7 +58,7 @@ I'm going to use the M5Stack ESP DualKey development kit. It provides enough rea
 
 A written **product specification** is the main contract among all the interested parties: the human developer, the firmware, and the assistant. Behaviors, timeouts, SSID and BLE names, LED meanings, reboot rules, gesture timing—everything relevant—should be there. When the specification and the code disagree, you decide whether to fix the code or update the specification—never leave both drifting.
 
-In this task, we collaborated to reach [this specification](https://github.com/rftafas/rust-dualkey-ble-provisioning/blob/main/references/spec/product_spec.md). The assistant can be pointed at it explicitly so refactors stay consistent with intended UX.
+In this task, we collaborated to reach [this specification](https://github.com/rftafas/dualkey-provisioning/blob/main/docs/spec/product_spec.md). The assistant can be pointed at it explicitly so refactors stay consistent with intended UX.
 
 ### 2.2 Prior working code, independent of language, is a great specification
 
@@ -168,7 +169,7 @@ Now, briefly, this whole idea was to prove to myself that Rust is viable to be u
 </div>
 
 
-The goal of this section is orientation only; authoritative detail stays in the [root README](https://github.com/rftafas/rust-dualkey-ble-provisioning) and [references/spec/product_spec.md](https://github.com/rftafas/rust-dualkey-ble-provisioning/blob/main/references/spec/product_spec.md).
+The goal of this section is orientation only; authoritative detail stays in the [dualkey-provisioning README](https://github.com/rftafas/dualkey-provisioning) and [docs/spec/product_spec.md](https://github.com/rftafas/dualkey-provisioning/blob/main/docs/spec/product_spec.md).
 
 ---
 
@@ -178,7 +179,7 @@ Along the way we accumulated **documentation the assistant could read** and **re
 
 - **`references/spec/`** — Product behavior, provisioning notes, environment setup (`env_setup.md`), and related design markdown.
 - **Root `README.md`** — Operator-facing gestures, LEDs, links, and build hints.
-- **[`rust-espressif-ai-starter-prompt.md`](https://github.com/rftafas/rust-dualkey-ble-provisioning/blob/main/rust-espressif-ai-starter-prompt.md)** — High-level project expectations and layout for AI-assisted work.
+- **[`docs/rust/rust-espressif-ai-starter-prompt.md`](https://github.com/rftafas/dualkey-provisioning/blob/main/docs/rust/rust-espressif-ai-starter-prompt.md)** — High-level project expectations and layout for AI-assisted work.
 
 **Session notes:** During long debug threads, the coding agent often produced structured troubleshooting notes—hypotheses tried, log snippets, “next steps”—much like a human engineer’s lab notebook. That was a surprise: even an AI benefits from a notebook instead of relying on context (i.e. memory) length alone.