| title | FS.GG project split |
|---|---|
| category | FS.GG |
| categoryindex | 6 |
| index | 1 |
| description | Index for the FS.GG split-repository direction and the documents that replace the previous monolithic SpecFlow plan. |
Current development work is indexed by the Unified Roadmap v3. BAR, SC2 and FourD use the games roadmap. The unified v2 archive retains historical evidence.
Building an app with FS-GG rather than developing FS-GG itself? This page and the documents below are the cross-repo decision record for people developing the platform. If you just want to use FS-GG, start at the consumer guide instead.
Two kinds of document live here. The Living reference below (architecture map, ADRs, registry projection, coordination protocol, build config, reports) is kept current and is the instruction of record. The Documents further down are the 2026-06 planning corpus — the historical proposal for the split, written in future tense about work that has since shipped. Read them as a record of intent, not as current instruction; each now carries a status banner pointing at what actually shipped.
For the wider development portfolio, start at the development master: it connects the current designs, their dependencies and open decisions, with a complete documentation inventory.
The Fable SC2 client and custom WASM design proposes a browser tactical client, native SC2 gateway, mouse/keyboard control and a staged product roadmap. It is a proposal; implementation and deployment are separate work.
The analogous Beyond All Reason research, design and roadmap builds on the existing HighBar/FSBar repositories and explicitly targets the FS.GG Fable game template. It also remains a proposal, with existing source, synthetic evidence and required live qualification distinguished.
The Unity native shim and full Fable replacement-client design researches reusable engine integration, title admission, browser rendering and custom WASM control. Its seven-milestone roadmap separates a playable reference, external-title qualification and published Fable game adoption.
Operators preparing the protected GitHub Substrate v2 ledger boundary should follow the timestamped
GS2-08.2 ledger-protection installation manual.
It fixes the two-App trust boundary, custody, rulesets, environment, initialization, monitoring, and acceptance
procedure while preserving the separately authorized ApplyAuthorized=false safety boundary.
The 4D grid tactics algorithm design and roadmap proposes an original squad tactics foundation with four spatial coordinates, including movement, visibility, cover, combat, AI and readable slice views. Six milestones lead from exact grid queries to a validated playable encounter.
FS.GG is preparing a coordinated replacement of its GitHub coordination substrate. The work builds a new
independently qualified FS.GG.Coordination component, performs one fail-closed fleet cutover, and retires
the current v1 production machinery after verification. Follow the living
GitHub Substrate v2 fleet-cutover roadmap for the complete sequence,
qualification gates, current execution anchors, and definition of live/retired. The existing system remains
authoritative until the roadmap reaches its protected OpenV2 transition.
Kept current — the system as built, and the machinery that keeps it coherent.
- Architecture — the newcomer's map of the whole system: the seven-component split, the one-way dependency rule, the contract registry, the shared F# house style, and how the repositories compose. Start here.
- Architecture Decision Records — cross-repo decisions (ADR-0001…), each with status and supersession history.
- Registry compatibility projection — the human-readable
projection of
registry/dependencies.yml: every cross-repo contract, its coherence flag, and the evidence behind it. - Cross-repo coordination — the coordination protocol, the contract-coherence gate, the skill-union assertion, and the auto-update fabric.
- Build config — the org-shared .NET build configuration (ADR-0006) and how consumer repos restore it.
- Reports — dated review/analysis artifacts, including the
2026-07-02 code-quality & architecture review,
the 2026-06-30 project-management topologies analysis,
the 2026-07-12 up-front design practices report
(what feeds the ADR pipeline, and the stale
Blocked bypremise in ADR-0034), the 2026-07-12 issue-throughput & recurring-error-loops audit (which of the day's 127 closures were real progress, and the five loops that regenerate), and the 2026-07-20 cross-repo coordination overhead root-cause (why ~76% of the day's commits were coordination bookkeeping, and the one anti-pattern under the five friction engines). - Xantham and Fable-bindings evaluation — measured generator results and integration options for the existing bindings template.
The current recommendation is to stop treating the UI runtime, lifecycle workflow, and governance system as one self-hosting platform. The rendering framework should be developed as a normal component repository using standard Spec Kit and narrow repo-owned checks. Governance rule-engine tooling and SDD lifecycle tooling should live in separate projects where they can evolve without blocking rendering work or each other.
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;
- keep governance rule/evidence/route tooling in its own repository and make it earn adoption from the outside;
- keep SDD lifecycle tooling in its own repository so project workflow can evolve without becoming the governance rule engine.
Historical planning corpus (2026-06). The documents in this section proposed the split and are preserved as a record of intent; the work they describe in future tense has since shipped. For the system as built and the machinery that keeps it coherent, see the Living reference above.
- Architecture is the newcomer's map of the whole system — the four-component split, the one-way dependency rule, the contract registry, the shared F# house style, and how the repositories compose — with links to every source. Start here for the big picture.
- 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.
- SDD project defines the separate spec-driven development lifecycle component and its relationship to Governance.
- 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, SDD, and governance 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.
The rendering and SDD projects may be customers of governance tooling, but they must not depend on that tooling to do ordinary component work. If governance tooling becomes heavy, brittle, or distracting, the component repositories should continue on standard Spec Kit and normal build/test/release practices.
Atlas is the primary curated project-knowledge archive and retrieval path.