Back to Details

reproduce-and-fix-issues

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Reproduce and fix issues

重现并修复问题

Wait for a trusted triage marker in the source thread. Reproduce the exact symptom through the target app's real UI. Verify an existing fix when one exists. Attempt a bounded fix only after a confirmed repro.
Load the external Benny configuration supplied by the automation. If the config, required actions, control adapter, or completed feature map is missing, fail closed.
等待源线程中出现可信的分类标记。通过目标应用的真实UI重现确切症状。若存在现有修复方案则进行验证。仅在确认重现问题后尝试进行受限修复。
加载自动化工具提供的外部Benny配置。若配置、所需操作、控制适配器或已完成功能映射缺失，则终止流程并返回失败。

Hard safety rules

硬性安全规则

  • Freeze the source channel and root thread coordinates before doing any work.
  • Never post a root message in the source channel.
  • Preflight the source parent before every source-thread post.
  • The coordinator is the only Slack poster.
  • Delegated analysis workers are read-only and return findings or media notes.
  • A fix-phase code worker may edit only when its environment provably excludes Slack credentials and every Slack write action. Otherwise the coordinator edits.
  • Every child prompt must explicitly forbid 
    SendSlackMessage
    , 
    PostToSlack
    , 
    chat.postMessage
    , and all other Slack writes.
  • Never give a child a Slack token, posting instructions, source coordinates for posting, or permission to report externally.
  • If a child needs Slack write access to run, do not launch it.
  • Utility bots are evidence sources. They do not own the fix unless a person explicitly delegated the fix to them.
  • The exact discriminating symptom must appear twice through real UI interaction.
  • State inspection may confirm an observation. It must not inject or force the symptom.
  • No confirmed repro means no authored fix.
  • Existing pull requests or commits switch the run to verify mode. Do not author over them.
  • Use 
    github.com
    pull request links.
  • Keep captures, recordings, logs, and tokens out of source control.
  • Use pstack's 
    principle-guard-the-context-window
    for delegated analysis.
  • Apply pstack's 
    principle-sequence-verifiable-units
    , 
    principle-fix-root-causes
    , and 
    principle-prove-it-works
    through repro, fix, and verification.
  • 在开展任何工作前，冻结源频道和根线程的坐标。
  • 切勿在源频道中发布根消息。
  • 在每次发布源线程消息前，预检源父消息。
  • 仅协调器可在Slack中发布消息。
  • 委托的分析工作者仅可读取信息，并返回调查结果或媒体记录。
  • 修复阶段的代码工作者仅可在其环境明确排除Slack凭据及所有Slack写入操作时进行编辑。否则由协调器进行编辑。
  • 每个子提示必须明确禁止
    SendSlackMessage
    、
    PostToSlack
    、
    chat.postMessage
    及所有其他Slack写入操作。
  • 切勿向子工作者提供Slack令牌、发布指令、发布用的源坐标或外部报告权限。
  • 若子工作者需要Slack写入权限才能运行，则不启动该工作者。
  • 实用机器人是证据来源。除非有人明确将修复工作委托给它们，否则它们不负责修复工作。
  • 必须通过真实UI交互两次重现确切的判别症状。
  • 状态检查可用于确认观察结果，但不得注入或强制触发症状。
  • 未确认重现问题则不得编写修复代码。
  • 若存在现有拉取请求或提交，则将运行模式切换为验证模式。不得在其之上编写新内容。
  • 使用
    github.com
    的拉取请求链接。
  • 请勿将捕获内容、录制文件、日志和令牌存入版本控制系统。
  • 委托分析时使用pstack的
    principle-guard-the-context-window
    原则。
  • 在重现、修复和验证过程中，应用pstack的
    principle-sequence-verifiable-units
    、
    principle-fix-root-causes
    和
    principle-prove-it-works
    原则。

1. Freeze source coordinates

1. 冻结源坐标

Before making a work list or delegating:
  1. Require the trigger channel to equal the configured source channel.
  2. Set 
    SOURCE_THREAD_TS
    to 
    trigger.thread_ts
    when present. Otherwise use 
    trigger.ts
    .
  3. Require a nonempty 
    SOURCE_THREAD_TS
    .
  4. Store 
    SOURCE_CHANNEL_ID
    and 
    SOURCE_THREAD_TS
    as immutable values.
  5. Read the source thread and verify its root has those exact coordinates.
  6. Fetch the source permalink.
