Resource Property Vocabulary

Each resource type exposes well-known properties for use in set_env expressions:

Not every type registers url: certificate registers two app-filesystem paths and no address at all. Where a type does register it, the url property is the fully-formed address of the resource — a connection string for a backing service (e.g. postgresql://user:pass@host:5432/dbname), and the public origin for https-origin (e.g. https://vault.example.com, the same value as $app.url). Where a type registers more than one property, the others provide individual components for apps that require them separately.

key_file — and every *_key / *_key_file property name, in any type's vocabulary or outside one — is credential-bearing: a provider registers its value with its redactor before generating anything, exactly as it does for password, secret_key and access_key (D-56 rule 5). Membership of a type's vocabulary never turns that off.

This vocabulary is also published in machine-readable form as schema/resource-properties.json, which adds a one-line semantic per property and is what tooling reads for advisory typo warnings (see DESIGN.md D-46).

The table above is the portable vocabulary: every provider that supports a listed type must expose those properties under those names. It is authoritative but not closed — a provider MAY expose additional properties for a listed type as a platform-specific extension, mirroring the $app.* rule above. Portable Launchfiles should use only the standard set. A reference outside the standard set is therefore not invalid: tooling reports it as an advisory warning, never a validation error, because it may be either a typo or a deliberate provider extension. Unknown properties resolve to empty string.

Resource types are extensible -- any string is accepted. Unknown types have no predefined property vocabulary; their properties are platform-defined, and no warning is reported for them.