founding

Post Founding Turn

Answer the pending question (or kick) and stream the resulting segment.

An empty body is the idempotent kick: it starts the first segment after naming, retries a segment that died (deploy, crash), and retries a failed founding. That single entry point is why the Retry button, the frontend watchdog and the heartbeat backstop are all the same code path.

The segment runs as a task that a client disconnect cannot cancel; this response is only a view of it.

The claim is taken before anything else happens, for two reasons that are easy to get backwards. It has to precede the STATUS CODE, because a 409 delivered as an error event inside a 200 is not a 409: the client's re-attach branch never fires and the connection sits open. And it has to precede the APPEND, because appending outside the claim writes at the seq a running segment is about to use — the loser leaves the transcript ending assistant(tool_use) -> user(text) with no tool_result, which is not a valid conversation and 400s on every replay from then on. That one is not recoverable except by starting over.

post/founding/{founding_id}/turn

Path parameters

founding_idstring uuid required

Headers

X-Posthog-Session-Idstring nullable
X-Client-Mobilestring nullable

Request body

question_idstring nullable
selected_option_idsstring[] nullable
textstring nullable
skipboolean
had_discarded_textboolean
is_section_editboolean
triggerstring nullable

Response

Successful Response

{"stackTrail":"paths:/founding/{founding_id}/turn:post:responses:200:content:application/json:schema","oasType":"schema","type":"unknown"}

Changes

No recorded changes to this endpoint across all 1 revision of this API.