Never replace these values with a reply timestamp, operations timestamp, or status-message timestamp.
Before every source-channel post:
  1. Read the thread by the immutable coordinates.
  2. Confirm the parent exists, is not deleted, and still belongs to the source channel.
  3. Send only with 
    channel=SOURCE_CHANNEL_ID
    and 
    thread_ts=SOURCE_THREAD_TS
    .
  4. Read the thread again and verify the new message is a reply.
If any check fails, post nothing. Never retry at the root or in a fallback channel.
在制定工作清单或委托工作前：
  1. 要求触发频道与配置的源频道一致。
  2. 若存在
    trigger.thread_ts
    ，则将
    SOURCE_THREAD_TS
    设置为该值。否则使用
    trigger.ts
    。
  3. 要求
    SOURCE_THREAD_TS
    非空。
  4. 将
    SOURCE_CHANNEL_ID
    和
    SOURCE_THREAD_TS
    存储为不可变值。
  5. 读取源线程并验证其根消息具有完全匹配的坐标。
  6. 获取源消息的永久链接。
切勿用回复时间戳、操作时间戳或状态消息时间戳替换这些值。
在每次发布源频道消息前：
  1. 通过不可变坐标读取线程。
  2. 确认父消息存在、未被删除且仍属于源频道。
  3. 仅使用
    channel=SOURCE_CHANNEL_ID
    和
    thread_ts=SOURCE_THREAD_TS
    发送消息。
  4. 再次读取线程并验证新消息是回复。
若任何检查失败，则不发布任何消息。切勿在根频道或备用频道重试。

2. Wait for the triage contract

2. 等待分类约定

Watch the source thread for the configured verdict budget. Stay silent while waiting.
Accept a verdict only when:
  • Its author matches 
    slack.triage_identity_user_id
    .
  • It is a reply under 
    SOURCE_THREAD_TS
    .
  • It contains exactly one configured marker.
Public marker forms:
text
[benny:bug]
[benny:bug] tracker=https://tracker.example/issue/123
[benny:performance]
[benny:performance] tracker=https://tracker.example/issue/123
[benny:other]
Proceed only for 
bug
or 
performance
. Capture the optional tracker URL. Stop silently for 
other
, a missing verdict, an untrusted author, conflicting markers, or a timeout.
This marker replaces private bot identities and free-form verdict matching.
在源线程中等待配置的判定时限。等待期间保持静默。
仅在满足以下条件时接受判定：
  • 作者匹配
    slack.triage_identity_user_id
    。
  • 消息是
    SOURCE_THREAD_TS
    下的回复。
  • 消息包含恰好一个配置的标记。
公开标记格式：
text
[benny:bug]
[benny:bug] tracker=https://tracker.example/issue/123
[benny:performance]
[benny:performance] tracker=https://tracker.example/issue/123
[benny:other]
仅针对
bug
或
performance
标记继续流程。捕获可选的跟踪器URL。若标记为
other
、缺少判定、作者不可信、标记冲突或超时，则静默终止流程。
此标记取代了私有机器人身份和自由格式的判定匹配方式。

3. Apply ownership and fix-artifact gates

3. 应用归属权和修复工件检查

Re-read the thread immediately before starting work.
在开始工作前立即重新读取线程。

Someone is explicitly fixing it

有人明确负责修复

Stop when a person clearly claims the fix, gives a concrete implementation plan, or asks another agent to implement, patch, fix, or open a pull request.
Do not treat these as fix ownership:
  • A bot summarizes evidence.
  • A tool looks up logs or tickets.
  • Someone asks a bot to diagnose, explain, inspect, or reproduce.
  • A bot posts a cause hypothesis without agreeing to implement it.
Judge the requested action, not the presence of a bot.
当有人明确声称负责修复、给出具体实现计划，或要求其他Agent实现、修补、修复或打开拉取请求时，终止流程。
以下情况不视为拥有修复归属权：
  • 机器人总结证据。
  • 工具查询日志或工单。
  • 有人要求机器人诊断、解释、检查或重现问题。
  • 机器人发布原因假设但未同意实施修复。
判断依据是请求的操作，而非是否存在机器人。

A fix artifact already exists

已存在修复工件

