Takes conventions v1.39.0

.github/workflows/conventions.yml

@@ -5,4 +5,4 @@ on:
   pull_request:
 jobs:
   conventions:
-    uses: robertblust/conventions/.github/workflows/check.yml@v1.38.0
+    uses: robertblust/conventions/.github/workflows/check.yml@v1.39.0

AGENTS.md

@@ -1,4 +1,4 @@
-<!-- conventions · v1.38.0 -->
+<!-- conventions · v1.39.0 -->
 Shared conventions of the robertblust, guestgraph and companygraph organizations live in `conventions/`, vendored from robertblust/conventions at the release `conventions.json` names. Read them before writing or committing anything here.
 
 - `conventions/WRITING.md` — how we write: one voice, three registers, English and German.

conventions.json

@@ -1 +1 @@
-{ "repo": "robertblust/conventions", "tag": "v1.38.0" }
+{ "repo": "robertblust/conventions", "tag": "v1.39.0" }

conventions/AGENTS.md

@@ -1,4 +1,4 @@
-<!-- conventions · v1.38.0 -->
+<!-- conventions · v1.39.0 -->
 Shared conventions of the robertblust, guestgraph and companygraph organizations live in `conventions/`, vendored from robertblust/conventions at the release `conventions.json` names. Read them before writing or committing anything here.
 
 - `conventions/WRITING.md` — how we write: one voice, three registers, English and German.

conventions/GLOSSARY.md

@@ -19,14 +19,16 @@ The German cells are inline code because the prose check reads no language and a
 | talk | talk | `Vortrag` | A talk on a site; the deck is the file that carries it. |
 | reference instance | reference instance | `Referenz-Instanz` | mental-model's role in the family; the form blust.ch's ideas page chose. |
 | guest graph | guest graph | `Gast-Graph` | The short form, distinct from guest identity graph; blust.ch's ideas page. |
-| core | core | `core` | The directory in companygraph/meta-model and the release its version names; a name the ecosystem reads, so not `Kern`. |
+| core | core | `core` | The directory in companygraph/meta-model and the release its version names; a name the ecosystem reads, so not `Kern`. Masculine, `der core`, as `der Kern` would be. |
 | considered, not accepted | considered, not accepted | `Erwogen, nicht angenommen` | The design system's phrase for a candidate weighed and set aside; one form on every billing page. |
 | figure | figure | `Diagramm` | The drawn graph on a model page. The owner's choice over `Zeichnung`, which reads as a drawing by hand. |
 | experience | experience | `Erfahrung` | An entry in the model's experiences folder, whatever its kind; blust.ch's timeline and model pages. The row it makes on the timeline is an `Eintrag`. |
 | kind of experience | kind of experience | `Erfahrungsart` | The experience-kind entities — Role, Project, Community, Education, Independent — whose names stay English in both views. The owner's choice over the bare `Art` on a control, which the page's prose may still use for the short form. |
 | surface | surface | `Surface` | A page the model is published on, written by hand or built by a repository's build, and the type in `model/surfaces/`. A name the ecosystem reads, so not `Oberfläche`, which in German software prose is the user interface. Capitalized as a German noun; feminine, `die Surface`, plural `die Surfaces`. |
 | lineage | lineage | `Herkunft` | The drawing on a Surfaces page from the model's commit through each maker to its surfaces. Not `Stammbaum`, which reads as family descent, and not `Linie`, which the same page uses for the drawn line itself. companygraph.io's label is `Herkunft der Surfaces`. |
 | owner | owner | `Owner` | The one person the company of one is, and the role of that name in the model. Kept English, because the role's name on blust.ch's team page is English in both views and the word and the role are one thing. The owner's choice over `Inhaber`. Masculine, `der Owner`. |
