Extract operational-repo rules into one scoped section (#368, PR-3) - #371
Merged
Conversation
Doc surgery on the granular-single-scope model. The operational-vs-release carve-out was scattered inline across Foundational Principles, Branching Model, and Release Model, so those all-downstream sections mixed two scopes a reader had to piece apart. - New "## Operational Repositories" section consolidates the operational workflow rules (direct-to-develop, advisory CI, the develop/main ruleset differences, dispatch-only release, dependabot/merge-bot on every tier). It is tagged appliesTo ["operational"] in spec/files.json, so PR-2's section-presence check requires it only on operational repos. - The three inline carve-outs slim to one-line pointers, leaving Foundational, Branching, and Release single-scope (the release model). No operational detail is lost - it all moves into the new section. - The operational line-ending rule stays in the Line Endings section (findable where EOL rules live) with a cross-pointer, rather than moving into the new section. Verified: operational repos require the new section and release repos do not, the hub's own AGENTS.md is complete, validate.py and the doc linters are clean. Once merged, the 4 operational repos will DRIFT on this section until they adopt it - the intended convergence signal. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Pull request overview
This PR refactors governance documentation by consolidating operational-repository (workflowModel: operational) rules into a single dedicated section, and updates the spec baseline so that section is required only for operational repos.
Changes:
- Add a new
## Operational Repositoriessection toAGENTS.md, moving previously scattered operational carve-outs into one scoped place. - Slim the operational references in Foundational Principles / Branching Model / Release Model down to short pointers to the new section.
- Update
spec/files.jsonto require the newOperational Repositoriessection only whenappliesTo: ["operational"].
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| AGENTS.md | Extracts and centralizes operational repo rules into a dedicated section, leaving other models single-scope with pointers. |
| spec/files.json | Makes Operational Repositories a section-level appliesTo: ["operational"] requirement under AGENTS.md. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
Third of the staged PRs for #368 — the first doc surgery. The
operational-vs-releasecarve-out was scattered inline across Foundational Principles, Branching Model, and Release Model, so those all-downstream sections mixed two scopes a reader (and the audit) had to piece apart. This makes the operational rules one granular single-scope piece.Change
## Operational Repositoriessection consolidates the operational workflow rules — direct-to-develop, advisory CI, thedevelop/mainruleset differences, dispatch-only release, dependabot/merge-bot on every tier. It is taggedappliesTo: ["operational"]inspec/files.json, so PR-2's section-presence check requires it only on the 4 operational repos.releasemodel). No operational detail is lost — it all moves into the new section.## Line Endings(findable where EOL rules live) with a cross-pointer, rather than moving into the new section.Scope
Deliberately just the operational extraction. The other two contaminants from the plan — hub-only pointers inside carried sections, and the csharp/python/docker examples baked into Release Model / Workflow YAML — are separate follow-up PRs, to keep each a small composable piece.
Verified
AGENTS.mdis complete (no missing sections in either view).spec/validate.py,markdownlint,editorconfig-checkerclean.Once merged, the 4 operational repos will DRIFT on this section until they adopt it — the intended convergence signal, not a regression. Held on
develop— nomainpromotion.