dreamboard（dreamboard 命令行）

Dreamboard CLI

Goal

Create and iterate on a Dreamboard game locally, then sync authored changes, compile, run, and test against the current reducer-native scaffold.

Prereqs

• Dreamboard CLI installed and available as dreamboard Install with npm install -g dreamboard
• Authenticated via dreamboard login

Source Of Truth

Use the generated reference files in references/ as the detailed reference set. They are synced from the public docs with pnpm --dir apps/dreamboard-cli run sync:skill-docs.

• Quickstart: references/quickstart.md
• Tutorial: references/building-your-first-game.md
• Rules: references/rule-authoring.md
• Manifest: references/manifest-authoring.md
• Reducer: references/reducer.md
• Game interface: references/game-interface.md
• Testing: references/testing.md

Current Scaffold

The current scaffold centers on these files:

• authored source: rule.md, manifest.json
• reducer: app/game-contract.ts, app/game.ts, app/phases/*.ts, app/setup-profiles.ts
• UI: ui/App.tsx
• tests: test/bases/*.base.ts, test/scenarios/*.scenario.ts, test/testing-types.ts

Command Flow

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.

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

Workflow

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.

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/.
• Keep reducer-owned UI data in views; do not reintroduce the old shared/ui-args.ts pattern in new scaffolds.

Editable Surface

Edit:

• rule.md
• manifest.json
• app/game-contract.ts
• app/game.ts
• app/phases/*.ts
• app/setup-profiles.ts
• ui/App.tsx
• test/bases/*.base.ts
• test/scenarios/*.scenario.ts

Do not edit generated or framework-owned files such as:

• app/index.ts
• shared/manifest-contract.ts
• shared/generated/ui-contract.ts
• ui/index.tsx
• test/generated/*

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.