+| owner of a nested entity | owner | `Besitzer` | The entity another is nested under, as a schema names it and as the plugin and the MCP tools' `owner` argument take it; companygraph.io's model page and Obsidian plugin talk. Not the person, who is `Owner`, so two senses keep two words. Masculine, `der Besitzer`. |
+| pane | pane | `Bereich` | A panel of the Obsidian window, as the plugin's compliance pane or the one Claudian opens; companygraph.io's CLI page and Obsidian plugin talk. The pane's own name stays English, in `«»`. Masculine, `der Bereich`. |
 | requestor | Requestor | `Requestor` | The seat that raises a feature request, and the role of that name in companygraph/mental-model. Kept English, as the model's role names are on a team page; masculine, `der Requestor`, like `der Owner`. |
 | contributor | Contributor | `Contributor` | The seat that proposes a contribution, and the role of that name in companygraph/mental-model. Kept English for the same reason; masculine, `der Contributor`. |
 | build | build | `Build` | What a repository runs to write a page or a built surface from the model. Kept English like `Connector`; masculine, `der Build`. |

conventions/PINS.md

@@ -31,6 +31,6 @@ A member declares its pins in `pins.json` at its root. The report reads every pi
 
 `pins` lists the pins. Each names its `kind`, the `file` that holds the line and the `repo` it points at. `after` lists the commands that run in the member once that pin has moved, in order. `move`, a command with `{version}` in it, replaces the kind's own move, and a `core-release` pin must give one. `watch` lists paths in the upstream for a commit pin, which is then behind only when a newer commit touches one of them; a `contract-commit` pin watches the paths its strings name without being told.
 
-`verify` lists the commands that run once every pin of the member has moved, and a failing one blocks the member. `release` lists the commands that run when the resync releases the member, with `{version}` standing for the new version without its `v`; they leave the bump uncommitted, and the run commits it. A member that nothing takes by tag has no `release`.
+`verify` lists the commands that run once every pin of the member has moved, and a failing one blocks the member. A check in `verify`, `npm run <name>:check`, fails as soon as a move changes what its writer `npm run <name>` writes, so the report names a check whose writer no pin's `after` or `move` runs. `release` lists the commands that run when the resync releases the member, with `{version}` standing for the new version without its `v`; they leave the bump uncommitted, and the run commits it. A member that nothing takes by tag has no `release`.
 
 The report names every entry that does not match a line in the file it names, so a `pins.json` that has fallen behind its member is seen the first time the report runs.

conventions/REPOSITORIES.md

@@ -87,4 +87,4 @@ A pin is an editorial line, moved on purpose. Which release each member is on is
 
 ## Re-syncing after a release
 
-In this order, one pull request each: design, then the three sites, then the three instances and meta-model, then service-conventions, then the engine, then the connector, then the MCP server, the chat server and the three deployments, then the Obsidian plugin, then field-notes, then the two `.github` repositories. Design first because a site's suite runs design's checks; the models before the engine because the sites' model pages are built from them; service-conventions before the engine and the connector because both vendor it; the connector after the engine because it is a client of the engine's API and its specification lives there; the MCP server after the models because it parses them, the chat server beside it because it is a client of the server's hosts and the same deployments pin both, the deployments after both because each pins a release of each, and the Obsidian plugin after the models for the server's reason, since it parses them with the same package. Nothing here opens those pull requests for you.
+The family resync moves the members that take a release, when the owner starts it: the README of robertblust/conventions says how, in its section on keeping the family in step, and the report the resync writes says which members move. The run computes the order from the pins, each member after what it takes, so this file keeps none.

conventions/WORKING.md

@@ -40,6 +40,8 @@ This holds for every repository in the family that another one takes from, whate
 
 A release is a tag and a GitHub Release with notes in the prose register: what changed for the consumer, what breaks, how to take it. There is no publish step anywhere in the family; the tag is the release.
 
