diff --git a/docs/01-rainbow-triangle.md b/docs/01-rainbow-triangle.md
index 942c322..e5eba7e 100644
--- a/docs/01-rainbow-triangle.md
+++ b/docs/01-rainbow-triangle.md
@@ -242,7 +242,7 @@ struct State {
   (e.g., after a compositor restart or display hotplug), recovery requires
   reconfiguring the swapchain with the window's live size — and that requires
   holding a reference to the window itself.
-- **`pipeline`** — the compiled [render pipeline](concepts/GLOSSARY.md#pipeline).
+- **`pipeline`** — the compiled [render pipeline](concepts/GLOSSARY.md#pipeline-render).
   A render pipeline is an immutable configuration combining a shader, a vertex
   buffer layout, a primitive topology, and a color target setup. Switching pipelines mid-frame is expensive; most applications use a few
   pipelines and change them between draw calls.
@@ -590,7 +590,7 @@ pre-blended with barycentric weights.
 
 **`-> @location(0) vec4<f32>`** — The fragment shader must output at least one
 color value at `@location(0)`. This number must match the corresponding color
-target in the [render pipeline](concepts/GLOSSARY.md#pipeline) descriptor. The
+target in the [render pipeline](concepts/GLOSSARY.md#pipeline-render) descriptor. The
 return type is `vec4<f32>` — RGBA with linear-space components.
 
 **`return vec4<f32>(input.vertex_color, 1.0);`** — Promotes the interpolated
@@ -718,7 +718,7 @@ let vertex_buffer = device.create_buffer_init(
 ## S6: Compiling the Render Pipeline
 
 New concept: **the render pipeline is a compiled GPU configuration.** A
-[render pipeline](concepts/GLOSSARY.md#pipeline) bundles every decision the GPU
+[render pipeline](concepts/GLOSSARY.md#pipeline-render) bundles every decision the GPU
 needs to execute a draw: which shaders to run, how to interpret vertex buffer
 bytes, what [topology](concepts/GLOSSARY.md#topology) to use, whether to cull
 back faces, what blend mode to apply, and where to write the output. Pipeline
@@ -1102,13 +1102,13 @@ color_attachments: &[Some(wgpu::RenderPassColorAttachment {
 **`RenderPassColorAttachment` has exactly 4 fields:**
 
 - **`view: &texture_view`** — the framebuffer we draw into. Must match the
-  color target format in the [render pipeline](concepts/GLOSSARY.md#pipeline).
+  color target format in the [render pipeline](concepts/GLOSSARY.md#pipeline-render).
 - **`depth_slice: None`** — only used for 3D texture slices. Not applicable
   to 2D rendering.
 - **`resolve_target: None`** — only used for MSAA resolve. When multisampling
   is active, the render pass writes to a multisampled buffer and resolves into
   this target. We have no MSAA, so `None`.
-- **`ops`** — [operations](concepts/GLOSSARY.md#render-pass) controlling load
+- **`ops`** — [operations](concepts/GLOSSARY.md#operations) controlling load
   and store behavior. Two sub-fields:
   - **`load: LoadOp::Clear(color)`** — before drawing, fill the entire
     framebuffer with this color. **This IS your background color.** Dark gray.
@@ -1133,7 +1133,7 @@ that pass the depth test). Useful for visibility-based culling.
 ### Binding State and Drawing
 
 **`render_pass.set_pipeline(&self.pipeline)`** — Tells the GPU which
-[render pipeline](concepts/GLOSSARY.md#pipeline) to use for subsequent
+[render pipeline](concepts/GLOSSARY.md#pipeline-render) to use for subsequent
 draw calls. The pipeline encapsulates the shader programs, vertex format,
 primitive topology, and output configuration. Must be set before any draw call
 in a render pass. Switching pipelines mid-pass is expensive and should be
@@ -1340,7 +1340,7 @@ each piece does:
   Each layer adds a capability: driver connection, window binding, GPU selection,
   resource management, and swapchain allocation.
 
-- **The [render pipeline](concepts/GLOSSARY.md#pipeline):** Shaders,
+- **The [render pipeline](concepts/GLOSSARY.md#pipeline-render):** Shaders,
   topology, and vertex layout compiled into a GPU configuration. Created once,
   reused every frame. Expensive to create, cheap to execute.