ai-sdlc-approvals-sandbox

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

ai-sdlc-approvals-sandbox: Approvals And Sandbox

ai-sdlc-approvals-sandbox：审批与沙箱

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-approvals-sandbox
```
Primary audience: Dev
Supporting audience: QA
Audience tags: Dev, QA
SDLC stage: Sandbox escalation decision
Purpose: Decide, request, and report sandbox escalation for AI SDLC commands only when the sandbox blocks a required action or the task explicitly requires approved external access.
Output: Sandbox escalation decision record with prefix_rule guidance and residual risk

技能名称：
```
ai-sdlc-approvals-sandbox
```
主要受众：开发人员（Dev）
支持受众：测试人员（QA）
受众标签：Dev、QA
SDLC阶段：沙箱升级决策
用途：仅当沙箱阻止必要操作或任务明确要求已获批的外部访问时，针对AI SDLC命令决定、请求并报告沙箱权限升级。
输出：包含prefix_rule指导和剩余风险的沙箱升级决策记录

0.1 Required Inputs

0.1 必要输入

Exact command that failed or requires external access.
Task reason for the command.
Sandbox error, expected restriction, and risk profile.

执行失败或需要外部访问的具体命令。
执行该命令的任务原因。
沙箱错误信息、预期限制及风险概况。

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
```
、
```
Not provided
```
或
```
Assumption
```
，不得编造。
将已确认事实与假设、待澄清问题分开。
当必要的上游产物或决策缺失时，不得进行下游合成工作。

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响应中返回进度、完成情况、验证及交接摘要。

在最终响应前，输出包含

result

、

blockers

、

next_required

和

next_optional

的

ai-sdlc-handoff/v1

