gamealgo-cli 0.3.4 → 0.3.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "gamealgo-cli",
-  "version": "0.3.4",
+  "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,26 @@ 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.