ai-sdlc-validation

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

ai-sdlc-validation: Validation Command Selection

ai-sdlc-validation：验证命令选择

Internal AI SDLC skill, not client-facing by default. Every rule below is important to follow. None of it can be skipped. Before producing the final artifact, confirm required inputs, target audience, missing facts, output format, and constraints when they are unclear. Do not invent missing information. Ask concise clarification questions when required inputs are absent.

内部AI SDLC技能，默认不面向客户。以下每条规则都必须遵守，无一例外。在生成最终产物前，若必要输入、目标受众、缺失信息、输出格式和约束条件不明确，请先确认。不得编造缺失信息。当必要输入缺失时，提出简洁的澄清问题。

0. Skill Card

0. 技能卡片

Skill name:
```
ai-sdlc-validation
```
Primary audience: Dev
Supporting audience: QA, BA
Audience tags: Dev, QA, BA
SDLC stage: Implementation validation
Purpose: Select, run, and report focused deterministic validation checks for AI SDLC code, SQL, API, provider, SDD, documentation, and tool-governance changes.
Output: Focused validation commands, outcomes, coverage notes, and residual risk

技能名称：
```
ai-sdlc-validation
```
主要受众：开发人员（Dev）
支持受众：测试人员（QA）、业务分析师（BA）
受众标签：Dev、QA、BA
SDLC阶段：实现验证
用途：为AI SDLC的代码、SQL、API、供应商、SDD、文档和工具治理变更选择、运行并报告针对性的确定性验证检查。
输出：针对性的验证命令、结果、覆盖范围说明和残留风险

0.1 Required Inputs

0.1 必要输入

Changed files, diff, or explicit validation target.
Active spec and QA context when user-visible or release-sensitive.
Sandbox constraints and previous validation output if relevant.

变更文件、差异或明确的验证目标。
当涉及用户可见或发布敏感内容时，需提供当前规范和QA上下文。
若相关，需提供沙箱约束和之前的验证输出。

0.2 Clarification Rules

0.2 澄清规则

Ask concise questions before finalizing when role, artifact, requirements, scope, audience, or constraints are unclear.
If optional information is missing, mark it as
```
TBD
```
,
```
Not provided
```
, or
```
Assumption
```
instead of inventing it.
Separate confirmed facts from assumptions and open questions.
Do not proceed to downstream synthesis when a required upstream artifact or decision is missing.

当角色、产物、需求、范围、受众或约束条件不明确时，在最终确定前提出简洁的问题。
若可选信息缺失，标记为
```
TBD
```
、
```
未提供
```
或
```
假设
```
，不得编造。
将已确认事实与假设和未解决问题分开。
当必要的上游产物或决策缺失时，不得进行下游合成工作。

0.2.1 Flow Mode Flags

0.2.1 流程模式标志

Support two explicit execution flags:
```
--quick-flow
```
and
```
--full-flow
```
.
If both flags are supplied,
```
--full-flow
```
takes precedence because it is the stricter mode.
```
--quick-flow
```
: move fast, make high-quality progress with available context, avoid clarification questions unless continuing would create material product, security, compliance, data-loss, or irreversible implementation risk.
In
```
--quick-flow
```
, use documented assumptions, recommended defaults, existing repository patterns, and the nearest available artifact evidence; record important assumptions and decisions in
```
decision-log.md
```
.
In
```
--quick-flow
```
, run only focused checks that are directly relevant, cheap, and likely to catch regressions for the requested work; report any skipped broader checks as residual risk.
```
--full-flow
```
: ask concise clarification questions when inputs, scope, ownership, acceptance criteria, or decisions are unclear; do not silently assume material requirements.
In
```
--full-flow
```
, verify upstream and downstream artifacts, decision-log entries, traceability links, acceptance criteria, and validation evidence before finalizing.
In
```
--full-flow
```
, run or recommend the skill-appropriate gates, reviews, scripts, and validation commands needed for end-to-end confidence; document any blocked verification explicitly.
When neither flag is supplied, follow the skill default rules and choose the least risky behavior for the request size and domain.

