What is not built yet
The gaps between the model these docs describe and the code that exists today.
Not built yet
This page describes intended behaviour, not what the CLI and registry do today. Commands and fields on it may not exist. Pages without this notice are checked against the shipped CLI.
The rest of this site documents what the CLI and registry do now. This page is the exception: it is the shortest honest account of what is missing, so you can tell whether Feed Packages are ready for what you want to do.
Items are in dependency order. Each one is work we intend to do, not a decision still being weighed.
Publishing a package you own
Today the only publish command is fruitful registry publish-first-party, which ships the packages maintained in the Fruitful repository. There is no path for a package you author yourself.
The authorization behind it already exists: namespaces are owned explicitly, ownership follows dot boundaries, and there is no first-publisher-wins path. What is missing is the endpoint that accepts a candidate release, and the CLI command that sends one.
fruitful registry publish my-packageA CLI you install instead of clone
The CLI runs from a checkout of the Fruitful repository because it still reaches the database directly to publish first-party packages. An external author cannot install it at all.
It needs to talk only to the API before it can be released on its own.
npm install -g @fruitful/cliNamespaces proved by domain
A namespace is granted to a reviewed publisher by a person. That works while every publisher is known to us, and does not scale past it.
The intended model follows the one Lexicons already use: the leading domain of a name is the authority, and you prove you control it. A site that wants to publish a package about itself proves the domain and the name is theirs, with no negotiation. Subdomain authority is included, because the team that would author a package is rarely the team that controls the apex domain.
Packages published by the site itself
Once a domain can be proved, a package written by the site it follows can be told apart from one written by somebody else, and labelled as such.
Proving a domain shows who published a package. It does not show that the package is good, or that it captures everything it should, so a proved package will still go through review before it is promoted. Where a site publishes its own package for a site somebody else already covers, both will be listed.
Where the docs are ahead of the code
Every page here except this one describes behaviour that exists. Commands shown on those pages are checked against the CLI's command table on every build, so a page cannot quietly promise something we have not built. A page that describes intended behaviour carries the same notice this one does.