Generate contract types, pin fixtures to spec, add build and ADRs
Some checks failed
ci / build (push) Failing after 1m6s
Some checks failed
ci / build (push) Failing after 1m6s
Completes FLUID-WP-0002. The record types in internal/contract are generated from schemas/ by a dependency-free generator; fixtures transcribed from the spec's worked examples validate against those schemas and round-trip through the generated types with DisallowUnknownFields, so a spec change that misses the schemas fails CI rather than drifting silently. Adds identifier prefix helpers, Makefile, GitHub Actions, and five ADRs recording the Go choice, out-of-process attachment, the wire contract as boundary, the evidence store, and revision identity. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014KmVxhJ35tCo7rE7UnLwWu Assistant: claude-code Assistant-Model: opus Assistant-Process: 1116572@bnt-lap001 Assistant-Session: 8ba9bb93-a72a-4883-b189-2499cce5c400
This commit is contained in:
parent
fbbf56df7a
commit
76912adef8
44 changed files with 4010 additions and 7 deletions
43
docs/adr/0002-out-of-process-attachment.md
Normal file
43
docs/adr/0002-out-of-process-attachment.md
Normal file
|
|
@ -0,0 +1,43 @@
|
|||
# ADR-0002 — Out-of-process attachment
|
||||
|
||||
**Status:** accepted · **Date:** 2026-09-04
|
||||
|
||||
## Context
|
||||
|
||||
A FLUID interface has to be able to wrap an existing API. The question is
|
||||
whether fluid-core is a library that API imports, or a process that sits in
|
||||
front of it.
|
||||
|
||||
Blueprint §42 already answers this implicitly: `gateway`, `revision-router` and
|
||||
`adapter-r41`/`adapter-r42` are separate deployments. That is process-level
|
||||
integration, not library-level.
|
||||
|
||||
## Decision
|
||||
|
||||
fluid-core attaches out of process. The gateway and router run in front of
|
||||
adapter processes reached over the network. The target API contributes no code,
|
||||
imports no library, and may be written in any stack.
|
||||
|
||||
An in-process SDK is explicitly deferred, not rejected. It would buy richer
|
||||
signal — call-sequence correlation and structured consumer feedback that a
|
||||
proxy cannot see from outside — at the cost of SDK versioning across languages.
|
||||
|
||||
## Rationale
|
||||
|
||||
Minimal conformance (`FluidAPIStandards.md` §36) requires a deterministic
|
||||
contract, revision identity, telemetry, declared intent, an evidence link,
|
||||
responsibility boundaries and deterministic security. Every one of those is
|
||||
observable from the proxy. Nothing in the conformance core needs to be inside
|
||||
the target process.
|
||||
|
||||
The language-agnostic promise is only credible if the framework never asks for
|
||||
an import. Making the SDK optional from the start, rather than retrofitting the
|
||||
proxy later, is what keeps that true.
|
||||
|
||||
## Consequences
|
||||
|
||||
- The revision descriptor carries `runtime.upstream`: the adapter's address.
|
||||
- Interaction topology (Blueprint §6.4) is reconstructed from correlation IDs
|
||||
observed at the gateway, not reported by the consumer.
|
||||
- Explicit feedback (`FluidAPIStandards.md` §15) arrives over the wire as its
|
||||
own endpoint rather than through an SDK call.
|
||||
Loading…
Add table
Add a link
Reference in a new issue