支持两种明确的执行标志：
```
--quick-flow
```
和
```
--full-flow
```
。
若同时提供两个标志，
```
--full-flow
```
优先，因为它是更严格的模式。
```
--quick-flow
```
：快速推进，利用现有上下文取得高质量进展，除非继续执行会造成重大产品、安全、合规、数据丢失或不可逆实现风险，否则避免提出澄清问题。
在
```
--quick-flow
```
模式下，使用已记录的假设、推荐默认值、现有仓库模式和最近可用的产物证据；将重要假设和决策记录在
```
decision-log.md
```
中。
在
```
--quick-flow
```
模式下，仅运行与请求工作直接相关、成本低且可能发现回归问题的针对性检查；将所有跳过的更广泛检查作为残留风险报告。
```
--full-flow
```
：当输入、范围、所有权、验收标准或决策不明确时，提出简洁的澄清问题；不得默默假设重要需求。
在
```
--full-flow
```
模式下，在最终确定前验证上游和下游产物、决策日志条目、可追溯性链接、验收标准和验证证据。
在
```
--full-flow
```
模式下，运行或推荐适合技能的关卡、评审、脚本和验证命令，以确保端到端的可信度；明确记录任何被阻止的验证工作。
当未提供任何标志时，遵循技能默认规则，并根据请求规模和领域选择风险最低的行为。

0.3 Output Rules

0.3 输出规则

Keep output structured with headings and bullets.
Make findings, gaps, risks, and blockers explicit.
Tie recommendations to evidence from the provided artifact, repository,
```
specs-refiniment/<feature-name>/<file.md>
```
workspace, or user context.
Include role ownership when the output creates follow-up work for BA, QA, Dev, PM, or Delivery.
Return progress, completion, validation, and handoff summaries directly in the Codex response.

Before the final response, emit the

ai-sdlc-handoff/v1

contract with

result

blockers

next_required

, and

next_optional

; every action includes

reason

command

, and

expected_artifact

Do not create
```
summary.txt
```
,
```
*-summary.txt
```
, or another standalone summary file unless the user explicitly requests one.
Keep durable writes limited to the canonical lifecycle artifacts, decision log, human-readable index, and
```
_ai_sdlc
```
machine files.
Let shared helpers migrate legacy paths on the next write; never overwrite or manually merge divergent legacy and canonical files.

输出需使用标题和项目符号保持结构化。
明确指出发现的问题、差距、风险和障碍。
将建议与提供的产物、仓库、
```
specs-refiniment/<feature-name>/<file.md>
```
工作区或用户上下文的证据关联。
当输出为BA、QA、Dev、PM或交付团队创建后续工作时，需注明角色归属。
直接在Codex响应中返回进度、完成情况、验证和交接摘要。

在最终响应前，输出

ai-sdlc-handoff/v1

契约，包含

result

、

blockers

、

next_required

和

next_optional

；每个操作需包含

reason

、

command

和

expected_artifact

。

除非用户明确要求，否则不得创建
```
summary.txt
```
、
```
*-summary.txt
```
或其他独立的摘要文件。
仅将持久化写入限制在规范生命周期产物、决策日志、人类可读索引和
```
_ai_sdlc
```
机器文件中。
让共享助手在下次写入时迁移旧路径；不得覆盖或手动合并不一致的旧文件和规范文件。

0.4 Artifact Routing

0.4 产物路由

Maintain a feature decision log whenever this skill records, resolves, changes, or depends on a product, delivery, QA, security, validation, branching, implementation, or rollout decision.
For PM, BA, QA, Delivery, discovery, planning, refinement, and readiness work, write decisions to
```
specs-refiniment/<feature-name>/decision-log.md
```
.
For developer implementation SDD work, write decisions to
```
specs/<feature-name>/decision-log.md
```
.
Each decision-log entry must include date, decision, context or evidence, options considered when relevant, owner, status, and links to affected artifacts, tasks, tests, or validation evidence.

