Developer tools · multi-repository workspaces
Turn a ticket into a complete development workspace. Repositories, agents, builds, and services—connected.
A ticket can touch several repositories. The setup finds its branches, reuses matching workspaces, and creates a coding-agent thread for each participant. Review the release, database, backend connection, and deployable artifacts together. Preparing the worktrees is a separate choice from building and starting the application.
See which modules will build and why before execution. Changed mode follows module inputs and affected dependencies; Full build and Selected give explicit control. The Build view keeps module results, output, diagnostics, and history together, with separate actions for compilation and deployment.
Each ticket gets its own application-server instances, port allocation, build cache, and frontend dev server. The Services view exposes startup steps, deployment state, and the frontend’s backend connection. Stop, restart, and teardown act on the ticket’s Stack while its repository threads retain the shared context.
Under the surface
A single business-software change can span shared Java libraries, backend services, and frontend applications. Getting ready to work often means reconstructing the ticket, checking out several branches, choosing a release toolchain, and bringing up the right services. I’m building GFOS Code to make that one coherent workflow: choose the ticket, prepare its workspaces, work with agents, then build and run the application with the same context.
The build system derives dependency order from Maven POMs and tracks module inputs, including uncommitted changes. Auto mode selects changed modules and their affected consumers; generated inputs and deployable EAR packages are part of that decision. Build previews explain the selection before execution. A verified artifact can be reused when its inputs still match, while uncertain state falls back to a full build.
A Stack is shared by the ticket’s repository threads. It owns isolated worktrees, Maven caches, application-server instances, and allocated ports. Build and deployment are separate actions: prepare the code, build selected modules, or build and start the application. Release-specific Java and WildFly configurations, frontend backend selection, retained build history, and restart recovery make the lifecycle inspectable.
I build the GFOS workflow in dedicated modules on top of T3 Code’s open-source agent harness and base clients. That gives repository threads the existing agent, diff, and terminal experience while keeping the ticket and Stack lifecycle cohesive. The Windows client and WSL execution environment retain explicit ownership of paths, build tools, and deployed artifacts.
Ticket activity can be reviewed by week or month, with editable descriptions and an allocation of overlapping agent sessions. It connects the development work back to the ticket without double-counting simultaneous turns. These are activity estimates for review; they do not automatically book time into company systems.