@xgamesfun/xcore 0.2.1 → 0.3.0

package/lib/server/contract.mjs

@@ -82,7 +82,10 @@ export const NODE_REFUSED = Object.freeze([
 /**
  * env.GF, the platform binding (a Workers RPC service, entrypoint GameServices; locally ./gf-local.js). Every answer is
  * {ok: true, …} or {ok: false, code, why}; a refusal is an answer, never a throw.
- *   verifyPlayer(token)                  → {ok, sub, wallet | null, x: {id, handle} | null, lvl, exp (unix s)}
+ *   verifyPlayer(token)                  → {ok, sub, wallet | null, x: {id, handle} | null, lvl, exp (unix s),
+ *                                           banned?: {kind: 'ban' | 'hide', until: ms | null} | null}
+ *                                           (banned: the creator's ban on the player from the console; a token made
+ *                                           before the ban still verifies, so a server refuses kind 'ban' itself)
  *   saves.get(player, key = 'main')      → {ok, value | null, updatedAt}
  *   saves.put(player, key, value)        → {ok, bytes}                 (a JSON value, 64 KB; 16 keys a player)
  *   saves.delete(player, key)            → {ok, deleted}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xgamesfun/xcore",
-  "version": "0.2.1",
+  "version": "0.3.0",
   "description": "xgames.fun from the command line: bring a web game you already made, check it as xgames.fun hosts it, give it a backend and a Solana economy, and publish it at a link anyone can play.",
   "keywords": [
     "game",
@@ -56,7 +56,7 @@
     "test": "node --test \"tests/**/*.test.mjs\""
   },
   "dependencies": {
-    "@xgamesfun/solana": "0.25.0",
+    "@xgamesfun/solana": "0.25.1",
     "esbuild": "0.28.2",
     "playwright-core": "1.63.0"
   },

package/skills/bring-your-own-game/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bring-your-own-game
-description: Help someone bring a web game they already made without this kit (plain HTML/JS, or a Vite, Next.js static export, Astro, SvelteKit, Nuxt, Create React App or Parcel project) to xgames.fun - adopt it, fix what does not fit the hosting (server-side rendering, paths from the root, CDN scripts and fonts, undeclared backend origins, secrets, size limits), check it with the page check, connect their own backend or a server/ Worker, add a loot economy, and publish it. Use when the person has an existing game folder or repository and wants web3, xgames.fun hosting, or the kit's checks for it; never rebuild such a game through the creation loop.
+description: Help someone bring a web game they already made without this kit (plain HTML/JS, or a Vite, Next.js static export, Astro, SvelteKit, Nuxt, Create React App or Parcel project) to xgames.fun - adopt it, fix what does not fit the hosting (server-side rendering, paths from the root, CDN scripts and fonts, undeclared backend origins, secrets, size limits), check it with the page check, connect their own backend or a server/ Worker, add a loot economy, review what a cheater gets from it, and publish it. Use when the person has an existing game folder or repository and wants web3, xgames.fun hosting, or the kit's checks for it; never rebuild such a game through the creation loop.
 ---
 
 # Bring your own game
@@ -12,7 +12,7 @@ here is `@xgamesfun/xcore` (the `xcore` command: `npx -y @xgamesfun/xcore …`,
 @xgamesfun/xcore`; never a bare `npx xcore`, which is another package), which needs no kit; with the kit, its MCP tools
 (`gamesfun_adopt` and the rest, named below) do the same.
 
-The order: **adopt → fix the list → check → (backend) → (economy) → publish when they ask.**
+The order: **adopt → fix the list → check → (backend) → (economy) → (review, when it pays) → publish when they ask → (review --live).**
 
 ## 1. Adopt
 
@@ -57,6 +57,17 @@ stays on their host as a backend (README, "A game with its own Node server"). Su
 Never edit their build tool's output by hand (it is made again on every build): change the source or the config.
 Adopt again after the fixes; the list should be empty.
 
+**Full screen.** Most players meet a game in a post on X or on a phone, where it first shows in a small frame. When adopt
+warns that the game has no way to go full screen, offer the person a button for it (their game, their call): a small
+button in a corner of the first screen, big enough for a thumb, that calls `GamesFun.fullscreen()` from the click
+(`gamesfun.js`, loaded by `xcore add signin`; Godot `await GamesFun.fullscreen()`; Unity `Screen.fullScreen`).
+Pressed again it comes back. It answers `{on, how}`: on xgames.fun the page around the game goes full screen, or fills
+the screen in an app's own browser (X's on a phone among them); on the game's own link the browser does; in a frame
+that allows none (a post on X on a computer) the game opens in a tab of its own (`how: 'tab'`); an iPhone's Safari has
+no full screen for a page (`how: 'none'`): there the button can hide, or say "Add to Home Screen".
+`GamesFun.onFullscreen(on => …)` follows it (Esc, the browser's own controls). A game that goes full screen already
+(its own button, or its engine's) needs nothing.
+
 ## 3. Check
 
 ```bash
@@ -139,8 +150,9 @@ out of `.dev.vars` or repeat it.
 
 Design it so a cheater gains little (docs/SERVER.md, "How much your server can check" and "Who gets paid"): never send
 the page a run's whole seed up front (reveal randomness as the run goes); give slack per second, not per request; one
-open run per player; pay only proven wallets (the page calls `gf.loot.link()` once; a wallet sign-in needs none);
-a wallet is free, so for rewards worth farming set `VOUCHERS.payOnly` to `'x'` and give every grant a `perDay` total.
+open run per player; pay only proven wallets (the page calls `gf.loot.link()` once; a player whose xgames.fun account
+has a wallet linked needs none); a wallet is free, so for rewards worth farming set `VOUCHERS.payOnly` to `'x'` (X only)
+or `'account'` (X or Google; a Google account is easier to make) and give every grant a `perDay` total.
 
 A page alone can't prove a score or a win: anyone can change it in the console. A leaderboard that must be fair is
 one the server owns: `env.GF.scores.setup(board, {writer: 'server'})` refuses the page's submits to it (a pattern,
@@ -152,7 +164,35 @@ your server can check". A bounded result earns small capped amounts; entry fees
 replayed one. Without a server,
 offer what the player pays for or the chain decides (a shop, boxes, raffles, staking, perks), and say why.
 
-## 6. Publish (only when they ask)
+## 6. Review (a game whose server pays results)
+
+Before publishing a game that pays results, read it as a cheater would:
+
+```bash
+xcore review <folder>           # evidence/review-N/review.md and review.json; exits 1 on a high finding
+xcore loot review               # the economy's part alone (@xgamesfun/solana's xsolana_review)
+```
+
+- **Fix every high finding** (a `PAY.check` that pays from the request alone, a route anyone can call, a seed in the
+  page, `.dev.vars` in git…), and run it again. Mediums are the person's to decide with you: say each one plainly.
+- **Declare `trust` honestly** on every grant a voucher pays: `"decides"` (the server runs the game; the page sends
+  only inputs), `"replays"` (the server runs the page's inputs again) or `"bounds"` (the page plays and reports; the
+  server checks its clock, order and caps). It is what `PAY.check` really does, not what you hope it does: a server
+  that times a run the page simulated is `bounds`, whatever it is called. (The field needs the `@xgamesfun/solana`
+  that has `review`: 0.25.0's `xcore loot check` refuses it, so with that one leave it out and still tell the person
+  the level in words.)
+- **Tell the person**, in plain words, from the end of `review.md`: for each paid route, the level it uses, what a
+  cheater gets (a bounded result pays a script that waits and reports, without playing; a decided one pays what a bot
+  that plays well wins), and what the stronger level would cost to build (replaying: a deterministic step and about
+  3 ms of CPU a second played; deciding: the rules moved to the server, a request each step). Let them choose: a
+  smaller prize and tighter caps, or the stronger level. Never call a bounded result safe.
+
+After publishing, `xcore review <folder> --live` asks the published game as a stranger (no sign-in, a forged one;
+nothing it sends can spend or sign) and checks its voucher key and economy against the folder. Under `xcore dev`,
+give its address: `--live http://127.0.0.1:<port>/game/`. `xcore publish` reminds you when the economy or `server/`
+changed since the last review.
+
+## 7. Publish (only when they ask)
 
 ```bash
 xcore publish <folder> --check  # the offline part: what goes up, what refuses it