Reconcile memory repository's direct-to-main model with MSXOrg's org-wide PR ruleset

[MariusStorhaug]

While standing up MSXOrg/memory from the new Memory Repository Template (#70), direct pushes to main were rejected even though the memory repository type is explicitly designed around "commit straight to main, no PR."

Request

The Agentic Development design and the new Memory Repository Template both describe memory repositories as a no-PR, direct-commit working-memory store. In practice, MSXOrg/memory (and presumably every other repository in the organization) is covered by an organization-wide "GitHub Flow" ruleset that requires every change to main to go through a pull request. The first push that creates an empty main branch is allowed through, but every subsequent direct push is rejected with GH013: Repository rule violations found / "Changes must be made through a pull request."

This means the documented memory-repo behavior does not actually work today without an organization administrator either exempting memory-type repositories from the ruleset (e.g. via a repository bypass actor) or the framework accepting that memory changes land through fast, low-ceremony PRs instead of true direct commits.

What is expected

One of:

• The MSXOrg organization ruleset is updated to exempt memory (and any future *-memory-type) repositories from the pull-request requirement, so the documented direct-commit model works as designed, or
• The Memory Repository Template and design docs are updated to describe the realistic workflow (e.g. "commit directly when the ruleset allows it; otherwise open and immediately self-merge a PR with no review gate") so the documentation matches enforced reality.

Acceptance criteria

• MSXOrg/memory (and any other org memory repository) has a documented, working way to land changes that matches what CONTRIBUTING.md in that repository actually says.
• The Memory Repository Template page in this repo reflects whichever resolution is chosen, so future adopting organizations (e.g. PSModule) don't hit the same surprise.

Current workaround

MSXOrg/memory's initial scaffold was landed via a PR that was squash-merged with gh pr merge --admin (organization-admin bypass), since required_approving_review_count is 0 and no CODEOWNERS file exists to trigger the code-owner-review requirement. This is functional but is not the "no PR" experience the repository's own CONTRIBUTING.md describes.

---

Technical decisions

Open: Whether to solve this via an organization ruleset bypass actor (scoped to memory-type repositories, or to repository admins) versus updating the framework's documented workflow to match the enforced ruleset. Resolving this requires organization-admin access to MSXOrg's ruleset configuration (admin:org scope), which this session intentionally did not self-grant.

---

Implementation plan

• Decide the resolution approach (ruleset bypass vs. documented PR-based workflow) for memory-type repositories
• If a ruleset bypass is chosen, add memory (and any future memory repos) as a bypass exception in the MSXOrg GitHub Flow ruleset
• If the documented workflow changes instead, update src/docs/Frameworks/Agentic-Development/memory-template.md, design.md, and MSXOrg/memory's README.md/CONTRIBUTING.md to describe the actual merge path
• Confirm PSModule/memory (tracked in AGENTS.md points to github.com/PSModule/memory, which doesn't exist PSModule/docs#83) does not hit the same ruleset conflict, or apply the same fix there

[MariusStorhaug]

Resolved. Both MSXOrg and PSModule now use a Type custom property with an exclude-only ruleset condition (Type != Memory is covered by GitHub Flow, not an include allow-list), so \memory-type repositories are cleanly out of scope for the pull-request-required ruleset instead of needing an admin-bypass workaround. Verified 1:1 coverage parity for every other repository in both orgs before cutover. Documented in #76 (Repository Type Property).