lokei

`lokei` 会影响本地网络环境，并可能触发设置流程。

不可妥协的规则：

1. 先确认 lokei 可用，再依赖它执行操作。
2. 未经批准，不要自动运行一次性设置或卸载流程。
3. 确认用户需要的是仅本地 HTTPS、公共隧道还是多服务编排。
4. 优先使用符合需求的最简单命令。
5. 清楚报告生成的 URL 和诊断到的阻碍。

lokei

输入

• $request：本地 HTTPS、共享、Docker、服务或诊断任务

目标

使用 lokei 来：

• 让本地项目通过带名称的 HTTPS .test 域名运行
• 按需通过隧道公开本地服务
• 编排 Docker 或多服务本地环境
• 诊断并解释本地代理或设置问题

步骤 0：验证安装和设置状态

检查：

• lokei --version
• lokei doctor

如果未安装 lokei，请告知用户：

尚未安装 lokei。请使用以下命令安装：

npm i -g lokei && lokei setup

lokei setup 只运行一次——生成本地 CA、在操作系统钥匙串中信任该 CA、为 .test 配置 DNS，并设置端口转发。

不要自动安装或运行设置。等待用户确认。

如果设置状态不正常：

• 说明发生故障的组件
• 常见修复方法：CA 未受信任或缺少 DNS 解析器 -> 重新运行 lokei setup
• 在建议或运行一次性设置操作前先征求用户同意

成功标准：lokei 可用，且其设置状态已明确。

步骤 1：确定所需模式

判断用户需要的是：

• lokei run：运行一个本地应用
• lokei share 或 lokei run --expose：公开访问
• lokei docker up：用于 Docker Compose
• lokei up：用于 .test.yaml 编排
• lokei routes ls、inspect 或 logs：用于诊断

同时确认是否需要覆盖项目名称、命令或端口。

成功标准：执行前已选择正确的 lokei 模式。

步骤 2：运行最精简且正确的命令

优先使用：

• lokei run：常规本地开发
• lokei share --port <port>：临时共享
• lokei run --expose：同一会话需要同时使用本地 HTTPS 和公共隧道
• 仅当项目结构确实需要时，才使用 lokei docker up 或 lokei up

除非用户明确要求，否则不要运行服务安装或卸载流程。

成功标准：执行的命令符合所需工作流，没有超出需求。

步骤 3：清楚报告 URL 和运行状态

执行后，报告：

• 本地 .test URL
• 如果创建了公共隧道，则报告其 URL
• 相关的项目名称和路由详情
• 如果命令失败，则报告任何 doctor 或设置方面的阻碍

成功标准：用户明确知道应用可通过何处访问；如果无法访问，也清楚了解失败原因。

防护规则

• 未经批准，不要自动运行 lokei setup、service install 或 uninstall。
• 如果仅本地 HTTPS 已足够，不要擅自假定用户需要公共隧道。
• 不要用笼统的“设置失败”概述掩盖诊断信息。
• 不要添加 disable-model-invocation；这是常规环境工作流技能。

何时加载参考资料

• references/command-reference.md 用于查阅完整命令目录、框架检测表、架构详情、.test.yaml 示例、git 工作树行为和场景速查。

输出约定

报告：

1. 选择的模式
2. 运行的命令
3. 生成的本地或公共 URL
4. 检测到的任何设置或网络阻碍
5. 需要用户批准时的下一步操作