@dreamboard-games/cli 0.1.30-alpha.19 → 0.1.30-alpha.20

package/dist/internal.js

@@ -10,7 +10,7 @@ import {
   resolveConfig,
   resolveProjectContext,
   shortHash
-} from "./chunk-R6RB4EKH.js";
+} from "./chunk-5PJWUB6W.js";
 import {
   applyWorkspaceCodegen,
   loadManifest,
@@ -19,16 +19,16 @@ import {
   setLatestCompileAttempt,
   updateProjectState,
   writeSnapshot
-} from "./chunk-YRSE5DLH.js";
+} from "./chunk-EJGB3IR7.js";
 import {
   getStoredSession,
   loadGlobalConfig
-} from "./chunk-VWMKJL4A.js";
+} from "./chunk-UI7NWSYA.js";
 import {
   ENVIRONMENT_CONFIGS,
   readJsonFile,
   writeJsonFile
-} from "./chunk-FFO2IJL3.js";
+} from "./chunk-EQNBQVIW.js";
 import "./chunk-2H7UOFLK.js";
 export {
   CONFIG_FLAG_ARGS,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@dreamboard-games/cli",
-  "version": "0.1.30-alpha.19",
+  "version": "0.1.30-alpha.20",
   "description": "Design board games with AI and turn ideas into playable digital prototypes.",
   "type": "module",
   "bin": {

package/release/authoring-release-set.json

@@ -4,7 +4,7 @@
   "packages": {
     "cli": {
       "name": "@dreamboard-games/cli",
-      "version": "0.1.30-alpha.19"
+      "version": "0.1.30-alpha.20"
     },
     "sdk": {
       "name": "@dreamboard-games/sdk",
@@ -34,5 +34,5 @@
     "portable": true
   },
   "packageManager": "pnpm@10.4.1",
-  "releaseSetId": "sha256:94f9e944361da712ec7f0b420643d3690e73b93a2c23d3a893b0f4183a93a847"
+  "releaseSetId": "sha256:a587040081f3664b0c55128b9b52af76f53daaee441d69486a61540c7e107bc8"
 }

package/skills/dreamboard/SKILL.md

@@ -10,14 +10,14 @@ metadata:
 
 ## Goal
 
-Create and iterate on a Dreamboard game locally, then sync authored changes,
-compile, run, and test against the current reducer-native scaffold.
+Create and iterate on a Dreamboard game locally with the Git-native Dreamboard
+CLI, then verify exact commits, run tests, and use the local dev host.
 
 ## Prereqs
 
 - Dreamboard CLI installed and available as `dreamboard`
   Install with `npm install -g dreamboard`
-- Authenticated via `dreamboard login`
+- Authenticated via `dreamboard auth login`
 
 ## Buliding Your First Game
 See [tutorials/building-your-first-game.md](references/building-your-first-game.md)
@@ -60,18 +60,25 @@ The current scaffold centers on these files:
 
 Use the commands for different kinds of state:
 
-- `dreamboard sync`
-  Upload local authored changes and advance the remote authored head. Run this after editing `rule.md`, `manifest.json`, or authored source files that should be part of the next remote build.
-- `dreamboard compile`
-  Compile the current remote authored head. Run this after `sync`, or re-run it after a failed compile when you have not made new authored edits.
-- `dreamboard pull`
-  Reconcile remote authored changes into the current workspace. Run this when someone else advanced the remote authored head or `dreamboard status` shows authored state `behind` or `diverged`.
+- `dreamboard project create <slug> --description <text>`
+  Create a project workspace and configure its Git remote.
+- `dreamboard project clone <project>`
+  Clone an existing project repository.
+- `dreamboard project status --commit <rev> [--wait]`
+  Read server state for one exact commit.
+- `dreamboard verify --commit <rev>`
+  Verify one exact commit from a detached worktree.
+- `dreamboard test`
+  Regenerate derived test artifacts as needed and run reducer, remote, or browser tests.
+- `dreamboard dev [--from-scenario <id>]`
+  Start the local dev host for browser validation.
 
 Quick rule:
 
-- edited files locally: `dreamboard sync` then `dreamboard compile`
-- compile failed but you have not edited files since: `dreamboard compile` again
-- remote authored head moved: `dreamboard pull` first
+- edited files locally: commit them with Git and push the branch
+- need server readback: `dreamboard project status --commit <rev> --wait`
+- need exact local proof: `dreamboard verify --commit <rev>`
+- need scenario proof: `dreamboard test`
 
 ## Workflow
 
@@ -79,23 +86,22 @@ Use this order by default:
 
 1. Write or revise `rule.md`.
 2. Align `manifest.json` to the rules.
-3. Run `dreamboard sync`.
-4. Implement reducer state, phases, actions, and views in `app/`.
-5. Implement the playable UI in `ui/App.tsx`.
-6. Run `dreamboard compile`.
-7. Generate test artifacts with `dreamboard test generate`.
-8. Run scenarios with `dreamboard test run`.
-9. Validate the local runtime with `dreamboard run`.
+3. Implement reducer state, phases, actions, and views in `app/`.
+4. Implement the playable UI in `ui/App.tsx`.
+5. Commit and push authored changes with Git.
+6. Run `dreamboard project status --commit HEAD --wait`.
+7. Run `dreamboard verify --commit HEAD`.
+8. Run scenarios with `dreamboard test`.
+9. Validate the local runtime with `dreamboard dev`.
 10. For agent-built games, run `dreamboard dev` and verify the browser UI before handoff. Use Playwright to open the dev host, check that the plugin iframe renders without console errors, and click a primary interaction such as selecting a playable hand card. Reducer scenarios alone are not enough when the game has an interactive UI.
 
 ## Guardrails
 
 - `manifest.json` and `rule.md` are the source of truth for scaffolding.
-- Run `dreamboard sync` after authored changes to keep generated files and the remote authored head in sync.
-- `dreamboard pull` reconciles authored divergence into the current workspace.
-- `dreamboard compile` is separate from authored sync; failed compiles do not mean the workspace needs a pull or another sync unless you changed authored files again.
-- Use `dreamboard status` to distinguish authored sync from compile health before deciding whether the next command should be `sync`, `compile`, or `pull`.
-- Re-run `dreamboard test generate` after runtime-shape changes in `manifest.json` or `app/`.
+- Use Git for source-control state transitions; Dreamboard does not stage,
+  commit, pull, merge, branch, or push for you.
+- Use `dreamboard project status --commit <rev>` for server state, not local Git status.
+- Run `dreamboard test` after runtime-shape changes in `manifest.json` or `app/`; it regenerates derived test artifacts automatically.
 - Keep reducer-owned UI data in views; do not reintroduce the old `shared/ui-args.ts` pattern in new scaffolds.
 - When a game exposes clickable hands, markets, boards, or prompts, prove the same interaction works through `dreamboard dev` in a browser. A direct scenario submission can pass even when the rendered surface does not collect the input.
 - For interactive card hands, render generated surfaces such as `handSurface.Hand` and `handSurface.Card` consistently. Do not swap a surface card for a raw `Card` or custom tile based on `me.canAct`; the surface primitive is responsible for disabling unavailable interactions.
@@ -124,7 +130,3 @@ Do not edit generated or framework-owned files such as:
 
 ## Offical Documentation
 Visit https://dreamboard.games/docs
-
-## Framework Feedback
-
-Use `feedback.md` in the game project root to record framework issues, missing features, or workflow friction. Include reproduction steps, expected behavior, and actual behavior when possible.

package/skills/dreamboard/references/building-your-first-game.md

@@ -34,12 +34,12 @@ By the end of the tutorial you will have:
 ## Prerequisites
 
 - Dreamboard CLI installed: `npm install -g dreamboard`
-- authenticated with `dreamboard login`
+- authenticated with `dreamboard auth login`
 
 ## 1. Create the workspace
 
 ```bash
-dreamboard new race-to-ten --description "A tiny scoring game with one shared die"
+dreamboard project create race-to-ten --description "A tiny scoring game with one shared die"
 cd race-to-ten
 ```
 
@@ -138,16 +138,17 @@ This game needs player-count metadata and one shared die.
 }
 ```
 
-Run:
+Commit and push the authored source with Git, then wait for the server to
+observe and verify the exact commit:
 
 ```bash
-dreamboard sync
-dreamboard compile
+git add .
+git commit -m "Build Race to Ten"
+git push -u origin main
+dreamboard project status --commit HEAD --wait
+dreamboard verify --commit HEAD
 ```
 
-`dreamboard sync` refreshes generated contracts from authored files.
-`dreamboard compile` builds the current authored head.
-
 ## 4. Define the reducer contract
 
 Open `app/game-contract.ts` and replace the empty schemas with the state the
@@ -471,23 +472,22 @@ export default defineScenario({
 });
 ```
 
-Generate artifacts and run the test suite:
+Run the test suite:
 
 ```bash
-dreamboard test generate
-dreamboard test run
+dreamboard test
 ```
 
 ## 10. Run the game locally
 
-Use the local runtime to verify the same flow manually:
+Use the local dev host to verify the same flow manually:
 
 ```bash
-dreamboard run
+dreamboard dev
 ```
 
-If you edit `rule.md` or `manifest.json`, run `dreamboard sync` again before
-continuing.
+If you edit `rule.md` or `manifest.json`, commit and push the changes before
+running commit-scoped build, preview, release, or remote test commands.
 
 ## Where to go next
 

package/skills/dreamboard/references/cli.md

@@ -5,21 +5,21 @@
 
 Reference for Dreamboard CLI workflows and commands.
 
-Dreamboard CLI manages the authored workspace loop: authenticate, create or
-clone a game, sync authored changes, compile, run, and test.
+Dreamboard CLI manages the Git-native authored workspace loop: authenticate,
+create or clone a project, verify exact commits, build or preview pushed
+commits, run a local dev host, and test reducer scenarios.
 
 ## Responsibility
 
 Use the CLI for:
 
 - authenticating the current machine
-- creating or cloning game workspaces
-- syncing authored files to the remote authoring head
-- compiling the current authored head
-- inspecting local versus remote state
-- pulling remote authored changes into the workspace
-- starting or observing playable sessions
-- generating and running reducer-native tests
+- creating or cloning project workspaces
+- inspecting server state for an exact commit
+- verifying an exact commit from a detached worktree
+- building, previewing, and publishing pushed commits
+- starting the local dev host
+- running reducer, remote, or browser tests
 
 ## Install targets
 
@@ -27,73 +27,74 @@ Use the published package for normal game work:
 
 ```bash
 npm install -g dreamboard
-dreamboard login
+dreamboard auth login
 ```
 
 ## Command flow
 
 Use this sequence for the normal authored loop:
 
-1. `dreamboard login`
-2. `dreamboard new ...` or `dreamboard clone ...`
+1. `dreamboard auth login`
+2. `dreamboard project create ...` or `dreamboard project clone ...`
 3. edit `rule.md`, `manifest.json`, and authored source files
-4. `dreamboard sync`
-5. `dreamboard compile`
-6. `dreamboard run` or `dreamboard start`
-7. `dreamboard test generate`
-8. `dreamboard test run`
-
-When the remote authored head moves first, run `dreamboard pull` before the
-next sync or compile. Use `dreamboard status` to decide whether the workspace is
-ahead, behind, or diverged.
+4. commit with Git and push to the configured remote
+5. `dreamboard project status --commit <rev> --wait`
+6. `dreamboard verify --commit <rev>`
+7. `dreamboard test`
+8. `dreamboard build --commit <rev>`
+9. `dreamboard preview --commit <rev>`
 
 ## Workspace commands
 
 | Command | Use it for |
 | --- | --- |
-| `dreamboard login` | Open browser login and store a refreshable session |
-| `dreamboard new <slug> --description "..."` | Create a new game and scaffold a local workspace |
-| `dreamboard clone <slug>` | Clone an existing game into a new local workspace |
-| `dreamboard sync` | Upload authored changes and refresh scaffolded files |
-| `dreamboard compile` | Compile the current remote authored head |
-| `dreamboard status` | Compare local authored and compile state with remote |
-| `dreamboard pull` | Reconcile remote authored changes into the workspace |
+| `dreamboard auth login` | Open browser login and store a refreshable session |
+| `dreamboard auth status` | Show the current authenticated session |
+| `dreamboard project create <slug> --description "..."` | Create a project, scaffold a local workspace, and configure Git |
+| `dreamboard project clone <project>` | Clone an existing project repository |
+| `dreamboard project status --commit <rev>` | Show server state for one exact commit |
+| `dreamboard verify --commit <rev>` | Verify one exact commit in a detached worktree |
 
 ```bash
-dreamboard new race-to-ten --description "A tiny scoring game"
-dreamboard sync
-dreamboard compile
-dreamboard status --json
+dreamboard auth login
+dreamboard project create race-to-ten --description "A tiny scoring game"
+git add .
+git commit -m "Create Race to Ten"
+git push -u origin main
+dreamboard project status --commit HEAD --wait
+dreamboard verify --commit HEAD
 ```
 
-## Session commands
+## Commit commands
 
-Use session commands after you have a successful compile for the current
-authored head.
+Use commit commands after the commit has been pushed to the configured Git
+remote.
 
 | Command | Use it for |
 | --- | --- |
-| `dreamboard run` | Start or resume a playable session and observe it from the CLI |
-| `dreamboard start` | Start a fresh session and open it in the browser |
+| `dreamboard test` | Run reducer, remote, or browser tests |
+| `dreamboard dev [--from-scenario <id>]` | Start the local project dev host |
+| `dreamboard build --commit <rev>` | Create a server build for a pushed commit |
+| `dreamboard preview --commit <rev>` | Create a preview for a pushed commit |
+| `dreamboard release publish --commit <rev> --yes` | Publish an explicit release |
+| `dreamboard release current` | Show the current release pointer |
 
 ```bash
-dreamboard run
-dreamboard run --players 4 --seed 1337
-dreamboard run --scenario path/to/scenario.json
-dreamboard start --players 2
+dreamboard test
+dreamboard dev
+dreamboard build --commit HEAD
+dreamboard preview --commit HEAD
 ```
 
-`dreamboard run` reuses the previous active session by default. Use
-`--new-session` when you want a fresh session instead.
-
 ## Test commands
 
 Use the scaffolded reducer-native test workspace for repeatable game assertions.
 
 ```bash
-dreamboard test generate
-dreamboard test run
-dreamboard test run --scenario test/scenarios/player-two-wins.scenario.ts
+dreamboard test
+dreamboard test --scenario test/scenarios/player-two-wins.scenario.ts
+dreamboard test --runner browser
+dreamboard test --runner remote --commit HEAD
 ```
 
 ## Start local server

package/skills/dreamboard/references/quickstart.md

@@ -14,13 +14,13 @@ npm install -g dreamboard
 Log in:
 
 ```bash
-dreamboard login
+dreamboard auth login
 ```
 
-Create a game:
+Create a project:
 
 ```bash
-dreamboard new my-game --description "A trick-taking card game"
+dreamboard project create my-game --description "A trick-taking card game"
 cd my-game
 ```
 
@@ -30,25 +30,27 @@ Edit `rule.md` and `manifest.json`. Use
 [Manifest authoring](./manifest-authoring.md) for the manifest
 schema.
 
-Regenerate scaffolded files from your authored source:
+Commit and push your authored source with Git:
 
 ```bash
-dreamboard sync
+git add .
+git commit -m "Create my game"
+git push -u origin main
 ```
 
-Compile the current authored head:
+Check server state for the pushed commit:
 
 ```bash
-dreamboard compile
+dreamboard project status --commit HEAD --wait
 ```
 
-Run the game locally:
+Verify the exact commit:
 
 ```bash
-dreamboard run
+dreamboard verify --commit HEAD
 ```
 
-Start a local server to play the compiled game
+Start a local server to play the project:
 
 ```bash
 dreamboard dev
@@ -56,9 +58,10 @@ dreamboard dev
 
 Useful follow-up commands:
 
-- `dreamboard pull` reconciles authored changes when the remote has advanced.
-- `dreamboard status` compares local and remote state.
-- `dreamboard clone <game-slug>` pulls an existing game into a local workspace.
+- `dreamboard project clone <project>` clones an existing project repository.
+- `dreamboard test` runs reducer, remote, or browser tests.
+- `dreamboard build --commit HEAD` creates a server build for a pushed commit.
+- `dreamboard preview --commit HEAD` creates a preview for a pushed commit.
 
 For a concise command reference, see [CLI](./cli.md).
 

package/skills/dreamboard/references/testing.md

@@ -34,26 +34,26 @@ be edited manually.
 
 ## Command flow
 
-Generate reducer-native test artifacts:
+Run all scenarios:
 
 ```bash
-dreamboard test generate
+dreamboard test
 ```
 
-Run all scenarios:
+Run one scenario:
 
 ```bash
-dreamboard test run
+dreamboard test --scenario test/scenarios/win-the-game.scenario.ts
 ```
 
-Run one scenario:
+Run browser-backed tests:
 
 ```bash
-dreamboard test run --scenario test/scenarios/win-the-game.scenario.ts
+dreamboard test --runner browser
 ```
 
-Re-run `dreamboard test generate` after changes that affect the runtime shape of
-the game, including:
+`dreamboard test` regenerates reducer-native artifacts automatically when
+changes affect the runtime shape of the game, including:
 
 - `manifest.json`
 - reducer code under `app/`
@@ -232,7 +232,7 @@ then: ({ phase, history, expect, publicState }) => {
 
 If the generated test artifacts no longer match the compiled game, refresh them:
 
-- `dreamboard test generate`
+- `dreamboard test`
 
 Common symptoms:
 
@@ -244,6 +244,6 @@ Common symptoms:
 
 This page documents the scaffolded reducer-native test workspace.
 
-If you also use `dreamboard run` for manual debugging or operational inspection,
+If you also use `dreamboard dev` for manual debugging or operational inspection,
 treat that as a separate workflow. It is useful for ad hoc runtime exploration,
 but it is not the primary authored test surface for a new Dreamboard project.