@cratis/pi 7.27.1 → 7.27.3

package/package/corpus/skills/cratis-screenplay-model-authoring/references/screen-authoring-workflow.md

@@ -12,6 +12,7 @@
 - 4. Validate authoring and executable readiness
 - 5. Run/render using the same configuration
 - 6. Use Screenplay-owned fixtures
+- Replay the workflow in CI without a Screenplay checkout
 - Edit, render, run and see it in the browser
 - Transcript checklist
 
@@ -109,6 +110,25 @@ contract for `--workspace` and keep its application identity equal to the source
 name. Build/tests/runtime checks are then the V5 steps owned by
 `cratis-screenplay-render-and-gap-fill` and `cratis-stage-rendering-and-sandbox`.
 
+Before re-rendering an edited model over an earlier render, preview it:
+
+```shell
+cratis render <model-folder> --name <ApplicationName> --destination <render-dir> --check -o json
+```
+
+`--check` (CLI 3.44.0) plans exactly like a render and reports per path what a real
+render would write, delete, leave unchanged or refuse, without writing anything. It
+exits `0` when the destination is current, `6` (`changes_pending`) when a render
+would change it and `5` when planning is refused. Since CLI 3.45.0 the receipt lists
+for every path the semantic declarations it realizes (`sources`: id, kind and a
+`Module/Feature/Slice/Name` address) and a `bySource` view mapping each declaration
+to its files. After an MCP edit, use `bySource` to confirm the edited screen or
+binding changed exactly the files you expect, and `semantic-diff` (MCP, Screenplay
+4.131.0: `before` and `after` as `{ "workspace": "active" }`, `{ "path": "<folder>" }`
+or `{ "workspaceJson": "<export>" }`) to compare the model before and after the
+edit. These are newer than the verified vector: report them as published, not as
+executed there.
+
 For screens-release parity, the smoke check must assert that every authored
 screen, template, component, form, toolbar, outlet, route and package/icon use is
 represented in the generated plan or runtime diagnostics. A consumer that cannot
@@ -125,8 +145,9 @@ maintained duplicate.
 Verified public vector and executable checks:
 
 - toolchain: public CLI 3.43.0 (`23e5a24`), whose default runtime is
-  `cratis/stage:4.52.0` and which bundles Screenplay 4.127.0. Latest public
-  packages are Scene 4.15.0, Screenplay 4.129.0, Stage 4.57.0 and Studio 0.144.4;
+  `cratis/stage:4.52.0` and which bundles Screenplay 4.127.0. Published since,
+  and not verified by this vector: Scene 4.17.0, Screenplay 4.133.1, Stage 4.64.0, CLI
+  3.46.1 (bundling Screenplay 4.130.0, default Stage still 4.52.0) and Studio 0.152.2;
   claims made through `cratis` are 4.127.0 compiler claims;
 - fixture root: `Source/DotNET/Screenplay.CanonicalCorpus/Corpus/ScreenComposition/v1/source/folder`
   in the Screenplay repository;
@@ -150,6 +171,15 @@ Verified public vector and executable checks:
   Play proof (test-account decision). UI-profile rejection and render-then-recover
   shipped in Cratis/cli#301.
 
+## Replay the workflow in CI without a Screenplay checkout
+
+`screens-smoke.sh <work-folder>` in the AI repository's `screens-smoke` verification folder installs the pinned public `cratis` CLI,
+materializes the published `Cratis.Screenplay.CanonicalCorpus` folder source (so the corpus stays Screenplay-owned and
+is never copied), replays the MCP transcript with the revision-checked column edit, renders the edited folder and
+requires the column in the generated `scene.json`. The pins live in `screens-smoke.json` and follow the verified
+vector above; the corpus package is the one that records that vector. The corpus verification job runs it on every
+change. The browser step below needs Docker and Chromium, so it stays a manual step.
+
 ## Edit, render, run and see it in the browser
 
 The loop above proves an agent can change the model. This proves the change

package/package/corpus/skills/cratis-screenplay-ui-composition/references/screen-composition-contract.md

@@ -34,8 +34,10 @@ hand-writing an alternate shape.
 Keep those three lines separate in reports. Correct an old limitation only when
 the package/version you are using proves the new level. Verified public vector:
 CLI 3.43.0 with its default `cratis/stage:4.52.0` and bundled Screenplay 4.127.0;
-latest public packages are Scene 4.15.0, Screenplay 4.129.0, Stage 4.57.0 and
-Studio 0.144.4. All three levels hold for the canonical `ScreenComposition`
+the executed vector renders on Scene 4.15.0. Packages published since are newer than
+that vector and are not claimed verified: Scene 4.17.0, Screenplay 4.133.1, Stage
+4.64.0, CLI 3.46.1 (its default Stage is still 4.52.0) and Studio 0.152.2. All
+three levels hold for the canonical `ScreenComposition`
 corpus:
 
 - authoring and executable admission: MCP opens it with `sourceSuccess true`,
