Coding Standards, Security, and Contributor Policy

Overview

This part of the repository defines how changes are proposed, reviewed, versioned, and licensed. It combines workflow rules, review gates, change-log conventions, a community code of conduct, and the project’s legal terms so contributors can move from idea to merged change with clear expectations.

The policy set is intentionally split between English source-of-truth files and Chinese-language mirrors under rules/zh/. The common workflow and code review documents define the baseline process, while the changelog, code of conduct, and license files govern release notes, community behavior, and distribution rights.

Contribution Workflow

The workflow is split across the common rules and the Chinese mirror set. The English documents describe the canonical process; the Chinese documents restate the same workflow and review rules, and rules/zh/README.md explains how rule precedence works.

Required workflow sequence

1. Research and reuse first

Search for existing implementations before writing new code. The document requires GitHub code search first, then library documentation, then broader web research only if the first two are insufficient.

1. Plan before coding

Generate planning artifacts before implementation and break the work into phases.

1. Use TDD

Write tests first, implement to make them pass, then refactor.

1. Run code review immediately after coding

The workflow says to use the review agent right after writing code and to fix critical and high-priority findings.

1. Commit and push with disciplined history

The workflow requires detailed commit messages and directs contributors to the git workflow document for commit format and pull request process.

1. Complete pre-review checks before requesting review

The workflow requires passing automated checks, resolving merge conflicts, and syncing the branch with the target branch before asking for review.

Code Review Policy

rules/common/code-review.md and rules/zh/code-review.md define the same review expectations in English and Chinese. They treat review as mandatory after code changes and before merges, with extra scrutiny for security-sensitive work.

Review checklist details

The review policy explicitly escalates auth, payments, user data, database, filesystem, external API, cryptography, and financial changes to security review.

The checklist in rules/common/code-review.md and rules/zh/code-review.md is concrete, not advisory. It asks reviewers to verify:

• code readability and naming
• focused functions
• cohesive files
• shallow nesting
• explicit error handling
• no hardcoded secrets or credentials
• no console logging or debug statements
• tests for new functionality
• minimum test coverage

The Chinese file mirrors the same structure and review thresholds, including the same severity levels and agent list.

Changelog Policy

CHANGELOG.md is the project’s release-history ledger. It states that all notable changes are documented there, that the format is based on Keep a Changelog, and that the project adheres to Semantic Versioning.

The file also records two important conventions:

• cross-references in parentheses point to either knowledge/matrix.kvx session entries such as sess#NN

or research decision IDs such as D1 through D18

• the changelog is organized into versioned sections, including [Unreleased], with release links at the bottom

What the changelog captures

The visible entries show that the changelog records:

• added features
• removed items
• versioned releases with dates
• implementation notes that point back to sessions and decisions

This makes the changelog both a release note and a provenance trail for major repository changes.

Code of Conduct

CODE_OF_CONDUCT.md adopts the Contributor Covenant Code of Conduct, version 2.1. It defines behavioral expectations, reporting channels, enforcement responsibilities, and escalation outcomes.

Core obligations

• Be welcoming, respectful, and constructive.
• Avoid harassment, insults, personal attacks, or disclosure of private information.
• Respect community leaders’ authority to clarify and enforce standards.
• Follow the scope of the conduct policy in all community spaces and when representing the community publicly.

Enforcement path

Reports are directed to conduct@paxeer.app. The file defines four enforcement outcomes:

• Correction
• Warning
• Temporary Ban
• Permanent Ban

The enforcement section also states that complaints are reviewed promptly and fairly, with privacy and security of reporters protected.

Licensing and Third-Party Terms

LICENSE.md is the repository’s primary license for Paxlabs code. It is not a standard permissive license; it is a custom Matrix-Protocol license with explicit copyleft, commercial-trigger, audit, and termination terms.

LICENSE.md summary

Third-party license inventory

licenses/README.md explains that the directory contains the texts for open-source dependencies used by the monorepo, and that Paxlabs code is covered separately by LICENSE.md.

Practical reading order for contributors

1. Read CODE_OF_CONDUCT.md for expected behavior.
2. Read rules/common/development-workflow.md for the implementation process.
3. Read rules/common/code-review.md for review gates and escalation.
4. Read CHANGELOG.md to understand release-note practice and how changes are recorded.
5. Read LICENSE.md and licenses/README.md for legal terms and third-party license coverage.
6. Use the Chinese mirrors in rules/zh/ when working in that language set.

Key Files Reference