feat(pseudo): show data-structure layout, not just control flow

Add rule 7: alongside the control flow, sketch the layout of the
data structures the code in focus reads or builds — record
fields, collection nesting, variant cases relevant to the
question — placed beside the code that touches them and reduced
in the same spirit (only the fields on the topic path). When the
data layout is the question, it leads and the flow becomes the
stub. Iron Law, worked example, frontmatter, and README updated
to match.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

README.md

@@ -36,9 +36,11 @@ One **conversational skill** stands outside the pipeline entirely:
 `pseudo` (typed `/pseudo`) switches replies into commented,
 human-readable pseudocode for explaining code — each answer opens
 with a source-file-and-line anchor, marks notable steps with
-reference markers the user can point back at, reduces the
+reference markers the user can point back at, sketches the
-irrelevant to stubs, omits low-level mechanics, and never runs
+layout of the data structures the code touches alongside the
-longer than one screen. It dispatches no agents.
+flow, reduces the irrelevant to stubs, omits low-level
+mechanics, and never runs longer than one screen. It dispatches
+no agents.
 
 Vocabulary is configurable. A **cycle** is one round in the
 pipeline graph; your project may call it a *release*, an *epic*,

pseudo/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: pseudo
-description: Use when the user wants code explained in human-readable, commented pseudocode rather than prose — invoked as `/pseudo` or when the user asks to "explain this in pseudocode". Every reply is pseudocode only; no prose paragraphs, opens with a source-file-and-approximate-line anchor, and tags notable steps with reference markers ([1], [A]) the user can point back at. Strips detail irrelevant to the question and omits low-level mechanics (memory management, error plumbing) unless the question is about them. Defaults to the project's main entry point.
+description: Use when the user wants code explained in human-readable, commented pseudocode rather than prose — invoked as `/pseudo` or when the user asks to "explain this in pseudocode". Every reply is pseudocode only; no prose paragraphs, opens with a source-file-and-approximate-line anchor, tags notable steps with reference markers ([1], [A]) the user can point back at, and sketches the layout of the data structures the code touches alongside the control flow. Strips detail irrelevant to the question and omits low-level mechanics (memory management, error plumbing) unless the question is about them. Defaults to the project's main entry point.
 ---
 
 # pseudo — explain code as commented pseudocode
@@ -26,6 +26,7 @@ EVERY ANSWER IS PSEUDOCODE. NO PROSE PARAGRAPHS.
 EVERY ANSWER OPENS WITH ITS SOURCE FILE AND APPROXIMATE LINE.
 MARK THE NOTABLE POINTS SO THE USER CAN POINT BACK AT THEM.
 SHOW ONLY WHAT THE QUESTION IS ABOUT — REDUCE THE REST TO A STUB.
+SKETCH THE DATA SHAPES THE CODE TOUCHES, NOT JUST THE CONTROL FLOW.
 OMIT LOW-LEVEL MECHANICS UNLESS THE QUESTION IS ABOUT THEM.
 NEVER LONGER THAN ONE SCREEN.
 ```
@@ -64,12 +65,22 @@ NEVER LONGER THAN ONE SCREEN.
    out — *unless* the question is precisely about them, in which
    case they become the topic and rule 5 reduces everything else.
 
-7. **Default entry point.** When the user names no starting
+7. **Show the data shapes, not just the flow.** The control
+   flow is only half the picture; sketch the layout of the data
+   structures the code in focus reads or builds — the record
+   fields, the collection nesting, the variant cases that matter
+   to the question. Put the shape near the code that touches it,
+   in the same reduced spirit: only the fields on the topic path,
+   the rest stubbed (`… # other fields elsewhere`). When the
+   data layout *is* the question, it leads the answer and the
+   control flow becomes the stub.
+
+8. **Default entry point.** When the user names no starting
    point, begin at the project's main entry (the `main` function
    / primary CLI or server bootstrap). Otherwise start where
    they point.
 
-8. **One screen, hard limit.** No answer exceeds roughly one
+9. **One screen, hard limit.** No answer exceeds roughly one
    screen page. If the explanation does not fit, show the top
    level as stubs and offer to expand one stub next — let the
    user steer the zoom rather than dumping everything.
@@ -78,22 +89,28 @@ NEVER LONGER THAN ONE SCREEN.
 
 ```
 # src/server.rs ~line 30 — how a request reaches a handler
+
+Router:                                   # [1] the structure match() reads
+    routes: list of { path_pattern, handler }
+    …  # fallback handler, middleware chain elsewhere
+
 main():
     config = load_config()                # details elsewhere
-    router = build_routes()               # [1]
+    router = build_routes()               # fills Router.routes
     serve(router):
         for each incoming request:
-            handler = router.match(request.path)   # [2]
+            handler = router.match(request.path)   # [2] scans routes
             response = handler(request)            # [3]
             send(response)
 ```
 
 That is a whole answer. It opens with the file-and-line anchor,
-starts at the entry point, keeps the request path in focus,
+sketches the `Router` shape `[1]` right beside the code that
-stubs the config load, omits the socket and memory mechanics,
+reads it (only the field on the topic path; the rest stubbed),
-marks the three discussable steps `[1]`–`[3]`, and fits one
+keeps the request path in focus, stubs the config load, omits
-screen. The user can now say "expand [2]" and the next answer
+the socket and memory mechanics, marks the discussable steps,
-zooms into route matching — with its own anchor line.
+and fits one screen. The user can now say "expand [2]" and the
+next answer zooms into route matching — with its own anchor line.
 
 ## When to stop