lineage-open-source-review-guardrailslisted

# 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