@qaping/cli 0.1.0 → 0.1.1

package/bin/qaping

@@ -183,12 +183,21 @@ function cmdPublishBuild(argv) {
     .main(argv.slice(1), { brandCommand: "qaping publish-build", nextStepToolName: "qaping_playtest" });
 }
 
+function cmdPublish(argv) {
+  // WEB games: their "build" is a static directory, hosted (not zipped) — the
+  // kit's hosted-draft publisher, brand-seamed like publish-build above. The
+  // printed URL files as `url` on qaping_playtest with NO platform field.
+  return require(path.join(resolveKitDir(), "harness", "publish.js"))
+    .main(argv.slice(1), { brandCommand: "qaping publish" });
+}
+
 const HELP = `qaping — automatic QA for your game: real human playtesters, driven by your coding agent
 
 usage:
   qaping setup [claude-code|cursor|codex] [--force]
   qaping remove [--client <c>]        remove qaping's MCP entries, skill and rule
   qaping publish-build <game.zip> --platform windows|macos
+  qaping publish <built-dir>          host a WEB game's built output (prints the URL to file with)
   qaping wait <ping_id> [--timeout <seconds>]
   qaping whoami
   qaping version
@@ -202,6 +211,7 @@ function route(cmd) {
   if (cmd === "remove" || cmd === "uninstall") return "remove";
   if (cmd === "wait" || cmd === "whoami") return "vendor";
   if (cmd === "publish-build") return "publish-build";
+  if (cmd === "publish") return "publish";
   return "unknown";
 }
 
@@ -217,6 +227,7 @@ function main() {
       // vendored default (the stock mount's wait) is not on /api/mcp/qaping.
       case "vendor": return process.exit(spawnVendor(argv[0] === "wait" ? [...argv, "--wait-tool", "qaping_wait"] : argv));
       case "publish-build": return void cmdPublishBuild(argv);
+      case "publish": return void cmdPublish(argv);
       default:
         console.error(HELP);
         process.exit(1);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@qaping/cli",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "qaping: automatic QA for your game. Your coding agent authors and maintains the QA plan, ships each patch's build to real human playtesters, and reports what broke.",
   "keywords": [
     "qaping",

package/skill/qaping/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: qaping
-description: Run automatic QA for a game repo through qaping — real human playtesters play the developer's builds on their own hardware, and the agent runs the whole loop. Use when the user says "set up QA for my game", "run QA on this patch", "did this patch break anything", "playtest my game" or "playtest this build", or asks for regression checks, patch verification, or human playtesting of a game. Covers both halves of the product - authoring and maintaining QA-PLAN.md in the game repo, and the per-patch run (read the diff, build, publish-build, file qaping_playtest rounds, report on the PR, file issues, promote settled checks into repo code tests). Do not use for web apps, websites, or UI review of anything that is not a game build — the qaping tools test game builds only.
+description: Run automatic QA for a game repo through qaping — real human playtesters play the developer's builds on their own hardware, and the agent runs the whole loop. Use when the user says "set up QA for my game", "run QA on this patch", "did this patch break anything", "playtest my game" or "playtest this build", or asks for regression checks, patch verification, or human playtesting of a game. Covers both halves of the product - authoring and maintaining QA-PLAN.md in the game repo, and the per-patch run (read the diff, build, publish-build, file qaping_playtest rounds, report on the PR, file issues, promote settled checks into repo code tests). Browser-playable web GAMES count as games (they file as web rounds — url only, no platform). Do not use for web apps, websites, or UI review of anything that is not a game — the qaping tools test games only.
 ---
 
 # qaping — the QA loop for a game repo
@@ -38,9 +38,20 @@ the build.
 2. Ask the dev ONCE for their build command (the one command that produces a
    shippable build) and which platforms they ship; record both in the plan's
    frontmatter so every future run can build without asking again.
-3. Author `QA-PLAN.md` at the repo root, format per `docs/QA-PLAN-FORMAT.md`
-   (shipped with this package — read it first). Order checks critical-path
-   first, then game-specific ones:
+3. Author `QA-PLAN.md` at the repo root in EXACTLY this format (self-contained
+   here — do not go looking for other docs). Plan frontmatter (YAML at the very
+   top): `game`, `build_command` (the ONE shippable-build command), `platforms:
+   [windows|macos|ios|web]` (`web` = a browser-playable game — its "build" is a
+   static directory, not a zip), optional `input` (hardware; default
+   keyboard+mouse, or touch for a mobile-web game).
+   Then one `##` section per check — the heading is the check's short name —
+   opening with a fenced yaml block of exactly `id` (stable slug, never
+   renamed), `rung: human | code`, `origin` ("authored" or the round id that
+   last changed it), `last_verified` (date or build tag), followed by the steps
+   as numbered prose a playtester who has never seen the game can follow (they
+   become the round's instructions verbatim). A `rung: code` check keeps its
+   prose and adds one `test:` line naming the repo test that asserts it. Order
+   checks critical-path first, then game-specific ones:
    1. the game boots to the main menu
    2. a previous-version save loads
    3. the first 15 minutes play clean on the declared input hardware
@@ -62,12 +73,19 @@ the build.
 1. **Select.** Read the diff (or PR). Pick the checks it can plausibly affect,
    plus the always-run criticals (the critical-path block above). Tell the user
    which checks run and why.
-2. **Build** via the recorded build command; zip the result.
-3. **Ship:** `qaping publish-build <game.zip> --platform windows|macos` →
-   prints a `/b/<slug>` URL (temporary hosting; filing a playtest extends the
-   build through the round; each publish mints a NEW URL). A store-delivered
-   game files with its Steam store page, TestFlight public link, or App Store
-   page as `url` instead.
+2. **Build** via the recorded build command; zip the result (native) or keep
+   the built static directory (web).
+3. **Ship**, by delivery: NATIVE uploads — `qaping publish-build <game.zip>
+   --platform windows|macos` → prints a `/b/<slug>` URL (temporary hosting;
+   filing a playtest extends the build through the round; each publish mints a
+   NEW URL). Store-delivered games file with their Steam store page, TestFlight
+   public link, or App Store page as `url`. WEB games — host the built output
+   at a public URL: the dev's own hosting if they have it, else
+   `qaping publish <built-dir>` prints a hosted URL. Localhost never works —
+   players open the link on their own devices.
+   When filing a WEB game: send `url` + `est_minutes` and OMIT `platform`
+   entirely (platform values are for native builds; a web round is claimed by
+   players in their own browser, phones included).
 4. **File** ONE `qaping_playtest` per batch of human checks a single session
    can cover, `est_minutes` an honest sum of the steps — the service accepts
    5–30 minutes (10 is the standard session; outside that range the filing is