1. What is the nature and description of the request?

The Jobs list view currently shows only the overall job state (pending/running/successful/failed). There is no mechanism to surface custom, component-level or task-level status information inline in the Jobs list while a job is running.

Customers orchestrating external services (e.g., microservices called via API or shell commands) from AAP playbooks need at-a-glance visibility into the progress of individual components without opening each job's Output/Events view.

The request is to add a capability for running jobs to expose user-defined sub-statuses (key/value pairs) that are rendered inline in the Jobs list row.

2. Why does the customer need this? (List the business requirements here)

The customer's playbooks orchestrate N microservices that run in parallel/series. Each microservice returns its own status (running/success/failure) via EDA webhooks. Release operators need a compact, at-a-glance view in the Jobs grid to understand which microservices are still running or have failed — without opening each job's Output.

• Shortens triage time during releases
•  Avoids constant drilling into individual job Output views
• Aligns with the real-time nature of AAP but at a summarized granularity

3. How would you like to achieve this? (List the functional requirements here)

Possible designs:

• A secondary, expandable pill/badge group in the Status column that maps to structured events (e.g., via set_stats, a special callback, or a supported annotation API) coming from the running job
• A hoverable tooltip or mini "progress chip" that lists <component>: <state> pairs derived from job events
• An API contract to submit intermediate "component status" updates (key/value) from a running job so the UI can render them.

Acceptance criteria:

• From the Jobs list, an operator can see the current state of each user-defined component (running/success/failed) reported by the playbook
• No need to open the job Output to get a quick state overview
• States refresh in near real-time while the job runs

4. List any affected known dependencies: Doc, UI etc.

• UI — Jobs list view needs new rendering capability for sub-status data
• API — New endpoint or extension to accept intermediate status updates from running jobs
• Docs — New feature documentation for the annotation/sub-status API