Record future HTTP boundary contract

docs/roadmap/implementation.md

@@ -15,6 +15,34 @@ Chosen defaults:
   app-level auth or in-app TLS in v1.
 - Trigger input: pipeline ID only.
 
+## Future HTTP Boundary Contract
+
+This roadmap records the target boundary for a later HTTP implementation. No
+HTTP server, routes, `serve` command, app-level authentication, or in-app TLS is
+implemented as part of this roadmap.
+
+Future trigger behavior:
+
+- The trigger endpoint accepts exactly one application input: pipeline ID.
+- The trigger is asynchronous. A successful admission starts a run and returns a
+  run ID rather than waiting for publication to finish.
+- Run status is exposed through a later status endpoint keyed by run ID. Status
+  records should expose the run ID, pipeline ID, current status, timestamps, and
+  completed report or error details when available.
+- Duplicate in-flight runs for the same pipeline ID map to `409 Conflict`.
+- Unknown pipeline IDs map to `404 Not Found`.
+
+Future runtime and security boundaries:
+
+- Request context guards admission. Once admitted, the actual run is tied to the
+  server or coordinator lifetime context, not to the client request lifetime.
+- The server defaults to private binding, such as `127.0.0.1`.
+- Operators should expose the server through a reverse proxy, private network,
+  or external mTLS when transport security or remote access is required.
+- The first HTTP implementation does not include bearer-token authentication,
+  in-app TLS configuration, or public-network exposure unless a later roadmap
+  explicitly changes that decision.
+
 ## Implementation Rules
 
 - Implement stages in order; each stage should be one prompt or commit unless