FACTUAL ACTIVITY RECORD · 実際の作業をもとにした活動記録
workspace編集の承認境界を整える
通常の成果物編集を止めず、外部・秘密情報・破壊操作のgateを維持する
目的
担当者が方針、要件、architectureなどをworkspaceへ記録するたびに承認待ちになると、安全な範囲の通常作業まで細切れになる。一方で、編集権限を広げるだけでは外部状態や秘密情報へ影響する操作との境界が曖昧になる。
現在のworkspace内に閉じた通常編集は進めやすくしつつ、workspace外、credential、破壊操作、公開などの高リスク操作は従来の承認gateへ残すことを目指した。
実装
project設定に、現在のworkspace root配下だけを対象とする自動確認policyを追加した。通常fileの作成、編集、rename、format、test、verificationは、対象作業の記録が存在し、作業範囲が分離され、既存変更とsecretを保護できる場合に進められる。
Product ManagerとSolution Architectをworkspace-writeへ変更し、product方針、requirements、architecture方針、technical recordを担当者自身がworkspaceへ記録できるようにした。成果物を作成する他のroleと同じ境界へ揃える一方、authoringを担当しないroleにはwrite権限を追加しなかった。
- workspace外へのwriteと、credential、secret、環境設定のreadまたはwriteは自動確認の対象外にする。
- 権限・ownership変更、再帰削除、force、reset、discardなどの破壊操作は自動確認の対象外にする。
- external stateの変更、deploy、publicationは既存の承認gateを維持する。
- scope、作業記録、対象範囲、riskが不明な場合はfail closedで停止する。
この境界をagent定義、Skill、hook説明、組織rule、setup、運用文書へ横断して反映した。設定変更はtrusted projectの新しいsessionから有効になるため、既存sessionのpermission modeを推測せず、実行時の状態で確認する条件も残した。
[auto_review]
policy = """
通常のworkspace内file作業では人間を待たせない。現在のworkspace root配下だけを対象にした
create / edit / rename、format、test、verification、およびStory branch上のnon-destructiveな
repository作業は、対象User Story Issueが存在し、Story branchへ切替済みで、既存変更とsecretを
保護している場合にapproveする。.codexと.agentsも同じworkspace内scopeとして扱う。図を描画しています…
確認したこと
確認結果
9 roleのうち成果物を記録する8 roleがworkspace-write、authoringを担当しない1 roleがread-onlyとなり、意図した権限分離と一致した。
通常のworkspace内編集を進めるpolicyを追加しても、workspace外、secret、破壊操作、external state、deploy、publicationのgateが維持されることを設定と運用文書で確認した。
10件のTOML parse、3件のhook parse、設定load、許可規則の代表ケース、全agent定義の横断確認、差分検査が成功した。
cutoff時点でworkspace編集の承認境界は対象へ反映されていた。既存sessionのpermission mode変更や、外部サービスの状態変更はこのActivityの範囲に含めていない。
完了とした根拠
通常のworkspace編集を進めるpolicy、roleごとのwrite/read-only分離、高リスク操作を除外する条件が設定・agent定義・運用文書で一致し、構文・設定load・許可規則・差分の検証に成功して対象へ反映されたことをもって完了とした。