Describe the direction. Not the tasks.
Write down what you want to see and what must not change. YATFA cuts it into proposals and tickets one slice at a time — each slice cut from the codebase as it stands, after the last one landed.
How a direction becomes work
Six steps, from one paragraph you write to a pause with a written account. Click any step.
- shift_reports_controller.rb
- time_window.rb — the resolver the sibling pages use
- reports/index — today: “this calendar month” only
Presets plus a custom from/to — through the resolver the sibling pages already use.
Cut now — from code that already has the window control.
Every slice this direction named has landed. What remains is a reading for you, not code.
Why cut at execution time?
The same slice, written two ways: on day one against the code as it was, or when its turn came — after three slices had landed. Switch between them.
Know at a glance whether a direction is alive
Every direction carries a delivery state read from what actually merged — not from a status someone forgot to update. Change what happened on any row and watch the state follow.
A pause is a signal, not a failure
When there is nothing left to derive from the code as it stands, a direction stops and writes you an account. You choose what happens next.
Nothing left to derive from main
Pick an answer on the left to see what it does.
It can suggest directions. Only you start them.
YATFA may propose a direction from what it keeps running into — a gap that came up again and again, a surface everyone works around. A proposed direction does nothing until a person activates it. Try it in the list at the top of this page — open “Search coverage”.
Two record types went live without search in six days — each time found later, by hand. Derive coverage from the list of record types, so a new one can’t ship unsearchable.