If an open pull request or merged commit plausibly fixes this report, switch to 
references/verify-existing-fix.md
.
An artifact may come from the thread, tracker issue, repository history, or pull request search. A claim without a commit or pull request is not a fix artifact.
If a person owns the work but has not produced an artifact, stop. Do not race them.
若存在开放的拉取请求或已合并的提交似乎可修复此报告，则切换至
references/verify-existing-fix.md
流程。
工件可来自线程、跟踪器问题、仓库历史或拉取请求搜索。仅声称修复但无提交或拉取请求的情况不视为存在修复工件。
若有人负责工作但尚未生成工件，则终止流程。切勿与其竞争。

4. Open an optional operations thread

4. 打开可选的操作线程

If 
slack.operations_channel_id
is configured, the coordinator may create one root status message there. This is the only allowed root post in the repro workflow.
Store its coordinates as 
OPERATIONS_CHANNEL_ID
and 
OPERATIONS_THREAD_TS
. Never confuse them with the source coordinates.
Use the configured plain Unicode status strings. Keep status text short:
  • Reproducing
  • Could not reproduce
  • Blocked
  • Reproduced
  • Verifying existing fix
  • Attempting bounded fix
  • Draft pull request opened
  • Fix did not land
Prefer configured Cursor Slack actions. Use 
BENNY_SLACK_BOT_TOKEN
only when the user configured it for a narrow missing capability such as editing this one status message. Never expose the token to a worker.
If no operations channel is configured, keep detailed status in the automation run output. Do not substitute a source-channel root message.
若配置了
slack.operations_channel_id
，协调器可在该频道创建一条根状态消息。这是重现工作流中唯一允许发布的根消息。
将其坐标存储为
OPERATIONS_CHANNEL_ID
和
OPERATIONS_THREAD_TS
。切勿将其与源坐标混淆。
使用配置的纯Unicode状态字符串。保持状态文本简短：
  • Reproducing（正在重现）
  • Could not reproduce（无法重现）
  • Blocked（已阻塞）
  • Reproduced（已重现）
  • Verifying existing fix（正在验证现有修复）
  • Attempting bounded fix（正在尝试受限修复）
  • Draft pull request opened（已打开草稿拉取请求）
  • Fix did not land（修复未生效）
优先使用配置的Cursor Slack操作。仅当用户为特定缺失功能（如编辑此状态消息）配置了
BENNY_SLACK_BOT_TOKEN
时才使用该令牌。切勿将令牌暴露给工作者。
若未配置操作频道，则在自动化运行输出中保留详细状态。切勿用源频道的根消息替代。

5. Load and check the control adapter

5. 加载并检查控制适配器

Read 
references/control-adapter.md
and the completed map at 
control.feature_map_path
, then invoke the skill named by 
control.skill_name
.
Find the feature-map section that matches the reported user path. Read it before driving the app. If no section covers the feature, mark the run blocked instead of inventing a path or selector.
Require all seven capabilities:
  1. Bring up the configured target app and test environment.
  2. Navigate the mapped feature and exercise its documented states.
  3. Drive the real UI with clicks, typing, keys, scrolling, drag, resize, or navigation.
  4. Inspect state without mutating it.
  5. Capture screenshots.
  6. Start and stop a screen recording.
  7. Clean up processes, sessions, profiles, and temporary data.
If the adapter is absent or any required capability is missing, mark the operations status as blocked and stop. Do not pretend a screenshot, unit test, state mutation, or source reading is a UI repro.
读取
references/control-adapter.md
和
control.feature_map_path
下的已完成映射，然后调用
control.skill_name
指定的技能。
找到与报告的用户路径匹配的功能映射部分。在驱动应用前读取该部分。若没有部分覆盖该功能，则标记运行已阻塞，而非自行创建路径或选择器。
要求具备全部七项能力：
  1. 启动配置的目标应用和测试环境。
  2. 导航至映射的功能并执行其文档化的状态。
  3. 通过点击、输入、按键、滚动、拖拽、调整大小或导航操作驱动真实UI。
  4. 检查状态而不修改它。
  5. 捕获截图。
  6. 启动和停止屏幕录制。
  7. 清理进程、会话、配置文件和临时数据。
若适配器缺失或任何所需能力缺失，则将操作状态标记为已阻塞并终止流程。切勿将截图、单元测试、状态修改或源代码读取视为UI重现。

6. Study the report

6. 研究报告

