game-opportunity

Game Opportunity

Turn new URLs from the game platform into directly selectable site-building candidates. Business judgment looks at today's search demand, competitive landscape and playable supply; game release time is only responsible for marking old versus new, and old games can equally enter the priority queue.

Reverse-lookup entry from one sentence

Users won't say "run evaluate"; they'll say "see what games can be done today". All commands are node game-opportunity/scripts/game-opportunity.mjs <子命令>。

What the user might say	What to run → where the basis for interpretation is
"Run the mini-game monitoring" "what games can be done today"	`daily`（= `collect` + `demand` + `evaluate`) → daily report `.rankup/demand/game-review/latest.md`, for grouped interpretation see "External Demand Dual-Track Gate" below
"Only look at what was newly added on the platform today"	`discover`(platform sitemap diff); if you only want the 24-hour new names use `radar`
"Check the volume and KD of this batch of games"	`plan` → `demand`（There are only 6 deep-check slots per day, the list is written by you into `YYYY-MM-DD-demand-selection.json`, see "Deep-Check Slots")
"Are these candidates worth doing"	`evaluate` Layout facts → Interpretation is yours: against the "Search Demand Track / Early Burst Track" score tables and the KD × New Site Action table, write the conclusion into `YYYY-MM-DD-evaluation.json`
"Is this round finished for today"	`collect-checklist` / `decision-checklist`(10 evidence acceptance checks each; what is checked is whether the evidence is complete, not whether the verdict is right)
"Rebuild today's list without internet"	`dedupe`(read the day's discovery/radar, deduplicate games and social campaigns)
"How to build a game site, how to monetize it"	Not in this Skill: read `rankup/references/game-sites.md` + `rankup/references/lifecycle.md`
"General questions about keyword selection/backlinks/site building"	back to `rankup`— this Skill only covers the "which game is worth doing" part

When collection from any source fails or a row's status:'not-queried' , mark the corresponding item as "not tested", and it must not be treated as 0 or "no demand".

Iron rule of division of labor: scripts only collect, judgment belongs only to AI

Layer	Who does it	Output
Collect	`game-opportunity.mjs` each subcommand	raw per-source evidence + manifest (each source `{source,status,count,error}`), challenge page raw HTML,`not-queried` strictly separate from measured zero
Interpret	AI against the raw signals	`YYYY-MM-DD-evaluation.json`(action/reason/missing evidence) and `YYYY-MM-DD-demand-selection.json`(deep-check list)
Format	`evaluate`/`render`	Only lays out facts and the interpretations AI has already written, and produces no conclusion sentences

The script has no scorer, no threshold gates, no verdict. All score tables and threshold numbers below in this document are AI interpretation guidance, for AI to use against the raw signals; when collection from any source fails, mark the corresponding item as "not tested" in the interpretation, it must not be treated as 0 or "no demand".

Task entry

Task	Action	Fixed output
`discover`	Crawl sitemaps from all platforms, filter by site path, and diff against the previous snapshot	`.rankup/demand/game-review/YYYY-MM-DD-discovery.json`
`radar`	Scan 24-hour release sources and player communities, and extract newly appeared game names, aliases, and gameplay terms	`.rankup/demand/game-review/YYYY-MM-DD-radar.json`
`collect`	Complete in sequence `discover` and `radar`, and merge the games newly added that day	The above two input files and `YYYY-MM-DD-new-games.json`
`collect-checklist`	Run collection and complete the 10 hard acceptance checks	`YYYY-MM-DD-collect-checklist.{json,md}`
`dedupe`	Offline, read the day's discovery/radar, and remove duplicate games and social campaigns	`.rankup/demand/game-review/YYYY-MM-DD-new-games.json`
`plan`	Generate a global-priority query plan from real games for original names, English names, and local names; for the deep-dive list, read the AI-written `YYYY-MM-DD-demand-selection.json`, defaulting to a mechanical order (due recheck → newly discovered that day → the rest), and write the full candidate pool along with whether each was selected into the plan	`YYYY-MM-DD-demand-plan.json` and `YYYY-MM-DD-global-keywords.txt`
`demand`	First query global volume and major countries, then query each country database in one pass; markets not queried are recorded as `status:'not-queried'` with a null value, strictly separated from measured zero	`YYYY-MM-DD-demand-results.json`
`evaluate`	Verify liveness, merge entities, overlay data retrieval results and AI interpretation, and lay out the daily report in mechanical order; save the challenge page's raw HTML to `YYYY-MM-DD-evidence/` and mark it, and candidates are not removed	`.rankup/demand/game-review/YYYY-MM-DD-candidates.json` and `YYYY-MM-DD-report.md`
`decision-checklist`	Run the demand research and daily report and complete the 10 hard acceptance checks	`YYYY-MM-DD-decision-checklist.{json,md}`
`daily`	Complete in sequence `collect`、`demand` and `evaluate`	All the above outputs

All tasks go through the same real entry point:

node game-opportunity/scripts/game-opportunity.mjs <discover|radar|collect|collect-checklist|dedupe|plan|demand|evaluate|decision-checklist|render|daily>

When the user only says "run mini-game monitoring", execute daily. Automated tasks are divided into collect and demand + evaluate two time periods: platform increments and the 24-hour radar first form stable input, then the demand stage queries data in the order of global, country, and competition and generates the daily report.

`radar`

New names within 24 hours are first discovered from release sources and player scenes, then enter search volume verification:

Supply side: game platform sitemaps, itch.io last 7 days, GameJolt Hot, Poki / CrazyGames new game slots, Scratch / Cocrea, SteamDB New & Trending, GitHub game repositories, and App Store / Google Play new games;
Player side: Reddit's r/WebGames、r/playmygame、r/IndieGaming, gameplay vertical communities;
Distribution side: YouTube same-day uploads, latest X posts, and local game forums in the target language;
Search side: Google Trends real-time hot searches, 7-day curves, and related rising, as well as long-tail sprouts such as play <name> online、<name> unblocked、<name> html5 in Google Autocomplete / Related Searches;
Verification side: Similarweb's last 28 days of keywords and traffic destinations, and Semrush's per-country search volume and KD.

Use Agent Reach's currently available backend to read communities; for desktop login state, prefer OpenCLI:

opencli reddit search "<游戏名>" --sort new --time day --limit 10 -f json
opencli youtube search "<游戏名> game" --upload today --sort date --limit 10 -f json
opencli twitter search '"<游戏名>" since:<YYYY-MM-DD>' --product live --limit 10 -f json

Search simultaneously for new browser game、playable demo、release trailer、HTML5 game and the corresponding expressions in each language, and extract new entities from the body, title, and landing links. Each radar record saves firstSeen, source URL, publish time, engagement, playable link, language, market, and aliases. Cross-community posts by the same author, official accounts, and identical copy are merged into one campaign; independent publishers, platform types, and unofficial engagement are counted separately. Radar leads first enter the verification queue and are upgraded after reaching the early-burst gate below.

New terms are rechecked on days 3, 7, 14, and 28 after first discovery. Early save volumeStatus: not-yet-observed, continue using community growth rate, cross-platform duplication, playable supply and Trends for judgment; once search volume appears, merge it into the regular KD, SERP and country filters. Similarweb is used for keyword, country and traffic destination verification over the last 28 days, and Semrush is used for per-country search volume and KD.

External demand dual-track gate (AI interpretation guidance, not executed by the script)

New on-site pages, homepage entries and sitemap bulk update times are responsible for discovering candidates. External demand is obtained from independent Google SERPs, local search volume, Trends, competitor organic search terms, and unofficial community spread.

The scores and passing lines of the two tracks below are reference criteria for AI when scoring and interpreting raw signals, not script behavior: the script only hands over the raw values, status and failure scene of each source. When a source status:'failed' or keyword row status:'not-queried' is present, the corresponding scoring item is marked "untested", and the entire verdict is handled as insufficient evidence and must not be counted as 0 points.

Search demand track

Item	Score
Exact keyword monthly searches in target country: 1–99 / 100–499 / 500–1999 / 2000+	5 / 10 / 15 / 20
Google top ten contains multiple independent domains and the intent is consistent with the game	10
30-day or 7-day Trends form a continuous curve and trend upward	10
Similarweb can see the term in competitor organic search terms	5
KD：≤30 / 31–40 / 41–50 / >50	15 / 12 / 8 / 3
SERP has low-authority, new pages or independent site gaps	10
Playable supply / stable on mobile / can go live within two days	10 / 5 / 5
Target country matches search intent	10

Exact keywords, gameplay categories and multilingual variants are scored separately. Search volume reaching "1,000 global exact keyword, or 500 exact keyword in target country" only enters research and does not mean development is allowed. AI judgment develop The reference hard thresholds are at least 10,000 global exact keyword, at least 2,000 in the top country, KD no higher than 30, game intent verified, independent external demand exists and playable supply is stable; if any item is missing or untested, judge research or observe. Candidates then calculate KGR (allintitle result count ÷ monthly searches): the community initial screening line is KGR <0.25 or allintitle <100; also check EMD and top-ten professional site occupancy. Total score 70+ is judged quick-ship, 50–69 is judged priority-research, the rest are judged watch——this scoring is completed by AI and written into the evaluation file together with the reasons; the script only passes it through.

Early outbreak track

When the panel has not yet formed data, save three snapshots at 4 hours, 24 hours and 7 days, and calculate using the deduplicated campaign :

Item	Initial passing line (run 1–2 weeks of backtesting first, then calibrate)
24-hour unofficial independent publishers	≥3
Independent platform types	≥2 (e.g. Reddit + YouTube)
24-hour posting rate / first 7-day daily average	≥3x
Unofficial interactions or views	≥20 interactions, or ≥500 views
Search budding	Trends rising, Autocomplete long tail, related queries or new SERP page hits one item
Playable supply	There is already an openable web game, demo or stable iframe

If all of the first four items are met and growth continues after the 4-hour recheck, enter priority-research; then obtain search budding and playable supply, and upgrade to quick-ship. These numbers are the first calibration values for automation: save hits and subsequent real search results every day, and after running for 1–2 weeks, adjust based on successful samples. Each publisher's account, copy, landing link, and publish time are saved in the evidence, making it easy to identify organic spread versus concentrated promotion.

For new terms, use 7-day and 30-day windows to look at acceleration; for gameplay terms with history, also look at 3-year and 5-year windows to distinguish long-term upward trends from short-term spikes. When the same pain point appears repeatedly on 3 or more independent platforms, record it as cross-platform demand evidence.

Data boundaries

This Skill is a reusable specialized capability of Rankup, not a temporary process in the project .rankup/ :

General SOPs, Checklists, and scripts are saved in game-opportunity*、rankup/ and backlink/；
Each website's own platform list, snapshots, candidates, data retrieval results, and daily reports are saved only in that project's .rankup/；
New rules verified as stable in a project are written back to the general Skill; project names, domains, and private data are not written into general rules.
Platform list:.rankup/demand/game-platforms.json
sitemap snapshot:.rankup/demand/game-sitemap-snapshots/
Publishing source snapshot:.rankup/demand/game-radar-snapshots/
Raw reports, KD inputs and results, candidate JSON, daily reports:.rankup/demand/game-review/
Long-term candidates and judgments:.rankup/research.md

These are all data belonging to the current project itself. Reusable rules and scripts are saved in this Skill, Rankup, and Backlink.

collect merges the day's discovery URLs with the Steam/itch/Poki game titles from radar into a unique games[], social campaign is kept only in the raw radar input and is not counted toward the number of new games.dedupe can rebuild that file without an internet connection.

`discover`

Run in the repository root:

node game-opportunity/scripts/game-opportunity.mjs discover

In the platform configuration, include、exclude、kind and timeout are respectively responsible for game paths, miscellaneous page paths, content types, and the per-site crawl window. Keep independent snapshots and statistics for each platform so reports can be traced back by platform, language, and market.

`evaluate`

First run the entry script to generate the day's candidate queue and verify liveness:

node game-opportunity/scripts/game-opportunity.mjs evaluate

1. Verify and merge

Read the day's discovery JSON and, for each new URL, complete the following in order:

Directly check HTTP status, final URL, body length, and title;
Use Jina Reader to extract readable body text;
When a page depends on a logged-in state or browser rendering, use OpenCLI to read it;
Merge multilingual pages of the same game by canonical, game name, slug, and iframe URL;
Divide into playable-game、new-on-platform、game-adjacent、stale-url。

new-on-platform means the monitoring site just indexed it today; separately determine the game's first release date. Write both into the report at the same time.

2. Generate keywords

For each valid entity, extract 1–3 real search expressions: official original name, official English name, existing local name. Case variants are merged;Demo is used only as a version marker and does not occupy a term on its own. The platform's country is recorded only as the discovery source and is not used to determine the game's origin or target market.

English must not be omitted just because the game comes from a minor-language platform: if there is an official English name or a common English name, it enters the global query. Non-English original names are also queried globally separately, because global queries count only exactly identical strings and will not automatically translate ノノグラム into nonogram。

First mark candidates as brand、category or generic, then build demand clusters:

brand: official name, English name, local name, and pc、online、guide and other conversion intents already supported by signals;
category: local users' alternative names for the same game type, and intent words such as free/online/play directly;
generic: first use the SERP to confirm that it really points to the same game need, then decide whether to keep it.

Semrush/Similarweb related terms are used to expand candidates and cannot be used directly as development evidence; expanded terms must still separately be checked for country volume, KD, and SERP. Synonyms may be searched by the same group of users; the report lists their figures separately and does not simply add them together into total market size. The country where the game platform is located only represents the discovery source; global, large English markets, and countries with real volume must not be skipped just because the source is a minor language.

Execute first:

node game-opportunity/scripts/game-opportunity.mjs plan
node game-opportunity/scripts/game-opportunity.mjs demand

demand Always run in the following order:

Take the top 6 real games by priority, query their original name, English name, and local name, read globalVolume and Top-N byCountry；
merge the discovery markets and the countries with volume inbyCountry into a country plan;
within the same Semrush page session, batch-fetch local volume, KD, CPC, and intent for all countries;
global and country results already fully obtained are reused directly, and the browser is not reopened on reruns.

When Semrush starts, the tool homepage appearing once is initialization; country queries must not restart the tool for each country or repeatedly jump to the homepage.

3. Query competition and demand

After the global and country distribution is complete, then query Ge Fei Web.Cafe's KD and SERP landscape for the main opportunities:

node rankup/scripts/seo-webcafe.mjs kd \
  --batch ".rankup/demand/game-review/${TODAY}-kd-input.txt" \
  --spacing-ms 6500 \
  --out ".rankup/demand/game-review/${TODAY}-webcafe-kd.json"

This command by default drives the locally logged-in Chrome via OpenCLI to run logged-in 100/day or VIP 500/day—no extra parameters are needed. The first line in the terminal printing "Quota Guest: used X/10" is adegradation signal, not the norm: either OpenCLI is unavailable (opencli doctor first see where the red is), or --guestwas explicitly added. Before batch-running a whole batch of terms, first confirm that the first line shows the logged-in/VIP tier, and do not plan how many terms to test in this batch based on the guest 10/day assumption (on 2026-09-11, three executors replayed this once on this command: they mistook this line's false report for the real upper limit and thought it was exhausted just as the batch started).

Web.Cafe results are used for KD, homepage/inner-page composition, weakest competitors, and link budget. Search volume, CPC, and global volume use:

node backlink/scripts/semrush-keyword.mjs \
  --kw-file ".rankup/demand/game-review/${TODAY}-keywords-<db>.txt" \
  --db <db> \
  --bulk \
  --out ".rankup/demand/game-review/${TODAY}-semrush-<db>.jsonl"

A single-country file can still be checked independently,--db is always filled in explicitly; the batch page submits at most 100 terms at a time. Cross-country automated tasks use:

node backlink/scripts/semrush-keyword.mjs \
  --bulk-plan ".rankup/demand/game-review/${TODAY}-country-plan.json" \
  --out ".rankup/demand/game-review/${TODAY}-semrush-countries.jsonl"

globalVolume indicates the global total for the exact same keyword,byCountry only indicates the main countries listed on the page, not all countries. Global volume cannot prove that the search intent belongs to this game:Island Survival generic terms like this must also be checked for <name> game、 play <name>, SERP entities, and competitor pages. Semrush's zero-value single terms are rechecked separately. For trends use rankup/scripts/gt.py to query the 12-month, 30-day, and 7-day windows. For playable candidates, extract the iframe or game entry point, and record HTTP status, landing page, and mobile and fullscreen clues.

Unified judgment of KD and SERP

KD	New site action
`<20`	When volume, intent, and supply hold, proceed directly to development review
`20–39`	The main battlefield for a new site; proceed after completing SERP and independent demand verification
`40–49`	Continue only when the top ten include weak positions/new sites, intent is concentrated, the page can be clearly better, and the backlink cost is acceptable
`>=50`	Do not treat as a main target term for a DR≈0 new site; can be kept as a demand-cluster secondary page or observation term

KD 40 is the deep-dive trigger line, not the automatic-abandon line. Brand-derived KD only indicates the difficulty of entering through third-party pages such as guides, downloads, and reviews; category terms use ordinary KD. When Semrush and Web.Cafe differ by more than 10 points, the keyword types are inconsistent, or one side has no data, you must state the caliber conflict and manually re-check the SERP; you cannot pick the lower number and draw a conclusion. For competitive evidence, at minimum save the search intent, weak positions in the top ten, whether low-authority/new sites exist, and whether the current page can create an experience difference.

Separate total volume from recent direction

Similarweb's last-28-day total answers "is there demand this month"; Google Trends' last 7 days answers "is it still accelerating, holding steady, or falling back". For each deep-dive candidate, save both 28d/30d and 7d, and use only the rising、flat、cooling、 insufficient four in conclusions. If the last 28 days are above the long-term average but the last 7 days are falling back, write it as "monthly still high, short-term cooling", not "still rising". Insufficient sample is insufficient, not zero demand.

Separate independent demand from in-platform traffic

New game platform pages, homepage recommendations, and in-site entries only prove that the platform is willing to promote this game. External demand must be obtained from independent Google SERPs, per-country search volume, unofficial communities/videos, and competitors' organic search terms. For each candidate, record internalTrafficRisk and independentDemand; when there are only in-platform signals, keep it in observation, and do not upgrade it just because the page exists or can be iframed.

4. Grouping (AI judgment)

The AI places candidates into three groups against the interpretation guidelines above and writes them into the evaluation file:

quick-ship: global volume, major-country volume, KD, game intent, independent demand, and playable supply all pass the development hard thresholds;
priority-research: there are already demand signals, but one more piece of supply, trend, or competitive evidence is still needed;
watch: game-related signals hold, waiting for the next platform, trend, or search-volume signal.

Candidates not judged by the AI are honestly placed in the "unjudged" group in the daily report, and are not judged by the script on its behalf. Old games enter the same interpretation set based on current volume, current KD, current SERP, and current supply. Invalid URLs (all tested 404/410) are summarized separately by the script as facts, to facilitate cleaning up sitemap noise; candidates blocked by a Cloudflare challenge pageare neither counted as invalid nor removed, and their raw HTML is in YYYY-MM-DD-evidence/, with the AI deciding whether to switch channels and retest or switch the judgment.

5. Write back and generate the daily report

Write the quantified results as .rankup/demand/game-review/YYYY-MM-DD-evaluation.json, in the format {"candidates":[...]}; merge each item with the queue using entityId, name, or URL.

This file is the only judgment entry point for the entire pipeline, and is written after AI interpretation. Brand terms/category terms, SERP intent, weak positions in the top ten, 7-day direction, in-site traffic risk, and action（develop/research/watch）、reasons、 decisionAudit.missingEvidence、nextAction can all only come from here; the script passes them through as-is, and missing means "unjudged"; the four acceptance checks D03, D06, D07, and D08 are exactly what they check. The deep-dive list is likewise written to YYYY-MM-DD-demand-selection.json(entityId array), and theplan field of pool lists the complete candidate pool for selection; when no list is written, the script uses the mechanical default order (due for review → newly discovered that day → the rest). evaluate and decision-checklist willautomatically read this agreed path, with no need to pass --evaluation：

node game-opportunity/scripts/game-opportunity.mjs decision-checklist

Only pass parameters explicitly when you want to override with a file from elsewhere (explicit parameters take precedence):

TODAY=$(date +%F)
node game-opportunity/scripts/game-opportunity.mjs render \
  --evaluation ".rankup/demand/game-review/${TODAY}-evaluation.json"

2026-08-27 fix: previously evaluate only recognized explicit --evaluation, while decision-checklist when calling it without passing arguments, so manual judgmentevery unattended run gets dropped, D03/D06/D07/D08 are constantly 0/6. Now both stages read the same agreed path.

The entry script fixedly generates a date file and two stable entries:

.rankup/demand/game-review/latest.json: machine-readable candidates;
.rankup/demand/game-review/latest.md: the latest daily report for users to read.

The daily report is displayed in develop、research、watch、未判 four groups (the labels of the first three groups come from AI), and each candidate must have a discovery page, playable page, or evidence link. Search volume is displayed separately as "global volume, highest country and its volume, discovery market and its volume"; the number of the highest country must not be written under the discovery market; at the same time include that main market's KD, number of unqueried rows, playable status (yes/no/untested), and the next step written by AI. When the automated task completes, directly return each group's List and these links to the user, and the user decides whether to continue research or create a website development task.

The daily report itself does not write concluding sentences. Judgments like "there is no opportunity that meets the development threshold today" are made by AI itself after reading the raw signals, and before saying so it must confirm: it is not that no opportunity appears only because some source failed or some markets were not queried—untested items must either be supplemented with tests, or be truthfully named in the conclusion. Do not upgrade small and medium keywords or broad terms with unverified intent into recommended development.

The previous day's research/watch is automatically carried forward; on the 3rd, 7th, 14th, and 28th days after first discovery, mark a review in carryForward.recheckDue . New candidates are always placed before carried-forward candidates.

Deep-dive slots: AI sets the list, the script only has a mechanical default

Every day there are only 6 deep-dive slots(which consume Semrush quota). Who occupies the slots is a judgment, so AI, before running plan/demand , looks at the complete candidate pool output by plan (thepool field), and writes the list into YYYY-MM-DD-demand-selection.json(an entityId array, used in order).

When no list is written, the script uses themechanical default order(looking only at the calendar and sources, not at quality):

Rank	Situation
1	Carried-forward candidates that today exactly cross the 3rd/7th/14th/28th day (review is a calendar commitment)
2	New discoveries of the day (`new-games`）
3	the remaining non-carried-forward candidates
4	Carried-forward candidates on non-review days (do not occupy slots—measured on 2026-08-27, permanent carried-forward candidates would leave only 1 slot for 224 new discoveries)

On 2026-08-27, two bugs were fixed that would cause the pipeline to stop discovering new opportunities:

The review determination used exact equality [3,7,14,28].includes(ageDays). If the pipeline misses a day, age jumps from 2 to 4, and the 3rd day's review ispermanently missed and will not be made up—and there will be no error at all. Changed to "trigger when a milestone is crossed."

Carried-forward candidates occupied all slots every day. Measured on 2026-08-27: 5 of the 6 slots were occupied by carried-forward candidates, 224 games newly discovered that day could only compete for 1; and the evidence gaps of these carried-forward candidates would not fill themselves, equivalent to the queue being permanently saturated. The root cause is that when inputCandidates was normalized, the carryForward field was lost, so carried-forward candidates looked brand new when sorted.

JSON artifacts

YYYY-MM-DD-candidates.json at least include:

{
  "date": "YYYY-MM-DD",
  "sourceReport": "...-discovery.json",
  "stats": {},
  "candidates": [
    {
      "entityId": "...",
      "names": [],
      "urls": [],
      "platforms": [],
      "languages": [],
      "markets": [],
      "pageType": "playable-game",
      "firstSeen": "...",
      "gameReleasedAt": "...",
      "reachable": true,
      "playable": true,
      "embed": {},
      "keywords": [],
      "keywordStrategy": {"entityType": "brand", "clusters": []},
      "demandProof": {"track": "search", "score": 0, "evidence": []},
      "promotionRisk": {"internalTrafficRisk": "medium", "campaigns": 0, "independentPublishers": 0},
      "competitionReview": {"serpIntent": "", "weakPositions": [], "newSitePresent": false, "kdInterpretation": "", "metricConflict": "reviewed"},
      "trend": {"direction": "flat", "windows": {"28d": {}, "7d": {}}},
      "decisionAudit": {"missingEvidence": []},
      "decision": "quick-ship",
      "reasons": [],
      "nextAction": "..."
    }
  ]
}

Each keywords[] Each entry stores the keyword, market, language, Web.Cafe KD, SERP shape, Semrush local volume, global volume, main-country volume, CPC, Semrush KD, query time, and the raw result file. The daily report uses a table to list candidates, volume, KD, playability, conclusion, and next steps.

Completion criterion: evidence is present, not a self-assessed pass

Whether it is complete depends onwhether all the evidence is on the board: the raw output of each step exists, each source has an explicit entry in the manifest collected/failed result, each failure leaves a trace (error message or raw HTML), and each interpreted field can be traced back to the evaluation file.collect-checklist / decision-checklist is the mechanized form of this evidence-presence check; they verify "whether the evidence is complete and the accounts balance," not "whether the verdict is correct"—verdict quality is reviewed by the AI and the user against the evidence.

Acceptance fields and applicability:

D04/D05 share the data-retrieval status rules with cache reuse.ok/measured/collected real values (including 0) are valid; a positive global volume also requires a country distribution of volume.absent、metrics_unavailable, errors, or all-empty rows are untested, cannot be reused as completed, and globalChecked: true cannot be treated as evidence.
When confirming the keyword database does not cover it, use verified-empty or absent-confirmed, keep the raw page evidenceFile, and verification: {pageChecked: true, controlPassed: true, controlFile: "..."}. First check the raw page's empty state and verify the same data-retrieval channel with a keyword that has volume, then fill it in; not covered is not zero demand.
D06's competitionReview records, in addition to the original SERP fields, status: "reviewed" and evidenceFile. When global and country data retrieval is complete and the global measured value is zero/coverage is verified as absent, the AI may write status: "not-applicable" and reason; acceptance displays not applicable separately and does not claim the board has been checked. Data-retrieval failures do not qualify for this exception.
Each of D07's trend.windows["28d"或"30d"/"7d"] stores status、file, the actually measured start/end. Valid statuses are ok/collected/measured/insufficient, the window span matches the name, and the as-of date should be within 3 days before the report date.insufficient is used only when the sample is insufficient after an actual query, and is paired with direction: "insufficient"; untested, wrong years, and crawl failures must not pass.
D08 checks supply by product form. Web games retain page measurement and playable；companion-tool use supplyReview: {status: "reviewed", evidenceFile: "...", dataSource: "...", license: "...", implementation: "..."} to record the identified data source, usage license, and implementation feasibility; an iframe is not required. Fields still unidentified are not filled in as complete.

The above file paths support project-relative paths. The machine checks status, dates, values, and file presence; whether the raw files truly support the written judgment must still be verified by the AI reading them, and fields must not be fabricated to make the check turn green. Failed items continue to retain a partial report.

The morning task uses the collect-checklist 10-item evidence acceptance as the completion threshold;
The decision task uses the decision-checklist 10-item evidence acceptance as the completion threshold;
The discovery report exists and gives the success, baseline, failure, and new-add counts; failed platforms are visible in the manifest;
Every new URL has an accessibility measurement result (yes/no/untested; being blocked by a challenge page counts as untested and the trace is in the evidence directory);
Multilingual duplicate pages have been merged;
Every candidate entering ranking has a supply status and at least one set of market keyword data;
Candidates first have globalVolume/byCountry, then the local volume of the discovery market and main countries; when there is an English name, the English term has entered the global query;
demandCoverage Clearly record the keywords and countries checked; the daily report does not treat the platform country as the game's country of origin;
Each deep-dive candidate has been labeled with brand terms/category terms, synonym and intent-fulfillment need clusters have been established, and overlapping search volumes are avoided from being added together;
The KD definition, weak SERP positions/new sites, 28-day total, 7-day direction, and in-platform traffic risk all have explicit fields;
JSON and Markdown numbers are consistent, and all private artifacts are located in .rankup/。
latest.json are consistent with that day's candidates,latest.md are consistent with that day's daily report;
The final reply includes develop/research/watch/未判 each group's candidates and clickable source links; undetermined and untested items are named truthfully and must not be written as zero or none.