FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Aligning approval boundaries for workspace editing
Keeping routine artifact editing unblocked while preserving gates for external, secret, and destructive operations
Purpose
When contributors must wait for approval every time they record product direction, requirements, or architecture in the workspace, even ordinary safe work becomes fragmented. Simply expanding write access, however, would blur the boundary around operations that affect external state or sensitive information.
The goal was to make routine editing contained within the current workspace easier while keeping high-risk operations involving external locations, credentials, destruction, or publication behind their existing approval gates.
Implementation
A project policy was added for automatic review of operations confined to the current workspace root. Creating, editing, renaming, formatting, testing, and verification on ordinary files can proceed when the work record exists, the scope is isolated, and existing changes and secrets are protected.
The Product Manager and Solution Architect moved to workspace-write, allowing them to record product direction, requirements, architecture direction, and technical records directly in the workspace. They now share the boundary used by other artifact-producing roles, while roles without an authoring responsibility did not receive write access.
- Exclude writes outside the workspace and reads or writes involving credentials, secrets, or environment configuration from automatic review.
- Exclude permission or ownership changes and destructive operations such as recursive deletion, force, reset, and discard.
- Retain the existing approval gates for external-state changes, deployment, and publication.
- Fail closed when the scope, work record, target boundary, or risk is unclear.
The boundary was synchronized across agent definitions, Skills, hook guidance, organization rules, setup, and operating documentation. Because project configuration changes take effect in new sessions of a trusted project, the guidance also requires checking runtime state instead of assuming the permission mode of an existing session.
[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として扱う。Rendering diagram…
What was confirmed
Verification results
Of nine roles, the eight that record artifacts used workspace-write, while the one without an authoring responsibility remained read-only, matching the intended permission split.
Configuration and operating guidance confirmed that adding a path for routine in-workspace editing preserved gates for outside-workspace access, secrets, destructive operations, external state, deployment, and publication.
Parsing of ten TOML files and three hook files, configuration loading, representative policy cases, cross-checks across all agent definitions, and the diff check passed.
At the cutoff, the workspace-editing approval boundary had been applied to the target. Changing the permission mode of existing sessions and modifying external services were outside this Activity.
Basis for completion
The work was complete when the policy for routine workspace editing, the write/read-only role split, and the exclusions for high-risk operations matched across configuration, agent definitions, and operating guidance; syntax, configuration-load, policy, and diff checks passed; and the result was applied to the target.