Project structure and engine
The first version needed more than a landing page. It needed a real package, a CLI, tests, examples, contribution notes and a licence so someone could actually clone it and understand how it works.
foundation, demo and UI clarity issues completed
larger next steps left visible for contributors
GitHub Pages updates from the docs folder
The first version needed more than a landing page. It needed a real package, a CLI, tests, examples, contribution notes and a licence so someone could actually clone it and understand how it works.
The engine now reads messy process text and turns it into simple outputs: workflow steps, bottlenecks, owner groups and automation opportunities. The first version is rule-based on purpose, so contributors can inspect and improve it without needing a paid model.
The project needed to be visible quickly. The public demo lets someone paste or upload plain text and see the workflow analysis in the browser, with no account, no API key and no setup barrier.
The first interface was functional, but it felt too generic. The redesign moved towards a calmer dark editorial interface: clearer typography, useful visuals, softer red accents and pages that explain the project without overwhelming the reader.
The first redesign had stronger personality, but the headings were too large and the pages felt too intense. This phase reduced the visual weight, improved spacing, softened the typography and added more meaningful explanation to the Progression and Why pages.
The next major step is persistence. Instead of treating every upload as a one-off analysis, WorkflowForge should remember repeated pain points, recurring workflows and repeated decisions over time.