@graview/skills 0.0.0-stage → 0.1.0

package/skills/graview-permissions/SKILL.md

@@ -0,0 +1,145 @@
+---
+name: graview-permissions
+description: Declare who may do what in a Graview app once, so the store enforces it, the actions strip narrows and an agent seat narrows with it — verified by graview check and by trying it.
+---
+
+# Declare who may do what
+
+Permission is another input to a derivation the framework already does. What
+can be done is already DERIVED from the schema and the invariants, so adding a
+principal and some grants narrows the interface and the agent surface at the
+same time, from one declaration.
+
+Two things must not be got wrong, and they are the reason to follow this rather
+than improvise.
+
+**Enforcement belongs at the STORE.** The tool runtime calls the same mutations
+a person does, so a check inside a React component is not a permission system,
+it is a suggestion — and the agent seat is the bypass.
+
+**An action you may not take should SAY SO rather than vanish.** Hiding it
+teaches people the software is broken: they watched a colleague do this
+yesterday and now the button is gone.
+
+## Do this
+
+1. **Write the policy where the checker can read it.** In your domain layer,
+   not your UI:
+
+   ```ts
+   export const policy: Policy = {
+     roles: ["coach", "analyst", "player"],
+     grants: [
+       { roles: ["coach"], mutations: "*" },
+       { roles: ["analyst"], mutations: ["plan-drill", "cut-drill", "design-drill"] },
+       // The line can be drawn by SUBJECT KIND on the same mutation: an
+       // analyst may rename a drill and not a position, because a position's
+       // name is part of the formation and the formation is selection.
+       { roles: ["analyst"], mutations: ["rename"], kinds: ["drill", "session"] },
+       { roles: ["player"], mutations: ["end-unavailability", "explain"] },
+     ],
+   };
+   ```
+
+2. **Hand it to both `defineApp` and the `Store`.** `defineApp` is what
+   `graview check` reads; the `Store` is what enforces.
+
+   The derived acts ride your grants rather than needing their own line:
+   `edit-<kind>` is permitted to whoever may change or make the kind,
+   `remove-<kind>` to whoever may make it — or to any grant that names the
+   act or says `*`. A refusal names who could, so a seat told no learns what
+   it lacks rather than concluding the capability is missing.
+
+3. **Give the provider a principal.** `<GraviewProvider principal={{ kind:
+   "human", id: me.id, roles: me.roles }}>`. The interface reads it to decide
+   what to OFFER; the store decides what to allow; the log attributes to it.
+   Three readings of one object, which is why they cannot drift.
+
+4. **Do not filter anything yourself.** The narrowing happens once, in
+   `deriveAffordances`. A provider written tomorrow inherits it.
+
+5. **Remember the absence of a policy permits everything.** That keeps
+   permission opt-in rather than a tax every app pays before it has decided it
+   has users.
+
+6. **The derived edits ride your grants.** `edit-<kind>` — the act the
+   framework derives for fields nobody writes — is permitted to whoever may
+   already run an act that writes a field of that kind or creates one, on
+   that kind. An analyst who may `resize-drill` may change a drill's other
+   fields; a player who may not, may not. Nothing to add to the policy; a
+   grant may still name `edit-drill` outright, and `*` reaches it. When no
+   role may write or create a kind at all, `graview check` says so per
+   field (`field-without-writer`): grant an act, or mark the field `fixed`.
+
+7. **Put the installation in the graph.** Who may use the app, who has been
+   asked to, and what each holds are nodes and acts, not a second app:
+
+   ```ts
+   const installation = declareInstallation({ roles: ["coach", "analyst", "player"], admin: "coach" });
+   createSchema([...yours, ...installation.kinds]);        // user, invitation — typed, so
+                                                          // an edge may say to: ["user"]
+   mutations: [...yours, ...installation.mutations];        // invite, welcome, remove-user, grant, revoke, revoke-invitation
+   modules: installation.modules;                           // drawn only for those who administer it
+   policy: installation.withPolicy(policy);                 // the admin's grants, and "you, on yours" for a profile
+   ```
+
+   The coach sees "Show the installation" in the bar and on an embed's strip
+   and the people and invitations rise as ordinary districts; nobody else
+   ever sees them. A person's record page is their profile, and the derived
+   `edit-user` is theirs alone through a `self: true` grant. Register
+   `reachLens` over the people with a title and the policy is a picture:
+   roles down the side, acts across the top, a mark where the store would
+   say yes. Chapter 14 of `apps/seedbed` is the worked example.
+
+   **Pointing at a person?** `declareInstallation({ …, required: true })`.
+   An edge into a module the app can turn off earns a `module-edge-leak`
+   warning, and for people the only answer is "it is never off" — an
+   installation without people is a household of one, not a disabled module.
+   Say it once and the checker stops asking.
+
+## Worked examples
+
+- `packages/core/tests/unit/permissions.test.ts` — grants by role, by mutation
+  and by subject kind, and the refusal that names who could
+- `packages/tools/tests/unit/affordances.test.ts` — a guarded store: what a
+  principal is offered, what is withheld and said, and how the agent seat
+  narrows with it
+
+## Then find out whether it worked
+
+```sh
+pnpm build && npx graview check ./dist/domain/app.js
+```
+
+The checker reports `mutation-unreachable-by-any-role` (declared and
+unreachable), `role-may-do-nothing`, `grant-unknown-mutation` and
+`grant-unknown-kind`. All four are silent at runtime and obvious at build time,
+and the person who finds them otherwise is the person standing in front of a
+button they cannot press. Report the output.
+
+**And try it.** Two tests that matter more than the check:
+
+```ts
+it("refuses at the store, where nothing can go around it", () => {
+  expect(() => store.apply(call, { author: player })).toThrow(PermissionDeniedError);
+  expect(store.log.length).toBe(0);
+});
+
+it("narrows the agent seat from the same policy", () => {
+  const seat = createToolRuntime(store, { author: { kind: "agent", roles: ["player"] } });
+  expect(seat.definitions.map((t) => t.name)).not.toContain("select-player");
+});
+```
+
+Undo is a change and is judged like one: what you may undo is what you may have
+done. If you have a custom undo path, check it goes through `store.undo`.
+
+## What the check cannot see
+
+- Whether the roles match how the organisation actually works. That is a
+  conversation, not a declaration.
+- Whether a withheld action's message helps. It names the roles that could;
+  whether that is useful depends on whether a person knows who holds them.
+- Whether the principal is who they say they are. Graview authorises; it does
+  not authenticate. Wire that to your own identity provider and pass the result
+  in as the principal.

