pi-outpost 0.32.4 → 0.34.0

package/dist/pi-outpost.sea.mjs

@@ -1,4 +1,4 @@
 [diffend] Oversized file quarantined before diffing.
 name: package/dist/pi-outpost.sea.mjs
-size: 35801861 bytes
-sha256: 3193b173a90f68e016149099ea42bda6d938198dd63814d3a6fe9931cddd5d30
+size: 38386180 bytes
+sha256: 5dd3975707387d78afef8c9d81c9ae669fd9c80ce088d0c4a8255dac3144f473

package/dist/sea-prep.blob

@@ -1,4 +1,4 @@
 [diffend] Oversized file quarantined before diffing.
 name: package/dist/sea-prep.blob
-size: 35800919 bytes
-sha256: b5f5679e4b5698a1a32c0232b05b32e4b555f249324727514e329f7265b0d76c
+size: 38385218 bytes
+sha256: ee8f6c6d18b4c2713ab8648883b4ef96b45053bcf34a065c7e8ad4d2ea624257

package/dist/skills/structured-exchange/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: structured-exchange
-description: Author a structured-exchange document — a graph, sequence, or table the interface renders natively, such as a table of requirements with their attributes, or a proposal to change one an external authority holds — and write figures of one into a document you are authoring. Read it before calling present_structure or write_structure_figure. Use when asked to draw or diagram a structure, to present requirements or other typed items, to propose an evolution of an existing model, to illustrate a report you are writing, when a project's profile refuses a kind, attribute or value, or when a result would otherwise be a hand-written diagram.
+description: Author a structured-exchange document — a graph, sequence, table or planning timeline the interface renders natively, such as a table of requirements with their attributes, a programme schedule with milestones and dependencies, or a proposal to change one an external authority holds — and write figures of one into a document you are authoring. Read it before calling present_structure or write_structure_figure. Use when asked to draw or diagram a structure, to present requirements or other typed items, to plan or show a schedule, roadmap or Gantt chart, to propose an evolution of an existing model, to illustrate a report you are writing, when a project's profile refuses a kind, attribute or value, or when a result would otherwise be a hand-written diagram.
 allowed-tools: Bash(node:*)
 license: MIT
 metadata:
@@ -13,22 +13,21 @@ Emit **data**, not a diagram. The interface renders the diagram from your data;
 diagram you draw by hand is syntax it has to guess at, and cannot be approved,
 validated, or applied.
 
-> **The one rule that trips everyone up.** When you propose a change to something
-> that already exists, the fields you write beside its `ref` say *what it is called
-> now*. They are not applied. The new value goes in `set`.
->
-> ```json
-> { "id": "ledger", "ref": "EL-7", "label": "Ledger",
->   "set": { "label": "General Ledger" } }
-> ```
->
-> Writing `"label": "General Ledger"` on its own does **not** rename anything — it
-> claims that is already its name, and the proposal silently does nothing. If the
-> tool answers `0 changed`, this is what happened.
+This page is what every document needs. The rest is in a `references` folder next to this
+file — the path you read this page at, with `SKILL.md` replaced by `references/<name>.md`.
+**Read the one for the job before writing the document**, and only that one.
+
+| To… | Read |
+| --- | --- |
+| plan or show a schedule, roadmap or Gantt chart, compare two versions of a plan | `references/timelines.md` |
+| propose a change to something that already exists (`target`, `ref`, `set`, `removals`) | `references/proposals.md` |
+| group elements, colour a table's rows by what a change did, declare viewpoints | `references/graphs-and-tables.md` |
+| carry attributes, expectations, locations, artifact links, or a requirements table with headings and traceability (version 2) | `references/enriched-contract.md` |
+| put a diagram or a table into a document you are writing | `references/figures.md` |
 
-Everything you need is on this page. The normative contract sits beside it, as
-`structured-exchange-1.json` in this same directory — read it when a detail here is
-not enough, and do not go hunting elsewhere in the workspace for it.
+The normative contracts sit in this directory too — `structured-exchange-1.json`,
+`-2.json`, `-3.json` — read one when a detail is not enough, and do not go hunting
+elsewhere in the workspace for it.
 
 ## The tool validates for you
 
