@fitlab-ai/agent-infra 0.5.3 → 0.5.5

package/README.md

@@ -410,7 +410,7 @@ The generated `.agents/.airc.json` file is the central contract between the boot
   "project": "my-project",
   "org": "my-org",
   "language": "en",
-  "templateVersion": "v0.5.3",
+  "templateVersion": "v0.5.5",
   "files": {
     "managed": [
       ".agents/workspace/README.md",

package/README.zh-CN.md

@@ -410,7 +410,7 @@ import-issue #42                    从 GitHub Issue 导入任务
   "project": "my-project",
   "org": "my-org",
   "language": "en",
-  "templateVersion": "v0.5.3",
+  "templateVersion": "v0.5.5",
   "files": {
     "managed": [
       ".agents/workspace/README.md",

package/lib/defaults.json

@@ -36,6 +36,7 @@
       ".claude/hooks/",
       ".gemini/commands/",
       ".github/hooks/check-version-format.sh",
+      ".github/scripts/",
       ".opencode/commands/"
     ],
     "merged": [

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fitlab-ai/agent-infra",
-  "version": "0.5.3",
+  "version": "0.5.5",
   "description": "Bootstrap tool for AI multi-tool collaboration infrastructure — works with Claude Code, Codex, Gemini CLI, and OpenCode",
   "license": "MIT",
   "type": "module",

package/templates/.agents/rules/issue-pr-commands.github.en.md

@@ -13,50 +13,65 @@ gh repo view --json nameWithOwner
 
 If either command fails, stop or degrade according to the calling skill.
 
+## Upstream Repository and Permission Detection
+
+Before any later `gh issue` or `gh api "repos/..."` call, follow `.agents/rules/issue-sync.md` to resolve `upstream_repo`, `has_triage`, and `has_push`.
+
+- every later `gh issue` command must use `-R "$upstream_repo"`
+- every later repository-scoped `gh api` command must use `"repos/$upstream_repo/..."`
+- keep `gh pr *` commands on the current repository without adding `-R`
+- keep organization-scoped commands such as `gh api "orgs/{owner}/..."` unchanged
+
 ## Read and Create Issues
 
 Read an Issue:
 
 ```bash
-gh issue view {issue-number} --json number,title,body,labels,state,milestone,url
+gh issue view {issue-number} -R "$upstream_repo" --json number,title,body,labels,state,milestone,url
 ```
 
 Create an Issue:
 
 ```bash
-gh issue create --title "{title}" --body "{body}" --assignee @me {label-args} {milestone-arg}
+gh issue create -R "$upstream_repo" --title "{title}" --body "{body}" --assignee @me {label-args} {milestone-arg}
 ```
 
 - expand `{label-args}` into repeated `--label` flags from the validated label list
+- pass `{label-args}` only when `has_triage=true`; otherwise omit it and continue
 - omit all `--label` flags when nothing valid remains
+- pass `{milestone-arg}` only when `has_triage=true`; otherwise omit it and continue
 - omit `{milestone-arg}` entirely when no milestone should be set
 
 Set the Issue Type:
 
 ```bash
 gh api "orgs/{owner}/issue-types" --jq '.[].name'
-gh api "repos/{owner}/{repo}/issues/{issue-number}" -X PATCH -f type="{issue-type}" --silent
+gh api "repos/$upstream_repo/issues/{issue-number}" -X PATCH -f type="{issue-type}" --silent
 ```
 
+- set the Issue Type only when `has_push=true`; otherwise skip and continue
+
 ## Update Issues
 
 Use this shape when updating titles, labels, assignees, or milestones:
 
 ```bash
-gh issue edit {issue-number} {edit-args}
+gh issue edit {issue-number} -R "$upstream_repo" {edit-args}
 ```
 
 Common arguments:
 - `--title "{title}"`
-- `--add-label "{label}"`
-- `--remove-label "{label}"`
+- `--add-label "{label}"` (only when `has_triage=true`)
+- `--remove-label "{label}"` (only when `has_triage=true`)
 - `--add-assignee @me`
-- `--milestone "{milestone}"`
+- `--milestone "{milestone}"` (only when `has_triage=true`)
+
+Do not pre-check assignee permissions. If the assignee command fails, silently skip it per the caller's contract.
 
 Close an Issue:
 
 ```bash
-gh issue close {issue-number} --reason "{reason}"
+gh issue close {issue-number} -R "$upstream_repo" --reason "{reason}"
 ```
 
 ## Read Issue Comments
@@ -64,7 +79,7 @@ gh issue close {issue-number} --reason "{reason}"
 Read Issue comments or search for existing hidden markers:
 
 ```bash
-gh api "repos/{owner}/{repo}/issues/{issue-number}/comments" --paginate
+gh api "repos/$upstream_repo/issues/{issue-number}/comments" --paginate
 ```
 
 ## Read and Create PRs
@@ -84,12 +99,21 @@ gh pr list --state {state} --base {base-branch} --json number,title,url,headRefN
 Create a PR:
 
 ```bash
-gh pr create --base "{target-branch}" --title "{title}" --assignee @me --body "$(cat <<'EOF'
+gh pr create --base "{target-branch}" --title "{title}" --assignee @me \
+  {label-args} {milestone-arg} \
+  --body "$(cat <<'EOF'
 {pr-body}
 EOF
 )"
 ```
 
+- expand `{label-args}` into repeated `--label "{label}"` flags from the validated label list
+- pass `{label-args}` only when `has_triage=true`; otherwise omit it and continue
+- omit all `--label` flags when nothing valid remains
+- expand `{milestone-arg}` into `--milestone "{milestone}"`
+- pass `{milestone-arg}` only when `has_triage=true`; otherwise omit it and continue
+- omit `{milestone-arg}` entirely when no milestone should be set
+
 ## Update PRs
 
 Update PR titles, labels, or milestones with:
@@ -108,4 +132,5 @@ Common arguments:
 
 - read failures: stop or skip based on the calling skill
 - update failures: warn and continue when the caller marks the action as best-effort
+- insufficient permission: skip direct writes according to the `has_triage` / `has_push` branch and continue
 - `@me` is resolved by `gh` CLI to the authenticated user

package/templates/.agents/rules/issue-pr-commands.github.zh-CN.md

@@ -13,50 +13,65 @@ gh repo view --json nameWithOwner
 
 如果任一命令失败，按调用该规则的 skill 约定停止或降级。
 
+## Upstream 仓库与权限检测
+
+在后续任何 `gh issue` 或 `gh api "repos/..."` 操作之前，先按 `.agents/rules/issue-sync.md` 完成 `upstream_repo`、`has_triage` 和 `has_push` 检测。
+
+- 后续所有 `gh issue` 命令统一使用 `-R "$upstream_repo"`
+- 后续所有 repo 级 `gh api` 命令统一使用 `"repos/$upstream_repo/..."`
+- `gh pr *` 命令保持作用于当前仓库，不额外加 `-R`
+- `gh api "orgs/{owner}/..."` 这类 org 级命令保持不变
+
 ## Issue 读取与创建
 
 读取 Issue：
 
 ```bash
-gh issue view {issue-number} --json number,title,body,labels,state,milestone,url
+gh issue view {issue-number} -R "$upstream_repo" --json number,title,body,labels,state,milestone,url
 ```
 
 创建 Issue：
 
 ```bash
-gh issue create --title "{title}" --body "{body}" --assignee @me {label-args} {milestone-arg}
+gh issue create -R "$upstream_repo" --title "{title}" --body "{body}" --assignee @me {label-args} {milestone-arg}
 ```
 
 - `{label-args}` 由调用方按有效 label 列表展开为多个 `--label`
+- 仅当 `has_triage=true` 时传入 `{label-args}`；否则整体省略并继续
 - 没有有效 label 时省略全部 `--label`
+- 仅当 `has_triage=true` 时传入 `{milestone-arg}`；否则整体省略并继续
 - `{milestone-arg}` 为空时整体省略
 
 设置 Issue Type：
 
 ```bash
 gh api "orgs/{owner}/issue-types" --jq '.[].name'
-gh api "repos/{owner}/{repo}/issues/{issue-number}" -X PATCH -f type="{issue-type}" --silent
+gh api "repos/$upstream_repo/issues/{issue-number}" -X PATCH -f type="{issue-type}" --silent
 ```
 
+- 仅当 `has_push=true` 时执行 Issue Type 设置；否则跳过并继续
+
 ## Issue 更新
 
 更新标题、label、assignee 或 milestone 时使用：
 
 ```bash
-gh issue edit {issue-number} {edit-args}
+gh issue edit {issue-number} -R "$upstream_repo" {edit-args}
 ```
 
 常见参数：
 - `--title "{title}"`
-- `--add-label "{label}"`
-- `--remove-label "{label}"`
+- `--add-label "{label}"`（仅当 `has_triage=true`）
+- `--remove-label "{label}"`（仅当 `has_triage=true`）
 - `--add-assignee @me`
-- `--milestone "{milestone}"`
+- `--milestone "{milestone}"`（仅当 `has_triage=true`）
+
+Assignee 同步不做权限预判；如果命令失败，按调用方约定静默跳过。
 
 关闭 Issue：
 
 ```bash
-gh issue close {issue-number} --reason "{reason}"
+gh issue close {issue-number} -R "$upstream_repo" --reason "{reason}"
 ```
 
 ## Issue 评论读取
@@ -64,7 +79,7 @@ gh issue close {issue-number} --reason "{reason}"
 读取 Issue 评论或按隐藏标记查找已有评论：
 
 ```bash
-gh api "repos/{owner}/{repo}/issues/{issue-number}/comments" --paginate
+gh api "repos/$upstream_repo/issues/{issue-number}/comments" --paginate
 ```
 
 ## PR 读取与创建
@@ -84,12 +99,21 @@ gh pr list --state {state} --base {base-branch} --json number,title,url,headRefN
 创建 PR：
 
 ```bash
-gh pr create --base "{target-branch}" --title "{title}" --assignee @me --body "$(cat <<'EOF'
+gh pr create --base "{target-branch}" --title "{title}" --assignee @me \
+  {label-args} {milestone-arg} \
+  --body "$(cat <<'EOF'
 {pr-body}
 EOF
 )"
 ```
 
+- `{label-args}` 由调用方按有效 label 列表展开为多个 `--label "{label}"`
+- 仅当 `has_triage=true` 时传入 `{label-args}`；否则整体省略并继续
+- 没有有效 label 时省略全部 `--label`
+- `{milestone-arg}` 展开为 `--milestone "{milestone}"`
+- 仅当 `has_triage=true` 时传入 `{milestone-arg}`；否则整体省略并继续
+- `{milestone-arg}` 为空时整体省略
+
 ## PR 更新
 
 更新 PR 标题、label 或 milestone：
@@ -108,4 +132,5 @@ gh pr edit {pr-number} {edit-args}
 
 - 读取失败：按调用方规则决定停止还是跳过
 - 更新失败：如果调用方标记为 best-effort，输出警告并继续
+- 权限不足：按 `has_triage` / `has_push` 分支跳过直接写操作，不阻塞调用方
 - `@me` 由 `gh` CLI 解析为当前认证用户

package/templates/.agents/rules/issue-sync.github.en.md

@@ -2,45 +2,121 @@
 
 Read this file before a task skill updates a GitHub Issue.
 
+## Upstream Repository Detection
+
+When an external contributor runs `gh` inside a fork, the default target is the fork instead of the upstream repository. Detect the upstream repository first and reuse `upstream_repo` for every later `gh issue` and `gh api "repos/..."` operation.
+
+```bash
+upstream_repo=$(gh api "repos/$(gh repo view --json nameWithOwner -q .nameWithOwner)" \
+  --jq 'if .fork then .parent.full_name else .full_name end' 2>/dev/null)
+```
+
+- non-fork repository: returns the current repository `full_name`
+- fork repository: returns the parent repository `full_name`
+- every later `gh issue` command must use `-R "$upstream_repo"`
+- every later `gh api "repos/..."` command must use `"repos/$upstream_repo/..."`
+
+## Permission Detection
+
+Run one permission check against the upstream repository before any write operation. When detection fails, treat it as no permission so the workflow degrades safely.
+
+```bash
+repo_perms=$(gh api "repos/$upstream_repo" --jq '.permissions' 2>/dev/null || echo '{}')
+has_triage=$(printf '%s' "$repo_perms" | grep -q '"triage":true' 2>/dev/null && echo true || echo false)
+has_push=$(printf '%s' "$repo_perms" | grep -q '"push":true' 2>/dev/null && echo true || echo false)
+```
+
+Operation-to-permission mapping:
+
+| Operation | Required permission | Notes |
+|------|---------|------|
+| add/remove labels | `has_triage` | triage is the minimum permission |
+| add/remove milestones | `has_triage` | same as above |
+| edit Issue body | `has_triage` | used by requirement checkbox sync |
+| set Issue Type | `has_push` | requires write permission |
+| set assignee | no check | skip directly when it fails |
+| publish/update comments | no check | allowed for authenticated users in public repositories |
+
+## Degradation Rules
+
+| Level | Operation type | With permission | Without permission |
+|------|---------|--------|--------|
+| silent degradation | label / milestone / Issue Type | run the `gh` command directly and also update the task comment | skip direct `gh` writes, update only the task comment, let the bot backfill |
+| direct skip | assignee | run the `gh` command directly | do nothing else |
+| normal execution | comments | run normally | run normally |
+
+Key rules:
+
+- task comment sync must continue whether write permission exists or not
+- insufficient permission only affects direct Issue metadata writes and must not stop the skill
+- keep the existing `2>/dev/null || true` error-tolerance pattern
+
+## External Contributor Locking
+
+Maintainers (`has_triage=true`) are never blocked. External contributors (`has_triage=false`) must check whether the current task already has a `task` comment author on the Issue before they start.
+
+```bash
+task_comment_author=$(gh api "repos/$upstream_repo/issues/{issue-number}/comments" \
+  --paginate --jq '[.[] | select(.body | test("<!-- sync-issue:{task-id}:task -->")) | .user.login] | first' \
+  2>/dev/null || echo "")
+current_user=$(gh api user --jq '.login' 2>/dev/null || echo "")
+```
+
+Decision rules:
+
+- no `task` comment exists: allow execution
+- the `task` comment author is the current user: allow continuation
+- the `task` comment author is another user: stop immediately and ask the contributor to coordinate with a maintainer before taking over
+
 ## Direct `status:` Label Updates
 
-If task.md contains a valid `issue_number` (not empty and not `N/A`) and the Issue state is `OPEN`, replace every existing `status:` label and add the target one:
+Algorithm note: keep the flow below aligned with `.github/scripts/sync-labels-to-set.sh` (set-diff sync). This is the AI agent-side equivalent implementation for the `target_set = {"{target-status-label}"}` case. If either side changes, update the other one in the same patch to avoid drift between the agent and the bot.
+
+If task.md contains a valid `issue_number` (not empty and not `N/A`) and the Issue state is `OPEN`, sync the `status:` labels to the target value with an idempotent set diff:
 
 ```bash
-state=$(gh issue view {issue-number} --json state --jq '.state' 2>/dev/null)
+state=$(gh issue view {issue-number} -R "$upstream_repo" --json state --jq '.state' 2>/dev/null)
 if [ "$state" = "OPEN" ]; then
-  gh issue view {issue-number} --json labels \
-    --jq '.labels[].name | select(startswith("status:"))' 2>/dev/null \
-  | while IFS= read -r label; do
-      [ -z "$label" ] && continue
-      gh issue edit {issue-number} --remove-label "$label" 2>/dev/null || true
-    done
-  gh issue edit {issue-number} --add-label "{target-status-label}" 2>/dev/null || true
+  current_status_labels=$(gh issue view {issue-number} -R "$upstream_repo" \
+    --json labels --jq '.labels[].name | select(startswith("status:"))' 2>/dev/null || true)
+  printf '%s\n' "$current_status_labels" | while IFS= read -r label; do
+    [ -z "$label" ] && continue
+    if [ "$label" != "{target-status-label}" ] && [ "$has_triage" = "true" ]; then
+      gh issue edit {issue-number} -R "$upstream_repo" --remove-label "$label" 2>/dev/null || true
+    fi
+  done
+  if [ "$has_triage" = "true" ] && ! printf '%s\n' "$current_status_labels" | grep -qxF "{target-status-label}"; then
+    gh issue edit {issue-number} -R "$upstream_repo" --add-label "{target-status-label}" 2>/dev/null || true
+  fi
 fi
 ```
 
 Use `while IFS= read -r label` so labels like `status: in-progress` are handled line-by-line instead of being split on spaces.
 
+If `has_triage=false`, skip direct label changes, update only the task comment, and let the bot backfill from the latest task metadata.
+
 If `gh` fails, skip and continue. Do not fail the skill.
 
 ## Assignee Sync
 
 When a skill creates or imports an Issue, automatically add the current executor as assignee:
 
-- `create-issue`: use `--assignee @me` in the `gh issue create` command
-- `import-issue`: run `gh issue edit {issue-number} --add-assignee @me 2>/dev/null || true` after import
+- `create-issue`: use `--assignee @me` in `gh issue create` and include `-R "$upstream_repo"`
+- `import-issue`: run `gh issue edit {issue-number} -R "$upstream_repo" --add-assignee @me 2>/dev/null || true` after import
 
-`@me` is resolved by `gh` CLI to the authenticated user. The operation is idempotent (adding an existing assignee is a no-op). If the command fails (e.g. insufficient permissions), skip and continue.
+`@me` is resolved by `gh` CLI to the authenticated user. The operation is idempotent. If the command fails, skip it directly and do not provide a fallback path.
 
 ## `in:` Label Sync
 
+> **Trigger timing**: run `in:` label sync only after code is committed (the `commit` skill). Do not run it during `implement-task` or `refine-task`. During `create-pr`, only copy the labels from the Issue to the PR without recomputing them.
+
 Read the `labels.in` mapping from `.agents/.airc.json`.
 
 ```bash
 git diff {base-branch}...HEAD --name-only
 ```
 
-`{base-branch}` is usually `main`; in PR context, use the PR's base branch.
+`{base-branch}` is usually `main`; in PR context, use the PR base branch.
 
 ### When a mapping exists (precise add/remove)
 
@@ -48,15 +124,18 @@ git diff {base-branch}...HEAD --name-only
 2. Match each file against the directory prefixes in `labels.in` to compute the expected `in:` label set
 3. Query the current `in:` labels on the Issue or PR
 4. Apply the diff:
-   - expected but missing -> `gh issue edit {issue-number} --add-label "in: {module}" 2>/dev/null || true`
-   - present but no longer expected -> `gh issue edit {issue-number} --remove-label "in: {module}" 2>/dev/null || true`
+   - expected but missing: only when `has_triage=true`, run `gh issue edit {issue-number} -R "$upstream_repo" --add-label "in: {module}" 2>/dev/null || true`
+   - present but no longer expected: only when `has_triage=true`, run `gh issue edit {issue-number} -R "$upstream_repo" --remove-label "in: {module}" 2>/dev/null || true`
 
 ### When no mapping exists (add-only fallback)
 
 If `.airc.json` has no `labels.in` field or it is empty:
+
 1. query existing repository `in:` labels
 2. derive the top-level directory from each changed file
-3. add matching labels only and never remove existing `in:` labels
+3. only when `has_triage=true`, add matching labels and never remove existing `in:` labels
+
+If `has_triage=false`, skip direct `in:` label edits and keep task comment sync as the source for later automation backfill.
 
 ## Artifact Comment Publishing
 
@@ -69,7 +148,7 @@ The hidden marker must remain compatible:
 Check for an existing comment before publishing:
 
 ```bash
-gh api "repos/{owner}/{repo}/issues/{issue-number}/comments" \
+gh api "repos/$upstream_repo/issues/{issue-number}/comments" \
   --paginate --jq '.[].body' \
   | grep -qF "<!-- sync-issue:{task-id}:{file-stem} -->"
 ```
@@ -99,20 +178,23 @@ Use this format:
 `{agent}` is the name of the AI agent currently executing the skill (for example `claude`, `codex`, or `gemini`).
 
 `summary` comments need extra handling:
+
 - find an existing `<!-- sync-issue:{task-id}:summary -->` comment ID first
 - create the comment when none exists
-- patch the existing comment in place when the body changed
+- patch the existing comment in place when the body changed by using `gh api "repos/$upstream_repo/issues/comments/{comment-id}" -X PATCH -f body=...`
 
 ```bash
-summary_comment_id=$(gh api "repos/{owner}/{repo}/issues/{issue-number}/comments" \
+summary_comment_id=$(gh api "repos/$upstream_repo/issues/{issue-number}/comments" \
   --paginate --jq '.[] | select(.body | startswith("<!-- sync-issue:{task-id}:summary -->")) | .id' \
   | head -n 1)
-gh api "repos/{owner}/{repo}/issues/comments/{comment-id}" -X PATCH -f body="$(cat <<'EOF'
+gh api "repos/$upstream_repo/issues/comments/{comment-id}" -X PATCH -f body="$(cat <<'EOF'
 {comment-body}
 EOF
 )"
 ```
 
+Comment publishing is not gated by `has_triage` or `has_push`.
+
 ## task.md Comment Sync
 
 Hidden marker:
@@ -124,7 +206,7 @@ Hidden marker:
 Use an idempotent update path for `task.md`:
 
 1. Read the full `task.md`
-2. Wrap the YAML frontmatter (content between the `---` delimiters) inside a `<details><summary>Metadata (frontmatter)</summary>` block with a `yaml` code fence; render the remaining body as normal Markdown
+2. Wrap the YAML frontmatter (content between the `---` delimiters) inside a `<details><summary>Metadata (frontmatter)</summary>` block with a `yaml` code fence, then render the remaining body as normal Markdown
 3. Use `task` as `{file-stem}`
 4. Find an existing comment ID for the marker
 5. Create the comment when none exists
@@ -155,20 +237,23 @@ task.md comment format:
 *Generated by {agent} · Internal tracking: {task-id}*
 ```
 
-When restoring, extract the frontmatter from the `<details>` block and reassemble with the body to recover the original `task.md`.
+When restoring, extract the frontmatter from the `<details>` block and reassemble it with the body to recover the original `task.md`.
 
 Title mapping:
+
 - `task` -> `Task File`
 
+task comment sync always runs and is never downgraded.
+
 ## Backfill Rules (run before `/complete-task` archives)
 
 - Scan `task.md`, `analysis*.md`, `plan*.md`, `implementation*.md`, `review*.md`, and `refinement*.md` in the task directory
 - Check whether each `{file-stem}` was already published by its hidden marker; publish only missing artifacts
-- Backfill only appends missing comments; never delete or reorder existing comments
+- Backfill only appends missing comments and never deletes or reorders existing comments
 - Resolve `{agent}` for backfilled comments in this order:
-  1. Match the artifact filename in Activity Log (for example `→ analysis.md`) and extract the executor from `by {agent}`
-  2. If no match is found, fall back to `assigned_to` in task.md frontmatter
-  3. If `assigned_to` is also unavailable, use the current backfilling agent
+  1. match the artifact filename in Activity Log (for example `→ analysis.md`) and extract the executor from `by {agent}`
+  2. if no match is found, fall back to `assigned_to` in task.md frontmatter
+  3. if `assigned_to` is also unavailable, use the current backfilling agent
 - Derive the previous and next neighbors from Activity Log order and add this note below the title:
 
 ```markdown
@@ -178,6 +263,7 @@ Title mapping:
 - If only one neighbor exists, keep only that side of the note; if neither exists, omit the note
 
 Title mapping:
+
 - `task` -> `Task File`
 - `analysis` / `analysis-r{N}` -> `Requirements Analysis` / `Requirements Analysis (Round {N})`
 - `plan` / `plan-r{N}` -> `Technical Plan` / `Technical Plan (Round {N})`
@@ -186,6 +272,8 @@ Title mapping:
 - `refinement` / `refinement-r{N}` -> `Refinement Report (Round 1)` / `Refinement Report (Round {N})`
 - `summary` -> `Delivery Summary`
 
+Backfilled comments are also not gated by `has_triage` or `has_push`.
+
 ## Requirement Checkbox Sync
 
 Extract checked `- [x]` items from the `## Requirements` section in task.md. Skip when none exist.
@@ -193,10 +281,12 @@ Extract checked `- [x]` items from the `## Requirements` section in task.md. Ski
 Read the current Issue body:
 
 ```bash
-gh issue view {issue-number} --json body --jq '.body'
+gh issue view {issue-number} -R "$upstream_repo" --json body --jq '.body'
 ```
 
-Replace matching `- [ ] {text}` lines with `- [x] {text}` only when the body actually changes, then PATCH the full body with `gh api`.
+Replace matching `- [ ] {text}` lines with `- [x] {text}`. Use `gh api` to PATCH the full body only when the body changed and `has_triage=true`.
+
+If `has_triage=false`, skip the body PATCH, update only the task comment, and let the bot backfill from the latest task state.
 
 ## Shell Safety Rules