Development Methods

Method Governance lets you choose, at setup, how your solution will be developed. That choice guides how the agent designs during THINK, it is ratified in the governed context at the freeze, and it is checked afterwards.

declare (setup / THINK)  ->  ratify (freeze)  ->  verify (freeze check, validation, audit)

Available since GTT 1.7.0 (GTT Bootstrap and GTT CLI). The texts of every method on this page are copied from its Method Pack, the single source: https://github.com/GTT-Community/gtt-bootstrap/tree/main/.gtt/methods

Why it matters

Without a chosen method, an AI agent tends to design by layers, because that is the most common shape in its training, not the most suitable one for your project. Epics come out as "data model", "API" and "frontend", and nothing works end to end until the last one is done. When you choose the method, the agent designs with it, and GTT can check that the design follows it.

How you choose it

gtt init asks two questions after the Method Plan. Without a terminal, answer them with flags; without an answer the method stays OPEN:

gtt init --dev-method ddd,vertical-slice --start walking-skeleton
gtt init --dev-method help

Question 1. How do you want to organise the development of your solution?

Methods may be combined, for example DDD to define the Epics and Vertical Slice to cut them. A combination the packs declare incompatible is refused, and you are asked to change it.

Vertical Slice (recommended)

The system is organised by complete features, not by technical layers. Each slice is one use case that crosses everything it needs (input, logic, data) and lives together in its own folder. Adding a feature is adding a slice, not touching five layers.

Fits when: You will deliver end-to-end features one at a time and want each change contained in one place.

Domain-Driven Design

The system is divided into bounded contexts: areas of the business with their own model and language. Each context owns its data and rules, and the others use it only through its public contract. It combines well with Vertical Slice: DDD defines the Epics and Vertical Slice cuts them.

Fits when: The business is complex, has areas with their own rules and vocabulary, and getting the model wrong is costly.

Event-First

Design starts from the facts of the business: the events that happen ("order confirmed", "payment rejected"), the commands that cause them and the policies that react to them. Modules talk by publishing and consuming events, not by calling into each other.

Fits when: The business is a flow of steps over time, with several parts reacting to the same thing or long-running processes.

Hexagonal (Ports and Adapters)

The domain sits at the centre and knows nothing of technology. It talks to the outside through ports (interfaces it defines), and adapters connect those ports to the database, the web, queues or external services. Changing a technology is changing an adapter.

Fits when: The business logic must outlive changes of database, framework or providers, and you want to test it without infrastructure.

Layered

The system is organised in stacked technical layers: presentation, application and data. Each layer uses only the one below and knows nothing of those above. It is the best-known form and the one most frameworks ship with.

Fits when: Your team and framework already work in layers and the system is mostly forms and data with little business logic.

I am not sure, help me choose

Nothing is chosen now. During THINK the agent reads your sources, proposes a method as a [PROPUESTA] with its reason, and you confirm. Without your confirmation the method stays OPEN.

Question 2. How do you want to start?

Walking Skeleton (recommended)

Before building features, build the thinnest version of the system that works end to end: one input, one minimal rule, one stored datum, deployed and tested. Each later Epic then puts flesh on that skeleton instead of inventing the structure as it goes.

Fits when: The stack, the deployment or the integrations carry risk and you want to find the problems in the first week, not at the end.

Straight to the main functionality

No skeleton Epic first: the first Epic is the most important functionality.

Help me choose decides nothing

• The agent reads your sources and proposes one method as a [PROPUESTA], with its reason and the parts of your documents it rests on
• It designs no Epic until you answer
• If you do not confirm, the method stays OPEN. An OPEN method does not block the freeze, but it is recorded as an open gap and shown as OPEN in the stack map
• The recommended method is never applied by default

The same Epic, two ways

An online shop, Epic "Customers can buy". Designed by layers, it becomes three Epics that only work when all three are finished:

EPIC-001  Data model: products, carts, orders
EPIC-002  REST API for carts and orders
EPIC-003  Frontend: catalog, cart and checkout screens

Designed with Vertical Slice and a Walking Skeleton, the first Epic is the thinnest path through the whole system, and each later slice delivers something a customer can use:

EPIC-001  Walking skeleton: one product, one order, deployed and tested end to end
EPIC-002  Customers can buy
          S-1  Add a product to the cart
          S-2  Pay for the cart
          S-3  See the order confirmation

Each slice in the Epic design records its use case, input and output, logic, the data it touches, its acceptance criterion and what stays out of it.

The Method Lock

When you confirm the context, the chosen method is written in the governed context and ratified at the freeze:

• architecture.md states the method and why, in words, plus a small block that scripts read
• An ADR locks it when the method is an architectural style. A start strategy such as Walking Skeleton needs no ADR
• The stack map shows a Development method row, and its dependency rules are written with your project's real folders, for example "src/features/* must not depend on another slice"

What is checked, and where

gtt check reads the ratified method and verifies its dependency rules in the code with the language's own tool. GTT has no import analyser of its own:

gtt check

• JavaScript and TypeScript: dependency-cruiser, installed in your project (npm install --save-dev dependency-cruiser). GTT never downloads it for you
• Without the tool installed, gtt check says the result cannot be determined (exit 7). It never reports a pass it did not verify
• Any other language has no adapter yet: the method is reported as declared-only for the code. That is reported, never hidden
• gtt dev-method shows the method in force, its status, the ADR that locks it and its verification level

The verification level each method declares:

A violation is reported as a conflict, with the rule, the source file and the forbidden dependency, and gtt check exits 1. GTT never corrects your code or your context on its own.

Changing the method after the freeze

The ratified method is not changed directly, and gtt init does not ask the questions again. A change is a change request with an impact analysis: which slices or modules move, which rules of the stack map change, which ADR is replaced. You decide, and a new freeze ratifies it.