@cratis/pi 7.1.3 → 7.1.5

package/package/corpus/skills/cratis-documentation-writing/SKILL.md

@@ -61,7 +61,13 @@ and neighboring pages; ask only when the alternatives change the outcome.
    targeted recipes, and exact reference. Give different languages or hosts
    their own procedures when a shared path cannot be run as written. A
    'coming from X' bridge should map familiar concepts to the new workflow,
-   not replace it.
+   not replace it. When a page shows several backends, state how they differ
+   once, in a "how the backends differ" table near the start: identity
+   source, id and response wire types, default authorization, live versus
+   snapshot queries, and unsupported features with their tracking issue.
+   Inside a step, write only what the current tab's reader needs. Across a
+   series, keep backend limitations in one table on the series index and link
+   it; don't repeat an issue-tracked limitation on every page.
 4. Draft in workflow order. For a tutorial, use one working domain throughout,
    show what to run and what appears, and recap before adding another concept.
    For a how-to, keep only what the specific task needs. Link out for details.
@@ -144,6 +150,12 @@ Never transcribe an API from memory, hand-translate an unsupported client, or
 claim a pasted block is runnable when it requires unstated setup. Show the
 command and observable output for a substantial walkthrough.
 
+Adding a backend or client to a product also changes pages the product's own
+checks don't scan, such as cross-product and site-level pages. Search them for
+single-language claims ("in C#", C#-only APIs presented as universal) and for
+series indexes whose description, reading order or production claims no longer
+hold.
+
 Edit the *authored* file, never a synced copy. The Cratis site derives each
 product page's edit link from that source path, so don't hand-author
 `editUrl` in product frontmatter. Recheck examples against the supported
@@ -157,8 +169,9 @@ wording, structure and examples as readers hit them.
 
 Read [Cratis site specifics](references/cratis-site.md) before writing a
 Cratis product page. It covers the teaching components (`YouWillLearn`,
-`Recap`, client tabs), maturity labeling, cross-product compatibility, the
-Prompter feedback signal, and who decides page structure.
+`Recap`, client tabs, including on site-owned pages), the variant-docs audit,
+maturity and preview labeling, cross-product compatibility, the Prompter
+feedback signal, and who decides page structure.
 
 ## Contextual awareness
 

package/package/corpus/skills/cratis-documentation-writing/references/cratis-site.md

@@ -25,6 +25,16 @@ imports and JSX. Use one where it clearly teaches better than plain Markdown.
 - The site links each expanded tab to its exact snippet file in the owning
   repository. Don't add those links by hand.
 - Arc's authoring check rejects `ArcBackendTabs` nested inside `Steps`.
+  Tabs can't sit inside `Steps` anywhere, so write a backend procedure as
+  numbered H2 steps and keep `Steps` for shared, untabbed procedures such as
+  the React screen.
+- Site-owned MDX under `web/src/content/docs/` can use `<ArcBackendTabs>` and
+  `<ChronicleClientTabs>` without an import. The site expands them from the
+  same manifest and client-owned snippets as product pages, including in the
+  Copy Markdown mirror; check the mirror to confirm the macro expanded.
+- The variant-docs audit (`web/variant-docs.yml`) also covers site-owned
+  pages. Every site page is audited or explicitly excluded with a reason, and
+  direct single-language backend fences are ratcheted.
 - `TopicHero` declares `title` (required), `icon` and `eyebrow`. Don't copy
   props from a page that passes others; they are ignored.
 
@@ -40,6 +50,10 @@ example in a `:::caution` aside, and state only the change and production
 limits the product source supports. Don't infer those limits from a
 site-wide label.
 
+Label a preview variant on the first screen of every page that shows it, not
+only on its own getting-started page. An unsupported-variant snippet is one
+sentence with its tracking issue; the surrounding prose doesn't repeat it.
+
 ## Cross-product compatibility
 
 There is no numbered compatibility matrix across the Chronicle kernel and its

package/package/corpus/skills/cratis-documentation-writing/verification.json

@@ -7,6 +7,10 @@
     { "kind": "skill-contains", "value": "## Work from the reader outward" },
     { "kind": "skill-contains", "value": "cratis-technical-examples" },
     { "kind": "skill-contains", "value": "## Completion checklist" },
-    { "kind": "skill-contains", "value": "(references/cratis-site.md)" }
+    { "kind": "skill-contains", "value": "(references/cratis-site.md)" },
+    { "kind": "skill-contains", "value": "\"how the backends differ\" table" },
+    { "kind": "skill-contains", "value": "keep backend limitations in one table on the series index" },
+    { "kind": "skill-contains", "value": "single-language claims" },
+    { "kind": "skill-contains", "value": "the variant-docs audit" }
   ]
 }

package/package/corpus/skills/cratis-technical-examples/SKILL.md

@@ -31,6 +31,11 @@ language-tab layout or documentation site implementation.
 - **Multi-language client example:** keep one explanation; use the established
   client-owned snippet mechanism, compile each client against its own SDK, and
   offer only implementations that exist. Do not translate a C# call by guess.
+  Use the same domain type names in every tab; if the prose has to explain
+  which name each tab uses, fix the snippets instead. State each backend's id
+  and command-response wire type (for example `Guid` versus `string`) and keep
+  one id type per concept across every page of a series. Shared frontend code
+  that depends on those types must be backend-neutral or tabbed per backend.
 - **Sample application:** one realistic domain, explicit prerequisites and
   package versions, a documented run command, a reproducible state to start
   from, and a visible result. Keep it minimal enough for a new reader to finish.
@@ -83,6 +88,14 @@ elsewhere in product documentation. For those, verify against real source and
 a runnable sample/spec or an explicit snippet comparison; do not claim
 coverage from a site build or a validator that never scans the page.
 
+A compiling tab is not a working tab. For each backend, confirm that the
+artifact is discovered and registered, that proxy generation emits the file
+and types the page names, and that any runtime behavior the page claims (live
+updates, constraint rejection) was observed against a real kernel and sink. If
+a tab's code compiles but fails at runtime, don't publish it with a workaround
+in the prose after it. Put working code in the tab and reference the tracking
+issue in a code comment.
+
 A simple process beats a large unmaintained examples gallery: give the reader
 one small success first, then link to a fuller sample when they need it. Update
 examples alongside public API changes and incoming reports of copy/paste failure.

package/package/corpus/skills/cratis-technical-examples/verification.json

@@ -6,6 +6,9 @@
     { "kind": "skill-contains", "value": "## Choose the right source" },
     { "kind": "skill-contains", "value": "**Multi-language client example:**" },
     { "kind": "skill-contains", "value": "## Build the example as a reader would" },
-    { "kind": "skill-contains", "value": "## Stop conditions" }
+    { "kind": "skill-contains", "value": "## Stop conditions" },
+    { "kind": "skill-contains", "value": "A compiling tab is not a working tab." },
+    { "kind": "skill-contains", "value": "one id type per concept across every page of a series" },
+    { "kind": "skill-contains", "value": "Use the same domain type names in every tab" }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cratis/pi",
-  "version": "7.1.3",
+  "version": "7.1.5",
   "description": "Configuration-aware Cratis AI integration for Pi",
   "type": "module",
   "files": [