app-auth 是一项用于标准化应用身份认证的技能，主要解决 Web、移动端和 TV 端之间共享登录流程、复用 Google 登录等需求。以下内容依据该技能的资料整理。
一、用途 该技能在用户要求“标准化应用认证”“在 Web、移动端和 TV 之间共享登录”“复用 Google 登录流程”等场景下使用。其目标是提供一条面向回访用户的简短路径，以及一条可靠的同一标签页内路径；账号选择或重新认证由 Google 和浏览器决定。资料明确要求不要承诺静默登录，也不要在没有测量的情况下把某条流程称为最快。
二、覆盖范围与检查项 该技能会检查登录、注册、邮箱验证、恢复、会话、登出、账号关联和授权等环节，并识别所选动作、语言区域、设计系统以及已注册的 Google 回调。
三、集成方式 在 React 19.2+ 中，可适配 GoogleSignIn.tsx 及其样式；可选使用 AuthPanel 及面板样式构建类似 Muvisafe 的外壳。其他框架应使用自身生命周期原语实现相同契约。对于邮箱/密码流程，可适配 EmailAuth.tsx 与邮箱样式，并阅读集成契约中的邮箱适配器部分；这些流程发送的邮件可使用 email-design。
四、Google 登录与回退 该技能要求保留带 FedCM 自动选择的官方 Google 按钮，以支持已记住的账号；同时始终提供普通的同一标签页链接。资料指出，GIS 登录不提供 OAuth 授权客户端的 error_callback，因此不得虚构弹窗失败检测、重试计时器或用户代理规则。
五、返回导航与会话策略 返回导航应在认证归属代码中解决。两条路径必须使用相同的账号/会话策略，并且只恢复一次先前动作。只有后端能够验证身份并授权访问。
六、验证与记录 应通过项目现有的 QA 测试框架运行适用旅程，并将固定装置结果、真实 Google 证据和已部署行为区分开。在项目已有的跟踪指南中记录应用提交、运行时版本和实际证据；只有新证据改变共享规则时，才修改共享配方。
七、职责划分 应用负责脚本加载、公共客户端配置、记住成功的 Google 账号、会话、错误报告和导航；组件负责渲染、待处理/错误界面，以及在认证界面关闭时取消其凭据操作。
八、架构与多客户端 若进行架构标准化，应阅读后端标准；该标准是提议的目标，不是已实现的 Go 依赖或已完成的迁移。对于 Web/原生/TV 客户端或其他社交提供方，应阅读平台与提供方部分。每个产品应在其各客户端间使用同一身份存储与吊销模型，同时保持浏览器 Cookie 与原生安全存储传输方式的区别。
九、整理原则 在声称具备生产覆盖前，应先阅读来源，区分已发布的参考实现、经过测试的提取和待定的应用集成。未来组件应在实际应用提供证据时，作为带有代码、集成契约和行为测试的聚焦技能加入；不要加入空目录，也不要把组件 PR 视为部署另一个应用的许可。
十、限制 资料未提供具体安装命令、收费方式、支持的完整平台列表或效果数据，这些内容暂未提供。