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.

Follow existing formatting and package conventions rather than introducing unrelated infrastructure.