@@ -210,10 +212,38 @@ screen owns the button. Dialog opening stays an interaction (`on click open dial
 node. A dialog destination must state every input with a typed `with`/`parameter`
 binding; a runtime default is not an authored contract.
 
+What Scene 4.17 adds to the runtime side of this contract, so an agent knows what a
+destination can do once it is authored (authoring acceptance and executable
+admission are separate, see Support levels - a Scene release is not a Stage
+release):
+
+- **Nested outlets.** A `core:outlet` component declares a named nested outlet on a
+  screen. A destination into it opens its screen there and keeps the declaring
+  screen on the page; the opened screen may declare outlets of its own, so
+  composition nests to any depth. A deep link to the innermost level composes
+  every level above it, and back closes the innermost level only. An outlet
+  declares the template types it accepts; a destination into a missing or
+  incompatible outlet is a navigation diagnostic, not a fallback.
+- **Toolbar buttons open destinations.** The Cratis Components toolbar button runs
+  its attached interactions and opens its authored `destination` (a dialog or a
+  slice screen) through the enclosing navigation host. Label, icon, text and
+  presentation are properties of the button, so author them on the toolbar item
+  rather than on a wrapper.
+- **Settings pages.** `@cratis/scene.blueprint.components` ships a `SettingsPage`
+  screen template: a module's settings as a generated command form with save and
+  discard. Prefer it to a hand-built form for settings, and expose its command as
+  template configuration.
+- **Embedded hosts.** `WebViewPackageHost` renders a custom package set inside a
+  webview (VS Code, Event Models) with no Studio dependency; the same package set
+  must produce the same screens in the standalone host.
+
+Whether a given Stage or CLI release renders each of these is a runtime level
+claim: confirm it from the render receipt and diagnostics before reporting it.
+
 ## Design-time generation results
 
 Design-time actions belong to component packages, not to the model and not to an
-agent. Scene 4.15 declares them as data (`PackageDesignTimeMetadata`) and ships
+agent. Scene 4.15 (unchanged in 4.17) declares them as data (`PackageDesignTimeMetadata`) and ships
 their code in an optional design-time bundle; a runtime host that does not set
 `loadDesignTime` loads none of it, so nothing a design-time action does can exist
 only at runtime. The one Cratis action today is **Generate fields**

package/package/corpus/skills/cratis-stage-rendering-and-sandbox/SKILL.md

@@ -42,7 +42,7 @@ argument or an invalid semantic option.
 
 | Source | Pin | Notes |
 | --- | --- | --- |
-| Stage | `4.52.0` (`v4.52.0`, `0e4fd87`) as the CLI 3.43.0 default; latest public package `4.57.0` (`3b8049f`) | Renderer, sandbox host, spec runner; the CLI default image is `cratis/stage:4.52.0`. Both define `STAGE-SCENE-ACTION-001` and `STAGE-SCENE-INTERACTION-001`. Earlier executed baselines: 4.51.3, 4.51.1, 4.49.5 and `v4.24.2` (`32dcac4`) |
+| Stage | `4.52.0` (`v4.52.0`, `0e4fd87`) as the CLI 3.43.0 default; newer public packages exist (latest `4.64.0`, built on Scene 4.16.0) and are not part of the verified vector | Renderer, sandbox host, spec runner; the CLI default image is `cratis/stage:4.52.0`. Both define `STAGE-SCENE-ACTION-001` and `STAGE-SCENE-INTERACTION-001`. Earlier executed baselines: 4.51.3, 4.51.1, 4.49.5 and `v4.24.2` (`32dcac4`) |
 | cratis CLI | `3.43.0` (`v3.43.0`, `23e5a24`) | `cratis render`, `cratis run`; the tag pins `StageVersion` 4.52.0 and `ScreenplayVersion` 4.127.0. The public CLI renders the canonical corpus and runs the stdio MCP transcript; refusing an unresolvable UI profile and recovering a rendered application shipped in Cratis/cli#301. Older baselines: 3.41.0, 3.40.7, `v3.28.2` (`141c499`, Cratis/cli#253) |
 | Screenplay | bundled `4.127.0`; latest public language package `4.129.0` | The CLI bundles 4.127.0, so compiler claims made through `cratis` are 4.127.0 claims; use the standalone 4.129.0 tool only for language features newer than the bundle |
 | Rendered applications | Arc, Chronicle, Scene 4.15.0, .NET 10 | CLI 3.43.0 renders the canonical corpus to `.cratis-render.json`, backend artifacts, `.frontend/**`, `scene.json`, `src/bindings.ts`. Verify the generated package set for each render before claiming exact Scene runtime parity |

package/package.json

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