Module schema 

The prov → flower schema adapter, for a workspace’s content documents.

prov detects a workspace’s controlled vocabularies and relations by resolving its config; flower renders and validates. This module is the seam between them: it turns a resolved WorkspaceConfig (plus the vocabularies its controlled fields point at) into a generic flower_core::Schema. flower-core never learns the word “prov”; this crate owns the translation.

• Each fields.<name> → a rule carrying its declared type. A field that also names a vocabulary gets a Constraint::Enum; one that only declares a type gets a typed rule with no constraint — enough for the editor to render the right widget (a date field gets a date picker) without claiming any value is illegal. Both a scalar-at-key rule and an each-item rule are emitted, so the field is governed whether written as a single value (audience: public) or a list (audience: [public, private]).
• Each relation → a Constraint::Reference; the spanning relation is flagged spanning: true, a many-relation also governs each item (a list of links). The relation’s means: gloss travels with it, so a row can say what part_of is for rather than leaving a reader to infer it.
• prov’s own kernel keys → kernel_rules. title, id, the opaque-payload axis and the root’s inline prov: policy block are prov vocabulary exactly as much as contents is, and a document schema that governed only the declared fields would leave the keys prov always reads as untyped text boxes. They come last, so a workspace that declares a field of the same name shadows them.

For the config document rather than the content documents, see [crate::config_schema].

Functions

document_rules

schema_from_config’s rules, before they become a schema — the composition point for an application overlay, and the peer of config_rules one document over.

kernel_rules

prov’s own frontmatter keys — the ones every document may carry whether or not the workspace declared anything.

schema_from_config

Build a flower Schema from a resolved prov workspace config and the vocabularies its controlled fields point at (keyed by field name). Vocabularies the caller could not load are simply absent, yielding an enum with no offered terms — still a rule (so a closed field with no store rejects everything, which is the honest signal that its vocabulary is missing).