Do some prep work for a foundation (#1312)

@BenTheElder @zlammerts-svg

Thanks again for driving this Tim!

CODE_OF_CONDUCT.md

@@ -71,13 +71,9 @@ dispute. If you are unable to resolve the matter for any reason, or if the
 behavior is threatening or harassing, report it. We are dedicated to providing
 an environment where participants feel welcome and safe.
 
-Reports should be directed to *[PROJECT STEWARD NAME(s) AND EMAIL(s)]*, the
-Project Steward(s) for *[PROJECT NAME]*. It is the Project Steward’s duty to
-receive and address reported violations of the code of conduct. They will then
-work with a committee consisting of representatives from the Open Source
-Programs Office and the Google Open Source Strategy team. If for any reason you
-are uncomfortable reaching out to the Project Steward, please email
-opensource@google.com.
+Reports should be directed to ate-cocc@googlegroups.com, the
+Project Steward(s) for Agent Substrate. It is the Project Stewards' duty to
+receive and address reported violations of the code of conduct.
 
 We will investigate every complaint, but you may not receive a direct response.
 We will use our discretion in determining when and how to follow up on reported

GOVERNANCE.md

@@ -1,8 +1,7 @@
 # Governance
 
-> **Status: Draft — under review and discussion.** This document is a proposal
-> and has not yet been ratified by the Substrate maintainers. Feedback welcome
-> via PR review or on the `ate-dev@googlegroups.com` mailing list.
+Feedback is welcome via PR review or on the `ate-dev@googlegroups.com` mailing
+list.
 
 Agent Substrate is an Apache-2.0 open-source project. This document describes
 how decisions get made and how contributors can take on more responsibility
@@ -44,7 +43,48 @@ project externally.
 A formal list of Maintainers and per-area Reviewers (e.g., via `CODEOWNERS` or
 `OWNERS` files) is a separate discussion and will land as roles are formalized.
 
-## Decisions
+### Becoming a Contributor
+
+Contributors are community members who have made some contributions to the
+project and are known to other community members.  Being a Contributor means
+your PRs can automatically run CI, and do not need to have a maintainer kick it
+off.
+
+To become a Contributor, you can either nominate yourself (via email to the
+ate-dev mailing list) or be nominated by another Maintainer or Reviewer.
+
+### Becoming a Reviewer
+
+Reviewers are Contributors who have made more significant contributions to the
+project and whose opinions are sought when reviewing other contributions.
+Being a Reviewer means you can review and label PRs and issues, but cannot
+merge PRs without a Maintainer.
+
+To become a Reviewer, you can either nominate yourself (via email to the
+ate-dev mailing list) or be nominated by another Maintainer or Reviewer.
+
+### Becoming a Maintainer
+
+Maintainers are Reviewers or Contributors who have made significant
+contributions to the project, and are trusted to approve and merge other
+people's PRs.
+
+To become a Reviewer, you can either nominate yourself (via email to the
+ate-dev mailing list) or be nominated by another Maintainer.
+
+### Emeritus Maintainers
+
+Depending on the reason for removal or resignation, a Maintainer may be
+converted to Emeritus status. Emeritus Maintainers are recognized for their
+past contributions and may still be consulted on project matters, but do not
+have voting rights or merge access. Emeritus Maintainers are listed in
+MAINTAINERS.md under a separate Emeritus section.
+
+An Emeritus Maintainer may be reinstated to active Maintainer status by a
+simple majority vote of existing Maintainers, provided they meet the current
+Maintainer requirements and can commit to ongoing participation.
+
+## Decision Making
 
 - **Code changes.** Every PR needs at least one Maintainer approval and green
   CI before merge. Authors should never approve or merge their own PRs, unless
@@ -67,6 +107,20 @@ months may have their status reviewed, with allowances for known absences
 designated "emeritus", which carries no formal authority but recognizes their
 past contributions and allows them to return at a future date if they wish.
 
+### Removing a Maintainer, Reviewer, or Contributor
+
+Maintainers may resign at any time if they feel that they will not be able to
+continue fulfilling their project duties.
+
+Maintainers may also be removed after being inactive, failure to fulfill their
+Maintainer responsibilities, violating the Code of Conduct, or other reasons.
+Inactivity is defined as a period of very low or no activity in the project for
+6 months or more, with no definite schedule to return to full Maintainer
+activity.
+
+A Maintainer may be removed at any time by a 2/3 vote of the remaining
+maintainers.
+
 ## Changing this document
 
 Open a PR. Allow at least one week for discussion. Requires Maintainer approval