FS.GG project split

The current recommendation is to stop treating the UI runtime and the governance system as one self-hosting platform. The rendering framework should be developed as a normal product repository using standard Spec Kit and narrow repo-owned checks. Governance and rule-engine experiments should move into a separate project where they can evolve without blocking rendering work.

Current direction

The earlier SpecFlow graph operating system proposal was internally consistent, but it pushed too much authority into one changing platform. It made rendering, template, release, product-contract, evidence, and governance workflow changes all part of the same system. That creates a dogfooding loop: the framework is developed on top of governance machinery that is itself still being designed.

The new direction is deliberately simpler:

• keep the rendering framework buildable, testable, releasable, and understandable without an experimental governance platform;
• use standard Spec Kit for feature workflow in each repository;
• keep only narrow deterministic checks in the rendering repository where they pay for themselves;
• move governance tooling into its own repository and make it earn adoption from the outside.

Documents

• Project split decision records why the monolithic graph operating system is being replaced by a split-repository strategy.
• Rendering project defines the runtime repository's scope, governance level, and release expectations.
• Design and controls defines where design-system primitives, themes, controls, and design-specific kits live.
• Governance project defines the separate tooling experiment and its adoption bar.
• Transition and boundaries explains how the old repository, package identities, docs, templates, and cross-repo contracts should be handled.
• Research notes preserves the durable research findings from the earlier report without keeping the old all-in-one plan as the active recommendation.
• Implementation plans coordinates the separate rendering-first and governance-later plans.
• Rendering implementation plan starts from a fresh standard Spec Kit repository and imports selected product slices.
• Governance implementation plan starts from its own fresh standard Spec Kit repository after rendering is usable.

Operating rule

The rendering project may be a customer of governance tooling, but it must not depend on that tooling to do ordinary product work. If governance tooling becomes heavy, brittle, or distracting, the rendering project should continue on standard Spec Kit and normal build/test/release practices.