+A release ends at its tag. The family resync moves the pins of the repositories that take it, and only the owner starts a resync: two runs started side by side open the same branches and write the same files, a resync after every release makes many small ones that overlap where one would carry them all, and the run computes from the pins which members move and in what order, so nobody works it out by hand. An agent that releases says in its report which members will move at the next resync, and neither re-pins them by hand nor starts a resync.
+
 Everything one repository takes from another is pinned by a visible line in the taking repository, in whatever form its tooling gives it — a tag in a package file, a commit in a source file, a release in a vendoring manifest. Pins are editorial. They move when the owner decides they move, in a commit that says why, and no bot proposes them; a pin that is behind is intent until the owner says it is drift.
 
 What is taken decides the form of the pin. Code or rules the taking repository runs or is checked against are pinned by tag, because the release is what carries the notes and the minor or major an update depends on: a parser, a design system, a schema vendored as `core/`, these files. Content it draws or serves is pinned by commit, because content changes with every edit and promises nothing a release could state, and the pin only chooses which state is shown: a mental model on a site or behind an MCP host, an OpenAPI file on a page. One repository can be taken both ways, and meta-model is: companygraph.io runs its parser at a tag and draws its `example/` and `core/` at a commit. One pin breaks the rule. The Apaleo connector implements contracts that live in the engine, and the engine has no releases, so the connector pins them by commit; once the engine releases, that pin becomes a tag.

conventions/manifest.json

@@ -1,18 +1,18 @@
 {
   "repo": "robertblust/conventions",
-  "tag": "v1.38.0",
+  "tag": "v1.39.0",
   "files": {
     "conventions/WRITING.md": "sha256:625c12b0d52ac3ad74c8a364228005e3441818297022246865f884a687f96e71",
-    "conventions/WORKING.md": "sha256:8fa553323ec1d53c8a2b4b5f260790731db69856a1053896f771db3caf94ee1c",
-    "conventions/REPOSITORIES.md": "sha256:c37d322b74344a7677ab5248841b230612c42107e6721123971458abde03dddd",
-    "conventions/PINS.md": "sha256:ccfa0b7876eb3b71127cfe1db573e03a0ed42b84cd0c4b80270a2ba0bef80bd9",
+    "conventions/WORKING.md": "sha256:5495621b9640d21fd9191ba4d9a8de9cc07ec259267f7729a800a245f1155d8b",
+    "conventions/REPOSITORIES.md": "sha256:461654ef06ee307d2e10daba201e97dbcad093cf6b3b7c35b6bad3627f9f4fec",
+    "conventions/PINS.md": "sha256:754a2f3d3f442e58a3ca05d6832c1062b92df80b21eb4d36e94c4b16fd302e10",
     "conventions/WRITER.md": "sha256:bc3b92683130b75993f824f0e34073d4344846c91be2009fd90c39099fd4fd48",
     "conventions/TRANSLATOR.md": "sha256:d56af63a98ce17c0219efc09a368a1a21f52b5dded59cef7aa83471383fd9183",
-    "conventions/GLOSSARY.md": "sha256:ffad6b58a3c3b5c92109ec15b1aa0669a2915e9641b7d240c3126a65a16a3cbf",
+    "conventions/GLOSSARY.md": "sha256:b43ee356adbbec543b08c82513344882db6be28d2dc6525cbae64f5375fb9d7b",
     "conventions/GERMAN.md": "sha256:2f4651dd74e2970f0751621bf9264441b43ee619b8a6e1373d5f3c7809581f77",
     "conventions/EDITOR.md": "sha256:5f761da18ae1b6c6e953b71cf79573c9dd1896db44c0c61593540281e8eb0777",
     "conventions/BACKREADER.md": "sha256:9f114bedb78e18d6c9505f95728992f06fd334a08c6aab66b18a31882d7c0ebd",
-    "conventions/AGENTS.md": "sha256:13d15a8a1f1994e0b20a3fe11cfc8d46a758dd47ee0e869d66d9f705ad9b712a",
+    "conventions/AGENTS.md": "sha256:8a2ef6f880cfbded83675a73cd2cb77b9f1f7697139ba4c3cbb165b3bf028ac4",
     "conventions/conventions-sync": "sha256:a190ff79c2d8d3f6f6d9a597e9f261654f2419d30e2ac43abf6c64ebe2c47ed9",
     "conventions/conventions-check": "sha256:30b2528e84381f04fd6b06b26ef103cd2360d877639706eb0b53f362a10fc433",
     "conventions/conventions-format": "sha256:2911a0d30dda1bc0f621522a9538b3e39704eee03458e65ba320eccbf39b5c7f",