package/skills/graview-port-app/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: graview-port-app
+description: Port an existing application onto Graview — deciding what is a node, what is a field and what is an edge — and proving the port with a parity test rather than an assertion.
+---
+
+# Port an existing application
+
+The hard part of a port is not the code. It is deciding what your existing
+schema was really saying, because a relational schema hides three different
+things inside a foreign key: a real relationship, an implementation detail, and
+a thing that should have been a node all along.
+
+## The decisions, in order
+
+1. **What is a NODE?** The test: does anything point at it, and does it have a
+   life of its own? A `status` string is a field. A `rationale` — a reason
+   someone recorded, that outlives the person who recorded it and that other
+   things refer to — is a node, and turning it into one is usually the moment a
+   port starts paying for itself.
+
+2. **What is an EDGE?** A relationship a person would name out loud. `assigned-to`
+   is an edge. `created_at` is a field. A join table with columns on it is a
+   node, not an edge, and pretending otherwise is the mistake that costs most
+   later.
+
+3. **What is a MUTATION?** Every change, named as an act rather than as a write.
+   Not `updateDuty` but "Reassign run". The title is the label a person reads
+   in the strip AND the instruction an agent reads in its tool schema, so an
+   opaque one costs twice. If you find yourself writing `patch`, you have
+   skipped this step.
+
+4. **What is an INVARIANT?** Everything your current code validates, plus
+   everything it was supposed to. Give each one repairs — see
+   `graview-invariant`. Rules that name their repairs are where the interface
+   stops needing you to design it.
+
+5. **What is a LENS?** Your primary screen, described without your nouns. A
+   calendar is intervals in columns. A checklist grid is a bipartite mapping. A
+   formation is positions with domain-given coordinates. If one of the three
+   shipped lenses fits, bind roles to your fields and write no picture at all.
+
+## Do this
+
+1. Build the domain tier first, with no UI. Get `graview check` clean before
+   anything renders.
+2. Load your real data through a `snapshot`, not a fixture you invented. A port
+   that works on twelve made-up nodes and falls over on the real graph has
+   proved nothing.
+3. Register default views, look at it, and only then write custom ones.
+4. Port the rules LAST, and port them as tests first.
+
+## Worked example
+
+- The household product (now in its own repository) is a port. Its parity
+  fixture was generated by running the ORIGINAL app's code over the same data,
+  and its test asserts the framework's invariants reproduce every violation —
+  90 across 9 provocations. That fixture-and-test pair is the reason anyone
+  should believe a port, and the shape to copy.
+
+## Then find out whether it worked
+
+```sh
+pnpm build && npx graview check ./dist/domain/app.js
+```
+
+**And write the parity test.** This is the one thing that makes a port
+trustworthy, and it is worth more than every other check here combined: run the
+OLD system's validation and the new invariants over the same graphs, and assert
+they agree.
+
+```ts
+// Generated by running the old code over N provocations, then committed.
+import expected from "./fixtures/legacy-violations.json";
+
+it("agrees with the system it replaces, violation for violation", () => {
+  for (const provocation of provocations) {
+    const store = createStore({ snapshot: provocation.graph });
+    const mine = store.violations().map((v) => v.message).sort();
+    expect(mine).toEqual(expected[provocation.name]);
+  }
+});
+```
+
+The framework's own the household example port does this across 90 violations and nine
+provocations, against a fixture generated by running the original code. If you
+cannot generate that fixture, say so — and say what you are relying on instead,
+because "I read both and they look the same" is a different claim.
+
+## What the check cannot see
+
+- Whether you modelled the domain or transcribed the database. The symptom is
+  edges named after columns.
+- Whether behaviour the old system had is gone. Only the parity test knows.
+- Whether the port is worth finishing. A port that has not made anything
+  clearer by the third kind is telling you something.

