把 CI、代码规范与无障碍分成三份证据
社区活动报名应用接受 Fork 提交，维护者准备修改工作流和报名失败反馈。本篇用这个原创案例说明三项审阅：流水线信任边界、前端约定与可访问的用户路径。没有执行真实工作流、修改安全设置或完成合规认证，原文中未经核实的事故数字与匿名故事不作为事实引用。
先记录源码版本、工作流文件、触发事件、权限、秘密访问、前端约定与用户路径。语法通过、云端任务成功和无障碍检查分别回答不同问题，证据不能混用。绿色流水线不证明全部依赖可信，也不证明整个产品都能被用户顺利操作。
场景一：沿输入与权限检查 Actions
为每个任务列出触发事件、检出的代码版本、可执行输入、令牌权限、秘密访问、产物及下游消费者。跟踪不可信输入进入表达式与脚本的位置。pull_request_target 本身不等于执行 Fork 代码，风险取决于工作流怎样在拥有的权限下处理不可信内容。应解释具体边界，而不只给事件名贴危险标签。
把不可信贡献验证与有发布权限的工作分开。下游不能仅凭一个产物看似成功就信任它，要检查来源、版本及预期用途。审阅第三方 Action 的固定引用、可复用工作流输入与运行器假设；固定提交有助识别代码，但不能让恶意或有漏洞的代码自动安全。不要为了方便排错把未经审阅代码接进有秘密的环境。
检查每个任务实际需要的权限、凭据是否持久化、怎样传递以及日志会输出什么。自动屏蔽不能保证变形后的值全部隐藏。先用无效样例检查日志与报告，不打印真实秘密测试脱敏。自托管运行器还需考虑持久状态、隔离与清理，不能把临时运行器的假设直接搬过去。
zizmor 是有文档的公开 CI 静态分析参考，项目标示 MIT，适合评估常见工作流风险。采用前核对版本、支持检查和集成模式；有发现时是否失败退出须按真实配置验证，不能以工具任务绿灯推断没有告警。本文没有执行它，也不将它称为已核验的 SkillPI 安装条目。
本阶段产物是具体文件引用、输入路径、权限边界、依据及最小修复建议。静态审阅可以在云端运行前发现问题，却不能证明远端环境和权限配置正确。修复后在授权测试环境验证，保留未执行项。格式检查器与安全分析器职责不同，不能把能解析 YAML 当成安全通过。
场景二：按项目成文规范审阅前端
先读取现有命名、目录、组件、格式、测试及提交约定，区分硬性规则与个人偏好。确认包脚本和框架版本后再选择命令。不要为了符合一份通用清单，把与报名问题无关的整个项目重构。规则不清楚时写明采用的局部解释，不编造所谓企业要求。
本例要求报名失败后保留用户输入并提供恢复反馈。应把状态处理、校验和请求结果一起检查，格式修正不能弥补表单丢值。样式变化与行为修复尽量保持可审阅，检查最终差异是否混入无关文件、依赖或配置。先复现失败，再改对应原因，避免只检查改后看起来正常。
若项目确实使用 React 或 Next.js，React Best Practices 可用于相关实现或性能模式审阅。需要对应源码、构建测试命令，性能问题还需要可比较测量。它不是 Actions 安全扫描器，也不能替代访问控制或业务行为检查。只应用匹配规则，不把示例性能数字当成本项目收益。
按改动运行已有的相关检查，记录命令与实际结果，环境不可用写为未知。产物要指出规则、文件、修改和验证，而不是只有一段评语。保留最小复现输入，方便下一次回归。多个 Skill 即使放在不同目录，指令仍可能有冲突，应按项目要求与宿主优先级解决，不能承诺技能多了绝不冲突。
场景三：沿实际用户路径检查无障碍
明确目标 WCAG 版本、等级及本次页面、状态、设备和辅助技术范围，以 W3C 成功准则及解释为依据。自动工具只能发现部分问题，不能单独证明完整符合。设计审阅、代码检查和真实交互的观察分别保留，不拿其中一种代替全部。
用键盘走报名全过程：到达表单、理解标签、输入、提交、理解错误、修正并完成。检查焦点可见、顺序合理，弹窗打开和关闭后焦点去向正确。错误不能只靠颜色或动画表达。添加一个 ARIA 属性并不自动证明预期体验，应在对应状态实际观察。
检查对比度、缩放与内容重排，必要时核对时间限制及适用要求，不虚构具体截止规则。屏幕阅读器结果需注明浏览器与辅助技术组合。记录观察到什么、失败在哪、未覆盖哪些状态。不能用单个本地样例给整个服务发合规证书，也不能把法律适用范围直接等同于某次工具输出。
Webapp Testing 可支持本地页面路径检查，前提是运行中的测试服务、明确地址或启动命令、授权虚构数据及对应 Python/Playwright 环境。它可以帮助记录 DOM、交互、截图和诊断线索，但不能仅凭浏览器检查证明屏幕阅读器兼容或完整 WCAG 符合。辅助技术与人工判断另留证据。
修复后重走失败路径和原来正常路径，确认没有新焦点陷阱或输入丢失。无障碍工作应贯穿设计和实现，不是发布前补一个徽章。报告按准则、版本、复现步骤和结果组织，让剩余不确定性可见。
实操请求、排错与 FAQ
可以请求：“先映射指定工作流的输入与权限边界，审阅报名改动是否符合本仓库规则，再准备键盘成功和错误恢复检查。给出文件引用及脱敏依据，不运行带特权的不可信 Fork 代码，不修改生产安全设置，不根据自动结果宣称全面符合。先提交最小修复方案，再按授权范围验证。”这将三类检查和各自产物连起来。
YAML 能解析却远端失败时，检查实际环境和权限；扫描任务成功但有发现时，检查集成退出模式；lint 通过却用户丢输入时，回到状态行为；错误提示后焦点消失时，复现状态转换，不只增加标签。例外规则需要具体原因及复查条件，不因赶发布时间屏蔽整类检查。
个人仓库也需要吗？范围可小，但信任边界仍需明确。静态检查能替代云端吗？不能，它只覆盖静态信息。规范会主观吗？以成文规则和具体依据减少争论，保留未约定部分。何时算通过？在声明范围内完成相应检查，实际结果可回查，未测项目明确列出。安装不等于执行，执行不等于全部风险消失。
来源与技能边界
本篇参考 GitHub Actions 安全使用文档、W3C WCAG 2.2 快速参考与 zizmor 公开项目，原文中英文来源配对保留。仅关联已核验的 React 模式审阅与本地网页测试技能，不伪造原文六个工具的详情。来源与许可核验、静态扫描、运行测试是不同信号。本例未运行扫描、改动权限或完成无障碍认证，后续以具体项目证据更新结论。