Use this exact decision-log structure:

markdown

# Decision Log

| ID | Date | Status | Owner | Decision | Context/Evidence | Options Considered | Affected Artifacts | Validation/Trace Links |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| DEC-001 | YYYY-MM-DD | proposed / accepted / superseded / rejected | role or name | concise decision | source facts, artifact links, or evidence | option A; option B; recommended default | affected docs, tasks, code, tests, or rollout notes | requirement IDs, test IDs, validation commands, PRs, commits, or tickets |

Use
```
specs/
```
only for developer implementation SDD packages and repo-governance artifacts.
Do not place PM, BA, QA, Delivery, discovery, planning, refinement, or readiness outputs in
```
specs/
```
; those belong at
```
specs-refiniment/<feature-name>/<file.md>
```
.
When consuming
```
specs-refiniment/<feature-name>/<file.md>
```
, treat it as upstream refinement context and create or update
```
specs/
```
only when implementation work is explicitly in scope.

每当本技能记录、解决、更改或依赖于产品、交付、QA、安全、验证、分支、实现或发布决策时，需维护功能决策日志。
对于PM、BA、QA、交付、发现、规划、细化和准备工作，将决策写入
```
specs-refiniment/<feature-name>/decision-log.md
```
。
对于开发人员实现SDD的工作，将决策写入
```
specs/<feature-name>/decision-log.md
```
。
每个决策日志条目必须包含日期、决策、上下文或证据、相关的备选方案（若适用）、负责人、状态以及受影响产物、任务、测试或验证证据的链接。

使用以下精确的决策日志结构：

markdown

# Decision Log

| ID | Date | Status | Owner | Decision | Context/Evidence | Options Considered | Affected Artifacts | Validation/Trace Links |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| DEC-001 | YYYY-MM-DD | proposed / accepted / superseded / rejected | role or name | concise decision | source facts, artifact links, or evidence | option A; option B; recommended default | affected docs, tasks, code, tests, or rollout notes | requirement IDs, test IDs, validation commands, PRs, commits, or tickets |

仅将
```
specs/
```
用于开发人员实现SDD的包和仓库治理产物。
不得将PM、BA、QA、交付、发现、规划、细化或准备工作的输出放在
```
specs/
```
中；这些内容应放在
```
specs-refiniment/<feature-name>/<file.md>
```
。
当使用
```
specs-refiniment/<feature-name>/<file.md>
```
时，将其视为上游细化上下文，仅当实现工作明确在范围内时才创建或更新
```
specs/
```
中的内容。

0.5 Feature State Machine

0.5 功能状态机

Maintain feature lifecycle state in TOON at

specs-refiniment/<feature-name>/_ai_sdlc/state.toon

for refinement work and

specs/<feature-name>/_ai_sdlc/state.toon

for implementation work.

Before executing this skill for a feature, check the state machine with

python3 skills/_shared/state_machine.py check --feature <feature-name> --skill <this-skill-name> --workspace <refinement|implementation> --quick-flow|--full-flow

When this skill starts durable work, mark it in progress with
```
begin
```
; when the skill's required artifact or review is complete, mark it done with
```
complete
```
and include
```
--artifacts <path>
```
plus
```
--decision-ref DEC-###
```
when a decision was involved.
In
```
--full-flow
```
, do not proceed when predecessor stages are incomplete, another lifecycle skill is active, or the state file reports a blocker.
In
```
--quick-flow
```
, a predecessor skip is allowed only when continuing is low risk and the command includes
```
--assumption "..."
```
or
```
--decision-ref DEC-###
```
; record the same assumption or decision in
```
decision-log.md
```
.

Use

python3 skills/_shared/state_machine.py status --feature <feature-name> --workspace <refinement|implementation> --format toon

to emit compact LLM-readable state before choosing the next skill.

The state machine is feature-scoped: do not reuse a
```
state.toon
```
across unrelated feature folders.

