[devin-ai-integration]

Summary

The generation progress bar snapped between stage boundaries — renderPipelineTrack() wrote completedStages / 3 * 100%, so the fill had exactly four positions and nothing moved while a stage was in flight.

Each stage now owns a third of the track and the fill eases inside its slice, the same shape CommitPhases uses for the deploy overlay:

• pipelineTrackPercent() returns (activeStage - 1) * 33.3% + 33.3% * 0.95 * (1 - exp(-elapsed / 12)) while the active stage runs — approaching 95% of the slice asymptotically so a slow stage still looks alive without ever claiming it finished.
• pipelineStageStartedAt re-arms on every updatePipelineProgressStep(); the existing 250ms pipelineElapsedTimer tick now also re-renders the track, so the fill moves continuously.
• Real completions still land on exact boundaries via the done/3 fallback; a failed stage freezes where it eased to; refine/fix re-entry at stage 2 starts its slice consumed (skipped stage 1 reads as passed).
• New e2e holds all three stage responses and asserts the fill strictly increases inside each slice and never crosses a boundary before the response lands.

Evidence

• CI=1 CCC_TEST_PORT=3105 npx playwright test stu377-pipeline-progress → 30/30 passed (new spec: the track eases through each stage's slice instead of jumping)
• npm test → 396/396 passed

Link to Devin session: https://app.devin.ai/sessions/2c1947d6c8094275a078fc26277154d5
Open in Devin Desktop: https://app.devin.ai/desktop/session/2c1947d6c8094275a078fc26277154d5?variant=devin
Requested by: @sgardoll

---

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access that start with 'Devin'.

• Disable automatic comment, CI, and merge conflict monitoring

[greptile-apps]

This PR does not match any of the 1 configured review trigger rule.

[devin-ai-integration]

Verified the smooth progress bar end-to-end against the real backend (not mocks). A full 3-stage generation run on the Vite dev server showed the fill easing continuously inside each stage's slice instead of jumping at boundaries.

Instrumented #pipeline-progress-fill every 100ms across the whole run:

• Stage 1 in flight (~19s): 77 distinct widths, strictly increasing 16.1→28.5%, never past the 33% slice
• Stage 2 in flight (~26s): 105 distinct widths, strictly increasing 33.3→61.4% — segment started exactly at 33.3333% when the architect response landed
• Stage 3 in flight (~14s): 55 distinct widths, strictly increasing 66.8→88.1%
• Zero decreases anywhere; fill hit exactly 100% on the final response and the results view rendered (score 100/100)
• Elapsed counter ticked normally throughout

More evidence

The branch's own spec the track eases through each stage's slice instead of jumping also passes.