1e3989d0d7
Enterprise 2026-10-03 实测：为避开主工作区里其他会话的在制品，在独立 worktree
分支上开 PR 交付时，get_delivery_status 只读主工作区当前分支，返回「当前分支没有
开放 PR」、CI 停在主工作区 HEAD，传 pr_number 也被忽略，只能用 git ls-remote 与
get_ci_status(commit_sha) 兜底。
- MCP schema 新增可选 pr_number（优先）与 branch；都不给时保持原行为
- pr_number：GET /pulls/{n} 取 head 分支与 head SHA，CI 与 review 均绑定该 PR；
PR 不存在（404）返回 not_found，与 Gitea 不可达（unavailable）区分；
同时传 branch 且与 PR head 分支不一致时以 pr_number 为准并在 detail 提示
- branch：匹配该分支的开放 PR 并以其 head SHA 查 CI；无开放 PR 时取 Gitea 上
该分支 head SHA；远端分支不存在时 CI 为 unknown
- 顶层新增 target（mode/pr_number/branch/head_sha/source/detail），
pull_request.data 增 head_sha；git 字段仍反映主工作区，既有字段兼容
- 取值校验在能力本体 DeliveryQuery 单点实现，MCP 只解析 JSON 类型；显式给出的
非法值直接报错，不静默回退主工作区
- Gitea 读取拆为本地/PR/分支三种目标，凭证存储注入以便合成 Gitea 测试；
merge_pull_request 门禁代码未改
- lian-jing skill 第 6 条改为 get_delivery_status(project_id, pr_number)，
base-onboarding 1.8.0→1.9.0（BASE_ONBOARDING_PACK_VERSION、模板
capability-packs.json、TEMPLATE_FINGERPRINTS）；Codex 插件 skill 同步
- 契约说明同步 docs/ai-context/project-context.yaml；蓝图 P3-F 标 ✅
Feature-Confirmed: true
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
20 lines
3.0 KiB
Markdown
20 lines
3.0 KiB
Markdown
---
|
||
name: lian-jing-project
|
||
description: Inspect an already onboarded Lian Jing project, use its existing MCP tools for status, and preserve project-owned development decisions. Use when a Codex task needs Lian Jing onboarding or delivery context; do not use to configure credentials, deploy, or infer an unregistered project identity.
|
||
---
|
||
|
||
# 炼境项目上下文
|
||
|
||
在已接入炼境的项目中，需要读取接入状态、交付信号或提交分组建议时使用本 Skill。
|
||
|
||
1. 先读取项目根目录的 `AGENTS.md`、`.blueprint/` 规则和 `.lian-jing/context.json`。
|
||
2. 仅将 `.lian-jing/context.json` 中的 `project_id` 用作炼境 MCP 调用参数。`.claude/liangjing.json` 只用于识别旧项目并提示迁移，不能作为长期身份来源。
|
||
3. 当项目已有 `lian-jing` MCP 时，可调用 `get_diagnostics`、`verify_onboarding`、`get_toolchain_status` 和 `get_delivery_status` 获取可观察信号。scoped 连接已绑定当前项目，可省略 `project_id`；仅在 initialize 报告 legacy 时显式传 canonical `project_id`，不得越界。
|
||
4. Node/pnpm 项目运行包管理命令前先读取工具链状态；`ready_managed` 时使用 `mise exec -- pnpm ...`。只有用户明确确认下载安装后，才可调用 `prepare_toolchain(project_id, confirmed=true)`；不得为适配 Codex bundled runtime 修改项目版本或 lockfile。
|
||
5. 合并 PR 前调用 `get_delivery_status(project_id, pr_number)`，按 PR 编号读取：head 分支与 head SHA 以 Gitea 为准，不受主工作区当前分支影响，在独立 worktree 分支上交付同样适用（不传 `pr_number` 时只看主工作区当前分支）。向用户展示 PR 编号、完整 head SHA、CI 与 review。只有当前用户明确确认该 PR 与 SHA 后，才调用 `merge_pull_request(project_id, pr_number, expected_head_sha, confirmed=true)`；合并后再次读取交付状态。不得自行推断确认。
|
||
6. 生成 CI workflow 时先调用 `plan_cicd_workflow(project_id, workflow_type)`，向用户展示目标文件、变更类型、`content_digest`、工具链来源与所需 secret 名称；只有用户明确确认这份摘要后，才以同一 digest 调用 `apply_cicd_workflow(..., confirmed=true)`。该流程只写项目 workflow，不配置 secret、不触发 CI 或部署；不得通过 MCP 传服务器地址、命令、路径或 secret 值，部署类配置先由用户在炼境 UI 保存。
|
||
7. 若缺少 MCP，依次判断 configured（scoped URL）→ reachable（炼境 loopback）→ reload（新建任务/重载客户端）；停在哪层就报告哪层。缺少 canonical context 或项目登记时不得猜测 project_id、MCP URL、凭证或状态，并建议通过炼境接入或 `inject_mcp` 修复。
|
||
8. 炼境提供状态、凭证托管和受控入口；项目 Agent 仍负责代码判断、测试选择、提交分组与业务交付决策。不要把 CI 成功或部署信号表述为业务验收。
|
||
|
||
本插件不包含 MCP server、MCP URL、项目 ID、凭证、部署命令或客户端项目 UI 映射；这些都属于项目接入与炼境控制面。
|