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

workplans/FC-WP-0001-foundations-and-wire-contract.md

@@ -0,0 +1,109 @@
+---
+id: FC-WP-0001
+type: workplan
+title: "FLUID foundations and the wire contract"
+domain: infotech
+repo: fluid-core
+status: active
+owner: worsch
+topic_slug: fluid
+created: "2026-09-04"
+updated: "2026-09-04"
+planning_priority: high
+planning_order: 1
+related_repos:
+  - fluid-telegram
+  - fluid-x
+  - fluid-substack
+---
+
+# FC-WP-0001 - Foundations and the wire contract
+
+Establish the boundary before any code depends on it. fluid-core integrates
+out of process, so its contract is a set of on-the-wire artifacts, not a Go
+API. Everything downstream assumes these schemas are stable.
+
+Reference: `spec/FluidHypothesisRevisionSchema.md`, `spec/ArchitectureBlueprint.md`
+§36 (revision descriptor), §17 (routing policy), §44 (control APIs).
+
+## T01 - Repository scaffold and INTENT
+
+```task
+id: FC-WP-0001-T01
+status: done
+priority: high
+```
+
+Go module, directory tree per the plan, `INTENT.md` declaring the wire-contract
+boundary and the four invariants this repo defends hardest.
+
+## T02 - Record schemas
+
+```task
+id: FC-WP-0001-T02
+status: todo
+priority: high
+```
+
+JSON Schema for `fluid_pressure`, `fluid_hypothesis`, `fluid_revision`,
+`fluid_experiment`, `fluid_event`, `fluid_backend_requirement` and the feedback
+record. Transcribe field names faithfully from the schema document — they are
+the interop surface, per its §1.
+
+## T03 - Descriptor and policy schemas
+
+```task
+id: FC-WP-0001-T03
+status: todo
+priority: high
+```
+
+JSON Schema for the revision descriptor (Blueprint §36) and the routing policy
+(Blueprint §17). These two are what the gateway consumes at runtime and must be
+readable without any fluid-core code.
+
+## T04 - Type generation
+
+```task
+id: FC-WP-0001-T04
+status: todo
+priority: high
+```
+
+Generate Go types into `internal/contract/` from `schemas/`. Hand-written record
+types are prohibited — drift between spec and implementation must fail CI.
+
+## T05 - Spec examples as fixtures
+
+```task
+id: FC-WP-0001-T05
+status: todo
+priority: high
+```
+
+Extract the YAML examples embedded in the spec documents and validate them
+against the schemas in CI. If the spec changes and the schema does not, the
+build breaks.
+
+## T06 - Build, CI and identifier conventions
+
+```task
+id: FC-WP-0001-T06
+status: todo
+priority: medium
+```
+
+Makefile, GitHub Actions (build, vet, test, schema validation), and the
+identifier prefix helpers from schema doc §16: `H- R- E- P- BR- D- EV- F- C-`.
+
+## T07 - Architecture decision records
+
+```task
+id: FC-WP-0001-T07
+status: todo
+priority: medium
+```
+
+ADRs for: Go as the implementation language; out-of-process attachment; the
+wire contract as boundary; SQLite to Postgres evidence store; and the revision
+identity scheme, which Blueprint §54 leaves deliberately open.

workplans/FC-WP-0002-deterministic-data-plane.md

