Studio graph capabilities

This system package implements ordinary Canvas/Placement/Placeable interfaces. It owns no database, web server, Worker, page session, or special presentation object per rendered subject. The workspace binds storage and relationship edges. The checked component is an independent consumer of the same public contracts.

  • Canvas.create creates an initialized canvas. The server entry factory uses the workspace host's idempotent root protocol, without a second package-local cache.
  • Canvas.place validates the requested renderer through the subject's portable Placeable.canPresent contract and creates one placement with both relationships.
  • Canvas.createAndPlace is an example compound factory: child canvas creation, renderer validation and placement creation share one transaction. An invalid renderer rolls back the child, too. Other domains can compose their own creation ports in exactly this way; there is no frontend business reducer.
  • position and size are separate whole-record registers. Concurrent move and resize survive independently; concurrent moves resolve in server acceptance order without mixing one move's x coordinate with another move's y coordinate.
  • remove is explicitly server-only. Deletion needs the full incoming-reference graph; a partial replica cannot safely predict all deletion restrictions and cascades. Removing a placement preserves its subject. The interface does not advertise a portable delete or keep a hidden archive in the canvas query.

The generic canPresent<atom Subject> implementation reads the explicitly granted reflection catalog [presentations] port. This exposes only immutable checked presentation IDs, subject contracts and their conforming atoms. It does not expose live object inventory or private state. The dispatcher verifies the concrete receiver; reference expectations supplied by a caller are not conformance proof. A changed presentation catalog participates in the consuming execution group's reuse digest. Unrelated modules do not acquire that dependency.

Queries have explicit prototype bounds: 100 canvases in navigation and 200 placements per open canvas. Title-only cards use their own small input projection. A selected/new placement can retain PlacementInputs even if a list excludes it. A larger Studio should add explicit windows or pagination rather than silently pretend these bounded queries cover an arbitrarily large workspace.

tools/local-first/studio.nix builds the source snapshot through the checked artifact builder and tests the generic workspace host. Run nix build .#checks.x86_64-linux.camino-studio-capabilities at the monorepo root. These are unpublished fixture resource pins; normal independently retained source assembly and scaffolding are qualified in WI-12. The old checkedServer/Yarn and migration recipes were removed, rather than presenting them as a compatible path.

S
Description
Quixos Workspace Template resource
Readme
465 KiB
Languages
TypeScript 64.8%
Nix 35.2%