Capabilities in this build

This page is generated from GET {management}/projects/{project}/capabilities, the answer the dashboard and the schema assistant read. Each sentence below is the framework’s own, copied verbatim.

Honoured

• entities
• auth
• tenancy
• access
• formats

Declared but not run in this build

• dynamicEntities — no runtime entity can be created and the whole dynamic schema-registry driver is absent, so every governance limit declared here bounds nothing (planned)
• automation — no rule is ever evaluated, so no declared action runs — which looks exactly like a condition that never matched
• templates — a template referenced by an after-hook ‘email’ action is rendered, but one referenced only from an automation rule is not, because no rule is evaluated yet — and a ‘bodyFile’ is not read on either path
• webhooks — an endpoint an after-hook posts to is delivered to, but one referenced only from an automation rule never receives anything; and no delivery is signed — ‘secretRef’ is not read and no Standard Webhooks HMAC header is sent, so a receiver cannot yet verify the sender (7.1), nor is the payload projected per endpoint (#152)
• functions — no function is ever invoked, on any trigger or schedule it declares
• auth.providers — only local credentials exist in this build — a person signs in with an address and a password Alvo holds; google, microsoft, github, apple and oidc sign-in are planned (#36), so a declared provider other than local offers no way in
• entity.storage — an entity declared with ‘storage: dynamic’ is not created: this build has no dynamic schema-registry driver (planned, #41), so the entity gets no table, no Data API route and no records, and the apply drops it without refusing it
• entity.realtime — no change is published over a realtime channel, because this build has none (planned, #38) — whatever an entity’s ‘realtime’ says, and its default is true, nothing is sent and nothing can subscribe

Refused at apply

• field.validation — Field ‘validation’ is not evaluated yet, so a value the expression forbids is accepted — the field is not constrained at all. Fix: Remove ‘validation’. Enforce the rule in a before-hook once #22 lands, or express it with a facet the API does validate — ‘maxLength’, ‘precision’/‘scale’, enum ‘values’ or a ‘format’.
• field.default — Field ‘default’ is honoured as a literal, but not as a ‘$cel’ expression: a CEL default is evaluated against the caller’s context at insert time, which is the ‘computed’ machinery rather than a column default — so the value would be dropped and the field left null. Fix: Declare a literal default, which this build emits as a column DEFAULT, or remove ‘default’ and send the value explicitly on create (#113).
• entity.softDelete — Soft delete is not supported yet: a delete would remove the row outright and reads would not exclude it, which is irrecoverable data loss where the schema promises recoverability. Fix: Remove ‘softDelete’ or track the soft-delete implementation issue. A flag written as false is not a declaration and maps normally.
• rollup.where — A rollup’s ‘where’ filter is not evaluated yet: the aggregate is still maintained, but it aggregates every record of the child entity instead of the subset this filter declares — a stored number that is silently wrong rather than absent. Fix: Remove ‘where’ and aggregate every child record, or move the distinction into the model: a separate child entity, or a second rollup once filtered rollups land. A partial implementation is deliberately not offered — an aggregate over the wrong row set costs more than this refusal.
• trigger.event — A wildcard event subscription is not matched yet: no rule fires for it today, and on the build that does implement matching it would subscribe to every entity or every operation of every tenant at once — a cross-tenant fan-out nobody re-reads this descriptor to catch, because the event envelope carries no tenant for a subscription to be scoped by (#153). Fix: Name the entity and the operation exactly — ‘entity.orders.created’ rather than ‘entity.orders.*’ — and declare one rule per pair. Wildcards are refused rather than accepted-and-ignored because a descriptor outlives the build that applied it: accepted today, it becomes the fan-out above on the day matching lands, with nothing between it and delivery.
• JSONata — JSONata transformations are not evaluated yet: the action still runs, but with Alvo’s canonical event envelope as its body instead of the transformation declared here — a delivery that succeeded carrying data you did not declare, which is indistinguishable from a bug in the consumer. Fix: Use a ’{{…}}’ template instead (e.g. “{{new.title}}”), which this build does render, or remove the transformation and accept the canonical envelope. A partial JSONata implementation is deliberately not offered: silently producing a different payload for the part it does not implement costs more than this refusal. Tracked in #149.
• email.data — An ‘email’ action’s ‘data’ is not rendered: it is validated when the descriptor is applied and then read by nothing, so the mail goes out with the referenced template’s own subject and body and the values declared here are silently dropped — a message that was delivered without the data you declared, which is indistinguishable from a template bug. Fix: Move the values into the template’s ‘subject’/‘body’ as ’{{…}}’ placeholders over ‘new’/‘old’/‘event’/‘@user.id’, which this build does render, or remove ‘data’. A ‘data.*’ placeholder root is new surface and lands with the PR that reads it.
• bodyFile — A template’s ‘bodyFile’ is not read yet: nothing in this build resolves a path inside a descriptor bundle, so an after-hook rendering this template would send a message with an empty body rather than fail. Fix: Move the body inline into the template’s ‘body’ — it takes the same ’{{…}}’ placeholders — or stop referencing this template from an after-hook until bundle files are read.
• function — The ‘function’ action is declared in the schema but not implemented in this build, so this hook invokes nothing — no function declared under ‘functions’ runs, on this hook or on any trigger or schedule it declares elsewhere. Fix: Use a ‘webhook’ or ‘email’ action, which this build does run. Custom functions are planned and the schema freezes their shape ahead of the implementation.
• http.call — The ‘http.call’ action is declared in the schema but not implemented in this build, so this hook makes no request: the URL is never called, and ‘headersSecretRef’ is never read, so a receiver you believe is being notified is not. Fix: Declare the target under ‘webhooks.endpoints’ and use a ‘webhook’ action instead — that is the managed path, and it is the one this build delivers on.
• entity.update — The ‘entity.update’ action is declared in the schema but not implemented in this build, so this hook writes nothing — no record is written or patched on the target entity, and no event is emitted for the write that did not happen. Fix: Perform the follow-up write through the Data API for now. ‘entity.update’ lands with automation, where the causation chain it creates can be bounded.