@@ -49,11 +48,10 @@ refused, never corrected — correcting it would produce a document you did not
 }
 ```
 
-`kind` is `graph`, `sequence`, or `table`. Under version 1 a table is a projection: it
-can be shown and reasoned about, never proposed — though its rows may report what a
-change did to them (see **Roles on a table's rows**). Under version 2 its rows can carry
-an identity, so a table can be proposed like anything else (see **The enriched
-contract**).
+`kind` is `graph`, `sequence`, or `table` — and, under version 3, `timeline`. Under
+version 1 a table is a projection: it can be shown and reasoned about, never proposed.
+Under version 2 its rows can carry an identity, so a table can be proposed like
+anything else (`references/enriched-contract.md`).
 
 Each carries its own `data`:
 
@@ -74,116 +72,66 @@ Each carries its own `data`:
 A message declares a `label` and no `kind` — the label *is* what is being sent.
 Message order is the order you write them in; nothing sorts them for you.
 
-## Roles on a table's rows
-
-A table cannot be proposed, but it can *report* on a change it projects. Any row
-may say what it plays, and the interface colours it the way it colours an added or
-changed element in a graph:
-
-```jsonc
-"data": {
-  "columns": ["id", "requirement", "status"],
-  "rows": [
-    { "role": "added",   "cells": ["REQ-5", "Log every actuation.", "draft"] },
-    { "role": "changed", "cells": ["REQ-2", "Signal a fault within 200 ms.", "in review"] },
-    { "role": "removed", "cells": ["REQ-3", "Read battery voltage at 10 Hz.", "withdrawn"] },
-    { "cells": ["REQ-1", "Stop the vehicle within 40 m.", "approved"] }   // context
-  ]
-}
-```
-
-`role` is one of `added`, `changed`, `context`, `removed`. A row that declares none
-reads as context when any other row declares one. Both row forms are accepted, so
-`["REQ-1", "…"]` and `{ "cells": ["REQ-1", "…"] }` are the same row, and a table
-that declares no role anywhere is rendered exactly as before roles existed.
-
-Declare the role — do not put it in a column and expect the colours. A `status`
-column is your data and is rendered as data; nothing infers a role from it.
-
-## Grouping: containers
-
-A graph or a sequence may declare **containers** — subsystems, layers, teams,
-whatever the domain groups things into — and each element or participant may say
-which one it belongs to.
+A timeline is version 3 and a whole envelope of its own. Start from this one — it holds
+what most plans need:
 
-```jsonc
-"data": {
-  "containers": [{ "id": "electrical", "label": "Electrical system" }],
-  "nodes": [{ "id": "battery", "label": "Battery", "container": "electrical" },
-            { "id": "driver",  "label": "Driver" }],          // in no container
-  "edges": [{ "from": "driver", "to": "battery", "kind": "operates" }]
+```json
+{
+  "schema": "urn:structured-exchange:3",
+  "kind": "timeline",
+  "data": {
+    "title": "Bench test campaign",
+    "time": { "start": "2027-03-01", "end": "2027-05-31", "scale": "week" },
+    "rows": [
+      { "type": "separator", "label": "Bench" },
+      { "type": "task", "id": "T1", "label": "Bench setup", "items": [
+        { "type": "activity", "id": "setup", "start": "2027-03-01", "end": "2027-03-19", "label": "Install and calibrate" }
+      ] },
+      { "type": "task", "id": "T2", "label": "Test runs", "items": [
+        { "type": "milestone", "id": "trr", "date": "2027-03-22", "kind": "TRR", "label": "Test Readiness Review" },
+        { "type": "activity", "id": "runs", "start": "2027-03-23", "end": "2027-05-14", "label": "Campaign" }
+      ] }
+    ],
+    "dependencies": [{ "from": "setup", "to": "trr" }, { "from": "trr", "to": "runs" }],
+    "periods": [{ "start": "2027-03-29", "end": "2027-04-02", "label": "Easter closure", "kind": "closure" }],
+    "references": [{ "date": "2027-05-28", "label": "Contractual delivery" }]
+  }
 }
 ```
 
-Four things to know:
-
-- **Membership goes on the member**, never as a list of members on the container.
-  An element belongs to one container or to none.
-- **Relationships ignore grouping entirely.** They connect elements, they cross
-  container boundaries freely, and an endpoint is never a container id. Naming a
-  container as `from` or `to` is refused.
-- **Containers do not nest.** A member names a container, never a chain of them.
-- **A container nobody joins is fine.** Declare the group first and fill it later
-  if that is what you mean; it is drawn as an empty box.
-
-Naming a container the document does not declare is refused rather than quietly
-ungrouped — an element shown outside a group it belongs to would misstate the
-system you are describing.
+- `scale` is `week` for a few months, `month` for a year or two, `quarter` beyond.
+- A closure or a holiday is a **period**, never an activity: it belongs to no task.
+- Every item falls inside `time`; a milestone is one `date`; give an item an `id` if
+  anything depends on it.
 
-In a sequence, the view puts a container's columns next to each other so its
-header spans them. If you interleave two containers, the columns are reordered:
-the first member of a container met brings the rest of that container with it,
-and anything belonging to no container keeps its place. Declare participants in
-the order you want them read.
+Read `references/timelines.md` for the rest: dependency types, comparing two versions of
+a plan, and putting a timeline in a report.
 
-## Viewpoints: the readings a graph is made for
-
-When a graph will be read in more than one way — power, then control, then what is
-safety-relevant — declare those readings as `viewpoints` on the envelope, rather than
-leaving the reader to rebuild each one from the key:
+A table of requirements with headings, typed rows and traceability is version 2 — start from
+this one, and read `references/enriched-contract.md` for attributes, expectations and links:
 
 ```json
 {
   "schema": "urn:structured-exchange:2",
-  "kind": "graph",
-  "viewpoints": [
-    {
-      "id": "power",
-      "label": "Power distribution",
-      "concern": "Where energy is stored, converted and consumed",
-      "elementKinds": ["source", "load"],
-      "relationshipKinds": ["power"]
-    }
-  ],
+  "kind": "table",
   "data": {
-    "nodes": [
-      { "id": "battery", "label": "Battery", "kind": "source" },
-      { "id": "motor", "label": "Motor", "kind": "load" },
-      { "id": "ecu", "label": "ECU", "kind": "controller" }
+    "columns": ["id", "requirement", "status"],
+    "rows": [
+      { "heading": "1. Braking", "depth": 1 },
+      { "id": "r1", "ref": "REQ-1", "kind": "requirement",
+        "cells": ["REQ-1", "Stop within 40 m", "approved"],
+        "attributes": { "verification": "test" } },
+      { "id": "r2", "ref": "REQ-2", "kind": "requirement",
+        "cells": ["REQ-2", "Read wheel speed at 100 Hz", "approved"] }
     ],
-    "edges": [
-      { "from": "battery", "to": "motor", "kind": "power" },
-      { "from": "ecu", "to": "motor", "kind": "signal" }
+    "relations": [
+      { "from": { "id": "r1" }, "to": { "id": "r2" }, "kind": "derives" },
+      { "from": { "id": "r1" }, "to": { "ref": "TEST-9" }, "kind": "verifiedBy" }
     ]
   }
 }
 ```
 
-- **A viewpoint says what it retains.** Name the element kinds, the relationship kinds,
-  or both — at least one list. A list you leave out keeps that whole vocabulary.
-- **Only kinds the document has.** Every kind you retain must be the kind of some
-  element (or, for `relationshipKinds`, some relationship) in this document. A typo is
-  refused, not corrected, and the refusal says when the word exists in the other list.
-- **Always give the concern.** It is printed inside every figure drawn for the
-  viewpoint — write it as the question that reading answers.
-- **Graphs only**, and at most twenty per document.
-- **Something with no kind survives every viewpoint.** If an element must drop out of a
-  reading, give it a kind.
-
-When you write a report with one chapter per reading, write one figure per viewpoint:
-`write_structure_figure` with `viewpoint: "power"`. Do not rebuild the same selection
-from hide lists — the viewpoint carries both the selection and the reason for it.
-
 ## Two identities, never confused
 
 Every element carries an `id`, and may carry a `ref`.
@@ -242,23 +190,23 @@ A physical architecture might use `battery`, `converter`, `motor`, `controller`,
 model whatever its profile defines. Relationships likewise: `power`, `thermal`,
 `communication` on a physical model, `calls`, `writes`, `publishes` on a software one.
 
-## Proposing a change to something that exists
-
-Name the artifact in `target`. Then:
+## Changing something that exists
 
-- An element you do not mention is left alone. Omission never removes anything.
-- **On anything carrying a `ref`, the fields you declare describe what is already
-  there.** They are how the reader recognises it. They change nothing.
-- **To change something, say so in `set`.** That is the only thing that is applied.
-- To remove something, say so in `removals`, giving both the `ref` and whether it is
-  an `"element"` or a `"relationship"` — a reference alone does not say which.
+> **The one rule that trips everyone up.** When you propose a change to something
+> that already exists, the fields you write beside its `ref` say *what it is called
+> now*. They are not applied. The new value goes in `set`.
+>
+> ```json
+> { "id": "ledger", "ref": "EL-7", "label": "Ledger",
+>   "set": { "label": "General Ledger" } }
+> ```
+>
+> Writing `"label": "General Ledger"` on its own does **not** rename anything — it
+> claims that is already its name, and the proposal silently does nothing. If the
+> tool answers `0 changed`, this is what happened.
 
-> **Say what you are removing.** A removal may also carry `label`, `kind`, and for a
-> relationship `from` and `to`. Add them. The reader's application holds your document
-> and nothing else — it cannot look up what `REL-88` stood for, so without them the
-> approval gate reads "relationship: REL-88" and asks someone to approve deleting
-> something they cannot see. These fields describe and never identify: `ref` is still
-> what names the thing.
+A whole proposal — one element kept as context, one renamed, one added, one relationship
+removed and said what it was:
 
 ```json
 {
@@ -281,142 +229,10 @@ Name the artifact in `target`. Then:
 }
 ```
 
-Read that proposal:
-
-- **The removal** names `REL-88` and says what it is: the `calls` from Ledger to
-  Billing. The reader sees what goes, rather than an identifier.
-
-- **`billing`** has a `ref` and a name, no `set` → **context**. It exists, it is shown
-  so you can see where the new thing attaches, and nothing happens to it.
-- **`ledger`** has a `ref`, its current name, and a `set` → **a change**. The reader
-  sees `Ledger → General Ledger`, which is what makes it approvable.
-- **`audit`** has no `ref` → **new**. With nothing to describe, its `label` is simply
-  its value.
-
-**Include as much context as the reader needs.** That is what the default is for: an
-element you include to make the picture legible costs nothing and changes nothing.
-Leaving it out to be safe is the wrong instinct — a proposal nobody can situate is a
-proposal nobody should approve.
-
-### Two rules that catch people out
-
-**Never put a `set` on something with no `ref`.** There is nothing to change; its
-fields are already its values. Refused.
-
-**Never both `set` and remove the same `ref`.** That states two intentions at once and
-is refused rather than resolved — decide which you meant.
-
-**A relationship always declares `from` and `to`**, even when it carries a `ref`. Its
-endpoints are its identity, not something you patch. To re-attach a relationship,
-remove it and declare a new one.
-
-**Moving something between containers is an ordinary change**: `"set": { "container":
-"electrical" }` on an element that carries a `ref`, like any other field you change.
-Containers themselves are not patched — they are declared afresh in every document.
-
-## What the reader sees, and what the model sees
-
-The structured document is rendered for the human and **does not reach the model** —
-not even yours, on a later turn. So the result's ordinary text must stand on its own:
-summarise what the structure says, well enough that the next question can be answered
-without it. A document with a rich diagram and a one-line text is a document you
-cannot reason about afterwards.
-
-You also do not choose how a graph is arranged. It is laid out across the page while it
-fits the reading column and down the page when it does not, and the reader can turn it
-either way. Do not describe a diagram's direction in your summary — say what it shows, not
-which way it runs.
-
-## Putting a diagram in a document you are writing
-
-`present_structure` shows a document in the conversation. When you are *writing* a
-file — a report, a design note, a README — a diagram belongs in that file instead,
-and `write_structure_figure` puts it there:
-
-```
-write_structure_figure(
-  path: "models/vehicle.json",
-  output_path: "figures/power-train.svg",
-  hide_relationship_kinds: ["diagnostic"]
-)
-```
+An element you do not mention is left alone; never put a `set` on something with no
+`ref`. Read `references/proposals.md` for the rest of the rules that refuse a proposal.
 
-It reads a structured-exchange document from the workspace, draws it, and writes one
-`.svg`. Reference it from your Markdown as a relative path — `![Power
-train](figures/power-train.svg)` — and the interface renders it in the preview.
-
-Three things about it are worth knowing before you use it.
-
-**The two hide lists are different vocabularies.** `hide_element_kinds` hides boxes by
-their `kind`; `hide_relationship_kinds` hides arrows by theirs. The same name in both
-means two unrelated things, and naming one where you meant the other hides nothing,
-draws a perfectly valid figure of the whole document, and looks like it worked.
-
-**Write one figure per view worth having.** A narrowed figure is the reason the tool
-takes a narrowing at all: three figures each about one thing beat one figure of
-everything, which is the diagram nobody reads. A figure that shows less than its
-document says so, inside the picture, so a figure separated from its source is never
-mistaken for the whole of it.
-
-**A relationship whose endpoint you hid goes with it.** An arrow to a box that is not
-drawn cannot be drawn. The result tells you how much of the document the figure shows,
-so a narrowing that took more than you meant is visible in the answer rather than in
-the file.
-
-A table has no figure — it is data. To put one in a document you are writing,
-`write_structure_table` writes it as Markdown:
-
-```
-write_structure_table(
-  path: "requirements/braking.json",
-  output_path: "reports/braking-requirements.md"
-)
-```
-
-It reads a table from the workspace and writes a new `.md` file — each chapter a heading
-followed by a Markdown table of its rows — which you can include in the document or hand on.
-It never overwrites an existing file, and a table the project's profile or rules refuse is not
-written. The reader can also export a table they are shown as a spreadsheet or as Markdown.
-
-## The enriched contract: `urn:structured-exchange:2`
-
-Everything above is version 1 and still works exactly as written. Declare version 2
-instead when you need any of what follows. Nothing is removed: change the identifier and
-a version 1 document is a version 2 document, except that `target` becomes an object
-(`"target": { "ref": "architecture-v4" }`), which is what lets it name a revision.
-
-**Emit version 1 unless you need something below.** The reader cannot tell which you
-used and neither contract is better; there is simply no reason to reach for the larger
-vocabulary to say a smaller thing.
-
-### Attributes: the properties your domain owns
-
-Any element, relationship or row may carry `attributes` — bounded, typed properties
-whose names belong to your domain, not to this contract.
-
-```json
-{ "id": "battery", "label": "Battery", "kind": "source",
-  "attributes": { "voltage": 400, "chemistry": "LFP", "serviceable": true,
-                  "suppliedBy": [{ "ref": "ORG-3" }] } }
-```
-
-A value is a string, a finite number, a boolean, `null`, a reference (`{ "ref": "…" }`),
-or one flat list of those. **Lists never nest and no other object shape is allowed.** A
-quantity with a unit is two attributes or one string — `"mass_kg": 3.4`, not
-`{ "value": 3.4, "unit": "kg" }`, which is refused.
-
-Name the vocabulary those names come from with `profile` on the envelope:
-
-```json
-{ "schema": "urn:structured-exchange:2", "kind": "graph", "profile": "acme/electrical", "data": { … } }
-```
-
-The profile is **a name and nothing more**. It is never fetched, resolved or executed,
-and a reader who does not know it still sees every attribute, rendered generically. Do
-not invent one to look official; use the identifier your domain actually uses, or omit
-it.
-
-### When the project holds you to a profile
+## When the project holds you to a profile
 
 A project may register profiles — its own data model: the kinds that exist, the attributes
 each kind carries, the values each enumeration allows, the kinds each relationship joins.
@@ -460,122 +276,18 @@ A profile may declare **viewpoints** too. `write_structure_figure` accepts one b
 even when the document does not declare it, and its result says whether the viewpoint came
 from the document or from the profile.
 
-### Description, expectation, change: three different claims
-
-Version 1 already separates *describing* a referenced thing from *changing* it. Version
-2 adds a third, and confusing them is the mistake that matters:
-
-```json
-{ "id": "r1", "ref": "REQ-1",
-  "label": "Stop within 40 m",
-  "expect": { "revision": "rev-9", "attributes": { "status": "approved" } },
-  "set": { "label": "Stop within 35 m", "attributes": { "status": "in review" },
-           "removeAttributes": ["waiver"] } }
-```
-
-- **beside `ref`** — what it is called *now*. How the reader recognises it. Applied to
-  nothing.
-- **`expect`** — what you believe is currently true, for the receiving authority to check
-  before it applies anything. You are not asserting it is true; you are saying what you
-  assumed. If you did not read the current state, do not write an `expect`.
-- **`set`** — the only thing that changes anything.
-- **`removeAttributes`** — takes properties away. **`null` does not delete.** Writing
-  `"waiver": null` sets the property to null; to unset it, name it here. Naming the same
-  attribute in both `set.attributes` and `removeAttributes` is refused rather than
-  resolved, because there is no precedence worth inventing.
-
-Put the revision you prepared against on the target: `"target": { "ref": "REQ-DOC-1",
-"revision": "rev-9" }`. A revision and an `expect` are only allowed in a proposal —
-there is no authority to check them against otherwise.
-
-### Locations: where it is, never what it is
-
-```json
-"locations": [{ "uri": "file:///src/brakes.ts", "revision": "abc123",
-                "range": { "startLine": 10, "endLine": 42 } }]
-```
-
-A hint for a reader, zero-based. It takes no part in identity: `ref` says what something
-**is**, a location says where a copy of it can be found today. Never encode a path into a
-`ref` to save writing one — moving the file would then change the thing's identity.
-
-Nothing is opened until a reader asks, and only through the application's existing rules
-about what may be opened at all.
-
-### Artifacts: linked, digested, not attached
-
-```json
-"artifacts": [{ "rel": "verifies", "uri": "https://ci.example/report.json",
-                "sha256": "sha256:<64 hex characters>", "mediaType": "application/json" }]
-```
-
-The digest is mandatory, and it is the point: it binds an approval to specific bytes
-even when the URI serves different ones later. If you cannot compute a digest, you do not
-have an artifact link — use a location instead. Never inline the content; the envelope
-carries references, and a payload pasted into it is a document nobody can read and a
-ceiling you will hit.
-
-### Tables that carry a document
-
-A row may declare an identity and a type of its own, which is what makes a requirements
-table more than a grid:
-
-```json
-{ "id": "r1", "ref": "REQ-1", "kind": "requirement",
-  "cells": ["REQ-1", "Stop within 40 m", "approved"] }
-```
-
-Headings organise it, and are rows of their own — not a data row with empty cells:
-
-```json
-{ "heading": "1. Braking", "depth": 1 }
-```
-
-Traceability between rows is declared beside them, with each end stated explicitly:
-
-```json
-"relations": [
-  { "from": { "id": "r1" }, "to": { "id": "r2" }, "kind": "derives" },
-  { "from": { "id": "r1" }, "to": { "ref": "TEST-9" }, "kind": "verifiedBy" }
-]
-```
-
-`{ "id": … }` is a row of this document and must exist — a typo is refused, not quietly
-drawn pointing at nothing. `{ "ref": … }` is something outside it and is accepted as
-leaving the document, which is the normal case for the test that verifies a requirement.
-Relation kinds are opaque, like every other kind: `derives`, `verifiedBy`, `satisfies` —
-whatever your domain says.
-
-**Do not state coverage you have not been told.** A requirement with no relation is a
-requirement with no relation; the application reports what you declared and infers
-nothing about what is missing.
+## What the reader sees, and what the model sees
 
-All of it together, as one document you can copy:
+The structured document is rendered for the human and **does not reach the model** —
+not even yours, on a later turn. So the result's ordinary text must stand on its own:
+summarise what the structure says, well enough that the next question can be answered
+without it. A document with a rich diagram and a one-line text is a document you
+cannot reason about afterwards.
 
-```json
-{
-  "schema": "urn:structured-exchange:2",
-  "kind": "table",
-  "profile": "acme/requirements",
-  "data": {
-    "columns": ["id", "requirement", "status"],
-    "rows": [
-      { "heading": "1. Braking", "depth": 1 },
-      { "id": "r1", "ref": "REQ-1", "kind": "requirement",
-        "cells": ["REQ-1", "Stop within 40 m", "approved"],
-        "attributes": { "verification": "test" },
-        "locations": [{ "uri": "file:///specs/brakes.md", "range": { "startLine": 10, "endLine": 12 } }] },
-      { "heading": "1.1 Sensing", "depth": 2 },
-      { "id": "r2", "ref": "REQ-2", "kind": "requirement",
-        "cells": ["REQ-2", "Read wheel speed at 100 Hz", "approved"] }
-    ],
-    "relations": [
-      { "from": { "id": "r1" }, "to": { "id": "r2" }, "kind": "derives" },
-      { "from": { "id": "r1" }, "to": { "ref": "TEST-9" }, "kind": "verifiedBy" }
-    ]
-  }
-}
-```
+You also do not choose how a graph is arranged. It is laid out across the page while it
+fits the reading column and down the page when it does not, and the reader can turn it
+either way. Do not describe a diagram's direction in your summary — say what it shows, not
+which way it runs.
 
 ## Size