docs: add GOVERNANCE.md, CODE_OF_CONDUCT.md and clean up SECURITY.md

- Rewrite GOVERNANCE.md with expanded structure: goals, scope, project
  values, detailed roles, decision-making process, merge expectations,
  maintainer lifecycle, and continuity sections.
- Add CODE_OF_CONDUCT.md covering expected behavior, unacceptable
  behavior, scope, reporting, and enforcement.
- Remove fictitious email address from SECURITY.md, keeping only
  GitHub Private Vulnerability Reporting as the reporting channel.

CODE_OF_CONDUCT.md

@@ -0,0 +1,33 @@
+# Code of Conduct
+
+We are committed to a welcoming, safe, and respectful community.
+
+## Expected Behavior
+
+- Be respectful and inclusive.
+- Assume good intent; seek to understand.
+- Provide constructive feedback; critique code, not people.
+- Follow project guidelines and security practices.
+
+## Unacceptable Behavior
+
+- Harassment, personal attacks, or discriminatory language.
+- Publishing private information without consent.
+- Disruptive or aggressive behavior in any project space.
+
+## Scope
+
+This Code applies to all project spaces, including issues, pull requests,
+discussions, chat, and events.
+
+## Reporting
+
+Report incidents via [GitHub Issues](https://github.com/anthropic-yikun/open-code-review/issues)
+or [GitHub Discussions](https://github.com/anthropic-yikun/open-code-review/discussions).
+Include as much detail as possible (what happened, when/where, links, screenshots
+if applicable).
+
+## Enforcement
+
+Maintainers will investigate in good faith and may take appropriate action,
+including warnings, temporary bans, or removal from the community.

GOVERNANCE.md

@@ -0,0 +1,223 @@
+# OpenCodeReview Governance
+
+This document describes how OpenCodeReview is governed today and how technical
+decisions are made in the project.
+
+It is intended to reflect the project's current open development practice. As
+OpenCodeReview grows, this document may evolve to support a more formal
+governance model.
+
+## Goals
+
+OpenCodeReview governance is designed to keep the project:
+
+- open to contributors and users
+- pragmatic in day-to-day decision making
+- transparent in technical direction
+- safe for public API and security-sensitive changes
+- sustainable across multiple components and maintainers
+
+## Scope
+
+This document applies to the OpenCodeReview repository and its major public
+surfaces, including:
+
+- the CLI tool and its subcommands
+- LLM integration and provider interfaces
+- diff parsing and code review engine
+- configuration and plugin system
+- SDKs, examples, and project documentation
+
+## Project Values
+
+OpenCodeReview maintainers and contributors are expected to act consistently
+with these principles:
+
+- **Open development**: design discussion, issue tracking, and code review
+  happen in public whenever possible.
+- **Compatibility awareness**: CLI behavior, configuration formats, and
+  documented user workflows should not change casually.
+- **Security first**: changes affecting credentials, API keys, or execution
+  safety require extra scrutiny.
+- **Component ownership with cross-project accountability**: subsystem
+  maintainers own their areas, while cross-cutting changes require broader
+  review.
+- **Documentation and implementation alignment**: public contracts, code,
+  examples, and docs should stay consistent.
+
+## Roles
+
+### Contributors
+
+Contributors are anyone who participates in the project, including by:
+
+- opening issues or discussions
+- submitting pull requests
+- reviewing code
+- improving docs, tests, examples, or tooling
+
+Contributors are expected to follow:
+
+- [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md)
+- [CONTRIBUTING.md](CONTRIBUTING.md)
+- [SECURITY.md](SECURITY.md) for vulnerability reporting
+
+### Maintainers
+
+Maintainers are trusted contributors who have demonstrated sustained,
+high-quality contributions and a solid understanding of the codebase. They have:
+
+- write access to the repository
+- authority to review and merge pull requests
+- responsibility to uphold code quality and project standards
+
+Maintainer responsibilities include:
+
+- reviewing pull requests for owned areas
+- helping preserve code quality, compatibility, and security
+- requesting cross-component review when a change affects other surfaces
+- keeping implementation, tests, docs, and examples aligned when needed
+- helping contributors land changes successfully
+
+New Maintainers are nominated by existing Maintainers and approved by the
+Project Lead.
+
+### Project Lead
+
+The Project Lead provides overall direction for the project and has final
+authority on decisions when consensus cannot be reached. The current Project Lead
+is [@lizhengfeng101](https://github.com/lizhengfeng101).
+
+## Decision Making
+
+### Day-to-Day Changes
+
+Most changes are made through the normal pull request workflow described in
+[CONTRIBUTING.md](CONTRIBUTING.md):
+
+1. discuss the change in an issue when appropriate
+2. submit a pull request
+3. pass automated checks
+4. receive maintainer review for affected areas
+5. address feedback
+6. merge once approved
+
+Normal changes are decided by maintainer review and rough consensus.
+
+### Significant Changes
+
+Changes with broader impact require wider review. This includes changes to:
+
+- CLI behavior or command interfaces
+- LLM provider integration interfaces
+- configuration formats or defaults
+- diff parsing or review engine behavior
+- security-sensitive areas such as credential handling
+
+For these changes, maintainers should seek explicit review from all materially
+affected areas, not just the first area touched by the patch.
+
+Significant changes (new features, architectural changes, breaking changes)
+should be proposed via a GitHub Issue before implementation to allow community
+discussion.
+
+### Consensus and Voting
+
+OpenCodeReview prefers **lazy consensus** for most technical decisions:
+
+- if affected maintainers agree, the change may proceed
+- if concerns are raised, they should be addressed in the PR or issue discussion
+
+If consensus cannot be reached in a reasonable time, the Project Lead has final
+decision-making authority.
+
+## Reviews and Merge Expectations
+
+The following expectations apply before merge:
+
+- relevant CI checks should pass, or failures must be understood and accepted by
+  maintainers
+- at least one maintainer of the affected area should review the change
+- cross-cutting changes should be reviewed by all materially affected areas when
+  practical
+- breaking changes should be clearly called out, with migration guidance where
+  needed
+- docs and tests should be updated when behavior changes
+
+Maintainers may decline or defer a change if it:
+
+- conflicts with approved design direction
+- introduces unnecessary compatibility risk
+- weakens security without a strong justification
+- mixes unrelated work into a single change
+
+## Communication Channels
+
+The project's public collaboration channels are:
+
+- GitHub Issues for bugs, feature requests, and implementation questions
+- GitHub Discussions for broader design discussion and community help
+- pull requests for concrete code and documentation review
+
+Security issues should follow the private reporting guidance in
+[SECURITY.md](SECURITY.md).
+
+## Continuity
+
+OpenCodeReview is hosted under the [Alibaba](https://github.com/alibaba) GitHub
+organization. Multiple members of the organization have administrative access to
+the repository, ensuring that the project can continue to operate even if any
+single individual becomes unavailable.
+
+Additionally:
+
+- Multiple Maintainers are familiar with the full codebase, ensuring no single
+  point of failure in terms of project knowledge.
+- The bus factor of the project is greater than one — critical subsystems
+  (agent, LLM integration, diff parsing, configuration) are understood by more
+  than one person.
+- Repository credentials, CI/CD pipelines, and release processes are accessible
+  to multiple team members within the Alibaba organization.
+
+## Becoming a Maintainer
+
+New maintainers are selected based on sustained, high-quality contribution to
+the project.
+
+Signals that someone may be ready for maintainership include:
+
+- repeated high-quality code or documentation contributions
+- strong reviews and constructive technical feedback
+- reliable follow-through on owned work
+- good judgment on compatibility, security, and project direction
+- collaborative behavior with contributors and maintainers
+
+The typical process is:
+
+1. nomination by an existing Maintainer
+2. discussion among Maintainers and the Project Lead
+3. no unresolved objections after a reasonable review period
+4. granting of write access and update of any relevant maintainer records
+
+## Maintainer Inactivity and Removal
+
+Maintainers may step down at any time by notifying the project.
+
+The Project Lead may also update maintainer status when someone has been inactive
+for an extended period, for example several months without meaningful review or
+maintenance activity.
+
+Removal should be handled respectfully and pragmatically, with the goal of
+keeping ownership accurate rather than punitive.
+
+Maintainers may also be removed for serious violations of project expectations,
+including repeated abuse of project privileges or violations of the Code of
+Conduct.
+
+## Changes to Governance
+
+Changes to this governance document should be made through a public pull request.
+
+Governance changes should receive review from Maintainers and the Project Lead,
+and should not be merged without giving maintainers and contributors a
+reasonable opportunity to comment.

SECURITY.md

@@ -13,10 +13,7 @@ Only the latest released version receives security updates. Users are encouraged
 
 **Please do NOT report security vulnerabilities through public GitHub issues.**
 
-Instead, use one of the following channels:
+Instead, use **GitHub Private Vulnerability Reporting** — go to the [Security Advisories](https://github.com/alibaba/open-code-review/security/advisories/new) page and submit a new advisory.
-
-1. **GitHub Private Vulnerability Reporting** — go to the [Security Advisories](https://github.com/alibaba/open-code-review/security/advisories/new) page and submit a new advisory.
-2. **Email** — send a report to **open-code-review-security@alibabacloud.com** with the details below.
 
 ### What to Include