在TOON中维护功能生命周期状态：细化工作的状态存于
```
specs-refiniment/<feature-name>/_ai_sdlc/state.toon
```
，实现工作的状态存于
```
specs/<feature-name>/_ai_sdlc/state.toon
```
。

在为某个功能执行本技能前，使用

python3 skills/_shared/state_machine.py check --feature <feature-name> --skill <this-skill-name> --workspace <refinement|implementation> --quick-flow|--full-flow

检查状态机。

当本技能开始持久化工作时，用
```
begin
```
标记为进行中；当技能所需的产物或评审完成时，用
```
complete
```
标记为已完成，若涉及决策，需添加
```
--artifacts <path>
```
和
```
--decision-ref DEC-###
```
。
在
```
--full-flow
```
模式下，当前置阶段未完成、另一个生命周期技能处于活动状态或状态文件报告障碍时，不得继续执行。
在
```
--quick-flow
```
模式下，仅当继续执行风险较低且命令包含
```
--assumption "..."
```
或
```
--decision-ref DEC-###
```
时，才允许跳过前置阶段；需在
```
decision-log.md
```
中记录相同的假设或决策。

使用

python3 skills/_shared/state_machine.py status --feature <feature-name> --workspace <refinement|implementation> --format toon

在选择下一个技能前输出紧凑的LLM可读状态。

状态机以功能为范围：不得在无关的功能文件夹间复用
```
state.toon
```
。

0.6 Artifact Metadata And Metatags

0.6 产物元数据和元标签

Every Markdown artifact generated or updated by this skill must start with an
```
artifact_metadata
```
YAML frontmatter block before the first visible heading.

Use schema

ai-sdlc-artifact-metadata/v1

and keep these fields current:

feature

artifact

path

workspace

skill

flow_mode

state_file

decision_log

status

owner

created_at

updated_at

trace_ids

related_artifacts

validation

, and

metatags

```
metatags
```
must include at minimum
```
ai-sdlc
```
, the workspace (
```
refinement
```
or
```
implementation
```
), this skill name, the artifact type or filename stem, and a lifecycle/status tag such as
```
draft
```
,
```
review
```
,
```
approved
```
, or
```
validated
```
.
When
```
--quick-flow
```
is active, set
```
flow_mode: quick
```
, keep assumptions visible in the body, and add tags for major defaults or unresolved risk only when they help retrieval.
When
```
--full-flow
```
is active, set
```
flow_mode: full
```
, keep blockers and validation evidence reflected in
```
status
```
,
```
validation
```
,
```
trace_ids
```
, and
```
related_artifacts
```
.
Update metadata whenever the artifact path, status, owner, trace links, validation evidence, related artifacts, or decision references change.
Metadata is an index for routing, retrieval, and traceability; it does not replace the artifact body,
```
decision-log.md
```
, or
```
state.toon
```
.

本技能生成或更新的每个Markdown产物必须在第一个可见标题前包含
```
artifact_metadata
```
YAML前置块。

使用

ai-sdlc-artifact-metadata/v1

schema，并保持以下字段最新：

feature

、

artifact

、

path

、

workspace

、

skill

、

flow_mode

、

state_file

、

decision_log

、

status

、

owner

、

created_at

、

updated_at

、

trace_ids

、

related_artifacts

、

validation

和

metatags

。

```
metatags
```
必须至少包含
```
ai-sdlc
```
、工作区（
```
refinement
```
或
```
implementation
```
）、本技能名称、产物类型或文件名主干，以及生命周期/状态标签（如
```
draft
```
、
```
review
```
、
```
approved
```
或
```
validated
```
）。
当
```
--quick-flow
```
激活时，设置
```
flow_mode: quick
```
，在正文中显示假设，仅当有助于检索时才添加主要默认值或未解决风险的标签。
当
```
--full-flow
```
激活时，设置
```
flow_mode: full
```
，在
```
status
```
、
```
validation
```
、
```
trace_ids
```
和
```
related_artifacts
```
中反映障碍和验证证据。
当产物路径、状态、负责人、追溯链接、验证证据、相关产物或决策引用发生变化时，更新元数据。
元数据是用于路由、检索和可追溯性的索引；它不能替代产物正文、
```
decision-log.md
```
或
```
state.toon
```
。

