Community guidance is local only when repository-specific

src/docs/Capabilities/agentic-development/AGENTS.template.md

@@ -30,7 +30,7 @@ pointers to canonical documentation pages.
 Read in this order:
 
 1. `README.md` — what this repository is and how it builds.
-2. `.github/CONTRIBUTING.md` — how a change is made and reviewed here.
+2. `.github/CONTRIBUTING.md` — repository-specific contribution instructions, when present.
 3. `docs/index.md` — this repository's own documentation.
 <!-- Add initiative-specific guidance here, after the local repository entries. -->
 4. [MSXOrg/docs](https://github.com/MSXOrg/docs/) — the organization standards.
@@ -39,3 +39,12 @@ Clone each linked repository locally, keep its configuration local to that
 clone, and update it before reading it.
 
 ````
+
+Tailor the entries to real destinations. Keep the local contribution entry only
+[when a local guide is needed](../../Ways-of-Working/Repository-Standard.md#contribution-guidance);
+otherwise replace it with a link to the organization default at its source. If
+the organization supplies no contribution default, link to the shared
+[Contribution Workflow](../../Ways-of-Working/Contribution-Workflow.md).
+Inherited community files are not included in clones, so a router uses a source
+link rather than a nonexistent local path. Do not create a local contribution
+file solely to fill the template.

src/docs/Capabilities/agentic-development/design.md

@@ -52,15 +52,17 @@ Product repositories carry local context and thin pointers:
   .claude/
     CLAUDE.md                      # required: routes Claude Code — @../AGENTS.md
   .github/
-    CONTRIBUTING.md                # how a change is made here
+    CONTRIBUTING.md                # conditional: repo-specific instructions or exception
     copilot-instructions.md        # required: routes the Copilot surfaces that need it
     instructions/
       <scope>.instructions.md      # exceptional: a path-scoped local caveat
   README.md                        # what it is, how it builds
   docs/                            # architecture and domain context
 ```
 
-The repository owns only repository-specific nuance, and each kind has a file that owns it: `README.md` for what the repository is and how it builds, `.github/CONTRIBUTING.md` for contribution mechanics, `docs/` for architecture and domain context, and path-scoped rule files for local caveats. `AGENTS.md` points at them and holds none of it. Cross-cutting standards remain in `docs`. Thin means "no duplicated reusable process," not "discard the local operating contract" — the contract lives, it just lives in the file a human would read.
+The repository owns only repository-specific nuance, and each kind has a file that owns it: `README.md` for what the repository is and how it builds, `.github/CONTRIBUTING.md` for contribution mechanics [when a local guide is needed](../../Ways-of-Working/Repository-Standard.md#contribution-guidance), `docs/` for architecture and domain context, and path-scoped rule files for local caveats. `AGENTS.md` points at them and holds none of it. Cross-cutting standards remain in `docs`. Thin means "no duplicated reusable process," not "discard the local operating contract" — the contract lives, it just lives in the file a human would read.
+
+Inherited community files are not included in clones. When no local contribution guide is needed, the router links to the organization's contribution default at its source. If the organization supplies no contribution default, link to the shared [Contribution Workflow](../../Ways-of-Working/Contribution-Workflow.md). Do not create a local guide merely to fill a router entry.
 
 ## OKF page model
 
@@ -112,7 +114,7 @@ flowchart TD
   msx --> refresh["Synchronize selected docs with Git<br/>stop unless exactly synchronized"]
   psmodule --> refresh
   other --> refresh
-  refresh --> repo["Read README, CONTRIBUTING,<br/>and local docs"]
+  refresh --> repo["Read README, contribution guidance,<br/>and local docs"]
   repo --> path["Apply path-scoped local rules"]
   path --> orgdocs["Read organization<br/>documentation"]
   orgdocs --> docs["Read inherited<br/>ecosystem documentation"]
@@ -142,7 +144,7 @@ mechanics, or standards.
 Read in this order:
 
 1. `README.md` — what this repository is and how it builds.
-2. `.github/CONTRIBUTING.md` — how a change is made and reviewed here.
+2. `.github/CONTRIBUTING.md` — repository-specific contribution instructions, when present.
 3. `docs/index.md` — this repository's own documentation.
 4. [MSXOrg/docs](https://github.com/MSXOrg/docs/) — the organization standards.
 
@@ -152,7 +154,7 @@ clone, and update it before reading it.
 Read nearest first. A local file never overrides a standard.
 ```
 
-A router lists the destinations that exist in that repository, written as the paths that repository actually uses — the ones above are an example, not a required layout. A repository with no documentation of its own drops that line; one that publishes the standards resolves steps 3 and 4 to the same tree and drops the duplicate. Writing a real path matters more than matching the example, because the router is read literally.
+A router lists the destinations that actually exist — the ones above are an example, not a required layout. Replace the optional local contribution entry with a link to the inherited organization default when no local guide is needed. A repository with no documentation of its own drops that line; one that publishes the standards resolves steps 3 and 4 to the same tree and drops the duplicate. Writing a real path or source link matters more than matching the example, because the router is read literally.
 
 The index trail is the default. A clear prompt can shortcut stage discovery: `Review this PR <link>` enters Review, `Make this issue <description>` enters Define, and `Implement <issue>` enters Implement. These phrases are routing hints interpreted by [Workflow](../../Ways-of-Working/Workflow.md#find-the-current-stage), not commands with independent procedures.
 

src/docs/Capabilities/agentic-development/spec.md

@@ -81,7 +81,7 @@ Applies to any organization that wants a shared project knowledge base for agent
 - An agent working in `github.com/MSXOrg/<repo>` resolves `github.com/MSXOrg/docs` as the canonical project context.
 - An agent working in `<host>/<org>/<repo>` for any adopting organization resolves its designated documentation repository as the canonical project context, with no change to the framework.
 - A new product repository can adopt the framework by adding a router and the client routes that reach it, without copying standards pages.
-- An agent reads the repository's own README and CONTRIBUTING before it reads an organization standard, and still applies the organization standard when the two disagree.
+- An agent reads the repository's own README and [applicable contribution guidance](../../Ways-of-Working/Repository-Standard.md#contribution-guidance), local when needed and otherwise shared, before an organization standard, and still applies the organization standard when the two disagree.
 - A human or agent can follow the declared entry index to the applicable Workflow and current stage procedure.
 - A prompt such as `Review this PR <link>` reaches the Review procedure directly, while `Make this issue <description>` reaches Define, without a parallel process definition.
 - A missing, dirty, locally ahead, diverged, wrong-branch, or unreachable canonical context repository stops discovery before any context index is read.
@@ -96,7 +96,7 @@ The framework uses this normative reading order:
 2. **User-global preferences** — the human operator's baseline style and risk posture.
 3. **Repository router** — `AGENTS.md` identifies the host, organization, and the context sources below, in the order they are read.
 4. **Freshness gate** — fetch every canonical context repository and stop unless each clean default-branch checkout exactly matches its remote head.
-5. **Repository context** — README, CONTRIBUTING, local docs, and narrow repository exceptions.
+5. **Repository context** — README, applicable contribution guidance (local when needed, otherwise shared), local docs, and narrow repository exceptions.
 6. **Path-scoped repository rules** — local rules that apply to the files being read, generated, reviewed, or edited.
 7. **Organization documentation** — the designated documentation repository for the resolved organization: start at its entry index, resolve the current stage, then load the relevant standards, specs, and designs.
 8. **Inherited ecosystem documentation** — where the organization inherits from a broader standard set, the layer it inherits from.

src/docs/Capabilities/repository-governance/design-types.md

@@ -127,6 +127,11 @@ leave a repository unclassified, and an unclassified repository is
 indistinguishable from a forgotten one. With it, the exemptions are a list that
 can be reviewed, questioned, and shortened.
 
+Contribution guidance follows the same
+[conditional local-file rule](../../Ways-of-Working/Repository-Standard.md#contribution-guidance)
+as governed repositories. Supported community guidance may be inherited; its
+availability does not require a repository-local copy.
+
 An archive, a scratch mirror, or a repository whose content is generated wholesale
 by another system are the shapes this fits. A repository people actively develop
 in is not.

src/docs/Capabilities/repository-governance/design.md

@@ -104,10 +104,18 @@ the same structure:
 | `README.md`, `AGENTS.md`, client routes, `.gitattributes`, and `.gitignore` | Required locally | Explain and govern the defaults repository; they are not organization defaults. |
 
 All inherited community files live under `.github/` in the defaults repository
-so their scope is visible from their path. A local file in a target repository
-takes precedence and therefore records a deliberate repository exception. If a
-target defines any local issue-template set, it owns that complete set rather
-than combining local and central forms.
+so their scope is visible from their path. Validate required defaults in that
+source repository, not by requiring consumer copies. A target retains a local
+community file only for genuine repository-specific content or a documented
+exception under [Organization Standard](../../Ways-of-Working/Organization-Standard.md#community-files-are-organization-defaults).
+If a target defines any local issue-template set, it owns that complete set
+rather than combining local and central forms.
+
+[GitHub's fallback](https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/creating-a-default-community-health-file)
+exposes supported defaults without placing them in consumer clones, packages,
+or downloads. Consumer checks resolve the effective contribution guidance from
+the local guide when needed or the shared source; absence of an unnecessary
+local copy is not drift.
 
 There is no PR-template-file surface to inherit or distribute. Ordinary and
 defaults repositories follow the [Repository Standard's file
@@ -140,8 +148,10 @@ names.
 ## Required files by type
 
 The [Repository Standard](../../Ways-of-Working/Repository-Standard.md#required-files)
-owns the file list and which type adds to it. This design owns only the
-enforcement: presence is checked by reconciliation on the default branch, at
+owns the file list, its conditional contribution rule, and which type adds to
+it. This design owns only the enforcement: reconciliation checks required local
+files on the default branch and resolves effective contribution guidance under
+the [contribution rule](../../Ways-of-Working/Repository-Standard.md#contribution-guidance), at
 **Block** severity for the files that make a repository contributable and
 **Report** severity for the rest.
 
@@ -169,7 +179,8 @@ the contract below, not the implementation that satisfies it.
 | Exemption is justified | Does an exempted repository carry a recorded reason? |
 | Rulesets apply | Do the rulesets the type implies actually evaluate against this repository? |
 | Branch shape matches | Do the protected branches, merge methods, and required checks match what the type declares? |
-| Required files present | Does the default branch carry the governed baseline and the files its type adds, or the explicit Unmanaged discoverability minimum? |
+| Required local files present | Does the default branch carry the locally required baseline and type-specific files, or the explicit Unmanaged discoverability minimum, including a local contribution guide only when needed? |
+| Contribution guidance available | Does effective local or shared contribution guidance resolve, with required organization defaults validated in their source repository rather than copied into consumers? |
 | PR authoring and file policy | Are PR-template files absent under the [Repository Standard](../../Ways-of-Working/Repository-Standard.md#no-pr-template-files), and do actual records meet [PR Format](../../Ways-of-Working/PR-Format.md#check-readiness) with verified source coverage and supporting evidence? |
 
 ### Severity decides the response

src/docs/Capabilities/repository-governance/spec.md

@@ -63,7 +63,7 @@ subject to the same baseline, regardless of type:
 - **FR7 — Required checks gate the merge.** A pull request MUST NOT be mergeable until the checks its type declares have passed.
 - **FR8 — A review is requested automatically.** Every pull request MUST have a review requested without the author asking. Whether that review *gates* the merge is a separate rule ([the review gate](#the-review-gate)).
 - **FR9 — Merged branches are deleted.** The repository-level `delete_branch_on_merge` setting MUST delete the head branch of a merged pull request automatically. A protected branch MUST NOT be deleted by this setting.
-- **FR10 — Contribution rules are present.** Every governed repository MUST carry the [required files](../../Ways-of-Working/Repository-Standard.md#required-files) its type declares, so a contributor arriving at the repository can act without leaving it.
+- **FR10 — Contribution rules are present.** Every governed repository MUST carry the [required local files](../../Ways-of-Working/Repository-Standard.md#required-files) its type declares and expose discoverable [contribution guidance](../../Ways-of-Working/Repository-Standard.md#contribution-guidance), inherited or repository-specific under that rule.
 
 ### The review gate
 

src/docs/Ways-of-Working/Definition-of-Ready-and-Done.md

@@ -39,6 +39,13 @@ Absent checks are not a pass. When a pull request reports no checks at all, the
 
 If any item is open, the pull request stays a draft. Marking it ready with known-open work shifts the author's unfinished job onto reviewers — the opposite of what the signal means.
 
+When a change affects community or contribution guidance, verify
+[effective contribution guidance](Repository-Standard.md#contribution-guidance):
+shared files remain in their organization `.github` source home, inherited
+guidance resolves without repository-local copies, and needed local instructions
+or documented exceptions are preserved. Already-correct guidance does not
+require a file edit.
+
 Once every item holds, hand the change off: mark it ready for review and enable auto-merge so it lands the moment review approves and the required checks stay green. See [Branching and Merging](Branching-and-Merging.md#required-checks-and-auto-merge).
 
 Auto-merge gates only on what the ruleset declares. It waits for the required status checks and required approvals the branch ruleset names, and for nothing else — so where a ruleset declares no required status checks, an armed auto-merge lands on approval alone and never waits for CI, and "auto-merge is enabled" means considerably less than it appears to. That is a misconfiguration, not a local variation to work around: [Required checks and auto-merge](Branching-and-Merging.md#required-checks-and-auto-merge) already requires the ruleset to enforce required status checks, so a repository without them is in breach of it. The fix is to add the rule, not to compensate by watching the build by hand.