FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Separating routine commands from Pull Request merge approval
Defining allow entries for inspection and review readiness while preserving explicit merge approval and one wrapper spelling
Purpose
Authentication preflight, post-merge cleanup, repository-status inspection, Pull Request viewing, and moving a Draft Pull Request to ready were repeated operations within software delivery. The CEO asked for those operations to be configured without per-use approval while keeping Pull Request merge, which updates the target branch, behind explicit approval.
The same repository-local wrappers also had duplicate scripts/... and ./scripts/... allow entries. This Activity separated routine inspection and delivery commands from merge operations in the command rules and standardized wrapper notation on scripts/....
Implementation
.codex/rules/organization.rules retained the existing allow entries for authentication-preflight and post-merge-cleanup wrappers, then added decision = "allow" entries for the git status, gh pr view, and gh pr ready command families. Rather than permitting each command through a broad prefix, the rules enumerated the argument forms used in the normal workflow through match.
# Explanatory summary; match and not_match examples are omitted
prefix_rule(
pattern = ["git", "status"],
decision = "allow",
)
prefix_rule(
pattern = ["gh", "pr", "view"],
decision = "allow",
)
prefix_rule(
pattern = ["gh", "pr", "ready"],
decision = "allow",
)
prefix_rule(
pattern = ["gh", "pr", "merge"],
decision = "prompt",
)git status was classified as a routine read of the local branch and working tree. gh pr view was classified as inspection of current Pull Request state. gh pr ready was not read-only, but it moved a Draft Pull Request into review readiness without updating the target branch, so it was included in the ordinary delivery flow.
gh pr merge remained separate with decision = "prompt" because it updates the target branch and can affect releases or Issue closure. This distinguished read-only checks, a review-readiness state change, and the operation that incorporates changes into the target branch.
The canonical spelling for repository-local wrappers became scripts/.... Three duplicate ./scripts/... allow entries covering authentication preflight, work-branch creation, and post-merge cleanup were removed, and .codex/rules/README.md documented that aliases would not be defined. Wrapper behavior was unchanged; the update removed duplicate rules pointing to the same execution entry points.
.codex/rules/README.md described git status and gh pr view as routine inspection, gh pr ready as a delivery operation that advances a Pull Request to review, and Pull Request merge as requiring CEO approval. The final change covered the command rules and their explanation across two files, with 51 additions and 40 deletions.
Verification ran git diff --check and searched for ./scripts/ after the cleanup. The only remaining occurrence was the README sentence explaining that the alias was not defined. A policy evaluator was not run against the new entries, and there was no end-to-end check proving that the runtime approval prompt no longer appeared.
What was confirmed
Verification results
allow entries were defined for git status, gh pr view, and gh pr ready, while a separate prompt entry remained for gh pr merge.
The README distinguished git status and gh pr view as inspection, gh pr ready as a review-readiness state change that does not update the target branch, and merge as the approval-gated operation.
Repository-local wrapper notation in the rules was standardized on scripts/..., and three duplicate ./scripts/... entries were removed.
The final change covered two files with 51 additions and 40 deletions. The whitespace check passed, and no ./scripts/ occurrence remained outside the explanatory convention.
The Activity did not run a policy evaluator or an end-to-end approval test. It therefore did not establish that the runtime would execute each allowed command without a prompt or always prompt for gh pr merge, and behavior across every possible additional argument was not tested.
Basis for completion
The Activity was complete when the distinction between routine inspection, review readiness, and Pull Request merge approval was reflected across the two rule-related files, repository-local wrapper spelling was standardized on scripts/..., and the static diff and residual-notation checks passed. Runtime no-prompt behavior was not part of the completion basis.