关于游仓
一个把「找游戏 — 拿网盘链接 — 转存」这条路径做短的中文资源索引站。 首版只做前端与数据形态，后端与采集管线按里程碑推进。
它解决什么问题
网盘资源散落在论坛、群聊和同类站的列表页里，信息结构混乱：同一个游戏有多个盘、多个版本， 体积与可用性经常对不上。游仓把每条资源结构化：统一的类型、平台、年份、体积字段， 一条资源对应一个明确的网盘与提取码，并记录它最近一次核查的状态。
用户不需要注册就能拿到链接，因为这里没有需要保护的用户数据；需要保护的是链接本身， 它决定了这个站能不能活下去（见「链接保护」一节）。
数据从哪来
演示版本的条目资料（中文名、简介、类型、发行日期、配置需求、封面与截图）来自 Steam 公开商店信息， 由 scripts/fetch-demo-data.mjs 一次性抓取并本地化到 public/media。
生产环境的三条录入路径（手动 / 半自动 / 自动）与采集器的限速、重试、置信度打分、 人工审核闸门，写在 docs/01-plan.md 第 3 节。
我们不做的事
不托管文件
不存游戏本体，只存指向网盘分享的索引。
不绕过付费墙
不采集需登录或付费才能看到的内容，不破解任何加密接口。
不做登录墙
查看资源不需要注册，搜索引擎也能正常收录。
不隐藏来源
每条资源都记录来源与审核人，出问题能追溯、能批量下架。
链接保护
详情页 HTML 与 RSC 载荷里不含任何明文链接。资源以 AES-256-GCM 密文形式随页面下发， 密钥由页面标识经 HKDF 派生；点击「获取网盘链接」后才在浏览器里解密。 完整方案（nonce 签名、一次性消费、三层限流、蜜罐、Turnstile）见规划文档第 4 节。
注意当前实现是混淆级：能挡住 grep 式批量抓取， 但懂代码的人可以解开（因为没有后端来保管密钥）。这一步的工程价值在于把交互、 状态与错误分支全部做完，M3 接上服务端后只换数据来源。
技术与许可
Next.js 16（App Router / RSC）+ TypeScript + Tailwind CSS v4，数据层以单一仓储模块repository.ts隔离，M2 换成 PostgreSQL 时页面代码不动。
游戏名称、封面与截图的版权归各自发行商所有；本站引用仅用于条目识别。 权利方要求下架时，按来源批量移除条目。