0.7 Specs Index

0.7 规范索引

Before searching across feature folders, inspect the compact LLM index first:
```
specs-refiniment/_ai_sdlc/specs-index.toon
```
for refinement work or
```
specs/_ai_sdlc/specs-index.toon
```
for implementation work.
Use the human-readable index at
```
specs-refiniment/specs-index.md
```
or
```
specs/specs-index.md
```
when reporting feature coverage, artifact inventory, or handoff status to people.

After this skill creates or materially updates an artifact, refresh the matching workspace index with

python3 skills/_shared/ai_sdlc_specs_index.py --workspace <refinement|implementation> --quick-flow|--full-flow

In
```
--quick-flow
```
, rely on
```
specs-index.toon
```
to choose the smallest relevant artifact set before opening files.
In
```
--full-flow
```
, verify the updated artifact appears in both
```
specs-index.toon
```
and
```
specs-index.md
```
before final handoff.
The specs index summarizes artifact metadata and state; it does not replace reading the selected source artifacts when details, approvals, or validation evidence matter.

在跨功能文件夹搜索前，先查看紧凑的LLM索引：细化工作查看
```
specs-refiniment/_ai_sdlc/specs-index.toon
```
，实现工作查看
```
specs/_ai_sdlc/specs-index.toon
```
。
当向人员报告功能覆盖范围、产物清单或交接状态时，使用人类可读索引
```
specs-refiniment/specs-index.md
```
或
```
specs/specs-index.md
```
。

当本技能创建或实质性更新产物后，使用

python3 skills/_shared/ai_sdlc_specs_index.py --workspace <refinement|implementation> --quick-flow|--full-flow

刷新匹配的工作区索引。

在
```
--quick-flow
```
模式下，依赖
```
specs-index.toon
```
选择最小的相关产物集，再打开文件。
在
```
--full-flow
```
模式下，在最终交接前验证更新后的产物是否同时出现在
```
specs-index.toon
```
和
```
specs-index.md
```
中。
规范索引汇总产物元数据和状态；当细节、审批或验证证据很重要时，它不能替代阅读选定的源产物。

References

参考资料

Use
```
scripts/validation_plan.py
```
when deterministic validation, planning, or formatting is required by the workflow; pass the same
```
--quick-flow
```
or
```
--full-flow
```
flag that was supplied to the skill when supported.

当工作流需要确定性验证、规划或格式化时，使用
```
scripts/validation_plan.py
```
；若支持，传递与技能相同的
```
--quick-flow
```
或
```
--full-flow
```
标志。

Script Usage

脚本使用

Run validation planning after identifying changed files and before choosing commands manually.

Quick flow:

python3 skills/ai-sdlc-validation/scripts/validation_plan.py --quick-flow <changed-file>...

Full flow:

python3 skills/ai-sdlc-validation/scripts/validation_plan.py --full-flow <changed-file>...

If no files are supplied, the script inspects the current git worktree.
Execute the suggested commands that match the requested risk level; document skipped broader commands as residual risk.

在识别变更文件后、手动选择命令前运行验证规划。

快速流程：

python3 skills/ai-sdlc-validation/scripts/validation_plan.py --quick-flow <changed-file>...

完整流程：

python3 skills/ai-sdlc-validation/scripts/validation_plan.py --full-flow <changed-file>...

若未提供文件，脚本将检查当前git工作区。
执行符合请求风险级别的建议命令；将跳过的更广泛命令记录为残留风险。

Purpose

用途

Select, run, and report focused deterministic validation checks for AI SDLC code, SQL, API, provider, SDD, documentation, and tool-governance changes.

为AI SDLC的代码、SQL、API、供应商、SDD、文档和工具治理变更选择、运行并报告针对性的确定性验证检查。

Inputs

输入

