Contribution
ContributorA scoped issue, acceptance criteria, tests and a pull request. No production credentials.
THE HARNESS
Open contribution.
Accountable release.
A home for the people who test, review and protect the work. Everyone can propose a change. Shipping it requires independent evidence and authority.
Release authority is separate from membership.
Joining a project, claiming work or completing a task never grants merge access, production credentials or permission to deploy.
The path to production
Required operating policyAutomated checks
CI runnerSecret scan, dependency audit, type checks, database tests, production build and browser checks on the proposed commit.
Independent review
Project maintainerSomeone other than the author verifies behavior, maintainability, accessibility and acceptance criteria.
Security review
Harness reviewerReview data access, abuse cases, dependencies and trust boundaries. Auth, database, workflow and release changes require specialist review.
Release approval
Release stewardApprove the exact reviewed commit and preview, record rollback and release evidence, then verify production.
What is established
- Protected application actionsIn source
Server verification, validated inputs and database access policies are in source. Hosted behavior still requires operator verification.
- Checks defined for each pull requestIn source
Known secret patterns, dependency audit, type checks, database tests, build and browser tests. A definition is not a successful run.
- Repository and hosting enforcementVerify setup
Required reviews, protected branches and production approvers must be verified in the providers. No live enforcement status is claimed here.
- Independent harness reviewersRecruiting
Security, maintainer and release roles need named, consenting people. This page does not invent a staffed team.
Review the change, not the reputation.
New and experienced contributors follow the same review boundary. Passing tests never substitutes for an independent review.
- Author cannot approve their own contribution.
- Approvals and checks refer to the exact commit. New changes require fresh evidence.
- Authentication, permissions, data, dependencies and CI changes receive security review.
- Untrusted contribution code runs without production secrets.
- Release records include a preview, approvals and rollback coordinate.
Build the team. Prove the boundary.
Real founding work, ready for humans to take over. Roles remain unassigned until someone accepts them.
Establish the independent harness team
Give the community an accountable review team before widening release access.
Acceptance criteria
Publish consenting maintainer and security reviewer contacts; document conflicts of interest and coverage; configure protected main with required checks and fresh independent reviews; prove a failing pull request cannot merge; record provider evidence.
Needs: Owner appoints trusted reviewers and approves repository settings.
Exercise the review boundary against hostile contributions
Demonstrate that untrusted contributions cannot gain authority or ship themselves.
Acceptance criteria
Publish a threat model and reproducible safe tests; prove self-approval and unauthorized completion are rejected; demonstrate stale evidence blocks acceptance; verify that application task completion cannot trigger a production deploy.
Needs: Hosted staging auth; independent review and release controls configured.
Rehearse a release and rollback with a human steward
Make every release attributable, reviewable and recoverable.
Acceptance criteria
Record source SHA, preview URL, check results and independent approvals; prove unauthorized deployment denied; rehearse rollback in staging; verify the released URL and record an owner-approved production procedure.
Needs: Harness team appointed; hosting release permissions reviewed.