Lineage Open Source Review Guardrails
Lineage should be easy to contribute to without letting quality, safety, or roadmap clarity drift.
Contribution Rules
- Contributors should assign an issue before starting work.
- PRs should target
develop and link the assigned issue, except maintainer-only housekeeping.
- Every PR should include relevant tests added/updated, or a clear no-test reason.
- Keep project-board status simple:
Todo, In Progress, Under Review, Done.
- Milestones are goals, not dates.
- Keep labels small and meaningful:
bug, enhancement, documentation, security, critical, needs:decision.
Review Standard
Review for correctness first, then safety, tests, maintainability, and documentation.
Look especially for:
- package inputs treated as trusted;
- provider-specific behavior leaking into core;
- missing tests for safety or idempotency;
- CLI output that cannot be inspected or tested;
- docs that imply future capabilities are already implemented;
- accidental disclosure of private roadmap, secrets, credentials, or machine-local state.
Public Voice
- Keep public docs focused on the agent-environment distribution layer.
- Avoid overpromising marketplace, enterprise, billing, cloud, vector DB, or workflow-engine capabilities.
- Prefer plain explanations of what currently works, what is experimental, and what is intentionally out of scope.
Maintainer Checklist
Before merge:
- Linked issue is assigned or the PR is explicit maintainer housekeeping.
- Required checks pass.
- Tests match the risk of the change.
- Branch target is
develop.
- Safety checklist is credible, not just checked.
1---2name: lineage-open-source-review-guardrails3description: Use when creating or reviewing Lineage issues, pull requests, contribution docs, release notes, labels, milestones, project-board updates, or maintainer decisions. Apply general code-review/contribution practice first, then enforce these Lineage-specific open-source rules.4---56# Lineage Open Source Review Guardrails78Lineage should be easy to contribute to without letting quality, safety, or roadmap clarity drift.910## Contribution Rules1112- Contributors should assign an issue before starting work.13- PRs should target `develop` and link the assigned issue, except maintainer-only housekeeping.14- Every PR should include relevant tests added/updated, or a clear no-test reason.15- Keep project-board status simple: `Todo`, `In Progress`, `Under Review`, `Done`.16- Milestones are goals, not dates.17- Keep labels small and meaningful: `bug`, `enhancement`, `documentation`, `security`, `critical`, `needs:decision`.1819## Review Standard2021Review for correctness first, then safety, tests, maintainability, and documentation.2223Look especially for:2425- package inputs treated as trusted;26- provider-specific behavior leaking into core;27- missing tests for safety or idempotency;28- CLI output that cannot be inspected or tested;29- docs that imply future capabilities are already implemented;30- accidental disclosure of private roadmap, secrets, credentials, or machine-local state.3132## Public Voice3334- Keep public docs focused on the agent-environment distribution layer.35- Avoid overpromising marketplace, enterprise, billing, cloud, vector DB, or workflow-engine capabilities.36- Prefer plain explanations of what currently works, what is experimental, and what is intentionally out of scope.3738## Maintainer Checklist3940Before merge:4142- Linked issue is assigned or the PR is explicit maintainer housekeeping.43- Required checks pass.44- Tests match the risk of the change.45- Branch target is `develop`.46- Safety checklist is credible, not just checked.
agentic-lineage