FountainImagePublicationKit.git · PLANS.md
FountainImagePublicationKit.git / PLANS.md
revision e7f9080e630508cf9e0119e7c136ae314541b152 · complete file
# Plans ## Phase 0/1 — public package and core contracts (2026-08-13) Goal: establish the standalone FCIS-Kit repository and dependency-light contracts before transport, server, or Reframe integration. Non-goals: iCloud/PhotoKit publication, local image authority, server deployment, OpenAI calls, image bytes in source, and Reframe UI changes. Acceptance: clean SwiftPM build, focused Codable/decision tests, cross-platform Foundation-compatible core, no private data fixtures, and README claims that clearly distinguish this tranche from later runtime capabilities. ## Phase 2 — typed client/server seam (2026-08-13) Goal: prove content-addressed intake, idempotency, status, and typed receipts without choosing production storage or server framework. Acceptance: the in-memory server and client share the same transport contract; duplicate intake returns the same receipt; a reused idempotency key with another content hash fails; status is recoverable by asset reference; no image bytes enter logs or repository fixtures. ## Phase 3 — durable host storage (2026-08-13) Goal: add a migratable content-addressed filesystem adapter and persist receipts/state independently of one server process. Acceptance: a second `ImageCloudServer` instance using the same explicitly configured root recovers the original intake receipt and status; writes are atomic and hash conflicts fail; the adapter remains behind `ImageCloudObjectStore`. ## Phase 4 — authenticated typed transport (2026-08-13) Goal: add a framework-neutral HTTP client/server seam without selecting a production server framework or exposing credentials to the image package. Acceptance: URLSession transport injects an opaque bearer token, the server handler rejects unauthenticated requests, typed intake routes to the existing server, errors are sanitized, and the transport remains replaceable by another Swift-supported deployment adapter. ## Phase 5 — authenticated reference rehydration (2026-08-13) Goal: let a client render an already accepted hosted asset after relaunch without introducing local image authority. `ImageCloudTransport.bytes(for:)` resolves bytes by the content-addressed asset reference. The filesystem and memory stores implement the same operation; the HTTP client/server expose it only behind the existing bearer boundary. The operation returns opaque bytes and never logs or projects them into Fountain. Reframe may use the bytes as a transient preview and must continue to persist only the `imagecloud://` reference. Acceptance: the same authenticated transport can intake, resolve, and verify bytes by hash; an unknown hash returns a typed not-found result; unauthenticated byte requests are rejected; and the released package remains buildable on its supported Swift platforms. ## Phase 6 — production Swift server adapter (2026-08-13) Goal: turn the framework-neutral HTTP handler into a deployable, portable Swift executable using the durable filesystem store and an explicit environment/SecretStore boundary. Acceptance: the executable has no framework dependency, requires an injected bearer token and explicit root, serves authenticated intake/status/bytes routes, keeps bytes out of logs, builds and tests on the development host, and is deployed only through a reviewed host adapter with a receipt and rollback path. The host unit is now part of the release boundary at `Deploy/fountain-image-cloud.service`. It does not contain a credential; the host injects `FOUNTAIN_IMAGE_CLOUD_TOKEN` from its secret-managed environment file.