@@ -0,0 +1,135 @@
+---
+id: FC-WP-0002
+type: workplan
+title: "Deterministic data plane (Blueprint Phase A)"
+domain: infotech
+repo: fluid-core
+status: active
+owner: worsch
+topic_slug: fluid
+created: "2026-09-04"
+updated: "2026-09-04"
+planning_priority: high
+planning_order: 2
+depends_on:
+  - FC-WP-0001
+---
+
+# FC-WP-0002 - Deterministic data plane
+
+The production request path. No AI, no analysis, no dependency on the control
+plane. Blueprint §5 and §34: the gateway must keep serving when everything
+above it is dead.
+
+## T01 - Edge gateway
+
+```task
+id: FC-WP-0002-T01
+status: todo
+priority: high
+```
+
+Transport termination, correlation IDs, coarse rate limiting, request size and
+shape limits. Blueprint §5.1 — the gateway must not invent interface semantics.
+
+## T02 - Revision resolver
+
+```task
+id: FC-WP-0002-T02
+status: todo
+priority: high
+```
+
+The §5.2 precedence chain: explicit revision, bound client contract, experiment
+assignment, stable default. Every resolution records its reason; resolution
+without an auditable reason is a defect.
+
+## T03 - Revision router
+
+```task
+id: FC-WP-0002-T03
+status: todo
+priority: high
+```
+
+Map a resolved revision to an adapter upstream. Reject unpublished, failed,
+ineligible and retired revisions (§5.3). Allocation rules are deterministic and
+read from routing policy the router does not author.
+
+## T04 - Contract validator
+
+```task
+id: FC-WP-0002-T04
+status: todo
+priority: high
+```
+
+OpenAPI 3.1 request and response validation (§5.4). The contract digest is part
+of the revision artifact and is content-addressed.
+
+## T05 - Backend connector layer
+
+```task
+id: FC-WP-0002-T05
+status: todo
+priority: high
+```
+
+Timeout, retry, circuit breaker, error mapping, tenant propagation (§5.6). The
+adapter is an upstream process reached over HTTP — this is where the
+language-agnostic promise is kept.
+
+## T06 - Response policy
+
+```task
+id: FC-WP-0002-T06
+status: todo
+priority: medium
+```
+
+Structured errors carrying a FLUID correlation reference, leaking no backend
+detail (§5.7).
+
+## T07 - Telemetry emitter
+
+```task
+id: FC-WP-0002-T07
+status: todo
+priority: high
+```
+
+Fire-and-forget emission. Blueprint §34.2 is a hard invariant: telemetry
+backpressure must never block or slow a request. Test it under a stalled sink.
+
+## T08 - Evidence store
+
+```task
+id: FC-WP-0002-T08
+status: todo
+priority: high
+```
+
+Append-only event storage, SQLite for development and Postgres-ready. Mutable
+summaries exist only as derived views (§26).
+
+## T09 - Intent store
+
+```task
+id: FC-WP-0002-T09
+status: todo
+priority: high
+```
+
+Bind every revision to an `InterfaceEvolutionIntent` version (§27), so audit can
+later answer whether a change was valid under the intent that existed when it
+was made.
+
+## T10 - Operator CLI, first commands
+
+```task
+id: FC-WP-0002-T10
+status: todo
+priority: medium
+```
+
+`fluid revision create|publish|list`, `fluid intent show`, `fluid events tail`.

workplans/FC-WP-0003-publication-and-control-apis.md

@@ -0,0 +1,93 @@
+---
+id: FC-WP-0003
+type: workplan
+title: "Revision publication pipeline and control APIs"
+domain: infotech
+repo: fluid-core
+status: active
+owner: worsch
+topic_slug: fluid
+created: "2026-09-04"
+updated: "2026-09-04"
+planning_priority: high
+planning_order: 3
+depends_on:
+  - FC-WP-0002
+---
+
+# FC-WP-0003 - Publication and control APIs
+
+Nothing reaches the router unsigned. The deterministic policy gate is built now,
+before anything can generate candidates, so a future Daimon has nowhere to
+bypass.
+
+## T01 - Publication pipeline
+
+```task
+id: FC-WP-0003-T01
+status: todo
+priority: high
+```
+
+Blueprint §35: SOURCE, BUILD, CONTRACT CHECK, TEST, SECURITY CHECK, POLICY
+CHECK, SIGN, PUBLISH, ROUTE. Each stage emits an audit event.
+
+## T02 - Descriptor signing and verification
+
+```task
+id: FC-WP-0003-T02
+status: todo
+priority: high
+```
+
+The router accepts only signed or otherwise authenticated published revision
+descriptors (§35). An unsigned descriptor must be refused, and that refusal
+tested.
+
+## T03 - Revision API
+
+```task
+id: FC-WP-0003-T03
+status: todo
+priority: high
+```
+
+Blueprint §44.1: create, verify, publish, set state, query lineage.
+
+## T04 - Intent API
+
+```task
+id: FC-WP-0003-T04
+status: todo
+priority: medium
+```
+
+Blueprint §44.5: read active intent, read historical intent, validate a
+candidate against intent, propose an amendment. Amendment stays separately
+governed — the API records a proposal, it does not enact one.
+
+## T05 - Deterministic policy gate
+
+```task
+id: FC-WP-0003-T05
+status: todo
+priority: high
+```
+
+Blueprint §28.2. Allowed adaptation class, permitted operational mode,
+complexity threshold, security status, test status, compatibility status,
+traffic-allocation maximum, budget, approval requirement. This gate is the
+architectural boundary that stops agentic reasoning from becoming security
+policy.
+
+## T06 - Trust model in the type system
+
+```task
+id: FC-WP-0003-T06
+status: todo
+priority: medium
+```
+
+Blueprint §47 made mechanical: generated artifacts are an untrusted candidate
+type until verification produces a signed revision. The compiler should make the
+unsafe path awkward to write.

