The factory closes its own loop: flowstate building, observing, and repairing flowstate

The capstone the issue graph has been converging on: flowstate's own engineering loop — build, deploy, observe, diagnose, fix, review, land — expressed as flowstate workflows. Deliberately meta, and deliberately not only meta: every piece is a real capability real teams need (deploy pipelines, incident loops, agentic repair, issue automation), and running them on ourselves is the acceptance test that keeps the claims honest. Nothing here is a new subsystem; it is the existing records composed to their conclusion, so this issue is mostly a wiring diagram with the missing pieces named.

The loop, stage by stage, against what exists

1. Build + test: git/github plugins (#170 shipped, #149 read tier), call: libraries (#168), flow test (#155). A CI-shaped workflow is already expressible the day #168 lands; self-hosting our own CI on flowstate is the dogfood milestone that pressure-tests the isolation ladder (#156) for real.
2. Deploy: the k8s plugin (tracked) for deploying workers/servers; the reflexive plugin (#174) for flow deploying flow — updating workflow definitions is flowstate.run against the new spec through the front door, policy-gated. "Inline edit in place" deliberately does NOT exist for running specs (invariant 10: a run means one thing forever); the honest primitive is new-spec-for-new-runs plus signals/cancel for in-flight ones — and that constraint is a feature of the factory, not a limitation: an edited-in-place workflow is an unreviewable one.
3. Observe: OTel is already first-class in the core (traces/metrics, the observability lab); the missing piece is the consuming direction — otel/grafana/loki query plugins so a workflow can ask "what does production look like" (read metrics, query logs) and act on the answer. That is the sensor input every reconciler-shaped repair loop (#166 shape 7) needs, and it belongs to the same plugin family as k8s: observe/act verbs, bounded, typed outputs for CEL.
4. Diagnose + fix: codex plugin (building now) and future claude-code plugin as peer — agents as steps, patches as values, loop: bounding attempts, humans arriving as wait_for_signal steps (#179 file 4 is this stage's acceptance target verbatim).
5. Issues + review: github plugin grows issue/PR verbs from the read-tier catalog on demand; Jira as a peer plugin is the forge-agnosticism proof for issue tracking exactly as gitlab is for git hosting — same discipline: provider-specific verbs in provider plugins, the workflow's shape unchanged when the tracker changes.
6. Feedback ingestion: the missing trigger type — webhook triggers, so CI results, review comments, and alerts start or signal runs natively (the triggers/extensibility thread finally has its concrete first customer). Webhook ingress is a policy surface: authenticated (HMAC/OIDC per source), fail-closed, payloads bounded and typed — designed once, reused by github/gitlab/jira/grafana alike.
7. Trust throughout: signing (#163) for what the factory commits; credential invisibility (#173) for what it holds; vetted binaries (#146) for what it runs; the fork-bomb bound (#174) for what it spawns. Self-review by agents is assistance forever — the merge gate stays a human or a human-set policy, because a factory that approves its own output has removed the property that made its output trustworthy.

Sequencing honesty

Nothing above jumps the queue. The order stays demand-driven: current wave → loop:/select → flow test → codex demo (#162) → webhook triggers (first new piece this issue adds) → observe-direction plugins → k8s → jira. Each stage lands as a real capability with a real example; the self-hosted loop assembles from them incrementally — first self-test, then self-observe, then self-repair-with-human-gate. The showcase (#179) files remain the acceptance targets; this issue adds the composition of them as the final one.

Related: #162, #163, #165, #166, #172, #173, #174, #177, #179, #149, #155, #156.

Start with the sequencing section and the existing records and plugins referenced in #155, #168, #174, and #179; file 4 of #179 is the stated acceptance target for the agent stage. Read the webhook-trigger requirements first, then trace how the observe, repair, issue, and review stages compose. Done requires real capabilities landing incrementally and the self-hosted loop exercising them with a human or policy merge gate.