Manual repository settings: align metadata and merge/branch policy

[dgenio]

Why this is manual

The connected GitHub app can read repository settings but does not expose repository-metadata, merge-strategy, branch-protection, or post-merge branch-deletion mutation. Keep these few UI-only actions in one place rather than scattering them across product/security backlog issues.

Current live repository metadata (2026-08-11):

• description: Capability-based authorization and policy enforcement for agents using large MCP and A2A tool ecosystems. — stale vs the merged product positioning;
• allow_squash_merge = true;
• allow_merge_commit = true;
• allow_rebase_merge = true;
• allow_auto_merge = false;
• delete_branch_on_merge = false;
• allow_update_branch = false;
• repository Discussions disabled.

Required manual changes

1. Align the GitHub description with the product contract

Set the repository description to:

Execution enforcement and audit for AI-agent actions

Do not add MCP/A2A/1000+-tool language to the short description; those are integrations/capabilities, not the validated product wedge.

2. Make the documented merge policy true

The repository documentation has historically said squash/linear history, while GitHub currently permits merge commits and rebase merges.

Recommended repository merge settings:

• Squash merging: ON
• Merge commits: OFF
• Rebase merging: OFF
• Default squash title: PR title / consistent project convention

Then protect main with Require linear history if that protection is available for this repository/account.

If you intentionally prefer multiple merge methods instead, update contributor docs instead of pretending squash-only is enforced. The recommendation here is to enforce the documented squash model.

3. Delete merged branches automatically

Set:

• Automatically delete head branches: ON (delete_branch_on_merge = true)

This reduces accidental reuse of historical branch names, the failure mode recorded in #272.

4. Allow branch updates

Set:

• Always suggest updating pull request branches / allow update branch: ON (allow_update_branch = true)

This gives humans/agents a supported path to bring an open PR onto current main rather than improvising stale-branch reuse.

5. Branch protection / ruleset

For main, verify the active ruleset/branch protection matches the repo's actual quality contract:

• require the intended CI/checks before merge;
• require linear history;
• do not allow force pushes or deletion of main;
• require the branch to be up to date before merge only if the project accepts the resulting CI churn; otherwise rely on exact-head validation and review current-base drift explicitly.

Do not add approval-count requirements just for ceremony while the repository is primarily single-maintainer; external review requirements can be added when there are real maintainers/reviewers to satisfy them.

Optional, not required now

• Auto-merge: currently off. Keep it off unless the project deliberately wants GitHub to merge automatically after required checks; it is not an adoption/security requirement.
• Discussions: currently off. The gate-driven roadmap does not require a new discussion forum at current scale; issues/PRs are sufficient until community traffic justifies another channel.

Verification after changing settings

Fetch/review repository settings and confirm:

• description matches Execution enforcement and audit for AI-agent actions;
• only the intended merge method(s) are enabled;
• merged branches auto-delete;
• update-branch support is enabled;
• main ruleset matches the documented CI/linear-history contract;
• CONTRIBUTING.md / AGENTS.md no longer promise behavior GitHub does not enforce.

Consolidates

• Merge flow contradicts the documented "squash-merge, linear history" policy — enforce it or fix the docs #231 — documented squash/linear history vs actual merge settings;
• Prevent stale branch reuse with repository lifecycle settings and branch preflight #272 — stale branch reuse / delete-after-merge / update-branch settings.

Close this issue only after the GitHub UI/settings changes are actually applied; do not mark it complete based on documentation alone.