Read the full source thread and tracker issue when present.
Collect:
  • Exact action path
  • Expected behavior
  • Observed behavior
  • Discriminating state where they diverge
  • Frequency
  • Version, environment, and platform
  • Attachments and error signatures
  • Candidate code area
Inspect screenshots and video. Use read-only parallel workers for code history, test ideas, blast-radius mapping, and media review when useful. Each worker gets a narrow question and the Slack-write prohibition.
Use pstack's 
how
skill to trace the action through the repository. Use 
why
for regression history and defensive code. Form competing cause hypotheses and identify evidence that would separate them.
读取完整的源线程和跟踪器问题（若存在）。
收集以下信息：
  • 确切操作路径
  • 预期行为
  • 观察到的行为
  • 两者产生差异的判别状态
  • 出现频率
  • 版本、环境和平台
  • 附件和错误签名
  • 候选代码区域
检查截图和视频。若有用，使用只读并行工作者进行代码历史查询、测试思路、影响范围映射和媒体审查。每个工作者会收到一个明确的问题以及禁止Slack写入的要求。
使用pstack的
how
技能追踪操作在仓库中的执行路径。使用
why
技能查询回归历史和防御性代码。形成相互竞争的原因假设，并确定可区分这些假设的证据。

7. Reproduce

7. 重现问题

Bring up the target app through the control adapter.
Confirm the correct app, workspace, account, data set, and feature state before acting. Use stable app markers. Do not rely on window order or a familiar title alone.
Drive the reported path through real UI actions.
Before calling it reproduced:
  1. Name the correct final state.
  2. Name the broken final state.
  3. Reach the point where they diverge.
  4. Observe the broken state.
  5. Reset enough state to make the second attempt independent.
  6. Repeat the same path and observe the same broken state again.
  7. Cross-check a real state value when possible.
An expected dialog, loading state, or setup step is not the bug. Capture the final state that distinguishes correct from broken behavior.
Use the configured repro budget. If the symptom does not reproduce within it, report a clean 
Could not reproduce
outcome. If the environment cannot provide a required capability, report 
Blocked
and state what was missing.
通过控制适配器启动目标应用。
在操作前确认正确的应用、工作区、账户、数据集和功能状态。使用稳定的应用标记。切勿仅依赖窗口顺序或熟悉的标题。
通过真实UI操作执行报告的路径。
在确认重现前需完成以下步骤：
  1. 明确正确的最终状态。
  2. 明确异常的最终状态。
  3. 到达两者产生差异的节点。
  4. 观察异常状态。
  5. 重置足够的状态以确保第二次尝试独立。
  6. 重复相同路径并再次观察到相同的异常状态。
  7. 尽可能交叉验证真实状态值。
预期的对话框、加载状态或设置步骤不属于bug。捕获区分正确与异常行为的最终状态。
使用配置的重现时限。若在时限内未重现症状，则报告明确的
Could not reproduce
（无法重现）结果。若环境无法提供所需能力，则报告
Blocked
（已阻塞）并说明缺失的内容。

8. Capture and review evidence

8. 捕获并审查证据

For a successful repro:
  • Record the full path through the symptom.
  • Capture a screenshot of the broken final state.
  • Save a short note with the exact steps and observed state.
  • Keep artifacts in the configured temporary artifact directory.
Have a read-only media reviewer answer one question: does the evidence visibly show the discriminating broken state?
If the answer is no or uncertain, the repro is not confirmed. Capture better evidence or use 
Could not reproduce
.
Post detailed evidence only in the operations thread when configured. Keep the source update concise.
对于成功重现的情况：
  • 录制完整的症状出现路径。
  • 捕获异常最终状态的截图。
  • 保存包含确切步骤和观察状态的简短记录。
  • 将工件保存在配置的临时工件目录中。
让只读媒体审查者回答一个问题：证据是否清晰显示了判别性的异常状态？
若答案为否或不确定，则未确认重现问题。需捕获更好的证据或使用
Could not reproduce
（无法重现）结果。
仅在配置了操作频道时，在操作线程中发布详细证据。保持源线程的更新简洁。

9. Report the repro outcome

9. 报告重现结果

Update the operations status first.
For 
Could not reproduce
or 
Blocked
, post nothing in the source thread. The operations thread or run output carries the result.
For a confirmed repro, run the source preflight and post at most one unprompted source reply:
  • Say the issue reproduced.
  • Link the operations evidence thread when one exists.
  • Include at most three short findings.
  • Link the tracker issue when one exists.
  • Do not ping an owner by default.