Collect changed files from
```
git status --short
```
,
```
git diff --name-only
```
, or explicit user-provided paths.
Read the active spec and
```
qa.md
```
when the work is medium, large, release-sensitive, or user-visible.
Collect previous validation output only when it is current for the same diff signature.
Collect sandbox constraints that affect Go cache, network access, local listeners, or external services.
Run the validation planner when changed files are not trivial:
bash
```
python3 skills/ai-sdlc-validation/scripts/validation_plan.py
```

从
```
git status --short
```
、
```
git diff --name-only
```
或用户明确提供的路径收集变更文件。
当工作属于中型、大型、发布敏感或用户可见时，读取当前规范和
```
qa.md
```
。
仅当与同一差异签名的当前验证输出相关时，收集之前的验证输出。
收集影响Go缓存、网络访问、本地监听器或外部服务的沙箱约束。

当变更文件不琐碎时，运行验证规划器：

bash

python3 skills/ai-sdlc-validation/scripts/validation_plan.py

Steps

步骤

Classify changed files by surface: Go package, SQL/sqlc, API contract, provider integration, frontend/docs, SDD/spec, tool governance, or mixed.
Select the narrowest command set that proves the changed behavior.
Prefer focused tests before broad suites when the risk is localized.
Use
```
GOCACHE=/tmp/ai-sdlc-go-cache
```
for Go tests to avoid sandbox cache write failures.
Run spec and skill validators for SDD, skill, helper script, or spec changes.
For active feature specs, run structural SDD validation plus clarify, checklist, analyze, and workflow-status commands when the spec changed or is the main subject of the work.
Run
```
git diff --check
```
for every change before completion.
Rerun with escalation only when a required command fails due to sandbox restrictions and the command is still necessary.
Record each command exactly as run and its outcome: passed, failed, skipped, or blocked.
Fix failures caused by the current change before reporting success.
Report skipped or blocked checks with residual risk.

按类型分类变更文件：Go包、SQL/sqlc、API契约、供应商集成、前端/文档、SDD/规范、工具治理或混合类型。
选择能证明变更行为的最窄命令集。
当风险局部化时，优先选择针对性测试而非广泛套件。
对于Go测试，使用
```
GOCACHE=/tmp/ai-sdlc-go-cache
```
以避免沙箱缓存写入失败。
对于SDD、技能、辅助脚本或规范变更，运行规范和技能验证器。
对于活跃功能规范，当规范变更或为工作主要对象时，运行结构化SDD验证以及澄清、检查清单、分析和工作流状态命令。
在完成前为每个变更运行
```
git diff --check
```
。
仅当必要命令因沙箱限制失败且仍需执行时，才升级重试。
准确记录每个运行的命令及其结果：通过、失败、跳过或阻止。
在报告成功前修复当前变更导致的失败。
报告跳过或被阻止的检查以及残留风险。

Output Spec

输出规范

Use this format:

text

Validation:
- command: exact command
  outcome: passed | failed | skipped | blocked
  reason: why this command was selected or skipped

Coverage:
- Changed surface: files or package group.
- Behavior covered: requirement, scenario, or risk covered by the command.

Residual risk:
- none | explicit unvalidated behavior and why it remains.

Quality gate:

Pass when validation commands match the changed surfaces, required checks are current for the active diff, and skipped checks include residual risk.
Fail when validation is broad but irrelevant, narrow but misses a changed contract, or reports success while a command failed.

使用以下格式：

text

Validation:
- command: exact command
  outcome: passed | failed | skipped | blocked
  reason: why this command was selected or skipped

Coverage:
- Changed surface: files or package group.
- Behavior covered: requirement, scenario, or risk covered by the command.

Residual risk:
- none | explicit unvalidated behavior and why it remains.

质量关卡：

通过：验证命令与变更类型匹配，必要检查针对当前差异是最新的，跳过的检查包含残留风险说明。
失败：验证范围广泛但无关，或范围狭窄但遗漏了变更契约，或在命令失败时仍报告成功。

Examples

示例

Focused Go package change:

text

