Contributor development
Contributor development
Section titled “Contributor development”Use this page after contributor getting started and the architecture guide. It connects a change to the repository area that owns it and to the checks that prove it is ready. Consumer-facing API contracts belong in the user package API reference, not in a second contributor API reference.
Choose the next guide
Section titled “Choose the next guide”| Concern | Guide | Purpose |
|---|---|---|
| Repository shape and runtime layers | Architecture | Locate ownership, source boundaries, generated output, and runtime flows. |
| Import direction and public entrypoints | Import boundaries | Keep consumers on published exports and keep Foundation, client, Server, and Tooling responsibilities separate. |
| First local run and focused commands | Local development | Install from the root, preserve package build order, and choose workspace commands. |
| Focused verification | Local development | Start with the owning workspace’s focused commands and root checks. |
| Package distribution | Package architecture | Confirm public packages, private workspaces, and manifest exports before packaging. |
| Release scope | Contributing to FrameKit | Keep versioned work within public package ownership and verify consumer-facing behavior. |
| Documentation site | Local development | Run docs workspace commands from the root and keep contributor and user audiences separate. |
From source to release
Section titled “From source to release”- Identify the owning workspace and runtime layer. Start with the repository architecture, package architecture, and import boundaries.
- Change maintained source, not generated registries, copied assets, or build output. The generated code guide explains which commands recreate those outputs.
- Run the focused command for the owning workspace from the repository root. The local development guide documents the package-first build order and available scripts.
- Run the checks appropriate to the change. Start with the focused commands in local development and add broader root checks when the change crosses workspaces.
- If the change affects a public package, export, or generated consumer, follow package architecture to confirm ownership and manifest exports before packaging. Keep consumer examples linked to the user package API reference.
- Treat a versioned release as a public-package change: confirm its ownership and exports in package architecture before applying the repository’s release process.
- For documentation changes, use local development for docs workspace commands and keep consumer instructions in the user documentation.
Keep responsibilities separate
Section titled “Keep responsibilities separate”The contributor path has three related but distinct views:
- Architecture explains where behavior and output live.
- Import boundaries explains which imports and layer directions are allowed.
- Local development covers focused commands, docs builds, and the first verification step.
- Package architecture identifies public packages and exports before distribution or release work.
- User documentation covers consumer contracts; contributor pages keep repository ownership and workflow separate.
Use the user package API reference and the generated files reference for consumer contracts and generated-project behavior. This contributor section records repository ownership and workflow without duplicating those contracts.