audit-xcode-security-settings

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Audit Xcode Security Settings

Xcode安全设置审计

Assess an Xcode project's security posture and progressively enable security build settings and entitlements — from broadly applicable warnings through Enhanced Security hardening.

评估Xcode项目的安全状态，逐步启用安全构建设置和权限——从广泛适用的警告到增强安全加固。

Tool Preferences

工具偏好

When XcodeGlob, XcodeGrep, XcodeRead, XcodeLS, and XcodeUpdate tools are available, ALWAYS use them. Do not fall back to Bash filesystem tools (

ls

find

cat

grep

) to learn about the project. They trigger extra permission prompts and bypass project scoping.

XcodeGlob for file discovery —
```
find
```
is forbidden for files inside the project.
XcodeGrep for content search —
```
grep
```
/
```
rg
```
is forbidden for files inside the project.
XcodeRead for file contents —
```
cat
```
/
```
Read
```
is forbidden for files registered in the project.
XcodeLS for directory listing —
```
ls
```
is forbidden for any path inside the project.
XcodeUpdate for in-place edits of project-registered files — same
```
filePath
```
/
```
oldString
```
/
```
newString
```
(+ optional
```
replaceAll
```
) signature as the built-in
```
Edit
```
tool, but accepts project-org paths.
```
Edit
```
is forbidden for files registered in the project; use it only for on-disk files that aren't project-indexed (e.g.
```
.entitlements
```
plists translated to filesystem absolute paths per the failure-modes table below).

Project root and name are already in the system prompt context. Do NOT run

ls

to "verify" the project layout before starting. The system prompt already tells you the working directory and the project structure.

Empty XcodeGlob results are not a failure. The

.xcodeproj

and

.xcworkspace

are not indexed as files inside the Xcode project organization —

XcodeGlob "**/*.xcodeproj"

correctly returns 0 matches. Use the project name from system-prompt context instead. Do not fall back to filesystem

ls

find

Path translation between project-org and filesystem. XcodeGlob returns project-org-relative paths. To read or edit a file:

Prefer
```
XcodeRead
```
/
```
XcodeUpdate
```
with the project-org path.
If that path is rejected (some on-disk files like
```
.entitlements
```
plists may not be navigable through
```
XcodeRead
```
), translate to a filesystem absolute path by prepending the project root from system context. Do NOT use
```
find
```
to discover the on-disk path.

Fall back to Bash only for operations the Xcode tools cannot do (e.g.,

plutil

for plist editing, git operations).

当XcodeGlob、XcodeGrep、XcodeRead、XcodeLS和XcodeUpdate工具可用时，请务必使用它们。不要退回到Bash文件系统工具（

ls

、

find

、

cat

、

grep

）来了解项目信息。这些工具会触发额外的权限提示，并且会绕过项目范围限制。

XcodeGlob 用于文件发现——禁止对项目内文件使用
```
find
```
。
XcodeGrep 用于内容搜索——禁止对项目内文件使用
```
grep
```
/
```
rg
```
。
XcodeRead 用于读取文件内容——禁止对项目中已注册的文件使用
```
cat
```
/
```
Read
```
。
XcodeLS 用于目录列表——禁止对项目内的任何路径使用
```
ls
```
。
XcodeUpdate 用于对项目注册文件进行原地编辑——其签名（
```
filePath
```
/
```
oldString
```
/
```
newString
```
+ 可选
```
replaceAll
```
）与内置
```
Edit
```
工具相同，但支持项目组织路径。禁止对项目中已注册的文件使用
```
Edit
```
；仅对未被项目索引的磁盘文件（例如，根据下方故障模式表转换为文件系统绝对路径的
```
.entitlements
```
属性列表）使用该工具。

项目根目录和名称已包含在系统提示上下文里。 开始前不要运行

ls

来“验证”项目布局。系统提示已告知你工作目录和项目结构。

XcodeGlob返回空结果并非失败。

.xcodeproj

和

.xcworkspace

不会被索引为Xcode项目组织内的文件——

XcodeGlob "**/*.xcodeproj"

返回0个匹配结果是正确的。请改用系统提示上下文中的项目名称。不要退回到文件系统的

ls

find

工具。

项目组织路径与文件系统路径的转换。 XcodeGlob返回的是项目组织相对路径。要读取或编辑文件：

优先使用
```
XcodeRead
```
/
```
XcodeUpdate
```
并传入项目组织路径。
如果该路径被拒绝（某些磁盘文件如
```
.entitlements
```
属性列表可能无法通过
```
XcodeRead
```
访问），请通过在项目组织路径前添加系统上下文提供的项目根目录，将其转换为文件系统绝对路径。不要使用
```
find
```
来查找磁盘路径。

仅当Xcode工具无法完成操作时，才退回到Bash（例如，使用

plutil

编辑属性列表、Git操作）。

Common Failure Modes

常见故障模式

Symptom	Cause	Correct Response
`XcodeGlob "*/.xcodeproj"` returns 0 matches	The `.xcodeproj` itself isn't a project-indexed file	Use the project name from system context; do not fall back to `find` or `ls`
`XcodeRead <project-org-path>` fails for a config-type file ( `.entitlements` , `.xcsettings` , `.xcconfig` )	Some on-disk artifacts aren't navigable via project paths	Translate to filesystem absolute path using the project root from system context, then use `Read` / `Edit`

症状	原因	正确处理方式
`XcodeGlob "*/.xcodeproj"` 返回0个匹配结果	`.xcodeproj` 本身不是项目索引文件	使用系统上下文里的项目名称；不要退回到 `find` 或 `ls`
`XcodeRead <项目组织路径>` 读取配置类文件（ `.entitlements` 、 `.xcsettings` 、 `.xcconfig` ）失败	某些磁盘工件无法通过项目路径访问	使用系统上下文里的项目根目录转换为文件系统绝对路径，然后使用 `Read` / `Edit`

Workflow

工作流程

Phase 1: Briefing

阶段1：简要说明

Before doing any work, tell the user — in two or three sentences — what this skill is, what it will do, and roughly how much of their time and attention to expect:

What it is. An audit of the project's Xcode security build settings and entitlements (compiler warnings, hardened-process capabilities, pointer authentication, universal binaries for libraries, etc.).
What happens. I analyze the project, write an editable plan file at the project root for you to review, and apply only the changes you approve. Nothing is modified until you pick Run.
Time commitment. A few minutes of my time to analyze (longer on projects with many targets — I'll narrate progress). Then your review time on the plan file, which can be quick or thorough — your call. After Run, applying is fast; two things can pause for your input — the inquiry step (if there are deliberately-disabled settings whose rationale isn't documented), and a final yes/no on whether to keep the plan file in your project as a record. This all usually takes about 15-30 minutes, depending on the number of build targets and how long it takes for you to review and approve the plan.

