Delivery Plan

Before the work starts, GTT turns your design into a plan with hours, fronts and a finish date, and tells you whether it fits the time you have. While the work runs, it measures real time against the estimate without spending a token. Everything is computed by scripts from your files; the agent only explains and proposes, and you decide.

Available since GTT 1.10.0 (GTT Bootstrap and GTT CLI). Details: https://github.com/GTT-Community/gtt-bootstrap/blob/main/.gtt/docs/delivery.md

The six questions

GTT asks them at the start, one at a time, and "I do not know yet" is always valid: nothing is invented.

• Who builds this: you with one agent, you with several agents in parallel, or a team of people each with their agent.
• How many parallel fronts you can sustain (it depends on the usage limits of your agent plan). If it is a team, their names: they own the fronts.
• When you need a first usable version: in days, in 1-2 weeks, in a month or more, or no date.
• What you prioritise: arrive fast, balance, or build everything in-house.
• Whether you can use third-party services for the generic parts (login, payments, email, files).
• The cap per Epic before GTT warns you: one full agent day (8 hours) by default.

`gtt init` asks the first three right after the Autonomy Profile; the Initial Design Questionnaire asks the rest. You can change any answer later with `gtt delivery set`, because it is operation, not architecture.

The plan before you start

During THINK the agent estimates each Epic in **agent hours plus human decision points**, never in weeks of a person. For each generic capability it compares building with integrating a service, with a dated source: an integration is an architecture decision and needs an ADR. It then splits the Epics into fronts that do not touch the same paths, and names the first vertical slice that delivers value.

`gtt plan` computes the rest: the plan per front, the longest chain of dependencies and the estimated finish. If it does not fit, it says so before you start and lists the levers with the hours each saves: parallel fronts, buying instead of building, cutting an Epic. Every lever is a proposal.

`gtt plan --lanes` prints one summary per front (its Epics, the paths it may touch, the interfaces it depends on, its Done when) and the `git worktree add` commands to copy. GTT does not create agents, sessions or worktrees: that belongs to your ADE.

Measuring while you work

Every change of status of a Story or Epic is appended, with its time, actor and front, to `gtt-domain/delivery-log.jsonl`. A script writes it from what the backlog says; the agent cannot write it. After three measured Stories the plan calibrates: the estimated finish uses the real/estimated ratio of your own Stories. Until then it says "uncalibrated".

`gtt report` shows percent per Epic, real against estimated time, the ratio and the forecast.

Signals

Observation raises these when they happen. What each means depends on your Autonomy Profile.

At the freeze, the same rules are checked: Light only warns, Medium requires the decisions, Hard and Team block. A project that never declared delivery planning is not obstructed.