Add IP Fabric screenshot placeholders for documentation

content/documentation/ip-fabric/_index.en.md

@@ -20,7 +20,7 @@ The distinction that matters most, coming from a monitoring background, is that
 
 That distinction is exactly why it slots into the "topology as source of truth" layer of the AIOps stack described in the blog series: an agent that needs to reason about the network needs this structured state before it needs metrics.
 
-[[CAPTURE: IP Fabric dashboard overview]]
+![IP Fabric dashboard with discovery statistics, vendor mix, and compliance reports](ipfabric_dashboard.en.png#center)
 
 ## How discovery and snapshots work, at a high level
 
@@ -32,7 +32,7 @@ IP Fabric works from two core concepts: discovery and snapshots.
 
 That snapshot model is what makes several of the use cases below possible: because history isn't discarded, questions like "what changed since yesterday" have a direct answer instead of requiring you to have thought ahead and set up your own diffing.
 
-[[CAPTURE: snapshot list / discovery settings screen]]
+![Discovery settings: IP scope, seeds, and advanced options](ipfabric_snap_config.en.png#center)
 
 ## Use cases
 
@@ -42,7 +42,7 @@ This is the use case that started it all for me, and the one referenced directly
 
 For my EVPN/VXLAN lab, that means I have an always-current answer to "what's connected to what" without trusting my own memory or an out-of-date diagram. This is the layer an AI agent would need to query first, before anything else, if it's going to reason correctly about the network — which is the whole point of the "blind agent" problem from the blog series: an agent working off stale topology data is confidently wrong, not cautiously uncertain.
 
-[[CAPTURE: IP Fabric topology diagram of the lab]]
+![Topology diagram of the EVPN/VXLAN lab, generated by IP Fabric](ipfabric_network_diagram.en.png#center)
 
 ### Intent checks
 
@@ -50,7 +50,7 @@ Intent checks are rules you define once, things like "no unused VLANs," "STP roo
 
 This is where IP Fabric moves from "descriptive" (what's out there) to "normative" (is what's out there correct). It's a natural fit for the standardization principle I keep coming back to in the blog series: intent checks are a way to enforce naming and configuration consistency automatically, instead of relying on a human to notice drift.
 
-[[CAPTURE: intent check results table, colored pass/fail]]
+![Intent check rules and their results, color-coded pass/fail](ipfabric_intent.en.png#center)
 
 ### Path lookup
 
@@ -58,7 +58,7 @@ Given a source, a destination, and optionally a protocol/port, IP Fabric simulat
 
 This turns "why can't this host reach that host" from a multi-device, multi-`show`-command investigation into a single query. It also validates security posture: a path lookup will tell you if an ACL or firewall rule blocks traffic somewhere along the way.
 
-[[CAPTURE: path lookup diagram between two lab hosts]]
+![Path lookup between two lab hosts, showing the hop-by-hop forwarding path](ipfabric_path2path.en.png#center)
 
 ### Snapshot comparison
 
@@ -66,7 +66,7 @@ Because every discovery run is preserved as its own snapshot, IP Fabric can diff
 
 This is the practical answer to "what actually changed," which is normally the hardest question to answer after an incident. Instead of reconstructing a timeline from memory or from scattered change tickets, the diff is already sitting there.
 
-[[CAPTURE: snapshot diff view showing added/removed items]]
+![Diff between two snapshots, with added and removed elements highlighted](ipfabric_snapshot_diff.en.png#center)
 
 ### Programmatic access: Python SDK and MCP server
 
@@ -76,4 +76,4 @@ More relevant to the AIOps angle of the blog series: IP Fabric also ships an [MC
 
 I haven't wired this up on my lab yet; that's future work, and future sections here.
 
-[[CAPTURE: MCP server tool list or example agent query]]
+![An agent querying IP Fabric through its MCP server to compare two snapshots](claude_mcp.en.png#center)