gamealgo-cli 0.3.3 → 0.3.5

package/package.json

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

package/skills/gamealgo/SKILL.md

@@ -67,6 +67,43 @@ Reuse events with the same business meaning, register new fields with their real
 
 For every game, prefer stable, human-readable Chinese values for business dimensions that will appear directly in report legends, axes, selectors, or tables. This includes values such as level or stage type, game mode, placement, item name, and business outcome or failure reason. Keep event names, field names, IDs, SQL aliases, and protocol-defined enums in their required technical format. Do not rename values already used by a live game solely to translate them, because that would split one historical dimension into multiple report values.
 
+## Initialize At The Earliest Safe Lifecycle Point
+
+Initialize GameAlgo at the beginning of the earliest runtime lifecycle hook where its minimal required dependencies are available. Do not place it after save loading, scene creation, asset loading, UI construction, ad initialization, or a broad game-module bootstrap merely for organizational convenience. Any unhandled failure before the call would otherwise exclude an opened user from telemetry, and an SDK initialization watchdog cannot report a failure when the SDK was never started.
+
+Wait only for dependencies GameAlgo actually needs, such as the platform runtime, client key, or a required stable identity. If richer gameplay context becomes available later, separate early SDK initialization from later context binding and business-event emission instead of delaying the SDK. Keep initialization non-blocking, isolate and log its synchronous exceptions without blocking the game, and do not silently discard an outer protected-call error.
+
+Before delivery, inspect the complete startup path rather than only the SDK wrapper. Verify that deliberate failures in later save, resource, scene, or UI initialization still occur after GameAlgo initialization has started and can produce either a successful initialization log or the configured initialization-failure diagnostic.
+
+## Always Track Maker Ad Close Callbacks
+
+For TapTap Maker `ShowRewardVideoAd`, entering the registered `onClose` callback is the platform's effective-exposure boundary. Call `TrackAd` unconditionally and exactly once whenever `onClose` runs.
+
+- Never gate `TrackAd` on `result.success`, any return or error code, `result.msg` / `result.message`, a custom failure classification, or whether a `trackId` was extracted.
+- Use `result.success` only to decide whether the game grants the reward. Other result fields may enrich diagnostics but must not suppress `TrackAd`.
+- If `trackId` is missing, still call `TrackAd` and also emit a missing-track diagnostic when available.
+- Do not infer that an `onClose` result was a pre-display failure. Only a thrown or rejected ad request, or a distinct failure callback that occurs without entering `onClose`, may skip `TrackAd`.
+- Keep a per-request guard so duplicate `onClose` delivery cannot produce duplicate `ad_view` events.
+
+Before delivery, inspect every Maker ad wrapper and test the `success=true`, `success=false`, non-success return-code, missing-trackId, and duplicate-callback cases. Each `onClose` case must produce exactly one `TrackAd`; only reward granting varies with `success`.
+
+## Keep Experiment Identity Out Of Game Logic
+
+When client code implements an experiment or remote Strategy, define a stable, typed parameter contract first, including each parameter's meaning, type, valid values or unit, and local fallback. Drive game behavior only from those config parameters or from a validated script payload. Variants provide different parameter values; they are not feature flags.
+
+- A Strategy key may select the executor or parameter namespace, but its name must not choose the behavior inside that namespace.
+- Experiment display names, Run IDs, Variant IDs, and `assignment.variant` / `Variant()` results are attribution metadata. Never compare them or use them as switch cases, lookup keys, feature flags, or gameplay modes.
+- Read behavior through `Value` or the platform's typed config accessors. Use Variant identity only for logging, diagnostics, debug UI, telemetry, and report attribution.
+- Keep the local fallback in the same parameter domain as the remote value so missing, ineligible, stale, or failed configuration has explicit behavior.
+
+Before delivery, inspect changed client code for Variant or assignment-identity access and verify none of it reaches business conditionals. Test active control and treatment configs, missing configuration, and the post-promotion shape where the Variant becomes `default` while the promoted config remains active; unchanged parameters must produce unchanged game behavior regardless of the Variant name.
+
+## Protect D0 Monetization In Maker Experiments
+
+For TapTap Maker and other Maker games, do not autonomously design, create, or start an experiment that removes all ads from a user's first local day, delays the first ad until D1 or later, or otherwise moves the game's core D0 ad inventory to a later day. Many Maker games lose a large share of users before D1, so this is a direct D0 revenue-risk decision rather than an ordinary ad-timing adjustment. A broad request to optimize ads is not approval for this design.
+
+The agent may still propose conservative within-session or within-D0 tests, such as changing the first eligible level, cooldown, placement, or frequency while retaining D0 monetization. Continue with a D1-or-later first-ad design only when the developer explicitly requests that exact delay. Before any external mutation, show the developer the baseline D0 ad revenue at risk, D1 retention and reachable treatment population, traffic and duration, stop-loss threshold, and rollback plan, then obtain approval for the concrete experiment.
+
 ## Changes And Verification
 
 - Make repository changes when the selected task requires them; keep unrelated files unchanged.