Keep it tight — the user already invoked the skill knowing they wanted an audit. The briefing exists so they have realistic expectations.

在开始任何工作前，用两三句话告知用户：这项技能是什么、会做什么，以及大致需要占用他们多少时间和精力：

技能定位：对项目的Xcode安全构建设置和权限（编译器警告、强化进程能力、指针认证、库的通用二进制文件等）进行审计。
执行流程：我会分析项目，在项目根目录生成一个可编辑的计划文件供你审阅，仅应用你批准的更改。在你选择“运行”前，不会修改任何内容。
时间投入：我分析项目需要几分钟时间（如果项目有多个目标，耗时会更长——我会实时告知进度）。之后是你审阅计划文件的时间，可快可慢，由你决定。选择“运行”后，应用更改的速度很快；有两种情况会暂停等待你的输入——查询步骤（如果存在故意禁用且未记录理由的设置），以及最终确认是否保留计划文件作为项目记录。整个过程通常需要15-30分钟，具体取决于构建目标的数量以及你审阅和批准计划的耗时。

表述要简洁——用户调用这项技能时已经知道他们需要审计。简要说明的目的是让他们有合理的预期。

Phase 2: Discovery

阶段2：发现

Read the Environment block in the system prompt. Relevant fields:

```
Primary working directory
```
— the project root (the project name is the basename).
```
Is a git repository
```
— whether the project is git-tracked (used by Phase 4 Step 1).

读取系统提示中的环境区块。相关字段：

```
Primary working directory
```
——项目根目录（项目名称是该目录的基名）。
```
Is a git repository
```
——项目是否由Git跟踪（阶段4步骤1会用到）。

Track Progress

进度跟踪

Every per-target / per-setting action that needs to happen must have its own task for transparency.

Phase 3 creates one task per target (
```
Audit <target>
```
); the task closes once Phase 3 has produced both the per-target audit-table rows and (for supported product types) the Enhanced-Security bucket for that target. After all per-target tasks complete, Phase 3 writes
```
<project-root>/xcode-security-audit-scratchpad.md
```
via the
```
Write
```
tool (filesystem only — the scratchpad is agent-internal state, not user-facing, so it deliberately is not registered in the Xcode project). Phases 4–7 re-read it via
```
Read
```
; they never assume the data is in memory. Do not stage this file in git.
Phase 4 (Plan & Approve) is one task that completes when the user picks Run/Cancel.
On Run, Phase 4 step 5 parses the plan, appends a
```
## Plan Selection
```
section to the scratchpad, and creates fine-grained tasks:
- One
```
Apply Enhanced Security to <target>
```
  per target needing changes (only if "Enhanced Security" is checked).
- ```
Apply Basic Clang Safety Warnings
```
  if checked.
- ```
Apply Hardware Memory Tagging
```
  if checked.
- ```
Apply Additional Diagnostic Settings
```
  if checked.
- ```
Emit Bounds Safety Adoption guidance
```
  if checked.
- One
```
Inquire about <MACRO> on <target>
```
  per Phase-6 candidate (only if "Inquire about disabled settings" is checked).
- ```
Report and update decision document
```
  .
- ```
Remove scratchpad
```
  — always second-to-last; also fires on error paths.
- ```
Prompt to remove plan file
```
  — always last; also fires on error paths.

When entering each phase or sub-step:

Print one line: "▶ Phase N: …" (or "▶ Phase N / Step M: …" for sub-steps).
Update the task to
```
in_progress
```
.

When finishing each phase or sub-step:

Print one line: "✓ Phase N: …" (with a brief outcome if applicable, e.g., "✓ Phase N: No disabled settings found.").
Update the task to
```
completed
```
.

每一项需要执行的按目标/设置划分的操作都必须有独立的任务，以保证透明度。

阶段3为每个目标创建一个任务（
```
Audit <target>
```
）；当阶段3生成了该目标的审计表行以及（对于支持的产品类型）增强安全分类后，任务关闭。所有按目标划分的任务完成后，阶段3通过
```
Write
```
工具（仅文件系统——临时文件是代理内部状态，不面向用户，因此故意不在Xcode项目中注册）写入
```
<project-root>/xcode-security-audit-scratchpad.md
```
。阶段4–7通过
```
Read
```
工具重新读取该文件；它们绝不会假设数据保存在内存中。不要将此文件加入Git暂存区。
阶段4（计划与批准）是一个任务，当用户选择“运行/取消”时完成。
选择“运行”后，阶段4步骤5会解析计划，在临时文件中追加
```
## Plan Selection
```
部分，并创建细粒度任务：
- 每个需要更改的目标对应一个
```
Apply Enhanced Security to <target>
```
  任务（仅当“增强安全”被勾选时）。
- 如果勾选了“基础Clang安全警告”，则创建
```
Apply Basic Clang Safety Warnings
```
  任务。
- 如果勾选了“硬件内存标记”，则创建
```
Apply Hardware Memory Tagging
```
  任务。
- 如果勾选了“额外诊断设置”，则创建
```
Apply Additional Diagnostic Settings
```
  任务。
- 如果勾选了“发出边界安全采用指南”，则创建
```
Emit Bounds Safety Adoption guidance
```
  任务。
- 每个阶段6候选项对应一个
```
Inquire about <MACRO> on <target>
```
  任务（仅当“查询禁用设置”被勾选时）。
- ```
Report and update decision document
```
  任务。
- ```
Remove scratchpad
```
  任务——始终是倒数第二个；在错误路径中也会触发。
- ```
Prompt to remove plan file
```
  任务——始终是最后一个；在错误路径中也会触发。

进入每个阶段或子步骤时：

打印一行："▶ 阶段N：……"（子步骤则为"▶ 阶段N / 步骤M：……"）。
将任务状态更新为
```
in_progress
```
。

完成每个阶段或子步骤时：

打印一行："✓ 阶段N：……"（如有适用，可添加简短结果，例如"✓ 阶段N：未发现禁用设置。"）。
将任务状态更新为
```
completed
```
。

Phase 3: Analyze Project and Settings

阶段3：分析项目和设置

No user interaction. Gather facts in the background.

无需用户交互。在后台收集信息。

Step 1: Locate the existing decision document

步骤1：定位现有决策文档

XcodeGlob '**/xcode-security-settings.md'

. If found,

XcodeRead

it and extract languages + prior setting decisions with their statuses and rationale. This informs subsequent phases.

执行

XcodeGlob '**/xcode-security-settings.md'

。如果找到，使用

XcodeRead

读取它，并提取语言信息以及之前的设置决策（包括状态和理由）。这会为后续阶段提供参考。

Step 2: Detect languages

步骤2：检测语言

One

XcodeGlob

per language. Empty result is not a failure — record the language as absent.

