Contribute

The product repo is public on GitHub. This page describes the practical path from idea to merged change.

Before you write codeCopy Anchor Link

• Check the ledger. Cross-repo proposals, ADRs, and tasks live in the project repo (myco). If your change touches architecture or positioning, it probably belongs there first.
• Read the rules. AGENTS.md in each repo is the contract — English everywhere, ports/adapters boundaries, generated files never hand-edited.

The loopCopy Anchor Link

1. Fork and branch from main.

2. Install with bun install — keep linker = "hoisted" in bunfig.toml (see Dev environment).

3. Change code, not generated files. Paraglide output, routeTree.gen.ts, and drizzle migrations are regenerated by the toolchain.

4. Verify locally:

   Copy Text

   bun run check     # fmt + lint + typecheck
   bun run test      # vitest (scope per package for speed)

5. Open a PR describing what and why. Small, single-concern PRs merge fastest — plugins are single-concern by design.

Contribution conventionsCopy Anchor Link

• Domain logic goes in Effect services behind ports; adapters stay at the edge. New external capability? That's a new port + adapter, not a vendor import inside a plugin.
• UI comes from @ktbhealth/ui — never copy components into apps. Missing component? It gets added in the ui repo and consumed via a git-tag dep.
• Copy follows the positioning rule: the physician decides, KTB records. No diagnosis/treatment/recommendation language.

Docs changesCopy Anchor Link

This site lives in the docs repo — content is MDX under content/docs/<locale>/, organized by audience tabs. See Writing content.