workplans/FC-WP-0004-fluid-insight.md

@@ -0,0 +1,122 @@
+---
+id: FC-WP-0004
+type: workplan
+title: "FLUID Insight - observation plane (Blueprint Phase B)"
+domain: infotech
+repo: fluid-core
+status: active
+owner: worsch
+topic_slug: fluid
+created: "2026-09-04"
+updated: "2026-09-04"
+planning_priority: high
+planning_order: 4
+depends_on:
+  - FC-WP-0003
+---
+
+# FC-WP-0004 - FLUID Insight
+
+Turn traffic into evidence. Deterministic heuristics only at this stage — no
+model inference anywhere in this workplan.
+
+## T01 - Telemetry ingest and normalizer
+
+```task
+id: FC-WP-0004-T01
+status: todo
+priority: high
+```
+
+Request, error, sequence, adoption and explicit-feedback events into one
+normalized interaction event (Blueprint §6.1).
+
+## T02 - Redaction and privacy filter
+
+```task
+id: FC-WP-0004-T02
+status: todo
+priority: high
+```
+
+Field exclusion, pseudonymization, tenant isolation, retention, cohort minimum
+sizes (§6.2). Raw payload capture is off by default and must stay that way —
+FLUID learns about the interface, not about people.
+
+## T03 - Cohort engine
+
+```task
+id: FC-WP-0004-T03
+status: todo
+priority: medium
+```
+
+Coarse, stable, comparable over time (§6.3). Resist granularity: cohorts should
+not be more specific than the analysis requires.
+
+## T04 - Interaction topology analyzer
+
+```task
+id: FC-WP-0004-T04
+status: todo
+priority: high
+```
+
+Recurring call-sequence detection (§6.4) — the signal that makes FLUID more than
+error counting.
+
+## T05 - Pressure classifier
+
+```task
+id: FC-WP-0004-T05
+status: todo
+priority: high
+```
+
+The ten pressure classes from §6.5. Classification retains evidence references
+in every case.
+
+## T06 - Pressure registry
+
+```task
+id: FC-WP-0004-T06
+status: todo
+priority: high
+```
+
+Deduplication, aggregation, frequency, severity, confidence, and the §9
+lifecycle. Pressure may remain unresolved on purpose — not every mismatch
+deserves adaptation.
+
+## T07 - Fitness engine
+
+```task
+id: FC-WP-0004-T07
+status: todo
+priority: high
+```
+
+Blueprint §18: primary metrics, guardrails, secondary and learning metrics kept
+distinct. Baseline and measurement window are retained, never recomputed.
+
+## T08 - Explicit feedback collector
+
+```task
+id: FC-WP-0004-T08
+status: todo
+priority: medium
+```
+
+API Standards §15. Accepted over the wire, stored as evidence, and never
+treated as authority to change anything.
+
+## T09 - CLI and pressure API
+
+```task
+id: FC-WP-0004-T09
+status: todo
+priority: medium
+```
+
+Blueprint §44.2 plus `fluid pressure list|show|dismiss`, `fluid cohort list`,
+`fluid fitness compare`.

workplans/FC-WP-0005-fluid-science.md