package/skills/graview-seed/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: graview-seed
+description: Get a Graview app from a blank graph to a useful one — the order the declaration already states, a plan a model proposes, and one turn that can be taken back.
+---
+
+# Fill a blank graph
+
+Every product ships empty once, and it is the state its author never sees:
+your own graph has had data in it since the first afternoon. A ten-kind app
+on a blank installation is one door and nine silent districts, and the person
+who finds that out is the first one to open it.
+
+Two things make it a surface rather than a wall: the app already declares the
+ORDER things must be made in, and what a model proposes can be an object
+rather than a list of calls somebody applies by hand.
+
+## What the declaration already says
+
+`creates: ["feature"]` on an act, and `zoneId: nodeRef(["zone"])` in its
+input, are together a chain: a feature cannot be made until a zone exists.
+
+```ts
+import { beginning } from "@graview/core";
+const chain = beginning(app);
+chain.roots;        // kinds that can begin with nothing in the graph
+chain.doors;        // the acts that are the way in
+chain.order;        // every kind, with what it waits for and how deep
+chain.unreachable;  // what nothing here can make — often right, always worth seeing
+```
+
+`graview check` says it as a note (`blank-graph-unreachable`), and
+`graview describe` reads the whole thing out. Run it before you believe your
+app onboards anybody:
+
+```sh
+pnpm build:domain && npx graview describe ./dist/domain/app.js
+```
+
+## Do this
+
+1. **Mount `<Begin>`.** It is derived — the chain, the acts that can run now,
+   what everything else is waiting for, in your own plurals. Put it on the
+   home surface of the routed face, or anywhere a person lands first. It
+   stands down on its own once every kind has something in it:
+   ```tsx
+   <Begin whenFull={<YourOwnHome />} />
+   ```
+
+2. **Give the root kind an act that needs nothing.** One act with no required
+   `nodeRef` is the difference between an app that onboards itself and one
+   that cannot be started. If every creating act needs a node, `graview check`
+   says `blank-graph-has-no-door` — and if the data really arrives by seed,
+   migration or sync, that note is the answer rather than a fault.
+
+3. **Let a model propose, and make it a plan.** A plan is ordered by the
+   chain, judged before any of it runs, reviewable, and applied as ONE turn:
+   ```ts
+   import { applyPlan, planFrom } from "@graview/tools";
+   const plan = planFrom(store, proposals, { app, principal });
+   const done = applyPlan(store, plan, { author: surveyor });
+   store.undo(done.batch);   // the whole seeding, back the way it arrived
+   ```
+   A call can name what it is about to make — `as: "lawn"` — and a later call
+   points at it with `{ $plan: "lawn" }`. That is the only way a model can
+   refer to a node that does not exist yet, and it is what turns forty
+   proposals into one graph. It is all-or-nothing and says where it stopped;
+   `keepWhatRan` is for a caller who would rather have the half.
+
+4. **Show it before you run it.** `<PlanReview plan={plan} declinable />`
+   draws the plan in the order it will run, counts what it makes, and strikes
+   refusals through with their reason. `declinable` lets a person drop one —
+   and declining the area declines the tree standing in it, said beside the
+   entry BEFORE the press (`dependentsOf`, `without`). A seeding nobody read
+   is a seeding nobody can trust, and a review nobody can disagree with is
+   not a review.
+
+5. **Write the prompt from the graph, not from your head.** The model needs
+   the kinds, the acts and their arguments — which `generateLlmsTxt(app)`
+   already writes — plus what is already there, so it does not propose a
+   second Back Lawn.
+
+## Then find out whether it worked
+
+```sh
+pnpm build:domain && npx graview check ./dist/domain/app.js
+npx graview describe ./dist/domain/app.js
+```
+
+Then open it with an empty store (`?fresh=1` with a ship browser adapter) and
+go through your own front door. A test holds it: derive the affordances of
+each root kind on an empty graph and assert the way in is offered, and that a
+kind deeper in the chain offers nothing and says what it waits for.
+
+## What the check cannot see
+
+- Whether the order is the order a PERSON would want. The chain says what is
+  possible, not what is kind: an app may be able to start with practices and
+  still want to ask about the ground first.
+- Whether the model's proposals are any good. They are typed, ordered,
+  permitted and reversible — none of which makes them right, which is why
+  the review is a surface and not a formality.
+- Whether a seeded graph reads as somebody's. Ten plausible rows a model
+  invented look exactly like ten rows that matter, until someone reads them.

