Sync Repo-docs-INSTITUTIONAL-CONTEXT-CONTRACT from project files
@@ -1,4 +1,4 @@
|
|||||||
<!-- codex-wiki-sync:42e1b7d33bbc9168ac2c37cf -->
|
<!-- codex-wiki-sync:c61d4e854c9fddd8b2222b97 -->
|
||||||
|
|
||||||
> Mirrored from `/mnt/DATA/git/govoplan-core/docs/INSTITUTIONAL_CONTEXT_CONTRACT.md`.
|
> Mirrored from `/mnt/DATA/git/govoplan-core/docs/INSTITUTIONAL_CONTEXT_CONTRACT.md`.
|
||||||
> Origin: `repository`.
|
> Origin: `repository`.
|
||||||
@@ -104,6 +104,39 @@ optional `services.availability` evaluator returns policy-scoped boolean
|
|||||||
assessments, reason codes, and evidence. Unknown consequential requirements
|
assessments, reason codes, and evidence. Unknown consequential requirements
|
||||||
fail closed; a reference itself never grants access.
|
fail closed; a reference itself never grants access.
|
||||||
|
|
||||||
|
## Service Launch
|
||||||
|
|
||||||
|
`ServiceLaunchRequest` and `ServiceLaunchResult` define the owner-neutral
|
||||||
|
boundary between Portal entry and a case, form, or workflow runtime effect.
|
||||||
|
The request carries the exact published Service definition, exact selected
|
||||||
|
binding, tenant, acting identity, timezone-aware request time, bounded
|
||||||
|
parameters, and idempotency key. The result must retain that exact Service and
|
||||||
|
binding, a same-tenant target reference, optional same-tenant evidence, and
|
||||||
|
only a relative or credential-free HTTP(S) destination.
|
||||||
|
|
||||||
|
`service_launch_capability(kind)` maps bindings to owner capabilities:
|
||||||
|
|
||||||
|
- `case` -> `cases.service_launcher`
|
||||||
|
- `form` -> `forms_runtime.service_launcher`
|
||||||
|
- `workflow` -> `workflow_engine.service_launcher`
|
||||||
|
|
||||||
|
`FormDefinition`, `FormFieldDefinition`, and `forms.definitions` provide the
|
||||||
|
owner-neutral exact-schema boundary used by Forms Runtime. Definitions carry an
|
||||||
|
exact tenant/revision, field types/options/constraints/defaults, publication,
|
||||||
|
draft, attachment, signature, policy, and handoff requirements. Forms owns
|
||||||
|
those immutable definitions; Forms Runtime persists instances and validation
|
||||||
|
evidence. A form Service binding uses `<form-id>/<revision>` and the launcher
|
||||||
|
rejects missing, superseded, unpublished, cross-tenant, or invalid definitions.
|
||||||
|
|
||||||
|
Portal may discover and invoke those capabilities but cannot write owner
|
||||||
|
tables. The owner must revalidate its definition/binding and current
|
||||||
|
authorization, produce its normal audit/event state, and make replay after an
|
||||||
|
ambiguous response safe. If the capability is absent, the service is
|
||||||
|
explainably unavailable. URL-only entries pass through the same launch-time
|
||||||
|
availability check and destination validation. Forms Runtime now supplies the
|
||||||
|
definition-aware form launcher when both Forms and Forms Runtime are active;
|
||||||
|
otherwise Portal continues to fail closed.
|
||||||
|
|
||||||
## Propagation
|
## Propagation
|
||||||
|
|
||||||
`PlatformEvent`, `ActionExecutionRequest`, and `AuditEvent` can carry the
|
`PlatformEvent`, `ActionExecutionRequest`, and `AuditEvent` can carry the
|
||||||
|
|||||||
Reference in New Issue
Block a user