PlanCard.vue currently takes the plan as a single string and hands it to RichContent to render as markdown, with Approve, Edit, Request changes and Reject underneath.
Once the Expert emits plans as structure, the card should render the units as units: the name and goal as the card's own header rather than markdown headings inside the body, and each unit as its own row.
Which then gives somewhere for status to live, so as the Expert works through an approved plan the user can watch it happen rather than waiting for a message at the end.
Done when
- A structured plan renders with its name, goal and units laid out as data rather than as one markdown block.
- Each unit is visually distinct and can show a status.
- Approve, Edit, Request changes and Reject all still work exactly as they do now.
Worth knowing
The four actions are load-bearing and shouldn't get lost in the redesign. The prompt tells the Expert those buttons are the only way the user responds to a plan, and that it must never ask whether to proceed, so if a button disappears the conversation has no way forward.
Unit instructions may still contain markdown inline, even once the plan is structured. So RichContent probably still renders each unit's text, just per unit instead of once for the whole plan.
Worth checking how this interacts with the streaming behaviour in AnswerWrapper, which sequences which parts of an answer appear in what order. A plan is currently one block that streams; several units might want to appear in sequence, or all at once, and that's a deliberate choice rather than something to leave to chance.
Progress display is arguably the more valuable half of this task and it's easy to treat as optional. If the artefact tables carry unit status, and this card can show it, then an approved plan being worked through becomes visible. That's the thing that makes the build phase feel like something happening rather than a wait.
PlanCard.vuecurrently takes the plan as a single string and hands it toRichContentto render as markdown, with Approve, Edit, Request changes and Reject underneath.Once the Expert emits plans as structure, the card should render the units as units: the name and goal as the card's own header rather than markdown headings inside the body, and each unit as its own row.
Which then gives somewhere for status to live, so as the Expert works through an approved plan the user can watch it happen rather than waiting for a message at the end.
Done when
Worth knowing
The four actions are load-bearing and shouldn't get lost in the redesign. The prompt tells the Expert those buttons are the only way the user responds to a plan, and that it must never ask whether to proceed, so if a button disappears the conversation has no way forward.
Unit instructions may still contain markdown inline, even once the plan is structured. So
RichContentprobably still renders each unit's text, just per unit instead of once for the whole plan.Worth checking how this interacts with the streaming behaviour in
AnswerWrapper, which sequences which parts of an answer appear in what order. A plan is currently one block that streams; several units might want to appear in sequence, or all at once, and that's a deliberate choice rather than something to leave to chance.Progress display is arguably the more valuable half of this task and it's easy to treat as optional. If the artefact tables carry unit status, and this card can show it, then an approved plan being worked through becomes visible. That's the thing that makes the build phase feel like something happening rather than a wait.