Establish fluid-core scaffold, intent, and phased workplans

Adds the repository structure, INTENT.md declaring the wire-contract
boundary, and seven workplans covering Blueprint Phases A-C plus the
fluid-telegram handover.

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

INTENT.md

@@ -0,0 +1,85 @@
+---
+project: fluid-core
+product: FLUID
+status: draft
+intent_version: 0.1.0
+date: 2026-09-04
+standard: FluidAPIStandards
+standard_version: 0.1.0
+---
+
+# INTENT.md — fluid-core
+
+> **FLUID envisions interfaces that learn when they should change, why, how to
+> test the change, and whether the result deserves to become part of their
+> evolving contract.**
+
+## 1. Repository intent
+
+`fluid-core` exists to make FLUID — *Flow Utilizing Interface Daimon* —
+executable. It is the reference framework for operating deterministic service
+interfaces inside a governed evolutionary control loop.
+
+The framework's defining commitment is stated in `spec/FluidAPIStandards.md` §3:
+
+> **Deterministic execution, adaptive evolution.**
+
+The production request path stays deterministic and auditable. Observation,
+analysis, hypothesis formation, experimentation and promotion happen *around*
+the interface, never inside the request path.
+
+## 2. What this repository owns
+
+- the deterministic data plane: gateway, revision resolver, revision router,
+  contract validation, backend connectors, response policy, telemetry emission;
+- the observation plane: telemetry ingest, redaction, cohorts, interaction
+  topology, pressure classification;
+- the evolution control plane through Blueprint Phase C: pressure registry,
+  hypothesis records, experiment control, fitness evaluation, promotion
+  decisions;
+- the evidence, artifact and intent stores;
+- the wire contract by which any interface, in any language, becomes FLUID.
+
+## 3. What this repository does not own
+
+- the interfaces themselves — those live in consumer repositories
+  (`fluid-telegram`, `fluid-x`, `fluid-substack`);
+- backend systems reached through connectors;
+- the Daimon's generative capability (Blueprint Phase D), deliberately deferred
+  until real telemetry exists for it to learn from.
+
+## 4. The boundary is a wire contract
+
+fluid-core is integrated **out of process**. A target API contributes no code,
+imports no library, and may be written in any stack. Integration happens through
+four artifacts:
+
+1. the revision descriptor (Blueprint §36);
+2. the routing policy (Blueprint §17);
+3. the telemetry envelope;
+4. the control APIs (Blueprint §44).
+
+Any change that leaks Go types across this boundary is a design failure. This
+constraint is what allows adapters, Daimons and future gateways to be written in
+whatever language suits them.
+
+## 5. Governing invariants
+
+The sixteen architectural invariants in `spec/ArchitectureBlueprint.md` §55 are
+constitutional for this repository. The four that most often get eroded and must
+be defended hardest:
+
+- **Runtime behavior remains deterministic.** No LLM in the mandatory request path.
+- **Evolution can stop without stopping the API.** Every control-plane component
+  must be killable in production with no runtime effect.
+- **AI-generated artifacts are untrusted until verified.** The deterministic
+  policy gate is not advisory.
+- **Backend authority does not leak into the interface Daimon.** Missing backend
+  capability is escalated as a structured requirement, never taken.
+
+## 6. Success
+
+`fluid-core` succeeds when an interface owner can put an existing API behind it
+without modifying that API, and then answer — from evidence, months later — the
+eleven auditability questions in `spec/FluidAPIStandards.md` §25 about any change
+the interface underwent.