00
密码管理器自动填充调试台
纯前端静态，不上传任何输入：表单被拦截，值只留在本机。
—
PAGES · 页面总数
编号即建议测试顺序。
—
TEST MATRIX · 全部页面
卡片由
assets/pages.js 生成
PROCEDURE · 一轮完整测试怎么走
- 先起服务，别双击打开文件。
file://下 origin 是null，iframe 判定和 WebAuthn 全部失真（见 DEPLOY）。 - 把 fixture 存进被测管理器。每页顶部 FIXTURE 表就是该页的期望值，账号密码逐页不同（
pm01@example.com/pm05@example.com…），一旦填错来源就能看出来。 - 聚焦第一个字段，让管理器自己弹建议。不要手动粘贴——手动输入会被判成
TYPED，测不出填充行为。 - 点 CHECK FILL。逐字段判 PASS / PREFIX / FAIL / ABSENT，覆盖率条同步更新。
- 看底部 DIAG 抽屉。
FILLED= 无键盘事件的 trusted 变更、SILENT-FILL= 连 input 事件都没有、:-webkit-autofill 命中= CSS 探测、SCRIPT= 非可信事件。 - 换页继续；一轮跑完到 DIAGNOSTICS 看合并日志。
HOW TO READ · 判定含义
PASS与 fixture 完全一致（忽略大小写与首尾空白）
PREFIX填入值是 fixture 的前缀：截断、分隔符吃掉后半段、或只填了半截
FAIL字段存在但值不符：填错条目、填错字段、或被脚本改写
ABSENTfixture 要求的控件在本页 DOM 里找不到
无 fixture 页覆盖率条改按“控件是否有值”计算，此时 PASS 只表示被填上，不保证填对
秘值字段password / cc-* / one-time-code 的值永远不进日志，只记长度与是否命中
ENVIRONMENT + CAPABILITY · 当前环境支持什么
CAPABILITY PROBE
MISSING 不代表站点坏了，只代表那一项没法在这台机器上测。
DEPLOY · 为什么必须用 http(s) 起服务
npx serve . -l 8443 # 或
python -m http.server 8000 # 然后访问 http://localhost:8000/- http://localhost / 127.0.0.1 —
isSecureContext = true，WebAuthn、clipboard、store()全通。日常回归首选。 - *.github.io — 表单填充可用；但
github.io在 Public Suffix List 上，rpId只能是公共后缀，且 eTLD+1 分组意味着全网所有 github.io 站点共用一个填充域。测 passkey 时会出现无法归因于你的代码的差异。 - 自己的域名 — eTLD+1 干净，passkey 归属明确，长期回归最佳。若要端点探测，把
/.well-known/passkey-endpoints放到站点根目录（本仓库已带）。
- “填得对不对”依赖真实管理器。本页只能证明 DOM 侧观测与判定逻辑；各家（Chrome/Edge/1Password/Bitwarden/iCloud/系统键盘）在真机上的表现需要你自己跑一轮并记录。
- 保存提示（save prompt）无法被 JS 观测。它是浏览器 UI，不在 DOM 里。只能靠“允许真导航”开关走真实提交后肉眼看，因此 01/02/04/05 页留了 REAL NAV 按钮。
- passkey 结果只能证明断言成立，不等于服务端可验证。本站没有后端，challenge 由本页生成、也不做校验，所以“验证可用性”指的是客户端链路（创建→枚举→get→签名→flags）。
- 跨浏览器差异未穷举。
:-webkit-autofill探测只对 WebKit/Blink 系有效；Firefox 走 silent-fill 轮询与 change 事件路径。 - 自动化脚本的 fill 不算填充。实测：CDP /
element.fill()派发的 input 事件isTrusted=false，本站判为SCRIPT而非FILLED。所以 Playwright/Puppeteer 只能验证 CHECK 逻辑，验证不了管理器的真实行为。