FE-539: Explicit phase outcomes and scope closure#33
Conversation
FE-539 Explicit phase outcomes and scope closure
Replace pure Acceptance
FE-567 Phase-aware observer extraction
Teach the observer to bias extraction by interview mode: scope prefers framing and constraints, design prefers decisions and assumptions, and later modes surface requirements, criteria, and revisions. Acceptance
|
🤖 Augment PR SummarySummary: This PR replaces implicit “resolution” semantics for scope with an explicit, persisted phase-outcome/readiness record and a user-confirmed closure flow. Changes:
Technical Notes: Workflow readiness is derived from the latest non-superseded outcome whose proposal turn remains on the active path; confirmations are carried through the same chat transport via typed data parts for durable replay/hydration. 🤖 Was this summary useful? React with 👍 or 👎 |
| observerResultPartSchema, | ||
| phaseSummaryPartSchema, | ||
| askQuestionToolPartSchema, | ||
| proposePhaseClosureToolPartSchema, |
There was a problem hiding this comment.
src/shared/chat.ts:295 — assistantPartsSchema now accepts tool-propose_phase_closure, but BrunchAssistantPart (used for persisted assistant parts elsewhere) doesn’t include that variant, so the code relies on unsafe casts and downstream handling may silently ignore this new tool part.
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| execute: async (input) => { | ||
| createPhaseOutcome(db, { | ||
| projectId, | ||
| phase: input.phase, |
There was a problem hiding this comment.
src/server/interview.ts:111 — createProposePhaseClosureTool() receives the current phase but persists phase: input.phase, so a malformed/LLM-mistaken tool call could write a phase outcome for a different phase than the turn’s actual mode.
Severity: medium
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
|
|
||
| void sendMessage({ | ||
| parts: [ | ||
| { type: 'text', text: 'Confirm scope closure' }, |
There was a problem hiding this comment.
src/client/workspace/workspace-controller.ts:113 — confirmPhaseClosure() hardcodes the text "Confirm scope closure" even though data-phase-summary includes a phase; if a non-scope closure is ever proposed (or the model emits the wrong phase), the UI/confirmation text will be misleading while still confirming the proposal by turnId.
Severity: medium
Other Locations
src/client/routes/InterviewWorkspace.tsx:64src/client/routes/InterviewWorkspace.tsx:78
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
| ? { kind: 'persisted-turn', turn: lastTurn } | ||
| const latestPhaseSummary = findPhaseSummary(messages); | ||
| const phaseSummary = | ||
| latestPhaseSummary && (isLoading || workflow.phases[latestPhaseSummary.phase].status === 'proposed') |
There was a problem hiding this comment.
src/client/workspace/workspace-controller-core.ts:284 — phaseSummary is shown only while isLoading or when workflow.phases[phase].status === 'proposed', which can briefly hide the confirmation card after streaming ends but before router.invalidate() refreshes workflow, causing a flicker/momentary prompt re-enable.
Severity: low
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
8dce4a8 to
d041872
Compare

No description provided.