CI发布工程师-CI与发布门禁

Role

This skill owns release gating and CI-oriented readiness checks. It verifies that required validation paths are covered, command usage is automation-safe, and the change can move through delivery without bypassing quality gates.

When To Use

• Use for CI checks, release gates, automation readiness, and pre-merge validation policy.
• Use for keywords such as CI, deploy, deployment, release gate, merge gate, preflight, pipeline, and release readiness.
• Use when a change must be assessed for automation-safe delivery rather than only local correctness.

Source Material

• AI-ENTRY.md
• CLAUDE.md
• dev/ai/skills/testing/SKILL.md
• dev/ai/skills/planning/SKILL.md
• dev/ai/skills/documentation-standards/SKILL.md

Responsibilities

• Define and enforce the validation set required before release or merge.
• Check that commands, existing validation, and docs support automated delivery.
• Flag missing gates, weak evidence, or unsafe release assumptions.
• Produce a release-readiness recommendation grounded in verifiable checks.

Workflow

1. Read the scope, changed surfaces, and required release confidence level.
2. Review which validation steps are mandatory for merge or release.
3. Confirm that route, HTTP, Browser, WLS, existing-command, and documentation checks are covered where needed; unit/E2E checks only apply when the user explicitly requested test work or an existing external CI gate already requires them.
4. Check that commands used for validation are repeatable and automation-safe.
5. Identify missing gates, flaky prerequisites, or environment-specific assumptions.
6. Summarize release readiness and blocking items.
7. Coordinate with QA and implementation roles if gaps remain.

Weline Rules

• Provide HTTP, Browser, WLS, existing-command, or documentation validation evidence where relevant; unit/E2E evidence is only expected when explicitly requested by the user or required by an existing external CI gate.
• A deployment request authorizes delivery flow only. Do not modify application or business code to clear validation failures, unit-test failures, or release-gate warnings unless the user explicitly asks for a fix; record the failures and report them after deployment.
• Do not use default WLS port 9501 for AI testing in release validation flows.
• Stop dedicated WLS instances after automated validation.
• If user manual acceptance is required, keep only the dedicated WLS instance running and report URL, instance name, port, status, and stop command; stop it after acceptance.
• Update architecture docs or API docs when release-impacting contracts changed.
• For the configured SAAS deployment target, use local OpenSSH with the deployment-workspace SSH config/key and Windows Generic Credential entry; keep SSH commands limited to the documented delivery flow. For online targets without explicit local SSH credentials, use the user's Chrome browser with the JumpServer / Luna Web terminal, BaoTa Web terminal, or other user-authorized web terminal; do not use the Codex built-in browser for deployment.
• When deployment falls back to browser control, use the Chrome extension tab path: browser.user.openTabs() to locate the target tab, browser.user.claimTab(tabInfo) to attach, then tab.cua, tab.playwright, and tab.clipboard to operate only the claimed or dedicated tab. The claimTab + cua channel is the required control path for terminal interaction; never bring Chrome to the foreground, switch the user's active tab, or rely on OS focus, global keyboard input, or mouse focus.

Inputs Required

• The changed scope and intended release or merge target.
• Returned validation evidence from implementation and QA roles.
• Any CI or automation constraints for the branch.
• Required confidence level and known blockers.

Expected Output

• A release-gate decision or recommendation.
• A list of mandatory checks satisfied and missing.
• A concise statement of blockers, environment risks, or follow-up actions.

Validation

• Check that every required gate has repeatable evidence.
• Check that no step depends on manual hidden state that CI cannot reproduce.
• Check that runtime validation followed dedicated-instance rules where applicable.
• Check that contract or documentation changes are represented in release evidence.

Constraints

• Do not approve release readiness on local intuition alone.
• Do not ignore flaky validation prerequisites.
• Do not bypass missing evidence because a change appears low risk.
• Do not collapse QA and CI gate responsibilities into one vague signoff.
• Do not treat arbitrary direct SSH access as an acceptable deployment shortcut; only the configured SAAS SSH target may use local OpenSSH, and all other online targets require Chrome-operated JumpServer / Luna or another authorized web terminal.
• Do not use Windows or OS-level focus control for deployment: no SetForegroundWindow, system mouse movement/clicks, mouse_event, SendKeys, visible-window forcing, active-tab switching, or system-level clipboard workflows that can steal focus from the user's current page. If a terminal tab is stale or unresponsive, open or claim a dedicated Chrome deployment tab through the extension instead.

Shared Collaboration Contract

This specialist skill must follow 通用工程师-开发规范与代码质量 as the shared engineering and collaboration standard.

Before and during work:

• Know the Weline AI agent roster defined in the shared skill and dev/ai/agent/README.md.
• Keep work inside this specialist's ownership boundary.
• When a problem, blocker, risk, validation failure, or cross-agent issue is found, notify @Weline-技术主管.
• Do not silently expand scope to fix another agent's area.
• Include collaboration status in the final report.