package/skills/graview-ship/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: graview-ship
+description: Deploy a Graview app — persistence, op-log-native migrations, export and health — with one declaration and one adapter, self-hosted or behind a service.
+---
+
+# Ship a Graview app
+
+`@graview/ship` holds what every deployment needs. One `defineApp`
+declaration plus one persistence adapter is a running deployment; nothing
+here requires a service.
+
+## Do this
+
+1. **Open the store through ship**, not by hand:
+
+   ```ts
+   import { createFileAdapter, openStore } from "@graview/ship";
+
+   const opened = await openStore({ app, adapter: createFileAdapter("./data") });
+   // opened.store is an ordinary Store; every applied diff is appended to
+   // the log and the snapshot rewritten, serialised in order. Hand off with
+   // `await opened.flush()` before close/exit — writes are async.
+   // One writer per scope: opening it twice interleaves and clobbers.
+   ```
+
+   The file adapter is deliberately readable: `snapshot.json`, append-only
+   `log.jsonl`, `meta.json` with the stored schema version. The core's
+   sqlite adapter is the scale answer.
+
+   **In the page, with no server**, the browser adapter stores the same
+   three things in `localStorage` and slots into the same call — import it
+   from `@graview/ship/browser` so the bundler never meets `node:fs`:
+
+   ```ts
+   import { browserStartsFresh, createBrowserAdapter, forgetFreshParam, openStore }
+     from "@graview/ship/browser";
+
+   const opened = await openStore({
+     app, adapter: createBrowserAdapter(), seed,
+     fresh: browserStartsFresh(),   // ?fresh=1 asks; a driven browser gets it unless ?remember=1
+   });
+   forgetFreshParam();              // the seed is the FIRST load, not every load
+   ```
+
+   Reopened, the store carries its persisted history: earlier edits are in
+   the activity, attributed, and undoable. Give the person a visible way
+   back — `StartFresh` from `@graview/primitives`, or `remembers: true` on
+   the pages context — because a demo that can be edited into a corner with
+   no exit teaches distrust. The sample apps' `main.tsx` files are the
+   worked examples; `pnpm remember` is the harness that holds them to it.
+
+   **The seed is read once**, into an empty store. When the default content
+   moves afterwards, do not delete the store to see it — diff and land it:
+
+   ```sh
+   graview sync-seed ./dist/domain/app.js --seed ./src/data/example.json --data ./data
+   graview sync-seed ./dist/domain/app.js --seed ./src/data/example.json --data ./data --apply
+   ```
+
+   The first prints the content steps — `task t-van is put`, `today is
+   patched: label`, `today holds t-van is tied` — and writes nothing; the
+   second lands them as one operation authored `system · ship:sync-seed`,
+   logged, undoable, leaving what people made alone unless `--prune` says
+   otherwise. The same five steps (`put-node`, `patch-node`, `drop-node`,
+   `put-edge`, `drop-edge`) go in `migrations[]` through `stepsMigration`
+   when every installation should get them.
+
+2. **Version the declaration, and migrate in primitives.** When the schema
+   changes shape:
+
+   ```ts
+   defineApp({
+     ...,
+     version: 2,
+     migrations: [{
+       from: 1, to: 2,
+       title: "size words become bed counts",
+       apply: (snapshot) => snapshot.nodes
+         .filter((node) => node.kind === "plot")
+         .map((node) => ({ op: "patch-node", id: node.id,
+           before: { size: node.size, beds: undefined },
+           after:  { size: undefined, beds: node.size === "large" ? 6 : 2 } })),
+     }],
+   })
+   ```
+
+   A migration answers in the op log's own five words, so running one appends
+   ordinary operations — authored `system · ship:migration`, stating intent,
+   carrying their inverse. `openStore` runs the pending chain on load.
+   `graview check` refuses a chain with a hole or a multi-version jump
+   (`migration-gap`, `migration-not-single-step`) before deploy time finds it.
+
+3. **Export is the exit.** `exportBundle(app, store)` — graph, attributed
+   history and version in one JSON shape; `assertBundle` refuses someone
+   else's app or a newer version, plainly. A tenant who cannot leave was
+   never a customer.
+
+4. **Health is coherence, not liveness.** `health(store)` reports sizes,
+   standing and dangling edges — poll it per deployment, curl it self-hosted.
+
+5. **The machine under the dev server is a door.** A locally-run product
+   very often has a coding agent installed, logged in and paid for; the
+   browser cannot spawn it and the dev server can.
+
+   ```ts
+   // vite.config.ts
+   import { localIntelligence } from "@graview/ship/dev";
+   plugins: [localIntelligence({ path: "/__graview/local", budgetUsd: 2 })]
+   ```
+
+   Declare it — `intelligence: [{ …, reach: ["paste", "local"], bridge:
+   "/__graview/local" }]` — and read it with `useLocalIntelligence(path)`
+   from `@graview/react`. The spawned session gets Read and only Read, a
+   turn per photograph plus three, a dollar budget, a closed stdin and an
+   environment with every `CLAUDE*` variable stripped. `apply: "serve"` means
+   a build carries no door: a deployed copy probes, gets nothing, and reads
+   as **closed** — which is a state, not a fault.
+
+## Then find out whether it worked
+
+Write, close, reopen, and read: the graph must survive the round trip and
+the persisted log must carry your ops with their authors. The framework's
+own rehearsal (`pnpm smoke`) does exactly this from packed tarballs —
+`theDeploymentShipped` is the verdict to mimic.
+
+## What the check cannot see
+
+- Whether your migration is the RIGHT transform — the chain being unbroken
+  says nothing about the data arriving meaningful. Migrate a copy of real
+  data and read it before shipping the step.
+- Whether the adapter's storage location survives your deployment story
+  (containers with ephemeral disks lose a file adapter's whole point).
+- Whether the export actually round-trips: rehearse import into a fresh
+  deployment, the way the framework's smoke run does — do not assume it.
+
+6. **Serve it, and let an agent in.** `graview serve <entry> --data ./data`
+   puts the store behind HTTP with the op log as the wire; `graview mcp
+   <entry> --remote-url <url>` and `graview apply … --remote-url <url>` are
+   the same commands an agent uses against a folder, now against the server,
+   judged under the seat the request carries. Put `serve` and `mcp` in the
+   app's scripts. The routes are `WIRE`, exported and pinned by a test, and
+   `serveStore({ seatOf })` is where a host reads its own credential —
+   `openRemote({ headers })` carries whatever it asks for.
+
+## The boundary
+
+Anything ONE deployment needs belongs in ship: the op log, the snapshot,
+migrating on open, the wire, a principal on every apply, the seed at first
+install, content steps, and the agent's door. Tenancy, provisioning,
+deploy-to-URL, billing, quotas and fleet upgrades belong to the operator of
+many — a separate service consuming ship like any customer, with its own
+`seatOf` mapping people and keys to principals. The concern table is in
+`@graview/ship`'s README; a third party can stand up their own host from
+it without forking anything.

package/skills/graview-studio/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: graview-studio
+description: Open an app's declaration as a graph in Graview's own interface, change it with ordinary acts, let graview check judge the result before it is applied, migrate a stored graph, and write the declaration back as the files graview create writes.
+---
+
+# Work the declaration in the studio
+
+The declaration — kinds, fields, edges, acts, rules, roles, grants, lenses,
+brand — is itself a graph. `@graview/studio` declares that graph with the
+same `defineNode` an app uses, so a change to the declaration is an act with
+an author, an intent and an inverse, judged by the same checker, undone like
+any other.
+
+## Do this
+
+1. **Open the studio over the app**, in a test, a script or a page:
+
+   ```ts
+   import { createStudio, createStudioLens } from "@graview/studio";
+   const studio = createStudio(app);          // the declaration, as a store
+   ```
+
+   The store's nodes have stable ids: `declared:plot` (not `kind:plot`,
+   which is the layout's name for the district), `field:plot.label`,
+   `edge:plot.tended-by`, `act:tend`, `rule:every-plot-tended`,
+   `role:coordinator`, `grant:2`, `lens:coverage`, `brand`.
+
+2. **Change it with acts**, not by hand:
+
+   ```ts
+   studio.store.apply({ name: "add-field", args: { kind: "declared:plot", label: "soil", type: "enum", required: true, options: ["clay", "loam"] } }, { author: june, intent: "Plots have soil" });
+   studio.store.apply({ name: "add-act", args: { kind: "declared:plot", label: "resize", title: "Resize", writes: ["size"] } });
+   studio.store.apply({ name: "add-rule", args: { kind: "declared:plot", label: "sized", description: "A plot has a size." } });
+   studio.store.apply({ name: "name-repair", args: { rule: "rule:sized", act: "act:resize" } });
+   ```
+
+   The acts: `add-kind`, `rename-kind`, `remove-kind`, `add-field`,
+   `remove-field`, `add-edge`, `remove-edge`, `add-act`, `remove-act`,
+   `add-rule`, `remove-rule`, `name-repair`, `forget-repair`, `add-role`,
+   `grant`, `revoke-grant`, and the derived `edit-<kind>` for every field
+   (a description, an inverse, a title, a lifecycle).
+
+3. **Check before you apply.** `studio.check()` is `graview check` on the
+   declaration as it now stands. `studio.apply()` refuses while there are
+   errors and says which; otherwise it hands back `{ app, migration }` —
+   the migration is `null` when a stored graph needs nothing, else a
+   `{ from, to, title, apply }` to append to the app's migrations (the new
+   app already carries it and the bumped version).
+
+4. **Write it back.** `studio.files({ schemaVar: "gardenSchema" })` is
+   `src/domain/schema.ts`, `mutations.ts`, `invariants.ts` and, with roles,
+   `policy.ts` — the files `graview create` writes. Shape is what a graph
+   carries: an act the studio declared gets a body from what it says
+   (create, connect, sever, write); an act the checkout wrote keeps the
+   checkout's body under the studio's declaration; a rule the studio
+   declared judges nothing until the checkout gives it an `evaluate`. Read
+   the files before you commit them, and keep a hand-written body where the
+   comment says so.
+
+5. **Let an agent propose.** `studio.propose(call, agentPrincipal, intent)`
+   applies under the agent's seat in a batch of its own; `studio.proposals()`
+   lists what stands; `studio.decline(batchId)` undoes one; accepting is
+   applying. In the interface, the trail shows the agent's turn with its
+   undo, like any turn.
+
+6. **Put it on a page.** The studio is an app: mount `studioApp()` with
+   `declarationToGraph(app)` as the seed, and register
+   `createStudioLens(app).View` over `kind` with a title — a place, "What
+   the checker says", one press from anywhere.
+
+## Then find out whether it worked
+
+Run `graview check` on the app the studio applied, and the checkout's own
+verify on the files it wrote. Say what they said.
+
+## What the check cannot see
+
+- Whether a body the studio wrote does what the person meant. It does what
+  the act declares — create, connect, sever, write — and nothing more.
+- Whether a rule the studio declared is right. It judges nothing until the
+  checkout gives it an `evaluate`; the checker sees a rule, not a judgement.
+- Whether a migration is safe for data it has not met. It is computed
+  against the stored graph when it runs; look at the primitives on a copy.
+- Whether the files should replace the checkout's. Read them; a hand-written
+  body is the checkout's to keep.