[sinkog]

What

Documentation only: no module code, no WASM change, no Relay code. A brief for decisions (docs/design/decision-brief-target-and-binding.md, an index line in docs/design/README.md) that gathers, in one place and in dependency order, what the documents of this series left open. It decides nothing; every recommendation is the author's and the decision is the owner's.

The series: plan-digest.md (M4a, implemented), approval-and-execution-state.md with relay-requirements.md R6 to R10 (M4b, concept), destroy-invoke-binding.md, target-origin-and-path-safety.md (D5), realization-context.md (D5-2, Forms side in section 6).

Structure

Each decision carries a code for how it can be settled: [S] readable from the sources, [M] needs a measurement that was not made, [O] the owner's choice, [J] joint with another repository's contract (Forms library, engine, Relay). The three layers depend on each other in one direction: architecture decisions constrain contract decisions, contract decisions constrain the order of implementation.

• Layer A, architecture: A1 (D5-6) the realization context inside or outside the materialized object [J][O]; where a context is authored and stored; granularity; who issues and authenticates it; routing and decomposition; lifecycle; naming (D5-7). A1 constrains the rest.
• Layer B, contracts by boundary: the provider module (D-DI-1 to D-DI-5, D5-1, D5-4, D5-5, the poll alias retirement); the Relay (raise R6 to R10; the host-boundary property of R7); the Forms library and the engine only if A1 is "inside the object".
• Layer C, order of implementation: steps 1 to 3 (path-building hardening, the API version in the registry, the destroy and invoke digests) are module-only and do not depend on layer A, and none of them is the realization proof; step 4 (the realization context) depends on layer A and, depending on A1, on the Forms, engine and Relay contracts; step 5 is the Relay's.

D5-6 is marked as not a choice for this repository alone: it touches the object boundary and has to be decided together with the Forms, engine and Relay contracts.

One answer read from the sources

The review of the destroy/invoke document asked where an invoke's declared fields come from. The registry already carries it: each of the four action-role operations (AddVcnCidr, ChangeVcnCompartment, ChangeSubnetCompartment, ChangeInstanceCompartment) has an input schema with declared properties and additionalProperties: false (read from module/schemas/core/*.json); the other roles have none. The module's resourceContract does not load it today (it keeps method, path and role). Whether every future action operation will carry one was not checked.

Missing measurements (listed in the document)

What OCI accepts as the number form of an integer field; the request-target that actually goes out over the network (the real Relay, and the Go HTTP client's output for a URL with a query or fragment); dot segments, an encoded dot segment and a double slash; idempotency tokens; the fields of a real Work Request and its OCID type segment; a run of the rewritten manual harness against real OCI.

Not in this PR

No decision, no contract change, no implementation, no claim that any step is implemented. No module.wasm rebuild or signature, no Relay change, no production-integration claim. The module.wasm release, the production integration, the asynchronous create cases B and C and phase 3 of #37 stay on hold, unchanged. No merge without explicit owner GO.

🤖 Generated with Claude Code