@numa-tech/numa 1.13.2 → 1.13.4

package/skills/numa-create-application/SKILL.md

@@ -0,0 +1,163 @@
+---
+name: numa-create-application
+description: 使用 Numa CLI 分析、规划、创建、接入或 promote 企业应用，并安全编排代码仓库、已有本地源码首次发布、Jenkins Job/流水线、GitOps target/service binding、legacy image writer 迁移、Jenkins GitOps rollout/readiness 和运行态证据。用户提到“创建新应用”“本地项目没有 remote”“把现有目录发布到 Codeup”“接入已有仓库”“promote 应用”“迁移 Jenkins image writer”“初始化 Jenkins 流水线”“推断应用归属或部署环境”时都应使用；即使平台某项能力未发布，也必须生成完整能力矩阵、恢复动作和待确认清单，不能把缺失能力静默改成人工直写。
+---
+
+# Numa 应用创建
+
+先读取事实并形成完整草案，再询问真正不明确的决策。把“应用团队”“代码库分组”和“部署集群”作为三个不同概念处理。任何外部写操作前都展示最终确认清单。
+
+## Promote 硬门禁
+
+`LOCAL_HISTORY_WITHOUT_REMOTE` 只能采用下面这一条父子链，计划和执行都不得改写顺序：
+
+```text
+app begin
+-> Repository CREATE plan (consumer=APPLICATION_ONBOARDING, consumerRef=sessionNo；Codeup 受管 README 初始化)
+-> schemaVersion=3 CREATE_NEW + PUBLISH_PROJECT parent plan/apply
+-> Repository child SUCCEEDED
+-> parent WAITING_EXTERNAL / ATTACH_PUBLICATION_PLAN
+-> app publication attach（同一 session、同一 parent planHash；CAS 更新 README.md 并写入完整 tree）
+-> Publication child SUCCEEDED + remote evidence
+-> Jenkins Job child（NO_BUILD）
+-> legacy image writer migration plan/apply（只在现有 overlay 缺 writer pointers 时，作为 GitOps materialize/apply 前置）
+-> GitOps child
+-> Jenkins GitOps rollout plan/apply + trusted readiness（MANUAL_OPERATOR_ATTESTED）
+-> Observer scope/evidence
+-> 独立首次 build/生产审批
+```
+
+以下方案即使“看起来能工作”也判定为错误并停止输出：
+
+- 先创建/发布仓库，再另建 schemaVersion=2 `ATTACH_EXISTING` onboarding；
+- 独立创建 `consumerType=STANDALONE` Publication 后再附着 Application；
+- 直接 `git remote add` / `git push` 作为默认路径；
+- 把 Repository、Publication、Application 或首次生产构建合并成一次笼统确认。
+
+在最终回答前逐项自检：必须明确写出 `schemaVersion=3`、`CREATE_NEW`、`PUBLISH_PROJECT`、同一 `sessionNo`、session-bound Repository plan、Codeup 受管 README 初始化，以及 `app publication attach` 通过 CAS 更新 README/写入完整 tree；缺任一项不得声称 Promote 计划完整。
+
+## 必读资源
+
+- 每次执行都读取 [references/checklist.md](references/checklist.md)。
+- 需要调用 Numa 或恢复失败操作时读取 [references/numa-cli.md](references/numa-cli.md)。
+- 需要推断团队、仓库、环境、集群或数据库时读取 [references/inference-rules.md](references/inference-rules.md)。
+- 创建、接入或 promote 涉及 Repository、Jenkins、GitOps 或 Observer 时读取 [references/promote-workflows.md](references/promote-workflows.md)。
+- 分析本地项目时运行 `node scripts/inspect-project.mjs [project-directory]`；不要自行扫描 `.env`、凭据目录或密钥文件。
+
+## 工作流
+
+### 1. 建立只读上下文
+
+1. 解析用户指定目录；未指定时使用当前工作目录。
+2. 运行项目事实采集脚本。
+3. 只读执行 Numa 诊断：版本、配置 profile、认证状态、当前用户、命令能力目录。
+   同时执行 `numa app capabilities --json`；本地有命令但服务端返回 501 时仍视为未发布。
+4. 查询当前可见的团队、系统、业务域、环境、SCM 连接、技术栈、模板、已有应用和流水线。
+5. 查询团队成员关系；不能查询时标记 `UNAVAILABLE`，不得把 realm/client role 或 Keycloak group 当作团队成员资格。
+6. 在任何受保护写操作前，明确显示目标 profile、API origin、tenant/profile ID 和环境级别。
+7. 根据运行时 command catalog 和 capability API 形成能力矩阵。区分 `AVAILABLE`、`MANUAL_BRIDGE`、`UNAVAILABLE`，不要因为命令名称看起来存在就声称端到端可执行。
+   Project Publication 的服务端 action 只认规范的 `PLAN_PUBLICATION`；`app publication attach/resolve` 必须另外由本地 command catalog 证明存在，`resolve` 是只读传输恢复命令，不是独立 capability action。
+
+只使用 profile 指向的正常 HTTPS 网关。网关不可达或写响应未知时，先按原 session/clientRequestId
+读取 status/events；`app publication attach` 必须先用原 `sessionNo/clientRequestId` 执行
+`numa app publication resolve <sessionNo> --client-request-id <original-id> --json`，不要先重放 bundle。
+不要为绕过故障启动或遗留 `kubectl port-forward`、SSH tunnel 或后台代理。
+
+不要打印 access/refresh token、Cookie、Authorization、SCM credential、数据库密码、完整 Secret、带 userinfo 的 URL 或 Numa token cache 内容。通用 `numa request` 必须过滤响应 headers，只输出允许字段。
+
+### 2. 生成完整草案
+
+使用 checklist reference 的全部栏目输出一张草案。每个字段标记：
+
+- `OBSERVED`：由仓库或平台只读 API 直接证明；
+- `INFERRED`：有证据的建议，附证据和置信度；
+- `CONFIRMED`：用户已明确确认；
+- `UNRESOLVED`：执行前必须补齐；
+- `DEFERRED`：当前平台能力未提供，记录但不执行。
+
+先展示完整草案，再开始提问。不要因为数据库/集群 CLI 尚未实现而省略对应栏目。
+
+必须先给本地源码分类：
+
+- `REMOTE_TRACKED`：remote、upstream、不可变 HEAD 均可证明；
+- `LOCAL_HISTORY_WITHOUT_REMOTE`：已有 clean Git HEAD，但没有 remote；
+- `REMOTE_WITHOUT_UPSTREAM`：有 remote，但当前分支未绑定 upstream；
+- `DIRTY_WORKTREE`：存在未提交内容，任何 publication/apply 前停止；
+- `UNVERSIONED_DIRECTORY`：不是 Git 仓库，不能冒充已有源码发布。
+
+`LOCAL_HISTORY_WITHOUT_REMOTE` 不是普通 blocker。按 promote workflow 生成 Repository CREATE plan（Codeup 默认受管 README 初始化）、schemaVersion=3 onboarding parent plan，再通过该 session 的 publication bridge 附加受限源码 child plan；只有 publication capability 确实不可用时才标记 `MANUAL_BRIDGE`，并单独请求用户授权，不能退化为未审计的 `git push`。
+
+本地事实中的 `executableTrackedPathCount` 大于 0 且 provider 为 Codeup 时，把
+`codeupCloneCredentialConfigured=true` 作为 publication plan 前置条件；`false` 或缺失证据都以
+`PUBLICATION_EXECUTABLE_MODE_UNSUPPORTED` 阻断。Personal AT 只证明 OpenAPI readiness。
+
+### 3. 协作补齐决策
+
+只询问 `UNRESOLVED`、低置信度或存在多个合理候选的字段：
+
+1. 每轮合并互不依赖的问题；最多 3 个问题。
+2. 每题提供 2–3 个互斥选项，把有证据的推荐项放第一并标注“推荐”。
+3. 每个选项说明影响，例如权限边界、资源成本、生产风险或以后迁移成本。
+4. 使用运行环境提供的结构化提问工具；若不可用，使用相同选项的简短文本问题。
+5. 允许用户通过 Other/自由文本输入精确 ID、名称或路径，并校验格式。
+6. 依赖前一答案的问题放到下一轮。例如先确认数据库类型，再询问 schema/instance。
+
+不要询问已经观察到且唯一的事实。即使只有一个平台候选，也要在最终清单中显示证据和目标 ID。
+
+### 4. 执行前确认
+
+所有必填字段明确后，按 checklist reference 输出最终确认清单，并单独列出：
+
+- 将创建或修改的外部资源；
+- 只记录、暂不执行的数据库/集群字段；
+- 是否会创建仓库、提交代码、推送分支、创建应用、创建流水线；
+- 是否会触发构建或部署；默认不触发；
+- 幂等键、目标 branch/HEAD、回滚或恢复入口；
+- 仍存在的告警和置信度。
+
+把每个外部步骤列成独立 child plan/run：Repository、Project Publication、Application、Jenkins Job、GitOps、legacy image migration、Jenkins GitOps rollout/readiness、Observer scope、首次 build。展示各自 plan number/hash、幂等键、预计副作用和恢复命令。首次 build 和生产部署永远是单独授权，不得包含在“创建应用”的笼统确认里。
+
+要求用户在“确认执行”和“返回修改”之间明确选择。未确认时不得调用 `--apply`、创建 SCM 连接、创建仓库、推送代码、触发流水线或执行部署。
+
+### 5. 预检与执行
+
+1. 重新执行所有关键只读检查，防止用户确认后平台状态变化。
+2. 要求现有仓库使用不可变 `expectedHead`；工作区有未提交变更时停止，并让用户决定提交范围。
+3. 对 `LOCAL_HISTORY_WITHOUT_REMOTE`，先用 `app begin` 幂等取得 sessionNo，再创建 consumer=`APPLICATION_ONBOARDING`、consumerRef=sessionNo 的 Repository plan；不要在 CLI 独立创建一个 `STANDALONE` publication plan。计划必须锁定本地 HEAD、manifest digest、目标 repository plan/ref 和默认分支；初始化方式服从 provider capability，例如 Codeup 使用受管 README 初始化后再 CAS 发布。
+4. 生成无凭据的 schemaVersion=3 onboarding spec 临时文件；固定 `mode=NEW`、`catalogStrategy=CREATE_NEW`、`repositoryStrategy=CREATE_NEW`、`projectStrategy=PUBLISH_PROJECT`，只引用不可变 Repository plan/ref、Jenkins/GitOps/Observer intent，不放 URL、token、本地路径或文件内容。必须用 `numa app onboard --session <app begin 返回值> --spec <file> --plan --json` 复用同一会话；parent apply 推进到 `WAITING_EXTERNAL / ATTACH_PUBLICATION_PLAN` 后才执行 `numa app publication attach`，由 session-scoped bridge 创建 `APPLICATION_ONBOARDING/<同一 sessionNo>` child plan。
+5. 先运行 `numa app onboard --session <app begin 返回值> --spec <file> --plan --json`；`PUBLISH_PROJECT` preflight 缺少 `--session` 时必须停止，不能隐式创建第二个 session。
+6. 展示服务端 plan、blocking errors 和任何规范化差异。差异实质改变确认内容时再次确认。
+7. 严格按父计划顺序 apply；每个 child 使用持久化幂等键。响应未知先按 status/events 找回，绝不生成第二套资源。
+8. 使用 `numa app inspect <sessionNo> --watch --json` 等到终态；断线时从最后 sequence 恢复。
+9. 只读核验 Application、Repository HEAD、Jenkins Job/binding、GitOps binding/scope 和 Observer evidence。除非用户另行明确要求，不触发 build/deploy。
+   旧 Jenkins image writer 需要迁移时，先用 `gitops service legacy-image-migration plan`；请求只能包含 application/target/profile/service stable references，当前没有 service binding 时不得猜测 `--service-id`。输出只展示 READY/BLOCKED、plan hash、blocker/recovery，不展示 path/diff/pointer。
+   Jenkins writer rollout 必须另行 plan/apply/readiness；readiness 只能是 `MANUAL_OPERATOR_ATTESTED`，不是 Jenkins live-read。CLI 不接受 secret/XML/env map/credential value，且 rollout 达到 READY/LEGACY 前不触发首次 build。
+10. 用户明确要求 promote/deploy 时，完成入驻后转入 `numa-jenkins-deployment` 的生产预检；应用创建确认不能替代生产审批。
+
+### 6. 失败与恢复
+
+- 响应不明时复用原 session 和 idempotency key；不要创建第二个会话。
+- 写请求返回 HTTP 2xx 但 CLI 解析失败时，视为“结果未知”；先用只读 list/inspect 核实，绝不直接重放。
+- Repository、standalone Publication、Jenkins Job 的写响应未知时，先用原 `clientRequestId` 执行各自 `status`；普通 session-scoped action 先 `app inspect`。`app publication attach` 是更严格的例外：CLI 必须用原 `sessionNo/clientRequestId` 有界轮询 `app publication resolve`，只有 200 same-session binding 且 `replayed=true` 才显示 `recovered_from_status`；retryable 404 `ONBOARDING_PUBLICATION_PLAN_NOT_RESOLVED` 只能稍后重查，不能先重放 attach。
+- 普通 session action 只有在写前 event cursor 之后出现、且与本次 planHash 或精确 intent 匹配的新持久事件时才能报告 `recovered_from_status`。既有 `WAITING_EXTERNAL`、旧 task/binding/scope/build 字段或信息不足的事件都只能返回 `onboarding_result_unknown`；当前 Jenkins binding 事件不含 `CONFIRMED`/expectedVersion，observer 事件不含完整坐标，first-build 累计输出也不含 action key/完整 intent，因此这三类未知写都必须 fail closed。Repository、Publication、Jenkins 的 resolve run 还必须匹配原 planNo；响应有 repository/workload identity 时一并匹配。
+- SCM 连接是平台级共享资源。缺失时把创建连接作为独立副作用列入确认，不要把它隐藏在应用创建中。
+- 代码库不可见、模板为空、用户不属于目标团队、env/cluster 不存在或 HEAD 已移动时停止执行，给出精确前置条件。
+- 生产构建/部署需要独立审批信息；应用入驻确认不能代替生产发布授权。
+- 平台 capability 缺失时保留父 session 和已完成 child evidence。不要绕过平台直接创建目录记录、Jenkins Job、Flux 文件或 Observer ACTIVE 状态。
+- legacy image migration plan 没有 Idempotency-Key/resolve-by-key，结果不明时必须 fail closed，不自动重放。Jenkins rollout plan create 也没有 resolve-by-key；apply 只有当 list 显示 exact application/instance/plan mode 且较写前 baseline version 增长才报告恢复；readiness 只有 GET 同 rollout 显示 exact reference/mode/status/identity 且 version 增长才报告恢复。预存 READY/LEGACY 不是本次写入证据。
+
+所有展示给用户的命令必须可直接复制：不要带 diff 的字面 `+`/`-` 前缀，不要把 shell continuation
+写成伪格式，也不要在命令中展开凭据、绝对本地路径或文件内容。
+
+## 完成标准
+
+只有以下条件全部满足才报告成功：
+
+- 应用目录存在且字段与确认清单一致；
+- 代码库绑定到确认的 provider、repository 和不可变 HEAD；
+- 本地源码发布场景中，远端 tree/commit evidence 与锁定 manifest/HEAD 一致；
+- 流水线绑定存在，tier/branch/buildability 符合确认；
+- 要求 GitOps 时，service binding、scope 和运行态 evidence 状态明确；未达 ACTIVE 时返回具体 recovery action；
+- 未意外触发构建或部署；
+- session 终态明确，idempotency key 和安全的资源 ID 已记录；
+- 数据库/集群待办明确标为已执行或 `DEFERRED`，没有把推断值冒充平台事实。