契约；每个操作需包含

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/approval_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/approval_plan.py
```
；若支持，需传入与技能相同的
```
--quick-flow
```
或
```
--full-flow
```
标志。

Script Usage

脚本用法

Validate approval requests before asking for escalation or recording an approval decision.

Quick flow:

python3 skills/ai-sdlc-approvals-sandbox/scripts/approval_plan.py --quick-flow --command "<command>" --justification "<user-facing question?>"

Full flow:

python3 skills/ai-sdlc-approvals-sandbox/scripts/approval_plan.py --full-flow --command "<command>" --justification "<user-facing question?>" --prefix-rule "<safe reusable prefix>"

Use
```
--prefix-rule
```
only when proposing a reusable non-destructive approval prefix; omit it for destructive or one-off commands.

在请求升级或记录审批决策前，先验证审批请求。

快速流程：

python3 skills/ai-sdlc-approvals-sandbox/scripts/approval_plan.py --quick-flow --command "<command>" --justification "<user-facing question?>"

完整流程：

python3 skills/ai-sdlc-approvals-sandbox/scripts/approval_plan.py --full-flow --command "<command>" --justification "<user-facing question?>" --prefix-rule "<safe reusable prefix>"

仅当提议可复用的非破坏性审批前缀时，使用
```
--prefix-rule
```
；破坏性或一次性命令需省略该参数。

Purpose

用途

Decide, request, and report sandbox escalation for AI SDLC commands only when the sandbox blocks a required action or the task explicitly requires approved external access.

仅当沙箱阻止必要操作或任务明确要求已获批的外部访问时，针对AI SDLC命令决定、请求并报告沙箱权限升级。

Inputs

输入

Collect the exact command that failed or must run outside the sandbox.
Collect the task reason that makes the command necessary.
Collect the sandbox error or expected restriction: filesystem, network, listener, GUI, external service, or destructive action.
Collect whether the command is destructive, secret-bearing, shell-heavy, or reusable.
Collect an intended narrow
```
prefix_rule
```
only when repeated approval is safe.

收集执行失败或必须在沙箱外运行的具体命令。
收集使该命令成为必要的任务原因。
收集沙箱错误或预期限制：文件系统、网络、监听器、GUI、外部服务或破坏性操作。
收集命令是否具有破坏性、包含机密、大量使用shell或可复用。
仅当重复审批安全时，收集预期的窄范围
```
prefix_rule
```
。

Steps

步骤

Run normal reads, workspace writes, local tests, and formatting in the default sandbox first.
Classify the command into one segment per shell operator when the command contains pipes, separators, logical operators, or subshells.
Request escalation only when a required command is blocked by sandbox restrictions or explicitly needs approved external access.
Do not request escalation to bypass SDD, skip validation, avoid fixing a local setup issue, or run unrelated broad commands.

Validate the approval plan before asking when time permits:

bash

python3 skills/ai-sdlc-approvals-sandbox/scripts/approval_plan.py \
  --command 'go test ./internal/service/...' \
  --justification 'Allow running focused service tests with the required sandbox permissions?' \
  --prefix-rule 'go test ./internal/service/...'

Phrase
```
justification
```
as a short user-facing question.
Provide
```
prefix_rule
```
only for narrow, reusable, non-destructive command classes.
Rerun the command only after approval is granted.
Report denied or partial approval and continue with the best safe fallback.

先在默认沙箱中执行常规读取、工作区写入、本地测试及格式化操作。
若命令包含管道、分隔符、逻辑运算符或子shell，按每个shell运算符将命令分类为不同段。
仅当必要命令被沙箱限制阻止或明确需要已获批的外部访问时，请求权限升级。
不得为绕过SDD、跳过验证、规避本地设置问题或运行无关的宽泛命令而请求权限升级。

若时间允许，在请求前验证审批计划：

bash

python3 skills/ai-sdlc-approvals-sandbox/scripts/approval_plan.py \
  --command 'go test ./internal/service/...' \
  --justification 'Allow running focused service tests with the required sandbox permissions?' \
  --prefix-rule 'go test ./internal/service/...'

将
```
justification
```
表述为简短的面向用户的问题。
仅为窄范围、可复用、非破坏性命令类提供
```
prefix_rule
```
。
仅在获得审批后重新运行命令。
报告被拒绝或部分获批的情况，并采用最佳安全备选方案继续执行。

Output Spec

输出规范

Return this decision record when escalation is requested, denied, or skipped:

text

Sandbox decision:
- Command: exact command
- Required for: task-specific reason
- Sandbox issue: filesystem | network | listener | GUI | external service | destructive | none
- Escalation: requested | not requested | denied | granted
- Prefix rule: proposed rule | none and why
- Result: passed | failed | skipped | blocked
- Residual risk: none | concrete limitation

Quality gate:

Pass when escalation is narrow, justified by the task, and avoids broad reusable approval for dangerous commands.
Fail when the request uses vague justification, proposes broad interpreter or shell prefixes, includes secrets, or escalates unrelated work.

当请求、拒绝或跳过升级时，返回以下决策记录：

text

Sandbox decision:
- Command: exact command
- Required for: task-specific reason
- Sandbox issue: filesystem | network | listener | GUI | external service | destructive | none
- Escalation: requested | not requested | denied | granted
- Prefix rule: proposed rule | none and why
- Result: passed | failed | skipped | blocked
- Residual risk: none | concrete limitation

质量关卡：

若升级范围窄、有任务依据且避免为危险命令授予宽泛的可复用审批，则通过。
若请求理由模糊、提议宽泛的解释器或shell前缀、包含机密或升级无关工作，则不通过。

Examples

示例

Valid request:

json

{
  "sandbox_permissions": "require_escalated",
  "justification": "Allow running Go tests with a writable external cache for this package?",
  "prefix_rule": ["go", "test", "./internal/service/..."]
}

Invalid counter-example:

json

{
  "sandbox_permissions": "require_escalated",
  "justification": "Need permissions.",
  "prefix_rule": ["python3"]
}

Reject this because the justification is vague and the prefix allows arbitrary scripts.

有效请求：

json

{
  "sandbox_permissions": "require_escalated",
  "justification": "Allow running Go tests with a writable external cache for this package?",
  "prefix_rule": ["go", "test", "./internal/service/..."]
}

无效反例：

json

{
  "sandbox_permissions": "require_escalated",
  "justification": "Need permissions.",
  "prefix_rule": ["python3"]
}

拒绝该请求，因为理由模糊且前缀允许执行任意脚本。

Edge Cases

边缘情况

Skip reusable
```
prefix_rule
```
for destructive commands such as
```
rm
```
,
```
git reset
```
, force push, or data deletion.
Skip reusable
```
prefix_rule
```
for heredocs, redirection, wildcards, command substitution, environment-heavy one-liners, or shell wrappers.
Warn immediately and avoid reusing commands when a command contains credentials, bearer tokens, private keys, webhook secrets, or production-only values.
Treat a missing dependency error as a setup issue first, not an escalation reason, unless the dependency download is required and network is blocked.
Report partial approval when one command segment is approved but another remains blocked.

对于
```
rm
```
、
```
git reset
```
、强制推送或数据删除等破坏性命令，跳过可复用的
```
prefix_rule
```
。
对于here文档、重定向、通配符、命令替换、依赖环境的单行命令或shell包装器，跳过可复用的
```
prefix_rule
```
。
若命令包含凭据、承载令牌、私钥、webhook机密或仅生产环境可用的值，需立即发出警告并避免复用该命令。
首先将缺失依赖的错误视为设置问题，而非升级理由，除非依赖下载是必要操作且网络被阻止。
当某命令段获批但另一段仍被阻止时，报告部分获批情况。

Scope Boundary

范围边界

Do not decide which validation commands are required; use
```
$ai-sdlc-validation
```
.
Do not approve destructive commands on the user's behalf.
Do not weaken developer SDD, review, or validation requirements because sandbox permissions are inconvenient.
Do not replace the active runtime’s higher-priority sandbox and approval policies.

不得决定需要哪些验证命令；使用
```
$ai-sdlc-validation
```
。
不得代表用户批准破坏性命令。
不得因沙箱权限不便而降低开发人员SDD、评审或验证要求。
不得替代当前运行时优先级更高的沙箱和审批策略。