ai-ops-cli 1.4.0 → 1.4.1

package/README.ko.md

@@ -162,8 +162,33 @@ ai-ops codex-hook install context-promotion
 ai-ops codex-hook install context-promotion --command "/custom/bin/ai-ops context-promotion hook post-tool-use"
 ai-ops codex-hook status context-promotion
 ai-ops codex-hook uninstall context-promotion
+ai-ops codex-permissions install safe-local
+ai-ops codex-permissions status safe-local
+ai-ops codex-permissions uninstall safe-local
 ```
 
+`safe-local`은 `~/.codex/config.toml`에 `ai-ops-safe-local` user-level Codex permission profile을 관리합니다. `~/.personal-project-contexts`, `${AI_OPS_HOME:-$HOME}/.ai-ops/context-promotion`, active workspace root 아래 `.codex/plans`에는 write를 허용하고, `.git`은 read-only로 두며 `**/*.env`는 deny합니다. `PermissionRequest` hook이나 command allow rule은 설치하지 않습니다.
+
+ai-coding worker에서는 Codex subprocess를 run-scoped로 실행하고, commit/push/PR 생성은 orchestrator가 담당하게 합니다.
+
+```bash
+codex exec --ignore-user-config --ignore-rules --cd "$WORKTREE" \
+  -c 'approval_policy="never"' \
+  -c 'default_permissions=":read-only"'
+
+codex exec --ignore-user-config --ignore-rules --cd "$WORKTREE" \
+  -c 'approval_policy="never"' \
+  -c 'default_permissions="ai-worker-impl"' \
+  -c 'permissions.ai-worker-impl.filesystem.":minimal"="read"' \
+  -c 'permissions.ai-worker-impl.filesystem.":workspace_roots"."."="write"' \
+  -c 'permissions.ai-worker-impl.filesystem.":workspace_roots".".git"="read"' \
+  -c 'permissions.ai-worker-impl.filesystem.":workspace_roots".".codex/plans"="write"' \
+  -c 'permissions.ai-worker-impl.filesystem.":workspace_roots"."**/*.env"="deny"' \
+  -c 'permissions.ai-worker-impl.network.enabled=false'
+```
+
+각 Codex 실행 후 orchestrator가 HEAD, branch ref, changed-file scope를 검증해야 합니다. Validation command 실행, commit 생성, branch push, `gh pr create --draft` 호출은 Codex가 아니라 orchestrator가 수행합니다.
+
 Subagent lifecycle 명령:
 
 ```bash

package/README.md

@@ -162,8 +162,33 @@ ai-ops codex-hook install context-promotion
 ai-ops codex-hook install context-promotion --command "/custom/bin/ai-ops context-promotion hook post-tool-use"
 ai-ops codex-hook status context-promotion
 ai-ops codex-hook uninstall context-promotion
+ai-ops codex-permissions install safe-local
+ai-ops codex-permissions status safe-local
+ai-ops codex-permissions uninstall safe-local
 ```
 
+`safe-local` manages a user-level Codex permission profile named `ai-ops-safe-local` in `~/.codex/config.toml`. It grants write access to `~/.personal-project-contexts`, `${AI_OPS_HOME:-$HOME}/.ai-ops/context-promotion`, and `.codex/plans` under active workspace roots while keeping `.git` read-only and denying `**/*.env`. It does not install `PermissionRequest` hooks or command allow rules.
+
+For an ai-coding worker, keep Codex subprocesses run-scoped and let the orchestrator own commits, pushes, and PR creation:
+
+```bash
+codex exec --ignore-user-config --ignore-rules --cd "$WORKTREE" \
+  -c 'approval_policy="never"' \
+  -c 'default_permissions=":read-only"'
+
+codex exec --ignore-user-config --ignore-rules --cd "$WORKTREE" \
+  -c 'approval_policy="never"' \
+  -c 'default_permissions="ai-worker-impl"' \
+  -c 'permissions.ai-worker-impl.filesystem.":minimal"="read"' \
+  -c 'permissions.ai-worker-impl.filesystem.":workspace_roots"."."="write"' \
+  -c 'permissions.ai-worker-impl.filesystem.":workspace_roots".".git"="read"' \
+  -c 'permissions.ai-worker-impl.filesystem.":workspace_roots".".codex/plans"="write"' \
+  -c 'permissions.ai-worker-impl.filesystem.":workspace_roots"."**/*.env"="deny"' \
+  -c 'permissions.ai-worker-impl.network.enabled=false'
+```
+
+After each Codex run, the orchestrator should verify HEAD, branch refs, and changed-file scope. The orchestrator, not Codex, should run validation commands, create commits, push branches, and call `gh pr create --draft`.
+
 Subagent lifecycle commands:
 
 ```bash

package/data/context-layer/docs/agent/checks/impact-checklist.md

@@ -16,3 +16,12 @@ update_when:
 - auth, permission, privacy, billing, credential, audit log에 영향이 있는가?
 - external integration, webhook, cron, queue, cache, background job에 영향이 있는가?
 - project-owned 문서, specs, runbook, operator guide, `docs/docs-status.md`, context-layer 갱신이 필요한가?
+
+## 유지보수 점검 신호
+
+다음 항목은 lint/test gate가 아니라 리팩토링 검토 신호다. 해당되면 변경을 끝내기 전에 분리, naming, test 위치를 한 번 확인한다.
+
+- touched production file이 250줄을 넘는가?
+- 새 기능을 400줄 이상 파일에 추가하는가?
+- 같은 패턴이 세 번째 등장했는가?
+- 한 변경이 서로 다른 책임의 section 3곳 이상을 건드리는가?

package/data/context-layer/docs/agent/rules/00-agent-baseline.md

@@ -35,6 +35,17 @@ update_when:
 - 파일 내부 선언은 types, constants, validators/guards, helper functions, main logic/exports 순서로 배치한다.
 - 한 파일에 의미가 다른 그룹이 둘 이상 있으면 `// ----- types -----` 같은 section divider comment로 경계를 표시한다.
 
+## 유지보수/리팩토링 기준
+
+- 줄 수 기준은 hard gate가 아니라 검토 신호로 사용한다. 자동 lint/test 실패 조건을 만들기보다 변경 맥락에서 분리 필요성을 판단한다.
+- touched production file이 250줄을 넘으면 책임 경계, 테스트 위치, helper 추출 가능성을 한 번 확인한다.
+- 새 기능을 400줄 이상 파일에 추가하려면 먼저 feature slice, command shell, pure logic, schema/state I/O로 나눌 수 있는지 검토한다.
+- production TypeScript 파일이 600줄을 넘으면 다음 기능 추가 전에 분리 계획을 우선 세운다.
+- 같은 패턴이 세 번째 등장하면 WET 유지보다 shared helper 또는 feature-local abstraction이 더 명확한지 확인한다.
+- 한 변경이 서로 다른 책임의 section 3곳 이상을 건드리면 파일/폴더 경계를 다시 그릴 시점으로 본다.
+- 공통화는 Rule of Three와 호출 맥락이 함께 맞을 때 진행한다. 우발적으로 비슷한 코드 두 개만 보고 abstraction을 만들지 않는다.
+- 리팩토링은 public CLI command, option, JSON/schema 계약을 보존하는 작은 이동부터 시작하고, behavior assertion은 먼저 유지한다.
+
 ## 네이밍
 
 - directory name은 kebab-case를 사용한다.