Contribute to Fungi

Start with the problem you want to solve. Open an issue with the maintainers of the component you use before writing a patch. Include the component version or Git revision, the expected result and a small reproduction. Agree the scope and source checkout with the maintainer.

For help finding the right maintainer, use the support contact. Send security reports through that page’s security contact instead of posting exploit details or credentials in a public issue.

Set up a workspace checkout

These instructions use the Fungi workspace containing mise.toml, mise.lock and pnpm-lock.yaml. For a separately distributed package, follow its own README and license.

Install Mise, the tool that selects the workspace’s Node.js and pnpm versions. The minimum Mise version is recorded in mise.toml. Review that file, then run these commands from the workspace root:

TERMINAL

mise trust
mise install --locked
mise run setup
mise run doctor

mise install --locked installs the tools recorded in mise.lock. mise run setup installs the frozen pnpm dependency graph. Both installation steps need access to their download sources. doctor reports the required tool versions as JSON; its overall status should be pass.

If a version is wrong, use the locked tools rather than updating the dependency graph to match your machine. Checks do not install missing dependencies for you.

Find the owner of a change

Source directory	Responsibility
apps/	Customer Apps, the Hub, terminal UI and websites
packages/	Reusable modules and their public contracts
runtimes/	Local, App and Computer execution
services/	Edge and host service composition
tooling/	Development, checks and deployment tooling

Read the component’s README, exported interface, a real caller and the nearest test before changing it. Keep the behavior and its callers together. Generated API pages come from source comments; edit those comments and use the package’s docs:write command when its README specifies one.

Check a small change

Run the nearest existing test first, then the affected component’s gate. For example, this checks Cairn, the identifier package, from a prepared workspace:

TERMINAL

mise run check:package -- @fungi.computer/cairn

The command accepts a package name or workspace directory. It runs the component’s routine checks, including its tests and applicable API-docs check. It does not publish the package. A change used by another component also needs that caller’s relevant test. Native or browser tests may require Linux, a runtime build or other prerequisites described in the component’s README.

For documentation-site changes, build the site and check its internal links:

TERMINAL

pnpm turbo:run run build --filter=@fungi.computer/docs
pnpm --dir apps/docs run check:links

The link check covers built same-site paths and assets. Review heading links and external destinations separately. Existing executable documentation examples run through pnpm --dir apps/docs test; new code fences are not automatically added to that proof. Keep examples complete and state any account, runtime or permission they require.

Send a patch for review

Work on a task branch and preserve other contributors’ changes. Make one coherent change, include a regression test when behavior needs one, and use a Conventional Commit message such as fix(cairn): reject an invalid identifier. Use the installed Git hooks.

In the agreed review channel, include:

• The source revision and files changed.
• The user-visible problem and how the change fixes it.
• The exact checks run, their results and any qualification you could not run.

Do not include account data, credentials or copied production logs. The maintainer joins the change and runs the required combined checks. A source patch does not authorize deployment or publication. License and attribution requirements come from the component’s actual license and notices; one component’s license does not cover unrelated code.