Design decision: the http family — why the client stays `http`, and where server-shaped capability actually lives

Prompted by the reasonable instinct that http might better be http.client with an http.server sibling. Working through it against the grammar and the execution model, the answer is no to both spellings and yes to the underlying capability — recorded here so the reasoning survives.

Why not http.client

The dot is spoken for, and what it says is valuable. The DSL's plugin-key decision (landed with the dotted-key work) makes a dotted step key unambiguously a plugin reference: task names are validated dot-free, couldBeATaskName rejects dots, so slack.post: tells a reviewer "this line leaves the engine's code and enters code somebody installed" with no lookup required. http.client: as a builtin would break that disjointness for marginal explicitness — and the explicitness is marginal because a task is definitionally client-shaped: the admission test's fourth condition says a task is an effect, and an effect is something the workflow initiates. There is no other thing http: could mean in step position. If builtins ever genuinely need families, that is a deliberate grammar revision to the reserved-shape rule, not a rename to make one name longer.

Why not http.server as a task

ARCHITECTURE.md's interaction-shape table already answers this row: "server-streaming, long-lived → does not fit one activity → a listener producing signals into a waiting workflow." A server is not an effect a step performs — it is a standing capability that produces events — and a listening socket on a worker would also be wrong operationally (workers scale horizontally and terminate freely; nothing should route inbound traffic to one).

Where the real need lands, in two shapes

1. "A workflow reacts to inbound HTTP" is #96, the webhook bridge: the control plane listens (it is already the process with an HTTP surface, auth, and JWKS), verifies signatures first-class, and translates deliveries into triggers (start a run) or signals (feed a waiting one). That is http.server capability, placed where listening belongs.
2. "This run waits for one inbound callback" — an OAuth redirect, a payment confirmation, a partner's async reply — is wait_for_signal: plus a per-run callback URL the bridge mints (a signed, single-purpose URL that delivers to exactly this run's signal channel). The Flowfile spelling already exists; what #96 adds is the addressable inbound edge. This is the genuinely beautiful version of http.server: the workflow says what it awaits, and the platform owns the socket, the verification, and the routing.

The quality bar this holds

One rule a reader can carry: bare key = the engine's own vocabulary; dotted key = installed capability; inbound = triggers and signals, never steps. Every future "should X be a task" question gets the same three-way test, which is what keeps the language small enough to memorize while the platform underneath it grows.

Related: #96 (the webhook bridge this routes to — the per-run callback URL belongs on its design), #95 (plugins own the dots), docs/DSL.md's admission test and ARCHITECTURE.md's interaction-shape table (the two frames that decided this).

Read docs/DSL.md for the admission test and ARCHITECTURE.md for the interaction-shape table, then compare the decision with related issues #95 and #96. Done means the HTTP naming and inbound-capability decision is documented consistently, with implementation or follow-up scope left to the referenced design issue.