Attach evidence only when the configured Slack action keeps it inside the same source thread and the organization's retention policy allows it.
Wait for the configured rejection window. If a person shows that the setup or interpretation was wrong, correct the repro once. Do not start the fix phase until the window closes without a valid rejection.
首先更新操作状态。
对于
Could not reproduce
（无法重现）或
Blocked
（已阻塞）结果，不在源线程中发布任何内容。结果由操作线程或运行输出承载。
对于已确认的重现结果，执行源预检并发布至多一条主动源回复：
  • 说明问题已重现。
  • 若存在操作证据线程，则链接该线程。
  • 包含至多三项简短发现。
  • 若存在跟踪器问题，则链接该问题。
  • 默认情况下不@负责人。
仅当配置的Slack操作可将证据保留在同一源线程中，且组织的保留策略允许时，才附加证据。
等待配置的异议窗口。若有人指出设置或解释有误，则修正一次重现。直到异议窗口结束且无有效异议后，才进入修复阶段。

10. Verify an existing fix

10. 验证现有修复

When a fix artifact exists, follow 
references/verify-existing-fix.md
.
Verification must show the symptom on the baseline and its absence on the patched build. Both paths use the real UI twice.
Do not edit the existing fix, add a competing patch, or open a replacement pull request.
若存在修复工件，请遵循
references/verify-existing-fix.md
流程。
验证必须显示基线版本存在症状，而补丁版本不存在症状。两条路径均需通过真实UI各执行两次。
不得编辑现有修复、添加竞争性补丁或打开替代拉取请求。

11. Qualify a bounded fix

11. 限定受限修复

Attempt a fix only when all of these hold:
  • The outcome is a plain confirmed repro.
  • Media review confirmed the broken final state.
  • No existing fix artifact appeared.
  • No person claimed the fix during the rejection window.
  • Runtime evidence identifies the root cause.
  • The likely change fits the configured fix budget and repository scope.
  • The control adapter can run both baseline and patched builds.
If any condition fails, keep the repro report and stop without a pull request.
When the gate passes, update operations status to 
Attempting bounded fix
.
仅在满足以下所有条件时才尝试修复：
  • 结果为明确的已确认重现。
  • 媒体审查已确认异常最终状态。
  • 未出现现有修复工件。
  • 在异议窗口内无人声称负责修复。
  • 运行时证据已确定根本原因。
  • 预期的更改符合配置的修复预算和仓库范围。
  • 控制适配器可运行基线版本和补丁版本。
若任何条件不满足，则保留重现报告并终止流程，不创建拉取请求。
当检查通过时，将操作状态更新为
Attempting bounded fix
（正在尝试受限修复）。

12. Root-cause and implement

12. 根本原因分析与实现

The coordinator owns every Slack post, the final diff review, commits, and the pull request.
Read-only workers may:
  • Trace code and history
  • Propose tests
  • Map blast radius
  • Review a diff
  • Review media
They do not edit, run external writes, post status, or own the fix.
A tightly scoped code edit may be delegated during this phase only when tool isolation removes Slack credentials and every Slack write action from that worker. Its prompt must still carry the explicit Slack-write ban. The coordinator reviews the edit and runs or verifies the required tests. If tool isolation is uncertain, keep the edit in the coordinator.
Confirm the mechanism with runtime evidence. Eliminate competing hypotheses before editing.
Fix the root cause with the smallest justified change.
  • Invoke pstack's 
    tdd
    skill when there is a cheap local test target, and write the failing test before the fix.
  • State why TDD was skipped when the path is expensive, unclear, or integration-heavy.
  • Keep unrelated cleanup out.
  • Stop if the change grows beyond the configured effort or risk budget.
协调器负责所有Slack发布、最终差异审查、提交和拉取请求。
只读工作者可执行以下操作：
  • 追踪代码和历史
  • 提出测试建议
  • 映射影响范围
  • 审查差异
  • 审查媒体
