Fix markdown lints

Author: P1n3appl3

src/2025h2/relink-dont-rebuild.md

@@ -4,15 +4,15 @@
 | Metadata         |                        |
 | --------         | ---                    |
 | Point of contact | @yaahc                 |
-| Teams            | @compiler, @cargo      |
-| Task Owner(s)    | @yaahc, @dropbear32    |
+| Teams            | <!-- TEAMS WITH ASKS --> |
+| Task owners      | <!-- TASK OWNERS -->   |
 | Status           | Proposed               |
-| Tracking Issue   | TBD                    |
-| Zulip Channel    | TBD                    |
+| Tracking issue   | |
+| Zulip channel    | |
 
 ## Summary
 
-Work towards avoiding rebuilds of a crate's dependents for changes that don't affect the crate's 
+Work towards avoiding rebuilds of a crate's dependents for changes that don't affect the crate's
 public interface.
 
 <!--Our end goal is to have some flags available on nightly that enable avoiding unnecessary rebuilds in certain cases. -->
@@ -36,9 +36,9 @@ identical one all cause rebuilds of reverse dependencies of that crate.
 This clashes with users' intuition for what needs to be rebuilt when certain changes are made
 and makes iterating more painful.
 
-As a point of reference, in C and C++ – where there is a strict separation between interface 
-and implementation in the form of header files – equivalent changes would only cause a 
-rebuild of the translation unit whose source has been modified. For other units, existing 
+As a point of reference, in C and C++ – where there is a strict separation between interface
+and implementation in the form of header files – equivalent changes would only cause a
+rebuild of the translation unit whose source has been modified. For other units, existing
 compiler outputs would be reused (and re-linked into the final binary).
 
 Our goal is to work towards making `cargo` and `rustc` smarter about when they do or don't need to
@@ -79,13 +79,13 @@ flowchart TB
   grep
   ignore
   ripgrep
-  
+
   globset --> ignore --> ripgrep
-  
+
   globset --> grep-cli --> grep --> ripgrep
 ```
 
-Consider a change that does not alter the interface of the `globset` crate (for example, 
+Consider a change that does not alter the interface of the `globset` crate (for example,
 modifying a private item or changing a comment within `globset`'s source code).
 
 Here is the output of `cargo build --timings` for an incremental build of `ripgrep` where only
@@ -168,7 +168,7 @@ flowchart TB
 ```
 
 [^caveat_pipelining]:
-    We have taken some liberties in the above graph w.r.t. pipelining. 
+    We have taken some liberties in the above graph w.r.t. pipelining.
     Today, `cargo` preforms a single `rustc` invocation to produce the `rlib` and `rmeta`
     for each crate – `rmeta` is modeled as an "early out".
     Additionally, producing `ripgrep.rlib` and linking (the `rg (bin)` node) happens as part
@@ -300,9 +300,9 @@ in `rustc_TBD`'s interface).
 
 *This text is NORMATIVE, in the sense that teams should review this and make sure they are aligned. If not, then the shiny future should be moved to frequently asked questions with a title like "what might we do next".*-->
 
-Only changes to a crate that affect the public interface of the crate should cause downstream 
+Only changes to a crate that affect the public interface of the crate should cause downstream
 crates to rebuild.
- 
+
 <!--
 ## Design axioms
 
@@ -320,15 +320,16 @@ crates to rebuild.
 
 *This section defines the specific work items that are planned and who is expected to do them. It should also include what will be needed from Rust teams. The table below shows some common sets of asks and work, but feel free to adjust it as needed. Every row in the table should either correspond to something done by a contributor or something asked of a team. For items done by a contributor, list the contributor, or ![Heap wanted][] if you don't yet know who will do it. For things asked of teams, list ![Team][] and the name of the team. The things typically asked of teams are defined in the [Definitions](#definitions) section below.* -->
 
-| Subgoal                       | Owner(s) or team(s)     | Notes |
+| Task                       | Owner(s) or team(s)     | Notes |
 | ----------------------------- | ----------------------- | ----- |
 | Design meeting | ![Team][] [compiler] |       |
 | Discussion and moral support  | ![Team][] [compiler] ![Team][] [cargo]      |       |
 | Nightly experiment for RDR  |                         |       |
 | ↳ Author MCP                  | @osiewicz | [already accepted](https://github.com/rust-lang/compiler-team/issues/790)  |
 | ↳ Rustc Implementation        | | [WIP](https://github.com/osiewicz/rust/tree/api-fingerprinting) |
 | ↳ Cargo Implementation        | | [WIP](https://github.com/osiewicz/cargo/tree/api-fingerprinting) |
-| ↳ Standard reviews            | ![Team][] [compiler] ![Team][] [cargo]    |       |
+| Improve DefId stability       | @dropbear32 | |
+| Standard reviews              | ![Team][] [compiler] [cargo]    |       |
 
 ### Definitions
 
@@ -366,18 +367,3 @@ todo: why not devote resources towards just speeding up `rustc` incrmental?
 
 idk that we want to draw attention to this or that it's worth calling out...
 -->
-
-### 
-
-<!--
-
-### What do I do with this space?
-
-This is a good place to elaborate on your reasoning above -- for example, why did you put the
-design axioms in the order that you did? It's also a good place to put the answers to any
-questions that come up during discussion. The expectation is that this FAQ section will grow
-as the goal is discussed and eventually should contain a complete summary of the points
-raised along the way.
-
--->
-