| name | sub-hdd-platform-atmtn |
| description | Class-level umbrella for sub.hdd.sb puzzle platform reverse engineering, Tampermonkey/userscript automation, solver hotfixes, and game-specific debugging across puzzle15, 2048, memory, sudoku, and tile-style games. Use when working on the sub.hdd.sb platform itself, its API contracts, iframe/hub-entry runtime, or any local solver script.
|
| tags | ["sub.hdd.sb","userscript","tampermonkey","puzzle-automation","reverse-engineering","solver-debugging"] |
| version | 1 |
sub.hdd.sb platform automation
Goal
- Provide one discoverable umbrella for the whole
sub.hdd.sb puzzle automation class.
- Cover platform/API reverse engineering, hub-entry/iframe runtime behavior, and recurrent userscript solver maintenance.
- Keep game-specific or session-specific detail in support files under
references/, templates/, or scripts/ instead of fragmenting into many narrow skills.
Use when
- The user mentions
sub.hdd.sb, 号多多, puzzle games, Tampermonkey solvers, puzzle15, memory flip cards, 2048, sudoku, or tile-style puzzle automation.
- You need to debug or improve a local userscript file such as
puzzle15-solver.user.js, memory-solver.user.js, puzzle2048-solver.user.js, sudoku-solver.user.js, or tile-solver.user.js.
- You need to inspect the platform’s API contract, difficulty enums, active-session behavior, or iframe/hub-entry page model.
Class-level workflow
- Read the local userscript first, not a repo copy.
- Identify whether the problem is:
- platform/API understanding
- hub-entry / iframe UI runtime
- solver state correctness
- heuristic/optimization quality
- proof/debug instrumentation
- Apply the smallest code-level fix first.
- Run
node --check on each edited userscript.
- Only after deterministic bugs are fixed should you tune heuristics.
Core platform model
sub.hdd.sb is a shared puzzle platform with multiple games behind a common shell.- The site frequently uses
custom/hub-entry plus a same-origin embedded iframe for the actual game page.
- These games are server-authoritative. Local solver logic plans moves, but the backend decides the true resulting state.
- Therefore API semantics and session sync matter more than DOM-only assumptions.
Problem classes
1. Platform/API reverse engineering
Use this class when you need:
- endpoint discovery
- auth model understanding
- difficulty enum validation
- per-game request/response semantics
- reward / session / anti-cheat behavior
2. Hub-entry / iframe runtime bugs
Use this class when you see:
- duplicate panels
- missing panels after navigation
- close buttons that do not stick
- start/difficulty controls that only click shell UI and not the real game surface
- stale panel bindings or stale intervals across page transitions
3. Solver-state correctness bugs
Use this class when you see:
- repeated illegal moves
- loops on the same card/index
- already revealed / already matched errors
- replaying consumed puzzle states
- invalid-sequence or local preview/API semantic drift
4. Heuristic / optimization work
Use this class when correctness is already stable and the remaining problem is:
- poor win rate
- slow convergence
- weak 4x4/5x5 puzzle performance
- 2048 oscillation or corner-loss behavior
Global rules
- Prefer API truth over inferred DOM truth.
- Treat iframe and page-kind transitions as first-class runtime concerns.
- Separate deterministic correctness fixes from heuristic tuning.
- Keep script-specific incident detail in
references/ rather than cloning a new skill.
Important recurrent lessons
hub-entry and embedded pages often need page polling plus explicit panel restoration.- Existing panels should usually be re-shown and rebound, not rebuilt from scratch.
- Server difficulty enums differ by game; do not reuse one game’s labels for another.
- Puzzle15 direction semantics often differ between local blank-motion solvers and API tile-slide commands.
- Memory-card solvers need three separate state buckets: known, revealed, matched.
- 2048 small-board reliability usually depends more on stability-aware scoring than raw greedy merges.
What belongs in support files
- Full per-game API maps
- exact patch recipes for known regressions
- puzzle15 optimization notes
- memory-resume/debugging notes
- other narrow reproductions or game-specific troubleshooting detail
Verification
node --check <userscript> for every changed script- confirm no duplicated panel/UI regressions on hub-entry
- verify session-adoption logic against a real active session where relevant
- verify API/local direction semantics before declaring puzzle15 fixed
See references
references/platform-reverse-and-api.mdreferences/userscript-hotfixes.mdreferences/puzzle15-optimization.mdreferences/memory-solver-debugging.md
