Project
Contributor roadmap
Useful operational and engineering input before public source release, and what a contribution proposal should explain.
Educational / conceptual specification · Not a released implementation contract

Contribute knowledge before code is public
A dispatcher can explain carrier reassignment; a warehouse supervisor can describe short loading; a broker can clarify commercial responsibility; an engineer can challenge a retry or authorization boundary. These contributions help shape the model before a public repository is available.
The strongest proposal identifies an actor, source of truth, shared reference and required evidence. Include an exception or correction path and remove personal information, credentials and commercially sensitive details. A generic request for a dashboard is less actionable than a clear decision an operator needs to make.
Keep contributions aligned with phases
Core MVP work focuses on coherent load, assignment, event and document workflows. Operations expansion follows that foundation; adapters and automation need stable contracts; hosted enterprise concerns remain future. A later-phase idea can be useful without being treated as an immediate product promise.
Public issues, code contribution instructions and review expectations will be announced with source release. No private repository URL or fictitious public pull-request channel is exposed here. Contact Kordspace with early collaboration interest instead.
Evaluate the full scenario
Future implementation should test duplicate requests, unknown references, permission denial, late events and incomplete evidence in addition to a happy path. A module is useful when it supports operator recovery as well as routine work.
The project should remain transparent about what has been verified. Conceptual documentation can guide review today, but source release and executed tests will be needed before calling a capability operational.