Story: Manage reports from the list a party runs — the remaining work

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.

• Opening reporting lands on the list of reports the party runs, and not on a choice of areas.
• One row per definition the party owns, and each row states its name, its report type, its schedule, when its latest run started, how long it took, its health word, and the errors that run recorded.
• The health word is one of failed, completed with errors, running, never run and completed clean, and it is derived from the definition's latest run.
• A row that completed while carrying errors is drawn apart from a row that completed clean, without the person opening anything, and the errors cell separates errors from warnings.
• A definition that has never run does not read as clean.
• A party that owns no definition is stated as such, in words, and not shown as an empty table.
• Choosing the conventions a report binds reaches a list of named convention sets and one link out to authoring. Report management does not author a set.
• Authoring a party's analytics is reached the same way: a link out, and not a surface on this screen.
• Every read the screen makes is party-scoped from the session, and a person who may not read a row is shown no action that would be refused after they press it.

• Split from Manage reports from the list a party runs on 2026-10-24 at sprint 28 close. The acceptance above is copied from that story; its done tasks are recorded there.

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.