Translate commons principles into contribution and stewardship guidance

CONTRIBUTING.md

@@ -70,3 +70,15 @@ A pull request should make it possible for another contributor to understand:
 5. what remains unresolved, if anything.
 
 Use the organization pull-request template when a repository does not define its own.
+
+## Collaboration and bounded openness
+
+**Proposed contribution guidance; project-local review pending.** Existing project rules remain in place until a change is explicitly adopted.
+
+The shared [commons collaboration proposal](https://github.com/Root-Sequence/root-sequence/blob/main/commons/README.md#collaboration-as-a-living-experiment) welcomes corrections, counterexamples, alternative models, domain expertise, lived experience, and small contributions. Agreement with an originator or the whole ecosystem is not a prerequisite. Give claims appropriate evidence and keep normative disagreement visible.
+
+Contribution does not confer merge, moderation, administrative, data-access, or publication authority. Use branches and review for consequential changes. Public branches and PRs are public publication surfaces; private drafts and participant material require explicit promotion before crossing that boundary.
+
+Document consequential powers and unresolved objections. Conduct boundaries should protect participation while leaving criticism possible. Repair is voluntary and must not require reconciliation or exposure. Make pauses, handoffs, smaller scope, and departure ordinary options; a fork remains bounded by licenses, third-party rights, and privacy.
+
+When proposing a collaboration experiment, identify the question, affected perspectives, burdens, authority, observations, review/stop conditions, and limits. Participation in repository work is not enrollment in participant research. Extend existing project processes; do not infer a new governing body or lift a project hold from this default guide.

PROJECT_STEWARDSHIP.md

@@ -195,3 +195,11 @@ A repository that has not adopted stewardship should continue working normally.
 A healthy project should require less remembering over time, not more.
 
 The maintenance layer exists so people can spend attention on exploration, learning, building, revising, connecting ideas, and adapting to new constraints instead of repeatedly reconstructing what routine maintenance was forgotten.
+
+## Human stewardship and adaptation
+
+**Proposed review prompts, not newly assigned roles or configured automation.** Extend the existing maintenance model by making consequential powers and burdens inspectable: actual maintainer, scope of access, decision authority, review route, handoff, and revocation. Maintenance labor does not automatically grant wider project authority.
+
+Ask whether the process depends on an irreplaceable person, consumes more attention than it saves, discourages criticism, or transfers unpaid work to someone else. Stepping away, reducing scope, and retiring a project are legitimate outcomes. A handoff should preserve the minimum operational knowledge and authorized access without retaining unnecessary personal information.
+
+Use voluntary feedback and bounded records to compare expected and actual maintenance costs. Record missing evidence and unresolved dissent. Silence, inactivity, and fewer contributions are ambiguous; they do not authorize deletion, publication, expanded automation, or changes to governance. Review signals should lead to a scoped proposal or a decision to stop, not a universal reputation or productivity score.

PULL_REQUEST_TEMPLATE.md

@@ -25,3 +25,7 @@ Check only what is relevant; do not update files mechanically.
 ## Notes / unresolved questions
 
 <!-- Anything reviewers or future contributors should know? -->
+
+## Participation and authority, when relevant
+
+<!-- Whose perspectives or burdens matter? What disagreement remains? Who can authorize the consequence? What enables review, reversal, handoff, or stopping? State privacy/publication boundaries. A passing check does not adopt a governance proposal or release a project hold. -->

README.md

@@ -39,3 +39,7 @@ npm run docs:audit
 Repositories can adopt the template incrementally. A repository without those scripts simply skips the corresponding maintenance steps.
 
 The longer-term plan is to move reusable maintenance logic into a dedicated cross-project stewardship engine while organization `.github` repositories remain thin adapters/templates.
+
+## Collaboration proposal
+
+The [commons collaboration proposal](https://github.com/Root-Sequence/root-sequence/blob/main/commons/README.md#collaboration-as-a-living-experiment) is published for discussion in the conceptual commons. Proposed applications to repository work are in [CONTRIBUTING.md](CONTRIBUTING.md), with maintenance questions in [Project Stewardship](PROJECT_STEWARDSHIP.md#human-stewardship-and-adaptation). Each project keeps its existing rules until it explicitly adopts a change.