Direct web candidate

Ignite

Static site generation with a SwiftUI-like authoring surface.

Many worlds. One workstream.
renderer Static HTML maturity Candidate to build next maintainer External upstream campus Campus maintainer candidate mode Static frontend with Swift npm No npm manifest observed setup Syntax specimen only import Ignite

Shipping question

Can a SwiftUI-like static site builder own the promoted marketing site output?

This specimen is generated by the wrkstrm homepage model. It does not prove the upstream framework is installed in the campus until a setup receipt lands here.

npm evidence: 2026-05-18 recursive GitHub tarball scan found Package.swift and no npm manifest or lockfile paths.

Package: https://github.com/twostraws/Ignite

current provisional award

Where this competitor is strongest.

Provisional best all-around web lane

Ignite

Fast build and fast load path with Swift-authored static output.

Why
It is the cleanest current path for a public marketing site: direct web output, Swift source, and no npm manifest observed in the repository scan.
Prove next
Install in campus, render the wrkstrm page, record build time, static asset weight, Lighthouse-style load timing, and animation ceiling.
Sharp edge
Static output can look polished while hiding weak interaction depth; it has to prove rich motion, not only fast pages.
fast-build fast-load direct-web swift-first award

Homepage arc

candidate

Generate possible worlds

Agents and digikomas produce apps, documents, diagrams, releases, and decisions.

parallel

Compare timelines

Shipped, stalled, counterfactual, and next-best branches stay visible together.

proved

Select the executable path

Schemas, Swift packages, DocC, receipts, commits, and releases back the branch.

Adapter sketch

struct WrkstrmHome: StaticPage {
  var title = "wrkstrm"
  var body: some HTML {
    Text("Many worlds. One workstream.")
      .font(.title1)
  }
}