```
**/*.c
```
→ C
```
**/*.cpp
```
,
```
**/*.cxx
```
,
```
**/*.cc
```
→ C++
```
**/*.m
```
→ Objective-C
```
**/*.mm
```
→ Objective-C++
```
**/*.swift
```
→ Swift

为每种语言执行一次

XcodeGlob

。空结果并非失败——记录该语言不存在。

```
**/*.c
```
→ C语言
```
**/*.cpp
```
,
```
**/*.cxx
```
,
```
**/*.cc
```
→ C++语言
```
**/*.m
```
→ Objective-C语言
```
**/*.mm
```
→ Objective-C++语言
```
**/*.swift
```
→ Swift语言

Step 3: Build the audit table

步骤3：构建审计表

See

references/reading-build-settings.md

for column definitions, the construction recipe, and the canonical predicates ("already hardened", "at default OFF", "deliberately disabled"). At a glance:

Enumerate the project's explicit targets. Skip implicit/aggregate targets (no real product type).
For each target:
```
TaskCreate "Audit <target>"
```
, set in_progress. Call
```
GetTargetBuildSettings
```
, run
```
scripts/filter_build_settings.py
```
over the resulting JSON, and record
```
evaluatedValue
```
and
```
setAtTargetLevel
```
(
```
yes
```
if
```
targetValue
```
is present in the JSON). Leave the task in_progress — Step 4 closes it.
One project-wide
```
XcodeGrep
```
for the catalog regex over
```
*.xcconfig
```
and
```
**/project.pbxproj
```
. Record per-macro
```
numMatchesInXCConfigs
```
,
```
numMatchesInPbxproj
```
, and the file:line citations.
The audit table is the joined view: one row per (target, catalog macro). Phases 4, 5, and 6 all consume this table; nothing else is re-fetched.

This step scales with target count: each

GetTargetBuildSettings

call takes several seconds, and there is one per target. On projects with roughly ten or more targets it can take a few minutes.

请查看

references/reading-build-settings.md

了解列定义、构建方法以及标准断言（"已加固"、"默认关闭"、"故意禁用"）。概览：

枚举项目的显式目标。跳过隐式/聚合目标（无实际产品类型）。
针对每个目标：创建
```
TaskCreate "Audit <target>"
```
任务，设置为
```
in_progress
```
状态。调用
```
GetTargetBuildSettings
```
，对生成的JSON运行
```
scripts/filter_build_settings.py
```
，并记录
```
evaluatedValue
```
和
```
setAtTargetLevel
```
（如果JSON中存在
```
targetValue
```
则为
```
yes
```
）。保持任务为
```
in_progress
```
状态——步骤4会关闭它。
对
```
*.xcconfig
```
和
```
**/project.pbxproj
```
执行一次项目范围的
```
XcodeGrep
```
，使用目录正则表达式。记录每个宏的
```
numMatchesInXCConfigs
```
、
```
numMatchesInPbxproj
```
以及文件:行引用。
审计表是联合视图：每行对应一个（目标，目录宏）。阶段4、5、6都会使用此表；不会重新获取其他数据。

此步骤耗时随目标数量增加而增加：每个

GetTargetBuildSettings

调用需要几秒，每个目标对应一次调用。对于拥有约10个或更多目标的项目，可能需要几分钟。

Step 4: Per-target Enhanced-Security state

步骤4：按目标划分的增强安全状态