@@ -0,0 +1,125 @@
+---
+id: FC-WP-0005
+type: workplan
+title: "FLUID Science - the adaptation loop closes (Blueprint Phase C)"
+domain: infotech
+repo: fluid-core
+status: active
+owner: worsch
+topic_slug: fluid
+created: "2026-09-04"
+updated: "2026-09-04"
+planning_priority: high
+planning_order: 5
+depends_on:
+  - FC-WP-0004
+---
+
+# FC-WP-0005 - FLUID Science
+
+Hypotheses, experiments, fitness and promotion. Entirely human-driven — the
+Daimon is deliberately absent. Blueprint §50 says the success criterion is
+proving this loop works cleanly and safely, not autonomous coding.
+
+## T01 - Hypothesis records and lifecycle
+
+```task
+id: FC-WP-0005-T01
+status: todo
+priority: high
+```
+
+Schema doc §2: DRAFT, READY, PRIORITIZED, DESIGNING, EXPERIMENTING, EVALUATING,
+then ACCEPTED, REJECTED, SUPERSEDED or DEFERRED. Keep observation, explanation,
+prediction, intervention and result separate — schema doc §18 warns that
+collapsing them into one narrative destroys criticism and auditability.
+
+## T02 - Competition groups
+
+```task
+id: FC-WP-0005-T02
+status: todo
+priority: medium
+```
+
+Rival explanations of one pressure coexist (schema doc §6). Preserving
+uncertainty is a feature.
+
+## T03 - Hypothesis API
+
+```task
+id: FC-WP-0005-T03
+status: todo
+priority: medium
+```
+
+Blueprint §44.3: create, compare, prioritize, attach candidate, record outcome.
+
+## T04 - Experiment controller
+
+```task
+id: FC-WP-0005-T04
+status: todo
+priority: high
+```
+
+Blueprint §16. Declares hypothesis, control, candidate, cohorts, allocation,
+metrics, guardrails, start and stop conditions, maximum duration. Per §17 it
+must not touch traffic directly: it writes routing policy the router consumes.
+Experiments are interruptible.
+
+## T05 - Experiment API
+
+```task
+id: FC-WP-0005-T05
+status: todo
+priority: medium
+```
+
+Blueprint §44.4: create, start, change bounded allocation, stop, record metrics,
+finalize.
+
+## T06 - Fitness evaluation against hypotheses
+
+```task
+id: FC-WP-0005-T06
+status: todo
+priority: high
+```
+
+Wire the fitness engine to experiments. Success criteria may not be changed
+after results are visible without recording the amendment (§18).
+
+## T07 - Promotion controller
+
+```task
+id: FC-WP-0005-T07
+status: todo
+priority: high
+```
+
+PROMOTE, EXPAND_EXPERIMENT, RETAIN_AS_OPTION, MODIFY, REVERT, ABANDON, DEFER
+recorded as decisions with an authorizing actor (§19). Human authority only.
+
+## T08 - Append-only event log
+
+```task
+id: FC-WP-0005-T08
+status: todo
+priority: high
+```
+
+Every transition above as a `fluid_event` (schema doc §15). FLUID evolution is
+itself a system behavior that must remain reconstructable.
+
+## T09 - Audit trace command
+
+```task
+id: FC-WP-0005-T09
+status: todo
+priority: high
+```
+
+`fluid audit trace <revision>` reconstructs pressure, hypothesis, revision,
+experiment, fitness and decision, answering all eleven questions in API
+Standards §25.

workplans/FC-WP-0006-conformance-and-self-validation.md

@@ -0,0 +1,90 @@
+---
+id: FC-WP-0006
+type: workplan
+title: "Conformance suite and self-validation"
+domain: infotech
+repo: fluid-core
+status: active
+owner: worsch
+topic_slug: fluid
+created: "2026-09-04"
+updated: "2026-09-04"
+planning_priority: high
+planning_order: 6
+depends_on:
+  - FC-WP-0005
+---
+
+# FC-WP-0006 - Conformance and self-validation
+
+Prove the loop mechanically before a real workload depends on it. Everything
+here runs in CI with no human steps and no external services.
+
+## T01 - Echo interface fixture
+
+```task
+id: FC-WP-0006-T01
+status: todo
+priority: high
+```
+
+`examples/echo-interface` — two revisions, R-1 deliberately inefficient
+(list then filter), R-2 the convenience form. This is the smallest honest
+reproduction of the Blueprint §33 worked example.
+
+## T02 - Minimal conformance assertions
+
+```task
+id: FC-WP-0006-T02
+status: todo
+priority: high
+```
+
+The seven requirements of API Standards §36, asserted as tests rather than
+claimed in a README.
+
+## T03 - Architectural invariant checks
+
+```task
+id: FC-WP-0006-T03
+status: todo
+priority: high
+```
+
+The mechanically checkable subset of Blueprint §55. Invariant 2 (evolution can
+stop without stopping the API) and invariant 9 (AI-generated artifacts untrusted
+until verified) matter most and get dedicated tests.
+
+## T04 - Failure containment matrix
+
+```task
+id: FC-WP-0006-T04
+status: todo
+priority: high
+```
+
+Blueprint §34. Kill the control plane, the evidence store and the telemetry
+pipeline in turn; assert the data plane keeps serving from cached published
+configuration each time.
+
+## T05 - End-to-end loop in CI
+
+```task
+id: FC-WP-0006-T05
+status: todo
+priority: high
+```
+
+The full §50 vertical slice automated: two revisions, a 90/10 experiment,
+fitness comparison, promotion, complete audit trail.
+
+## T06 - Integration guide
+
+```task
+id: FC-WP-0006-T06
+status: todo
+priority: medium
+```
+
+`docs/integration-guide.md` — how to put an existing API of any stack behind
+fluid-core without modifying it.

