Contribution workflow

Contribute a focused fix, plugin, documentation improvement, or reusable platform capability. Start from the repository and inspect existing code and tests before designing a change.

Choose the owner

A plugin feature belongs in its plugin. Generic rendering, permission checks, credentials, RPC, and installation belong in core. A plugin using existing capabilities should not require Rust or runtime edits.

Discuss a new privileged operation in an issue before implementing a broad API. Describe the user action, data needed, authorization, lifetime, and cleanup.

Prepare a change

1. Set up the development environment.
2. Create a branch in your fork or checkout.
3. Reproduce the problem with a focused test or controlled fixture.
4. Implement the smallest coherent change and update affected documentation.
5. Run the relevant checks from the test guide.
6. Open a pull request describing the problem, resulting behavior, and validation.

Include visible before/after evidence for interface changes. Mention any validation you could not run and why.

Review boundaries

Keep plugin-specific selectors and third-party service behavior out of core. Do not weaken validation, trust checks, or sandbox restrictions to accommodate a plugin.

Never use a personal Fluxer installation as an automated mutation target. Generated fixtures provide controlled archives and process identities.

The project uses the MIT license. Follow existing formatting and package conventions rather than introducing unrelated infrastructure.