Route each target into one of three buckets by product type (inferred per the table in

references/reading-build-settings.md

Entitlements-supported — product type is in the "Supported Product Types" list of
```
references/enhanced-security.md
```
(applications, XPC services, system extensions, driver extensions [build settings only], tools). Read the resolved
```
CODE_SIGN_ENTITLEMENTS
```
plist and bucket the target as Up-to-date, Partial, Off, or No-entitlements-file.
Library/framework — product type is in the qualifying set listed in
```
references/universal-binaries-for-libraries.md
```
(frameworks, static frameworks, static libraries, dynamic libraries). No entitlements read. Phase 5 will configure a universal-binary
```
ARCHS
```
recommendation for these.
Skipped — anything else (test bundles, app extensions, etc.).

TaskUpdate "Audit <target>"

to completed once the bucket is recorded (immediately for Library/framework and Skipped — they need no entitlements read). Phases 4 and 5 consume these buckets — neither re-reads entitlements.

On large projects this iterates over many

.entitlements

plists — if Step 3 took noticeable time, this one will too.

根据产品类型（参考

references/reading-build-settings.md

中的表格推断）将每个目标分为三类：

支持权限——产品类型在
```
references/enhanced-security.md
```
的"支持的产品类型"列表中（应用程序、XPC服务、系统扩展、驱动扩展[仅构建设置]、工具）。读取已解析的
```
CODE_SIGN_ENTITLEMENTS
```
属性列表，并将目标分类为最新、部分完成、未启用或无权限文件。
库/框架——产品类型在
```
references/universal-binaries-for-libraries.md
```
列出的合格集合中（框架、静态框架、静态库、动态库）。无需读取权限。阶段5会为这些目标配置通用二进制
```
ARCHS
```
建议。
跳过——其他类型（测试包、应用扩展等）。

记录分类后，将

TaskUpdate "Audit <target>"

更新为

completed

状态（对于库/框架和跳过类型可立即完成——它们无需读取权限）。阶段4和5会使用这些分类——两者都不会重新读取权限。

在大型项目中，此步骤会遍历多个

.entitlements

属性列表——如果步骤3耗时明显，此步骤也会耗时较久。

Step 5: Persist the analysis

步骤5：保存分析结果

Write

<project-root>/xcode-security-audit-scratchpad.md

via the Write
tool (not

XcodeWrite

— the scratchpad is agent-internal state and intentionally is not registered in the Xcode project, so it doesn't clutter the user's Project Navigator). Resolve

<project-root>

from the Environment block's

Primary working directory

. The file has two sections:

```
## Audit Table
```
— the rows from Step 3.

## Enhanced-Security Buckets

— one line per target with its bucket and a short delta hint (e.g.

Foo: Partial — missing hardened-heap, has deprecated platform-restrictions

Phase 4 step 5 (on Run) will append a third section

## Plan Selection

via

Edit

. The final

Remove scratchpad

task in Phase 7 removes the scratchpad via

Bash rm

. If the file is missing at re-read time during a later phase, that phase aborts with an error — never re-derive silently.

通过**

Write

工具**（而非

XcodeWrite

——临时文件是代理内部状态，故意不注册到Xcode项目中，因此不会占用用户的项目导航器）写入

<project-root>/xcode-security-audit-scratchpad.md

。从环境区块的

Primary working directory

解析

<project-root>

。该文件包含两个部分：

```
## Audit Table
```
——步骤3中的行数据。

## Enhanced-Security Buckets

——每个目标一行，包含其分类和简短的增量提示（例如

Foo: Partial — missing hardened-heap, has deprecated platform-restrictions

）。

阶段4步骤5（运行时）会通过

Edit

工具追加第三部分

## Plan Selection

。阶段7中的最终

Remove scratchpad

任务会通过

Bash rm

删除临时文件。如果后续阶段重新读取时文件缺失，该阶段会报错终止——绝不会静默重新推导数据。

Phase 4: Plan & Approve

阶段4：计划与批准

This phase produces a tailored, editable plan file that the user reviews before any changes happen. Once approved, Phases 5–7 run end-to-end with no further prompts.

此阶段生成一个定制的可编辑计划文件，供用户在进行任何更改前审阅。一旦批准，阶段5–7会全程运行，无需进一步提示。

Step 1: Check for version control

步骤1：检查版本控制

The project is version-controlled if either:

The Environment block's
```
Is a git repository
```
field is
```
true
```
, or
A single filesystem check at the project root finds any of
```
.git
```
,
```
.hg
```
,
```
.svn
```
,
```
.bzr
```
,
```
.fslckout
```
,
```
_FOSSIL_
```
,
```
CVS
```
.

Otherwise the project is not version-controlled.

如果满足以下任一条件，则项目是版本控制的：

环境区块的
```
Is a git repository
```
字段为
```
true
```
，或者
在项目根目录进行一次文件系统检查，发现存在
```
.git
```
、
```
.hg
```
、
```
.svn
```
、
```
.bzr
```
、
```
.fslckout
```
、
```
_FOSSIL_
```
、
```
CVS
```
中的任意一个。

否则，项目未进行版本控制。

Step 2: Skip if everything is already configured

步骤2：如果所有配置已完成则跳过

Inspect the scratchpad. Early-exit if all default-checked plan items are already at their target state:

Every Enhanced-Security bucket is Up-to-date or Skipped.
Every relevant Basic-Clang-safety setting is
```
already hardened
```
on every applicable target.
The
```
deliberately disabled
```
predicate yields no rows (after the Phase-6 exclusions below).

Optional follow-ups (Additional diagnostic settings, Bounds safety adoption) do not block early-exit. Report "Everything in scope is already configured" and exit; do not write a plan file.

检查临时文件。如果所有默认勾选的计划项已处于目标状态，则提前退出：

所有增强安全分类均为最新或跳过。
每个相关的基础Clang安全设置在每个适用目标上均为
```
already hardened
```
。
```
deliberately disabled
```
断言无匹配行（排除阶段6的排除项后）。

可选后续操作（额外诊断设置、边界安全采用）不会阻止提前退出。报告"范围内的所有内容已配置完成"并退出；无需写入计划文件。

Step 3: Write the plan file

步骤3：写入计划文件

Create

xcode-security-audit-plan.md

at the root of the Xcode project organization via

XcodeWrite

(path:

xcode-security-audit-plan.md

, no parent group).

XcodeWrite

both writes the file to disk under

<project-root>/

and registers it in the project so the user can open it directly from Xcode's Project Navigator.

Include only items that apply to the project (see omission rules below). Use this template — substitute the placeholders in

<…>

markdown

undefined

通过

XcodeWrite

在Xcode项目组织的根目录创建

xcode-security-audit-plan.md

（路径：

xcode-security-audit-plan.md

，无父组）。

XcodeWrite

会将文件写入磁盘的

<project-root>/

目录，并将其注册到项目中，以便用户可以直接从Xcode的项目导航器中打开它。

仅包含适用于项目的项（请参阅下方省略规则）。使用以下模板——替换

<…>

中的占位符：

markdown

undefined

Xcode Security Audit — Plan

Xcode安全审计——计划

Project: <name> · <N> targets · languages: <list> Generated: <YYYY-MM-DD>

⚠️ No version control detected. This skill modifies build settings and entitlements. Without Version Control System (e.g., Git), rollback requires manual undo. Consider running
git init
or copying the project before picking Run. Edit the items below — set what steps to perform now, or leave them unchecked to defer them.

项目： <名称> · <N>个目标 · 语言：<列表> 生成时间： <YYYY-MM-DD>

⚠️ 未检测到版本控制。 此技能会修改构建设置和权限。没有版本控制系统（如Git），回滚需要手动操作。建议在选择运行前执行
git init
或复制项目。编辑以下项——设置现在要执行的步骤，或者取消勾选以推迟执行。

Phases

阶段

Enhanced Security — apply to: <target list>. Adds hardened-process entitlements and sets
```
ENABLE_ENHANCED_SECURITY=YES
```
.
Basic Clang safety warnings — <N> settings, applied to all C/C++/ObjC targets.
Inquire about disabled settings — <M> found (e.g.,
```
<setting>=NO
```
on
```
<target>
```
). May trigger follow-up questions if no rationale is documented.
Hardware memory tagging — applies to <target list filtered to MTE-supported platforms>. Adds soft-mode MTE entitlement.
Additional diagnostic settings — extra warnings/checkers. Produces more findings to review. See
```
references/additional-settings.md
```
.
Bounds safety adoption — pointer to a separate skill. No changes applied here.

增强安全 —— 应用于：<目标列表>。添加强化进程权限并设置
```
ENABLE_ENHANCED_SECURITY=YES
```
。
基础Clang安全警告 —— <N>个设置，应用于所有C/C++/ObjC目标。
查询禁用设置 —— 发现<M>项（例如，
```
<target>
```
上的
```
<setting>=NO
```
）。如果没有记录理由，可能会触发后续问题。
硬件内存标记 —— 应用于<支持MTE的平台目标列表>。添加软模式MTE权限。
额外诊断设置 —— 额外的警告/检查器。会产生更多需要审阅的结果。请参阅
```
references/additional-settings.md
```
。
边界安全采用 —— 指向独立技能。此处不应用任何更改。

Decision document

决策文档

The skill creates or updates

xcode-security-settings.md

to record every setting decision (kept, deferred, disabled, with rationale). Edit the path to relocate.

Path:
```
xcode-security-settings.md
```


Include the ⚠️ blockquote only when the project is **not version-controlled**; omit it otherwise.

The decision document should live in the same directory as the rest of the documentation, or at the project level.

此技能会创建或更新

xcode-security-settings.md

，以记录每个设置决策（保留、推迟、禁用及理由）。可编辑路径进行迁移。

路径：
```
xcode-security-settings.md
```


仅当项目**未进行版本控制**时，才包含⚠️块引用；否则省略。

决策文档应与其他文档放在同一目录，或放在项目根目录。

Item omission rules

项省略规则

A plan item is omitted entirely when it doesn't apply:

Enhanced Security — omit if every supported-product-type bucket from Phase 3 step 4 is Up-to-date or Skipped.
Basic Clang safety warnings — omit if pure-Swift, or if every relevant setting is
```
already hardened
```
on every applicable target.
Inquire about disabled settings — omit if the
```
deliberately disabled
```
predicate yields no rows (after excluding
```
ENABLE_POINTER_AUTHENTICATION = NO
```
on non-arm64e platforms).

Hardware memory tagging — omit if no target's

SUPPORTED_PLATFORMS

SDKROOT

matches

macosx

iphoneos

iphonesimulator

xros

, or

xrsimulator

Additional diagnostic settings — never omitted; always offered.
Bounds safety adoption — omit if no C or C++ code is present.

当某项不适用于项目时，完全省略该项：

增强安全 —— 如果阶段3步骤4中所有支持产品类型的分类均为最新或跳过，则省略。
基础Clang安全警告 —— 如果是纯Swift项目，或者每个相关设置在每个适用目标上均为
```
already hardened
```
，则省略。
查询禁用设置 —— 如果
```
deliberately disabled
```
断言无匹配行（排除非arm64e平台上的
```
ENABLE_POINTER_AUTHENTICATION = NO
```
行），则省略。
硬件内存标记 —— 如果没有目标的
```
SUPPORTED_PLATFORMS
```
/
```
SDKROOT
```
匹配
```
macosx
```
、
```
iphoneos
```
、
```
iphonesimulator
```
、
```
xros
```
或
```
xrsimulator
```
，则省略。
额外诊断设置 —— 永不省略；始终提供。
边界安全采用 —— 如果没有C或C++代码，则省略。

Default check state

默认勾选状态

Items under Phases are default-checked (

[x]

); items (

[ ]

) are default-unchecked. The user can flip either by editing the plan file before picking Run.

阶段下的项默认勾选（

[x]

）；项（

[ ]

）默认不勾选。用户可以在选择运行前编辑计划文件来切换状态。

Step 4: Ask for approval

步骤4：请求批准

Tell the user:

"Plan written to
xcode-security-audit-plan.md
and added to the Xcode project — open it to review. Edit it as needed — uncheck or delete items to skip them; edit the decision document path to relocate. When ready, pick Run. Pick Cancel to abort without changes. Nothing is modified until you pick Run."

Then ask via

AskUserQuestion

with single-select options:

Run — proceed to "Phase 5"
Cancel — abort

告知用户：

"计划已写入
xcode-security-audit-plan.md
并添加到Xcode项目中——请打开它进行审阅。根据需要进行编辑——取消勾选或删除项以跳过；编辑决策文档路径进行迁移。准备就绪后，选择“运行”。选择“取消”则中止操作，不进行任何更改。在你选择“运行”前，不会修改任何内容。"

然后通过

AskUserQuestion

提供单选选项：

运行 —— 进入"阶段5"
取消 —— 中止操作

Step 5: Handle the response

步骤5：处理响应

If Cancel: run the two final cleanup tasks (see "Phase 7: Report and Decision Document" below —

Remove scratchpad

, then

Prompt to remove plan file

). The keep-or-remove prompt is offered on Cancel too, so the user's choice to abandon the audit doesn't silently differ from a normal completion. Report "Cancelled — no changes applied," and exit the skill.

If the plan file is missing at re-read time (the user deleted it from disk before responding), treat it as a Cancel — but skip the

Prompt to remove plan file

task (there's nothing to remove). Still run

Remove scratchpad

If Run:

XcodeRead xcode-security-audit-plan.md

. Parse:

Each
```
- [x]
```
or
```
- [X]
```
bullet is a checked item; the item name is the bold portion (between
```
**…**
```
).
Items written as
```
- [ ]
```
and items deleted from the file are skipped — both produce identical skip behavior.
Under the "Decision document" heading, the value after
```
Path:
```
is the decision document location.

Append a

## Plan Selection

section to the scratchpad via

Edit

capturing the parsed checked items and the decision-document path. Then create the fine-grained tasks listed in Track Progress. Phase 5 onward reads the scratchpad via

Read

rather than relying on memory.

If the parsed plan has zero checked items, run the two final cleanup tasks immediately and report "Plan was empty — nothing to do."

如果选择取消：运行两个最终清理任务（请参阅下方"阶段7：报告与决策文档"——

Remove scratchpad

，然后

Prompt to remove plan file

）。即使取消操作，也会提供保留或删除计划文件的提示，因此用户放弃审计的选择不会与正常完成时的行为产生差异。报告"已取消——未应用任何更改"，并退出技能。

如果重新读取时计划文件缺失（用户在响应前已从磁盘删除），则视为取消——但跳过

Prompt to remove plan file

任务（无文件可删除）。仍需运行

Remove scratchpad

。

如果选择运行：执行

XcodeRead xcode-security-audit-plan.md

。解析：

每个
```
- [x]
```
或
```
- [X]
```
项目符号是已勾选的项；项名称是加粗部分（
```
**…**
```
之间的内容）。
写为
```
- [ ]
```
的项以及从文件中删除的项会被跳过——两者的跳过行为相同。
在"决策文档"标题下，
```
Path:
```
后的内容是决策文档的位置。

通过

Edit

工具在临时文件中追加

## Plan Selection

部分，记录解析后的已勾选项和决策文档路径。然后创建进度跟踪中列出的细粒度任务。阶段5及以后通过

Read

工具读取临时文件，而非依赖内存。

如果解析后的计划没有已勾选项，则立即运行两个最终清理任务，并报告"计划为空——无操作可执行"。

Phase 5: Apply Settings

阶段5：应用设置

Read only from the audit table for build-setting state.

How to apply build settings:

Project uses
.xcconfig
files — edit the xcconfig directly. Supports both project-level and target-level settings.
Project uses
.pbxproj
only — use
```
UpdateTargetBuildSetting
```
for target-level settings and
```
UpdateProjectBuildSetting
```
for project-level settings.
Mixed — if a target has an
```
.xcconfig
```
file, edit the xcconfig. Otherwise, use the Xcode build setting tools. Never introduce a new configuration method.

Prefer project-level when possible (less duplication). For most projects,

ENABLE_ENHANCED_SECURITY

should be set at project level such that any existing and future build targets inherit this setting. This setting should be disabled only after serious consideration and with strong justification.

仅从审计表读取构建设置状态。

如何应用构建设置：

项目使用
.xcconfig
文件 —— 直接编辑xcconfig文件。支持项目级和目标级设置。
项目仅使用
.pbxproj
—— 对目标级设置使用
```
UpdateTargetBuildSetting
```
，对项目级设置使用
```
UpdateProjectBuildSetting
```
。
混合使用 —— 如果目标有
```
.xcconfig
```
文件，则编辑xcconfig文件。否则，使用Xcode构建设置工具。绝不要引入新的配置方式。

尽可能优先使用项目级设置（减少重复）。对于大多数项目，应在项目级设置

ENABLE_ENHANCED_SECURITY

，以便所有现有和未来的构建目标都继承此设置。只有经过认真考虑并有充分理由时，才应禁用此设置。

Step 1: Enhanced Security

步骤1：增强安全

The fine-grained

Apply Enhanced Security to <target>

tasks created in Phase 4 step 5 already enumerate the targets needing changes (the Partial, Off, and No-entitlements-file buckets — Up-to-date and Skipped are excluded). Walk those tasks.

Read

references/enhanced-security.md

for the full key list, defaults, deprecated keys, version migration, and the supported product-type list. For details on individual sub-options, see:

```
references/pointer-authentication.md
```
— arm64e pointer signing
```
references/typed-allocators.md
```
— type-aware memory allocation
```
references/stack-zero-init.md
```
— automatic stack variable zeroing
```
references/readonly-platform-memory.md
```
— dyld state protection
```
references/runtime-restrictions.md
```
— dylib and Mach message restrictions

references/security-compiler-warnings.md

— security-focused compiler warnings

```
references/cpp-hardening.md
```
— C++ stdlib hardening and bounds checking
```
references/hardware-memory-tagging.md
```
— ARM MTE

Pointer authentication and binary dependencies. Enhanced Security is a bundle of independent protections; only pointer authentication cascades to

arm64e

. Always recommend

ENABLE_ENHANCED_SECURITY = YES

at the project level. If the project has a binary Swift Package, xcframework, or prebuilt framework that does not ship

arm64e

, the right mitigation is to override

ENABLE_POINTER_AUTHENTICATION = NO

at the target level on every target that links the dependency — not to skip Enhanced Security. List the offending dependencies in the report so the user can ask the vendor for

arm64e

support and lift the override later.

Producer side — universal binary on library/framework targets. Pointer authentication is highly recommended on library and framework targets too — do not skip it on the grounds that the universal recipe produces a larger on-disk artifact (RAM footprint and execution cost are unchanged; dyld loads only one slice). For each target in the Library/framework bucket from Phase 3 step 4, Phase 5 below also applies a target-level

ARCHS = "arm64 arm64e"

and

ONLY_ACTIVE_ARCH = NO

(Release) so consumers can pick either slice. See

references/universal-binaries-for-libraries.md

For each task:

Compose the change set from the bucket delta in the scratchpad.
- Entitlements-supported buckets (Partial / Off / No-entitlements-file): entitlements add/remove/update; create
```
.entitlements
```
  if missing and wire
```
CODE_SIGN_ENTITLEMENTS
```
  . DriverKit targets are supported for build settings only — skip entitlement changes for them.
- Library/framework bucket: no entitlements work. The change set is the universal-binary recipe — see item 2 below.
Build settings: if xcconfig, set
```
ENABLE_ENHANCED_SECURITY = YES
```
at project level there; otherwise
```
UpdateProjectBuildSetting
```
. Because a project-level
```
ENABLE_ENHANCED_SECURITY = YES
```
cascades
```
ENABLE_POINTER_AUTHENTICATION = YES
```
to every target, pre-write a target-level
```
ENABLE_POINTER_AUTHENTICATION = NO
```
override on each target that either (a) has a platform that doesn't support arm64e (detect via
```
SDKROOT
```
/
```
SUPPORTED_PLATFORMS
```
from the audit table), or (b) links a binary dependency that doesn't ship
```
arm64e
```
. Skip targets that already have an explicit target-level value per the audit table.
For each Library/framework-bucket target where pointer authentication will end up enabled (the target's platform supports arm64e and there is no existing target-level
```
ENABLE_POINTER_AUTHENTICATION = NO
```
), also pre-write target-level
```
ARCHS = "arm64 arm64e"
```
and
```
ONLY_ACTIVE_ARCH = NO
```
(Release configuration). Use the target's xcconfig if it has one, otherwise
```
UpdateTargetBuildSetting
```
. Skip targets that already have an explicit
```
ARCHS
```
per the audit table.
Do not auto-enable default-OFF sub-options (MTE family); those are handled by Step 3 below if checked.
Apply entitlements edits, build-setting changes, and any new
```
.entitlements
```
files atomically per target.

After all targets are processed, report: "Enabled Enhanced Security on N target(s). Removed M deprecated entitlement(s). Upgraded version string to 2 on K target(s). Added arm64e override on T target(s). Configured universal binary on U library/framework target(s)."

The user already approved this in "Phase 4" — no further prompt is needed.

The per-target

Apply Enhanced Security

tasks dominate Phase-5 wall time on multi-target projects. Each one writes build settings and edits the target's

.entitlements

plist.

阶段4步骤5创建的细粒度

Apply Enhanced Security to <target>

任务已列出需要更改的目标（部分完成、未启用和无权限文件分类——排除最新和跳过）。处理这些任务。

请查看

references/enhanced-security.md

获取完整的密钥列表、默认值、已弃用密钥、版本迁移以及支持的产品类型列表。有关各个子选项的详细信息，请参阅：

```
references/pointer-authentication.md
```
—— arm64e指针签名
```
references/typed-allocators.md
```
—— 类型感知内存分配
```
references/stack-zero-init.md
```
—— 自动栈变量清零
```
references/readonly-platform-memory.md
```
—— dyld状态保护
```
references/runtime-restrictions.md
```
—— dylib和Mach消息限制

references/security-compiler-warnings.md

—— 聚焦安全的编译器警告

```
references/cpp-hardening.md
```
—— C++标准库加固和边界检查
```
references/hardware-memory-tagging.md
```
—— ARM MTE

指针认证与二进制依赖。 增强安全是一组独立的保护措施；只有指针认证会关联到

arm64e

。始终建议在项目级设置

ENABLE_ENHANCED_SECURITY = YES

。如果项目包含未提供

arm64e

版本的二进制Swift包、xcframework或预构建框架，正确的缓解措施是在每个链接该依赖的目标上设置目标级

ENABLE_POINTER_AUTHENTICATION = NO

覆盖——而非跳过增强安全。在报告中列出有问题的依赖，以便用户可以向供应商请求

arm64e

支持，之后再取消覆盖。

生产者端——库/框架目标的通用二进制文件。 指针认证在库和框架目标上也高度推荐——不要因为通用二进制方案会产生更大的磁盘工件而跳过它（内存占用和执行成本不变；dyld仅加载一个切片）。对于阶段3步骤4中属于库/框架分类的每个目标，下方的阶段5还会应用目标级

ARCHS = "arm64 arm64e"

和

ONLY_ACTIVE_ARCH = NO

（Release配置），以便消费者可以选择任一切片。请参阅

references/universal-binaries-for-libraries.md

。

针对每个任务：

根据临时文件中的分类增量组成变更集
- 支持权限分类（部分完成/未启用/无权限文件）：添加/删除/更新权限；如果缺失则创建
```
.entitlements
```
  并关联
```
CODE_SIGN_ENTITLEMENTS
```
  。DriverKit目标仅支持构建设置——跳过其权限更改。
- 库/框架分类：无需处理权限。变更集为通用二进制方案——请参阅下方第2点。
构建设置： 如果使用xcconfig，在项目级设置
```
ENABLE_ENHANCED_SECURITY = YES
```
；否则使用
```
UpdateProjectBuildSetting
```
。由于项目级
```
ENABLE_ENHANCED_SECURITY = YES
```
会将
```
ENABLE_POINTER_AUTHENTICATION = YES
```
传递给每个目标，请预先为以下目标写入目标级
```
ENABLE_POINTER_AUTHENTICATION = NO
```
覆盖：(a) 平台不支持arm64e（通过审计表中的
```
SDKROOT
```
/
```
SUPPORTED_PLATFORMS
```
检测），或(b) 链接了未提供
```
arm64e
```
版本的二进制依赖。跳过审计表中已有显式目标级值的目标。
对于每个库/框架分类目标，如果最终会启用指针认证（目标平台支持arm64e且没有现有的目标级
```
ENABLE_POINTER_AUTHENTICATION = NO
```
），还需预先写入目标级
```
ARCHS = "arm64 arm64e"
```
和
```
ONLY_ACTIVE_ARCH = NO
```
（Release配置）。如果目标有xcconfig文件，则使用该文件；否则使用
```
UpdateTargetBuildSetting
```
。跳过审计表中已有显式
```
ARCHS
```
值的目标。
不要自动启用默认关闭的子选项（MTE系列）；如果勾选，这些会在下方步骤3中处理。
应用权限编辑、构建设置更改以及任何新的
```
.entitlements
```
文件，每个目标的操作都是原子性的。

处理完所有目标后，报告："已在N个目标上启用增强安全。已移除M个已弃用权限。已将K个目标的版本字符串升级到2。已在T个目标上添加arm64e覆盖。已为U个库/框架目标配置通用二进制文件。"

用户已在"阶段4"批准此操作——无需进一步提示。

在多目标项目中，按目标划分的

Apply Enhanced Security

任务是阶段5耗时的主要部分。每个任务都会写入构建设置并编辑目标的

.entitlements

属性列表。

Step 2: Basic Clang Safety Warnings

步骤2：基础Clang安全警告

If pure Swift, skip. Skip individual settings whose audit-table row is

already hardened

on a given target. Otherwise apply target-level (see "How to apply build settings"):

```
GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR
```

GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE

```
CLANG_WARN_IMPLICIT_FALLTHROUGH = YES
```
```
GCC_WARN_64_TO_32_BIT_CONVERSION = YES
```

GCC_TREAT_IMPLICIT_FUNCTION_DECLARATIONS_AS_ERRORS = YES

(C/ObjC/ObjC++ only)

CLANG_ANALYZER_SECURITY_FLOATLOOPCOUNTER = YES

CLANG_ANALYZER_SECURITY_INSECUREAPI_RAND = YES

CLANG_ANALYZER_SECURITY_INSECUREAPI_STRCPY = YES

Report briefly: "Enabled additional compiler warnings."

如果是纯Swift项目，跳过。跳过审计表行中在给定目标上为

already hardened

的单个设置。否则应用目标级设置（请参阅"如何应用构建设置"）：

```
GCC_WARN_ABOUT_RETURN_TYPE = YES_ERROR
```

GCC_WARN_UNINITIALIZED_AUTOS = YES_AGGRESSIVE

```
CLANG_WARN_IMPLICIT_FALLTHROUGH = YES
```
```
GCC_WARN_64_TO_32_BIT_CONVERSION = YES
```

GCC_TREAT_IMPLICIT_FUNCTION_DECLARATIONS_AS_ERRORS = YES

（仅适用于C/ObjC/ObjC++）

CLANG_ANALYZER_SECURITY_FLOATLOOPCOUNTER = YES

CLANG_ANALYZER_SECURITY_INSECUREAPI_RAND = YES

CLANG_ANALYZER_SECURITY_INSECUREAPI_STRCPY = YES

简要报告："已启用额外编译器警告。"

Step 3: Hardware Memory Tagging

步骤3：硬件内存标记

If the Hardware memory tagging plan item was unchecked or deleted, skip this step.

Hardware memory tagging is supported only for targets whose

SUPPORTED_PLATFORMS

(or

SDKROOT

) is

macosx

iphoneos

iphonesimulator

, or

xros

xrsimulator

. Hardware backing is M5-class Apple silicon and later.

Read

references/hardware-memory-tagging.md

and apply the soft-mode MTE entitlement to every supported target. The user already approved this in "Phase 4" — no further prompt is needed.

如果"硬件内存标记"计划项未勾选或已删除，跳过此步骤。

仅当目标的

SUPPORTED_PLATFORMS

（或

SDKROOT

）为

macosx

、

iphoneos

iphonesimulator

或

xros

xrsimulator

时，才支持硬件内存标记。硬件支持为M5级及更高版本的Apple芯片。

请查看

references/hardware-memory-tagging.md

，并为每个支持的目标应用软模式MTE权限。用户已在"阶段4"批准此操作——无需进一步提示。

Step 4: Additional Diagnostic Settings

步骤4：额外诊断设置

If the Additional diagnostic settings plan item was unchecked or deleted, skip this step.

Read

references/additional-settings.md

and follow it. The user already approved this in "Phase 4" — no further prompt is needed.

如果"额外诊断设置"计划项未勾选或已删除，跳过此步骤。

请查看

references/additional-settings.md

并按照说明操作。用户已在"阶段4"批准此操作——无需进一步提示。

Step 5: Bounds Safety Adoption

步骤5：边界安全采用

If the Bounds safety adoption plan item was unchecked or deleted, skip this step.

This step does not apply changes — it emits guidance only.

For C projects, print:

"To adopt
ENABLE_C_BOUNDS_SAFETY
(annotation-based bounds safety for C), invoke the
adopt-c-bounds-safety
skill."

For C++ projects, print:

"To adopt
ENABLE_CPLUSPLUS_BOUNDS_SAFE_BUFFERS
(C++ bounds-safe buffer patterns), read the documentation at https://clang.llvm.org/docs/SafeBuffers.html"

如果"边界安全采用"计划项未勾选或已删除，跳过此步骤。

此步骤不应用更改——仅发出指南。

对于C项目，打印：

"要采用
ENABLE_C_BOUNDS_SAFETY
（基于注解的C语言边界安全），请调用
adopt-c-bounds-safety
技能。"

对于C++项目，打印：

"要采用
ENABLE_CPLUSPLUS_BOUNDS_SAFE_BUFFERS
（C++边界安全缓冲区模式），请参阅文档：https://clang.llvm.org/docs/SafeBuffers.html"

Phase 6: Inquire about Disabled Settings

阶段6：查询禁用设置

If the Inquire about disabled settings plan item was unchecked or deleted, skip this phase.

This phase pauses for one user response per deliberately-disabled setting that lacks a documented rationale. If the candidate list is long, surface the count up front so the user knows what to expect ("I found 7 deliberately-disabled settings; let me ask about each").

A row is a candidate when the

deliberately disabled

predicate (defined in

references/reading-build-settings.md

) holds. Exclude

ENABLE_POINTER_AUTHENTICATION = NO

rows on targets whose platform doesn't support arm64e (the skill itself sets it there); flag arm64e-capable targets. Restrict to settings whose Scope (in

references/settings-and-entitlements-catalog.md

) covers a language detected in Phase 3 step 2.

For each candidate, walk the corresponding

Inquire about <MACRO> on <target>

task created in Phase 4 step 5:

If the decision document has an entry with status
```
Disabled
```
and a rationale → note it in the report and move on.
Otherwise →
```
AskUserQuestion
```
: "I found
```
<MACRO>
```
explicitly set to
```
NO
```
with no explanation. Is there a reason for this?" Double-check that the macro is
```
deliberately disabled
```
and not merely at Xcode's default OFF — only call out explicit overrides. Record the rationale (or recommend re-enabling if none).

Same flow applies to

ENABLE_ENHANCED_SECURITY = NO

if present in the audit table.

如果"查询禁用设置"计划项未勾选或已删除，跳过此阶段。

此阶段会针对每个故意禁用且未记录理由的设置暂停，等待用户响应。如果候选列表较长，先告知数量，让用户有所预期（"我发现7个故意禁用的设置；我会逐个询问"）。

当

deliberately disabled

断言（定义于

references/reading-build-settings.md

）成立时，该行是候选项。排除非arm64e平台上的

ENABLE_POINTER_AUTHENTICATION = NO

行（技能本身会在这些平台设置该值）；标记支持arm64e的目标。仅保留

references/settings-and-entitlements-catalog.md

中Scope覆盖阶段3步骤2检测到的语言的设置。

针对每个候选项，处理阶段4步骤5创建的对应

Inquire about <MACRO> on <target>

任务：

如果决策文档中有状态为
```
Disabled
```
且带有理由的条目→在报告中记录并继续。
否则→调用
```
AskUserQuestion
```
："我发现
```
<MACRO>
```
被显式设置为
```
NO
```
且无解释。是否有理由这样做？" 再次确认该宏是
```
deliberately disabled
```
而非仅仅是Xcode默认关闭——仅指出显式覆盖。记录理由（如果没有理由，则建议重新启用）。

如果审计表中存在

ENABLE_ENHANCED_SECURITY = NO

，同样遵循此流程。

Phase 7: Report and Decision Document

阶段7：报告与决策文档

Produce a lean summary:

Enabled — project-wide settings that were enabled.
Enhanced Security per target — one line per target: name, final status (up-to-date / applied / skipped-by-user), terse delta (entitlements added, deprecated keys removed, version bumps, whether an entitlements file was created). Roll up Skipped targets into one line.
Already active — settings already configured correctly.
Inquired — settings found disabled and the outcome of the inquiry.

Decision document. Read

references/decision-document.md

and follow it to create or update the decision document.

After Phase 7 — and on any error path during Phases 5–7 — these two final tasks run in order:

Remove scratchpad
—
```
Bash rm <project-root>/xcode-security-audit-scratchpad.md
```
. The scratchpad is agent-internal state with no value to preserve; removal is unconditional.
Prompt to remove plan file
— ask the user via
```
AskUserQuestion
```
: "The audit is complete. Remove the plan file
```
xcode-security-audit-plan.md
```
from your project?"
- Yes, remove it (Recommended) →
```
XcodeRM xcode-security-audit-plan.md deleteFiles:true
```
- No, keep it → leave it in place; it stays in the Project Navigator as a record of what was approved. The user can delete it later from Xcode or Finder.

If either removal fails, warn the user but do not block exit.

生成简洁的摘要：

已启用——已启用的项目级设置。
按目标划分的增强安全——每个目标一行：名称、最终状态（最新/已应用/用户跳过）、简短增量（添加的权限、移除的已弃用密钥、版本升级、是否创建了权限文件）。将跳过的目标汇总为一行。
已激活——已正确配置的设置。
已查询——发现的禁用设置以及查询结果。

决策文档。 请查看

references/decision-document.md

并按照说明创建或更新决策文档。

阶段7完成后——以及阶段5–7中的任何错误路径——会按顺序运行以下两个最终任务：

Remove scratchpad
——执行
```
Bash rm <project-root>/xcode-security-audit-scratchpad.md
```
。临时文件是代理内部状态，没有保留价值；无条件删除。
Prompt to remove plan file
——通过
```
AskUserQuestion
```
询问用户："审计已完成。是否从项目中删除计划文件
```
xcode-security-audit-plan.md
```
？"
- 是，删除（推荐）→执行
```
XcodeRM xcode-security-audit-plan.md deleteFiles:true
```
- 否，保留→保留文件；它会留在项目导航器中，作为已批准操作的记录。用户之后可以从Xcode或Finder中删除它。

如果删除操作失败，向用户发出警告，但不阻止退出。

User-Facing Interaction Guidelines

用户交互指南

Keep replies lean. Short sentences.
Keep user questions minimal. Two scheduled questions: the plan approval prompt (Run / Cancel) at the end of "Phase 4", and the keep-or-remove-plan-file prompt at the end of "Phase 7". Other questions are situational: inquiries about deliberately-disabled settings during "Phase 6" (only when an explicit
```
= NO
```
lacks a documented rationale).
Report progress so the user can track: "Enabling...", "Evaluating...", "Keeping/Reverting..."
Use
AskUserQuestion
for the plan approval (Run / Cancel), for inquiring about disabled settings during "Phase 6", and for the keep-or-remove-plan-file prompt at the end of "Phase 7".
When asking a question provide context the user needs to answer the question. For example, describe the benefit of the security protection before asking whether to enable it. Describe it in terms of the protection it provides, not how it is enabled.
When emitting lists of Xcode build settings, use bullet lists Don't use comma-separated lists.

回复简洁。使用短句。
尽量减少用户问题。有两个预定问题：阶段4末尾的计划批准提示（运行/取消），以及阶段7末尾的保留或删除计划文件提示。其他问题是情境性的：阶段6中查询故意禁用的设置（仅当显式
```
= NO
```
且无记录理由时）。
报告进度，以便用户跟踪："正在启用..."、"正在评估..."、"正在保留/恢复..."
**使用
```
AskUserQuestion
```
**处理计划批准（运行/取消）、阶段6中查询禁用设置，以及阶段7末尾的保留或删除计划文件提示。
提问时提供用户回答所需的上下文。例如，在询问是否启用安全保护前，描述该保护的益处。用它提供的保护来描述，而非启用方式。
列出Xcode构建设置时，使用项目符号列表。不要使用逗号分隔的列表。