Add redteam rule and paper updates

Author: vinniefalco

.cursor/commands/redteam.md

@@ -0,0 +1,46 @@
+---
+description: Red-team a WG21 paper - report the single worst vulnerability
+---
+
+Red-team `$ARGUMENTS` (or the currently open file if none specified).
+
+## Setup
+
+1. Read the target paper in full.
+2. Read `CLAUDE.md` in the repo root for style and tone rules.
+3. If the paper references source code via GitHub links, read the linked files to verify claims.
+4. If the paper quotes another WG21 paper by section number, verify the quote and section number are accurate when the source is accessible.
+
+## Severity Taxonomy
+
+- **CRITICAL** - Factually wrong. A spec reference that does not exist. A quote that is not exact. A code snippet that does not match the linked repo source. A causal logic break where step N does not follow from step N-1. A broken link. A citation number in the body that does not match the corresponding References entry. A cross-reference to a companion paper that states something the companion does not actually say.
+- **STRUCTURAL** - A competent hostile reader could use this to invalidate an entire section or the paper's core claim. An unstated assumption the argument depends on. An unaddressed counterargument that threatens the main thesis. A logical gap in the causal chain. An internal contradiction between two sections of the same paper.
+- **TONAL** - A sentence hotter than the paper's own disclosure promises. An implied accusation of bad faith. Words like "clearly" or "obviously" doing argumentative work the evidence has not earned. The attack instinct leaking through measured prose. A violation of CLAUDE.md tone rules 39 or 40.
+- **COSMETIC** - Awkward phrasing, slightly clunky transition, word choice that is fine but not perfect, minor style nit. **Below threshold. Never report cosmetic findings.**
+
+## Procedure
+
+1. Analyze the paper against all four severity levels.
+2. Report **ONLY the single highest-severity finding**. Format:
+
+```
+**[SEVERITY]** Section X.Y / paragraph N / "quoted text..."
+
+Problem: <one sentence>
+Fix: <one sentence>
+```
+
+3. If multiple findings share the highest severity, report the one that is most damaging to the paper's credibility.
+4. If no CRITICAL, STRUCTURAL, or TONAL issues remain:
+
+```
+**CLEAR** - paper is below threshold. Ship it.
+```
+
+## Rules
+
+- One finding per invocation. No lists. No "also consider." Just the single worst thing.
+- Do not suggest rewrites beyond the one-sentence fix direction.
+- Do not report cosmetic issues. Ever. They are below threshold.
+- Do not praise the paper. Do not summarize the paper. Just the finding or CLEAR.
+- Verify factual claims against linked sources when feasible rather than assuming correctness.

source/d4050-task-diversity.md

@@ -382,7 +382,7 @@ This paper does not argue that the composition algebra is useless for networking
 
 ---
 
-## 10. Qt Sender vs. Coroutine
+## 10. Qt Sender and Coroutine Side by Side
 
 Ville Voutilainen's [libunifex-with-qt](https://git.qt.io/vivoutil/libunifex-with-qt)<sup>[16]</sup> contains a chunked HTTP downloader written as both a sender pipeline and a coroutine.
 
@@ -474,7 +474,7 @@ capy::task<> timeout_a_worker()
 }
 ```
 
-Both models provide structured concurrency. In the sender model, the operation state protocol guarantees that child operation states are destroyed before the parent's receiver is called. In the coroutine model, `capy::when_all` and `capy::when_any` guarantee the same property through coroutine frame lifetimes: child coroutines complete and their frames are destroyed before the parent coroutine resumes. Stop tokens propagate through `io_env` at `await_suspend` time. The mechanism differs - operation state protocol vs. coroutine frame scoping - but the structured concurrency guarantees are equivalent: no child outlives its parent, cancellation propagates downward, and results are available only after all children complete. The sender `when_all` additionally provides compile-time work-graph visibility, static type checking of completion signatures, and heterogeneous child composition (GPU + network + timer in one expression) that the coroutine `when_all` does not.
+Both models provide structured concurrency. In the sender model, the operation state protocol - formalized by `async_scope` ([P3149R9](https://wg21.link/p3149r9)<sup>[6]</sup>) - guarantees that child operation states are destroyed before the parent's receiver is called. In the coroutine model, `capy::when_all` and `capy::when_any` guarantee the same property through coroutine frame lifetimes: child coroutines complete and their frames are destroyed before the parent coroutine resumes. Stop tokens propagate through `io_env` at `await_suspend` time. The mechanism differs - operation state protocol vs. coroutine frame scoping - but the structured concurrency guarantees are equivalent: no child outlives its parent, cancellation propagates downward, and results are available only after all children complete. The sender `when_all` additionally provides compile-time work-graph visibility, static type checking of completion signatures, and heterogeneous child composition (GPU + network + timer in one expression) that the coroutine `when_all` does not.
 
 They differ in where the compound result is visible when the composition decision is made (Q8, Q10). The trade-off table (Section 9) applies at every I/O boundary inside a structured concurrency scope.
 
@@ -627,4 +627,4 @@ Any person quoted in this paper who believes their words have been presented out
 
 19. [D3980R0](https://wg21.link/d3980r0) - "Task's Allocator Use" (Dietmar K&uuml;hl, 2026). https://wg21.link/d3980r0
 
-20. LEWG reflector (lib-ext), March 2026. Threads: "Complicated success at coroutine/sender composition boundaries" (http://lists.isocpp.org/lib-ext/2026/03/31375.php) and "std::execution - dynamically selecting a channel" (http://lists.isocpp.org/lib-ext/2026/03/31377.php).
+20. LEWG reflector (lib-ext), March 2026. Threads: "Complicated success at coroutine/sender composition boundaries" (http://lists.isocpp.org/lib-ext/2026/03/31375.php) and "std::execution - dynamically selecting a channel" (http://lists.isocpp.org/lib-ext/2026/03/31377.php). Compilable examples: Petersen's four sender implementations (https://godbolt.org/z/7W51hYE7c) and Voutilainen's channel ping-pong (https://godbolt.org/z/h5cv5fbTE).