workplans/FC-WP-0007-fluid-telegram-handover.md

@@ -0,0 +1,142 @@
+---
+id: FC-WP-0007
+type: workplan
+title: "Handover: HelixForge Telegram identity and hall-of-helix channel"
+domain: infotech
+repo: fluid-core
+status: active
+owner: worsch
+topic_slug: fluid
+created: "2026-09-04"
+updated: "2026-09-04"
+planning_priority: high
+planning_order: 7
+depends_on:
+  - FC-WP-0006
+related_repos:
+  - fluid-telegram
+  - helix-forge
+  - hall-of-helix
+---
+
+# FC-WP-0007 - Handover to fluid-telegram
+
+The point of the whole sequence. Establish a Telegram identity for HelixForge
+and a channel publishing hall-of-helix entries, as the first real FLUID
+interface. Outbound-first: agents and publishing jobs are the consumers,
+Telegram is the backend.
+
+Deliverables land in `docs/handover/fluid-telegram.md` here and as `FT-WP-0001`
+in the `fluid-telegram` repository.
+
+## T01 - Interface evolution intent
+
+```task
+id: FC-WP-0007-T01
+status: todo
+priority: high
+```
+
+Fill the template for `helix-forge-telegram-publishing`. Parent intent is
+`helix-forge/INTENT.md`. Initial authority mode FLUID-2 (advisory): the Daimon
+may propose and never generate or promote. Out of scope for now: inbound
+commands, payments, Mini Apps, moderation. Non-authority: never create Telegram
+entities, change membership, or touch credentials.
+
+## T02 - Bot identity
+
+```task
+id: FC-WP-0007-T02
+status: todo
+priority: high
+```
+
+**Human step.** Register the HelixForge bot via BotFather (Canon BOT-01). Store
+the token in OpenBao per Canon SEC-04, consistent with HF-WP-0002. The token
+never enters the repository; the adapter receives only that credential, per
+Blueprint §28.1 runtime identity.
+
+## T03 - Channels
+
+```task
+id: FC-WP-0007-T03
+status: todo
+priority: high
+```
+
+**Human step.** Create a private test channel first, then the public
+hall-of-helix channel (Canon PUB-01). Bot is administrator with post rights
+only. All verification runs against the private channel before anything is
+published publicly.
+
+## T04 - Revision R-1 contract
+
+```task
+id: FC-WP-0007-T04
+status: todo
+priority: high
+```
+
+`POST /v1/hall-entries` (idempotent on entry id) and
+`GET /v1/hall-entries/{id}`. OpenAPI plus signed revision descriptor.
+
+## T05 - Telegram adapter and connector contract
+
+```task
+id: FC-WP-0007-T05
+status: todo
+priority: high
+```
+
+Map a `hall-of-helix/entries/*.md` file to a Telegram post. The adapter is a
+separate process and may be written in whatever suits the platform. Declare the
+connector capability contract: identity, auth, timeouts, retry, rate limits,
+error mapping.
+
+## T06 - Cohorts, telemetry and redaction
+
+```task
+id: FC-WP-0007-T06
+status: todo
+priority: high
+```
+
+Subscriber classes and agent consumers as cohorts. Redaction rules that keep
+Telegram user identity (Canon ID-01) out of the evidence store entirely.
+
+## T07 - First competing hypotheses
+
+```task
+id: FC-WP-0007-T07
+status: todo
+priority: high
+```
+
+Telegram's 4096-character message limit against long-form entries is the first
+genuine pressure. Two presentation adaptations compete: H-A, teaser plus link
+back to the hall; H-B, full entry serialized as a multi-part rich post
+(Canon PUB-02/MED-02). Blueprint §37 argues presentation is the safest and
+highest-value place to start.
+
+## T08 - Live experiment and audit
+
+```task
+id: FC-WP-0007-T08
+status: todo
+priority: high
+```
+
+R-2 and R-3 implement H-A and H-B. Run the experiment on real subscriber
+traffic, measure read-through and reaction, and confirm `fluid audit trace`
+reconstructs the whole chain. This is the §50 slice on a real workload.
+
+## T09 - Runbook and handover package
+
+```task
+id: FC-WP-0007-T09
+status: todo
+priority: medium
+```
+
+Token rotation, channel admin recovery, rollback to R-1, and the assembled
+handover document.