Validation:
- command: GOCACHE=/tmp/ai-sdlc-go-cache go test ./internal/service -run 'TestLoanTransfer|TestReturnPreflight' -count=1
  outcome: passed
  reason: covers changed service behavior and preflight failure paths.
- command: git diff --check
  outcome: passed
  reason: required whitespace validation for all changes.

Residual risk:
- none

Tool setup change:

text

Validation:
- command: PYTHONPYCACHEPREFIX=/tmp/ai-sdlc-harness-pycache python3 -m py_compile skills/ai-sdlc-validation/scripts/validation_plan.py
  outcome: passed
  reason: validates changed skill metadata.
- command: python3 skills/ai-sdlc-sdd/scripts/sdd_status.py --spec specs/185-spec-kit-sdd-quality-gates
  outcome: passed
  reason: confirms the active governance spec is structurally valid and ready for implementation.
- command: find skills -name SKILL.md -maxdepth 2
  outcome: passed
  reason: validates SDD governance shape.

Invalid counter-example:

text

Validation passed.

Reject this because it omits exact commands, changed surface coverage, and residual risk.

针对性Go包变更：

text

Validation:
- command: GOCACHE=/tmp/ai-sdlc-go-cache go test ./internal/service -run 'TestLoanTransfer|TestReturnPreflight' -count=1
  outcome: passed
  reason: covers changed service behavior and preflight failure paths.
- command: git diff --check
  outcome: passed
  reason: required whitespace validation for all changes.

Residual risk:
- none

工具设置变更：

text

Validation:
- command: PYTHONPYCACHEPREFIX=/tmp/ai-sdlc-harness-pycache python3 -m py_compile skills/ai-sdlc-validation/scripts/validation_plan.py
  outcome: passed
  reason: validates changed skill metadata.
- command: python3 skills/ai-sdlc-sdd/scripts/sdd_status.py --spec specs/185-spec-kit-sdd-quality-gates
  outcome: passed
  reason: confirms the active governance spec is structurally valid and ready for implementation.
- command: find skills -name SKILL.md -maxdepth 2
  outcome: passed
  reason: validates SDD governance shape.

无效反例：

text

Validation passed.

拒绝此输出，因为它省略了精确命令、变更范围覆盖和残留风险说明。

Edge Cases

边缘情况

Mark a check
```
blocked
```
when sandbox, missing dependency, missing credential, or unavailable service prevents execution.
Request escalation only after a required command fails for a likely sandbox reason; do not escalate to bypass project policy.
Run broader suites after focused checks when the changed surface spans handlers, services, providers, config, or generated contracts.
Do not run production integrations unless the user explicitly requests them and required credentials are already available through approved mechanisms.
Treat stale validation as absent when files changed after the command ran.

当沙箱、缺失依赖、缺失凭证或不可用服务导致无法执行时，将检查标记为
```
blocked
```
。
仅当必要命令因可能的沙箱原因失败时，才请求升级；不得为绕过项目策略而升级。
当变更范围跨越处理器、服务、供应商、配置或生成契约时，在针对性检查后运行更广泛的套件。
除非用户明确请求且必要凭证已通过批准机制可用，否则不得运行生产集成。
当文件在命令运行后发生变更时，将过时的验证视为无效。

Scope Boundary

范围边界

Do not design acceptance scenarios; use
```
$ai-sdlc-qa
```
.
Do not derive scenario matrices; use
```
$ai-sdlc-test-cases
```
.

Do not review code for findings; use

$ai-sdlc-code-review

$ai-sdlc-security-testing

Do not mark work done when validation is failed, blocked without disclosure, or unrelated to the changed surface.

不得设计验收场景；使用
```
$ai-sdlc-qa
```
。
不得推导场景矩阵；使用
```
$ai-sdlc-test-cases
```
。
不得评审代码发现的问题；使用
```
$ai-sdlc-code-review
```
或
```
$ai-sdlc-security-testing
```
。
当验证失败、未披露的阻止情况或与变更范围无关时，不得标记工作为已完成。