package/skills/numa-create-application/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Numa 应用创建"
+  short_description: "安全规划本地源码、仓库、Jenkins、GitOps 迁移与 writer rollout 的完整 promote"
+  default_prompt: "使用 $numa-create-application 分析当前项目，先自述运行时能力，再协作确认并通过 Numa CLI 完成 Repository、源码发布、应用、Jenkins、GitOps legacy writer 迁移与 rollout/readiness 计划；默认不触发构建或部署。"

package/skills/numa-create-application/evals/evals.json

@@ -0,0 +1,75 @@
+{
+  "skill_name": "numa-create-application",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "我有一个现有 Java 项目 /workspace/active-code-inbox，Git 工作区干净，main HEAD=d510f0f6，Jenkinsfile 里的 APP_NAME=code-index，但没有任何 git remote。Codeup 连接 codeup-numa 已登记，目标组织路径是 numa/framework，最终要接入生产 prd。请给出可执行的 promote 计划，但现在不要创建资源、推送代码、构建或部署。",
+      "expected_output": "把源码判定为 LOCAL_HISTORY_WITHOUT_REMOTE，推断稳定应用码 code-index；生成 Repository README 初始化、schemaVersion=3 parent、session-scoped Project Publication、Jenkins Job、GitOps/Observer 和独立首构建/生产审批，不使用裸 git push或第二个 onboarding session。",
+      "files": [],
+      "assertions": [
+        "明确分类为 LOCAL_HISTORY_WITHOUT_REMOTE，并且没有把无 remote 当成无法处理的普通 blocker。",
+        "应用码使用 Jenkins APP_NAME 的 code-index，而不是直接使用目录名 active-code-inbox。",
+        "Repository 计划使用受管 Codeup connection、numa/framework、PRIVATE，并说明 Codeup 新仓需要 README 初始化后再 CAS publication。",
+        "Project Publication 锁定本地 HEAD 和 manifest/tree digest，拒绝把本地路径、凭据或原始 git push 当成默认执行路径。",
+        "Application onboarding 使用 schemaVersion=3 CREATE_NEW/PUBLISH_PROJECT；Repository child 完成后通过同一 session 的 app publication attach 创建 consumer-bound child，不另建 ATTACH_EXISTING session。",
+        "Jenkins Job、GitOps、Observer scope、首次 build、生产部署被拆成独立 child plan/run；当前请求不会触发 build/deploy。"
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "请把 /workspace/order-api 接入 Numa。仓库干净，origin 已映射到受管 repositoryKey=codeup-numa:143926:order-api，main 本地和远端 HEAD 都是 4f7d9b1。应用属于 Team Order，先接入 stg，不要触发 Jenkins 构建。请给计划并说明当前能力边界。",
+      "expected_output": "识别 REMOTE_TRACKED 并复用受管仓库，不创建第二仓；锁 expectedHead，形成 onboarding、NoTrigger Jenkins Job、GitOps/Observer 计划及运行时能力矩阵。",
+      "files": [],
+      "assertions": [
+        "明确分类为 REMOTE_TRACKED，并核对本地 HEAD 与远端 HEAD 相等。",
+        "复用 repositoryKey=codeup-numa:143926:order-api，不生成 CREATE 新仓计划。",
+        "Application 计划锁定不可变 expectedHead=4f7d9b1，并保留 Team Order 的成员资格校验。",
+        "输出 AVAILABLE/MANUAL_BRIDGE/UNAVAILABLE 能力矩阵，结论由运行时 command catalog/capability 证明。",
+        "Jenkins Job 采用 NoTrigger 或等价不构建计划，明确 scan/index 与 build 不相同。",
+        "GitOps target/service binding、Observer scope/evidence 与首次 build 分开，当前请求不会构建。"
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "把当前 /workspace/payment-service 直接 promote 到生产。仓库已有 origin，但 git status 显示 7 个已修改文件和 2 个未跟踪文件；平台已经有 production target。我希望你顺手提交、推送并马上构建。",
+      "expected_output": "识别 DIRTY_WORKTREE 并在任何 publication/apply 前停止；不自行提交、stash、reset、push；列出恢复路径，并把生产构建审批与应用接入确认分离。",
+      "files": [],
+      "assertions": [
+        "明确分类为 DIRTY_WORKTREE，并在所有 publication/apply/构建动作前停止。",
+        "只报告变更数量，不读取或打印未提交文件内容与可能的敏感信息。",
+        "不执行或建议默认执行 commit、stash、reset、push 来绕过用户确认。",
+        "给出用户先确定提交范围、形成 clean immutable HEAD、再重新 plan 的恢复步骤。",
+        "生产 build/deploy 要求独立审批依据，不能由 promote 或应用创建确认替代。",
+        "不会因为 production target 已存在就声称 GitOps binding/Observer evidence 已完成。"
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "我有一个 clean 的本地 Git 项目 /workspace/report-runner，HEAD=7a6b5c4d，Jenkins APP_NAME=report-runner，没有 remote；仓库里有一个已提交的 100755 脚本。目标 Codeup connection 显示 OpenAPI access token ready，但 HTTPS clone credential readiness 未知。普通 Numa 网关刚才在 publication attach 返回时断开。请给安全的恢复与后续 promote 命令模板，不访问外部系统，也不要执行写操作。",
+      "expected_output": "先通过 app/child runtime capabilities 自述，并用原 session/clientRequestId 的 app publication resolve 恢复 attach 结果；把 Codeup HTTPS clone readiness 作为 100755 publication blocker；保持同一 schemaVersion=3 CREATE_NEW/PUBLISH_PROJECT session，且命令可复制、无 diff + 前缀和 port-forward 旁路。",
+      "files": [],
+      "assertions": [
+        "先使用 app capabilities、command catalog 和 child capability 形成 AVAILABLE/MANUAL_BRIDGE/UNAVAILABLE 能力矩阵；服务端 Project Publication action 必须是 PLAN_PUBLICATION，app publication attach/resolve 由本地命令目录证明，不能把 transport recovery 命令虚构为服务端 capability。",
+        "100755 + Codeup 场景要求 codeupCloneCredentialConfigured=true；readiness 未知时以 PUBLICATION_EXECUTABLE_MODE_UNSUPPORTED 阻断，不把 Personal AT 当 Git 密码。",
+        "publication attach 写响应未知时先用同一 session 和原 clientRequestId 执行 app publication resolve；只有 200 same-session binding/replayed=true 才报告恢复，retryable 404 稍后重查，不先重放 attach 或生成新 plan/session。",
+        "完整链保持同一 session 的 schemaVersion=3、catalog/repository CREATE_NEW、PUBLISH_PROJECT、README 初始化后 CAS 完整 tree。",
+        "Jenkins Job NO_BUILD、GitOps、Observer evidence 与首次 build/生产审批是独立 gate；当前不触发 build/deploy。",
+        "不建议 kubectl port-forward、SSH tunnel 或后台代理；所有 shell 命令没有字面 diff + 前缀、绝对本地路径、凭据或文件内容。"
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "code-index 已有应用和 confirmed Jenkins binding，要 promote 到 prd。现有 overlay 缺 Jenkins image writer pointers，当前还没有 GitOps service binding。Jenkins instance=numa，服务端批准的 shared-library commit=230e0f00444dfd1874e1ab3e624381341a0c31c5。请给 migration 和 rollout 命令计划，但不访问外部系统、不做任何写入或构建。",
+      "expected_output": "把 legacy migration 作为 GitOps materialize/apply 前置，使用 prd 且不猜测 service-id；规划 instance=numa 的 exact approved revision rollout，把 MANUAL_OPERATOR_ATTESTED readiness 和首次 build 分开，所有未知结果 fail closed。",
+      "files": [],
+      "assertions": [
+        "migration 命令是 numa gitops service legacy-image-migration plan --application code-index --target prd，当前没有 binding 所以不带 --service-id，也不接受 YAML/path/image/secret。",
+        "migration 仅在 overlay 缺 writer pointers 时作为 GitOps materialize/apply 前置；普通 GitOps plan 已产生合规 pointers 时跳过。",
+        "rollout plan 使用 --instance numa 和 exact revision 230e0f00444dfd1874e1ab3e624381341a0c31c5；plan/apply/readiness 写命令都有稳定 idempotency key 与 --yes，但当前不执行。",
+        "rollout apply 只持久化 fail-closed gate，不连接 Jenkins、不改全局配置、不触发 build。",
+        "readiness 明确是 MANUAL_OPERATOR_ATTESTED 而不是 Jenkins live-read；CLI 不接受 secret/XML/env map/credential value，只回传 server GET 的 exact tuple 和 reference names。",
+        "migration/rollout plan 未知结果不自动重放；apply/readiness 只在写前 baseline 之后出现 exact intent 且 version 增长才恢复，预存 READY/LEGACY 不是证据。"
+      ]
+    }
+  ]
+}

package/skills/numa-create-application/references/checklist.md

@@ -0,0 +1,130 @@
+# 应用入驻确认清单
+
+## 目录
+
+- [状态模型](#状态模型)
+- [完整字段](#完整字段)
+- [草案格式](#草案格式)
+- [最终确认](#最终确认)
+
+## 状态模型
+
+每项记录 `value`、`state`、`confidence`、`evidence`、`requiredBefore`：
+
+- `OBSERVED`：权威事实；
+- `INFERRED`：推荐值，等待确认；
+- `CONFIRMED`：用户确认；
+- `UNRESOLVED`：阻止 plan/apply；
+- `DEFERRED`：当前能力未提供，不得声称已配置。
+
+`requiredBefore` 使用 `PLAN`、`APPLY`、`FIRST_DEPLOY` 或 `FUTURE_DATABASE_PROVISION`。
+
+## 完整字段
+
+### 目标和身份
+
+- Numa version、profile ID、API origin、tenant、目标环境级别；
+- runtime command catalog、`app capabilities` 与各 child capability 状态；
+- 当前用户 subject/username/email；
+- 平台角色、团队成员关系及最低所需成员级别；
+- 操作范围：仅 plan、创建应用/仓库/流水线、是否触发 build/deploy。
+
+### 应用归属
+
+- application code、name、description/status；
+- teamId/team code、成员资格证据；
+- systemId/system code；
+- business-domain ID/code；
+- owner/maintainer 联系边界。
+
+### 项目和代码库
+
+- 本地目录、技术语言/框架、构建系统；
+- Git dirty 状态、branch、HEAD、remote；
+- source state：REMOTE_TRACKED/LOCAL_HISTORY_WITHOUT_REMOTE/REMOTE_WITHOUT_UPSTREAM/DIRTY_WORKTREE/UNVERSIONED_DIRECTORY；
+- mode：NEW/EXISTING；repoMode：STANDALONE/ADD_MODULE；
+- SCM connection/provider/organization；
+- repository namespace/name/externalId/defaultBranch/expectedHead/visibility；
+- 模板 code/revision、技术栈 code、模板参数；
+- 缺仓库时的创建、首次提交和推送策略。
+- publication manifest/version/digest、文件数/总字节、排除项、plan/run/idempotency key；
+- executable tracked file count；Codeup HTTPS clone credential readiness（只记录 boolean）；
+
+### 构建和流水线
+
+- MCI build-flow、APP_NAME、APP_HOME、agent label、Node/JDK/Python version；
+- PORT=8080、启动入口、健康检查；
+- Jenkinsfile/Dockerfile 策略；
+- jenkinsRequired、tiers、trigger branch、manual/webhook；
+- build parameters（仅非敏感）、Sonar、artifact/image name；
+- 是否只创建流水线，是否触发 build/deploy。
+- Jenkins Job plan/run/config digest、inventory generation、binding confirmation；
+- Jenkins GitOps rollout plan/hash、application/instance/mode、approved shared-library revision、status/version；
+- trusted readiness 证据源必须为 `MANUAL_OPERATOR_ATTESTED`、外部 operator action reference 与 exact tuple/reference names（不记录 credential value/XML/env map）；
+
+### 环境和运行位置
+
+- defaultEnvironmentId/env code/tier；
+- clusterId/name、region、tenant/network zone、architecture；
+- Kubernetes namespace、replicas、resource profile；
+- GitOps target/profile/service plan、binding、Observer scope 与 live evidence；
+- 现有 overlay 是否缺 writer pointers；legacy migration 是否必要、READY/BLOCKED、plan hash、blockers/recovery；没有 binding 时 `serviceId` 必须留空，不得猜测；
+- ingress/domain、service port、readiness/liveness；
+- 与数据库/外部依赖的网络可达性。
+
+### 数据库
+
+- needed、engine/version、shared/dedicated；
+- instanceId/code/name、environment/region/network；
+- database name、schema、owner role；
+- HA/replicas/storage、backup/retention；
+- migration tool/owner；
+- secret injection mechanism（只记录引用方式，不记录 secret）；
+- capability：AVAILABLE 或 `DEFERRED`。
+
+### 治理和恢复
+
+- onboarding sessionNo/revision/planHash/idempotency key；
+- Repository、Publication、Jenkins、GitOps、Observer 各 child plan/run 和 last event sequence；
+- migration plan 和 Jenkins rollout plan/apply/readiness 的 unknown-result baseline/readback 证据；旧 READY/LEGACY 不得记为本次 recovered；
+- 预期外部副作用；
+- 生产审批需求；
+- blocking warnings、恢复动作和回滚边界。
+- 写响应是否由原响应确认或由写前 cursor 之后、精确匹配本次 intent 的新持久证据恢复；既有状态不得标为 `recovered_from_status`。publication attach 必须记录原 sessionNo/clientRequestId、resolve 200 same-session binding/replayed=true，或 retryable 404 待恢复状态；禁止的 port-forward/tunnel 旁路。
+
+## 草案格式
+
+先输出紧凑表格：
+
+| 类别 | 参数 | 建议/事实 | 状态 | 置信度与证据 |
+|---|---|---|---|---|
+| 应用 | code | `order-service` | INFERRED | HIGH：Jenkins APP_NAME |
+| 归属 | teamId | `12 / payments` | UNRESOLVED | MEDIUM：同系统应用多数归属 |
+| 环境 | envId | `2 / dev1` | INFERRED | HIGH：唯一 active DEVELOP 环境 |
+| 数据库 | instanceId | — | DEFERRED | 数据库 CLI 尚未提供 |
+
+表格后列出：
+
+1. 可直接采用的观察值；
+2. 推荐决策及原因；
+3. 本轮要问的问题；
+4. 当前 blockers；
+5. 未来能力待办。
+
+## 最终确认
+
+执行前用以下顺序展示：
+
+1. **身份与目标**：谁、在哪个 profile/tenant、操作哪个环境；
+2. **应用归属**：code/name/team/system/domain；
+3. **代码库**：provider/connection/repo/branch/HEAD，以及是否创建和推送；
+   本地无 remote 时另列 publication manifest digest、bundle 边界和是否需要人工桥接；
+4. **技术与构建**：stack/template/build-flow/8080/health；
+5. **部署位置**：envId/cluster/namespace/tier；
+6. **数据库**：engine/instance/database/schema，明确 AVAILABLE 或 DEFERRED；
+7. **将发生的写操作**：逐项编号；
+8. **不会发生的操作**：默认包括 build、production deploy 和 secret 写入；
+9. **恢复信息**：session/idempotency key/结果未知处理；
+10. **未决告警**：必须为空才允许 apply；`DEFERRED` 项需明确不影响本次 apply。
+
+最后只提供“确认执行（推荐，仅在清单无 blocker 时）”和“返回修改”两类选择。用户确认后仍要做一次只读漂移检查。

package/skills/numa-create-application/references/inference-rules.md

@@ -0,0 +1,69 @@
+# 参数推断规则
+
+## 目录
+
+- [证据优先级](#证据优先级)
+- [应用和团队](#应用和团队)
+- [代码库](#代码库)
+- [技术栈](#技术栈)
+- [环境和集群](#环境和集群)
+- [数据库](#数据库)
+
+## 证据优先级
+
+按以下顺序使用证据：平台权威 API > 已提交仓库配置 > Git remote/HEAD > 用户明确描述 > 命名约定。冲突时展示冲突，不自动选低优先级值。
+
+置信度建议：唯一权威映射为 HIGH；两个独立证据一致为 MEDIUM/HIGH；仅名称相似为 LOW。LOW 值必须询问。
+
+## 应用和团队
+
+- 应用 code 优先取已存在 catalog code，其次 Jenkins `APP_NAME`，再取 remote 仓库 slug，最后取根 package/project 名。
+- code 使用小写 kebab-case；不要静默改动已部署镜像名或稳定 API 标识。
+- 应用团队代表业务/运维责任，不等同于 Codeup group、Keycloak group 或 Kubernetes namespace。
+- 团队候选依次参考：已有同系统应用、CODEOWNERS/maintainer、仓库 namespace、package scope、当前用户团队成员关系。
+- 只推荐当前用户至少具有平台要求成员级别的团队。成员关系无法证明时必须询问或停止。
+- systemId 优先复用同一产品族的系统；business domain 只提供背景，不能替代 systemId。
+
+## 代码库
+
+- 已有 remote 且平台 SCM 能返回同一仓库时使用 `EXISTING`，固定 `externalId`、default branch 和 `expectedHead`。
+- remote 不存在但平台有同名仓库时，先确认是否接管；不得只凭名字认领。
+- 没有代码库时，从应用 code 推断 repository name，从已确认团队/系统推断 namespace；检查名称冲突和 SCM create capability。
+- 已有 clean Git HEAD 但 remote 列表为空时分类为 `LOCAL_HISTORY_WITHOUT_REMOTE`。它不是受管模板 NEW：先锁定同 application code 的私有 Repository CREATE plan（Codeup 使用受管 README 初始化），再创建 schemaVersion=3 parent，并通过 session-scoped Publication child 发布现有 tree；继续同一 session，不转成第二个 ATTACH_EXISTING。
+- Jenkins `APP_NAME`、线上镜像/HelmRelease 名称和目录名冲突时，优先稳定运行身份；目录名只作为低优先级线索。不得因此创建两个远端仓库。
+- 新仓库优先私有、默认分支 `main`，除非组织标准或现有项目明确使用其他分支。
+- 模板为空或 SCM 没有 CREATE capability 时，不绕过 Numa 直接造目录记录。给出缺少模板、连接、权限或仓库的前置清单。
+- 工作区不干净、无 commit 或 HEAD 与远端不一致时，不创建基于该 HEAD 的流水线。
+- publication capability 不可用时标记 `MANUAL_BRIDGE`，不要把普通 `git push` 伪装成平台自动化。人工桥接必须单独确认并读回 remote HEAD。
+
+## 技术栈
+
+- 从构建文件、依赖和产物识别实际框架，再与 `numa` 返回的 technology stack 匹配。
+- 不把通用 Fastify/Express 项目伪装成 NestJS，也不把 Vite SPA 伪装成 Next.js。
+- 没有精确 stack 时显示实际检测结果和最接近候选，要求用户确认平台映射或先注册 stack。
+- 创建前检查 MCI 构建标准：Jenkins `buildEntry()`、APP_NAME、构建节点、8080/PORT、启动入口和 Dockerfile 保留理由。
+
+## 环境和集群
+
+- envId 只能来自 Numa/platform 权威环境列表，不能从 `dev1`、`stg1`、`prod` 字符串自行构造 ID。
+- 未明确要求生产时优先推荐可用的 DEVELOP 环境；不得默认生产。
+- 集群优先选择 envId 显式绑定的 active/ready 集群；其次匹配 tenant、region、网络区和 workload class。
+- 同一 env 有多个集群时比较容量、架构、合规标签、数据库网络可达性和现有同系统应用分布，并询问用户。
+- 一等 cluster CLI 不存在时，通过已批准的只读 API收集候选；没有权威数据时标记 `DEFERRED`，不要编造 clusterId。
+- namespace 默认候选为应用 code，但必须检查平台命名策略和冲突。
+
+## 数据库
+
+先判断是否需要持久化：
+
+- 没有 ORM/driver/migration/config 信号时推荐 `NONE`。
+- `pg`、PostgreSQL URL、Drizzle/Postgres migration 等信号推荐 PostgreSQL。
+- `mysql2`/MariaDB 信号推荐 MySQL；Mongo driver/Mongoose 推荐 MongoDB；SQLite 只默认用于本地开发，不能自动当作生产数据库。
+
+数据库清单至少包含：engine、version、shared/dedicated、instanceId、database name、schema、owner、environment、region/network、HA、backup/retention、migration owner、secret injection。不得推断密码或连接串。
+
+- PostgreSQL shared instance 推荐独立 database role 和独立 schema；schema 候选为应用 code 转 snake_case，限制在 63 bytes 内。不要默认使用 `public`。
+- PostgreSQL dedicated database 可让 database name 与应用 code 的 snake_case 一致，但 database 和 schema 仍分别确认。
+- MySQL 的 schema 与 database 通常同义，在清单中明确标注。
+- instanceId 必须来自平台数据库 inventory。当前 CLI 无该能力时标记 `DEFERRED`，同时保留期望 engine/schema/环境供以后升级。
+- 数据库选择必须与目标 env/cluster 网络可达性一致。先确认 env/cluster，再最终选择 instance。