gamealgo-cli 0.3.8 → 0.4.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gamealgo-cli",
-  "version": "0.3.8",
+  "version": "0.4.1",
   "description": "GameAlgo command-line client for AI agents and game developers",
   "repository": {
     "type": "git",

package/skills/gamealgo/SKILL.md

@@ -20,10 +20,11 @@ Run commands from the game repository that owns the integration. Before any game
 When the user asks what GameAlgo can do, asks for ongoing iteration, or names a broad optimization goal:
 
 1. Run `gamealgo optimize list --json` to load the complete current task catalog from the Server.
-2. Treat the result as an unranked capability catalog. Do not claim that a task is recommended or ready until its prerequisites have been checked against the current game.
-3. Once the user selects a task, or their request clearly identifies one, run `gamealgo optimize get <task-id> --json`.
-4. For each topic named in the task's `docs` field, run `gamealgo docs <topic> --list --json`, then read the sections relevant to the selected task with `gamealgo docs <topic> --section <section-id>` before implementation.
-5. Follow the returned `agentSteps` and use `deliverables` as the completion checklist.
+2. When making a recommendation for the current game, run `gamealgo diagnosis --json` as well. It returns the same structured competition, monetization, and retention diagnosis used by the dashboard. If it is unavailable, treat the diagnosis as an unmet prerequisite rather than fabricating a conclusion; it is available only to account-verified Maker games.
+3. Treat the result as an unranked capability catalog. Do not claim that a task is recommended or ready until its prerequisites have been checked against the current game.
+4. Once the user selects a task, or their request clearly identifies one, run `gamealgo optimize get <task-id> --json`.
+5. For each topic named in the task's `docs` field, run `gamealgo docs <topic> --list --json`, then read the sections relevant to the selected task with `gamealgo docs <topic> --section <section-id>` before implementation.
+6. Follow the returned `agentSteps` and use `deliverables` as the completion checklist.
 
 Do not run every catalog task in sequence. Complete the selected task and report unmet prerequisites instead of manufacturing missing data.
 
@@ -33,7 +34,7 @@ Classify the requested work by the actions it requires, not only by the user's t
 
 Use each topic's section list as the router. Read the whole topic only when the task genuinely spans most of it; when that is necessary, load one full topic per tool call. If any tool marks documentation output as truncated, treat it as incomplete, retrieve the missing sections, and do not infer that unseen guidance is absent or switch workflows based on the partial output.
 
-- SDK installation, identity, lifecycle, telemetry, attribution, advertising, or purchase work: run `gamealgo integration get-plan --environment <domestic|overseas> --platform <ios|android|maker|rest> --json`, then list the `sdk-integration` sections and read the relevant shared and platform-specific sections.
+- SDK installation, identity, lifecycle, telemetry, attribution, advertising, or purchase work: run `gamealgo integration get-plan --environment <domestic|overseas> --platform <ios|android|maker|web> --json`, then list the `sdk-integration` sections and read the relevant shared and platform-specific sections.
 - Calling or changing a concrete public SDK function: additionally run `gamealgo docs api <function> --platform <platform>` for each affected function. Never infer one platform's API from another.
 - Adding or changing events: additionally run `gamealgo events list --days 30 --json` before defining fields or names.
 - Querying an existing dashboard or report: read `gamealgo docs reports --section report-query` plus the section that defines the relevant metric or template. Creating, changing, previewing, or publishing Report Packs, charts, report SQL, or business metrics: list the `reports` sections and read every section affected by the change before interpreting data or editing definitions.
@@ -46,7 +47,17 @@ For `report validate`, `report manifest`, `report preview`, and JSON `report res
 
 When changing an existing Report Pack, run `gamealgo report pull --out <working-pack.json>` before editing and use that current published Pack as the baseline. Do not start from a remembered or stale local copy. Run `gamealgo events diff --pack <working-pack.json>` after defining the Pack events; if it reports missing fields, type conflicts, or blocked/deprecated events, inspect the actual game call sites and prepare real business descriptions rather than inventing catalog text from field names. The diff is read-only and does not authorize `events apply` or event activation.
 
-Validate with the compact default output, then preview every chart or group affected by the change without querying unrelated tabs. A report query must explicitly select a tab, group, or chart. A globally unique bare chart id is accepted; if the Server returns `ambiguous_chart_id`, use its candidate ids and the local Pack structure to retry without asking the developer to choose an internal chart id. Before applying event metadata or publishing the Pack, show the exact changes and impact unless the developer already authorized them. After publishing, pull the effective Pack again and verify the expected manifest or report result.
+Validate with the compact default output, then use `report preview` to inspect v2 validation and generated Dataset SQL without running a warehouse query. After publishing, verify only the affected tab, group, or View with `report result`; do not query unrelated tabs. A report result request must explicitly select a tab, group, or chart/View. A globally unique bare id is accepted; if the Server returns an ambiguity error, use its candidate ids and the local Pack structure to retry without asking the developer to choose an internal id. Before applying event metadata or publishing the Pack, show the exact changes and impact unless the developer already authorized them. After publishing, pull the effective Pack again and verify the expected manifest and materialized result state.
+
+### Use Report Pack v2 For New Work
+
+New, validated, previewed, or published Report Packs must declare `schemaVersion: 2`. Unversioned v1 Packs may still be pulled and queried during migration, but they are read-only; do not edit them in place, pass them to a write command, or add v2 branches to their Report/Chart model. v2 uses independent `datasets`, inline `groups[].views`, `tabs`, and optional `advancedQueries`; it has no top-level `reports` or `charts`, no `groups[].standard`, and no author-managed Pack version.
+
+An ordinary v2 Dataset must read only `adn.dwd_gamealgo_events_enriched_di`, include `dt` in its output grain, and be independently computable for each natural day. Before selector filtering, each `datasetFingerprint × platform × dt` must remain at or below 100 rows and 128 KiB. Estimate the output cardinality from every `groupBy` dimension before publishing. If it may exceed either limit, reduce or bucket dimensions, split the business question, or move it into `advancedQueries`; a table View, front-end selector, or `dataset.limit` does not bypass the ordinary limit.
+
+Keep ratio and average components as additive Dataset columns and calculate the final value in the View after range aggregation. For example, materialize `wins` and `attempts`, then define `win_rate = wins / attempts` in `groups[].views[].data.metrics`. Each View references exactly one Dataset. A selector switch is a local View recalculation and must not be modeled as a new warehouse request.
+
+Use `gamealgo report result` to read an existing ordinary v2 materialization for an explicit date range and scope. It never starts a DW query. Use `gamealgo report advanced run --query-id <id> --platform <platform> --from <date> --to <date>` only when an explicit high-dimensional or non-preloaded query is required. `--pack <file>` supplies an immutable v2 Pack snapshot for that Run without publishing it. `advanced get` and `advanced list` only read the saved Run/history. Advanced results are whole-run bounded to 20,000 rows and 20 MiB and retained for 30 days; never replace this path with local production scans or a hidden query side channel.
 
 For initial integration or business dashboard work, standard dashboards are only the baseline. During the initial integration, inspect the actual game loop and define a separate game-specific new-user flow dashboard with meaningful milestones and drop-off diagnostics. Add required milestone telemetry and event catalog fields in the same integration instead of waiting for production volume. Validate the pipeline with test data; label business conclusions as awaiting data when production samples are immature, but do not omit the dashboard design.
 
@@ -78,7 +89,7 @@ Reading documentation does not grant permission to mutate production. CLI and Se
 For SDK integration or telemetry changes, determine the actual deployment environment and runtime platform, then run:
 
 ```bash
-gamealgo integration get-plan --environment <domestic|overseas> --platform <ios|android|maker|rest> --json
+gamealgo integration get-plan --environment <domestic|overseas> --platform <ios|android|maker|web> --json
 ```
 
 Inspect the existing project before editing. Reuse existing SDK wrappers, user identity, lifecycle, event, advertising, purchase, and attribution flows.
@@ -165,11 +176,11 @@ Before delivery, inspect changed client code for Variant or assignment-identity
 
 ## Preserve Experiment Platform Scope
 
-A Strategy key is shared by the game and keeps a global fallback default, while every Run belongs to exactly one runtime platform: `ios`, `android`, or `rest` (`rest` includes TapTap Maker). A promoted Run updates only its own platform default. Other platform defaults remain unchanged, and a platform without an explicit default continues to use the global fallback.
+A Strategy key is shared by the game and keeps a global fallback default, while every Run belongs to exactly one runtime platform: `ios`, `android`, `maker`, or `web`. A promoted Run updates only its own platform default. Other platform defaults remain unchanged, and a platform without an explicit default continues to use the global fallback.
 
 - When a Run includes `variantId: default`, the Server snapshots the effective default for that Run's platform, falling back to the global Strategy default only when that platform has no promoted default.
 - `experiment run promote` needs no platform flag because the Run records its platform.
-- When rolling a platform back to a global historical version, pass `experiment strategy rollback ... --platform <ios|android|rest>` so the global version is copied into that platform default rather than replacing the global fallback.
+- When rolling a platform back to a global historical version, pass `experiment strategy rollback ... --platform <ios|android|maker|web>` so the global version is copied into that platform default rather than replacing the global fallback.
 - Treat `experiment strategy publish` and `experiment strategy default` as global-fallback operations; they do not overwrite existing promoted platform defaults.
 
 ## Require Explicit Approval Before Publishing Experiments