Story: Manage reports from the list a party runs

Report management gets a UX of its own, and its front door is the list of reports a party runs. The person opens reporting and lands on one row per report definition their party owns. That row is where the arc of a report becomes visible to a person: what exists, when it last ran, whether it is healthy, and when it runs next. Everything else in the group is reached from a row.

The arc is the whole argument of the screen. A definition exists (its name, its type, its party). It ran (the start and the duration of its latest run). It is healthy or it is not (one of five health words, derived from that run and never from the definition). And it will run again, or it waits for a person (its schedule, and, where the server can answer, when it fires next). A report that has never run appears on the same list with a word that says so, because nothing ran and nothing was checked.

Complex inputs keep their own surfaces. A report does not author its conventions, and this story does not author a party's analytics. Report management chooses and links out; the authoring UX is somebody else's front door.

The story closes on the tasks it finished:

• Specify the reports a party runs screen and its server gaps.
• Close the gaps the reports a party runs screen records.
• Record the plotting requirements the reports screens inherit.
• Build the reports a party runs screen and its endpoint.

• Closed at sprint 28 close with its 4 done tasks. The 2 open tasks and the original acceptance moved to Manage reports from the list a party runs — the remaining work in the product backlog inbox.
• The front door is the list of definitions, not the ledger of runs. The person arrives with no identifier, so the screen answers from the party alone. What is scheduled is the thing a trading desk checks before the first number is quoted. The prototype's ledger-first and attention-first variants remain readings of the same facts, and they are filters and histories behind this list, not the landing page.
• Health comes from the latest run, never from the definition. A definition can be perfectly healthy while its last run failed. The latest run is the run with the greatest start among the runs of that definition.
• Complex inputs get their own screens. Report management chooses a named set and links out. The pattern is Name the convention sets a report chooses: a short list, a choice, and one link. This story borrows that pattern for analytics rather than inventing a second one, and that story is the place the pattern is argued.
• The analytics half is not authoring. Analytics need the same treatment conventions received, so report management does not carry the analytic authoring story. Authoring analytics is its own UX, and it is deferred.
• A gap is a deliverable. Where the server cannot answer a column, the answer is a recorded gap, not a change to the design. The first task carries the initial list.

The screen the story asks for is the one See the reports a party runs describes, and that journey is the design intent. The prototype is See the reports a party runs, in the group Reporting prototypes, and its design note says what each of the three variants argues and what is fake.

The rest of the group is already written down, and it is not this story:

• Reading a run's outputs is Read what a run produced.
• Diagnosing a failure, down to the trade, the analytic or the curve, is Find out why a run went wrong.
• The schedule editor, which chooses when a report runs, is Choose when a report runs.
• Running one report now and watching it finish is Run a report and watch it finish.

This story owns the front door those four are reached from. It does not restate them, and it does not change them.

• The implementation itself. The first task is a specification and a server-side gap analysis. The screen, its endpoint and the reads it needs are the work that follows.
• Authoring conventions. A person chooses a named set here and follows one link out. Creating a set, naming it and binding its kinds belongs to conventions.
• Authoring, editing or publishing a party's analytics. Report management links out to that surface when it exists. No analytic is created, edited or published from this story.
• Any change to the prototype. The prototype is the design intent. Where it shows something the server cannot supply, the gap is recorded, and the prototype is not rewritten to hide it.
• Any schema, service or seeder change to close a gap. Each gap the first task records becomes the task that closes it, and those are their own work.
• The other six reporting journeys. Their screens, their writes and their states are not designed here.

• Reporting journeys — the group this story opens, and the vocabulary the rows use.
• Name the convention sets a report chooses — the conventions pattern this story borrows for analytics.
• Reporting prototypes — the ten prototypes, and the one this story implements.