Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
87 lines (68 loc) · 3.49 KB

CONTRIBUTING.md

File metadata and controls

87 lines (68 loc) · 3.49 KB
Raw

Contributing

Thanks for helping improve ROSS, a modified fork of Mike. Please keep contributions small, focused, and easy to review while preserving the inherited Mike functionality recorded in the baseline contract.

Guidelines

  • Prefer targeted edits over broad refactors.
  • Keep each PR focused on one bug, feature, or cleanup.
  • Update docs or env examples when changing setup, config, or user-facing behavior.
  • Please do not propose local-hosting refactors for the main app, such as local LLMs, local databases, or local filesystem storage. Those ideas are better suited to a future fully local version of the project.
  • Do not commit secrets, API keys, private documents, or local .env files.
  • Do not use confidential, privileged, regulated, proprietary, or real client material in fixtures, previews, demonstrations, issues, or pull requests.
  • Do not scrape CanLII. Licensed connectors require an approved agreement, transport, entitlement, and activation record.

Before Opening a PR

  • Install all dependencies from the repository root with npm run install:all.
  • Run the baseline contract tests with npm test.
  • Run the full local verification suite with npm run check.
  • For a release-candidate change, regenerate and verify the governed manifest with npm run build:release-manifest and npm run test:release-manifest.
  • If deployed test URLs are available, run ROSS_E2E_API_URL=... ROSS_E2E_APP_URL=... npm run test:e2e.
  • Check git diff and remove unrelated changes.
  • Write a concise Markdown PR description with:
    • summary
    • changes
    • why
    • testing
    • tradeoffs and risk
    • upstream provenance, when applicable

Testing Expectations

  • Add a regression test at the lowest practical layer for each feature or bug fix. Prefer a focused unit test, then a route or integration test, and use an end-to-end test only when a browser or deployed service is necessary to prove the behaviour.
  • Do not weaken, skip, broadly disable, or delete an existing test merely to make a change pass. Correct stale expectations only when the implementation and governing contract demonstrate that the expectation is obsolete.
  • Record the exact commands run in the PR description. Baseline verification is required on the final PR head; a successful run on an earlier commit is not sufficient.
  • Tests requiring live Supabase, provider keys, or deployed URLs must be explicitly environment-gated and must not expose secrets or real client data.
  • Changes to authentication, authorization, privacy, data boundaries, migrations, deployment, or release mechanics require focused verification in addition to the normal Baseline.

System Workflows

System workflows live in mike-workflows/system/. Put structured metadata in the YAML frontmatter at the top of SKILL.md, put workflow instructions in the body of SKILL.md, and use table-config.yaml for tabular review columns.

After changing system workflows, regenerate the app files:

node scripts/build-workflows.js

Security

Do not open a public issue for security vulnerabilities. Use ROSS private vulnerability reporting instead. If an issue also affects upstream Mike, coordinate disclosure before opening an upstream report or pull request.

We will aim to respond promptly and coordinate a disclosure timeline with you.

Local Development

Backend:

npm run build --prefix backend

Frontend:

npm run build --prefix frontend