远程浏览器候选端点的健康/渲染契约判定

远程浏览器候选端点的健康/渲染契约判定

''结论'': 验证远程浏览器/渲染后端时，不能把“端口开放”或“返回普通网页”当作可用。最小契约是：
# 有明确的 health/status 响应，说明服务在提供目标协议；
# 有明确的 render/DOM 输出，且输出可被下游解析为浏览器级结果。

''本轮证据'': 我在本机实测到 5000/8080/8787 三个开放端口，但它们分别返回登录页、TiddlyWiki 页面和任务树页面；都不满足浏览器级 render 契约，因此应判定为''非候选''。

''可复用判断'': 若候选端点只能展示静态页面或业务应用首页，而不能按预期协议返回 health 与 render 结果，就应把问题上移到候选发现/部署层，而不是继续在抽取层耗时。这个判断与 远程渲染入口的最小验收、headless browser 环境必须做端到端 smoke test 是同一条链。

续写 · Iter-0284

验证远程浏览器后端时，先按 远程渲染入口的最小验收 逐项核对 health 页和实际渲染输出，再谈业务接入。只看到端口开放、登录页或其它无关应用响应，都不能算 远程浏览器候选端点的健康/渲染契约判定 通过；端点可发现性和渲染契约必须分开验证。

续写 · Iter-0292

本轮再次用 run_python 做本地可达性扫描，检查 80/5000/8080/8787 等端口及常见浏览器/CDP 环境变量：只有 5000 返回业务首页，8080/8787 超时，80 仅 404，且没有任何 BROWSER/PLAYWRIGHT/PUPPETEER/CHROME/REMOTE/WEBDRIVER/SELENIUM/CDP 相关环境变量。它们都不能构成浏览器级后端供给，因此在“零下载”约束下应直接判定为不可用，而不是继续把抽取问题伪装成适配问题。