它们不得进行编辑、执行外部写入、发布状态或负责修复工作。
在此阶段，仅当工具隔离已从该工作者的环境中移除Slack凭据及所有Slack写入操作时，才可委托其进行范围严格限定的代码编辑。其提示仍需明确包含禁止Slack写入的要求。协调器需审查编辑内容并运行或验证所需测试。若工具隔离情况不确定，则由协调器进行编辑。
通过运行时证据确认机制。在编辑前排除所有相互竞争的假设。
用最小的合理更改修复根本原因。
  • 若存在低成本本地测试目标，调用pstack的
    tdd
    技能，并在修复前编写失败测试。
  • 当路径成本高、不明确或集成度高时，说明跳过TDD的原因。
  • 不包含无关的清理操作。
  • 若更改超出配置的工作量或风险预算，则终止流程。

13. Prove the fix

13. 验证修复效果

Keep the original baseline evidence.
On the patched build:
  1. Run the same real UI path.
  2. Repeat it twice.
  3. Show that the broken state is gone.
  4. Show the expected state in its place.
  5. Capture an after recording and screenshot.
  6. Cross-check the same real state value used for the baseline.
A compile, unit test, code review, or plausible diff is not after evidence.
Run focused tests, then smoke the blast radius around the changed behavior. Cover nearby states, inputs, permissions, platforms, and failure paths that the change could affect. Stop without a pull request if a regression remains.
保留原始基线证据。
在补丁版本上：
  1. 运行相同的真实UI路径。
  2. 重复两次。
  3. 显示异常状态已消失。
  4. 显示预期状态已恢复。
  5. 捕获修复后的录制文件和截图。
  6. 交叉验证与基线版本相同的真实状态值。
编译、单元测试、代码审查或看似合理的差异均不属于修复后的证据。
运行针对性测试，然后检查更改行为周围的影响范围。涵盖更改可能影响的邻近状态、输入、权限、平台和故障路径。若仍存在回归，则终止流程，不创建拉取请求。

14. Open a draft pull request

14. 打开草稿拉取请求

Only after before-and-after proof:
  • Review the final diff for unrelated changes and secrets.
  • Run the repository's required checks.
  • Create small ordered commits when the repository workflow allows it.
  • Open a draft pull request. Never merge or deploy from this workflow.
  • Link the configured tracker issue using the tracker's supported pull request syntax.
  • Use the configured public URL form, normally 
    https://github.com/{owner}/{repo}/pull/{number}
    .
  • Include the repro steps, root cause, test result, before and after evidence, and blast-radius checks.
  • Run the pull request text and all Slack updates through pstack's 
    unslop
    skill.
If pull request creation fails, do not claim success. Keep the commit or branch state in the run output and mark operations status 
Fix did not land
.
On success, mark operations status 
Draft pull request opened
and post one concise reply in the operations thread with the linked pull request. Do not create a second source-channel root or unprompted source reply.
仅在获取前后对比证据后：
  • 审查最终差异，检查是否存在无关更改和敏感信息。
  • 运行仓库要求的检查。
  • 若仓库工作流允许，创建小型有序提交。
  • 打开草稿拉取请求。切勿从此工作流进行合并或部署。
  • 使用跟踪器支持的拉取请求语法链接配置的跟踪器问题。
  • 使用配置的公共URL格式，通常为
    https://github.com/{owner}/{repo}/pull/{number}
    。
  • 包含重现步骤、根本原因、测试结果、前后证据以及影响范围检查内容。
  • 通过pstack的
    unslop
    技能处理拉取请求文本和所有Slack更新。
若拉取请求创建失败，则不得声称成功。将提交或分支状态保留在运行输出中，并将操作状态标记为
Fix did not land
（修复未生效）。
成功后，将操作状态标记为
Draft pull request opened
（已打开草稿拉取请求），并在操作线程中发布一条简洁的回复，包含链接的拉取请求。不得创建第二条源频道根消息或主动源回复。

15. Follow-ups and cleanup

15. 后续跟进与清理

Watch the configured operations thread for one follow-up window.
  • Answer a direct question from evidence already gathered.
  • Apply one concrete correction and rerun the repro once when it invalidates the setup.
  • Stay out of human coordination and side chatter.
  • Stop when asked.
Always call the control adapter's cleanup capability. Keep artifacts only as long as the configured retention policy allows.
在配置的后续跟进窗口内监控操作线程。
  • 针对已收集的证据回答直接问题。
  • 当设置被证实时，应用一次具体修正并重新运行一次重现流程。
  • 不参与人工协调和闲聊。
  • 被要求时终止流程。
始终调用控制适配器的清理能力。仅在配置的保留政策允许的时间内保留工件。